[libre-riscv-dev] [Bug 257] Implement demo Load/Store queueing algorithm

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Fri Mar 20 11:03:18 GMT 2020


--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (In reply to Jacob Lifshay from comment #1)
> > Luke, it looks like you probably have something that works just as well as
> > this would, so I'm resolving the bug.
> maayybee... i don't know.  it's taking me considerable time to piece
> together.

nope, struggling.  and the N-N-way comparisons for the high MSBs is going to
kill power usage.  took me a while to realise what you were saying about using
a LRU (we have a PLRU implementation here):

can you take a look?  assume that each LD/ST buffer has *two* "ports",
one that is 16 bytes wide with address port0_addr and is normally used,
the other is *8* bytes wide (actually, 7), is *always* at port0_addr+16,
and deals with misalignments.

actually, that's a red herring.  to clarify: it's safe to assume that
misalignments have  been "dealt with" by being pre-split into separate
"aligned" ports.

also assume that addresses+len are expressed as:

* top bits numbered 4 and up as a binary address
* LSBs 0 to 3 as a 16-bit unary "mask" which *also* encapsulates data length

(with no misalignments, which means that some mask bit groups will be
non-power-2 long)

also assume that it is *guaranteed* - by this class - that there will be
ZERO overlaps.  as in, absolutely guaranteed.


it's the top MSBs of the address that are not covered by that (because it's
too much).

i figured, rather than a ring buffer, a PriorityPicker could identify QTY 1
address to put through, then all other address MSBs go through... the PLRU?

i get lost at this point.

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

More information about the libre-riscv-dev mailing list