SV-BC LRM Issues:

LRM-15

SV-EC/SV-BC

11.22

Editor’s Note: Verilog syntax is "int static". Is the "static int" above correct? NOTE: The Co-design SystemSim simulator allows both forms. I submitted a request to the BC committee to clarify if SystemVerilog was intended to also allow both forms. I do not know the result of that request.

Open

We will use “int static” and change the example (should not use “static int”)

LRM-26

SV-BC

18.8.3

See Section XX for more port connection rules with interfaces.
Editor’s Note: What is the cross reference for above?

This was pushed to LRM 3.2, so it is a reference to non existing section.

The recommendation is to delete this sentence.

LRM-46

SV-BC

A.1.6

extern_tf_declaration ::=
extern method_prototype
| extern forkjoin task named_task_proto ;
Editor’s Note: The added syntax added just for interface items may be better combined with the DPI import, but
that is allowed anywhere a function may be declared... The BC should take a look at the DPI import/export to
make sure these make sense... The dpi_import_export is in A.2.6

Dan Jacobi took the action item to check this issue and come up w/ a fix or update for the BNF (while communicating w/ Stefen Boyd)

LRM-48

SV-BC

A.2.2.1

non_integer_type ::= time | shortreal | real | realtime | $built-in
Editor’s Note: Why isn’t $built-in mentioned in the text? What is it? Remove? Should be bold?

$builtin is a short hand any time of a builtin system task (this was inherited from superlog), like system function.

It was decided to remove $builtin

LRM-49

SV-BC

A2.2.1

Editor’s Note: Singular is listed as anything but unpacked structs, unpacked arrays, and handle type. Either the
text should simply let the singular_type bnf explain or should deal with other exceptions: union, void, dynamic
arrays

SV-EC has added this. They split the packed and unpacked unions.

Therefore, we are moving this issues back to EC.

LRM-50

SV-BC

A.2.2.1

Editor’s Note: Enum here suggests that we can have ports:
input enum { a, b, c} myin;
Is this a problem (considering the semi-strong typing introduced in 3.1 for enum)?

It is not possible to declare the enum in the port.

It was decided that no change should be done here. Instead, add semantics check to make sure that ports can not be enums.

LRM-51

SV-BC

A.2.2.1

Editor’s Note: String and event assignment restrictions not part of bnf productions (semantic only)

Should be moved back to EC, because string was added by EC

LRM-52

SV-BC

A.2.6

Editor’s Note: Enum here suggests that we can have return values:
function enum { a, b, c} myfunc;
Is this a problem (considering the semi-strong typing introduced in 3.1 for enum)?

Remove enum from the function data type, while keeping the struct and the union.

Leave the way it is. We’ll do semantics check.

LRM-53

SV-BC

A.2.6

Editor’s Note: Why eliminate [ signing ] from this production and then add note? The note will constantly need
updating due to new types (e.g. string) and function prototypes won’t be allowed to be signed. Better to make
“function_data_type ::= data_type | handle |void” and move the “[ signing ]” from function_declaration to the first
line of range_or_type.

The reason we voted for splitting this rule was the location of the signing which should go before the data type and after the function keyword.

Recommendation: keep this BNF.

LRM-54

SV-BC

A.2.6

Editor’s Note: Since [ signing ] was removed from function_data_type, we can’t have a signed prototype?

Dan suggested adding the signing. All agreed. Dan will send the new BNF

LRM-55

SV-BC

A.2.7

Editor’s Note: Looks like the new definition disallows “output signed [3:0] foo” (same for inout). I took the liberty
of adding it.

It looks OK, but it should be moved back to EC because it was changed by them.

LRM-56

SV-BC

A.6.1

Editor’s Note: I used expression since that is what is used in module instance ports. Dispite the style of showing
semantics in the BNF, I’m following the style of ports of module instances. One restriction that is not clear in the
text is that the bit and part selects of nets in an alias must be constant (i.e. can’t use [expression +: constant])

Alias was pushed by SV-EC, therefore this issue should be moved back to them

LRM-57

SV-BC

A.8.3

Editor’s Note: This change collided with BC19-44. I left variable_lvalue alone since it now does what variable_lvalue_item used to do.

The BNF is OKAY. The editor note should be dropped. Dan has already communicated this to Stefen Boyd.

LRM-58

SV-BC

A.8.4

Editor’s Note: The general syntax for making a function call to a method is given here. I do not list all the possible
methods for each type. As is done with system tasks and functions, these will have BNF descriptions that are separate
from Annex A.

[ . method_identifier { attribute_instance } [ ( expression { , expression } ) ] ]

This note refers to the changes which were specifically done by SV-EC. The issue should be moved back to SV-EC.

