Industry Insights

SystemC AMS – A New Proposal For Mixed-Signal Verification

2010-03-18T13:00:00Z

In an effort driven by European semiconductor companies and universities, the Open SystemC Initiative (OSCI) last week announced the first version of the SystemC analog/mixed-signal language standard, AMS 1.0. Since Cadence is the industry leader in mixed-signal design and verification, and is strongly promoting a transaction-level modeling (TLM) based design and verification flow on the digital side, it's natural that folks at Cadence would take an interest in this development.

The message I get from our mixed-signal team is that while it's too early to speak of any potential support plans, Cadence is watching this development carefully and is seeking to learn more about the proposed standard and its current and future applications. We are reviewing closely the use of SystemC AMS, how it compares to other mixed-signal behavioral modeling approaches, and what the level of customer interest is.

Some background and commentary about SystemC AMS follows.

What it's all about

With increasing analog and mixed-signal content on systems-on-chip, design teams are looking for faster ways to run system-level simulations. They also need to incorporate mixed-signal functionality into system-level design and architectural exploration. Spice and Fast Spice are too slow for full-chip, top-level verification, and even languages like Verilog-AMS can pose a performance bottleneck.

According to the OSCI announcement, SystemC AMS extends the SystemC class library to provide functional modeling, architectural exploration, virtual prototyping, and integration validation for "embedded analog/mixed-signal systems." The extensions are intended to help engineers understand the interaction between hardware/software and mixed-signal subsystems at the architectural level.

A SystemC AMS whitepaper points out that system-level tools such as Simulink are often used for functional modeling but don't target architecture. It adds that Verilog-AMS and VHDL-AMS don't support hardware/software co-design at a high level of abstraction, and that co-simulation that mixes SystemC and Verilog-AMS or VHDL-AMS does not provide sufficient performance.

The whitepaper describes three types of SystemC AMS extensions:

Linear signal flow (LSF) models instantiate signal flow primitives such as adders, integrators, or transfer functions. They require a linear differential equation solver.
Electrical linear networks (ELN) instantiate predefined network primitives such as resistors or capacitors. They also require a linear differential equation solver.
Timed data flow (TDF) models consist of modules that are connected to signals using TDF ports. They accelerate data flow simulation by using static scheduling that is computed before the simulation starts.

The SystemC AMS 1.0 language reference manual (LRM) and associated documentation can be downloaded from the OSCI web site. Meanwhile, a 2009 article by Martin Barnasconi of NXP, OSCI AMS working group chair, provides more detail about modeling formalisms. The article notes support from NXP, STMicroelectronics, and Infineon in addition to several universities.

Questions and commentary

The basic idea behind SystemC AMS is right - mixed-signal design and verification need to move to higher levels of abstraction in order to run much faster. "When we talk about a system strategy, we need to make sure we include analog," said Andreas Kuehlmann, director of Cadence Research Labs. "To simulate any functionality, you need to simulate analog components together with software, processors, DSPs and so on."

There are, however, a number of practical questions, such as what one can and cannot do with transaction-level modeling in the analog world. Another question is what capabilities SystemC AMS might provide compared to other analog modeling approaches for high level design and verification, like Verilog-AMS wreal and VHDL real, and mixed language approaches like the combination of SystemC with Verilog-AMS/VHDL-AMS in a true mixed-signal simulator.

As noted in a recent whitepaper, real number models can represent analog behavior in a digital context, and the Cadence Incisive Enterprise Simulator can then run wreal and real models in a pure digital environment with all the advantages of high performance and metric-driven verification. Virtuoso AMS Designer can deal with mixed-language scenarios including SystemC, Verilog-AMS, VHDL-AMS, and Spice, providing a smooth path down to transistor-level implementation if needed.

So far, most of the push behind SystemC AMS has come from a few large European semiconductor companies, especially NXP, and academia. Now that the standard is out, will the interest extend more broadly? "As part of our interest in system-level analog modeling, this [SystemC AMS] is one of the options we will carefully monitor," Andreas said.

Feedback from analog/mixed-signal designers is very welcome!

Richard Goering

ARM AMBA 4 Protocol And VIP – A Closer Look

2010-03-17T13:00:00Z

ARM last week announced the first phase of its AMBA 4 specification, and Cadence simultaneously released Incisive verification IP (VIP) for the e language and SystemVerilog. So why is ARM releasing AMBA 4, what's in the two phases, and what's in the VIP? To get a closer look at what's in the AMBA 4 specification I talked to Keith Clarke, vice president and general manager of Fabric IP at ARM's Processor Division.

The widely-used AMBA 3 spec has been around since 2003, and it was time for an upgrade, Keith said. He noted that AMBA 4 was developed in conjunction with some 35 partners, including Cadence. A big motivation, he said, is the increase in performance of processor cores, as well as the ability to place multiple cores on SoCs and to support many different functions on a chip.

Additionally, the phase one release that was disclosed last week adds new support for FPGAs. Phase one includes the AXI4, AXI4-Lite, and AXI-Stream protocols. The phase two release, which will be disclosed later this year, will bring in features that will help users develop and program multicore SoCs.

Pete Heller, product line manager for VIP at Cadence, said he is "definitely seeing interest" among the customer base for AMBA 4. "The traditional mobile guys are currently planning their roadmaps for it," Pete said. What's attracting customers, he said, is increased performance, along with a hoped-for power savings.

AXI4 Protocol

AXI4 is an incremental and backwards-compatible update to AXI3 that improves performance and interconnect utilization for multiple masters. It supports burst lengths of up to 256 beats (data packets). Previous support only went up to 16 beats. "We don't foresee ARM processor requests for 256 beats of data, but we do foresee certain types of masters, in certain types of applications, that do need these long transactions of data," Keith said. An example, he said, could be a data interface in a networking application.

AXI4 also adds quality-of-service (QoS) signaling and support for multiple-region interfaces.

AXI4-Lite Protocol

This is a subset of AXI4 designed for communication with simpler, smaller control register-style interfaces. It can reduce the number of wires required to access "peripherals that have simpler needs." While designed with FPGAs in mind, "there is nothing to stop it being used for SoCs," Keith said.

In this protocol, all transactions have a burst length of one, all data accesses are the same size as the width of the data bus, and exclusive accesses are not supported.

AXI4-Stream Protocol

This protocol, unlike AXI4-Lite, is not a strict subset of AXI4. Designed primarily with FPGAs in mind, it aims to greatly reduce signal routing for unidirectional data transfers from master to slave. The protocol lets designers stream data from one interface to another without needing an address, Keith said. It supports single and multiple data streams using the same set of shared wires.

AMBA 4 Phase Two - Simplifying Multicore SoC Design

ARM is not saying much about AMBA 4 phase two now, but the company has noted that it will provide hardware support for cache coherency and message-ordering barriers. By putting more capabilities in hardware, AMBA 4 will simplify multicore programming. Keith said phase two will "have quite a lot of new technology for coping with multi-master systems."

VIP Support

Cadence Incisive VIP support is "really important," Keith said. "Cadence announcing so quickly is really good news for our customers who want to get a start on designing with AMBA 4." Verification IP, Keith noted, is increasingly important because "the complexity of devices has gone up, and people need to know when they attach various design IP blocks together that they are actually talking the same language."

Pete Heller said that the Cadence AMBA 4 VIP is currently available as part of an early access program for customers. It will be in production later in the year. In addition to the testbench VIP that is available today, Cadence will also provide assertion-based VIP for formal verification and transaction-based VIP for system-level verification. The VIP is OVM-compliant and will include the Cadence Compliance Management System (CMS), which supports verification planning and metric-driven verification.

Pete noted that Cadence AMBA 2 and AMBA 3 VIP has nearly a 10 year track record and has been used in well over 1,000 projects, and he said Cadence is regularly working with ARM to ensure the highest quality and to support phase two of the AMBA 4 release with VIP. A Team Specman blog has more details about the AMBA 4 VIP and tells how you can request early access.

Richard Goering

Bringing MEMS Design To The Mainstream

2010-03-15T16:00:00Z

Micro-electrical mechanical systems (MEMS) have been around for years, and have found their way into high-volume applications such as automobile air bag controllers, GPS systems, and inkjet print heads. But MEMS devices such as accelerometers, gyroscopes, RF switches and pressure sensors are not as widely used as they could be. There are three limitations to the widespread use of MEMS:

MEMS design typically requires PhD-level experts in areas such as mechanical, optical, fluidic, and package design.
MEMS historically requires specialized process development for each design, and is mostly confined to IDMs who have their own fabs.
Even though most MEMS devices reside within electronic systems, the MEMS design flow has been totally separate from the EDA environment.

As a result, bringing a MEMS product to market today can cost $40 million, and take 4-10 years of development time. Multi-disciplinary teams of experts are required. The biggest growth area for MEMS is in high-volume consumer applications, and long, expensive development cycles won't cut it there.

What's needed is a way to bring MEMS out of the realm of experts working for IDMs, and into the IC design mainstream. Mike Jamiolkowski, CEO of MEMS tool provider Coventor, calls this process the "democratization of MEMS." This will result in a shift from traditional MEMS companies to semiconductor foundries and fabless design houses, and will make MEMS ubiquitous in everyday life, he says.

