Industry Insights

User Interview: How ECO Handling Works With Equivalence Checking

2009-11-19T14:00:00Z

Vishvabhusan Pati is a senior staff engineer and manager at Qualcomm, where he’s involved in design work and formal and semi-formal design verification. In this Q&A interview, he discusses advantages and limitations of formal equivalence checking, and describes his experience with automated Engineering Change Order (ECO) handling with the Cadence Encounter Conformal ECO Designer.

Q: What kind of verification work does your team do, for what kinds of chips?

A: Typical of many design flows, we do vector-based simulation and semi-formal equivalence checks together. Our designs go into chips that are targeted towards wireless applications.

Q: What are your biggest challenges from a verification perspective?

A: First, complete and comfortable verification of complex designs involving digital and non-digital sections, and designs with aggressive power saving techniques. Second, formally and semi-formally verifying the correctness of designs that are becoming exponentially more complex.

Q: How, and why, do you use formal equivalence checking?

A: Our formal equivalence checking methodology is generally tool based. The methodology is used to augment design coverage that would otherwise be done through gate-level simulation, and to test causes and conditions that are not covered in simulation.

The biggest reason for using equivalence checking is the advantages it has over simulation. The methodology relies on mapping a reference design to a DUT [device under test] that is meant to be a replica of the reference through a tool-based transformation, such as a netlist generated out of synthesis or after place and route. They can then be compared for “likeness.” When done well, this will indicate whether every part, element, or cell of the DUT is functionally identical to the reference design. While a very large number of identical test cases and amount of test time would be required to simulate both the reference and the DUT, formal equivalence checking can do the job more completely as well as faster.

Limitations of equivalence checking, in my understanding, include the difficulty of mapping today’s complex designs to mathematical entities for formal comparison, particularly when today’s synthesis and place and route tools perform design transformations through unforeseen optimizations. Other limitations include problems caused by state-of-the-art power saving techniques, and the mapping of complex library cells that are custom designed for high performance.

Q: Did you use a manual ECO flow before using Conformal ECO? What were the problems?

A: We have traditionally used a manual ECO flow. Timing ECOs are still often done manually or inside of placement and routing. For functional ECOs, the problems of manual ECOs are very well known – large turnaround time for the ECOs, the need for netlist expertise, and limitation of the type of ECOs to simple non-state-machine kinds, cell additions, or simple arithmetic.

Q: How does Conformal ECO automate the functional ECO process? What are the advantages?

A: Conformal ECO provides an environment to perform the equivalence checking and ECO process together in a unified manner. Once the upfront setup is completed, both tasks can be performed in one run. In fact, the generation of ECO changes to the netlist is an extension of the equivalence checking. Generating the ECO netlist through the GUI has worked best for us.

As for advantages, getting an ECO done does not require an ECO expert, since the tool is the expert here. This does, however, bring in the requirement of getting well acquainted with the tool. In principle, very complex ECOs can be handled. This would be practically impossible if attempted manually.

What has not gone so smoothly is working with complex designs with multiple power domains and clock-gating controls. However, in principle, it works well.

Q: What advice would you give other engineers about formal equivalence checking and ECO handling?

A: As a regular user of formal equivalence checking, I would encourage users to use this formal technique wherever possible, to increase confidence in the fidelity of tool-generated netlists against their reference implementations. Now that tool-generated ECOs are possible, I would certainly recommend that flow.

However, I would encourage users to use their ingenuity. Understanding the tool, along with its strengths and limitations, makes for successful usage. Use appropriate constraints in equivalence checks to get the best results. Understand which warnings are important and which are safe to ignore. In the ECO process, manually cross-check the number and type of cells introduced. When attempting tool-based ECOs, always try to analyze the netlist. Roughly estimate the number of cells a manual ECO might add and compare with the tool-generated ECO. Watch out for cloning clock-gating logic or missing isolation logic in the ECOed netlist.

Richard Goering

Guest Blog: Characterizing Process Variability At 32 nm And Below

2009-11-18T14:00:00Z

Process characterization becomes much more complex as feature sizes shrink. In this guest blog Jim Bordelon, president and CTO of Stratosphere Solutions, describes requirements and methodologies for modeling variability at 32 nm and below.

Peering under the hood of a 32 nm process early in its lifecycle provides a wealth of information about the challenges awaiting designers and EDA tool providers alike. A recent 32 nm test chip project conducted with Cadence, IBM and Stratosphere Solutions included a suite of characterization structures designed to measure transistor variability. As discussed in a previous blog, the variety of “contexts” that a transistor experiences within the community of other transistors in the design can strongly influence both the performance and yield of the product circuit. How big and how close your neighbor is matters.

Cadence and Stratosphere have developed modeling techniques to capture and incorporate variability into the design flow. Stratosphere provides specialized test chips and modeling tools that supply fundamental variability information that the Cadence Encounter toolset uses to accurately assess the statistical timing and power characteristics of a product. Stratosphere’s Strato-Pro testchip produces volumes of raw data that our Ozone modeling tool crunches to generate models of variability that span many different transistor contexts. This task introduces new requirements for both silicon characterization and data modeling.

On the characterization front, many transistor contexts must be distilled into suitable test structure DUTs (devices under test) and replicated to yield a statistically significant set of test data. In principle, this is no different from the conventional device characterization that all fabs have done. Today, though, the large variety of structures and sample sizes required for a leading CMOS process dictate a much higher density of test structures than what is economically achievable with conventional testchips, and require a faster method of test as well.

Once upon a time, fabs relied on testchip data from multiple dice on multiple wafers from multiple lots to build a statistical picture of the process. The statistics of device variability at 32 nm must be modeled within die so that the systematic and random components of variability can be teased apart, modeled, and applied appropriately by the EDA toolset. Random variations impact circuit performance and yield differently than do systematic variations.

High density, array-based, characterization circuits like StratoPro combine test devices with active addressing circuitry designed to be robust to process variations. The result is somewhat like a memory array, but with cells containing various sets of replicated DUTs that are testable in an analog fashion (such as sweeping a MOSFET gate voltage and measuring a drain current) and useable on early process mask sets. The array serves the dual purpose of enabling many more types of DUTs, design rule experiments, and context experiments, as well as allowing DUTs to be easily replicated without chewing up more valuable mask area.

