Electronic Design

ASIC Handoff Gets Physical As Front And Back Ends Converge

The clean separation between logical and physical design is gone. RTL designers must think about implementation or suffer the consequences.

True or false: ASIC design follows a very straightforward path that begins with high-level architectural definition. It proceeds through RTL design and preliminary floorplanning. After synthesis, the resulting timing-verified, gate-level netlist is handed to the ASIC vendor, who takes over with more floorplanning, detailed place and route, and output of GDSII for fabrication. As a rule, register transfer level (RTL) designers don't care about implementation, and place-and-route experts don't give much thought to what's in the RTL.

If you answered "true" to all, or even most, of the above, you may, at best, be designing very simple and relatively slow ASICs in 0.35-µm process technology. At worst, you could be sitting on a more ambitious ASIC design that will never see the light of day. If, however, something didn't ring quite right, it's probably because you've woken up to the reality of ASIC design in the third millennium.

That reality is this: At 130-nm and smaller process ge-ometries, the days of the nice, clean handoff of a gate-level netlist to an ASIC vendor are very much over. Even if ASIC design meth-odologies never vary from the tried-and-true formula of gate-level netlist handoff, something has to give.

ASIC vendors are finding that the gate-level netlist, based as it typically is on statistical wire-load models, doesn't convey nearly enough information for accurate delay calculations. In this day of interconnect delays that easily swamp gate delays in terms of their overall contribution to timing, the traditional gate-level netlist is a recipe for disaster. More often than not, the result is an endless cycle of iteration from synthesis to floorplanning and global placement and routing, back to synthesis, in an effort to achieve timing goals (Fig. 1).

According to Dave Reed, vice president of solution delivery at Monterey Design Systems, "Starting at 0.35 µm, and certainly by 0.18 µm, you had to look not just at a statistical wire-load model, but also at the physical placement, to get an idea of what the wire length was going to be, so you could accurately model the delay. The problem is, for sure with 0.13 µm already and, no doubt, 90 nm, just knowing the placement isn't nearly enough to have all you need to know to close the design. You need to get information from the routing world too."

It appears that at least one of two things must happen in the ASIC flow as process geometries drop to 130 nm and smaller. RTL designers must develop an awareness of, and a methodology for ascertaining, the effects on implementation of their RTL code. Some tout such techniques as the only way out of the iteration quagmire that plagues traditional methodologies. Tools that analyze RTL to look ahead to its impact on physical implementation are beginning to make their presence felt. Others that build virtual prototypes from RTL to examine how delays will shake out promise to break the synthesis/place-and-route iteration deadlock.

Less certain, but still worth examining, is the need for a shift in the point at which ASIC designs are handed off for implementation. Some would have ASIC design teams pass their designs over for implementation at a higher level of abstraction than a synthesized, gate-level netlist. Proponents of RTL handoff point to the advantages of not separating synthesis from place and route as is done in the traditional front/back-end split.

Others would take the handoff point to a place farther down the road to implementation, suggesting that the synthesized netlist should be brought down to the level of placed gates. Placement-based handoff, as this is sometimes called, would by necessity include a global route. Going in this direction would, at least, give the designers more to go on in terms of physical information and, it's thought, a better shot at timing closure.

Finally, others say that the customer-owned tooling (COT) model makes the most sense as an ASIC methodology. In a COT flow, the typical scenario is for a system house to directly work with a pure-play foundry. A COT flow generally means that the system house takes its design all the way through to physical implementation. The resulting GDSII representation of the design is, in theory, ready for fabrication and packaging.

To some extent, the handoff point is a business-model decision. It also is a matter of risk and who assumes it. System design houses with the expertise to take the COT route are relatively few. If you're an ASIC vendor, that's good news. COT flows and ASIC vendors generally don't mix, as ASIC vendors lose much of their opportunity to provide value-added services in such scenarios. Taken as a group, EDA tool vendors, ever-hopeful of coming up with an answer to the deepening design gap, seem to be pointing in conflicting directions.

The question of what must happen at the RTL stage of the ASIC design process is much clearer. More physical information must be accounted for in the front end of the cycle. "Pushing physical information forward is clearly happening," says George Janac, president and CEO of InTime Software. "Wire-load models don't mean a thing. I think there's going to be more tools that let RTL designers look downstream and determine what timing will really look like."

