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

Maybe I was not clear.

If I have a loop which executes 16 times, and the loop contains a unique
case construct, then that unique case will execute 16 times. However,
each iteration of the unique case should be considered separately from
the other iterations. I don't want the violation of each iteration to
cause that of the previous iteration to be forgotten. SV-AC has a
proposal for dealing with assertions in loops in Mantis 1995.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Greg Jaxon
> Sent: Friday, October 12, 2007 9:39 AM
> To: Bresticker, Shalom
> Cc: Gordon Vreugdenhil; sv-bc@server.eda.org
> Subject: 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.
> 
---------------------------------------------------------------------
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.