Hardware Reference
In-Depth Information
Enabling all assertions or all functional coverage or both.
Exclusion of nonsynthesizable code like action block reporting tasks, covergroups
or testbench related items.
Local configuration on a per-instance basis is best achieved by elaboration-time
constants and conditional generate blocks. This includes:
Selection of specific functional coverage items or levels, from a combination of
cover property
and
covergroup
constructs.
Selection of
assert
,
restrict
,or
assume
forms of assertions.
Configuration and selection of subsets of assertions that should be active in a
checker instance.
Specification of minimal and maximal delay latencies and repetition counts in
clock cycles.
Specific user failure and success messages.
Specification of severity level of assertion failure.
Elaboration-time constants must provide default values. For example,
Most typical assertion usage (assertion kind, temporal delays and repetitions).
Default failure message.
Minimal useful functional coverage.
Functional coverage should provide several levels of detail whenever practically
useful. Some may or may not be suitable for formal and synthesis tools and these
should also be under global control. Here is a typical gradation:
Minimal—“did the checked behavior ever happen?”
More detailed—“which specific delay or data values were observed?”
Corner cases—“were min and max delays, and boundary data points ever
encountered?”
It is often desirable to perform
x/z
value checks on signals used in a checker.
There may be separate checkers that perform just that task and report a failure when
an
x
or
z
is detected. However, even “regular” assertions may have to include such
checks to disable the assertion from failing or forcing a failure. The choice depends
on whether separate checks for these values are used. If yes, then there is no point in
reporting a failure in regular assertions, they should just report a vacuous or disabled
success. Usually, the detection of
x/z
is done using the system function
$isunknown
that returns true if an
x
or
z
is detected in the argument expression value. For more
detailed testing of
x
and
z
values, system function
$countbits
(Sect.
7.1.1
) can be
used as well.
The ease of using configuration capability is important when different test
environments are used. For example, control may be provided over the following
features:
Choice of failure, success and information reporting integrated with the System-
Verilog testbench verification methodologies (e.g., UVM [
9
], VMM [
19
]orOVM
[
38
]), or only reporting using
$display
, or using run-time error tasks, such as
$error
,etc.
Search WWH ::
Custom Search