Bronco Webinar 800x100 1
Semiconductor Expert Forum

Posted on

Why I’ll Always Be an Andy Grove Fan

Why I’ll Always Be an Andy Grove Fan
by Martin Lund on 04-29-2016 at 4:00 pm
Categories: Foundries, Intel Foundry

Silicon Valley sadly lost a respected and revered leader with the death of Andrew Grove in March. The co-founder and former CEO of Intel was an inspiration to generations of technologists and business leaders, including me. Andy had a profound influence on me throughout my career. And while I only met him once, I feel as though I’ve lost a friend and mentor.

When faced with difficult business situations, many times I have asked myself, “What would Andy do?” And most of the time, the answer would appear from applying the disciplined and analytical thought processes that Andy advocated.

I met Andy in 1997 at the Intel worldwide sales conference. Back then, I was working for a small Danish company that was being acquired by Intel. After his keynote, Andy came directly down to our table and asked us what we thought. One of the executives sitting at the table said something flattering and, frankly, vacuous. He then turned to me, and I bluntly pointed out what I thought was an important point he’d missed in his speech. Andy fixed his clear, blue eyes on me for an uncomfortably long moment, and I thought I had ended my career at Intel before it had even begun. But, then, I saw a flicker of recognition in his eyes and knew that he appreciated being told the truth, straight, and had no time for fluff.

That short interaction with Andy has stayed with me over the years, and so has his first management book, High Output Management. In fact, I like it so much that I’ve given out tens of copies to high-potential managers in my organizations. It’s still very relevant today.

I’d like to share the most important lessons I’ve learned from Andy:

Constructive confrontation.
The essence of constructive confrontation is about getting the best results through productive dialogs, even in the face of deep disagreement. In other words, fight for what you believe in with respect, passion and intellectual honesty. And when it’s all said and done, be prepared to disagree and commit.

Outside-in thinking.
Business leaders make bad decisions when they get caught up in the inertia of the status quo and the internal company reality. This lesson comes from the classic Intel story from the mid-1980s, when Andy Grove and then-CEO Gordon Moore were struggling to decide how to save the company. Andy famously asked, “If we both got fired and new management came in, what would they do?” The answer was, they would get out of memory chips and focus on microprocessors. That’s exactly what they did, and the decision led to one of the greatest corporate turnarounds ever. Being able to mentally step outside your company and view it dispassionately is vital for making good decisions, doing the right things and staying true to your objectives.

Good KPIs vs. Bad KPIs.
How your performance indicators are designed and implemented can change culture, processes and outcomes — for better and for worse. I have used the concept of leading indicators for almost 20 years — and not just for making breakfast!

Intent-based organizationaldesign.
Businesses oscillate between two main corporate structures: centralized and distributed. Each structure has merits. The important lesson here is that the correct organizational design for your company or business unit depends on the market environment and your business objectives.

Core drilling.
Just like with a soil test, Andy was able to sample all the levels of his company and knew the most finite details of his organization, all without micromanaging. This technique allows you to stay in touch with what’s really going on in your organization, and I’ve been able to use it effectively in the businesses I’ve managed.

Only the paranoid survive.
These are words to live by in business, and they became thetitle of Andy’s second management book in 1999. You have to respect your competitors, big or small, and should always be looking over your shoulder at what they’re doing. Also, you need to look constantly for disruptions and nonlinearity in your market. For me, it also means not succumbing to the not-invented-here syndrome and always having a healthy dose of humility, especially when everything seems fine.

A lifelong learner and teacher, Andy was an inspiration to people not just in Silicon Valley but everywhere, and from any walk of life. He will be missed. But his legacy lives on in all the people like me whom he has taught about technology, business and life.

Also read:

My morning with Andy Grove

The time Andy Grove came to Fortune and refused to meet with the editors

Andy Grove’s Less Remembered Intel

Good bye and thank you, Andy Grove!

Posted on

Ecosystem Partnership for Effective Network Hardware Design

Ecosystem Partnership for Effective Network Hardware Design
by Bernard Murphy on 04-29-2016 at 12:00 pm
Categories: EDA, Siemens EDA

