SemiWiki – Page 307 – The Open Forum for Semiconductor Professionals

RVN! 26 Banner revised (800 x 100 px) (600 x 100 px)

May 28, 2021March 25, 2022

Heterogeneous Chiplets Design and Integration

Transistor Cost per Billion 3nm Projection

Over the recent years, the volume and velocity of discussions relating to chiplets have intensified. A major reason for this is the projected market opportunity. According to research firm Omdia, chiplets driven market is expected to be $6B by 2024 from just $645M in 2018. That’s an impressive nine-fold projected increase over a six-year period.

Chiplets are neither chips nor packages. They are what we end up with after architecturally disintegrating a large integrated circuit into multiple smaller dies. The smaller dies are referred to as chiplets. Conceptually one could say that a chiplets-based design resembles a Silicon-In-Package (SiP) based design. But the similarity stops at the concept level at best. Historically SiP based approach was adopted primarily for faster time to market by mixing and matching dies of pre-existing chips. Many times, these pre-existing dies were in different process technologies. The package related cost savings combined with the time to market benefit made certain SiP-based products better business decisions compared to a system-on-chip (SoC) approach.

Chiplets based design seems attractive starting with sub-10nm process node. There are a number of reasons for this. For one, litho equipment impose reticle size limits to ensure distortion free mask exposures, thereby limiting the size of large chips. Another reason is the exorbitant cost of developing a SoC-based product. Yet another reason is the number of good dies per wafer expected from large chips in these advanced process nodes. The yield rate is better for smaller dies. The multiple smaller dies could avoid high development cost relating to very advanced process nodes and still deliver an overall product cost advantage as a chiplet-based implementation. Additionally, at sub-5nm process nodes, transistor cost is projected to uptick. Refer to Figure 1 below.

Figure 1: Cost of transistor at different process technologies

Source: International Business Strategies 2020

Currently lot of attention and efforts are directed at chiplet interfaces. A number of companies have developed excellent IP products supporting different types of chiplet interfaces. Equally important is a well-defined design and integration methodology that will deliver successful chiplets-based products. A recently published whitepaper from Siemens EDA addresses exactly this. It identifies the technical challenges to anticipate and presents ways to overcome those. The whitepaper was authored by Keith Felton, Anthony Mastroianni, Kevin Rinebold and Per Viklund. This blog synthesizes the salient points garnered from that whitepaper.

Early planning and predictive analysis

A number of challenges get introduced when dealing with chiplets integration. Apart from power delivery and thermal management, developing and co-optimizing the interposer and package becomes challenging as different teams will be dealing with different chiplets. Investigating the interposer connectivity structures and evaluating available material options early on will prevent late-stage design changes. And approximating metal coverage per layer using a Monte Carlo-type sweep analysis will help identify parts of a circuit whose performance would be impacted the most. These steps help accelerate the design and integration process.

Hierarchical chiplet co-optimization

Even though any one particular chiplet is a subset of functions of an SoC, taking a hierarchical planning of the chiplets provides a lot of benefits. Combined with a robust engineering change order (ECO) mechanism as one would with a SoC approach, asynchronous changes from different chiplet teams would not fall through the cracks. And chiplet’s bump array and signal assignments can be created at the interposer level and passed back to the individual chiplet design teams.

Chiplet interface management and design

Even with standardized chiplet interfaces, frequently graphical schematics are used to specify the interfaces. The designer looks up interface definition for each chiplet and manually creates the required connectivity. But this is a lot of manual work and has the potential to introduce mistakes that may not be easy to catch early in the design process. Siemens EDA introduces a novel concept for eliminating this risk.

A novel concept – Interface based design

The interface description becomes part of the chiplet model as an interface-based-design (IBD) object. This novel approach ensures correct-by-design chiplet connectivity. It enables the designer to focus on chiplet floorplanning and chiplet-to-package or chiplet-to-interposer signal assignments. The designer is able to explore routing scenarios without having to transition to a substrate place-and-route tool.

Electrical, thermal and mechanical stress management

The close proximity of chiplets may introduce chip-package interactions (CPI) that result in electrical, thermal and/or mechanical stress issues. It is very important that predictive analysis is started as early in the planning phase as possible. This will help identify the right materials for certain connectivity structures.

Testing and testability

Testing and testability are always challenging aspects when it comes to chip designs. Although the different chiplets sourced will be wafer sorted and delivered as known good dies, testing is still needed as an assembled product. IEEE test standards are being developed to accommodate 2.5D test methods. Tool vendors may deploy different approaches to implementing these standards, causing potential test compatibility issues when utilizing chiplets from different vendors. A number of advances are being made in this area as well to ensure interoperability.

Verification and signoff

With so many aspects involved, it is imperative that verification and in-design validation happen throughout the process from the initial planning stages through the layout process. This ensures that any layout enhancement techniques used to improve yield and reliability have not impacted the design in any unintended way. And if impacted, the issues are caught early on before the design is sent to manufacturing.

Summary