The democratization of MEMS calls for a more standardized design flow. What's needed is a "Mead Conway equivalent" for MEMS, as Randy Fish, product marketing director at Cadence, puts it. An important part of that flow is the ability to simulate a MEMS device along with the electronic circuitry in the overall system. "MEMS typically don't stand alone," Mike said. "MEMS and electronics interact strongly, and the designs need to be simulated together."

Also important is an ability to import a MEMS device into a schematic, and ultimately into a physical layout, of the entire system. Unfortunately, MEMS designers use 3D CAD/CAE tools while electronics designers work with EDA tools such as the Cadence Virtuoso platform. The handoff from MEMS designers to IC or package designers is mostly manual, requiring the expert handcrafting of MEMS models for the EDA environment.

Coventor's recently-released MEMS+ product takes a different approach. After assembling a 3D design, users can generate a schematic symbol for the Cadence Virtuoso environment, a netlist for the Cadence Spectre or Ultrasim simulators, and a PCell for Cadence Virtuoso layout. The MEMS device can be inserted into the schematic and simulated along with the electronic circuitry. The MEMS designer can view the simulation results in the Coventor 3D environment.

As a result, Mike said, "the handoff to the IC engineer is very simple, very clean." He said Coventor is selling MEMS+ to IC design teams as well as MEMS designers, opening up a new marketplace for MEMS design. Some expertise is still required to build the 3D MEMS device, but the barrier to entry is a lot lower than with traditional MEMS CAD systems, Mike said. An article on the Design Automation Conference (DAC) web site, co-authored by Coventor and Cadence, provides further perspectives about the connection of MEMS development to the IC design environment.

The next challenge is developing standard foundry processes for MEMS. There is some progress. According to Mike, many IDMs have figured out how to develop MEMS processes that can handle derivative designs, as opposed to the traditional "one design, one process" approach. There are also a number of specialized MEMS foundries.

Pure-play foundries are beginning to show interest. In 2008 TSMC announced it would upgrade a portion of its 0.35 micron logic process capacity to MEMS. In October 2009, Cypress spinoff SVTC and TSMC announced a joint development effort aimed at MEMS commercialization. What is ultimately needed is a foundry infrastructure including process development kits (PDKs), IP, and reference flows.

With the right tooling and with foundry support, we may be standing at the threshold of a tiny revolution.

Richard Goering

Challenging Misconceptions About Verification Languages

2010-03-10T14:00:00Z

One thing I learned from the recent DVCon conference is that there are a number of common misconceptions about hardware verification languages (HVLs). I had a few of these myself. Two provocative and well-attended presentations provided a different way of looking at HVLs:

"Apples Versus Apples HVL Comparison Finally Arrives." Presented by Brett Lammers of Cadence Feb. 24.
"Where OOP Falls Short of Verification Needs." Presented by Matan Vax of Cadence Feb. 25.

Some of the misconceptions identified in these talks are as follows.

Misconception #1: The design language defines the HVL choice

At the beginning of his talk, Brett noted that verification is fundamentally different from design. With design, one is implementing a spec; with verification, one is checking the implementation. Instead of what the device should do, verification engineers are concerned about what the device should never do. Instead of area, timing and power, verification engineers prioritize test generation, coverage, and corner cases.

It thus makes sense that the unique characteristics of verification make HVLs "special," as Brett put it.

An attentive DVCon audience listened to Brett Lammers' HVL presentation.

Misconception #2: Object-oriented programming is the best way to get verification reuse

While OOP facilitates reuse in many software applications, it's not a complete solution for HVLs, Matan argued. His paper explained that verification does not lend itself naturally to classic object-oriented design, and that attempts to insert OOP techniques place an additional burden on programmers. In a video interview in a recent blog by Joe Hupcey III, Matan stated that "what you're doing with the object-oriented mechanism is emulating a different paradigm, and it would be much easier if the language could use that paradigm directly."

As Brett noted in his presentation, OOP allows a modular approach by encapsulating behavior within objects, but verification presents many "aspects" (like checking, coverage, and error injection) that cut across many objects. An aspect-oriented programming (AOP) language like the e language makes it possible to represent aspects as modules of their own. "Verification represents a lot of aspects, and AOP allows you to capture them in a more manageable way," Brett said.

Misconception #3: Verification productivity = simulation runtime

Verification engineers tend to focus on how fast simulators run. But overall project productivity involves more than just simulation speed, Brett noted. If you can shrink the time required to create the verification environment and write the tests, and spend more time, rather than less time, in regression testing, this will provide more time to find and fix bugs.

Brett noted that simulator performance depends on simulation tools and has no inherent connection to the language that's chosen.

Misconception #4: Compiling languages are best and fastest

Compiled languages such as e and SystemVerilog do provide the highest simulation performance, Brett acknowledged. But a language that can be either compiled or interpreted, such as e, provides more flexibility. A mix of interpreted and compiled code may be better for development, and using all interpreted code helps with debugging.

Misconception #5: Legacy VIP means you're stuck with an HVL forever

Not so, Brett said. Cadence has extended the Open Verification Methodology (OVM) to support e and SystemC testbenches and verification IP (VIP) along with SystemVerilog. VIP in these languages can be mixed in a common environment. The Cadence Incisive Enterprise Simulator supports e, SystemVerilog, and SystemC, making it possible to migrate from one language to another.

Misconception #6: One HVL is best for all

Not even the e language, with all its capabilities, is the best choice for everyone. Brett's last slide looked at "which language fits best where." As you can see, there's a place for both SystemVerilog and e.

Cadence's approach is to support both SystemVerilog and e, along with SystemC. Why pick just one HVL when you can offer a choice?

Richard Goering

Photo by Joe Hupcey III

Cadence Community blogs about DVCon 2010

Steve Svoboda: Quiet Before The Storm? And What To Expect at DVCon 2010

Adam Sherer: DVCon: Showcasing The Cadence Passion For Verification Excellence

Joe Hupcey III: DVCon "Day 0" - Quick Report From SystemC Day

Richard Goering: DVCon SystemC Day - Forging A TLM Design/Verification Flow

Joe Hupcey III: DVCon 2010 - Day 1

Richard Goering: DVCon SystemC Day Quandry: Need For Third Party TLM IP

Richard Goering: Lip-Bu Tan Keynote: Rethinking EDA For 2010 And Beyond

Joe Hupcey III: DVCon 2010 - Day 2

Tom Anderson: DVCon 2010 Rocked!

Richard Goering: DVCon Panel: Why Verification Engineers Are "Sleepless"

Joe Hupcey III: DVCon 2010 - Day 3

Richard Goering: DVCon Panel: Three Ways To Minimize Verification Effort

Joe Hupcey III: Why OOP Falls Short For Verification

Richard Goering: DVCon OVM Panelists: Easing The Debug Challenge

Q&A: New Challenges, New Solutions In IC Implementation

2010-03-08T14:00:00Z

Advanced nodes are raising tough new challenges for analog/mixed-signal and digital IC implementation, according to David Desharnais, group director and product manager for implementation at Cadence. In this interview, he notes where IC designers are struggling and succeeding, and describes Cadence's 2010 strategy to help make customers more productive and profitable.

Q: David, what does your job at Cadence involve?

A: Every day I get to work side-by-side with the sharpest minds in the world of electronic design - people who are working on designs and design solutions for the biggest, most complex chips on the planet, which ultimately find their way into the coolest products and gadgets that change the world in which we live. I get to be in the center of all the action, with customers, R&D, field operations, and partners - right where I want to be.

Officially, I lead product management and marketing for our digital, full custom, and analog design, implementation, and signoff verification offerings.

Q: What are the biggest customer challenges in IC implementation?

A: When you clear away all the fancy jargon and speak in everyday language, there are really two main things designers and their companies are concerned about today - how to be more efficient and effective in the design of their chips, and how to make the most money from the chips they choose to make. Simply put, it all boils down to productivity and profitability in the end.

Companies are making fewer but significantly bigger bets on the designs they target. It used to be that companies would do 10-12 SoCs, hedging with the expectation that only a handful would have reasonable-or-better market success. Today these same companies are only targeting 2-3 SoCs, and it has become a very expensive proposition. The success or failure of these SoCs can mean the success or failure of the enterprise itself.

As a consequence, these 2-3 designs are insanely large and complex - from the loads of functionality that has to be shoehorned onto them, to the advanced process nodes used to hit aggressive area or performance targets. Getting to the point where you have the most competitive and differentiated die-size, performance, power, and yield for an SoC is a Gordian Knot that somehow engineers need to find a way to cut through.

For the implementation engineers, it's a really crazy time. The shrinking of process nodes and the sheer number of gates they have to deal with on a single SoC can really throw a wrench in the works if they aren't prepared for it. New and more severe factors come into play that design engineers traditionally didn't have to worry about, like how to architect the clocks when the size of the chip requires 2-3 clock cycles to traverse it, or how to optimize interactions of multi-mode, multi-corner timing, power, signal integrity, and DFM [design for manufacturability] in parallel. Optimizing these things sequentially becomes a whack-a-mole situation.

