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. 2016-04-24 14:27 GMT+02:00 Lehmann, Patrick <patrick.lehm...@tu-dresden.de>: > 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 > E-Mail: patrick.lehm...@tu-dresden.de > 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. > > 2016-04-24 1:10 GMT+02:00 Lehmann, Patrick <patrick.lehm...@tu-dresden.de>: >> 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 >> E-Mail: patrick.lehm...@tu-dresden.de >> WWW: http://vlsi-eda.inf.tu-dresden.de >> >> -------- Ursprüngliche Nachricht -------- >> Von: Stefan Dröge >> Datum:24.04.2016 00:15 (GMT+01:00) >> An: ghdl-discuss@gna.org >> 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 >> Ghdl-discuss@gna.org >> https://mail.gna.org/listinfo/ghdl-discuss >> >> _______________________________________________ >> Ghdl-discuss mailing list >> Ghdl-discuss@gna.org >> https://mail.gna.org/listinfo/ghdl-discuss >> > > _______________________________________________ > Ghdl-discuss mailing list > Ghdl-discuss@gna.org > https://mail.gna.org/listinfo/ghdl-discuss > > _______________________________________________ > Ghdl-discuss mailing list > Ghdl-discuss@gna.org > https://mail.gna.org/listinfo/ghdl-discuss > _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