In essence, Siemens has elucidated a methodology with clear steps to take to achieve success with heterogeneous chiplets design and integration. It has also highlighted the need for coming together of the ecosystem to support chiplets based design testing. For detailed insight, please refer to the whitepaper and have exploratory discussions with Siemens EDA. You can download the whitepaper “Heterogeneous Chiplets Design and Integration” here.

Also Read:

Siemens EDA Acquires an IP Validation Tool for standard cells, IO and Hard IP

Safety Architecture Verification, ISO 26262

Developing Verification Flows for Silicon Photonics

May 27, 2021September 30, 2021

Siemens EDA Acquires an IP Validation Tool for standard cells, IO and Hard IP

$fractal CrossFire min$

We’re living in an era of good growth for semiconductor design companies, and it’s no secret that each new SoC that comes along contains hundreds of IP blocks, so IP design re-use is just an accepted way of getting to market more quickly with lower risks. But how do we really know that all of the new IP is really correct? Like a famous president once said, “Trust, but verify.” In the EDA industry we have Fractal Technologies that has been successful in building up a business by offering a tool that lets engineers perform IP validation.

I spoke this month with Amit Gupta and Wei-Lii Tan of Siemens EDA about their recently announced acquisition of Fractal Technologies. Amit is famous for founding Solido Design Automation back in 2005, then getting acquired by Mentor Graphics in 2017; and they offered a set of EDA tools for design variation and ML characterization. I’ve met Amit at DAC several times over the years, and was always amazed that brute-force Monte Carlo SPICE simulations were now replaced by something much smarter and faster.

On SemiWiki our first blog on Fractal was back in April 2013, really, they’ve been around since 2010 and their CrossFire product is quite solid and unique in the marketplace. With the acquisition the product is renamed to Solido CrossCheck, which makes sense, as it’s now part of the Solido product group within Siemens EDA.

There were common customers already using both the Solido tools and Fractal, so the acquisition is complementary, and Gupta reports that the Fractal customers are quite happy to learn about the acquisition, as it means a long future for a trusted EDA tool. Over the years the engineers using Fractal tools would add their own IP checks, extending the robustness of checking, then send them to Fractal for possible inclusion to all users. That trend will continue.

Fractal tools work with industry standard file formats (views), and being part of Siemens EDA will continue that support for hundreds of checks.

Verilog / VHDL (timing arcs)
Schematic
Liberty
ECSM
LEF
GDSII
CSS
UPF

IP Validation

Who uses IP Validation? Both IP vendors and IP integrators, because each wants to know if all of their IP views are consistently defined. Both digital and analog IP can be run through the Solido CrossCheck tool.

Could you write your own scripts to validate IP? Yes, but it would take too many man-years of effort to come up with something approaching what Fractal has already done since 2010.

Perhaps in the future we could see Solido CrossCheck adding some ML capabilities, since the Solido engineering team has been applying ML for a decade now. Stay tuned. The bottom line is that your silicon design team really needs a tool that finds any IP errors before tape out.

DAC 2016 – Fractal Technologies

Summary

In the EDA world there have been many acquisitions, and the most successful ones follow some simple maxims:

Complementary technology
Growing market segments
Compatible management styles
Common customers
Allow the smaller company to innovate and grow
Learn from each other
Let the smaller company teach the bigger company AEs to become specialists
Reward achievements

I’ve seen how well Mentor treated the people from Berkeley Design Automation, Solido and Tanner EDA, growing their business segments after acquisition, so I expect it will be the same with Fractal joining the Solido group in Siemens EDA. At DAC in December I will follow up and see how the Solido CrossCheck product and developers are doing.

Related Blogs

May 27, 2021April 20, 2022

Accellera Unveils PSS 2.0 – Production Ready

Accellera Unveils PSS 2.0 – Production Ready
by Bernard Murphy on 05-27-2021 at 6:00 am
Categories: Accellera, Semiconductor Services

I recently had a discussion with Tom Fitzpatrick of Siemens and Faris Khundakjie of Intel on the latest release of the Portable Test and Stimulus Standard (PSS). Faris chairs the PSS working group and Tom is vice-chair. In what follows I synthesize feedback from both, sometimes I call out interesting individual comments. My first obvious question: what distinguishes 2.0 from 1.0? I’m interested in motivation rather than technical details, so we started with the goals of 1.0 and how 2.0 has built on early release.

Evolution of PSS

PSS is a fairly big departure from the most commonly understood platform for IP and SoC test (UVM). UVM is great for many things, but not for software-driven testing, or porting tests between users at different levels of integration and under different configurations. Or even to support constrained random verification in a truly system level sense. Needs that have been vigorously demanded over many years by many verification experts. None of which could be managed comfortably in yet another rev of UVM.

Hence PSS 1.0 was born (and a little later 1.0a). It was a departure from a known environment and didn’t have the benefit of building on established solutions like AVM, OVM and Vera in the way that UVM could. Tom said the PSS first release had more in common with the SystemVerilog first release. Lots of promise but demanding quite a bit of reorientation from users and solution providers. Who, as they developed experience, started asking for a lot of new features. Those are now converging in 2.0, pointing to more maturing of the standard.

