<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments for Verification Vertigo</title>
	<atom:link href="http://www.chipdesignmag.com/bailey/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.chipdesignmag.com/bailey</link>
	<description>Just another WordPress weblog</description>
	<pubDate>Thu, 28 Aug 2008 00:28:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Comment on Slow, Cumbersome and Incomplete by Phil Dworsky</title>
		<link>http://www.chipdesignmag.com/bailey/2008/08/11/13/#comment-29</link>
		<dc:creator>Phil Dworsky</dc:creator>
		<pubDate>Thu, 14 Aug 2008 21:27:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.chipdesignmag.com/bailey/?p=13#comment-29</guid>
		<description>Brian - thanks for pointing out the importance and challenges of verification posed by power management. Also, thanks for pointing out the &lt;a href="//www.synopsys.com/lpmm" rel="nofollow"&gt;"Low Power Methodology Manual"&lt;/A&gt; (LPMM), which is a perfect book for getting a strong practical understanding of designing for low power, especially architecture and implementation. You're correct that the LPMM didn't include a lot of verification depth, and that's why &lt;a href="http://synopsys.mediaroom.com/index.php?s=43&#38;item=582" rel="nofollow"&gt;ARM, Renesas, and Synopsys have been collaborating to produce the first verification methodology for low power designs&lt;/A&gt; ("VMM-LP"). The VMM-LP also includes as co-author, David Flynn from ARM, a co-author of the LPMM.

VMM-LP is the result of years of experience of low power industry leaders and documents best practices and a blueprint to enable comprehensive, repeatable and productive verification of low power designs. It's in response to the growing importance and difficulty of comprehensively verifying a low power design before it is committed to silicon. VMM-LP is also an answer to "slow, cumbersome and incomplete" verification of low power designs.
 	
VMM-LP includes a book that describes the common causes of failures in low power designs, a "how-to" manual on setting up a verification environment for low power including power-aware assertions, coverage, and test plans, and a methodology for a scalable and reusable infrastructure for verification of low power designs.

Importantly, VMM-LP also includes free access to source code under an Apache 2.0 license for a System-Verilog base class library that is aware of the simulation semantics of power shutdown and retention and helps create the reusable verification environment. There is tremendous interest and excellent progress in the VMM-LP effort. Both the book and the base classes are scheduled for release in fall 2008. People interested in being notified immediately on the availability of the book and class library can register at &lt;a href="//www.vmmcentral.org/cgi-bin/vmmlp/reg1.cgi”" rel="nofollow"&gt;www.vmmcentral.org&lt;/A&gt;.

So, we look forward to your feedback then!

You also mention MVSIM with VCS as a Synopsys solution for verification of low power designs but don't recognize that MVSIM has been in active use for more than 3 years and became part of the Synopsys product portfolio last year through Synopsys' acquisition of ArchPro. MVSIM and MVRC were specifically designed to address the growing problem of low power verification - MVSIM from a simulation perspective and MVRC from a static perspective. They have helped designers successfully weed out power management bugs prior to silicon and prevented re-spins. MVSIM also implements a lot of the verification methodology that is now being documented in the VMM-LP book, and Cypress and Renesas have been public in discussing their successes. With the VMM-LP effort, Synopsys and other low power leaders are making available in public domain the methodology already implemented and proved in MVSIM.