There are three primary ways to move physical information forward into the front-end flow: virtual prototyping, floorplanning, and RTL analysis. The idea of virtual prototyping is to give the front-end designer a set of tools that rapidly maps a design into a rough estimate of what the physical design might look like.

But, says Bob Smith, vice president of marketing at Magma Design Automation, it's important to provide the front-end designer with that physical insight in a way that gives him data that he's used to seeing, rather than forcing a move into full-blown physical design. "When they get to the next handoff point, they have a good degree of comfort that the chip can be laid out and routed," says Smith.

"Designers are finding that they have to go farther and farther into the physical domain, and bring those ramifications into the design cycle," echoes Suk Lee, vice president of marketing for ASIC programs at Cadence Design Systems. But at the same time, Lee maintains, they're trying to avoid becoming silicon experts. "Otherwise, why not just go COT?"

For its part, Cadence is working toward what it terms a virtual physical prototype-based handoff. Such a strategy entails a placement-based handoff that's augmented with detailed information about the actual nanometer wires that connect gates. "In a traditional front- and back-end methodology, the first time you see those wires is in the detailed routing stage," says Lee.

Among early entrants in the virtual physical-prototyping arena is Cadence's Encounter RTL-to-GDSII architecture for nanometer-scale digital design implementation. The system accounts for such factors as IR drop; delays, which are based on layer assignment and coupling capacitance; and any crosstalk effects. Through a trial-detailed route, the tools provide a detailed representation of the wires at every stage of design implementation.

Agere Systems has signed on with Cadence for purposes of providing its ASIC customers with a temporary First Encounter license. Agere's goal is to enable customers to deliver designs that are more likely to meet first-silicon success. As a result, Agere itself can shorten the back-end implementation cycle through elimination of the typical iterations across the front- and back-end divide.

Hybrid techniques are available that combine floorplanning, virtual prototyping, and RTL analysis as well. One example of this can be seen in Tera Systems' TeraForm RTL Design Planner. Tera's approach centers on the notion that to succeed in nanometer ASIC design, RTL designers must know more about physical design. Likewise, place-and-route experts ought to know more about what's going on in RTL. But neither should have to become experts in the other's domain.

"The 'gotcha' in the middle of this is a knowledge gap," says Mark Miller, Tera's vice president of marketing and business development. According to Miller, the design teams are asked to assimilate new technology and skills in the placement realm. Conversely, the ASIC vendor's support organization is filled with layout and place-and-route experts. Their aptitude in language-based design isn't that high, nor do they know much about synthesis. In the end, Miller contends, the knowledge gap is that both sides of the equation need each other's knowledge to successfully move the handoff point in either or any direction.

Miller and Tera Systems are of the opinion that the point at which ASIC designs are handed off for fabrication must move up in abstraction to RTL. Given that eventuality, the methodology question that arises is whether the RTL representation of the design is handed to a synthesis expert, who gives a netlist to a place-and-route expert for implementation, or the RTL is provided to a single expert in both synthesis and implementation.

For Philip George, director of business development and strategic marketing at Atrenta, the growing RTL handoff trend is clear. "The motivating factor is that we can no longer do this sequential process where synthesis is at a different step than place and route. Synthesis and layout are working together much more intimately for many EDA vendors out there," he says.

But George and Tera's Miller agree on the knowledge-gap issue. That individual with expertise from synthesis through place and route simply doesn't exist. "As ASICs become more complex, you need more and more experts in the back end. If that's the case, there's a problem," says George. "There was once a time when a synthesis guy could take on placement. Not anymore. Now, you've got different experts for placement, routing, and timing."

If ASIC designers are to stick with the traditional gate-level netlist handoff, they must go well beyond functional verification and synthesis. To make the design operate at rated clock speed and make it manufacturable by the ASIC vendor, the system design team now has to learn about physical design attributes like placement, aspect ratios of blocks, pinouts, overall die-size constraints, congestion, and more. "You're asking a community of people who have a clear, historic aptitude as system-level architects to handle all this," says Miller.