New features

Faris mentioned that 2.0 introduces a register model into PSS, to support configuration for example. Now PSS test designs can build tests with register references in a portable fashion. I poked at this a bit more. UVM has register modeling, what makes PSS different here? Faris said that it’s in the abstraction. PSS is careful about having a nimble model of registers and groups which doesn’t need to rest on a full instantiation. Allowing the realization layer to determine how best to handle these, in an emulator for example. Which no doubt can also map into a UVM realization where appropriate. Tricky stuff, this abstraction, but I see his point.

The new release also adds a lot more control over scenarios and how those scenarios are composed. Allowing for timing relationships when you might have power scenarios overlapping with functional and security scenarios. They also added a lot of enhancements around Exec blocks, that critical realization layer between the high-level test description and mapping to UVM, or C or whatever might be the target. These enhancements enable more reusability/portability by allowing users to add more abstract functionality to exec blocks. To help define procedural code in one place, yet still be able target all those different realizations.

Where’s PSS being used?

Another obvious question – how is PSS being used in practice today? Tom said that a very popular use model is in (pre-silicon) bring up testing. As you start pulling the SoC functionality together, there’s need to make sure that everything is at least able to converse. The essentials of system-level communication, even before you boot the OS. Here you can mimic scheduling in your PSS testbench. Subsequently, a great thing about the standard is that you can connect to the OS through API calls. To start to verify the hardware model is working correctly with that level of software. And you can begin randomizing to see what breaks. A pretty compelling application for tools based on the standard.

Ecosystem development

I wrapped up with a question about the supporting ecosystem – libraries, training and so on. First, in 2.0, the standard moved ahead of existing capabilities in tools, so they all probably have some catching up to do and the ecosystem will follow along. Faris sees a lot of opportunity for apps to develop around areas like security and coherency. These exist already but there’s value in seeing PSS-compliant implementations. Similarly, there’s great opportunity for PSS libraries around other standards: CXL, PCIe and so on. Being able to interact with these standards in system-level validation. Tom added that he’s also sure leaders in training are likely to jump on PSS 2.0, once the tools are ready.

Want to know more? Click HERE.

Also Read:

Functional Safety – What and How

An Accellera Update. COVID Accelerates Progress

DVCon 2020 Virtual Follow-Up Conference!

May 26, 2021May 26, 2021

Functional Safety – What and How

Functional Safety – What and How
by Daniel Payne on 05-26-2021 at 10:00 am
Categories: Accellera, Semiconductor Services

I’ve written before about how the automotive industry adheres to functional safety (FS) as defined in the ISO 26262 standard, along with other SemiWiki bloggers. That standard certainly defines the What part of FS, however it doesn’t mandate how you meet the standard, what tools you should be using, file formats or even languages. Fortunately for us, the pragmatists at Accellera Systems Initiative are focused on the How part of FS, as witnessed by their recent organization of a Functional Safety Working Group (FSWG), and publication of a 27 page white paper on their efforts to define standards for sharing functional safety data. I also spoke with Allessandra Nardi who chairs the FSWG, and works at Cadence as the Sr. Software Engineering Group Director, Automotive solutions.

The stakeholders in the FSWG are in four areas:

Most of the EDA industry is focused on two stakeholders: EDA Experts, IP Experts. Our EDA customers are typically the last two stakeholders: Silicon Experts, System Experts. The new standardization will provide FS data exchange plus traceability through these analysis and work products:

FTA – Fault Tree Analysis
FMEA – Failure Modes and Effect Analysis
DFA – Dependent Failure Analysis
FMEDA – Failure Modes and Effects and Diagnostic Analysis

Terminology

In the semiconductor design world we use familiar words to define layers of abstraction, like: IP, Component, Module, System. In the FS world of ISO 26262 there’s a slightly different set of words for these same four layers:

The general FS workflow has 10 steps that are inter-related, also known as data elements contained in work products:

Challenges Today

Today when two suppliers deliver work products to a customer, then multiple data formats are typically used, causing headaches for the integrator to resolve:

With a standardized FS data exchange format, the promise is that suppliers only need to follow the standard, and can then deliver the same work products to multiple customers:

The supply chain will be able to streamline FS data exchange between IP, Component, Module and System levels, saving time and avoiding integration challenges.

Traceability

When a requirement changes, how will that impact my IP, Components, Modules and ultimately the System being designed? Traceability is the answer, for both requirements and verification, plus with litigation you need to know at which level FS was compromised. Evidence created through each development layer needs to be traceable, justified and then documented as a safety case, which is then kept around for years after the design work has been completed.

FS Data

You can expect that the FSWG will provide us with a FS data exchange that is interoperable throughout the supply chain, provides traceability, and uses automation in EDA tools. Here’s the scope of the FSWG shown in green, where the first efforts are below the green dotted lines:

IEEE

Just like many standards efforts over the years, once completed and published, the Accellera Functional Safety standard will be considered for contribution to IEEE.

