FST support for custom types

[albydnc]

I am trying to work on a quite large and complex design (GHW ~ 300 MB). GTKwave is not capable of opening such file, resulting into enormous RAM usage and hanging.
I tried to switch to FST since it should be much better for handling big designs in GTKwave. The issue is that my design has a lot of subtypes, many of which are arrays and they are not exported into the FST format (nor the VCD).
E.g. I have arrays of std_logic_vector which are ignored completely.

Is it possible to export these into FST? Is there a workaround?

[Paebbels]

As I remember, FST (fast) is a format invented by GTKwave as a faster replacement for VCD and compressed VCD. So it's limited to Verilog features. (VCD - Value-Change-Dump is a format defined by Verilog.)

Internally, GTKwave reads all waveform formats for representation. So when GTKwave has problems to handle a 300MB GHW file, I assume it also has problems with a 300 MB FST file. Have you already reported that issue to GTKwave? Tony Bybell can analyze which parts of GTKwave consumes most memory when opening such large files. It might be interesting to describe if your simulation is

• long (less signals, but many data per signal),
• big (many signals, but medium runtime),
• complex (many signals and deep hierarchy as well as complex datatypes (e.g. many enums)

For GHDL and GHW, you can limit the number of signals written into a waveform. See the --read-wave-opt= simulation option. This should enhance simulation speed (less disk I/O) and filesize/complexity (less hierarchy levels).

[tgingold]

If you recompile a very recent ghdl with the mcode backend, the support of FST has been improved. But as mentioned by @Paebbels GTKWave has a limited support for record/arrays.

[albydnc]

@Paebbels I have opened an issue to GTKwave (gtkwave/gtkwave#280).
Apparently GTKwave unpacks and loads every signal from the GHW onto RAM, which is quite expensive on resources. Instead, FST loads it on demand, which results into faster and leaner experience. In my tests, the GHW and the FST are more or less the same size, but FST loads (and fast <1s), but GHW does not and hangs the waveform viewer.
The simulation is 35 million signals and runs for 500 us (fastest clk is 4 ns). Here you can find the ghw file I have generated https://cernbox.cern.ch/s/GBA8otWWO0MgeqR.

Thank you for suggesting the --read-wave-opt=, I will try it 👍

[ekiwi]

@albydnc The surfer waveform viewer has a different GHW implementation than GTKWave and is now able to load your file. You will have to use a local installation though, the web version is significantly slower which makes a difference for large files like yours. Feel free to report any problems you find to the surfer issue tracker. GHW support is very new, so there are definitely still some bugs. One major issue that we are aware of is that enums are currently rendered as numbers instead of their string values. We are working on fixing that.

[ekiwi]

Surfer correctly renders enums now. This is what your file looks like opened in Surfer:

Opening it does take ~10-20s, but memory usage is under control (< 400MB). FST would be much faster to load still, because of the way it stores each signal trace separately.