<?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>Notes from Silicon Valley &#187; Semiconductor Industry</title>
	<atom:link href="http://www.davidschwan.com/blog/category/semiconductor-industry/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.davidschwan.com/blog</link>
	<description></description>
	<lastBuildDate>Fri, 03 Feb 2012 16:22:48 +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>Analog Constraints</title>
		<link>http://www.davidschwan.com/blog/2010/10/analog-constraints/</link>
		<comments>http://www.davidschwan.com/blog/2010/10/analog-constraints/#comments</comments>
		<pubDate>Mon, 25 Oct 2010 17:47:56 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Semiconductor Industry]]></category>

		<guid isPermaLink="false">http://www.davidschwan.com/blog/?p=98</guid>
		<description><![CDATA[<p>During the 23rd Synopsys EDA Interoperability Forum an update was given on the status of the IPLnow efforts (http://www.iplnow.com). The majority of the new work in iPDK has to do with Analog Constraints. Here are some of my thoughts concerning analog constraints:</p> <p>Constraints are a type of meta data that describe behavior expected in a [...]]]></description>
			<content:encoded><![CDATA[<p>During the 23rd Synopsys EDA Interoperability Forum an update was given on the status of the IPLnow efforts (http://www.iplnow.com). The majority of the new work in iPDK has to do with Analog Constraints. Here are some of my thoughts concerning analog constraints:</p>
<p>Constraints are a type of meta data that describe behavior expected in a circuit. For our purposes constraints imply some particular attribute of a chip layout. Examples of a constraints include things like the width of a line, the orientation of a number of transistors, and the size of devices. Line width affects capacitance and resistance, too much or too little of each can impact a circuit in a negative manner. For circuit matching purposes devices need to be oriented in the same direction. Any matched devices need to share this same orientation, thus constraints regarding orientation are defined. Devices often need to be similar in size to match properly, thus placing size constraints is important; for example having two resistors, one 1 um by 1um versus 20um by 20um; the 20 um device will show less variation and thus much better matching characteristics.</p>
<p>Any system using constraints must support the following features:</p>
<ol>
<li>You must be able to visually confirm any defined constraint.</li>
<li>There must be a mechanism to allow automated verification of the defined constraints similar to a DRC check, and this check must be able to be run at tape-out.</li>
<li>Constraints must work cell to cell, not only within a given cell.</li>
<li>An automated mechanism needs to exist to override electrical constraints that impair a circuits performance.</li>
</ol>
<p>Most of these features are self evident, number 4 is not. For example, if early in a design I specify a line width of 2 um based on the current density requirements, and later the specification (and design) changes and requires 4um width, I have specified an incorrect constraint. Ideally I would like these constraints defined from some electrical parameter such as current which as the design is changed is tracked through layout. Unfortunately I suspect constraints will not be quite so flexible for a while, and we are stuck with line width. We do not want to have constraints defined that cause a circuit not to work. coming up with a solution to this will not be easy.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davidschwan.com/blog/2010/10/analog-constraints/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Thoughts about the 23rd Synopsys EDA Interoperability Forum</title>
		<link>http://www.davidschwan.com/blog/2010/10/thoughts-about-the-23rd-synopsys-eda-interoperability-forum/</link>
		<comments>http://www.davidschwan.com/blog/2010/10/thoughts-about-the-23rd-synopsys-eda-interoperability-forum/#comments</comments>
		<pubDate>Mon, 25 Oct 2010 05:56:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Semiconductor Industry]]></category>

		<guid isPermaLink="false">http://www.davidschwan.com/blog/?p=90</guid>
		<description><![CDATA[<p>On Thursday Oct. 21 Synopsys held their 23rd EDA Interoperability Forum. The following are some of my observations about the presentations.</p> <p>ARM</p> <p>It was hinted at by a representative from ARM that they actively are modifying their processors to improve the performance of Adobe Flash playback. Would Intel or some other processor vendor change their [...]]]></description>
			<content:encoded><![CDATA[<p>On Thursday Oct. 21 Synopsys held their 23rd EDA Interoperability Forum. The following are some of my observations about the presentations.</p>
<p><strong>ARM</strong></p>
<p>It was hinted at by a representative from ARM that they actively are modifying their processors to improve the performance of Adobe Flash playback. Would Intel or some other processor vendor change their hardware to improve Flash; I suspect not. H.264 does not seem to be subject to the same hardware enhancement. Apple on the original iPhone platform had a brilliant engineer work on there OpenGL implementation on a Broadcom chip (I know the engineer who did this). ARM is setting a dangerous precedent here. Software developers should be the ones to improve the performance of their software. Making hardware changes may ultimately introduce a non-optimal chip. Adobe should clean up their mess, not let chip companies fix things for them.</p>
<p><strong>Software and Power Consumption</strong></p>
<p>As mobile platforms contain to proliferate more attention will need to be placed on how power efficient. Both chip companies and cell phone manufacturers offer development platforms for creating applications for their mobile device(s). Since power consumption is so important to the usefulness of the mobile device, being able to profile an applications power consumption should be part of the development platform. Programmers normally do not think about power consumption when creating applications. This will change in the future. Power will be part of the applications developers total experience.</p>
<p>Each operating system has a power state profile. Someday we will see the power state profile become the chief design constraint.</p>
<p><strong>ESL</strong></p>
<p>In the Synopsys presentation on their ESL (electronic system level design) eco-system they made no reference to Mathworks MatLab and their Simulink environment. Most companies doing algorithm development use MatLab or more often these days Simulink as their preferred development platform. Interesting that Synopsys does not talk about this aspect of ESL.</p>
<p><strong>Keynote</strong></p>
<p>The keynote presentation included information from a case study of the design of a 130nm wireless chip. Lots of attention was placed on getting the firmware co-developed with the hardware as a way to improve the delivery date of a chip. What really got lost in this case study was how chip went through two re-spins to fix yield problems. While not stated I would assume these yield problems were in the the analog/RF portions of the chip. Getting rid of one of these re-spins would have a dramatic effect on the delivery date. Providing better tools to let designers eliminate a re-spin should be the goal of all of the EDA vendors, unfortunately this is not an easy problem to solve, and often requires a true mixed signal simulation solution. A different way to solve the problem is to use an architecture on chip that mitigates analog/RF yield issues; this again requires a true ESL solution that includes all those pesky analog/RF blocks, not just structures that can be implemented in TML (transaction level modeling).</p>
<p><strong>Customer Wants Versus EDA Vendor</strong></p>
<p>Results of a customer survey were presented, talking about how customers perceived accuracy as their most important criteria for a particular EDA tool. One vendor&#8217;s representative stated that he thought the customers (note plural) did not know what they where talking about, and that actually a different criteria was more important as a feature. I get very nervous about any company that thinks they know better than their customers. This implies they do not listen to their customers. Over the long term not a good way to interact with your customers.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davidschwan.com/blog/2010/10/thoughts-about-the-23rd-synopsys-eda-interoperability-forum/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Models versus Models</title>
		<link>http://www.davidschwan.com/blog/2010/05/models-versus-models/</link>
		<comments>http://www.davidschwan.com/blog/2010/05/models-versus-models/#comments</comments>
		<pubDate>Sun, 16 May 2010 00:19:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Semiconductor Industry]]></category>

		<guid isPermaLink="false">http://www.davidschwan.com/blog/?p=48</guid>
		<description><![CDATA[<p>I gave a presentation last year at the MOS-AK workshop in San Francisco. The people attending this workshop are all interested in simulation models for semiconductors. One of the comments made during the workshop, was that circuit designers blame the models when their circuits do not work right. In most cases what is meant as [...]]]></description>
			<content:encoded><![CDATA[<p>I gave a presentation last year at the MOS-AK workshop in San Francisco. The people attending this workshop are all interested in simulation models for semiconductors. One of the comments made during the workshop, was that circuit designers blame the models when their circuits do not work right. In most cases what is meant as model, is really the model parameters that are created by a foundry for a specific simulation model.</p>
<p>The real models go by names such as BSIM, PSP, Gummel-Poon, HICUM. These models are the sets of equations that mimic the electrical behavior of a device. The model is of itself useless without a set of parameters that are process and geometry unique. These parameters are created (fitted) from test circuits the foundry creates. A circuit simulator implements the particular models equations, this coupled with the model parameters, and a netlist describing the desired circuit will give a simulation of how the circuit should work.</p>
<p>A great deal of work goes into the model. This work is reviewed by many people. While mistakes can occur in the model, because of their wide adoption and peer review they tend not to be buggy. The model parameters on the other hand do not experience the same peer review process. The methods of extracting data to fit to the model may vary greatly, how well the data is fitted to the model is variable. Some foundries have very accurate model parameters, some not so accurate. When circuit designers talk of model problems most often they mean model parameter problems.</p>
<p>Model versus Model, really is Model versus Parameters.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davidschwan.com/blog/2010/05/models-versus-models/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Is Analog Design Feasible at </title>
		<link>http://www.davidschwan.com/blog/2009/09/is-analog-design-feasible-at/</link>
		<comments>http://www.davidschwan.com/blog/2009/09/is-analog-design-feasible-at/#comments</comments>
		<pubDate>Sat, 26 Sep 2009 21:00:50 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Semiconductor Industry]]></category>

		<guid isPermaLink="false">http://www.davidschwan.com/blog/?p=42</guid>
		<description><![CDATA[<p>As feature size is reduced in chip design life for digital design gets way more complicated. We are building 45 and 32nm chips using 193nm light sources. This is like using a 4 inch wide brush to paint 1 inch lines, something doable, but inherently limiting. Double patterning is beginning to be used to achieve [...]]]></description>
			<content:encoded><![CDATA[<p>As feature size is reduced in chip design life for digital design gets way more complicated. We are building 45 and 32nm chips using 193nm light sources. This is like using a 4 inch wide brush to paint 1 inch lines, something doable, but inherently limiting. Double patterning is beginning to be used to achieve the small feature sizes, by using two large feature masks, and printing each separately, the intention is to create the smaller feature size through two large steps[1]. By having two patterning steps, there are two alignment steps. This means that there will be misalignment, and this will be part of the inherent variation of the transistor. While this may be ok for digital design, is analog design going to be feasible? My feeling is this will make analog design so hard, so low performance, that it will force the push to using deep UV, from 193nm.</p>
<p>[1] &#8211; <a href="http://en.wikipedia.org/wiki/Double_patterning">http://en.wikipedia.org/wiki/Double_patterning</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.davidschwan.com/blog/2009/09/is-analog-design-feasible-at/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DVCon 2009</title>
		<link>http://www.davidschwan.com/blog/2009/02/dvcon-2009/</link>
		<comments>http://www.davidschwan.com/blog/2009/02/dvcon-2009/#comments</comments>
		<pubDate>Thu, 26 Feb 2009 00:46:40 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Semiconductor Industry]]></category>

		<guid isPermaLink="false">http://www.davidschwan.com/blog/?p=34</guid>
		<description><![CDATA[<p>I attended DVCon today at the Double Tree Hotel in San Jose. Went to the keynote address by Aart de Geus of Synopsys, and the panel session &#8220;EDA: Dead or Alive?&#8221;</p> <p>The Panel session was hosted by Peggy Aycinena of EDA Confidential. Also in attendance were Gabe Moretti or Gabe on EDA, and Gary Smith [...]]]></description>
			<content:encoded><![CDATA[<p>I <span>attended DVCon today at the Double Tree Hotel in San Jose. Went to the keynote address by Aart de Geus of Synopsys, and the panel session &#8220;EDA: Dead or Alive?&#8221;</span></p>
<p>The Panel session was hosted by Peggy Aycinena of EDA Confidential. Also in attendance were Gabe Moretti or Gabe on EDA, and Gary Smith of Gary Smith EDA. Those three represent the main journalists/analysts of the EDA industry. The starting tone of Peggy Aycinena was hostile to the EDA industry as a whole. A closing question by Gabe Moretti was equally hostile in nature. When I couple their behavior with comments over the last year by Gary Smith, the impression I get is that these are a bunch of people pissed off over not being able to make a living covering EDA for the mainstream press or being a full time research analyst. They all come off as a group of &#8220;old foggies&#8221; and do the EDA community a disservice from their lack of objectivity.</p>
<p>Open question that Peggy Aycinena asked of the panelists was whether they were worried about the trend that certain IDM&#8217;s were developing their own internal EDA tools versus buying commercial tools. The panel seemed dumbfounded by the question. She went on to state that Intel and IBM were developing their own tools. One of the panelists responded by saying that Intel and IBM were not the whole industry. Gary Meyers of Synopsys stated that they see much the opposite, that the development costs of creating internal EDA tools was prohibitive, and they were actively working with both Intel and IBM. Historically both Intel and IBM have had large internal EDA tool development programs. It is quite likely both continue to invest in internal tools for specific applications. IBM specifically stated last year at the Common Platform Technology Symposium that they were investing heavily in software to create mask data. When we hear that Qualcomm, Broadcom, and Marvell have large internal EDA development teams, then we should start to get worried about the EDA industry as a whole.</p>
<p>The question Gabe Moretti asked, was why the EDA companies don&#8217;t do something visionary, looking ahead 5 years for what the needs of the semiconductor industry might need. This is a stupid question. EDA companies are here to make money for their investors, they are not charities. Most EDA companies I know of are trying desperately to stay even with the foundries in providing tools that match the feature size of the latest process technology. If you want visionary research, look to the world&#8217;s universities.</p>
<p>The only other question asked by the audience was why don&#8217;t we see more open source software in the EDA world. Ravi Subramanian of Berkeley Design Automation had a simple answer to how useful open source software is. He stated that if you wanted to use a PSP model, you need a commercial simulator. Spice (from UC Berkeley) only supports BSIM. Simple tasks in the EDA world might be able to go open source, but for most applications the technology investment is far too great, the need far too current, for open source software to be able to keep up with the pace of development in the semiconductor world.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davidschwan.com/blog/2009/02/dvcon-2009/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>TSMC Technology Forum 2004</title>
		<link>http://www.davidschwan.com/blog/2004/04/tsmc-technology-forum-2004/</link>
		<comments>http://www.davidschwan.com/blog/2004/04/tsmc-technology-forum-2004/#comments</comments>
		<pubDate>Sat, 10 Apr 2004 00:20:10 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Semiconductor Industry]]></category>

		<guid isPermaLink="false">http://www.davidschwan.com/blog/?p=12</guid>
		<description><![CDATA[<p>Comments about TSMC&#8217;s 2004 Technology Forum - Moore&#8217;s law is not broken, its just slowed down. Not a true statement, just wishful thinking. There seems to be a fear that if we declare Moore&#8217;s law is over, that the whole semiconductor business is over.</p> <p>There are still only 40 products in development in 90nm, about [...]]]></description>
			<content:encoded><![CDATA[<p>Comments about TSMC&#8217;s 2004 Technology Forum -<strong> </strong>Moore&#8217;s law is not broken, its just slowed down. Not a true statement, just wishful thinking. There seems to be a fear that if we declare Moore&#8217;s law is over, that the whole semiconductor business is over.</p>
<p>There are still only 40 products in development in 90nm, about twice as many as a year ago (yet production comes in the second half of this year). 90nm was announced two years ago but still not in production. Just as SOC design looks feasible the development costs becomes crushing. For 65nm, the low power flavor is coming first; which is not typical of previous process introductions.</p>
<p>At 65nm they are using SiGe EPI.</p>
<p>Photomask costs are not coming down soon. To do PSM &amp; OPC some people are using 1000 processors to handle one mask.</p>
<p>At 90nm the mask cost is estimated to be 2-5% of the total cost of developing a chip (this is an estimate from p. 22 of the 2004 TSMC Technology Symposium Book). So at $2 million dollars for a mask set, we have $40-100 million total cost for a new chip. Consider that $30-40 million is a high number for raising venture capital; not many startups will be playing in this market space.<strong><br />
</strong></p>
]]></content:encoded>
			<wfw:commentRss>http://www.davidschwan.com/blog/2004/04/tsmc-technology-forum-2004/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

