RE: [sv-ac] ballot result on 2088

Thanks Tom and Dmitry,

I understand this works inside checker the same as inside module which
is good,
I have also reviewed the new proposal and it looks good and the two new
examples explains this well.

one minor editorial note: remove one of "the the" from the following
text in the proposal.

 IF Mantis 2089 is accepted
A covergroup may also be triggered by a procedural call to its sample()
method (see 18.8). Inside a checker,
the the call


Yaniv


-----Original Message-----
From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM] 
Sent: Monday, January 28, 2008 23:56
To: Fais Yaniv
Cc: Korchemny, Dmitry; sv-ac@eda.org
Subject: Re: [sv-ac] ballot result on 2088

Hi Yaniv,

Thanks to Mantis 2149, you are now able to override the sample() method
to allow arguments.  Your example would get the sampled value, because
the sampled value is passed to the sample() method.

However, if you used the default sample() method, with no arguments, the
covergroup would see the current values of it's covergroups and sigals
when it is executed.  So, there's going to be a right way and a wrong
way to write covergroups. Note that this works the same way as it would
in a module.


Regarding calling of the sample() method from a function called from an
always_check.  What is the problem with that?  It's pretty much
equivalent to calling the sample() method from an always procedure in a
module.

Tom
Fais Yaniv wrote:
> 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.