Subject: RE: [sv-ac] Missing elements from LRM for consideration.
From: Stephen Meier (Stephen.Meier@synopsys.com)
Date: Wed Feb 05 2003 - 12:42:13 PST
Bassam and Adam:
I will contact Swapnijit to get the SV-CC results incorporated.
We are actively bringing the DAS system tasks into the document
and expect to have this document ready soon. We are coodinating
with the LRM to integrate the whole document together.
Adam on point (2), I agree that assertions can appear in either
interfaces, or generate statements. We will update the document
to make this more clear.
Steve
---------
At 11:15 AM 2/3/2003 -0800, Bassam Tabbara wrote:
>Adam and all,
>
>For the -assertion control subset- of Item (1) below, I suggest that the
>SV-AC chair coordinate with SV-CC chair on having a consistent control
>API. As background info, there has already been discussion on this, and
>SV-CC has a doc specifying basic control (both a "spec", and a version
>in VPI notation/extension). Should be an easy item to address, SV-CC did
>the work already (granted we have a small number of cross members), just
>a matter of adding the corresponding $assert... System tasks (it covers
>all of 3.0 and more).
>
>Steve/?? Can you take this as action item and talk to Swapnajit ? He can
>provide the docs.
>
>In other words, I "second" Adam's suggestion on (1).
>
>-Bassam.
>
>--
>Dr. Bassam Tabbara
>Technical Manager, R&D
>Novas Software, Inc.
>
>http://www.novas.com
>(408) 467-7893
>
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org
> > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Adam Krolnik
> > Sent: Monday, February 03, 2003 10:21 AM
> > To: sv-ac@server.eda.org
> > Subject: [sv-ac] Missing elements from LRM for consideration.
> >
> >
> >
> >
> > 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
> >
Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell: 408-393-8246
This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 12:42:58 PST