Menu
▾
▴
#733 VCD or $monitor() can contain changes from unchanged values
Here is a snapshot of a VCD file created by Icarus version 0.91:
-----------------------------------
#50
b1111111110001011 *
...
#55
0G
#60
...
b1111111110001011 *
...
-----------------------------------
The value of '*' is the same for times #50 and #60 and there is no change in between. According to the Verilog 2001 standard, only changed values shall appear in the VCD file. Quote: "Only the variables which change value during a time increment are listed."
I think this is a bug, isn't it?
It certainly looks like a bug, but we need an example that generates this to debug with. Icarus has a few known bugs that could generate this kind of output. Once we have an example we can see if this is an already known problem or something new.
I'm marking this pending until we get an example that demonstrates the problem. Once we have an example this will likely be reassigned to development or another bug report depending on the testing outcome. Any fix from development will be back ported to V0.9 if possible.
testcase to reproduce the issue
I uploaded the testcase now. The times seem to have changed slightly (could be that I modified the testcase a little bit in the meantime), but the signal is still named '*'. Note that the code is automatically generated and not handwritten.
The Icarus version I use is:
Icarus Verilog version 0.9.devel (s20081118)
I tracked this down and I think Icarus is working correctly and your design has a race that is creating the duplicate values.
The issue is that you are driving the Mux0_of_Reg_1 and Mux0_of_Reg_2 multiplexers with values that change exactly at the time that the select changes. This creates a zero width glitch since the select and the inputs do not swap at exactly the same instance in time. This creates a value change update callback, but by the time it executes the value has stabilized to the original value hence the same value is dumped twice. Remember Verilog uses delta cycles to solve the system. This issue will become more obvious as the circuit is synthesized where real delays will create visible glitches.
I'm not going to close this yet because I want to verify that this is not a defect in our implementation of the cbValueChange callback or if this something that we need to handle special in the dumper routines.
This must have been causing you problems since I'm surprised you would notice this. GTkWave accepts and ignores the duplicate values. Have you tested this on other tools to see what they do?
As far as the standard is concerned I could argue that the value changed twice during the time increment once to a new value and then again back to the original value.
We will discuss all this on the iverilog-devel list if you want to see or contribute to the discussion.
Maybe it is a matter of what you define to be a change. The quote from my initial bug entry is the only statement in the standard I could find about this.
I noticed that, because I implemented my own VCD parser. Please don't put too much effort into this bug, because it is easy to work around (simply filtering out duplicates). The duplicate values just came unexpected to me and so I thought it might be worth a bug entry.
For now I'm dropping this from my list of assigned reports. We will try to look at this eventually, but what free time I do have lately needs to go to higher priority tasks.
I was thinking about this a bit today and thought that $monitor like the dumpers could also have this same issue. I coded a simple example to test this and yes it does have the same issue. I also currently have access to a commercial simulator and it did not run the $monitor when I was not expecting it to. I am attaching the code here, raising the priority and changing the summary.
$monitor() example file