<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Barry&#039;s Power Points</title>
	<atom:link href="http://chipdesignmag.com/lpd/pangrle/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://chipdesignmag.com/lpd/pangrle</link>
	<description>Making Semiconductor Architectures More Efficient</description>
	<lastBuildDate>Sun, 08 Apr 2012 03:39:41 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>Comment on Undervolting &amp; Underclocking by Jake</title>
		<link>http://chipdesignmag.com/lpd/pangrle/2012/01/12/undervolting-underclocking/comment-page-1/#comment-628</link>
		<dc:creator>Jake</dc:creator>
		<pubDate>Sun, 08 Apr 2012 03:39:41 +0000</pubDate>
		<guid isPermaLink="false">http://chipdesignmag.com/lpd/pangrle/?p=204#comment-628</guid>
		<description>$55 per year! Man, when you put it like that, it&#039;s hard to dismiss concerns about power usage. I had always just ignored it but that is pretty significant, especially when you consider a light bulb uses about $1/year.</description>
		<content:encoded><![CDATA[<p>$55 per year! Man, when you put it like that, it&#8217;s hard to dismiss concerns about power usage. I had always just ignored it but that is pretty significant, especially when you consider a light bulb uses about $1/year.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A Brief History Of Power Formats by Bhanu Kapoor</title>
		<link>http://chipdesignmag.com/lpd/pangrle/2012/02/09/a-brief-history-of-power-formats/comment-page-1/#comment-532</link>
		<dc:creator>Bhanu Kapoor</dc:creator>
		<pubDate>Thu, 09 Feb 2012 20:40:22 +0000</pubDate>
		<guid isPermaLink="false">http://chipdesignmag.com/lpd/pangrle/?p=228#comment-532</guid>
		<description>Barry, thanks for bringing up the timeline for power format description and it was good to read your article. Back in 2003 when I was working for Atrenta  (joined 2001), we met with semiconductor companies that were key players in cell phone applications and baseband processor business. They all pointed to a huge problem in verifying designs with power management. We quickly realized that we need something beyond Verilog and VHDL to communicate the information related to power managed designs for the design tools. I was leading the development of SpyGlass Low Power at the time and it was adapted to solve these verification issues for the cell phone chip makers.  Atrenta had a power format that was in use by semiconductor companies back in 2003. Between 2003 and 2005, this tool was used by almost every cell phone chip maker to verify some of the issues in the designs utilizing power management techniques. We filed patents (7,152, 216 and 7,712,061) in 2004 and 2006 for some power management design and verification techniques and these patents also list some of the early statements of the Atrenta power format that were used to capture voltage domain related information. We also had a high-level discussion on EDA issues and solutions related to power managed designs at the EDPS meeting in 2004. I left Atrenta in 2006 to join ArchPro and to the best of my knowledge,  Atrenta’s format was donated to CPF related efforts after my departure. 
US Patent 7,152,216 -- http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=4&amp;f=G&amp;l=50&amp;co1=AND&amp;d=PTXT&amp;s1=Bhanu&amp;s2=Kapoor&amp;OS=Bhanu+AND+Kapoor&amp;RS=Bhanu+AND+Kapoor

US Patent 7,712,061 --  http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;co1=AND&amp;d=PTXT&amp;s1=Bhanu&amp;s2=Kapoor&amp;OS=Bhanu+AND+Kapoor&amp;RS=Bhanu+AND+Kapoor

EDPS meeting in 2004 --  http://www.eda.org/edps/edp04/postedPapers.html</description>
		<content:encoded><![CDATA[<p>Barry, thanks for bringing up the timeline for power format description and it was good to read your article. Back in 2003 when I was working for Atrenta  (joined 2001), we met with semiconductor companies that were key players in cell phone applications and baseband processor business. They all pointed to a huge problem in verifying designs with power management. We quickly realized that we need something beyond Verilog and VHDL to communicate the information related to power managed designs for the design tools. I was leading the development of SpyGlass Low Power at the time and it was adapted to solve these verification issues for the cell phone chip makers.  Atrenta had a power format that was in use by semiconductor companies back in 2003. Between 2003 and 2005, this tool was used by almost every cell phone chip maker to verify some of the issues in the designs utilizing power management techniques. We filed patents (7,152, 216 and 7,712,061) in 2004 and 2006 for some power management design and verification techniques and these patents also list some of the early statements of the Atrenta power format that were used to capture voltage domain related information. We also had a high-level discussion on EDA issues and solutions related to power managed designs at the EDPS meeting in 2004. I left Atrenta in 2006 to join ArchPro and to the best of my knowledge,  Atrenta’s format was donated to CPF related efforts after my departure.<br />
US Patent 7,152,216 &#8212; <a href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&#038;Sect2=HITOFF&#038;p=1&#038;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&#038;r=4&#038;f=G&#038;l=50&#038;co1=AND&#038;d=PTXT&#038;s1=Bhanu&#038;s2=Kapoor&#038;OS=Bhanu+AND+Kapoor&#038;RS=Bhanu+AND+Kapoor" rel="nofollow">http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&#038;Sect2=HITOFF&#038;p=1&#038;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&#038;r=4&#038;f=G&#038;l=50&#038;co1=AND&#038;d=PTXT&#038;s1=Bhanu&#038;s2=Kapoor&#038;OS=Bhanu+AND+Kapoor&#038;RS=Bhanu+AND+Kapoor</a></p>
<p>US Patent 7,712,061 &#8212;  <a href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&#038;Sect2=HITOFF&#038;p=1&#038;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&#038;r=1&#038;f=G&#038;l=50&#038;co1=AND&#038;d=PTXT&#038;s1=Bhanu&#038;s2=Kapoor&#038;OS=Bhanu+AND+Kapoor&#038;RS=Bhanu+AND+Kapoor" rel="nofollow">http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&#038;Sect2=HITOFF&#038;p=1&#038;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&#038;r=1&#038;f=G&#038;l=50&#038;co1=AND&#038;d=PTXT&#038;s1=Bhanu&#038;s2=Kapoor&#038;OS=Bhanu+AND+Kapoor&#038;RS=Bhanu+AND+Kapoor</a></p>
<p>EDPS meeting in 2004 &#8212;  <a href="http://www.eda.org/edps/edp04/postedPapers.html" rel="nofollow">http://www.eda.org/edps/edp04/postedPapers.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Intel’s Claremont Near-Threshold Voltage IA Core by Gary Smith</title>
		<link>http://chipdesignmag.com/lpd/pangrle/2011/10/06/intel%e2%80%99s-claremont-near-threshold-voltage-ia-core/comment-page-1/#comment-405</link>
		<dc:creator>Gary Smith</dc:creator>
		<pubDate>Wed, 12 Oct 2011 18:19:44 +0000</pubDate>
		<guid isPermaLink="false">http://chipdesignmag.com/lpd/pangrle/?p=167#comment-405</guid>
		<description>Any idea how they handled reliability ?  I expected you would have to use a considerable amount of redundant logic. - Gary</description>
		<content:encoded><![CDATA[<p>Any idea how they handled reliability ?  I expected you would have to use a considerable amount of redundant logic. &#8211; Gary</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Power Of Standards by Sumit DasGupta</title>
		<link>http://chipdesignmag.com/lpd/pangrle/2010/07/08/the-power-of-standards/comment-page-1/#comment-46</link>
		<dc:creator>Sumit DasGupta</dc:creator>
		<pubDate>Mon, 26 Jul 2010 20:53:52 +0000</pubDate>
		<guid isPermaLink="false">http://chipdesignmag.com/lpd/pangrle/?p=34#comment-46</guid>
		<description>Three plus years later and with both low power formats adopted by a multitude of users, we are back to debating whether to kill one of the  battling low power formats. Wish it could be so simple just willing away one of the formats. In these intervening years, many hundreds of users have learned to use CPF (and many of the same users have adopted UPF), they have created CPF “golden” files that are already in use and have been employed to tape out many, many designs with many more in the pipeline. Equally importantly, these golden files and associated scripts will be transferred to future designs. Does the author suggest that these design teams back up three years and map these commands on to UPF/1801?

The question above is rhetorical at best. The CPF Format Working Group in the Low Power Coalition at Si2 has released an Interoperability Guide to the industry in which it has communicated with the 1801 WG and which is hoped will assist both CPF and UPF find ways to co-exist as they go forward. The important lesson from the creation of this document is that CPF and UPF form a Venn Diagram with more commands that are different than are common, i.e., can be mapped 1:1 from one to the other. Given this situation, how does the author who suggests killing CPF accommodate the immediate needs of those users who must forthwith move to UPF when the latter does not yet support many of the constructs that are now part of the designers’ “golden” files?

The better approach would be to accept that the genie is out of the bottle and that rather than embarking on a futile effort to put it back in that the effort should focus on developing both formats so that the area of intersection between the two increases over time to satisfy the needs of all users and not the whim of an EDA developer.  At the end of the day, it&#039;s clear that designers would rather focus on having interoperable flows that work than resurrect old format wars from their vendors.</description>
		<content:encoded><![CDATA[<p>Three plus years later and with both low power formats adopted by a multitude of users, we are back to debating whether to kill one of the  battling low power formats. Wish it could be so simple just willing away one of the formats. In these intervening years, many hundreds of users have learned to use CPF (and many of the same users have adopted UPF), they have created CPF “golden” files that are already in use and have been employed to tape out many, many designs with many more in the pipeline. Equally importantly, these golden files and associated scripts will be transferred to future designs. Does the author suggest that these design teams back up three years and map these commands on to UPF/1801?</p>
<p>The question above is rhetorical at best. The CPF Format Working Group in the Low Power Coalition at Si2 has released an Interoperability Guide to the industry in which it has communicated with the 1801 WG and which is hoped will assist both CPF and UPF find ways to co-exist as they go forward. The important lesson from the creation of this document is that CPF and UPF form a Venn Diagram with more commands that are different than are common, i.e., can be mapped 1:1 from one to the other. Given this situation, how does the author who suggests killing CPF accommodate the immediate needs of those users who must forthwith move to UPF when the latter does not yet support many of the constructs that are now part of the designers’ “golden” files?</p>
<p>The better approach would be to accept that the genie is out of the bottle and that rather than embarking on a futile effort to put it back in that the effort should focus on developing both formats so that the area of intersection between the two increases over time to satisfy the needs of all users and not the whim of an EDA developer.  At the end of the day, it&#8217;s clear that designers would rather focus on having interoperable flows that work than resurrect old format wars from their vendors.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Power Of Standards by Pete Hardee</title>
		<link>http://chipdesignmag.com/lpd/pangrle/2010/07/08/the-power-of-standards/comment-page-1/#comment-45</link>
		<dc:creator>Pete Hardee</dc:creator>
		<pubDate>Wed, 14 Jul 2010 19:51:21 +0000</pubDate>
		<guid isPermaLink="false">http://chipdesignmag.com/lpd/pangrle/?p=34#comment-45</guid>
		<description>Good topic for discussion, so a couple of comments from me. First, I should make it clear that CPF is a standard - latest release is CPF 1.1 from Si2, and it&#039;s supported by multiple EDA companies. Second, UPF is effectively two standards in one - UPF 1.0 was the original Accellera standard and then there&#039;s IEEE 1801 (aka UPF 2.0), which extended the standard in many important ways, but included UPF 1.0 in full for backward compatibility. What I am hearing from many leading companies trying to make UPF work is that they want UPF 2.0, not the UPF 1.0 currently supported in most tools (despite as you rightly point out, the 1801 standard being available for over a year). Meanwhile, many customers who have adopted CPF find that it is meeting their advanced low power design needs. I agree that it&#039;s less than ideal that we got to the position of two standards. The history is what it is - we can&#039;t change it - but we need to look forward to improve things for the low power design community. Interoperability between the two formats is a step in the right direction. And a necessary step to improve interoperability is the adoption of the some of the newer constructs in IEEE 1801 by the EDA vendors that support UPF, to enable better mixed vendor flows for advanced low power designers.</description>
		<content:encoded><![CDATA[<p>Good topic for discussion, so a couple of comments from me. First, I should make it clear that CPF is a standard &#8211; latest release is CPF 1.1 from Si2, and it&#8217;s supported by multiple EDA companies. Second, UPF is effectively two standards in one &#8211; UPF 1.0 was the original Accellera standard and then there&#8217;s IEEE 1801 (aka UPF 2.0), which extended the standard in many important ways, but included UPF 1.0 in full for backward compatibility. What I am hearing from many leading companies trying to make UPF work is that they want UPF 2.0, not the UPF 1.0 currently supported in most tools (despite as you rightly point out, the 1801 standard being available for over a year). Meanwhile, many customers who have adopted CPF find that it is meeting their advanced low power design needs. I agree that it&#8217;s less than ideal that we got to the position of two standards. The history is what it is &#8211; we can&#8217;t change it &#8211; but we need to look forward to improve things for the low power design community. Interoperability between the two formats is a step in the right direction. And a necessary step to improve interoperability is the adoption of the some of the newer constructs in IEEE 1801 by the EDA vendors that support UPF, to enable better mixed vendor flows for advanced low power designers.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

