Peter, I would agree that moving from one foundry to another is no trivial task! Qualcomm would be wise to invest in a part of a fab as a second source backup and to allow for upside production. I wonder if there is an available existing fab that would be reasonably compatible (or could be tweaked to be) with their existing foundry process?
Still, it is cheaper than building a fab.
For a company that couldn't tell oxidation from rust, the cost for IP would make a lot of lawyer very happy.
Anyway, it is a good joke. I can hear the roaring laugher coming from Shinchu.
Considering the rising cost and unclear roadmap to future CMOS, it doesn't make much sense to build their own fab at this point. Especially they are competing Intel and Samsung in the same market mobile processors. If they were using 90nm technology, then maybe. The statement from Qualcomm is directed at TSMC and pressure them to deliver on time.
Used to work like that until 40nm when only variables are stress engineering and gate oxide but not anymore.. The differences of advanced technologies are so subtle and is reached to the point that even Qualcomm do not have enough resources to make their design multi-sourceable and EDA tools are not sufficient(not upto par with technology changes) to address these issues.
A far cheaper way for fabless companies is to develop some independent DFM expertise and make their layout manufacturable everywhere.
The rules are more or less the same because the fabrication equipment are the same and the EDA software are the same. Fabless companies can build or uses or transform an existing standard organization to do it (Si2, Sematech, etc.).
For now, we are seeing the effects of de facto foreign monopoly. A monopoly helped by the fabless companies. Consumers will pay more.
There's nothing wrong with UMC or GlobalFoundries and -- as i discuss in an analysis -- I think GlobalFoundries could be a major supplier to Qualcomm.
However, the days when you could easily move an IC design from one foundry to another are long gone.
So are the technologies incompatible...well both foundries are offering CMOS.
But they are different CMOS processes, with different tweaks, design rules, checks and sequences. There is considerable foundry supplied IP required to make a design work and different foundries have different IP sets and design rules associated with those IPs.
The result has been that fabless chip companies have tended, even where they work with multiple foundries, to only bring a given design up at one foundry. To run genuine multivendor second sourcing is generally thought to be too expensive.
And at the leading-edge you would have to wait for a second foundry to match the first's capability. Waiting is not a good idea in consumer markets.
However, when you are single-sourced on a leading-edge process and you do not get the volume of chips you desire you start to think "How could i get favorable treatment? I want my allocation of chips and my rival's allocation."
Qualcomm's current supply problems come as part of a fabless strategy. You can't have it both ways. If you don't own a wafer fab, then you can not control your supply of chips. If you do own a fab then you have to pay for it when you have excess and, or, obsolete fab capacity. It's going to be expensive either way. In the last several years being fabless has been very good to Qualcomm. It may now change for the next several years. Right now it seems IDMs like Intel and Samsung have the advantage.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.