Designing “with” instead of “for”
By Thomas L. Anderson, Cadence Design Systems Inc. -- EDN, June 20, 2007
In the beginning, there was design-for-test (DFT). In order to help ensure that the resulting physical chip would be testable, logic designers were required to alter their gate-level or RTL designs. Not surprisingly, many designers were less than thrilled about this addition to their responsibilities. One common reaction was, “Test is the responsibility of the back-end team; why do I have to deal with it?”
More recently, several other examples of “design-for” approaches have fallen on designers as well. One common example is design-for-verification, which usually translates into a requirement that the designers must add assertions and functional coverage points to their RTL. This requirement makes sense: many studies have shown that assertions make it easier to detect and diagnose bugs, while functional coverage is at the very heart of contemporary constrained-random, coverage-driven testbenches.
Despite these well established benefits for verification, many designers have responded negatively: “Why do I have to do more work to make life easier for the verification team? I want my weekends back!” Similar comments are being heard more often as additional requirements bubble up from chip implementation to RTL coding. For example, design-for-power is starting to show up everywhere due to the ubiquity of portable devices and various “green” initiatives.
The problem for designers is that “design-for” has usually translated into design for the benefit of someone else, or design for the benefit of the entire project. It’s not that designers don’t want to help the rest of the development team. However, they are under increasing pressure as designs become ever larger and more complex at the same time that time-to-market demands are compressing project schedules. It’s quite understandable that they do not want to feel that too much burden is being placed on them.
The answer to this situation is not to reverse the requirements for the RTL. There are very solid reasons why “design-for” has to happen during the RTL stage and must involve the designers. For example, 80 percent of the power budget for a chip is locked in at the architectural and RTL level, so that any opportunity to save more than 20 percent of the power must be addressed early in the flow, prior to synthesis, rather than during the physical implementation stages of the project.
A much better solution is to use a combination of technology and methodology to enable designers to “design-with” these requirements rather than “for” them. This is more than just a simple wording change; it implies both more integration of the design process with other aspects of the project and a higher return on designer investment. Although a relatively new concept, real benefits from “design-with” are already starting to appear.
One of the most dramatic changes has been in design-with-verification. Traditionally, designers have been encouraged (or required) to add assertions and coverage for the benefit of chip-level simulation. Attempts were made to try to motivate the designers by pointing out that they could also use formal analysis to leverage the assertions. It was a good try, but history has now shown that the promise of “eventual” formal has not proven to be a very effective motivator for designers.
Figure: “Design-with” techniques eliminate feedback loops, making the development process more predictable
Design-with-verification works much better. The goal is to involve logic designers more deeply in the verification process, starting with proactive use of formal analysis as the primary verification method at the block level. Formal with assertions and coverage allows the designers to verify many of their blocks far more thoroughly, without having to write block-level testbenches. Thus, formal analysis has proven to be a better motivator for assertions than assertions were motivation for formal.
When designers develop block-level testbenches, perhaps on blocks not ideal for formal analysis, they do not want or need the same level of power and complexity that verification teams use at the full-chip level. Design-with-verification also encompasses module-based techniques that enable logic designers to develop constrained-random, coverage-driven testbenches without having to become experts on class libraries, inheritance, polymorphism, and other object-oriented programming concepts.
By handing cleaner blocks to the chip integration team, designers save a great deal of time later in the project. Each problem found at the chip level requires a debug effort to track the bug to its source deep in the design; fewer bugs found means less work for designers. The burden for logic designers in the test domain has largely been eliminated by more automation. Today they design-with-test by providing a few pins and defining their test requirements so that the implementation tools can create and integrate the test logic automatically.
Just in the last few months, design-with-power has evolved to a similar situation. Designers no longer have to insert isolation cells between power-down domains or level shifters between voltage islands. They can capture their intent just once—in a power specification file—and then the design, verification, and implementation tools can create and check the required logic automatically. Thus, low-power requirements are integrated into the RTL flow with a design-with-power mindset rather than being a burden to designers.
In the past, finding that the power budget has been exceeded late in the back-end flow often led to major architectural changes and RTL design. Design-with-power avoids these long feedback loops; design-with-physical has a similar effect. Automatic physical layout estimation models physical effects during synthesis, eliminating long iterative feedback loops from place-and-route back to RTL to fix timing problems found in post-layout timing analysis. The result is a shorter and more predictable development schedule along with peace of mind that the end product won’t catch on fire due to chip power problems.
Shifting from a design-for mentality to a design-with approach is a current, ongoing evolution in the chip development process. Some of the traditional pain points for logic designers have already been greatly reduced, and additional technology will further reduce designer overhead and provide more return on whatever level of investment is still required. The benefits for the project are too compelling to be ignored: happier logic designers, reduced development time, a predictable tape-out date, and higher quality chips.
Thomas L. Anderson is a product marketing director at Cadence Design Systems Inc., where he focuses on verification technologies relevant for logic designers. He holds a B.S. in Computer Systems Engineering from the University of Massachusetts at Amherst and an M.S. in Electrical Engineering and Computer Science from MIT.
