The Pace Quickens as we Approach the Opening of the 45th DAC

by Gabe Moretti, Editor

Companies continue to try to catch problems as early as possible in the design cycle.  DACeZine organized a roundtable discussion about system-level verification to explore the topic.  The article on Transaction-Level Verification gives a picture of the thinking about some of the issues associated with this topic.  To be fair, the technology is still new, and a few of the approaches are experimental.  But the requirements are concrete and the development of the TLM 2.0 specification by OSCI is an answer to the need.

Simon Davidmann brings the software point of view, while Lauro Rizzatti speaks from an emulation background.  Patrick Sheridan has been involved with ESL issues for some years and has also been instrumental in the growth of OSCI.  Finally, Giovanni Mancini from The Mathworks provides the experience of a company that has dealt with system design issues not just for electronic design, an area they are entering with enthusiasm and success, but also at the level of integrating and verifying heterogeneous systems.

Luc Burgun, CEO of EVE, the successful emulation company based in France, provides a humorous view of what it is like to start a company outside of Silicon Valley.  At times you may think that his view of the role of France in the world's affairs may be a bit parochial, but we must confess that Silicon Valley suffers, frequently, from the same malaise.

The third article looks at the immediate future of the EDA business as it is affected by Moore's Law.  Geoffrey James gives reasons to dismiss the predictions of those who say that manufacturing complexity will constrain creativity and force designers to use standard logic blocks that have been pre-verified by the foundry.  I am in the camp of those that say that some standardization will occur, especially in analog design. 
Free-hand analog circuitry is very demanding on resources, both for design and verification.  And without standard blocks, it will be difficult to ever achieve analog synthesis.  But you are free to express your own opinion.  Write a letter to the editor, or a Viewpoint, and let us know how you feel about it.

********************************************

The DACeZine also has a Letters to the Editor section to allow for shorter contributions to the contents and directions of the publication. When necessary, answers to the letters will come from the appropriate member of the team (including our readers), since I do not (yet) hold the total knowledge of the industry within me. I encourage all of you to write, either a viewpoint or a letter, and state your opinions on matters that impact our industry, the contents of this publication, or, for that matter, the publication itself. Send your letters to: dacezine@dac.com.

I hope you enjoy this DACeZine issue and pass it along to your friends and colleagues: I am sure they will want to subscribe as well. They can do so by visiting the www.dac.com web page.

Same Problems, Different Answers
Transaction-level verification is exposing the weak spots in advanced chip design, but it’s also prompting some new approaches.

DACeZine sat down to discuss transaction-based verification with Lauro Rizzatti, general manager of EVE USA; Patrick Sheridan, director of solution marketing platform design solutions at CoWare; Simon Davidmann, president and CEO of Imperas; and Giovanni Mancini, product marketing manager at The Mathworks. What follows are excerpts of that conversation.

By Ed Sperling

Q: Transaction-level verification (TLV) is a term that sounds very precise, but the real-world application seems far less so. What exactly does it purport to solve?

