RE: [sv-ac] RE: call to vote on 2088

Hi Tom,

The limitations are usually not explained in the LRM, therefore I would
drop "This is to prevent race conditions within the checker." And
certainly not in the example comment: " Would cause a race condition if
allowed."

Otherwise, I am OK with this version.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Thomas Thatcher
Sent: Friday, January 11, 2008 4:11 AM
To: Korchemny, Dmitry
Cc: john.havlicek@freescale.com; sv-ac@server.eda.org
Subject: Re: [sv-ac] RE: call to vote on 2088

Hi Dmitry,

I have put the following text into the proposal.  Does this solve the 
problem?

The new proposal, 2088_covergroups_20080110.pdf has been uploaded.

Tom

The clocking event which controls the covergroup sampling may not 
reference or depend on a checker variable.
This is to prevent race conditions within the checker. For example:

   checker my_check_w_clock_div(logic clk, active);
     checkvar bit clk_div2 = 1'b0;
     checkvar bit a;

     assign a = active;

     always_check @clk clk_div2 <= !clk_div2;

     // Illegal: covergroup may not reference checker variables in 
clocking
     // event. Would cause a race condition if allowed.
     covergroup cg1 @(clk_div2);
       // Reference to a;
       ...
     endgroup
   endchecker : my_check_w_clock_div



Korchemny, Dmitry wrote:
> 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: Wednesday, January 09, 2008 1:15 AM
> To: Korchemny, Dmitry
> Cc: john.havlicek@freescale.com; sv-ac@server.eda.org
> Subject: Re: [sv-ac] RE: call to vote on 2088
> 
> Hi Dmitry,
> 
> This same ambiguity already exists.  That is why we have rules for 
> race-free design.  Here are the rules:
> 
> 1.  For all combinational logic, use assign statements or procedural 
> blocking assignments
> 2.  For all sequential logic use non-blocking assignments.
> 
> Consider your example implemented in a module:
> 
>      bit newclock = 0;
>      bit a, b;
> 
>      assign a = regular_var_1;
>      assign b = regular_var_2;
> 
>      always @clk newclock = !newclock;
> 			//     ^ Need blocking assign here
> 
>      covergroup cg1 @(newclock);
>      ... // References to a and b
>      endgroup
> 
> 
> To make the example race-free, the always block that generates the 
> newclock variable must use a blocking assignment to assign to
newclock. 
> This assures that the event on newclock takes place in the current 
> active region, before the flip-flops which eventually drive 
> regular_var_1 and regular_var_2 are updated with new values.  Thus,
the 
> covergroup will sample the old values of a and b.
> 
> Unfortunately, in checkers, there is no blocking assignment allowed
for 
> checker variables.  This means that it is impossible to implement your

