Debian Question posted in
The oficial documentation can be found here.

Verilator – explanation of VerilatedVcdC->dump() – Debian

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.

enter image description here

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?

Tags:

2

Answers


  1. 0

    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’

    Login or Signup to reply.
  2. 0

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search