[sv-ac] RE: review 1682

Hi Doron,

1. This would have to be the sampled value from the next time step.
Under the conditions stated in the document, the value in the observed
region should be the same as the sampled value in the next time step. We
could state it as sampled value in the next time step, however, that
requires shifting the evaluation of the assertion to the next time step
and possible performance penalty, or do what is stated now under the
hood and potentially have differences between simulators, both of which
I wanted to avoid.

2. Yes, that can be changed.

3. This proposal does not really need global clocking, I could remove it
from the example.

Thanks,
ed



> -----Original Message-----
> From: Doron Bustan [mailto:dbustan@freescale.com] 
> Sent: Thursday, February 22, 2007 11:53 AM
> To: Eduard.Cerny@synopsys.COM; sv-ac@eda-stds.org
> Subject: review 1682
> 
> Review of proposal 1682
> ==========================
> 
> 1. I don't have problem with restricting the use of these functions to
>    assertions, but then I think that $nextvalue should return 
> the sampled
>    value not the observed.
> 
> 2. Current definition of all other function return a 4 state variable
> 
>    e.g.  $isrising(expression) has the same effect as
>          !lsb(expression)&& $nextvalue(lsb(expression)).
> 
>    so if "a" is X in the current cycle and 1 in the next cycle, then
>    the result of $isrising(a) is Z. I recommend using the 
> same language
>    as in the definition of $rose etc.
> 
>    The Table should represent 4 states variables.
> 
> 3. First example use global clocking which is not there yet...
> 
> 
> 

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