Cadence Community

Highlights From ClubT Hertzelia

teamspecman — Thu, 19 Nov 2009 19:52:00 GMT

Over 125 Verification engineers honored us this past Tuesday by attending the annual "ClubT" in Hertzelia. Here are some of the highlights (and if you were an attendee please post your feedback or follow-up questions in the comments below):

Main themes:

There was high interest in latest updates delivered in recent versions, with particular interest on the 9.2 version that just came out. (Apparently quite a few of the attendees are approaching the point in their project cycle(s) where they are free to upgrade versions.)
There was also a lot of interest in our future roadmap proposals, and how users will be able leverage and/or trade off their "magic" vs. compute resources.
dentifying, debugging, and fixing bugs faster is clearly a growing issue. Note that this includes making improvements in error messaging and results display such that it's easier to understand the behavior of the simulation.
Questions also came up about leveraging multi-core technologies for increased testbench simulation performance.

Verification CTO Yoav Hollander takes his turn driving the panel discussion

11 presenters gave bite-sized, 20 minute sessions, which helped simultaneously maintain focus and momentum throughout the event. And in retrospect, this observation might seem obvious, but having the event completely in the local language (Hebrew) helped maintain audience focus too.

The customer presentation on their conversion from e to SystemVerilog and back to e again was almost too positive -- apparently some in the audience wondered if it was a Cadence Marketing guy was giving the presentation! (It was not -- he was the real thing, telling a true story.)

As per the themes listed above, the topic of the panel discussion, "Why Does Debug Have To Be So Costly?", seemed to be well aligned with the audience's interests. The panel itself comprised 4 customers (Intel, Zoran, Marvell, and Ace Verification), and 3 Cadence R&D leaders (Yoav Hollander, Shlomi Uziel, and Ronen Shoham).

In what is becoming a ClubT tradition, the round table on our future technologies was the most popular. And unlike ClubT Europe, we were able to give live, interactive demos in this venue. [Note to Club EU attendees: Team Specman asks your forgiveness for just showing slides and not a live demo -- we'll change this next year!]

Things to improve for next time:

Evidently the momentum of the event was a little too strong, as by the end of the day people were too worn out to get the most from the round table sessions.
For future panels we need better balance the time allotted for introductory statements to give more time for the Q&A.

ClubT Hertzelia attendees: please give your feedback and suggestions for future events in the comments below!

Happy Verifying!

Team Specman

On Twitter: @teamspecman

User Interview: How ECO Handling Works With Equivalence Checking

rgoering — Thu, 19 Nov 2009 14:00:00 GMT

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

Observations From This Autumn's Events

jvh3 — Wed, 18 Nov 2009 14:00:00 GMT

As you may recall I was involved in producing several events this past fall. Allow me to share a few nuggets from the experience:

Specialization Is Accelerating
As industries advance, there is always a natural trend toward increasing specialization since the given technologies evolve beyond the ability of any single person to handle the wealth of growing knowledge. For example, 100 years ago a doctor could be trained in virtually all the medical knowledge that there was at the time; commonly dabbling in surgery, anesthesiology, obstetrics, etc. in the course of their practice. Today, of course, there are numerous sub-specialties within ever narrower categories of practice.

In EDA, there is finally a broad recognition that verification is a significant specialty in its own right. However, those in the vanguard of verification -- namely, Specman users -- appear to be themselves sub-dividing into distinct areas of domain expertise under the verification umbrella. Specifically, at many of the Specman-centric "ClubT" events, I was surprised to learn that this theoretically homogenous group was starting to splinter into Electronic System Level (ESL), analog mixed signal (AMS), and testbench integration-specific aspects of verification (to name just a few emerging specialties).

The User Presentation "Catch 22" Continues
Less surprising was the ongoing trend of users wanting to see more user-created presentations, yet being unwilling to contribute presentations themselves. Granted, some of this is economically driven in that a given engineer is fearful of asking their management for time and legal permission to work on a paper. However, the main negative factor here is a blanket, hyper-concern for IP leakage and/or revelation of secrets. While it's clearly good to be protective of hard-won IP, I think many companies are over-doing it to the detriment of all. They could stand to trust their people more, and/or just coach them a little. [I'll get off this soap box now & save it for a future post.]

ESL's Time Has Come
I've been in engineering long enough to have seen the first wave of ESL crest back in the late 90's. The interest in ESL was as sincere then as it is today; but this time around there was a critical difference. Long story short, it was evident that fellow veterans of the first ESL wave have a much better idea of what they are looking for from the second. If you are a specialist in RTL tools & methodologies, and this news surprises you, I strongly recommend you start following my colleagues' System Design and Verification blog stream (and read and internalize all the prior posts too).

As always, I invite you to share your observations in the comments below, or tweet them with an #EDA tag in your quip.

Joe Hupcey III

Twitter: @jhupcey

Guest Blog: Characterizing Process Variability At 32 nm And Below

