[Libre-soc-bugs] [Bug 392] wiki page needed for documenting nmigen behaviour when using "Settle()"

[bugzilla-daemon at libre-soc.org]

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

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #1)

> 4) We change any signals we like.
> 
> Because we are already past the clock edge, we cannot influence any
> registered output on this cycle, even if we change their inputs.
> 
> Combinatorial logic, on the other hand, will really be influenced, on this
> cycle.
> 
> 5) We call Settle()
> 
> The time point moves to when all propagation delays are over, when both
> registers and combinatorial logic had a chance to propagate and settle their
> final values.

rrright.  i had to think about what is going on here.  i can confirm that
removing Settle() from the test code, after a yield which is supposed to
perform full clock sync, results in *failure* of the test.

the only reason i can think of why that would be the case is if, inside
the FSM that creates new output on each new clock cycle, the output is
*NOT* directly from a register/latch, it is from yet more further combinatorial
logic that is created **FROM** clock-synchronised registers/latches.

consequently, although we intuitively might expect the data to be valid at
the clock, certain designs this will not be the case and it's going to be
something we seriously have to keep an eye on.

i don't know if it's just unavoidable or it's bad design practice.

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