100X800 Banner (1)
Semiconductor Expert Forum

Podcast EP200: Dan and Mike’s Top Ten List For the Semiconductor Industry

Podcast EP200: Dan and Mike’s Top Ten List For the Semiconductor Industry
by Daniel Nenni on 12-29-2023 at 10:00 am

Dan is joined by podcast producer and collaborator Mike Gianfagna for Semiconductor Insiders episode 200. Dan and Mike look over the past two years (and 200 podcasts) to develop a top ten list of changes and innovation in the semiconductor industry. There is a lot of back-story detail on each topic in this far-reaching discussion.

The topics discussed are:

Dan: Innovation and advances at TSMC, Intel, and SMIC, changes in the automotive industry, and the RISC-V movement.

Mike: Semiconductors becoming a household word, the explosion of AI, the impact of AI on chip design, and the CEO change at Synopsys.

The views, thoughts, and opinions expressed in these podcasts belong solely to the speaker, and not to the speaker’s employer, organization, committee or any other group or individual.

Posted on

The Transformation Model for IP-Centric Design

The Transformation Model for IP-Centric Design
by Kalar Rajendiran on 12-29-2023 at 6:00 am
Categories: EDA, Perforce

HelixIPLM Accelerate Semiconductor Development with IP Centric Design

Semiconductor designs have been progressing over time to address wider product varieties and designs with increasing complexity. Organizations have been addressing intense time-to-market pressures by leveraging globally dispersed team resources. The project-centric design methodology, which once worked well with smaller projects and longer timelines is struggling to meet the demands of the modern semiconductor landscape. It creates isolated silos, discourages reuse, and fuels redundancies. Traceability becomes very difficult at best, and global collaboration strains under the weight of manual coordination and disparate data management systems. Mistakes and design gaps have become prohibitively expensive, and the global distribution of design teams presents new complexities, especially with dynamic geopolitical realities.

More efficient design practices are needed to achieve ambitious goals while controlling costs and meeting time-to-market demands. One promising solution is the IP-Centric Design approach.

IP-Centric Design: A Paradigm Shift

An IP-Centric Design approach reframes the entire design process, placing reusable intellectual property (IP) blocks at the heart of the development cycle. These pre-verified, optimized modules become the building blocks of new chips, fostering a host of benefits. Re-purposing proven IP allows design teams to leapfrog past repetitive tasks and costly respins, propelling them ahead of the competition. A centralized repository of IP fosters seamless collaboration and end-to-end project tracking, streamlining workflows and ensuring accountability. Pre-optimized IP guarantees reliability and performance, translating into robust, dependable products that consumers trust. IP-Centric Design is inherently scalable, effortlessly adapting to accommodate ever-growing design footprints and larger product portfolios.

A Roadmap for IP-Centric Design

To switch from project-centric design methodology to IP-Centric Design methodology will not happen overnight. Transitioning to IP-Centric Design is not without its challenges. It’s a mindset shift, not merely a methodology change. Legacy systems, ingrained habits, and cultural resistance may pose initial hurdles. Different teams may have varying levels of maturity in specific areas, and implementing the model requires careful planning and organizational buy-in.

Perforce has published a whitepaper presenting a Transformation Model that provides a blueprint for organizations to navigate this journey. The Model describes five key levels of transformation that organizations have to undergo in order to successfully achieve IP-Centric Design methodology.

Level One: Embracing IP-Centric Design

Design blocks are modeled as intellectual properties (IPs), each with a list of dependencies. This creates a versionable, hierarchical model of the design outside regular data management tools. The definition of IP broadens, encompassing not only pre-packaged design blocks from third-party providers but any block in the design, including those specific to a project, shared between projects, or delivered by central teams.

Level Two: Discovery & Reuse

The modeled IPs, independent of underlying data management, evolve into a dynamic catalog. The catalog allows users to search, filter, and comprehend available IPs based on metadata, irrespective of their location and content. This leads to seamless IP discovery and standardizes project configuration, embedding traceability into the design process. Teams can now make informed build-vs-buy decisions, fostering a culture of reuse that streamlines design efforts.

Level Three: Enterprise Development at Scale

Level Three addresses the challenge of scaling the system to meet the needs of a widespread community of users around the globe. The system must be architected for horizontal scaling, allowing teams to add hardware resources as the team and user numbers grow. Local or near-local response times are critical for effective IP discovery and reuse, especially as different teams collaborate across projects and design centers.

Level Four: Built-In Traceability

The central system becomes the single source of all data and metadata pertaining to designs. Users and workflows can find any design data and metadata they need, ensuring full traceability. This level is crucial for industries governed by standards, where compliance requires proof and provenance of designs. Effective integrations at this level enable organizations to confirm adherence to standards like ISO 26262, ITAR, or CFR21.

Level Five: Planning at Platform Scope

The highest level of IP-Centric Design involves modeling all components of a platform in a unified system. It goes beyond tracking work-in-progress to provide a platform for planning projects and anticipating upcoming needs. This level enables users across the enterprise to view existing IPs and plans for IPs in progress, fostering collaboration, influencing designs, and streamlining efforts across design teams.

Summary

The Transformation Model for IP-Centric Design emerges as a strategic blueprint for success to overcome the challenges of exponential complexity, global collaboration, and intense time-to-market pressures. The journey to IP-Centric Design may seem daunting, but the rewards are undeniable. By taking the first step and partnering with trusted solution providers, organizations can navigate this journey and unlock the full potential. Perforce offers semiconductor solutions that provide the foundation, structure, and scalability necessary for successful implementation. Visit the product page.

Organizations leveraging Perforce can expect improved collaboration, accelerated design cycles, informed build-vs-buy decisions, and streamlined efforts across design teams. Click here to request information.

Also Read:

Chiplets and IP and the Trust Problem

Insights into DevOps Trends in Hardware Design

IP Lifecycle Management for Chiplet-Based SoCs

