viewpoint

It's the Methodology, Not the Design Tools The rush to embrace commercial EDA tools may have left the design flow lost in the shuffle. Pay close attention to the big picture--in particular to compatibility--and not to bells and whistles. by Pran Kurup

As semiconductor and system companies strive to establish a seamless design flow, design methodology has become a critical aspect of the design process. Companies must focus on it, rather than on acquiring and using point tools.

No EDA vendor provides all the tools required for the entire design flow (though the major ones claim to provide "best-in-class tools" and "complete solutions"). Instead, each company delivers point tools that serve specific stages of the design flow. Internal CAD groups across the industry are constantly challenged to develop methodologies that effectively utilize the diverse tools and incorporate new ones as they emerge. Unfortunately, EDA tools from different vendors, and sometimes from the same vendor, don't always talk to each other. (So much for standards.) Thus almost every output from one tool requires some level of postprocessing before it can be accepted by the next tool in the flow. As a result, it has become virtually impossible to effectively assimilate all the best-in-class tools available, and most semiconductor and system companies wind up with an unwieldy concoction of in-house tools, commercial software, and custom just-in-time kludges.

Moreover, design teams must often develop new methodologies on the fly that are often dangerous and can have disastrous consequences on the final silicon. Meanwhile, EDA companies tend to simplify design flows as if they were just mundane block diagrams--using, of course, their proprietary tool offerings.

A predefined, concise, well-documented design methodology that accounts for all the strengths and limitations of existing commercial tools is key to the success of any design project. Further, it's imperative that every design group follow a strict set of guidelines for naming conventions of signals, ports, and file names, as well as for standardized directory structures, effective revision control mechanisms, well-defined optimization strategies, reliable and exhaustive verification techniques, back-annotation procedures, accurate parasitic extraction, and so on. Without those guidelines, designs simply take longer to accomplish and are often error-prone.

The reality on the design side is that there's often a legacy of tools and in-house methodologies that needs to be considered in developing a new flow. It's almost impossible for any design house to instantaneously abandon existing flows for those based on the pretty pictures peddled by EDA vendors. A transitory period is almost always essential in which existing proprietary tools and flows are phased out gradually in favor of new commercial tools.

To have a better understanding of the different tools and methodologies that are used throughout the design process, companies should implement training courses that focus on the overall design flow. Unfortunately, most present-day training courses are very much EDA vendor-specific. Flow-based courses, though, could effectively supplement training courses that largely focus on point tools.

A few words of caution: In general, when evaluating new tools--in addition to checking for all the desired tool features--it's important to investigate all the flow aspects. A tool with fancy features but a poor interface to other tools can be a serious liability to the overall flow. EDA vendors very often repackage "existing tools done right" as new tools that you supposedly can't live without. If you're already using the previous version of the similar tool from the same EDA vendor, it's likely that you've already developed methodologies that overcome its limitations. So you might not necessarily need the repackaged version that addresses the same problems--at least not in the near term. Once the P.O. is signed, don't be tempted to chase the next set of new tools; just plunge head-on into the integration battle and simply make what you've got work.

Pran Kurup is cofounder and vice president of marketing and business development at Bytek Designs, Inc., a Palo Alto, Calif.-based consulting and training services company that focuses on developing Web technologies for everyday design issues. Previously manager of design methodology at Cirrus Logic, he is the coauthor of two books, Logic Synthesis Using Synopsys and It's the Methodology, Stupid!

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

integrated system design  March 1999