> example in a race-free manner.  The only way to do it is to implement 
> the clock divider for newclock externally with a blocking assignment, 
> and then pass in newclock as a parameter to the checker.
> 
> It would be nice if covergroups outside of programs used the sampled 
> values, but I think that's too big a change to put in now.
> 
> [Korchemny, Dmitry] One of the reasons of introducing checker
variables
> was to make them race-free. And indeed their values at the end of the
> Observed region are always unambiguously defined. The problem here is
> that we are trying to access the variable values somewhere in the
middle
> of the Observed region.
> 
> There are several options how to deal with this problem, e.g.:
> 
> 1. Disallow events dependent on checker variables for covergroups.
> Regular events should be enough for all practical purposes. E.g., if
the
> covergroup in the above example is controlled by a regular event, say
> @clk, or @(posedge clk), where clk is a regular signal, there will be
no
> race conditions (except of the race conditions that you mentioned
above,
> but this is not different from the regular usage mode). The events
> dependent on checker variables arise only when you model the event
> itself in the checker. Though this is useful for FV modeling, I don't
> think it will be very common in coverage collection.
> 
> 2. Extend AAR to covergroups and modify the simulation semantics
> appropriately: require that the checker variables from the control
event
> depend on the variables referenced in the covergroup. It is a cleaner
> solution, but introduces unnecessary complications.
> 
> 3. Recommend to the user to always use strobe = true for covergroups
> with events dependent on checker variables. It should be a user
> responsibility to do it correctly. But this should be explicitly
> mentioned in the proposal.
> 
> ...
> 
> I prefer the first option since it is the simplest one and answers 99%
> of the practical needs. It may be relaxed in the future without any
> backward compatibility problems. 
> 
> Other items:
> 
> 1.  Reference added to covergroup section 18.3.
> 2.  Added the period after the list item.
> 3.  Colored the inserted section blue.
> 4.  Changed the text to the following:
>      "A covergroup may reference any variable visible in its scope,
>      including checker formal arguments and checker variables."
>      (The intent of the sentence was to explicitly allow covergroups
to
>      reference checker variables)
> 5.  I think I fixed the fonts, but I may have caused other problems.
> 6.  Fixed.
> 
> [Korchemny, Dmitry] This is OK with me.
> 
> Tom
> 
> Korchemny, Dmitry wrote:
>> I vote "no" on 2088.
>>
>> Major comments:
>>
>> * Covergroup sampling in checkers require some clarification. In case
>> when the clocking event refers to a checker variable, it will happen
> in
>> the Observed region, and some checker variable will have their old
>> values (those who evaluate before the variable in the clocking event)
>> and others will have the new values already assigned.
>>
>> E.g.,
>>
>> checkvar bit newclock = 0;
>> checkvar bit a, b;
>>
>> assign a = regular_var_1;
>> assign b = regular_var_2;
>>
>> always_check @clk newclock <= !newclock;
>>
>> covergroup cg1 @(newclock);
>> ... // References to a and b
>> endgroup
>>
>> Here you cannot tell what the evaluation order is: newclock, a, b; a,
> b.
>> newclock, etc.
>>
>> Minor comments and friendly amendments:
>>
>> * Need to insert references to subclauses describing the covergroups.
>>
>> Page 2.
>>
>> * "Covergroup declarations and instances" -> "Covergroup declarations
>> and instances." - missing the trailing dot.
>>
>> * The added text in the new section should be in blue.
>>
>> * A covergroup may reference either input signals of the checker or
>> checker variables, including free variables."
>>
>> The term "input signals of the checker" is not defined. Is the
> intention
>> about the input formal arguments? Also, why global variables defined
>> elsewhere are disallowed in the covergroup?
>>
>> * Need to fix fonts throughout the document: Arial appears in many
>> places instead of Times New Roman.
>>
>> Page 3.
>>
>> * "bins active = { [1'b1 };" -> "bins active = { 1'b1 };"
>>
>> Thanks,
>> Dmitry
>>
>> -----Original Message-----
>> From: John Havlicek [mailto:john.havlicek@freescale.com] 
>> Sent: Monday, December 31, 2007 7:00 PM
>> To: sv-ac@eda.org
>> Cc: Bustan, Doron; eduard.cerny@synopsys.com;
> yaniv.fais@freescale.com;
>> john.havlicek@freescale.com; Korchemny, Dmitry;
>> Manisha_Kulshrestha@mentor.com; johan.martensson@jasper-da.com;
>> piper@cadence.com; Seligman, Erik; bassam.tabbara@synopsys.com;
>> thomas.thatcher@sun.com
>> Subject: call to vote on 2088
>>
>> Hi Folks:
>>
>> Since my last call to vote on 2088 did not reach the reflector,
>> I am calling for a new, 1-week vote.  This is that call.
>>
>> I have copied the eligible voters individually because the 
>> reflector seems unreliable.
>>
>> Please send your ballot both to the reflector and to me 
>> individually.
>>
>> Please vote if you are eligible.  See the details below.
>>
>> J.H.
>>
>>
>
------------------------------------------------------------------------
>> ----------
>> Ballot on Mantis 2088
>>
>> - Called on 2007-12-31, final ballots due by 2008-01-07 T
23:59-08:00.
>>
>>  v[xxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan
> (Intel)
>>  v[xxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny
>> (Synopsys)     
>>  n[--------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani
>> (Synopsys)
>>  v[xxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais
>> (Freescale)
>>  t[xx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek
>> (Freescale - Chair)
>>  v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny
>> (Intel - Co-Chair)
>>  v[xxx-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[xxxxxxxxxxxxxxxxx..............................] Johan Martensson
>> (Jasper)
>>  n[-------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller
>> (Freescale)
>>  v[xxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper
> (Cadence)
>>  v[xxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman
>> (Intel)
>>  n[-----x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor
>> Graphics)
>>  v[xxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara
>> (Synopsys)
>>  v[xxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun
>> Microsystems)
>>    |----------------------------------------------- attendance on
>> 2007-12-18
>>  |------------------------------------------------- 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
>> ---------------------------------------------------------------------
>> 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.