United Business Media EE Times


Search

HOMEMARKET INTELLIGENCE UNITFORUMSDESIGNNEW PRODUCTSCAREERSBLOGSCONTACTEVENTSSIGN UP!RSSMost Popular contentTrusted Sources

 

System Design

Readers Speak Out on Deep Submicron

Integrated System Design surveys its readers and gets several earfuls. Our report covers the need for an RTL interoperability standard, floorplanning, and placement and routing.

by Jonah McLeod


In July, we surveyed our readers about their experiences in implementing designs with deep-submicron (DSM) process technology. Our premise was that as semiconductor feature sizes have reached 0.5 µm and below, the methods needed to design circuits have had to change. Until recently, commercial design tools were built to handle circuits in which gate delays exceeded interconnect delays. However, at the smaller feature sizes of DSM processes, the opposite is true. Yet designers are still using conventional ASIC flows, even for designs implemented with 0.25-µm processes.

We asked designers if DSM constraints have created a need for an RTL interoperability standard. Does the need for a new design method give synthesis tool vendors an opportunity to challenge the entrenched market leader, Synopsys Inc. of Mountain View, Calif.? We also asked designers if they were happy with the delay information offered by foundry libraries, information that they used to design for DSM processes.

Another area of interest was the use of pre- and post-synthesis floorplanning--now necessary as interconnect delays determine the timing of DSM designs. We asked designers if they tried to achieve the performance and the die area benefits DSM processes make possible by performing full placement and routing of their designs, rather than relying on ASIC vendors for this function. Also, we wanted to learn which layout tools they preferred.

We asked about RTL interoperability standards in light of the criticism over Synopsys 's reluctance to accept an RTL synthesis standard: "How important is such a standard to your work, and do you see such a standard becoming more important as you design for process technologies of 0.5 µm and below?"

The case for RTL interoperability Andrew Graham, president of Silicon Integration Initiative (SI2), formerly the CAD Framework Initiative (Austin, Texas), listed two reasons for RTL interoperability: to use it as a baseline for a broader design description language and to use it as a medium of exchange. "As the baseline for a broader description language," Graham says, "the original attempt at an RTL standard fell short because the market really needed standards beyond the basic synthesis subset of the language. Although Verilog is a de facto standard, it is unable to bridge from higher-level constructs down to the new levels of detail required by DSM modeling."

"I see an end to the 'one size fits all' language approach," he asserts. "There is a need for a modeling language able to represent the spectrum of DSM information that is compatible with, and linkable to, EDA tools. The language will provide a platform for intellectual property developers. LADL is a proprietary version of such a language that has existed for some time at Synopsys ."

Graham explains that as a medium of exchange, "increasingly, silicon companies are accepting RTL as a sign-off description. Thus design intent must be transmitted to ensure a successful flow through the back-end process. The trend has economic motivation for the end customer choosing to focus on functionality and timing and for the silicon vendor who can add implementation value."


Andrew Graham, president of Silicon Integration Initiative (SI2), sees the need for a modeling language able to represent the spectrum of DSM information.
A senior member of the technical staff at a military electronics company also sees the need for a medium of exchange. "RTL interoperability standards will be very important to enabling synthesis tool interchangeability. Libraries of IP will certainly include RTL models at some point. With technology changing every year now and accelerating, we'll need to synthesize to the latest technology with every chip spin. The RTL model must work with whatever synthesis tool cuts time to market most."

According to Russell Ray, a staff engineer at Mitsubishi Semiconductor America Inc. in Durham, N.C, RTL operability would solve another problem: "With smaller geometries, it's very likely that we'll be using different tools for different portions of a design--a datapath compiler or a customized control compiler along with a synthesis tool. A standard will allow one RTL representation that every tool will understand."

Chris Tann, a project engineer at Atmel Corp. in San Jose, disagrees. "We use Verilog RTL for our digital design work. We perform our synthesis work using Synopsys , although some RTL development is performed using Exemplar. For us, interoperability is not a major issue today."


Nancy Nettleton, ASIC design methodology manager at Sun Microsystems, says an RTL interoperability standard will be important only when her company comes to rely heavily on cores.
This sentiment is echoed by Nancy Nettleton, ASIC design methodology manager at Sun Microsystems Inc. in Mountain View, Calif. "I see this standard as important only if we come to rely heavily on cores," she explains. "We don't rely heavily on cores today to manage deep-submicron complexity, and I frankly don't see it as an effective tactic. It can certainly trim off a few commonly used blocks, but the bulk of our deep-submicron logic is unique. I'm going to code it up and send it through a synthesis tool. Its interoperability isn't important once the product is out."

