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

Hi Matt,

My intention was not to provide a good solution for your problem, since
I still don't have any, but to highlight important issues in the
suggested definition of the stable check of the unique case. Since we
are working now on the definition of "final" assertions, the problems we
are facing are very similar to the problems that you may encounter.

Since stability requires some kind of sampling, it is natural to try to
extend concurrent assertions for other use cases where stable assertions
are required. This is not straightforward, but may eventually work.

Please, see my specific 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 the
new iterations 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 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 of the Observed region. You can
either state that you sample values when entering the Observed region
for the first time, or that you sample them 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?  

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

Is this the motivation for trying to overload concurrent assertions?

[Korchemny, Dmitry] The motivation of overloading concurrent assertions
is that they can do the work for the "synthesizable" code (I am not
trying to define here what this exactly means). For the true
"non-synthesizable" code the immediate assertions seem to be the best
choice.

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] Exactly. Therefore introducing this clock should not
slow down the simulation as compared to other concurrent assertions. 
 
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.

[Korchemny, Dmitry] There is no burden for users, at least in your case,
since you can keep the syntax you suggested for unique case.
Semantically it will mean sampling in the Preponed region at each step.
As for explicitly written assertions, one can introduce a default
notation, e.g., no clock = simulation tick.

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.   

[Korchemny, Dmitry] Yes, I understand this. But you need an unambiguous
definition of unrollable and non-unrollable loops. Note also that the
problem gets more complicated when an assertion/unique case, etc. is
written inside a function or a task, etc.

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.