[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 #49 from Cesar Strauss <cestrauss at gmail.com> ---
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. 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.
4) It is illegal to keep ready_i high when valid_o is low.

As a diagram:

clk      1 2 3 4 5 6
data_i   . D D D D .
valid_i  . 1 1 1 1 .
ready_o  . . . . 1 .
latched  . . . . D .

Back to back transactions are also permitted:

clk      1 2 3 4 5 6
data_i   . A A B C .
valid_i  . 1 1 1 1 .
ready_o  . . 1 1 1 .
latched  . . A B C .

Well, while tracing the ALU input handshake, in the parallel unit test, in
src/soc/experiment/test/test_compalu_multi.py, I found this:

          clk     1 2 3 4 5 6
CompUnit: valid_i . . 1 1 . .
ALU:      ready_o . . . 1 1 .
                          ^
                          trouble

On cycle 5, ready_o is still high while valid_i is low. This can generate
trouble if ready_o is wired-or with other modules.

Worse yet, on the src/soc/experiment/alu_hier.py unit test:

valid_i . . 1 1 1 1 1 1 . .
ready_o . . . 1 1 1 1 1 1 .

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.

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

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