SemiWiki – Page 349 – The Open Forum for Semiconductor Professionals

May 5, 2020July 6, 2020

DFT Innovations Come from Customer Partnerships

There is an adage that says that quality is not something that can be slapped on at the end of the design or manufacturing process. Ensuring quality requires careful thought throughout development and production. Arguably this adage is more applicable to the topic of Design for Test (DFT) than almost any other area of IC development and verification. DFT is quite literally built into the design and involves every part of the chip. In addition to helping validate completed chips to ensure they meet their functional requirements, DFT is also used to feed yield and reliability statistics back into the design process to help prevent quality issues.

Detecting and preventing defects in ICs is a major area of research and technology development. Over the last 15 years DFT has been the topic of numerous academic papers and articles that rely on investigations and data derived from real world designs produced by leading semiconductor companies. To help enable these investigations and use their results to leverage DFT tool and flow development Mentor, a Siemens business, has worked with many of these companies on improved methods for DFT.

Mentor uses a partnership model for developing new and advanced features in their DFT tools. In a recent publication titled “How to Maximize Your Competitiveness in the Semiconductor Industry Using Advanced DFT” Mentor talks about how important these partnerships are and highlights some of the advances they have made possible.

One such example is how the traditional fault models dating back many years have been expanded with the cell-aware fault model that proves useful for understanding defects that can occur within cells. The Mentor publication references a jointly authored paper with AMD and ON Semiconductor that shows in detail how the cell-aware test approach can reduce defect rates.

The Mentor publication also discusses the origins of their Tessent TestKompress. Back in 2001-2002 as 130nm designs were being developed using copper interconnect it became necessary to run at-speed tests with new fault models. Mentor devised TestKompress to allow the new patterns to fit in limited tester memories. TestKompress has continued to evolve since then to help accommodate larger design sizes at smaller nodes and new test types that require more patterns. The paper cites their work with Broadcom in 2015 that resulted in an IEEE paper for DAC.

Mentor also talks about their work partnering with foundries, such as GLOBALFOUNDRIES, to improve physical failure analysis (PFA). Looking at large numbers of wafers and dies, scan diagnosis can help pinpoint defect locations and lead to understanding the failure/defect mechanisms. Scan diagnosis is used for both yield ramp and yield improvement. Mentor has also worked with fabless semiconductor companies, foundries and integrated device manufacturers to develop root-cause deconvolution (RCD) which uses AI algorithms to estimate the defect Pareto from volume diagnosis results in the presence of noise.

Another significant advancement that has been presented in an IEEE paper is Mentor’s hierarchical DFT. Performing DFT on smaller blocks individually and then wrapping them so each instance can be tested in-situ makes the processes much more manageable. Mentor mentions how both Amazon and Samsung benefited from hierarchical DFT because of improvements in runtime, pattern count and compute resources. Hierarchical DFT is so compelling that it has become the standard practice.

The Mentor paper does a good job of discussing their unified Tessent Connect DFT environment for managing the entire DFT process. One of the innovations here is how it helps move parts of the DFT process into the RTL stage. They also touch on how they have helped their customers meet functional safety requirements, such as ISO 26262 for the automotive market. Built-in self-test (BIST) required new features to operate in these systems. Mentor worked with ARM to put together a safety ecosystem that works for these applications.

The Mentor paper includes references to many of the partnerships that have driven and proven their DFT offerings. It also makes clear that without this level of cooperation and collaboration it would not be possible to develop such a rich and full featured solution for DFT. The full paper and its citations make interesting reading for those looking for a deep dive into their state of the art test solutions.

May 5, 2020April 20, 2022

Accellera Tackles Functional Safety, Mixed-Signal

Accellera Tackles Functional Safety, Mixed-Signal
by Bernard Murphy on 05-05-2020 at 6:00 am
Categories: Accellera, Automotive, Events, Semiconductor Services

I managed a few meetings at DVCon this year in spite of the Coronavirus problems. One of these was with Lu Dai Chairman of Accellera. I generally meet with Lu each year to get an update on where they are headed, and he had some interesting new topics to share.

Membership and headcount remain pretty stable. Any changes (at the associate level) are more in composition as some join for new areas, some drop out as their topic of interest wraps up. Since DVCon is Accellera’s show, Lu walked me through conference status by region. DVCon US happened, but was noticeably cut back since both Cadence and Synopsys dropped out. DVCon China was cancelled (surprise, surprise) and we’ll have to wait to see what will happen to the DVCon Europe show (Oct 27-28). These are strange times.

WEBINAR: Portable Stimulus: Moving UVM Verification Up To The Next Level

On a brighter note they have two new functional working groups, on functional safety and UVM AMS. Functional safety started as a proposed working group late last year and became a full working group in February. UVM AMS also moved pretty quickly from proposed working group to full working group. Lu said that the detail in the proposals and contribution from participants convinced them pretty quickly that both these topics were ready to be developed more fully.

Functional Safety
Functional safety work within Accellera is attracting a lot of support, sometimes from companies that haven’t been involved with Accellera before. Lu didn’t want to tell me who, but I did notice that Bosch is listed as an associate member. I’m told there are now 19 companies participating in the working group. I’m not surprised there is momentum behind standards here. ISO 26262 is famously good at defining what in general you must demonstrate, without getting into details of how you do that. Good for them but that leaves a lot of freedom, some of it unnecessary, in how builders comply. Adding more guidelines can only be a good thing.

Lu told me a big focus area is traceability of requirements between stages – architecture to implementation. He said he has personal experience of this need on one of his own projects. When they aim to certify functional safety, they’re asked to provide traceability. Right now they have no tool to automate that task, to trace between assets in the specs, their architecture, design and development flows.

Without automation and structure this is a lot of overhead and still comes down to trust. That’s OK when you’re dealing with someone you’ve worked with for many years, but not when you want to expand to new customers. Take testing as an example. You might start with a high-level spec in PDF. Then you write your test plan in a vendor tool flow, or maybe in Excel or some in-house format, then you implement the test plan, perhaps in Verilog. When you run the test, some of it runs in C on a processor for which you can’t get coverage, but you can get a logfile dump. Then you have to demonstrate fault coverage, say in an FMEDA. How do you convince your customer that their higher-level safety specs map down cleanly into what you have done? Even if you can, you’ve proven compliance for your tool flow but what happens if your customer wants to integrate components tested with other sets of tools? This is an area ripe for standardization and for automation.

