[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

Cesar Strauss <cestrauss at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cestrauss at gmail.com

--- Comment #1 from Cesar Strauss <cestrauss at gmail.com> ---
Hello, Yehowshua.

I think your model is mostly right. But, I would replace "right before the next
clock edge" with "right after the registered and combinatorial signals have
propagated and settled". I mean, the function is called Settle, after all...

If you have slow logic, the signals really will take that long to settle. And
it will have an impact on your timing budget, and consequently the maximum
clock rate.

But, on a simulation, logic is infinitely fast. Signals will settle right after
the rising edge of the clock.

If you zoom-in on GTKWave, you will see no delay at all between the rising
clock, and the signals changing.

So, technically, you don't have to wait until before the next clock edge. It's
not wrong if you do, but you would be missing some finer points.

Here is what happens, as I understand it:

1) You just called yield.

This will cause the clock to rise.

2) Yield returns.

The time point, it's just after the clock has risen.

Registers have registered their inputs, but are still outputting their old
value.

This is because flip-flops have a non-zero delay, between the rise of the
clock, and the output reflecting the new value.

Since we are just after the clock has risen, this has not taken place yet.

3) We sample any signals.

As said above, signals (registered or not) will keep the values they had just
before the clock edge.

It's as if the sampling point was just before the previous clock edge.

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.

6) We sample any signals, again

This time, we will finally see the new values of the registers, and any
combinatorial logic that depends on them.

7) We change any signals we like, again.

Here, we have the chance to respond in the same cycle, as if we were
combinatorial logic ourselves.

Hope it was clear.

Regards,

Cesar

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