Discussion:
[Ghdl-discuss] Improved '.fst' file format for VHDL
Stefan Dröge
2016-04-23 22:12:58 UTC
Permalink
Some changes/additions were recently made to gtkwave's .fst file
format, which can now also support 9 value logic, and special VHDL
types like records, etc. (see gtkwave manual page 21).

Since the .fst file format shows better performance for larger
waveform dumps, it would be very useful if these changes could be
included in GHDL. For the implementation it might be interesting to
have a look at https://github.com/nickg/nvc/blob/master/thirdparty/fstapi.c
(I could not find any information on the fst format directly from the
gtkwave website, besides the user manual)

Lastly, since I am new to the mailing list, let me say a big "thank
you!" to the Tristan and the other contributers. I am using ghdl
extensively for my master thesis project. I am writing a GPS receiver
in VHDL, including a MBlite Softcore CPU (a microblaze variant), and I
am doing my simulations exclusively in GHDL. I especially like the
performance of ghdl and that it is very pedantic about the LRM. My
life would be several orders of magnitudes harder without GHDL.
Lehmann, Patrick
2016-04-23 23:10:31 UTC
Permalink
_______________________________________________
Ghdl-discuss mailing list
Ghdl-***@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
Stefan Dröge
2016-04-24 02:40:31 UTC
Permalink
Yes, I know of the .ghw format. (That is what I am using at the moment).
However, for large waveform dumps, the .ghw format is terribly slow to
the point were it is unusable.
Hello Stefan,
if you need more features in the exported waveform database files, there is
also the *.ghw (GHDL wave) format, which is also supported by GTKWave.
ghdl -r ..... --wave=waveform.ghw
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351
463-38324
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Stefan Dröge
Datum:24.04.2016 00:15 (GMT+01:00)
Betreff: [Ghdl-discuss] Improved '.fst' file format for VHDL
Some changes/additions were recently made to gtkwave's .fst file
format, which can now also support 9 value logic, and special VHDL
types like records, etc. (see gtkwave manual page 21).
Since the .fst file format shows better performance for larger
waveform dumps, it would be very useful if these changes could be
included in GHDL. For the implementation it might be interesting to
have a look at https://github.com/nickg/nvc/blob/master/thirdparty/fstapi.c
(I could not find any information on the fst format directly from the
gtkwave website, besides the user manual)
Lastly, since I am new to the mailing list, let me say a big "thank
you!" to the Tristan and the other contributers. I am using ghdl
extensively for my master thesis project. I am writing a GPS receiver
in VHDL, including a MBlite Softcore CPU (a microblaze variant), and I
am doing my simulations exclusively in GHDL. I especially like the
performance of ghdl and that it is very pedantic about the LRM. My
life would be several orders of magnitudes harder without GHDL.
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
Rene Doss
2016-04-24 06:14:03 UTC
Permalink
Also gtkwave crashed at lager GHW waveforms. If I restart gtkwave than
works correctly with the same GHW datafile.

Rene
Post by Stefan Dröge
Yes, I know of the .ghw format. (That is what I am using at the moment).
However, for large waveform dumps, the .ghw format is terribly slow to
the point were it is unusable.
Hello Stefan,
if you need more features in the exported waveform database files, there is
also the *.ghw (GHDL wave) format, which is also supported by GTKWave.
ghdl -r ..... --wave=waveform.ghw
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351
463-38324
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Stefan Dröge
Datum:24.04.2016 00:15 (GMT+01:00)
Betreff: [Ghdl-discuss] Improved '.fst' file format for VHDL
Some changes/additions were recently made to gtkwave's .fst file
format, which can now also support 9 value logic, and special VHDL
types like records, etc. (see gtkwave manual page 21).
Since the .fst file format shows better performance for larger
waveform dumps, it would be very useful if these changes could be
included in GHDL. For the implementation it might be interesting to
have a look at https://github.com/nickg/nvc/blob/master/thirdparty/fstapi.c
(I could not find any information on the fst format directly from the
gtkwave website, besides the user manual)
Lastly, since I am new to the mailing list, let me say a big "thank
you!" to the Tristan and the other contributers. I am using ghdl
extensively for my master thesis project. I am writing a GPS receiver
in VHDL, including a MBlite Softcore CPU (a microblaze variant), and I
am doing my simulations exclusively in GHDL. I especially like the
performance of ghdl and that it is very pedantic about the LRM. My
life would be several orders of magnitudes harder without GHDL.
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
Lehmann, Patrick
2016-04-24 12:27:13 UTC
Permalink
_______________________________________________
Ghdl-discuss mailing list
Ghdl-***@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
Stefan Dröge
2016-04-25 16:32:42 UTC
Permalink
You mean the .ghw file that I have trouble with? You can download it
here: https://goo.gl/DjJceY
I guess gtkwave tries to load it entirely into the RAM, and since the
file is enormous, unzipped its 6GB, gtkwave will crash eventually.
afaik gtkwave can access other formats like .fst or .lxt2 more
efficient, without loading the complete file to RAM.

