RE: [sv-ac] ballot result on 2088

Hi Dmitry and Tom, 

I'm not sure I understood how this works,
consider this example:

checkvar logic [0:10] cv = 0;
always_check @(clk)
  cv <= cv + inp1;
cover property (evt1 ##1 (evt2 && cv>10,cg.sample(cv)));

which value of "cv" is seen inside the covergroup ? is it the preponed
value seen by the assertion or the updated value assigned in the
Observed region ?
I would like this to be the preponed value so sampling of "old" values
from assertions would be enabled the same as it is for modules (see
mantis 2149)


Another point:

is it possible to write this code for calling .sample() from within
always_check ? 

           function logic f_dummy;
             cg.sample();
             return 1;
          endfunction

          checkvar dummy;
          always_check @(posedge clk)
	  dummy <= f_dummy();

if so then it should be defined, in my opinion this can be disallowed.


Yaniv


-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Korchemny, Dmitry
Sent: Monday, January 28, 2008 16:01
To: Thomas.Thatcher@sun.com; sv-ac@eda.org
Subject: RE: [sv-ac] ballot result on 2088

Hi Tom,

Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Thomas Thatcher
Sent: Thursday, January 24, 2008 2:00 AM
To: sv-ac@server.eda.org
Subject: Re: [sv-ac] ballot result on 2088

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.
[Korchemny, Dmitry] The intention was about those constructs where
sampled values of variables are expected, e.g., concurrent assertions
use sampled values of their arguments. It is written in Mantis 1900
16.18.6.1, page 21, that "All variables participating in the right-hand
side of a checker variable assignment are sampled, except the continuous
check bits". In all other cases unless it is stated explicitly, the
current values are used. I will clarify the statement in Mantis 1900
16.18.6.2:

"Sequential check bits (see 16.8.5.1) are sampled in the Preponed
region, as the regular variables are." -> "Sequential check bits (see
16.8.5.1) referenced in concurrent assertions and in the right-hand side
of the checker variable assignment, are sampled in the Preponed region,
as the regular variables are."

I also added a clarification to 16.4:

"The values of variables used in assertions are sampled in the Preponed
region of a time slot, and the assertions are evaluated during the
Observe region." -> "The values of variables used in assertions are
sampled in the Preponed region of a time slot (except for continuous
check bits in checkers, which are not sampled, see 16.18.6.2), and the
assertions are evaluated during the Observe region."

     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.

[Korchemny, Dmitry] This is true for all variables.

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

[Korchemny, Dmitry] I don't think it is possible at all. sample() is
void method, therefore it cannot be used in the right-hand side of the
assignment (as far as I understand it).

     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 [Korchemny, Dmitry]
No, this is not the case, see my comment above. )

     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.

[Korchemny, Dmitry] I like the idea to be able to sample CG values in
the Preponed region, but I don't think it is directly related to
checkers and may be subject of a separate proposal (targeted for one of
the future releases).

Have I forgotten any cases?

[Korchemny, Dmitry] I don't see other use cases, either, therefore I
believe that your CG definition in checkers is sound.

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.

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



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