Subscribe: Comments on: Checks or Functional Coverage?
http://www.verilab.com/blog/2007/07/checks-or-functional-coverage/feed/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
check  checkers  checks  code coverage  code  coverage  fifo  functional coverage  functional  functionality  important  part  point  write 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments on: Checks or Functional Coverage?

Comments on: Checks or Functional Coverage?



Verilab



Published: Wed, 21 Feb 2018 19:59:58 +0000

 



By: Hamilton

Mon, 12 Nov 2007 06:40:07 +0000

Hi David, Thanks for starting this interesting conversation! I've posted more thoughts on how coverage and checks can play off of and reuse one another at: http://metricdrivenflow.blogspot.com/2007/11/reusing-functinal-coverage-components.html Hamilton



By: Manmohan Singh

Fri, 26 Oct 2007 09:39:45 +0000

Hi David, Nice & insightful comments I like when you said "So functional coverage might be the icing on the cake, but it will never be the cake" I completely agree with you that checkers are an integral part of verification and of course with add on functional coverage the life of Verification Engineer has slightly got better :-) Manmohan



By: sergio

Fri, 20 Jul 2007 21:23:49 +0000

Hi David thanks for putting this in clear words. And I totally I agree with you: coverage is important but checkers are by far more important. Better to write a check for a FIFO and hope that it is triggered, rather then having a functional coverage point on "FIFO full" and hope that you also have a check in place to actually detect wrong behavior. At least in theory ... In practive, we must admit that detecting a missing checker in a testench code review is difficult but possible, whereas manual detection of a missing stimuli is simply impossible in most cases. Now I want to plant 2 seeds for further discussions: 1. A big part of a testbench, including checkers, is effectively (re)modeling the verified functionality (you need that to compute your expected behavior) and part is dealing with modeling the enviroment (e.g., constrains for stimulus generation). Functional coverage and code coverage help to detect issues with insufficient stimulus generation. What helps you in detecting issues with insufficient or wrong checkers ? 2. We all know that code coverage is not enough and that functional coverage gives more relevant information on what functionality has been actually exercised. But look at this from the technology point of view. A tool for collecting code coverage needs to be quite smart and have powerful technology to be able to instrument RTL code in a smart way. On the other hand, when it comes to functional coverage, the smart part is really about understanding what are the important coverage points and then coding them up. What is the tool doing? Seems to me not much more then collecting data and have a nice GUI to display greens and reds. Sergio



By: Janick Bergeron

Tue, 17 Jul 2007 17:15:19 +0000

Interesting and important discussion and Thanks for the book plug! I think you are correct that there isn't much talk about checks nowadays because there is little new in that area. Functional coverage makes for much better slideware :-) > if you had to run a testbench that had checks but no > functional coverage, or a testbench that had functional > coverage but no checks, which would be better? Actually, neither. Without some form of coverage, how do you know that you have actually exercised and confirmed that the checked functionality was correct? For example, you may have a check that a FIFO, when full, stops accepting write cycles, but if you never fill the FIFO, the check is useless. Note that a directed testcase is another form of functional coverage. If you code a test explicitly (e.g. fill the FIFO then do another write request), it is similar (but less reliable) to implementing the equivalent functional coverage point (e.g. that measures whether a write cycle was attempted on a full FIFO).



By: Rahul V Shah

Tue, 17 Jul 2007 04:55:50 +0000

Hi David, This is a great article and very inspiring and makes lot of sense. I also had some concerns about the functional coverage, in terms of the way it is marketed. I am pasting the link of some thoughts which I wrote for the same. http://shahrahulv.blogspot.com/search/label/ASIC Regards Rahul



By: Sean W, Smith

Fri, 13 Jul 2007 16:17:34 +0000

Good point... I think that everyone understands checkers so the functional coverage has become the new hot topic. Clearly checkers are the backbone of verificaiton but coverage is almost as important so we can know if we generated useful traffic to check. In terms of language support even E and VERA lack a lot of useful infrastructure there which is augmented by class libraries like eRM and RVM that provides these basic functions. I see many users going beyond these classes and adding other hooks to deal with test phases and my favorite challenge OIR (online insertion or removal) aka. Hot Plugging. OIR presents unique challenges when crafting checkers... Sean