FS Scope

With a standardized FS data model, you can see how all layers in the EDA ecosystem will be used together.

The FS data exchange goals are to be both ASCI and machine parsed, flexible, tool agnostic, and support differing views per abstraction level.

Summary

Functional safety adherence keeps us all safe while driving a car, flying in a jet, receiving medial care and using electronics in industrial applications, so it makes a lot of sense to create standards for exchanging FS data. Accellera has created a FSWG to address the How part through a standard for exchanging FS data, so take a look at their white paper to get all of the details, and maybe even participate with them.

Related Blogs

May 26, 2021March 16, 2022

Fuzzing to Validate SoC Security. Innovation in Verification

Fuzzing to Validate SoC Security. Innovation in Verification
by Bernard Murphy on 05-26-2021 at 6:00 am
Categories: Cadence, EDA, Security

Fuzzing is to software verification what randomization is hardware verification. Can a fuzzing approach improve hardware security testing? Paul Cunningham (GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, entrepreneur, former Synopsys CTO) and I continue our series on research ideas. As always, feedback welcome.

The Innovation

This month’s pick is HyperFuzzing for SoC Security Validation. The authors presented this paper at ICCAD 2020. They are from IIT Kanpur.

This is an intriguing approach to fuzzing, adapted specifically to modern SoC design. It builds on hyper-property checking in dynamic simulations. These hyper-properties reason about behaviors over sets of traces, an approach well suited to security checking. The authors offer as examples information flow checks (privileged data cannot leak from A to B say) and non-interference checks (adversarial actions must not interfere with computations flow). Security is then checked by comparing bundles of simulation traces with and without tampering.

Tampering in this approach can model different types of vulnerabilities to untrusted sources. By randomizing firmware instructions, write instructions from a component to the NoC, or bit flips in a memory. The authors also propose several novel coverage metrics. These are designed to guide iterations to tampering around cases most influenced by previous tampering runs.

Their testcase is a small though representative SoC (details in GitHub) running firmware tests against cryptographic blocks, checking for non-interference and other vulnerabilities. They also run secure boot with data block checks. They found multiple security violations in the crypto blocks, except where block include ECC protection.

Paul’s view

Security verification is a such an important topic, and there is much work ongoing here both in academia and in industry. This paper nicely brings together randomized mutation-based coverage with “hyper-properties” over sets of simulation traces to create an innovative solution that is both scalable and effective at demonstrating security flaws.

Some security properties can be formally defined only over a set of simulation traces. For example, “non-interference” means that an attacker cannot interfere with certain protected computations in a design. To demonstrate interference, you need to compare two traces, identical in input stimulus except for the presence of some attacker actions in one trace. If any protected computations in the attacked trace differ from those in the golden trace, then there has been interference.

The authors create their own special flavor of language for assertions over multiple traces and use it to formulate security properties for non-interference and confidentiality. They build a custom flow to randomly tamper with simulations and check their security properties between tampered and non-tampered simulations. Their random tampering algorithm also has an elegant coverage-based learning heuristic to guide it to more efficiently find security flaws.

The idea of assertions over multiple simulations is very powerful. I wonder if it would be possible to cleanly extend SystemVerilog to support these kinds of assertions. This could open the door to some compelling native extensions to commercial simulation and formal tools. Another possibility might be to extend the new Portable Stimulus Standard (PSS) to include assertions that span across multiple generated tests.

This paper is an easy and enjoyable read, although I do wish for some more details on the results. The authors claim their solution finds security holes in their open-source SoC testcase but there are no details on what these holes are or how their approach compares to other approaches in the literature that could be applied to finding the same holes.

Raúl’s view

I’m going to look at this first from a technology maturity angle. I like the idea in general, a very interesting approach to grade for security in a design. That said, each design requires designers to provide seed tests, tamperers and security specs in a novel assertion language. For me this bounds the approach firmly to the academic domain for now. Great for dissertations and papers, not yet close to something that could make the jump to commercial application.

I’ll put my investor hat on for the second challenge. Security is an important topic, no question. But outside of a few domains we already know – aerospace, defense, payment systems and processors/servers for example. It’s still not an existential problem for most OEMs and component builders. They’re willing to check a box if generally expected. But only if impact on cost or time to market is small. Because their customers generally won’t pay more for security. Which leaves security for most markets still dependent on turnkey IP, such as hardware roots of trust, and easy-to-use apps. Solutions packaged in one of these ways will be investable, otherwise not so much.

My view

Paul and Raúl covered most of what I might have suggested. I like Paul’s idea of extending SVA, at least to encourage experimentation with hyper-properties. This must open a new class of interesting tests, leading eventually to new bundled verification methods.

Also Read

Cadence Extends Tensilica Vision, AI Product Line

Agile and Verification, Validation. Innovation in Verification

Cadence Dynamic Duo Upgrade Debuts

May 25, 2021May 25, 2021

Molecular Sensing for Semiconductor Etch Applications

