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

Accellera has this policy too. See my earlier email -- I think there is
good market penetration. And yes there are many interoperable vendors
today too -- most work for a single timepoint of history in VPI though
:) [see vpiLimitedAccessInteractive mode]. 

To dispell any other misinformation see
http://www.eda-stds.org/sv-cc/hm/. 

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Steven J. Dovich
Sent: Friday, September 21, 2007 11:31 AM
To: Warmke, Doug
Cc: Jim Vellenga; Bresticker, Shalom; Vreugdenhil, Gordon;
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]

This situation is at the heart of a policy decision made by both the
Internet Engineering Task Force and the IEEE POSIX working group.  They
have mandated that they will only consider existing practice for
inclusion in a published standard. Implementations need to exist and be
in use to demonstrate the feasibility and value for a particular
technology proposal.  Invention in committee is strongly discouraged and
those communities close ranks to enforce that culture.  As a result,
they view the standard not as a place to innovate, but rather as a place
to document known working solutions.

This is not to suggest that the Data Read API is not a workable
solution, but rather it has not yet reached the market penetration that
justifies inclusion in the standard.  If folks are ready to remedy that,
and make the corresponding changes to the text where needed, then I
don't see anyone caring enough to force Data Read out of the standard. 
But until that happens, SystemVerilog will retain elements of fiction in
its specification.  Data Read is not presently a standard, IEEE
publication not withstanding.  Can anyone point to two interoperable
implementations? If not, then those with IETF experience would be forced
to ask why it is in the document.

/sjd


Warmke, Doug wrote:
> 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.