rgoering — Wed, 18 Nov 2009 14:00:00 GMT

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

What's Good About the SPB16.3 Release? Join The Virtual Conference 12/02/09 and See!

Jerry GenPart — Tue, 17 Nov 2009 16:23:00 GMT

You will NOT want to miss this event! The first ever Virtual Trade Show for the SPB products will take place on December 2, 2009. Mark your calendars and register ASAP!

The event opens at 11:00am EST. All the Cadence® SPB16.3 products will be covered - Allegro® and OrCAD®, PCB and IC packaging/SiP design technology.

To attend this event - simply register here

You can read more about this from the main Cadence PCB site as well.

You can read about some of the technical details of the SPB16.3 release in the news article - "Cadence Leverages New Miniaturization Capabilities to Advance PCB Design Leadership"

Some key takeaways:

The Allegro and OrCAD PCB Design Release 16.3 brings PCB engineers significant new benefits, including the ability to miniaturize the footprint of their end product and reduce the number of physical prototype iterations, making the design cycle more predictable.
“We participated in the multiphase beta program for release 16.3 and were very impressed,” said Vincent Di Lello, senior PCB designer at Kaleidescape Canada, Inc. “The improvements in this new version address our miniaturization design challenges very well, and we look forward to adopting this new release into our design flow at the earliest opportunity after it is available.”
Extended micro via stacking rules allow users to create the most difficult HDI designs, and multi-line curved bus routing that hugs the flex outline accelerates the creation of rigid-flex designs.
An integrated 3D PCB viewer gives designers visibility into components and HDI micro via breakouts, thus eliminating unnecessary iterations with mechanical design teams.
The Allegro PCB RF Option also helps engineers speed the time to create accurate RF circuits through the use of asymmetrical clearances for one or more RF elements.
“This latest Allegro release provides many improvements to address miniaturization design challenges on a rigid or rigid-flex design,” said Scott Miller, chief operating officer at Freedom CAD. “As a design services company, we are always interested in improving our designer productivity and design process predictability. We will be moving to 16.3 and also recommending our customers to migrate soon.”
OrCAD Capture CIS, for instance, now offers autowire capability to quickly add connections, as well as new 3D footprint viewing.
OrCAD PCB Editor provides 3D viewing and “flip-board” design/editing and jumper support for single-sided PCB designs.
OrCAD Signal Explorer has a revamped user interface, with drag-and-drop and copy-and-paste functionality, context-sensitive RMB functions and native IBIS model support.
The Allegro PCB Signal and Power Integrity software offers a new user interface and adds stack-up-aware capabilities to the pre-route analysis environment. Buffer modeling standards are embraced through native IBIS and SPICE support, including Cadence Virtuoso® Spectre® Circuit Simulator models. Another improvement that boosts design cycle management is the ability to quickly scan a PCB with dozens of multi-gigabit signals and quickly determine where detailed analysis should be applied as signals are ranked according to their signal-to-noise ratio.
The Part Data Management solution now offers an integrated ECAD, MCAD part creation, generation and distribution capability that reduces unnecessary physical prototype iterations. The new part introduction capability extends management, notification of pre-release and temporary parts to shrink the design cycle. In addition, engineers can implement part updates automatically based on approved, recommended replacements, ensuring quality of results through obsolete part tracking.
The Allegro and OrCAD PCB Design Release 16.3 will be available for download by customers in early December 2009.

Keith Felton, Group Director of Product Management at Cadence says - "It's really like going to a mini DAC in a way, but through your computer."

Here are just a few of the highlights:

You'll hear from the SPB Marketing team as they introduce the new features and functionality of the SPB16.3 Cadence® Allegro® and OrCAD® printed circuit board (PCB) software
You can talk to people through on-line chats
You'll see virtual booths with presentations and demonstrations
You'll be able to watch videos
There will be white papers you can review
You'll hear from a number of guest speakers

You can visit 7 booths of interest within a virtual exhibition hall. Each booth targets a specific design task and contains information on the most recent technological improvements:

Allegro design authoring
Allegro PCB implementation
Allegro high-speed design
Allegro Design Workbench
Allegro IC packaging and SiP design
OrCAD PCB design
FPGA design

In addition to learning about the new SPB16.3 product features, there will be speakers from both the PCB industry and customers. Here's just a sample:

Keynote Speaker - Clive Max Maxfield, President TechBites Inc.

Keynote Speaker - Keith Felton, Group Director of Product Management Cadence Design Systems

Motorola - Al Craver Senior Manager & Chris Day, Senior Solutions Engineer

Xilinx - Brian Jackson, Director

PTC - Andreas Kulik, Product Manager

Dassault Systemes - Rob Shinno, High Tech Market Development Global Director

Artwork Conversion Software - Steve DiBartolomeo, Applications Manager

Schlumberger - Mark Mosser, Business Analyst

