Dear Brian
I was just wondering if GHW is the best format for your
purpose or if we could be developing an FST interface alongside your
project. But apparently I wasn't clear.
I don't see any other objection to using ghw, though I don't know if
it's well enough documented.
I think that this is more of a technical decision. GHW and FST have
the most elaborate APIs and either could be a possible starting point
(I will explain this).
The FST implementation is not in the /src dir of GTKwave but is found
in /src/helpers/fst . There is also a helpful block_format.txt that
explains the file format a bit (not a direct BNF per se). It also
seems to me that FST currently does not support real arithmetic (only
integers in the value change blocks). On the other side, I see
facilities for generating compressed traces which is useful.
I have done insufficient reading on FST, but that's where I would start;
it is supported by gtkwave already.
Indeed FST looks good, thanks!
One hobby horse of mine : VHDL has an excellent type system; I would
want any interface to it to preserve that type information into the
other domain (which domain is free to discard what it cannot use or
support).
That type support should naturally include real data and physical types
to represent analog data.
I am basically thinking of how a generic waveform format should look
like, given the following prerequisities:
1. Support VHDL and VHDL-AMS with full type support as you have noted.
2. Ideally, be able to directly handle Verilog-2005 (eventually
SystemVerilog-2009) and SystemC for hardware design (all-in-one),
otherwise via vcd/evcd to/from fst tools (I think this would mean to
extend existing tools).
Best regards
Nikolaos Kavvadias
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
