Advertisement

Zibb

Ron WilsonEDN Executive Editor Ron Wilson explores how IC design teams really work: the struggle for power efficiency and performance, wrestling with semiconductor processes and design methodologies, the challenges of global design teams. How do we somehow herd architecture, IP, design and verification into a successful tape-out?



   Advertisement

Profile

RSS Feed

  • Add this blog to your RSS newsreader!

Recent Posts

Recent Comments

Most Commented On

Archives

By Category

Blog

Monday, March 16, 2009

Synopsys Lynx updates Pilot approach to managing an IC design flow

Mar 16 2009 12:00AM | Permalink |Comments (0) |


Synopsys today unveiled Lynx, a package of software intended to help automate the execution, oversight, and management of chip design flows. Like its predecessor Pilot, Lynx is not a design tool or a flow, but a package of recommended flow, database, supervisory tools and services intended to improve productivity—and by the way, make it easy to decide on a turnkey all-Synopsys tool set.

As described by Synopsys VP of professional services Glenn Dukes, Lynx comprises four elements: a management cockpit, a runtime manager, a foundry-ready system, and a production flow. The most familiar of these would be the production flow, which is simply a collection of synthesis, physical-design, and analysis tools based on the Synopsys recommended RTL-to-tapeout flow for 45 and 32 nm, but of course it is adaptable to customer needs and tool preferences.

The foundry-ready system is a bit more difficult to explain glibly. You could say it is an interface package that binds a set of foundry libraries, tech files, and hard IP macros to your design flow. This appears to be done through a set of file converters to get things into the formats and naming conventions the Synopsys tools are expecting, completeness checkers to make sure the flow isn't going to stall because of a missing view or file, and apparently, some degree of consistency checking. You can use the package at the beginning of a design, or any time a change comes in on the PDK or from your hard-IP vendors.

The remaining two modules are supervisory tools. The runtime manager is kind of a cockpit for execution the flow. Using interactive Web screens it allows you to set up a flow via flow diagrams, to control and monitor execution of individual tools on a particular data set, and to manage the associated set-up scripts and switches. This latter point seems particularly useful, in that the tool gives a graphic way of comparing switch settings between tool runs on different blocks, on the same block at different times, or against department standards. There is also provision for viewing run logs and interactively executing the individual tools, giving the user a fair amount of run-time debug capability.

Finally, the management cockpit pulls together the current states of the blocks in the design so that someone with ultimate schedule responsibility can see whether it is time to relax, to call in a consultant, or to polish the old resume. Using an SQL database to which all the Synopsys tools automatically contribute, this cockpit gives Web-based graphic views of important design metrics such as area, power, timing slack, and test coverage. There is extensive flexibility for configuring graphs or reports, and ability to bring in historical data and data from other designs.

Dukes suggests that the management cockpit in many ways can function like a weekly design review meeting, but on demand, instantly bringing together the status information from all the working groups in one format where everyone can see it. He doesn't venture that the tool can replace the steering meetings, but he does say that can shave an hour per team-leader off the task of preparing the data for them. And it can avoid the wrong person getting surprised during the meeting. These capabilities seem particularly attractive when there are several design sites scattered around the world, all working on the same tapeout.

A couple of interesting points about the overall system. First, Lynx is intended for an hierarchical design style, so it recognizes the notion of independent blocks, and the important distinction that some blocks may have different flows than others. This part is vital for one of the features: the ability to have custom sub-flows for particularly demanding or unusual IP such as ARM cores. ARM is, in fact, working with Synopsys on this point. Another point is that there appears to be no explicit provision for analog or mixed-signal design in Lynx, except that analog blocks will have their own distinct flows and this is acceptable to the hierarchy. It is not clear how well, for example, the SQL database and the design manager are integrated into Synopsys's Custom Designer tools, or for that matter exactly analog design tools could report to the database. Lynx is really about the RTL-to-GDSII portion of a modern mixed-signal chip design.

Another important point is that Lynx is not intended to be a one-size-fits-or-else solution. Synopsys is happy to make Lynx available as a turnkey package, doing the equivalent of a forklift upgrade to your methodology. Or for a fee, they will be happy to adapt Lynx to your particular choice of tools and methodology. As a third option, Synopsys can drop Lynx into an existing shop simply as an RTL-to-GDSII subflow. Just how much the pre-integrated Lynx database, cockpits, and monitors can help, and how much they duplicate the tools that many design teams have already implemented for themselves, is an individual decision.


Related entries in: Digital ICs | EDA | 


Post a comment



Display Name

Change Image
Before submitting this form, please type the characters displayed above.
Note the letters are NOT case sensitive.


ADVERTISEMENT

©1997-2010 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites