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.
Reprints