UVM-AMS
On AMS, Lu told me he has an analog designer friend who expresses frustration that Accellera develops lots of “toys” for the digital folks but nothing for people like him. Apparently he’s not the only one concerned. According to Lu, pent-up demand culminated at DVCon Europe last year (there are a lot of analog designers in Europe). He said the analog voice is still a minority but it has become very consistent (and perhaps insistent).

Accellera held an open session in which some groups shared proposals and others expressed interest in participating in working groups. It became quite was pretty clear there were concrete things that could be done. One point they were all clear on is that the methodology they propose should be language-independent, working for both SystemC and SystemVerilog. The next milestone is a whitepaper, intended to be released in October, though the virus and travel constraints might have something to say about that date.

Lu also briefly mentioned progress on PSS 1.1, not enough for me to comment since I missed the tutorial unfortunately. Generally, I’m happy to see they are working on some important areas!

WEBINAR: Portable Stimulus: Moving UVM Verification Up To The Next Level

Also Read:

Functional Safety Comes to EDA and IP

Accellera IP Security Standard: A Start

Semiconductor IP Security Issues

May 4, 2020July 6, 2020

Webinar: Build Your Next HBM2/2E Chip with SiFive

Webinar: Build Your Next HBM2/2E Chip with SiFive
by Mike Gianfagna on 05-04-2020 at 10:00 am
Categories: Events, IP, RISC-V, SiFive

I have been watching the trend for quite some time now that many advanced FinFET designs today are actually 2.5D systems in package. All of these 2.5D silicon interposer-based designs have high-bandwidth memory (HBM) stacks on board. Often there are multiple memory stacks in both 4-high and 8-high configurations. If you follow what’s been called the “more than Moore” revolution associated with 2.5 and 3D design, you know that HBM memory stacks essentially paved the way for this revolution. The HBM memory specification is alive and well with new, high performance versions available today and more in the pipeline.

That’s why an upcoming webinar from SiFive caught my eye. Entitled SiFive HBM2/2E IP Subsystem: Features and Integration Guidelines, this webinar will take you through everything you need to know about the latest HBM standards and how to add HBM memory to your next chip. If you’re even considering the benefits of HBM memory stacks, you need to attend this webinar. The event will be hosted on Thursday, May 14, 2020 from 9AM-10AM and 6PM-7PM, Pacific Daylight Time. One of those time slots should work for you and you can register for the SiFive webinar here.

If you’re still on the fence about attending, here is some information that should help. The event will cover three aspects of HBM-based designs:

Ketan Mehta, Director, SoC IP Product Marketing at SiFive will cover markets, applications and roadmaps
Pranav Kale, Staff Engineer, SoC IP Engineering at SiFive will cover the features of the new HBM2/2E standards
Ritam Das Adhikari, Manager, SoC IP Applications at SiFive will cover implementation guidelines for these technologies

I will have the honor of moderating the event. I’ve reviewed the presentation material with the SiFive team and I can tell you it’s quite complete. You should have an honorary degree in HBM design after attending. Let’s look at a few details to whet your appetite.

First of all, what is HBM and why do you need it? HBM memory stacks are actually very dense memory subsystems implemented with 3D packaging technology. The latest version of the specification is HBM2E. SiFive prepared a useful table below that summarizes what the latest HBM2E spec can deliver when compared with more traditional memory technologies. I would pay particular attention to the density, power efficiency and bandwidth rows.

If your application needs ultra-dense, high-performance memory, HBM is really the only practical path forward. SiFive offers an HBM2/HBM2E IP subsystem that provides the critical elements of an Integrated HBM controller and HBM PHY that support both the HBM2 and HBM2E standards in multiple fab technologies. Below is a table summarizing the substantial technology and support offered by SiFive and their HBM2/2E subsystem. Note that CoWoS stands for chip-on-wafer-on-substrate, a 2.5D technology offered by TSMC.

The webinar goes on to cover popular applications for HBM technology, including high-performance computing, AI training/inference and networking. SiFive’s experience in these areas, as well as their technology roadmap are presented. You will also get a detailed overview of the extensive features and options supported by the SiFive HBM2/2E IP subsystem.

The webinar concludes with an overview of implementation guidelines for your next HBM design. The following items are all addressed:

Key implementation guidelines
HBM2/2E bump map
HBM2/2E PHY orientation in ASIC
Loopback support for testability
DFT methodology debug tools
Collateral available
Support infrastructure

In short, everything you need to embark on an advanced 2.5D HBM-based design. There will also be a Q&A session with the presenters moderated by yours truly. As I’ve said, if you’re even thinking about HBM for your next design, you need to attend this webinar. You can register here. I hope to see you there.

May 4, 2020October 3, 2020

Talking Sense With Moortec…Are You Listening?!

Talking Sense With Moortec…Are You Listening?!
by Tim Penhale-Jones on 05-04-2020 at 10:00 am
Categories: FinFET, IP, Moortec

It almost doesn’t matter what your job may be, whether in the public sector or a private company, or how technical or how dangerous, many of life’s adages and sayings can be interpreted to have some direct meaning for all of us.

Over the years in our personal lives, we have been constantly advised that prevention is better than cure…certainly a flu jab in the fall seems a good idea to avoid flu in the winter and we all have jabs in childhood to prevent the more common diseases that plagued previous generations. The trouble with these sayings is a certain class of individual, commonly called a smart ass will pipe up ‘I told you so!’ if you don’t follow the advice.

In Star Wars, a common expression amongst all those who do not have the power of The Force is ‘I’ve got a bad feeling about this’…we mortals call it a ‘gut feeling’ or intestinal fortitude. It’s a wonderful thing and yet it is not really a sound basis for large SoC device development. With finFET mask sets costing seven or eight digits, trusting to guts is not to be advised. Apart from functional and system challenges, your silicon might be doing all sorts of things you might not be aware of, some inadvertently of your making (hot spots and voltage droops through not distributing data payloads sufficiently) and many through process variance and second and third order effects. For those who can’t all rely on ‘The Force’, Moortec provide technology that can give you that in-field visibility.