Posted on

Achieving a Unified Electrical/Mechanical PCB Design Flow – The Siemens Digital Industries Software View

Achieving a Unified Electrical/Mechanical PCB Design Flow – The Siemens Digital Industries Software View
by Mike Gianfagna on 12-28-2023 at 10:00 am
Categories: EDA, Siemens EDA

Achieving a Unified Electrical:Mechanical PCB Design Flow – The Siemens Digital Industries Software View

Let’s face it, designs are getting harder, much harder. Gone are the days when the electrical and mechanical design of a system occurred separately. Maybe ten years ago this practice was acceptable. Once the electrical design was completed (either the chip or the board) the parameters associated with the design were then given to the package or PCB design team to implement the physical delivery of the design. The handoff was done once, and each team lived in its own world. Those days are gone. In current day design complexity, the electrical design impacts the mechanical design in subtle ways. Similarly, the mechanical design of the system, including things like choice of materials has a profound impact on what is possible electrically. One must break down the walls and collaborate continuously, or accept the likelihood of project overruns and failure.  A comprehensive and informative white paper was recently published on this topic for PCB design. Read on to understand achieving a unified electrical/mechanical PCB design flow – The Siemens Digital Industries Software view.

Why Now?

Entitled Unifying ECAD-MCAD PCB design through collaborative best practices, the Siemens white paper begins by setting the stage for why a unified PCB design flow is so important now. Most SemiWiki readers will be familiar with this trend. The overall demands for PCB design have also been discussed in detail in this SemiWiki post.  The new Siemens white paper cites four trends in electronic design that are making a unified flow so urgent:

Compute power: Since the advent of the microprocessor, there’s been an astronomical increase in the compute power that chips can deliver – a trillion-fold over six decades. Given the slowing of Moore’s Law, future performance gains in semiconductors will be driven by, among other factors, advanced packaging flows.

Engineering discipline convergence: The “smaller, denser, faster” mantra associated with today’s products is magnifying the importance of ensuring that electromechanical compatibility is addressed prior to the first fabrication – waiting until manufacture to validate electronic and mechanical compatibility is clearly leaving things until too late.

Sustainability: The environmental impact of the manufacture of electronic devices is starting to get more scrutiny, as is the worldwide energy consumption of devices during their working life. This one is quite important to Siemens.

AI in electronics design: The fourth trend is the rise of AI in electronics design. AI might be considered a product of electronics, yet AI can also help with electronics design.

The white paper goes into a lot more detail on these topics. Links are coming so you can see the whole picture, as well as learn more about the Siemens approach.

What’s Needed?

The white paper covers a lot of ground. Here are some of the topics that are examined:

The importance of ECAD-MCAD collaboration: An integrated ECAD/MCAD collaboration environment enables electrical and mechanical design teams to work together throughout the entire design process in real time. And this can spell the margin of victory for a complex design project. The specific benefits of a well-integrated approach are discussed.

Ways ECAD-MCAD collaboration can be improved: A lot of engineering development teams still struggle to break free of legacy practices, which were perfectly good in their day but fall short in the present day. Specific approaches to improving the process are discussed.

A multi discipline, multi domain workflow supporting real time collaboration

Keys to successful ECAD-MCAD collaboration: Efficient collaboration between ECAD and MCAD domains enables both to optimize an electronics design within tight form-factor constraints while still meeting quality, reliability, and performance requirements. In this section, specific approaches to design methodology and data sharing are presented. The goal is a multi-discipline, multi-domain workflow that supports real-time collaboration, as illustrated in the figure.

A toolkit for collaborative engineering: Now that some of the reasons collaboration is so important and some of the obstacles to its adoption have been discussed, this section looks at the solutions available to support ECAD- MCAD collaboration.

Accelerating PCB design: The Siemens Xcelerator business platform ecosystem is presented, with details of scope, capabilities, and benefits for design teams worldwide.

To Learn More

If you’re involved in complex system design this white paper is a must read. You can access the full text here.  There is also a great podcast from the authors of the white paper available here.  You can now learn about achieving a unified electrical/mechanical PCB design flow – The Siemens Digital Industries Software view.

Posted on

Will Chiplet Adoption Mimic IP Adoption?

Will Chiplet Adoption Mimic IP Adoption?
by Eric Esteve on 12-28-2023 at 6:00 am
Categories: Alphawave Semi, Chiplet, IP, IPnest
2 Comments

Adoption theory

If we look at the semiconductor industry expansion during the last 25 years, adoption of design IP in every application appears to be one of the major factors of success, with silicon technology incredible development by a x100 factor, from 250nm in 2018 to 3nm (if not 2nm) in 2023. We foresee the move to chiplet-based architecture to soon play the same role that SoC chip-based architecture and massive use of design IP has played in the 2000’s.

The question is how to precisely predict chiplet adoption timeframe and what will be the key enablers for this revolution. We will see if diffusion of innovation theory can be helpful to fine-tune a prediction, determine what type of application will be the driver. Chip-to-chip interconnect protocol standard specifications allowing fast industry adoption, driving applications like IA or smartphone application processor quickly seems to be the top enabler, but EDA tools efficiency or packaging new technologies and dedicated fab creation, among others, are certainly key.

Introduction: emergence of chiplet technology

During the 2010-decade, the benefits of Moore’s law began to fall apart. Moore’s law stated transistor density doubled every two years, the cost of compute would shrink by a corresponding 50%. The change in Moore’s law is due to increased in design complexity the evolution of transistor structure from planar devices, to Finfets. Finfets need multiple patterning for lithography to achieve devices dimensions to below 20-nm nodes.

