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

Hi Dmitry,

There is another possible solution that we might want to consider.

We could create a new type of deferred assertion that would mature
in the Postponed region. If the action block of such an assertion were
limited to a single call to $display it might be reasonable to define such an
assertion. I believe an assertion defined this way would not suffer from
the glitch problem that arises due to the use of a program block as
a design stub.

The Postponed region is currently very limited. $monitor and $strobe currently
execute in this event region.

Neil

On 11/09/10 05:48, Korchemny, Dmitry wrote:
> Hi Neil,
>
> Please, see below.
>
> Thanks,
> Dmitry
>
> -----Original Message-----
> From: Neil Korpusik [mailto:neil.korpusik@oracle.com]
> Sent: Tuesday, November 09, 2010 4:46 AM
> To: Korchemny, Dmitry
> Cc: Gordon Vreugdenhil; Eduard Cerny; Arturo Salz; sv-ac@eda.org; sv-bc@eda.org
> Subject: Re: [sv-ac] RE: [sv-bc] RE: Simulation semantics of deferred assertions (Mantis 3206)
>
> Hi Dmitry,
>
> This whole discussion sounds like a good topic for the upcoming SV-AC
> face-to-face meeting in February. This is the sort of topic which is
> difficult to resolve via email.
>
> [Korchemny, Dmitry] I agree. If it is decided that this issue is important, we will discuss it in our F2F meeting.
>
> Arturo made some suggestions for potential changes to the semantics of deferred
> assertions that might be useful in your environment. One of those suggestions
> involved changing deferred assertions so that they mature in the Re-NBA region.
>
> I don't see how this particular change will help much. Value changes driven out
> of a program output port will happen in the reactive region set, but the
> "design processes sensitive to those cross-region variables and nets are
> scheduled for wake up in the active region set." (24.3.2). Because of this, the
> new values coming from the program block may not reach the inputs to the
> deferred assertions until the event processing has gone around the Outer loop.
> That would leave you with the same glitch problem that you are trying to
> eliminate.
>
> [Korchemny, Dmitry] This is a serious issue.
>
> There is also the problem of breaking backward compatibility.
>
> [Korchemny, Dmitry] If we come to some acceptable solution, we will have to consider its implications to the backward compatibility. We should strive to introduce as little incompatibility as possible.
>
> Deferred assertions, as they are defined today, are very useful. The cases
> that you are trying to resolve seem to be more related to methodology
> issues rather than language issues.
>
> [Korchemny, Dmitry] I do my best to filter out pure methodology issues. This one seems to be a real issue of the language.
>
> Neil
>
>
>
> On 11/08/10 13:32, Korchemny, Dmitry wrote:
>> Hi Gord,
>>
>>
>>
>> Please, see below.
>>
>>
>>
>> Thanks,
>>
>> Dmitry
>>
>>
>>
>> *From:* Gordon Vreugdenhil [mailto:gordonv@model.com]
>> *Sent:* Monday, November 08, 2010 6:34 PM
>> *To:* Korchemny, Dmitry
>> *Cc:* Eduard Cerny; Arturo Salz; sv-ac@eda.org; sv-bc@eda.org
>> *Subject:* Re: [sv-bc] RE: Simulation semantics of deferred assertions
>> (Mantis 3206)
>>
>>
>>
>> I agree with Neil -- don't do things that cause the problems.
>>
>> Deferred assertions were explicitly designed to deal with
>> "in-region" glitching. Trying to extend that to cross-region
>> glitching isn't going to work very well. We intentionally
>> and explicitly agreed that "big loop" issues causing glitches
>> were going to be part of the model.
>>
>> */ /*
>>
>> */[Korchemny, Dmitry] We told that mixing in the same assertion design
>> and TB variables is not a good methodology. The problem that we
>> disregarded is the case when an assertion/assumption combines a primary
>> input and an internal signal. Writing such untimed assertions is not a
>> good practice for ABV. However, this is done for formal equivalence
>> check, and such assertions/assumptions turned out to be essential. /*
>>
>>
>> Having re-active continuous assigns in checkers and
>> expecting clean interactions with the design is not really
>> reasonable -- the program regions and design regions
>> were intentionally designed to provide for TB/DUT
>> interaction, not for interwoven interaction and it has
>> been intentional in EC and BC to go that route.
>>
>> */[Korchemny, Dmitry] We can consider defining continuous and blocking
>> assignments in checkers in the Active region. This looks strange since
>> the nonblocking assignments in checkers are performed in the Re-NBA
>> region. We will discuss this and see what the implications are./*
>>
>>
>> So I don't think that there should be a solution to this
>> that involves creating specific program/design region
>> scheduling requirements. The checkers semantics
>> for things like CAs or other problematic features should
>> probably be re-examined by the AC to see whether they
>> can be fit more cleanly into a single region. I certainly
>> don't want to try to twist the original (already complex)
>> scheduling model to fit different assumptions and
>> interactions for which it was never designed.
>>
>> */[Korchemny, Dmitry] We will do that and see if it is possible (as I
>> mentioned above)./*
>>
>>
>> If AC can make a sufficiently strong case for yet another
>> scheduling sub-loop, you could try to go that route,
>> but there is going to be a great deal of resistance to that
>> as well.
>>
>> */[Korchemny, Dmitry] This is the last resort./*
>>
>>
>> Gord.
>>

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