Bronco Webinar 800x100 1

Conflating ISO 26262 and DO-254

Conflating ISO 26262 and DO-254
by Bernard Murphy on 01-30-2018 at 7:00 am

If you’re in the ASIC business, by now you should have a rough understanding of ISO 26262, the safety standard for automotive electronics. You may be less familiar with DO-254 which has somewhat similar intent for airborne electronics. Unless, that is, you design with FPGAs in which case your familiarity may be the other way around since there aren’t enough new aircraft produced each year to justify custom ASICs. So, ISO 26262 – ground-based vehicles, DO-254 – air-based vehicles, right?

Those lines are starting to blur. FPGAs are increasingly popular in ADAS and self/assisted- driving applications, particularly for their flexibility in supporting logic updates. Similar functionality is also useful in airborne applications. Planes are already well ahead of cars in self-piloting and continue to advance. Meantime ASIC products for those advanced cars (think deep-learning platforms and more sensor fusion) could also be used in planes.

The technology and business potential are appealing. But if you’re aiming at both markets, you now have to comply with both standards. How much fun is that going to be? Two sets of documentation, two organizations, two engineering flows, even two products? Actually, it isn’t that bad. Aldec recently hosted a webinar on what it takes to get to dual compliance and showed there is a significant degree of overlap and that while there is some overhead, it can be managed with careful planning.

Aldec invited Tom Ferrell to present on this topic. Tom is principal in his own organization and has a 25-year background in dealing with standards of this type, which naturally have proliferated as indicated in the useful chart above. Tom broadly contrasted ISO 26262 and DO-254 in this way. The automotive standard is industry-driven, compliance depends on 3[SUP]rd[/SUP]-party accreditation through the supply chain, allows for different level of compliance depending on context and compliance is voluntary, at least in principle. The aeronautic standard on the other hand is highly regulated, compliance depends on government or surrogate approval, must be uniform for a class of equipment and is effectively mandatory. He also noted that the standards are in some ways moving closer (albeit slowly) particularly in DO-254 through “guidance” extensions.

There are differences in terminology which can be confusing, particularly with respect to safety levels. There are also differences in scope (ISO 26262 is primarily about safety whereas DO-254 covers a broader range of requirements), how reliability is treated (the ISO standard is more explicit here), handling validation out of context (again ISO is better here) and personnel requirements (ISO requires identified staff with training/certification).

He added that that the ISO standard better defines the supplier interaction and that thanks to its relatively recent development and learning from prior standards it takes a more holistic view of the system and software. It also allows for data-driven decision-making. In contrast, the DO standard is arguably less prescriptive and integrates requirements for process assurance (unlike ISO).

Tom’s net from this is first that there are no blocking points or direct contradictions between the standards and that the tailoring (alternate means of compliance) option in the ISO standard provides a path to having it both ways. That said, you can’t fudge the documentation. You still have to generate two sets, but you can simplify the task (internally) by generating a compliance matrix where you match “items” (a loaded word, with different meaning in the ISO and DO standards) to check and document your compliance.

He also stressed that dual compliance is not something you can bolt on at the end of the product cycle. Planning for both has to start up-front, looking at architectural mitigation plans and safety analyses in both contexts. On the plus side, the required safety manager for ISO can also serve as the focal point for certification for the DO standard.

Tom made the point that this is hard work, requiring a deep understanding of both standards. Of course he’s plugging his services but I’m guessing people with his level of expertise are not thick on the ground. You can watch his presentation HERE. I should add a plug for Aldec also. This is an important topic and the webinar barely mentions Aldec tools (which are widely used in FPGA design, particularly in support of needs like this). Kudos to Aldec for promoting this general interest topic. This is true high-value content marketing!


IoT Designs Beginning to Shift to 7nm: Promises Upside for Cadence Physically-Aware Design Flow

IoT Designs Beginning to Shift to 7nm: Promises Upside for Cadence Physically-Aware Design Flow
by Mitch Heins on 01-29-2018 at 12:00 pm

Until recently, ICs at bleeding edge nodes like 7nm technology from foundries like TSMC were mostly targeted for high-performance-computing (HPC) and mobile applications or possibly high radix switches that needed the increased performance of advanced nodes. The momentum of Moore’s law and Moore-than-Moore saw foundries continuing to invest in more aggressive nodes, but it left many wondering what markets (and associated IC volumes) would justify the investments needed for 7nm and below.

In the meantime, the internet-of-things (IoT) emerged, and with it came the need for highly heterogeneous IC architectures with multiple different processor cores, embedded memories, networks-on-chip (NoCs) and a variety of different sensors, actuators, and interfaces including wireless transceivers. Conventional wisdom had been that these designs would separate the analog/mixed-signal portions (e.g. analog sensors, radios, transceivers, etc.) onto separate die from the digital processing elements and then combine everything into Systems-in-a-Package (SiPs).

However, we’re starting to see a shift. IoT designs, for example, can potentially drive huge volumes and as such SiPs may be too costly, forcing designers to move to the bleeding-edge nodes to once again do it all on one chip. Similarly, IP companies that may have been making their own discreet analog/mixed-signal chips are being asked to integrate their IP into customer’s systems-on-chip (SoCs) to lower overall costs, especially in markets like mobile and IoT. Moving to nodes like 7nm enables designers to consolidate everything onto one die while achieving superior performance, lower overall system power and reduced piece part pricing. Viola, build it and they will come. It looks like the IoT market may end up making 7nm a node that hangs around for a long time. It’s a big gamble though as designing at 7nm is not for the faint of heart.