At the end of this decade, computing needs have exploded, mostly due to proliferation of datacenters and due to the amount of data being generated and processed. In fact, adoption of Artificial Intelligence (AI) and techniques like Machine Learning (ML) are now used to process ever-increasing data and has led to servers significantly increasing their compute capacity. Servers have added many more CPU cores, have integrated larger GPUs used exclusively for ML, no longer used for graphics, and have embedded custom ASIC AI accelerators or complementary, FPGA based AI processing. Early AI chip designs were implemented using larger monolithic SoCs, some of them reaching the size limit imposed by the reticle, about 700mm2.

At this point, disaggregation into a smaller SoC plus various compute and IO chiplets appears to be the right solution. Several chip makers, like Intel, AMD or Xilinx have select this option for products going into production. In the excellent white paper from The Linley Group, “Chiplets Gain Rapid Adoption: Why Big Chips Are Getting Small”, it was shown that this option leads to better costs compared to monolithic SoCs, due to the yield impact of larger. These chip makers have designed homogenous chiplet, but the emergence and adoption of interconnect standard like Universal Chiplet Interconnect Express (UCIe) IP is easing adoption of heterogeneous chiplet.

The evolution of the newer, faster, protocol standards is picking up speed as the industry keeps asking for higher performance. Unfortunately, the various standards are not synchronized by a single organization. New PCIe standards can come one year (or more) earlier or later than the new Ethernet protocol standard. Using heterogeneous integration allows silicon providers to adapt to the fast-changing market by changing the design of the relevant chiplet only. Considering advanced SoC design fabrication requires massive capital expenditures for 5nm, 4nm or 3nm process nodes, the impact of chiplet architectures is tremendous to drive future innovation in the semiconductor space.

Heterogeneous chiplet design allows us to target different applications or market segments by modifying or adding just the relevant chiplets while keeping the rest of the system unchanged. New developments could be launched quicker to the market, with significantly lower investment, as redesign will only impact the package substrate used to house the chiplets. For example, the compute chiplet can be redesigned from TSMC 5nm to TSMC 3nm to integrate larger L1 cache or higher performing CPU or number of CPU cores, while keeping the rest of the system unchanged. Chiplet integrating SerDes can be redesigned for faster rates on new process nodes offering more IO bandwidth for better market positioning.

Using heterogeneous chiplet will offer better Time-to-Market (TTM) when updating system, reusing the part of system with no change if it’s designed in chiplet. This will also be a way to minimize cost when keeping some functional chiplet on less advanced nodes, cheaper than the most advanced. But the main question is to forecast when the chiplet technology will create a significant segment of the semiconductor market? We will review the IP adoption history as chiplet and IP are similar, both have to break the NIH syndrome to become successful. We will extract the main causes of chiplet adoption and build a forecast, using the innovation theory and the defined category (Innovators, Early Adopters, etc. see Figure below).

Figure 1: Innovation Theory (Reminder)

We will review ARM CPU IP adoption through 1991 to 2018 and IP adoption history through 1995 to 2027, and check how this adoption rate stick with the Innovation Theory.

We will explain why chiplet adoption will be boosted, reviewing the technology and marketing related reasons:

  • From IP-based SoC to chiplet-based system
  • Interoperability, thanks to chiplet interconnect preferred protocol standard
  • Explaining why high-end Interface IP are key for Chiplet adoption
  • Design-related challenges to solve.
  • Last but not least, investment made by foundry

Finally, we can build a tentative chiplet adoption forecast, based on innovation theory. Just to mention, the industry just moved in the “Early adopters” phase, seeing numerous IP and chiplet vendors serving HPC and AI.

If you download the white paper, you will enjoy with all the text, and numerous pictures, some of them beeing created exclusively for this work.

By Eric Esteve (PhD.) Analyst, Owner IPnest

Alphawave sponsored the creation of this white paper, but the opinions and analysis are those of the author. Article can be found here:

https://awavesemi.com/resource/will-chiplet-adoption-to-mimic-ip-adoption/

Also Read:

Unleashing the 1.6T Ecosystem: Alphawave Semi’s 200G Interconnect Technologies for Powering AI Data Infrastructure

Disaggregated Systems: Enabling Computing with UCIe Interconnect and Chiplets-Based Design

Interface IP in 2022: 22% YoY growth still data-centric driven

Posted on

Fail-Safe Electronics For Automotive

Fail-Safe Electronics For Automotive
by Kalar Rajendiran on 12-27-2023 at 10:00 am
Categories: AI, Analytics, Automotive, IP, proteanTecs
1 Comment

MegaTrends Driving the Need for Next Generation Silicon Capabilites

The automotive industry is on the brink of a revolutionary transformation, where predictive maintenance and monitoring are taking center stage. In a recent webinar panel session, industry experts delved into the challenges, current approaches, and future innovations surrounding the guarantee and extension of mission profiles.

proteanTecs hosted that webinar with the following experts as panelists:

Heinz Wagensonner, Sr. SoC Designer, CARIAD (software division of Volkswagen Group)

Jens Rosenbusch, Sr. Principal Engineer, SoC Safety Architecture, Infineon Technologies,

Xiankun “Robert” Jin, Automotive SoC Safety Architect, NXP Semiconductors.

Gal Carmel, Executive VP, GM, Automotive, proteanTecs.

Ellen Carey, Chief External Affairs Officer, Circulor, moderated the panel session.

The key themes that emerged were the increasing reliance on artificial intelligence (AI), the importance of real-time monitoring, and the need for a paradigm shift in industry thinking. The following are the salient points that came out of that panel session. You can access that entire panel session on-demand from here.

Current Challenges

The conversation began by acknowledging the challenges faced by the automotive sector. For instance, the introduction of a Central Gateway controller connected to the cloud for extended periods poses challenges for reliability and safety. Traditionally, managing uncertainties involved building margins into design, fabrication, and testing processes. However, this approach may become unsustainable in the future.

Current Approaches

To address these challenges, the industry is shifting towards a more proactive and predictive maintenance approach. Rather than relying solely on built-in margins, the emphasis is on implementing health monitors or sensors that continually assess the device’s status. This data is aggregated and analyzed, potentially through machine learning, providing insights that were previously inaccessible. This newfound understanding enables decisions such as swapping devices before imminent failure, a concept known as predictive maintenance.

