100X800 Banner (1)
Semiconductor Expert Forum

Podcast EP70: A Review of EDA and IP Growth For 2021 with Dr. Walden Rhines

Podcast EP70: A Review of EDA and IP Growth For 2021 with Dr. Walden Rhines
by Daniel Nenni on 04-08-2022 at 10:00 am
1 Comment

Dan is joined by Dr. Walden Rhines in his capacity as Executive Sponsor for the SEMI Electronic Design Market Data Report. Wally provides an overview of the most recent report covering all of 2021. Spoiler alert: it was a record-breaking year in many areas.

Dan and Wally explore the details behind the numbers and what it may mean for the coming year of semiconductor growth. Various events around the world are also discussed with regard to their possible impact on the industry.

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

CEO Interview: Dr. Esko Mikkola of Alphacore

CEO Interview: Dr. Esko Mikkola of Alphacore
by Daniel Nenni on 04-08-2022 at 6:00 am
Categories: Alphacore, CEO Interviews, IP

Esko Mikkola Polo

 CEO’s background: what led to your current organization?
Since an early age, exceeding expectations has driven me to succeed in my areas of interest. While enlisted in the Finnish Army, I was selected, trained, and short-listed for the country’s astronaut training program before it was unfortunately dissolved.  A major realized goal was to qualify and represent Finland in the 2004 Athens Olympics. In the US, I won the NCAA javelin championship in 2013. This rigorous athletic discipline complemented a similar intense academic drive to extensively research advanced analog electronics with an emphasis on radiation tolerance, reliability modeling and characterization structures. While completing a PhD in Electrical Engineering, I had a focus on evaluating analog IC modelling correlation issues affecting advanced small geometry technologies. During the course of this work, it became apparent that a significant unserved opportunity existed to deliver ultra-low power, high-speed, and high-resolution data converter solutions. I was particularly interested in the mixed signal aspects of conversion architectures especially as applied to analog circuit functionality and reliability when using emerging very small nanometer-scale geometries. Those experiences led to managing successful research and development programs where the ideas were put into practice. Once the technology and opportunity were validated, I made the entrepreneurial leap as the Founder and CEO of Alphacore Inc.

Please tell us about Alphacore and its product offering.

The Alphacore design team has extensive experience in delivering products and solutions for a diverse customer base. We offer products and services that often far exceed the performance specifications of what is available in the market today. These solutions fulfill the needs of a broad range of leading-edge commercial, scientific, and aerospace communication applications. For example, Alphacore’s novel data converter architecture, HYDRATM (Hybrid DigitizeR Architecture), allows us to deliver a best-in-class family of RF data converters. The resolution in this family is up to 14bits with analog bandwidths as high as 25Ghz, while consuming milliwatts of power. These hybrid architecture innovations are key to delivering the unbeatable specs found in our Gigasamples per second and milliwatts of power RF data converter library.

From our foundation in RF Data Converters, we have built a transceiver architecture, SMARTTM (Scalable Macro Architecture for Receiver and Transmitter), that is delivered to customers as scalable macros. This innovative and multi-core macro approach is ideal for phased arrays, beam forming, Massive-MIMO, 5G/6G applications that offer significant advantages compared to other approaches. Starting with our RF data converter family, we cover selectable data converter specs for multi-channel arrays available from a few hundred MHz to 20 Gigasamples per second. Alphacore’s innovative hybrid architecture enables these arrays to be configurable with best-in-class area and power efficiency. Our scalable macro transceiver architecture can be configured with on-board PLL’s, with selectable I/O formats, and with or without SerDes.  This scalable approach enables optimum performance, maximum configurability, with minimal customization and design risk.

What makes Alphacore Intellectual Property/products unique?

Continuing with the theme from the previous questions, there are really two things that make our products unique. First, and probably most important is that the team has invented and now productized HYDRATM and SMARTTM architectures that solve the area, performance, and power challenges of not just the data converters, but of the macros required at the RF system level.

Alphacore is growing fast, and leverages our small company agility to deliver innovative architectures and remarkable system performance for our partners and customers. Our ADCs have the lowest power in their resolution and bandwidth class. Additionally, we are a member of the prestigious GlobalFoundries FDX Network that recognizes these industry demonstrated design accomplishments. We continue to blaze new trails in leading edge process technologies such as GF’s 22FDX 22nm fully depleted silicon on insulator (FD-SOI) CMOS process, our customers are assured their unique solution is developed using rigorous discipline approved by an internationally respected partner.

For example, our exciting IP cores with World-class performance levels, using low power FD-SOI technologies, offer proven solutions that include data converter products. We alone offer reduction in power that is 10X lower than nearest commercial competitors, wide bandwidth, and innovative automatic background calibration for spur removal all with Gigasample-class conversion rates. The outright performance increase of our cores offers a unique market disrupting position with established competitor data conversion vendors. Significantly, these have enabled cost-effective IC readout solutions with frame rates all the way up to 600,000 frames per second, and more reliable control electronics for harsh environments.

What customer challenges/competitive positioning are you addressing?

Our commercial customers are in market segments that are driven by frequently upgraded specifications and new advanced product demands, such as emerging 5G communications standards, and Advanced Driver-Assistance Systems that demand high quality solutions at low-cost. Alphacore delivers data converters with the best performance figure of merit (power dissipation, sampling rate, effective number of bits, and signal-to-noise and-distortion ratio parameters), imaging solutions with the highest resolutions and frames per second available, and power management products such as the most power efficient DC-DC converters.

