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

Erik,

There appears to be some wording in Mantis 2005 that could use
some work.  In particular, the statement:
     A clock is inferred if the statement is placed in an always or initial
     block with an event control...

An always or initial does not have an event control.  The process
has a statement which may have an event control.  This is an important
distinction since, for example, @(*) is an event control that binds to
a statement rather than always_comb which is a process type.  Many
people confuse the two so I'd like to be careful about the LRM wording
in such cases.


I have problems with:
     A particular implementation of assertions in procedural code need
     not use shadow variables, but the observable behavior must the same
     as if the shadow variables were used.

Are these shadow variables observable via pli, etc?  If not,
then I don't think that they should be discussed in this manner.
You should only talk about something like "the sampled value of
the expression" or similar.  I don't think that shadow variables
should be "potentially" visible -- they either must be visible
or not.  If they are, you need to deal with naming issues, etc.
When you state that something is "equivalent to", you open up
huge questions regarding name resolution, hierarchical visibility,
being able to assign to the shadow, etc, etc.  I know what you
are after -- assertion behavior equivalence -- but the proposal
doesn't say that nor explicitly say that shadow variables are
invisible to the HDL code and to the pli, etc.


I need to think about:
     Each specific call of a function requires that a new copy of the
     function be created and declared together with the required shadow
     variables in the scope where the always or initial block, or continuous
     assignment is located. These variables are assigned in the function at
     the location of the assertions using side-effect assignments.

Anytime I see something like "copy of the function" I get really, really
worried about all the pli and similar impact.  I don't think that you
really want to express things in that manner.

Gord.


Seligman, Erik wrote:
> Hi guys-- 
> 
>     (Sorry to enter this conversation late, I wasn't subscribed to
> sv-bc.)   I think from the conversation below, the latest Mantis 2005
> proposal may be pretty close to what you are suggesting:  concurrent
> assertions are enabled even in unclocked locations.  An unclocked
> concurrent assertion is defined as taking effect at the end of each time
> step.  Have you taken a look yet?  Any suggested rephrasings /
> improvements would be appreciated; I'm not quite sure if the way we've
> specified it in the current draft is acceptable.
> 
> 
> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
> Behalf Of Maidment, Matthew R
> Sent: Monday, September 10, 2007 11:04 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
> 
> That's approximately what I'm after. I thought I stated as much in the
> thread.  Anyway, I'm after a combinational assertion that can be placed
> in procedural for-loops and functions and everywhere else that should
> enable good assertion practice of location with relevant code-- and get
> evaluation semantics closer to that of a concurrent assertion.
> 
> unique/priority are follow-ons IMO.  I was proposing adding a modifier
> to them such that their built-in check could be evaluated with this new
> semantic instead of the current, immediate semantic.
> 
> Matt
> --
> Matt Maidment
> mmaidmen@ichips.intel.com
>   
> 
>> -----Original Message-----
>> From: Steven Sharp [mailto:sharp@cadence.com]
>> Sent: Monday, September 10, 2007 8:01 PM
>> To: sharp@cadence.com; sv-bc@eda-stds.org; Brad.Pierce@synopsys.com; 
>> Maidment, Matthew R
>> Subject: RE: [sv-bc] Glitches in unique/priority case/if violations
>>
>>
>>> From: "Maidment, Matthew R" <matthew.r.maidment@intel.com>
>>> 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.
>> Those restrictions appear to be necessary to make Erik's proposed 
>> mechanism work.
>>
>>> 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 would think you could have the concept of a concurrent assertion that
> 
>> is "clocked" by a change in any of its operands (like a combinational 
>> block) and waits until an appropriate end-of-time queue to evaluate in 
>> order to filter out glitches.  Is that what you meant?
>>
>> However, that still doesn't solve the problem of unique/priority.
>> Those are effectively immediate assertions.  The existence of 
>> combinational concurrent assertions doesn't solve the problem of 
>> converting an immediate assertion into a concurrent assertion.
>>
>>> 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.
>> Would the addition of combinational concurrent assertions allow 
>> execution of the user check in the appropriate region?
>>
>> Steven Sharp
>> sharp@cadence.com
>>
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.