Collaboration and Standardization

The transition to predictive maintenance is not a journey undertaken by individual companies but requires collaborative efforts within the automotive industry. One significant initiative mentioned during the panel session is the creation of a framework for automotive predictive maintenance. A technical report, TR 9839, was published during the past summer, paving the way for the Third Edition of ISO 26262 standard. This collaborative approach involves stakeholders, including semiconductor vendors, original equipment manufacturers (OEMs), and regulatory bodies.

The Role of AI in Predictive Maintenance

The integration of AI emerged as a crucial factor in revolutionizing predictive maintenance. AI’s ability to analyze vast datasets and identify patterns that may elude human observers makes it a valuable tool for predicting failures. Whether optimizing production processes or analyzing failures in the field, AI plays a pivotal role in enhancing efficiency and accuracy.

AI is not just about finding known issues but uncovering latent defects or anomalies that may lead to failures. The application of AI in the analysis of sensor data from millions of vehicles in a fleet opens up possibilities for early detection of potential failures. However, the discussion also highlighted the importance of standardizing AI applications to ensure accuracy and reliability.

On-Chip Monitoring for Real-Time Insights

A critical aspect of transforming automotive maintenance is the adoption of on-chip monitoring. The traditional process of failure analysis, involving sending faulty components back for analysis, was deemed slow and inefficient. On-chip monitoring, if implemented effectively, can provide real-time insights into the behavior of silicon while the vehicle is in operation.

The Future Landscape

As the automotive industry moves towards autonomy and increased connectivity, the need for a flexible and adaptive approach to maintenance becomes paramount. The speakers emphasized a change in thinking, where a cross-platform, data-driven approach is embraced. This involves creating a common language, pooling insights, and utilizing a combination of hardware mechanisms and software analytics to drive proactive maintenance.

Summary

The panel session highlighted the industry’s dynamic shift from reactive to proactive maintenance strategies. The integration of AI and on-chip monitoring represents a leap forward in enhancing reliability, reducing costs, and improving overall product quality. Collaboration among industry stakeholders, standardization efforts, and a change in thinking towards a vertical approach will be key in shaping the future of automotive maintenance. As the industry navigates this transformative journey, the focus remains on leveraging technology to ensure vehicles not only meet but exceed reliability and safety standards.

You can listen to the entire panel session here.

Also Read:

Building Reliability into Advanced Automotive Electronics

Unlocking the Power of Data: Enabling a Safer Future for Automotive Systems

proteanTecs On-Chip Monitoring and Deep Data Analytics System

Posted on

Information Flow Tracking at RTL. Innovation in Verification

Information Flow Tracking at RTL. Innovation in Verification
by Bernard Murphy on 12-27-2023 at 6:00 am
Categories: Cadence, EDA, Security

Innovation New

Explicit and implicit sneak paths to leak or compromise information continue to represent a threat to security. This paper looks a refinement of existing gate level information flow tracking (IFT) techniques extended to RTL, encouraging early-stage security optimization. Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, entrepreneur, former Synopsys CTO and now Silvaco CTO) and I continue our series on research ideas. As always, feedback welcome.

The Innovation

This month’s pick is Register Transfer Level Information Flow Tracking for Provably Secure Hardware Design. This article appeared at DATE 2017 and has gathered an impressive 53 citations. The authors are from the University of California San Diego.

This group earlier developed gate-level IFT (GLIFT) technology, launching as a product under Tortuga Logic (later rebranded as Cycuity). Information flow techniques offer a more general and formal approach to modeling and reasoning about security properties than testing by vulnerability use-cases. The method generalizes by propagating taint information alongside regular logic evaluation, flagging say a signal sourced from an insecure domain controlling a condition selection in a secure domain. Combining this with formal verification methods offers potential for strong security guarantees.

Extending analysis to RTL enable several improvements: scalability to larger circuits, application earlier in design and a somewhat improved understanding of higher-level dependencies in design intent without need for user-supplied annotations. The authors also describe a method by which designers can tradeoff between security and verification performance in serving differing market needs.

Paul’s view

Security verification is something I care about deeply – we can’t trust digital data without it, and this includes my own personal data! This month’s paper is an easy read highlighting one of the mainstream techniques in security verification: adding “tainted” (i.e. compromised or no longer trusted) bits to all signals in a design and enhancing gate models propagate tainted bits through gates as well as signal values.

Tainted bit propagation is conceptually almost identical to “X-propagation” in mainstream design verification flows: if a signal is tainted then it’s as if we don’t know its value since we don’t trust the value it has.

This paper proposes two things: first, doing tainted bit annotation and propagation at the RTL level rather than the gate level; and second, doing the equivalent of what mainstream EDA tools call “X-pessimism removal”. The latter refers to not marking the result of an operator as X simply because at least one of its inputs is X, but rather to mark it as X only if it truly is X based on the definition of that operator. For example, consider c = a & b. If a=0 then c=0 even if b is X. Equivalently, in security verification speak, if a=0 and a is not tainted, then c=0 and is not tainted even if b is tainted. Seems easy for “&”, gets a bit more tricky for if, else and case constructs.

As you can expect, the paper concludes with some benchmarking that clearly shows propagating tainted bits at RTL is much faster than at gate-level, and that “precise” tainted-bit propagation (i.e. tainted-bit pessimism removal) reduces the false positive rate for tainted-bits at design outputs by a significant %. All this benchmarking is done in a formal proof context, not a logic simulation context. Case closed.

Wish you all a Happy Holidays!

Raúl’s view