Then there are things like how to deal with parasitics from the board and/or package and how they impact the silicon and vice-versa...and who's going to make sure that all the team members are compliant and aligned. The list goes on, but it comes down to about a 10X increase in complexity for each major node transition.

Q: Does this complexity call for a higher level of collaboration?

A: I would say there is a bit of a paradox happening right now. To improve productivity, collaboration is vitally important. However, the harder the problem or challenge, the worse the quality of communication seems to be. You would want the opposite to be true to solve problems in a more cohesive way. But, when you have a team in Texas and a team in India and a team in Europe all working on various blocks of an SoC, it is non-trivial.

Things have to be done differently than in the past. Flows have to be very coordinated, unified standards must be applied, and full transparency is needed across all the pieces. Otherwise what you have is inefficiency and waste. Complexity has compounded in a very systematic way.

Q: What is Cadence's strategy for helping customers with productivity and profitability?

A: To reign in the productivity crisis, we need to help engineers harness complexity. One approach we've taken is through recommended design flows and methodologies we call Foundation Flows. Our approach is to bring downsteam intelligence up front in the design process and to provide tight linkages, out-of-the-box scripts, and visibility from the system level all the way down to final silicon. Besides integration, we are also focused on establishing better handoff points across the flow, data abstraction, and overall simplification - like reducing the number of keystrokes or decisions that designers have to make in the course of a design. All this is done so designers can move their low-power or mixed-signal SoC to the next process node with as few barriers as possible.

When it comes to profitability, our focus is to help customers create the most differentiated silicon possible, getting them to market in a predictable manner, and achieving the highest-yielding parts. For example, when we help a customer gain an extra 3-4 points in yield on a high volume part, by showing them how to optimize for DFM and yield right there in the design cockpit well before silicon, this can make multiple millions of dollars in difference to their top-line revenue, and it carries straight through to their bottom line profitability.

Design cycles that used to be 18 months or 2 years are 6 or 9 months now. And the silicon has to work and work well. If you miss the window, you miss it completely.

Q: What are you seeing in terms of adoption of advanced nodes? Are customers moving on or staying put?

A: We see a cautious approach by the industry. The bulk of the market is still at 130 nm or 90 nm, but definitely people are starting to move. Every conversation I have with customers today includes advanced nodes and DFM - 40 nm or 32/28 nm, and more recently even 20 nm. These kinds of designs can run into the $60-$100 million range, so there is a definite gut check that happens before taking the plunge.

Customers want to know what to expect in terms of additional overhead they have to take on, compared to the benefit they hope to get. On top of this, they have to find enough of a market to give them upwards of 80 million units to support that kind of investment. This kind of volume typically means consumer, which also means advanced node, mixed-signal and low power. Companies serving the consumer market are the trailblazers as you might expect.

Q: There's been much talk about 3D ICs with TSVs [through silicon vias]. Are you seeing customer interest, and if so, for what types of applications?

A: Yes, definitely. It's a very exciting area. Customers are producing test chips and production designs with TSVs already, and we have had longstanding partnerships with foundries and heavyweight customers in this area going on for 3 years now.

3D itself is not new. It's been done for years. However, 3D with TSV is new and the projections for growth in this area are high. A key driver is that a 3D IC gets you a better form factor than a traditional side-by-side SiP, and brings significant advantages in performance, low power, and time-to market. A 3D IC approach also lends itself very well to design reuse and derivative designs.

Consumer electronics, wireless communications are by far the heavy users for 3D ICs, but we also see customers in other applications, such as bio-medical devices and automotive, moving to this technology now.

Q: What's been successful with low power design, and what remains to be done?

A: We have made great strides in low power, and we very much pioneered low power automation for the EDA industry. Every piece of our flow entirely supports and comprehends Si2's CPF [Common Power Format] today, and over the past two years we've seen literally had several hundred designs tape out using the Cadence Low Power Solution. Along the way, we established mature, high-quality support for the various low-power techniques in broad use in the industry, and we have automated advanced low-power techniques like multiple supply voltages, multiple power domains, power shutoff, dynamic voltage and frequency scaling, and disjoint power domains as some examples.

Going forward our objective is to extend our leadership in low power, and we'll provide even more aggressive innovations like mixed-signal, variation-aware low power support, and enhanced thermal analysis.

Q: How will Cadence move forward on mixed-signal SoC implementation?

A: This is a core strength for Cadence. We have the technology, flows, expertise, and a significant user base that has been taping out these kinds of designs for over 20 years, and we continue to set the pace for new developments. We handle all aspects - design, verification, and implementation of mixed-signal SoCs.

With our latest release of Virtuoso [IC6.1.4] alone, customers are seeing upwards of 30% improvements in productivity. But mixed-signal design is not just about analog or full-custom design -- it requires strong digital technology as well. And the convergence of our digital [Encounter] and analog [Virtuoso] platforms drives many new opportunities for efficiencies across a mixed-signal flow. Things like mixed-signal floorplanning, block and chip-level electrical analysis, substrate analysis, late-stage ECOs, unified constraints, and usability become very straightforward when you integrate the analog and digital design, implementation and verification worlds together. That is very important for our customers and the industry overall.

Q: There are some new competitors in the analog/custom space. How will Cadence maintain its lead?

A: We are experts when it comes to analog and full-custom design, and we got this way from working with leading edge companies around the world to achieve technology breakthrough after breakthrough for well over 20 years. Every significant design in the world today uses Virtuoso. We have taken this experience and have folded this knowledge into our tools. We never stop innovating here. It's in our DNA.

For example, we recently reinvented our entire analog/full-custom suite of tools from schematic capture, environment, layout, automatic routing, and chip-finishing with Virtuoso 6.1, and customers are experiencing a massive difference in productivity and capability right out of the box. There is a lot you can do when you know everything about the transistor -- how to build it, model it, simulate it, and connect it, particularly in the context of mixed signal SoCs. We also constantly track flows and metrics with our major customers and use the results to further enhance productivity and the user experience.

Competitors will have to walk before they run. If customers want a place to walk, okay - but we're light-years beyond that, and from what we see, designers cannot afford to erase a decade of advancement in analog/full-custom design automation, even if it is free.

Q: Cadence recently announced Encounter 9.1. What's special about that release?

A: Last year we introduced a completely re-architected digital implementation product line called Encounter Digital Implementation [EDI] System. This has really been a hit with customers. Our newest release of EDI System - 9.1 - builds on this very high-capacity, multicore, integrated infrastructure, and adds much more.

We consider EDI System 9.1 to be our "productivity" focused release, bringing higher capacity, performance, and usability, along with a full suite of integrated signoff capabilities for timing, signal integrity, power, extraction, and DFM. Heck, even the user-interface has been completely rebuilt from the ground-up and now adds many analog-style capabilities to address the requirements of very sensitive, high-speed clocks and signal nets that take on more and more analog characteristics as the process nodes shrink.

In EDI System 9.1 customers will find that we've built manufacturing and signoff intelligence into what a designer does by default, so the quality of results are significantly better. Also there is some very exciting technology around design exploration and automatic floorplan synthesis. Not only can a designer can give the tool some criteria, and it will automatically build a good floorplan that attempts to meet the criteria -- it will actually leverage our multicore backplane to automatically create multiple permutations of floorplans, and rank and rate them from best to worst based on the criteria set. Our customers tell us that this capability alone can take months off of the time it normally takes to arrive at an optimal floorplan. Now that's what productivity is about, right?

Q: What do you see as the most exciting trend in implementation right now?

A: I think the most interesting trends are in 3D-IC and in the bringing together of analog and digital design to make mixed-signal SoCs.

A good friend told me once that doing analog design is like doing surgery. The surgeon has to do it all very hands-on, methodically, and precise, and take the time to get it right. Improvements come in the form of new tools, and better methods to drive more efficiency and performance without sacrificing the quality. Conversely, doing digital design is like being a race-car driver - it's all about performance, timing, and breaking all the rules you have to, in order to get to the checkered flag. As process nodes shrink the racetrack turns from a nicely paved road to a bumpy dirt road. Improvements come in the form of absorbing the shocks and putting on meatier tires and heartier equipment, and tweaking the driving style to still win the race.

If you follow that analogy so far, then the punchline is that designing today's mixed-signal SoCs is like asking that surgeon to jump in the racecar and do surgery while going 200 mph down a bumpy dirt road. It's a problem the customers are trying to solve. Design, implementation and verification across analog and digital boundaries can be tripping points for customers. The most exciting thing for me is the opportunity to tie all these together.

Richard Goering

DVCon OVM Panelists: Easing The Debug Challenge

2010-03-04T14:00:00Z

The good news about the Open Verification Methodology (OVM) and the advanced verification techniques it supports is that verification engineers are now finding more bugs than ever. The bad news is that the bottleneck is shifting to debugging. What are we going to do with all those bugs? User and vendor representatives grappled with that question at a Cadence-sponsored lunch panel at DVCon Wednesday, Feb. 24.

