RE: [sv-ac] Updated proposal for 1641 (severity system tasks)

Hi Yaniv,
 
This section is about immediate assertions that is why the example is of
immediate assert.
 
Manisha

________________________________

From: Fais Yaniv [mailto:yaniv.fais@freescale.com] 
Sent: Sunday, March 11, 2007 6:13 AM
To: Kulshrestha, Manisha
Cc: sv-ac@eda-stds.org
Subject: Re: [sv-ac] Updated proposal for 1641 (severity system tasks)


Hi Manisha,

In clause 17.2:

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

should be changed to 

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

Thanks,
Yaniv


Kulshrestha, Manisha wrote: 

	Hi,
	 
	I have updated a proposal based on the discussion in the
meeting. This proposal does not distinguish usage of these tasks in
assertion vs. regular sequential code. All the information is printed
based on where the severity task is called.
	 
	Please send your feedback.
	 
	As we discussed in the meeting how a user can print information
about assertion from these tasks if the task is not directly inside
action block. Here is an example about how a task can be called from an
action block and print the error messages. I did not find any standard
way for these tasks to print file name and line number of the assertion
statement (although there are tool specific ways to do that). Hopefully
in future it will be possible in System Verilog itself. Here is an
example:
	 
	module test;
	 
	reg clk;
	reg a;
	reg [127:0] name;
	 
	initial
	begin
	 clk = 0;
	 a = 0;
	end
	 
	always #10 clk = ~clk;
	 
	MYASSERT:assert property (@(posedge clk) a) else
	begin
	   $swrite(name, "%m");
	   myTask(name);
	end
	 
	task automatic myTask(ref reg [127:0] assertName);
	begin
	   $error($time, ": assert %s failed", assertName);
	end
	endtask
	 
	endmodule
	
	Thanks.
	Manisha

	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, and is 
	believed to be clean. 
	
________________________________



	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.

	 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.