[libre-riscv-dev] [Bug 216] LOAD STORE buffer needed

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Jun 5 20:40:37 BST 2020


--- Comment #57 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Tobias Platen from comment #56)
> fixed

fantastic.  you'll see i added some comments in the DualPortInterface.  i think
what might need to be done is:

* to have the the incoming PortInterface.oper_i.data_len
  be one unary bit only (0b1, 0b10, 0b100, 0b1000)

* however for the outgoing ones, due to the "misalignment", they
  can be set to 0b11, 0b111, 0b101, and so on.

actually this is ok! :)  it is a 4-bit field after all.

so basically:

* one LD/ST comes in
* it will be routed to EITHER left (bit 4 ==0) OR right (bit 4==1)
* misalignment possibility results in a *SPLIT* LD/ST that **ALWAYS**
  goes out the **OTHER** port.
* if both ports are to be used, the data from both has to be

now, there are a few things that are different from LDSTSplitter:

1) LDSTSplitter rather hilariously treats the data as 16-bit, not 16-byte.
   this is easily fixable by using Repl on the mask and multiplying by 8
   and so on

2) LDSTSplitter does *NOT* do the correct bit-4 routing.  it is HARDCODED
   to ALWAYS assign non-misaligned data to port 0

            with m.If(mask2 == mzero):
                comb += self.valid_o.eq(self.sld_valid_o[0]) <-- wrong

   fixing that is slightly complicated in that ld1 and ld2 need to dynamically
   swap over.

3) LDSTSplitter although it creates the mask correctly (using LenExpand)
   does not "re-create" the *binary* version of that, which is the key
   information that needs to go back into PortInterface.oper_i.data_len
   along with the "altered" addresses.

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

More information about the libre-riscv-dev mailing list