LRM-59	SV-BC	A.9.3	Editor’s Note: This isn’t referenced by any other production. Remove? Add reference somewhere?	Open
LRM-60	SV-BC	A.9.3	Editor’s Note: Looks like this is left over from state machine syntax that didn’t make it into 3.0	Open
LRM-61	SV-BC	A.9.3	Editor’s Note: This isn’t referenced by any other production. Remove? Add reference somewhere?

Dan recommends that we remove the real identifier and the state identifier. All agreed.

The text_macro_identifier should be kept as is.

LRM 3.1 Draft 4.0 Review Assignments:

Chapters 1, 14, 15 è Cliff Cummings

Chapter 12 è Brad Pierce

12.1, "object oriented framework"--"object-oriented framework"

12.2, "`2b0"--"'2b0"

12.2, EC-CH114, "endtask"--""

12.4, "the system task constraint_mode()"--"the built-in constraint_mode()

method"

12.4, Why aren't constant functions allowed in constraint expressions?

12.4.4, 2nd limitation, "expression" should be italicized?

12.4.8, "all combinations of values"--"all legal combinations of values",

"all value combinations are equally probable"--"all legal value

combinations are equally probable". Or how about just saying "all

solutions" in this paragraph.

12.4.8, "provide a mechanism for order variables"--"provide a mechanism for

ordering variables"

12.4.8, "chosen independent of d"--"chosen independently of d"

12.4.8, last restriction, This is not a restriction and is just restating

the conceptual distinction between a specification and an implementation.

It's not really necessary, but if it's included it should just be a

paragraph, not a "restriction".

12.5.3, third bullet, "fails post_randomize()"--"fails, post_randomize()"

12.9, 2nd bullet, "the constraint_mode() system task"--"the built-in

constraint_mode() method"

12.9, 3rd bullet, "the rand_mode() system task"--"the built-in rand_mode()

method"

12.10.1, "determines which random number"--"determines which sequence of

random numbers"

12.10.1, "generates the same number"--"generates the same sequence of

numbers"

12.11.1, 1st bullet, "hierarchical seeding" should be in italics instead of

quotation marks

12.11.2, last sentence seems oddly phrased

12.12, 1st par., last sentence, "hierarchical object seeding" should be

italicized

Throughout, "sub-tree"--"subtree", "bi-directional"--"bidirectional"

BNF, Annex A, B è Dan Jacobi

Review for System-Verilog 3.1 Draft 4

Annex A and Annex B

Flowing are my review notes for Annexes A and B of the System-Verilog 3.1 draft 4. my notes refer to changes added to the standard by ALL the System-Verilog sub-committees.

The comments related to the Keywords in Annex B are labeled as DJ-AB-<id these are easy issues that could be added to the final publication. The comments related to the BNF in Annex A are labeled as DJ-AA-<id some of these issues are more complex.

Annex A – BNF

DJ-AA-1. No BNF for the data-type chandle. This data-type is described under section 3.7.

DJ-AA-2. No BNF for final blocks. These blocks are described under section 8.6.

DJ-AA-3. No BNF for the keyword local. This keyword is described under section 11.16.

DJ-AA-4. No BNF for the keyword super. This keyword is described under section 11.13.

DJ-AA-5. No BNF for the keyword this. This keyword is described under section 11.9.

DJ-AA-6. The following production:

constraint_item ::=

constraint_expression ;

| constraint_expression = constraint_item_or_block

| if ( constraint_expression ) constraint_item_or_block [ else constraint_item_or_block ]

Causes a problem known as “The dangling if-else ambiguity”

The ‘else’ in the following constraint item can be matched to both ‘if’s”

if (mode != large)

if (mode == small)

len < 10;

else // Does the else apply to if (mode != large) or if (mode == small)

len 100;

The following langadge should be added to section 12.4.6 (this is similar to the language describing the if-else statements in the IEEE 1364-2001).

Because the else part of an if-else style constraint declarations is optional, there can be confusion when an else is omitted from a nested if sequence. This is resolved by always associating the else with the closest previous if that lacks an else. In the example below, the else goes with the inner if, as shown by indentation:

if (mode != large)

if (mode == small)

len < 10;

else // else applies to preceding if

len 100;

DJ-AA-7. Remove the second editors note from A.2.6 – the signing can be added before the function’s data type (After the function/automatic keyword).

DJ-AA-8. Under A.2.6 REPLACE

named_function_proto::= function_data_type function_identifier (

list_of_function_proto_formals )

WITH

named_function_proto::= [ signing ] function_data_type function_identifier (

list_of_function_proto_formals )

And remove the third editors note regarding the signed function prototype.

DJ-AA-9. Remove the Editors note from A.8.3 the current BNF reflects the changes accepted by the SV-BC.

DJ-AA-10. Under A.9.3 Remove the production:

real_identifier ::= identifier

And remove the following editors note. The real_identifier is a “left over” from the IEEE 1364 standard.

