Well DAC 2013 is around the corner, so I guess it is time to blog about it, especially since this is in Austin

 And no, I am not going to tell you about the best BBQ joints or sushi places (yes I did say sushi in Texas) since I lived there for almost 15 years, but I’m going to tell you about our DAC AMS lunch event.

 http://www.synopsys.com/Tools/Verification/AMSVerification/Pages/dac-2013-ams-verification-luncheon.aspx

 We wanted this year to present some of the challenges Synopsys customers face to ensure successful AMS design validation for advanced process nodes. Consequently, our topics vary from low power and reliability to mixed-signal verification and memory characterization.

 Our speakers are industry experts coming from various sectors (SoC, Mobile, Memory, SRAM, etc.) so they will present a very exhaustive landscape of those challenges as well as Synopsys latest flows and features to further tune your current AMS methodologies for performance and accuracy. Now, I am listing below companies, titles and abstracts, that would probably convince you more than a long marketing speech

 Our speakers are (in chronological order):

 Micron – Off-Chip and On-Chip Power Delivery Modeling with HSPICE

 Abstract: Power delivery for a part (be it memory, logic, or otherwise) is of paramount importance, requiring the need to design a Power Delivery Network system which is optimized for the various models of die demand, at the least risk of resonances. Hspice and Finesim are used to characterize the various block models, to spot potential problems and finally to run transient sims to validate AC optimization.

ARM – Overcoming Challenges of FinFET Memory IP using FineSim

 Abstract: FinFET process technology offers significant improvements in performance and power efficiency of ARM-based SoCs. Along with these improvements come many challenges in the design, margin analysis and model generation for advanced embedded memory. During this luncheon ARM will discuss some of the key challenges of FinFET memory development and how Synopsys’ FineSim fast SPICE simulator is used to provide full-featured, high-quality ARM Artisan® memory IP for mobile, network storage and server applications.

 STE- Improve IC-level verification coverage by using assertions with CustomSim-VCS multi-thread real number flow

 Abstract: Time and resources to ensure a good coverage for IC-level functional verifications are growing year after year with design complexity. There is, therefore, a need to reduce simulation setup and analysis. Discovery-AMS with VHDL Real Number approach permits to maximize and accelerate verification coverage by creating easily co-simulation setup and taking advantage of FastSPICE multithreading.

Broadcom- Advanced Memory characterization using FineSim for performance and accuracy

Abstract: Broadcom has developed a complex internal flow to create and characterize compiled memories that are used throughout their production chips. This flow highly leverages Synopsys’ flagship simulators FineSimPro and FineSimSpice. The simulators are used to characterize the memory for three distinct needs, timing, power and leakage. BRCM fine tunes FineSim technology to give the required accuracy/performance needed for each area of characterization.

ST : Aging model implementation using MOSRA API flow from HSPICE to CustomSim

 Abstract: An innovative platform of reliability simulation including all front-end wear-out mechanisms is presented. Customized physics-based models of Bias Temperature Instability (BTI) and Hot Carrier Injection (HCI) are implemented in MOSRA. The aging models are developed for HSPICE simulator and extended to FastSPICE CustomSim. Aging simulation with CustomSim is a promising solution enabling the robustness assessment of large circuit and providing both accuracy and speed.

Because we wanted to offer a depth and breadth of understanding of verification challenges and related solutions, this AMS lunch-on should be extremely valuable to anyone involved with advanced AMS verification.

Hope to see you there!

Blog on Wednesday, Happy hour on Friday

I recently got several opportunities to discuss with many verification-driven companies on their needs for a powerful regression testing and verification environment. As such, in this post, I decided to show some features of Synopsys CustomExplorer Ultra (also labeled as CXU) that directly address your verification needs.

Synopsys CustomExplorer™ Ultra (CXU), is a GUI- and netlist-based verification platform that helps automate Verification regression tests without manually creating different configuration files or scripts.

CXU being a very versatile platform, you may have seen already several success stories on its use model:

http://blogs.synopsys.com/analoginsights/tag/customexplorer-verification-platform/

http://blogs.synopsys.com/analoginsights/2012/10/05/optimizing-your-mixed-signal-verification-environment-using-customexplorer-ultra-part-1/

http://www10.edacafe.com/blogs/analoginsights/2012/11/01/qa-st-drastically-decreased-turn-around-time-for-their-technology-validation-flow-using-synopsys-custom-explorer/

That time, we will be focusing on regression testing. I have asked Paul Chapman to show us a demo and comment on his user experience.

Paul Chapman is currently working in Synopsys as a senior application consultant. After 10 years of mixed signal design at board level and full custom chips, he joined Analogy, an EDA company, in 1996 as an application engineer, worked for Avant! (hspice ), Neolinear ( Neocircuit Circuit sizing / optimization ), Cadence ( Virtuoso ), CSR (analog CAD), Magma ( Finesim), and finally Synopsys.

Glad to have you on board Paul

Q- Bonjour Paul ! Regression – it’s a word that brings few happy thoughts, especially for AMS Designers. As an EDA user that has been exposed to multiple environments, can you share some insights with us ?

Bien sur Helene . We think of ourselves as a creative bunch; a fascinating blend of inspiration and the technical ability to take our ideas beyond dreams into everyday practical reality. However the true value of our designs is not when everything is good, but how they cope when temperature, chemistry and old age are against them.

With modern concurrent design methods and processes far more ECO’s happen late in the design cycle. Regression testing is what tells you if your design has unexpectedly degenerated, and so is very much needed to reduce the risk of a re-spin, or low production yield. Testing (boring) then documenting (more boring) is not why we chose to be engineers. Even a simple analog block needs dozens of tests to verify it across corners. All the AMS blocks of an SOC can easily reach many thousands of tests – too many for existing design environments. With reuse of IP and layout dependent effects we should verify the golden data – the netlists – that drive both simulators and physical implementation, but then cross-probe to schematics when available.