Distributions of many device parameters over a wide range of device variations (both sizes and contexts) are obtained from measurements of one array. Considering that multiple arrays can be placed on a test chip, multi-project wafer die, or even a scribe line, a large amount of data is produced that gives a detailed statistical picture across multiple spatial domains associated with an array, die, reticle, and wafer. The hierarchy of data enables the extraction of systematic variations which exist at the die, reticle, and wafer levels, as well as the intrinsic random variations. The systematic variations are important for ascertaining deterministic relationships between device properties and device size, context, and spatial location.

As an example of many DUT contexts studied, a poly line that closely abuts the end of a 32nm MOSFET poly gate was seen to significantly reduce the random variability of the threshold voltage and the systematic variation of threshold voltage with gate width. Ring oscillator data clearly indicated a spatial systematic variation across a wafer of NAND gate delay as high as 28% of the mean value. Stratosphere’s Ozone tool separates spatial systematic variability from the underlying random variability of all types of measured data, and also reports correlation between variations of different device and circuit parameters. Empirical variability models created by Ozone enhance the accuracy of statistical EDA engines further upstream in the design flow.

Together, high density test vehicles and statistical data modeling tools constitute the front end of the emerging statistical EDA infrastructure. Stratosphere’s tools have been run at multiple fabs and proven from 65 nm down to 32 nm. Incorporating the silicon-accurate variability models produced by these tools within the Encounter tool suite for simulating timing, power, and standard cell performance results in a design capability for 32nm and below that offers true optimization of performance and parametric yield.

Jim Bordelon

User Panel: Can Formal Tools Reduce Need For Simulation?

2009-11-16T14:00:00Z

It was not surprising that a customer Q&A panel at the Logic Design Technology Event, held at Cadence last week, would focus almost entirely on functional verification. As one panelist noted, verification consumes over 50 percent of the design effort. What I found interesting was the amount of discussion around static formal checking and equivalence checking, and the extent to which it can replace gate-level simulation.

As moderator, I noted that all three user presentations at the event discussed the use of Cadence Encounter Conformal products, and all cited uses other than the equivalence checking for which Conformal was originally best known. In a presentation before the panel discussion, Arvind Chopra, design manager for the microcontroller product group at NXP Semiconductors, talked about Conformal Low Power. Camille Kokozaki, director of design automation services at Integrated Device Technology (IDT), talked about Conformal Constraint Designer and Conformal Equivalence Checker. Vishvabhusan Pati of Qualcomm, who didn’t join the user panel, talked about automated ECO handling with Conformal ECO Designer.

I asked panelists why they use Conformal. Some answers:

“We use it for equivalence checking and more and more for low power checking. There’s less time to run things at the gate level, hence it’s very important to use other techniques,” Chopra said. He added that “it does reduce the need for simulation at the gate level.”

“There is definitely a reduction in simulation,” Kokozaki said. “Once you change something and you cannot formally prove it is equivalent, guess what – you have to do a lot of simulation.”

Fred Jen, director of physical design at Qualcomm, said that “in the ideal world, we would eliminate all gate-level simulation. It would reduce a huge run time.”

Fred Jen (Qualcomm), Rajiv Parameshwaran (Sandisk), Camille Kokozaki (IDT), and
Arvind Chopra (NXP) discuss verification at the Logic Design Technology Event (left-right).

An audience member noted that automatic test pattern generation (ATPG) requires gate-level simulation. “It’s true,” Jen responded. “But there are two parts to it. First you want to make sure your functional design is correct. ATPG is actually straightforward in terms of test.” Kokozaki said ATPG is a “checklist item,” and noted that “the debug and analysis of corner cases is where you spend most of your time. If you prove everything is functionally equivalent, you don’t have to go through that.”

Chopra, however, noted that “we have found some value in gate-level simulation. Sometimes there are things like clock glitches that are very hard to catch through any other means.” Later on, an audience member asked him why formal tools can’t do clock sequencing. Chopra responded that it would probably be feasible to put some assertions into a formal tool that would detect clock sequences that cause glitches.

Some other perspectives that came from the panel are as follows:

To simplify verification, stay with standard interfaces and buy standard test packages (verification IP) rather than writing them yourself (Jen).
Analog blocks pose a big verification challenge, and one problem is that analog designers rarely have expertise in modeling (Kokozaki).
Block level power estimation is easy. A hierarchical power analysis is much harder, and needs more support (Rajiv Parameshwaran, staff engineer at Sandisk).
Nobody uses pure statistical timing analysis. People find violations first and then use statistical timing to see if they go away (Jen).
Assertions are very helpful, but are not signoff quality (Chopra).

I’ll close with a pointed comment by Chopra – that there is no single tool or methodology that allows you to “sign off” and be assured that the design is completely checked and that it works. All verification approaches have both advantages and limitations. A big part of the verification challenge is finding the right approach at the right time.

Richard Goering

User Interview: Formal Analysis Speeds IP Connectivity Verification

2009-11-12T17:00:00Z

The biggest challenge with verification is “always the schedule,” according to Chaitanya Kosaraju, senior design engineer at Xilinx. Thus, anything that can cut verification time without compromising coverage presents a huge advantage. At the recent CDNLive! Silicon Valley, Kosaraju showed how formal analysis reduced verification times from 3 ½ months to 1 month for a multiplexed pad interface block.

Kosaraju gave a paper entitled “Time-Saving Formal Analysis Approach for Multiple IP Connectivity Verification” at CDNLive! In it, he discussed the challenges of using a conventional simulation testbench approach for verifying a multiplexed pad interface, given the large number of possible input combinations. He showed how he used the Cadence Incisive Formal Verifier (IFV) to verify the entire block, with no need to generate test stimulus, set up functional coverage points, or write assertions from scratch.

In an interview after his presentation, Kosaraju further discussed his experiences with IFV. In the video clip below he tells how and why he uses formal analysis, how he saved verification time on his pad interface block, and how he developed assertions.

