Subject: RE: [sv-ec] Agenda for meeting 10 February 2003
From: Michael McNamara (mac@verisity.com)
Date: Mon Feb 10 2003 - 11:00:08 PST
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 - 11:02:07 PST