RE: [sv-ac] RE: [sv-bc] Simulation semantics of deferred assertions (Mantis 3206)

Hi Dave,

I do understand that there are problems with program blocks. However, they are part of the language and the people use them, therefore they should be adequately supported. And indeed, there is the whole layer of reactive regions to support them. These regions are also aligned with assertion action blocks.

Why is this too late to change the scheduling semantics of deferred assertions? Unless we are talking about the VPI, any new suggested definition will produce the same results for all cases that could be processed properly in deferred assertions, and will also handle cases correctly which are not handled correctly now.

How do you suggest to handle sequence triggered methods in continuous assignments in checkers? Note that this use case is important in checkers, at least in FV.

Thanks,
Dmitry

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Monday, November 08, 2010 5:23 PM
To: Korchemny, Dmitry; neil.korpusik@oracle.com
Cc: sv-ac@eda.org; sv-bc@eda.org
Subject: RE: [sv-ac] RE: [sv-bc] Simulation semantics of deferred assertions (Mantis 3206)

Dmitry,

Your first case is one of the major reasons I recommend that people do not use program blocks. See http://go.mentor.com/programblocks

The OVM examples and tutorials never used program blocks when describing their methodologies.

It's really way too late to change the scheduling semantics of deferred assertions unless every agrees they are useless the way they are currently defined. If the use of sequence.triggered() method in a continuous assignment in a checker is the only reason for this discussion, then you ought to be addressing that case specifically.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Korchemny, Dmitry
> Sent: Monday, November 08, 2010 3:47 AM
> To: neil.korpusik@oracle.com
> Cc: sv-ac@eda.org; sv-bc@eda.org
> Subject: [sv-ac] RE: [sv-bc] Simulation semantics of deferred assertions
> (Mantis 3206)
>
> Hi Neil,
>
> There are two strong driving cases when the current definition of
> deferred assertions doesn't work, and it is impossible, or at least, not
> desirable to avoid using deferred assertions there. The first case
> happens when some design blocks are replaced with TB for debug purposes,
> as explained in Mantis 3206. Consider two blocks A and B, such that A
> drives the inputs of B and B has a deferred assertion between one of its
> input and an internal signals. Such assertions/assumptions are commonly
> written for formal equivalence check. When it is wanted to debug the
> block B, the block A is replaced with a program, and the assertion that
> worked properly starts producing false negatives (glitches). This case is
> common, and I believe that it should be addressed.
>
> Another case is going to arise when continuous and blocking assignments
> are introduced in checkers. Continuous assignments in checkers should be
> executed in the Reactive region. Introducing them in the Active region
> would result in glitches in concurrent assertions when the RHS of the
> assignment refers to a sequence triggered method. If continuous
> assignments in checkers are defined in the Reactive region, we will face
> the problem described in Mantis 3206: there will be glitches when the
> body of a checker deferred assertion contains a mix of design and checker
> variables. It is, of course, highly undesirable to disallow such a mix in
> checker deferred assertions.
>
> Thanks,
> Dmitry
>
> -----Original Message-----
> From: Neil Korpusik [mailto:neil.korpusik@oracle.com]
> Sent: Saturday, November 06, 2010 2:56 AM
> To: Korchemny, Dmitry
> Cc: sv-ac@eda.org; sv-bc@eda.org
> Subject: Re: [sv-bc] Simulation semantics of deferred assertions (Mantis
> 3206)
>
> Hi Dmitry,
>
> My suggestion is to leave things as they are and not write assertions
> that suffer from this problem.
>
>
> Neil
>
>
>
>
>
> On 11/05/10 17:24, Korchemny, Dmitry wrote:
> > Hi all,
> >
> >
> >
> > Deferred assertions were designed to avoid simulation glitches. However
> > simulation glitches are still possible when some of the assertion
> > subexpressions are evaluated in the Active region and the others in the
> > Reactive one. In this case the assertion matures twice: the first time
> > when it reaches the Observed region for the first time, and the second
> > time when it reaches it again upon the evaluation in the Reactive
> > region. One such example is discussed in Mantis 3206
> > (http://www.eda-stds.org/mantis/file_download.php?file_id=4571&type=bug
> > <http://www.eda-
> stds.org/mantis/file_download.php?file_id=4571&type=bug>).
> > This situation is going also to occur in checkers when the continuous
> > assignments in checkers are introduced.
> >
> >
> >
> > To address these problems the simulation semantics of deferred
> > assertions should be changed. I can think of the following options:
> >
> > 1. Make assertions mature in the Postponed region instead of the
> > Observed one. The advantage of this solution is its simplicity, the
> > obvious disadvantage is the inability to change anything from the
> > assertion action blocks.
> >
> > 2. Require deferred assertions to "make two full iterations through
> > simulation regions", and make them mature only starting at the second
> > visit in the Observed region. The advantages is the ability to change
> > design variables from the assertion action blocks (e.g., to count), its
> > disadvantage is performance penalty and more complicate simulation
> > semantics.
> >
> >
> >
> > What would you suggest?
> >
> >
> >
> > Thanks,
> >
> > Dmitry
> >
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
> is
> > believed to be clean.
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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