When you’re designing a hardware solution to plug into what is arguably the most complex system of all – the Internet – you can’t get away with a little fake traffic to test whether your box is going to do all the right things at the right performance. You have to model realistic voice, video, data and wireless traffic in multiple protocols (and software-defined networking) at variable bandwidths.

First, you’re obviously not going to do this with a simulator, which, best-case, might model 100 packets per day. You need to get to tens of millions of packets a day over 128 ports to have a reasonable chance of tracing bugs. And that’s only possible in emulation.

But then how do you model realistic traffic? Networking design teams already know the answer to this one. They work with companies like Ixia who are well established in providing solutions for validating and optimizing physical and virtual networks and particularly, in this instance, for network modeling and traffic testing.

So you have great solutions on either end of the modeling problem – design modeling and network modeling – but that usually means the design team has to figure out how to hack some kind of connection between the two, usually inelegant, inefficient and incomplete and often in as much need of debug as the design itself.

Or the solution providers on each end could partner, which is exactly what Mentor and Ixia have done. Mentor has integrated the Mentor® Veloce® emulation platform- through the Virtual Network (VN) App – with Ixia’s virtual edition test product family – IxNetwork® Virtual Edition (VE) to accelerate the verification of complex networking chips.

The key value of the integration is Ixia script re-use with the emulator. This means that Ethernet traffic generation is consistent between simulation, emulation and lab testing. Being able to run realistic traffic on the emulator is half of what design teams need – knowing that it will correlate with real lab testing is the other half and is often where custom-crafted integrations break down.

Mentor built the VN App in a close collaboration between the R&D teams at Mentor and Ixia. VN has been designed to create a highly optimized flow from simulation to the lab for greater efficiency and improved debug. Mentor is currently demonstrating a working prototype to mutual customers in their emulation lab in Fremont California.

You can learn more about other Veloce emulator applications HERE.

More articles by Bernard…

Posted on

Process Development, CAD and Circuit Design

Process Development, CAD and Circuit Design
by Daniel Payne on 04-29-2016 at 7:00 am
Categories: EDA, Primarius

Working at Intel as a circuit designer I clearly remember how there were three distinct groups: Process Development, CAD and Circuit Design. Each of the groups sat in a different part of the building in Aloha Oregon, we had different job titles, different degrees, spoke with different acronyms and yet we all had to work together somehow to ensure success for our company. There is one company that does span all three of these groups over the past 20 years, and that’s ProPlus. I just watched their latest archived webinar on a new tool for process and device evaluation, so wanted to blog about what I learned.

The CTO of ProPlus is Dr. Bruce McGaughy, he was the presenter in this webinar and we’ve met at DAC over the years to get an update on what’s new. SoC designers today have many foundries to choose from, and each foundry has multiple process nodes where each node may have many variants, so sifting through all of this complexity is a challenge as the Process Design Kits (PDKs) are always changing.

In the days of 180nm process nodes we were using BSIM 3 models for transistor behavior and they used dozens of parameters, however now at the 16nm node we’re using BSIM-CMG models which can have thousands of parameters in each model. Transistors can use macro-models and custom found models, which add to the complexity.

CAD engineers can manage the relationship with the foundry and cope with the PDK files and versions, then the design teams can use the models to run SPICE circuit simulations, monte carlo analysis and other tools for variation analysis. How do you manage all of the revisions inherent in this cycle?

A New Tool
ProPlus has created a new tool dubbed MEPro to help cope with these issues, so here’s what goes into that tool and how it helps in five areas.

Using the PDK model library as the key input you can now explore, compare and even verify the soundness of the models. Designers are assisted because they can understand and explore the process design space. The five ways to look at any process with this tool are:

  • Browse your library files using familiar icons for folders and files
  • Review the process specification sheet to see how it matches your requirements
  • Look at device-level behavior curves
  • See the statistical variation of process parameters
  • Look at circuit simulation results using each process variant

A first-time user of MEPro can invoke the tool, load a PDK library, then click OK to run 1,212 plots showing device performance based on pre-defined templates, all in under 1 minutes by using the built-in Fast SPICE tool NanoSpice. Trying to do the same thing with your own scripts, assembling the plots and presenting the data would likely take days to weeks of effort. The templates may be updated by using a GUI, and then you can save or share any of your projects.

