[libre-riscv-dev] [Bug 336] ALU CompUnit needs to recognise that RA (src1) can be zero

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=336

--- Comment #30 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #28)
> Don't lose sleep about it, I can handle the FSM.(In reply to Luke Kenneth
> Casson Leighton from comment #25)
> > not quite correct, did something different, do git pull see if you can
> > get the test to work.  will take a look in morning.
> 
> Don't lose sleep about it, I can handle the FSM. It's my bread and butter.

:)

i realised that actually there's probably nothing wrong with the modification
i made: it's the unit test that must not check a flag (rd.req) that is never
going to get set.


(In reply to Cesar Strauss from comment #29)
> (In reply to Luke Kenneth Casson Leighton from comment #22)
> > if rd.rel[0] is being set when zero_a is on, yes that's bad.
> > 
> > rd.go[N] is an external response to rd.req[N].  this is why it is critical
> > to get rd.req and wr.req bits set right because the external user of the
> > CompUnits kniws nothing about *why* they are set, they just respond.
> 
> In this case, "external user" are the dependency matrices, right?

yes.

> I've read https://libre-soc.org/3d_gpu/architecture/6600scoreboard/.
> 
> As far as I understand it, the Dependency Matrices also need to know
> themselves that the operand is immediate, 

not quite.  immediates are immediate, therefore there is no concept of a
"dependency".  

therefore, technically you are correct, but it is by way of "total omission
of involvement".

> and not set the corresponding FU-Reg Latch, correct?

by way of the DMs not in the slightest remote bit knowing *anything* about
immediates.... yes.

> Is this already implemented?

yes.  the DMs manage "dependencies".  an immediate is not a Dependency
Hazard (not a read or write register).

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