If video fails to launch click here.

The pad interface block was Kosaraju’s first experience with IFV. There wasn’t much of a learning curve, he said, given that the IFV Connectivity Package automates the generation of assertions. Kosaraju observed that Xilinx found 16 bugs in a one-month period in the pad interface block, including bad RTL mappings, discrepancies in the spec, and documentation errors.

His advice for teams considering formal analysis? “Building the testbench environment takes so much time,” Kosaraju said. “If management wants to see some results, you can employ IFV and do some basic checks before your testbench is up and running.” He also advised engineers to “look at areas of the design where formal will probably fit, and where you have to use your testbench for verification. I think they both go hand in hand.”

Richard Goering

Call for papers! The CDNLive! EMEA conference will be held May 4-6, 2010 in Munich, Germany, and abstracts for proposed paper submissions are due December 11, 2009. An academic track at the conference, developed by the Cadence Academic Network, is seeking paper submissions as well. The academic track provides a forum for university researchers to present their work to both academic peers and industry attendees.

Panel Question: Should Designers Do Their Own Verification?

2009-11-11T14:00:00Z

One question that prompted a lively discussion at the recent Cadence Mixed-Signal Design Summit was whether design engineers should do their own verification. This is a particularly good question for analog and mixed-signal design, where the tradition of separate verification teams is not as strong as in the digital world. At the summit, participants in a Q&A panel made a strong case for separate verification teams in mixed-signal design.

I wrote previously about user presentations at the summit, and the five users I wrote about were members of the panel, which primarily discussed mixed-signal SoC verification. Here is what they had to say when asked, “does it make sense for designers to do their own verification, or does it make sense to have a separate verification team?”

“You definitely want a different person running your verification. It doesn’t matter whether it’s mixed-signal or digital. You want separate pairs of eyes verifying your design. You will get much better coverage that way than letting the designer verify his own IP, because he will verify it for zero bugs.”

--Yuval Shay, staff engineer for mixed-signal verification at STMicroelectronics.

“Obviously there has to be a team with a dedicated focus. You have people dedicated to overall verification for the SoC.”

-- Kumar Abhishek, senior analog and mixed-signal design engineer at Freescale Semiconductor.

“I’m approaching your design as if everything is wrong. My main goal is to break the design. That is what differentiates me from a designer. You don’t try to break your own design.”

– Prasanth Aprameyan, senior verification manager at Micron Technology.

“Developers have a bias. That’s why you need a second set of eyes looking at it.”

–Robert Milkovits, director of technical support at Jazz Semiconductor.

“For us, the most efficient way to proceed is to have a dedicated verification team. We find bugs, and then it’s more efficient to hand it off to the designer and say ‘why isn’t this working?’”

– Jess Chen, senior staff engineer at Qualcomm.

Later on in the panel, Aprameyan noted that Micron separates functional verification teams from performance verification teams. Milkovits talked about the need for a “joint venture” between designers and verification engineers. There was also considerable discussion about who should write analog behavioral models for simulation. “Analog designers usually don’t want to get involved, but they’re the ones who have the knowledge,” Chen noted.

My perspective? On the analog side, I think there could be a real benefit in having a separate verification person or team. Analog designers are coping with increased functional complexity, higher performance demands, and low-power requirements. Having someone who can do behavioral modeling, run detailed regression tests, and treat verification as more than a late-in-the-day afterthought can help meet these demands.

On the digital side, where separate verification teams are commonplace, it’s more a question of who does what in terms of verification. If the designer can do some early checking before turning his or her block over to a dedicated verification team, it will help reduce the overall verification burden. Static checking with formal tools, such as Cadence Encounter Conformal Low Power or Cadence Incisive Formal Verifier, can help with some of that early block verification.

It’s kind of like the publishing world. If you write an article for a newspaper or magazine, someone will (hopefully) edit it, and it’s very helpful to have that extra set of eyes. But with copy editors in short supply, writers should carefully read their own copy and run static verification tools that check spelling and grammar. In any area of endeavor, the more checking you can do up front, the better.

Richard Goering

“Software Signoff” Raises Many Questions

2009-11-09T14:00:00Z

At a discussion at the ICCAD conference last week, EDA notables Jim Hogan and Paul McLellan talked about “what EDA needs to change for 2020 success.” One topic they emphasized is “software signoff,” and they encouraged those present – mostly bloggers – to go forth and write and tweet and blog about it. It’s an interesting concept, but I think it raises a number of questions, as listed below.

1. What is software signoff? A GDSII file is “software,” as is an application program written for an off-the-shelf microprocessor, so we have to clearly define what “software” we are talking about. Hogan, a former Cadence executive fellow and current private investor, defined software signoff as “signoff from behavior to an implementation in embedded software and/or a hardware implementation fabric.” Both he and McLellan, author of the EDA Graffiti blog, indicated they were talking about behavioral C/C++ code, not SystemC.

However, the word “behavioral” can mean many different things. Is it purely algorthmic, or does it define an architecture? What exactly is signed off, by whom, and to whom? How is existing silicon IP handled? Are constraints provided? In sum, what are the deliverables for software signoff?

2. What are the advantages and tradeoffs? The idea is appealing – you write some code in C/C++, and turn it over to machines and/or people who will convert it into a programmed system on chip (SoC) or FPGA. But what are the implications for performance, power, area, and unit cost?

3. What are the tooling requirements? Either the algorithm-to-silicon path will need to be automated, or you’ll be turning the behavioral software specification over to a hardware design team using traditional methodologies, in which case you’re moving work to a different location rather than actually reducing it. There has been tremendous progress in high-level synthesis with tools like the Cadence C-to-Silicon Compiler, but no tool automates the entire flow from algorithms to GDSII. Software signoff will also require some really good estimation, prototyping and profiling tools.

4. What are the silicon requirements? It seems to me software signoff will work best with some kind of predefined fabric, such as an FPGA, where someone has already taken care of issues relating to manufacturability, yield, and process variability. Otherwise, these will need to be dealt with.