Q- Being an expert user of verification environments in general and Synopsys CustomerExplorer Ultra (CXU) more specifically, can you further comment on its capabilities as a regression environment?

Two of the objectives of Custom Explorer Ultra (CXU) are to make running tests relatively painless, and if a failure is found to help quickly find the cause. The demo shows setup and testing of a simple block. Results of the tests are collated and exported to standard office tools for reporting.

Make a habit of adding each block to your tests, and you don’t need to fear that changes of design or PDK have regressed your creation back to a knuckle dragging Neanderthal. An overnight run will easily confirm all is well, or point the way to where you need to make an adjustment. Although we have limited this example to pure analog block, CXU supports mixed signal simulations and Circuit Check analysis to provide comprehensive verification.

CXU also includes multiple features and flows that help keep the tedious bits to a minimum, and giving you more time to dream and create, or just get home before my dog gets my dinner !

Thanks Paul !

You can find more information on CustomExplorer Ultra at:

http://www.synopsys.com/tools/verification/amsverification/designanalysis/pages/customexplorer-ultra.aspx

More info and videos to come on CXU soon. Meanwhile, feel free to contact me anytime or append your well appreciated feedback

If you have been following my blog, you may have noticed a couple of posts on FinFET technology, mostly on the modeling side. I recently worked with the WMED committee to look at innovative subjects (especially for those spots after lunch time ). One topic we selected was the challenges faced by analog and digital designers when using a FinFET based process.

WMED stands for IEEE Workshop on Microelectronics and Electron Devices and will occur on April 12, 2013, at Boise State University, Boise, Idaho.

http://www.ewh.ieee.org/r6/boise/wmed2013/WMED2013.html

In this post, I am interviewing Victor Moroz about his guest talk at WMED on FinFET variability and its impact on digital and analog circuits.

Dr. Victor Moroz is a Synopsys Scientist, engaged in a variety of projects on modeling 3D ICs, transistor scaling, FinFETs, stress engineering, solar cell design, innovative patterning, random and systematic variability, junction leakage, non-Si transistors, and atomistic effects in layer growth and doping. Several facets of this activity are reflected in three book chapters and over 100 technical papers, invited presentations, and patents. He has been involved in technical committees at ITRS, IEDM, SISPAD, DFM&Y, ECS, IRPS, and ESSDERC.

Q- Victor, you are deeply involved with SYNOPSYS and major foundries/semiconductor companies in our FinFET initiative. Can you describe SYNOPSYS leading role in this area?

Synopsys is involved in three different stages of FinFET chip development: a) providing tools and services for modeling and optimizing FinFET technology, b) providing tools and services for synthesizing, routing, and simulating FinFET circuits, and c) creating FinFET circuit IP for digital and analog chips. The FinFETs bring a number of benefits, but also several FinFET-specific issues that need to be carefully managed to achieve a good combination of performance, cost, manufacturability, and reliability. Early engagement with the major foundries/semiconductor companies ensures a smooth transition from planar MOSFETs to the FinFETs.

Q- Your talk is about FinFET variability and its impact on analog and digital designs. Can you tell us a little more about it? How is SYNOPSYS addressing those as a leading EDA provider?

Transistor variability is a key factor standing in the way of reducing power consumption in mobile devices. Typical three sigma Vt value for a narrow 28 nm planar MOSFET exceeds 150 mV. The circuit has to be able to handle the entire transistor population, ranging from the leaky transistors with low Vt to the hard-to-turn-on transistors with the high threshold. The low threshold side of the distribution is defined to meet the static power consumption spec and the high threshold side of the distribution defines the minimum possible power supply voltage Vdd. Any reduction in the threshold distribution width directly translates into reduction of Vdd, which affects dynamic power consumption as Vdd^2.

The dominant threshold variability mechanism for planar MOSFETs is random dopant fluctuations (RDF). For the first generation of FinFETs with doped channel, the RDF is still present, but at significantly suppressed level due to the tighter gate control. However, several new FinFET-specific variability mechanisms enter the picture. Subsequent FinFET generations with undoped channel will experience rise and fall of the major variability mechanisms, notably those related to geometry and patterning fidelity. The dominant RDF variability that you see in the planar MOSFETs is inevitable, because it is impossible to control positions of all the dopant ions in the channel. Therefore, it was imposed on the entire industry in a very similar way as there is not much you can do about it. On the contrary, the geometry-related variability mechanisms that are dominant in FinFETs, can be continuously tightened by perfecting the semiconductor manufacturing equipment, such as etching, deposition, lithography, epitaxy, and other critical process steps that define the shape and the size of the FinFETs.

The impacts of FinFET variations on the digital and analog circuits are substantially different. These differences define the distinct approaches in handling variability in analog and digital circuit design.

Q- Synopsys is currently working with major design houses. Moving forward, do you see a large deployment and use of FinFET technology for low power designs and advanced process nodes? What are the main compelling factors?

Yes, we definitely see a big role of the FinFET technology for low power designs. The main compelling factors are the reduced random variability and the improved short channel effects leading to better scaling potential w.r.t. the planar MOSFETs. There is a significant hurdle to develop the FinFET manufacturing process that requires a huge effort. Once the hurdle is cleared, the FinFETs will enable scaling for the next several technology nodes.

Hope you enjoy Victor’s interview!  If you would like more information, I am listing below the link to WMED conference technical track:

http://www.ewh.ieee.org/r6/boise/wmed2013/Technicalprogram.html

Attractive title, isn’t it?   I wanted to share with you some benchmarks we conducted with key partners using Discovery-AMS multi-core technology. This feature is available in 2013.3 release for Mixed Signal Verification and allows you to considerably speed up your simulation. Two key advantages of Discovery-AMS are performance and versatility. By combining the efficiency of a Fast-Spice solver with multithreading, we were able to boost performance up to 10X.

