there is a time 26 with a rising clock edge which the default vcdcat case is missing.
It appears that the delta option uses PrintDeltasStreamParserCallbacks and therefore the value callback method, which works as expected. However, the default case uses PrintDumpsStreamParserCallbacks and the time callback method. Since this callback happens before any of the values for the new time period are processed it is only able to handle values from the previous time period. Since there are no more time periods in the file the time callback isn't able to print the final value.
One option would be to just switch PrintDumpsStreamParserCallbacks to use the value callback. However, using time in this way seems more generally useful. Rather than drastically change the behaviour of the time callback perhaps an endfile callback or similar would make sense? For PrintDumpsStreamParserCallbacks and similar code the endfile callback could just call the same code as the time callback, catching the final time period. There may also be other cases where a final processing step at the end of the file would be useful.
Thoughts? I have a quick implementation of endfile I can submit if that's the way you'd like to go.
The default case of
./vcdcat counter_tb.vcd
produces the following:However,
./vcdcat -d counter_tb.vcd
producesFrom the end of the VCD file:
there is a time 26 with a rising clock edge which the default
vcdcat
case is missing.It appears that the delta option uses
PrintDeltasStreamParserCallbacks
and therefore thevalue
callback method, which works as expected. However, the default case usesPrintDumpsStreamParserCallbacks
and thetime
callback method. Since this callback happens before any of the values for the new time period are processed it is only able to handle values from the previous time period. Since there are no more time periods in the file the time callback isn't able to print the final value.One option would be to just switch
PrintDumpsStreamParserCallbacks
to use thevalue
callback. However, usingtime
in this way seems more generally useful. Rather than drastically change the behaviour of thetime
callback perhaps anendfile
callback or similar would make sense? ForPrintDumpsStreamParserCallbacks
and similar code theendfile
callback could just call the same code as thetime
callback, catching the final time period. There may also be other cases where a final processing step at the end of the file would be useful.Thoughts? I have a quick implementation of
endfile
I can submit if that's the way you'd like to go.