FST dumping - Improvements

[Blebowski]

Hi,

I have few remarks for improvements of waveform dumping, IMHO it would be good to include following:

1. Option to enable/disable dumping of internal signals (not only all signals)
2. Option to enable/disable dumping of instance ports
3. Add dumping of variables within processes and shared variables, option to enable/disable such dump.
4. Add dumping of constants, option to enable/disable such dump.

Would it be feasible only in NVC, or does it require extensions of FST API (and therefore GTKWave modifications)?

[nickg]

The first two should be possible. But I don't think FST or GtkWave has any concept of variables. I'm also not sure when you would dump them: at the end of each time step? There also isn't a notion of 'EVENT for variables so it's not obvious when a value change should be emitted.

[Blebowski]

Well there are two options I think:

• At the end of each non-delta cycle
• Each time when variable is assigned (which can be multiple times during single simulation time).

AFAIK, GTKWave does not support viewing / expanding delta-cycles on dumped objects, which would be also nice feature, but it would require changes in GTKWave, as well as dumping also information about delta-cycle. This is usefull when debugging heavily clock gated designs which can have lot of delta-cycle "ghost" issues...

I think each time when variable is assigned would be best. Constants obviously would need to be dumped only during initial assignment.

[nickg]

AFAIK, GTKWave does not support viewing / expanding delta-cycles on dumped objects, which would be also nice feature, but it would require changes in GTKWave, as well as dumping also information about delta-cycle.

I also think this would be a useful feature, and the implementation on the NVC side would be trivial - just need to change the callback from postponed to non-postponed and emit the delta cycle number somewhere. But I don't know how much effort it will be on the FST/GtkWave side.

I think each time when variable is assigned would be best. Constants obviously would need to be dumped only during initial assignment.

The overhead of dumping variables on every assignment would be extreme - not just because of the data generated (e.g. in loops) but to dump the new value would require a runtime call after every assignment which will basically inhibit almost all optimisations LLVM does now. Dumping all the variables on the last delta cycle is probably ok (although still need to be careful e.g. with large arrays).

I actually think this sort of thing would be better in some interactive debug environment where you could pause the simulation, inspect variable values, single step, etc.

[Blebowski]

OK, I see, then dumping at the end of non-delta cycle seems more reasonable.

As for the GTKWave, I don't know. I have looked into it long time ago, and I don't really remember nearly anything from it. AFAIK, the focus now is on migrating towards GTK4 (or not?).

As for the debug environment, I would like to see something like that but I think the effort to implement something like this will be extreme. Its a question whether to start from GTKWave, or a new waveform viewer. There is a good discussion which explains "why writing waveform viewer is difficult" at: https://github.com/gtkwave/gtkwave/issues/140

That being said, I would really like to have OS SW which has analog/digital waveform capability, tight coupling with simulator and features such as: hierarchy browse, UVM / OSVVM object browser, coverage viewer / analyzer, cover points in waves, x tracing, interactive schematic viewer and good performance, but I don't think it will happen anytime soon.

Maybe a good starter would be actually modifying GTKWave FST loading, to allow loading incremental loading of FST files, and adding a simple "GUI" control to stop/run simulation.

As for the waveforms dumping in NVC, I came accross next thing which might be good to add:

** Warning: cannot represent multidimensional arrays in FST format
    > ../tb/tb_top.vhd:95
    |
 95 |     signal nested_arr      :   t_tensor(2 downto 0, 2 downto 0, 2 downto 0);
    |            ^^^^^^^^^^
** Note: 0ms+0: Report Note: G is 0001