As mentioned before Alphacore’s new products enable market disrupting consumer priced solutions with unbelievable performance and pricing in monolithic packages that replace expensive and less reliable hybrid multi-chip modules. Alphacore’s business model provides our customers with optimum tradeoff selection for power and performance of data converters to propel faster time-to-market for their system designs that are simpler, smaller and more affordable, with available assistance from our dedicated technical support during the process.

Furthermore, competitive versions of these products can be delivered with characterized radiation tolerance specifications.

Which markets most benefit from Alphacore IP?

Our technical team includes disciplined and seasoned “Radiation-Hardened-By-Design” (RHBD) experts; however, we specialize in designing commercial high-performance solutions for niche needs of demanding segments including 5G communications. Alphacore’s very-low-power and high-speed data converter IP design blocks are ideally suited to direct RF sampling architectures necessary for advanced communication standards including 5G, LTE and WiFi and their base stations.

Also, our library of IP facilitates the fast development pace of new technology in other major markets for automotive sensors, aerospace, defense, medical imaging, homeland security, scientific research, or electronics for High Performance Computing (HPC) in space environments.

All of these market segments drive next generation products, that similar to Moore’s Law, seem to demand 2x, 3x, multiples of performance or resolution increases at similar multiples of economies of scale and pricing. Significantly, Alphacore’s product roadmap with complementing photolithographic breakthroughs, novel scaling architectures, etc., is ideal whether customers request low-cost high-performance IP or much larger scaled IP versions with massive increases in data or image resolution.

What are Alphacore’s Goals?

The company is driving towards recognition of its strengths and expertise, and commercial business development of its products and licensable IP in a handful of strategic business opportunity-driven areas that directly focus on Alphacore’s clear strengths. I would characterize these critical growth areas for us as 1) High-performance Analog, Mixed-Signal and RF Solutions, 2) Advanced CMOS Image Sensor, Camera System and ROIC products and services, 3) Radiation Hardening expertise for applications with Harsh Environments, and 4) Emerging Solutions for 5G, SATCOM, Scientific Research, Automotive, Defense, Space.

Also Read:

Aerial 5G Connectivity: Feasibility for IoT and eMBB via UAVs

A Tour of Advanced Data Conversion with Alphacore

Analog to Digital Converter Circuits for Communications, AI and Automotive

Posted on

Design to Layout Collaboration Mixed Signal

Design to Layout Collaboration Mixed Signal
by Tom Simon on 04-07-2022 at 10:00 am
Categories: Cliosoft, EDA, Synopsys

Cliosoft integration with Custom Compiler

When talking about today’s sophisticated advanced node designs it’s easy to first think about the digital challenges. Yet, the effort to design the needed analog and mixed signal blocks for them should not be underestimated. The need for high speed clocks, high frequency RF circuits and high bit rate IOs makes the analog portions, particularly on FinFET nodes, complex and difficult. Analog design has in reality maintained its importance to SOC success over time. Indeed, the facts show growing numbers of analog and AMS circuit and layout designers working in teams around the world. Collaboration within and among these teams has become a primary concern.

There is a changing analog tool landscape too. Custom Compiler from Synopsys is making significant inroads into the previously monolithic custom IC design market. Synopsys reports that there are now nearly 200 companies using Custom Compiler. This, in conjunction with Synopsys’ own internal usage for the development their commanding analog IP portfolio, means that there are literally thousands of seats in use today and the numbers are growing. In a recent webinar by Synopsys and Cliosoft, a leading design data management solution provider, Synopsys cites increased design efficiency as the key to their on-going success. The webinar titled “Enabling Effective Design & Layout Collaboration for Next Generation Analog and Mixed Signal Designs” touts the efficiencies added by integration with Cliosoft for design collaboration.

One might assume that this is just about checking files in and out so they can be edited safely. However, the webinar goes into detail about some pretty important aspects of the integration of Cliosoft SOS and Synopsys Custom Compiler. They specifically highlight the signoff review features. It’s important to note that circuit designers and layout engineers working on the same project might be sitting halfway around the world from each other. The integration described in the webinar offers sophisticated features so that one team can add notation to areas within a design, including highlighting specific areas of the design graphically to help communicate changes that might be needed. The Cliosoft SOS integration allows this collaboration activity right inside of the Custom Compiler user interface and directly on the design.

Cliosoft integration with Custom Compiler for Collaboration

The webinar has an overview that shows how Cliosoft SOS capabilities can be used for design/layout collaboration and closure. The four elements of this are managing the design, facilitating collaboration, offering insight through analysis and finally making reuse possible.

Design data management includes revision control as you would expect. It offers release and variant management. Data security and access controls are provided as well. It also contains features that help to optimize network and disk storage usage.

The collaboration element covers support for remote cache servers with automatic synchronization. Underlying this are mechanisms that provide secure and efficient data transfer between sites.

The analysis features can produce design audit reports. It can also be used to spot schematic/layout differences. There are also reports on the changes made between releases or over time on designs. All of this helps manage and track the design process.

The fourth category is reuse, while long sought after, has in practice proven challenging. Cliosoft SOS helps companies effectively locate and reuse designs. Customers can create their own IP catalog. When there are fixes and releases to IP in the catalog, they are propagated so everyone stays up to date. The net effect is to increase productivity.

The webinar covers examples of each of these elements. Also, it includes a demo that shows how Cliosoft SOS is used directly inside of the Custom Compiler GUI for several of the tasks mentioned above to improve collaboration. The full webinar can be viewed on the Synopsys website.

Also read:

Synopsys Tutorial on Dependable System Design

Synopsys Announces FlexEDA for the Cloud!

Use Existing High Speed Interfaces for Silicon Test

 

 

Posted on

Intel Best Practices for Formal Verification