I know it is not ideal to do dump all the signals. But afaik ghdl does
not have an option to select the signal.
What I did as a temporary workaround is, that I just write the data
that I need to a file, with plain VHDL commands, and analyze it in
matlab. But as a long term solution it would be really good if ghdl
could output files in .fst format.

Other advantages of .fst format are, that it can display the type and
direction of the signals in gtkwave a bit nicer.

I actually looked at the code in grt-fst.adb, and I think I could even
write a patch. However probably not before June, as I will be busy
writing my thesis until then. Maybe earlier if I feel the sudden need
for some procrastination, hehe ;) But I will look into it.
Hello Stefan,
can you give an example of such a file?
Is it slow because of the signal count or because of the runtime / event
count.
Currently GHDL dumps every signal. Maybe it's possible to reduce the signal
count by specifing the signals for dumping in the future. Could this help?
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351
463-38324
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Stefan Dröge
Datum:24.04.2016 04:43 (GMT+01:00)
An: GHDL discuss list
Betreff: Re: [Ghdl-discuss] Improved '.fst' file format for VHDL
Yes, I know of the .ghw format. (That is what I am using at the moment).
However, for large waveform dumps, the .ghw format is terribly slow to
the point were it is unusable.
Hello Stefan,
if you need more features in the exported waveform database files, there
is
also the *.ghw (GHDL wave) format, which is also supported by GTKWave.
ghdl -r ..... --wave=waveform.ghw
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49
351
463-38324
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Stefan Dröge
Datum:24.04.2016 00:15 (GMT+01:00)
Betreff: [Ghdl-discuss] Improved '.fst' file format for VHDL
Some changes/additions were recently made to gtkwave's .fst file
format, which can now also support 9 value logic, and special VHDL
types like records, etc. (see gtkwave manual page 21).
Since the .fst file format shows better performance for larger
waveform dumps, it would be very useful if these changes could be
included in GHDL. For the implementation it might be interesting to
have a look at
https://github.com/nickg/nvc/blob/master/thirdparty/fstapi.c
(I could not find any information on the fst format directly from the
gtkwave website, besides the user manual)
Lastly, since I am new to the mailing list, let me say a big "thank
you!" to the Tristan and the other contributers. I am using ghdl
extensively for my master thesis project. I am writing a GPS receiver
in VHDL, including a MBlite Softcore CPU (a microblaze variant), and I
am doing my simulations exclusively in GHDL. I especially like the
performance of ghdl and that it is very pedantic about the LRM. My
life would be several orders of magnitudes harder without GHDL.
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
Stefan Dröge
2016-04-27 09:25:40 UTC
Permalink
Just found out: Even a "moderatly" sized (600MB) .ghw file uses almost
8GB of RAM when loaded into gtkwave. Super weird.
No wonder that I couldn't load my earlier .ghw file that was 6GB. If
that scales linear it would've taken 80GB of RAM!
Hello Stefan,
can you give an example of such a file?
Is it slow because of the signal count or because of the runtime / event
count.
Currently GHDL dumps every signal. Maybe it's possible to reduce the signal
count by specifing the signals for dumping in the future. Could this help?
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351
463-38324
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Stefan Dröge
Datum:24.04.2016 04:43 (GMT+01:00)
An: GHDL discuss list
Betreff: Re: [Ghdl-discuss] Improved '.fst' file format for VHDL
Yes, I know of the .ghw format. (That is what I am using at the moment).
However, for large waveform dumps, the .ghw format is terribly slow to
the point were it is unusable.
Hello Stefan,
if you need more features in the exported waveform database files, there
is
also the *.ghw (GHDL wave) format, which is also supported by GTKWave.
ghdl -r ..... --wave=waveform.ghw
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49
351
463-38324
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Stefan Dröge
Datum:24.04.2016 00:15 (GMT+01:00)
Betreff: [Ghdl-discuss] Improved '.fst' file format for VHDL
Some changes/additions were recently made to gtkwave's .fst file
format, which can now also support 9 value logic, and special VHDL
types like records, etc. (see gtkwave manual page 21).
Since the .fst file format shows better performance for larger
waveform dumps, it would be very useful if these changes could be
included in GHDL. For the implementation it might be interesting to
have a look at
https://github.com/nickg/nvc/blob/master/thirdparty/fstapi.c
(I could not find any information on the fst format directly from the
gtkwave website, besides the user manual)
Lastly, since I am new to the mailing list, let me say a big "thank
you!" to the Tristan and the other contributers. I am using ghdl
extensively for my master thesis project. I am writing a GPS receiver
in VHDL, including a MBlite Softcore CPU (a microblaze variant), and I
am doing my simulations exclusively in GHDL. I especially like the
performance of ghdl and that it is very pedantic about the LRM. My
life would be several orders of magnitudes harder without GHDL.
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
https://mail.gna.org/listinfo/ghdl-discuss
Adam Jensen
2016-04-26 22:44:46 UTC
Permalink
I've long imagined a GHDL with an HDF5 data file format and an embedded TCL interpreter for signal selection, signal file layout, and sophisticated simulation run-time control.
Lehmann, Patrick
2016-04-27 01:53:18 UTC
Permalink
_______________________________________________
Ghdl-discuss mailing list
Ghdl-***@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
Tristan Gingold
2016-04-29 06:32:10 UTC
Permalink
Post by Stefan Dröge
Some changes/additions were recently made to gtkwave's .fst file
format, which can now also support 9 value logic, and special VHDL
types like records, etc. (see gtkwave manual page 21).
Since the .fst file format shows better performance for larger
waveform dumps, it would be very useful if these changes could be
included in GHDL. For the implementation it might be interesting to
have a look at https://github.com/nickg/nvc/blob/master/thirdparty/fstapi.c
(I could not find any information on the fst format directly from the
gtkwave website, besides the user manual)
I agree that the waveform dumping could be improved:
- the fst dumper is still restricted to verilog like signals
- the ghw dumper doesn't use compression and the reader always read the
whole file
- both always dump all signals.