Traditional design books are static documents, while using MEPro you can create all the data used in a design book very quickly and interactively, providing more insight.

One application for MEPro is model exploration by using custom templates that have been configured to your specific needs. One example of customized templates showed how the tool could produce five different types of data: Process Spec Sheet, analog device curves, memory device curves, digital device curves and even custom analysis curves.

Analog designers can explore device characteristics, matching and statistical behavior of a process. Layout Dependent Effects (LDE) can often be a bit mysterious to the designer, so MEPro helps you by visualizing the value of SA graphically. Process variations like multiple Vt choices can be shown graphically for measurements like Idsat as a scatter or linear plot. You can plugin any transistor-level circuit to your template, browse your netlist, then get quick SPICE simulation results shown graphically in one environment.

Users can benchmark and compare two different processes like 28HP and 28HPM, as the tool graphically shows PMOS and NMOS transistor curves. There’s no need for manual data collection, or using Excel for comparisons.

Let’s say that your process model from the foundry has been updated, how do you know the impact on your designs after this revision? Using MEPro you can quickly find out how your most sensitive circuits are affected by a new PDK revision.

Models can actually be verified with MEPro in terms of:

  • Accuracy checking – model versus silicon measurements
  • Quality checking – are there any kinks, glitches, crossover or continuity issues
  • Behavior checking – curves are monotonic, peaks, symmetry, range checking

In summary, you can approach the task of comparing, validating or evaluating PDK models manually or with an automated flow like in MEPro. The time savings with the automated flow approach look impressive. Bridging the gap between foundries and fabless design users is now made easier. Designers can now more readily understand any process, get better margin out of their designs, or even ask the foundry to tweak the process for their specific design.

Dr. Lianfeng Yang then did a live product demonstration to show how intuitive MEPro is to use, running on his laptop.

Watch the entire 59 minute webinar online here.

Posted on

Webinar alert – VHDL guru says its time to move up

Webinar alert – VHDL guru says its time to move up
by Don Dingee on 04-28-2016 at 4:00 pm
Categories: Aldec, EDA

Many years ago when I worked for Ed Staiano at Motorola, I learned never to use the word “comfortable” in a career context. I’m comfortable being with family and friends. This new high-back chair I sit in at my new faux-cocobolo desk (slightly distressed chalk-painted wood and industrial piping, awesome) is comfortable, a lot more so than that camp chair I was on for a few months. It’s comfortable inside this air conditioned house on a humid day. But I’m never, ever comfortable with my knowledge, competitiveness, or position at work. Andy Grove may have written the book, but Ed lead the choir on comfort leading to complacency.

Engineers tend not to operate that way (unless they encounter one of these managers or their disciples). Expertise has a high value. Years of investment in learning every detail of a skill lead to more opportunities to use that skill. That works for a while, perhaps even decades, until it becomes time to upgrade skills. COBOL programmers are still out there, but they don’t get a lot of new opportunities unless they learn something more on the cutting edge.

I can see engineers being extremely comfortable with VHDL. It’s tried, and proven, and still usable. But it’s the 21[SUP]st[/SUP] Century and all, and there are new standards and new tools and people getting better results in chip design. Resisting a move to SystemVerilog and UVM, now both in wide adoption and growing, can be a career limiter.

So when the author of “VHDL: Programming by Example” speaks on a webinar providing a look at SystemVerilog and contrasting its features and use with VHDL, it’s time to move up. Doug Perry is working at Doulos these days as a Senior MTS, and he may be the biggest of the VHDL gurus left – many VHDL designers have his book on their desk.

Perry will walk through the challenges in making the transition from comfortable VHDL to the more modern SystemVerilog from his unique perspective, using examples running in Aldec Riviera-PRO. Registration for this May 4th webinar is free on the Doulos site:

Getting into SystemVerilog from VHDL: Guidance from a VHDL Guru
Europe and Asia time zones
North America time zones

If you haven’t already made this move, take an hour and learn why you should from a guru.

Posted on

