Let p.ready_o be active while the test ALU is idle

The valid/ready protocol doesn't actually forbid p.ready_o
being active while p.valid_i is inactive. It just mean that
the ALU is idle, and is ready to accept new data.

This should help avoiding potential combinatorial loops from
p.ready_o to p.valid_i.

diff --git a/src/soc/experiment/alu_hier.py b/src/soc/experiment/alu_hier.py
index 5b1968c2a19a085a478b179380fad3f205f60cce..581fd11324d50a0fccf7814c0895a22ad53d5bbc 100644 (file)
--- a/src/soc/experiment/alu_hier.py
+++ b/src/soc/experiment/alu_hier.py
@@ -227,7 +227,7 @@ class ALU(Elaboratable):
         with m.Else():
             # sequential ALU handshake:
             # ready_o responds to valid_i, but only if the ALU is idle
-            m.d.comb += self.p.ready_o.eq(self.p.valid_i & alu_idle)
+            m.d.comb += self.p.ready_o.eq(alu_idle)
             # select the internally generated valid_o, above
             m.d.comb += self.n.valid_o.eq(alu_done)