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

Hi Neil,

Yes, this is also a possibility, and it has many advantages. The downside is introducing one more kind of assertions. We will discuss this proposal.

Thanks,
Dmitry

-----Original Message-----
From: Neil Korpusik [mailto:neil.korpusik@oracle.com]
Sent: Tuesday, November 09, 2010 8:07 PM
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,

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.
>>
---------------------------------------------------------------------
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.