[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 #57 from Cesar Strauss <cestrauss at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #56)
> (In reply to Cesar Strauss from comment #55)
> > (In reply to Luke Kenneth Casson Leighton from comment #54)
> > > hmmm i tried putting OP_NOP in there, and both compunit1 and parallel
> > > locked up.  this tends to indicate a combinatorial loop.  any clues?
> > 
> > I see. I'm looking into it.
> 
> it may be because "now" is set at the default action.  i have yet to work
> out how to detect combinatorial loops.  there may be something that can be
> done using yosys synth, michael showed me something a couple weeks ago.  ltp
> command?

Found it manually, staring from valid_o, and changing comb to sync along the
way. Interesting debug experience.

I don't really recall being much afflicted by this sort of issue. But then, I
normally try to avoid using latches as much as possible, this may be the
reason.

commit c8c13adf3da9a6ca8b7765edc597ec7fdf19e8d8
Author: Cesar Strauss <cestrauss at gmail.com>
Date:   Tue Jun 9 08:57:31 2020 -0300

    Avoid a combinatorial loop on valid_o

    The path was:

    all_rd (1) -> all_rd_pulse (1) -> alui_l.s (1) ->
    -> alu.p.valid_i (1) -> ALU (zero-delay) -> alu.n.valid_o (1) ->
    -> rok_l.r (1) -> all_rd (0)

    Decided to break the loop on the reset of the read-done, write proceed
    latch (rok_l.r), with no ill effects on performance.

    Added a test case for this, using the zero-delay ALU (OP_NOP).

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