[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue Jan 5 17:02:08 GMT 2021


https://bugs.libre-soc.org/show_bug.cgi?id=560

--- Comment #86 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #84)
> (In reply to Jacob Lifshay from comment #82)
> 
> > still suffice since each individual byte can only be unswapped, 16-bit
> > swapped, 32-bit swapped, or 64-bit swapped. no other combinations are
> > supported/needed since they are ruled out by the natural alignment
> > requirements.
> 
> this really needs diagrams to go over it.  i did a video, it is still
> uploading (horribly slowly)
> 
> i think what you are suggesting is one of the following:
> 
> * to impose a restriction on the permutations permitted by the Dynamic
> Partitioned SIMD ALUs (to 888888 16161616 3232 and 64) 

That's what I proposed in comment #81, however in comment #82 I realized that
we don't need to restrict it that much, we only need to restrict it to have
elements be naturally aligned (not what you appear to think it is) which we
need anyway since the SIMD mul unit already expects that.

I'll create some illustrations today.

> now i have written them out those are the same thing.  i thought that one of
> them might involve moing the dynamic byteswapping to be part of
> MultiCompUnit, where the quantity of gates gets multiplied even more than it
> already is.

The byte-swapping would be a pipeline stage right after the mux for selecting
which FUs to execute, as well as another stage right before the results are
sent back to those FUs. It most likely won't need to make any pipelines take
any more clock cycles.

If we make changing the SPR bit for the CPUs data endian mode trap so we can
run 64-bit byteswap instructions on all registers to keep the OpenPower
expected values, then we don't need the byteswap HW at the register file, it's
only needed in the ALU/ld-st/etc. pipelines.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libre-SOC-ISA mailing list