RE: [sv-bc] RE: [sv-cc] Read API

I think a portable format is needed because there is a need to be able
to transfer information between tools easily without having to link in
multiple APIs. Also, sometimes there is a need to look at the raw data.
I have more than once debugged a problem by opening up the VCD text file
and seeing exactly what is written there. I do think a binary format
(which could be transformed in a standard way to ASCII) is needed,
because ASCII is too big.

Shalom  

> -----Original Message-----
> From: owner-sv-cc@server.eda.org 
> [mailto:owner-sv-cc@server.eda.org] On Behalf Of Bassam Tabbara
> Sent: Wednesday, October 03, 2007 7:16 AM
> To: stuart@sutherland-hdl.com; Bassam.tabbara@synopsys.com; 
> Maidment, Matthew R; sv-cc@server.eda.org
> Cc: sv-bc@server.eda.org
> Subject: Re: [sv-bc] RE: [sv-cc] Read API
> 
> Thanks Stu for the elaboration. The API does offer a means 
> for portable queries which is what both user and tool really 
> need and assumed to be the goal. Yes it does not and is not 
> meant to use a file or expose any other database to 
> accomplish that goal.
> 
> If the end goal is the file itself not the data within 
> (queried) then file is the way to go. In general, however 
> people in similar fields are moving away from file 
> interchange and towards API. In SV there is VPI for part of 
> the equation and that API works fine ... Read API is meant to 
> finish the thought ... 
> 
> Hope I clarified the idea -- I for one think its neat :).
> 
> THX. 
> -Bassam
> 
> -----Original Message-----
> From: Stuart Sutherland <stuart@sutherland-hdl.com>
> To: 'Bassam Tabbara' <Bassam.Tabbara@synopsys.COM>; 
> 'Maidment, Matthew R' <matthew.r.maidment@intel.com>; 
> sv-cc@eda.org <sv-cc@eda.org>
> CC: sv-bc@eda.org <sv-bc@eda.org>
> Sent: Tue Oct 02 21:16:50 2007
> Subject: RE: [sv-bc] RE: [sv-cc] Read API
> 
> 
> I fully understand that the API does not provide a portable 
> file format.
> That is why it does not solve the problem of having a 
> portable and standard way to communicate simulation activity 
> to a variety of tools.  Certainly the API could be used to 
> create such a file, but that file would not be in an industry 
> standard format.  What is needed is a more efficient version 
> of the VCD that supports all of SystemVerilog.  The fact that 
> no simulation vendor has implemented the API along with the 
> fact those same vendors state that their customers are not 
> asking for it, indicate that the API does not solve the 
> problem of exchanging what took place in simulation between 
> various types of tools.  This is why I feel the API can be 
> deprecated.  
> 
> I also agree with Shalom and others that deprecating the API 
> does not solve the problem of having an enhanced VCD standard 
> (or a replacement for the VCD).  But keeping the API does not 
> give us that either, and trying to maintain an API that no 
> one is using takes resources away from being able to enhance 
> or replace the VCD.
> 
> On the other hand, if the SV standard contained the API code 
> to create a standard SystemVerilog data format file (would 
> that be an SSVDF file?), then the API would solve the current 
> VCD problems.
> 
> Just my opinion.  I'm not going to lose sleep over whether or 
> not the API is deprecated.  Nor am I likely to ever have a 
> need or opportunity to use it.
> For me, it's just clutter in a big LRM, but easy clutter to ignore.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> Sutherland HDL, Inc.
> stuart@sutherland-hdl.com
> 503-692-0898
>  
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bassam Tabbara
> > Sent: Tuesday, October 02, 2007 6:33 PM
> > To: Maidment, Matthew R; sv-cc@server.eda.org
> > Cc: sv-bc@server.eda.org
> > Subject: [sv-bc] RE: [sv-cc] Read API
> > 
> > Hi Matt,
> > 
> > The summary below seems lacking/inconsistent to me -- please 
> > elaborate.
> > 
> > The read API is NOT meant to provide a portable file format 
> rather the 
> > opposite (see LRM) so the reasoning of motion, as stated below, and 
> > the outcome is not clear. VCD and the API have same 
> ultimate goal yes 
> > (i.e.
> > data query) but they are distinct -- meaning we can have 
> either, both, 
> > or none (!). Current LRM strategy offers the API and discusses the 
> > advantages of an API (e.g. efficiency) over file exchange.
> > 
> > Thx.
> > -Bassam.
> > 
> > -----Original Message-----
> > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of 
> > Maidment, Matthew R
> > Sent: Tuesday, October 02, 2007 4:55 PM
> > To: sv-cc@eda.org
> > Cc: sv-bc@eda.org
> > Subject: [sv-cc] Read API
> > 
> > Hello SV-CC	
> > 
> > As the future of the Read API could impact the future of the VCD 
> > specification as well as impact the ability of users to debug, the 
> > SV-BC discussed the proposal to deprecate the Read API.
> > 
> > During the October 1 meeting, a majority (_not_ unanimous) vote was 
> > passed to communicate to the SV-CC that the SV-BC has no 
> objection to 
> > deprecating the Read API.
> > 
> > Per the unapproved minutes:
> > 
> >   Stu moves that the SV-BC notify the SV-CC that the SV-BC has no
> >   objection to deprecating the Read API.  Reasons: the API does
> >   not solve the problem of a portable file format for debug 
> > information.
> >   Cliff seconds.
> > 
> >   For: Cliff, Mark, Dave, Steven, Gord, Stu, Alex, Don
> >   Opposed: Brad (approved during the SV process and should not be
> > removed)
> >            Shalom (Need a commitment to provide a new method for 
> > providing
> >                    information or extension of vcd)
> >            Tom (Agrees with Shalom's comments)
> >   Abstain: Francoise (Some potential names to maintain the read api)
> >            Karen (may be escalated- will withhold opinion)
> > 
> > We hope this helps in your process to decide the fate of 
> the Read API.
> > 
> > Matt
> > --
> > Matt Maidment
> > mmaidmen@ichips.intel.com
> >  
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, and is believed to be clean.
> > 
> > 
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, and is believed to be clean.
> > 
> > 
> > 
> > 
> 
> 
> 
> -- This message has been scanned for viruses anddangerous 
> content by MailScanner, and isbelieved to be clean.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.