Thanks for highlighting the importance of verification to low power design!
-phil</description>
		<content:encoded><![CDATA[<p>Brian - thanks for pointing out the importance and challenges of verification posed by power management. Also, thanks for pointing out the <a href="//www.synopsys.com/lpmm" rel="nofollow">&#8220;Low Power Methodology Manual&#8221;</a> (LPMM), which is a perfect book for getting a strong practical understanding of designing for low power, especially architecture and implementation. You&#8217;re correct that the LPMM didn&#8217;t include a lot of verification depth, and that&#8217;s why <a href="http://synopsys.mediaroom.com/index.php?s=43&amp;item=582" rel="nofollow">ARM, Renesas, and Synopsys have been collaborating to produce the first verification methodology for low power designs</a> (&#8221;VMM-LP&#8221;). The VMM-LP also includes as co-author, David Flynn from ARM, a co-author of the LPMM.</p>
<p>VMM-LP is the result of years of experience of low power industry leaders and documents best practices and a blueprint to enable comprehensive, repeatable and productive verification of low power designs. It&#8217;s in response to the growing importance and difficulty of comprehensively verifying a low power design before it is committed to silicon. VMM-LP is also an answer to &#8220;slow, cumbersome and incomplete&#8221; verification of low power designs.</p>
<p>VMM-LP includes a book that describes the common causes of failures in low power designs, a &#8220;how-to&#8221; manual on setting up a verification environment for low power including power-aware assertions, coverage, and test plans, and a methodology for a scalable and reusable infrastructure for verification of low power designs.</p>
<p>Importantly, VMM-LP also includes free access to source code under an Apache 2.0 license for a System-Verilog base class library that is aware of the simulation semantics of power shutdown and retention and helps create the reusable verification environment. There is tremendous interest and excellent progress in the VMM-LP effort. Both the book and the base classes are scheduled for release in fall 2008. People interested in being notified immediately on the availability of the book and class library can register at <a href="//www.vmmcentral.org/cgi-bin/vmmlp/reg1.cgi”" rel="nofollow">http://www.vmmcentral.org</a>.</p>
<p>So, we look forward to your feedback then!</p>
<p>You also mention MVSIM with VCS as a Synopsys solution for verification of low power designs but don&#8217;t recognize that MVSIM has been in active use for more than 3 years and became part of the Synopsys product portfolio last year through Synopsys&#8217; acquisition of ArchPro. MVSIM and MVRC were specifically designed to address the growing problem of low power verification - MVSIM from a simulation perspective and MVRC from a static perspective. They have helped designers successfully weed out power management bugs prior to silicon and prevented re-spins. MVSIM also implements a lot of the verification methodology that is now being documented in the VMM-LP book, and Cypress and Renesas have been public in discussing their successes. With the VMM-LP effort, Synopsys and other low power leaders are making available in public domain the methodology already implemented and proved in MVSIM.</p>
<p>Thanks for highlighting the importance of verification to low power design!<br />
-phil</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Positive and Negative Verification by Brian Bailey</title>
		<link>http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/#comment-27</link>
		<dc:creator>Brian Bailey</dc:creator>
		<pubDate>Sun, 10 Aug 2008 18:22:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.chipdesignmag.com/bailey/?p=11#comment-27</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>Hi John,<br />
    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&#8217;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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Positive and Negative Verification by John Swan</title>
		<link>http://www.chipdesignmag.com/bailey/2008/07/21/positive-and-negative-verification/#comment-26</link>
		<dc:creator>John Swan</dc:creator>
		<pubDate>Sun, 10 Aug 2008 04:51:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.chipdesignmag.com/bailey/?p=11#comment-26</guid>
		<description>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?</description>
		<content:encoded><![CDATA[<p>Related to proving that a design does not have bugs is proving that the testbench is catching all improper design behavior.</p>
<p>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. </p>
<p>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?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Verification defined by Verification Vertigo &#187; Blog Archive &#187; Positive and Negative Verification</title>
		<link>http://www.chipdesignmag.com/bailey/2008/05/15/verification-defined/#comment-19</link>
		<dc:creator>Verification Vertigo &#187; Blog Archive &#187; Positive and Negative Verification</dc:creator>
		<pubDate>Tue, 22 Jul 2008 03:13:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.chipdesignmag.com/bailey/?p=4#comment-19</guid>
		<description>[...] a previous blog, I talked about the differences between verification and validation. What can confuse those [...]</description>
		<content:encoded><![CDATA[<p>[...] a previous blog, I talked about the differences between verification and validation. What can confuse those [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on EDA Standards by Ray Salemi</title>
		<link>http://www.chipdesignmag.com/bailey/2008/06/24/eda-standards/#comment-11</link>
		<dc:creator>Ray Salemi</dc:creator>
		<pubDate>Tue, 24 Jun 2008 15:53:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.chipdesignmag.com/bailey/?p=7#comment-11</guid>
		<description>The end comment of your panel is one that I often hear as an EDA guy.  One person will say, "Standards are a Good Thing."  Then everyone shouts "Hear! Hear!" and all eyes slowly turn to the EDA vendors sitting in the back of the room (the greedy lummoxes!)

However, I've found that the engineers's love of a standard methodology quickly slips away when they are actually presented with one.  This is because the proposed methodology is "too big" or "too small" or "too OOPy" or "not OOPy enough" or "too confusing" or "too simplistic" or "too open" or "too closed" or "too new" or "too old" and always "Not Invented Here."

I applaud your comment that the user community should let their voices be heard.  I wonder, though, if they will all say something that can result in a standard.</description>
		<content:encoded><![CDATA[<p>The end comment of your panel is one that I often hear as an EDA guy.  One person will say, &#8220;Standards are a Good Thing.&#8221;  Then everyone shouts &#8220;Hear! Hear!&#8221; and all eyes slowly turn to the EDA vendors sitting in the back of the room (the greedy lummoxes!)</p>
<p>However, I&#8217;ve found that the engineers&#8217;s love of a standard methodology quickly slips away when they are actually presented with one.  This is because the proposed methodology is &#8220;too big&#8221; or &#8220;too small&#8221; or &#8220;too OOPy&#8221; or &#8220;not OOPy enough&#8221; or &#8220;too confusing&#8221; or &#8220;too simplistic&#8221; or &#8220;too open&#8221; or &#8220;too closed&#8221; or &#8220;too new&#8221; or &#8220;too old&#8221; and always &#8220;Not Invented Here.&#8221;</p>
<p>I applaud your comment that the user community should let their voices be heard.  I wonder, though, if they will all say something that can result in a standard.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Verification defined by Gordon McGregor</title>
		<link>http://www.chipdesignmag.com/bailey/2008/05/15/verification-defined/#comment-5</link>
		<dc:creator>Gordon McGregor</dc:creator>
		<pubDate>Fri, 13 Jun 2008 16:10:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.chipdesignmag.com/bailey/?p=4#comment-5</guid>
		<description>Brian, I enjoyed listening to your presentation at DAC that covered much of this information. As you stated several times, that 'have been fulfilled' section is the one that is often ill defined and not well understood, with our current approaches to measuring behaviour.</description>
		<content:encoded><![CDATA[<p>Brian, I enjoyed listening to your presentation at DAC that covered much of this information. As you stated several times, that &#8216;have been fulfilled&#8217; section is the one that is often ill defined and not well understood, with our current approaches to measuring behaviour.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