5. What about analog integration? Hogan commented that analog design is inherently “algorithmic.” True, but algorithm-to-transistor synthesis has not worked very well in the analog world. Nearly all SoCs going forward will be mixed-signal, and somebody has to design and integrate the analog portions.

6. How is verification handled? Somebody needs to verify that the implementation matches the spec, is functionally correct, and meets timing and power requirements. Who does that and how?

7. Where will software signoff make sense…and not? I don’t think software signoff will be used for applications that need highly optimized performance, power or area, or those that need a very low unit cost. It could work well, however, for people want to accelerate applications using an FPGA or hardware acceleration platform, but who don’t want to, or can’t, do hardware design themselves. (I am assuming that software signoff involves some custom hardware creation or reconfiguration – otherwise, you’re just writing software for off-the-shelf hardware).

In conclusion, I think “software signoff” is one way that some people will create embedded applications. But there will be other methodologies as well. Right now, the most logical move is from RTL to a SystemC transaction-level modeling (TLM) based design and verification flow, with high-level synthesis and virtual platforms. That flow is available today.

I really have only one prediction about EDA in 2020 – that one size will not fit all.

Note: Slides from the Hogan-McLellan presentation are available at the Si2 web site. Other blogs commenting on the discussion are listed at http://leepr.com/Home.html.

Richard Goering

DFT Challenge: Evaluating The True Cost Of Test

2009-11-05T14:00:00Z

Remember DFT? “Design For Test” faded into the background in recent years as the industry turned its focus to DFM, but if anything test is an even larger concern than it was 10 or 15 years ago. That’s because test is becoming more difficult and expensive at nanometer process nodes, especially with the drive for low-power design and the increasing prevalence of on-chip analog and mixed-signal circuitry.

A recent discussion with Sanjiv Taneja, vice president for Encounter Test at Cadence, showed me that the traditional way we’ve evaluated test costs is way too limited. Test cost is traditionally calculated in terms of capital costs and operating costs. Test engineers focus on optimizing throughput in order to minimize the amount of time each IC spends on the tester. One way that’s done is minimizing test data volume.

While minimizing time on the tester is still important, Sanjiv notes that there are additional criteria that must be considered to evaluate the true cost of test. These include:

Impact of power on yield and test cost. If a test program turns on all the power modes during test, it can result in very high switching activity and excessive IR drop. Good chips can fail on the tester, reducing yield and increasing costs.

Integration of DFT with design implementation flow. Synthesis tools should optimize for testability as well as area, timing and power. Otherwise, test structures can impact routability and timing closure. Poor design/test integration will decrease productivity and thus increase costs.

Analog/mixed-signal test. If analog IP takes up 20 percent of a system-on-chip, it probably accounts for over 50 percent of the test cost. Analog test often requires an expensive, manual approach. Sometimes built-in self test (BIST) is used, but this requires extra work and planning.

Cost of escaped defects. If you think test costs are high, what does it cost for a defective chip to escape detection until system test, or until it’s out in the field? Shipping bad parts to customers can not only kill budgets – it can kill companies.

Ramping to volume production. Process interactions and process variability make it difficult to ramp to volume production at 45 nm and below. Given today’s time-to-market concerns, a delayed yield ramp can be a huge expense.

All of the challenges listed above impact designers, and all can be alleviated through EDA tools. For example, power-aware automatic test pattern generation (ATPG) can make the right tradeoffs between test power reduction and test time reduction. DFT automation tools can hook up BIST engines to a chip test interface, and translate BIST set-up and run-time sequences to test interface ports. Advanced fault modeling and test-point insertion techniques can reduce the risk of escaped defects. And diagnostic EDA tools can speed yield ramps by figuring out the root causes of failures.

Cadence offers such capabilities in the Encounter Test product line, which is being shown at this week’s International Test Conference (ITC) in Austin, Texas. The ITC program, meanwhile, has a strong DFT emphasis. It includes a keynote and a plenary invited address that focus on the integration of design and test, as well as panel discussions on DFT for analog and low-power design. Cadence has representatives on both panels.

DFT has been around for a long time. I started writing about it in 1984 for Computer Design magazine, well before the term “EDA” was even invented. Here we are now, 25 years later, and it turns out that DFT is more important than ever. Some things never go out of style.

Richard Goering

Greatest Moments In EDA Innovation

2009-11-03T14:00:00Z

Innovation is the lifeblood of the EDA industry, and it is only because of innovation from many sources – including academia and industry – that modern IC design is possible at all. Today at Cadence (Nov. 3, 2009), we are celebrating Cadence Innovation Day. As such, it seems like a good time to consider the “greatest” innovations that shaped our industry.

Also this week, the EDA Consortium will present the 16th annual Phil Kaufman award to Prof. Randal Bryant, whom I interviewed for a recent Industry Insights blog. This award is the EDA industry’s highest honor, and a look at the past 16 award winners provides some good background into the history of EDA innovation.

Here are my nominations (not necessarily in order) for the “greatest moments in EDA innovation.” Any further suggestions are welcome.

1. Spice simulation

Spice (Simulation Program with Integrated Circuit Emphasis) was one of the very first EDA programs, and it’s still the gold standard today for analog and custom circuit simulation. Spice was derived from a program called Cancer, which came out of a class project led by Prof. Ron Rohrer (2002 Kaufman award winner). Prof. Donald Peterson (1995 Kaufman award winner) oversaw the Cancer rewrite that became Spice, which was first publicly presented in 1973.

2. Verilog HDL

The Verilog language ushered in the present era of language-based IC design, and made RTL synthesis and simulation possible. Verilog was developed by Phil Moorby, 2005 Kaufman award winner, at Gateway Design Automation in the early 1980s. When former Cadence CEO Joe Costello won the Kaufman award in 2004, one reason cited was Cadence’s 1989 purchase of Gateway and subsequent opening of Verilog for standardization.

3. Multi-level logic synthesis

