Ah, ok. So it looks like my understand was correct, and I don't need to add yet more language to the proposal to cover sequences. I'll add a 'cover property' to your covergroup example, and I think that should work well for a clarification to 2110. Thanks! (BTW-- I wonder if we should open a small item to clarify the LRM on this matter? Though it's probably a little late in the process to add anything.) -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Thomas Thatcher Sent: Tuesday, February 05, 2008 5:17 PM To: Seligman, Erik Cc: Korchemny, Dmitry; sv-ac@server.eda.org Subject: [sv-ac] Re: Request: example of use of covergroup in combination with cover statements? Hi Erik, I can't find anything in the LRM to say one way or another, so I did an experiment: In our simulator, it does seem that the sequence is not executed unless it is referenced. The example code is attached. The function say_hello() will be called only if the cover property line is uncommented. Tom Seligman, Erik wrote: > I think my area of confusion is more basic. Forget about 2110 for the > moment. > > The question is: if a sequence is declared, but not referenced in an > assertion statement, does it do anything? > In particular, does it activate a covergroup? > > I thought a sequence had to be used in an assertion statement in order > to cause any actions, including activating a covergroup. But I > haven't dealt with covergroups, or with sequences outside an assertion > context, so that may be a misunderstanding. I agree, if a sequence > does stuff just by being declared, then we need to make them execute > for each loop iteration just like assertion statements. > > > -----Original Message----- > From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM] > Sent: Tuesday, February 05, 2008 3:03 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, > > 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Feb 6 07:22:13 2008
This archive was generated by hypermail 2.1.8 : Wed Feb 06 2008 - 07:22:34 PST