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

Shalom,

I think there is an assumption issue at work here.

Let me give an example:

    always_comb
       for(int i =0; i < P; i++) begin
          ...
          assert ....
       end

The "block" model that Erik was talking about does NOT "flush"
in the for loop block.  It is the "process block" that
Erik is talking about.

Unfortunately that becomes messy because I suspect that
Erik may be making a common mistake -- thinking that in
    always @(a,b,c) begin ... end
the "@(a,b,c)" is part of the process rather than the statement.

That makes this way of expressing the problem awkward and may
be the cause of some confusion.

I think that Erik's model of the above always process would be:
    always @(a,b,c) begin
       flush_my_deferred_assertions()
       begin ... end  // the original body
    end

So sequential loops would behave as you want.

The difference between what Erik is suggesting and what I
was suggesting is primarily exposed when you have non-combinational
processes with internal zero delay events.  In such cases, Erik's
approach would preserve the assertions and mine would not.



One could, however, construct an explicit internal "forever @(...)"
loop *within*  a sequential process.  Consider the following:
    initial begin
       // do some preamble
       forever @(a,b,c) begin ... end   // I want this to be combinational
    end

If such code was written explicitly by the user, Erik's approach
would lose the "combinational glitch suppression" behavior while my
approach would not.

So there is a certain amount of potential loss of assertion
reporting in either approach.


If all we really care about is "combinational processes", I
think that I'd prefer my semantics since for things like
always_comb and "normal" combinational always blocks with immediate event
control the two are equivalent while my suggestion covers internal
combinational behavior as well.  If no one is worried about the
internal combinational behavior and is worried about potential
loss of assertions in the non-combinational cases, Erik's suggestion
should be followed.


Gord.

Bresticker, Shalom wrote:
> 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.
> 

-- 
--------------------------------------------------------------------
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.