Adam, < FST (Fast Signal Trace, or Fast Simulation Trace) is a binary file format used by Icarus verilog, GTKwave and a few other tools (Covered comes to mind).
HDF5 is used extensively throughout several scientific communities and many data analysis/visualization tools have HDF5 file access support. I am not aware of any HDL-simulator type of CAD tool that uses the HDF5 data-store as a signal trace format. I suspect most HDL-CAD users and tool makers are probably focused on digital logic at the wire level. However, if complex data structures (of an abstract model) are going to be traced during simulation, HDF5 might be a good candidate for the dumpfile format. /> Thanks. Sorry for my lack of knowledge on these formats. I've heard of Icarus Verilog, but have never used it. I will find time to take a closer look into FST and HDF5. Tristan, Great to know that the minor changes for VHDL-2008 are simple or trivial to do. < Are you using 2008 style arrays ? /> I'm assuming you are referring to the simplified Array / Bit Logic Operators described in Jim's paper. Yes, I do use these whenever I need to manipulate data (e.g. concatenate data from different sources, or performing arithmetic operations). VHDL-2008 includes several overloaded functions (such as the "and" functions in the paper) that make it easier to do these things, instead of having to declare intermediate signals. I usually write my own subprograms to do these things in the past, but for all new projects, I will be using the simplified techniques from VHDL-2008. However, I admit I don't need to manipulate data very often, unless the application is a DSP-intensive one. Probably, there is no change at all for GHDL, other than including the new overloaded subprograms from the standard. I can't be too sure though. On a separate note (still on the topic of composite types), I also like to keep things unconstrained until later. So I tend to use VHDL-2008's unconstrained record elements often, deferring the size/width definition until much later. This makes the design unit able to be reused for different applications requiring different bus widths (but same functionality). Another thing I've been doing very often these days is using generic types. In fact, I try to use generic types more than unconstrained record elements. If I have a record with an unconstrained element of type std_logic_vector for example, I will not be able to change this type to something else, e.g. unsigned / signed, and use it directly for another application, without first performing type conversion. So, these days, I prefer to use generic types, i.e. have virtually all type information deferred until much later when the application eventually defines the datatype and the buswidth. So, in terms of priority, I would say support generic types, packages, and subprograms first before supporting unconstrained record elements. < The main advantage of FST, VZT and other gtkwave formats is the compression level. /> On the topic of compression, I was thinking that we could use GHW in conjunction with compression techniques such as LZMA. I'm not saying we should ditch the other formats (FST, VZT, HDF5) altogether; I'm saying we could study these formats to either incorporate them into GHDL, or improve the existing GHW format with a good compression algorithm (which is probably the only thing GHW lags behind now?). Or we could do both (include the other formats, and improve GHW). Brian, < It is naturally compatible with any VHDL without nested comments; the count simply never exceeds 1. So I think it's a simple enhancement rather than a deep change. Whether it's worth fixing at this stage is probably debatable, (let alone the effect on syntax highlighting editors etc!) but I'll raise it. /> If this is so, I believe this is worth raising on P1076. regards, daniel
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