Tera's and Atrenta's answers to this dilemma lie in the realm of RTL analysis. Tera's design-planning tool incorporates an RTL rule-checking capability known as the RTL Design Consultant (see "Rule Checker Takes RTL Analysis Into The Physical Realm," electronic design, June 10, 2002, p. 45). The tool uses a .tcl-based command set to check RTL code against sets of rules that comb the design for both syntactical problems and structural conditions that would complicate matters for downstream physical implementation. The results of the rule checks are taken in context of the full tool's design planning capability, including full-chip partitioning, optimization, floorplanning, routing, analysis, and visualization.

Atrenta's Spyglass tool is a predictive RTL analyzer that performs detailed structural analysis on RTL Verilog and VHDL, checking coding styles, synchronization, timing, RTL-handoff, design re-use, clock/reset requirements, and much more. "One of the areas in which we do a lot of analysis is the whole clocking and reset structure, which strongly affects the feasibility of building the design," said Bernard Murphy, Atrenta's chief technology officer.

The utility of RTL checking is not lost on the ASIC vendor by any means. While most customers still send a gate-level netlist at the handoff point, LSI Logic's point of engagement with its ASIC customers is coming earlier.

"We are receiving RTL code from customers in order to analyze that code," said LSI's Jeff Vanderlip, CAD and methodology technology product marketing. "We're actually doing that at 0.13 µm, on every opportunity. Some 0.18 but all 0.13. So this is happening before 90 nm. We analyze the RTL code for problematic structures that we know will cause issues in layout, either timing or congestion," says Vanderlip.

LSI takes ASIC customers through a three-review process with their RTL code. Part of that process involves running the Tera Systems tool, using it to run checks of rules that are specifically geared to pinpoint problematic RTL coding that will gum up LSI's process technology.

"Our goal in RTL analysis is to find all the major problems in the code. I wouldn't say we're 100% there today, but we're well on the way," says Vanderlip. "The goal is to find the major problems so that when we move into physical synthesis, the problems that are left can be resolved in that process."

The notion of checking and analyzing RTL ahead of the place-and-route cycle is appealing, but when it comes to higher-end designs, claims Vanderlip, many customers want to maintain control of the process a bit further downstream. "The conversation is not complete without mentioning customers who are running physical synthesis or placement tools."

RTL analysis has fans in other quarters as well. "We're seeing a lot more RTL handoffs," says Doug Bailey, vice president of marketing at Chip Express. "People are seeing less value in doing the synthesis themselves when they're sure that the design can be synthesized." Bailey terms RTL analysis tools as "underutilized." Chip Express is working toward defining rule sets much as LSI Logic has for its own processes. The company also plans to support Cadence's First Encounter virtual prototyping tool on its forthcoming 0.18-µm process.

With wire delays growing more dominant, the netlist that synthesis produces is less indicative of what you'll see after layout. Having front-end designers run physical synthesis, which generally results in a netlist coupled with a timing-closed placement and global route, can bring about a more accurate representation of where they really stand with respect to the ability to close the design.

Placement-based handoffs generally come in two flavors, according to Sandeep Khanna, director of marketing for physical synthesis at Synopsys. One is where the system design house takes care of everything from RTL to floorplanning to physical synthesis and hands a netlist and timing-closed placement to the ASIC vendor. The other is a scenario in which floorplanning is taken over by the ASIC vendor.

An emerging third option for placement-based handoff is called pseudoplacement handoff. Aimed at mid-performance designs, pseudoplacement handoff is championed by Synopsys. It takes advantage of new capabilities added earlier this year to Physical Compiler. The RTL Performance Prototyping (RPP) flow allows a rapid exploration of physical design alternatives early in the design cycle (Fig. 2).

Khanna notes that one key prerequisite of physical synthesis has been a floorplan. "The pseudoplacement flow with RPP builds a floorplan automatically under the hood, making synthesis based on detailed subplacements rather than on a statistical model. That improves the accuracy of the results. Therefore, before the handoff to the vendor takes place, the quality of the constraints that are passed off, and confidence in the quality of the netlist, is much higher," says Khanna.

Somewhere between RTL-based handoff and a placement-based approach is a coordinated floorplanning strategy. InTime's floorplanning method results in design handoffs at multiple stages in the flow (Fig. 3). "Design teams are looking for two things," says InTime's Janac. "One is to pinpoint things in RTL that just won't make timing. Every chip has one. The other is to know whether or not RTL is in the ballpark where Physical Compiler can succeed and the router can route it."

