Hi Mehdi, Francoise et al,
I have noted below some queries regarding the coverage mantis 2993 and 2953. Please consider these
for review in today's meeting when coverage mantis are discussed.
Regds,
Swapnajit
======================================
Queries on mantis 2993
======================================
Q1. In case of embedded covergroups, LRM says that anonymous type is defined. So, the
proposed syntax is not clear on how user can do this for embedded cgs? Consider the following example.
How does the user declare an instance "cg1_inst" inside "cg2" declaration?
class c1;
int a,b;
covergroup cg1;
A: coverpoint a;
B: coverpoint b;
endgroup
covergroup cg2;
cg1 cg1_inst = new; <<------- This will not be allowed as "cg1" is the instance name and not the type
X: cross cg1_inst.A, cg1_inst.B; <<----- So, in order to make this work, we need to think about some modification
endgroup
function new;
cg2 = new;
endfunction
endclass
Q2. Please consider the following example.
covergroup cg1 @ clk<mailto:cg1@clk>;
A: coverpoint a;
B: coverpoint b;
endgroup
covergroup cg2;
cg1 cg1_inst = new;
X: cross cg1_inst.A, cg1_inst.B;
endgroup
cg2 cg2_inst = new;
cg2_inst.sample();
In this case, how many items will be considered to belong to "cg2"? Should we consider only cross X as part of "cg2"? As per my
understanding, we should consider only the cross X as part of "cg2". This makes sense because "cg2" does not inherit the items
from "cg1" and just uses them using hierarchical references.
Q3. In the above example, modification of "cg2" as below should also be allowed.
covergroup cg2;
cg1 cg1_inst = new;
A: coverpoint aa; <<--------------- local coverpoint with same label
X: cross cg1_inst.A, cg1_inst.B;
Y: cross A, cg1_inst.A ; <<-------------- using local A and hierarchical A
endgroup
Q4. In the example given with Q2, when user does the instantiation of "cg1_inst" inside "cg2", will it start the sampling of this covergroup instance
such that sampling of a, b happens at every event on "clk"? OR the sampling of "cg1_inst" will only happen when sampling of "cg2_inst"
happens using sample() method as shown? This will determine the coverage numbers for covergroup type "cg1".
Q5. In the example given with Q2, if option.per_instance for "cg1" is set to 1, then will the instance-based coverage of "cg1_inst" be tracked and reported?
Please note "cg1_inst" is declared inside "cg2" just to enable "cg2" to access its coverpoints. This instantiation does not intend to create a separate
independent instance of "cg1". Is this the expected behavior?
Q6. Please look at the following example. This is similar to example shown in Q1 with the addition of one more instance of "cg1" outside
the scope of "cg2".
covergroup cg1 @ clk<mailto:cg1@clk>;
A: coverpoint a;
B: coverpoint b;
endgroup
covergroup cg2;
cg1 cg1_inst = new;
X: cross cg1_inst.A, cg1_inst.B;
endgroup
cg2 cg2_inst = new;
cg2_inst.sample();
cg1 cg1_inst_out = new; <<----------- Instance of "cg1" outside the scope of "cg2"
In this case, we need to understand the sampling semantics clearly. One interpretation of the sampling semantics may be:
- "cg1_inst_out" samples at every "clk" event independent of "cg2_inst".
- In addition, when "cg2_inst" samples using the sample() method, the coverpoints A, B in "cg1_inst" should also sample.
Please let me know your views on this.
Q7. Should we allow following ways of cyclic specifications?
covergroup cg1 @ clk<mailto:cg1@clk>;
A: coverpoint a;
B: coverpoint b;
cg2 cg2_in_1_inst = new; <<------- cg2 used in cg1
cross cg2_in_1_inst.cg1_inst A, A; <<---- accessing same item A
endgroup
covergroup cg2;
cg1 cg1_inst = new; <<----- cg1 used in cg2
X: cross cg1_inst.A, cg1_inst.B;
endgroup
cg2 cg2_inst = new;
cg2_inst.sample();
Q8. Should we allow hierarchical references to the internal instances e.g. "cg1_inst" and set their options procedurally? This is shown below.
cg2_inst.cg1_inst.option.weight = 5;
This will impact coverage numbers for "cg2_inst".
Q9. The syntax given in example is probably incorrect, The first item mentioned in the cross refers to the covergroup instance "pe" and
not any coverpoint inside "pe". Also the second item in the cross declaration i.e. "op.op.prec" is incorrect. If we assume it is
"op.op_prec" then also it is wrong because LRM doesn't allow cross of cross. This needs to be clarified.
covergroup stage_corners(ref bit ovr_bit, ref bit udr_bit, ref bit err ..., ref bit [71:0] op, ref bit[1:0] precision);
pipe_events pe = new(ovr_bit, udr_bit, err,...;
opcodes op = new(op, precision);
cross pe op.op.prec; <<-------- Issues here as noted above.
endgroup
Q10. Since we are allowing hierarchical names with cross, the crossbins syntax (shown below) will need modification.
Currently it allows only identifier or coverpoint identifier.
bins_expression ::=
variable_identifier
| cover_point_identifier [ . bins_identifier bin_identifier ]
===============================
Queries on mantis 2953
===============================
Q11. Please note the following LRM excerpt from section 27.3.
"The term generate scheme refers to the method for determining which or how many
generate blocks are instantiated. It includes the conditional expressions, case alternatives, and loop control
statements that appear in a generate construct.
Generate schemes are evaluated during elaboration of the design. Although generate schemes use syntax that
is similar to behavioral statements, it is important to recognize that they do not execute at simulation time.
They are evaluated at elaboration time, and the result is determined before simulation begins."
But in the proposed syntax for covergroup, the stopping criteria of the for-loop may involve an input argument of covergroup which
is fixed during runtime. This is shown below. So, the bin determination will happen during simulation rather than elaboration.
covergroup cg (int dw);
coverpoint data {
bins r2l [dw+1] = {generate for (ii = 0; ii <= dw; ii++) begin
(1 << ii) - 1
end} ;
}
endgroup
cg cgi = new(dw_a);
________________________________
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Mehdi Mohtashemi
Sent: Saturday, June 19, 2010 4:49 AM
To: sv-ec@eda.org
Subject: [sv-ec] Meeting Monday June 21 2010, 11:00am - 1:00pm (GMT-08:00) Pacific Time (US & Canda)
The next meeting of SV-EC will be on Monday June 21 2010,
Time: 11:00am - 1:00pm (GMT-08:00) Pacific Time (US & Canda).
Toll Free Dial In Number: (888)635-9997
***************************************
PARTICIPANT CODE: 0536987#
***************************************
International Access/Caller Paid Dial In
Number: (763)315-6815
[also updated on http://www.eda.org/sv-ec/Minutes.html ]
Agenda:
1. Review IEEE patent policy
------------------------------------------------------
http://standards.ieee.org/board/pat/pat-slideset.ppt
2. Approval of previous meeting minutes:
------------------------------------------------------
June 7 2010 meeting minutes
http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_May_24_2010_Minutes.txt
3. Estimates for the top 25 issues and categories:
------------------------------------------------------
Review and finalize the time estimates to be proivded to p1800WG on June 24 2010.
The results are in spreadsheet, uploaded onto sv-ec site:
http://www.eda.org/sv-ec/Minutes/svec_top25_June7_2010result.xlsx
estimates of hours
top 25
Id
Number of Votes
weighted vote
Summary
Degrees of difficulty
4
1
2848
7
159
Is it legal to assign an interface containing class declaration to a virtual interface
med
12
2
3002
8
125
Aspect Oriented Programming (AOP) features
High
1
3
3046
8
112
Dotted names within inlined constraints
Low
16
4
1356
6
112
Multiple Inheritance
High
2
5
3001
9
102
Proper Polymorphic behavior of instantiation
low
3
6
2999
7
99
Class Handle reference inside of Constraints
med
5
7
3003
6
98
Constraint Composition
High
8
8
3082
7
96
Ambiguity resolution (see slide 10 for examples of parts of the Standard that have been interpreted differently by different simulators) [The first 3 items on page 10, the other 4 on this page are more trivial]
4
9
2845
4
84
virtual interface type checking versus interface type that had been defparam'ed
high
0.5
10
2956
4
76
clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5)
low
3
11
2505
4
76
class select: what is allowed after the dot?
low
4
12
2735
4
73
Ballot Comment #48: Chaining of method calls
med
1
13
1706
4
72
Meaning of static prefix for virtual interface assignments
2
14
2488
4
69
Are virtual method calls legal within class constructors?
med
2
15
2112
6
69
Remove restrictions on NBA assigments to class members
med
2
16
3028
6
68
constraints for unique array elements.
Med
2
17
2950
4
67
virtual method prototype matching
low
1
18
2794
4
64
Clarify queue methods return status
low
4
19
2993
4
63
Cross cover points across different cover groups
med
0.5
20
1442
3
63
Clocking blocks legal in modports, missing from text description in 20.9
6
21
2953
6
61
Algorithmic generation of covergroup bin contents
high
0.5
22
1349
5
61
fork/join_none: what if parent thread terminates without blocking statement?
0.5
23
2949
4
60
LRM is silent about the semantics of referencing a clocking block output
low
4
24
2451
6
58
Omitting body defaults
med
4
25
2987
6
56
Soft Constraints
med
92
total
46 (2hr sessions)
0.5
26
3006
5
55
LRM doesn't say explicitly what should happen if null pointer is randomized
low
4
27
3004
5
55
Ability to declare/qualify classes/methods/variables/constraints final
med
2
28
2998
4
55
Solve Before enhanced
low
4
29
2117
3
52
Allow extending of covergroups in classes
high
4
30
No Mantis 6
5
51
(3) Allow reuse of enumerated names (slide 31)
0.5
31
2928
3
50
ambiguous restriction on function calls in constraint expressions
low
4
32
2787
3
50
reference via scope operator to parametrized superclass item
med
2
33
2972
3
49
add class constructor/method, task/function overloading
High
2
34
2996
4
49
Method overloading
High
0
35
2988
2
48
Defaults Constraints
med
0
36
No Mantis 4
2
47
(1) AOP when-inheritance (slide 31)
23
total
11 sessions
4. Review/resolve sv-ec mantis items
-------------------------------------------------------------------------------------
Several mantis items were marked as trivial, we can get started on resolution:
2956, 1442, 1349, 2949, 3006, 2928,
PLEASE send in any manits items that you think we can start reviews/resolution.
5. Next meetings June and July 2010
-----------------------------------------------------
[July 5th is holiday in US]
Monday July 19 2010 11:00-1:00pm [tentative]
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Jun 21 06:13:32 2010
This archive was generated by hypermail 2.1.8 : Mon Jun 21 2010 - 06:13:51 PDT