RE: [sv-ac] 1995 assertions in loops questions

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Thu Dec 06 2007 - 08:41:26 PST
Hi Erik,
 
if there is one eval per iteration, then the coverage will not be able
to distinguish which iterations had a success and which did not.
However, since the indices can be stored in local variables and then
dumped to a covergroup (see mantis 2149 for passing args to sample()),
the issue may not be a problem provided that cg's are allowed in
checkers as per your other proposal.
 
Best regards,
ed
 


________________________________

	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Seligman, Erik
	Sent: Thursday, December 06, 2007 10:30 AM
	To: Lisa Piper; Bassam Tabbara
	Cc: sv-ac@eda.org
	Subject: RE: [sv-ac] 1995 assertions in loops questions
	
	
	Yeah, things would be a lot easier if my initial attempt to
describe this as a rewrite-as-generate had not been shot down!
	 
	Anyway, here's what I think I'll do in response to Lisa's
points.  Tell me if you guys have any objections or better suggestions:
	 
	- Add a change to section 16.14.3 explicitly stating how covers
in loops are counted: as one eval attempt per loop iteration.
	- Add changes to the VPI section to have concurrent assertions
possibly point to a list of iterators.
	- Not add any specific statements regarding how tools handle
these for debug.
	
	
________________________________

	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper
	Sent: Wednesday, December 05, 2007 5:50 PM
	To: Bassam Tabbara; Seligman, Erik
	Cc: sv-ac@server.eda.org
	Subject: RE: [sv-ac] 1995 assertions in loops questions
	
	

	But generates create unique assertions.  Assuming a
for-generate, there is one assertion for each for-index.  This proposal 

	states "It is still considered a single assertion, not a set of
assertions for each iteration, so no loop index is used."  That would
need to change.

	Lisa

	 

	
________________________________


	From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
	Sent: Wednesday, December 05, 2007 8:42 PM
	To: Lisa Piper; erik.seligman@intel.com
	Cc: sv-ac@eda.org
	Subject: RE: [sv-ac] 1995 assertions in loops questions

	 

	I think same as generate.

	 

	Thx.

	-Bassam.

	 

	 

	
________________________________


	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Lisa Piper
	Sent: Wednesday, December 05, 2007 4:02 PM
	To: Seligman, Erik
	Cc: sv-ac@eda.org
	Subject: RE: [sv-ac] 1995 assertions in loops questions

	 

	 

	
________________________________


	From: Seligman, Erik [mailto:erik.seligman@intel.com] 
	Sent: Tuesday, December 04, 2007 10:26 AM
	To: Lisa Piper
	Cc: sv-ac@eda.org
	Subject: RE: [sv-ac] 1995 assertions in loops questions

	 

	Those are good questions.

	 

	As for the statistics counters:  can you point me to the Manits
ticket or LRM section that describes these in detail?  A search for
'statistics' in Draft 4 only gives me 3 occurrences, none of which talks
about these in any detail.  If it's necessary to state something
explicit, my suggestion would be that we consider the total number of
attempts to be multipled by the loop iterations.  

	Lisa Piper >>>] I think the information you are looking for is
described in 16.14.3.  Do a search for "attempt" in chapter 16. VPI for
coverage is in the chapter on code coverage. Specifically 39.5 VPI
Coverage (I'm not sure why the title of the chapter is code coverage
instead of coverage). 

	 

	Debug-wise, I think most reasonable tools will treat the
assertion as a set of assertions, one per loop iteration, for reporting
purposes.  But we don't need to specify this in the standard-- perhaps
some vendors will come up with other clever methods.  

	 

	I haven't thought a whole lot about VPI issues: I was assuming
that these would be handled like any other assertion in the VPI.  But I
see your point, that the iterators are now special objects with unique
status for the assertion.  Do you think we should modify the diagram in
36.43 to add a connection to a set of vpiAssertionIterator variables or
something?

	[Lisa Piper >>>] No idea.  I am just learning VPI and don't know
much about how it is used in practice.  But if we want to view it as a
single assertion then I would think you'd want one counter. For a
specific failure message though, I would think you'd need to know which
iterator it was, which is why I thought the automatic error message that
is printed should have this information.

	 

	
________________________________


	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper
	Sent: Monday, December 03, 2007 7:33 PM
	To: Seligman, Erik
	Cc: sv-ac@server.eda.org
	Subject: [sv-ac] 1995 assertions in loops questions

	Hi Erik,

	I finally took the time to review your proposal for assertions
in for loops. You state "It is still considered a single assertion, not
a set of assertions

	for each iteration, so no loop index is used."  What happens to
the statistic counters?  If the loop executes 5 times, for example, is
this 5 attempts of the same assertion?  So in this case, the number of
attempts is not equal to the number of clocks of the assertion?   Have
you given though to debug of these?  Should the message be required to
print the loop iterator value(s) for example?  While the user can create
a custom message, it might be nice if this were automated.  Have you
thought about VPI callbacks?  I would think that the user data could
supply the loop iterators, but I'm not an expert on VPI callbacks.

	Lisa

	
	-- 
	This message has been scanned for viruses and 
	dangerous content by <http://www.mailscanner.info/> MailScanner,
and is 
	believed to be clean. 

	
	-- 
	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 <http://www.mailscanner.info/> MailScanner,
and is 
	believed to be clean. 
	-- 
	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 Thu Dec 6 08:42:03 2007

This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 08:42:12 PST