I recently spoke with David Stratman, DSG Product Management & Business Development manager at Cadence Design Systems. David confirmed that they have seen a dramatic upturn in the number of medium- and large-sized companies moving their mobile and IoT designs from more mature nodes straight to 7nm for the reasons mentioned above, and in turn requiring any digital or mixed signal subsystem IP providers do the same. These companies are looking to Cadence’s expertise at 7nm to help them make the transition into a very different design environment. Fortuitously, Cadence has been planning for this since its introduction of the first of their next-generation digital platform products (Ex: Innovus, Tempus, Genus).

Innovus initially took on 16nm challenges such as FinFET design including the use of colorization for multi-patterning. At 10nm, colorization became a full requirement and the tools also had to deal with increased wire resistance making interconnect layer selection more challenging. At 7nm, it becomes even more complex with the use of via-pillars to get access to device pins. In fact, the entire flow had to be re-engineered to take physical aspects of 7nm design into consideration from the very beginning of the flow through to tapeout.

In the past, there was a clear line of demarcation between logic design and physical design. For decades designers used flows made up of tools from multiple electronic design automation (EDA) vendors, passing data between tools through both standard and non-standard interfaces. Cadence is betting that this is going to start changing with the latest technology nodes, and their tool flow reflects it. Their digital platform starts with a foundation of common core engines and full-flow optimizations. The flows make use of shared code that uses stage-specific abstractions of the data. Shared engines include placement, routing, delay calculation, extraction, timing and power analysis. The idea is to make the flow more predictive from the very start of the design by taking physicality into account as early in the design flow as possible.


This physical-first design flow changes the way design is done. Physical context is leveraged throughout the flow to the point that there is no explicit hand-off between logic and physical design. The idea is to continuously converge on design closure with smaller iteration loops enabled by shared compute engines. This full-flow optimization is difficult to do when using tools from multiple EDA vendors and Cadence is betting that the difference will be significant enough to convince customers to use their tools for the entire flow. To give added incentive, Cadence also upgraded their tool architecture to take advantage of massively parallel compute resources. Not only is the tool flow more integrated and predictive, but it’s also able to handle vastly larger design blocks when dealing with compute-intensive analysis algorithms such as extraction, timing and power analysis and physical verification.


David shared some recent results from a stealth startup company. The company began using Cadence Innovus on their first 16nm project alongside other industry tools and moved to the full Cadence digital flow at 7nm because of the flow’s shared physically-aware scalable engines.Not only did the company see big improvements in individual tool runtimes (example: Distributed STA on 400M gates flat ran in 6.5 hrs vs 50+ hrs), they also saw a 2X improvement physical design turnaround time with the Cadence Genus-Spatial + Innovus flow vs their traditional flow.

Back to the IoT angle on this, Cadence also made sure that their digital flow now interfaces seamlessly with their Virtuoso-based mixed-signal and custom flow. That means that IoT designers have a direct path to integrating everything (digital and mixed-signal) they need on their SoC at the advanced design nodes. If IoT customers continue in a trend to jump to 7nm both Cadence and TSMC stand to greatly benefit from Cadence’s physical-first design flow.

See Also:

TSMC @ N7 with Cadence (Cadence Breakfast Bytes Blog)
Cadence Digital Design and Signoff Platform


Global Semiconductor Market Trends ISS 2018

Global Semiconductor Market Trends ISS 2018
by Daniel Nenni on 01-29-2018 at 7:00 am

One of the other blog worthy analyst presentations at ISS 2018 was by Len Jelinek of IHS. Len is my kind of analyst, he spent 28 years in the semiconductor industry before going to the dark side so he knows what he is talking about. Len’s presentation on Global Semiconductor Market Trends is action packed so I will be doing a lot of cut and pasting here:

IHS forecasts that total semiconductor industry revenue will grow by 7.4% in 2018

  • Overall semiconductor revenue growth in 2017 is estimated to be 21.7%
  • In 2018 IHS is forecasting that Memory will grow by 14% and all other semiconductors will grow by 4.5%
  • Wireless communication is forecast to benefit from next generation handsets incorporating new features like biometrics, AI capability and increased batty life
  • Automotive electronics continues to grow by focusing on advanced safety features
  • Consumer electronics benefits from the move toward internet connected devices
  • Increased servers supporting cloud computing is major driver in Data Processing segment

I really think the semiconductor industry is being a bit conservative here. I would be quite shocked if we did not see double digit growth here. One example, China has more than 900 fabless semiconductor companies designing chips for new applications and I highly expect India and other populous countries to follow suit. This is like the second coming of the fabless transformation we talked about in our first book Fabless: The Transformation of the Semiconductor Industry.

Consumers Identify Increasing Value in Smartphones

  • Smartphones returned to growth in 2[SUP]nd[/SUP] half of 2017 driven by introductions of revolutionary features
  • Total smartphones in 2017 are forecast to grow by 7.4% with mid-tier handsets growing by 11.9%
  • Smartphone shipments are forecast to increase in 2018 to 1.6 billion units with YoY growth rate of 6.8%
  • Mid-tier smartphones are providing consumers with the most features / value for lowest price. In 2018 IHS anticipates these phones will grow by 12.4%

In my opinion the smartphone business still has plenty of room to grow. TSMC’s smartphone forecast for 2018 was even more conservative, which may be true, but my friends at Apple have other plans. Apple is all about the edge device and now that they have higher performance SoCs with embedded AI cores coming we will start to see some amazing things, absolutely. Think Health and Wellness applications.

Revitalization of Consumer Electronics is Underway

  • Opportunities exist for consumers to benefit from connected products (IoT) which enhance daily lives
  • China continues to represent the largest single market for consumer electronics with a CAGR of 6%
  • Wearable devices, home appliances and consumer drones are forecast to outperform the overall market segment
  • Home appliances are the largest sub segment within consumer electronics and represent one of the largest IoT