You don’t have to be a smart ass to be wise after the event, you don’t even need to be a Jedi…you can select off the shelf IP to be your eyes and ears for when you get your expensive silicon back from the fab.

Your device is talking to you, are you listening?

In case you missed any of Moortec’s previous “Talking Sense” blogs, you can catch up HERE

*Note to Reader: This blog was written before the terrible outbreak of Covid-19. Each and every countries governments strategies and actions will be analysed once we have reached the new norm, in the meantime our brave doctors and nurses on the frontline are working all hours to keep us safe, and for this we will be eternally grateful.

May 4, 2020August 27, 2020

Linux for Medical Devices Q&A

Linux for Medical Devices Q&A
by Daniel Nenni on 05-04-2020 at 6:00 am
Categories: EDA, Siemens EDA

As I have mentioned before SemiWiki gets to meet some very smart people and here is another one. Scot Morrison has an MS degree in Aerospace Engineering from MIT specializing in control systems. Today he is the general manager of the Embedded Platform Solutions Division at Mentor, a Siemens business. Scot oversees the Linux®, Nucleus®, and Mentor Embedded Hypervisor runtime product lines, as well as associated tools, middleware, and professional services.

Prior to joining Mentor in 2012, Scot served as GM and SVP of products at Wind River Systems, Inc. Before that he worked at Integrated Systems Inc., where he last served as the VP and GM of the design automation solutions business unit in 1999, responsible for MATRIXx, and the pOSEK embedded operating system.

In speaking with Scot, the top three points of interest/intrigue with Linux for medical devices is Safety, Security, and Size (of code) so keep that in mind as you continue reading:

Q: Can I use Linux in a medical device?
The answer to this question is, it depends. Linux has been deployed safely in a wide variety of medical devices, but in order to use Linux in a medical device that has a safety requirement you need to follow the process defined by the certification standard that you must comply with.

Q: We all know that safety and security are both necessary when we’re looking at medical devices. We hear that you can’t have safety without security, but why is that?
Security is something that can be looked at standalone; and even in medical devices, not all aspects of security are tied to safety. For example, when we talk about protecting people’s personal information, this is an aspect of security that does not overlap with safety. But, when we talk about safety, we talk about things that if they go wrong will impact the patient’s health. If the device is not secure, it makes it possible for bad actors to make these negative impacts happen either accidentally, or purposefully (which is much rarer).

Q. Does the use of Linux and other open source software help protect these devices?
Linux is the most heavily used operating system for devices in the world. It has a large, worldwide developer base that focuses on ensuring that it works as expected in all conditions, and is as secure as possible. That said, it is also the most studied operating system in the world, both by the vast majority of developers who are conscientiously working on improving Linux and other open source packages, and also by a small number of actors who are looking at ways to break into Linux for their own purposes. The security of applications using open source is a constant tug of war between these opposing forces. And as above, without security, you can’t have safety.

Q. How is it possible that Linux can have so many security flaws that we’re always finding more?
Linux (and other major open source packages like OpenSSL or SQLite) are large packages that have sometimes unpredictable interactions with other software that might be running in the system. This is combined with the fact that many flaws are hard to find in code reviews, normal testing, or by static analysis, and are undetectable unless software is combined with task switching and inter-process communication. Best practices will not identify every possible flaw or exploit, and much of the open source software that we rely upon was not originally developed with today’s best practices in place.

That said, the most important pieces of open source software used in devices world-wide are in a much more stable and secure place than they were 5 years ago, mainly due to the hard work and diligence of engineers all over the world in identifying avenues of exploitation, fixing those when they find them, and then the worldwide community looking for similar issues in their own projects. The work will never be complete, but it is becoming harder and harder to find exploitable flaws in this important infrastructure software.

Q. What happens when a security issue is found in Linux?
For the most part, security issues in Linux (and other important software like OpenSSL) are found by engineers either by happenstance (a bug that they uncover as part of their work), or through concerted efforts to find exploits (“white hat” hacking). Very occasionally, an exploit will be found as a result of a post-mortem analysis of an attack, but that is very uncommon. In either event, the discoverer of an exploit will notify the community of the offending open-source component, and in most cases, the discoverer or somebody in the community will notify the Common Vulnerability and Exposures (CVE) group, which is run by MITRE, and is closely related to US National Vulnerability Database (NVD), run by the National Institute of Standards and Technology (NIST).

Once a vulnerability is understood, and usually after a fix is available, the CVE is publicized by inclusion in these lists and if sufficiently serious, discussed by the security community worldwide. This is the point where devices are potentially most vulnerable; since most vulnerabilities are found by the “good guys”, the bad guys find out about them at the same time as the rest of the world, and can deploy exploitation that take advantage of the newly found vulnerability. That said, this publicity is very important, since it alerts the worldwide community of both the issue and the fix, so that an organization can determine if a particular exploit might affect their devices, and if it is, they can mitigate the issue before it may be attacked.

Of course, not everybody will be able to update their devices, which will leave them open to attacks, but since there are no real secrets in the world, this openness prevents more issues than it causes.

Q: Let’s bring it back to safety. Is Linux safe?
An operating system like Linux does not directly do anything to make a device safer. The Operating system doesn’t prevent a failure from occurring, nor does it make the system recover when a failure occurs; so in the terminology of safety an operating system is not a safety mechanism. This makes sense when you think about it. When you put Linux on a system with no other application and turn it on, Linux boots, but it just sits there at a login prompt; it’s not doing anything until applications run that leverage Linux, and it’s those applications that contribute to the overall safety of the device. When you think in those terms, while an operating system is not a safety mechanism, it does enable them; going back to the terminology of safety, the operating system is considered to be a safety element; something necessary but not sufficient to create a safety mechanism. So, the real question is “Can Linux be used as a safety mechanism?” The answer to that question is “Yes, but it’s complicated”.