DJ-AA-11. Under A.9.3 Remove the production:

state_identifier ::= identifier

And remove the following editors note.

DJ-AA-12. Do not remove the production:

text_macro_identifier ::= identifier

Remove the following editor’s note. The text_macro_identifier token is referenced from with-in the IEEE 1364-2001 (section 19.3.1) even though it is not referenced from the 1364 BNF. Removing this production will cause miss-consistency with the 1364 standards.

DJ-AA-13. BNF for more than one initial statement and more than one-step assignment with in a for loop is missing. Currently the BNF for the following for loop statement is missing:

for (a=1,b=2 ; a<10 & b<200 ; a=a+1,b=b*2) …

DJ-AA-14. Under A.6.3 the following production is problematic

action_block ::= [ statement ] [ else statement ] ;

The following assertion statement can be interpreted in more than one way:

assert (cond) if (cond2) a = 1; else a = 2;;

One-way to parse this statement - If the assertion succeeds (cond == true) evaluate the if-else conditional statement.

The other way to parse this statement is – If the assertion succeeds (cond == true) and if cond2 is true than assign ‘a’ with the value 1. If the assertion fails then assign ‘a’ with the value 2.

Some language needs to be added chapter 17 that deals with this case and with more complicated cases such as nested assertion and nested conditional if-else statements and the nesting of assertions in if-else statements and vise-versa for example how should the following RTL be parsed “

always

if (c1) assert (c2); else assert(c3); else if (c4) a =1; else a = 2;; else a=3;;;;;;;;

DJ-AA-15. Under A.2.10 the following production has a loop:

sequence_expr ::=

[ cycle_delay_range ] sequence_expr { cycle_delay_range sequence_expr }

…

The token sequence_expr can parse itself I would recommend the following change to the begging of the sequence_expr production

sequence_expr ::=

~~[ cycle_delay_range~~ ~~] sequence_expr { cycle_delay_range sequence_expr }~~

cycle_delay_range sequence_expr { cycle_delay_range sequence_expr }

| sequence_expr cycle_delay_range sequence_expr

{ cycle_delay_range sequence_expr }

…

DJ-AA-16. Under A.2.10 the prentices of the sequence_expr production should be in bold.

REPLACE

sequence_expr ::=

…

| ( sequence_expr ) [ sequence_abbrev ]

…

WITH

sequence_expr ::=

…

| ( sequence_expr ) [ sequence_abbrev ]

…

DJ-AA-17. Precedence for the operators added by the sequence_expr production under A.2.10 should be added to section. The precedence for the and, intersect, or, first_match, throughout, and within operators is not defined.

The following sequence expression :

d1 intersect d2 within d2

Can be parsed in two ways:

(d1 intersect d2) within d2

d1 intersect (d2 within d2)

DJ-AA-18. Under A.2.10 the production sequence_expr causes a problem when adding a prentices around an expression that relates from the primary production.

In the following example:

d1 within (d2 & d3)

The prentices may be parsed using the primary production

(primary :: = ( mintypmax_expression ) ) or using the sequence_expr production (sequence_expr ::= ( sequence_expr ) [ sequence_abbrev ] )

DJ-AA-19. Under A.2.9 replace the name of the token const_range_expression to sequence_const_range_expression. The original name causes a confusion with the constant_range_expression token.

Annex B – Keywords

DJ-AB-1. The keyword private does not appear in Annex B even though it appears under the BNF A.1.8.

DJ-AB-2. The keyword handle was removed from Annex B even though it appears under the BNF A.2.6.

DJ-AB-3. The keyword endsequence does not appear in Annex B even though it appears under the BNF A.2.10.

DJ-AB-4. The keyword endproperty does not appear in Annex B even though it appears under the BNF A.2.10.

DJ-AB-5. The keyword randomize does not appear in Annex B even though it appears under the BNF A.6.2.

DJ-AB-6. Should the sequence “DPI” be marked as a keyword? It appears under the BNF A.2.6.

Chapters 2, 3, 4, 5, 7 è Dave Rich

Chapters 11, 13 è Francoise Martinolle

Chapter 16 è Karen

In 16.1 item 3, I would reword the item to use "syntactic" rather than

"syntactical." Both are in the dictionary and mean the same thing, but

when I showed it to several people, they all stumbled over the use of

syntactical there and thought it should be syntactic.

In the third example, the keyword "module" needs to be in bold.

In the paragraph after the third example, UPD probably needs to be UDP.

In 16.6, $stop needs to be in bold.

Chapter 8 è Dennis

No major issues found. The minor changes are the 8 following. I also have attached a mark-up of Draft 4 Section 8 if this helps the editor.

