I have posted numerous times about the emergence of the large ecosystems covering smartphones, tablets, laptops and eventually TV’s. Just look at the trouble Microsoft is having getting traction for Windows Mobile 7. It’s a nice operating system but the ecosystem is still limited. This value looking at the ecosystem in a large context doesn’t just apply to computers and smartphones. In the semiconductor space, the success (or lack thereof) of a foundry is heavily influenced by the surrounding ecosystem. I am using ecosystem in a broad sense. It encompases tool support, foundry technology support, and IP availability.
Smaller foundries often support a limited number of tools. An analog fab might have DRC files for Cadence’s Assura but not Synopsys’ Hercules or Mentor’s Calibre. A digital fab might support Calibre but not the others. This can drive customers away but supporting software that no customer uses is a waste of money and dilutes support for real customers. Striking the right balance of tool support can be tricky.
Technology support is related to tool support but extends to areas such as design guidance. Just because tools are supported doesn’t mean getting to the desired end result will be easy. If the device model support is piecemeal, with little guidance by the foundry, then design teams can be left with an impossible number of combinations of simulations if they are to reasonably assure manufacturability.
The largest ecosystem issue is often IP support for the target process. I remember a VP of a product line declaring that a part would be run at a foundry that was giving the chip company excellent wafer pricing. The problem was that many of the I/O’s would have to be designed from scratch. The IP didn’t exist for the target process. In other cases, the IP existed but would have to be purchased. Moving to another foundry avoided IP expenses since the IP was available under agreements already in place with no incremental use charges.
So what does a smaller foundry do? Covering all of the tool sets can mean expensive staffing. The same goes for technology support. IP support can be a frustrating catch-22 situation. IP vendors don’t target the small foundry because, well, because they are small. But… in order to grow, the small foundry needs better IP support. Argh!!!
Attacking these issues is important and it is all about creating as complete and comprehensive an ecosystem as possible. Both tool support and technology support, while having some differences, revolve around the same solution – people. Not the number of people but the quality. This is one place where individual capability trumps numbers. A great engineer who has a deep understanding of what the tools do and how they work can convert a technology file from one tool to a competing product in short order. Attacking this with numbers rather than quality just leads to frustrated customers who eventually take their business elsewhere. These engineers must deeply understand how the tools are used and what the design team’s frustrations will be. For that reason I have often hired engineers for these positions with some design background or exposed them to design so that they appreciate what is annoying and why. Similarly, a great technologist who understands the needs of design teams can save the design teams weeks and even months worth of work by using his understanding of how the process parametrics vary relative to each other to generate a concise set of simulation corners.
The IP problem is more difficult. It may be necessary to put an IP development team in place to make sure a process has at least the basics building blocks available. This is a place where inexpensive labor may be a good solution. However, some IP, particularly high speed SERDES, require a few top notch engineers. If there are a large number of processes needing IP, an optimum solution is often a small group of highly skilled engineers backed up by a pool of cost effective talent. That often means a design group either in India or China. Blending the two groups can be difficult but, properly done, it can yield big benefits.
There is one more approach to IP support which has emerged and deserves strong consideration. Just join an existing ecosystem. UMC does this by trying to match their processes to those of TSMC. UMC attempts to make it easy to use IP originally targeted at TSMC. GlobalFoundries, and to a lesser extent samsung, try to follow IBM. This relationship is open and by contract as opposed to that of UMC which is down without the support of TSMC. Samsung, IBM and GlobalFoundries are members of the Common Platform Alliance. The concept is to have common processes that share IP and that the combined capacity of these three foundries will attract IP developers. The formation this year of a larger group matching the members of the Common Platform Alliance with Intel and TSMC in a joint process development agreement, the Global 450 Consortium, has the potential to further strengthen this approach. However, unlike the Common Platform Alliance, the Global 450 Consortium has no stated goal regarding IP interoperability. Still, a common technology base opens up the possibility of easier IP portability. The big question is how will those companies on the outside, such as UMC and SMIC, react.
paulplatt 