Q. Why is it complicated?
To answer that, we need to look back 5 years or so. At that point, if Linux was used in a medical device, the architecture was designed to separate Linux from the safety critical part of the system to the greatest extent possible because it wasn’t trusted. The system would probably run Linux on a separate processor, and Linux would be responsible for activities that it was well suited for, like connectivity to the office or hospital network, running a display, taking user input, etc. Then, if information came in that would affect the safety function of the device (say, a dosage in an infusion pump), the new setting would be validated on another processor or in hardware before the change was administered to the patient. In many cases, these kinds of inputs that impact safety might not even come from Linux, but maybe from a dial or other hardware input. If an issue arose in Linux it would not impact the rest of the device, which would continue to execute safely.

Today, microprocessors are much more powerful and complex, with many cores, which are designed to support what we call heterogeneous multiprocessing; where there will be powerful general-purpose cores to support running an operating system like Linux, and then more specialized cores to handle other functions. Your cell phone probably has such a processor (or capabilities that provide for separation); the powerful processor is running Android or iOS and your apps, while something separate is managing your secure data. Safe devices today are taking advantage of this trend; the microprocessors are much cheaper than the multiple ones you might use in the past, and much more powerful. But, it means that there are more considerations to think about when you use them.

Q. How does a multiprocessor system affect safety?
Designing for safety is no longer just a hardware or software issue, it’s an integrated systems issue. To take full advantage of the lower board BOM costs and higher integration of components in an advanced multiprocessor chip for a safety sensitive design, applications must be kept separated – what’s known as mixed-safety criticality.

For example, you can now run the user interface portion of your system on a processor cluster that’s optimized for user applications with features like multi-level cache, and power islands for shutting off individual processors and memory, thus conserving power, say in a battery-operated medical device. Linux can also make optimal use of the application processor cluster with built-in features like Symmetric Multi-Processing, parsing tasks and threads to individual processors. Simultaneously, the safety critical portion of the system runs on a separate cluster that is dedicated to real-time processing with features like tightly-coupled data and instruction memory with extremely low fetch cycles, and highly deterministic performance; or lockstep mode to for error detection.

Advanced multiprocessing systems contain hardware-enforced isolation that keeps the application world and the safety-critical world separated, but the software designer will need to use middleware such as the Mentor Hypervisor or Mentor Multicore Framework to take advantage of those hardware features. These software packages make important system-level functions like secure Inter-processor Communication (IPC) between the processor clusters possible.

Q. Are there other hardware considerations Linux can take advantage of?
Definitely. One example is an advanced option in the Linux kernel known as the Power Framework. The software application can utilize the kernel to power down portions of the system when they’re not needed, and power them up when required, conserving system power. Advanced SoCs include peripheral interfaces in the processor clusters like I2C or USB that can be controlled in this manner, but that advantage can also be extended to implementing “soft” peripherals external to the processing cluster in RTL logic, for example a CAN interface; and even peripherals outside the chip, like an Ethernet PHY.

Taking full advantage of modern embedded systems means designing hardware with awareness of what the software is capable of; while at the same time, writing accompanying software drivers, firmware, and applications that can utilize all the features of the hardware.

Q. And I can get this advanced middleware and drivers from the silicon vendors?
The silicon vendors are primarily focused on what they do best, providing the best chips available to the market. All embedded silicon vendors provide some level of software support, but typically this is limited to bare-metal drivers, open-source builds of Linux, and some limited middleware. For advanced features like enabling mixed-safety criticality medical systems, the best option for the designer is to utilize a software vendor like Mentor that specializes in enabling multi-core applications. Thus your designers can focus on your own IP, and not having to code and debug the middleware.

Q. So, can Linux be pre-certified for use in a device?
Not really. Certain real-time operating systems (RTOSs) such as the Nucleus RTOS from Mentor, can be acquired pre-certified, as can other embedded software components from a number of vendors. To achieve this kind of pre-certification the vendor must be able to show that the complete software development process (requirements, design, development, testing and verification and all of the steps of development) have been performed to medical industry standards such as ISO 13485 and/or IEC 62304. Linux and other open source components are not developed to these standards, and thus cannot be pre-certified. As a note, there have been efforts to show conformance of Linux to the over-arching concepts of functional safety (usually mapping to IEC 61508, from which many industry standards are derived, including IEC 62304). While these have not been successful so far, the current effort (project ELISA) is showing promise in this area both in improving the processes used in open-source software development, and in mapping the higher-quality output to these standards. However, this promise is likely years away from being completely realized.

Instead of pre-certification, in medical devices, Linux is generally handled using a concept from IEC 62304 called Software of Unknown Providence, or SOUP. Under these guidelines the use of Linux is considered as part of the risk assessment of the overall device, and potential failures of Linux as used in the device must be considered, and mitigated if they might cause harm to a patient.

This risk assessment must meet the requirements of the FDA’s pre and post submission guidance, so on the front end it requires considerations on the use of Linux in the design, implementation, testing and verification of the device, and then after release, the use of Linux (and all open-source software) must consider the possibility that issues will be found after release. Certifiers are taking a very close look at this aspect of open-source, especially as far as security issues (i.e. CVEs) are concerned.

Q. How does using a commercial Linux provider help?
If you use open-source in your device, you are responsible for acquiring it, and maintaining it in your device both during development and after release. Acquiring Linux (and other open-source modules that you are likely to use) is easy; it often is available from your board or microprocessor vendor targeted to your development board. However, this Linux is usually made available on an as-is basis and is meant to get a system up and running; your board vendor will not be performing maintenance or timely updates of that Linux for you to use after release. As a result, this responsibility falls onto the device developer to manage, for the life-time of the device. This is not impossible, but by doing it yourself you are committing engineering resources to monitor and maintain the significant number of CVEs that are reported against open source components every day… As an example, in 2019 there were 170 CVEs issued just against the Linux kernel and 12,174 CVEs created in total. It is a significant effort to review each of these, determine which are important, round up the fixes, and verify that the operating system is still operating as you would expect. A commercial Linux provider does this work as part of their core competency, and while they will charge you for this kind of service, it will cost you less in the long run and you’ll end up with a higher-quality product with fewer integration issues as you maintain the product over its lifetime.