Nearly all complex digital circuits are designed with logic synthesis today. Synthesis was first applied to two-level logic with programs such as Espresso. However, a breakthrough in multi-level synthesis was required to make the technology practical for contemporary IC design. That came about in the 1980s through efforts such as IBM’s Yorktown Silicon Compiler project and the MIS and SIS programs from U.C. Berkeley. Prof. Robert Brayton, 2007 Kaufman award winner, and Prof. Alberto Sangiovanni-Vincentelli, 2001 Kaufman award winner and Cadence board member, collaborated in the development of Espresso, MIS and SIS.

4. Automated IC layout

Today’s ICs could not be designed without placement and routing software. Prof. Ernest Kuh, who was at U.C. Berkeley from 1956 to 1993, helped lay the groundwork for IC physical design in the 1970s and 1980s. He won the 1998 Phil Kaufman award for his foundational work in circuit layout theory, partitioning, floorplanning, placement and routing.

5. Structured VLSI design

EDA innovation is not just about tools and algorithms – it’s about methodologies. Prof. Carver Mead, winner of the 1996 Phil Kaufman award, is known not only for his work in areas such as silicon compilation, but also as the co-author along with Lynn Conway of “Introduction to VLSI Design” in 1980. This seminal book set forth a structured methodology for the design of large-scale ICs.

The innovators mentioned above have set a high bar to follow. But given the emphasis that Cadence is placing on innovation and R&D, it just could be that someone at today’s innovation awards ceremony will follow in their footsteps.

Richard Goering

Users Outline New Approaches To Mixed-Signal Verification

2009-11-02T14:00:00Z

At the Cadence Mixed-Signal Design Summit, held Oct. 27, I had a hard time finding a seat in a packed auditorium. One reason for the summit’s popularity was its hands-on, practical nature. A series of user presentations showed how designers are solving real problems in mixed-signal verification. Below are quick summaries of five such presentations.

Jess Chan (Qualcomm), Robert Milkovits (Jazz), Prasanth Aprameyan (Micron), Kumar Abhishek (Freescale),
and Yuval Shay (STMicroelecrtronics) presented at the Mixed-Signal Design Summit (left to right).

Top-down approach guides mixed-signal simulation

Yuval Shay, staff engineer for mixed-signal verification at STMicroelectronics, gave a presentation entitled “Mixed-language simulation of sigma-delta ADC with AMS Designer.” In the presentation, he outlined a “top-down” hierarchical verification methodology that uses the Cadence Virtuoso AMS Designer simulator within the Virtuoso Analog Design Environment (ADE).

The idea behind the top-down methodology is to start verification as soon as the design effort starts. To accomplish this, engineers create models at the highest level possible and slowly expand the hierarchy “downwards,” substituting behavioral models with transistor-level models until full-chip, transistor-level simulations can be executed. The same testbench developed for the behavioral level can run the full transistor-level design.

Shay identified three basic steps to ST’s methodology:

Partition design into analog and digital domains. Simulate analog blocks with Virtuoso Spectre simulator (Spice) and digital blocks with Cadence NC-Sim.
Run signal path verification for modulator and digital filter.
Run full-chip functional verification, including transistor level models and post-layout netlists.

Shay said this approach has “proven to be a very good solution” for his company’s needs.

Modeling methodology moves real numbers

Simulating real number traffic is an important part of mixed-signal simulation, but there are some tricks to it, according to Jess Chen, senior staff engineer at Qualcomm. His presentation was entitled “A modeling methodology for verifying functionality of a wireless chip.”

There are some challenges with real number traffic in event-driven simulations, Chen said. He prefers a “baseband equivalent” approach that passes multiple real numbers on a single wire. Advantages: the models run fast by suppressing the carrier, they produce realistic signals at the DAC outputs and ADC inputs, IQ swapping is easy to detect, and noise is easy to include.

Chen said his group considered various options for simulating real number traffic, and used a PLI function. This makes it possible to pass real vectors between Verilog modules, use bidirectional real number traffic, switch between voltage and current on the fly, and use a resolution function for real number drivers. Qualcomm applied this methodology to a wireless SoC and found over 100 functional bugs before tapeout.

Full chip Spice simulation really does work

Think full-chip Spice simulation is impractical? Kumar Abhishek, senior analog and mixed-signal design engineer at Freescale Semiconductor, showed how it can work in a presentation entitled “Full chip Spice simulation methodology for zero defect silicon.”

What Abhishek described is actually a Verilog-AMS/Spice co-simulation approach. In a microcontroller SoC, he used Spice models for blocks such as ADC, DAC, voltage regulator, LCD controller, and clock generator. Verilog-AMS models were used for a crystal driver, analog sensor model, and supply driver. Verilog-AMS monitors were used for display, clock profile, data converter, and power monitor.

Abhishek showed a list of microcontroller verification challenges, including those related to analog behavior, power management, and pad rings. He said the AMS/Spice co-simulation approach is “robust” or gives 90 percent confidence in most cases. He also showed a number of test cases and talked about setup times and simulation run times. For example, in a test case with 6M transistors, power-up simulations took a setup time of 2-3 days and a run time of 15 hours.

He concluded that the proposed full-chip Spice methodology is useful for catching corner cases for complex mixed-signal SoCs, especially in complex power-gating scenarios. Abhishek noted, however, that it is “not a replacement” for the existing SoC mixed-signal verification flow, but a complement that can help attain 100 percent coverage for complex protocols.

How to capture design intent

Robert Milkovits, director of technical support at Jazz Semiconductor, gave a presentation entitled “Capturing AMS design intent.” He first spoke of “design intent holes and misses,” including:

Incomplete coverage for circuit analysis
Design sensitivity not uncovered
Parasitic effects on performance
Layout implementation discrepancies
Insufficient time for optimization and coverage analysis

Milkovits talked about how Cadence Virtuoso platform updates in IC6.1 help users represent design intent. He noted that constraint management is integral to design intent, and showed how Virtuoso constraints help “address both the big picture and the design details.”

A look at flash memory verification

Prashanth Aprameyan, senior verification manager at Micron Technology, spoke on “Mixed signal verification – a NAND memory perspective.” He said that NAND memory verification is very similar to other mixed-signal verification, and noted that “for us, verification cost is as important as design cost.”

