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.