Issues with dump files containing integer types #431

rfuest · 2025-04-30T20:01:01Z

I've found another rabbit hole, this time it's integer types. Here are some issues I've noticed so far:

The VCD loader handles SV integer types, e.g. shortint, like vectors and not like the regular integer, which the FST loader does. This means that it adds [15:0] to the name. The FST loader works correctly.
Both loaders strip off index ranges, like [31:0], from integer variables, which makes sense because tools like iverilog add them, which the probably shouldn't according to an example in the VCD specs. But any index range is removed without further checks, which means that technically invalid declarations like $var integer 64 ! int $end or $var integer 64 ! int[63:0] $end work as 64 bit integers, but there is no indication in the UI that this isn't a regular 32 bit integer. I think it would be a reasonable approach to only strip valid index ranges, e.g. [31:0] for integer or [15:0] for shortint, and add or preserve the index ranges for all other integer variables.
The VCD loader also strips bit indices, which can lead to name clashes. $var integer 32 a int[0] $end and $var integer 32 b int[1] $end are both shortened to int and only the first variable is visible in the SST without any warnings or errors. The FST loader does seem to handle this correctly and treats the indices as part of the name.

The text was updated successfully, but these errors were encountered:

tbybell · 2025-05-01T21:34:00Z

I'll have to experiment with these. To get arrays of integers, I need to bounce through FSDB first because VCS skips dumping them. From fsdbdebug, the FSDB file doesn't leave anything to chance in the signal name for arrays of integers (k) and fully specifies everything.

Scope: vcd_module top top Has_mem_var 
Var: vcd_reg top.clk l:0 r:0 implicit 1 1B 0
Var: vcd_reg top.i[15:0] l:15 r:0 implicit 2 1B 0
	 Array Begin
	 Array Name: k[10:0]
	 Array Size: 11
Var: vcd_integer top.k[10][31:0] l:31 r:0 implicit 3 1B 0
Var: vcd_integer top.k[9][31:0] l:31 r:0 implicit 4 1B 0
Var: vcd_integer top.k[8][31:0] l:31 r:0 implicit 5 1B 0
Var: vcd_integer top.k[7][31:0] l:31 r:0 implicit 6 1B 0
Var: vcd_integer top.k[6][31:0] l:31 r:0 implicit 7 1B 0
Var: vcd_integer top.k[5][31:0] l:31 r:0 implicit 8 1B 0
Var: vcd_integer top.k[4][31:0] l:31 r:0 implicit 9 1B 0
Var: vcd_integer top.k[3][31:0] l:31 r:0 implicit 10 1B 0
Var: vcd_integer top.k[2][31:0] l:31 r:0 implicit 11 1B 0
Var: vcd_integer top.k[1][31:0] l:31 r:0 implicit 12 1B 0
Var: vcd_integer top.k[0][31:0] l:31 r:0 implicit 13 1B 0
	 Array End
Upscope:

It indirectly sidestepped shortint though by making it a reg:
Var: vcd_reg top.i[15:0] l:15 r:0 implicit 2 1B 0

From a practical point of view, we should see well-behaved signal declarations. For the name clashes with your example using int, I didn't see that in 3.3.122 or what's in revision control and will be 3.3.123. The example above I have, even with the [31:0] stripped out appears fine EXCEPT if I expand the signal, the higher order dimension (10..0) is missing in the expanded signal name.

I'll mess with these. I've never deliberately tried to break the loaders because in the past, it's often been the case where a simulator developer would have gone back and forth with me interatively on how the $var declarations should be named--especially when the Verilog spec turned out not to define something at all.

tbybell · 2025-05-01T23:10:46Z

From a practical point of view, we should see well-behaved signal declarations. For the name clashes with your example using int, I didn't see that in 3.3.122 or what's in revision control and will be 3.3.123. The example above I have, even with the [31:0] stripped out appears fine EXCEPT if I expand the signal, the higher order dimension (10..0) is missing in the expanded signal name.

92a0efa..8bb04d3 lts -> lts

tbybell · 2025-05-02T15:29:01Z

For the integers that aren't declared as 32b, I think the reason that non-32b sizes are accepted by the VCD loader is staring me in the face from that old set of VCD waves. These aren't integers, but parameters effectively are constant integers. I don't know if simulators still do this leftmost 1 bit optimization for length when writing out VCD. I don't recall seeing anything like this in recent memory but I haven't paid attention, either.

I didn't expect there would be the unearthing of a time capsule this year. :-)


$date
     	Mon Jul 26 12:19:13 1999
$end
$version
        ModelSim Version 5.2a
$end
$timescale
	10fs