Finally, Charles Keith, electronic design automation engineer at Hewlett-Packard Co. based in San Diego (speaking for himself and not his company), sees RTL interoperability as a nonissue: "Verilog HDL source code is about as interoperable as C source; both require porting effort, but Verilog is less likely to be ported. What this illustrates is more Synopsys 's attitude toward its customers than any burning real-world problem."

We surveyed sentiment about Synopsys and the premier position of its synthesis tools. We asked: " Synopsys is the predominant supplier of synthesis tools, but recently a new start-up, Ambit, has begun offering a competitive solution. Have you had experience with the new Ambit tool, Build Gates, and if so is it better or worse than Synopsys ?"

The great synthesis war One respondent summarized the competitive battle by saying, "In February 1997, we saw that for some, but not all, circuits, Ambit was able to get better timing results than Design Compiler 3.4b at the cost of increased run time and larger area. But Synopsys 1997.01 is somewhat better than 3.4b on average, and Ambit's tools are changing rapidly, so the picture is less clear today. I'd really need to do another benchmark to be sure."

Another reader also performed a recent benchmark of both the Ambit and Synopsys tools. He supplied benchmark data that supports the previous reader's assertions (see "Ambit vs. Synopsys , mano a mano ").

Other readers either had no experience with Ambit or had heard favorable comments from other designers who had used the tool. A few doubted Ambit's chances against the dominantly established Synopsys . Two others pointed out the dark side of the new start-up. One of them, John Mathieson, vice president of technology at VM Labs, Los Altos, Calif., comments: "We're a small company, with only a few Synopsys licenses, and Ambit told us that they are pursuing large accounts for now and are not interested in supporting small companies."

Despite its dominance in the market, in general designers were happy with Synopsys 's tools. "I found Synopsys to be an 'infuriatingly good' product," says one anonymous reader. However, he also states, "Getting Synopsys to synthesize to the correct constraints can take way more time than getting functionally correct logic." Another reader adds, "There is considerable investment in Synopsys -based scripts in the industry. Just the thought of ripping up all our Make files and scripts gives me shivers."

But some readers, none of whom wish to be identified, complain about the negative aspects of Synopsys . One response in particular illustrates their frustration: "I don't like Synopsys requiring new licenses for every new major release they offer. For example, scan-ready synthesis requires a test compiler license."

Timing is everything Bigger than the debate over which synthesis tool a designer needs to create deep-submicron designs is the problem in acquiring accurate delay models for process technologies in which interconnect delays exceed gate delays. We asked: "One of the major stumbling blocks to right-first-time ASIC design in process technologies below 0.5 µm is ASIC vendors' libraries' lack of detailed timing information needed to accurately predict critical-path timing. Has this been your experience in building ASICs in process technologies below 0.5 µm? If so, how have you solved the problem?"

"Major stumbling block is right," agrees one anonymous designer at a major semiconductor company. "ASIC libraries are always way off. We routinely recharacterize for our processes, and that's a lot of work for the library team."

Gary McMillian, vice president and chief technology officer at Systems & Processes Engineering Corp. in Austin, Texas says, "We've developed our own libraries completely independently of Vitesse and Motorola, our gallium arsenide foundries. It was a lot of work, but I think it pays off when developing 500-plus-MHz ICs."

Respondents affected by library timing fall into three categories. In one group, represented by the previous examples, designers took matters into their own hands by creating their own libraries based on process data received from the foundry. In a second group, respondents pushed their ASIC vendors to achieve the performance they needed. Members of the third group contented themselves with existing libraries by setting more conservative performance goals.

Responding to the second group of designers' demands for improved data, John Griswold, ASIC design engineer at ASIC vendor Symbios Logic, based in Boston, remarks, "Through customer feedback, we've improved the models in our libraries. We assign one or more physical designers to assist and work with the logic designers from the start. That helps address critical-path issues, clock distribution, I/O issues, etc."

