[sv-bc] Proposed changes for 1800-2008 Draft 3

From: Maidment, Matthew R <matthew.r.maidment_at_.....>
Date: Thu Apr 19 2007 - 12:34:38 PDT
Below are the proposed changes to be included in Draft 3 of 1800-2008.
Please review.  I'll send a follow-up email with a more concise ballot.


--- SB1-1-1 ---------------

1.2: Delete "Informative delay model for SDF".

--- SB1-1-2 ---------------

1.4: Delete "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_index" and "lsb_index" are equivalent to "index." It
applies only in the VCD file syntax description, which is not part of
Annex A anyway.

--- SB1-1-3 ---------------

1.6: "Clause 25 describes user-defined packages, compilation units
($unit), and built-in packages.": $unit is described in 3.8.1.

--- SB1-1-4 ---------------

1.6: "Annex G (normative) describes the SystemVerilog standard packages,
containing type definitions for mailbox, semaphore, randomize, and
process." -> should be "package". Only one package, Std, is described.

--- SB1-1-5 ---------------

1.8: Delete 'several' in "Several small SystemVerilog code examples are
shown throughout this standard.": 'several' sounds like just a few. It
is probably several hundred.

--- SB1-2-1 ---------------

In the Normative References (Clause 2):

IEEE Std 1364(tm), IEEE Standard for Verilog(r) Hardware Description
Language.
IEEE Std 1364(tm)-2005, IEEE Standard for Verilog Hardware Description
Language.
IEEE Std 1364(tm)-2001, IEEE Standard for Verilog Hardware Description
Language.
IEEE Std 1800(tm), IEEE Standard for SystemVerilog-Unified Hardware
Design, Specification, and Verification Language.
IEEE Std 1800(tm)-2005, IEEE Standard for SystemVerilog-Unified Hardware
Design, Specification, and Verification Language.

Delete the references to 1364 and 1800 without years. Delete 1364-2001
or move it before 1364-2005.

--- SB1-3-1 ---------------

3.7: Delete "A list of building block instances is referred to as a
netlist." This is too big a generalization of the term netlist, and it
is not used elsewhere except in one example in 3.7 where it is really is
a gate-level description.

--- SB1-3-2 ---------------

3.7: That same example contains the line: "not g1(sel_n, a, sel);". That
looks like a mistake. A not gate has one input and one or more outputs,
and a is an input to the module. Change to "not g1(sel_n, sel);".

--- SB1-3-3 ---------------

3.1: "A design element is a SystemVerilog module (see Clause 22),
program (see Clause 22), interface (see Clause 24), package (see Clause
25), primitive (see Clause 27) or configuration (see Clause 31)." - If
config is a design element, then it needs an overview description in
clause 3.

--- SB1-5-1 ---------------

5.1: Change "- String" to "String literal".

 

--- SB1-5-2 ---------------

In 5.6.1, "The use of x and z in defining the value of a number is case
insensitive," z should not be blue or underlined.

--- SB1-5-3 ---------------

5.7 (Simulation time units and precision) is out of place in a clause on
lexical conventions. Presumably, it was placed here because 5.8 is Time
literals, to define time beforehand. That is not good enough
justification. Move 5.7 to clause 4 (Scheduling semantics), since
scheduling and time are related.

 

--- SB1-5-4 ---------------

5.9 starts, 'A string literal is a sequence of characters enclosed by
double quotes ("").' The next sentence starts, "A string literal is
enclosed in quotes...," which is duplication. Delete the second phrase.

--- SB1-5-5 ---------------

In Table 5-1, change "b\a" to "\a".

 

--- SB1-5-6 ---------------

Delete "NOTE-the special string characters \v, \f, \a and \x were added
in IEEE 1800-2005" following Table 5-1. No need for it.

 

--- SB1-6-1 ---------------

6.1 is called Value set, but its introductory paragraph is important
enough and different enough (it does not talk about value sets), that it
should be a separate sub-section 6.1 called "Data objects and data
types", with "Value set" being 6.2.

--- SB1-6-2 ---------------

6.2: "A singular variable or expression represents a single value,
symbols, or handle." -> "symbol".

 

--- SB1-6-3 ---------------

6.14 and 7.6 both describe strings. Merge them or have only a
two-sentence paragraph in 6.14 as done with classes in 6.13.

