Meeting - Thursday 31st March 2011
Attendees:
============
Dave Cronaur (Synopsys)
Ian Wilson (BDA)
Kevin Cameron (Consultant)
Shalom Bresticker (Intel)
Dave Miller (Freescale)
* Call times.
As of 3rd April everyone has now transitioned from/to daylight savings time. As
we move forward we need to identify a new time. Australia and India have had an
awkward time the last few iterations, so new suggested time is:
Friday 03:00am UTC
San Francisco : Thurs 8:00pm
Austin: Thurs 10:00pm
Adelaide: Fri 12:30pm
India: Fri 8:30am
* SVAMS merge: overview of updated chapter 01 Introduction
We went through an initial review of the updated chapter 01 Introduction.
Comment was again raised why we are doing this work within the Accellera group,
and will it make it difficult to keep track of potential changes within the
IEEE System Verilog document.
The decision late last year when discussing whether to become part of IEEE or
remain in Accellera was to remain with Accellera until we have the first
working version of the SV-AMS document. It was felt at the time that this would
allow us to do two things:
1. perform the initial implementation of the ASVA changes within the
Verilog-AMS document.
2. Allow us to get a working version of the language in place before donating
it to IEEE P1800 group.
It was felt that by remaining under the Accellera banner we would have a lot
more flexibility/freedom in how we approach this work.
Once we have a working version of the language we will again revisit how we
want to work with the P1800 group in terms of a dot standard etc.
Shalom indicated that even though we are proceeding with this merge basing it
against the SV 2009 Std, we should be ok. The changes currently under review
for the SV 2011 (2012?) Std are fairly limited in scope and should have very
little impact on our work
With respect to the initial version of the merged document, we plan on doing a
very shallow merge to just allow the two languages to co-exist. With that in
mind, most of the changes with the Introduction chapter are reference and
version changes.
Shalom provided some valuable feedback on the change bars which I have included
at the end of these minutes.
One interesting point was raised. For Chapter 3 - Data types, data types in SV
have undergone a conceptual change that will need to be reflected in the SV-AMS
manual. Data objects in SV are broken down into a data kind and a data type.
The data kind may be a net for example. But the data type may be an integer.
This is different to how the existing Verilog-AMS views data types where an
integer defines both the kind and type. Special care will have to be taken when
reviewing Chapter 3.
Next call is tentatively scheduled for Thursday 14th Apr. The meeting is
tentative depending on whether I am able to complete Chapter 2 - Lexical
Conventions in time. Clarification on the call will be sent out early next week.
* Note new times (Friday 03.00am UTC) *
Dialin Details:
San Francisco, Thurs 08.00p
Austin, 10.00p
Boston, 11.00p
Amsterdam, 5.00a
Tel Aviv, Fri 6.00a
New Delhi, 8:30a (next day)
Adelaide, 12:30p
Call-In Details:
USA Toll Free : 8008671147
Australia Toll Free: 1800009128
India Toll Free : 0008006501482
Netherlands : 08002658223
Passcode: 0970751#
Feedback from Shalom on 01-Introduction:
1. It calls SV and SV-AMS an "HDL". However, while Verilog was indeed called an
HDL, SV is called an HDVL, Hardware Design and Verification Language (or even
more fully, a Hardware Design, Specification, and Verification Language).
2. In referencing IEEE standards, the "S" in "Std" should be upper-case, i.e.,
"IEEE Std 1800-2009".
3. SV-2009 is "IEEE Std 1800-2009", not "IEEE Std P1800-2009" (no "P").
4. The third paragraph describes SV as "based on the Accellera SystemVerilog
3.1a extensions" to Verilog. While historically true, the time has come in 2011
to stop referring to SV 3.1a, which was really just an intermediate stage on
the way to the IEEE. It is somewhat like saying that Draft 7 is based on Draft
6. SV 3.1a is a historical artifact that should be forgotten. I still encounter
papers being written that mention SV and then put a reference to SV 3.1a in the
footnote, instead of referencing IEEE 1800-2005 or 2009.
5. In 1.2, the font of "analog" in "analog procedural block" is not consistent.
6. Section 1.4, item 3 says, "Blue characters are used to denote syntax
productions that are SystemVerilog-AMS extensions to IEEE std 1364-2005 Verilog
HDL syntax." I believe that should be "extensions to IEEE Std 1800-2009
SystemVerilog syntax".
7. Item 7 says, "If the name of any category starts with an italicized part, it
is equivalent to the category name without the italicized part. The italicized
part is intended to convey some semantic information. For example,
msb_constant_expression and lsb_constant_expression are equivalent to
constant_expression, and node_identifier is an identifier which is used to
identify (declare or reference) a node."
That text is old. SV-2009 does not use that form of partly-italicized name.
Instead, SV-200 says, "A <i>qualified term</i> in the syntax is a term such as
<i>array_identifier</i> for which the "array" portion represents some semantic
intent and the "identifier" term indicates that the qualified term reduces to
the "identifier" term in the syntax. The syntax does not completely define the
semantics of such qualified terms; for example while an identifier which would
qualify semantically as an array_identifier is created by a declaration, such
declaration forms are not explicitly described using <i>array_identifier</i> in
the syntax."
-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Apr 5 12:45:17 2011
This archive was generated by hypermail 2.1.8 : Tue Apr 05 2011 - 12:45:28 PDT