Verilator - explanation of VerilatedVcdC->dump()

Question

I am reading a wonderful Verilator tutorial and in these slides (page 25) author uses a library call:

tfp->dump(tickcount * 10 - 2);

I know that tfp is a pointer to a Verilator library object VerilatedVcdC and therefore this call is actually:

VerilatedVcdC->dump(tickcount * 10 - 2);

But what does this call actually do? Description in the header file /usr/share/verilator/include/verilated_vcd_c.h is a bit short. It only says this:

/// Write one cycle of dump data

A bit of confusion here:

Does this means CPU cycle or OS cycle? I programatically already found out here that on my Linux Debian OS cycle is 10 ms. I assume from now on that Verilator authors meant CPU cycle because gtkwave in the end will show units of nano seconds (keep reading)!

So VerilatedVcdC->dump(x) should theoretically write/dump x CPU cycles (entire period and not ½ period) of data in the dump file tfp.

But author for some reason multiplies this by 10 and substracts 2. His comment than says:

//dump 2ns before the tick

At first I could not belive this because when tickcount = 1, then we get:

VerilatedVcdC->dump(8);

And therefore we should dump 8 CPU cycles...

For some reason I am wrong and this is confirmed if I upload the dumped file inside the gtkwave and check the wave pattern.

Trully, 2ns of data are dumped at the beginning into the dump file. How is this possible?

---

Is it possible that x in VerilatedVcdC->dump(x) is actually an absolute value of the OS tick counter and not some relative time?

Answer 1

i'm just beginning with verilator also. i believe x represents the delay in your circuit you created with verilog. its called 'delta' in some books. it should not be related to anything running on your machine specifically.for tickcount = 1, the call dumps data at value (1 * 10 - 2) which is delta = 8. the next count is (2 * 10 - 2) which is delta = 18 so on and so forth. here's a link to the tutorial i'm following: https://www.itsembedded.com/dhd/verilator_1/ .in short, tickcount is not related to your machine, its the simulation 'time'

Answer 2

I got tripped at that same point in ZipCPU's tutorial, and it took me a while to figure out a very simple solution: the key is that the argument to VerilatedVcdC->dump() is not a "delay", but "a moment in time".

In other words, it's the simulation time point at which you dump -- in practice, if (as in the tutorial) you dump following every clock tick and 'eval()', just keep incrementing the argument by one. See explanation in Verilator's issue 2924, as mentioned by @71GA in an earlier comment.