We implemented this feature first in CustomSim/Xa then Discovery-AMS. Using a revolutionary technique based on Newton-Raphson, CustomSim/Xa can significantly speed up large partitions on multiple CPUs without loss in accuracy. CustomSim/XA multi-core’s major target is Analog Circuits with Large Partitions and Synchronous Groups.

During our beta testing, XA’s Multi-core technology showed the value in the simulation like IREM, high accuracy full-chip simulation and final full-chip verification. Those simulations usually take 2 or 3 days; with multi-core technology many of our beta customers could complete their simulations within 1 day.

Here is for example one comment from our initial beta testers within our Solution designs Group regarding our FastSpice feature for Analog designs (CustomSim/Xa  only):

“We use XA only for top level transient analysis. We see that simulation speed up is proportional to the number of cores we are using, eg simulation is ~8 times faster if we use 8 cores. This mean that we are able to simulate top level within one week – without mt CustomSim/Xa simulation is running ~ 30 days. “

In this post, ST Ericsson demonstrates a similar significant performance trend on a PMU (Power Management Unit) while using Discovery-AMS for Mixed Signal verification. I asked Francois Ravatin to share his honest and unbiased opinion (yes, I promise:)) on this new feature.

Francois Ravatin has joined in 1994 Thomson Consumer Electronic Components (ST Microelectronic – Thomson Multimedia joint venture) in digital libraries and tools support team. In 1998 he joined ST Microelectronics as analog mixed-signal designer in Wireless division and then Display division. He moved in 2007 as AMS verification engineer in analog & RF design flow group at ST Ericsson.

Q – Can you describe the results you have seen using Discovery-AMS multi-core technology?  Did it further improve your verification flow?

Our Discovery-AMS flow is based on a spice on top netlist. The design under test (DUT) is spice with leaf cells in VHDL-RN for analog IPs and Verilog or VHDL for digital RTL. The stimulus is define in VHDL-RN. The figure1 below describe one of our scenario used in our flow.

Figure 1: spice on top flow description

So stimulus VHDL-RN is driving:

• All ports of the DUT :
  • All analog and digital signals with sources.
  • Interface : serial links (I2C, SPI), USB.
• External components values (R, L, C, etc values)
• Spy analog and digital nets in the DUT to create assertions.

Early this year, Synopsys give us the possibility to test multi-core on Discovery-AMS Real Number flow. I decided to try it on a complex PMU to increase the coverage verification. Our verification process includes different scenarios where we mixed on demand transistor and digital blocks. What we know is that adding more and more sensitive spice Analog IPs as DC-DC increased the runtime therefore our first test was to have all the DC-DC in spice then check the runtime. I did not observed any accuracy degradation and the gain was around 3.5x on #12 cores.

Several tests had been done on this test case with different core numbers. Results are below:

After this first promising result I decided to fix the measuring rod higher by adding the digital core in spice too. Such configuration includes now around 1.3 Millions of transistors for a total of 5 Millions of devices.

The figure below represents CPU time versus transient time.

Figure 2: multi-core vs one core comparison

Yellow/white curve defines the CPU time using one core as the green curve refers to the one using twelve cores.

How to interpret such slope modification? :

Technically speaking high clock frequency starts at 37ms, propagated directly into the digital core. New event as DC-DC power-up appeared also at 38ms. Those additional extra activities can be immediately observed by looking at the different slope values after 37ms and even more at 38ms. Green curve slope did not change in the same range than the yellow one, this show the efficiency of multi core.

At the end, run time in single core was close to 27 days (estimated) and less than 9 days with #12 cores. We observed here again a 3X speed up even if the total number of transistors increased by 2x compared to the first test. Nine days is a very short run time regarding the complexity and the activity of the test case .

Speed up is directly dependant on two points; this first one is the partitioning and more precisely the number of devices into that large partitions. The second point is link to the test bench itself and how it reacts with those partitions, which means do we have or not activities in such parts!!! Considering these two conditions met, multi-core take all the power so you will probably adopt it as this kind of verification has to be done generally just before the tape out where every day is crucial wins.  This improvement of “full spice” simulation (test bench still in digital) open a new area of verifications before tape out but also useful for design debug after silicon validation.

Q- Besides performance, did this feature allow you to further improve your verification methodology?

Yes, in our case multi-core is complementary with VHDL-RN modelling. The goal of models is to speed up simulations to achieve complex sequences with an acceptable run time by using a linear model of switched blocks but, some functionality can be missed as behavioural models may lead to spice misalignment. So there is a need to check the blocks start-up in spice at IC level to require matching the silicon measurement reference, which might not be the case when verification is done at IP level. Multi core first results are promising, we will continue in this way for the future.

Q- Have you tested Discovery-AMS multi-core technology on other circuits? Which performance gain did you see?

Yes, after the PMU this new technology has been tested on other designs type as for example a display which includes a PLL. The gain was even more impressive as we reach a 6.6X speed up improvement on #8 cores (from 32hrs to less than 5hrs). Such number allows us to have several runs into a single working day which is really a key point.

Q- A lot of EDA Fast-spice simulators require extensive and circuit specific settings. Can you comment on ease of use? When testing this feature, did you spend a lot of time setting simulator options?

Clearly it was another point for us to test and this is what we have done on a high sensitive analog design where we have changed our current CustomSim setting (local setting on IPs) by only one command (global setting). Results were really positive as we reach a 2x performance improvement using #8 cores.

Merci Francois !

I hope you enjoyed this post. As usual, comments/questions/feedback are welcome.

Yes it is Thursday again