Software-Driven Verification Drives Tight Links between Emulation and Prototyping

Software-Driven Verification Drives Tight Links between Emulation and Prototyping
by Bernard Murphy on 04-28-2016 at 12:00 pm
Categories: Cadence, EDA, Prototyping

I’ve mentioned many times what has become a very common theme in SoC and system verification – it has to be driven by the software because any concept of exhaustively verifying “everything” is neither feasible nor meaningful. Emulation has become a critical component of this flow in validating and regressing software “close to the metal”. On an emulator you can even boot Linux and Android and run Android test suites – but not at a performance acceptable to the fast turns and regression needs of software development teams.


Accelerating performance often takes advantage of mixed platforms, for example combining virtual platforms with emulation to accelerate OS-boot. An increasingly common way to accelerate, especially as the design starts to converge, is by prototyping on an FPGA platform. This can run an order of magnitude (or better) faster than emulation, which makes it more practical for regression flows where you want to run hundreds, thousands or more tests in each regression pass. Prototyping is great on speed but doesn’t offer as much internal visibility to debug problems on the hardware side as emulators do, so you want be able to jump back to emulation (where you have much better internal visibility) for debug. There you isolate, diagnose and correct problems as they are discovered, while continuing regression testing on the prototype platform.

This means you need to be able to jump back and forth between prototyping and emulation to get to the coverage you need, and to shake out problems as they arise. But there’s a problem with this appealing concept – typically it can take up to 3 months to build a manually optimized FPGA prototype, and that’s not exactly conducive to quick turn-around debug between prototyping and emulation.


Cadence has been working on reducing the turnaround time by optimizing the flow between their Palladium™ (emulation) and Protium™ (prototyping) platforms as a natural extension to their continuum of verification solutions. Optimizations start logically with a unified compile to both platforms, enabling reuse of scripts, constraints, clock definitions, memory definitions and more.

This compatibility isn’t just for input formats. Clocking semantics are compatible between the Palladium and Protium environments—a netlist for the Protium tool can be moved back to the Palladium platform and debugged there. And the Protium tool is compatible with the SpeedBridge adapters that work with the Palladium environment.

In addition, Protium bring-up time (for handling memories and clocks, partitioning, FPGA back-end design and functional unit debug) has been reduced from months to weeks. And with the Perspec System Verifier (the Cadence implementation of the emerging PS standard for portable stimulus between platforms), you can easily transfer stimulus between engines. A further optimization is through support for black-boxing. Black-boxes for Protium are treated as “don’t-touch” – they don’t need to be rebuilt in the prototyper in subsequent revisions, which means you can further accelerate turn-around times in RTL transfer to Protium.

Between these capabilities and the ability of the Protium platform to backdoor download memory contents, you can quickly switch from regression in prototyping to a more detailed debug in emulation. And when you have accumulated enough fixes, you have a shorter path to rebuild a new prototype for late-stage regressions.

So design/verification teams have three options for hardware-enabled verification:

  • They can use pure emulation, all RTL in hardware, and test benches either synthesized into into the emulator or connected via acceleration. This option provides great, simulation-like debug on the hardware side, though the speed may not satisfy notoriously impatient software developers. :rolleyes:
  • A second, and faster, approach can use virtual platforms for the compute subsystem, intelligently connected to an emulation hosting the items that require full accuracy – like GPUs (reports show a speed improvement of between 50X and 200X). This second approach also allows you to execute software-driven tests faster (users report an up to 10X speed increase).
  • Finally, a third approach couples emulation with FPGA-based prototyping, which is ideal when the hardware has matured and you need the speed that will satisfy software developers.

Also, since the Palladium emulation database runs out of the box on the Protium platform, re-using the same front-end compile, users can make a tradeoff between fast automated bring-up with reasonable prototyping speed or more time-consuming manual optimization for even more speed. Cadence has seen reports of 5MHz to 10MHz out-of-the-box for FPGA-based prototyping using the fully automated flow, with potential to reach 10s of MHz up to 100Mhz by manually optimizing with partitioning guidance and black-boxing.

You can learn more about Protium capabilities in the following excellent webinar HERE.

More articles by Bernard…

Posted on

