viewpoint

The Time Has Come for Knowledge-based Debugging A knowledge-based debugging system frees design and verification teams from dependence on cumbersome and tedious graphical representations. by Dale A. Pollek

Are you spending too much time simply trying to understand, analyze, and locate the cause of design problems in your HDL code? If so, your design verification and debugging tools aren't knowledge-based.

A knowledge-based debugging system intelligently directs a user through a design--locating a condition quickly, isolating the relevant data subset, and then automatically pinpointing the cause and effect of the issue at hand. Knowledge-based system architectural design parses out simulation and synthesis errors early in the design flow, avoiding excessive reruns of expensive and time-consuming tools. The knowledge used by the method encompasses design-specific criteria that facilitate fast and accurate graphical views of the design's intent, which is typically buried in the mounds of HDL code. Thus a knowledge system simplifies the verification of ever more complex designs and speeds the time to tape-out.

Today's leading-edge design requires a team of design and verification engineers. In order to go forward with more complex and larger designs, the team needs a new way to debug designs, not more boat anchors--traditional GUIs and graphical PLI tools--hooked on to its simulators. Waveforms are no longer enough for efficient design debugging.

Design debugging needs a knowledge-based solution. It's time to say goodbye to tedious hours of surfing uncountable Unix files and using grep to find signal names of which grep has no connectivity knowledge. Knowledge-based tools should serve as the console for all the verification steps in a design flow, regardless of the simulator, language, formal tools, test benches, coverage tools, or static tools used. Currently, the volume of data hides design intent and makes debugging difficult and time-consuming. Verification tools not only take a long time to run, but generate volumes of data--much of it unrelated to the immediate design debugging need.

Verification team members thus lack critical knowledge of the original design intent, inhibiting their understanding of the work they need to accomplish. In many cases, they're developing and integrating legacy or third-party code and doing so without a context or documentation. Such blindfolding handcuffs the design debugging process. Let's face facts: Design reuse is a dream, not a reality; legacy and third-party IP integration is a nightmare without a knowledge-based debugging system.

So design teams make the best debugging decisions possible, given their tools and the readily available knowledge. They often run more simulations to debug a design problem, whereas a knowledge-based system uses the existing data to point them to the solution. More simulation runs might seem better, but the result is usually too much data to process. The waveforms and extracted information are usually not enough to pinpoint a problem. They yield little more than a pretty picture of the tool's internal representation, while slowing down the simulation run time. In most cases, they produce the simulator's flattened representation of the hierarchy--not the designer's intent.

The HDL source is both the "golden design" and the "golden view." Since verification and design automation tools work with the HDL source, so should design teams. Stimulus and response data (value change data, in other words) are crucial, but such information represents only some of the useful debugging data. Waveforms represent the design from an inferior tool-centric view that is usually not the best view for debugging. In a typical multiple-tool verification flow, several nagging questions recur: Which tool view do you use most often? Which is the best? How do you correlate the different tools' views? A knowledge-based system shoves those questions aside.

The complexity of today's designs makes knowledge-based debugging tools mandatory. Once you sign off on your RTL representation, you don't synthesize from the simulator's flattened representation of the design. You go directly to synthesis and layout from the original RTL description. So why debug your design using the simulator's representation?

Dale A. Pollek is vice president of sales and marketing at Novas Software, Inc. in Milpitas, Calif. He has over 18 years of experience in the EDA and electronics industries. Prior to working at Novas, he was director of sales at Systems Science. He has also held positions at CAE Systems and ECAD.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  February 1999