Molecular Sensing for Semiconductor Etch Applications
by Tom Simon on 05-25-2021 at 10:00 am
Categories: Atonarp, Semiconductor Services

As process technologies have advanced, the difficulties in performing etch operations have increased. New structures and chemistries have created challenges in monitoring these complex operations. For instance, 3D-NAND structures call for high aspect ratio (HAR) trench etching. Likewise, in addition to involving Al, W, Cu, Ti and TiN, etching is now used for high-k dielectrics, metal gates and rare earth metals used in memory stacks. In-situ quantitative gas metrology by using molecular sensing is proving to be an essential tool to qualify process chambers and monitor process chemistries to ensure high yields. Its use is not, however, without some challenges.

Atonarp, a leader in molecular sensing technology, has written a white paper that identifies the issues encountered with conventional gas analysis metrology and shows how their Aston molecular sensor product addresses them. Key among these issues is durability, chamber matching, system integration and ease of use. Aston can monitor precursors, reactants and by-products during processing steps. Aston works in real time for baseline chamber and process fingerprinting, chamber clean, process monitoring (including in the presence of corrosive gases), particle deposition and gaseous contaminant condensation.

Aston offers two new features that enable it to work more reliably and longer before maintenance is needed. Their ReGen^TM mode uses energetic plasma ions to remove deposits on the sensor chamber walls. Also, the sensor offers two ionization sources; the μPlasma ionization feature preserves filament life from the effects of aggressive gases such as NF₃, CF₄ Cl₂and there is also a separate electron impact (EI) filament ionizer for baselining and calibration. These features combined with the removal of particles such as (Tetraethyl Orthosilicate) TEOS and vapor contaminant deposits concurrently with regularly scheduled chamber clean cycles, dramatically extends the sensor lifetime between scheduled maintenance cycles by up to x100.

The Atonarp white paper reviews the metrology difficulties encountered when high aspect ratio masks are needed for 3D device structures. These are seen in 3D NAND flash and DRAM as well. Aspect ratios of greater than 100:1 are common. Etching through alternating layers of silicon nitrate and silicon oxide demand high speed sensing and quantitative end point detection, which is increasingly challenging for legacy metrology solutions. Variation from wafer to wafer must be minimized and held to tight margins or else yield will be compromised. New materials such as tungsten and copper call for increased contamination analysis to ensure protocol zones are managed within the FAB.

According to the Atonarp white paper, Aston provides comprehensive in-situ gas metrology. It can detect and quantify contamination, cross-contamination, gas impurities and process chemistry inside the process chamber. It can help assess performance of etch recipes. Aston also measures post-etch clean to help eliminate process drifts. Lastly, it uses plasma or gas monitoring to provide fast and accurate end point detection (EPD). For instance, it can do this by monitoring CO by-product decline during dielectric etching, or Cl reactant rise for polysilicon and metal at endpoint.

Molecular sensing

Low Open Area (OA) and HAR designs are making optical emission spectroscopy (OES) less desirable for EPD. OES already was facing challenges for OA due to background noise levels that inhibited detection of changes in emitting species. For tungsten etch there is a reduction in Cl reactants with smaller OA. With HAR the etch tends to slow down due to reduced material transport. The combination of both of these effects decreases the consumption of reactant gas, making it difficult to see observable changes in the OES signal due to depletion of reactants from the plasma. The white paper points out that Aston is capable of looking at both reactants and by-products for accurate EPD.

Aston is useful for atomic level etch (ALE) because it can report on chamber and process health. While ALE is basically self-limiting, it can still be useful to monitor process drifts for maximum throughput. Aston does not need plasma to make observations, so it is a good fit for ALE, which is chemical de-absorption, not plasma based. With ALE Aston can be used during the process to monitor all the chemical changes and ensure the process is properly going through all the steps.

The semiconductor etch process has become much more complex in recent years and calls for more advanced monitoring. Atonarp’s Aston in-situ metrology product looks like an excellent fit for these applications. In this article I was only able to skim the white paper, which offers much more detail on the uses of Aston. The full white paper is available in the Atonarp website by registering at this link https://www.atonarp.com/contact/aston

May 25, 2021August 22, 2024

Machine Learning Applied to Increase Fab Yield

Machine Learning Applied to Increase Fab Yield
by Tom Dillinger on 05-25-2021 at 8:00 am
Categories: Events, Foundries, GlobalFoundries
1 Comment

Machine learning applications have become pervasive and increasingly complex, from recommendation agents in online interactions to personal assistants for command response to (ultimately) autonomous vehicle control. Yet, an often overlooked facet of machine learning technology is the deployment in industrial process control systems.

The use of machine learning classification and decision algorithms can provide an immediate benefit in manufacturing yield (and thus, cost) and shipped product quality (through improved statistical variation control).

At the recent Advanced Semiconductor Manufacturing Conference (ASMC), sponsored by SEMI, Matthew McLaughlin from GLOBALFOUNDRIES provided an enlightening talk describing how the production fab team developed a machine learning method which resulted in significant yield improvements for a key, critical process flow step.[1]

