RE: [sv-ac] RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - deprecate Data Read API]

I very much agree with Dave's and Joao's comments. I would add that
users are central to the equation. A standard data read interface is
meant to improve design productivity with increased
interoperability/portability, and reduced maintenance data exchange
cost. In fact, the LRM has a brief motivation for same (note: I think
one of the mantis items suggests striking this section out :)). 

Yes as Doug states, the API improves vendor interoperability as well --
again to the benefit of users. Yes a debug vendor donated a proven API
and committee worked together to shape into VPI much like the DPI and
assertion/coverage APIs -- the evolution of all these APIs is documented
at http://www.eda-stds.org/sv-cc/hm/. No it is not designed exclusively
for debug vendors rather any provider that stores data and wishes to
give users (or by proxy another vendor) access to. 

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Rich, Dave
Sent: Friday, September 21, 2007 8:36 AM
To: Jim Vellenga; Brad Pierce; sv-ac@eda.org; sv-bc@eda.org;
sv-ec@eda.org; sv-cc@eda-stds.org
Subject: [sv-ac] RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 -
deprecate Data Read API]

Jim,

There is a strong demand in requests to provide a standard mechanism for
dumping all SV data. Most people, like Michael, assume that the VCD
format is capable of dealing with that task.  I don't agree, and this
problem has been around for 7 years since my days of simulation with
Superlog.

I put forward that it would be easier to correct and implement the
read/write API than it would be to extend the VCD format along with the
tools that would have to parse that format. It's like trying to stream a
full feature movie in real time over a dial-up connection. Certain
mediums are just not up to the task.

As people move towards transaction level modeling in both their
testbenches and designs, writing transaction out to a format that was
only designed to handle 1's and 0's for gate-level design does not make
sense. Dynamic data aside, the very nature of tracing though class
handles requires a level of sophistication much grater than simple text
processing.

Also as a precedent, SV 3.0 had a completely different assertion
language that was thrown out and replaced with the current SVA. So if
the current data read/write is unworkable and the majority agrees, there
is nothing preventing you from starting all over again.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Jim Vellenga
> Sent: Friday, September 21, 2007 5:18 AM
> To: Brad Pierce; sv-ac@server.eda.org; sv-bc@server.eda.org; sv- 
> ec@server.eda.org; sv-cc@server.eda-stds.org
> Subject: RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - deprecate
Data
> Read API]
> 
> I think the showstopping problem so far seems to be a lack of demand.

> Can any of the vendors say that they have customers asking them to 
> implement it?
> 
> If not, then the showstopping problem is going to be a lack of enough 
> interest to justify the resources to implement it.
> 
> Brad, you're the first person we've run across who seems genuinely 
> interested.  Can we inveigle you into working on the Mantis items?
> 
> Regards,
> Jim
> 
> ---------------------------------------------------------
> James H. Vellenga                            978-262-6381
> Software Architect                              (FAX) 978-262-6636
> Cadence Design Systems, Inc.         vellenga@cadence.com
> 270 Billerica Rd
> Chelmsford, MA 01824-4179
> "We all work with partial information."
> ----------------------------------------------------------
> 
> ]-----Original Message-----
> ]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On ]Behalf Of 
> Brad Pierce
> ]Sent: Thursday, September 20, 2007 6:36 PM
> ]To: sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda-stds.org
> ]Subject: RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - 
> ]deprecate Data Read API] ] ]Another conclusion I could reach from the

> same data is that, as with ]many other SV features, a slew of Mantis 
> items has been opened ]regarding ]the Data Read API, but there are no 
> serious problems with it.
> ]
> ]Surely the SV-CC could point to at least one "showstopper" problem
that
> ]"will prevent vendors from implementing" the Data Read API?
> ]
> ]-- Brad
> ]
> ]-----Original Message-----
> ]From: Moorhouse, Abigail [mailto:abigailm@model.com]
> ]Sent: Thursday, September 20, 2007 3:12 PM
> ]To: Brad Pierce; sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org; 
> ]sv-cc@eda-stds.org
> ]Subject: RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - deprecate

> ]Data Read API] ] ]hi Brad ]It's kind of the point of the deprecation 
> suggestion, that no-one is ]interested in creating this prioritized 
> list! Effectively, we have
all
> ]taken a look, and assigned them priority "don't do this".
> ]
> ]However, the Mantis items whose description starts with a ]section 
> number
> ]31 are in this category. The Mantis items are:
> ]
> ]560
> ]559
> ]593
> ]592
> ]590
> ]588
> ]587
> ]584
> ]583
> ]581
> ]580
> ]579
> ]568
> ]567
> ]565
> ]563
> ]562
> ]558
> ]557
> ]556
> ]555
> ]
> ]Why don't you take a look and see what priorities you would assign?
> ]
> ]Abi
> ]
> ]-----Original Message-----
> ]From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org]
On
> ]Behalf Of Brad Pierce
> ]Sent: Thursday, September 20, 2007 2:48 PM
> ]To: sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org;

> ]sv-cc@server.eda-stds.org
> ]Subject: RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - deprecate

> ]Data Read API] ] ]This proposal seems extreme -- ]
> ]   http://www.eda-stds.org/svdb/view.php?id=2054
> ]
> ]"The Data Read API has many serious problems which will prevent
vendors
> ]from implementing it. Unless someone wants to step up and work ]on 
> fixing ]them, I think the entire section should be eliminated."
> ]
> ]To help us understand the context of this proposal, could ]someone 
> please ]send a prioritized list of these "many serious problems"?
> ]
> ]-- Brad
> ]
> ]-----Original Message-----
> ]From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On ]Behalf Of 
> Neil ]Korpusik
> ]Sent: Thursday, September 20, 2007 2:27 PM
> ]To: sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org
> ]Subject: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - deprecate
Data
> ]Read API]
> ]
> ]Forwarding to a wider audience.
> ]
> ]Neil
> ]
> ]
> ]-------- Original Message --------
> ]Subject: [sv-cc] Added Mantis item 2054 - deprecate Data Read API
> ]Date: Thu, 20 Sep 2007 16:09:46 -0400
> ]From: Charlie Dawson <chas@cadence.com>
> ]To: SV-CC <sv-cc@eda-stds.org>
> ]
> ]Hi All,
> ]
> ]I've added a mantis item to deprecate the Data Read API and a
proposal.
> ]We can further debate the merits of this at our next meeting.
> ]
> ]   -Chas
> ]
> ]
> ]--
> ]Charles Dawson
> ]Senior Engineering Manager
> ]NC-Verilog Team
> ]Cadence Design Systems, Inc.
> ]270 Billerica Road
> ]Chelmsford, MA  01824
> ](978) 262 - 6273
> ]chas@cadence.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 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 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 and
dangerous content by MailScanner, and is
believed to be clean.