Information Flow Tracking (IFT) is a computer security technique which models how information propagates as a system computes. It was introduced back in the 70’s by Denning, a good introduction and survey can be found here. The basic idea is to label data with a security class and then track these labels as the data is used for computations. For the purposes of the reviewed paper, the label is just a bit indicating data is “taint” (label=1, untrusted).  The most conservative approach in using this label, is that the output of any operation involving taint data is taint; or said inversely, only operations with all input data being not taint yield a not taint output. The paper relaxes this approach somehow as I’ll explain later.

Computer security aims at maintaining information confidentiality and integrity. Confidentiality means that information is only disclosed to authorized entities. IFT verifies if secret information can ever be disclosed by tracking that all locations it flows to are also secret (not taint), e.g., a secret key does not leak outside a restricted memory space. Integrity is the inverse: to maintain the accuracy and consistency of data, untrusted entities are not allowed to operate on trusted information. How information flows throughout a computing system is crucial to determine confidentiality and integrity. IFT is among the most used techniques for modeling and reasoning about security.

The paper reviews existing IFT approaches at the gate level and RTL level. At the gate level reconvergence is a source of imprecision. In a multiplexer a taint select signal will yield a taint output even if both inputs are not taint. Modeling a multiplexer at the RTL level allows to fix this. Existing RTL level approaches involve the need of modifying the RTL code. The system implemented by the authors, RTLIFT, fixes both above shortcomings. It provides a library of RTL operators which allows to implement different approaches to IFT such at tainting outputs if any input is taint (conservative) or a more nuanced approach such as tainting outputs for a multiplexer only if one of the data inputs is taint (avoids false positives). It also provides an automatic translation of an RTL design in Verilog to an IFT-enhanced version which can be used for verification purposes.

The results on cryptographic cores show RTLIFT to be about 5 times faster than gate-level IFT (GLIFT). On a collection of 8 adders, multipliers, and control path logic, RTLIFT shows a 5%-37% decrease in false positives (false taint) over GLIFT for a simulation of 220 random input samples.

A comprehensive paper on security, that extends IFT to RTL, a very enjoyable read!

Also Read:

ML-Guided Model Abstraction. Innovation in Verification

Cadence Integrates Power Integrity Analysis and Fix into Design

Accelerating Development for Audio and Vision AI Pipelines

Posted on

Making UVM faster through a new configuration system

Making UVM faster through a new configuration system
by Daniel Payne on 12-26-2023 at 10:00 am
Categories: EDA, Siemens EDA

Elapsed Time min

The Universal Verification Methodology (UVM) is a popular way to help verify SystemVerilog designs, and it includes a configuration system that unfortunately has some speed and usage issues. Rich Edelman from Siemens EDA wrote a detailed 20-page paper on the topic of how to avoid these issues, and I’ve gone through it to summarize the highlights for you. Verification engineers use a UVM configuration database to set values, then to get the values later in their UVM test. One example of setting and getting a value ‘T’ is:

uvm_config#(T)::set(scope, instance_path_name, field_name, value);

uvm_config#(T)::get(scope, instance_path_name, field_name, value);

Connecting the UVM testbench to the device under test uses the configuration database to pass the virtual interfaces. There are three problems with using the UVM configuration:

  • Big code, some 2,600 lines of code
  • Requires exact type matching, so ‘int’ and ‘bit’ are not the same
  • Slow code

Consider the case of slow code, because with thousands of calls to set() using names with wildcards can take up to 30 minutes to complete the ‘set’ and ‘get’ phase.

Rich proposes a new solution to UVM configurations that has much faster speeds, taking only a few seconds in comparison.

If your UVM code avoids using wildcards and has few ‘set’ commands, then your code will run faster.

Possible solutions to the UVM configuration issues are:

  • Use a global variable instead
  • Use UVM configuration with one set()
  • Use UVM configuration with a few set()
  • Use a configuration tree
  • Try something different

That last approach of trying something different is the new solution, and it continues to use the set() and get() API, then simplifies by removing parameterization of the configurations, removes precedence, and removes the lookup algorithm change. The results of this new approach are fast speeds.

Your new configuration item is defined in the derived class from ‘config_item’, and the example below shows ‘int value” as the property being set. For debug purposes you add the pretty-print function.

class my_special_config_item extends config_item; 
   function new(string name = "my_special_config_item");
     super.new(name);
   endfunction 

   int value; 

   virtual function string convert2string();
     return $sformatf("%s - value=%0d <%s>", get_name(), value, super.convert2string());
   endfunction
 endclass

The ’config_item’ has a name attribute, and this name is looked up, plus the instance name. The configuration object also has a get_name() function to return the name. To find any “instance_name.field_name” the configuration database uses an associative array for fast lookup and creation speeds.
For traceability you can find out who set or who called get, because a file name and line number are fields in the set() and get() function calls.

set(null, "top.a.b.*", "SPEED", my_speed_config, `__FILE__, `__LINE__) 
get(null, "top.a.b.c.d.monitor1", "SPEED", speedconfig, `__FILE__, `__LINE__)

The accessor queue can be printed during debug to see who called set() and get().

To support wildcards required adding a lookup mechanism using containers. Consider the instance name ‘top.a.b.c.d.*_0’.

Container Tree

The wildcard part of the instance name is handled by using the container tree, instead of the associative array.

Summary

Sharing data between the module/instance and the class-based world in a UVM testbench can be done using the UVM configuration database, just be aware of the speed slowdowns. If your methodology uses lots of configurations, then consider using the new approach introduced which has a package using about 300 lines of code instead of the 2,600 lines of code in the UVM configuration database file.

Read the full 20-page paper, Avoiding Configuration Madness The Easy Way at Siemens EDA.

Related Blogs

Posted on

SPIE 2023 Buzz – Siemens Aims to Break Down Innovation Barriers by Extending Design Technology Co-Optimization

SPIE 2023 Buzz – Siemens Aims to Break Down Innovation Barriers by Extending Design Technology Co-Optimization
by Mike Gianfagna on 12-26-2023 at 6:00 am
Categories: EDA, Events, Siemens EDA

