Attendees:

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

The 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.

Dialin Details

Note new times (Friday 03.00am UTC)

San Francisco, Thurs 08.00p
Austin, 10.00p
Boston, 11.00p
Amsterdam, 5.00a (next day)
Tel Aviv, 6.00a
New Delhi, 8:30a
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."

-- DavidMiller - 2011-04-05