We had another successful event on Mixed  Signal Verification at DVCON 2013. Because DVCON is a conference focusing on Digital Verification, Martin Barnasconi and I were able to showcase Mixed Signal Verification from a traditional/Analog Standpoint to a more Digital/Systemlevel approach. I posted a few weeks ago a description of our tutorial (see below), I therefore wanted to give you a summary as multiple topics and opinions were shared.

http://blogs.synopsys.com/analoginsights/2013/02/21/must-see-user-experiences-tutorial-on-mixed-signal-verification-at-dvcon-2013/

With that in mind, I have asked several of our speakers (see names and affiliations below) to give us their insights and impressions on this event:

Christophe Curis – STMicroelectronics

Ozan Erdogan – Maxim Integrated Products, Inc.

Martin Barnasconi – NXP Semiconductors

Thilo Voertler – Fraunhofer IIS

Thang Nguyen – Infineon Technologies AG

Q- can you summarize in a few lines (less than 4 sorry )  your presentation on Mixed Signal Verification and the challenges you are trying to address?

Christophe Curis

Christophe (ST):The complexity of the IPs we are developing for modern SoC is increasing, growing from analog design to analog and digital interwoven. My presentation tried to present one of those small systems, which has a strong focus on analog, thus requiring more complex mixed-signal environment for its validation, with the performance versus accuracy challenge to address for designer’s reactivity needs.

Ozan (Maxim): The biggest challenge in mixed-signal SoC verification is the time it takes to run full chip simulations. I presented a methodology for speeding up functional verification of mixed-signal chips by modeling analog sections in SystemVerilog.

Martin (NXP): For automotive products, it is essential to guarantee a fail-safe IC implementation, compliant with the system specification. Therefore verification both at the system- and IC-level becomes very important, which should also include the interaction between the analog, digital and software functions.

Thilo (Fraunhofer IIS): At Fraunhofer and together with our “Verdi EU project” partners, we are working on a new verification methodology, especially targeted at the verification of system models using SystemC/AMS. In addition this new methodology will bridge the gap between simulation based verification and measurement oriented lab validation.

Thang (Infineon): The tutorial presents a hardware assisted verification approach using FPGA and AMS test chip. The approach proves to overcome those mixed-signal verification scenarios which simulation is not suitable, e.g.: long-term test (up to 5 hours of system operational time) with millions of sensor frames (analogue format) transmission. The approach is also used to accelerate the verification and lab validation.

Q- Looking at this tutorial, it is clear that Mixed Signal Verification landscape is fairly vast and may require different flows depending of your design and industry needs.  In your industry, how do you see the future of Mixed Signal Verification evolving?

Christophe (ST): In the domain of mixed-signal IP development, the AMS extensions to the languages is already providing a number of solutions to today challenges, yet its usage will have to expend more amongst designers. There will be a need to ease the use of these technologies to help conceiving future IPs, which will integrate more and more complex analog and digital interacting together and better flow support.

Ozan Erdogan

Ozan (Maxim): As the chips we are building gets more complex, we will use a mix of tools to achieve first silicon success. At top level high level languages, such as Matlab, can be used for quickly exploring the design space, in the next level implementation assumptions can be checked with analog behavioral languages, such as Verilog-AMS, and for full chip verification we will see more and more behavioral modeling for pure digital simulators for speed.

Martin Barnasconi

Martin (NXP): Mixed signal verification approaches will more and more use techniques inherited from the digital verification domain, like functional verification approaches based on UVM. However, we still need to extend and customize these digital-centric methods, as we deal with analog, continuous-time functions. Besides some language challenges, we also have to learn how coverage-based and assertion- based techniques can be applied in the mixed-signal domain.

Thilo (Fraunhofer IIS): To understand and verify AMS designs at the system level, we see that simulation speed and model complexity are the key challenges to scale verification to larger designs. Therefore easily understandable and fast behavioral models are needed e.g. written in SystemC/AMS. On the verification methodology side support for digital techniques like UVM should be integrated to allow the reuse of existing VIP.

Thang (Infineon): Complex mixed-signal SoC products with high number of functionalities integration has also recently become a trend for automotive electronics industry in the future. The verification in such automotive SoC product is even more challenging as there are still a high number of analogue interfaces to the physical world and a number of the application has to deal with the new safety standard ISO 26262, e.g.: braking, airbag, electronic power steering system, and etc. Verification of such product in the context of ISO 26262 does not only to comply the specification but also to functionally verify the product in its application circuit with sensors and actuators. As well as, time-to-market and first time right design are key requirements in project to win customer and market share. For the future of Mixed-Signal Verification, a right verification strategy and a comprehensive combination between different tools and methodologies – e.g.: from classical approach of mixed-signal simulation with directed test, to using advance methodologies UVM/UVM-AMS or FPGA and emulation platform – will become crucial skills. The acceleration of verification and validation will become also an important topic in the future as the product complexity is increased while the cost per silicon area is decreased.

Q- Besides the fact that your track organizers are plain awesome , do you have any takeaway from this tutorial you would like to share?

Christophe (ST): It has highlighted that there are two trends in AMS modeling, the big system world (SoCs) which can tradeoff the accuracy of analog modeling in AMS (through real numbers) for performance due to the size of their systems, and the mixed-signal IPs which can benefit from lower-level, more accurate modeling to better validate the interactions between analog and digital blocks in small systems.

Ozan (Maxim): We received some great questions from the attendees, it was clear that the tutorial was very relevant to today’s mixed-signal SoC verification challenges. It was great to see such a variety of verification approaches in one tutorial.

Thilo Vortler

Martin (NXP): I noticed that the leaders in mixed-signal verification start using object-oriented languages like SystemC and SystemVerilog to get the job done. There is clearly a need to have more expressive languages to create advanced mixed-signal testbenches and also offer features to further abstract the analog signals. It becomes clear that only real-value-modeling is not good enough.

