<?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>TechGuri &#187; CTS</title>
	<atom:link href="http://www.techguri.com/tag/cts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.techguri.com</link>
	<description>Technical blog EDA, semiconductor industry</description>
	<lastBuildDate>Wed, 08 Sep 2010 15:40:25 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Myth # 8 : Crosstalk aware timing fixing can be done in post-route stage only.</title>
		<link>http://www.techguri.com/2009/09/08/myth-8-crosstalk-aware-timing-fixing-can-be-done-in-post-route-stage-only/</link>
		<comments>http://www.techguri.com/2009/09/08/myth-8-crosstalk-aware-timing-fixing-can-be-done-in-post-route-stage-only/#comments</comments>
		<pubDate>Tue, 08 Sep 2009 20:56:33 +0000</pubDate>
		<dc:creator>Alpesh Kothari</dc:creator>
				<category><![CDATA[Place and Route]]></category>
		<category><![CDATA[65nm]]></category>
		<category><![CDATA[crosstalk]]></category>
		<category><![CDATA[CTS]]></category>
		<category><![CDATA[ECOs]]></category>
		<category><![CDATA[EDA]]></category>
		<category><![CDATA[P&R tool]]></category>
		<category><![CDATA[placement-based optimization]]></category>
		<category><![CDATA[post-clock optimization]]></category>

		<guid isPermaLink="false">http://www.techguri.com/?p=538</guid>
		<description><![CDATA[One of the most convincing stories you can hear from any big EDA marketing person is that crosstalk is something which can only show up after the routes are laid down and thus needs to be fixed as a post-process step after routing.]]></description>
			<content:encoded><![CDATA[<p>Myth # 8 : Crosstalk aware timing fixing can be done in post-route stage only.</p>
<p>One of the most convincing stories you can hear from any big EDA marketing person is that crosstalk is something which can only show up after the routes are laid down and thus needs to be fixed as a post-process step after routing. In theory, this looks reasonable since without real knowledge of the wires how can you predict coupling between them? But, if you step back and look at this from 1000 ft view, the same theory can apply to computing wire delays. Without routing how can you predict the wire delay and thus you need to route the design to accurately predict wire delays. But wait, how are we doing placement and placement-based optimization, CTS and post-clock optimization? </p>
<p>I recently surveyed few of my customers and P&#038;R designers to check on how the big “three” handles SI in their flow:</p>
<p>Here is what I found/heard:</p>
<p><strong>Company A :</strong> Detail Route the design. Fix all the regular timing. Turn on SI aware timing and do SI based timing optimization.</p>
<p><strong>Company B :</strong> Route the design and later do SI based timing analysis and fix the regular and SI based timing. All this may be clubbed into one name but if you look at the logfile you can see the obvious!</p>
<p><strong>Company C :</strong> They try to do some SI prevention during global routing based on heuristics and later some quick optimization following track assignment. Later post-detail routing, if you still have SI based timing violations left, you need to run post-route timing optimization.</p>
<p>The question anyone can have is what is wrong with the above approaches? These are perfectly valid approaches at 90nm or 130nm where SI was not significant in the designs. At 90nm, I know designers who’ll add 100ps extra margin to account for SI and not really do SI based timing analysis in implementation tool. They will just do it in sign-off tool and later run few ECOs to fix timing on outlier paths. There were several reasons for not doing SI based timing optimization in P&#038;R tool:</p>
<p>a.	P&#038;R tool’s SI numbers wont correlate with sign-off tool’s SI prediction.<br />
b.	P&#038;R tools runs really slow especially timer and extractor in post-route mode. So, if you want to do SI based timing optimization during post-route you are talking in days.<br />
c.	SI effects were not significant at 90 and 130nm. So, you can add extra margin and/or run few ECOs to close timing.</p>
<p>All this is changing at 65nm and 40nm. The crosstalk based timing effects are really significant. I have seen 500ps to 1ns difference in timing when between regular and crosstalk aware analysis. This is huge and cannot be solved by doing ECOs or adding 100ps or so margin.</p>
<p>So, all the designers who are working at 65nm and below are forced to run crosstalk aware timing closure flow in the P&#038;R tool. The result be it company A, B or C, runtimes are loooong and no guarantee of complete SI based timing closure or correlation to sign-off tools (see my other post Myth # 9 : I need to tune R and C factors to get good correlation to sign-off tools and achieve predictable timing closure). While talking to one of my friend, I found that post-route SI aware timing optimization took 3.5 days in one tool and still it was not clean. Later, they did several (more than 10) ECOs for next 2 weeks to get timing closure!</p>
<p>This brings me back to my initial question: Crosstalk aware optimization is possible in post-route stage only? The answer is no. Any company, who wants you to believe otherwise are trying to hide the fundamental limitations with their P&#038;R software to handle this effect appropriately.</p>
<p>Let me talk about how AtopTech’s Aprisa has tried to address this very issue. Instead of thinking about SI as a post-route issue, it is handled more in-line in the tool as any other thing like doing CTS or placement. Crosstalk prevention and fixing starts as soon as the global route is laid out. Here, actual optimization engine is called to optimize the design to fix and prevent crosstalk based timing effects. All this is not done based on some heuristics but actual timing windows etc. to accurately fix the problems where they will get reported by the sign-off tool. To do all this, P&#038;R tool needs ultra-fast timer and extraction engines. Not only that, timer as well as extraction engines need to incremental to get to the next violating path faster. Both of this is achieved in Aprisa with help of multi-threaded extractor and timer. In addition, after doing global route and track assignment based SI fixing, the same is done during and after detail routing. Again, fast timer/extractor makes it possible to achieve timing closure in real time and not waiting for days to figure out if the design will be ultimately timing and routing clean.</p>
<p>In summary, if you are still struggling with timing closure on your chip, I will strongly recommend to challenge the methodologies setup for crosstalk aware timing closure…</p>
]]></content:encoded>
			<wfw:commentRss>http://www.techguri.com/2009/09/08/myth-8-crosstalk-aware-timing-fixing-can-be-done-in-post-route-stage-only/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Azuro Strengthens Leadership in Low-power CTS on Complex SoC Designs</title>
		<link>http://www.techguri.com/2009/07/28/azuro-strengthens-leadership-in-low-power-cts-on-complex-soc-designs/</link>
		<comments>http://www.techguri.com/2009/07/28/azuro-strengthens-leadership-in-low-power-cts-on-complex-soc-designs/#comments</comments>
		<pubDate>Tue, 28 Jul 2009 23:59:54 +0000</pubDate>
		<dc:creator>Azuro, Inc.</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Azuro]]></category>
		<category><![CDATA[CTS]]></category>
		<category><![CDATA[low-power clock tree synthesis]]></category>
		<category><![CDATA[nanometer chip design]]></category>
		<category><![CDATA[PowerCentric]]></category>
		<category><![CDATA[SoC]]></category>
		<category><![CDATA[system-on-chip]]></category>

		<guid isPermaLink="false">http://www.techguri.com/?p=499</guid>
		<description><![CDATA[ Azuro, Inc., a provider of advanced implementation tools for nanometer chip design, today announced version 5 of  its PowerCentric™ low-power clock tree synthesis (CTS) solution with extended support for complex system-on-chip (SoC) designs.  ]]></description>
			<content:encoded><![CDATA[<p><em>New release of PowerCentric™ delivers reduced power, faster runtimes, UPF 2.0 support, and ground- breaking new rapid CTS prototyping</em></p>
<p><strong>SANTA CLARA, Calif., July 28, 2009 –</strong> Azuro, Inc., a provider of advanced implementation tools for nanometer chip design, today announced version 5 of  its PowerCentric™ low-power clock tree synthesis (CTS) solution with extended support for complex system-on-chip (SoC) designs.  </p>
<p> “Azuro’s proprietary global approaches to clock tree balancing and patented clock gate optimization algorithms are ideally suited to complex SoC designs,” said Paul Cunningham, CEO and co-founder of Azuro. “PowerCentric is being actively used to tape out many of the world’s most complex chips with hundreds of intertwined clocks and dozens of voltage islands. This latest software release strengthens our proven leadership position in CTS and reinforces Azuro’s continued commitment to deliver lowest clock power, best clock gate timing, and fastest CTS turnaround time.”</p>
<p>Key features in PowerCentric version 5 include:</p>
<ul>
<li>30% reduction in CTS runtimes on designs with multiple modes and corners.</li>
<li>Enhanced clock gate optimization and clock tree buffering algorithms delivering up to 10% additional clock power savings.</li>
<li>Comprehensive support for UPF 2.0 (IEEE 1801™) power domain configuration format.</li>
<li>Ground breaking new “Trial CTS” capability delivering accurate post-CTS design timing with runtimes of less than one hour per one million placeable instances.  </li>
<li>Top level clock balancing through hardened sub-chips with back-annotated parasitics.</li>
<li>Full database save with rapid restore.</li>
</ul>
<p>PowerCentric version 5 is available now with UPF 2.0 support in limited availability. For more information on Azuro’s products and the technology behind them, please visit <a href="http://www.azuro.com">www.azuro.com</a>.</p>
<p><strong>About PowerCentric™</strong><br />
PowerCentric is a complete replacement for the clock tree synthesis (CTS) step in a digital chip design flow. It reduces chip power by up to 20% and dramatically increases designer productivity on designs with complex clock networks.<br />
<strong><br />
About Azuro™</strong><br />
Azuro is an electronic design automation (EDA) company supplying software tools to design digital semiconductor chips. The company’s unique clock tree synthesis and physical optimization technologies make chips faster, reduce chip power and dramatically accelerate chip time to market. Customers of Azuro’s software include Broadcom, Cambridge Silicon Radio, NVIDIA, NXP, STMicroelectronics, and Texas Instruments. Founded in 2002, the company is headquartered in Santa Clara, CA with R&#038;D in Cambridge, UK, and is privately held.<br />
Rubix, SASim, and PowerCentric are trademarks of Azuro, Inc.</p>
<p><strong>Contacts:</strong><br />
Azuro – Marc Swinnen, (408) 464-7350, <a href="mailto:marcs@azuro.com ">marcs@azuro.com </a></p>
<p>Cayenne Communication &#8211; Linda Marchant, (919) 451-0776, <a href="mailto:linda.marchant@cayennecom.com">linda.marchant@cayennecom.com</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.techguri.com/2009/07/28/azuro-strengthens-leadership-in-low-power-cts-on-complex-soc-designs/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
