[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 #60 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #59)
> Created attachment 64 [details]
> Suggested pipeline design for the ALU Comp Unit
> 
> (In reply to Luke Kenneth Casson Leighton from comment #58)
> > (In reply to Cesar Strauss from comment #57)
> > > I don't really recall being much afflicted by this sort of issue. But then,
> > > I normally try to avoid using latches as much as possible, this may be the
> > > reason.
> > 
> > yyeah they're not a "normal" way to do FSMs.  however with some aspects being
> > combinatorial and some being sync, we can't use "standard" techniques.
> 
> Did you consider implementing the ALU CompUnit as a pipeline?

you mean, MultiCompUnit itself?  if so: this would violate the mission-critical
protocol, the purpose for which MultiCompUnit exists.

MultiCompUnit *must not* abandon its data.  its absolutely must track the
operands from start to finish.

we call this a "Phase-aware Function Unit".  "phase-aware" because it
absolutely
has to keep track of the start time and completion time.
failure to do so would be absolutely disastrous.

a pipeline *abandons* its data.  it says "here, you deal with it, i'm
abdicating
all responsibility for data-tracking".  i.e. once the data is in the pipeline,
there is *no hardware* in the actual pipeline itself which tracks or handles
responsibility for tracking the completion of that result.

this was the subject of a rather excruciating discussion on comp.arch: it
became
clear that there simply does not exist an Industry-standard or Computer Science
term that covers "Function Units which track data from operand to result".

one had to be invented, and the best that could be thought of was "Phase-aware
Function Unit"

for an out-of-order system, it is absolutely imperative that we have
Phase-aware Function Units, and that "management" task is what MultiCompUnit
is for.

a pipeline *cannot* fulfil that role.  by definition and by design.

however.... MultiCompUnit can *MANAGE* pipelines... by using the ready/valid
protocol.

and if we have multiple MultiCompUnit front-ends onto a single pipeline,
*now* we have Reservation Stations.

and that's what the ReservationStations class is for:
https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/concurrentunit.py;hb=HEAD#l40


> I can give it a try, in parallel with other tasks. It would be a nice way to
> learn more about the pipeline API.

actually we do need a ReservationStation version of a MultiCompUnit unit test.
a 2 or 3 stage "real" but dummy pipeline (simply passing its input through to
its output, maybe doing +1 on each stage or something, or, heck, doing ADD
would be perfectly on)

then there would be 4 to 5 MultiCompUnits wired up to a ReservationStation
version
of that pipeline (see nmutil multipipe.py)

the unit test would then be an adaptation of the test_inout_mux_pipe.py test,
throwing multiple inputs in and seeing if they come out successfully at the
end.

https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/test/test_inout_mux_pipe.py;hb=HEAD

there's some other code i can refer you to, if you're interested
(and we should raise a new bugreport for it)

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