Comments on: Positive and Negative Verification http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/ ESL Design and Verification Tue, 06 Sep 2011 02:23:02 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Recent URLs tagged Positive - Urlrecorder http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/comment-page-1/#comment-342 Recent URLs tagged Positive - Urlrecorder Mon, 13 Apr 2009 14:54:13 +0000 http://www.chipdesignmag.com/bailey/?p=11#comment-342 [...] recorded first by aaronlea on 2009-02-28→ Positive and Negative Verification [...] [...] recorded first by aaronlea on 2009-02-28→ Positive and Negative Verification [...]

]]> By: Brian Bailey http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/comment-page-1/#comment-27 Brian Bailey Sun, 10 Aug 2008 18:22:46 +0000 http://www.chipdesignmag.com/bailey/?p=11#comment-27 Hi John, Good question John, and actually in part related to my latest blog entry - when is the time right. Mutation analysis will find out if software code has a reason to exist. By inserting faults in a piece of code, or deleting a line of code entirely and running the set of testcases - some test should show a difference. If it doesn't then it either means that the testbench failed to propagate a difference to an observable output, or that line of the design had no reason to exist in the first place. Certess - with their Certitude tool, takes this one stage further and ensures that not only is a difference propagated, but that something in the testcase actually detects the error and reports it. This product thus tests the testbench and provides a direct and objective measure of its quality. Now, you mentioned detecting illegal behavior. This is somewhat more difficult and qualifying the testbench can can tell you about behavior that may be missing in the design. So if code should exist to recover from a situation, then you may have a problem. Having said that, both the design and the testbench would have to be missing this functionality, or functional qualification would have detected it. If you want more information on this, I suggest that you contact Certess directly. Hi John,
Good question John, and actually in part related to my latest blog entry – when is the time right. Mutation analysis will find out if software code has a reason to exist. By inserting faults in a piece of code, or deleting a line of code entirely and running the set of testcases – some test should show a difference. If it doesn’t then it either means that the testbench failed to propagate a difference to an observable output, or that line of the design had no reason to exist in the first place. Certess – with their Certitude tool, takes this one stage further and ensures that not only is a difference propagated, but that something in the testcase actually detects the error and reports it. This product thus tests the testbench and provides a direct and objective measure of its quality.

Now, you mentioned detecting illegal behavior. This is somewhat more difficult and qualifying the testbench can can tell you about behavior that may be missing in the design. So if code should exist to recover from a situation, then you may have a problem. Having said that, both the design and the testbench would have to be missing this functionality, or functional qualification would have detected it. If you want more information on this, I suggest that you contact Certess directly.

]]> By: John Swan http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/comment-page-1/#comment-26 John Swan Sun, 10 Aug 2008 04:51:05 +0000 http://www.chipdesignmag.com/bailey/?p=11#comment-26 Related to proving that a design does not have bugs is proving that the testbench is catching all improper design behavior. Last year I took a course in SystemVerilog and it appeared to me there was no convenient way to confirm that the SystemVerilog code was indeed catching all the illegal behavior I was expecting it to do. The instructor confirmed there was no tool support he knew of in industry to help verify the testbench itself. Neither did the class address technique(s) for accomplishing this. Please comment on this. Do you know of any commercial tool support for this? With the advent of SystemVerilog rules, what are the the/some recommended techniques for verifying the robustness of the rules? Related to proving that a design does not have bugs is proving that the testbench is catching all improper design behavior.

Last year I took a course in SystemVerilog and it appeared to me there was no convenient way to confirm that the SystemVerilog code was indeed catching all the illegal behavior I was expecting it to do. The instructor confirmed there was no tool support he knew of in industry to help verify the testbench itself. Neither did the class address technique(s) for accomplishing this.

Please comment on this. Do you know of any commercial tool support for this? With the advent of SystemVerilog rules, what are the the/some recommended techniques for verifying the robustness of the rules?

]]>