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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Jun 6 21:53:05 BST 2020


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

--- Comment #50 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #49)
> I'm advancing on the ALU CompUnit parallel unit test. Having gone past the
> rd rel/go interface, I've moved on to the ALU input interface.
> 
> The ALU input interface uses a valid/ready protocol. I assume that this,
> like rel/go, is similar to the wishbone interface.

standard wishbone / AXI4 yes.  the difference being that rel/go will NEVER be
back to back (multiple transactions one after the other) however ready/valid
can be.

however in the MultiCompUnits it is never used for that, because MCU is single
transaction only.

> As such:
> 
> 1) The port is idle when valid_o and ready_i are both zero.
> 2) If valid_o is high but ready_i is low, we have a wait state.
> 3) When both are high, we have a data transfer, and the transaction ends.

or, takes place on that clock cycle, abd ends "as far as the next clock cycle
is concerned".

> 4) It is illegal to keep ready_i high when valid_o is low.

> This is supposed to cover a single transaction, but in my undestanding I see
> 5 acknolowdged back-to-back transactions followed by a illegal state.

this does not surprise me.  the alu_hier.py ALUs were written "in a hurry" and
are there purely for test purposes only.


> Can I go ahead and fix all these cases, to be more like wishbone? Or, is my
> assumption of wishbone likeness wrong?

yes please do...

or...

last week i considered throwing them out and using nmutil.singlepipe ALUs
instead.

if you feel it does not take a long time to "fix" alu_hier.py ALU classes
please do go ahead.

otherwise if it will take a long time it would be better to drop them and
replace them with ALUs based on e.g. TestBufPipe (see nmutil unit tests)

again: they are only there for test purposes, however as tests it is indeed
good for them to properly conform to the required API

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


More information about the libre-riscv-dev mailing list