At one time, the relationship between logic designers and physical implementation specialists was simpler. Front-end designers had long been accustomed to providing their ASIC vendors with a timing-qualified, gate-level netlist that was blessed by their "golden" sign-off quality simulator. The ASIC vendor would accept that netlist and take it into physical design, doing its level best to meet its customer's performance, power, and area constraints.
But things are no longer that easy. Rather, the relationship is complex and becoming more so. ASIC vendors are finding that at deep-submicron (DSM) process geometries, their customers' netlists don't always tell the whole story.
Sometimes issues are embedded in those netlists, and in the register-transfer level (RTL) code from which the netlist was synthesized, making physical design a nightmare. These issues can range from simple structural problems, such as unconnected ports or undefined signals, to more complicated and difficult-to-diagnose matters like snake paths, which cross multiple hierarchies and tend to cause trouble in synthesis.
Thus, some ASIC vendors now ask their customers for the source RTL code that their netlists were synthesized from. ASIC and system-on-a-chip (SoC) de-signs are growing so large and densely integrated that ASIC vendors are chafing at the notion of having to dig back into the RTL at the late stage of physical implementation to find out the root of problems that they would rather not know in the first place.
One aspect of the answer to this dilemma is further blurring of the lines between the front (logical) and back (physical) ends of the design process. This blurring has already taken several forms, one being the emergence of a new class of synthesis tools that strive to account for physical effects. Another is what some call virtual silicon prototyping, which has a rough floorplanning stage as part of the synthesis process. A third part is a trend toward RTL analysis, where RTL is examined for problems that the ASIC vendor wishes to avoid in implementation.
In this last arena, a major revision to Tera Systems' TeraForm RTL analysis and virtual prototyping package is a big step toward a solution. An added powerful rule-checking capability solves problems for the front-end system design teams that need help anticipating the impact of their RTL code on downstream implementation flows. It also aids ASIC vendors' design center support staff who must check SoC designs for those basic implementation stumbling blocks and for conformance to process-specific requirements. Both ends work toward the middle, achieving cleaner RTL that will make its way through implementation in far better shape than ever before (Fig. 1).
Rule checking in RTL for physical implementation only heightens the capabilities already present in TeraForm. The tool, which was initially conceived for front-end use, automatically converts RTL code into a silicon virtual prototype. However, it does so at a higher level of abstraction by mapping the RTL into structures called TeraGates that accurately model logic, layout, and timing. Plus, it increases design capacity and turnaround time by 10 times.
Using TeraGates effectively collapses the number of objects that the tool must handle. The TeraGate library is composed of objects modeled from RTL constructs that are typically employed in digital design. Examples include arithmetic functions (adders, subtractors, incrementers, decrementers, and more), multipliers, comparators, registers, multiplexers, decoders, and encoders. Other items are NAND gates, NOR gates, and inverters that are instantiated into designers' RTL and structural primitives. Also supported are most single-output standard cells described in the Synopsys library format.
By internally mapping de-signs into the higher abstraction level of TeraGates, the tool gains its speed advantage. It sidesteps much of the low-level detail. Yet because the design never really leaves the RTL realm, designers retain the ability to crossprobe directly to the design itself.
As TeraForm builds its virtual silicon prototype from the designer's RTL, the rule-checking functionality comes into play. The rule-checking engine, dubbed Design Consultant, can be considered a diagnostic tool. Using a .tcl-based command set, rules are formulated to check for both syntactical RTL problems and structural conditions that would complicate implementation. The latter might include such bugaboos as gated clocks, which aren't problems unless the front-end design team fails to alert its ASIC vendor's design center engineers to their presence. The tool will check for cross-clock domain paths too.
Rules can be constructed for missing clock constraints, missing I/O constraints, unused ports, unconnected input cells, presence of latches in the design, incomplete case statements, modules with unregistered outputs, shift registers, large multiplexers, and high-fanout nets. Most of these rules are parametric, meaning that limits can be set to look for, say, fanouts of more than a certain number. In addition, the tool can search for local or global congestion, checks that require area information derived from TeraForm's virtual prototyping functionality.
Another important feature of the rule checker is that rules can be applied in combination or hierarchically. Rule authors can use the result of one rule to conditionally branch into the execution of another. This makes it possible to write some highly sophisticated checks.
Rules come from three sources. One is Tera Systems itself. With the upgraded version of TeraForm, the company will provide a generic rule set that will try to anticipate violations of good, solid design practices. An example might be an attempt to use a single-state machine as a controller for multiple IP blocks across a die instead of replicating that state machine as a standalone controller for each block. Long traces result, stretching hither and yonder with attendant congestion and clocking problems.
The ASIC foundries will be the second source of rules. They're apt to see the new release of TeraForm as a way to impose process-specific rules on front-end system-level designers early in the game. This would sidestep many of the downstream issues that can stem from RTL written without heeding the implementation stage (see "The ASIC Vendor's View Of RTL Rule Checking," p. 46).
Last will be project- or methodology-specific checks that a project leader or the CAD group in a system-design organization might enforce. Just as the ASIC vendors' design centers require good, clean RTL to ensure timely implementation spins, project leaders need their teams to produce RTL that will make it through synthesis without delaying tapeout.
Results from the Design Consultant rule checker come in the form of diagnostic reports that show what parts of the design violated the particular rules executed against it. These reports can be tailored so that information is presented in the most useful way for a user. The most robust option allows users to click on an error that has been identified for a direct link into TeraForm. The tool provides cross probing between the floorplan, the RTL, the generated TeraGate-level schematic, and the timing report.
The graphical user interface (GUI) associated with Design Consultant offers a clear view of what it's checking for and what it found in the prior RTL. A screen capture shows how the Design Consultant window groups rules via tabs. Each rule has a status, options, and a view button to bring up detailed results. A Summary window supplies a summation of the results for each rule group and rule. In the CrossClock Domain report, users will see a detailed report for the cross-clock domain rule. The Timing Analysis window gives users insight into path delays, while the HDL (hardware-description language) window reveals the reports cross-probed together with RTL lines corresponding to the cell selected in the schematic (Fig. 2).
For the front-end RTL designer, Design Consultant itself can be employed as a runtime rule execution engine for RTL analysis using an externally supplied set of rules. This configuration, though, won't permit authoring of new rules.
For project lead engineers and integration specialists, the new flagship version of TeraForm is dubbed TeraForm VP. In addition to the full suite of RTL virtual prototyping capabilities, it incorporates the Design Consultant rule checker with the ability to execute any rules from any source.
It's expected that a future version of TeraForm will be introduced for CAD groups, design support teams, and ASIC vendors. This package will enable users to author, debug, verify, and securely publish sets of rules for judging customer's designs. They will be evaluated with rules that capture their internal expertise, knowhow, design techniques, and practices that the vendor knows will make for a simpler, faster implementation flow.
Price & Availability
The TeraForm RC rule-execution engine costs $20,000. The full TeraForm VP tool is available now at $50,000 per year for a three-year time-based license, or at $100,000 for a perpetual license with 20% per year maintenance.
Tera Systems Inc., 2105 South Bascom Ave., Suite 135, Campbell, CA 95008; (408) 879-1990; www.terasystems.com.