Final newline at end of .vcd output is missing

[josyb]

Impulse in Eclipse throws an exception for the missing newline at the end of the .vcd output
It is benign and not blocking, but 'ein bisschen unschön'

• OS: Windows 11
• Origin: Nightly build

Perhaps I should file the bug at toem.de but I feel that a final newline is warranted.

[tgingold]

I have just checked a vcd file generated by ghdl and there is a newline at the end.
Does it requires a second newline ?

Can you file a bad and a correct vcd file ?

[josyb]

The end of a large .vcd

But this time Impulse doesn't complain ...
I shortened the run-time by placing a finish early and then I get what looks like an uncomplete .vcd file
If a move the finish I get a file with a final newline
and I f I move the finish elsewhere I get a good file without a final newline
So 3 endings.
vcd.zip

[tgingold]

Interesting.
Do you have an example of how to generate a vcd without final newline ?
I don't see how this is achieved according to the code.

[josyb]

Not really, I encountered the issue when simulating a large project. I am not at liberty to share it.
I will use GHDL more in my future personal/open source work, I guess. If I encounter the same problem I will re-raise this issue.

[tgingold]

How does the large simulation finish ? Do you interrupt it, do you use env.stop ?

[josyb]

use std.env.finish;

[josyb]

I stumbled onto another problem: GHDL doesn't export array in .vcd

$comment crcdata is not handled $end
$comment crc_crcout is not handled $end

Although that is easily accomplished by e.g.:

$scope module crcout $end
$var reg 10 F crcout(0) $end
$var reg 10 G crcout(1) $end
$var reg 10 H crcout(2) $end
$var reg 10 I crcout(3) $end
$upscope $end

So I gave GHW another try and managed to get GTKWave to load the file: and I do see the array
But GTKwave doesn't show state machine signals (enumerations) !

Here is the file: tb_iliye.sim.ghw.zip
GHDL info:
GHDL 4.0.0-dev (3.0.0.r441.g5da5750cd) [Dunoon edition]
Compiled with GNAT Version: 13.2.0
mcode code generator

I did some checking with ghwdump, and yes the enumeration types are there:

type t_enum_pythonremapwriter_states_5 is (idle, flsid, img0, img1, img, fleid, lcrc, check_crc, wls);

So I guess I have to complain to GTKWave?

[tgingold]

Yes, ghdl only outputs the signals compatible with vcd and doesn't try to decompose them. It's on my todo list. Enumerated types should work with gtkwave. Are you sure you have selected them ?

[josyb]

Enumerated types should work with gtkwave. Are you sure you have
selected them ?

I had no idea I would have to enable them for GHW ouput?

[diogratia]

Enumerated types should work with gtkwave. Are you sure you have
selected them ?

Selected for display in the GTKWave Waves window.

