Re: [sv-ac] ballot result on 2088

From: Thomas Thatcher <Thomas.Thatcher_at_.....>
Date: Wed Jan 23 2008 - 16:00:10 PST
Hello everyone,

I'm trying to work through the different scheduling cases:
Here is what I know so far:

1.  Continuous check bits are never sampled.  (Mantis 1900, 16.18.6.2)
     They are updated by the continuous assignment in the Observed region
     (Mantis 1900, 16.18.6.4)
2.  Sequential check bits are sampled in the Preponed region, as the
     regular variables are. (Mantis 1900 16.18.6.2)
     Dmitry,
     This statement is kind of broad:  Does this mean that any reference
     to a sequential check bit (from a final block, or a cover group, for
     example) will see the sampled value?  Or is this statement just
     talking about what happens in the original constructs allowed in a
     checker?  i.e. Assertions, continuous check bit assignments, and
     non-blocking check bit assignments.

     The sequential check bits are also performed in the observed region
     (Mantis 1900, 167.18.6.4)

3.  Other variables are not necessarily sampled, unless they appear in
     an assertion, or in a checker assignment.

4.  The covergroup usually samples its arguments at the time when it is
     triggered.  The covergroup can be triggered by an event, or by a
     function call.

Here is a list of possible cases:

1.  The covergroup sampling event is @(posedge clk).  As long as clk is
     not ultimately driven by a non-blocking assignment, and any
     checker inputs are ultimately driven by non-blocking assignments,
     there should be no race condition, and the covergroup will always
     see the old values of any signal that it observes (whether checker
     input, continuous check bit, or sequential check bit)

     if clk is ultimately driven by a non-blocking assignment, or a
     checker input is driven from a blocking assignment, then there will
     be a race condition.  The value of the checker input will be
     non-deterministic. However, this is no different from what occurs
     outside a checker.
     There still will be no race for check bit values, because these
     are not updated till the observed region.

2.  The covergroup sampling event is a function.  The function could be
     called from an procedural block, from an assertion action block,
     or from a sequence match item.

     a) Dmitry, do you think it's possible to call a sampling function
     from an always_check block?  It would probably not be easy.  It
     would probably have to be done like this, because you allow only
     assignments within an always_check:

	checkvar dummy;
	always_check @(posedge clk) begin
		dummy <= cg.sample();
	end

     b)  If the sample() method is called from an assertion action block
     or from a sequence match item, the processing occurs in the reactive
     region. There is no race condition, but the covergroup will always
     observe the updated values of any variables, including checker
     inputs, continuous check bits, or sequential check bits.
     (Unless Dmitry confirms above that he intended any reference to
     check bits to use the Preponed sampled value)

     Again, this behavior is consistent with what already exists.


Do we want to specify that any covergroup appearing in a checker will 
always see Preponed region sampled values?  This means that covergroup
constructs will work differently inside a checker than outside a checker.

Have I forgotten any cases?

Thanks,

Tom
John Havlicek wrote:
> Hi Folks:
> 
> Our ballot on 2088 failed due to negative vote.
> 
> See the results below.
> 
> J.H.
> 
> ----------------------------------------------------------------------------------
> Ballot on Mantis 2088
> 
> - Called on 2008-01-15, final ballots due by 2008-01-21 T 23:59-08:00.
> 
> yv[xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
> yv[xxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
>  n[----------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
> yv[xxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
>  t[xxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
> yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
> nv[xxxxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
>  n[------------------------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
>  n[---------x------------x--xxx.....................] Joseph Lu (Altera)
>  v[xxxxxxxxxxxxxxxxxxx..............................] Johan Martensson (Jasper)
>  n[---------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
> yv[xxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
> yv[xxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
>  n[-------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
> yv[xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
> yv[xxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
>    |------------------------------------------------- attendance on 2008-01-15
>  |--------------------------------------------------- voting eligibility for this ballot
> |---------------------------------------------------- email ballots received
> 
>         Legend:
>                 x = attended
>                 - = missed
>                 r = represented
>                 . = not yet a member
>                 v = valid voter (2 out of last 3 or 3/4 overall)
>                 n = not a valid voter
>                 t = chair eligible to vote only to make or break a tie
> 
> ----------------------------------------------------------------------------------
> Rationale for Negative Vote
> 
> [MK]
> 
> I vote 'no' as I am not sure if this proposal handles all the sampling
> issues related to covergroups. I am not completely familiar with
> covergroups but I do see that in the LRM there are multiple ways to
> sample the variables which are used in covergroups. The 1900 also talks
> about sampling of checker variables. E.g. in 16.18.6.2 it says:
> 
> 
> Sequential check bits (see 16.8.5.1) are sampled in the Preponed region,
> as the regular variables are. Continuous check bits (see 16.18.6.1) are
> never sampled either in assignments (see 16.18.6.1) or in concurrent
> assertions.
> 
> What will happen if these check bits are used in covergroups ? The new
> proposal does not talk about it.
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jan 23 16:00:33 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 16:01:02 PST