Moderator Mike Stellfox, principal verification solutions architect at Cadence, noted that OVM and techniques such as constrained-random test generation have dramatically shortened the time it takes to build a testbench. "We're finding a lot more bugs than we could with traditional directed-test approaches, but now we're getting more bugs than we can debug in a timely manner," he said. In a recent Cadence survey, he noted, advanced verification users said that debug now takes about 50 percent of the overall verification effort.

Panelists (left to right in the photo below) included Steve Jorgenson, verification specialist at Hewlett-Packard; Jerel Canales, design verification manager at Zoran; Stellfox (at podium); Umer Yousafzai, solutions architect at Cadence; and Alicia Strang, principal verification engineer at Marvell. Yuchin Hsu, vice president of R&D for verification products at Springsoft, was also on the panel.

Panelists pondered debug challenges at an OVM lunch at DVCon.

With an emphasis on the user presenters, here are several perspectives that I thought were interesting.

How OVM helps with debug

"We find that OVM is very useful," said Strang. "If you just use that methodology, and use the naming conventions, everybody is on the same page." Canales noted that easier debugging is a key OVM benefit. He said that the "limited scope of issues" in testbenches that are all built to the same methodology makes it easier to find bugs.

In a conventional directed-test environment, Yousafzai said, users spend a lot of time debugging test stimulus. In OVM, which supports up-front planning, users spend less time tracking down problems in the testbench and more time finding bugs in the design. Jorgenson noted that OVM supports higher levels of abstraction, and said that "I really think abstraction is what will save us in the end from our debugging problems."

Testbenches need debugging, too

Jorgenson commented that verification teams can easily spend half their time just debugging problems in the testbench. One antidote is to move up in abstraction and reuse as much as possible from previous verification environments. Strang had another suggestion. "In a modern software environment like a testbench, you can do whatever you want. Keep it simple, and you can avoid a lot of bugs in the testbench."

Constrained-random stimulus may obscure bug causes

When a bug is found in a directed-test environment, Jorgenson said, a designer can very likely help identify the root cause. But with constrained-random techniques, "you don't always know what the test did. One thing we've had to do is go in there and get the test to tell us what it did."

Specman: Don't just load and compile

Canales observed that many new engineers load and compile an entire Specman run, not realizing that the e language makes incremental changes possible. There's no need to recompile everything when a change is made. "Hardware verification languages should allow you to very quickly make changes to the testbench, and get feedback, without having to recompile," he said.

Assertions are important

Zoran verifies video frames with a great deal of data, and achieves a "tremendous benefit" with assertion-based verification, Canales said. If written properly, he said, assertions will cause the simulation to stop right away. Strang noted that some kinds of bugs can be found only with assertions. These include bugs that do not affect data. "If it's data in, garbage out, I know it's wrong, but if it's data in, data out I don't see anything wrong," she said. Jorgenson said his group has been using assertions for 8 or 9 years, long before SystemVerilog assertions were standardized.

Yousafzai told of a customer who ran a single test 30,000 times on a block, and still had to do a respin because all these tests couldn't find a "trivial" bug - a signal that wasn't toggling correctly under some conditions. He noted that simple assertions that can be added easily are often the most effective ones.

How to find software bugs

Strang uses transaction monitors that generate waveforms that show what firmware is doing in parallel with hardware signals. From this, she said, "I can tell whether software issued a wrong command, or hardware is behaving incorrectly."

A conclusion

As I noted in a blog last year, based on part on an interview with Mike Stellfox, the bug diagnosis-and-repair cycle is becoming the biggest bottleneck in the verification flow. If debug really takes 50 percent of the verification effort - and verification takes 60 to 70 percent of the total design effort, as we've repeatedly heard - do the math and you can see this is an area that deserves far more attention. The OVM lunch panel was thus a very timely event.

Richard Goering

DVCon Panel: Three Ways To Minimize Verification Effort

2010-03-02T14:00:00Z

With verification taking up more and more of the design cycle, is there any hope that verification will keep up with escalating design complexity? Yes, according to panelists at the DVCon conference Thursday Feb. 25. From the discussion, I distilled three basic approaches to improving verification productivity:

Raise the level of abstraction for verification and design
Apply more intelligence throughout the flow, at every level of abstraction
Educate new engineers for real-world design and verification challenges

Verification consultant Brian Bailey, panel moderator, started the discussion on a hopeful note. "We've muddled through a 16X increase in design complexity since 2004, and we're not in verification hell," he said. "We're obviously doing an awful lot right." But how, he asked, will we survive another six years and another 16X increase in design complexity?

1. Raise the level of abstraction for verification and design

Perhaps the most obvious way to improve verification productivity is to move to a higher level of abstraction. This means less code, fewer bugs, easier reuse, and faster simulations. Indeed, as I reported in an earlier blog, Bailey spoke about the advantages of a SystemC transaction-level modeling (TLM) based flow earlier at DVCon.

Panelist Ran Avinun, marketing group director for system design and verification at Cadence, noted that the transition from gate level to RTL began 15 years ago. "We see the same thing happening right now with SystemC," he said. Moving up in abstraction, Avinun noted, makes it possible to separate functionality from constraints and leverage high-level synthesis.

DVCon panelists included (left to right) Brian Bailey, Ran Avinun, Janick Bergeron, Shawn McCloud, J.L. Gray, and Rajeev Ranjan.

"I'm calling for the death of state-based design," said Janick Bergeron, fellow at Synopsys. "That term includes RTL, and C level synthesis that's barely above RTL." Don't start with states, he said - start with the application, build a corresponding virtual platform, and then bring in synthesis and equivalence checking.

Shawn McCloud, director of high-level synthesis at Mentor Graphics, said that a customer survey showed that verification is the number one reason that people move to high-level synthesis. Moving to a high level not only speeds verification, he noted, but makes it easier to find tricky corner-case bugs.

2. Apply more intelligence throughout the flow, at every level of abstraction

This second point is perhaps more subtle, but is no less important. We can move to a TLM-based flow, but that doesn't mean that RTL and gate-level design will disappear. What's needed, Avinun said, is a "unified verification environment that we can use throughout the flow."

This flow, Avinun said, has three components. One is metric-driven verification guided by an executable verification plan and coverage metrics. Another is the use of verification IP, which he said is "as important, or in many cases more important, than [design] IP." A third is scalable performance throughout the verification process. This is where acceleration and emulation become important.

Rajeev Ranjan, CTO at Jasper Design Automation, noted that formal technology can offer improvements during all phases of the verification flow. In particular, he noted, formal tools can allow a "designer pre-verification" without having to generate a testbench.

3. Educate new engineers for real-world design and verification challenges

A point that was made in a Feb. 24 DVCon panel, and reported in my previous blog, is that universities are doing a poor job of training engineers for the real world of IC design and verification. University graduates need a lot of additional training before they're really useful on design and verification projects, and as a result, are often not hired in today's economy.

J.L. Gray, verification consultant at Verilab, moderated the Feb. 24 panel. As a panelist on the Feb. 25 panel, he noted that "the thing I've realized about the advanced verification techniques we need to move forward is that a very large majority of engineers don't have the skills to take full advantage of these techniques."

"The lack of educated people for design and verification is a big challenge," Ranjan concurred. He talked about graduating from U.C. Berkeley in 1997, and noticing that fewer students and professors were involved in IC design and verification.

"If training is one of the biggest issues, we've got to fix the educational system," Bailey said. That's a tall order. As I wrote last year, the Cadence Academic Network is one attempt to bring real-world relevance into university education. The time has come for an industry-wide discussion of this issue.

Richard Goering

Photo by Joe Hupcey III

DVCon Panel: Why Verification Engineers Are “Sleepless”

2010-03-01T14:00:00Z

I view a panel as successful when I leave the room knowing more than when I came in. Such was the case at the "What keeps you up at night" panel at DVCon Feb. 24, which offered some interesting, provocative, and in several cases surprising perspectives about challenges and solutions in IC design and verification.

Moderator J.L. Gray, verification consultant at Verilab and author of the Cool Verification blog, said the purpose of the panel was to "let people purge, get things off their chests, and have a good discussion to see what kinds of solutions we can come up with." While previous DVCon "Industry Leaders" panels included EDA CEOs or representatives, this year's panel was very different. Participants were:

Steven Gary, vice president of professional services at Numetrics Management Systems, a provider of enterprise software tools for IC companies.
John Goodenough, worldwide director of design technology at ARM Ltd.
Sheela Pillia, senior manager of process, circuit and technologies at AMD.
Jim Crocker, vice president of engineering at design services firm Paradigm Works.
Victor Melamed, director of engineering at digital media device provider Ambarella.

Following are some of the conclusions I found most interesting.

The "What keeps you up at night" panel included John Goodenough, Victor Melamed, Sheela Pillia,
Steven Gary, and Jim Crocker (left to right).

Analog models come too late, or are just plain wrong

Pillia noted that her group works with mixed-signal blocks with small amounts of digital content. Verification starts with the digital part, but the analog model comes too late. "We are trying to come up with a solution to get an architectural model up front," she said. She also noted that Verilog-AMS is too slow, and that AMD uses a "homegrown" simulation tool that requires a lot of hand-holding.