SPIE 2023 Buzz – Siemens Aims to Break Down Innovation Barriers by Extending Design Technology Co Optimization

Preventing the propagation of systematic defects in today’s semiconductor design-to-fabrication process requires many validation, analysis and optimization steps. Tools involved in this process can include design rule checking (DRC), optical proximity correction (OPC) verification, mask writing and wafer printing metrology/inspection (to gauge the process), wafer printing metrology/inspection, and physical failure analysis to confirm failure diagnosis. The exchange of information and co-optimization between these steps is a complex process, with many feed-forward and feed-back loops. Communication is often hampered by “walls” between various parts of the process technology, slowing innovation. At the recent SPIE conference Siemens EDA presented a keynote address that proposed a series of approaches to break down these walls to improve the chip design to manufacturing process. Read on the see how Siemens aims to break down innovation barriers by extending design technology co-optimization.  

About the Keynote

SPIE is the international society for optics and photonics. The organization dates back to 1955 and its conference has become a premier event for advanced design and manufacturing topics. At this year’s event, Siemens presented the keynote that is the topic of this post. There were many contributors to the presentation, including Le Hong, Fan Jiang, Yuansheng Ma, Srividya Jayaram, Joe Kwan, Siemens EDA (United States); Doohwan Kwak, Siemens EDA (Republic of Korea); Sankaranarayanan Paninjath Ayyappan, Siemens EDA (India). The title of the talk was Extending design technology co-optimization from technology launch to HVM.

The talk was part of a session on design technology co-optimization (DTCO). This concept isn’t new, but Siemens looked at its application across a broader scope of the process, from design to high-volume manufacturing (HVM). The ideas and results presented have significant implications. Let’s take a closer look.

What Was Presented

First, a look at the current state of DTCO usage across key parts of the ecosystem was presented. From a design perspective, many advanced fabless companies have a DFM team that is seeing the limits of a pattern-based approach. What is really needed is new technology to facilitate yield learning without foundry dependence.

The foundries are using brute-force pattern-based machine learning approaches, which are costly but not completely effective. They are also seeking efficient information mining of the massive manufacturing data they create. Equipment vendors and EDA vendors have been working closer together and are coming up with more efficient machine learning solutions.

Stepping back a bit, it was pointed out that there are walls between the design and manufacturing phases of the process. Fabless companies create the design, perform DRC and design for manufacturing (DFM), then they toss it over the wall to the OPC/RET team within the foundry or IDM. The design gets tasks such as OPC and verification done, and then the data is tossed over another wall for mask writing and metrology/inspection. The final wall is for fabrication. Here, electrical test and failure analysis will be done. By the time a root cause of failure is found, 6-18 months have passed. That’s a very long feedback loop. The graphic at the top of this post depicts this process.

DTCO attempts to break down the walls, but the methodologies available are incomplete. Traditional DTCO starts very early in process development. Starting with a scaling need, a standard cell is defined, and synthesis, place, and route are performed to come up with basic patterns and measure the performance and power. SRAM yielding is also done and that data loops back to the standard cell design.

What was presented at the SPIE keynote was a way to extend this co-optimization concept to the entire process from design to manufacturing. The approach involves enabling an easier flow of information from design all the way to the final process and physical analysis by creating an information channel.

While this sounds straight-forward, it is not. Many challenges were discussed with concrete approaches to mitigate the issues.  For example, early designs can be created with layout synthetic generators to help calibrate the process to real design issues as the process is developed. This can alleviate many of the surprises currently faced with early process tapeouts.

Dealing with massive data volumes is another challenge. Using new sophisticated compression techniques, a 30X improvement is possible. This improves the data handling and analysis tasks quite a bit.  A concept called explainable AI can help to find root causes of problems much faster. The ability to re-train AI models later in the manufacturing process without invalidating earlier results is another area for improvement. Also in the data analysis area are techniques to deal with “imbalanced data”. For example, there may be one hot spot found in 100,000,000 patterns.

Putting all this together can create a much more efficient end-to-end design flow, as shown in the figure below.  

Platform details

To Learn More

The impact of the approaches outlined in this keynote presentation is substantial. You can view the presentation and access a white paper on the process here.  There’s a lot of useful information to be gained.  And that’s how Siemens aims to break down innovation barriers by extending design technology co-optimization.

Posted on

Application-Specific Lithography: Sense Amplifier and Sub-Wordline Driver Metal Patterning in DRAM

Application-Specific Lithography: Sense Amplifier and Sub-Wordline Driver Metal Patterning in DRAM
by Fred Chen on 12-25-2023 at 10:00 am
Categories: Lithography
2 Comments

Varying pitch in metal lines in DRAM periphery

On a DRAM chip, the patterning of features outside the cell array can be just as challenging as those within the array itself. While the array contains features which are the most densely packed, at least they are regularly arranged. On the other hand, outside the array, the regularity is lost, but the in the most difficult cases, the pitches can still be comparable with those within the array, though generally larger. Such features are the lowest metal lines in the periphery for the sense amplifier (SA) and sub-wordline driver (SWD) circuits. A key challenge is that these lines are meandering in appearance, and the pitch is varying over a range (Figure 1). The max/min pitch ratio can range ~1.4 to 2. The imaging performances of two or more pitches together cannot be judged from the imaging performance of each of those pitches by themselves.

Figure 1. Varying pitch in metal lines in DRAM periphery. From the right, the pitch is at a minimum, but from the left, it is nearly twice the minimum pitch.

The image of lines for a fixed pitch is constructed from the interference of at least two beams that emerge from the pupil and go through the final objective with numerical aperture NA. The maximum phase error between any two of the beams affects the degradation of the image as it goes out of focus. In an EUV system with 0.33 NA, a 44 nm pitch image can only be formed from two beams, while the 66 nm pitch can be formed from two, three, or four beams. Figure 2 shows the interesting result that the two-beam image has the lowest maximum phase error. This underlies the existence of forbidden pitches with dipole illumination [1]. This has driven the two-mask exposure approach [2].

