thanks for help

[simdream]

I am taking zipCPU as an example to learn how to make Verilator used in my project.

From testb.cpp, I noticed you are use one extra eval() before posedge clock:

            // Pre-evaluate, to give verilator a chance
	// to settle any combinatorial logic that
	// that may have changed since the last clock
	// evaluation, and then record that in the
	// trace.
	eval();

But if this is a synchronous design, should the eval() following clock wagging updated the comb logic also? To add one more eval() here might also slow down the run time performance?

Many thanks,

[ZipCPU]

Does this slow down run time performance? Yes.

I discuss this problem somewhat in lesson 4 of my tutorial.

Here's the issue: between calls to tick(), the C++ hardware emulators might change input ports. A classic example of this would be the serial port simulation line, or even the SD Card emulator. Verilator needs to be told that these values may have changed outside of its view of the world before adjusting things lest the trace ... not make sense. As it is, because these values are shown to be adjusted just before the clock tick, you might argue that the trace doesn't make sense anyway, but this is the best I've been able to do in order to keep things consistent between the emulated and the simulated environments.