<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: DAC Theme #2 - &#8220;Oasys Frappe&#8221;</title>
	<link>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/</link>
	<description>sharing insights into the people side of ASIC design</description>
	<pubDate>Sat, 11 Feb 2012 19:56:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.2</generator>
		<item>
		<title>By: Nick</title>
		<link>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1149</link>
		<dc:creator>Nick</dc:creator>
		<pubDate>Thu, 13 Aug 2009 11:54:42 +0000</pubDate>
		<guid>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1149</guid>
		<description>While the concepts fundamental to any logic synthesis system  remain the same (even if it is global synthesis algorithms) and all being derived from berkeley synthesis in one form or another,  synopsys or any other CAD vendor would have made significant changes to their algorithms to accommodate growing design sizes and moore's law  and more importantly to stay ahead of competetion.

And any innovation in synthesis has been very incremental over a long period of time with a lot of hardwork. More recently (past 10 years!) a push for physical synthesis which pushes the placement information back into the logic synthesis environment. Almost every major cad vendor has physical synthesis in the flow.

In the present day synthesis market, jargon and marketing claims wont just cut it and only benchmarks will prove which synthesis tool is better.</description>
		<content:encoded><![CDATA[<p>While the concepts fundamental to any logic synthesis system  remain the same (even if it is global synthesis algorithms) and all being derived from berkeley synthesis in one form or another,  synopsys or any other CAD vendor would have made significant changes to their algorithms to accommodate growing design sizes and moore&#8217;s law  and more importantly to stay ahead of competetion.</p>
<p>And any innovation in synthesis has been very incremental over a long period of time with a lot of hardwork. More recently (past 10 years!) a push for physical synthesis which pushes the placement information back into the logic synthesis environment. Almost every major cad vendor has physical synthesis in the flow.</p>
<p>In the present day synthesis market, jargon and marketing claims wont just cut it and only benchmarks will prove which synthesis tool is better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Swinnen</title>
		<link>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1147</link>
		<dc:creator>Marc Swinnen</dc:creator>
		<pubDate>Wed, 12 Aug 2009 19:03:13 +0000</pubDate>
		<guid>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1147</guid>
		<description>I want to applaud Oasys for introducing new technology and trying to move synthesis forward. Taking risks and tackling the hard problems are what startups are supposed to do. 

From a technical perspective, I think you are absolutely correct with your first concern where you say it is not really possible to close timing without considering the real, propagated clock tree. 

You are also correct in pointing out that the other synthesis vendors do not optimize with the clock either. 

The best technical solution for your concern is a combination of Oasys’ product and a clock concurrent optimization tool like Rubix: Oasys does a very fast synthesis and placement to get timing into the ballpark. Rubix then does a detailed physical optimization while building the clock trees at the same time. Rubix essentially builds a skewed clock network specifically tailored to match the logic while at the same time optimizing the logic to match the clock. This offers a fundamental solution to the problem you highlight. There is really no reason to view physical synthesis and CTS as two different steps. And you can forget about clock balancing – that has become an increasingly irrelevant holdover from the past.

Clock concurrent optimization closes design timing in propagated clock mode with full visibility of OCV derates, clock-gate timing, actual insertion delays, etc.

I’m glad that you recognized that clocks area major missing piece in traditional timing optimization approaches.</description>
		<content:encoded><![CDATA[<p>I want to applaud Oasys for introducing new technology and trying to move synthesis forward. Taking risks and tackling the hard problems are what startups are supposed to do. </p>
<p>From a technical perspective, I think you are absolutely correct with your first concern where you say it is not really possible to close timing without considering the real, propagated clock tree. </p>
<p>You are also correct in pointing out that the other synthesis vendors do not optimize with the clock either. </p>
<p>The best technical solution for your concern is a combination of Oasys’ product and a clock concurrent optimization tool like Rubix: Oasys does a very fast synthesis and placement to get timing into the ballpark. Rubix then does a detailed physical optimization while building the clock trees at the same time. Rubix essentially builds a skewed clock network specifically tailored to match the logic while at the same time optimizing the logic to match the clock. This offers a fundamental solution to the problem you highlight. There is really no reason to view physical synthesis and CTS as two different steps. And you can forget about clock balancing – that has become an increasingly irrelevant holdover from the past.</p>
<p>Clock concurrent optimization closes design timing in propagated clock mode with full visibility of OCV derates, clock-gate timing, actual insertion delays, etc.</p>
<p>I’m glad that you recognized that clocks area major missing piece in traditional timing optimization approaches.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: harry</title>
		<link>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1145</link>
		<dc:creator>harry</dc:creator>
		<pubDate>Wed, 12 Aug 2009 07:10:00 +0000</pubDate>
		<guid>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1145</guid>
		<description>Hi Jeff,

Good to hear from you after all these years. I should have posted something about synthesis sooner :-)

Someone came up with a idea on Twitter that we really need to objectively benchmark the tools to see which one really performs the best. Just like with the BCS in college football, we really need a playoff to settle this thing on the field of play.

If such a benchmark could be arranged, and if it were fair, would Cadence participate?

Oasys and Synopsys: If you are reading this, would you participate?

Moment of truth.

Harry</description>
		<content:encoded><![CDATA[<p>Hi Jeff,</p>
<p>Good to hear from you after all these years. I should have posted something about synthesis sooner <img src='http://theasicguy.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>Someone came up with a idea on Twitter that we really need to objectively benchmark the tools to see which one really performs the best. Just like with the BCS in college football, we really need a playoff to settle this thing on the field of play.</p>
<p>If such a benchmark could be arranged, and if it were fair, would Cadence participate?</p>
<p>Oasys and Synopsys: If you are reading this, would you participate?</p>
<p>Moment of truth.</p>
<p>Harry</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Flieder</title>
		<link>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1144</link>
		<dc:creator>Jeff Flieder</dc:creator>
		<pubDate>Tue, 11 Aug 2009 18:39:55 +0000</pubDate>
		<guid>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1144</guid>
		<description>Harry,
	Thanks for posting this information about Oasys, it was very informative. As you know, I’m a long time synthesis guy as well, having worked at Synopsys for many years as an AE and Consulting Manager. What you probably don’t know is that for the past 7 years I’ve been at Cadence working with RTL-Compiler and associated products. I’d like to comment on some of your statements in this posting.
First of all, comparing RTL-Compiler to all the other “Groundhog Day” products is a completely unfair comparison.  All of the other synthesis tools you mentioned are all based on the same Berkeley Algorithms as Design-Compiler and you quite rightly refer to them as “me too products”. RTL-Compiler is very different in that it is based on an entirely new set of Global Synthesis algorithms that are unrelated to Berkeley Based synthesis tools. RTL-Compiler was architected from the ground up by a group of very experienced synthesis engineers, many of which started their careers as software developers at Synopsys. They understood the shortcomings of single objective, rule based synthesis, and set out to create an entirely new type of synthesis tool. After many years of work they created RTL-Compiler, which is a multi-objective globally synthesis tool. While I don’t have the time to go into all the details of this groundbreaking technology, or it’s impact on modern chip design, suffice it to say that we consistently see better results than any other synthesis tool on the market. I would be happy to discuss this in gory detail with you (and anyone else for that matter) at your convenience.
I would like to address some of the technology that you mentioned in your blog and explain why I believe that the RTL-Compiler approach is better than what you describe.


1.	My first comment has to do with getting to meaningful optimization almost immediately in the synthesis flow and for this I could not agree more. In the RTL-Compiler world, we have something called Physical Layout Estimators that are used to accurately estimate 80 – 90% of the wires in the design during the initial synthesis. We have found this to give the best results while leaving the estimation of the last 10-20% of wires to our RC-Spatial or RC-Physical technology. These technologies use real placement to estimate these outlying wires.
2.	The RTL partitioning idea, while interesting, seems a bit impractical in today’s world of global design teams and IP reuse. It is very unlikely that any designer has the ability to let a tool repartition the design and move RTL from one layout block to another automatically. Most of these decisions are made based on the chip level architecture and data flow and are defined very early in a project.. I would also imagine that this would make any post-synthesis verification a nightmare at best, and impossible at worst. And trying to perform an automated ECO after this would most likely be impossible.
3.	As for your comment on physical optimization after the initial synthesis, this is one place where RTL-Compiler really shines. Over the last few years we have developed significant advances in physical synthesis. Not only can we optimize based on legal placement, but we have also added the ability to modify the design in order to reduce congestion, improve timing, and reduce area and power, all based on detailed physical information. This technology also allows us to write out a full legal placement to feed forward to any P&#38;R tool.

So, in conclusion, I would like to say to Oasys welcome to the Logic Synthesis world. It has always been the case that more awareness of the issues surrounding synthesis are good for the tools and good for our customers. We are confident that we have the absolute best synthesis on the market and with continued research and development will continue to do so for the foreseeable future. If you would like to discuss this further, please feel free to contact me at jflieder@cadence.com. If nothing else, it would be good to catch up, it’s been a long time.</description>
		<content:encoded><![CDATA[<p>Harry,<br />
	Thanks for posting this information about Oasys, it was very informative. As you know, I’m a long time synthesis guy as well, having worked at Synopsys for many years as an AE and Consulting Manager. What you probably don’t know is that for the past 7 years I’ve been at Cadence working with RTL-Compiler and associated products. I’d like to comment on some of your statements in this posting.<br />
First of all, comparing RTL-Compiler to all the other “Groundhog Day” products is a completely unfair comparison.  All of the other synthesis tools you mentioned are all based on the same Berkeley Algorithms as Design-Compiler and you quite rightly refer to them as “me too products”. RTL-Compiler is very different in that it is based on an entirely new set of Global Synthesis algorithms that are unrelated to Berkeley Based synthesis tools. RTL-Compiler was architected from the ground up by a group of very experienced synthesis engineers, many of which started their careers as software developers at Synopsys. They understood the shortcomings of single objective, rule based synthesis, and set out to create an entirely new type of synthesis tool. After many years of work they created RTL-Compiler, which is a multi-objective globally synthesis tool. While I don’t have the time to go into all the details of this groundbreaking technology, or it’s impact on modern chip design, suffice it to say that we consistently see better results than any other synthesis tool on the market. I would be happy to discuss this in gory detail with you (and anyone else for that matter) at your convenience.<br />
I would like to address some of the technology that you mentioned in your blog and explain why I believe that the RTL-Compiler approach is better than what you describe.</p>
<p>1.	My first comment has to do with getting to meaningful optimization almost immediately in the synthesis flow and for this I could not agree more. In the RTL-Compiler world, we have something called Physical Layout Estimators that are used to accurately estimate 80 – 90% of the wires in the design during the initial synthesis. We have found this to give the best results while leaving the estimation of the last 10-20% of wires to our RC-Spatial or RC-Physical technology. These technologies use real placement to estimate these outlying wires.<br />
2.	The RTL partitioning idea, while interesting, seems a bit impractical in today’s world of global design teams and IP reuse. It is very unlikely that any designer has the ability to let a tool repartition the design and move RTL from one layout block to another automatically. Most of these decisions are made based on the chip level architecture and data flow and are defined very early in a project.. I would also imagine that this would make any post-synthesis verification a nightmare at best, and impossible at worst. And trying to perform an automated ECO after this would most likely be impossible.<br />
3.	As for your comment on physical optimization after the initial synthesis, this is one place where RTL-Compiler really shines. Over the last few years we have developed significant advances in physical synthesis. Not only can we optimize based on legal placement, but we have also added the ability to modify the design in order to reduce congestion, improve timing, and reduce area and power, all based on detailed physical information. This technology also allows us to write out a full legal placement to feed forward to any P&amp;R tool.</p>
<p>So, in conclusion, I would like to say to Oasys welcome to the Logic Synthesis world. It has always been the case that more awareness of the issues surrounding synthesis are good for the tools and good for our customers. We are confident that we have the absolute best synthesis on the market and with continued research and development will continue to do so for the foreseeable future. If you would like to discuss this further, please feel free to contact me at <a href="mailto:jflieder@cadence.com">jflieder@cadence.com</a>. If nothing else, it would be good to catch up, it’s been a long time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SKMurphy &#187; DAC 2009 Blog Coverage Roundup</title>
		<link>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1142</link>
		<dc:creator>SKMurphy &#187; DAC 2009 Blog Coverage Roundup</dc:creator>
		<pubDate>Tue, 11 Aug 2009 00:34:54 +0000</pubDate>
		<guid>http://theasicguy.com/2009/08/10/dac-theme-2-oasys-frappe/#comment-1142</guid>
		<description>[...] Oasys Design: Harry Gries on &#8220;DAC Theme #2: Oasys Frappe&#8220; [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Oasys Design: Harry Gries on &#8220;DAC Theme #2: Oasys Frappe&#8220; [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

