eda platform

A Strategy for Linux EDA Success Windows owns office automation, but Linux's strengths on the server side are compelling. Hardware vendors unite! by Steven E. Schulz

Over the past year, ISD has led the charge in an industry debate on the pros and cons of using the Linux operating system for EDA applications. The subsequent outpouring of support for Linux on the engineering desktop has truly been phenomenal, not only in the pages of this magazine, but at industry conferences as well. It's been refreshing, and I'm still waiting for the Linux-versus-Windows NT mud-wrestling matches at this year's DAC. Yet something tells me that the emotional--no, make that religious--fervor may not have the full impact intended. Like a good main course with no dessert, I've been left wanting more. So it's my turn now to stake out a position on Linux, but no emotion or mud here, just business strategy. I propose to define the issue differently--not in terms of Linux versus NT, but in terms of "server-side" versus the desktop. Unix vendors, read on.

Let's start with a little bit of history to set the stage. If you're old enough to remember the early days of EDA, then you might appreciate how our computing environment has come nearly full circle. Twenty years ago, centralized mainframe computers did it all. The designer sat in front of a dumb terminal and ran batch simulations from netlists or (limited) schematic capture. Office automation needs of the day consisted entirely of ASCII text files and Xerox machines. ASCII text was universally used for everything from requirements documents and electronic mail to central information services and text-only meeting transparencies (with foil markers for graphics).

Things improved markedly with the advent of the workstation in the early '80s. Ushered in with great fanfare, the Apollo and Daisy workstations were a huge success. Engineering productivity improved with the adoption of graphics support and locally networked operating systems, although 8-inch floppy disks remained the archival format of choice.

By the late '80s, Unix prevailed for its inherent advantages of reliability and scalability in a multi-user, fully networked environment. Sun Microsystems became wildly successful by leveraging the strengths of both Unix and the network, well characterized by the insightful slogan "the network is the computer." All engineers became fluent with FTP and telnet, happily transferring both text files and schematic databases among each other. During this period, the philosophy was simple: Designers designed on Unix and managers managed on PCs. Of course, during this period Microsoft's Windows operating system flourished in the office as well as in the home, and with it the Word, Excel, and Powerpoint applications.

Then something very significant happened. Someone thought it would be a good idea to merge text formatting and graphical presentation formats with the network (again)--that is, the Internet--and the World Wide Web was born. Suddenly, anyone could effortlessly share information with others--no engineering degree required. With the help of a few plug-ins, even managers could use the power of the Net for exchanging and viewing all of their office documents.

This development started yet another paradigm shift, as the traditional lines of distinction between engineers and managers continued to blur. Job grades and geographic boundaries alike became irrelevant for work groups connected on the Web. Soon, everyone was expected to share documents developed in PC-specific applications, creating a new chasm. PC formats flourished with their vast majority in numbers, placing the full responsibility on Unix users to find ways to make up the difference or be ignored altogether.

So what does the current situation have to do with Linux? Everything! The desktop needs of engineers have clearly changed, and despite Windows emulation software (like WABI and WINE) or remote application servers for Unix (such as Wincenter or Winframe), the direction remains very clear. Compatibility with native PC file formats and PC applications continues to grow as a corporate productivity issue. Work group software is on a dramatic rise, particularly for automated conference scheduling and time management systems.

Of course, PC workstations can be rebooted between Windows and Linux, but that's an awkward patch solution at best. Although there are some signs of encouragement for additional applications supported under Linux, it's unrealistic to expect a high level of office automation compatibility. Moreover, although WINE offers hope for running some Windows applications coexisting on Linux, it can never keep pace with the rate of change at Microsoft (by design, I suspect).

Let's now return to our history lesson on server-centric EDA. The job of electronic design has become so complex and CPU-intensive that we're seeing most high-powered EDA applications migrate to workstation servers. That's happening despite the fact that most designers are sitting directly in front of their own Unix box. These expensive servers offer more gigabytes of memory, parallel processing using multiple-CPU configurations, and shared resources for redundant disk arrays and hardware emulation. Since Unix and Linux are blessed with the X Windows environment, and since even Windows 95 is sufficient to run stable, high-performance X server software, a solution to this dilemma becomes apparent. The engineering requirements for a reliable and scalable operating system and the increasing need for office automation integration can be met with a combined server-desktop strategy incorporating the best of both.