Bringing Formal Verification into Mainstream

Bringing Formal Verification into Mainstream
by Pawan Fangaria on 04-28-2016 at 7:00 am
Categories: EDA, Synopsys

Formal verification can provide a large productivity gain in discovering, analyzing, and debugging complex problems buried deep in a design, which may be suspected but not clearly visible or identifiable by other verification methods. However, use of formal verification methods hasn’t been common due to its perceived complexity and the expertise and effort required in preparing the design and testbench for formal verification. However, with growing design complexity formal verification is fast becoming an essential part of verification methodologies to catch those bugs prone to be missed by simulation or other verification engines even after a large number of cycles.

Not all designers or verification engineers have requisite expertise to prepare the design code for applying formal verification. A few expert engineers, who have acquired a good level of expertise about formal verification by using it over the years, are usually preoccupied with many other tasks and cannot be employed for the huge benefit formal verification can provide by applying it on large SoCs at the enterprise level. This results in ‘ad hoc’ formal verification by a few experts. The real potential of formal verification remains underutilized in an organization.

What if we had an intelligent methodology with an intelligent, high capacity, and easy-to-use tool which could automate things to leverage formal verification? We could utilize the skills of those formal verification experts to a large extent in formalizing the methodology and making the formal verification available for all designers and verification engineers without needing much of their expertise in introducing formal verification constructs into the design code.The formal verification could best complement simulation and other verification engines for faster verification closure of large SoCs.

I am very much impressed with VC Formal, the brand new tool for formal verification launched by Synopsys. This tool makes it very easy for a verification engineer to setup a design for formal verification, run, and debug it in quick steps.


In addition to formal property checking, VC Formal provides various apps which require minimal setup and are quick and easy to execute. They are all seamlessly integrated with the Synopsys verification and debug environment. For example, VC Formal and its apps use the same design parser and compiler as VCS, do quick analysis of code, report about ‘unreachable code’, and generate formal goals for code coverage. The apps include solutions like Formal Coverage Analyzer, Connectivity Checking, Sequential Equivalence Checking, and so on.

Recently, an app-based approach for formal verification has become very popular and is employed in a few tools in the market; however its effectiveness and success lies in the ease-of-use, tool capacity and performance, and effective interface with simulators and the debug system. VC Formal has large capacity and high performance which can be leveraged for exhaustive analysis required for hard-to-catch bugs, and of course for quick checks and analysis.

For debug, VC Formal uses Verdi, the most familiar debugging platform in the verification community. This provides design view, verification task management, progress status, waveforms, constraint generation, etc. on a single platform already familiar to design and verification teams, thus making it very effective for reproducing and debugging deep-rooted problems.

What is more important in a formal verification system is a strong methodology to define the flow keeping in mind the particular designs and their users, what to apply where and in which circumstances. This can be best done by experienced formal verification experts who can define the strategy to identify the design blocks which can be most effective for formal verification. Simple code coverage or any criteria other than verification closure cannot be an effective measure for formal verification. The formal strategy and methodology for a particular design flow can be best realized by a strong tool with high capacity, speed, strong formal engines with intelligent algorithms, and easy debugging.

Talking to Prapanna Tiwari, Senior Manager, Formal Verification Product Marketing at Synopsys, I learnt that VC Formal employs some brand new technologies that build an optimized formal model for faster operation such as SoC level connectivity checking or deep bug hunting in case of corner cases, among many others. Also, there are many usability features provided for effective interaction with designers to improve their productivity significantly.

Prapanna says the core engines in VC Formal were developed by a team of experienced professionals with deep expertise in formal verification. The GUI has been put through to realise a defined formal methodology most effectively. The tool is already in use with major design houses who have realized significant improvement in the time to verification closure of their designs.

There is an on-line webinar– Increasing Verification Closure Effectiveness with Formal Verification, first delivered live in the last week by Dr. Sean Safarpour, Formal Verification CAE Manager at Synopsys. Dr. Safarpour has presented in great detail about how to go about formal verification in general, the app engines and capabilities of VC Formal, the GUI, and debugging features with Verdi.