Intel Best Practices for Formal Verification
by Daniel Nenni on 04-07-2022 at 6:00 am
Categories: Events, Foundries, Intel Foundry

formal dynamic verification comparison

Dynamic event-based simulation of RTL models has traditionally been the workhorse verification methodology.  A team of verification engineers interprets the architectural specification to write testbenches for various elements of the design hierarchy.  Test environments at lower levels are typically exercised then discarded, as RTL complexity grows during model integration.  Methodologies have been enhanced to enable verification engineers to generate more efficient and more thorough stimulus sets – e.g., biased pseudo-random pattern generation (PRPG); portable simulation stimulus (PSS) actions, flows, and scenarios.

Yet, dynamic verification (DV) is impeded by the need to have RTL (or perhaps SystemC) models thoroughly developed to execute meaningful tests, implying that bug hunting gets off to a rather late start.

Formal verification (FV) algorithms evaluate properties that describe system behavior, without the need for dynamic stimulus.  These are three facets to FV:

  • assertions

Model assertions are written to be exhaustively proven by evaluating the potential values and sequential state space for specific signals.

  • assumptions

Known signal relationships (or constraints) are specified on model inputs, to limit the bounds of the formal assertion proof search.

  • covers

A covergroup defines an event (or sequence) of interest that should eventually occur, to record the scope of verification testing – an example would be to ensure proper functionality of the empty and full status of a FIFO stack.

A common semantic form for these FV properties is SystemVerilog Assertions (SVA). [1]

The properties in an assertion to be exhaustively proven have a range of complexities:

  • (combinational) Boolean expressions
  • temporal expressions, describing the required sequence of events
  • implication: event(s) in a single cycle imply additional event(s) much occur in succeeding cycles
  • repetition: an event much be succeeded by a repetition of event(s)

When a formal verification tool is invoked to evaluate an assertion against a functional model, the potential outcomes are:

  • proven
  • disproven (typically with a counterexample signal sequence provided)
  • bounded proven to a sequential depth, an incomplete proof halted due to resource and/or runtime limits applied as the potential state space being evaluated grows

FV offers an opportunity to find bugs faster and improve the productivity of the verification team.  Yet, employing the optimal methodology to leverage the relative strengths of both formal verification and dynamic verification (with simulation and emulation) requires significant up-front project planning.

At the recent DVCON, Scott Peverelle from the Intel Optane Group gave an insightful talk on how their verification team has adopted a hybrid FV and DV strategy. [2] The benefits they have seen in bug finding and (early) model quality are impressive – part of the initiative toward “shift left” project execution.  The rest of this article summarizes the highlights of his presentation.

Design Hierarchy and Hybrid FV/DV Approaches

The figure above illustrates a general hierarchical model applied to a large IP core – block, cluster, and full IP.  The goal is to achieve comprehensive FV coverage for each block-level design, and extend FV into the cluster-level as much as possible.

The expectation is that block-level interface assertions and assumptions will be easier to develop and verify.  And similarly, end-to-end temporal assertions involving multiple interfaces across the block will have smaller sequential depth, and thus have a higher likelihood of achieving an exhaustive proof.  Scott noted that the micro-architects work to partition block-level models to assist with end-to-end assertion property generation.

Architectural Modeling and FV

Prior to focusing on FV of RTL models, a unique facet of the recommended hybrid methodology is to create architectural models for each block, as depicted below.

The architectural models can be quite abstract, and thus small and easy to develop.  The models only need to represent enough behavior to include key architectural features.

A major goal is to enable the verification team to develop and exercise the more complex interface and end-to-end FV assertions, and defer work on the properties self-contained within the block functionality.  These architectural models are then connected to represent a broader scope of the overall hierarchy.

Although the resource invested in writing architectural model may delay RTL development, Scott highlighted that this FV approach expedites evaluation of complex, hard-to-find errors, such as for:  addressing modes and address calculation; absence of deadlock in communication dependencies; verification of the order of commands; and, measurement of the latency of system operations.

Formal Verification of RTL

The development of additional FV assertions, assumptions, and covers expands in parallel with RTL model coding, with both the micro-architects and verification team contributing to the FV testbench.

The recommended project approach is for the micro-architects to focus initially on RTL interface functionality; these RTL “stubs” are immediately useful in FV (except for the end-to-end assertions).  Subsequently, the baseline RTL is developed and exercised against a richer set of assertions and covers.  And, the properties evaluated during the architectural modeling phase are re-used and exercised against the RTL.

As illustrated below, there is a specific “FV signoff” milestone for the block RTL.

The FV results are evaluated – no failing assertions are allowed, of course, and any assertions that are incomplete (bounded proven) are reviewed.  Any incompletes are given specific focus by the dynamic verification testbench team – the results of a bounded search are commonly used as a starting point for deep state space simulation.

Promotion of FV Components to Higher Levels

With a foundation in place for block-level FV signoff, Scott described how the FV testbench components are promoted to the next level of verification hierarchy, as illustrated below.  The FV component is comprised of specific SystemVerilog modules, with assertions and assumptions partitioned accordingly.  (An “FBM” is a formal bus model, focused on interface behavior properties.)

Each FV component has a mode parameter, which sets the configuration of assertions, assumptions, and covers.  In ACTIVE mode, all assertions and covers are enabled; assumptions (in yellow) are used to constrain the property proof.  When promoting an FV component, the PASSIVE mode is used – note that all assume properties are now regarded as assertions to be proven (green).

In short, any block model assumption on input ports need to be converted to assertions to verify (either formally or through dynamic simulation) at the next level of model integration.

