<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<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 for All About EDA</title>
	<link>http://www.allabouteda.com</link>
	<description>All about EDA, VHDL/Verilog, Logic and Circuit Simulation, and more, from an Expert!</description>
	<pubDate>Mon, 06 Sep 2010 07:44:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>Comment on Gemini uncloaks, announcing threaded SPICE. We talk with them to find out more. by Arvel Peterson</title>
		<link>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-14515</link>
		<dc:creator>Arvel Peterson</dc:creator>
		<pubDate>Wed, 02 Jun 2010 20:03:40 +0000</pubDate>
		<guid>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-14515</guid>
		<description>&lt;i&gt;There are a lot of big claims from Gemini. I know from my experience at Mentor Graphics with the FastSPICE tool Mach TA that it can take man-years of development effort just to get the parser working robustly for HSPICE, let alone adding Spectre and Verilog-A into the mix. That&#8217;s a lot of productivity out of a small group of developers in such a short period of time. I wish them all of the success in the SPICE world. The start-up companies are offering the most innovation in the SPICE space for now. I&#8217;d love to see a head-to-head live benchmark of: Gemini, Infinisim, HSPICE, Spectre, Berkeley DA Analog Fast SPICE. Maybe we could get Sun or Intel to provide the hardware, then allow the teams to tune their results for one week on the condition that they show the results publicly, let&#8217;s say at a design conference or trade show, along with a panel of judges to declare winners in several categories (ie. PLL, Converters, Extracted netlists, charge pumps, memories, etc.).&lt;/i&gt;