For additional information please check the Mentor Embedded Software and Medical Devices landing pages.

May 3, 2020July 6, 2020

Is Chip Embargo aimed at China, Huawei, TSMC or all three?

Is Chip Embargo aimed at China, Huawei, TSMC or all three?
by Robert Maire on 05-03-2020 at 10:00 am
Categories: Semiconductor Advisors, Semiconductor Services
6 Comments

Is TSMC the real target, not just collateral damage?
Is equipment embargo threat to bring TSMC to heel?
Is an embargo a “Trifecta” of US strategic goals?

Maybe TSMC is a real target of chip equipment embargo not just potential collateral damage
It occurs to us when we talk about TSMC being caught in the middle between the US and China and being “collateral damage” in the crossfire of an embargo and trade war that maybe the US is really targeting TSMC, along with China and Huawei, and really killing three birds with one embargo stone.

Think about TSMC from a US perspective…..they have blown past beloved Intel in terms of technology dominance and clearly enabling AMD and others. They are building chips for the US’s enemies both military and commercial. They have in essence put US foundries out of business, GloFo, Intel’s foundry effort among others, and forced the US to buy all advanced chips from them with no alternate. They are getting a “bear hug” from their bigger nearby neighbor who covets them and could crush the US technologically by taking them over. And last, but not least, TSMC has refused US efforts to get them to either put a fab in the US or help with one such that the US chip supply would be protected from a hostile takeover.

Maybe if I were in power in the US government I would want to something over TSMC to bring them to heel and get them to cooperate or see things my way. Maybe I could cut off, or threaten to cut off, their “oxygen supply” of US made or controlled semiconductor equipment which could effectively put them out of business or cripple them.

The hand of the US government continues to get closer and closer to that “oxygen valve” that controls the flow of equipment. The ratcheting up of pressure and implied threat is crystal clear.

We would not be surprised to see some capitulation on the part of TSMC by preemptively agreeing to some sort of licensing arrangement that gives the US more control over their customers. We would also not be surprised to see some sort of US based foundry effort that TSMC could be part of. Maybe joint with Intel. Buy out GloFo’s fab and refit it or maybe a greenfield somewhere that gains political points.

Intel will not shed a lot of tears over TSMC getting bullied and could stand to benefit. TSMC could play it publicly as a win for them with some sort of concession to build a fab in the US. The US could say that jobs and leadership are being brought back to the US.

China’s Chip aspirations
Obviously one of the larger targets of a US chip equipment embargo would be to stave off the “made in China 2025” plans that China is focused on. Right now China is not self reliant on Chip manufacture let alone equipment to make chips.

Sooner or later China will catch up and get more and more chip technology but the strategic game plan is to delay, slow down and make as difficult as possible that goal. The longer we can keep them behind, the better for the US.
We have already seen the risk associated with China making 90% of US pharmaceuticals and probably 90% of PPE etc;. Obviously not only the US’s health is at stake but our military & intelligence superiority which is based in very large part on our advanced technology.

Cutting off Huawei and 5G
Huawei, which not that long ago was a tiny “copycat” of US router innovator , Cisco, is now threatening to dominate 5G and along with it a significant part of technology infrastructure. Obviously cutting off their supply of advanced chips would kill or effectively kill their 5G program which in turn would keep the US effectively in charge of the 5G rollout.

Neither Apple nor Cisco would shed tears. We know that Tim Cook has been close to the current US administration much as Intel’s prior management was also very close and probably whispers in high ranking ears about the threat of China, Huawei and 5G to not only US defense interests but commercial interests which translates to the all important stock market and US jobs.

The perfecta embargo “Trifecta”
All this suggests that embargoing or at the very least threatening to embargo US made and controlled semiconductor equipment gets 3 big goals; 1) slows China access to chip dominance 2) slows or stops China’s 5G plans 3) gets TSMC to “align” with US interests. Maybe not in that order of importance.

Three big birds on one stone? Is the US government really that smart? or that devious? We”ll find out……..

The stocks
Obviously TSMC’s stock is just as vulnerable as US semiconductor equipment makers. Maybe I want to be long non-US equipment makers such as Advantest, Tokyo Electron,ASMI, BESI and others and perhaps neutral to short US equipment makers and TSMC (for now).

Investors seem pre-occupied with the Covid crisis and are finally starting to realize the long term implications of Covid economic impact will in fact actually impact beloved tech stocks, perhaps as much if not more than the broader market.

Ugliness and excess risk abounds…

May 3, 2020August 2, 2020

Covid Created Collateral China Crisis

Covid Created Collateral China Crisis
by Robert Maire on 05-03-2020 at 6:00 am
Categories: China, Semiconductor Advisors, Semiconductor Services
7 Comments

Economic damage-
China relationship damage will far outlast direct Covid19 logistics impact-
Economic damage could be huge but trade damage could be larger with more specific impact on chips-

A long build up to a China trade nuclear winter, the “drum-beat of war”
When we started talking about a potential chip trade embargo with China 3 years ago we were roundly criticized and laughed at….not so any more as the specter of a full blown, tech led, trade war with China seems to get larger by the day.

Several months ago the heat got turned up again. On Monday the Commerce department issued three new rules that will effectively pave the way for technology exports to China and exports to companies doing business with China (read that as TSMC) to be more easily restricted.

Elimination of License Exception
Expansion of controls for Military Use
Modification of License Exception

This feels an awful lot like tanks are massing on the border and warships are moving into position. The direction and intention of moves made over the last several months are very, very clear. It seems with all this planning and build up that implementation is all but inevitable.

Can’t go after Covid so lets go after China
The administration seems to have lost the PR war and momentum of “rally around the flag” associated with Covid as approval ratings are dropping.
The media seems to be increasingly full of news that appears to be “redirecting” anguish and angst about Covid at China and their role (whether rightly or wrongly and as yet unproven…). Taking “revenge” on China for Covid through technology export restrictions restrictions seems like a logical, calculated response that may help sagging approval ratings with another “rally around the flag” associated with a conflict with China.

