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

----- Non-member submission from Bassam Tabbara -----
Date: Tue, 27 Jun 2006 16:23:12 -0700

Hi All, [apologies for wide cc]

I want to comment that the trend in our industry today, driven by users,
is to move away from file-based interchange for obvious reasons that I
will not motivate here (some is in clause already). If gate abstraction
and below is taking this route it behooves SV's RTL and above to do so
too and move away from files. The Read API does this by using SV's VPI
as the data model/access API. Yes Stu some more control/read
extension/specialization is warranted (for tasks/API) for new types, and
yes Neil the *write* API is missing, covered in part by ease of DPI/SV
task call. 

The data model approach is a "new" (tool-integration) use model so
likely will have some growing pains. We can make the call on whether to
put resource into improving it or fall back on extending VCD despite
known issues and limitations.

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-cc@eda-stds.org [mailto:owner-sv-cc@eda-stds.org] On
Behalf Of Stuart Sutherland
Sent: Monday, June 26, 2006 11:01 PM
To: Neil.Korpusik@sun.com; 'Francoise Martinolle'
Cc: sv-cc@verilog.org; sv-bc@verilog.org; 'Clifford E. Cummings'
Subject: [sv-cc] 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
> ---------------------------------------------------------------------
> 
> 
>