--- SB1-7-1 ---------------

In Clause 7, delete the first sentence, "This clause defines structures,
unions and arrays, which can represent aggregate collections of data."
It duplicates the following paragraph.

 

--- SB1-7-2 ---------------

7.1.1.1 brings me to say that I dislike going down to 4th level
sub-clauses if it can be avoided. Change the following structure:

 

7.1 Structures and unions

  7.1.1 Structures

  7.1.2 Unions

 

to simply

 

7.1 Structures

7.2 Unions

 

--- SB1-10-1 ---------------

10.5.1: Stu asked:

Does the result of a continuous assignment to a variable update
immediately when the variable is released? It should, in order to be
consistent with the behavior of continuous assignments. 

 

--- SB1-10-2 ---------------

A better place for 10.7 (Assignment Patterns) is in clause 7 (structures
and arrays).

 

--- SB1-11-1 ---------------

11.2.7: Define here the new term "procedural assignment operator", which
Stu has invented and used in 10.3 and 10.3.1.

 

--- SB1-11-2 ---------------

11.2.18: "If cond_predicate is true, the operator returns the first
expression; if false, it returns the second expression." Brad wrote,
"Actually, it evaluates an expression and returns its value."

 

--- SB1-11-3 ---------------

11.2.18: "If the lengths of the first and second expression are
different, the shorter operand shall be lengthened to match the longer
and zero-filled from the left (the high-order end)," Stu asked, "Is the
shorter operand always zero extended, or can it be sign extended?" It
can be sign-extended, see Mantis 1004.

 

--- SB1-11-4 ---------------

11.6.1 (String literal expressions) should not be a subsection of 11.6
(Tagged union expressions). Make it 11.7.

--- SB1-12-1 ---------------

Move 12.7 (Named blocks and statement labels) into 9.2 (Block
statements).

--- SB1-16-1 ---------------

Move 16.15 (Binding) to the clause on hierarchies.

 

--- SB1-19-1 ---------------

Merge 19.4 (Display tasks) and 19.17 (Enhancements to Verilog system
tasks) into Clause 20 (I/O).

--- SB1-19-2 ---------------

19.9: Change "$atan2(x,y) atan2(x,y) Arc-tangent of x/y" to "$atan2(y,x)
atan2(y,x) Arc-tangent of y/x", to be as in C standard.

 

--- SB1-20-1 ---------------

Move 20.4 ($sdf_annotate) into Clause 33 (SDF).

--- SB1-20-2 ---------------

20.5.2.3: Change "In the $var section, a net of net type uwire shall
have a variable type of wire." to "In the $var section, a net of type
uwire shall have a var_type of wire."

 

--- SB1-21-1 ---------------

21.12: Add 1800-2008 as a version_specifier and add appropriate text.
Note that there is no need to have duplicate tables in 21.12 and in
Annex B. For the keyword set of the current version of the LRM, it can
just point to Annex B.

 

--- SB1-21-2 ---------------

21.4.1: Change "Once a text macro name has been defined, it can be used
anywhere in a source description; that is, there are no scope
restrictions." to "Once a text macro name has been defined, it can be
used anywhere in the compilation unit where it is defined. There are no
other scope restrictions once inside the compilation unit."

 

--- SB1-21-3 ---------------

21.4.1: "The text specified for macro text shall not be split across the
following lexical tokens: ... - Strings" -> "String literals".

 

--- SB1-22-1 ---------------

22.1: "A module can represent functional and timing at a very detailed
level" -> "function".

 

--- SB1-22-2 ---------------

22.1.1: Change "The port directions and sizes of the module" to "The
direction and size of each port".

 

--- SB1-22-3 ---------------

22.1.3: Change "The parameter type of parameters can be redefined for
each instance of a module" to "Parameter types can be redefined for each
instance of a module".

 

--- SB1-22-4 ---------------

22.2: "Top-level modules are implicitly instantiated (see 22.2.1)."
needs to say that the implicit instance name is the same as the module
name.

 

 --- SB1-25-1 ---------------

Move 25.1.1 (Built-in package) to the end of Clause 25 (Packages). Make
it a 2nd-level sub-clause instead of a 3rd-level sub-clause. Add xref
from 17.11 to it. 

 

--- SB1-25-2---------------