Thilo (Fraunhofer IIS): Coming from Fraunhofer, a research organization with the mission to bring newest scientific results into industrial practice, it has been a great experience being to DVCon and getting lots of feedback from industrial users but also having the chance to talk to EDA vendors

Thang Nguyen

Thang (Infineon): The tutorial session was very information and successful. It did cover a wide range of challenges related to mixed-signal verification within different industrial applications. Even though digital verification becomes more and more dominant, I would stress out that mixed-signal verification will still be a challenge in the coming years, especially for automotive electronics industry.  This tutorial session should be kept running so that authors with different application back-ground could share their end-user experience in the field of mixed-signal verification.

Thanks to our speakers for their valuable insights. If you have any comments/questions or are interested in this tutorial, please let us know.

Hope to see you next year !

Blog post on Thursday, Happy hour on Friday… so I had to release it today:)

We had a few weeks ago a very interesting and interactive panel on AMS Behavioral modeling at DesignCon. I therefore wanted to share this discussion with some of you that may have not been able to attend. Behavioral modeling for AMS being a very wide topic, I wanted to ask questions pertinent to Analog, Mixed-Signal and RF to see if we could draw correlations or some high level common themes between domains. With that in mind, I asked to our panel attendees a series of questions aiming to generate some reaction in our panel as well as in the audience. It looks like it worked

The panel description can be accessed at:

http://designcon.com/santaclara/conference/tracks.php?session_id=269

I have asked two of our panelists,  Shayan Farahvash and Richard Shi, to share with us their answers to some of the topics discussed. I am always interested to hear your comments and thoughts so feel free to add anything to this post.

Shayan Farahvash is a senior principal engineer with Maxim integrated, where he is in charge of architecture selection, product definition and algorithm development for cellular transceivers and radio tuners. Prior to Maxim, Shayan was with Hughes and RFMD, where he led transceiver and synthesizer development from sub 1-GHz to millimeterwaves. Shayan also established mixed signal verification flows in RFMD using behavioral modeling in Simulink, ADS and System Verilog. He holds a PhD from Penn State University and he has been granted two US patents with several more pending.

Richard Shi is a founder and CTO of Orora Design Technologies, Inc, where he leads a team pioneering automated analog abstraction for mixed-signal design and verification.  He is also on leave from the University of Washington where he is a professor in Electrical Engineering. He is elevated to a Fellow of IEEE for his contribution to computer-aided design of mixed-signal integrated circuits, and has worked on SPICE and behavioral modeling since 1983.

What was your main motivation for using behavioral modeling? Top down design approach for first path verification? Performance?

Shayan: Performance verification is rarely a reason to perform behavioral modeling, specially in  wireless applications. Behavioral models, very appropriately,  only capture some operational aspects of a high performance analog/RF circuit, so they are a poor substitute in brute-force circuit simulation with all the layout parasitics included. On the other hand, verifying the functionality of a high-performance circuit, specially as a part of a larger system, is unnecessarily complicated without using behavioral models.

Richard: Behavioral models were firstly used for top-down analog design, and recently we have seen from our customers the increased use of behavioral models for first path verification, both functionality and performance. Automated behavioral modeling is emerging to bridge the gap between top-down design and bottom–up verification. This is especially true for 28nm/20nm mixed-signal system-on-chip design.

How long is too long for a verification/top level simulation run? At what point do you decide to look for behavioral modeling to speed up your simulation and gain performance versus accuracy?

Shayan: If objective is performance verification, then simulation time is irrelevant: you simulate as long as it takes. This rule is generally applicable except for PLL’s, where circuit simulation has scale of weeks instead of days. For PLL’s, some sort of combined behavioral and circuit models is the optimal choice. To say the obvious, this has to be done carefully. For instance, if you model frequency dividers don’t forget to about their additive jitter.

Richard: We have seen that our customers run a verification/top level simulation for one month at 20nm/28nm nodes! The wish is 1 day for verification. The key issue is to increase the simulation coverage of various configurations, where at this moment, designers typically run simulation for 1 case. Behavioral modeling is essential to speed up the simulation. Behavioral modeling can be very accurate but with less unwanted details.

Who should write behavioral models?  Designers? Verification engineers? Modeling experts?

Shayan: Designers for sure. No one else has the intimate knowledge of a circuit to write a behavioral model for it.  Delegating this responsibility  to verification engineers is highly inefficient because they must first understand the subject circuit and then work with a designer to ensure that the behavioral model captures the essence of that circuit. This is a long and error-prone process. Instead, verification engineers must focus on functional verification at top level and report any non-compliance to designers to see if it was a symptom of a real circuit defect or a mere modeling error.

Richard: For verification, behavioral models shall be generated from schematics or post-layout netlist by designers using automated tools, and shall be qualified by verification engineers. Modeling experts will be responsible for setting up the methodology together with designers and verification engineers. For top-down design, designers shall write models as specification incorporating verification requirements from verification engineers, with the assistance from modeling experts.

How do you deal with true mixed signal blocks and circuits: model it in the analog domain, in the digital domain, or really in both domains? Which factors do you use to determine architecture and flow to use?

Shayan: The best approach is a mixed one: combine digital and analog models. RTL languages are a poor vehicle to write a behavioral model for an analog circuit since they don’t have the primitive constructs for a mathematical model of an analog/RF circuit. Similarly, VeilogA  has a very limited capability to model binary, event-driven, discrete time systems.

Richard: We predict that the future of mixed-signal modeling will be at the two extremes: (1) digital on top, then analog blocks will be modeled using Verilog-D/REAL, simulated and verified by digital simulators, and (2) analog on top, both analog blocks and digital blocks will be modeled in Verilog-A, and simulated by high-performance analog simulators. Purely digital simulators and purely analog simulators will dominate mixed-signal verification, as enabled by automated bottom-up behavioral model generation from SPICE netlist. We continue to believe that the future of mixed-signal simulation and co-simulation will be limited.

