[libre-riscv-dev] [Bug 318] fix LDSTCompUnit

[bugzilla-daemon@libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=318

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
+++ b/src/soc/experiment/compldst_multi.py
@@ -477,7 +477,7 @@ class LDSTCompUnit(Elaboratable):
         comb += pi.op.eq(self.oper_i)    # op details (not all needed)
         # address
         comb += pi.addr.data.eq(addr_r)           # EA from adder
-        comb += pi.addr.ok.eq(self.ad.go) # "go do address stuff"
+        comb += pi.addr.ok.eq(alu_ok) # "go do address stuff"
         comb += self.addr_exc_o.eq(pi.addr_exc_o) # exception occurred
         comb += addr_ok.eq(self.pi.addr_ok_o)  # no exc, address fine
         # ld - ld gets latched in via lod_l

ok this "fixes" the address issue for ST.  alu_ok is the signal that
indicates the condition that the ALU address is ok to proceed.

however given that alu_valid and alu_ok are *sustained*, this causes
problems on the alu SR Latch which, if using *only* alu_ok to reset it,
would result in the alu_l being permanently held OFF

to fix that i am doing this:

        # alu latch.  use sync-delay between alu_ok and valid to generate pulse
        comb += alu_l.s.eq(reset_i)
        comb += alu_l.r.eq(alu_ok & ~alu_valid & ~rda_any)

alu_ok is one clock cycle behind alu_valid: therefore alu_ok & ~alu_valid
will generate the required one-clock pulse to indicate that the alu latch
can safely capture the address.

(which we noted previously we don't strictly need to do, but hey)

moving on from there, LD is currently bouncing around like mad.  the ld_ok
condition is being raised, which should end the FSM, however it does not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev