Subject: RE: [sv-ec] Agenda for meeting 10 February 2003
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Feb 10 2003 - 14:12:55 PST
> From: "David W. Smith" <david.smith@synopsys.com>
>
> 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.
>
I'd like to disagree with you there. Since large amounts of functionality
currently describing testbenches and designs is in C/C++, the ability to
migrate that IP simply into SV at a future date is important. The less
syntactic (and semantic) compatibility between the languages the harder
that migration is (and the slower it goes). This is also an issue with
software/hardware trade-off where you want to specify algorithms in a
way that fits with the compilers for embedded processors (C/C++) and with
synthesis tools (SV) i.e the code should be polymorphic where possible.
So I view syntax as being as important as semantics for this particular
language.
> 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
It's debatable how readable any of these languages are to the uninitiated,
the only plus I find in keywords is that I can get them colored differently
in Emacs which seems to make it more readable (thanks Mac).
Regards,
Kev.
> David W. Smith
> Synopsys Scientist
>
> -----Original Message-----
> From: Michael McNamara
>
>
> 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 - 14:14:16 PST