"When I ask an analog designer to give me a model so I can start verifying, they give me something that is similar but not exactly the same as what they're designing," said Melamed. "My struggle is to convince them that what they give me has to reflect what they're doing."

Flows are more important than methodologies or standards

"Asking about methodology is the wrong question," Goodenough said. "Asking about workflow is the right question, because that's what impacts cost and schedule. There is no end to clever languages. It's more about how you use them in the workflow." He noted, however, that "some languages allow us to be more productive, and some allow easier SoC integration."

People are more important than anything...but training is lacking

Tommy Kelly, CEO of Verilab, spoke from the audience to say that a quality verification team is the key to reaching time-to-market. "I would much rather have a mediocre tool flow and great engineers than a great tool flow and mediocre engineers," he said.

This comment touched off a discussion about the lack of training for new verification engineers, and the failure of universities to prepare new engineers for the real world. "I see a lot of resumes from young engineers coming from school," said Crocker. "There is no adequate software training for people going into this [verification] business."

"Verification is a mix of hardware and software," Melamed said. "New college grads who know a lot about software and a little about hardware do okay. Those who know a lot about hardware and have only rudimentary ideas about software don't do very well."

(Note: Last year I blogged about the Cadence Academic Network, which was set up to help universities train new engineers for real-world occupations).

There can be a "negative benefit" from IP reuse

If silicon IP is not easy to integrate and reuse, it can actually hurt more than it helps, according to Gary. "When the reusable design data falls below 50 percent, the benefit in terms of effort savings is almost zero," he said. "At lower levels, it costs more to try and reuse IP than to build from scratch."

Open source IP is not the answer

An audience member asked if open-source IP will help engineers sleep a little better. Apparently not. "There is no free lunch," Goodenough said. He noted that the software community is large enough to support and maintain open source, but the IC design community is much, much smaller.

"Okay, so you get some open-source VIP and run it in simulation," Melamed said. "When it core dumps, who do you call?"

85 percent of projects are missing schedules

Numetrics helps IC design companies optimize staffing and productivity, and it's a challenge. "We try to keep design cycles short," Gary said. "The reality is that 85 percent of the projects out there are missing their schedules, and unfortunately they're off by 10 to 150 percent. Quantifying tasks is a critical issue."

The $50 question: one vendor or two?

Before the panel, moderator J.L. Gray put out a request for questions and offered a $50 prize for the best question. It was: "Is what keeps you up at night the fact that you went to bed with only one vendor, or more than one vendor?"

If you stick with one vendor, Melamed said, you miss the "flexibility and opportunity" of having two. But having to deal with two or more vendors causes a lot of pain. He then expressed the hope that OVM and VMM will combine into one methodology. As I noted in a recent blog, that is one goal that's now within reach.

Richard Goering

Photo by Joe Hupcey III

...

Lip-Bu Tan Keynote: Rethinking EDA For 2010 And Beyond

2010-02-25T14:30:00Z

Business conditions are looking up for the EDA and semiconductor industries, but customer concerns have shifted, according to Lip-Bu Tan, president and CEO of Cadence. At a DVCon keynote speech Feb. 24, Lip-Bu described a new landscape in which EDA providers must help customers be both productive and profitable in the face of escalating complexity and soaring design costs. This calls for a different approach to end user product development, and new role for the EDA industry.

The speech was entitled "Breaking through the efficiency barrier." What follows is my list of takeaways from the broad-ranging, 40 minute speech.

Conditions are improving for the semiconductor industry

"The industry is improving. In the last six months there's been a sea change," Lip-Bu said. After visiting 300+ customers, Lip-Bu said he's seeing more new project developments. He noted that at least 10 semiconductor companies are planning to go for IPOs this year, possibly creating some momentum in which VCs will start investing in semiconductor startups again. "I'm very excited about this industry and I think we have a great opportunity going forward," he said.

Some new growth drivers for end market customers

When he visits customers, Lip-Bu noted, he spends a lot of time trying to understand their products and end markets. He believes there are some exciting growth drivers that will create opportunities for EDA providers. Specifically, he called out 4G communications, cloud computing, and mobile video. Such applications will demand low-power and mixed-signal design expertise.

Semiconductor vendors now responsible for software stack

Semiconductor companies are becoming software companies. Lip-Bu talked about a fabless semiconductor provider in the wireless market that has hired over 1,000 software developers and is developing the entire software stack for its products. As a result of such efforts, he said, concurrent hardware/software development is becoming very important.

Design costs are threatening profitability

A new SoC development project may cost $100 million at an advanced process node, Lip-Bu said, meaning that 80 million units may need to be shipped for a company to attain profitability. This is a tremendous risk. "It's not just about productivity," Lip-Bu said. "It's about design costs, profitability, and time to market. Our job is to ensure that the customer becomes profitable in their project."

Closing the productivity gap

There is still a gap between silicon capacity and engineer output. How can we close it? On the design side, Lip-Bu said, it's time move to the transaction-level modeling (TLM) level of abstraction. On the verification side, hardware/software integration and IP reuse are critical. On the implementation side, new technology must embrace challenges such as giga-gate complexity, design for manufacturability, and mixed-signal design.

Closing the profitability gap

Profitability can be achieved if customers efficiently "Create, Integrate, Optimize." The Create stage should produce "integration ready," silicon-proven IP designed at a high level of abstraction. The Integrate stage depends on "open IP access" and rapid SoC integration. Hardware/software convergence is very critical in this phase, along with cost-effective verification. The Optimize stage brings in die, package, and test automation. This phase will rely on expertise in mixed-signal design and package design, both areas of strength for Cadence.

Criteria for successful acquisitions

Lip-Bu commented that any prospective acquisition should involve three things. These include a team that brings value to Cadence, a product that strategically "makes sense," and customer traction that can be built upon and expanded. "If all three are right and the pricing is right, we'd love to do it," he said.

My observation

Listening to the customer is the best way to find out where any industry is going. With 300-plus visits in a little over one year - no, more than that, because some companies were visited multiple times - Lip-Bu has gained a unique perspective on where the electronics industry is headed, and what the EDA industry must do to support it. I hope EDA providers and customers alike will shake off the doldrums of 2008-2009, and share some of the excitement Lip-Bu feels about the coming decade.

Richard Goering

Note: Photo taken by Joseph Hupcey III

DVCon SystemC Day Quandry: Need for Third Party TLM IP

2010-02-24T18:00:00Z

Sometimes in the most optimistic of discussions, there is an "elephant in the room" that people don't say much about. Such was the case at the DVCon SystemC Day Feb. 22, where despite strong attendance and upbeat presentations, there was only a small amount of discussion about the need for third-party transaction level modeling (TLM) IP.

The portion of SystemC Day I attended was a North American SystemC Users Group (NASCUG) meeting. It started out with an Open SystemC Initiative (OSCI) update by OSCI chair Eric Lish and a keynote by industry analyst Gary Smith. In addition to several technical presentations about SystemC modeling, it included a talk by Brian Bailey on TLM design and verification, which I blogged about separately.

About the only discussion of commercial TLM IP came in question-and-answer sessions. Gary Smith noted that an International Technology Roadmap for Semiconductors (ITRS) working group found that IP blocks with over a million gates are unusable by most customers. Integrators need "modifiable" blocks they can assemble and integrate quickly, without losing too much of the original verification environment. "You can't develop that kind of block at the RT [register transfer] level," Gary said.

Good turnout, strong technical sessions at SystemC Day NASCUG meeting - but what about IP models?
Above, Jack Donovan speaks.

"The difference between RTL modeling and transaction level modeling is that you can make money at the transaction level," Gary said. "We have to get IP providers to move up to the transaction level." He noted that large customers pulled their IP development in house when large blocks came out, and suggested that it may be because they can't get modifiable IP at the RT level.

I was immediately reminded of a recent blog by Dan Nenni that stated that only about 30 percent of the IP that can be outsourced is outsourced. Could the lack of commercially available TLM IP be a factor?

HighIP Design is a new company launched by Jack Donovan, former president of XtremeEDA, to provide hardware and software IP for use with high-level synthesis. "What's the business model for selling IP at a high level? I'm not sure what it is yet," he said in a response to a question after his NASCUG presentation on managing code complexity. He noted that there will have to be a "high degree of assurance" that TLM models and RTL models operate in the same way.

Another presentation showed that some TLM modeling is occuring. Herve Alexanian of Sonics described an Open Core Protocol (OCP) modeling kit from the OCP-IP organization that supports various levels of TLM abstraction, ranging from TL0 (RTL) to TL4 (loosely timed transaction level), based on the OSCI SystemC TLM-2.0 specification. In another presentation, David Black of XtremeEDA offered some practical suggestions for developing TLM models without clocks.

As the Brian Bailey presentation showed, good progress is being made towards a TLM-driven design and verification flow that can greatly boost productivity and time-to-market. Tools such as the Cadence C-to-Silicon Compiler are enabling that flow. And as noted in a SystemC Day tutorial, work is ongoing on a standard SystemC synthesizable subset.

Now we need commercial IP providers to come on board with SystemC TLM models. Will they hear the call?

Richard Goering

DVCon SystemC Day – Forging A TLM Design/Verification Flow