+1</description>
		<content:encoded><![CDATA[<p><i>There are a lot of big claims from Gemini. I know from my experience at Mentor Graphics with the FastSPICE tool Mach TA that it can take man-years of development effort just to get the parser working robustly for HSPICE, let alone adding Spectre and Verilog-A into the mix. That&#8217;s a lot of productivity out of a small group of developers in such a short period of time. I wish them all of the success in the SPICE world. The start-up companies are offering the most innovation in the SPICE space for now. I&#8217;d love to see a head-to-head live benchmark of: Gemini, Infinisim, HSPICE, Spectre, Berkeley DA Analog Fast SPICE. Maybe we could get Sun or Intel to provide the hardware, then allow the teams to tune their results for one week on the condition that they show the results publicly, let&#8217;s say at a design conference or trade show, along with a panel of judges to declare winners in several categories (ie. PLL, Converters, Extracted netlists, charge pumps, memories, etc.).</i><br />
+1</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Second generation circuit simulation - Fast-SPICE by Michael Vye</title>
		<link>http://www.allabouteda.com/second-generation-circuit-simulation-fast-spice/#comment-13956</link>
		<dc:creator>Michael Vye</dc:creator>
		<pubDate>Thu, 13 May 2010 17:32:41 +0000</pubDate>
		<guid>http://www.allabouteda.com/second-generation-circuit-simulation-fast-spice/#comment-13956</guid>
		<description>I am seeking someone to run a spice program for the development of a circuit
916-424-1887</description>
		<content:encoded><![CDATA[<p>I am seeking someone to run a spice program for the development of a circuit<br />
916-424-1887</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Second generation circuit simulation - Fast-SPICE by kyle alexander</title>
		<link>http://www.allabouteda.com/second-generation-circuit-simulation-fast-spice/#comment-12961</link>
		<dc:creator>kyle alexander</dc:creator>
		<pubDate>Wed, 31 Mar 2010 16:43:22 +0000</pubDate>
		<guid>http://www.allabouteda.com/second-generation-circuit-simulation-fast-spice/#comment-12961</guid>
		<description>Is fast-spice circuit simulation a HOT or Good topic for research. I read few articles on this field in publications such as IEEE TCAD and ICCAD for now. (I am a rookie@circuit simulation research, :-b )</description>
		<content:encoded><![CDATA[<p>Is fast-spice circuit simulation a HOT or Good topic for research. I read few articles on this field in publications such as IEEE TCAD and ICCAD for now. (I am a <a href="mailto:rookie@circuit">rookie@circuit</a> simulation research, :-b )</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Rajeev says there&#8217;ll only be 2 EDA companies in 5 years. by voidEDA</title>
		<link>http://www.allabouteda.com/rajeev-says-therell-only-be-2-eda-companies-in-5-years/#comment-5959</link>
		<dc:creator>voidEDA</dc:creator>
		<pubDate>Sat, 25 Jul 2009 06:03:01 +0000</pubDate>
		<guid>http://www.allabouteda.com/rajeev-says-therell-only-be-2-eda-companies-in-5-years/#comment-5959</guid>
		<description>Synopsys will survive. No doubts. Mentor or Cadence for the other? I believe Mentor will survive. Cadence won't.</description>
		<content:encoded><![CDATA[<p>Synopsys will survive. No doubts. Mentor or Cadence for the other? I believe Mentor will survive. Cadence won&#8217;t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Gemini uncloaks, announcing threaded SPICE. We talk with them to find out more. by Kevin Cameron</title>
		<link>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-661</link>
		<dc:creator>Kevin Cameron</dc:creator>
		<pubDate>Thu, 30 Oct 2008 08:02:14 +0000</pubDate>
		<guid>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-661</guid>
		<description>The problem here is that to verify an analog design you need to run a lot of corners. A parallel processing simulator by its nature has lower throughput than a single threaded simulator in CPU cycles, i.e. you're usually better off running 4 jobs on a 4cpu machine than 1 4-threaded job (4 times), so multithreading is not really a big plus.  Also, analog designers hate switching tools so the ramp up time to revenue is usually way too long for newcomers to survive. I expect one of Gemini, Xoomsys or Nascentric may survive, but I wouldn't like to have money riding on it.</description>
		<content:encoded><![CDATA[<p>The problem here is that to verify an analog design you need to run a lot of corners. A parallel processing simulator by its nature has lower throughput than a single threaded simulator in CPU cycles, i.e. you&#8217;re usually better off running 4 jobs on a 4cpu machine than 1 4-threaded job (4 times), so multithreading is not really a big plus.  Also, analog designers hate switching tools so the ramp up time to revenue is usually way too long for newcomers to survive. I expect one of Gemini, Xoomsys or Nascentric may survive, but I wouldn&#8217;t like to have money riding on it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Gemini uncloaks, announcing threaded SPICE. We talk with them to find out more. by Simon</title>
		<link>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-659</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Thu, 30 Oct 2008 05:32:08 +0000</pubDate>
		<guid>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-659</guid>
		<description>I hear you on the productivity sink that full HSPICE netlist compliance can be - I've seen it take up to 10 man years to get it to the point where finding a defect became rare; where I define rare as "a less than monthly occurrence." But I've also seen 2 man years. 

As for the shoot-out, wouldn't that be nice? But I seem to recall at least one big EDA vendors End-User License Agreement expressly prohibiting publication of benchmark results, no matter if the benchmark ended in a win for them, a loss or a draw. Wonder if that's still the case.</description>
		<content:encoded><![CDATA[<p>I hear you on the productivity sink that full HSPICE netlist compliance can be - I&#8217;ve seen it take up to 10 man years to get it to the point where finding a defect became rare; where I define rare as &#8220;a less than monthly occurrence.&#8221; But I&#8217;ve also seen 2 man years. </p>
<p>As for the shoot-out, wouldn&#8217;t that be nice? But I seem to recall at least one big EDA vendors End-User License Agreement expressly prohibiting publication of benchmark results, no matter if the benchmark ended in a win for them, a loss or a draw. Wonder if that&#8217;s still the case.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Gemini uncloaks, announcing threaded SPICE. We talk with them to find out more. by Daniel Payne</title>
		<link>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-658</link>
		<dc:creator>Daniel Payne</dc:creator>
		<pubDate>Thu, 30 Oct 2008 05:09:12 +0000</pubDate>
		<guid>http://www.allabouteda.com/gemini-uncloaks-announcing-threaded-spice-we-talk-with-them-to-find-out-more/#comment-658</guid>
		<description>There are a lot of big claims from Gemini. I know from my experience at Mentor Graphics with the FastSPICE tool Mach TA that it can take man-years of development effort just to get the parser working robustly for HSPICE, let alone adding Spectre and Verilog-A into the mix. That's a lot of productivity out of a small group of developers in such a short period of time. I wish them all of the success in the SPICE world. The start-up companies are offering the most innovation in the SPICE space for now. I'd love to see a head-to-head live benchmark of: Gemini, Infinisim, HSPICE, Spectre, Berkeley DA Analog Fast SPICE. Maybe we could get Sun or Intel to provide the hardware, then allow the teams to tune their results for one week on the condition that they show the results publicly, let's say at a design conference or trade show, along with a panel of judges to declare winners in several categories (ie. PLL, Converters, Extracted netlists, charge pumps, memories, etc.).</description>
		<content:encoded><![CDATA[<p>There are a lot of big claims from Gemini. I know from my experience at Mentor Graphics with the FastSPICE tool Mach TA that it can take man-years of development effort just to get the parser working robustly for HSPICE, let alone adding Spectre and Verilog-A into the mix. That&#8217;s a lot of productivity out of a small group of developers in such a short period of time. I wish them all of the success in the SPICE world. The start-up companies are offering the most innovation in the SPICE space for now. I&#8217;d love to see a head-to-head live benchmark of: Gemini, Infinisim, HSPICE, Spectre, Berkeley DA Analog Fast SPICE. Maybe we could get Sun or Intel to provide the hardware, then allow the teams to tune their results for one week on the condition that they show the results publicly, let&#8217;s say at a design conference or trade show, along with a panel of judges to declare winners in several categories (ie. PLL, Converters, Extracted netlists, charge pumps, memories, etc.).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why aren&#8217;t EDA tools more precise? by Kevin Cameron</title>
		<link>http://www.allabouteda.com/why-arent-eda-tools-more-precise/#comment-654</link>
		<dc:creator>Kevin Cameron</dc:creator>
		<pubDate>Wed, 29 Oct 2008 08:29:00 +0000</pubDate>
		<guid>http://www.allabouteda.com/why-arent-eda-tools-more-precise/#comment-654</guid>
		<description>Given that it's hard to build anything small on Silicon with much accuracy, there isn't a lot of market for a simulator that is super accurate. Manufacturing chips is pretty much a statistical game so for the simulator vendors it's an exercise in providing enough performance for engineers to verify their design over a rather large design/manufacturing space - i.e the emphasis is on handling multi-rate issues and employing parallel processing.

Some circuits do require accurate simulators to get the correct behavior and noise characteristics, but who is prepared to pay the extra for a simulator guaranteed to do it right?</description>
		<content:encoded><![CDATA[<p>Given that it&#8217;s hard to build anything small on Silicon with much accuracy, there isn&#8217;t a lot of market for a simulator that is super accurate. Manufacturing chips is pretty much a statistical game so for the simulator vendors it&#8217;s an exercise in providing enough performance for engineers to verify their design over a rather large design/manufacturing space - i.e the emphasis is on handling multi-rate issues and employing parallel processing.</p>
<p>Some circuits do require accurate simulators to get the correct behavior and noise characteristics, but who is prepared to pay the extra for a simulator guaranteed to do it right?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why aren&#8217;t EDA tools more precise? by Simon</title>
		<link>http://www.allabouteda.com/why-arent-eda-tools-more-precise/#comment-630</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Tue, 28 Oct 2008 07:09:34 +0000</pubDate>
		<guid>http://www.allabouteda.com/why-arent-eda-tools-more-precise/#comment-630</guid>
		<description>The big EDA companies certainly aim to hobble new technology. The primary reason, said to me pointedly many times, is to make it cheaper to acquire the technology/company if they're successful. A secondary reason may be to give them (the big EDA companies) the chance to develop some competing technology. One day I may write a post about my experience working with sales in the big EDA companies. The only problem is I'll have to go back into therapy to deal with opening that particular Pandora's box...

What is the need for high accuracy in solvers? It's really a case of how much precision is needed for the task at hand, no? If you're designing a power grid, can you actually get your job done with 2 digits of precision? There are many design groups who'd say not. There are those who want SPICE to deliver more than the customary 6 digits (I know you can use a .OPTIONS card to print more significant digits if you wish.) Frankly, solvers that deliver fewer than 6 digits, or worse that vary the results depending on some unrelated parameter (number of threads is one that bugs me), are playing a shell game, just moving the error around. 

I look at it this way: if you're trying to determine a parameter that's varying in the nth digit, you need to have tools accurate to the (n+2)th digit in order to have a chance of getting 1% accurate results. It's not uncommon for n to be 6 today. Hence, solvers accurate to 8 significant figures are required. That's non-trivial, and compute intensive. There's some very interesting innovation in this area that should see the light of day some time before next DAC. Watch this space!</description>
		<content:encoded><![CDATA[<p>The big EDA companies certainly aim to hobble new technology. The primary reason, said to me pointedly many times, is to make it cheaper to acquire the technology/company if they&#8217;re successful. A secondary reason may be to give them (the big EDA companies) the chance to develop some competing technology. One day I may write a post about my experience working with sales in the big EDA companies. The only problem is I&#8217;ll have to go back into therapy to deal with opening that particular Pandora&#8217;s box&#8230;</p>
<p>What is the need for high accuracy in solvers? It&#8217;s really a case of how much precision is needed for the task at hand, no? If you&#8217;re designing a power grid, can you actually get your job done with 2 digits of precision? There are many design groups who&#8217;d say not. There are those who want SPICE to deliver more than the customary 6 digits (I know you can use a .OPTIONS card to print more significant digits if you wish.) Frankly, solvers that deliver fewer than 6 digits, or worse that vary the results depending on some unrelated parameter (number of threads is one that bugs me), are playing a shell game, just moving the error around. </p>
<p>I look at it this way: if you&#8217;re trying to determine a parameter that&#8217;s varying in the nth digit, you need to have tools accurate to the (n+2)th digit in order to have a chance of getting 1% accurate results. It&#8217;s not uncommon for n to be 6 today. Hence, solvers accurate to 8 significant figures are required. That&#8217;s non-trivial, and compute intensive. There&#8217;s some very interesting innovation in this area that should see the light of day some time before next DAC. Watch this space!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why aren&#8217;t EDA tools more precise? by PitchMonk</title>
		<link>http://www.allabouteda.com/why-arent-eda-tools-more-precise/#comment-628</link>
		<dc:creator>PitchMonk</dc:creator>
		<pubDate>Tue, 28 Oct 2008 05:08:43 +0000</pubDate>
		<guid>http://www.allabouteda.com/why-arent-eda-tools-more-precise/#comment-628</guid>
		<description>Hi Simon,
I will come to the defense of EDA. 
Disclaimer:I am a ex-EDA employee (just like you). I still have some ties with EDA.

It is not that EDA players sweep the limitations under the carpet. More often, EDA falls into the trap of "averaging". For example, if you take two test cases and if a tool shows +50% in one test case and -50% in another, the tool vendor could claim as average accuracy of 0%. While a tool that consistently gets +0.5% will appear bad. Another trap is that EDA vendors are making a general purpose solution that works for all cases. This is because the more applications they can run, they can attract a bigger market. Often times, even the most innovative companies fall into this trap. Focusing on a specific problem and solving to perfection may be the right approach but the tool is losing out on other markets. Today EDA is dominated by the big ones - C, S, M and M. These companies own probably 90% of the market. Any new player has to challenge this might in order to succeed. And the market is shrinking anyway. Big companies kill innovation through many means, popular are roadmap and lawsuit (You must be well aware of #2). Even for the customers there is no incentive for promoting innovation. Imagine, if you have a tool that provides orders of magnitude  higher accuracy, do you think customers will start using this right away? Today, you need to read various SPICE netlists, must have ADE integration, support whole bunch of features before a customer even looks at the tool (believe me, this is based on personal experience). Even after you cross this hurdle, the customer will be saying, OK, we dont have any budget, because the ___(fill in your best EDA vendors' name) sales guy tool the whole budget. This is even before the competitive tools play their roadmap/lawsuit card. The key thing is even brilliant algorithmic expert gets dragged into all these issues rather than providing highest accuracy or precision. It is no wonder that most EDA companies aspire their exit to be acquisition.
One last comment: You have discussed the need for precision/accuracy during extraction. But you havent explained the need for higher accuracy in solvers.</description>
		<content:encoded><![CDATA[<p>Hi Simon,<br />
I will come to the defense of EDA.<br />
Disclaimer:I am a ex-EDA employee (just like you). I still have some ties with EDA.</p>
<p>It is not that EDA players sweep the limitations under the carpet. More often, EDA falls into the trap of &#8220;averaging&#8221;. For example, if you take two test cases and if a tool shows +50% in one test case and -50% in another, the tool vendor could claim as average accuracy of 0%. While a tool that consistently gets +0.5% will appear bad. Another trap is that EDA vendors are making a general purpose solution that works for all cases. This is because the more applications they can run, they can attract a bigger market. Often times, even the most innovative companies fall into this trap. Focusing on a specific problem and solving to perfection may be the right approach but the tool is losing out on other markets. Today EDA is dominated by the big ones - C, S, M and M. These companies own probably 90% of the market. Any new player has to challenge this might in order to succeed. And the market is shrinking anyway. Big companies kill innovation through many means, popular are roadmap and lawsuit (You must be well aware of #2). Even for the customers there is no incentive for promoting innovation. Imagine, if you have a tool that provides orders of magnitude  higher accuracy, do you think customers will start using this right away? Today, you need to read various SPICE netlists, must have ADE integration, support whole bunch of features before a customer even looks at the tool (believe me, this is based on personal experience). Even after you cross this hurdle, the customer will be saying, OK, we dont have any budget, because the ___(fill in your best EDA vendors&#8217; name) sales guy tool the whole budget. This is even before the competitive tools play their roadmap/lawsuit card. The key thing is even brilliant algorithmic expert gets dragged into all these issues rather than providing highest accuracy or precision. It is no wonder that most EDA companies aspire their exit to be acquisition.<br />
One last comment: You have discussed the need for precision/accuracy during extraction. But you havent explained the need for higher accuracy in solvers.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