Apache Design Solutions - Dr. Ji Zheng, Director of Engineering

PCBDesign007 - Andy Shaughnessy, Editor

SI GUYS - Donald Telian, Consultant

DownStream Technologies - Richard A. Almeida, Founder

Freedom CAD Services - Robert Jardon, Senior PCB Designer

Leventhal Design & Communications - Roy Leventhal, Consultant

DFM - David Price, President

Bayside Design - Kevin Roselle Chief Technical Officer

As always feel free to comment about what you'll be focusing on during this event and I'll post again after the 12/2/09 conference with a review.

Jerry "GenPart" Grzenia

Things You Didn't Know About The Rhinovirus and ViVA (Part 3)

stacyw — Tue, 17 Nov 2009 14:00:00 GMT

Okay, so I really have no idea how to tie those 2 things together, but I ran across this little widget the other day and just had to share it (slide the slider until it's about 2/3 of the way across). I know we've all seen electron microscope images of those transistors we're fiddling with, but do you really have any idea how small they are? Maybe you do, but I don't think I realized that the length of the gate of that transistor you're about to put in your circuit is the same size as a single rhinovirus (that's the common cold to use layfolks). Looks like you could fit a whole inverter inside of an influenza virus (would that make it not an influenza virus?). All I can say is...wow...and don't sneeze on my chip...

Okay, now on to our main topic--the ViVA Results Browser and a few useful features you may not have known were there.

Results Browser (RB)

The RB can be invoked from lots of places--from the Tools menu of the ADE L window or any ViVA graph window, from an icon in an ADE XL window, even from the CIW. And of course, the RB is your main base of operations if you invoke ViVA stand-alone. Once you've found it, click on the little icon that looks like a file folder to find a waveform database and open it. Go ahead, open more than one at a time. That's one of the real powers of the RB.

Searching through the hierarchy and through multiple databases

The bottom half of the RB has 2 tabs. If you click on the Search tab, you can enter a search string and find all the signals throughout the hierarchy in all open databases matching that string. Then you can select (or Ctrl-select) what you're interested in click the right mouse button and plot them. This is a quick way to compare the same signal from multiple simulations or to find a signal buried deep in the hierarchy.

Sweep Range