$end
$scope module ks1 $end
$scope module genrx $end
$var parameter 20 ! tx_link_burst_max $end
$var parameter 20 " tx_interval_max $end
$var parameter 3 # ack_cnt_max $end
$var parameter 5 $ tx_bit_cnt_done $end
$var parameter 32 % auton_link_pulse_width $end
$var parameter 5 & rx_flp_cnt_done $end
$var parameter 5 ' rx_bit_cnt_chk $end
$var parameter 9 ( rx_flp_min_max $end
$var parameter 11 ) rx_flp_max_max $end
$var parameter 17 * rx_nlp_min_max $end
$var parameter 21 + rx_nlp_max_max $end
$var parameter 9 , rx_data_detect_min_max $end
$var parameter 10 - rx_data_detect_max_max $end
$var parameter 32 . lp_min_w $end
$var parameter 25 / brk_link_max $end
$var parameter 24 0 auton_wait_max $end
$var parameter 24 1 link_fail_inh_max $end
$var parameter 32 2 ack $end
$var parameter 17 3 nlpt_min_max $end
$var parameter 21 4 nlpt_max_max $end
$var parameter 4 5 nlpt_link_count_max $end
$var parameter 21 6 nlpt_link_loss_max $end
$var parameter 32 7 normal_lp_sep $end
$var parameter 32 8 o_delay $end
$var reg 1 9 rxn $end

rfuest · 2025-05-02T15:53:10Z

For the name clashes with your example using int, I didn't see that in 3.3.122 or what's in revision control and will be 3.3.123.

Sorry, I thought that I checked this in the latest LTS revision, but apparently I only checked it with the latest release in my distro, which is 3.3.121. I can confirm that it works in the latest LTS commit.

It indirectly sidestepped shortint though by making it a reg:
Var: vcd_reg top.i[15:0] l:15 r:0 implicit 2 1B 0

iverilog does the same. Do you remember if you added support for these types with a specific tool in mind back in 2013? (https://github.com/rfuest/gtkwave-archive/commits/main/?before=bbbadd275880b2466415ca972ab8fb0fb8b92012+876) If no tool uses these types anyway I would like to remove them and print a warning to the user instead. The loaders would then treat them as a regular wire or reg and both loaders should handle them the same.

rfuest · 2025-05-02T16:08:02Z

For the integers that aren't declared as 32b, I think the reason that non-32b sizes are accepted by the VCD loader is staring me in the face from that old set of VCD waves. These aren't integers, but parameters effectively are constant integers. I don't know if simulators still do this leftmost 1 bit optimization for length when writing out VCD. I don't recall seeing anything like this in recent memory but I haven't paid attention, either.

I didn't expect there would be the unearthing of a time capsule this year. :-)

Thanks for digging that out, that's really interesting. Based on this info I think I'll handle integer types in GTKWave 4 like this:

$var integer 32 a int $end, $var integer 32 a int[31:0] $end
shown as int in the SST
$var integer WIDTH a int $end, $var integer WIDTH a int[WIDTH - 1:0] $end with WIDTH < 32
also shown as int in the SST based on the assumption that this was used by the VCD writer to save memory
$var integer WIDTH a int $end, $var integer WIDTH a int[WIDTH - 1:0] $end with WIDTH > 32
shown as int[WIDTH - 1:0] in the SST to indicate that this is not a regular integer
for all other invalid indices use the same logic as for a vector

tbybell · 2025-05-02T16:18:45Z

iverilog does the same. Do you remember if you added support for these types with a specific tool in mind back in 2013? (https://github.com/rfuest/gtkwave-archive/commits/main/?before=bbbadd275880b2466415ca972ab8fb0fb8b92012+876) If no tool uses these types anyway I would like to remove them and print a warning to the user instead. The loaders would then treat them as a regular wire or reg and both loaders should handle them the same.

I added SV datatypes to FST as I expected simulators would eventually add them, so I wanted to get ahead of any spec updates. They were added to VCD mainly so vcd2fst/fst2vcd were somewhat symmetrical in capabilities.

That said, I added them speculatively to the VCD loaders in case the VCD section of the 1800 spec was updated, but it doesn't look like it ever was (looking at the 2017 version) or ever will be. I doubt they'll ever be a part of the spec if they aren't already. Ironically, there are pretty much useless net types in a modern production context such as tri0, etc. in the list of supported types in the spec.

Based on this info I think I'll handle integer types in GTKWave 4 like this:

That sounds very good to me.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Issues with dump files containing integer types #431

Issues with dump files containing integer types #431

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Issues with dump files containing integer types #431

Issues with dump files containing integer types #431

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!