Re: [vhdl-200x] Standardize GHW format?

From: Daniel Kho <daniel.kho@gmail.com>
Date: Fri Nov 04 2011 - 05:15:15 PDT

Good to hear his reply.

My response to him would be (sorry I'm not on the other mailing list):
It is good to have "just a few" waveform formats, then to have everybody
come up with their own format.
It's good to see gtkwave supports ghdl's GHW format (which already exists).
However, if anybody else building their own simulator would come up with
their own format, even the lightweight gtkwave will eventually grow bulky
if it were to support so many different formats.

regards, dan

On Fri, Nov 4, 2011 at 5:57 AM, David Koontz <diogratia@gmail.com> wrote:

>
> On 3/11/2011, at 11:04 AM, David Koontz wrote:
>
>
> On 2/11/2011, at 10:11 PM, Daniel Kho wrote:
>
> Hi Martin,
> So far what I have is just some Ada source codes. There's no documentation
> on the format. But at least Ada is close enough to VHDL that we could all
> possibly understand.
>
> Yes, I'm having that view as well. It's probably easier to standardize
> something open source than if it were proprietary / closed source.
>
> Perhaps we could get the GHDL and GtkWave authors involved in the
> standardization effort as well?
>
>
>
> The source tree for ghdl also contains the C source used in gtkwave. I
> believe the author of ghdl Tristan Gingold supplied the code to gtkwave's
> author originally. Three files with ghw in the name in the translate/grt
> subtree of the source.
>
> As indicated in the second link your first post provided the reason he
> implemented a new dump file format was because VHDL types weren't
> conveyable in VCD as it's defined today, being Verilog centric. I'd
> suggest a little more foundation on the need for dump file format
> standardization in VHDL before addressing the specifics of a format.
>
> You might find various tools for doing VCD dump file comparison used
> primarily for regression testing but potentially also usable for comparing
> different levels of model abstraction. I did a quick search and found no
> indication of any tools for doing ghw dump file comparison, and we tend to
> see assertions and textio used in test benches for verification.
>
> The idea being what purpose a dump file standardization serves. I tend to
> think dump file formats are closely related to simulator implementations
> and that declaring a standard format that should be adhered to might
> constitute a burden on existing VHDL simulator implementations. Vendors
> likely already have their own solutions.
>
> When considering the use of the ghw dump file format I've heard to three
> waveform viewer implementations, although only gtkwave is actively
> supported. Is there overriding reason to use this format over another? We
> see tools capable of performing dump file format conversion, allowing the
> use of a wider range of formats with waveform viewers.
>
> I can't imagine Verilog and System Verilog implementations embracing
> changes to VCD to better support VHDL unless they proved transparent. To
> support VHDL would imply any waveform viewers be modified and they already
> tend to accept multiple formats (as does gtkwave). The effort to
> standardize across hardware description languages doesn't seem warranted at
> first glance.
>
> All this isn't meant as discouragement, rather getting ducks all in a row
> is in order - proposal, justification, implications. An actual dump file
> format sounds like only a small part and not exactly rocket science,
> although there are implications for headers making a format useful for
> verification.
>
> I forwarded the top of this thread on the eda.org email reflector to
> Tristan to see if he cares to respond.
>
>
> From Tristan-
>
> I saw the thread. The copyright isn't a problem. But I don't really
> understand the need of standardizing a wave format.
>
>
> Tristan.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri, 4 Nov 2011 20:15:15 +0800

This archive was generated by hypermail 2.1.8 : Fri Nov 04 2011 - 05:16:24 PDT