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

Other related Mantis items are 1142, 1102, 1032, 1023, 1000.

I want to note 1142 in particular. One of the major disadvantages of VCD
is its size.

If you dump arrays as well, it becomes much bigger.

1142 requests a binary format. Even a compressed format would be an
improvement.

Shalom 

> -----Original Message-----
> From: Jim Vellenga [mailto:vellenga@cadence.com] 
> Sent: Friday, September 21, 2007 2:27 PM
> To: Bresticker, Shalom; 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]
> 
> 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.
> ]
> ]
> ]
> 
---------------------------------------------------------------------
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.