by Ahmed Eisawy, Mentor Graphics
Nearly all of today's chips contain Analog/Mixed-Signal circuits. Although these often constitute only 25% of the total die, they may be 100% of the product differentiation and also, unfortunately, 80% of the problems in actually getting the chip to market in a cost effective and timely way. With growing complexity and shrinking time-tomarket Mixed-Signal verification is becoming an enormous challenge for designers, and improving Mixed-Signal verification performance and quality is critical for today's complex designs.
Source: Courtesy of IBS and Dr. Handel Jones
The challenges in mixed-signal verification stem from two opposing forces, time-to-market constraints and shrinking process technologies.
- Force a move to higher levels of abstraction to cope with the added complexity in design
- Can already be seen in digital design, where cell based design is rapidly moving to Intellectual Property, reuse-based, or block-based design methodologies
Shrinking process technologies:
- Because of the increasing significance of electrical and physical effects, there has been a need to verify at increasing levels of detail
- Signal integrity, electro-migration, and power analysis are now adding severe complications to design methodologies already stressed by the increasing device count
CHALLENGES IN ANALOG/MIXED-SIGNAL VERIFICATION
Analog in Digital Verification World
Analog circuits are particularly sensitive to variability, which has a dramatic effect on parametric yield loss. While SoCs remain primarily digital, analog design and verification plus verification at the analog/digital boundary eats up more than 75% of the resources.
More Analog - Less Productivity
The combination of growing AMS design size and complexity with the variability introduced at advanced process nodes threatens mixed-signal chip yield, performance, and longevity. What formerly were second order electrical effects, today are first order and account for yield loss or chip failures. Parametric yield is a critical business issue at 65nm and below.
So for those who are brave enough to develop AMS SoCs, it all comes down to three important questions:
- Will the first silicon be functional?
- Will it be robust, i.e. fully meet the specs?
- Does your full chip fully meet the specs?
- What's your tape-out confidence?
- Will it be reliable, i.e. will it still work 5 years from now?
- So your IC is functional, the yield is great, does it work in Alaska and in the Sahara?
- Some reliability issues are becoming critical from 65nm and below We don't bring a lot to any of the below, like:
- Electro Migration
- Time Dependent Dielectric Breakdown
- Negative Bias Temperature Instability
- Hot Carrier Injection
The overall chosen methodology will dictate much of your AMS design and verification success and the EDA tools you should use.
Which design methodology to choose: "Bottom-Up Flow" or "Top-Down Flow"?
A successful design environment strategy is to build advanced, high quality products based on a system platform architecture that effectively incorporates leading-edge hardware and software algorithms as well as core technology. This strategy provides integration density, performance, and packaging advantages and enables product differentiation in features, functions, size, and cost. In most cases, to fully exploit these opportunities, this strategy requires a transition from a serial or bottom-up product development approach to top-down design.
The bottom-up design approach does have some advantages including focusing on the initial product delivery and allowing work to begin immediately on critical portions of the system. With this approach, however, system-level design errors do not surface until late in the design cycle and may require costly design iterations. Furthermore, while related products can reuse lower-level components, they cannot leverage any system-level similarities in design architecture, intellectual property, or verification environment. Even though Bottom-up still uses the notion of design reuse within the same technology node and across other nodes, migration at this point would be the hurdle. Nevertheless, reuse may not be optimum since a new system may need a new architecture of blocks that may be different from the original design.
The top-down design approach results in higher confidence that the completed design will meet the original schedule and system specifications. The design team can reuse and re-verify alternative designs, packages, or implementations without having to rebuild a new context or infrastructure. With this approach, however, a system-level description is needed which involves knowledge of the system and system-level descriptive language(s) or tool(s).
Which design topology to choose: Analog-Centric or Digital-Centric?
Design topology tries to answer the first basic design question: Will the first Silicon be functional? In an analog-centric case, the design is mostly analog with growing circuit complexity and blocks size which impacts the simulation performance that is not practical any more. Therefore, there is a need to improve the simulation speed and/or design capacity for architecture exploration, design corner validation or regression testing.
The typical environment used in these cases, is the schematic-driven environment where the design entry point is a schematic that then netlisted into either SPICE or HDLAMS language that drives the mixed-signal simulations.
In a digital-centric case, the design is mostly digital with a meaningful amount of analog content and/or behavior which impacts the results accuracy. Therefore, there is a need to improve the simulation accuracy for analog blocks.
When the size of the analog content becomes significant – in an analog-centric flow or a digital-centric flow – then the verification performance will be seriously impacted. Relying only on faster analog solvers to solve the analog content won't help too much. However, using mixed-signal languages (VHDL-AMS and/or Verilog-AMS) would be an interesting alternative to help alleviate this bottleneck.
Using a combination of Fast-SPICE/Faster-SPICE with HDL and HDL-AMS languages would be an interesting alternative (shown at the top of the following page), by keeping as much digital content as possible in HDL and partition "dubious" digital & analog to a smart Fast-SPICE engine – if accuracy criteria can be loosened (if not, then a Faster-SPICE engine might be a better option) followed by some manual partitioning if needed.
The HDL-AMS languages can be used to model the analog blocks by abstracting the effects that are not needed in a given design phase. In an analogcentric flow, these languages can even do a better job representing the entire design hierarchy by translating the schematic views into a netlist that drives the simulation, as opposed to using SPICE as the translating language, typically used in analog-centric flows. This alternative could potentially improve the performance as well as the capacity in the simulation.
The AMS language could be VHDL-AMS or Verilog-AMS. Either language can support a vastly dominant analog content or a vastly dominant digital content, depending on the modeling needs, while keeping the digital, custom logic and/or embedded memory modeled with VHDL/ Verilog languages. Additionally, AMS models can be used for repetitive and/or highfrequency blocks.
The pros/cons of this approach:
- Abstraction improves performance by reducing the SPICE matrix
- Allows staying in the analog world or in the digital world
- Wide Analog modeling scope
- Easy connection to the external world
- Selected Analog effects can be displayed with fidelity appropriate to the problem
- Requires AMS modeling expertise
- Relatively long learning curve
- Accuracy ranges from "Really Bad" to "Excellent"
- Model calibration versus transistor always a problem — critical issue in verification context
- The important question is, did I model the right analog effects or not?
In order to optimize the performance/accuracy tradeoff, different parts of the chip can be simulated by a different technology (as shown in the image to the right). For instance, digital blocks, which don't require high accuracy, can be simulated in digital or System-Level languages to speed up the performance. Chip may also contain IP from another company, which is described in AMS language. Analog blocks can be simulated by SPICE or Fast-SPICE engine for higher accuracy.
The choice of language for the top-level is as essential as the choice made for each block. Moreover, the choice of language for each block will impact the interactions between the various blocks, and hence, the requirements on setting-up these blocks. However, the language choice(s) can be overwritten at various design stages based on the needs, by using design reconfiguration schemes, or even Checkerboard verification.
Top-level language and testbench language
There is a wide range of languages that can be used for the top-level and the language used at the top-level is set by the design topology.
For example, when SPICE is used as the top-level language, the design topology is then called "SPICE-on-Top" design. This topology is most commonly used in schematic driven environments because historically, SPICE was the netlist representation of an Analog schematic. However, with current Analog-centric approaches, when mixed-signal designs increase in size and complexity SPICE is no longer a good option to use. Instead HDLAMS languages should be used to substantially improve performance. In this situation, Verilog-AMS is becoming a common language with its benefit of a highly structured syntax.
Similarly, when SystemVerilog is used as the toplevel language, the design topology is then called "SystemVerilog-on-Top" design. This topology, along with VHDL & Verilog, is the most commonly used in digitalcentric Environments. SystemVerilog is being used in OVM/ UVM setups to build complex testbenches and manage the DUT efficiently. Many extensions to SystemVerilog to address this area are being investigated and implemented.
Extending top-level languages to lower-levels of the hierarchy
Each language has its merits and demerits when used to model sub-systems or blocks in a typical design – In some cases, language choice is a designer preference. Other times, the environment restricts the user to specific language(s) supported by the downstream tools. Switching between languages will increase the complexity of Interface Elements inserted at the Analog/Digital boundary as well as data compilation step (prior to simulation).
If the designer believes that he will need to reconfigure parts of the chip based on the design cycle or verification purposes then planning for this reconfiguration step is important.
Design reconfiguration means switching languages to use different representations for different blocks. These different representations will involve some sort of abstraction to help boost the verification performance. With abstraction, the designer could choose to "mask", "hide", or "suppress" some of the block effects to simplify the model. Simplification of the model leads directly to performance gains.
An important aspect of this process is to maintain good testing coverage to ensure all blocks are tested. However, this is where it gets tricky since you need to test one part of the chip in one test but not the others. How to do that? Well, Checkerboarding could help!
In space, testbenches, Corners and Configurations would constitute the three axes. Checkerboarding would be the plane bounded by testbenches and configurations.
Checkerboard Verification allows the following:
- Systematic divide-and-conquer
- Virtual SPICE accuracy with improved performance
- Independent tests means parallel execution and less waiting
Separating verification code from design code
Separating the verification code from the design code helps keep the design clean from any unnecessary alterations. The separation can be done by a combination of SystemVerilog binding and Net Spy tasks.
SystemVerilog Bind directive is a language construct that allows the user to specify properties and bind them to specific modules or instances.
Binding is needed to keep verification code (e.g. assertions) separate from the design, while still being associated (via Bind directive) with the design code.
By extending the SystemVerilog Binding capability to the mixed-signal domain (by supporting SPICE, Verilog-AMS and VHDL-AMS as the Binding target), the verification code will be able to connect to any part of the design and implicitly instantiate the specified properties within the Target.
Net Spy tasks offer consistent probing capabilities Verilog allows access to any signal from any other hierarchical Verilog module without needing to route it via an interface (i.e. testbench can access signal values using hierarchical notation). This capability fails when a Verilog testbench attempts to reference a signal when the hierarchy includes VHDL, VHDL-AMS or Verilog-AMS models. The Net Spy procedures and system tasks can overcome these limitations and allow monitoring (or, "spying") – and in general "observe" – hierarchical objects in VHDL, VHDL-AMS, Verilog, Verilog-AMS and SPICE models. A Net Spy allows the testbench to probe or force an arbitrary location in the DUT hierarchy. The probed point may be an analog voltage or current, or a digital signal. If the probe touches an analog point then a boundary element is automatically inserted. Thus, the Net Spy will automatically adjust if a digital DUT is replaced with its Mixed-Signal equivalent.
How Can the Mentor Graphics Questa ADMS help?
Questa ADMS can bridge the gap between the analog design world and digital design world with its user-friendly design reconfiguration setup that allows reconfiguring the design during elaboration phase instead of making changes to design files on disk and maintain compatible methodologies between design groups.
Questa ADMS provides the Unified Solution for today's Mixed-Signal designs:
- For Analog/Mixed-Signal designers
- Leverages digital verification tools, robust language support, UCDB, OVM
- For digital designers
- Enables simulation of designs requiring analog content accuracy
- For SoC integrators
- Enables use of a consistent verification environment throughout flow/refinement
INTEGRATING MULTIPLE TECHNOLOGIES INTO A SINGLE MIXED-SIGNAL SOLUTION
Questa ADMS can be integrated with Mentor Pyxis & Cadence Virtuoso Schematic driven Environments, currently used in analog-centric designs with SPICE-on-top or mixed-signal-on-top topologies.
Questa ADMS is adaptable to emerging SoC designs and methodologies. Using Questa ADMS with mixed-signal-on-top topology from schematic-driven environments allows the verification of larger mixed-signal designs that suffers from large analog contents. Verifying these designs with SPICE-on-top topology would suffer performance degradation and would limit design capacity, especially on the analog side. Supporting this topology in Questa ADMS is easily done since it supports all analog and digital languages as well as AMS languages.
Questa ADMS supports virtually all analog and digital languages as well as AMS languages, thus supporting true mixed hierarchies and Sandwich Structures. This flexible architecture allows early design exploration with top-down design approach that can be easily and systematically reconfigured based on the design phase. Questa ADMS also offers 2 types of integrations with Matlab/Simulink that covers the needs for both Analog-centric designs as well as Digital-centric designs.
Improve Analog Verification Quality
Questa ADMS improves Analog verification using the following features:
- Can be used with various SPICE engines: Eldo Classic (SPICE), Eldo Premier (Faster-SPICE) and ADiT (Fast- SPICE) to optimize the performance/accuracy tradeoff
- Built-in optimizer: optimize transistor size based on goals
- Smart Monte Carlo Analysis that converges to user specifications
Extend Digital Domain to AMS Domain
Questa ADMS extends the digital capabilities to the analog and mixed-signal domains:
- Intelligent interface elements management (insertion, power-aware)
- Automatic detection of the analog/digital boundary and allows the user to define criteria for signal mapping
- Support bi-directional ports, solving both sides of a mixed-signal net
- Support power and signal connections used in Power-Aware simulations
- Apply OVM/UVM methodology to mixed-signal domain
- Adding support for analog blocks at the monitor/driver/responder level
- Extending SystemVerilog binding to the mixed-signal domain
- Questa ADMS Bind extends the SystemVerilog Binding capability to the mixed-signal domain by supporting SPICE, Verilog-AMS and VHDL-AMS as the binding target
- Net Spy tasks/ procedures for consistent probing
- Monitor hierarchical objects in VHDL, VHDL-AMS, Verilog, Verilog-AMS and SPICE
- AMS extension to Questa unified coverage database (UCDB)
- Dynamic control of module-level analog precision that can divide a simulation into time windows and allow the user to specify different accuracy parameters in each window
- Interrogating mixed-signal nets by displaying information regarding inserted boundary elements, digital drivers and analog currents associated with the net
- Abstract analog with real number modeling from VHDL, SystemVerilog and Verilog-AMS
- Support for the SystemVerilog Assertion (SVA) sub-language
Analog/Mixed-Signal design and verification is becoming a major challenge in SoC design and requires an increasing amount of dedicated and costly resources. Good engineering has a balance between top-down and bottom-up design approaches but there should generally be a bias towards top-down because the ultimate goal is to meet the system requirements since the balancing force is feasibility. A mixed-signal-on-top topology can be considered as a generalized approach that offers more flexibility than the other two topologies while allowing the user to meet the necessary requirements.
Questa ADMS can be adapted in various topologies supporting the available methodologies with little or no impact on design flow, including analog-on-top, digital-on-top and mixed-signal-on-top topologies. It offers capabilities to help improve the productivity mixed-signal verification flows.
Back to Top