Figure 2. Phase errors for various images at 66 nm pitch vs 44 nm pitch under 45 nm defocus in a 0.33 NA EUV system. Two-beam images give the least phase error.

Unfortunately, only 10% of the pupil in the 0.33 NA EUV system supports two-beam imaging for both 44 nm and 66 nm pitches (Figure 3). Light cut out at the condenser reduces the light available for exposure [3]. The usable pupil fill is further reduced to 0 by considering pupil rotation across slit [4].

Figure 3. Portion of 0.33 NA EUV pupil supporting two-beam imaging for 44 nm and 66 nm pitches, at slit center (blue) and slit edge (orange) after 18 deg rotation. No part of the pupil supports the imaging consistently across slit.

It gets worse for the High-NA 0.55 NA EUV system, as there will definitely be at least three beams emerging from the pupil and the depth of focus is reduced further by the higher NA.

If a DUV 1.35 NA system were used instead, double patterning is necessary to achieve both 44 nm and 66 nm pitches. Thus, 88 nm and 132 nm pitches will be actually exposed. Both of these use two-beam imaging, which bodes well for finding illumination that has sufficient depth of focus for both pitches (Figure 4).

Figure 4. Phase errors for 88 nm and 132 nm pitches under 45 nm defocus in an 1.35 NA ArF (DUV) system, for an optimized dipole illumination shape (inset).

At this point, we can generalize to set some lithographic requirements for metal line patterning for SA and SWD circuits. In order to maintain two-beam imaging, the maximum-to-minimum pitch ratio should be <2, corresponding to half-pitch k1=0.5 and k1=0.25, respectively. For a max/min pitch ratio of 1.5, current 1.35 NA DUV systems can support down to 80 nm minimum pitch, 120 nm maximum pitch without double patterning. Once double patterning is used, however, the maximum line pitch should not exceed ~90 nm. The max/min pitch ratio may need to be correspondingly adjusted. Due to the meandering nature of the metal lines, it would not be unreasonable to have, for example, 3 metal lines (2 pitches) in one section span the same extent as 4 metal lines (3 pitches) in another section. This even-odd disparity could be resolved by splitting and stitching the odd metal feature, as shown in Figure 5 [5,6].

Figure 5. Splitting a layout containing even and odd numbers of lines can be resolved by splitting the odd feature to be stitched back together with the double patterning.

When the minimum line pitch gets smaller than ~40 nm (beyond 13nm DRAM node [7]), we should expect the DUV double patterning to become quadruple patterning (Figure 6). But why not consider EUV single exposure patterning?

Figure 6. Quadruple patterning (with a 1.35 NA DUV system); each color represents a separate exposure.

An additional consideration for SA and SWD metal patterning is that the layout requires two dimensions to accommodate the perpendicular bit line and word line directions. This entails the use of X+Y dipole, or cross-dipole illumination, which will restrict the mask types used. Essentially, the illumination can only support pitches in one orientation, and degrades pitches with the other orientation. Masks without pre-designed phase shifts (aka binary masks) suffer from a drop in normalized image log slope (NILS) (Figure 7). EUV currently contends with a lack of the necessary phase-shift masks [8,9]. Hence, two exposures (each already more than the cost of two DUV exposures [10]), one for X orientation, one for Y orientation, would be required.

Figure 7. Cross-dipole illumination reduces NILS for 2-beam imaging with binary masks.

DUV attenuated phase-shift masks (attPSMs) can be designed with 180 deg phase shifts between the bright and dark regions, mitigating this issue (Figure 8).

Figure 8. Cross-dipole illumination still reduces NILS for 2-beam imaging with attPSM masks, but the value stays above 2.

The scenarios described above are summarized in the table below.

Table 1. Scenarios for SA and SWD minimum pitch metal patterning in DRAM.

References

[1] M. Eurlings et al., Proc. SPIE 4404, 266 (2001).

[2] D. Nam et al., Proc. SPIE 4000, 283 (2000).

[3] M. van de Kerkhof et al., Proc. SPIE 10143, 101430D (2017).

[4] A. Garetto et al., J. Micro/Nanolith. MEMS MOEMS 13, 043006 (2014).

[5] Y. Kohira et al., Proc. SPIE 9053, 90530T (2014).

[6] S-Min Kim et al., Proc. SPIE 6520, 65200H (2007).

[7] J. Lee et al., Proc. SPIE 12495, 124950S (2023).

[8] F. Chen, “Phase Shifting Masks for NILS Improvement – A Handicap For EUV,” https://www.linkedin.com/pulse/phase-shifting-masks-nils-improvement-handicap-euv-frederick-chen

[9] A. Erdmann, H. Mesilhy, and P. Evanschitkzy, J. Micro/Nanopatterning, Materials, and Metrology 21, 020901 (2022).

[10] L. Liebmann, A. Chu, and P. Gutwin, Proc. SPIE 9427, 942702 (2015).

This article first appeared in LinkedIn Pulse: Application -Specific Lithography: Sense Amplifier and Sub-Wordline Driver Metal Patterning in DRAM

Also Read:

BEOL Mask Reduction Using Spacer-Defined Vias and Cuts

Predicting Stochastic Defectivity from Intel’s EUV Resist Electron Scattering Model

China’s hoard of chip-making tools: national treasures or expensive spare parts?

Posted on

Preventing SOC Schedule Delays Using the Cloud

Preventing SOC Schedule Delays Using the Cloud
by Ronen Laviv on 12-25-2023 at 6:00 am
Categories: EDA

compute peaks 1

In my previous article, we touched on ways to pull in the schedule. This time I’d like to analyze how peak usage affects project timeline and cost. The above graph is based on real pattern taken from one development week in Annapurna Labs 5nm Graviton.

