[sv-ac] Re: Request: example of use of covergroup in combination with cover statements?

Hi Erik,

Interesting . . .  My understanding was that the sequence would be 
evaluated for every loop iteration, just as a cover property would be.
Are you saying that the sequence would not be replicated for every loop 
iteration UNLESS it is referenced by a cover property??? (I think my 
brain just did a divide-by-zero).  Or are you saying that sequences are 
never replicated?  Either way, this is another non-intuitive feature of 
checkers in loops which will have to be explained.

My thought was, that for every iteration of the enclosing loop, the 
sequence would be evaluated with a different bit of the valid array, and 
a different slice of the opcodes array.  Each evaluation could 
potentially trigger the covergroup.  The custom sample() method would be 
passed the slice of the array that was used to evaluate the sequence in 
the current loop iteration.

Tom

Seligman, Erik wrote:
> Thanks Tom--
> One issue is that right now, all your examples would be identical for 
> all iterations of an enclosing loop in the current definition of 2110, 
> as only a 'cover property' is effectively replicated.
>  
> But I'm not sure I understand your last example.  If a sequence is 
> declared, but does not appear in a verification statement, does it still 
> get executed and trigger covergroups?  If not, adding a 'cover property 
> op_accept' might make it a good example for this proposal.
>  
>  
> 
> ------------------------------------------------------------------------
> *From:* Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM]
> *Sent:* Tuesday, February 05, 2008 12:29 PM
> *To:* Seligman, Erik
> *Cc:* Korchemny, Dmitry; sv-ac@eda.org
> *Subject:* Re: Request: example of use of covergroup in combination with 
> cover statements?
> 
> Hi Erik,
> 
> 
> The first example in my 2088 proposal shows a covergroup which is 
> triggered by an (@*posedge* clk) event.  If the checker containing this 
> covergroup were placed in a precedural loop, it would be executed only 
> once per clock tick, while all the other assertions will be executed 
> once for every pass of the enclosing loop.  This will be a little 
> non-intuitive for new users, so it probably should be explained in the text.
> 
> The second example in the 2088 proposal shows a covergroup which is 
> triggered by a call to the default *sample()* method.
> 
> The third example might be the most useful.  This shows a covergroup 
> triggered by a custom *sample()* method. It should be easy to modify 
> this example so it could be placed in a loop.
> 
> *checker* op_test (*logic* clk, vld_1, vld_2, *logic* [3:0] opcode)
> 
> *    checkvar* *bit* [3:0] opcode_d1;
> 
> 
> *    always_check* @(*posedge* clk) opcode_d1 <= opcode;
> 
> 
> *    covergroup* cg_op *with* *function* sample(*bit* [3:0] opcode_d1);
> 
>         cp_op : *   coverpoint* opcode_d1;
> 
> *    endgroup*:cg_op
> 
>     cg_op cg_op_1 = *new*();
> 
> *    sequence* op_accept;
> 
>         @(*posedge* clk) vld_1 ##1 (vld2, cg_op_1.sample(opcode_d1));
> 
> *    endsequence*
> 
> *endchecker*
> 
> 
> Suppose the above checker is placed in a loop where vld1 and vld2 are 
> bits of arrays, and opcode is a slice of a two-dimensional array.  The 
> checker portion could be written like this (I'll take out vld2 to avoid 
> the procedural code in the checker).
> 
> *checker* op_test (*logic* clk, vld_1, *logic* [3:0] opcode)
> 
> *    checkvar* *bit* [3:0] opcode_d1;
> 
> *    covergroup* cg_op *with* *function* sample(*bit* [3:0] opcode_d1);
> 
>         cp_op : *   coverpoint* opcode_d1;
> 
> *    endgroup*:cg_op
> 
>     cg_op cg_op_1 = *new*();
> 
> *    sequence* op_accept;
> 
>         @(*posedge* clk) (vld1, cg_op_1.sample(opcode));
> 
> *    endsequence*
> 
> *endchecker
> *
> 
> *...
> logic [3:0] valid;
> logic [3:0] opcodes [0:3];
> *
> 
> *for (i=0; i<=3; i++) begin
>     op_test my_op_test (.clk(clk), .vld1(valid[i]), .opcode(opcodes[i]));
> end
> *
> 
> 
> Does this help?
> 
> Tom
> 
>  
> Seligman, Erik wrote:
>> Tom-- can you send me a short fragment giving an example of what you 
>> were alluding to in the meeting?
>> I couldn't find something like this in 2088, or in the current LRM.
>>  
>> Thanks!
>>  
>>  
>>
>> *Erik Seligman*
>>
>> ***Formal Verification Architect*
>>
>> *Corporate Design Solutions*
>> *Design Technology and Solutions*
>>
>> *Intel Corporation*
>>
>> M.S. JF4-402                  
>> 2111 NE 25^th Ave
>> Hillsboro, OR 97124
>>
>> Phone:   (503) 712-3134
>>
>>  

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.