Maybe I should focus first on the fst dumper. What is the first missing
feature (please give priorities!) ?
Post by Stefan Dröge
Lastly, since I am new to the mailing list, let me say a big "thank
you!" to the Tristan and the other contributers. I am using ghdl
extensively for my master thesis project. I am writing a GPS receiver
in VHDL, including a MBlite Softcore CPU (a microblaze variant), and I
am doing my simulations exclusively in GHDL. I especially like the
performance of ghdl and that it is very pedantic about the LRM. My
life would be several orders of magnitudes harder without GHDL.
Nice quote. Thanks!

Tristan.
Stefan Dröge
2016-04-29 11:16:39 UTC
Permalink
Post by Tristan Gingold
- the fst dumper is still restricted to verilog like signals
- the ghw dumper doesn't use compression and the reader always read the
whole file
- both always dump all signals.
Maybe I should focus first on the fst dumper. What is the first missing
feature (please give priorities!) ?
In my design I am making heavy use of bundling signals in records.
This is currently not included in ghdl's fst dumper. So on top of my
wishlist would sit "Being able to log signals in records".
Second would be able to log memory arrays like RAMs.

Since .fst output seems to be comparably small, being able to select
which signals are dumped is not really important to me. (But maybe
they are only small for me, because the signals from records/memories
are missing in the dump).

Loading...