Again, I think Len is being conservative here. Another application to watch, especially in China, is crypto currency mining (GPUs and ASICs). TSMC mined the mining market quite well in 2017 and I expect that to continue well into 2018 and maybe even 2019.

Semiconductor Device Growth 2016/2017


Semiconductor Device Forecast 2017/2018

Summary
A strengthening global economy should provide a positive impact on semiconductor industry in 2018:

  • Consumers and business anticipate positive economic growth in 2018 which should provide stable demands for semiconductor components throughout 2018
  • IHS anticipates that semiconductor revenue in 2018 will grow by approximately 7.4%
  • Impact on the semiconductor industry revenue from volatility of memory pricing is forecast to be minimal
  • Non memory component revenue growth will slow in 2018 to 4.5%, down from 10.3% in 2017

Next generation demand drivers supporting IoT, 5G, and autonomous driving are still several years away from impacting semiconductor component manufacturing:

  • Next generation 5G wireless communication will start limited trials in 2018, commercialization targeted for 2020
  • Strong inventory management will impact manufacturing run rates throughout the first half of 2018
  • Q1 revenue is forecast to decline by 5.3% revenue recovery forecasted to start in Q2
  • Demand for handsets, PC’s, and consumer electronics is forecast to experiences seasonal post-holiday slowing

Capital investments will continue to grow in 2018 by 5.4% supporting new technology development and capacity expansions for memory and advanced CMOS

Absolutely!


What GM Can Learn from Tesla

What GM Can Learn from Tesla
by Roger C. Lanctot on 01-28-2018 at 7:00 am

General Motors has had wireless connections to its cars for more than 21 years, thanks to Project Beacon, better known as OnStar, now operated as Global Connected Consumer Experience. OnStar has likely saved hundreds of lives, if not thousands, by summoning emergency responders to the scenes of crashes where airbags deployed.

To this day, the rest of the automotive industry remains of two minds regarding OnStar’s “automatic crash notification” functionality. Some luxury car makers have replicated and implemented the feature. Ford Motor Company offers a smartphone-based equivalent dubbed 911 Assist. But the feature never became the checkoff item it was intended to be and U.S. government regulators never saw fit to require it – unlike Europe where a local equivalent called eCall will become standard equipment on new type-approved vehicles later this year.

Even Tesla Motors chose not to implement an OnStar-like function in its cars. Every Tesla Motors vehicle is built with an embedded telecommunications connection, but if you crash in a Tesla and you are unconscious you will have to depend on the kindness of strangers to alert emergency responders.

Arguably Tesla vehicles were not designed with the prospect of a crash in mind. Yet Teslas continue to experience crashes including one famous fatal one in Florida in 2016. The thinking at Tesla may be that it is best to avoid crashes altogether rather than focusing on what to do after one occurs.

Now, both Tesla and GM, caught up in the struggle to deliver an automated driving proposition, have experienced nearly simultaneous collisions potentially tied to automated driving systems. In GM’s case, a motorcyclist has filed a lawsuit after a low-speed mishap involving a Cruise Automation test vehicle. For Tesla, a Model S equipped with Autopilot (activated) collided with a firetruck parked on the side of the road.

– GM Faces Lawsuit after Crash between Motorcyclist and Self-Driving Chevy Bolt – theverge.com

– Tesla Crash with Autopilot Triggers Safety Board Interest – Bloomberg.com

Tesla and GM have faced similar safety challenges in the past. In Tesla’s case, the company used vehicle data for its own forensic purposes to determine 1) that the Florida crash was entirely the fault of the driver of the vehicle misusing the Autopilot feature and 2) that Tesla vehicles equipped with Autopilot create fewer insurance claims.

In GM’s case, the company is still wrestling with the aftermath of the ignition switch crisis which has led to multiple individual and class action lawsuits, a $900M fine from the U.S. Department of Transportation and multiple Capitol Hill hearings to respond to Congressional questions as to how the ignition switch vulnerability had been overlooked for as long as it had. The possibility of GM exonerating itself Tesla-style with telltale vehicle data was never on the docket.

But knowledgeable industry observers and even some incredulous Congressional representatives were asking themselves, if not GM, how the company could have failed to detect the ignition switch failing from the data collected from OnStar-equipped vehicles in the wild to say nothing of inferences that might have been drawn from diagnostic scans at dealerships. For GM, it was the internal e-mail trail that proved determinative.

Maybe in this latest incident in California GM will be able to finally steal that page from the Tesla playbook and show, from vehicle data, that the Chevy Bolt was blameless in the low-speed collision with the motorcyclist. It’s an essential turning point for GM and the global automotive industry.

GM’s Cruise Automation unit, which is running tests in California, is in a contest with Waymo for self-driving car leadership. While Waymo has put up gaudy (i.e. impressively low) disengagement event data, Waymo has been focused on operating in the suburbs. Cruise has been subjecting itself to the acid test of operation in an urban environment – San Francisco, to be specific – with all of the conflicting modes of transportation pedestrian and otherwise and some unique topography and street restrictions.

It’s no surprise that Cruise has been experiencing way-more (wink) collisions than Waymo ever did. But it’s no excuse and GM/Cruise need to clear up the source of responsibility for the crash and make any necessary corrections before the otherwise minor incident is whipped up by safety advocates into a full-blown emergency brake moment for automated driving.

Why is it so important that we stay the course on automated driving? Because! Because current estimates are that approximately 37,000 people were killed on U.S. highways in 2017, the second consecutive annual increase. This is more than 100 daily fatalities and ignores the even more terrifying figures for injuries, to say nothing of the economic impact.

