Subject: RE: [sv-ec] Agenda for meeting 10 February 2003
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Feb 10 2003 - 13:17:55 PST
Actually there were discussions in the favor of the use of var (thereby
ref). Aso the addition of new keywords.
This is, and will continue to be, a hot topic in the committee.
Unfortunately it also tends to be a very distracting issue. The fundamental
issue in language design is NOT syntax is being added. The fundamental issue
is what semantics are being added. The question of the appropriate use of
operators (obfuscation related) vs keywords (backward compatability related)
is important but secondary to the question of the semantics.
Clearly the issue of backward compatility exists in any language.
Unfortunately Verilog was not designed with many extension mechanisms in the
language limiting the choices of how to add new features. We are definitely
trying to add some new mechanisms (member syntax, classes, etc) so that
backward compatability will be possible while adding new features. But,
there will always be problems (as you have found in Verilog-1995,
Verilog-2001, etc...).
I would also like to point out that adding as many new semantics to this
language and restricting the additions to being only operators will result
in an API like language (completely unreadable except to the initiated).
Some new keywords will have to be added. The art is which ones.
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
http://www.synopsys.com
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Michael
McNamara
Sent: Monday, February 10, 2003 11:00 AM
To: David W. Smith
Cc: 'Jay Lawrence'; 'Neil Korpusik'; sv-ec@eda.org; david.smith@synopsys.COM
Subject: RE: [sv-ec] Agenda for meeting 10 February 2003
David: I do recognize the committee's sense of urgency to address the
hundreds of other issues before it; however as a board member of Accellera I
do want to make sure the team is aware of the large practical value of doing
everything possible to make additions of new functionality enter this living
language by using syntax that today is illegal. This way the new
functionality has no downside: if their is no desire to use it the new
capability in a design, no change it required.
Hence the choice of using '&' versus 'ref' as an operator is an extremely
large issue in that use of 'ref' as an operator creates a new reserved word,
removing that word from the list of legal variable names that existing
designs very well may include today.
An extremely significant criteria that should be applied in the evaluation
of any proposed addition to a living language like Verilog is that the
addition not break existing designs, of which there are hundreds of
thousands.
So, when and if this proposal makes it to the IEEE, and to the design
community, recognize that there will be huge push back against the
introduction of new keywords.
Because to my reading, no one has expressed any reason in FAVOR of the use
of 'ref', I am curious as to why this use has attracted half of the votes?
David W. Smith writes:
> Hi Jay,
> Now that I have given the procedural response I want to respond to a
couple of points that you made. I noticed the same issue about > how the
vote was split. I guess my personal response is that it is not a real big
issue either way. The & has some positives but > also implies some things
which are not true (the use for taking a reference and declaring a reference
that this means in C++ does > not exist in Verilog - to use it for one
would imply the other). Having said that it could be lived with. We spent a
week > considering. Many arguments had been made on this in the past (for
var: var from the java community, trying to make it clear that it > does
NOT mean the same thing as & in C++) (for &: allusion to the use within C
and C++).
>
> What I do not want to do is spend more time on it. The choice is NOT a
critical issue and does not affect any semantics in the > language. Yes we
have to talk to SV-BC and have them deal with the change from 'var' to
'ref'. Same would be true if & had won. >
> So, focusing on the future we have lots to deal with to complete the
review of CH 11 and 12. Let's try and focus on this and not get > bogged
down in decisions already made. >
> Regards
> David
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jay
Lawrence > Sent: Friday, February 07, 2003 5:42 PM > To: Neil Korpusik;
sv-ec@eda.org; david.smith@synopsys.com > Subject: RE: [sv-ec] Agenda for
meeting 10 February 2003 >
>
>
>
> I think the intent here was to narrow down the choices (as we did with >
fork/join choices last week). It is very telling to me that 4 of the 6 >
votes for & come from the "user/consultant community" and all of the >
'ref' votes are from vendors. Quite frankly, I'm just thrilled 'var' has >
virtually been eliminated so that we can preserve it for replacing 'reg' >
as keyword in future generations of the language. >
> I could easily be convinced to change my vote to '&'.
>
> The only remaining issue as far as I'm concerned is a coordination issue
> with sv-bc. In that world, we had tentatively agreed that 'var' would be
> used on ports to indicate that a variable could be connected to the port
> and had "shared variable" semantics. There was some discussion that this
> should be the same as the "pass-by-reference" world. >
> There is also a desire for sv-cc to be able to specify
> pass-by-reference.
>
> If we can reconcile these issues with the other committees then I'm >
happy with '&' for pass by reference to tasks and functions. >
> jay
>
>
> ===================================
> Jay Lawrence
> Architect - Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> > -----Original Message-----
> > From: Neil Korpusik [mailto:Neil.Korpusik@eng.sun.com]
> > Sent: Friday, February 07, 2003 8:31 PM
> > To: sv-ec@eda.org; david.smith@synopsys.com
> > Subject: Re: [sv-ec] Agenda for meeting 10 February 2003
> >
> >
> > Hi David,
> >
> > It looks like you are missing Kev's vote from your
> > summary. I believe that he voted for '&' which leaves
> > us with a 6-6 tie between 'var' and '&'.
> >
> > Is there anyone out there that is willing to change
> > their vote from 'ref' to '&' ?
> >
> > If you voted for 'ref' simply because you didn't give
> > it much thought, or don't really care one way or the other > > perhaps
you should abstain or give it a bit more thought.
> > I saw several good reasons given for going with '&' and
> > didn't see any justification for var/ref.
> >
> > Neil
> >
> >
> > ------------- Begin Included Message -------------
> >
> > From: "David W. Smith" <david.smith@synopsys.com>
> > To: <sv-ec@eda.org>
> > Subject: [sv-ec] Agenda for meeting 10 February 2003
> > Date: Fri, 7 Feb 2003 17:10:22 -0800
> > MIME-Version: 1.0
> > X-Priority: 3 (Normal)
> > X-MSMail-Priority: Normal
> > Importance: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> > There will be an extra meeting for the SV-EC committee from
> > 11:00am until
> > 1:00pm PDT on Monday 10 February 2003.
> >
> > Meeting will start promptly at 11:00am and may run over in
> > order to complete
> > review of all three chapters.
> >
> > Dial in Information
> >
> >
> >
> > * PARTICIPANT CODE: 516134
> > * Toll Free Dial In Number: (877)233-7845
> > * International Access/Caller Paid Dial In Number: (505)766-5458
> >
> >
> >
> > Agenda
> >
> >
> >
> > 1. Review and approve minutes from Feb 3 meeting (as ammended
> > on web site).
> > 2. Review and resolve email voting results on var/ref/& (see attached)
> > 3. Review open action item status > > 4. Review LRM
> > a. Review 11, 12
> > b. Vote on acceptance of Chapters 1-11, 12 (with
> > condition that all
> > relate action items will be approved)
> >
> > 5. Address any other issues before committee
> >
> > For the rest of the review process discussion will be limited to the >
> following items: > >
> > clarification
> > problems
> > solutions to clarification and problems
> >
> > No new proposals will be entertained.
> >
> > A copy of the LRM is available at:
> > <http://www.sutherland-hdl.com/download/SystemVerilog_3.1_draft1.pdf>
> > http://www.sutherland-hdl.com/download/SystemVerilog_3.1_draft1.pdf
> >
> > Please review the information available on the website:
> > < <http://www.eda.org/sv-ec> http://www.eda.org/sv-ec>
> > <http://www.eda.org/sv-ec> http://www.eda.org/sv-ec.
> >
> > David W. Smith
> > Synopsys Scientist
> >
> > Synopsys, Inc.
> > Synopsys Technology Park
> > 2025 NW Cornelius Pass Road
> > Hillsboro, OR 97124
> >
> > Voice: 503.547.6467
> > Main: 503.547.6000
> > FAX: 503.547.6906
> > Email: david.smith@synopsys.com
> > <http://www.synopsys.com/> http://www.synopsys.com
> >
> >
> >
> > ------------- End Included Message -------------
> >
> >
>
This archive was generated by hypermail 2b28 : Mon Feb 10 2003 - 13:20:04 PST