Also, Dr. Safarpour has explained setting up of a formal testbench, assertion setup and debug, and analysis of over-constraints through a real example. It’s worth attending this on-line webinar to learn about formal verification in general and specifics of VC Formal.

More Articles from Pawan

Posted on

Tcl scripts and managing messages in ASIC & FPGA debug

Tcl scripts and managing messages in ASIC & FPGA debug
by Don Dingee on 04-27-2016 at 4:00 pm
Categories: Blue Pearl Software, EDA, FPGA

Our previous Blue Pearl post looked at the breadth of contextual visualization capability in the GUI to speed up debug. Two other important aspects of the ASIC & FPGA pre-synthesis workflow are automating analysis with scripts and managing the stream of messages produced. Let’s look at these aspects Continue reading “Tcl scripts and managing messages in ASIC & FPGA debug”

Posted on

Metric-Driven Verification for System Signoff

Metric-Driven Verification for System Signoff
by Bernard Murphy on 04-27-2016 at 12:00 pm
Categories: Cadence, EDA

Everyone knows that verification is hard and is consuming an increasing percentage of verification time and effort. And everyone should know that system-level verification (SoC plus at least some software and maybe models for other components on a board) is even harder—which is why you see hand-wringing over how incompletely tested these systems are compared to expectations at the IP level.

The problem is not so much the mechanics of verification. We already have good and increasingly well-blended solutions from simulation to emulation to FPGA prototyping. The concept of UVM and constrained random test generation is now being extended to software-driven test generation.There are now tools to enable randomization at the software levels and the developing Portable Stimulus (PS) standard will encourage easy portability of use cases between platforms to trade-off super-fast analysis versus detailed analysis for debug.

The problem at the end of the day is that tools only test what you tell them to test (with possibly some randomization spread). Thanks to the effectively boundless state-space of a system level design, conventional views of test coverage are a non-starter. The burden of how well the design has been tested falls on a (hopefully) well-crafted and vigorously debated verification plan. This has to comprehend not only internally-driven and customer-driven requirements but also new standards (like ISO26262 for example) and regulatory requirements (e.g. for medical electronics).

Once you have that verification plan, you can quantify how far you have progressed towards “done” and more accurately predict functional closure. That has to depend on unambiguous metrics across each line in the verification plan: functional metrics, coverage metrics at the software level and hardware level, register and transaction metrics, performance and latency metrics, connectivity metrics for the top-level and IOs, safety and security metrics – all quantifiable, unambiguous metrics for every aspect of the design. And, for each of these sections there is an agreed upon verification plan which organizes and then breaks down the plan into a long list of sub-items which make up the actual details of the testing. This is metric-driven verification (MDV), now applied to system level.


Cadence Incisive vManager provides a platform to define the test plan (vPlan in Cadence terminology) in an executable format, and also provides the means to roll-up current stats from each of the verification teams and each of the many sources of verification data. You get an at-a-glance view of how far you have progressed on each coverage goal and you can drill down wherever you need to understand what remains to be done and perhaps where you need to add staffing to speed up progress.

One very interesting example where new tools are playing a role in getting to coverage closure is the increasing use of formal to test for unreachable cases. When you see in vManager that coverage on some aspect has flattened at something below 100%, it may be time to deploy formal proving to see if that last few percent is heavily populated by unreachable states. If so, you can call a halt to further testbench development because you know you are done.

While metric-driven verification is not new, Cadence Design Systems pioneered vManager in 2005 to encapsulate these concepts, really driving a more automated and verifiable foundation for system signoff. Instead of using spreadsheets, you can roll-up coverage from simulation, from static and formal analysis, and from emulation and prototyping software-driven verification. Cadence plans to continue integration of yet more metrics across this broad spectrum of technologies to further augment this capability.

To learn more about vManager, click HERE.

More articles by Bernard…

Posted on

No reason for FD-SOI Roadmap to follow Moore’s law!

No reason for FD-SOI Roadmap to follow Moore’s law!
by Eric Esteve on 04-26-2016 at 4:00 pm
Categories: FD-SOI, Foundries, STMicroelectronics

