Subject: [sv-ac] Missing elements from LRM for consideration.
From: Adam Krolnik (krolnik@lsil.com)
Date: Mon Feb 03 2003 - 10:20:40 PST
Good afternoon all;
I would like to recommend consideration of these items that are not within
the current LRM.
1. Inclusion of existing system tasks and system functions from SystemVerilog 3.0
There was concensus that these tasks and functions were useful for control
of assertions and ease of use for common specifications.
$assertoff - stopping new executions of assertions from reporting pass/failure.
$assertkill - disabling all (currently running) assertions and stopping new
execution from reporting pass/failure.
$asserton - Enabling assertions to execute.
[ The parameters to these are like those of the $dumpvars systemtask functionality.]
$onehot() - Return 1'b1 if only 1 bit of argument is true
$onehot0() - Return 1'b1 if 0 or 1 bit of argument is true.
$inset() - Return 1'b1 if first expression is equal to 1
of the remaining expressions.
$insetz - Same as $inset() but uses casez semantics for matching.
$isunknown() - Return 1'b1 if ^expression === 1'bx
2. Use of concurrent assertion_item.
According to the BNF, concurrent assertion items (property directives, property,
sequence, boolean and template declarations and template instantiations) can
be used in a module context and as a procedural context.
I would recommend that 'concurrent assertion items' be allowed in:
A. Interfaces
This would co-locate assertions directly with definitions of interface signals.
This is a good place (possibly better than an implementation of a given
interface.)
B. The generate context.
I have seen many examples where it would be nice to parameterize assertions
such that they can be generated with a loop soas to be extensible, reuseable
and shorter than the generated results.
Thanks.
Adam Krolnik
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 10:22:24 PST