RE: [sv-ac] RE: call to vote 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: 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.

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