From 2b4b3a653806c543a17b5f6e6db2c00d24996210 Mon Sep 17 00:00:00 2001 From: Cesar Strauss Date: Sun, 28 Jun 2020 18:38:03 -0300 Subject: [PATCH] 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. --- src/soc/experiment/alu_hier.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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) -- 2.30.2