Re: [sv-ac] Review of 3033

Hi Dmitry,

On 05/30/11 01:14, Korchemny, Dmitry wrote:

> 17.5 Checker procedures
>
> Why not make all procedural assignments use current values, not sampled
> values? Then have assertions use the sampled values of all
> deterministic checker variables. This would be much more regular.
>
> [Korchemny, Dmitry] See my comment at the beginning.
>
> It would also fix your example: both a (the checker input) and x (the
> checker variable assigned in the always_ff) would use the sampled value,
> and the assertion would return the same value, no matter whether clk
> changes in the Active region (from RTL code) or the Reactive region
> (from the test bench).
>
> [Korchemny, Dmitry] Are you assuming that checker inputs are sampled? This is problematic even now for deferred assertions (see the preamble), and will also kill continuous and blocking assignments introduced in this proposal.
>
No, you are correct. The RHS expressions of non-blocking assignments
need to be sampled. However, I would still suggest that concurrent
assertions use the sampled values of the deterministic checker
variables. In most cases it doesn't matter. But if anyone tries to
derive a clock inside the checker, then the assertions would see
consistent values, even though the assertions are evaluated in the
second pass through the Observed region.

> Random checker variables would still be assigned
> in the beginning of the Observed region, and assertions would use the
> current values of these variables. In the case of Random assignments,
> the assume properties that determine the values chosen would use the
> sampled values of both the checker inputs, the deterministic checker
> variables, and of XMRs that are referenced. So the result would be
> consistent, no matter how many times we go around the "big loop" before
> we assign the random checker variables. This would also mean that we
> wouldn't need to get multiple values for random checker variables, even
> if they are solved multiple times in one time-step.
>
>
> 17.7.3
> I'm not sure whether we should put this example in or not. There's no
> way we could document all the different ways users could cause problems
> for themselves.
>
> [Korchemny, Dmitry] If I remember correctly, somebody asked me to insert this example. Let's discuss its usefulness in the meeting.
>
Should it be an error for a random variable to be constrained by assume
property constructs with different clocks? It seems troubling that a
random variable would be solved multiple times in one time step.

> Tom
>

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