Briefly, there is also an ARCH mode setting for each FV component, as depicted below:

If a high-level architectural model is integrated into a larger verification testbench, end-to-end and output assertions become FV assumptions (in yellow), while input assumptions are disabled (in grey).

Additional Formal Apps

Scott highlighted the additional tools that are still needed to complement the formal property verification methodology:

  • inter-module connectivity checks (e.g., unused ports)
  • clock domain crossing (CDC) checks for metastability interface design
  • sequential equivalence checking, for implementation optimizations that introduce clock gating logic
  • X-propagation checks

3rd Party IP Interface Verification

If the design integrates IP from an external source, a FV-focused testbench is a valuable resource investment to verify the interface behavior.  Scott mentioned that end-to-end assertions that are developed to ensure the overall architectural spec correctly matches the 3rd party IP behavior have proven to be of considerable value.  (Scott also noted that there are commercially-available FV testbenches for protocol compliance for industry-standard interfaces.)

Dynamic Verification

Although FV verification can accelerate bug finding, Scott reiterated that their verification team is focused on a hybrid methodology, employing DV for deep state bug hunting, and for functionality that is not well-suited for formal verification.  Examples of this functionality include:

  • workload-based measurements of system throughput and interface bandwidth
  • power state transition management
  • firmware and hardware co-simulation (or emulation)
  • SerDes PHY training

Results

The planning, development, and application of FV components and integration in a verification testbench requires an investment in architecture, design and verification team resources.  Scott presented the following bug rate detection graph as an indication of the benefits of the approach they have adopted.

The baseline is a comparable (~20M gate) IP design, where dynamic verification did not begin in earnest until the initial RTL integration milestone.  The early emphasis on FV at the architectural level captured hundreds of bugs, quite a few related to incorrect and/or unclear definitions in the architectural spec (including 3rd party IP integration).   These bugs would have taken much longer and more verification resource to uncover in a traditional DV-only verification flow.

Summary

Formal property verification has become an integral part of the initiative toward a shift-left methodology.  Early FV planning and assertion development combined with a resource investment in architectural modeling helps identify bugs much earlier.  A strategy for focusing on FV at lower levels of the design hierarchy, following by evaluation of constraints at higher levels of integration, will offer FV testbench reuse benefits.  This is an improved method over lower-level dynamic verification testbench development that is commonly discarded as the design complexity progresses.

The best practices FV methodology recently presented by Intel at DVCON is definitely worth further investigation.

References

[1]   IEEE Standard 1800 for SystemVerilog, https://ieeexplore.ieee.org/document/8299595

[2]   Chen, Hao; Peverelle, Scott;  et al, “Maximizing Formal ROI through Accelerated IP Verification Sign-off”, DVCON 2022, paper 1032.

Also read:

Intel Evolution of Transistor Innovation

Intel 2022 Investor Meeting

The Intel Foundry Ecosystem Explained

Posted on

TSMC’s Reliability Ecosystem

TSMC’s Reliability Ecosystem
by Tom Dillinger on 04-06-2022 at 10:00 am
Categories: Events, Foundries, TSMC

AC accelerated stress conditions

TSMC has established a leadership position among silicon foundries, based on three foundational principles:

  • breadth of technology support
  • innovation in technology development
  • collaboration with customers

Frequent SemiWiki readers have seen how these concepts have been applied to the fabrication and packaging technology roadmaps, which continue to advance at an amazing cadence.  Yet, sparse coverage has typically been given to TSMC’s focus on process and customer product reliability assessments – these principles are also fundamental to the reliability ecosystem at TSMC.

At the recent International Reliability Physics Symposium (IRPS 2022), Dr. Jun He, Vice-President of Corporate Quality and Reliability at TSMC, gave a compelling keynote presentation entitled:  “New Reliability Ecosystem: Maximizing Technology Value to Serve Diverse Markets”.  This article provides some of the highlights of his talk, including his emphasis on these principles.

Technology Offerings and Reliability Evaluation

The figures above highlight the diverse set of technologies that Dr. He’s reliability team needs to address.  The reliability stress test methods for these technologies vary greatly, from the operating voltage environment to unique electromechanical structures.

Dr. He indicated, “Technology qualification procedures need to be tailored toward the application.  Specifically, the evaluation of MEMS technologies necessitates unique approaches.  Consider the case of an ultrasound detector, where in its end use the detector is immersed in a unique medium.  Our reliability evaluation methods need to reflect that application environment.”

For more traditional microelectronic technologies, the reliability assessments focus on accelerating defect mechanisms, for both devices and interconnect:

  • hot carrier injection (HCI)
  • bias temperature instability (NBTI for pFETs, PBTI for nFETs)
  • time-dependent dielectric breakdown (TDDB)
  • electromigration (for interconnects and vias)

Note that these mechanisms are highly temperature-dependent.

As our understanding of the physics behind these mechanisms has improved, the approaches toward evaluating their impact to product application failure rates have also evolved.

Dr. He commented, “Existing JEDEC stress test standards are often based on mechanism acceleration using a DC Vmax voltage.  However, customer-based product qualification feedback did not align with our technology qualification data.  Typically, the technology-imposed operating environment restrictions were more conservative.”

This is of specific interest to high-performance computing (HPC) applications, seeking to employ boost operating modes at increased supply voltages (within thermal limits).

Dr. He continued, “We are adapting our qualification procedures to encompass a broader set of parameters.  We are incorporating AC tests, combining Vmax, frequency, and duty cycle variables.”

The nature of “AC recovery” in the NBTI/PBTI mechanism for device Vt shift has been recognized for some time, and is reflected in device aging models.  Dr. He added, “We are seeing similar recovery behavior for the TDDB defect mechanism.  We are aggressively pursuing reliability evaluation methods and models for AC TDDB, as well.”

