Section 22.7

Severity System Tasks

Description

Currently System Verilog does not provide any standard way to specify severity information while printing user-defined general error messages. The Assertion severity system tasks could be used for that purpose, but they are currently only permitted in SVA action blocks. It would be valuable for users if these tasks were allowed anywhere $display is allowed. This will provide an easy and standard way to print info, warning, and error messages from general Verilog code.

 

Suggested Resolution

In Clause 22.7, change:

22.7 Assertion severity Severity system tasks

 

In Table Syntax-22.5, change:

 

assert_severity_task ::=

fatal_message_task

| nonfatal_message_task

 

Table Syntax-22-5, change the table description:

 

Syntax 22-5—Assertion sSeverity system task syntax (not in Annex A)

 

In the body of Clause 22.7, change:

SystemVerilog assertions have has a severity level associated with any assertion failures detected. By default, the severity of an assertion failure is “error”. The severity levels can be specified by including one of the following severity system tasks in the assertion fail statement:

— $fatal shall generate a run-time fatal assertion error, which terminates the simulation with an error code. The first argument passed to $fatal shall be consistent with the corresponding argument to the Verilog $finish system task, which sets the level of diagnostic information reported by the tool. Calling $fatal results in an implicit call to $finish.

— $error shall be a run-time error.

— $warning shall be a run-time warning, which can be suppressed in a tool-specific manner.

— $info shall indicate that the failure carries no specific severity.

All of these severity system tasks shall print a tool-specific message, indicating the severity of the failure, and specific information about the failure, which shall include the following information:

— The file name and line number of the assertion statement

— The hierarchical name of the assertion if it is labeled or the scope of the assertion if it is not labeled.

For simulation tools, these tasks shall also report the simulation run time at which the severity system task is called.

Each of the severity tasks can include optional user-defined information to be reported. The user-defined message shall use the same syntax as the Verilog $display system task and can include any number of arguments.

SystemVerilog provides special text messaging system tasks that can be used to flag various exception conditions. The tasks are defined as follows:

— $fatal shall generate a run-time fatal error, which terminates the simulation with an error code. The first argument passed to $fatal shall be consistent with the corresponding argument to the Verilog $finish system task, which sets the level of diagnostic information reported by the tool. Calling $fatal results in an implicit call to $finish.

— $error shall indicate a run-time error.

— $warning shall indicate a run-time warning, which can be suppressed in a tool-specific manner.

— $info shall indicate that the failure carries no specific severity.

Each of the severity system tasks can include optional user-defined information to be reported. The user-defined message shall use the same syntax as the Verilog $display system task and thus can include any number of arguments.

All of the severity system tasks shall print a tool-specific message, indicating the severity of the exception condition, and specific information about the condition, which shall include the following information:

— The file name and line number of the severity system task call.

— The hierarchical name of the scope in which the severity system task call is made.

— For simulation tools, the simulation run time at which the severity system task is called.

In Clause 17.2, change:

Because the assertion is a statement that something must be true, the failure of an assertion shall have a severity associated with it. By default, the severity of an assertion failure is error. Other severity levels can be specified by including one of the following severity system tasks in the action block: fail statement:

Since the assertion is a statement that something must be true,  the information about assertion failure can be printed using one of the following severity system tasks in the action block.

—      $fatal is a run-time fatal.

—      $error is a run-time error.

—      $warning is a run-time warning, which can be suppressed in a tool-specific manner.

—      $info indicates that the assertion failure carries no specific severity.

 

The syntax for these severity system tasks is shown in 22.7.

 

In Clause 17.2, change:

All of these severity system tasks shall print a tool-specific message indicating the severity of the failure and specific information about the specific failure, which shall include the following information:

— The file name and line number of the assertion statement severity task call.

— The hierarchical name of the assertion, if it is labeled, or the scope of the assertion if it is not labeled. The hierarchical name of the scope in which the severity system task call is made.

In Clause 17.2,  add:

 

The display of messages of warning and information types can be controlled by a tool-specific option, such as a command-line option.

The severity system tasks can also be used in assertion pass statements. These tasks shall print the same tool-specific message when used either in a pass or a fail statement. For example:

assert_foo : assert(foo) $info("passed"); else $error(“failed");

 

 

In Clause 17.13.1, change:

 

The action_block shall not include any concurrent assert, assume, or cover statement. The action_block, however, can contain immediate assertion statements.

 

The conventions regarding default severity (error) and the use of severity system tasks in concurrent assertion action blocks shall be the same as those specified for immediate assertions in 17.2.

 

The pass and fail statements of an assert statement are executed in the Reactive region. The regions of execution are explained in the scheduling semantics in Clause 9.