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.