Missing complex signal in waveform

[Schottkyc137]

Signals that are arrays of records seem to be missing in generated waveforms. For the following example:

entity mre_complex_types is
end entity mre_complex_types;

architecture arch of mre_complex_types is
    type IQ is record
      I: bit_vector(15 downto 0);
      Q: bit_vector(15 downto 0);
    end record;

    type iq_array is array (1 downto 0) of IQ;

    signal foo : iq_array;
    signal bar: bit;
begin

  foo <= ((X"0000", X"0001"), (X"0002", X"0003"));
end architecture arch;

when invoking the command

nvc -a mre_complex_types.vhd -e mre_complex_types -r --wave --format vcd

the resulting vcd file does not contain the signal foo, only bar:

$date
    Thu Aug 29 10:04:04 2024

$end
$version
    nvc 1.14-devel
$end
$timescale
    1fs
$end
$attrbegin misc 03 /home/lukas/mre_complex_types.vhd 1 $end
$attrbegin misc 04 1 4 $end
$scope vhdl_architecture mre_complex_types $end
$attrbegin misc 02 BIT 1026 $end
$var logic 1 ! bar $end
$upscope $end
$enddefinitions $end
#0
$dumpvars
0!

Moreover, when one removes the bar signal, the following output is observed:

** Note: writing VCD waveform data to mre_complex_types.vcd
** Fatal: 0ms+1: fstReaderOpen failed for temporary FST file

and the generated vcd file is empty. Having no signals at all causes the same behavior.

Version: nvc 1.14-devel (1.13.0.r100.ge821b31a) (Using LLVM 14.0.0) OS: Linux 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC x86_64 x86_64 x86_64 GNU/Linux

[nickg]

You need to add --dump-arrays to include arrays of composite types.

[Schottkyc137]

I see, thanks a lot for the swift response. May I ask why this is not the default behavior?

[nickg]

It's to avoid accidentally generating excessively large dump files when you have e.g. large memories in the design. Arguably there should be a size cut-off rather than defaulting to off.

[Schottkyc137]

Is the dump-arrays option not supported to fst dumps?

[nickg]

It works for both. Actually the VCD dumper is just the FST dumper with an extra step where it converts it to VCD (should be equivalent to running fst2vcd).

If you leave this open I'll try to fix the fatal error when there are no signals. I've noticed before that GtkWave's FST library doesn't handle empty files properly so the fix should probably go there.

[Schottkyc137]

Maybe I found a different issue (potentially also related to gtkwave). For the following example:

entity mre_complex_types is
end entity mre_complex_types;

architecture arch of mre_complex_types is
    type iq_array is array (1 downto 0) of bit_vector(15 downto 0);

    signal foo : iq_array;
begin

  foo <= (X"0000", X"0001");
end architecture arch;

gtkwave produces the following output: i.e., no signals are shown. The signals are correctly dumped, i.e., I can see them in the vcd dump and I can add them to the wave window. Is this also expected?

[nickg]

I'd guess that's a GtkWave issue related to the file having no time steps. Is there a reason you're using VCD rather than FST? FST has much better performance and compression, and is supported natively by GtkWave. VCD is only really useful for compatibility with tools that don't support FST.

[Schottkyc137]

The issue persists with something like

entity mre_complex_types is
end entity mre_complex_types;

architecture arch of mre_complex_types is
    type iq_array is array (1 downto 0) of bit_vector(15 downto 0);

    signal foo : iq_array;
begin

  process is
  begin
      foo <= (X"0000", X"0001");
      wait for 2 ns;
      foo <= (X"0002", X"0003");
      wait;
  end process;
end architecture arch;

which should have a timestamp, right? I'm just using VCD to see whether the signal is actually dumped to the file; normally I'd use fst.

[nickg]

This seems like a GtkWave display issue. I tried your example above with VCD output and there is a transition on the far right side of the waveform but it's a bit difficult to see:

[egorxe]

Maybe it is possible to add an optional limit argument for --dump-arrays? In a lot of cases it is convenient to dump small arrays (like array of records in the first post of this issue) but not huge ones representing memories. So something like --dump-arrays=10 which will dump arrays up to 10 elements long will be very useful in my opinion.

[nickg]

Maybe it is possible to add an optional limit argument for --dump-arrays?

Yes this sounds reasonable and I've implemented it, along with a hint message if any signals are not dumped because --dump-arrays was not passed, which should help with the original issue.