How do you see behavioral modeling evolve in the next five years for Analog, RF and Mixed-Signal?

Shayan: We will see that behavioral modeling becomes an integral part of the design flow. Today, such models are generated and used in system-level verifications on a “need” basis. Every increasing complexity of the coming analog/RF chips combined with ever increasing development cost and low tolerance for failure because of “silly” mistakes will foster an environment that makes the behavioral modeling and system-verifications compulsory.

Richard: In five years, behavioral modeling will be used by every analog, RF and mixed-signal designer, and automated behavioral modeling will be ubiquitously embedded in every step of mixed-signal design flow. All the leading simulators (analog, digital and mixed-signal) will have the robust support of behavioral modeling languages.

Thanks again to our panel attendees for giving us such a great session.

DVCON tutorial summary report will be next

Happy Thursday !

I have been asked to be co-chair at DVCON for a tutorial on Mixed Signal verification (yes, what a surprise ) in collaboration with Martin Barnasconi, from NXP. We therefore use the best of our brain cells to put together a tutorial that highlights the latest innovations in Mixed-signal design and verification. I have listed the link below to this event:

http://dvcon.org/2013_event_details?id=144-4-T

Because DVCON is a conference focusing on functional design and verification, we recruited experts to talk about the latest advancements in mixed-signal design and verification as well as current and future challenges they foresee. Topics in this tutorial cover the application of the Universal Verification Methodology (UVM) in the mixed-signal domain, usage of VHDL-AMS or Verilog-AMS for AMS verification, and the introduction of mixed-signal features in SystemVerilog or SystemC to enable verification at the system-level. Whether you are working on extending your digital verification methodology to AMS or looking for ways to improve performance of your analog flow by leveraging digital verification techniques, this tutorial is a must see.

Our speakers are (in chronological order):

Henry Chang – Designer’s Guide Consulting, Inc.- Common Mistakes Made in Analog Verification

Jonathan David- Qualcomm – The Mixed Signal Verification Challenge

Christophe Curis – STMicroelectronics – Mixed-Signal Validations for a BIST on ADC

Ozan Erdogan – Maxim Integrated Products, Inc.- SystemVerilog Modeling for
Mixed-Signal SoC Verification

Martin Barnasconi – NXP Semiconductors – AMS system-level design and verification for automotive applications

Thilo Voertler – Fraunhofer IIS- Mixed Signal Verification and Validation for SystemC/AMS

Thang Nguyen – Infineon Technologies AG – FPGA and AMS Test chip Approach for complex SoC product design and verification

The order is fairly logical: we start with analog verification challenges (Henry) , continue with  mixed signal verification using a traditional behavioral modeling  approach (verilogams- Jonathan/vhdl ams- Christophe) and  SystemVerilog/ real number modeling (Ozan). We would conclude this user experiences tutorial by looking into more advanced topics (systemC –AMS, Martin and Thilo) and finishing with a more hardware centric approach (Thang).

Each user would present his methodology for 20 minutes, followed by a Q&A. We will then wrap up the session with a general Q&A where pro and cons those approaches would be discussed and compared.

By offering a depth and breadth of understanding of a full spectrum of current and developing technologies, I believe this tutorial would be extremely valuable to anyone involved with Mixed signal verification.  We had a very animated panel at DesignCon on behavioral modeling, so I am hoping to reproduce the same dynamics for this Mixed signal Verification tutorial

Hope to see you there !

I know you all have been waiting for this blog to be back up

Well the first post of this year is going to be on DesignCon. Being the chairman for the AMS track, I wanted to create, in addition of the track, some specific events that would relate to behavioral modeling. Behavioral modeling is a vast topic that can be approached through different angles, specifically at a conference as broad as DesignCon.

I put together two events, a tutorial and a panel,  and I got fortunate to get industry experts to present and discuss each domain. I am listing below information for each event.

The tutorial can be accessed at:

http://designcon.com/santaclara/conference/tracks.php?session_id=268

As you can see, we are adopting a progressive approach starting from IBIS/spice model , then migrating to a more system level approach (matlab) and concluding with behavioral modeling specific to mixed signal/digital verification (verilogA/AMS, real number modeling). I have interviewed below our speakers to give us more insights on their material.

http://www.edn.com/electronics-blogs/exploring-the-ams-universe/4405689/Behavioral-Modeling-Approached-for-Analog–Mixed-Signal–and-RF-

The panel will then conclude our AMS track by discussing those approaches, the motivations behind behavioral modeling but also its future.

Some of the questions:

•Who should drive the next steps in behavioral modeling? Users themselves, EDA / board companies, standardization bodies, or all together?

Considering some of those modeling styles compete with each other and we will have experts in each area in the room, we should have a great panel

Well, it has been a while, hasn’t it? No, I have not been lazy, I have just been busy working on Synopsys amazing portfolio of simulators.

I attended last week MTV (Microprocessor Test and Verification) conference in Austin (and no, that was not a music festival, sorry..), and participated in a panel on Mixed Signal Verification:

http://mtvcon.org/advance-program/

The panel included professionals from Design Houses, EDA vendors as well as Universities. Our goal was really to discuss about Digital verification extended to Mixed signal domain and current advantages and pitfalls in both simulation and environment through two main questions (I have listed those below).

This was a really good discussion as panel attendees were coming from different backgrounds and have various views and insights.  I am sharing with you some of the answers I gave earlier as well as some comments from other attendees. Feel free to comment.

Question 1:  Can mixed-signal functional verification be done effectively today without an analog simulator?  Is it possible in the future?  What pieces are missing?

Can be done – Yes; Effectively- No

