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

A clarification: <Option 1: ..*. **the obvious disadvantage is the inability
to change anything from the assertion action blocks*.>
*If that really something that we want to encourage? Dmitry, can you provide
an example where this feature is really needed? *
[Ben] Option 1 make assertions mature in the Postponed region instead of the
Observed one.
Action block assignments to design variables is still needed in SVA, but if
that assignment takes place in the Postponed region, then wouldn't have this
loop back to the active region. The original issue is the loopback and the
deferred assertions. Are there issues if the assertions are executed in
the Reactive region, but action block assignments to design variables
occurring in the Postponed region?
Ben SystemVerilog.us

On Fri, Nov 5, 2010 at 6:10 PM, ben cohen <hdlcohen@gmail.com> wrote:

> Neil,
> *< leave things as they are and not write assertions that suffer from this
> problem.>*
> This is a suggestion, but it is not a rule that can be safeguarded by the
> language definition.
> VHDL timing definitions has safeguard because of the definition of the
> language.
> I like option 1.
> <Option 1: ..*. **the obvious disadvantage is the inability to change
> anything from the assertion action blocks*.>
> If that really something that we want to encourage? Dmitry, can you provide
> an example where this feature is really needed?
> Ben SystemVerilog.us
>
>
> On Fri, Nov 5, 2010 at 5:55 PM, Neil Korpusik <neil.korpusik@oracle.com>wrote:
>
>> 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.
>>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>>
>

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