Automated driving and all of the advances leading up to it hold the promise of actually putting a dent in those figures and mitigating the economic impact and personal tragedy simultaneously. The minor incidents characteristic of current real-world testing of automated driving technology pale in comparison to the massive carnage being inflicted daily by non-autonomous driving activities. Where is the outrage?

We do need to learn, though, from these experiences so let the investigations of both incidents begin. With some luck GM will learn from Tesla and use this event as an opportunity to educate regulators and the general public as to the extent of its responsibility and the nature of the crash. As for Tesla, if history is any guide, Tesla will forage through its data trove and deliver up an exculpatory assessment of events preceding and leading to the Model S crash with the firetruck. (Maybe Musk will work his Jedi magic and have us believing that the crash never happened in the first place!)

GM is attempting to school Tesla and Alphabet as to how to deliver a self-driving car to market by 2019. Before GM schools any competitor, though, it needs to learn a few lessons of its own as to how to put vehicle data to work. Tesla and Alphabet are leaders in this respect and GM has some catching up to do.

As for avoiding collisions with motorcycles, GM and other car makers (and smartphone makers) ought to take a closer look at Ridar Systems. Ridar offers an app capable of alerting drivers to the presence of a nearby motorcyclist. A Lyft driver tooling me around Las Vegas two weeks ago might have benefited from the use of such an application in the near-miss event we shared. There are solutions around for common every day driving challenges – if one just looks closely enough. As for GM and Tesla, the answers to autonomous driving are in the data.


Webinar: The Emergence of FPGA Prototyping for ASIC and SoC Design

Webinar: The Emergence of FPGA Prototyping for ASIC and SoC Design
by Daniel Nenni on 01-26-2018 at 12:00 pm

One of the more interesting markets that I cover is FPGA Prototyping. Interesting because it is fast growing ($150-250M) and interesting because it is all about design starts and design starts are the lifeblood of the semiconductor industry.

If you are interested in FPGA prototyping you might want to start with the 30+ S2C Inc blogs we have done over the last three years. You can also read our eBook Prototypical. Even better, you can sign up for the upcoming S2C webinar:

The Emergence of FPGA Prototyping for ASIC/SoC Design
FPGA prototyping has become a dominant part of the ASIC and SoC design and validation flow by significantly speeding up the progress of your project. This webinar will provide a brief overview of FPGA prototyping and address the key points on system selection. We will analyze how the flow changes on single or multiple FPGA systems and how prototyping software participates in the verification flow.

  • Thu, Feb 8, 2018 8:00 AM – 9:00 AM PST

Agenda:

  • S2C Prototyping Solutions Overview
  • How to Quickly Build and Target FPGA Prototyping
  • The Importance of Daughter Cards
  • Demonstration Image processor on VUS/VUD
  • Questions and Answers

Presenters:
Daniel Nenni Founder of SemiWiki.com
Richard Chang Vice President of Engineering, S2C Inc.

I’ve recently started doing business development work with S2C and have been impressed with not just the products and employees, but also the diverse markets they serve. China, for example, has more than 900 fabless chip and systems companies doing designs, most of which will be using FPGA prototyping for chip verification and software development. FPGA prototyping is a front row seat to the future of semiconductor devices with S2C and China leading the way, absolutely.

About S2C
Founded and headquartered in San Jose, California, S2C has been successfully delivering rapid SoC prototyping solutions since 2003. S2C provides:

With over 200 customers and more than 800 systems installed, S2C’s focus is on SoC/ASIC development to reduce the SoC design cycle. Our highly qualified engineering team and customer-centric sales force understand our users’ SoC development needs. S2C systems have been deployed by leaders in consumer electronics, communications, computing, image processing, data storage, research, defense, education, automotive, medical, design services, and silicon IP. S2C is headquartered in San Jose, CA with offices and distributors around the globe including the UK, Israel, China, Taiwan, Korea, and Japan. For more information, visit www.s2cinc.com.


IEDM 2017 – Controlling Threshold Voltage with Work Function Metals

IEDM 2017 – Controlling Threshold Voltage with Work Function Metals
by Scotten Jones on 01-26-2018 at 7:00 am

As I have said many times, IEDM is one of the premier conferences for semiconductor technology. On Sunday before the formal conference started I took the “Boosting Performance, Ensuring Reliability, Managing Variation in sub-5nm CMOS” short course. The second module in the course was “Multi-Vt Engineering and Gate Performance Control for Advanced FinFET Architecture” taught by Steven Hung of Applied Materials. This excellent module was particularly timely because GLOBALFOUNDRIES and Intel gave papers on their 7nm and 10nm processes at IEDM and both processes use work function metals to control threshold voltages. In this article I will discuss this emerging process technology.

Introduction
Simply put, the threshold voltage (Vt) of a MOSFET is the voltage that is required to turn the transistor on. As optimization of power and performance have become increasingly important for mobile devices, the number of different threshold voltages available on a process have proliferated. Where one or two threshold voltages were once typical, today we are seeing four or even five threshold voltages. Multiple threshold voltages allow designers to select the best option for each section of a design trading-off power and performance.

Setting Threshold Voltage (Vt)
The Vt of a MOSFET is determined by:

  • Interface charges – because interface charges can vary over time due to traps charging and discharging, it is generally desirable to minimize interface charges and they are not used to “tune” the threshold voltage.
  • Gate dielectric (oxide) thickness – Vt varies with gate oxide thickness with Vt being reduced for thinner oxides, see figure 1. For current foundry processes, it is common to have two oxide thicknesses and sometimes three. A thinner oxide may be used in the core for low Vt – high performance transistors and a thicker oxide may be used in the I/O area to support higher voltages.

 


