[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 #52 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #51)
> (In reply to Luke Kenneth Casson Leighton from comment #50)
> > if you feel it does not take a long time to "fix" alu_hier.py ALU classes
> > please do go ahead.
> 
> One more thing. These test ALUs are non-pipelined, right? I mean, they take
> a finite number of cycles to sequence through their stages, but are not able
> to accept a new operation, each cycle, meanwhile, right?

correct.  this is to simulate FSMs (such as a DIV operation) and also to
provide a way to check that the MultiCompUnits work properly when there is a
delay.

it is a SEVERE violation of the entire MultiCompUnit API for a MCU to expect to
process (generate) more than one result at a time.

this because that implies that it is "abandoning" a result, in direct violation
of its role and responsibility to monitor the result through to completion.

the way to use pipelines: for an N Stage Pipeline, have a minimum of N
MultiCompUnits with a fan-in and fan-out.  this is what the class
ReservationStations is for.

the whole purpose of writing this parallel test is to be able to work towards
the scenario of doing exactly that: have Nx MultiCompUnits throw 100-200
results at a pipeline (a "proper" N-stage pipeline) and check that the results
are consistent.

however that is for later.

> In this case, I think setting ready_o combinatorially, based on valid_i
> being high, and the sequence counter being zero, is enough. This will even
> keep ready_o from activating if valid_i is high and the ALU is still busy.
> Will check if it works.

go for it.

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