[libre-riscv-dev] [hw-dev] Re: 6600-style out-of-order scoreboard designs (ariane)
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed May 22 20:43:41 BST 2019
On Wed, May 22, 2019 at 6:25 PM Mitchalsup <mitchalsup at aol.com> wrote:
> > * two instructions are both idle
> --Do you mean "two FUs are idle"?
yes, sorry.
> > RD Deps are NORed together to produce "Readable" (which, because
> > the reads are all LO, and there is *NO RD_REQ_RELEASE*,
> > is *PERMANENTLY* HI for *BOTH UNITS*):
> NOR should be OR after ANDING with complement Global_Write.
hilariously, this was one of the many, many, maaaany
random-drunken-walk variations that "showed promise" at being
successful. unfortunately it was masked by other bugs at the time.
> But in any event, if your FUs are idle, then there are no INT_Read_Pending going out and thereby
> there will not be a Readable assertion no matter the Global_INT_Write_Pending.
with ~global_wr_pend & int_rd_pend... yes. however in the case where
there are not yet any instructions, even global_wr_pend is entirely
zero: consequently, NOR gave the false "readable HI" on every FU.
> Readable = 0;
> for(i=0; i < 32; i++)
> Readable |= ~global_INT_Write_Pending[i] & Int_Read_Pending[i];
this makes much more sense, now. let me try to write it in english.
a read may proceed on this function unit if:
for all registers [i] where this function unit needs to read
(int_read_pending[i]), there is no global write that needs to occur on
that same register [i].
that parses in english and logically makes sense.
it's that "A implies B", operator, isn't it.
so, the modifications needed to the FunctionUnit diagram would be as
shown in the jpg? each bit of GLOBAL_INT_Write_Pending is inverted
prior to ANDing with its corresponding readable bit?
l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019-05-22_20-28.jpg
Type: image/jpeg
Size: 83315 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190522/d54eaa5f/attachment-0001.jpg>
More information about the libre-riscv-dev
mailing list