Mantis 1348

Statement labels

In Section 9.3.5

CHANGE

9.3.5 Block names versus statement labels

The block name is specified after the begin or fork keyword, preceded by a colon. For example:

begin : blockA // named block

...

end

A named block is used to identify the entire statement block. A named block creates a new hierarchy scope.

A label can be specified before any statement, as in C. A statement label is used to identify a single statement.

The label name is specified before the statement, followed by a colon.

labelA: statement

A begin–end or fork–join- block is considered a statement, and can have a statement label before the block.

labelB: fork // label before the begin or fork

...

join_none : labelB

It shall be illegal to have both a label before a begin or fork and a block name after the begin or fork. A label cannot appear before the end, join, join_any, or join_none, as these keywords do not form a statement.

A statement with a label can be disabled using a disable statement. Disabling a statement shall have the same behavior as disabling a named block. See 9.6 on disable statements and process control.

TO

9.3.5 Block names versus statement labels

The block name is specified after the begin or fork keyword, preceded by a colon. For example:

begin : blockA // named block

...

end

A named block is used to identify the entire statement block. A named block creates a new hierarchy scope.

A label can be specified before any procedural statement (any non-declaration statement that can appear inside a begin-end block), as in C. A statement label is used to identify a single statement.

The label name is specified before the statement, followed by a colon.

labelA: statement

A begin–end or fork–join- block is considered a statement, and can have a statement label before the block. Specifying a statement label before a begin or fork keyword is equivalent to specifying to a block name after the keyword, and a matching block name may be specified after the block end or join keyword. Example:

labelB: fork // label before the begin or fork

...

join_none : labelB

It shall be illegal to have both a label before a begin or fork and a block name after the begin or fork. A label cannot appear before the end, join, join_any, or join_none, as these keywords do not form a statement.

A statement label on a for or foreach loop names the implicit block created by the for or foreach loop. For other types of statements, a statement label creates a named begin-end block around the statement and creates a new hierarchy scope.

A label may also be specified before a generate begin-end block (see 26.3).

A label may also be specified before a concurrent assertion (see 16.4).

A statement with a label can be disabled using a disable statement. Disabling a statement shall have the same behavior as disabling a named block. See 9.6 9.6.2 on disable statements and process control.

In 16.3,

CHANGE

The optional statement label (identifier and colon) creates a named block around the assertion statement (or any other SystemVerilog statement) and can be displayed using the %m format specification.

assert_foo : assert(foo) $display("%m passed"); else $display("%m failed");

TO

The optional statement label (identifier and colon) creates a named block around the assertion statement (or any other SystemVerilog statement) and the hierarchical name of the scope can be displayed using the %m format specification.

assert_foo : assert(foo) $display("%m passed"); else $display("%m failed");

IN 20.2.1.6

CHANGE
20.2.1.6 Hierarchical name format

The %m format specifier does not accept an argument. Instead, it causes the display task to print the hierarchical

name of the module, task, function, or named block that invokes the system task containing the format

specifier. This is useful when there are many instances of the module that calls the system task. One obvious

application is timing check messages in a flip-flop or latch module; the %m format specifier shall pinpoint the

module instance responsible for generating the timing check message.

TO

20.2.1.6 Hierarchical name format

The %m format specifier does not accept an argument. Instead, it causes the display task to print the hierarchical

name of the module design element, task, function, or named block, or labeled statement that invokes the system task containing the format

specifier. This is useful when there are many instances of the module that calls the system task. One obvious

application is timing check messages in a flip-flop or latch module; the %m format specifier shall pinpoint pinpoints the

module instance responsible for generating the timing check message.