And yes [tb_iliye.sim.ghw contains signals of enumerated types whose values are shown an various times besides signals who elements are BIT or STD_ULOGIC/STD_LOGIC. Using ghwdump you can see all this.

With the example from your previous issue:

%: ghwdump -tHs foo.ghw
type some_enum is (a, b, c, d, e, f, g);
design
package /standard:
package /std_logic_1164:
instance /foo:
signal /foo/state: some_enum: #1
process /foo/P0:
Time is 0 fs
#1: a (0)
Time is 0 fs
#1: a (0)
Time is 10000000 fs
#1: b (1)
Time is 20000000 fs
#1: c (2)
Time is 30000000 fs
#1: d (3)
Time is 40000000 fs
#1: e (4)
Time is 50000000 fs
#1: f (5)
Time is 60000000 fs
#1: g (6)
Time is 70000000 fs
#1: g (6)
Time is 80000000 fs
#1: g (6)
%:

On your dump file

%: ghwdump -tHs tb_il*.ghw > ghwdump_-tHs.txt
^C
%:

(Quit traversing your 171 MB dump file with CTRL C, I quit over 1GB of output to ghwdump_-tHs.txt, I trimmed it down to 10,000 lines.)

%: more ghwdump
ghwdump_-tH.txt  ghwdump_tHs.txt
%: more ghwdump_tHs.txt
type std_ulogic is ('U', 'X', '0', '1', 'Z', 'W', 'L', 'H', '-');  -- WKT:3
subtype std_logic is std_ulogic range 'U' to '-';
type integer is range <>;
subtype natural is integer range 0 to 2147483647;
type std_ulogic_vector is array (natural range <>) of std_ulogic;
subtype std_logic_vector is std_ulogic_vector;
type array_of_slv is array (natural range <>) of std_logic_vector;
type array_of_array_of_slv is array (natural range <>) of array_of_slv;
type array_of_array_of_array_of_slv is array (natural range <>) of array_of_array_of_slv;
type mpython1300_states is (idle, do_fot, do_rot, begin_line, begin_id, repeat1_line, repeat2_line, end_line, end_id, crc);
type unresolved_unsigned is array (natural range <>) of std_ulogic;
type t_enum_bridgemodule_states_1 is (idle, writing, reading, reading2);
subtype unsigned is unresolved_unsigned;
type array_of_unsigned is array (natural range <>) of unsigned;
type array_of_std_logic is array (natural range <>) of std_logic;
type boolean is (false, true);  -- WKT:1
subtype integer is integer range -2147483648 to 2147483647;
type sensordeser_states is (sd_idle, sd_aligning, sd_aligned);
type cdcp_states is (idle, requested, preidle);
type p1300s_states is (idle, do_fot, do_rot, begin_line, begin_id, repeat1_line, repeat2_line, end_line, end_id, crc);
type t_enum_mmread_states_1 is (idle, rd1);
type t_enum_spi_states_3 is (idle, sync, transfer_header, pause, extraclocks, transfer_data, ending, preidle);
type t_enum_clkdivider_states_2 is (low, high);
type t_enum_pythonremapwriter_states_5 is (idle, flsid, img0, img1, img, fleid, lcrc, check_crc, wls);
type t_enum_pythonremapreader_states_8 is (idle, transfer);
type t_enum_cdcp_states_4 is (idle, tfr, busy);
type t_enum_framedpixelpackntom_states_6 is (fill, pack_last);
type t_enum_framedpixelpackntom_states_7 is (fill, pack_first, pack_middle, pack_last);
type t_enum_cdcp_states_9 is (idle, tfr, busy);
type t_enum_roihorizontal_states_10 is (idle, hunt, transfer, terminate);
type t_enum_ple_state_11 is (ple_free, ple_taken);
type t_enum_ple_state_12 is (ple_free, ple_taken);
type t_enum_ple_state_13 is (ple_free, ple_taken);

You can see your dump file traces of signals of enumerated types:

%: grep ple_state ghwdump_tHs.txt
type t_enum_ple_state_11 is (ple_free, ple_taken);
type t_enum_ple_state_12 is (ple_free, ple_taken);
type t_enum_ple_state_13 is (ple_free, ple_taken);
type t_enum_ple_state_14 is (ple_free, ple_taken);
signal /tb_iliye/dut/frontend/ti_pl_ple0_smn: t_enum_ple_state_11: #9553
signal /tb_iliye/dut/frontend/ti_pl_ple0_smp: t_enum_ple_state_11: #9554
signal /tb_iliye/dut/frontend/ti_pl_ple1_smn: t_enum_ple_state_12: #9645
signal /tb_iliye/dut/frontend/ti_pl_ple1_smp: t_enum_ple_state_12: #9646
signal /tb_iliye/dut/frontend/ti_pl_ple2_smn: t_enum_ple_state_13: #9693
signal /tb_iliye/dut/frontend/ti_pl_ple2_smp: t_enum_ple_state_13: #9694
signal /tb_iliye/dut/frontend/ti_plo_ple0_smn: t_enum_ple_state_14: #9695
signal /tb_iliye/dut/frontend/ti_plo_ple0_smp: t_enum_ple_state_14: #9696
%: 

And no signal changes for signal #9553 in the first 10,000 lines of the GHW dump. I'd suggest learning your way around a GHW dump with ghwdump with a smaller design or shorter simulation interval.

Note the foo.ghw dump from the small example in your previous issue has one signal states (#1) and shows 6 updates plus the original value.

AND opening your 171 MB GHW dump we can find signal #9553:

(The last signal trace at the bottom of the Waves Pane, I had to search for it by hierarchy. Toggling trace hierarchy in the Waves Pane is done with Toggle Trace Hier in Edit in the top level GTKWave menu.)

This was done with GTKWave 3.3.107, the latest pre-built available for MacOS. I can't speak to 3.4 which is presumably under GTK4.

I'd say it's either the GTKWave you're using or to quote Steve Jobs "You're holding it wrong." Not accusatory, I had a hard time finding signal #955 particularly lacking signal and type declarations or the design hierarchy other than the GHW dump file. I had to 'practice' ghwdump until I understood what I was seeing.

Selecting frontend in the hierarchy in the SST pane the signals declared at the hierarchy level show up in the Signals pane. The one shown was appended and showed up in the Waves Pane.

I also set the Max Trace Hier to 0 which would presumably show the entire hierarchy in the path names in the Waves Pane. I think the default wast 4 and I didn't want to get bit.

(And ya, I know you previously decried the GTKWave User Interface.)

[josyb]

Dear Dio,

I could have mentioned that all my state machine enumeration signals have sm in their name.
This early mornings I managed to find them :)
Don't understand how I missed them at first - but as you say GTKWave is not my thing (decry is a bit strong?) - Impulse in Eclipse is far nicer - but that doesn't talk .ghw
And please don't quote Steve Jobs - he tried to talk around a design error .... His final words on that death-grip were "Relax ... it is only a phone" -> http://www.edibleapple.com/2010/07/01/steve-jobs-relax-it-is-just-a-phone-not-worth-it/