Verilator - VerilatedVcdC->dump()

Question

我正在阅读一个出色的Verilator 教程，在这些幻灯片 (第25页)中，作者使用了一个库调用：

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

我知道tfp是指向Verilator库对象VerilatedVcdC的指针，因此这个调用实际上是：

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

但这个电话到底是做什么的？头文件/usr/share/verilator/include/verilated_vcd_c.h中的描述有点短。它只说：

/// Write one cycle of dump data

这里有点混乱： 这意味着CPU周期还是操作系统周期？我已经编程地发现这里在我的Linux周期上是10毫秒。我想，从现在起，Verilator作者意味着CPU周期，因为gtkwave最终将显示纳米秒的单位(继续阅读)！

因此，理论上VerilatedVcdC->dump(x)应该在转储文件tfp中写入/转储x CPU周期(整个周期而不是半周期)。

但出于某种原因，作者将这一数字乘以10，减去2。他的评论中写道：

//dump 2ns before the tick

一开始我无法相信这一点，因为当tickcount = 1时，我们得到：

VerilatedVcdC->dump(8);

因此我们应该转储8个CPU周期..。

由于某些原因，我错了，如果我上传gtkwave内部的转储文件并检查波形，这是肯定的。

​

​

实际上，2ns的数据在开始时被转储到转储文件中。这怎麽可能？

难道x在VerilatedVcdC->dump(x)中实际上是操作系统滴答计数器的绝对值而不是相对时间吗？

Answer 1

我也刚开始做校监。我相信x代表了你用verilog创建的电路中的延迟。在一些书中叫做“三角洲”。它不应该与机器上运行的任何数据( specifically.for tickcount = 1 )相关，调用将数据转储为值(1 *10-2)，值为δ= 8。下一个计数是(2 *10-2)，增量= 18，依此类推。下面链接到我正在学习的教程：1/ .in short，tickcount与您的机器无关，它是模拟的‘时间’

Answer 2

在ZipCPU的教程中，我遇到了同样的问题，我花了很长时间才找到一个非常简单的解决方案:关键是VerilatedVcdC->dump()的论点不是“延迟”，而是“时间的一刻”。

换句话说，这是你转储的模拟时间点--在实践中，如果(和本教程一样)你在每个时钟滴答和'eval()‘之后转储，只需将参数递增一个。参见Verilator的第2924期中的解释，正如@71GA在前面的评论中提到的那样。