Verification of mixed-signal IPs can be done using a digital simulator only. It is possible today by using technologies based on real-number modeling. Real number modeling is offered today by VerilogAMS (wreal), SystemVerilog (real) as well as VHDL (real).

In Real number modeling, analog voltages are represented as a time varying sequence of real values. So there is no voltage vs current equations or no Kirchoff’s laws being checked – the output is directly computed from the input, without taking in account currents or drive/loads conditions .

This provides satisfactory results for metrics that are digital centric, i.e. when you want to ensure the IP behaves properly, that it is functionally correct and that its features are fully exercised.  In this case,the concept of RNM provides system verification with a fraction of the time, compared to a spice/fast spice approach.

Now if you are interested in current and power consumptions, voltage and current spikes, noise, IR drops and other types of analog measures, you can’t use this approach. You will have in this case to switch to a spice or behavioral modeling approach.

As such, it is fairly common today to see a mixed flow of RNM, behavioral modeling , and transistor-levels. Designers will use RNM as much as possible to take advantage of the speed up of digital simulation and model a few blocks using behavioral modeling when accuracy is required.

While one attendee did describe a mixed signal flow based on RNM only, most attendees seem to agree on the existing limitations of a Real Number Modeling only flow for a top level Mixed Signal verification.

Now, to answer those limitations, there is more and more work in this area to extend digital model languages such as System Verilog or System C with ams constructs that would provide more and more analog capabilities.

For some of you interested in this topic, I am co-chairing a tutorial with Martin Barnasconi  (NXP Semiconductors) at DVCON on this topic (finalizing speakers as writing J)

http://dvcon.org/2013_event_details?id=144-4-T

2- Digital debug tools often ignore the mixed-signal case.  Are the current tools adequate if there is no analog simulator in the mix? Are the increasingly complicated system/board level constraints changing the answer to this question?

For an entirely digital simulation, including RNM,  digital debugging tools which allow graphing, single stepping through the code, stop-points in the code,… seem to be adequate. Kai Yang from SpringSoft (now Synopsys) did provide a good description of their digital debug tool capabilities.

If today, the digital debug tools are getting enhanced for mixed signal, (at least for common waveform dumping or for post-processing ) , there are still many short comings.

The main reason is that analog and digital designers come from two different environments. From a  high level standpoint, you can refer to a digital flow as being tcl/script based and an analog flow as schematic driven. A digital designer will talk about coverage and regression tests while an analog designer will refer to  assertions, PVT and montecarlo. So there are clearly two different methodologies that need to be consolidated.

One example, mixed signal verification is done using either Spice testbench or Verilog/AMS testbench and correctness is assessed using waveform comparison or measurements. To answer capacity and performance needs of today mixed-signal verification, you need to do more automated self-checking test for mixed signal design: for a better productivity, digital test bench (constraint random test generation) and self-checking assertion methodology needs to be applied on mixed signal design. Synopsys fast spice simulators provide a portfolio of circuit check commands which can be used for verification ( the earlier STE blog post on CustomSim CCK is a good technical example). However, generally speaking, Spice, as a language, does not provide behavioral constructs, which are needed to write proper checker in a concise way.  Another approach is therefore to get analog voltages as real numbers from spice into digital domain and then use all digital behavioral constructs to write a proper checker. With System Verilog assertion language, it is then possible to write advanced checker very concisely. Synopsys has developed an AMS testbench flow based on this principle, where you apply digital techniques to optimize mixed signal verification.

So in order to answer performance and capacity needed by today mixed signal verification, EDA companies clearly to consolidate methodologies.

That’s it for now. As always, your comments/constructive criticisms are more than welcome.

You may have watched the previous video I posted on CustomExplorer Ultra (if not, it is not too late ). A very interesting feature of this tool is its Waveform comparison capability.

This utility allows you to compare two sets of simulation runs in batch and produce a text report of the differences. In just a few words, you define a simple rules file that controls the comparisons, what signals are to be compared and the tolerances of the comparisons. Using sample-based comparison techniques, CXU compares golden-to-target simulation results and provides validation results.  You are going to tell me, nothing really revolutionary here.. So let me just give you finer details

Because CXU is a verification platform supporting multi test-benches as well as simulators, you can use this utility in multiple ways:

- In a multi-testbench configuration, you can compare your master set of data to any number of other tests. Similarly, in a multi-sweep configuration (parametric, corner etc.), you can also validate all your runs to a golden set of data. If you are a verification engineer, you can eliminate the vast majority of manual “eyeballing” of analog or digital signals. Some of our users have reported reducing as much as one full week of manual effort to 15 minutes for analyzing 100 analog waveforms.

-  Because CXU supports multiple Synopsys and third party simulators as well as data formats, you can compare a golden set of data (of course HSPICEJ) to different simulators runs. This feature is especially useful for CAD engineers, dealing with multiple vendors and tools.

- Other interesting point for Mixed-signal designers, you can validate your results versus a golden set of data across both analog and digital domains. You can for example compare analog to analog, analog to digital or digital to digital. Similarly using CXU hierarchy editor, you can toggle views at the leaf level (for example schematic versus Verilog-AMS) and compare results to your golden standard, allowing you to easily calibrate your behavioral models.

This interview post talks about a fourth application .  Here Branimir Ivetić and Vani Priya from Technology R&D – Smart Power Technology of STMicroelectronics talk about a unique flow they have developed using CX-U Waveform Compare to validate their Smart Power device models on FastSPICE simulators and how it has increased their confidence in Synopsys FastSPICE simulators.

Branimir Ivetić was born in 1979 in Sarajevo (Bosnia and Herzegovina) and moved to Italy with his family in 1994. He got the Degree in Electronics Engineering from “Polytechnic University of Milan” in 2003, while already completing his apprenticeship activity in STMicroelectronics’ Flash Wireless Division. In 2004 he joined the Technology R&D department for Smart Power technologies, and he is currently part of its Design Enablement group, as a Senior AMS Verification engineer.

