Re: [sv-bc] Suppression of unique/priority glitches

A procedural for-loop evaluates in a single process (usually
within a single activation of that process), so its uniqueness violations
would accumulate as deferred reports (in a region that only issues its
error reports when the system is in an "observable" state)
and would only be purged if that process re-activates (or restarts) before the
system reaches an observable condition.  It is the process (the
outermost construct around a procedural scope) which must repeat,
not the unique construct inside it.  There must be a step in process
"initiation" which purges its deferred reports, if we accept Erik's
idea, or in process "activation", if we accept Gord's original
proposal.   I like what Erik suggests.

Greg

Bresticker, Shalom wrote:
> What about unique/priority if/case occuring within a for-loop?
> 
> Shalom
>   
> 
>> -----Original Message-----
>> From: owner-sv-bc@server.eda.org 
>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
>> Sent: Friday, October 12, 2007 1:11 AM
>> To: Steven Sharp
>> Cc: sv-bc@server.eda.org
>> Subject: Re: [sv-bc] Suppression of unique/priority glitches
>>
>>
>>
>> Steven Sharp wrote:
>> [..]
>>> Is there a consideration I am missing here?
>> No.  When we all talked about the fork..join_none issues for 
>> continuous assigns (which has a very weak relationship to 
>> this) people were concerned about various things and it 
>> wasn't clear to me whether that would be of concern here too.
>>
>>
>>> The scenarios I am worried about are the more unusual ones: 
>> procedural 
>>> continuous assigns, nonblocking assigns, $monitor, and so 
>> forth.  The 
>>> only one that seems likely to come up in reasonable designs are the 
>>> nonblocking assigns, but the behavior has to be specified 
>> for everything.
>>
>> I don't think nbas are a concern since the evaluation is 
>> still in the originator.  The procedural continuous assigns 
>> and $strobe, $monitor, etc. are a bit troublesome, but I 
>> think they are under almost any model that I've heard people discuss.
>>
>> Proposal (off the cuff) -- unique/priority assertions should 
>> be ignored if they occur during the evaluation of a 
>> procedural continuous assign or any system task (which would 
>> include user define arg evaluations as well).
>>
>> Would anyone worry about those?
>>
>>
>>
>>>> I would support the same semantics for continuous assigns, 
>> but would 
>>>> certainly consider other alternatives that were well formed.
>>>> Would you suggest treating unique/priority violations in 
>> the current 
>>>> immediate manner in such scenarios and differently in true 
>> "process" 
>>>> contexts?
>>> No, I don't think it would make sense to treat them 
>> differently.  As I 
>>> said, I think it would be well-behaved.  And I'm not happy about 
>>> having to treat violations differently in the same function 
>> depending 
>>> on what kind of process it was called from.
>>
>> I too am a bit worried about the potential cost of this but I 
>> think with a bit of thought it may not be too bad.  I think 
>> that this could be considered as a specific kind of "disable"
>> of a child assertion reporting thread.  The cost then could 
>> just be borne by processes that have (or better "have done") 
>> at least one unique/priority evaluation.  Basically, I think 
>> the cost could be made to scale with the number of processes 
>> that do priority checks.  I don't see anything fundamental 
>> that would require a seriously non-efficient approach.  
>> Obviously there may be impacts on one's ability to optimize 
>> designs in such cases which could be noticeable, but I don't 
>> think this kind of thing can be done "for free".  I certainly 
>> hope that users can be made to understand that this kind of 
>> feature does have implementation implications and that this 
>> likely won't be a free lunch in any implementation.
>>
>> Once again, I don't see much of a better alternative -- all 
>> of the other approaches seem to have much deeper potential 
>> analysis and scalability issues.  I'm afraid that there are 
>> some fundamental costs with any approach to this kind of suppression.
>>
>> I would love to find a cheap, simple to describe, scalable 
>> approach; if you have any ideas to recast things such that it 
>> could be less intrusive, that would be great!
>>
>> I suspect that the user community cares primarily about the 
>> "normal" circumstances so we should explore whether reducing 
>> the generality will be acceptable to users and will help with 
>> describing what happens in the weird cases.
>>
>> Gord.
>> --
>> --------------------------------------------------------------------
>> 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.
>>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 


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