The figure above illustrates the how the Vt shift due to BTI is a function of the duty cycle for the device input environment, as represented by the ratio of the AC-to-DC Vt difference.  The figure also highlights the newer introduction of a TDDB lifetime assessment for high-K gate dielectrics, as a function of input frequency and duty cycle.

Parenthetically, Dr. He acknowledged that end application product utilization can vary widely, and that AC reliability testing makes some usage assumptions.  He indicated that TSMC works with customer to establish appropriate margins for their operating environment.

Reliability Evaluation of New Device Types

TSMC has recently added resistive RAM (RRAM) and magneto-resistive RAM (MRAM) IP to their technology offerings.

The unique physical nature of the resistance change in the storage device for these technologies necessitates development of a corresponding reliability evaluation procedure, to establish retention and endurance specifications.  (For the MRAM technology, the external magnetic field immunity specification is also critical.)

For both these technologies, the magnitude and duration of the write current to the storage cell is a key design parameter.  The maximum write current is a crucial reliability factor.  For the MRAM example, a high write current through the magnetic tunnel junction to set/reset the orientation of the free magnetic layer in the storage cell degrades the tunnel barrier.

TSMC collaborates with customers to integrate write current limiting circuits within their designs to address the concern.  The figure below illustrates the write current limiter for the RRAM IP.

TSMC and Customer Collaboration Reliability Ecosystem

In addition to the RRAM and MRAM max write current design considerations, Dr. He shared other examples of customer collaborations, which is a key element of the reliability ecosystem.

Dr. He. shared the results of design discussions with customers to address magnetic immunity factors – the figure below illustrates cases where the design integrated a Hall effect sensor to measure the local magnetic field.  The feedback from the sensor can be used to trigger corrective actions in the write cycle.

The customer collaboration activities also extend beyond design for reliability (DFR) recommendations.  TSMC shares defect pareto data with customers.  Correspondingly, the TSMC DFR and design-for-testability (DFT) teams will partner with customers to incorporate key defect-oriented test screens into the production test flow.

Dr. He provided the example where block-specific test screens may be appropriate, as illustrated below.

Power management design approaches may be needed across the rest of the design to accommodate block-level test screens.

The figure below depicts the collaboration model, showing how customer reliability feedback is incorporated into both the test environment and as a driver for continuous improvement process (CIP) development to enhance the technology reliability.

Summary

At the recent IRPS, TSMC presented their reliability ecosystem, encompassing:

  • developing unique reliability programs across a wide breadth of technologies (e.g., MEMS)
  • developing new reliability methods for emerging technologies (e.g., RRAM, MRAM)
  • sharing design recommendations with customers to enhance final product reliability
  • collaborating closely with customers on DFR issues, and integrating customer feedback into DFT screening procedures and continuous improvement process focus

Reflecting upon Dr. He’s presentation, it is no surprise that these reliability ecosystem initiatives are consistent with TSMC’s overall principles.

-chipguy

Also read:

Self-Aligned Via Process Development for Beyond the 3nm Node

Technology Design Co-Optimization for STT-MRAM

Advanced 2.5D/3D Packaging Roadmap

Posted on

Synopsys Tutorial on Dependable System Design

Synopsys Tutorial on Dependable System Design
by Bernard Murphy on 04-06-2022 at 6:00 am
Categories: Arm, Automotive, EDA, IP, Security, Synopsys

Dependability

Synopsys hosted a tutorial on the last day of DVCon USA 2022 on design/system dependability. Which here they interpret as security, functional safety, and reliability analysis. The tutorial included talks from DARPA, AMD, Arm Research and Synopsys. DARPA and AMD talked about general directions and needs, Arm talked about their PACE reliability analysis technique and Synopsys shared details on solutions they already have and aligning standards in safety and security.

DARPA on practical strategies for security in silicon

Serge Leef (PM DARPA) provided insight into the DARPA focus on scalable defense mechanisms in electronics, particularly trading off cost versus security. They’re targeting not the big semis or consumer electronics guys but rather mid-sized semis and defense companies, who are most interested in getting help. The ultimate goal in the project that Serge oversees is automatic synthesis of secure silicon (AISS). No-one ever accused DARPA of thinking small.

Synopsys, Northrop Grumman, Arm and others have been selected to drive this effort. A security engine, developed in a different part of the program will be integrated together with commercial IP and security aware tools. In a phased approach to full automation, initially systems will be composed around these various IP. A second phase optimization will be configured within a platform-based architecture. In the final phase they aim to be able to specify a cost function around power, area, speed and security (PASS). Allowing system teams to dial in the tradeoff they want.

As I said, an ambitious goal, but this is the organization that gave us the Internet after all 😀.

AMD on functional safety

Bala Chavali is an RAS architect at AMD (RAS is reliability, availability and serviceability/ maintainability). Her main thesis in this talk was the challenge in meeting objectives across multiple dependability goals, each with their own standards and expectations. She breaks these down into reliability, safety, security, availability and maintainability.

In part the challenges arise from disconnected standards, lifecycle requirements and required compliance work products across these multiple objectives. In part challenges come from lack of enough standards on IP suppliers, particularly around safety, security, and traceability.

Bala underscored the importance of unifying these objectives as much as possible to minimize duplicated effort. She sees value in aligning common standards efforts, for example in defining a generic dependability development lifecycle. This should leverage a wholistic analysis data set. Also a common data exchange language across applications (automotive, industrial, avionics, and across the system design hierarchy). Bala mentioned the Accellera functional safety working group (on which she serves) as one organization working towards this goal, also IEEE P2581 as another with a similar objective.

