Subject: [sv-ac] Summary of problems with error message and signal/variables.
From: Adam Krolnik (krolnik@lsil.com)
Date: Thu Oct 02 2003 - 07:17:57 PDT
Good morning all;
I am summarizing the problem of error reporting of assertions.
The problem with error reporting is that the error message does not
directly have access to the signal values and local variables used
in the property to determine a legal sequence of actions or an illegal
sequence.
For example, this property has signals and variables:
property follow_req(a, b, c, address)
reg [31:0] req_addr;
@(posedge clk) // Simple example
(a, (req_addr = address)
=> b ##1 c)
endproperty
assert follow_req(a, b, c, address)
else
$error("C (%0d) did not follow b after a with address %0h.\n", c, req_addr);
// 'c' and req_addr may show the wrong value.
These are the goals to be achieved in coding an error message:
1. Direct access to the same variable values for the error message as the sequences use.
2. Direct access to the local sequence variable values for the sequence (which one)
that has terminated.
Here are the real problems we face in trying to obtain the listed goals.
1. The property/sequences use sampled values when evaluating the property/sequence.
These sampled values are obtained by definition of the evaluation semantics of
sequences and properties.
2. The action block (pass statements and fail statements) does not use the sampled
values that the sequences use. Thus they are reporting possibly false information
about the real failure. This will absolutely confuse engineers trying to debug
their simulation using the shown information. Arguably, error reporting is broken!
3. We really don't have any access to the local variables computed in a sequence or
property. This is due to the fact that sequences can overlap each other in
their computation and can succeed or fail at the same event/time. Thus there is
an ambiguity in how to forward local variable values from a particular thread to
the error message (or action block in general.)
Attempted solutions at the problem.
1. Reserve use of the action block of assert and cover directives for non-reactive
operations - error reporting using assertions and coverage reporting using
cover directives. Then the action block must use sampled values for the variables
it references. - This solves only goal #1.
2. Move the error message somehow into the property block. Then the error message
uses the sampled values for the variables it references by virtue of it being
in the same scope as the sequence/property itse.f - This solves only goal #1.
3. Make $error, $fatal, $warning, $info system functions that return a 1/0 based on
the severity (fatal and error return a zero, implying failure, rest return a 1.)
Then include the system function as part of the sequence/property. The sequence
and property would call the system function when it wanted something to fail. E.g.
a |=> b | $error("Didn't see b after a.");
This solves goal #1 and #2.
This has the problem if possibly requiring the error message is several places
depending on where the property would fail.
This has the problem of possibly inverting the sequence to obtain the correct
polarity to produce the error message.
Goal #1 is particularly important - otherwise the use of assertions will leave a
bad taste in designers mouths.
Goal #2 is necessary to maximize use of local variables - they are a shorthand for
creation of satellite logic. Without access from outside, the variable is not
very useful as one will create satellite logic anyways.
THanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Thu Oct 02 2003 - 07:18:51 PDT