RE: [sv-bc] FW: mantis item 104: vcd file and data read API

I agree with all that Neil has said.  I will add that VCD files are used for
more than just waveform displays.  Some companies have in-house tools that
extract information from VCD files.  VCD is an important part of HDL based
design, and needs to be enhanced to support more of SystemVerilog types,
including dynamic types.  VCD also needs to be enhanced to provide more
efficient file formats.  Standard switches need to be added to the VCD
system tasks that provide for more capabilities, and for backward compatible
modes.  In-house tools seldom migrate to new language features as quickly as
EDA vendors, so backward compatibility is critical.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@server.eda-stds.org 
> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Neil Korpusik
> Sent: Monday, June 26, 2006 6:31 PM
> To: Francoise Martinolle
> Cc: sv-cc@server.verilog.org; sv-bc@server.verilog.org; 
> Clifford E. Cummings; stuart@sutherland-hdl.com
> Subject: Re: [sv-bc] FW: mantis item 104: vcd file and data read API
> 
> Here is my feedback on the question of vcd versus the 
> SystemVerilog API.
> I am assuming that you are referring to clause 30 in SystemVerilog.
> 
>    30. SystemVerilog data read API
> 
> I don't view the API described in clause 30 as a replacement 
> for the vcd file
> format. There is a completely different use-model required 
> for each of these.
> 
> vcd:
> 
>    This file format allows data produced from one application 
> to be read into
>    a different application. There is no extra work required 
> on the part of the
>    user to pass vcd data between applications that support 
> this file format.
>    Each application understands the same file format.
> 
> API:
> 
>    In order to use the API to pass data between applications 
> can require some
>    effort on the part of the users. In order for the data 
> produced by one
>    application to be used by another application requires the 
> following:
> 
>        Application A - writes out data to its proprietary file format
>                      - must provide the API for this data 
> file. This will
>                        presumably be provided by a library 
> file that can be
>                        linked into a second application.
>        Application B - must be able to use the API from 
> application A to get
>                        access to the data written out by 
> application A.
>                      - the provider of application B could 
> provide a library
>                        that could be linked to the API 
> library provided by
>                        application A. That would then allow 
> the user of
>                        application B to link it with the API 
> library for
>                        different applications, so that 
> application B can now
>                        read in data from each of the 
> proprietary file formats
>                        supported by those other applications.
>                      - alternatively application B could 
> provide a prepackaged
>                        version of its application that already has the
>                        library for application A linked into 
> it, so that it
>                        can read in the file produced by 
> application A. In
>                        general, this will not be the case.
> 
> This use of the API to allow interoperability of the files 
> produced by one
> application is useful, but it will undoubtably require work 
> on the part of
> the user community to make it work. There will most likely be 
> a few places
> where the interoperability will be provided (e.g. for a major 
> waveform tool's
> file format), but in general this type of interoperability won't be
> provided by the tool vendors. It will then be up to the 
> user's to be able
> to link the required set of libraries to make it work.
> 
> The vcd file format offers a simple means of passing data 
> between different
> applications. Yes, it can be inefficient, but it works. Once 
> we start talking
> about various libraries and so forth, there can be issues 
> with linkers and
> version compatibilities.
> 
> Neil
> 
> 
> Francoise Martinolle wrote On 06/21/06 09:54,:
> > Resend since I sent it to eda.org before.
> >  
> > 
> > 
> --------------------------------------------------------------
> ----------
> > *From:* Francoise Martinolle
> > *Sent:* Monday, June 19, 2006 2:29 PM
> > *To:* 'SV-CC'
> > *Cc:* Bresticker, Shalom; 'Clifford E. Cummings';
> > 'stuart@sutherland-hdl.com'; Francoise Martinolle; 'sv-bc@eda.org'
> > *Subject:* mantis item 104: vcd file and data read API
> > 
> > The BC committee would like to get the opinion of the CC 
> committee on
> > mantis item 104.
> > Mainly the question is "would the database read API be a total
> > replacement for vcd format"
> > or should we extend the vcd format to support new SV datatypes.
> >  
> > If we want to extend VCD, should we limit it to statically 
> elaborated
> > objects of the design? (Specifying how dynamically 
> elaborated objects
> > for example automatic variables, or objects of dynamic datatypes are
> > dumped can be difficult.)
> > Currently VCD has been extended to allow unpacked structs 
> (section 24.2
> > in P1800: this is sort of a hack) but does not provide support for
> > unpacked arrays.
> >  
> > Cliff, Stu,
> > can you provide the VCD user point of view?
> >  
> > Francoise
> >        '
> 
> -- 
> ---------------------------------------------------------------------
> Neil Korpusik                                     Tel: 408-720-4852
> Senior Staff Engineer                             Fax: 408-720-4850
> Frontend Technologies - ASICs & Processors (FTAP)
> Sun Microsystems
> email: neil.korpusik@sun.com
> ---------------------------------------------------------------------
> 
> 
>