Verilator

Wait on rising edge from c++

I have clock from DUT and I need to sample output in right time.
If I just change main clock and call eval() all combination paths are evaluated and I am not able to read correct value from simulation, because it is too late.

I need somehow call callback if signal value is updated.
Or I need to perform combinational and sequential eval() in separate run.

Replies (6)

Perhaps I misunderstand the problem, but call eval() without changing any clocks, then compute your combo logic, then call eval() again without changing any clocks, repeat your logic and eval() calls until stable.

Yes, with --threads 1 you can have different simulations in multiple thread.

The fundamental problem is really that generated clocks don't work nicely even in an all-verilator model, much less expecting external code as part of the process.

From a IEEE spec sense there isn't really a difference between combo and sequential code, the real difference is when delayed assignments take effect. However Verilator generally squashes this distinction because to do otherwise would be slow (all delayed assignments would need to be stored.)

However for your case it probably is the case that if you make a separate eval_combo call this would solve your issue. I won't make any claims this will solve more general problems; generally at present with Verilator clocks should be fed in, not out of the model for correct results.

If you want to experiment with an eval_combo() call I'd suggest to reduce performance loss that the eval_combo() replicate most of what is in eval() but without any of the clock detection. (Versus splitting combo out of existing eval() which would cause some optimizations to be lost.) This probably goes in V3Clock.cpp

Note the _combo in the function names isn't necessarily only combo code, you need to check the internal AstActive types to see what code is marked combo or not.

satisfied, on first clk edge evaluation just break the _eval() and run it again (if required).

Possibility to read value on clock edge

satisfied, on the BEFORE_RISING_EDGE of specified clock just read the values

Clock gating

probably can be emulated

X, Z, U values

RE:

generated clocks don't work nicely even in an all-verilator model

I think that problem is that Verilator is not discrete event simulator. The problem is that order of events is specified compile time.
But it may not be the problem as it can be solved by disabling of segments of eval() and revaluating of the eval().
But it may be quite hard task to find such a conditions for re-evaluation of the segments.

What do you propose BEFORE_RISING_EDGE will do? Generally this won't work as Verilator assumes all signals are only changed by Verilator itself. Furthermore due to scheduling the same clock may have multiple IF statements.

generated clocks don't work nicely even in an all-verilator model

I think that problem is that Verilator is not discrete event simulator.