NAND flash memory includes a memory array, sense amplifiers, high-voltage circuits, controller and logic, and low-voltage analog, pad and I/O. Micron uses both Verilog-A and digital Verilog modeling of the memory array. The Cadence Virtuoso UltraSim simulator, a fast Spice simulator, is extensively used for NAND flash verification. Micron is also investigating wreal behavioral modeling with Verilog-AMS.

Apremeyan noted that full-chip simulation time is becoming prohibitive, that it would be nice to have all electrical aspects of verification under a single tool, and that design for yield (DFY) analysis in fast Spice would be helpful.

Q&A panel

In a Q&A panel following the presentations, panelists fielded questions on the difficulty and cost of developing analog behavioral models, whether designers should do their own verification, modeling for performance verification, SoC-level and IP challenges, and test.

The summit also featured a keynote by Paul Emerson, general manager for the analog and logic business at Texas Instruments, and several presentations on Cadence’s mixed-signal solutions. Videos will be available on-line in November. Another review of the summit can be found in Paul McLellan’s blog.

Richard Goering

User Interview: How To Estimate Power Early

2009-10-29T13:00:00Z

Early power estimation makes it much easier to manage IC power, according to Camille Kokozaki, director of design automation services at Integrated Device Technology (IDT). At the recent CDNLive! Silicon Valley, he presented a case study of architectural power estimation with a 65nm system-on-chip with 250K logic cells and a maximum frequency of 400 MHz.

Kokozaki described a flow that uses five steps:

“Back of envelope” estimations in spreadsheet provide assumptions about voltage, dynamic power factor, leakage power factor, design for test overhead, and other factors.
Power estimation from InCyte Chip Estimator uses a provided model library. InCyte estimates dynamic power sensitivity versus activity.
Cadence Encounter RTL Compiler provides estimation from early synthesis run.
More accurate estimation based on full synthesis netlist.
Power calculation from post-layout netlist.

Accuracy increases with each successive step, but the higher levels of abstraction provide a greater ability to influence power.

In an interview following his presentation, Kokozaki discussed his approach to power estimation further. In the attached video clip, he discusses the importance of power analysis at an architectural level, and talks about his use of spreadsheets, InCyte, and pre-synthesis and post-synthesis power estimations.

If video fails to launch click here.

For the chip described in the CDNLive! case study, IDT employed clock gating. Kokozaki said IDT also uses more advanced power management techniques where appropriate.

Kokozaki had a warning about the use of activity levels in power estimates. “Be very careful about activity and what it means,” he said. “There are cases where a 10 percent activity for a particular mode can consume even more power than a 15 percent activity rate on a different mode in the same design. You have to know what you’re putting in there. I also advise people to not go overboard and use a much higher activity rate than what they end up seeing.”

Richard Goering

Panelists: 32 nm HKMG Is Ready To Roll

2009-10-28T14:30:00Z

The 32/28 nm Common Platform high-k metal gate (HKMG) technology is “ready and open for business,” according to the title of a breakfast panel at the ARM Techcon3 conference Oct. 22. Panelists from IBM, ARM and Cadence talked about the benefits of HKMG, the requirements it places on the design flow, and the deep and early collaboration that made a supporting ecosystem with libraries and tools possible.

All of the panelists talked about the Common Platform/ARM/Cadence collaboration, which began in 2008 just a few months after the Common Platform started its process development work. Starting that early is very unusual, according to Jaya Jagannathan, director of semiconductor technology business development and marketing for IBM’s System and Technology group.

Jaya Jagannathan (IBM), Rob Aitken (ARM), and Vassilios Gerousis (Cadence)
discuss the Common Platform 32 nm HKMG technology (left to right).

HKMG, introduced by the Common Platform at 32 nm, promises significant power and performance advantages. The main benefit of HKMG, according to Jagannathan, is that it allows the scaling of gate lengths to continue. This had almost stopped at 90 nm, he said, because gate oxides were only a few angstroms – and atoms – in width. But HKMG, which uses thicker materials, allows scaling to resume. Further, he said, HKMG allows the “densest SRAM in the industry at 32 nm.”

Jagannathan also said that the 32/28 nm process uses a “gate first” approach in which gates are processed towards the beginning of the process flow. This, he said, allows a 50 percent scaling from one generation to another, while minimizing design restrictions and avoiding the addition of complex process steps. “Based on all the work we’ve done jointly, I can tell you that we can achieve the gate density we promised, we can achieve the performance we promised, and we can achieve the simplicity that we promised with gate first,” he said.

Why 32/28 nm? 32 nm is the main process node, but it’s designed so that a 10 percent optical shrink will enable the half-node of 28 nm. Today, Jagannathan said, a 32 nm low-power (LP) process design kit (PDK) is available in a beta release, and a 28 nm LP PDK is available in an alpha release. IBM has been providing multi-project wafers (MPWs) to customers and partners including ARM and Cadence.

Rob Aitken, R&D fellow at ARM, noted that a physical IP library for the 32/28 nm HKMG process is available for download now. It includes 12 memory compilers, logic libraries, and new multi-channel libraries. The multi-channel libraries make it possible to reduce leakage by using cells that have slightly longer gate lengths. It’s an alternative to the use of high voltage-threshold cells, which can reduce performance.

“The HKMG process is really quite different from previous processes,” Aitken noted. As such, ARM and the Common Platform worked together on design rules, manufacturability, and the library itself. Aitken said ARM has had five tapeouts with the Common Platform 32 nm process, and one 28 nm tapeout. These test chips made it possible to demonstrate early collaboration and to work on design rules.

ARM also used the test chips to run feasibility studies. Engineers found that the 32 nm LP process is able to attain frequencies in the GHz range on critical paths at a nominal operating point.

Vassilios Gerousis, senior architect at Cadence, discussed two 32 nm test chips that Cadence developed with IBM, as described in a previous blog. One let Cadence develop a CMP model, and showed that the 32 nm process has less relative copper loss than 45 nm but higher variability. Another showed that the random variation is large compared to stress, which is a systematic variation. Results may change as the process matures, he noted.

