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.