We tend to focus on the recent advances in fabrication technology and equipment development that have enabled continued device and interconnect scaling. If I were to conduct a survey of SemiWiki readers, “What is the most critical step in microelectronics fabrication?” the answers would likely be dominated by newer technologies. High aspect ratio trench/contact etch. EUV lithography. Atomic layer deposition. In actuality, the most critical fab step has not changed in 50 years. The most important module in any fab is the photoresist spin coating system.

Photoresist Spin Coating

The figures below illustrate how photoresist is applied to the wafer, in preparation for mask layer lithography.

The wafer is mounted on a vacuum chuck. Photoresist is dispensed on the wafer surface, and a specific sequence of chuck spin ramp-up and steady-state RPM steps are used to distribute a thin uniform photoresist layer. (A preliminary step is also often employed – a solvent is applied to the wafer, which is spun and subsequently dried in N2 to pre-clean the surface and improve photoresist adhesion.) A special shroud around the chuck collects the excess photoresist which is centrifugally thrown off the wafer, to reduce any back-splash splatter.

The uniformity of the photoresist layer is absolutely critical. The subsequent lithography exposure step relies on the depth-of-focus and illumination dose to expose the photoresist, and ensure proper dimensions after developing the photoresist. And, of course, any material or particulate defects in the photoresist are local yield detractors.

The team at GLOBALFOUNDRIES focused on how to improve process control for the applied photoresist coat, inspected after the develop step.

Photoresist Layer Issues

There are several potential issues associated with the photoresist layer coat:

“short” coverage (the wafer circumference is inadequately coated)
“comet” streaking (often due to a surface contaminant)
poor coverage at edges of the wafer
“drip” issues (due to nozzle dispense irregularities)
“splatter”

The photoresist dispensing nozzle may need cleaning or replacement, the spinner may need (preventive) maintenance, or a “bad batch” of photoresist may have been received from the chemical supplier. The emergence of an issue needs to be detected as quickly as possible – such as, during post-develop inspection – before any subsequent process steps. After the issue has been identified, and corrective actions taken, the photoresist layer can be readily stripped off and the coating step re-run, saving the work-in-progress (WIP) wafer lot.

Machine Learning and improved Photoresist Coating Defect Reduction

The difficulty associated with quality control inspection of the photoresist layer is that the thickness uniformity requirements are extremely stringent. For example, the image below highlights an area on the wafer that is out-of-spec, but imperceptible to visual inspection.

The GLOBALFOUNDRIES team pursued a machine learning approach to classification of the inspected wafer images. Due to the very slight local differences in image color/contrast, the images were first subjected to adaptations. Color hue + saturation balance adjustments were applied; subsequently, (strong) RGB equalization enhances the image contrast.

The figures below illustrate the result of these image processing steps – the top figure shows the enhanced image of the original wafer map above.

As with any machine learning model development, the GLOBALFOUNDRIES team prepared a (pre-classified) training and testing set of images, and refined the model to achieve a very high GOOD/BAD classification match result, as depicted in the flowchart below.

The figure below illustrates the various inspection issues, with enhanced image examples for each classification.

The figure below depicts the improvement in the “splatter” defect data, as this machine learning-based inspection model has been deployed in production – a 30X reduction in splatter photoresist defect impact. Wow.

As exemplified by this example at GLOBALFOUNDRIES, the application of machine learning technology to improve semiconductor fabrication process control offers considerable potential for yield and quality improvement.

-chipguy

References

[1] McLaughlin, M., et al., “Enhanced Defect Detection in After Develop Inspection with Machine Learning Disposition”, ASMC 2021, paper 8.1.

Also Read:

Foundry Fantasy- Deja Vu or IDM 2?

A Perfect Storm for GLOBALFOUNDRIES

Technology Optimization for Magnetoresistive RAM (STT-MRAM)

May 25, 2021April 15, 2022

Avery Levels Up, Starting with CXL

Avery Levels Up, Starting with CXL
by Bernard Murphy on 05-25-2021 at 6:00 am
Categories: Avery Design Systems, IP

Let me acknowledge up front that Avery isn’t the most visible EDA company around. If you know of them, you probably know their X-propagation simulator. Widely respected and used, satisfying a specialized need. They have also been quietly building over the years a stable of VIPs and happy customers, with a special focus on VIPs for PCIe and standards building on PCIe such as NVMe, CXL and CCIX. All hot standards in datacenters. Avery claims, and I have no reason to doubt them, that they are the #1 provider of VIPs in this area.

OK, good for them, they’re now active in a bigger market with more product range. But what caught my attention is what they are offering around CXL. First, I need to explain why this is important.

The off-chip cache coherence war

For those of you who don’t know, CXL and CCIX are off-chip/off-die cache-coherent interfaces. In some applications, particularly in machine learning, designs have become so big that they must split across multiple die/chips. Accelerators, memory and administration spread across multiple die. Yet applications still require the system as a whole to have a common logical view of memory. Which, since those memory accesses are mediated by caches, means they must be cache coherent. This problem has been solved on-chip through for example the ARM CCI network and the Arteris IP Ncore NoC. But those only work on-chip. CXL and CCIX extend from these networks to interconnect between chips/die. Intel is behind CXL, while AMD, ARM and several others are behind CCIX.