The consensus among respondents, however, supports the contention that many designers are in the third group, not fully utilizing the performance and density improvements smaller geometries provide. "I've solved critical-path timing issues by overconstraining the paths during synthesis and paying specific attention to these paths during postlayout static timing analysis," says Kelly Fromm, a design engineer at Packet Engines Inc. in Spokane, Wash.

Gyudong Kim, member of the technical staff at Silicon Image Inc. in Cupertino, Calif., echoes that sentiment. "The only solution for me was to overkill the design with excessive pipelining, which resulted in excessive power consumption."

Providing metrics for the performance hit, Janick Bergeron, director of technology at Qualis Design Corp. in Beaverton, Ore., says, "The problem is typically solved by allocating a 10 to 20 percent margin in setting the clock period constraints and fully expecting that ASIC vendors will also err in the same direction and provide timing estimates that are pessimistic. Five to 10 percent timing violations often disappear after layout."

Another reader, though, doesn't see a problem at all. "We use TI [Texas Instruments Inc. of Dallas] for ASIC foundry services. Their libraries are characterized in non-linear delay style using input slew as well as output load to calculate delays. In addition, they supply detailed wire load models for interconnect loading estimation. The problem you outline hasn't been apparent."


Ken Paist, design engineering manager at Integrated Circuit Systems, says that the effect of interconnect parasitics is probably the biggest stumbling block to right-first-time timing for ASICs.
Developing accurate wire load models Survey respondents more frequently cite interconnect, not libraries, as the culprit in getting DSM designs to meet timing requirements. Ken Paist, a design manager at Integrated Circuit Systems Inc. in Valley Forge, Pa., articulates that view: "The effect of interconnect parasitics on path delays is likely the biggest stumbling block to right-first-time timing of ASICs," he asserts. "These are not so much library issues as technology file or wire load model issues. They relate to tools and methods more than libraries. A number of EDA vendors have rightly identified this as the next hurdle in accurate timing analysis, and they're starting to provide tools to handle it."

Sun's Nettleton expands on Paist's contention: "The ASIC vendors have been supporting multiple EDA tool library formats. These different formats have different levels of accuracy associated with them, as do the tools that are using them. These tools and their libraries don't address all of the timing issues below 0.5 µm related to slew rate or signal characteristics. The result is inconsistent delay calculations by different tools."

Nettleton described Sun's noteworthy solution: "We're attempting to address some of the inconsistency issues by supporting a standard library format [DPCL]. This will help, although not eliminate, the consistency issue. It also starts to address some of the issues associated with accuracy, in particular slew rate propagation and path-specific delay."

Ed Miller, product manager at LuxSonor Inc. of Fremont, Calif., offers another solution. "We've taken three steps to combat the problem. One, we use overly pessimistic constraints to guarantee more slack in the timing. Two, we use floorplanning to minimize unwanted routing. Three, we use prioritized routing for critical nets."

Ambit vs. Synopsys , mano a mano
by Anonymous*

Before going into performance-related differences between Ambit and Synopsys , I'd like to mention some general impressions I have of the two tools. I found Ambit easy to use and applaud their use of the TCL shell for the command language and scripting. TCL provides a powerful and consistent programming interface that makes it easy to write scripts and perform highly automated tasks. I also found that Ambit's shell implementation was more consistent than that of Synopsys ; the meaning of a given command was clear from the syntax.

Ambit also seemed to be faster at managing its design database. I spent less time waiting for reports to be generated, and the tool parsed Verilog files more quickly than Synopsys .

I evaluated Ambit and Synopsys on three sizes of designs

  • small (<10,000 gates)

  • medium (10,000-25,000 gates)

  • large (>25,000 gates)

These designs required high clock rates (66 to 100 MHz) and used 0.5-µm and 0.35-µm libraries.

The small size is typical of the designs that engineers here have been using with Synopsys . Historically, we've found that Synopsys does well with this size of design and had convergence problems with larger designs, although DesignTime has alleviated some of those limitations.

For the small designs, which ranged from a trivial circuit to a bus interface, both tools performed well. Run times favored Synopsys for smaller designs and Ambit for larger ones, while the results from each tool were roughly equivalent in terms of timing and gate counts. Typically Synopsys would synthesize the design in slightly less area--0 to 10 percent less.

For a medium-sized design, I used another existing design as the sample logic. Synopsys [97.01] couldn't synthesize the design in our library to meet timing when given the design and top-level constraints.

