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

From: Michael Rohleder <michael.rohleder_at_.....>
Date: Fri Sep 21 2007 - 05:52:03 PDT
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