Re: [sv-bc] e-mail ballot due Monday, Feb 18, 8AM PST

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Fri Feb 15 2008 - 09:43:57 PST
My issue with just removing the "one" assignment is that the
wording:
   When a first attains a new value of 1...
is still making assumptions about initial states of "a" and "not_a".

When does "a"  **FIRST** get a 1?  Was it initialized
that way?  What was the state of "not_a" at initialization?
If neither is initialized (and are 2 state) then on a's
FIRST transition to 1, there is no conflict.

I agree that having the initialization makes the general
case more strange but the entire point of this example
is to talk about just the glitch aspect.

If you want to talk about the general case, get rid of the word
"first" and have something like:
     When "a" and "not_a" are in the state 0 and 1 respectively
     and "a" transitions to 1 ...

That would cover both of our concerns I think.

Gord.


Alsop, Thomas R wrote:
> Hi Gord,
> 
>  
> 
> So I hesitate to make this change only because we would be hardwiring 
> this example with an initial value when we really want the example to 
> more broadly show what can happen at any point in time in the 
> simulation.  I'm sure it doesn't make any difference from an 
> implementation perspective, but it just makes thing more understandable 
> from a violation report perspective.  This example is saying this 
> violation glitch and recovery can happen at any point in time during 
> simulation.
> 
>  
> 
> I do agree that the assignment to “one” is superfluous so I will remove 
> that:
> 
>  
> 
> *always_comb begin*
> 
>     not_a = !a;
> 
> *end*
> 
> * *
> 
> *always_comb begin : *a1
> 
>     *unique* *case* (1’b1)
> 
>        a     : z = b;
> 
>        not_a : z = c;
> 
>     *endcase *
> 
>   
> 
>  
> 
> *end*
> 
>  
> 
> In this example the unique-case is checking for overlap in the two 
> case-item selects.  When a first attains a new value of 1, this 
> unique-case may be executed while a and not_a are both true, so the 
> violation check for uniqueness will fail.  But since this violation 
> check is in the active region set the failure is not reported 
> immediately. After the update to not_a, process a1 will be rescheduled, 
> which results in a flush of the original error. After that, the 
> violation check will pass, and no error will be reported.
> 
>  
> 
> WRT to the clarification to the wording following “this unique-case may 
> be executed” I didn’t have any issues following it (remember I didn’t 
> initially write this) and kept the “may” assumption in mind as I read 
> the rest of the paragraph.  If you have any suggestion on how to clarify 
> this further I welcome your inputs.
> 
>  
> 
> All that said, I don't have too strong of an opinion about this so if 
> you _really_ want the initializations in there and will vote no 
> otherwise, I'll make your changes:')
> 
>  
> 
> Thanks, -Tom
-- 
--------------------------------------------------------------------
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.
Received on Fri Feb 15 09:44:25 2008

This archive was generated by hypermail 2.1.8 : Fri Feb 15 2008 - 09:44:47 PST