Chip companies votes don’t matter
As we have previously pointed out in several prior notes the political consequences of starting a trade war with China that primarily impacts tech companies (located in the “blue” state of California) doesn’t really matter. This is similar to stopping ASML’s export of an EUV scanner as Dutch residents don’t vote in US elections.

Starting a trade conflict with China as payback for Covid may get a lot of core support as well as support in swing states among the unemployed.

Locked and Loaded
The recently announced rule changes coupled with the current political and media under currents make it clear that we are ready to pull the trigger on the first shot in a trade war at any time as there is little more preparation to be done….all we need is some triggering event…..

Bracing for the impact
Lam updated its risk factors toady with a filing that said that China was 22% of 2019 and 29% of 9 months of 2020 and that all bets are off with respect to obtaining export licenses. Obviously Applied Materials and KLA as well as ASML and many others are just as impacted if not more.

Of course the biggest and most impactful company caught in the crossfire is TSMC with roughly 15% of revenues going to Huawei alone at risk and a lot more going directly or indirectly to China. TSMC would be major “collateral” damage in a trade war with China as would the US’s exports to TSMC.

We keep reminding readers that Taiwan is a short boat ride from mainland China which views Taiwan the same as Hong Kong just not yet brought back into the fold (by any means necessary)

Would a China trade war be limited to chips and tech ???
It is unclear whether China and the US would keep trade war limited to chips and tech. Could the entire trade deal recently concluded become at risk of falling apart before it ever started? Could US farmers and other industries become embroiled?

Maybe redirecting people’s attention away from Covid to a trade war with China would be viewed as a positive, after all, trade with China as well as a Southern wall were part of the reason the current administration is there in the first place.

Support for doing something against China is likely coming from both sides of the aisle and could prove a popular, uniting idea.

The real problem is limiting the fall out when the economy is already in a tail spin. Throwing fuel on an already raging economic bonfire by limiting exports is very tricky. Limiting it to tech or specifically chips, makes it much more palatable.

The stocks
Our position remains the same. The near term Covid impact is largely logistic by nature and will pass over time (though with a lot of pain and suffering…) but the longer term, economic impact is yet to be seen and much longer lived. If we add to that long term Covid economic impact the risk of a trade war with China revolving around chips and tech it makes the chip and tech stocks very unattractive at almost any valuation due to risk.

We have seen a short term pop in stock prices as the near term Covid impact has been lighter than most expected but the market seems to have not discounted the longer term impact nor much impact from the China trade risk.
While the values of the stocks on a purely numerical basis may look good right now, the risks are anything but.

We would prefer to keep our money on the side or in more defensive names.
The actual announcement of a chip/tech trade war could cut the value of the impacted stocks a lot more than Covid and a lot more quickly which is a risk that’s hard to tolerate especially now.

Semiconductor Advisors

Semiconductor Advisors on SemiWiki

May 1, 2020July 6, 2020

TSMC’s Advanced IC Packaging Solutions

TSMC’s Advanced IC Packaging Solutions
by Herb Reiter on 05-01-2020 at 10:00 am
Categories: Foundries, TSMC
8 Comments

TSMC as Pure Play Wafer Foundry
TSMC started its wafer foundry business more than 30 years ago. Visionary management and creative engineering teams developed leading-edge process technologies and their reputation as trusted source for high-volume production. TSMC also recognized very early the importance of building an ecosystem – to complement the company’s own strengths. Their Open Innovation Platform (OIP) attracted many EDA and IP partners to contribute to TSMC’s success, all following Moore’s Law, to 3 nm at this time, to serve very high-volume applications.

Markets need Advanced IC Packaging technologies
For many other applications Moore’s Law is no longer cost-effective, especially not for integration of heterogeneous functions. “Moore than Moore” technologies, like Multi-chip modules (MCMs) and System in Package (SiP) have become alternatives for integrating large amounts of logic and memory, analog, MEMS, etc. into (sub)system solutions. However, these methodologies were and still are very customer specific and incur significant development time and cost.

In response to market needs for new multi-die IC packaging solutions, TSMC has developed, in cooperation with OIP partners, advanced IC packaging technologies to offer economical solutions for More than Moore integration.

TSMC as supplier of Advanced IC Packaging solutions
In 2012 TSMC introduced, together with Xilinx, the by far largest FPGA available at that time, comprised of four identical 28 nm FPGA slices, mounted side-by-side, on a silicon interposer. They also developed through-silicon-vias (TSVs), micro-bumps and re-distribution-layers (RDLs) to interconnect these building blocks. Based on its construction, TSMC named this IC packaging solution Chip-on-Wafer-on-Substrate (CoWoS). This building blocks-based and EDA-supported packaging technology has become the de-facto industry standard for high-performance and high-power designs. Interposers, up to three stepper fields large, allow combining multiple die, die-stacks and passives, side by side, interconnected with sub-micron RDLs. Most common applications today are combinations of a CPU/GPU/TPU with one or more high bandwidth memories (HBMs).

In 2017 TSMC announced the Integrated FanOut technology (InFO). It uses, instead of the silicon interposer in CoWoS, a polyamide film, reducing unit cost and package height, both important success criteria for mobile applications. TSMC has already shipped tens of millions of InFO designs for use in smartphones.

In 2019 TSMC introduced the System on Integrated Chip (SoIC) technology. Using front-end (wafer-fab) equipment, TSMC can align very accurately, then compression-bond designs with many narrowly pitched copper pads, to further minimize form-factor, interconnect capacitance and power.

Figure 1 shows that CoWoS technology is targeting Cloud, AI, Networking, Datacenters and other high-performance and high-power computing applications.

InFO serves some of these and a broad range of other, typically more cost-sensitive and lower power markets.

SoIC technology offers multi-die building blocks for integration in CoWoS and/or InFO designs. – see Figure 2.

