Conquering errors in the hierarchy of FPGA IP

FPGA design today involves not only millions of gates on the target device, but thousands of source files with RTL and constraints, often generated by multiple designers or third party IP providers. With modules organized in some logical way describing the design, designers brace themselves for synthesis and a possible avalanche of errors.

Large FPGA designs are usually segregated into several types of IP – known-good legacy modules, third party IP, modules under development, and modules not yet started – arranged in some type of hierarchy. Synthesis tools may not pick up on the context, however.

Traditionally, an FPGA synthesis tool would take a whack at the entire design, combining and analyzing the thousands of source files, and likely encountering errors. Rather than complete synthesis, the tool would stop, making a report of items needing resolution. Designers would go in and decipher the report (not necessarily organized along the lines of the design hierarchy), and kick off another synthesis run which would presumably get farther, probably generating new errors. This iterative synthesize-find-fix process could easily take weeks before successful synthesis completion for the entire design.

A better solution is “continue-on-error”, capability found in Synopsys Synplify Premier and Synopsys Certify. In this approach the synthesis tool observes the hierarchy, and is able to broadside the design on a module-by-module basis, attempting synthesis of all modules. Many modules, presumably the known-good ones and hopefully a good number of third party and newly developed ones, will complete successfully.

In a first-pass synthesis, there may still be a multitude of errors, as Angela Sutton, staff product marketing manager for Synopsys, put it. The difference in a continue-on-error synthesis is most if not all of the errors existing in the total design are spotted, and categorized against specific modules in the hierarchy. This allows modules to be taken out, worked on in isolation, and merged back in. Such a “divide-and-conquer” approach may not completely eliminate iterations, but it dramatically reduces the number of runs needed compared to the traditional approach where only part of the design is synthesized if subsequent runs produce errors.

How is the hierarchy established? Synplify supports compile points, specifying user-defined RTL partitioning, or a hierarchical design interface where partitions can be exported based on the problem areas. Files can be merged back into the total design either at the RTL level (top-down flow) or at the netlist level (bottom-up flow).

Continue-on-error synthesis and divide-and-conquer debug of hierarchically-organized modules are just two of the techniques described in a recent Synopsys white paper authored by Angela:

10 Ways to Effectively Debug Your FPGA Design

I asked Angela to discuss what her team is working on next on the list of continuing improvements to Synplify, and she mentioned two areas. One is what to do with black-box IP, where the synthesis and debug tools have limited visibility. Synopsys is working with IEEE P1735 IP encryption, allowing tools to interpret a standardized format including design constraints, while maintaining the integrity of rights management. The second area is overall improvements in querying a design database and providing improved reporting. She cited a strong example in how gated clock transforms are handled and reported on. TCL scripting, either from Synopsys or user written, can extend the reporting capability to suit particular needs.

The challenge for FPGA designs continues to be bigger designs in less time, and clobbering tedious work of manual exploration of errors with automated solutions to zoom in on problem areas quickly. Synopsys continues to drive state-of-the-art for FPGA synthesis.

lang: en_US

More articles by Don Dingee…