RE: [sv-bc] Glitches in unique/priority case/if violations

Hi Matt,

Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: Maidment, Matthew R 
Sent: Tuesday, September 04, 2007 10:10 AM
To: Korchemny, Dmitry; 'Warmke, Doug'; 'Brad Pierce';
'sv-bc@server.eda.org'
Subject: RE: [sv-bc] Glitches in unique/priority case/if violations

I don't understand why using the observed region is taboo. What parts of
the system are active in the observed region and what causes re-entry
into the standard design regions?

[Korchemny, Dmitry] The scheduling diagram (see Fig. 4-1 shows that
iterations from the beginning may start after execution of the Observed,
the Post-Observed, the Post-Re-NBA and the Pre-Postponed regions. E.g.,
the property specified in the expect statement is evaluated in the
Observed region, and the subsequent code may cause new events so that
the Observed region will be visited again. Another example provide
sequence events (9.4.2.4)

Not the design as far as I can tell.

[Korchemny, Dmitry] The LRM does not specify a notion of the design. I
believe that in most of conventional RTL designs the Observed region is
visited only once. But this situation may change. E.g., people may start
using sequence events in their RTL code.

This new assertion class should be used to fend off the effects of
simulator-induced glitches due to ambiguity in evaluation of concurrent
processes.  If some external factors such as a testbench or interesting
assertion action code cause the design to behave erratically, at least
there's someone to blame and some code to adjust.

[Korchemny, Dmitry] See my previous comment.

What's the big hurdle to activating them in the observed region?

[Korchemny, Dmitry] It is not a problem to activate assertions in the
Observed region, but to sample values in the Observed region. You never
know whether this is your last visit to the Observed region. You can
either sample values when entering the Observed region for the first
time, or each time when you enter the Observed region. In the latter
case you can still have glitches.

Do you really need to define a sub-region within the observed region or
create a new region?  Is this the motivation for trying to overload
concurrent assertions?

[Korchemny, Dmitry] I don't think that introducing yet another region
will solve the problem. If you want to sample values in the Observed
region, more radical changes in the scheduling algorithm are required.
Assertions without action blocks, like unique case may be checked in the
Postponed region using sampling values in the Postponed region, but then
you introduce yet another class of assertions in SV.

I'm very much opposed to attaching a clock or pseudo-clock-- precisely
because it is so abhorrently inefficient.  And once we have defined some
system-known, every-time-step clock, simulators will optimize the clock
right back out.
[Korchemny, Dmitry] 
Making users bear this burden
is unreasonable and burdening users with the draconian task of multiple
words to do so
on each and every assertion doesn't add up to me.

Regarding the for-loop, let me clarify my intentions:  each iteration of
the for 
loop initiates the evaluation of the assertion (just like an immediate
assertion)
but the evaluation is actually queued until the observed region.  For
your example,
the 3 assertions (unique a[0],b[0]; unique a[1],b[1]; unique a[0], b[0])
would
be queued for final evaluation in the observed region.   

Just to make sure we don't lose sight of the problem, here's an example
of code
that evaluates differently on different simulators but should not be a
problem
at all:

http://www.eda.org/sv-ac/hm/2932.html

Matt
--
Matt Maidment
mmaidmen@ichips.intel.com
  

>-----Original Message-----
>From: Korchemny, Dmitry 
>Sent: Monday, September 03, 2007 11:36 PM
>To: Maidment, Matthew R; Warmke, Doug; Brad Pierce; 
>sv-bc@server.eda.org
>Subject: RE: [sv-bc] Glitches in unique/priority case/if violations
>
>Hi Matt,
>
>Unfortunately it is not easy to understand what the final 
>value is. Should it be in the Observed region? But the 
>Observed region may be visited several times in the simulation 
>step and it is not known whether the current visit is the last 
>one. To evaluate the assertions in the Postponed region is not 
>an option, since there is no slot for the execution of an 
>action block there.
>
>Since checking unique case does not require any action block 
>to execute, it may be done in the Postponed region, but then 
>you are implicitly introducing yet another kind of assertions 
>into the language.
>
>Our first attempt was to define "final" assertions to sample 
>their values in the Observed region, but we could not define 
>it without making major changes in the SV scheduling process. 
>This is why we are trying to reuse concurrent assertions for 
>this purpose.
>
>If you want to evaluate a concurrent assertion at each time 
>step (i.e., to be clock independent), it is enough to define a 
>system function, say $simulation_tick, which will return an 
>event at the beginning of each simulation tick (it can be 
>defined accurately). This function would be similar to 
>$global_clock which we are trying to introduce now. The main 
>reason why we did not want to state that the $global_clock is 
>ticking at each simulation step was the simulation efficiency.
>
>Another point that needs to be taken into account is loops. A 
>straightforward definition will produce unexpected results. 
>Consider your example modified:
>
>for (int i = 0; i < 3; i++) begin
>	assert unique case (1'b1) inside 
>  	[a[i]] out = ina;
>  	[b[i]] out = inb;
>	endcase
>end
>
>When checked in the Observed or in the Postponed region, the 
>check will be performed for i = 2 only, which apparently is 
>not your intention.
>
>Regards,
>Dmitry
>
>-----Original Message-----
>From: owner-sv-bc@server.eda.org 
>[mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R
>Sent: Tuesday, September 04, 2007 9:03 AM
>To: Warmke, Doug; Brad Pierce; sv-bc@server.eda.org
>Subject: RE: [sv-bc] Glitches in unique/priority case/if violations
>
>
>
>In my opinion, there should be a class of assertions that are evaluated
>at the end of the 
>time step in which they are triggered.  The values that are sampled are
>the final values for 
>that time step-- and no clock should be implicitly or explicitly
>associated with the assertion. 	
>
>As awful as this may seem, I would propose an addition modifier to the
>case statement to change
>the evaluation from immediate to this new mode.  Something like
>postponed or observed or reuse some 
>keyword like assert or final.
>
>observed unique case (1'b1) inside 
>  [a] out = ina;
>  [b] out = inb;
>endcase
>
>assert unique case (1'b1) inside 
>  [a] out = ina;
>  [b] out = inb;
>endcase
>
>I'm not stuck on the position of a new modifier, I'm just throwing it
>out there so I can
>see what it might look like.
>
>I advocate leaving immediate assertions as they are and create this new
>class to avoid
>compatibility issues.
>
>Matt
>--
>Matt Maidment
>mmaidmen@ichips.intel.com
>  
>
>>-----Original Message-----
>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
>>Behalf Of Warmke, Doug
>>Sent: Monday, September 03, 2007 9:40 PM
>>To: Brad Pierce; sv-bc@eda.org
>>Subject: RE: [sv-bc] Glitches in unique/priority case/if violations
>>
>>Hi Brad,
>>
>>I thought of this myself when I first saw Erik's proposal.
>>After I read the proposal, I thought the technique he
>>is proposing to deglitch those was not appropriate for
>>the unique/priority case/if glitch problem.  But, maybe
>>there are some things that could be done.
>>
>>The fundamental issue with unique/priority case/if is the
>>lack of a clocking specification that would be used to
>>strobe the logic at appropriate times.  
>>
>>In the immediate assertions situation, Erik is proposing to
>>replace the immediate assertions with concurrent assertions.
>>There are a few modifications to concurrent assertion semantics
>>to make them appropriate for replacing immediate assertions.
>>And by nature, concurrent assertions must be associated with
>>an implicit or explicit clocking event.
>>
>>So, if we could oblige users to write their unique/priority
>>case/if constructs in code where clocking can be inferred,
>>perhaps the technology could work.
>>
>>But what about cases where no clocking can be inferred?
>>Should those cases turn into errors?  Backwards compatibility
>>problems would then arise.  Though backwards incompatibility
>>with glitchy unique/priority detection could be argued to
>>be not such a bad thing... 
>>
>>For the assertions proposal, I think this clocking situation
>>is easier.  In cases where no clocking can be inferred,
>>users will continue to use immediate assertions. They
>>are susceptible to glitches, but at least there are no
>>compatibility issues.
>>
>>Regards,
>>Doug
>>
>>-----Original Message-----
>>From: owner-sv-bc@server.eda.org 
>[mailto:owner-sv-bc@server.eda.org] On
>>Behalf Of Brad Pierce
>>Sent: Monday, September 03, 2007 9:07 PM
>>To: sv-bc
>>Subject: [sv-bc] Glitches in unique/priority case/if violations
>>
>>In http://www.eda-stds.org/sv-ac/hm/4668.html the SV-AC is proposing a
>>possible solution for the glitch issue in immediate assertions.
>>
>>Is there some way that this proposal could be leveraged into 
>a solution
>>for the glitch issue in unique/priority case/if violoations?
>>
>>That is, could the violations of unique/priority be defined 
>in terms of
>>implicit immediate assertions?
>>
>>Erik's SV-AC proposal is at
>>
>>  http://www.eda-stds.org/sv-ac/hm/att-4668/assertfinal070830es.pdf
>>
>>-- Brad
>>
>>
>>-- 
>>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.
>>
>
>-- 
>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.