Gerousis noted that Cadence has focused on several areas related to 32 nm, including advanced layout rules, a high-frequency router option to NanoRoute, manufacturing awareness, and the ability to handle large designs. “32 nm is really a breakthrough in terms of layout rules. The number of layout rules is tremendous, and the impact on layout tools is also large,” he noted. NanoRoute is “100 percent compatible” with these layout rules, he said, and the Cadence Virtuoso Space-Based Router supports 32/28 nm layout rules as well. To help with random variations, Cadence is supporting statistical design for timing, signal integrity and leakage.

Panel moderator Ana Molnar Hunter, vice president of foundry for Samsung Semiconductor, closed the panel by stating that “we’re seeing tremendous customer interest in this technology because of the advantages HKMG brings to customers. There’s a lot of excitement and a lot of built-up demand.” Indeed, a full room for an early morning breakfast panel is itself a sign of interest. Designing in a new process node is never easy, but it appears that those who want to move forward will find plenty of ecosystem support.

Richard Goering

Panelists Broaden Scope Of Low-Power Discussion

2009-10-26T13:00:00Z

Most of the discussion about low-power design has centered around the RTL-to-GDSII flow for digital ICs. But the real problem is much broader, according to panelists from AMD, Sonics, Wipro, and Cadence at the recent Power Forward Initiative (PFI) Low-Power Design Summit Oct. 20.

Entitled “The Low-Power Evolution: Challenges and Opportunities,” the panel was chartered to take a high-level view of how low power design is changing and how it impacts product development. As moderator, I noticed (but wasn’t surprised) that panelists said very little about the RTL-to-GDSII digital IC design flow. Instead, the focus was on early power estimation, analog/mixed-signal design, embedded software, packaging, and other areas where automation is still lacking. Some interesting comments are noted below.

SoC integration complexity and power

“The SoC integration problem is growing as we add more and more cores together, we have more and more power domains, more and more clock domains, and a higher level of problems to solve,” said Scott Evans, director of software at IC interconnect provider Sonics. “CPF [Common Power Format] allows you to describe what you’re trying to build, but then it’s even easier to add more complexity to your design.”

Analog/mixed-signal design

Ron Burns, general manager for semiconductor and systems solutions at design services firm Wipro, said his biggest concern with respect to low power is analog/mixed signal design. He noted that his company is designing an increasing number of systems-on-chip (SoCs) with analog interfaces. “What we’ve found is that digital is performing well even down to below 40 nm,” he said. “What we’re concerned about now is making sure we have the right flow for analog and digital.” He said he’d like to see the same IP library format across both domains.

“We’ve done a fairly good job of automation and risk reduction in the digital portion of the design, and we’re pushing forward into analog/mixed-signal and starting to address packaging alternatives,” noted Steve Carlson, vice president of solutions marketing at Cadence.

Ron Burns (Wipro), Steve Presant (AMD), Scott Evans (Sonics), and Steve Carlson
(Cadence) discuss low power at the PFI Summit (left to right).

Embedded software and operating systems

“Being able to take advantage of power at the software level is a huge factor in terms of being able to save power,” said Evans. “Providing interaction with the hardware so software can control it better is certainly a place that needs a lot more work and a lot more automation.”

There’s a “huge opportunity” to take a more holistic approach towards estimating hardware and software together, said Steve Presant, fellow at AMD. He suggested “an environment where an application profile describes power, and an OS considers that and interacts with the hardware.”

The link to packaging

Wipro’s Burns cited a case in which his company designed a graphics accelerator IC while separately working with a packaging partner. “The only way to transfer information from the design database to the packaging house was through Excel files,” he said. “We don’t yet see a seamless way to interoperate between packaging and design. The reality is that the packaging companies use custom internal tools, and interoperability just isn’t possible.”

Early estimations

“It is critical for us to be able to estimate power and performance at very early stages,” said AMD’s Presant. Today, he said, “we do a lot of work based on Excel and we use a spreadsheet to make estimates based on area approximations and voltage and frequency estimates. It’s very crude. I think the future is transaction-level power approximations, so if you know that a certain transaction or activity carries a certain amount of energy with it, you can approximate power that way.”

As an IP provider, Evans said, Sonics needs its IP models to work with models from other sources. “We need some type of standardization for power estimation for models, so that when you plug in the models you know what you’re looking at and you can provide those early estimates,” he said.

Carlson talked about how emulation can provide a dynamic power analysis, help users evaluate the impact of software, and make it possible to select a “window” of operations for detailed analysis.

It’s the whole product

I started to make a point that I’ll bring out a little more here. The end consumer of an electronics product does not care how much power an IC dissipates. The consumer cares how long the battery life is, what it will cost to run the device, or what the environmental impact is. Low power isn’t just about digital chips – it’s about the entire system, with its analog components, packages, printed circuit boards, wiring, enclosures, fans, heat sinks, and software. With the help of the Common Power Format (CPF) and some good tools, we have made great progress in automating the low-power design flow for digital ICs. But as PFI Summit panelists noted, the time has come to take a broader look at low-power design.

Richard Goering

User Interview: An Under The Hood Look At PDKs

2009-10-22T13:00:00Z

Well-made process design kits (PDKs) are critical for successful IC design, and design teams should keep in touch with PDK technology development, according to Kristin Liu, principal CAD engineer at National Semiconductor. In an interview at the recent CDNLive! Silicon Valley, she talked about the challenges of PDK development and explained “model playback,” the topic of her CDNLive! paper.

Liu is involved in PDK development and automation, project management, customer support, PDK methodology and flow definition, circuit modeling, benchmarking, and new CAD tool implementation. She is working on BiCMOS processes for the analog ICs that National develops. National’s PDKs include customized schematic symbols, parameterized cells (Pcells), verification runsets, customized utilities, mask design libraries, and standard cell libraries. The PDKs are used in the Cadence design environment.

In the video clip below, Liu talks about the challenges of PDK development, the need for accurate device characterization, and National’s use of the Cadence Spectre simulator.

If this video fails to play please click here.

Liu’s CDNLive! paper was entitled “A Conventional Model Playback Utility In The Cadence Design Environment.” Model playback, she explained, is a utility developed at National Semiconductor that lets designers examine how a model behaves in real time. It lets designers “play back” the device characterization with customized design specifications. Designers can compare device behaviors among different processes, validate the model with different simulators, or view the model accuracy between the simulation results and the silicon measurement data, all in real time.