A new standards war, but what is important here is that, as I mentioned earlier, these standards are exceptionally important in datacenters. Particularly to the hyperscalars. And they’re still very new standards.

Avery CXL – more than a VIP

All of which means that compliance testing becomes very important. Against emerging/evolving standards. This takes a bit more than just VIPs, especially for cache coherence checking which must run through extensive testing. So Avery stepped up. They have built a virtual host co-simulation platform, around a CXL-aware QEMU emulator running Linux and connecting to a simulation (or emulation or prototyping platform) running the DUT. Avery’s CXL VIP sits inside the DUT testbench and connects to the QEMU host. Particularly notable here is that the VIP (and the QEMU host and Linux kernel with latest Intel patches for CXL) is ready to run type-3 designs, ahead of availability of processor silicon supporting that release.

This is arranged so the QEMU host looks like an Intel motherboard CXL host system. Meaning that a design team can validate against this setup. With high confidence that what they will build will work against real boards once those become available. In particular, they can run compliance tools and tests suites, such as CXLCV. And they can run performance benchmarking applications such as FIO and PCMark8.

Avery is contributing to the Intel QEMU/SystemC branch with a number of extensions in support of this capability. You might expect to see such a solution in compliance labs, especially since Avery is an early CXL Consortium member. And you probably wouldn’t be wrong.

And it’s more than CXL

Unsurprisingly, Avery also supports this path for PCIe host communication. They’ve recently been working with the University of New Hampshire Interoperability Lab and an industry leading NVMe SSD vendor on NVMe SSD validation using the UNH-IOL INTERACT^TM test software. Plus other performance benchmarking applications such as FIO, PMark8, and CrystalDiskMark. Each of these comes which their own compliance tools you can run on the host side to model real traffic and testing against your DUT. The same QEMU co-sim idea also works for embedded processor side and supports Arm targets and AMBA bus communication.

Avery is now enabling more comprehensive validation of standards important to the hyperscalars and the companies who serve those giants. Leveling up indeed. You can learn more HERE.

Also Read:

Data Processing Unit (DPU) uses Verification IP (VIP) for PCI Express

PCIe 6.0, LPDDR5, HBM2E and HBM3 Speed Adapters to FPGA Prototyping Solutions

Controlling the Automotive Network – CAN and TSN Update

May 24, 2021September 30, 2021

Safety Architecture Verification, ISO 26262

Safety Architecture Verification, ISO 26262
by Daniel Payne on 05-24-2021 at 10:00 am
Categories: EDA, Siemens EDA

I love to read articles about autonomous vehicles and the eventual goal of reaching level 5, Full Automation, mostly because of the daunting engineering challenges in achieving this feat and all of the technology used in the process. The auto industry already has a defined safety requirements standard called ISO 26262, and one of the questions that must be answered as part of the safety architecture is, “Do random failures violate any safety requirement?”

IC designers and test engineers have been aware of random failures in their semiconductor chips ever since the beginning, so over the decades have developed Design For Test (DFT) techniques like full scan design, and then adding tools like Automatic Test Pattern Generation (ATPG) to stimulate a fault, and then propagate that fault to an observable output pin. For automotive safety verification the approach is to:

Inject a random fault
Propagate the fault
Check if safety mechanisms catch the fault
Classify the fault
Generate safety metrics

Siemens EDA has been in the DFT business for decades now, and they have extended that experience into the ISO 26262 realm, so I read a white paper from Jacob Wiltgen for a deep dive into the concept of fault campaigns.

Huge Number of Fault States

A simple two input logic gate can have three fault injection sites, but then consider that a modern SoC likely has a million+ gates, and that fault models can be both stuck-at and transient faults, so that’s a large fault state space.

The Automotive Safety Integrity Level (ASIL) has defined levels A through D, where D is the highest, and fault injection is highly recommended to meet ISO26262 requirements.

Functional Simulators

Every design engineer has easy access to a functional simulator, and for small blocks, sure, you could manually choose to inject faults, then verify the effects of that fault, but it would be too time consuming, so not viable.

Fault Injection Platform

Beyond functional simulators, there are now four helpful methods to inject faults and analyze the results:

Formal Analysis
Fault Simulator
Fault HW Emulator
Fault Prototype Board

With Formal Analysis you get the benefits of an exhaustive approach on smaller blocks where a fault classification proof is needed, while not requiring a test bench, but you need some formal experience.

For higher capacity than Formal Analysis consider using a Fault Simulator, and it does require a test bench where the efficiency depends on how good your stimulus is.

The highest capacity is achieved with a Fault Emulation method, and you can run software test libraries too.

OK, we have these four distinct ways of doing fault injection, but how do I create the shortest fault campaign? It all starts with a written plan, detailing which approach will be applied to each block or module in a system, the total number of faults to be tested, etc. Consider using the following table to help you sort out the different Design Profiles of your system: Digital IC, Digital IP, Mixed Signal, Analog IP.

