Cross-viewing improves ASIC & FPGA debug efficiency

We introduced the philosophy behind the Blue Pearl Software suite of tools for front-end analysis of ASIC & FPGA designs in a recent post. As we said in that discussion, effective automation helps find and remedy issues as each re-synthesis potentially turns up new defects. Why do Blue Pearl users say their tool suite is easier to use than other linting and CDC tools?

An effective ASIC & FPGA design flow integrates analysis tools with the main EDA environment, minimizes jumping back and forth between tools, but allows flexibility in how results are obtained. In what Blue Pearl terms “continuous integration”, code review is automated to a manageable rule set so coding standards are enforceable across teams and projects. While automated testing is fast and thorough, the key to productivity is how debug information is managed and resolved. Analysis tools that present accurate results quickly and clearly soon become part of a designer’s trusted environment.

All debug results produced by the Blue Pearl testing suite – including Analyze RTL, Clock Domain Crossing (CDC) analysis, and a Synopsys Design Constraints (SDC) management tool – are presented in a GUI with cross-linked viewers. Tcl scripts are also supported via a command line interface (CLI), and analysis jobs run from the CLI can have their results viewed in either the GUI or the CLI.

The power of the Blue Pearl GUI is its cross-viewing capability. Most linting tools spit out endless lists of text messages, usually linked to a view of source code. CDC tools typically provide text messages with a link into a schematic window illustrating the problem. Messages are often cryptic, and without context sometimes determining the exact severity of a problem is difficult.

One of the Blue Pearl customer presentation slides starts out with this: “Getting an error message is only part of fixing problems.” Unique to the Blue Pearl suite is how everything is tied together and manageable, allowing the user to visualize any issues and see in what context they occur. The obligatory text message window is at the center, but reimagined with meaningful messages linked to a line of code and cross-linked to several other viewer windows.

Messages from the main window can be narrowed down by grouping or user-defined filtering in the message viewer window. This is critical to any linting system; some errors are really warnings, others are severe and require design changes. Users can find what errors demand action quickly, rather than sifting through a long list with eyeballs and hoping to catch everything.

More powerful contextual capability is represented in several other windows.

• Finite state machines (FSMs) have their own viewing window, clearly showing terminal or unreachable states.
• Clocks and domains have their own window, under the presumption that some issues are related to how clocks and domains are set up.
• CDCs also have their own window to view the synchronizer constructs in detail.
• Pruned schematics and highlighted paths have windows so errors can be visualized in their context, and tracing can follow a signal forward or backward in the code to help identify the source of the problem.
• False paths have their own view for individual treatment.
• A search and navigate window helps find signals, objects, or hierarchical relationships quickly.

Cross-viewing capability in the Blue Pearl suite allows errors to be understood and solved quickly. RTL issues can be uncovered pre-synthesis, and CDC problems difficult to detect at all in simulation can be identified and handled. Compare this approach to post-synthesis debug that has to go all the way around the loop and may still not completely resolve the actual source of the error, requiring another debug and synthesis pass.

We’ll discuss the Tcl script interface and message filtering and waiver system more in our next post describing the Blue Pearl 2016.1 release features.