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. 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. 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 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) 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. Have I forgotten any cases? 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.Received on Wed Jan 23 16:00:33 2008
This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 16:01:02 PST