We in Semiwiki are writing about FD-SOI since 2012, describing all the benefits offered by the technology in term of power consumption, price per performance compared with FinFET, etc. Let me assess again that I am fully convinced that FD-SOI is a very smart and efficient way to escape from the Moore’s law paradox: the transistor cost is increasing for (FinFET) technology node below 20 nm, and that I expect FD-SOI to see market adoption.

But I think that some people are confused when dealing with FD-SOI. When you see some picture like this “SOI Roadmap” (from VLSIResearch), it seems that the picture designer has just made a copy of the Bulk Roadmap and pasted it with 2 years shift. Even if 28 and 22 nm FD-SOI become successful technologies –that I hope- it will take some time for the foundries supporting these nodes to generate enough ROI before investing in a way as described on this graphic.

As of today, the Bulk technology roadmap and the production status is well-known: 28 nm is in full production, 14/16 nm also, chips are in design in 7 and 10 nm and probably taped out in 10 nm. If we focus on 14/16 nm, we realize that the very high runners like application processors for mobile, PC processors and data center SoC probably represent most of the foundries (or Intel) revenues for this node, and these revenues are really high, thanks to Apple, Mediatek, Qualcomm, Samsung (and more).

As of today, the only application processor targeting FD-SOI has been demonstrated by STMicroelectronics in 2013; unfortunately, the company has now exited the mobile market. To make it clear, none of the above listed high runners chips has targeted FD-SOI and the reason is most probably linked with risk aversion. FD-SOI technology for advanced technology node is perceived as completely new (even if this is not true, see IBM) and taking the decision to move such a healthy business to a new technology is just too risky.

As a result, the heavy investment made by foundries to develop new FinFET nodes can be quickly recovered thanks to a fast and large ROI coming from the top semiconductor players who need to design always larger, faster and lower power SoC to keep their market share in the couple of very lucrative application, mobile AP, PC processor and data center SoC. And can afford the incredibly high development cost for 14/16 or 10 nm FinFET technology nodes.

If you look at this problem from another angle, that leave many more chips which will NOT be developed on these too expensive nodes, like SoC addressing application processor for automotive (infotainment, smart vehicle…), for consumer application and many more. These chips need high performance (but not the highest possible), low power (in some case like IoT the lowest possible) and a unit cost as low as possible. Because the addressed market is more in the million or 10’s million units than the 100’s million, the NRE and development cost has to be kept reasonable, and certainly not in the $100’s million like for advanced FinFET SoC.

FD-SOI adoption has started! Samsung forecast 10 tapeouts on 28nm FD-SOI this year, SONY is shipping a GPS chips (announced in Tokyo SOI Forum in January 2015), NXP has adopted 28nm FD-SOI for the two new platform (iMX-7 and iMX-8) and GlobalFoundries is well engaged in 22 FDX process. FD-SOI provides such advantage in term of power consumption, thanks to forward Biasing capability, that we can expect technology penetration in many segments where low power and low cost of ownership (unit price + NRE) is more important than ultimate performance.

But it will take time, and by the way I think that stopping the 28 nm FD-SOI roadmap in 2022 (like on the picture) doesn’t make sense. Because we can expect volume production to start only in 2017 for chips taped out this year, so it will not be surprising if 28 nm FD-SOI production last 10 years (2027). This also means that it will take longer to collect enough ROI to be in position to offer 14 nm FD-SOI. Why not offering 40 nm or even 65/55 nm FD-SOI instead? It would make sense to support SoC integrating mixed-signal and digital, addressing application like low cost IoT edge devices… If you agree with this position, you will also challenge the above forecast, at least the $6B figure for 16/14nm FD-SOI production in 2017 or 2018…

Let’s come back to the initial question: why should FD-SOI technology follow Moore’s law, when the technology has been defined as one option to escape Moore’s law paradox (higher transistor price for lower node)? I think the only reason is a lack of creativity, pushing to duplicate a concept validated for FinFET (roadmap) to FD-SOI, although the market dynamic is completely different. The technology and marketing people who have defined and marketed FD-SOI have tried to think outside the box, analysts should go outside of their comfort zone and not just resale the same framework. Which is valid for FinFET may be completely different for FD-SOI…

Eric Esteve from IPNEST –