[libre-riscv-dev] store computation unit

[Luke Kenneth Casson Leighton]

On Sun, Jun 9, 2019 at 6:30 PM Mitchalsup <mitchalsup at aol.com> wrote:

> > From: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > then i thought, hmm, how the hell, in a multi-issue context, where
> > several LD/STs can be issued and retire simultaneously, are we going
> > to wire a single "mismatch" vector from the AGEN mis-match-spotter,
> > back into the MemRef (MDM) Matrix?
>
> When an already AGENed address detects "I cannot be the same as"
> an address which has just been AGENed and is being inserted into the
> MDM, the one already in there is the one that releases its dependence
> on the newly arriving one.
>
> Mc88120 did this 3-wide OoO. Each entry had 3 LOB comparators
> and could relax dependencies from the 3 addresses currently
> being inserted into the MDM.

 yehyeh, i figured something like this might be the case.  three
separate sets of "i cannot be the same as" wires that come in from
both the left and the top (left side would be the LHS of the addr1 !=
addr2, top would be the RHS)

 what i decided to go with is a full overlay of the addrN != addrM
comparisons onto the MDM.  the reason is because of the vectorisation
being perfectly capable of saturating the entire (full) MDM in a
single cycle.

 paradoxically this simplifies the design as there is no need to
consider what would happen if, say, 4 LD/ST-CUs generated AGEN Refs
simultaneously, where there were only 3 LOB comparators.

 with there being exactly N LD/ST-CUs, NxN AGEN matchers and the MDM
being NxN, there's no priority contention to be concerned about.

 i will have to make sure that the AddrMatcher is a pascal triangle
not a full NxN set of address comparators, because addr1 != addr2 is
the same as addr2 != addr1.

l.