The Graph shows the number of variable servers per hour per day. There’s a baseline of “always on” compute that was removed from the graph, to focus on the variability of that usage per time in the week. We’ll touch how to address the baseline on a different article with saving plans or reserved instances.

Navigating the Uncertain Waters of On-Premises Compute

Looking at the next compute refresh cycle, estimating the required number of CPUs, memory size, and CPU type for diverse projects involves a significant amount of guesswork, often leading to inefficient resource allocation. While future articles will dive deeper into these specific aspects, this piece focuses on the limitations removed when adding AWS to your on-premises cluster.

When using on-premises compute, companies are forced to choose between oversizing the cluster (creating waste but enabling engineers) or under sizing it with opposite results. Imagine purchasing compute resources to accommodate the highest peak you see in the graph of Figure 1. The orange areas surrounding the peak represent unused, paid-for compute. This highlights the crucial tradeoff companies face: balancing the cost of resources against the potential impact on schedule requirements, quality and licenses utilization.

The Bottleneck Conundrum

So, the IT team, together with R&D leadership would work to guess the right compute number and reduce the amount of unused compute (upper orange block). Nevertheless,

a significant portion of un-used compute still remains, representing unutilized, purchased resources as you can see in the graph on Figure2.

However, this is not the most critical issue.

The true challenge lies in daily peak usage (white areas). During these periods, projects may face delays due to insufficient on-premises compute capacity that cause engineers or licenses to wait for their jobs to run. This forces companies to make difficult choices, potentially compromising on crucial aspects like:

  • Test coverage: Running fewer tests can lead to undetected issues, impacting product quality and potentially resulting in costly re-design, backend re-runs or ECOs after tapeout.
  • Number of parallel backend trials: Limiting parallel trials slows down the development process, hindering overall project progress. In the new era of AI runs, EDA tools as Cerebrus (Cadence) or ai (Synopsys) could directly affect schedule and PPA (Power Performance Area) results.
  • Simulations: Reduced simulations or regressions testing may potentially lead to problems later in the development cycle. As we all know, bugs that are found earlier in the product cycle have minimal impact on schedule. Bug that are found late in the process are often causing re-design, new place & route, timing, … and add redundant cycles to the critical path to tapeout.
  • Formal methodologies: Similar to reduced simulations, cutting back on formal methodologies increases the risk of design flaws and errors. Same problems discussed above for simulations are also relevant here.

These compromises can add risk to both tapeout quality and time to market (posting a potential tapeout delay). Both factors are critical in today’s fiercely competitive landscape.

Some companies attempt to address peak usage issues by shifting capacity from other projects. While this might seem like a quick fix, it has cascading effects, impacting the schedule and quality of the other projects as well. Ultimately, if resources are limited, shifting them around is not always a sustainable solution. If you find yourself in a situation where you don’t have the compute resources for your project, your schedule would probably slip or you may have to compromise on specifications, quality and PPA (Power Performance Area).

Embracing the AWS Cloud
Fortunately, there exists a simple yet powerful solution: AWS Cloud computing eliminates the need for guesswork and waiting for jobs. You only pay for the resources you use, ensuring efficient utilization and eliminating the “orange cost” of unused resources. AWS cloud will help you overcome capacity limitations. Your engineering team should not have any license waiting for a compute node. This will increase your EDA license utilization and engineering productivity.

Here’s a short video that summarizes it all:

Addressing the License Challenge

One valid concern regarding cloud adoption might be the question of licenses: “While the cloud solves the compute issue, what about EDA licenses?”.

Your company might not have enough licenses, and you’ll be constrained by them anyway.

This is a legitimate point. Addressing run issues requires a comprehensive approach that considers both compute and licenses. Fortunately, all key EDA vendors are now offering innovative licenses as well as technical solutions specifically designed for cloud usage. By collaborating with your EDA vendors (Cadence, Synopsys, Mentor–Siemens), you can explore these options and find the solution that best suits your needs.

However, it’s crucial to remember that you may also have EDA licenses that are waiting for compute to be able to run. Those also represent a potentially large hidden cost. Idle engineers waiting for runs translate to wasted money on licenses (…and engineering) as well as lost time to market. Similar to the un-used compute waste in Figure2, the white area affects also “licensing cost”. Since it can significantly impact your bottom line and time to market. We will explore this topic further in future articles.

Unlocking the Potential of the Cloud for Faster Time to Market

By embracing the cloud, companies can secure several key benefits:

  • Avoid delays: Cloud computing ensures access to the necessary compute power during peak usage periods. This prevents project delays and ensuring smooth development.
  • Optimize resource allocation: With the cloud’s pay-as-you-go model, companies can eliminate the waste associated with unused on-premises resources.
  • Variety of compute types: Other than access to quantity and not waiting for compute, there is also an aspect of the machine type itself: Memory size, CPU type etc. Those parameters affect performance as well and we’ll touch this topic in one of the future articles.
  • Faster time to market: By eliminating delays and optimizing resources, cloud computing helps companies bring their products to market faster, giving them a competitive edge. ARM reported doing 66% more projects with the same engineering team.
The Cloud: Beyond Technology, a Mindset Shift

To sum up, the cloud is about enabling your team to achieve its full potential and optimize its workflow without having to guess the capacity. Ability to handle pick usage has a direct effect on quality, schedule and engineering/license utilization. In my next article, I’ll talk about more cloud aspects that would result faster time to market and better utilization of your engineering and licenses.

Disclaimer: My name is Ronen, and I’ve been working in the semiconductor industry for the past ~25 years. In the early days of my career, I was a chip designer and manager, then moved to the vendor side (Cadence) and now spending my days assisting companies in their journey to cloud with AWS. Looking at our industry along the years, examining the pain points of our industry as a customer and a service provider I am planning to write a few articles to shed some light on how chip design could benefit from the cloud revolution that is taking place these days.

C U in the next article.