In years past, DAC has provided a stage for presenting the tools that have dramatically changed the design world we live in. Virtually all evolutionary phases in EDA tools and methodologies have been announced at DAC. The fact that the adoption rate has, historically, hovered around zero for a year or more following each important announcement merely indicates that any tools released at DAC must be tested over time to validate the associated innovation as acceptable and significant.

In its short history, the EDA industry exhibited cycles of about eight to ten years per major tool change.

We've watched as tools have evolved from netlists, to schematics, to language-based design, to synthesis. Over the same time period, the level of abstraction has continued to move upwards, from discrete devices and their interconnections, to graphical depictions of device connections, to text descriptions of functionalityý starting at the gate level, progressing to RTL, and now approaching the system-level.

The move to the system level, however, seems to have stalled. We haven't seen pervasive adoption of new tool categories at the design level since the introduction of synthesis. The level of design abstraction moved up from gates, but the basic design flow still consists of writing words that describe a logic flow. Although the majority of a design is at the register-transfer level, at present very little seems to be at a higher level. One of the challenges is in defining the appropriate entry type: it could be an object-oriented language like C++ or Java, a special system-design language(s), graphical entry tools, or something elseýfor instance, a general purpose programming language.

Unfortunately, the occasional perception of DAC as a venue for major design flow departures is marginalized by the high rate of faulty announcements that come out of the conference. For example, two years ago the buzz was on IP and SOCs. The tool vendors claimed that their new tools and methodologies would make the design of large IC system chips "easy." This posturing probably delayed the adoption of system-level design tools by at least two yearsýa situation that may be in part a function of the hubris of the EDA companies. Thus, just as you should never trust a "turnkey" tool, use good judgement when entertaining ideas that don't seem earned. That being said, it's still the creative people, who make the changes and optimizations that enable the next generation of products.

Gordon Moore notes that up to and including the 0.25-ým generation of processes, changes in device speed and density could be attributed to: two-thirds part processing changes and one-third part designer creativity. In the future, these ratios will undoubtedly reverse.

Last year, the big announcements at DAC were centered on physical design and verification. In the physical space, about a half dozen new companies and a couple of older companies introduced new toolsýmost trying to achieve timing closure by performing some type of logical optimization at the physical level. In the verification arena, many companies added capabilities and tools to the mix to address the growing need for better verification.

Here, in the verification space, we may find the key to the slow movement toward system-level design. Today, designers develop their designs in RTL and pass it on to the verification staff, who then requires up to 75 percent of the design cycle to prove the design. If the designers move up to a higher level of language, how do the verification people keep up with the amount of code generated? If the design entry is a C-type language, the RTL that results from the language input will be even less readable and less understandable than human-generated code. RTL would present additional difficulties, because the optimizing steps from the compiler would make the source even more distant from the intermediate HDL.

At a recent EDAC meeting, Anant Agrawal, vice president of engineering at Sun, said after his designers develop and verify a design, then the verification team re-verifies the design at functional-, RT-, gate-, transistor-, and netlist-level to ensure functionality prior to tape-out. He said "the next generation of design flows needs to have the capability to verify once and then, through formal methods or correct by construction techniques, make the various transformations to the design."