Jim, Shalom, I can only repeat my statements from the last discussion the CC comittee: - we need to fix the VCD in any case. Many users are not C programmers and there are a lot of scripts out there that need some means to extract the related information. I do not see the Data Read API as a replacement, but as an extension (that might provide better results) to the VCD. Everybody I spoke to about this in my company shares this opinion, so this is not only my point of view. Currently I am not aware of any (real) user of the Data Read API. - there is some concern from my side on the support of the Data Read API. The fact that we do not find someone who wants to champion fixing all the issues that have been identified tells me that the support by all vendors for this functionality is minimal. One of the big benefits of SystemVerilog is that it is a standard that will/should be implemented by all companies. If pieces of it are only implemented by a single or a few vendors, we certainly have to rethink whether we want to use it or not. In two sentences: - Fix the VCD -- this is not an option - Fix the Data Read API -- or deprecate it, if there is no agreement by all vendors to support it -- or declare it as a future extension, that should not be used and will be fixed later [for me this is also a sort of deprecation, but it sounds a little better ;-)] Just my $0.02 Best regards, -Michael Rohleder Jim Vellenga wrote: > 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. > ] > ] > ] > > -- NOTE: The content of this message may contain personal statements which are not neccessarily the view of Freescale, unless specifically stated. ___________________________________________________ | | | Michael Rohleder Tel: +49-89-92103-259 | / )| Principal Staff Engineer Fax: +49-89-92103-101 |( \ / / | Freescale Semiconductor, www.freescale.com | \ \ _( (_ | _ New Product Development Center _ | _) )_ (((\ \>|_/ > Schatzbogen 7, D-81829 Muenchen, Germany < \_|</ /))) (\\\\ \_/ / mailto:michael.rohleder@freescale.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \ This e-mail, and any associated attachments have been classified as: [ ] Public [ ] Freescale Semiconductor Internal Use Only [x] Freescale Semiconductor Confidential Proprietary Freescale Halbleiter Deutschland GmbH Schatzbogen 7 D-81829 Muenchen www.freescale.com Sitz der Gesellschaft/Registered Office: Muenchen Registergericht/Registered Court: Amtsgericht Muenchen HR B 151590 Geschaeftsfuehrer/General Manager: Juergen Weyer, Karen Roscher, John Pence, Oliver Kaltenbach, Andreas Wild USt.-ID-Nr./VAT-ID-No. DE813898243 Steuernummer/Tax No. 143/138/30552 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Sep 21 05:52:47 2007
This archive was generated by hypermail 2.1.8 : Fri Sep 21 2007 - 05:54:54 PDT