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

From: Thomas Thatcher <Thomas.Thatcher_at_.....>
Date: Tue Jan 08 2008 - 15:14:57 PST
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.


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.

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.


Received on Tue Jan 8 15:16:21 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 08 2008 - 15:16:52 PST