Figure 1. Threshold voltage versus oxide thickness at a fixed channel doping level.
  • Channel doping – for many years the main method of producing multiple Vts on the same process has been to use masked implants to dope selected channel regions. Figure 2 illustrates Vt versus channel doping. There are two main issues with channel doping to set Vts. The first is that doping the channel reduces mobility and performance. Secondly, at very small dimensions there are only a few dopant atoms in the channels and small changes in the number of dopants referred to as random dopant fluctuations (RDF) can lead to variations in Vt.


Figure 2. Threshold voltage versus channel doping at a fixed oxide thickness.

 

  • Work function – since the transition to high-k gate oxides occurred, metal gate electrodes have been used to avoid the polysilicon depletion effect. The high-k metal gate (HKMG) process typically has two types of gate electrode metal stacks, one for the pFET and one for the nFET. The dual work function metals (WFM) is part of optimizing the nFET and pFET Vts. Now we are seeing more than two WFM used to “tune” Vt. With the advent of the foundry 7nm processes (Intel 10nm process) we are seeing multiple WFMs used to tune Vts with no channel doping. This approach improves mobility in the channel and therefore performance and avoids RDF.


High-k Metal Gates

In the early days of HKMG there were two approaches, gate-first and replacement metal gate (RMG). In gate first the HKMG is formed before the transistor implants, anneals and raised source/drains. The problem with this process is that the HKMG structure must stand up to a lot of high temperature processing and achieving optimal Vts is very difficult. RMG has now become the standard HKMG process.

In an early version of RMG, an interfacial oxide, high-k gate oxide and capping layer are deposited and then covered with a sacrificial polysilicon layer. The transistor implants, anneals and raised source/drains are performed. The sacrificial polysilicon is then etched out and gate WFM are deposited. This avoids the WFMs seeing a lot of high temperatures. In the current versions of this process an interfacial oxide is grown, sacrificial polysilicon is deposited and then the transistor is formed. The sacrificial polysilicon is etched-out, the surface is cleaned and then the interfacial oxide, high-k oxide, capping titanium nitride (TiN) layer and second sacrificial polysilicon layers are deposited. An anneal of the high-k oxide is preformed and the second sacrificial polysilicon layers is etched away. The WFM is now deposited. This method avoids having the high-k oxide exposed to all the high temperature transistor formation process steps.

Two Work Function Metals

For many years the standard WFM process has been to create an n and a p WFM.

The basic process is (does not include second sacrificial polysilicon deposition, anneal and removal), see also figure 3:

  • Form interfacial oxide
  • Deposit high-k gate oxide
  • Deposit TiN cap layer
  • Deposit tantalum nitride (TaN) etch stop layer
  • Deposit TN work function layer
  • Mask and etch TiN off of nFET
  • Deposit titanium aluminum carbon (TiAlC) work function layer
  • Deposit TiN barrier
  • Deposit tungsten (W) fill
  • Planarise

Figure 3. Dual work function metals.

It should be noted that although this stack is shown flat for illustrative purposes, the films are deposited into a trench.

Four Work Function Metals
At 10nm TSMC implemented the first four WFM approach I have seen. In the process outlined below the net result is two nFET WFM stacks and two pFET WFM stacks. This would achieve two Vts and I believe channel doping is used to achieve additional Vts. Possibly there would be one nFET and one pFET with undoped channels for maximum performance and then perhaps three additional Vts with doping.

The basic process is (does not include second sacrificial polysilicon deposition, anneal and removal), see also figure 4:

  • Form interfacial oxide
  • Deposit high-k gate oxide
  • Deposit TiN cap layer
  • Deposit tantalum nitride (TaN) etch stop layer
  • Deposit TN work function layer
  • Mask and etch TiN off of everything but the high Vt pFET
  • Deposit second TaN layer
  • Mask and etch TaN2 off of the low Vt nFET and high Vt pFET
  • Deposit TiAlC work function layer
  • Mask and etch TiAlC off of the low Vt pFET
  • Deposit TiN barrier
  • Deposit tungsten (W) fill
  • Planarise

Figure 4. Four work function metals.

This process flow was developed after examining cross sections of 10nm TSMC process provided by TechInsights.

If only two Vts are required, this 4 WFM process will meet that requirement. If channel doping is acceptable, then implants may be used to provide additional Vts.

For the Intel 10nm process (similar to foundry 7nm) Intel has a base process with 2 Vts achieved with 4 WFMs and an optional 3 Vt process achieved with 6 WFMs. GLOBALFOUNDRIES 7nm process has 4 Vts achieved with 8 WFMs. These processes are not available for analysis yet and we don’t know how these 6 and 8 WFM stacks are achieved. In the next section I will discuss some of the options.

Multiple Work Function Metal Options
Multiple work function can be achieved by simply using different metals that have different work functions, but there are a limited number of suitable metals.