SoIC technology benefits
TSMC’s latest innovation, the SoIC technology is a very powerful way for stacking multiple dice into a “3D building block” (a.k.a. “3D-Chiplet”). Today SoICs enable about 10,000 interconnects per mm2 between vertically stacked dice. Development efforts towards 1 Million interconnects per mm2 are ongoing. 3D-IC enthusiasts, including myself, have been looking, for an IC packaging methodology that enables such fine-grain interconnects, further reduces form-factor, eliminates bandwidth limitations, simplifies heat management in die stacks and makes integrating large, highly parallel systems into an IC package practical. As its name – System on IC – suggests, this technology meets these challenging requirements. The impressive capabilities of SoIC and SoIC+ are further explained here. TSMC’s EDA partners are working on complementing this technology with user-friendly design methodologies. I expect IP partners to offer soon SoIC ready chiplets and simulation models for user-friendly integration into CoWoS and InFO designs.

Personal comment: More than 20 years ago, in my alliance management role at Synopsys, I had the opportunity to contribute to Dr. Cliff Hou’s pioneering development work on TSMC’s initial process design kits (PDKs) and reference design flows, to facilitate the transition from the traditional IDM to the much more economical fabless IC vendor business model.

With the above described packaging technologies, TSMC is pioneering another change to the semiconductor business. CoWoS, InFO and especially SoIC enable semiconductor and system vendors to migrate from today’s lower complexity (and lower value) component-level ICs, to very high complexity and high value system-level solutions in IC packages. Last, but not least, these three advanced IC packaging solutions are accelerating an important industry trend: A big portion of the IC and system value creation is shifting from the die to the package.

May 1, 2020January 11, 2022

Lithography Resolution Limits: Line End Gaps

Lithography Resolution Limits: Line End Gaps
by Fred Chen on 05-01-2020 at 6:00 am
Categories: Lithography
1 Comment

In a previous article [1], the Rayleigh criterion was mentioned as the resolution limit for the distance between two features. On the other hand, in a following article [2], the minimum pitch was mentioned for the resolution limit for arrayed features. In this article, we reconcile the two by considering gaps between arrayed features, for example, between a minimum pitch line end and the edge of a perpendicular line.

Counting Spatial Harmonics (Diffraction Orders)

The number of features that can fit into the pitch equals the number of spatial harmonic intervals (=wavelength/pitch) that are passed by the numerical aperture (NA) of the optical system. If 5 spatial harmonics, or diffraction orders beyond the zeroth, are passed, then five intensity peaks emerge, indicating a minimum feature size of one-fifth the pitch (Figure 1).

Figure 1. The fundamental (1st harmonic) only generates one feature per pitch, while the fifth harmonic generates five.

With a minimum pitch of wavelength/NA in the horizontal direction, and a wider pitch in the vertical direction, the number of features spaced vertically within the vertical pitch at most will be the number of diffraction orders in the vertical direction (besides the zeroth), and this will depend on the illumination. The minimum pitch dictates an optimum illumination (e.g., dipole or quadrupole) which will limit the number of diffraction orders to two in the horizontal direction and a given number in the vertical direction. By dividing the vertical pitch by the number of diffraction order intervals, the minimum gap in the vertically running line can be estimated (Figure 2).

Figure 2. Left: The optimum illumination for a given pitch between vertical lines will arrange to have the diffraction orders at equal horizontal distances from the center, while allowing a number to spread out vertically. The circle represents the numerical aperture which will cut off diffraction orders which fall outside. Center: Top view of aerial image of a rectangle between horizontal lines. The cut line aerial image (right) from the center cutline shows the gap where intensity drops is roughly 1/5 the vertical pitch, as expected from the number of included diffraction order intervals.

This is calculated for a range of minimum pitches and cross-pitches and plotted in Figure 3.

Figure 3. Left: Tip-to-edge gap for a line pitch of wavelength/NA, as a function of cross-pitch, normalized to wavelength/NA. Right: Tip-to-edge gap for a cross-pitch of 4 x line pitch, as a function of line pitch, normalized to wavelength/NA. The illumination is optimized for the line pitch.

In fact, the lower limit of gap size can be calculated exactly if the minimum line pitch is at most wavelength/NA. It is sqrt(3)/3 * wavelength/NA. The proof is given in the Appendix.

Sanity Check: consistency with the Rayleigh Criterion

The Rayleigh criterion and the arrayed feature results are both derived from Fourier transforms truncated by the numerical aperture. The Airy disc underlying the Rayleigh criterion comes from the Fourier transform of a circular aperture while the Fourier transform of an array produces a Fourier series convolved with the apertures within a pitch. Hence, there should be no conflict between the above and previous [2] arrayed feature results and the Rayleigh criterion.

Shrinking the gap below k1=0.6

An interesting effect is predicted when the gap is smaller than 0.6 wavelength/NA. It appears as if less light is absorbed or transmitted (reflected for EUV case) by the shrinking feature. This can lead to resist scumming for example [4]. This can be understood by considering the amplitudes of the harmonics (Figure 4).

Figure 4. The amplitudes of the spatial harmonics (diffraction orders) which are not cut off by the numerical aperture all decrease when the gap size falls below 0.6 wavelength/NA (k1=0.6), but above this size, the higher harmonics decrease while the lower ones increase.

For features below 0.5-0.6 wavelength/NA, the amplitudes of all the harmonics decrease with decreasing size. However, for features sized 0.6 wavelength/NA and higher, the higher harmonic amplitudes decrease as size is increased while the lower harmonics have the opposite trend, indicating a trend toward sharper edges [5]. Below 0.6 wavelength/NA, gaps in lines are better patterned by a separate cut mask exposure [6]. This allows the smaller line end gaps to be compensated with a higher dose.

The gap between line end and perpendicular line edge can also be reduced below ~0.6 wavelength/NA by spacer patterning within an initially wider starting gap (Figure 5). This approach is also known as spacer-is-dielectric self-aligned double patterning (SID SADP) [7].

Figure 5. SID SADP approach to reducing gap width.

Summary of Lithography Resolution Limits

The lithography resolution limits are now summarized as follows:

Gap between isolated pairs: 0.61 wavelength/NA

Minimum pitch of arrayed features: 0.5 wavelength/NA/(1-angle tolerance)

Line end gaps for line pitch<=wavelength/NA: 0.58 wavelength/NA

Appendix: Derivation of lower limit of arrayed gap size for minimum line pitch of wavelength/NA or less

