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
---------------------------------------------------------------------