[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
https://bugs.libre-soc.org/show_bug.cgi?id=216
--- 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
recombined.
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