Ambit, however, returned a synthesized netlist that met timing and used less area than the Synopsys netlist and did so with less run time than Synopsys required--on the order of two to six times less. For instance, the memory controller took 2 hours on Ambit and about 12 hours on Synopsys 97.01.

For the large design, I used an existing design that had never met timings under Synopsys . Ambit completed the synthesis, met timing, and gave good area results. I'm still in the process of evaluating this design and don't have metrics for Synopsys 's performance. Needless to say, we were impressed to see that Ambit generated quality results from top-level constraints and a single synthesis.

In summary, I have found that using Ambit, I'm able to synthesize larger blocks without having to break up the design and have gotten better run times than with Synopsys . This becomes especially important as we move to smaller technologies and larger designs.

However although Ambit is an excellent tool for synthesis, it's still new and lacks some functionality that would allow it to totally replace Synopsys 's DesignTime. Its reporting capabilities are still lacking, although they seem to improve weekly, and some of the back-end algorithms are just coming on-line. Ambit has been very good about addressing these problems, and I expect the tool will be rounded out sometime this fall.

*A design engineer at a large electronics company who asked not to be identified

While providing reliable designs, Miller concedes that the solution has come at a cost. Increased area results from overconstraining the design, and longer schedules for placement and routing occur as a result of the floorplanning and prioritized routing.

Can floorplanning solve the delay problem? Floorplanning tools have been around for over a decade, yet they've only recently been widely discussed as part of an ASIC flow. We wanted to understand how pervasive the practice has become. To that end, we asked the following: "Have you used floorplanning tools in designs that you've implemented in process technologies below 0.5 µm? If so, have the floorplanners been effective in improving the accuracy of delay prediction? Was there any floorplanner that worked better than others?"

One answer suggests that designers are embracing floorplanners out of necessity. Nettleton says that virtually every ASIC design team at Sun that's been burned by timing nonconvergence on their last 0.5-µm part is jumping up and down to do floorplanning on their 0.35-µm part.

Sun's designers needed what Anders Nordstrom, senior ASIC designer at Nortel Ltd. in Ottawa, claims to have achieved--more accurate wire load models. He says that pessimistic statistical wire load models from the foundry contained delays that were twice the amount found after floorplanning. "In contrast, on average the delays estimated by floorplanning were within 5 to 10 percent of final layout delays."

More accurate delays from floorplanning reduce the number of layout iterations. Bill Cordan, ASIC engineering manager at Symbios Logic in Fort Collins, Colo., reports that his design required only a single place and route followed by some engineering changes afterward.

Nettleton, however, doesn't differentiate today's floorplanning tools based on their ability to accurately predict delay. Her areas of distinction would be ease of use; seamless integration with placement and routing; and finally, quality or accuracy of delay prediction, including quality of RC estimation and delay calculation.

"As we move into 0.25-µm processes and start seeing million-plus-gate parts running in excess of 150 MHz, floorplanners will be increasingly differentiated by their ability to handle the integration of complex chips," she insists. "Hierarchy will be a big deal, as no one will be able to put these mega-ASICs together in one big-bang flat place and route. Clock balancing and power distribution get exceedingly nasty at these sizes and speeds. Flip-chip and area I/O hit the streets at 0.25 µm and make hierarchical chip design a bear."

Another respondent who requested anonymity suggests a similar gulf between the vendor's proposed use of the floorplanner and the user's real application for the tool. "The floorplanner vendor boasted of the ability to link delay-annotated files or generate wire load models that could be used in the synthesis portion of the design, but in reality it was cumbersome and error-prone," he says. "In the future we will move to close these feedback loops, but for the early passes we used the floorplanner to remove variables and constrain our design such that the design process, concept to silicon, was more predictable."

Jean Bou-Farhat, manager of corporate design systems at Symbios Logic in Fort Collins, describes yet another problem with today's floorplanners. "We found that sometimes a floorplan optimized for performance may not be routable. The floorplanning tools have to improve, to add rules and checks that today exist only in the minds of layout engineers."

Most commercially available floorplanners are meant for postsynthesis placement. With the advent of presynthesis floorplanners, we tried to determine how successful designers were in using this type of tool. We asked: "Have you had any experience with a presynthesis floorplanning tool, and if so, has it lived up to its claims, fallen short of them, or failed completely to improve the accuracy of your critical-path timing estimation?"