25.1.1 says that std "contains system types (e.g., classes), variables,
tasks, and functions." Actually, it only contains classes and a
function.  

 

--- SB1-25-3 ---------------

Add xrefs between 25.1.1 and Annex G.

 

--- SB1-27-1 ---------------

27.1.5-6 discuss arrays of instances. Move into 22.2 (earlier than
22.2.3), as it is applicable to all kinds of modules (and interfaces). 

 

--- SB1-33-1 ---------------

Move Clause 33 (SDF) to after clause 30 (Timing checks).

 

SB-O-1. 3.7 and 22.2.1  define "top-level module" slightly differently.

 

SB-O-2. 3.1: "A design element is a SystemVerilog module (see Clause
22), program (see Clause 22), interface (see Clause 24), package (see
Clause 25), primitive (see Clause 27) or configuration (see Clause 31)."
- 31.1 insists that a configuration is a design element, but almost of
all the uses of the term within the LRM, most of which relate to
timescales, are not relevant to configs. 

SB-O-3. 3.2 lists among the constructs modules can contain: "procedural
blocks", where the reference is to always, initial, etc.
procedures/constructs. Re the discussion about what to call these
constructs, there are a number of places, such as here, where the term
'procedural block' is used, and it will be either awkward or unclear to
just say 'procedure'.

SB-O-4. String literals are discussed in 5.9 and 11.6.1. Beyond the
basic definition of a string literal, the discussion of what you can do
with them is split up between these two sections roughly evenly, with
some duplication and overlap. The two sections should be unified, or 5.9
should be just a minimal definition of string literals, with all further
discussion in 11.6.1.

SB-O-5. The discussions of string literals and string types should be
much closer to each other, since they are so closely related.

SB-O-6. 'Nonprinting and other special characters are preceded with a
backslash.': Does this mean that it is allowed to enter a nonprinting
character directly (preceded by a backslash)? What is included in 'other
special characters'? Is the intent of both of these only those
characters in Table 5-1? What about other special characters?

SB-O-7. Clause 6 is Data Types. 6.1 starts off nicely with
"SystemVerilog makes a distinction between an object and its data type,
etc." However, later on, the LRM blurs this distinction in terminology
between objects and types. 6.3 is bad in particular, saying "There are
two main groups of data types: the variable data types and the net data
types."  The term 'net data type' only appears 3 times, but 'net type'
appears many times. I think we should be consistent and change most of
the references to them to be 'net objects' or simply 'nets'. Same for
'variable data types' and 'variable types'.

SB-O-8. 10.7 Assignment Patterns: Combine with 5.10-11 Structure and
Array literals

SB-O-9. The term 'assignment operator' is not used consistently in the
LRM. It is used sometimes to refer to an entire set of operators, and
sometimes to refer specifically to '='.

SB-O-10. 22.2.3.5 should separate the discussions of unpacked array
ports and arrays of instances. The discussion of arrays of instances
there should be combined with the general discussion of port connections
to arrays of instances.

SB-O-11. 35 ("Programming language interface (PLI and VPI) overview"):
On the one hand, VPI is treated as one generation of PLI, e.g., "Verilog
procedural interface routines, called VPI routines, are the third
generation of the PLI," i.e., as being included in the term 'PLI'. On
the other hand, it is also treated separately, as in the title of clause
35, "PLI and VPI". This seems inconsistent and confusing. 

--- SB2-6-9-1---------------

In 6.9.1, para. 2, "table Table" -> "Table".

--- BP1-5-1 ---------------

In 5.8, undelete the Note. And as described in the 03-07-07 bugnote of

http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000700
<http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000700> 

change "Greek letter m" to use a Greek letter mu instead of a Latin 'm',

and in "properly ms", change the Latin 'm' before 's' to a Greek mu. 

 

--- BP1-5-2 ----------------

In 5.5.4 replace

"The affects of a compiler directive is limited to a compilation unit

(see 3.8.1) and shall not affect other compilation units."

with

"The effects of a compiler directive are limited to a compilation

unit

(see 3.8.1) and shall not affect other compilation units."

 

--- BP1-5-3 ----------------

In 5.9, in "A string literal can be assigned to an integral type",

replace "type" with "data object".

 

--- BP1-5-4 ----------------

In 5.9, REPLACE

"The rules of SystemVerilog assignments shall be followed if the

