From: Cesar Strauss <cestrauss@gmail.com>
Date: Sun, 28 Jun 2020 21:38:03 +0000 (-0300)
Subject: Let p.ready_o be active while the test ALU is idle
X-Git-Tag: div_pipeline~210
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=2b4b3a653806c543a17b5f6e6db2c00d24996210;p=soc.git

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 5b1968c2..581fd113 100644
--- 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)