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

I believe this data read API was targeted at easing collaboration
between vendors.  The thought was that debug vendors would like
to make use of this API in order to create and manage their own
waveform database.  And simulator vendors would implement the API
so that debug vendors could portably interoperate with all simulators.

The fact that no one is stepping forward to take ownership of this
API indicates that there is an absence of interest in the above.

Simulator vendors certainly can't be expected to drive the need
for the API.  They already have efficient ways to create their
own waveform databases.  And end users can't be expected to drive
the need for the API - they aren't into creating and maintaining
sophisticated waveform databases and viewing tools.

Clearly there are successful debug vendors, and they have databases,
and they are interoperating with the simulator vendors.  And the
data read API doesn't exist, for all practical purposes.

This should tell everyone something:  There is no demand for this API,
or even a fixed version of this API.  People are getting the job done
by other means, or at the least they are working on getting the job
done by other means.

If someone wants to step forward and champion the data read API,
and the good of SV users depends on it, of course the SV-CC would
be willing to put in the time to refine and mature the API.
And vendors would be willing to implement it in that case, since
it would benefit their users and thus help their business.

In the absence of demand, how can either the SV-CC or any of the
simulator vendors afford to invest resources in a zero ROI project
like this?

Regards,
Doug



-----Original Message-----
From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On
Behalf Of Jim Vellenga
Sent: Friday, September 21, 2007 5:27 AM
To: Bresticker, Shalom; Vreugdenhil, Gordon
Cc: sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org;
sv-cc@server.eda-stds.org
Subject: RE: [sv-ac] Re: [sv-ec] RE: [sv-bc] [Fwd: [sv-cc] Added Mantis
item 2054 - deprecate Data Read API]

Shalom,

I agree that leaving VCD deficient is intolerable
and disrepectful, but I don't agree that replacing it with
an interface that no one is implementing is any better.

Wouldn't it be better to put the resources into fixing up
VCD as noted by Mantis items 104, 1770, and 1950 (and
perhaps others)?

Regards,
Jim Vellenga

--------------------------------------------------------- 
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 Bresticker, Shalom
]Sent: Friday, September 21, 2007 1:44 AM
]To: Gordon Vreugdenhil
]Cc: sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda-stds.org
]Subject: RE: [sv-ac] Re: [sv-ec] RE: [sv-bc] [Fwd: [sv-cc] 
]Added Mantis item 2054 - deprecate Data Read API]
]
]The situation now is that VCD is quite incomplete. Vendors are
]implementing proprietary enhancements which are not portable. One
]popular third-party debug-tool vendor told me that its extensions work
]with one of the big simulators, partly with a second, and not at all
]with a third.
]
]Till now, the excuse for not extending VCD was that the Data Read API
]replaces it. Now some people want to remove the API and leave the
]standard with an officially deficient debug interface?? As a user, I
]find that intolerable and disrespectful of our needs.
]
]Shalom
]
]
]> -----Original Message-----
]> From: owner-sv-ac@server.eda.org 
]> [mailto:owner-sv-ac@server.eda.org] On Behalf Of Gordon Vreugdenhil
]> Sent: Friday, September 21, 2007 1:22 AM
]> To: Steven Sharp
]> Cc: sv-ac@server.eda.org; sv-bc@server.eda.org; 
]> sv-ec@server.eda.org; sv-cc@server.eda-stds.org; 
]> Brad.Pierce@synopsys.com
]> Subject: [sv-ac] Re: [sv-ec] RE: [sv-bc] [Fwd: [sv-cc] Added 
]> Mantis item 2054 - deprecate Data Read API]
]> 
]> Worse than that is the problem that if someone does actually 
]> start implementing to a seriously deficient spec, then you 
]> end up with more difficult to resolve backwards compatibility 
]> issues when attempting to fix things.
]> 
]> Better in my opinion to remove the whole thing and 
]> reintroduce a rational definition once one can have a 
]> reasonable expectation that serious compatibility issues won't arise.
]> 
]> Gord.
]> 
]> Steven Sharp wrote:
]> >> 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.
]> > 
]> > I read the items and didn't see any showstopping problems.  
]> However, 
]> > it does sound like the section is a mess and needs serious 
]> rewriting.
]> > 
]> > If nobody cares enough about the section to do that 
]rewrite, then I 
]> > don't see a reason to keep it.
]> > 
]> > Steven Sharp
]> > sharp@cadence.com
]> > 
]> > 
]> 
]> --
]> --------------------------------------------------------------------
]> Gordon Vreugdenhil                                503-685-0808
]> Model Technology (Mentor Graphics)                gordonv@model.com
]> 
]> 
]> -- 
]> This message has been scanned for viruses and
]> dangerous content by MailScanner, and is
]> believed 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.
]
]
]

-- 
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.