2010-02-23T14:00:00Z

Advanced design technologies are of no value unless there's a coherent, workable methodology that supports them. SystemC transaction-level modeling (TLM) has lacked a methodology that goes all the way to silicon without major gaps. Independent verification consultant Brian Bailey filled in some of those gaps at SystemC Day at the DVCon conference Feb. 22.

Brian spoke at the first half of SystemC Day, which was the North American SystemC User Group (NASCUG) 12^th meeting. Other morning talks included an overview by Open SystemC Initiative (OSCI) chair Eric Lish and a keynote by analyst Gary Smith. The second half of SystemC Day included a DVCon tutorial on the proposed OSCI SystemC synthesis subset, taught by Michael McNamara of Cadence, Michael Meredith of Forte, and John Aynsley of Doulos.

As he began his talk, Brian noted that his presentation is based on consulting work he's recently done with Cadence. It's a "work in progress," he said, but he outlined some major characteristics of a TLM-driven design and verification methodology, including the points below.

Design and verification must work in tandem

Forget the traditional "V" shaped flow in which design and verification proceed separately, and come together only at the end. Verification needs to occur every time a transformation is made in a model. "We must verify as we make decisions rather than leaving them until some point much later in the flow," Brian said.

Separation of concerns simplifies modeling and verification

Communication and computation should be treated as independent concerns. This way, both communications and computation blocks can be reused without being dependent on one another. If you take computation blocks and connect them together without communications, you create a protocol-agnostic virtual platform. "You want a methodology that allows you to pick any two things and put them together in a way that doesn't require re-verification," Brian said.

Similarly, function and architecture should be treated separately as well. "We don't want to pollute our functional description with how we're going to implement it."

Working with multiple abstraction levels

TLM-driven design and verification will occur in a "multi-abstraction" environment. The best approach is to start from the top with algorithm design and verification, go through the loop to complete that process, and move down to architectural verification, while reusing as much from the algorithmic level as possible. The next step is to move from architectural to micro-architectural verification, again reusing as much as possible.

Adapters and interfaces

The design process will likely start with C/C++ algorithmic models. To move to architectural models that can be used in virtual platforms, it will be necessary to define hardware/software boundaries, registers, and concurrency. This is where SystemC comes in. As model transformations proceed, there will be a need for "adapters," which are simple routines that handle such concerns as rate matching and buffer sizing.

The flow that Brian outlined relies heavily on high-level synthesis. Since the OSCI TLM 1.0 and 2.0 standards are not synthesizable, the flow uses an interface based on OSCI TLM 1.0 that does not strictly adhere to the standard. For example, it leaves out simulation features that are not synthesizable, and adds missing features needed for synthesis such as reset. It also brings in "generic payload" capabilities from OSCI TLM 2.0. (A blog I wrote last year talks more about TLM 1.0 versus 2.0).

What about third-party TLM IP?

Actually, this wasn't part of Brian's presentation, although in response to a question he said that defining a synthesizable SystemC subset will help enable the IP industry. It seems to me that the availability of TLM IP is the next big question, but that's a topic for another blog.

Presentations from the NASCUG meeting will be available at the NASCUG web site. Meanwhile, for a Cadence perspective on SystemC, see the video interview with Steve Svoboda in the SystemC Day blog by Joe Hupcey III.

Richard Goering

EDAC CEO Forecast Panel: Takeaways For 2010 And Beyond

2010-02-19T22:30:00Z

After a hard year and a half for the EDA industry and the economy in general, what's on tap for 2010 and beyond? The EDA Consortium's annual "CEO Forecast and Industry Vision" panel Feb. 18 had what I would call a "cautiously upbeat" mood, with CEOs making some interesting comments about ongoing challenges, new opportunities, and major changes for the EDA industry and its customers.

Lip-Bu Tan, president and CEO of Cadence, joined the annual discussion for the first time. Other panelists included Aart de Geus, chairman and CEO of Synopsys; Wally Rhines, chairman and CEO of Mentor Graphics; and John Kibarian, president and CEO of PDF Solutions. Following are some takeaways from the discussion.

1. Bad news, better news - revenue estimates for 2009-2010

Overall, the panel was much more about "vision" than "forecast," with none of the panelists offering a revenue forecast for 2010. But moderator Jay Vleeschhouwer, senior software analyst at Ticonderoga Securities, started off with some hard data. By "hard" I do not just mean numerical - Jay said EDA industry revenues declined about 10 percent in 2009, to $4.15 billion. That marks two consecutive years of declines. Jay expects 2010 EDA revenues to be in the plus 3% to 4% range over 2009.

2. EDA technology must enable customer profitability

Lip-Bu Tan talked about visiting over 300 customers in the past year, and hearing that profitability is becoming their most critical concern. Customers are contemplating chip design projects that may cost $100 million, and looking at how many units they'd have to ship to be profitable. They need to reduce design costs and meet time-to-market windows. EDA vendors must become "business and collaboration partners" to help customers be productive and profitable, Lip-Bu said.

Later, Aart de Geus said there is a "massive push towards productivity and profitability" and noted that "the other side of this coin is innovation".

The EDAC CEO panel included Jay Vleeschhouwer (at podium), and Lip-Bu Tan, John Kibarian, Wally Rhines, and Aart de Geus (left to right).

3. Watch the semi industry closely, and you can predict EDA revenues

In past years Wally Rhines has come to EDAC forecast panels armed with charts and graphs linking semiconductor R&D spending to EDA revenues, and has offered forecasts for the following year. This year he couldn't talk about 2010 because Mentor hadn't reported earnings yet. But he did note that his 2009 forecast (minus 6%) was fairly close, and he repeated his argument that EDA revenues closely track semiconductor R&D spending. Unfortunately, that spending decreased in the recession.

4. "Excess" capacity is a hard call to make

As Wally noted, excess capacity is bad news for semiconductor companies and their suppliers. But John Kibarian argued that we are not, as some claim, going into an excess capacity situation with respect to logic. There's been a lack of investment for a long time, he said, and new products are driving user demand. "If we see capacity utilization come down, I'm wrong and we've overshot," he said. My take: we will only know "excess" capacity in hindsight.

5. Moving beyond Moore's Law into uncharted waters

The term "inflection point" may be overused, but Aart believes we're at one in the "shift from scaled complexity to systemic complexity." Scaled complexity is basically what we've heard about for years with Moore's Law. Systemic complexity involves "multi-layered," interacting challenges, such as hardware/software integration. He didn't elaborate further, but I would add "more than Moore" technologies like MEMS and 3D ICs to the list.

6. Don't expect a quick recovery

Jay asked panelists about their views of the second half of 2010 (I'm not sure why they weren't asked about the entire year). Second half visibility is "not clear," Lip-Bu responded. "R&D budgets are still very tight. We are cautiously optimistic." Earlier in the panel, Aart spoke of a "very gradual return" for the economy.

7. Is semiconductor industry consolidating or isn't it?

Jay asked how consolidation in the semiconductor industry is impacting EDA, and got a surprising response from Wally. The semiconductor industry is not only not consolidating, he said, but has been in a state of "monotonic de-consolidation almost from the beginning." The five largest semiconductor companies have less market share today than the five largest companies had 35 years ago, he said.

What we are really seeing, Aart said, is a "capex consolidation" around process development and new fab construction.

8. End markets are the number one driver

At last, something that the big three EDA vendors all agree on! Lip-Bu, Aart, and Wally all agreed that end markets are the biggest demand drivers for EDA. Lip-Bu said he is "very excited" about 4G, a "billion dollar opportunity that's very hard to do." He also said end markets and increasing complexity are driving demands for low power design, mixed-signal ICs, and functional verification.

Panel summary - my view

There was no time for audience Q&A, and there wasn't much in the way of revenue forecasts or controversial comments. But I think the panelists offered some balanced, hype-free insights into where the EDA industry and the designers it serves are headed. It was very good to have Lip-Bu join this annual event and hear his insights.

I understand that a video replay will be available on the EDA Consortium web site.

Richard Goering

Q&A: How System Design And Verification Can Go “Mainstream”

2010-02-18T14:00:00Z

System design and verification are part of the RTL flow today, but a higher level of abstraction is now poised to enter the IC design mainstream, according to Ran Avinun, marketing group director for system design and verification at Cadence. In this interview he discusses trends in hardware/software integration, prototyping, and transaction-level modeling (TLM), and offers a perspective on the recent merger activity in the virtual platform market. He also provides a preview of Cadence involvement in next week's DVCon 2010 conference.

Q: Ran, how do you define "system" design and verification?

A: There are two definitions for "system" in the electronic industry. One has to do with a higher level of abstraction beyond RTL. The second definition points to system-on-chip [SoC] and system-above-chip integration, including hardware and software.

Q: Why is it so important to bring software into the design and verification process?

A: Just recently there was a Toyota Prius problem where the antilock braking system [ABS] gives drivers an "inconsistent feel" when braking over rough or bumpy surfaces. The core problem is the electronic interface (hardware and software) between the ABS and the regenerative braking system, according to reports. This is just one example. In general our devices are getting more complex, and each one of them has at least one processor, or perhaps other programmable components. Each one of those processors comes with embedded software. If you ignore software, you basically just do half of the job.