Integrated Circuit Systems' Paist reports using the Design Planner presynthesis floorplanner from HLD Systems, now part of Cadence Design Systems Inc. of San Jose, to create empty blocks (abstracts) of hard and soft macros before they were implemented as gates or transistors. This top-down approach minimized block interconnections, optimized placement, and identified problems with logic partitioning and hierarchy. "As a result, potential problems were identified early, and they were fed back into the design process," Paist explains. "It's difficult to say if accuracy was improved, since we estimated logic that hadn't been implemented yet. However, the ability to take an early look, route some test cases, and improve wire load models is a plus."

Shortcomings of presynthesis floorplanning Yet most of the people who commented on presynthesis floorplanning pointed to its shortcomings. "My biggest beef with the RTL floorplanners is the basis for their estimation," says Nettleton. "They all rely on synthesis from a generic technology library to do their estimation. If I'm going to synthesize onto these cooked-up gates, why wouldn't I just synthesize onto real gates? Our experience is that this generic technology synthesis is not dramatically faster than specific-technology synthesis and can even be slower in some instances."

RTL synthesis also lacks demonstrable metrics showing that it can accurately predict wire delays. "I haven't seen any data showing the correlation of the RTL-estimated wire lengths to final wire lengths," she continues. "That would go a long way toward convincing me that this was a technology worth taking seriously. In lieu of that, we plan to instead focus on early black-box floorplanning based on synthesized gates and gate estimates. The focus is on methodology rather than estimation technologies."

Robert Maffit, chief technical officer of Prescient Systems, a small company based in San Carlos, Calif., echoes Nettleton's contention. "I've used HLD Systems' PDP and LDP. They help, but they don't influence synthesis enough and there are still major surprises once layout is done."

Mindful that designers were frustrated with the inability of floorplanners to accurately predict final layout timing, we wanted to measure the depth of their frustration. We asked: "Have you begun performing final placement and routing internally, and has this reduced the number of design iterations to achieve the desired timing?"

Symbios Logic's Cordan says that placement and routing is simply an extension of the front-end design flow and floorplanning. The key, he says, is having a dedicated place and route group with expertise in layout. "The latest placement tool offers engineering change order capability that allows timing changes to be made without disturbing the working sections of the design. It can be done faster than initiating a full new place and route. Greater accuracy in the prelayout gate-level design is still required, however, in order to get the most out of this capability. Hence floorplanning is still key."

In contrast, one respondent concedes that the number of design iterations "has increased for deep submicron because of poor floorplanning and poor hierarchical physical verification and place-and route tools. "We need tools for deep-submicron designs that aren't just faster, but contain new algorithms. Tool methodology must change to handle millions of transistors and 3-D layout for verification, parasitic extraction, placement and routing, and floorplanning. Those tools aren't here yet."

We also asked designers doing layout which tools they were using. There was nearly an even split between those using tools from Avanti Corp., Fremont, Calif., and those using Cadence's tools. A couple of users also praise tools from Silicon Valley Research Inc. in San Jose. *

To voice an opinion on this or any Integrated System Design article, please e-mail your message to miker@isdmag.com.


integrated system design  November 1997



[ Articles from Integrated System Design Magazine ] [ ICs and uPs ]
[ Custom ICs and Programmable Logic ] [ Vendor Guide ]
[ Design and Development Tools ] [ Home ]



For more information about isdmag.com e-mail cam@isdmag.com
For advertising information e-mail amstjohn@mfi.com
Comments on our editorial are welcome
Copyright © 1997 Integrated System Design Magazine

  Free Subscription to EE Times
First Name Last Name
Company Name Title
Email address
  Click here for your Free Subscription to EETimes Europe
 
CAREER CENTER
Looking for a new job?
SEARCH JOBS
SPONSOR

RECENT JOB POSTINGS
CAREER NEWS
SRC Expands R&D Centers
The Semiconductor Research Corp has added a new center to its university R&D efforts.

For more great jobs, career related news, features and services, please visit EETimes' Career Center.


All White Papers »   

 
Education and
Learning


Learn Now:












Home | About | Editorial Calendar | Feedback | Subscriptions | Newsletter | Media Kit | Contact | Reprints|  RSS|   Digital|  Mobile
Network Websites
International
Network Features




All materials on this site Copyright © 2009 TechInsights, a Division of United Business Media LLC All rights reserved.
Privacy Statement | Terms of Service | About