Now we focus on the real objective, which is support for mainstream commercial EDA vendor tools for Linux. The level of customer support needed to construct complete design flows requires major purchases by large corporations, not just by small design shops. Yet achieving corporate backing requires that Linux be consistent with all corporate initiatives and expectations. As I discussed earlier, a major and relevant goal of today's popular corporate initiatives is desktop office integration. I also made the case for why corporations assume an operating environment executing Windows applications, directly accessible from the desktop. However, let's consider the firm requirements of EDA applications, which by their very nature demand more expensive resources that scale better in a server environment.

If we concede that the corporate engineering desktop is destined to run Windows and that EDA applications require the robustness of Unix, then why Linux? The truth is, there are several good commercial implementations of Unix available that satisfy the core requirements for EDA--as evidenced by the current marketplace. However, only Linux runs on every major hardware platform, including Intel-based PCs. This represents a tremendous opportunity for consistency, with reduced EDA development and maintenance expenses (not to mention leverage against Microsoft). I've found, though, that Linux has far more going for it than is generally discussed. Advantages include ease of initial installation and the use of a superior "package" implementation, like RPM, for easily managing additional operating system and application software components. Linux offers multiple state-of-the-art, high-quality desktop environments (such as KDE and Gnome), which in several ways put old CDE to shame.

Let's not forget one more item--it's freely distributed. For some, this feature may be perceived by corporations as a disadvantage, as it implies a lack of accountability and support. In fact, support is widespread, leveraging extensive documentation on the Web and complete technical support available from such companies as Red Hat, Caldera, and Debian. A more valid criticism might concern accountability for rapid turnaround on software patches, since development has been so broadly distributed. Nonetheless, Linux has proven itself to an estimated 8 million users as a highly stable and secure environment for the most demanding applications.

So my proposal boils down to this: The strengths of Linux really play more to the server side of EDA, where reliability and scalability are critical and office integration isn't. The desktop needs for office integration and application interoperability are well served only with a native Windows operating system on the desktop. This arrangement generally works well with X server software as the portal into stable, scalable Linux. Office integration needs, including mail attachments, work group software, ZIP'ed files, word processing, slide presentations, and spreadsheets, are best handled on the local desktop. There may be the rare desktop mail attachment usable only under Unix, but in those cases FTP bridges the gap reasonably well.

Linux offers the EDA world an opportunity for convergence. Rather than having different installation procedures, shared libraries, and make dependencies for Sun, HP, Compaq, and IBM (with no support for PC-class workstations), Linux offers a renewed chance for Unix to compete in a Microsoft-centric, multimedia world. My message to Sun, HP, Compaq, and IBM is simple: Unite for strength! Any kernel modification required for high-end hardware should be derived from a common Linux base.

Having a common operating system and desktop environment across those platforms would be attractive to corporate users and EDA suppliers alike. After all, it's well known that CDE has been stagnant for years and is falling further behind both Linux and Windows. Since Linux already exists for those vendors' hardware, the EDA user community can take it upon themselves. However, where this strategy makes sense, I urge readers to contact their workstation suppliers directly.

I made this recommendation in an interview with Red Hat Software and in discussions with others in the Linux and EDA communities, and I believe it was very well received. I also believe that, as the EDA tools migrate to 64-bit operating systems, Linux is well-positioned to make inroads with corporate users and EDA suppliers alike. I have little doubt that Windows NT will continue to improve, so the prime opportunity for Linux to succeed in EDA will likely be over the next three to five years.

Sometimes, winning the war takes more than passion: It takes good marketing analysis and a focused action plan. The issue is not whether engineers like Windows NT. The objective should be the success of Linux for commercial EDA, to the mutual benefit of both. Let's move beyond debate, lest the war be lost before the battle has even begun.

Contributing editor Steve Schulz is a senior member of the technical staff in Texas Instruments, Inc.'s Worldwide ASIC division in Dallas. He serves as president of the board of directors of VHDL International and is the executive sponsor of the System-Level Design Language.

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