[Libre-soc-bugs] [Bug 417] FSM-based ALU example needed (compliant with ALU CompUnit)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #15 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #14)
> (In reply to Luke Kenneth Casson Leighton from comment #13)
> > interesting!  a "yield" was missing which was only caught by cxxsim
> 
> I tried running cxxsim by "git checkout cxxsim" in nmigen, updating yosys to
> latest git master, and setting "cxxsim = True". But it is giving me weird
> waveforms (signals are changing on the falling edge of the clock).

yes.  i believe this is down to the combinatorial logic appearing at the
"earliest convenience" which is the falling edge.

pysim will actually, if you zoom in really closely, change combinatorial
logic a few nanoseconds after the clock tick.

> 
> > commit fc256a3df6502d725131a3aa979c2a88aa695d3d (HEAD -> master)
> > Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > Date:   Sun Jul 19 15:53:36 2020 +0100
> > 
> >     fix bug in alu_fsm.py found by cxxsim: missing one cycle hold of ready_i
> 
> There was already a one cycle hold of ready_i.
> 235   # signal readiness to receive data
> 236   yield dut.n.ready_i.eq(1)
> 237   yield
> 
> You added another one, and now there are two.
> 244   # must leave ready_i valid for 1 cycle, ready_i to register for 1 cycle
> 245   yield
> 
> Looking at the waveform, I can see that, after the last transfer, ready_i is
> held for one extra cycle, which is wrong.

ok so this is just what it took to "fix" the problem in cxxsim.  

                 m.d.comb += self.n.valid_o.eq(1)
                 with m.If(self.n.ready_i):
                    # go back to IDLE when the data is accepted
                    m.next = "IDLE"

this *should* set the FSM to "IDLE" on the *next* cycle, however
the fact that in the unit test ready_i is dropped *immediately*,
combined with the fact that valid_o is set combinatorially, what
happens instead is:

* valid_o is set to 1 (combinatorially)
* unit test (combinatorially) notices that (in the while yield loop)
* unit test (combinatorially) sets ready_i to 0
* DUT - *combinatorially* - notices that ready_i has been set to 0
* DUT *NO LONGER ASSERTS m.next=IDLE*

and this combinatorial bun-fight shows up on the *falling* edge.



> What did you see in cxxsim? Is it possible that cxxsim is giving wrong
> results?

yes it is a possibility.  cxxsim is very new.

> If the simulation stops too soon, we can add an extra yield, after receiving
> the last result.

it doesn't stop at all.

whitequark is aware of the bug that we're running into.  it's recorded at:
https://github.com/nmigen/nmigen/issues/439

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