packed

array width is does not match the number of characters multiplied by

8."

WITH

"The rules of SystemVerilog assignments shall be followed if the size

of the data object is not the number of characters multiplied by 8."

--- BP1-5-5 ----------------

In 5.9, in "When integral type is larger than required",

replace "integral type" with "the integral data object".

 

 

--- BP1-5-6 ----------------

In 5.9, replace ".padded" with "padded".

 

 

--- BP1-5-7 ----------------

In 5.9, in "larger than the destination integral type",

replace "type" with "data object".

 

--- BP1-5-8 ----------------

In 5.9, replace

"String literals stored in vectors" 

with

"String literals stored in integral data objects"

 

--- BP1-6-1 ----------------

In 6.6.1, remove the italics from "the" in "the msb" and from

"specified by the" in "specified by the lsb".

 

--- BP1-6-2 ----------------

After Table 6-8, remove

"Note-The 1364-2005 standard only had the reg, integer and time

integer variables."

 

--- BP1-6-3 ----------------

In 6.10, replace

"These three types are collectively referred to as real variables."

with

"Variables of these three types are collectively referred to as

real variables."

--- BP1-6-4 ----------------

In 6.13, in

"A class variable is a dynamic data type that

can hold a handle to a class object. "

remove

"is a dynamic data type that"

 

--- BP1-6-5 ----------------

As explained in

http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000507
<http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000507> 

In 6.18.3, change "non local" to "nonlocal".

 

--- BP1-6-6 ----------------

In 6.20.2, remove the editorial question about the Note, which is

correctly only a note because there is already normative text saying

"If all data types within a packed structure are 2-state,

the structure as a whole is treated as a 2-state vector. If any data

type within a packed structure is 4-state, the structure as a whole is

treated as a 4-state vector. If there are also 2-state members in the

structure, there is an implicit conversion from 4-state to 2-state when

reading those members and from 2-state to 4-state when writing them."

 

--- BP1-7-1 ----------------

In 7.2.4, replace

"Each packed dimension in the array is known as a memory element

or word"

With

"An element of the fastest-varying unpacked dimension in the

array is known as a memory element or word"

 

--- BP1-7-2 ----------------

In 7.2.1, in "A vector (see 6.6) is a a one-dimensional packed array",

change "a a" to "a".

 

--- BP1-7-3 ----------------

In Table 7-2, remove the "in" in "replication in".

--- BP1-7-4 ----------------

In 7.1.1, because of the issues in 

http://www.eda-stds.org/sv-bc/hm/5780.html
<http://www.eda-stds.org/sv-bc/hm/5780.html>  

remove 

"A structure represents a collection of variable types that can

be referenced using the structure name. By default, structures are

unpacked, meaning that there is no defined representation on how

each variable in the collection is stored. Unpacked structures

can contain any variable data type."

 

--- BP1-8-1 ----------------

In 8.1, in "Class instances, or objects, can be passed around via object

handles, which provide a safe-pointer capability in the language" remove

"in the language".

--- BP1-9-1 ----------------

In 9.1, replace

"The initial procedure shall execute only once, and its activity

shall cease when the statement has finished. In contrast, the

always procedures shall execute repeatedly. Its activity shall

cease only when the simulation is terminated."

with

"An initial procedure shall execute only once, and its activity

shall cease when the statement has finished. In contrast, an always

procedure shall execute repeatedly, and its activity shall cease

only when the simulation is terminated."

 

--- BP1-9-2 ----------------

In 9.1.3, in "All final procedure shall execute in an arbitrary order"

replace "procedure" with "procedures".

 

--- BP1-9-3 ----------------

In 9.2, in "The procedural statements in sequential block shall be

executed sequentially in the given order" replace "in sequential"

with "in a sequential".

 

--- BP1-9-4 ----------------

In 9.2, in "The procedural statements in parallel block shall be

executed concurrently" replace "in parallel" with "in a parallel".

 

-- BP1-10-1 ----------------

In 10.2.2, in "or module output,." remove the comma.

 

-- BP1-10-2 ----------------

In 10.3, replace 

"variable type on left-hand side"

with 

"variable type on the left-hand side"

 

-- BP1-10-3 ----------------

In 10.4, remove the sentence

"Variable declaration assignments are only allowed