Liu has some words of advice for the IC design teams who rely on PDKs. “As an RF IC designer myself earlier, I felt frustrated and helpless with PDK issues,” she said. “Now I realize that it is important for designers to be involved in the PDK methodology definition. I’d encourage designers to work as closely as possible with PDK developers for feature enhancements, demos, design guides, design automation, and design flow benchmarking. This will maximize design productivity and reduce human error.”

Richard Goering

Cadence’s Andreas Kuehlmann To Head IEEE Council On EDA

2009-10-21T13:00:00Z

With a deep involvement in conferences, publications, educational programs and awards, the IEEE Council on EDA (CEDA) is a behind-the-scenes organization that has a large influence on the professional EDA community. Andreas Kuehlmann, Cadence fellow and director of Cadence Research Labs, will become president of IEEE CEDA in January – and he’s aiming to “ramp up” CEDA’s activities and increase its visibility and value.

Whether or not you’ve heard of IEEE CEDA, you’ve certainly heard of the Design Automation Conference (DAC), which CEDA co-sponsors. In fact, the council sponsors or co-sponsors over a dozen EDA-related conferences, including the International Conference on Computer Aided Design (ICCAD) and Design Automation and Test in Europe (DATE). CEDA publishes the IEEE Transactions on CAD and the newly-launched IEEE Embedded Systems Letters. The council offers a Distinguished Speaker Series and sponsors the A. Richard Newton and Phil Kaufman awards.

In this short video, Andreas talks about why CEDA was formed, what activities CEDA is involved in, what his priorities will be as CEDA president, and how people can get involved.

If this video fails to launch click here.

Andreas will succeed current CEDA president John Darringer, director of the design automation department at IBM Research. Additional members of Andreas’ team include the following:

Prof. Donatella Scuito from Politecnico di Milano in Italy will become president-elect (and president after Andreas’ two-year term).
Sani Nassif, manager of the IBM Austin Research Laboratory, will become vice president of conferences.
Prof. David Atienza Alonso of the Complutense University of Madrid will become vice president of finance.
Prof. Rajesh Gupta of the University of California/San Diego remains as vice president of publications.
Shishpal Rawat, director of EDA investments for Intel, remains as vice president of technical activities.

I wish this team well in their efforts to bring more value to the EDA community.

Richard Goering

OpenAccess – So Much To Celebrate, So Much To Do

2009-10-19T12:00:00Z

Two distinct messages emerged from the Silicon Integration Initiative (Si2) OpenAccess Conference last week. One is that the OpenAccess database is a great EDA standards success story, perhaps the biggest such story of all. Another is that there’s still a lot of work to do so OpenAccess can offer even more capabilities for next-generation IC design.

OpenAccess, initially developed by Cadence, has been in the public domain since 2002. Today it is managed by Si2’s OpenAccess Coalition, which includes several dozen semiconductor and EDA vendors, including Cadence, Synopsys, Mentor Graphics, and Magma. Many people may not realize that OpenAccess is constantly being maintained and updated by a sizable development group at Cadence.

Setting the theme for the conference, Sumit DasGupta, senior vice president of engineering at Si2, proclaimed that “OpenAccess is here and it is now.” All four major EDA vendors have adopted it for parts of their flows, and it’s become a compelling development platform for startups, he noted. But DasGupta cautioned that “this is no time for complacency. We have to get back to work and keep pushing the envelope with OpenAccess.”

Steve Schulz, Si2 president, said OpenAccess is “the largest EDA standards effort in the history of our industry.” Now, he said, OpenAccess is in the “early majority phase.” He talked about how Renesas uses OpenAccess throughout its IC development process, and how IBM bases its custom design flow on OpenAccess. Later at the conference, Jose del Cano of Intel described how his company uses OpenAccess to integrate internal tools with commercial EDA tools.

But don’t break out the champagne – at least not for long. There’s no rest in store for OpenAccess developers. In his keynote speech, Barry Dennington, senior vice president at NXP and chairman of the Si2 board, hailed OpenAccess as “something to be very proud of.” He said, however, that “OpenAccess needs a lot more work, it needs a lot more adoption, and the roadmap needs to be very clear.”

Specifically, Dennington said, porting existing libraries and design data to OpenAccess is not cheap, OpenAccess needs to be adopted by NXP’s IP providers, and 45 nm designs are taxing database performance and memory usage. How far can OpenAccess go, he asked? Could it replace other exchange formats, like GDSII?

“OpenAccess has proven to be a great standard,” Dennington said. “Cadence has led by example by pulling together Virtuoso and Encounter [on OpenAccess]. But we still need more EDA industry tools to connect with OpenAccess.” Intel’s del Capo wants OpenAccess to extend to new “domains,” such as post-silicon debug and large-scale layout visualization.

A presentation by Michaela Guiney, product engineering director for OpenAccess at Cadence and co-architect in the OpenAccess Coalition change team, made it clear that a tremendous amount of effort is going into improvements for OpenAccess. In January 2008, she noted, a new version called Data Model 4 (DM4) was introduced, with enhancements in such areas as constraints, routing constructs, and vias. Today it’s used in a number of popular EDA products, and the development team has improved its functionality, reliability, and performance in the meantime. In fact, there were 13 DM4 releases in 2008 and 2009.

An upcoming release at the end of 2009 will add more new capabilities, including performance enhancements. 2010 will bring further improvements in performance and capacity, as well as constraint modeling, Guiney said. She added that Cadence is working with foundries to understand 32 nm design rules, and plans to contribute 32/28 nm constraints to the OpenAccess Coalition in mid-2010. Meanwhile, coalition working groups are working to improve debugging, parasitic handling, and scripting interfaces.

A personal note: As an EE Times editor, I started writing about OpenAccess in its early days, and I followed its development as it moved from controversy to acceptance and adoption. It has, indeed, been a great success story, but the final chapter is far from written – we’re just getting to the good parts of the book.

Richard Goering