In the past, many devices or boards were designed only by hardware engineers, and the software was not part of the hardware design. Integration was done after tapeout when the SoC or board was shipped to the system integrator. This worked well when you had 2-3 years in your design cycle and the design was relatively simple. But when designs became complex, and design cycles shortened to 6-9 months, it didn't work well.

One of the paradigm shifts we see is that more and more semiconductor and IP companies are delivering the hardware together with the software to the system integrator. An IP company needs to think about all the different configurations in which the software will interact with the hardware and create regression tests to test those scenarios. It creates a new set of challenges.

Q: In the hardware design world, we have a metric-driven verification methodology along with formal verification techniques. Can this type of formalized methodology be applied to software verification?

A: Most software verification techniques today are very primitive, and are based on pure code coverage or on methods used in hardware design 15 or 20 years ago. I think there is a place for advanced verification techniques, but they probably will not evolve directly in the pure software world. Instead, they will be created and executed by the hardware developer who is integrating the embedded software.

I think there is room for growth in tools that address the creation of scenarios or use cases to improve up-front verification for hardware and software. Our Incisive Software Extensions product lets users take advanced verification and power shut-off techniques that were applied to hardware only, and start to apply them to both hardware and software.

Q: What do you see as the respective roles for virtual platforms, FPGA-based prototypes, and emulation, and why is there a need for all three?

A: While different products have different software stacks, the lower levels of the stack normally have a higher hardware dependency. Acceleration and emulation do a good job of handling the lower layers of the stack where you have this dependency.

With FPGA prototyping, you start to address higher layers of the software stack. Virtual platforms enable you to run higher-level applications.

From the hardware side there are three tradeoffs customers need to make - speed, accuracy, and bring-up time. In many cases, bring-up time will be a function of turnaround time. Acceleration and emulation address accuracy and bring-up time very well, since they are based on existing RTL models and provide very good automation and compile time.

FPGA-based prototyping provides better performance, but still has issues with bring-up time, which is unpredictable. To some extent, FPGA prototyping is inaccurate - in many cases it requires you to make changes to your design as you map it to the hardware. Turnaround time and debug are also poor with FPGA-based prototyping systems.

Virtual prototyping provides high speed but not accuracy. Bring-up time is not good for new designs, but for derivative designs where you already have the models, it can be faster. The main issue with virtual prototyping is that you never know if what you build represents your real design and implementation. This is an issue that the industry and EDA vendors will need to address in the future. While today most customers are using one or two of these platforms, I expect all three will be used by customers in the future.

Q: There's been some recent merger activity in the virtual platform market. Synopsys bought Vast and CoWare, and Intel bought Virtutech. What's your perspective about this activity?

A: These acquisitions confirm that hardware/software integration is a significant issue facing our customers. These acquisitions, however, only focus on one small piece of the total solution. The hardware/software integration challenge will not be solved by amassing a segregated collection of point tools.

Our approach is to address the problem by connecting the hardware and software worlds to the design, verification and implementation methodologies and flows. We provide a comprehensive TLM [transaction level modeling] driven design and verification solution, including high-level synthesis and full system integration using acceleration and emulation. Our flows and methodologies are based on standards. As part of this flow, we provide customers with a single verification environment, verification IP and a metric-driven verification methodology for TLM, RTL simulation, acceleration, emulation, and hardware/software integration.

Q: Some people may be hesitant to invest in acceleration/emulation. Why is it so important for system design and verification?

A: Although many new IP blocks are created in TLM, when it comes to SoC integration, most designers are still relying on their RTL. If you want to bring up your system including hardware and software at RTL pre-silicon, there is only one way to do that - hardware-assisted verification. If you need accuracy for hardware, and you need to bring up new complex designs in a short time frame, emulation will definitely provide the fastest bring-up. If you don't have acceleration/emulation you may miss the target because it takes you 6 or 9 months to bring up the environment.

FPGA-based prototyping is a good hardware/software integration solution for a sub-system but is not scalable. Once you get into larger designs, the time spent mapping and bringing up the design is very long, and also the performance will degrade significantly, maybe even to the point where you're running slower than emulation. Also, debug visibility into the chip is very limited.

Many companies are using a combination of emulation and FPGA prototyping. We see this happening in two ways. "Dual mode" is where they use each platform at different phases of the design. "Hybrid mode" is where they're connecting FPGA prototyping to acceleration/emulation and running them together at the same time.

Q: Cadence is putting a lot of emphasis on a TLM-driven design and verification flow. TLM describes hardware. Does TLM modeling help with software verification?

A: Absolutely. You can use a TLM model as a single source, and apply it to both a virtual platform and to high-level synthesis in order to link to implementation. It might be that as you do this, you generate two models - one will be faster, another will have more details about implementation, but the point is that you start from a single model that you can continue to update as your golden source.

Q: How does transaction-level modeling help with the design and verification challenge?

A: TLM gives you a productivity improvement in both hardware design and verification.

Through the transition to TLM, our goal is to provide our customers with a 3-10X design productivity improvement, 2X shorter verification cycle, and 10X faster exploration and architectural trade-offs. As you write a smaller amount of code and keep a separation between your functionality and design constraints, your initial design and especially IP re-use becomes faster. When it comes to verification, you can simulate your design and debug your problems faster, because you're debugging at the protocol level and there are likely to be fewer bugs because you're writing less code.

Q: What's needed to bring TLM into the design and verification mainstream?

A: We're moving from the early adopter or missionary deployment into the mainstream, and I think right now we're at the inflection point. I think there were two issues that didn't allow this to happen in the past. One is that TLM models were not created to be synthesized and implemented -- they were created only for simulation and modeling and therefore resulted in a discontinuity between TLM and RTL.

In order to change this, TLM needs to have a link to mainstream logic design and implementation. We're doing that with C-to-Silicon Compiler by embedding RTL Compiler into it, and building a TLM to GDSII flow. Now we need IP providers to start delivering IP in TLM. We see that today, but only for modeling and simulation, not for implementation. I think that will start to happen as the methodology becomes part of the mainstream flow.

Another point is that verification engineers were not part of this [TLM] environment. They waited until the architecture was done and an RTL description was ready. We have recently started to see large companies preparing their infrastructure in order to extend their verification environment to TLM. This is a good sign, showing us that we are at the tipping point of the change.

Q: How will Cadence participate in DVCon 2010, Feb. 22-25?

A: First, there is a SystemC day Monday, February 22 and we will participate in multiple ways. Mike McNamara [Cadence] and Mike Meredith of Forte will give a tutorial on the SystemC synthesizable subset. On the same day, Brian Bailey will give a presentation on TLM-driven design and verification based on the Cadence methodology.

An OVM tutorial [Feb. 23] will show, for the first time, our OVM acceleration methodology applied to our Incisive Palladium products. I'm also going to participate in a panel [Feb. 25] that will discuss how to minimize verification time and effort. And Lip-Bu Tan [Cadence CEO] will be the keynote speaker [Feb. 24] for DVCon, and will talk about the new directions will Cadence bring to the industry.

[Note: For further information about Cadence participation in DVCon, click here.]

Richard Goering

Q&A: Why The e Verification Language Is Alive And Well

2010-02-16T14:00:00Z

In spite of rumors about the decline of the e verification language, it's not only still alive but is thriving and growing, according to Mitch Weaver, corporate vice president for front-end verification at Cadence. In this pre-DVCon interview, he answers questions about Cadence and industry support for the e language and the Specman/e verification environment, as provided by Incisive Specman Elite and Incisive Enterprise Simulator XL.

Q: Mitch, there have been some rumors that Cadence is not investing in Specman or the e language any more. What's the reality?

A: It always makes me upset to hear any absolutely false rumor or perception regarding the future of e! First, let me say that Specman/e is a great business for Cadence. Almost all of our top customers are using the technology because of its ongoing effectiveness to handle the giga-gate designs they are developing today. Even with all the SystemVerilog pressure over the past five years, they have chosen to stick with e. They've evaluated all the alternatives and found that Specman/e excels in speed, ease of use, coding efficiency, scalability, and verification throughput.

Specman/e license usage has more than tripled since the Cadence merger with Verisity. The IntelliGen constraint solver technology was developed after the Verisity acquisition. Specman continues to successfully provide e support for other simulators. Of course, we also provide full native e support in our own Incisive Enterprise Simulator XL. Cadence is thus continuing its investment in the development, integration, and methodology of e, both in terms of our own products and the vibrant e ecosystem.

If you monitor user groups such as Team Specman and Yahoo! Specman, you can see that many customers and partners are successfully using e and that it is widely acknowledged as the "best" testbench language available. So, I would like to emphasize that Cadence has not taken the focus off Specman or e at all. We continue to enhance this technology and we have a full commitment to our customers to support them going forward. Bottom line: cutting back on Specman/e would be like cutting our own throat.

Q: How has Cadence integrated Specman/e into its functional verification offerings?