Rizzatti: TLV is a way of simplifying the testbench and moving out everything that is time-consuming because it is at a lower level of abstraction. You only leave in the testbench the code that has to do with a high level of processing. This environment can work anywhere—in an emulation system or a simulation system.  In terms of processing, it doesn’t matter which one you use. The simulator takes charge or the emulator takes charge of the testbench.
Mancini: What you’re really talking about is how you deal with complexity. On the verification side, if you look at communications protocols and the way things are designed, you encapsulate smaller things into bigger things—and at a very high level—to deal with performance. This approach allows you to do a larger portion of the design at a higher level of abstraction. You essentially separate what’s encapsulated from those objects in your system that you need to deal with in detail. For example, you separate the data from the timing to do a simulation of an FPGA. What really slows down the simulation are the details. You can do the timing very quickly, but if you have to deal with all the timing interfaces it slows the simulation down. That’s one level of abstraction. We have multiple layers of abstraction. What you’re talking about is encapsulating complexity so you can take advantage of that in your design, and then using the more abstract view in the verification process to test that the system is working the way designers envision it. One of the problems with TLV when it was introduced was that designers objected to recapturing the testbench. The moment you have to change things, return on investment goes down.
Sheridan: At CoWare we view this from the point of view of the system. The design tasks at the system level are a little different than with RTL verification, but we apply some of the same ideas in addition to transaction-level concepts at the system level. This can come up in a number of ways. One is when you’re doing verification of an SoC, and you are looking at the performance of the global interconnect and the global memory subsystem.  You are working at the transaction level, with the level of accuracy required by the architect. In this case, you can take advantage of existing and verified RTL blocks to play a role in the memory controller to validate the performance of the chip. That’s just one way TLV comes up at the system level. Another way is verifying the estimates of performance later when you actually have the different subsystems. Here the goal would be more hardware-software co-verification, or making sure the RTL is behaving as expected in terms of system-level performance.
Davidmann: In a previous life, when we were building SystemVerilog, one of the key things we tried to do was hide communication. From a design point of view and a verification point of view, you want to take the thing you’re working on and have it interface with the thing or things you are talking to.  The goal is to ensure that the system is working as expected.

Read the rest of the article

Nightmare Scenario
Will Moore's Law Put the EDA Industry Out of Business?

By Geoffrey James

It’s been called the nightmare scenario for the EDA industry, and it goes something like this:

As the usable real estate on a chip (measured in terms of available transistor count) grows geometrically larger, the cost of designing a custom ASIC grows as well.  Since each process node mandates additional design rules, that cost accelerates, particularly in the areas of test and verification.  At some point, it becomes more economically viable to simply slap every kind of circuit that anybody might need onto a standardized, ultra-densely populated “platform” SoC, rather than to design custom ASICs.  A relatively small selection of these programmable chips, manufactured at high volume and high yield, largely supplant the ASIC.  As a result, the market for EDA software shrinks to a tiny handful of standardized platform SoC designers, thereby devastating EDA industry revenues. 

There’s only one thing wrong with this idea: it ain’t gonna happen.  Here’s why.

Reason #1.  Design costs aren’t really rising all that fast.
There’s no question that chip design gets more difficult as features' dimensions continue to shrink.  “The amount of rules required to satisfy the physics for an SoC design at the smaller nodes is making digital design almost as complicated as analog design at larger nodes,” explains Steve Lewis, director of product marketing for the Virtuoso platform at Cadence Design Systems.   The increase in design cost can even be tracked from node to node, according to Richard Wawrzyniak, senior market analyst for ASIC and SoC at Semico Research Corp. “When you’ve maxed out every parameter on the die and packed the most that you possibly can onto the design, it’s naturally going to cost more,” he says.  (See Graphic: Increases in Design Cost by Node.) 

Read the rest of the article

********************************************

DAC Workshops and Collocated Events

by Gabe Moretti, Editor

As in previous years, DAC attendees will have the opportunity to attend a number of events organized during the conference that address specific topics from across the ecosystem of electronic design.  The number of events available this year is greater than ever before.  By going to the DAC website and choosing Related Events on the left hand side menu, you will be presented with three choices: Collocated Events, Adjunct Events, and Additional Meetings.  As I write this article, I count 25 events, mostly concentrated on Sunday and Monday, the two days preceding the opening of the Technical Program.  But I dare say that the number is likely to increase.  Additionally, a number of consortia, EDA vendors, and standards organizations are planning events during breakfast or lunch during the actual conference.  You can find a description of each event by clicking on the appropriate link that is available from the DAC site, and the list is growing, so visit frequently to keep up to date.  Workshops are listed under the Conference Program entry on the same menu.

Collocated Events

Collocated events provide DAC attendees with the opportunity to attend specialized programs in specific areas of interest, and also give professionals attending them an opportunity to attend DAC while minimizing travel expenses and shortening the time spent away from their desks.  The organizers of one of the events sent me additional information that I am happy to share with you.

Read the rest of the article