at the module level."

 

-- BP1-11-1 ----------------

In Table 11-1, remove "C-like".

 

-- BP1-12-1 ----------------

In 12.2, remove the sentence

"Pessimism reduction can also be done using unique-case priority-case

(see 12.3.3)."

 

-- BP1-12-2----------------

In 12.5.1, in "The variable used to control a for-loop can be declared

prior to the loop", replace "variable" with "variables".

 

-- BP1-12-3 ---------------

In 12.5.1, in "The variable used to control a for-loop can also be

declared within the for-loop", replace "variable" with "variables".

 

-- BP1-12-4 ----------------

In 12.5.1, in "The variable used to control a for-loop can also be

declared within the for-loop", replace the second "for-loop" with

"loop".

 

-- BP1-12-5 ----------------

In 12.7, replace "can have name specified" with "can have a name

specified".

 

-- BP1-13-1 ----------------

In 13.1, remove the sentence

"A function shall have at least one input type argument"

and remove the editorial question in the margin.

 

-- BP1-13-2 ----------------

In 13.1, in "A function nonvoid function" remove the first "function".

 

-- BP1-13-3 ----------------

In 13.3, replace 

"A function declaration can include an optional function_data_type

or packed_dimension range, which shall specify the type or size

of value returned by the function. A function specified without a

function_data_type or packed_dimension defaults to a scalar logic

for the return value. If a packed_dimension is specified, the

function shall return a packed array of type logic."

with

"To indicate the return type of a function, its declaration can

either include

an explicit function_data_type or use an implicit syntax that

indicates

only the ranges of the packed dimensions and, optionally, the

signedness.

When the implicit syntax is used, the return type is the same as if

the

implict syntax had been immediately preceded by the logic keyword."

 

-- BP1-13-4 ----------------

In 13.3.3, in "These items shall be shared across all uses of the task

executing concurrently" replace "task" with "function".

 

-- BP1-13-5 ----------------

In 13.3.3, in "Functions can defined to use static storage by explicitly

defining

the task as static" replace "can defined" with "can be defined" and

replace "task"

with "function".

 

-- BP1-13-6 ----------------

In 13.4, replace "listed of the call" with "listed in the call".

-- BP1-13-7 ----------------

In 13.4.4, in "The fun function", the "fun" should be in a monospaced

font.

 

-- BP1-22-1 ----------------

In 22, in "The formal syntax for a module definitions", replace

"definitions"

with "definition".

 

-- BP1-22-2 ----------------

In 22.1, in "or and entire complex digital system", replace "and"

with "an".

 

-- BP1-22-3 ----------------

In 22.2, replace 

"A module can be used (instantiated) in two ways"

with

"A module can be instantiated in two ways"

 

-- BP1-22-4 ----------------

In 22.2.2, in "is used illustrate", replaced "used" with "used to".

 

-- BP1-22-5 ----------------

In 22.2.2.2, replace

"The following example instantiations of a module call A is illegal"

with 

"The following example instantiations are illegal"

--- BP1-A-1 ----------------

Fix the BNF according to the proposal in 

http://www.eda-stds.org/sv-bc/hm/5779.html
<http://www.eda-stds.org/sv-bc/hm/5779.html> 

MH-1) 7.1.1:

 

A structure represents a collection of variable data types that can be
referenced using the structure name as a whole or the individual data
types that make up the structure can be referenced by name. By default,
structures are unpacked, meaning that there is no defined representation
on how each variable in the collection is stored an
implementation-dependent packing of the data types. Unpacked structures
can contain any variable data type.

 

MH-2) 7.1.2:

 

A union is a data type that represents a single piece of storage which
can store one of any variable type which can be accessed using one of
the named member data types. Only one variable type can be in a union at
one time of the data types in the union can be used at a time. By
default, a union is unpacked, meaning there is no required
representation for how members of the union are stored. Dynamic types
and chandle types can only be used in tagged unions.

 

MH-3) In 7.6.10:

 

Change:

 

The conversion parses Verilog syntax for real constants.

 

TO:

 

The conversion parses Verilog syntax for real constants.

 



--
Matt Maidment
mmaidmen@ichips.intel.com
  


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 19 12:35:35 2007

This archive was generated by hypermail 2.1.8 : Thu Apr 19 2007 - 12:36:08 PDT