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

I think any restrictions regarding for-loops should be removed.
If there's some need to clarify the behavior in a for-loop,
that's fine.

I agree with your statement about simplicity and feel that some
very simple feature is missing-- glitch insensitive combinational
assertions.  Not all assertions require a clock and using one
can actually hide problems.  

I don't believe forcing users to write a function to handle the
process however they choose is practical.  I don't believe there
are enough features in the language to enable code execution in
the appropriate order in/at/around each simulation region.

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

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
>Behalf Of Steven Sharp
>Sent: Friday, September 07, 2007 9:45 PM
>To: sv-bc@eda-stds.org; Brad.Pierce@synopsys.com
>Subject: Re: [sv-bc] Glitches in unique/priority case/if violations
>
>Note that Erik's proposal also places restrictions on the kinds of
>loops that these assertions can appear within.  Similar restrictions
>would be required on unique/priority case/if to use this approach.
>Since there are currently no restrictions on where unique/priority
>if/case can appear in procedural code, this would not be backward
>compatible.
>
>Personally, I think it is a mistake to try to add a lot of complex
>rules where the tools try to figure out what you are trying to do.
>Computers are not very good at doing that, and LRMs are not very good
>at specifying it.  It is better to provide basic flexible features
>that the user can use to build exactly what they want, using their
>own understanding of what they are doing.
>
>In this case, I think it would be better to provide a mechanism
>to save the success or failure of the unique/priority condition into
>a user variable.  Then the user can write whatever code they want
>to check it.  If they want to wait until a particular clock edge to
>check it, then they can do so.  They can use a concurrent assertion
>to check it, if those are the semantics they want.  If they need to
>keep track of it for each iteration of a loop, they can use an array
>to save the result for each iteration.
>
>This could be done by adding some syntax to provide a place to write
>the result.  For example
>
>  unique(result) case (select)
>  ...
>  endcase
>  
>
>Steven Sharp
>sharp@cadence.com
>
>
>-- 
>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.