[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