In the “Multi-Vt Engineering and Gate Performance Control for Advanced FinFET Architecture: module of the short course I took, three ways of modifying work functions were discussed:
[LIST=1]

  • Thickness modification – changing the thickness of work function metals layers changes the work function. This allows changes in the Vt over a wide range but requires multiple depositions, masks and etches and very tight thickness control. This technique results in stacks of different thicknesses and may be difficult to implement for gate-all-around.
  • Material modification – this technique introduces or removes species such as oxygen to change Vt. This technique has less range of values than thickness modification and is most effective when the layers are closer to the high-k gate oxide. This technique does not result in different thickness for each WFM stack. One technique that has been investigated for material modification is implanting nitrogen into the WFM, the concern with this technique is the implanted ions may knock metal atoms from the WFM into the high-k gate oxide.
  • Electrostatic dipole – certain elements can introduce a dipole into the high-k gate oxide, for example elements such a lanthanum (La). Dipole formation with La and aluminum (Al) was used by the IBM/GLOBALFOUNDRIES/Samsung alliance as part of their WFM scheme for their gate first process at 28nm. This technique offers a broad range of Vts but needs very good thickness control of the deposited dipole materials and thermal drive in.Conclusion
    The transition to fully undoped channels with WFM Vt control is underway. TSMC has implemented 4 WFM at 10nm, Intel ‘s 10nm (similar to foundry 7nm) will feature 4 and 6 WFM options and GLOBALFOUDNRIES 7nm will have 8 WFM. We don’t yet know how this many WFMs will be achieved but likely it will be a combination of the techniques outline in the preceding section.The change to undoped channels should improve performance and reduce Vt variations enabling lower voltage operation for lower power.

Related Blog


Wanted by January 30th: Paper for DAC IP Track 2018!

Wanted by January 30th: Paper for DAC IP Track 2018!
by Eric Esteve on 01-25-2018 at 12:00 pm

DAC 2018 will take place in San Francisco in June (24 to 28) and you have a fantastic opportunity to present a paper in the IP track! In fact, the deadline has been extended to January 30[SUP]th[/SUP] to submit your proposal.

Let’s make it clear: you are not expected to send the completed paper by this date, just the following:

  • The title of the presentation
  • Abstract of 100 words
  • Category (a list is provided at the bottom)
  • Topic Area (a list will be provided)
  • Presenter(s) name, affiliation, city, state, country, and email address
  • Upload 6 slides max PowerPoint presentation (extra note is optional but preferred)

If you are not familiar with the DAC IP track, here is a summary extracted from the DAC web site:

The IP Trackis targeted specifically at practitioners. Whether you are an hardware designer, IP provider, IP core user, application engineer or verification IP user, the IP Track is an ideal place to meet and share your experiences.

This year, IP Track will include presentations, poster sessions and a rich set of invited talks/panels to facilitate information exchange and interactions. It offers a unique opportunity to network with and learn from other industry experts about best practices and current trends. There is no better way to improve your “IP IQ” in such a short amount of time.

DAC IP Track is looking for presentation and poster submissions with timely topics and high-quality contents targeting challenges, innovations and trends in IP architecture, design, integration, reuse, ecosystem, and verification IP. This includes the unique application requirements and challenges for advanced technologies, automotive, security, Machine Learning, and the Internet of Things.

Presenting a paper, especially in a highly visible conference like DAC, is a great opportunity and I tell you why. If you are part of a small to medium company involved in IP design or IP verification, one of the most challenging task is to get access to your customers. These may simply don’t know about your product or your company but would need the type of IP you are designing.

Obviously, you can invest into marcom, invest into booths, write white paper and more. But if you can also spend one day or less and write about the design or verification of your IP product and submit your proposal, this effort may be rewarded (assuming your paper is selected). You and your company will benefit from the high visibility of such a conference, and may reach people who could become new customers. Don’t forget that the paper will be listed on the DAC website, so even people who don’t physically attend to your presentation will become aware of you and your product!

But, please, don’t send pure marketing material, it would be rejected. The DAC IP track list a few conditions that your paper will have to fulfill:

· Accepted IP Track submissions (both posters and presentation slides) will be made available on the DAC website after the conference as a part of the DAC Archives.
· IP Track submission will be accepted as a 15 minute presentation or presented as a poster in a 90 minute group session.
· A good IP Track presentation addresses innovative solutions with high-quality results. The considerations used by the program committee in acceptance decisions include:oSignificance of results supported by clear, measurable criteria, including, but not limited to: improved quality of silicon, decreased complexity, and reduced time-to-market.

oAbility to overcome design challenges such as scalability and integrating IP.

oValidation of the proposed techniques using real designs, case studies, or established benchmarks.

oA good IP track presentation inspires vision and healthy discussion for advancing the design and IP community.

oQuality of material including writing, illustrations, and organization.

oProduct marketing material is inappropriate for the IP Track.

Best Paper Award, Best Poster Award
: your paper or poster can be selected to get the best paper (best poster) award. In this case, you will be notified before the conference that you are in the short-list. I can tell you from experience that it’s always a great emotion when you receive this notification! But only one paper and one poster will receive the award…

Are you ready to jumpstart and write an IP focused paper?

Go to this “IP Track Presentation Submissions

From Eric Esteve from IPnest

Category List:
·IP.01 IP Provider CPU / GPU / DSP
·IP.02 IP Provider Memory Controller / NOC
·IP.03 IP Provider Communications IP
·IP.04 IP Provider Analog / PHY / High speed interfaces
·IP.05 IP Provider Embedded Software
·IP.06 IP Provider Configurable IP / IP Compilers
·IP.07 IP sub-systems / Multi-discipline IP / Programmable logic IP
·IP.08 IP optimized for emerging markets and applications such as Automotive, IoT, Mobility, Networking, Cloud, Security, Resilience, Etc.
·IP.09 IP Management / Assembly / Strategy / Roadmap
·IP.10 IP Verification / Validation


Webinar: Fast-track SoC Verification – Reduce time-to-first-test with Synopsys VC AutoTestbench

Webinar: Fast-track SoC Verification – Reduce time-to-first-test with Synopsys VC AutoTestbench
by Bernard Murphy on 01-25-2018 at 7:00 am