A: Since the Verisity acquisition, we've been on a serious investment binge around the unification of Verisity technologies inside our product offerings, particularly the Incisive Enterprise Simulator. We just did a big release called Incisive 9.2, and its mission was to complete that unification. We had already integrated the Verisity engine, but this new release goes further by allowing multi-language verification capabilities.

What this means is that verification IP [VIP] from anywhere can mix in any fashion and form. You can have e on top of SystemVerilog and SystemVerilog on top of e, in any kind of mix and any level of hierarchy you want. We now have a single verification platform with a single debugger, a single trace generation capability, and a common assertion capability across all design and verification languages. INCISIV 9.2 is the complete unification of all verification technologies around multiple languages.

Q. How is Cadence working to move the e language forward?

A: Cadence is aggressively increasing its investments in e language related products, research, education, technical donations to IEEE 1647, and developers programs. Specman/e technology is one of the pillars of our advanced innovation program. Our focus areas include increasing verification throughput, extending metric driven verification to all non-RTL domains, and increasing automation.

Q. Verisity used to have a very good partnership program. However, we don't hear much talk these days from other vendors about supporting e. Is the ecosystem still intact?

A: The ecosystem is still very healthy. Many of our partners have strong verification IP, services, and training businesses around e. For example, over 43 service providers worldwide and over 250 experts support e. VIP providers include Cold Spring Engineering, eInfochips, Globetech, and Paradigm Works. AMIQ offers the DVT development environment. Doulos is among several companies offering e language education.

One of the key partners that Verisity had was Novas for debugging. Novas used to strongly promote the nBench solution for e. As you may know, the partnership with Novas made sense for Verisity but after the Cadence merger, we integrated the Specman/e technology into our SimVision product. We believe our integration of Specman/e is much tighter and more seamless today than it was in the past with Novas

Q. Isn't e support expensive and costly to maintain?

A: The elegance of the Cadence multi-language approach is that we can support the breadth of the IEEE design and verification languages by finding novel ways to share resources inside our R&D organization. Specman/e technology is very strategic to the overall Cadence verification business.

Some of the key reasons for our ongoing support are that e is widely acknowledged as the "best" testbench technology available, it is a mature and proven language for verification of the world's largest chips, and Specman has a 96 percent track record of first-time silicon success. Many large, important customers are starting new projects with e. Our own verification IP depends on e to implement its core functionality.

Q. In that case, can you help us understand how e fits into the overall multi-language OVM/UVM campaign?

A: We view OVM [Open Verification Methodology] as an over-arching technology that is not language specific. We believe that the key to future SoC design productivity is the ability to maintain a team's expertise in one language, while being able to integrate IP that may be implemented in different languages.

OVM e is the next generation of the Verisity eRM [e Reuse Methodology], which was the first methodology that provided a framework for verification IP reuse. OVM is fully backward compatible with eRM, but it also provides some new capabilities that are especially suited to address the verification challenges of SoC verification. e users have created the largest base of methodology-compliant verification IP, and SystemVerilog and SystemC users can access it via the OVM multi-language capability. This represents a huge productivity gain because the e VIP is well proven, and integrating it reduces verification costs regardless of your primary verification language choice. Of course, if your choice is e, this integration is even easier.

Q. What is the relationship between Metric Driven Verification (MDV) and the e language?

A: Customers that have the most difficult verification challenges tend to be using e, and most of them utilize our metric driven verification solution. Just like the progression from eRM to OVM and now UVM, the MDV methodology originated and was prototyped with e. It continues today to be the most complete, stable, and effective solution for implementing highly automated verification environments. We like the fact that e is mature, which gives us the ability to implement a full featured MDV solution for our customers, and have that be risk free from a technology perspective.

Q. I understand that e is IEEE Standard 1647-2008. Is there any current activity in the IEEE 1647 group?

A: Yes. e was accepted as IEEE standard 1647 in March 2006, and then the spec was revised in May 2008. The IEEE standards committee is working on a new release of the standard this year: IEEE 1647-2010. The working group is on track for an update in the third quarter.

Q. Since e is an IEEE standard, will Synopsys and Mentor support it?

A: Well, they certainly should, since no one can claim to support all IEEE-standard design and verification languages without supporting 1647! Customers should not hesitate to ask vendors about their plans to support IEEE 1647.

Q. How do customers considering a move to more advanced verification view e versus SystemVerilog?

A: Many of the largest Cadence customers are using Specman/e today for SoC verification. They have been very successful using the e-based solutions and plan to continue using it. This year at DVCon, multiple papers are being presented that highlight Specman performance as well as how Specman/e technology can be used for mixed-signal verification.

Users moving from Verilog or VHDL testbenches to more modern verification environments face a choice between e and SystemVerilog. Of course we support both languages equally well and are happy with whatever they choose, but we do make an effort to educate them on the unique advantages that only e offers.

Q. Speaking of those unique advantages, Specman uses aspect oriented programming (AOP) while SystemVerilog and SystemC use object oriented programming (OOP). What's the advantage of AOP?

A: Both AOP and OOP share the concepts of objects, and enable the users to organize their code around those objects. AOP can be thought of as a superset of OOP, in the sense that users generally have to apply OOP concepts first to successfully apply AOP. But an AOP language such as e allows the user to extend objects in the environment from within different modules without creating new types. AOP is a "building-block" superset of OOP for rapid environment construction, easy reuse, and unlimited scalability. The important point is that AOP makes it possible to extend an existing program, such as a verification environment, without modifying the core environment itself.

For verification engineers, AOP makes it easy to write and run efficient tests, and to reuse verification environments from block to system and from one project to another. AOP thus makes e a much more productive verification language.

Q: What can you say about the performance of the e language?

A: e is a high-performance language, on par with C for common procedural code. e also has a built-in interpreter that makes it possible to load incremental code on top of a compiled environment, or to debug code without recompiling. Many past rumors about slow e performance were due to the fact that people compared e interpreted code to a compiled version of other solutions. In all the cases we looked at, e proved to be the fastest language with a real apples-to-apples comparison.

Q. What are the plans for the Specman/e technology in 2010 and beyond?

A: We have very detailed roadmaps for Specman and e for 2010 and beyond. At a high level, we are investing in Specman simulation performance, debug performance, multi-language integration enhancements, VIP enhancements, coverage and generation with IntelliGen, and other areas as well.

Q. Is Cadence planning on hosting more public Specman/e oriented events in 2010?

A: Yes, we are planning on continuing hosting worldwide "ClubT" events this year. We are planning the dates now and will roll out the schedule soon. Please join the Team Specman user group to get the latest details on the ClubT events, and read Team Specman Cadence community blogs.

Richard Goering

Toyota Prius 2005: An Early Warning About Verification

2010-02-12T14:00:00Z

The news headlines have been full of reports about the 2010 Toyota Prius, which apparently has a software bug that causes braking problems on bumpy roads. What most reports don’t say is that some 2004 and 2005 Toyota Prius cars also had a software bug, and that Toyota engineers did an analysis of the problem that called for a new verification methodology.

The 2004/2005 problem was a bug that caused some Toyota Prius hybrid cars to stall or shut down while driving at highway speeds. Toyota identified a “programming error” in the computer systems of 23,900 Prius cars, and advised the owners to bring the cars into dealers for a software update. I found a very interesting presentation on line, apparently written by three Toyota authors, that talks about this powertrain control bug and the verification problems behind it. The presentation was given at a 2006 SCADA (Supervisory Control and Data Acquisition) conference.

The presentation notes that automotive control systems have become large-scale control systems. They’re comprised of modules that were designed and tuned by individual engineers over the years, and then integrated into an “incrementally developed legacy structure.” The presentation cites a lack of understanding of the whole structure. As complexity grew, hundreds of modules were interacting with each other. The number of tests grew exponentially as new functionality was added.

Citing the need for model-based development, the presentation calls for:

Formal definition of multiple layers of abstraction for control system software that captures component interactions, data-access rules, and explicit/implicit dependency structures
Formal specification of control system properties to assist validation and verification
Hierarchical verification at the module, feature, and system levels
Test generation for closed-loop feedback control system
Assertion-based verification

So now it is five years later and we have another Toyota Prius software bug, along with several other highly publicized problems. I have no insight into Toyota’s verification methodology today, but I have to wonder what was learned from the 2004/2005 experience.

The central problem is that software verification has no formalized methodology. Engineers basically run ad-hoc, directed tests until the clock runs out. On the hardware side we have metric-driven verification, executable verification plans, and coverage. Cadence Incisive Software Extensions, along with the IBM Enterprise Verification Management System (EVMS) I wrote about earlier this week, are aimed at bringing some of these hardware verification capabilities into the software world.

I think the Toyota 2004/2005 experience, and the analysis that followed, provides a lesson for system-on-chip (SoC) designers. Like Toyota, SoC designers are integrating many modules built by different people, and are often trying to upgrade and test an “incrementally developed legacy structure.” As complexity grows and modifications occur, understanding and verifying the whole structure becomes exponentially more difficult. A formalized, hierarchical approach to hardware and software verification is needed.

Meanwhile, as a 2006 Toyota Prius owner who’s been very happy with the product, I hope I’m not writing a blog five years hence about a 2015 Toyota Prius bug!

Richard Goering