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.