<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Olivier Coudert&#039;s Blog &#187; power gating</title>
	<atom:link href="http://www.ocoudert.com/blog/tag/power-gating/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ocoudert.com/blog</link>
	<description>My take on tech --and other topics</description>
	<lastBuildDate>Sat, 21 Jan 2012 20:30:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Automated low-power design flow is up for grabs (Part II)</title>
		<link>http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/</link>
		<comments>http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/#comments</comments>
		<pubDate>Tue, 06 Oct 2009 10:40:25 +0000</pubDate>
		<dc:creator>Olivier Coudert</dc:creator>
				<category><![CDATA[EDA]]></category>
		<category><![CDATA[ASIC]]></category>
		<category><![CDATA[low power]]></category>
		<category><![CDATA[power gating]]></category>
		<category><![CDATA[synthesis]]></category>
		<category><![CDATA[verification]]></category>

		<guid isPermaLink="false">http://coudert.wordpress.com/?p=225</guid>
		<description><![CDATA[A previous post showed a very-high level view of low power design with UPF/CPF. Power gating, a must-do for mobile products, is still a very manual process, and verifying the correctness of its implementation is a very challenging task. In this follow-up post, I single out some aspects of the power-gating flow, and I hint [...] [...]<p>Continue reading <a href="http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/">Automated low-power design flow is up for grabs (Part II)</a></p>
Related posts:<ol>
<li><a href='http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/' rel='bookmark' title='Automated low-power design flow is up for grabs (Part I)'>Automated low-power design flow is up for grabs (Part I)</a></li>
<li><a href='http://www.ocoudert.com/blog/2011/08/27/mentor-quitting-on-esl/' rel='bookmark' title='Mentor quitting on ESL?'>Mentor quitting on ESL?</a></li>
</ol>]]></description>
			<content:encoded><![CDATA[<p>A <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/">previous</a> post showed a very-high level view of low power design with UPF/CPF.  Power gating, a must-do for mobile products, is still a very manual process, and verifying the correctness of its implementation is a very challenging task.  In this follow-up post, I single out some aspects of the power-gating flow, and I hint at how they can be automated for the benefit of the designer.</p>
<p>I will focus on three items necessary for <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/#power_gating">power gating</a>: (1) the FSM that controls the <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/#sleep">sleep</a> and wake-up sequences; (2) the <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/#retention">retention flops</a> used to restore the state of the device when it is awakened; and (3) the correctness of the power gating implementation.  Items (1) and (2) are manually done via UPF/CPF directives and FSM hand-coding.  Item (3) is carried out with customer-specific methods, even though the use of <a href="http://en.wikipedia.org/wiki/Common_Power_Format">CPF</a> together with <a href="http://www.cadence.com/products/ld/conformal_lowpower/pages/default.aspx">Conformal</a> produces a more solid verification flow.</p>
<p><strong>Sleep/wake-up protocol synthesis </strong></p>
<p>Items (1) and (2) must really be considered together to answer the following question: how to implement a sleep and wake-up sequences that use retention flip-flops to resume the device’s state?  It is clear that answers to that question are different tradeoffs between the number of retention flops and the length of the sequences.  The more retention flops, the shorter the sequences are, but the higher the price in terms of area and residual leakage power.  In essence, one would like to be able to explore the possible tradeoffs and pick the best compromise, depending on the application.  Also from the designer point of view, one should not have to manually decide which flip-flops must be shadowed, nor one should have to hand-code the FSMs for the sleep and wake-up sequences.</p>
<p><a href="http://www.ocoudert.com/blog/wp-content/uploads/2009/10/power-state-table.png"><img title="high-level power state table" src="http://www.ocoudert.com/blog/wp-content/uploads/2009/10/power-state-table.png" alt="high-level power state table" width="260" align="right" /></a>Instead, one should be able to <em>synthesize</em> the retention flip-flops and the sleep and wake-up FSMs directly from a power state table –what I call sleep/wake-up protocol synthesis.  I would propose an extension of the power state table so that transitions can also be labeled with constraints: an upper bound on the sequence length (in terms of number of clock cycles or milliseconds), and an upper bound on the area taken by the retention flops (actual area or as a percentage of the element area).  This way the designer can concentrate on the power management strategy and explore different tradeoffs, instead of having to figure out the implementation itself.</p>
<p>Sleep/wake-up protocol synthesis is no small task.  I would look into information relevance and functional dependency analysis to derive a candidate set of retention flops.  Compression and encoding methods can then be used to reduce this set.  The final FSM synthesis would implement the decoder.  Looking into techniques coming from DFT, simulation, and formal verification could prove very helpful.</p>
<p><a name="power_gating_verification"></a><strong>Sleep/wake-up protocol verification</strong></p>
<p>Item (3) is verifying the correctness of the power gating implementation.  There are two aspects here.  One is purely physical, and consists of checking that <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/#shifter">level shifters</a>, <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/#isolation">isolation cells</a>, and power switches have been properly inserted.  The insertion of these cells can be automated, and verifying that their insertion obey basic physical rules in not a problem (this is supported for both UPF and CPF).</p>
<p>The main issue is to verify the functional correctness of the sleep/wake-up sequences, namely that the device meets some operational expectation once re-activated (e.g., the pre-sleep state is fully restored).  Intensive simulation will give some coverage, but cannot be exhaustive in general.  Sequential formal verification or property checker can then be used for a proof of correctness.  For instance the property would go something like “if the device goes to sleep and then is re-activated, its state is fully restored to its pre-sleep state in less than one second”.  To be manageable, such a property must be broken down in smaller or more abstract expressions.  The same synthesis system that takes care of items (1) and (2) should generate the properties that a 3<sup>rd</sup> party property checker can independently verify to guarantee the correctness of the sleep/wake-up protocol.  This is no different than a RTL synthesis tool giving hints to an equivalence checker to simplify the proof.</p>
<p><strong>Conclusion</strong></p>
<p>Given the complexity of today&#8217;s sleep/wake-up protocol design and verification, it is somewhat surprising that no EDA tool is really tackling the problem today.  Is it because of user unawareness, or because of the size of the challenge?  Regardless of the reason, the first company to offer sleep/wake up protocol synthesis and verification will make a major impact in the low power design community.</p>
<p>Related posts:<ol>
<li><a href='http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/' rel='bookmark' title='Automated low-power design flow is up for grabs (Part I)'>Automated low-power design flow is up for grabs (Part I)</a></li>
<li><a href='http://www.ocoudert.com/blog/2011/08/27/mentor-quitting-on-esl/' rel='bookmark' title='Mentor quitting on ESL?'>Mentor quitting on ESL?</a></li>
</ol></p>]]></content:encoded>
			<wfw:commentRss>http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Automated low-power design flow is up for grabs (Part I)</title>
		<link>http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/</link>
		<comments>http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/#comments</comments>
		<pubDate>Mon, 05 Oct 2009 21:05:35 +0000</pubDate>
		<dc:creator>Olivier Coudert</dc:creator>
				<category><![CDATA[EDA]]></category>
		<category><![CDATA[ASIC]]></category>
		<category><![CDATA[low power]]></category>
		<category><![CDATA[power gating]]></category>
		<category><![CDATA[synthesis]]></category>
		<category><![CDATA[verification]]></category>

		<guid isPermaLink="false">http://coudert.wordpress.com/?p=187</guid>
		<description><![CDATA[Low power is becoming more and more critical as the number of mobile and wireless applications is increasing. Battery life is a feature that can make the difference between a success and a flop. Remember the first version of the iPhone? All praised the touch screen interface, but so many criticized its poor battery life. [...] [...]<p>Continue reading <a href="http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/">Automated low-power design flow is up for grabs (Part I)</a></p>
Related posts:<ol>
<li><a href='http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/' rel='bookmark' title='Automated low-power design flow is up for grabs (Part II)'>Automated low-power design flow is up for grabs (Part II)</a></li>
<li><a href='http://www.ocoudert.com/blog/2011/08/27/mentor-quitting-on-esl/' rel='bookmark' title='Mentor quitting on ESL?'>Mentor quitting on ESL?</a></li>
</ol>]]></description>
			<content:encoded><![CDATA[<p>Low power is becoming more and more critical as the number of mobile and wireless applications is increasing.  Battery life is a feature that can make the difference between a success and a flop.  Remember the first version of the iPhone?  All praised the touch screen interface, but so many criticized its poor battery life.</p>
<p>For mobile products, <a href="#leakage_power">leakage power</a> (the power consumed when the device is on but idle) has become a dominant factor, as opposed to <a href="#dynamic_power">dynamic power</a> (the power resulting from the actual activity of the device, e.g., during a call for a cell phone).  In that context, <a href="#power_gating">power gating</a> is a key for extended battery life.  Under some condition (e.g., the “on/off” button is pressed, or the device has been unused for some time), the device goes to <a href="#sleep">sleep</a>: it powers down most of its elements and preserves enough information to restore the state it was in before going to sleep.  Under another condition (e.g., the “on/off” button is pressed again), the device powers back up and resumes its course as it was right before going to sleep.</p>
<p><a href="http://www.google.com/url?sa=t&amp;source=web&amp;ct=res&amp;cd=3&amp;url=http%3A%2F%2Fwww.unifiedpowerformat.com%2F&amp;ei=AM_JSvakBIuanwOMhdlK&amp;rct=j&amp;q=UPF+power&amp;usg=AFQjCNFClvZ6pzAUiLWZqiBx_D5DTCupDA">UPF</a> (Unified Power Format, endorsed by Synopsys, Mentor, and Magma) has been introduced to describe the power supply distribution and its control.  With UPF one can specify power domains (a set of design elements that share a power supply), and a power state table that captures the transitions between the power domains.  For instance it is used to describe under which conditions the device goes to sleep, under which conditions it must be powered back up, and what happens whenever the device transitions between these modes.  UPF allows the designer to specify <a href="#retention">retention flops</a>, <a href="#shifter">level shifters</a>, and <a href="#isolation">isolation cells</a>, all necessary items for <a href="#mvdd">multiple voltage</a> designs and power gating.  <a href="http://en.wikipedia.org/wiki/Common_Power_Format">CPF</a>, promoted by Cadence, is another format that is used to describe similar power management schemes.</p>
<p>Low power has been a subject of attention from chip designers and EDA for more than 10 years.  Indeed, a lot of improvement has been done.  New techniques have been introduced, and most are now common practices and relatively well automated –<a href="#clock_gating">clock gating</a>, <a href="#mvt">multiple Vt</a> cells, <a href="#mvdd">multiple voltages</a>.</p>
<p>Despite these progresses, low power-centric design flows remain a very labor intensive process.  Even if UPF/CPF can be used to describe transitions between different power modes, it is up to the designer to manually write the controller (as a FSM) that implements the transitions, and it is up to the designer to determine which information must be preserved (the retention flops) in order to resume the application to its pre-sleep state.</p>
<p>Also low-power designs create new challenges for functional verification.  For instance, after going to sleep, the device must be able to resume without loss of information.  Since the sleep and power-back-up sequences take several clock cycles, simple equivalence checking is not sufficient.  Sequential verification or intensive simulation is needed.  Cadence did a relatively good job in tying CPF to its Formal Verification solution (<a href="http://www.cadence.com/products/ld/conformal_lowpower/pages/default.aspx">Conformal</a>), Mentor and Synopsys have some reasonable flow for UPF, but verifying the correctness of a power state table FSM is still a very manual and error-prone process.</p>
<p>EDA stands for bringing automation to design flows, and low power design could use some help.  In <a href="http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/">Part II</a>, I will show how some parts of the low power design flow can be automated.</p>
<p><strong>Glossary</strong></p>
<p><a name="sleep"></a><strong>Sleep mode</strong>: the power state a device is in when it is not actively used by the user.  In that state most of the device is shut down, but is ready to wake up when the user needs it.</p>
<p><a name="active"></a><strong>Active mode</strong>: the power state a device is when it is fully active (e.g., making a call with a cell phone).</p>
<p><a name="power_domain"></a><strong>Power domain</strong>: a set of design elements that share a power supply.  Power domain is also used to denote the power supply itself.</p>
<p><a name="power_table"></a><strong>Power state table</strong>: a table that describes the transitions between <a href="#power_domain">power domains</a>.  Transitions are annotated with logical expressions under which they are triggered.</p>
<p><a name="retention"></a><strong>Retention flop</strong>: an always-on flop that shadows the state of a flop.  It retains its logic state even when the primary power supply to the cell is shut off.  It is used to restore the state of a device when it is powered back up.</p>
<p><a name="shifter"></a><strong>Level shifter</strong>: cell used to allow a signal to pass from one <a href="#power_domain">power domain</a> to another.</p>
<p><a name="isolation"></a><strong>Isolation Cell</strong><strong>: </strong>cell used to isolate a device element from its neighbors when it is powered down.</p>
<p><a name="clock_gating"></a><strong>Clock gating</strong>: power-saving technique that consists of blocking the clock signal leading to flops so that flops cannot change their state.  Since their states are fixed, the downstream logic will not toggle, which saves <a href="#dynamic_power">dynamic power</a>.</p>
<p><a name="power_gating"></a><strong>Power gating</strong>: power-saving technique that consists of shutting down the power supply to a device component, so that its power consumption is zero.</p>
<p><a name="mvt"></a><strong>Multiple Vt</strong>: multiple voltage threshold cells.  A cell speed depends on its voltage threshold.  The lower its voltage threshold, the faster the cell is, but the higher its <a href="#leakage_power">leakage power</a>.  High Vt cells are used for non-timing critical parts of the circuit, while low Vt cells are used for critical paths only, so that the overall leakage power is reduced.</p>
<p><a name="mvdd"></a><strong>Multiple voltages, Voltage islands, MVDD</strong>: a component of a circuit can operate under several voltages, or components can have different operational voltage.  The higher the voltage, the faster the component is, the higher its <a href="#leakage_power">leakage</a> and <a href="#dynamic_power">dynamic</a> power.</p>
<p><a name="dynamic_power"></a><strong>Dynamic power</strong>: the power dissipated by a circuit due to its cells switching from one state to the next.  It is proportional to Vdd<sup>2</sup>tr, where Vdd is the voltage supply of the cell, and tr is its transition rate (or toggle rate) per second.</p>
<p><a name="leakage_power"></a><strong>Leakage power, static power</strong>: the power dissipated due to the leakage current passing through transistors.  Practically it is the power dissipated when the cell does not toggle.  It is proportional to Vdd exp(- Vt / T), where Vdd is the voltage supply of the cell, Vt is its <a href="#mvt">voltage threshold</a>, and T the temperature.</p>
<p>Related posts:<ol>
<li><a href='http://www.ocoudert.com/blog/2009/10/06/automated-low-power-design-flow-is-up-for-grabs-part-ii/' rel='bookmark' title='Automated low-power design flow is up for grabs (Part II)'>Automated low-power design flow is up for grabs (Part II)</a></li>
<li><a href='http://www.ocoudert.com/blog/2011/08/27/mentor-quitting-on-esl/' rel='bookmark' title='Mentor quitting on ESL?'>Mentor quitting on ESL?</a></li>
</ol></p>]]></content:encoded>
			<wfw:commentRss>http://www.ocoudert.com/blog/2009/10/05/automated-low-power-design-flow-is-up-for-grab-part-i/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