Arm Research on PACE reliability analysis

Reiley Jeyapaul, Senior Research engineer at Arm Research, talked about using formal tools for reliability estimation on a Cortex-R52 using their proof-driven architecturally correct execution (PACE) methodology. Their objective is to estimate the fraction of their design which is vulnerable to soft errors (random failures) to produce an architecture vulnerability factor (AVF). They suggest this as a model to derate the estimated FIT rate. This factor is needed since not all naïve vulnerabilities are real (if an error does not propagate), or may in some cases be only conditionally vulnerable. Arm will license PACE models to partners for their use in system vulnerability assessments.

Reiley provides detail on their formal technique and how they validated this method against exhaustive fault injection (EFI). Models are a little pessimistic, but not as pessimistic as the naïve model, and run dramatically faster than EFI. Sounds like a valuable capability for SoC designers.

Synopsys on automation for safety and security

Meirav Nitzan, director of functional safety and security solutions at Synopsys, closed the tutorial. She summed up capabilities offered by Synopsys for safety and security, in tools and IP and across both software and hardware design. I’m not going to attempt to summarize that long list. I think their selection for the DARPA AISS program is endorsement enough. I will call out a few points that I found interesting to my predominantly hardware audience.

We all know tools and IP suites in this area. To this they add SW test libraries for safety and software security analysis for 3rd part SW running on HW. They also provide virtual prototyping for developing secure SW. They use fault simulation for FMEDA analyses of course. I also found it interesting that they support fault modeling for malicious attacks, also sample fault simulation in emulation. Which I would guess would be valuable in testing vulnerability to probing attacks.

Meirav wrapped by reiterating the work IEEE P2581 is doing; to align security and safety requirements, a worthy goal for all of us. Learn more about Synopsys’ solutions for mission-critical silicon and software development HERE.

Also read:

Synopsys Announces FlexEDA for the Cloud!

Use Existing High Speed Interfaces for Silicon Test

Getting to Faster Closure through AI/ML, DVCon Keynote

Posted on

The Importance of Low Power for NAND Flash Storage

The Importance of Low Power for NAND Flash Storage
by Tom Simon on 04-05-2022 at 10:00 am
Categories: IP
1 Comment

Low Power for NAND Flash

Even though we all know that reducing power consumption in NAND Flash Storage is a good idea, it is worthwhile to take a deeper dive into the underlying reasons for this. A white paper by Hyperstone, a leading developer of Flash controllers, discusses these topics providing useful insight into the problem and its solutions. The paper is titled “Power Consumption in NAND Flash Storage.”

Low Power for NAND Flash

It almost goes without saying that the most obvious reason to reduce NAND flash storage is to reduce operating costs – lower power means lower utility bills. Furthermore, lower power can also mean packaging and cooling system savings which will reduce end product costs. Along with that there are several other equally important reasons.

Regarding the key issues for NAND flash devices, the Hyperstone white paper mentions thermal stress. Increasing complexity and higher performance translate into more thermal stress for semiconductors. The problem is especially aggravated when devices are located in industrial or automotive settings where heat is already an issue. One property of semiconductors that works to our disadvantage is when they operate at higher temperatures, they use more power – creating a positive feedback loop. The white paper points out that a temperature rise from 50C to 100C leads to a ten-fold increase in leakage current. Thermal stress can lead to multiple kinds of failures such as device breakdown, electromigration and physical fatigue.

Leakage current, an important issue for NAND flash devices, is static current that flows through devices when they are not active. Unfortunately, the percentage of chip power consumption from leakage is growing as chips move to smaller more advanced process nodes. Additionally, there is a tradeoff between performance and leakage power. Lower threshold transistors, which have more leakage, are necessary for higher performance. The Hyperstone paper describes some specialized techniques for applying bias voltages to transistors to vary their leakage current as needed based on time-dependent performance requirements.

Within the NAND flash controller, the different functional elements have their own power requirements which can change depending on workloads and operational modes. The white paper does a good job of delineating the major functional blocks that can affect power consumption. Likewise, the NAND flash itself requires different levels of power for different operations. These are also dependent on whether it is single level charge (SLC) or multi-level charge (MLC).

The Hyperstone white paper describes the power implications of operational modes for the host interface over PCIe, and also discusses the power characteristics of DRAM which is often used for cache purposes. Error correction can play a hard to predict role in power usage. Encoding error correction information is not compute intensive. However, when there are errors, especially multiple errors extensive computation can be involved. This can drive up power consumption.

As a result, getting objective power measurements under different workloads and operating speeds can be tricky. Benchmarking power consumption is required to make realistic determination of low power performance. All of the above factors and more come into play. Many decisions in the total system design influence the result. DC to DC power converters need to be properly selected to handle transitions from modes to active modes. Interfaces should fully support low power modes. Controller chips and their ancillary chips needs to include advanced and complex power saving features, such as clock gating and power gating. Hyperstone includes information about their use of CystalDiskMark for benchmarking SSDs with Hyperstone flash memory controllers. They even include several graphs of power performance over long intervals that show their relative performance versus a competitor.

Because power consumption is such an important consideration for SSDs, it is good to get a deeper insight into its sources and solutions. Hyperstone does a good job of covering all of this in their white paper. You can download the white paper and other relevant Flash Storage white papers on the website of Hyperstone.

Posted on

Security Requirements for IoT Devices

Security Requirements for IoT Devices
by Daniel Nenni on 04-05-2022 at 6:00 am
Categories: Intrinsic ID