The starting point here is that for a minimum pitch p <= wavelength/NA (dense line k1<=0.5), the illumination will first produce the diffraction order distribution shown on the left in Figure 2. In terms of spatial frequency coordinates, this means the x-coordinates are +/- 0.5 wavelength/p. Here we express the y-pitch as a multiple of the minimum pitch, i.e., np. The diffraction order interval is therefore wavelength/p/n. The number of such intervals which fit within the numerical aperture NA is therefore given by

N=2 * sqrt(NA^2-(0.5 wavelength/p)^2)/(wavelength/p/n)

= 2 n sqrt((p*NA/wavelength)^2-1/4). (1)

The estimated gap size is therefore

gap size = np/N = n p/ [2 n sqrt((p*NA/wavelength)^2-1/4)]

= p/sqrt[(2 NA p/wavelength)^2-1]. (2)

Since p lies within the range 0.5-1 wavelength/NA, the minimum gap size occurs for p = wavelength/NA, giving a gap size of 1/sqrt(3) wavelength/NA = sqrt(3)/3 wavelength/NA ~ 0.58 wavelength/NA (Figure 6). Note that this is larger than the nominal line spacing (k1<=0.5). So, for connections to the next layer that must not exceed k1=0.5, the gap must be printed with a cut mask.

Figure 6. Gap size vs. line pitch, where both are normalized to wavelength/NA (k1=dimension/(wavelength/NA)).

References

[1] https://www.linkedin.com/pulse/lithography-resolution-limits-paired-features-frederick-chen/

[2] https://www.linkedin.com/pulse/lithography-resolution-limits-arrayed-features-frederick-chen/

[3] https://en.wikipedia.org/wiki/Fourier_optics

[4] D. Chou, K. McAllister, “Line end optimization through optical proximity correction (OPC): a case study,” Proc. SPIE 6154, 61543A (2006).

[5] https://user.eng.umd.edu/~tretter/enee322/FourierSeries.pdf

[6] Z. Li et al., “The study of 28nm node poly double patterning integrated process,” CSTIC 2015.

[7] Y. Du et al., “Enhanced spacer-is-dielectric (sid) decomposition flow with model-based verification,” Proc. SPIE 8684, 86840D (2013).

Slash Tapeout Times with Calibre in the Cloud

Slash Tapeout Times with Calibre in the Cloud
by Mike Gianfagna on 04-30-2020 at 10:00 am
Categories: EDA, Siemens EDA

I’ve spent many years in the ASIC business, and I’ve seen my share of complex chip tapeouts. All of these projects share one important challenge – compute requirements explode when you get close to the finish line. Certain tools need to run on the full-chip layout for final verification and the run times for those tools can get excessively long. The story is probably quite familiar to many. There is a fixed compute capacity available in any on-premise datacenter. That capacity is designed to handle typical workloads for the company and most of the time that works OK.

Near tapeout, run times for some key tools start to explode however, thanks to the massive amount of data to be processed for the final full-chip runs. Adding more processors and memory helps a lot. Going from 2,000 to 8,000 cores for example. But who has 6,000 cores sitting idle when the whole compute farm is provisioned at around 2,000 cores? You get the picture.

Mentor’s Calibre DRC is one such tool that is a key part of the full-chip tapeout process. That’s why a recent white paper from Mentor entitled “Mentor, AMD and Microsoft Collaborate on EDA in the Cloud” caught my attention. This white paper presents a thoughtful and complete analysis of how to tame the peak load demand problem using cloud computing to access essentially unlimited compute power when needed.

The white paper is written by Omar El-Sewefy, a technical lead at Mentor who has been working on their advanced products for almost 12 years. Omar presents a thoughtful analysis of how to reduce long run times by exploiting the cloud-ready capabilities of Caibre’s physical verification technology. The analysis is a collaboration with AMD for processing power and Microsoft Azure for cloud infrastructure, so the results are based on mainstream, “available now” technology. The punch line is that a speed-up of 2X or more in physical verification cycle time can be achieved on a 7nm design.

While that’s an eye-catching statistic, the piece offers a lot more insight into how to achieve that improvement and how to even exceed it. A key part of the analysis is finding the right mix of compute resources for optimal, cost-effective improvement. More isn’t always better, and when you’re using the essentially infinite resources offered by the cloud knowing what to ask for is very important.

The best practices for using Calibre in the cloud presented in the white paper were done using AMD EPYC™ servers running on the Azure cloud service environment. The latest foundry-qualified rule deck was also used to ensure the latest technology was applied. I mentioned Calibre’s cloud-readiness. Mentor has been steadily improving Calibre’s processing and memory efficiency to facilitate better results in the cloud. The figure below illustrates normalized memory improvements on the left and normalized run time improvements on the right for Calibre releases over the past year.

The analysis presented in the white paper used various configurations of AMD’s EPYC 7551 processors running in the Azure cloud. The 2019.2 release of Calibre was used, with Calibre nmDRC™ providing hyper-remote distributed computing capability up to 4,000 cores. The results in the white paper focus on the optimal balance of processing power and memory to deploy for the case used. This is quite important. The resources offered by the cloud are essentially unlimited. This means the user must be thoughtful about what resources are used or project budgets can go out of control.

The white paper provides a lot of good details about how to achieve this balance and I highly recommend you download it to see the details for yourself. To whet your appetite, here are a few key observations:

Regarding the number of cores, it turns out there is a “knee” in the scaling curve where the “best value for money” is achieved. For the design and node that was run, the knee was reached between 1,500 and 2,000 cores
Regarding memory usage, RAM requirements per remote core are reduced by increasing the total number of remote cores, which aligns with the overall scaling strategy

To put all this in perspective, the original run time for this case could be 24 hours using a typical on-premise datacenter. By increasing cores to 2,000 in the cloud, the run time can be reduced to 12 hours, allowing twice as many runs per day. I mentioned that the Calibre 2019.2 release was used for these experiments. What if the latest release was used? That experiment yielded an addition 3-hour reduction with 2,000 cores. More improvements are possible by increasing the cores to 4,000 of course. That becomes a cost/benefit decision, one that is only possible when you are using the cloud. You can download the whole story here.