p. 58 Second to last paragraph: Change font for force/release that is Times Roman to the "keyword" font, bold/courier.
p. 60: Change "... hand side, and information may be lost, a ..." to "hand side, information may be lost, and a ..."
p. 60. Paragraph before 8.3: Should "can" be changed to "may?"
p. 61 First example comment: Change "... a error ..." to "... an error ..."
p. 61 Second Paragraph from end of page: Suggest making the last sentence a note. Change: "By specifying a unique ..." to "Note, by specifying a unique ..."
p. 65 Second to last Paragraph: Delete non-LRM language. Change: "... continue for a clean way to break ..." to "... continue to break ..."
p. 66 First paragraph after Syntax 8-7: The X and Z state should be capitalized, not lowercase.
p. 67 OK to editor's notes

Chapter 9 è Matt Maidment

9.1

CHANGE:

In an always block which is used to model combinational logic, forgetting an else

leads to an unintended latch. To avoid this mistake, SystemVerilog adds specialized always_comb and always_latch blocks, which indicate design intent to simulation,

synthesis and formal verification tools. SystemVerilog also adds an always_ff block

to indicate sequential logic.

TO:

In an always block which is used to model combinational logic, forgetting an else

leads to an unintended latch. To avoid this mistake, SystemVerilog adds specialized always_comb and always_latch blocks, which indicate design intent to simulation,

synthesis and formal verification tools. Along with always_latch blocks, SystemVerilog adds always_ff blocks to indicate sequential logic.

-- both latches and flops are sequential circuits

CHANGE:

Execution of each thread may be interrupted between statements at a semicolon, but a single statement (not a block) containing no user task or function call is uninterrupted.

TO:

Execution of each thread may be interrupted between statements at a semicolon, but a single statement (not a block) containing no user task or function call cannot be interrupted.

--symmetry of phrasing

CHANGE:

SystemVerilog 3.1 adds dynamic processes by enhancing the fork...join construct,

in a way that is more natural to Verilog users.

TO:

SystemVerilog 3.1 adds dynamic processes by enhancing the fork...join construct

in a way that is more natural to Verilog users.

--unnecessary comma

9.3

-- What is "latch sensitive?" Latches are level sensitive.

Why not Level-Sensitive Sequential Logic for 9.3, Edge-Sensitive

Sequential Logic for 9.4 and either Combinational Logic or

Level-Sensitive Combinational Logic for 9.2?

9.6

"The fork...join construct provides the primary mechanism for creating concurrent processes."

Aren't always blocks the primary mechanism for creating concurrent processes?

Why not something like...

"The fork...join construct enables the creation of concurrent processes from

each of its parallel statements."

CHANGE:

In Verilog a fork...join block always causes the process executing the fork statement to block until all the forked off processes terminate. SystemVerilog adds the join_any and

join_none keywords that specify when the parent (forking) process resumes execution.

TO:

In Verilog a fork...join block causes the process executing the fork statement to block until the termination of all forked processes. With the addition of the join_any and join_none keywords, SystemVerilog provides three choices for specifying when the

parent (forking) process resumes execution.

-- fork..join also specifies when the parent process resumes execution.

join_any and join_none off 2 additional choices

QUESTION:

In table 9-1, the verb for creating separate processes is "spawn" but

before and after it is fork. I suggest using "fork" in the table

or substiting the verb fork with the verb spawn in the entire chapter.

CHANGE:

In the following example, two processes are forked off,

TO:

In the following example, two processes are forked,

--I believe the off is redundant in "forked off"

CHANGE:

Because the join keyword is specified, the parent process will

block until the two processes complete, that is, 20ns have elapsed

and eventA has been triggered.

TO:

Because the join keyword is specified, the parent process will block until the two processes complete. That is, 20ns have elapsed and eventA has been triggered.

-- New sentence starting with "That is"

CHANGE:

SystemVerilog 3.1 deprecates the process statement, in favor or the fork...join_none form.

TO:

SystemVerilog 3.1 deprecates the process statement in favor of fork...join_none.

9.7

CHANGE:

but a single statement (not a block) containing no user task or function

call shall not be interrupted.

TO:

but a single statement (not a block) containing neither a user task nor a function call shall not be interrupted.

9.8.1

REGARDING:

"In the following example, in the task do_test, the first two processes are spawned and the task blocks until one of the two processes completes (either exec1, or exec2). Next, two more processes are spawned in the background. The wait fork statement will ensure that

the task do_test waits for all four spawned processes to complete before returning to its caller."

--Again there's a switch from fork to spawn. Why not replace spawn with fork?

9.8.2

CHANGE:

static syntactical information

TO:

static, syntactical information

REGARDING:

"Thus, disable will end all processes executing a particular block, whether the processes

were forked by the calling thread or not, while disable fork will end only those processes that were spawned by the calling thread."

--Again we see the intermixing of fork and spawn. Would prefer one or the other

Chapter 10 è Johny