A second way to decide which tool to use for fault injection is by the Safety Feature: Digital HW, Software, LBIST/MBIST, Analog HW.

Fault Injection Methodology

Start with your fault list generation, then run the fault injection tool, and finally the work product is generated as a Failure Modes, Effects and Diagnostic Analysis (FMEDA) report. A FMEDA will describe the failure modes, and safety metrics calculated using fault classifications spotted during the fault injection.

Fault List Generation

You determine if each fault in the fault list is safety critical or not. The flow for creating the fault list with the chosen safety architecture is:

Fault Injection

When a fault is injected and propagated, can we see the effects and does that infringe a safety goal or a safety requirement? Can the fault be detected by some safety mechanism?

A fault that infringes a safety goal or requirement are called Observed, while faults that can be detected by some safety mechanism are called Detected, so we get four fault classifications:

Each of the four injection methods are used, then the results get merged into a single list of fault classifications.

Work Product Generation

In the ISO 26262 standard there are three safety metrics that need to be calculated for your safety architecture:

Single Point Fault Metric (SPFM)
Latent Fault Metric (LFM)
Probabilistic Metric for Hardware Failure (PMHF)

Equations for each:

The five FMEDA safety metrics are:

Failure In Time (FIT)
Single Point Fault Metric (SPFM)
Latent Fault Metric (LFM)
Probabilistic Metric for Hardware Failure (PMHF)
Diagnostic Coverage (DC)

Summary

The safety architecture and ISO 26262 requirements for preventing random failures from becoming safety violations is a tough problem to solve, yet it can be done with the multi-prong approach developed by Siemens EDA over the years. Yes, there were lots of acronyms introduced in this blog, and the complete 14 page White Paper has even more details to bring you up to speed on designing and verifying automotive ICs that conform to safety standards.

Related Blogs

May 24, 2021March 25, 2022

WEBINAR: What Makes SoC Compiler The Shortest Path from SoC Design Specification to Logic Synthesis?

WEBINAR: What Makes SoC Compiler The Shortest Path from SoC Design Specification to Logic Synthesis?
by Daniel Nenni on 05-24-2021 at 6:00 am
Categories: Defacto Technologies, EDA, Events

Defacto SoC Compiler whose 9.0 release was announced recently automates the SoC design creation from the first project specifications. It covers register handling, IP and connectivity insertion at RTL, UPF and SDC file generation right to logic synthesis. As part of the generation process of RTL and design collaterals, basic advanced editing and refactoring are made automated which is a major step forward for RTL design engineers and SoC architects. Indeed, design structural changes which are automated by SoC Compiler have a multi-domain awareness: physical, power, clocking and DFT.

Towards domain awareness during the front-end SoC design process, a user has access to exploration, coherency checks, linting and view generation capabilities.

As a typical example, power awareness includes UPF linting, UPF & RTL design exploration and coherency checks, UPF file generation and UPF promotion or demotion capabilities for a top-level generation or a hierarchical UPF file extraction, respectively.

SoC Compiler can be used at different steps from user specification to logic synthesis.

Step1: Extraction, generation & update of power intent files

To manage power intent requirements a user can start by generating UPF files either from scratch or by extracting necessary files from previous projects databases. UPF updates are also automated by SoC Compiler whenever a change happens in an RTL or a gate-level description.

Step 2: Exploration, linting & coherency checks

Any generated UPF is automatically checked through design exploration capabilities and coherency checks between RTL, liberty and UPF files.

Step 3: Integration/Promotion

During SoC design assembly, UPF files are automatically promoted in conjunction with RTL files and all related files are generated, ready for synthesis.

The above automated steps for power intent management are also taken into consideration by SoC Compiler for other domains as well. The provided APIs, Python, TCL or C++ make the solution particularly easy to use, open and ready to be plugged in within internal design flows.

SoC Compiler is adopted by major SoC chip companies and recommended by top IP core providers for IP integration.

Defacto experts are hosting a LIVE webinar on June 3rd 10-11am PDT (REGISTER HERE) in which typical cases such as System Integration, RTL Integration and Power Integration will be presented.

About Defacto
Defacto Technologies is an innovative chip design software company providing breakthrough RTL platforms to enhance integration, verification and Signoff of IP cores and System on Chips. New segment markets such as automotive, mobile, virtual reality and artificial intelligence require leading edge SoCs with greater functionality, higher performance and much lower consumption.

Meeting time-to-market requirements and lowering the overall cost including design steps is becoming a critical factor of success. By adopting Defacto’s SoC Compiler design solutions, major semiconductor companies are continuously moving from traditional and painful SoC design tasks to the Defacto’s joint “Build & Signoff” design methodology. The related ROI has been proven for hundreds of projects.

Also Read

Small EDA Company with Something New: SoC Compiler

CEO Interview: Dr. Chouki Aktouf of Defacto

Power in Test at RTL Defacto Shows the Way