There seems to be a general sense that we have the foundations for block/IP verification more or less under control, thanks to UVM standardizing infrastructure for directed and constrained-random testing, along with class libraries providing building blocks to simplify verification reuse, build sequence tests, verify register behavior and more. Not that this is trivial; UVM is still a complex animal requiring a lot of training and learning on the job. There continue to be debates about features and extensions: what should be standardized and what should be left to vendor solutions for example. Evolution naturally, but along a fairly clear path.


REGISTER HERE for the Webinar, on January 31[SUP]st[/SUP] at 10am Pacific

The same claim couldn’t be made for SoC and subsystem-level verification, at least until relatively recently. You’re still going to build testbenches using the UVM standard, but a bunch of what UVM offers for block-level verification is less useful at the system-level; for example, constrained-random is a hopeless approach to effective system-level testing. There are other important areas to optimize also, among which getting to a working testbench is the most obvious barrier to starting system-level verification.

At the SoC level, testbenches are much more than a stimulus/monitor/cover shell around a DUT: configuring the design, swapping IPs for VIPs with their transactors, assertions and covers for protocol verification (across the many protocols common in an SoC), along with adding hooks for validating against verification plans, adding performance testing, stress testing and coherency testing. When you consider also that many of these IP come from different sources, with different verification assets, assembling these testbenches is a complex and time-consuming task, often taking days to weeks to get to first effective verification.

But it doesn’t have to be that way. Synopsys’ VC AutoTestbench can assemble an SoC testbench in hours. This will import the DUT description, select and configure VIP, instantiate and connect these within the DUT and build out the test environment. They have this down to a pretty simple 5 step process. DUT and VIPs are read in and configured as IP-XACT, clock, reset and ad-hoc signals can be configured automatically and a testbench drops out. None of this requires protocol expertise or even UVM expertise. You’re up, simulating, and debugging in Verdi in hours rather than weeks. That sounds like a real-time saver.

REGISTER HERE for the Webinar, on January 31[SUP]st[/SUP] at 10am Pacific

Webinar Abstract
Today’s highly complex SoCs typically include multiple embedded processors, a memory subsystem, several interfaces to standard and custom protocols and a sophisticated interconnect architecture. These designs come together from IPs to subsystems to the full SoC, with system-level verification typically done late in the project cycle. Current verification environments don’t scale well from the IP- to SoC-level, are effort-intensive and time-consuming to build, and inherently error-prone. Due to time-to-market pressures, system-level verification to functionally verify the numerous system configurations is often insufficient and incomplete. Hence, there is a pressing need for automation in SoC verification, starting from testbench generation and bring-up.
In this Synopsys webinar, we will discuss how to reduce the time-to-first-test from weeks to hours by automating the process of testbench generation with Synopsys VC AutoTestbench. We will also include a demo of this flow using a real-world design and Synopsys AMBA VIP. Specifically, you will learn:

  • How to quickly and easily generate a complete SystemVerilog/UVM verification environment
  • How to efficiently reuse SoC-level testbenches for IP & interconnect verification
  • How to bring-up the auto-generated testbench and run tests from the Synopsys AMBA VIP test suites

Speakers:

Vaishnav Gorur
Product Marketing Manager – Verification Group
Synopsys

Vaishnav Gorur is currently Staff Product Marketing Manager for Debug & SoC Verification Automation products in the Verification Group at Synopsys. He has over 12 years of experience in the semiconductor and EDA industry, with roles spanning IC Design, field applications, technical sales and marketing. Prior to joining Synopsys, Vaishnav worked at Silicon Graphics, MIPS Technologies and Real Intent. He has a Masters degree in Computer Engineering from University of Wisconsin, Madison and an M.B.A. from University of California, Berkeley.


Satyapriya Archarya
Senior Manager – Applications Engineering – Verification Group
Synopsys

Satyapriya Acharya is a Senior AE Manager at Synopsys, where he manages the use of Synopsys Verification IP for ARM AMBA protocols with several key customers. He has been involved in the development, verification and deployment of Synopsys Verification IP for the AMBA 3, AMBA 4 and AMBA 5 specifications. He has over 15 years on experience in design and verification.


Designing an SoC for 3D TV Without using the Funny Glasses

Designing an SoC for 3D TV Without using the Funny Glasses
by Daniel Payne on 01-24-2018 at 12:00 pm

In the blur of activities at DAC last year I visited the Mentor booth a few times and had just a few minutes to glance at a 3D TV display that didn’t require me to wear any funny glasses, kind of novel I thought at the time because I’ve read that the market of 3D TV sets is being hampered by requiring viewers to wear glasses. The design team responsible for implementing an SoC for 3D TV without the use of glasses is called StreamTV Network, and they just described their journey in a white paper. So, what kind of 3D are we talking about here?

Well, these graphical gurus at StreamTV have figured out how to take the existing 2D video content and then add their Ultra-D technology layer on top of that, all in real time using their secret sauce (i.e. proprietary real-time algorithms). The team decided to go ahead and create a proof of concept SoC, even before they knew critical requirements like:

  • Silicon process node
  • Interfaces
  • Protocols
  • Memory
  • Bandwidth

The engineers decided to take a High Level Synthesis (HLS) approach to create their proof of concept, and they used the Catapult HLS tool in the process. Inside of their SoC is a Real-Time Conversion (RTC) IP block that has a 2D depth estimation function that creates a depth map. Then the image and depth map get sent to the Ultra-D block to create a stereo depth map.

In the above diagram you can see two BW images, the depth maps where a whiter color means that the image is closer to the viewer and black means the image is farther away.

A conventional SoC design flow would have an algorithm design team coding in C++, then a digital design time manually coding in RTL with an error-prone and time consuming process of going from C++ into RTL code:

The StreamTV team heard about the HLS approach from an NVIDIA engineer and started talking with Mentor about the possibility of using Catapult, so they started out with a portion of C++ code as a sample. AEs from Mentor spent some time onsite to help push the C++ code through the Catapult tool and the StreamTV engineers could quickly simulate the RTL code from Catapult to verify that it was working OK. So the new flow was more automated than the conventional SoC design flow:

Some of the benefits in using an HLS flow include:

  • C++ is the golden source for the algorithm and digital design engineers
  • Only one language to be concerned with
  • Direct how hardware gets synthesized with HLS directives

For an FPGA prototype using Altera parts the RTL code will run at 150 MHz, while choosing a TSMC process node the RTL code is much faster at 450 MHz.

During the design process there is block-wise verification run where the algorithm engineers wrote C++ functions that are then re-used as a testbench for the RTL generated code, so no manual steps were involved to verify. With the C++ being the golden source then all team members have a single language: Software, SW test, Verification testbench, Hardware. Having a unified source helped get the product out quicker than older design flows with multiple abstraction layers and manual steps.

Did the SteamTV team learn their new HLS flow by simply reading the fine manuals? Not really, they instead relied on local AE support to get up to speed with Catapult by learning best practices and avoiding pitfalls along the way. These first-time HLS users reported that they reduced SoC development time by at least 50% compared to previous designs, and that a big plus was being able to make last-minute changes because the time to generate RTL code was so fast.

The team even kept track of how much manual RTL they had to write versus HLS-generated, then how that impacted their debugging time:

What surprised me was to see that with only 5% of their design using manual RTL coding that the debug time for that code was disproportionately large at 80% of all debug time. Learning to place HLS directives created 3X more bugs at 15% of the total debug time compared to just learning how to code HLS at 5% of the debug time.

Once the StreamTV engineers learned the new HLS flow and did their first project they are not returning to their former flow again. The Catapult technology proved itself quite capable for these video challenges in 3D TV.

To read the complete 10 page White Paper click here.

Related blogs:


Context is Everything – especially for autonomous vehicle IP

Context is Everything – especially for autonomous vehicle IP
by Tom Simon on 01-24-2018 at 7:00 am

GM has just announced that it will introduce a car with no steering wheel or pedals in 2019. According to their statement, they have already planned four phases of their autonomous driving system, and they will plan many more. However, before we jump into this latest car and not grab the wheel for a spin, it is reasonable to ask about the reliability of the driverless electronics.

However, to put the safety of automotive automation in perspective we should look at the safety of how cars operate today. The largest single cause of automobile accidents is distracted driving. A related statistic is that one third of all accidents involve straying from the driving lane. Autonomous driving systems will be hands down better at sustained vigilance than humans. Indeed, this is the impetus for self-driving cars – we won’t have to try to focus on driving during our trips, and can be as distracted as we wish. I for one look forward to this.

The lingering question is how well will these systems operate. Advances in AI have helped improve the software element of these systems. As software quality improves, it reveals system hardware as the next area of focus. As I have written before, there are standards to help ensure reliability. The two main standards of interest are ISO26262 and AEC-Q100. Anyone building a system or a chip intended for automotive use needs to be thoroughly acquainted with both of these standards.

Safety in these systems relies on the biggest and the smallest components. Each need to be designed and assessed with the ultimate application in mind. One of the most poignant examples of how a very small but important component can lead to system failure is the Challenger explosion in 1986. In that case O-rings on the solid rocket booster were operated outside of their designed operation specifications, leading to catastrophic failure of the spacecraft and a loss of life.

Silicon Creations, a leading supplier of high performance analog IP, recently presented at the Reuse 2017 conference in Santa Clara on the topic of developing IP suitable for use in safety critical systems in automobiles. Andrew Cole, Silicon Creations’ VP, presented the session.

Andrew started off with a review of Silicon Creations, highlighting their strong growth since their founding in 2006. They have development groups in Krakow and Atlanta and their products span 180nm down to proven silicon at 7nm.

Because IP such as PLL’s and SerDes are ultimately used as part of larger designs, they cannot be certified by themselves. Andrew spoke about two fundamental concepts in automotive safety, Safety Element out of Context (SEooC) and Fault Time Tolerance Interval (FTTI). SEooC basically says that you must understand the use case for a sub-unit such as a PLL before you can properly assess its safety performance. To harken back to the Space Shuttle failure, we can see a similarity with the O-rings performance. They worked adequately for launches above 54 degrees, but at freezing temperatures they failed. The operating environment is an essential consideration when evaluating safety.

Once we are given a specific use case it is then possible to talk about failures and the allowable time to detect and correct them. Once again, without a use case we cannot really have a meaningful discussion of system level reliability. FTTI is concerned with system level design to detect failures and given the severity and criticality of the failure, how long the system can tolerate the malfunction, until it can be corrected. A failure in the entertainment system is nothing like a processor failure in the autonomous driving system. The former can wait for a visit to the dealer, the latter must be corrected or dealt with in fractions of a second.

The presentation, which can be downloaded from the Silicon Creations website, also discusses several design approaches and considerations for assuring system level certification of systems that use IP blocks such as their PLL’s and SerDes. Another topic he grapples with in the presentation is AEC-Q100 grading and testing. AEC-Q100 can be a sore point for products with small production volumes because it requires destructive testing of costly quantities of fabricated parts. Additionally, some care must be used when defining the mission profile for a chip, and its consequently incorporated IP.

The hope is that autonomous vehicles with lead to fewer accidents and improved safety. This cannot come about unless the entire supply chain is ready to step up and participate in a meaningful effort to meet and exceed safety standards. Silicon Creations is clearly making the effort and reaping favorable results. The slides used in Andrew’s talk can be found on their website. I highly recommend looking them over.