One way of sorting through the clutter of a large database, especially the results of a parametric sweep is to use the "Select Sweep Data" feature. This can be accessed by clicking on the icon at the top of the RB that looks like a set of horizontal lines with a curly bracket next to them (or from the Options->Select Data... menu item). If you have a parametric sweep database, you can then selectively highlight just the parameter values for the data you want to plot and instead of getting a whole family of curves, you'll only get the ones you want. If you've just got a single sweep database (like a regular transient run, for example), this features comes in handy to load only a limited slice of a large database. Just enter the start and end times in the form (use scientific notation for this--for some reason suffix notation doesn't work) and only that section of the waveform will be loaded and plotted.

Y vs. Y

Another feature of the RB that is fairly cryptic to use is the Y vs. Y plot. If you want to plot 2 signals against each other, here's how to do it. First click on the signal you want to be on the Y axis. Then click on the Y vs. Y icon at the top of the RB (looks like one Y with another Y lying down next to it). Finally click on the signal you want to be on the X axis and voila! the plot appears. Just remember, Y, then X.

Export

Finally, I wanted to point out some of the powerful data export features in ViVA. A waveform or trace can be exported from the RB (File->Export... or RMB->Export...) or from the graph window (select trace, then Trace->Save... or RMB->Save...). One popular application of this is to save the waveform in Spectre format so it can be used as stimulus in a Spectre PWL source. You also have to option to sample and/or interpolate the data to get specific step sizes.

Another useful application is to save one or more waveforms (or time slices of the waveforms) to PSF or SST2 format in order to reduce the size of the database. Data can also be saved in Matlab or CSV format for additional post-processing.

Happy browsing until next time...

Stacy Whiteman

User Panel: Can Formal Tools Reduce Need For Simulation?

rgoering — Mon, 16 Nov 2009 14:00:00 GMT

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

Interview With Teradyne on Metric Driven Verification

Team MDV — Fri, 13 Nov 2009 14:00:00 GMT

Welcome to the first TeamMDV blog. We are excited to bring you information, tips, tricks and recommendations all centered around Metric Driven Verification (MDV). To start, here is an interview with Dylan Dobbyn, the verification manager at Teradyne, about their first time experience in implementing MDV. Check out Dylan's recent Chip Design article on "Metric-Driven Verification: The Key to Achieving a New Level of Productivity"

Q: First of all Dylan, thank you for taking the time to articulate to other users your experience in MDV. Let's start with an easy one, tell us a little bit about yourself and Teradyne?

A: My pleasure. Teradyne is a test equipment manufacturer based in the Boston area with 1.1B in sales for 2008. Teradyne designs and manufactures the test equipment, which is used primarily by electronics companies. I am the Verification Manager for the Semiconductor Test Division.

Q: What were the big reasons why you decided to make a change to MDV?

A: Like a lot of companies these days, we were under pressure to cut costs, and at the same time, we were coming out with a new and more complicated chip design for one of our testers. We also wanted to improve our verification environment, so that we could improve both visibility and predictability of the verification process. Measurements are the key to success, and keeping the old process with limited visibility and schedule padding was not an acceptable option. Today's project management requires a predictable process, and we knew we had to do something different than we had been doing in the past.

Q: What made you decide to choice the MDV approach?

A: Project managers were clamoring for metrics. Cadence provides metrics. The decision was easy. Additional benefits of streamlining the verification the process turned out to be an added bonus.

Q: Can you tell us a little bit about how painful this was given your existing verification environment?

A: We did struggle a bit in getting started. Teradyne products have a long life cycle which translates to a lot of legacy code and environments. Additionally, large projects required 64-bit simulation environments, which was another hurdle to jump. We needed the additional the address and memory space, but had to make sure our code was still able to run properly.

Q: What was the single biggest challenge with this change?

A: Our single biggest challenge was upgrading legacy environments to run with the latest product release, which takes full advantage of the MDV features. Specifically, this using Incisive Enterprise Simulator (IES) and Incisive Enterprise Manager (IEM). The tool upgrade was actually more challenging then implementing the new MDV methodology, which actually went pretty smooth.

Q: What do you think the benefits will be in the end?

A: Predictability of course, but also efficiency. As we rely more on constrained random testing, improved methods are important to keep the simulation resources and debug times under control. We also ended up with a plan based flow, which we did not have previously. We intend on leveraging this solution to not only improve the robustness of the reusable plan, but also to reduce our total verification time even further with even more automation.

Additional information about MDV can be found at the following locations:

MDV101 Video from Demo's-On-Demand - Link
Maximizing Verification Effectiveness Using Metric-Driven Verification Whitepaper - Link
Metric Driven Verification Cadence.com Website Address - Link

Team MDV

Android System Verification Part 2

jasona — Fri, 13 Nov 2009 14:00:00 GMT

In Part 1 of this series on Android System Verification I provided the basics about how to run the Android emulator. When I initially looked at the emulator I was looking for information about available verification techniques, primarily at the system level. I surmised that many Android projects aggregate the available software, add some new custom software to support a specific hardware platform, enable the wide range of available applications, and put all of this together to create a product. Android...(read more)

User Interview: Formal Analysis Speeds IP Connectivity Verification

rgoering — Thu, 12 Nov 2009 17:00:00 GMT

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.

We and Our Competitors Agree (Well, Almost!)

SteveSvoboda — Thu, 12 Nov 2009 14:00:00 GMT

It’s rare in EDA to see competitors agreeing, but an interesting article in EEtimes Europe this week caught my eye, by Lauro Rizzatti the VP Mktg of EVE. Lauro discussed a survey EVE ran during DAC, where they asked customers how they felt about the current state of hardware-assisted verification, what their priorities were, etc. One paragraph really stood out (emphasis mine): “More interesting was the ranking of six criteria in selecting the next hardware-assisted verification platform...(read more)

What's Good About Cadence Online Support? – Here’s My List!

Jerry GenPart — Wed, 11 Nov 2009 15:03:00 GMT

My good friend and fellow blogger - Bob Dwyer - recently posted on the new Cadence Online Support.

Bob did a terrific job and I encourage you to read his post - Find, Fix And Learn With Cadence Online Support

Bob's provided screenshots, highlights, and suggested tips for navigating in the system!

The new Cadence Online Support was released in a Beta mode on 10/26/09.This Beta technique has been used by several companies (including Google) to recieve valuable customer feedback prior to launching the post-Beta release. The Cadence Online Support team has received several very good suggestions for how to further enhance the site. There are of course, other areas where we know we need to make adjustments and those tune-ups will happen in subsequent releases. You can read more about the details here - Cadence Online Support Goes Live! "We designed the infrastructure to be scaleable and we are excited to be able to plan for a steady stream of releases in the coming months," stated Joe Kugler, Director of Web Enablement. A closed-loop feedback system will capture user comments. The "Feedback" page tool is present on all Cadence Online Support pages.

My personal favorites of the NEW and improved features are:

Searching across all areas of content including - Troubleshooting, Product Manuals, New or Changed Features, Design Info, Blogs and Forums. Some of these are new areas for simultaneous searching.
Much faster search with cleaner returned results. By cleaner, I can see the type of results (Troubleshooting, Blogs, etc. in a clearly categorized visualization) the date, and I have a "Show Attributes" link that provides more details.
Filters provided on the search results pages so I can quickly adjust the results by product, date, etc.
The "Top 3 Overall Matches" list and "My Search History" - slick!
Search within a list of returned results - so I can find certain words/phrases to further narrow my results.
The overall streamlined look and feel. I can access everything quickly from the top menus.
The "My Service Requests" section is on my Home page and I can quickly review the details. I like to use the middle-mouse button to open links in new browser tabs, so navigating and reviewing multiple Service Requests is a snap.

As the next release features roll-out (you can read the plans in the link above), I'll be back to discuss those and get yourfeedback.

I welcome your "favorite things" feedback about the new Cadence Online Support system. I would encourage you to provide formal feedback to the Cadence Online Support team by clicking the Feedback link at the top of any page on the site.

Jerry "GenPart" Grzenia

Panel Question: Should Designers Do Their Own Verification?

rgoering — Wed, 11 Nov 2009 14:00:00 GMT

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

IntelliGen Lab Now Live on Xuropa - See What You Are Missing!

teamspecman — Tue, 10 Nov 2009 16:00:00 GMT

Team Specman guesstimates that a majority of users have migrated to "IntelliGen" -- the all new, Aspect-Oriented generation engine inside of Specman and IES-XL, and/or they are in the process of adopting IntelliGen now. However, in case your CAD configuration is just becoming unfrozen after a long project, or you just want to quickly train new users on this powerful technology, we are excited to announce there is a new lab on IntelliGen available now on the Xuropa online community. Simply go to:

http://www.xuropa.com/cadence
and click on the "Specman 'IntelliGen' Stimulus Generation Lab".

You can make a make one-off request to do the lab without signing up for the Xuropa community, or dive right in if you are already a community member. (Digression: the Xuropa community is an EDA-specific social network -- roughly similar to LinkedIn -- but with specific features to help you identify and connect with other professionals in your area of expertise (eg. verification, FPGA design, AMS, etc.)

IMPORTANT: this lab is not some cheesy Flash demo -- it's a real live, online workshop where you run and play around with the actual tool. This video by fellow blogger Joe Hupcey III from the DVCon 2009 launch of this lab platform for our VIP Portfolio elaborates on this new training medium.

Finally, as a refresher, here are some links to prior Team Specman posts on IntelliGen technology and methodology:

Introductory white paper published by the IntelliGen Team when it was first released back in December 2007

Generation Debugging With "IntelliGen" (With Video)

Generation Action: Constraints From Above

A New Generation Testcase Utility

IntelliGen Statistics Collection Utility

Performance-Aware e Coding Guidelines: Constraint Solver Tips

Constraint layering - Fine Tuning Your Environment - Part 1 and Part 2

Happy Generating!
Team Specman

P.S. This whole "online lab" experiment is an interesting one from the general perspective of "using the internet to enable people to do something that can be expensive to do effectively in-person". Of course the general idea is to give you the opportunity to get real training 24/7, on your own terms, and get the information you need without having to beg your boss for travel authorization or training budget. As such, if you try the lab -- if only in the interest of science -- please let us know if the experience "worked", and/or what can be improved to make it more valuable to you.

“Software Signoff” Raises Many Questions

rgoering — Mon, 09 Nov 2009 14:00:00 GMT

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

Android System Verification Part 1

jasona — Mon, 09 Nov 2009 14:00:00 GMT

From time to time I hear or read stories about how engineers find ways to apply Specman to verification problems that are outside of normal RTL verification. Often times they are about connecting Specman to a post-silicon environment such as a physical board. There are probably many of them, but a quick search on cadence.com turned up one published by Intel in 2006. Most of the time these applications of Specman are setup to drive the hardware, but often for the purpose of verifying the entire system...(read more)

Ten Things I've Learned About Formal

tomacadence — Fri, 06 Nov 2009 14:00:00 GMT

2009 is the tenth year that I've spent at least a portion of my time responsible for formal analysis products. As per my profile, my two most recent employers before Cadence were 0-In (now part of Mentor) and Synopsys. Between these jobs I consulted for eight other EDA companies, four of which offered formal products.

You would think that I've learned a few things during the past decade, and I believe that I have. Here are ten lessons I learned along the way, one for each year:

Formal should be applied early – any formal tool that requires an advanced simulation testbench as a starting point can only be run late in the project when there are few bugs left

Formal is about proofs as well as bugs – proving at least some assertions correct instills additional confidence in the design once bugs are no longer being found

Designers should be directly involved in formal analysis – many of the best assertions arise from designers capturing the assumptions in their heads

Automatic assertions can be interesting – while no tool can divine from RTL the intent in the designer's head, customers see real value in many types of automatic checks

You can't neglect the basics – R&D should not focus on exotic features at the expense of language support, robustness, and core engine performance

Assertion-based VIP should be a product, not a freebie – creating quality VIP is hard work that requires a serious resource commitment, so you should get paid for it

Coverage is a good way to link simulation and formal – customers understand coverage in simulation, so anything that formal can do to contribute metrics is a motivation for use

A good marketing story is not enough – licensing a generic formal engine from an external research lab and tacking it onto a “lint” front end does not yield a true solution

Moving users from “lint” to automatic assertions to full formal is not easy – it's better to demonstrate the value of user-specified assertions and formal right up front

It is possible to create a mainstream formal solution – Incisive Formal Verifier (IFV) is a successful product being used by logic designers as well as verification specialists

I learned the first nine things from my direct experience with customers and clients prior to arriving at Cadence three years ago. IFV was already a well established product at that point, so I realized when I joined that Cadence had also learned these important lessons even if some of its competitors had not.

Of course, IFV has continued to evolve since then, and I'm proud to have been a part of its ever-growing success. Now we've introduced Incisive Enterprise Verifier (IEV), offering novel links between simulation and formal analysis. We also have automatic assertions, high-quality assertion VIP products, coverage links, and the methodology and support for wide deployment.

The other day I sat in a Sales review at which I heard that just one Cadence customer, at just one of its sites, is actively using more than 200 IFV and IEV licenses. I could only dream of this sort of deployment in my past involvement with formal. I guess that we’ve all learned a few things in the past ten years!

Tom A.

The truth is out there...sometimes it's in a blog.

"ClubT" Herzelia Israel Verification Seminar Invitation 17 November

teamspecman — Fri, 06 Nov 2009 14:00:00 GMT

Specmaniacs Based In Israel,

Please join us for a day of in-depth presentations and demonstrations of the latest methodologies and technologies for advanced verification this 17 November at the Dan Accadia Hotel in Herzelia.

Specman users and Cadence R&D experts will deliver presentations and demos, as per the following agenda:

08:30-09:00 Registration

09:00-09:15 Welcome and Introduction

09:15-10:30 MDV flow & solutions
--> includes updates to Enterprise Planner, Enterprise Manager, OVM e & OVM Multi-Language, IES-XL siimulation, VIP and the Compliance Management System

10:30-11:00 How to build your own Compliance Management System

11:00-11:15 << Break >>

11:15-12:00 User Presentation: "Choosing verification language and methodology: a first hand testmonial", Wilocity

Technology deep dives:

12:00-12:45 OVM e and OVM Multi-language

12:45-13:45 << Lunch >>

13:45-14:30 Panel discussion: "The Debug Challenge"

14:30-15:45 IES-XL 9.2 technology updates and Specman 9.2 Core deep dives

15:45-16:00 << Break >>

16:00-17:00 Round table discussions with R&D:
- IntelliGen + Gen Debug
- Closure automation
- Verification IP
- Enterprise Manager & Planner
- IES-XL + SimVision
- OVM e / SystemVerilog / Multi-language　

To register, please contact Etty Alon: etty at cadence dot com

Hope to see you there!

Team Specman

Find, Fix And Learn With Cadence Online Support

BobD — Thu, 05 Nov 2009 18:00:00 GMT

We recently rolled out a new online support mechanism that replaces Sourcelink called Cadence Online Support. Point your web browser to sourcelink.cadence.com and you'll notice that it redirects to support.cadence.com.

Improving the search capabilities was one of the major focuses of Cadence Online Support. A single box enables searching across the following areas:

Troubleshooting
Product Manuals
New or Changed Features
Design Info
Blogs and Forums

Additionally, the "Top 3 Overall Matches" across all of these areas are returned. The result, hopefully, is that it's easier to find the information you're looking for. Check it out and let us know how we're doing.

(click to enlarge any of these images)

You can also provide Feedback specifically about any page on the new site. Please take advantage of this capability- we really want to hear what you think and your Feedback will be responded to and tracked to closure:

The new site surfaces up your most recent service requests, and provides a link to create a new service request:

Finally, the site offers a way to learn about how our tools are intended to be used with "Design Topics". Design Topics are the place to look when you don't have a specific bug or issue you're trying to troubleshoot but rather when you want to understand conceptually what Cadence recommends at any given stage on the design process. This information is accessible via Design Topics->View Design Topics on the top of Cadence Online Support pages. Here's an example of the available subtasks within Block Implementation. You can expand any one of these subtasks for more information -or- go directly to any one of the Technical Topics for more information:

So there you have it: Find, Fix and Learn. Click HERE to learn more about Cadence Online Support (login required using your existing Cadence.com password).

Question of the Day: What do you think of the new Cadence Online Suport so far? Leave a comment below or make use of the Feedback mechanism within Cadence Online Support.

Bob Dwyer

DFT Challenge: Evaluating The True Cost Of Test

rgoering — Thu, 05 Nov 2009 14:00:00 GMT

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

Things You Didn't Know About Virtuoso: ViVA (Part 2)

stacyw — Wed, 04 Nov 2009 14:00:00 GMT

This week's installment, boys and girls, is brought to you by the letters H, V, m & a and by the symbol %. Apologies to anyone out there who didn't grow up with Big Bird and Cookie Monster. (Is that even possible?)

Remember those letters, we'll get back to them in a bit...

First a couple of FAQ's about axes in ViVA.

How can I tell which axis a signal is associated to?

Well, this isn't the easiest thing in the world, but if you look very closely, you'll notice one or more colored bars next to each axis title. They only appear if you actually have more than one axis on your graph, which will happen if you plot quantities of different units (like voltage and current). If you look closely, you'll see that the colored bars on each axis correspond to the colors of the plotted signals associated with that axis.

How can I move a signal from one axis to another (or to a new axis)?

This is easy. Simply select the signal you want to move by clicking on the waveform or it's name in the legend (don't forget you can use the Alt key--one of the sponsors of last week's episode--to quickly see which signal is which). Then, from the menu, select Trace->Assign To Axis and either select the axis you want to move it to or choose New Axis to do just that.

Now a word from our sponsors...

The letters H, V, m & a are the bindkeys you use to create interactive marker measurements in ViVA.

H (that's capital H, or Shift-H) will place a horizontal marker and Shift-V will--no fair, you peeked--place a vertical marker.
m (that's little m, without the Shift) will place a single point marker.
a (again, lowercase) will create a delta marker between itself and the most recent "m" marker.

There are several nice things about these markers.

You can have as many of them on your graph as you like.

You can select Marker->Show Table to get a tabular readout of all your marker intercepts with your signals. There's also an icon to do this. I'll let you find that on your own. If you move the markers (or rerun the simulation), simply press the Update icon in the marker table to refresh the values. This table can then be saved to a file for documentation.

They stay where you put them (unless, of course, you drag them to move them somewhere else--or delete them)

Speaking of dragging, you can drag the marker labels around to position them wherever looks nicest, without disconnecting the marker from the trace.

Speaking of marker labels, that's where our final sponsor comes in, the mysterious % symbol. First, double-click on the marker label to bring up the marker attributes form. The marker labels can be customized and the % sign is used to create some powerful types of formatting. The complete list can be found in the Virtuoso Visualization & Analysis Tool User Guide, but here are a few useful examples:
- %X, %Y will display the X and Y coordinates (%x, %y will display the 2nd X and Y coordinates for delta markers)
- %W, %H will display delta X and delta Y
- %N will print the name of the trace (handy on a crowded graph)
- My personal favorite, %E, works with the Expression field in the form to allow you to pull an expression from the calculator buffer or one of the calculator memories (more on that in a future episode) and annotate it directly onto the graph. This way you can get a clear visual representation of what is being measured. (Note: This was broken for a while, so make sure you've got the latest IC6.1.3 ISR if it doesn't work for you)

Now you can use the File->Save As Image or File->Print menu to save your beautiful graph to display at your design review.

Stacy Whiteman

OVM Innovation Means Business

Adam Sherilog — Tue, 03 Nov 2009 20:01:00 GMT

Today, Cadence recognized it's OVM team for their innovative contribution to the Cadence enterprise starting in 2008. Why enterprise? To me, enterprise is the most exciting part because it underscore how the OVM has rallied all of Cadence verification around a common cause which has both polished our image as the verification leader and created new business opportunities.

To understand the impact, we need to step back to 2007. SystemVerilog implementations were just coming together and VMM was a mix of SystemVerilog and Vera. e and eRM, on the other hand, were well established with years of success at this point. So why OVM? To unify the ecosystem. OVM was the first open, multi-vendor, scalable methodology architected for multi-language. Looking back, this statement seemed simple enough, but the simplicity is the innovation.

Open. It doesn't get more simple than that, but it was a rallying point in the marketing and development that changed everything. The OVM started as both Apache licensed and multi-vendor and, in fact, remains the only verification methodology embodying both. With a community now 8000+ strong as measured on the OVM World website, the marketing and development simplicity certainly resonated.

Scalable. The OVM introduced to the SystemVerilog community the agent-architecture used by the e community for years. The concept itself is simple -- a consistent way to describe verification components for reuse -- but is backed by a sophisticated implementation. The innovation here is all technical -- place the burden of complexity on the methodology/library developer and provide the consumer with ease of use.

Creative: Building on past success was important, but new solutions were needed to win the hearts and minds of the nascent SystemVerilog community. The development team built an advanced factory mechanism, field automation, test classes and test selection mechanism, and more many of which have found their way into competing libraries due to that bold move to be open. As the next point will show, the team has never looked back. The creative stream is still flowing with callbacks, configuration mechanism, OVM multi-language capabilities, and much more.

Passionate. Did that one surprise you? If you have talked to anyone from the extended OVM team -- and there are hundreds of us -- that is our simple connection. I've been with Cadence for 18+ years and working with the OVM rekindled the start-up in us. We argued. We fought. We united and we delivered. And we are still doing that today. The simplicity of that emotive drive assures that you get the best out of us all the time, every time. Maybe that was latent in the team for a while, but we are certainly bringing it now. And for those on the internal team, you know we were doing that even today. :-)

I know this blog was a "pat on the back" for the OVM team, but we all need to step back from time to time and assess ourselves. We're proud of the innovation we have brought to verification and even more proud to say we ain't done yet!

=Adam Sherilog on behalf of the whole OVM team

Today's Innovation Awards and The "Trailblazer" Marathon

jvh3 — Tue, 03 Nov 2009 19:00:00 GMT

Today myself and the whole Trailblazer team are proud to celebrate the success of my colleagues' winning awards on Cadence's "Innovation Day". In specific reference to the verification segment winners, over the past year I've had a front row seat to their struggles. They will be too modest to admit this, but let me tell you there were times when it was really dark for them.

Boston Marathon: Hearbreak Hill

But despite temptations to settle for less ambitious solutions, guided by their years of industry experience, deep technical expertise, collegial teamwork, as well as the strength derived from their hobbies (like running marathons -- no kidding, see above), they persevered to deliver on their innovative roadmap.

Fast forward to the present:

The Trailblazers are currently in mile 20 of a product development marathon to automate verification in ways no one has dared attempt before. In Boston Marathon terms, it feels like we are ascending Heartbreak Hill; so to say the least it's encouraging to have our award-winning colleagues cheer us forward as we count down the remaining miles!

Joe Hupcey III

P.S. Fellow blogger and Cadence Innovation Day award winner Adam Sherer is a real live marathon runner, who has requalified and committed to running his 8th consecutive Boston Marathon for the benefit of Children's Hospital. Beating the Patriot's Day rush by sponsoring Adam now will no doubt inspire him during his 5AM winter training sessions!

Cadence and Very Cool Stuff

Rich Owen — Tue, 03 Nov 2009 17:44:00 GMT

One of the very cool things about my job is that I get to see all kinds of new stuff early. I’m privileged to be involved in technology roll outs, and so get to be involved in early discussions with R&D, Product Engineering, and Marketing. And, I gotta tell you, there is very cool stuff coming out.

As I think we’ve established, I’m a geek. (And there’s my daughter again, rolling her eyes, and saying, “tell’em something they don’t already know, Dad.”) And so when I get a chance to see some of the new stuff being prepped by our R&D teams, I get pretty excited.

Here’s just one thing that’s on the burner – a method to explore the power solution space. I met a good customer today, and he very accurately pointed out that Power Shut Off (PSO) is a system function. The system designers very clearly know what blocks can be shut off when – it is a system function. But Multi-Supply Voltage (MSV) is another matter. Fundamentally MSV is about trading off speed for power – the faster you need it, the more power you’ll need. And this really means that any effective power estimation solution needs to consider the libraries, architecture, and expected implementation. If you don’t consider these, you’re not looking at the full picture. In the absence of the ability to estimate the impacts of timing, any kind of architectural analysis is largely meaningless. I mean, why not set the voltage on everything to 0.1v? You’ll save a ton of power. Of course timing closure might be a bit challenging.

So we’re getting ready to come out with something that will allow exploration of the power solution space; something that will really allow you to trade off speed for power. You set up the starting points – stuff like the libraries, constraints, and the like. You then set up the bounding conditions – the allowed solution space. The tool will then go off and run through the scenarios, identifying the best combination of voltages that will meet your timing and power targets. Under the hood, the tool is taking advantage of RTL Compiler’s target setting function to identify whether a given scenario will meet the requirements.

This will take the guess work out of MSV designs. What I really like is that this is the same technology that will then produce a production quality netlist. So correlation is not an issue – there’s no magic library conversions or RTL manipulations to produce this. You pour RTL, libraries, and constraints in, and you get the right scenario out. And you can then just push the button to implement the scenario.

As I mentioned, I was at a customer today. With me were two members of the R&D team – both PhDs and both widely known in the industry. We were presenting the challenges of low power design and how Cadence flows and methodologies solve those challenges. Now these are seriously smart people, and to see their passion and enthusiasm for the technology was contagious. These R&D guys really know their stuff, and they’re committed to making my customer successful. Cadence has (obviously) being going through a down cycle. But with guys like these, and with the technology we’ve got, no one should count us out. Nor should anyone discount our commitment to our customer’s success. We still have the best flows and tools and technology, and we’re still driving the innovation in the industry. We’ve not changed our passion or commitment one little bit – and don’t let anyone tell you differently.

Oh, and here’s a chance for you to hear about the latest innovations in the Front End Design space: Cadence is hosting the annual FED Event in San Jose on Nov 10. This is an event with R&D leaders discussing the new technology and innovations coming out in the next releases. You’ll hear from all of the R&D leaders in this space, and hear from other customers using our technology. And you’ll even get to see me – I’m on a panel offering my perspective about FED. Sign up at www.secure-register.net/cadence/ld_event2009 and I hope to see you there.

Rich Owen

Greatest Moments In EDA Innovation

rgoering — Tue, 03 Nov 2009 14:00:00 GMT

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