To achieve these goals, InTime's tools construct hierarchical floorplans of an RTL design as a means of predicting timing. "We're basically quantifying RTL timing as a two-dimensional scatter plot," says Janac. The resulting plot allows designers to see which paths in the design will make, and miss, timing budgets. The tool also points to problem areas in the RTL itself that cause timing mishaps.

There's little doubt that today's process geometries demand attention to physical effects during front-end design. These physical effects can manifest themselves in a myriad of signal-integrity and power-related difficulties, all of which must be part of the ASIC signoff checklist. "First, in the signal-integrity domain, the delay calculation must comprehend all of the coupling effects," says Jerry Frenkil, vice president of advanced development at Sequence Design. "Unless you account for not just the wire delays, but in particular, the capacitive coupling be-tween wires, your delay calculations will be quite erroneous."

Thorough examination of an ASIC design from the perspective of power integrity is critical, Frenkil points out. Power signoff needs to happen in three places. One is at the RTL stage, because most power-related aspects of a design have already been put in place in RTL. The next is immediately after synthesis, and the last, and most comprehensive, is after placement and routing.

"You want to verify several things at that point," says Frenkil. "One is the total amount of average current. Another is minimizing voltage drops on the power grid. If you have excessive drop, it can cause all of your timing calculations to be wrong. Plus, the switching of all the transistors can cause noise on the power lines, which gets coupled into signal lines."

In methodology terms, dealing with these issues sequentially and in isolation can lead to an endless cycle of fixes. "You might fix a power problem and get a noise issue in return. Fix the noise issue and you get a timing issue. Fix the timing issue and you get a timing issue in another part of the design," Frenkil notes. Thus, only a concurrent ap-proach is practical at 90 or 100 nm.

While some EDA vendors are in the market of specific solutions to the problem of pulling physical detail up into RTL, others tout a more holistic ap-proach to ASIC design closure and handoff to fabrication. Not surprisingly, the latter camp tends to see a trend toward COT flows in the ASIC world.

For vendors of the latest generation of high-capacity tool sets, the value of separating floorplanning from full legal placement and routing comes under question. "From my perspective, placement is a very large part of place and route," says Chi-Ping Hsu, chief operating officer of Get2Chip. "We spent 15 years trying to merge these two things into one. Now people are trying to separate them again."

In Hsu's view, a move into floorplanning is so akin to legal placement, with so much attention to detail required if it's to be done well enough to make a difference, that the design team may as well finish the job. "One of the solutions being batted around for ASIC handoff is placed gates. That's tantamount to going COT," adds Steve Carlson, Get2Chip's director of marketing. "You've saved yourself one button push, basically. At the back end, you have to do all the rest of the work to really know what you have placed gates-wise. Otherwise, you've stopped in the middle of a single process," Carlson says.

Get2Chip's architectural synthesis tools purport to bring higher capacity to the equation. This enables designers to run synthesis on large portions of their design while preserving top-level constraints.

In the end, one might indeed ask if a netlist has any relevance at 90 nm and below. "In my mind, it doesn't," says Magma's Bob Smith. "Timing is so highly dependent on that final layout. The netlist might tell you functionally what's going on, but from a timing standpoint, it's bound to be pretty hopeless without that layout information." Going forward, ASIC design teams will be forced to get physical, early in the process, if they're to succeed in the nanometer era of design.

Need More Information?
Atrenta Inc.
(408) 453-3333

Cadence Design Systems
(408) 943-1234

Chartered Semiconductor Mfg.
(408) 941-1100

Chip Express Corp.
(408) 988-2445

Get2Chip www.get2chip.com
(408) 501-9600

InTime Software
(408) 565-0111

LSI Logic Corp.
(866) 574-5741

Magma Design Automation Inc.
(408) 864-2000

Mentor Graphics Corp.

Monterey Design Systems, Inc.
(503) 685-7000
(408) 747-7370

Sequence Design Inc.
(408) 961-2300

Synopsys Inc.
(877) 321-6063

Tera Systems Inc.
(408) 879-1990

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.