A "hand-off" of the design information from the logical/system designers to the physical implementation designers usually occurs somewhere in the design flow There are several types of hand-offs, and many challenges associated with designing large ASICs. RTL hand-off is a major step to address these challenges, leading to the ultimate goal of successful first silicon.

A variety of hand-offs

Successful RTL hand-off — in which no iterations are required between front-end and back-end operations — is a major part of a true virtual silicon prototype. Typically, a system design house team does the front-end system design capture, RTL creation and various forms of verification. Normal front-end verification iterations identify and correct front-end design or test errors. Then, the system design team runs synthesis and hands off a gate level netlist to a back-end implementation team.

The implementation team does the back-end physical design tasks of netlist checking, scan test insertion, placement and routing. It performs a variety of electrical and physical design rule checks, and analyzes timing, signal integrity, thermal, noise, and so forth. Normal back-end verification iterations identify and correct back-end design or test errors. The team then delivers a final physical design file to the mask shop for fab or foundry.

Hand-offs between "front-end" and "back-end" teams can occur at several points in the design flow.

• If the system design house elects to do all the back-end design steps, and then delivers the final physical design file, the hand-off is called COT (customer-owned tooling).
• If the system design house does the floorplanning and placement, and hands off the design to the ASIC house, the hand-off is called a placement hand-off.
• If the system design house stops at synthesis, it is a traditional netlist hand-off.
• If the system house stops at the RTL level (before synthesis), it is an RTL hand-off.

Types of hand-offs

The earlier the hand-off takes place in the design methodology, the higher the level of abstraction the system designers utilize, and the less involved system designers need to be in the physical design details. Thus they concentrate more on system design and verification issues.

Some designers of very high-performance chips may want to own more of the back-end design. However, the majority of ASIC business customers wish to concentrate on developing RTL for the system design, and prefer a low risk hand-off to the ASIC back-end provider.

Some RTL hand-offs are not crisply defined, but may need several iterations between the system designers and the back-end team to reach a clean hand-off.

Problems with existing flows

Unpredictability
Large ASIC designs currently are unpredictable in area and performance. In addition, they take too long, and cost too much to develop. They often exceed expected turnaround time (TAT) and time to market (TTM) expectations. At a recent Design Automation Confernece panel about COT (nicknamed "Customer Owned Trouble"), panelists mentioned that a very large percentage of COT designs are late to market, require one or more silicon re-spins, and miss the targeted performance /area goal.

Unknown layout impact from RTL
The RTL can be lexically clean, but still result in physical layout problems (congestion, timing, signal integrity). Newer RTL qualification tools identify and report lexical and layout-critical RTL structural problems. They also analyze and generate the necessary timing and physical constraints to prevent or correct problems.

Front-end/back-end disconnects
Front-end timing estimates based on front-end floorplanning often do not match actual back-end physical placement timing. Little physical information is fed forward from the front-end design to the back-end implementation. Thus errors discovered in the back-end often require rework in the front end, and subsequent rework in the back-end.

Synthesis (mapping of RTL logic into library cells) often acts as a "blender," slicing and dicing the logic so resulting logic and timing have lost their relationship to the original RTL. This makes the front-end more disjoint from the back end, further aggravating the front-end / back-end iteration problem. Repeated synthesis and place & route iterations are usually required.

Rework in either the back-end or front-end may solve one problem but cause another (for example, fixing a timing problem in one place may cause a new timing, signal integrity, congestion or power problem in another place). Final resolution of all these problems constitutes "design closure."

Design closure issues

Successive rework iterations may converge to closure, but that is currently unpredictable, and thus there is no guarantee that closure can be achieved. Errors requiring front-end/back-end iterations after hand-off are the most unpredictable and time-consuming. Each such iteration takes a lot of time to analyze, fix, and re-verify, which affects development cost and TTM.

Sometimes, it's too late to fix the front-end, based on issues found in the back end. (ASIC vendors and COT back-end teams deal with this all the time). Furthermore, the RTL may not always be available (if the RTL design is frozen or there are intellectual property access issues).

The top 10 attributes

1. Performance — a 10X or better speedup of the front-end design and RTL/physical optimization process resulting in quick generation of floorplanning, placement and timing estimates.

Currently, design engineers are forced to handle too many gates to do front-end physical floorplanning and RTL analysis. In addition, the front-end tools take too long. A higher level of abstraction (10 "20X) allows faster RTL analysis/ partitioning/floorplanning tool performance.

In addition, eliminating front-end/back-end iterations results in much faster turnaround time and time-to-market for the design.

2. Full RTL analysis — Many current tools address only a portion of the RTL analysis problem. RTL qualification must go beyond lexical correctness and include:

• RTL physical implementation constructs (structural correctness)
• Fast, high-level RTL physical planning
• Fast, high-level synthesis/physical partitioning
• Design floorplanning
• Fast timing, area, and congestion analysis and flaw reporting
• Clear graphical reporting of problems to aid the engineer

4. Support for logical/physical hierarchies — good layout often requires a physical hierarchy different from the logic hierarchy. So the tools and data model must support separate hierarchies, but maintain traceability. The graphical reporting should clearly link the logical and physical hierarchies, so problems can be quickly resolved in either domain.

5. Ease of use — the RTL design tools and approach should be simple and easy to learn, with no-hassle integration.

6. Incremental compatibility — the improved RTL tools must interface with and be compatible with legacy systems. These include existing front-end and back-end design capture and verification (for example, formal, semi-formal and simulation) tools. In addition, a user should be able to insert the new RTL hand-off tools into their current flow, and start using or trying the new tools without a wholesale multi-tool change-over to a new design flow.

7. Back-end independence — the front-end design flow for RTL hand-off should interface and be operable with a variety of back-end flows.

8. No forced compromises — such as trading off development time (cost), area (cost) or predictability to achieve performance, and/or time to market (TTM). Such compromises are common with current design methodologies. An RTL hand-off design flow must provide early performance, area and timing information to RTL designers when the impact to the design is the greatest and the cost to modify is the lowest — during RTL development.

9. Cost control — the ability to handle front-end designs of 5-10M gates or greater without adding expensive server farms, high-priced workstations or expensive tool licenses.

10. Clean hand-off — a crisp, clean hand-off from front-end designers to back-end designers. This provides better risk control, less confusion and less "shared" responsibility. It eliminates time-consuming initial back-end / front-end iterations during the hand-off.

Conclusion

Design methodology that includes these attributes enables a true single-pass RTL hand-off from front-end design to back-end implementation, with no front-end/back-end iteration. It vastly lowers the risks in achieving function, performance, and area goals, and reduces chip cost, development cost and market opportunity cost.

Mike Purnell is vice president of engineering at Tera Systems. RTL hand-off will be discussed further at the RTL Hand-off symposium at the Design Automation Conference, "The Real World Advantages of an RTL Handoff Methodology: Unleashing the New Wave In Silicon."