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

I couldn't disagree more with your statements.  The deficiencies
of immediate assertions (of which I include unique/priority case) 
and concurrent assertions are too numerous to use effectively
for large-scale design projects.   I had to read no further than
the spec to come to that conclusion.  We didn't go through any
painful discovery, we just called it out right away.

I will further state that there are several tools that know
how to do it better and that those tools address the very
limitations that you are willing to shoulder.  They are real,
practical problems that prevent good methdology and hurt designer
productivity. 

IME, designers know how to use the pragmas better than the standard
allows.

If they are deprioritized, it should be for lack of time, not because
of some perception that the designers got it wrong.  IMO, the standard
got it wrong.

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

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
>Behalf Of Stuart Sutherland
>Sent: Monday, September 10, 2007 8:38 AM
>To: sv-bc@eda-stds.org
>Subject: RE: [sv-bc] Glitches in unique/priority case/if violations
>
>
>I have been following this discussion thread, and have come to the
>conclusion that it might be best to drop the idea of defining 
>glitch-free
>unique/priority decisions for this go-around of the standard.  It is a
>language feature that is useful, but not essential.
>
>Even if we had glitch-free unique/priority, unique and 
>priority decisions
>are not for every situation in a design.  They have a 
>significant impact on
>synthesis.  When used correctly, these decision modifiers are 
>useful and can
>catch design bugs.  When used incorrectly, they have the same
>well-documented (thanks to Cliff's papers) pitfalls as the synthesis
>full_case pragma.  A similar situation exists when using 
>unique/priority in
>combinational logic.  There are places where the decision modifiers are
>appropriate and useful, and there are places where the 
>modifiers will fire
>inappropriately due to glitches.  In models where the decision 
>statement
>glitches, SystemVerilog has alternate verification mechanisms, 
>so it is not
>essential to u	se unique/priority.
>
>It is perhaps regretful that users who learn by 
>experimentation often learn
>the hard way on how to correctly use much of 
>Verilog/SystemVerilog (or any
>programming language), but writing the language to prevent 
>abuse would also
>limit useful features.  The unique/priority modifiers are 
>language features
>where users will simply need to learn (formally or informally) 
>the right
>places to use them.
>
>We have lots of things to work on for the 2008 version of the 
>standard.  In
>my opinion, further work on this topic should be moved to the near the
>bottom of the priority (no pun intended) list.
>
>Stu
>~~~~~~~~~~~~~~~~~~~~~~~~~
>Stuart Sutherland
>Sutherland HDL, Inc.
>stuart@sutherland-hdl.com
>503-692-0898
> 
>
>> -----Original Message-----
>> From: owner-sv-bc@server.eda.org 
>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R
>> Sent: Sunday, September 09, 2007 11:47 PM
>> To: Steven Sharp; sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com
>> Subject: 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.
>> 
>> 
>> 
>> 
>
>
>
>-- 
>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.