Vani Priya holds a Bachelor Degree in “Electronics and Telecommunication Engineering” and has been working for STMicroelectronics, India since 2007 in Technology R&D Smart Power Technology, Design Enablement group.

Q- What are your current job responsibilities and which technologies are you currently working with?

Branimir – My main job responsibilities include the development, deployment, maintenance and support of AMS verification methodologies for ST Smart Power design community worldwide. The primary target for those methodologies is to guarantee the first silicon success of our Smart Power ASICs and applications. Some of those methodologies are:

-       Pre and Post Layout Simulation with SPICE and FastSPICE simulators;

-       A/D co-simulation for an efficient full-chip verification;

-       Static and Dynamic Analog ERC (Electrical Rules Checking);

-       Mixed-mode simulation and HDL-AMS modeling;

These methodologies are developed and supported with all ST’s Smart Power technologies. In particular, our most advanced Smart Power technology is a 0.13um High-Density BCD.

Vani – My primary responsibilities include:

-       BCD Silicon Device Models Validation against FastSPICE simulators;

-       Continuous enhancement and support of FastSPICE simulators (HSIM, XA, etc.) for their efficient usage among design community;

-       Evaluation and deployment of specific AMS Verification methodologies, like the ones based one HSIM Circuit Check, Verilog-A macro-models etc.

Q- Branimir, please tell our readers about Smart Power Technology. What kinds of applications are typically targeted on Smart Power Technologies?

Branimir Ivetic

Branimir – In general terms, a Smart Power process technology is quite more complicated than a lithographically corresponding pure CMOS technology. That’s because these two kinds of process families are conceived to fabricate quite different final applications. The complexity gap is expressed through the availability of more (and more complex) elementary devices, more operating voltages (spanning from a typical low voltage 1.8V or 5V to a maximum of 65V, 90V or 100V) and logically different blocks, that need to coexist, all together, on the same Silicon die of a Smart Power ASIC.

The native name given to the Smart Power technologies was BCD (Bipolar-CMOS-DMOS). In fact, those technologies allow the integration of control logic functions (CMOS based), analog circuits for signal conversion/management (both CMOS and Bipolar based) and power management blocks (based on power DMOS structures) on the same chip.

On the other hand, the main differentiator of ST Smart Power technologies from the competitors’ ones is the completeness of its offering portfolio. We do dispose of High-Voltage, High-Power, High-Density and SOI BCD technologies, covering all lithographies (with products running from 2.0um to 0.13um) and all ST business segments. Some typical BCD applications are:

• Lighting applications and motors drivers in general;
  • Motherboards DCDC converters, HDD Power Combo, Power line drivers and modems;
  • Bio-medical applications like 2D or 3D ultrasound ecography;
  • Control and signal conditioning ASICs for proprietary MEMS sensors.
  • Airbag, gasoline direct injection and ESP/ABS control, car battery monitoring;
  • Car radio and consumer audio amplifiers, automotive and consumer electronics power management, etc.

Q – Branimir, how key is Device Model Validation on Fast SPICE to your team?

Branimir – As I have just exposed, a so wide range of applications together with the high complexity, typical for Smart Power technologies, require efficient AMS verification methodologies supported by proven FastSPICE simulators.

The first mandatory step to support a FastSPICE simulator for a complex technology consists in Silicon device models validation. In fact, finding any inaccuracy in the interpretation of device models during the design becomes very expensive, because fixing the device models in the simulator is not a trivial task, and may mean not using the FastSPICE for one or two months, possibly disrupting delivery targets. To avoid such issues, we at ST – “Technology R&D Smart Power Technology” – make it absolutely necessary to fully validate correct support of our Smart Power device models by HSIM and XA, simulators that we officially adopt in our design flows. So the activity of device models validation, even if transparent to our design community, is really important, and one of the key factors allowing us to guarantee a high quality for our AMS verification methodologies.

Silicon device models validation flow consists of accurate simulations of apposite small test cases sets with three simulators, our golden SPICE, HSIM & XA, and the resultant waveforms are compared.

ST Flow Diagram

Q- Vani, please give us more insights into your SNUG paper which discusses about this flow? What are the main advantages of this flow versus the earlier approach?

Vani Priya

Vani – First of all about the flow, each Smart Power technology has around 50 devices having on an average with six test cases per device for device characterization. So, we first generate around 300 (50 x 6) test cases for each FastSPICE simulator that is adopted by our design team. These testcases include AC, DC and transient simulations according to the device characteristic that needs to be validated. Next these simulations are submitted to the compute farm. Finally the resultant waveforms from these 300 simulations are compared on a waveform viewer taking into account visually absolute and relative tolerances that are permissible.

One can imagine that performing all these steps manually is highly time-consuming and prone to human errors. Due to these reasons we started automating the validation flow starting from the test case generation till plots comparison using CX waveform compare, which is being done today without any human interventions.

The main point that has attracted us to CX Waveform Compare is its ability to read plot files from different simulators and different formats. Moreover, we found it’s command language to be very powerful and well thought out (with all the bells and whistles) For example, one can set different tolerance for voltage and current waveforms, ignore certain regions of the waveforms, account for shifts along X-axis etc.

The validation flow has been in production now for over a year. With quite accurate rules setting for CX Waveform Compare, the time of comparison between two plot files with about 10 waveforms has been reduced to few seconds and this in turn has reduced our validation turn-around time – including debugging of reported mismatches – from 8 weeks to 1 week.

As a pilot project, we have also run this flow on a medium sized AMS IP with about 100 signals selected for comparison and we were satisfied with the run time.

Thanks to Branimir and Vani for sharing their insights. For more information on their work, you can access STMicroelectronics India SNUG paper at:

SNUG paper

SNUG presentation