IoT Product Lifecycles SemiWiki

Designing for secure computation and communication has become a crucial requirement across all electronic products.  It is necessary to identify potential attack surfaces and integrate design features to thwart attempts to obtain critical data and/or to access key intellectual property.  Critical data spans a wide variety of assets, including financial, governmental, and personal privacy information.

The security of intellectual property within a design is needed to prevent product reverse engineering.  For example, an attacker may seek to capture firmware running on a microcontroller in an IoT application to provide competitive manufacturers with detailed product information.

Indeed, the need for a security micro-architecture integrated in the design is not only applicable to high-end transaction processing systems, but also down to IoT devices, as well.

Vincent van der Leest, Director of Product Marketing at Intrinsic ID, recently directed me to a whitepaper entitled, “Preventing a $500 Attack Destroying Your IoT Devices”.  Sponsored by the Trusted IoT Ecosystem Security Group of the Global Semiconductor Alliance (GSA), with contributions from Intrinsic ID and other collaborators, the theme of this primer is that a security architecture is definitely a requirement for IoT devices.  The rest of this article covers some of the key observations in the paper – a link is provided at the bottom.

Types of Attacks

There are three main types of attacks that may yield information to attackers:

  • side-channel attacks: non-invasive listening attacks that monitor physical signals coming from the IoT device
  • fault injection attacks: attempts to disrupt the internal operation of the IoT device, such as attempting to modify program execution of an internal microcontroller to gain knowledge about internal confidential data or interrupt program flow
  • invasive attacks: physical reverse engineering of the IoT circuitry, usually too expensive a process for attackers

For the first two attack types above, current IoT systems offer an increasing number of (wired and wireless) interfaces providing potential access.  Designers must be focused on security measures across all these interfaces, from memory storage access (RAM and external non-volatile flash memory) to data interface ports to test access methods (JTAG).

The paper goes into more detail on the security architecture, Cryptographic Keys and a Digital Signature, plus Key Generation.

Examples of Security Measures

The first step to prevent IoT attacks is taking certain design considerations into account. Here are some examples of design and program execution techniques to consider:

  • firmware storage.

An obvious malicious attack method would be to inject invalid firmware code into the IoT platform.  A common measure is to execute a small boot loader program upon start-up from internal ROM (not externally visible), then continue to O/S boot and application firmware from flash.  As the intent of using flash memory is to enable in-field product updates and upgrades, this externally-visible attack surface requires a security measure.  For example, O/S and application code could incorporate a digital signature evaluated for authentication by the security domain.

  • runtime memory security

Security measures may be taken to perform integrity checks on application memory storage during runtime operation.  These checks could be evaluated periodically, or triggered by a specific application event.  Note that these runtime checks really only apply to relatively static data – examples include:  application code, interrupt routines, interrupt address tables.

  • application task programming

An early design decision involves defining which tasks within the overall application necessitate security measures, and different operating system privileges.  As a result, the application may need to be divided into small subtasks.  This will also simplify the design of the security subsystem, if the task complexity is limited.

  • redundant hardware/software resources

For additional security, it may be prudent to execute critical application code twice, to detect an attack method that attempts to inject a glitch fault into the IoT system.

  • attestation

An additional measure to integrate into the design is the means by which the security subsystem attests (through an external interface) to confirm the IoT product is initialized as expected.  If runtime security checks are employed, the design also needs to communicate that operational security is being maintained.

IoT Product Development and Lifecycle

The figure above provides a high-level view of the IoT product lifecycle.  During IC fabrication, initial configuration and boot firmware are typically written to the device.  Cryptographic keys would be included as part of the security subsystem.  During IoT system integration, additional security data may also be added to the SoC.

Summary

The pervasive and diverse nature of IoT applications, from industrial IoT deployments to consumer (and healthcare) products, necessitates a focus on security of critical economic and personal privacy assets.  The whitepaper quotes a survey indicating that security concerns continue to be a major inhibitor to consumer IoT device adoption.  A recommendation in the whitepaper is for the IoT product developer to pursue an independent, third-party test and certification of the security features.

Here is the whitepaper: Preventing a $500 Attack Destroying Your IoT Devices

Contributors:

Published by:

Also read:

WEBINAR: How to add a NIST-Certified Random Number Generator to any IoT device?

Enlisting Entropy to Generate Secure SoC Root Keys

Using PUFs for Random Number Generation

Posted on

Designing a FinFET Test Chip for Radiation Threats

Designing a FinFET Test Chip for Radiation Threats
by Tom Simon on 04-04-2022 at 10:00 am
Categories: EDA, Siemens EDA
2 Comments

Charged Particles

Much of the technology that goes into aerospace applications is some of the most advanced technology that exists. However, these same systems must also offer the highest level of reliability in what is arguably an extremely difficult environment. For semiconductors a major environmental risk in aerospace applications are the effects of charged particles in the upper atmosphere and space.  Charged particles can lead to soft errors, where an IC is not permanently damaged, but its operation is temporarily disrupted leading to unpredictable results. Of course, ICs used in aerospace are hardened to limit the effects of charged particles, but their underlying process technology plays a big role in their susceptibility, especially in the case of FinFETs.

To lower the risk from charged particles, aerospace ICs have tended to use trailing process nodes. However, new nodes offer many attractive characteristics, such as reduced power and higher levels of integration. According to a Siemens EDA white paper, the European Space Agency (ESA) was interested in evaluating various FinFET nodes to determine which ones were the most promising candidates for use in their flight systems. The white paper titled “IROC tapes out aerospace SoC with Aprisa place-and-route” talks about ESA’s work with IROC Technologies to design test chips for evaluating the effects of charged particles on these advanced nodes.

IROC has broad capabilities for designing and testing ICs for quality and reliability. Yet, when ESA approached them to design self-contained test vehicles for FinFET processes they needed to put in place a complete FinFET SOC design flow for 16nm. The test chip design calls for standard cells, memories, complex IP and more. Along with the structures being tested the chip also had to include support circuitry to measure, record and analyze the performance of the test structures. The monitoring blocks had to be completely immune to radiation.

Like many companies looking for tools to set up their flow, IROC started looking at the tools qualified for the targeted TSMC N16 FinFET process. They were of course familiar with Calibre, but also saw that Siemens’ Aprisa place and route solution was included as well. IROC decided to proceed with using Aprisa for this project. Their initial decision, guided by Aprisa’s integration with other Siemens tools and tools from other vendors, was affirmed once they saw how intuitive and easy Aprisa was to set up and use. IROC used the reference flow provided by the Aprisa support team to go through their rapid learning process. One example of this smooth bring-up was the ease of setting up Aprisa to use the TSMC PDK for their process.

IROC started with the design partitioning step using a combination of custom and RTL based blocks. Aprisa let them generate the Liberty and layout views necessary for floor planning and chip assembly. Within a few days of setting up the flow they had completed first pass placement. The built-in timing analysis engine only required a few lines of Tcl to give them timing feedback that correlated well with their final sign off tools.

In the white paper IROC said they were pleased with the quick turnaround of the detail-route-centric design results provided by Aprisa’s multithreading capability. According to the white paper IROC saw high quality results that reduced the need for iterations to achieve design closure. In only three months IROC went from tool installation all the way through to a successful tapeout. For a FinFET process this is a remarkable achievement. They were able to use the silicon to perform the targeted reliability analysis for ESA. The aggressive schedule for the project meant that IROC made the decision to proceed with Aprisa without a traditional evaluation. Their assessment that the Aprisa would perform well for their project appears to have been well founded. No doubt the reputation that Siemens has earned for its EDA tools played a large factor in this decision. Aprisa is also certified down to TSMC N6 and is in the process of gaining certification for TSMC N5 and N4. The white paper is available for download on the Siemens EDA website.

Also read:

Path Based UPF Strategies Explained

Co-Developing IP and SoC Bring Up Firmware with PSS

Balancing Test Requirements with SOC Security

Posted on

Bridging Analog and Digital worlds at high speed with the JESD204 serial interface

Bridging Analog and Digital worlds at high speed with the JESD204 serial interface
by Daniel Nenni on 04-04-2022 at 6:00 am
Categories: Comcores, Events, IP

Comcore JESD204 Webinar SemiWiki

We are delighted to showcase our “Bridging Analog and Digital worlds at high speed with the JESD204 Serial Interface” webinar on April 20th, in case you missed the live webinar back in February 2022.

To meet the increased demand for converter speed and resolution, JEDEC proposed the JESD204 standard describing a new efficient serial interface to handle data converters. In 2006, the JESD204 standard offered support for multiple data converters over a single lane with the following standard revisions; A, B, and C successively adding features such as support for multiple lanes, deterministic latency, and error detection and correction while constantly increasing Lane Rates. The JESD204D revision is currently in the works and aims to once more increase the Lane Rate to 112Gbps with the change of lane encoding and a switch of the error correction scheme to Reed-Solomon. Most of today’s high-speed converters make use of the JESD standard and the applications fall within but are not limited to Wireless, Telecom, Aerospace, Military, Imaging, and Medical, in essence anywhere a high-speed converter can be used.

Watch the replay here

 

The JESD204 standard is dedicated to the transmission of converter samples over serial interfaces. Its framing allows for mapping M converters of S samples each with a resolution of N bits, onto L lanes with a F octet sized frames that, in succession, form larger Multiframes or Extended Multiblock structures described by K or E parameters. These frames allow for various placement of samples in high- or low-density (HD) and for each sample to be accompanied by CS control bits within a sample container of N’ bits or at the end of a frame (CF). These symbols, describing the sample data and frame formatting, paired with the mapping rules dictated by the standard, allow to communicate a shared understanding of how the transmitted data should be mapped and interpreted by both parties engaging in the transmission.

The 8b10b encoding scheme of JESD204, JESD204A and JESD204B paired with Decision Feedback Equalizers (DFEs) may not work efficiently above 12.5Gbps as it may not offer adequate spectral richness, for this reason, and for better relative power efficiency 64b66b encoding was introduced in JESD204C targeting applications up to 32 Gbps. JESD204D that is following in its footsteps with even higher line rates planned up to 112Gbps utilizing PAM4 PHYs demands a new encoding to efficiently encapsulate the Reed Solomon Forward Error Correction (RS-FEC) 10-bit symbol-oriented mapping.

Deterministic latency introduced in JESD204B allows for the system to maintain constant system latency throughout reset, and power up cycles, as well as re-initialization events. This is accomplished in most cases by providing a system reference signal (SYSREF) that establishes a common timing reference between the Transmitter and Receiver and allows the system to compensate for any latency variability or uncertainty.

The main traps and pitfalls of system design around the JESD204 standard would deal with system clocking in subclass 1 where deterministic latency is achieved with the use of SYSREF as well as SYSREF generation and utilization under different system conditions. Choosing the right frame format and SYSREF type to match system clock stability and link latency can also prove challenging.

Watch the replay here
Also read:

CEO Interview: John Mortensen of Comcores

WEBINAR: Unlock your Chips’ Full Data Transfer Potential with Interlaken

WEBINAR: O-RAN Fronthaul Transport Security using MACsec