A design house details why it's found that Windows NT isn't as effective as Unix as an EDA platform.

FEEDBACK

Dear Editor:

Your recent Focus Report on Windows EDA tools [October, p. 40] seems to imply that Windows NT is an effective substitute for Unix as a design automation platform. We have found that it isn't true in our shop.

As a small design house, we are always looking for a more cost-effective method of EDA than the Unix status quo. Our search has given us years of first-hand experience in the use of EDA tools with Windows NT. For design projects involving more than one engineer, our PCs running Windows NT just don't pass muster.

The NT EDA user environment offers us neither satisfaction nor security. We own several mainline EDA applications that fail routinely under NT, often under uncertain circumstances. Many failures cause unrecoverable system crashes. Reports of NT's security holes further reinforce our perception that the NT OS is just too labyrinthic to rely on for an EDA backbone.

My partner describes the situation beautifully: Unlike Unix, he says, NT "knows" that it is smarter than you are at every turn. All basic underlying mechanisms are hidden. When NT fails, there's often no recovery, no indication of where things went wrong, and usually no way to find out how to prevent a recurrence of the problem. Often, our "solutions" are nothing more than behavior modification, because the last time he tried one, it crashed NT.

As Unix EDA users, we found that 6 to 12 months of hard study in network administration gave the student enormous control and understanding of Unix and its connection to the application software. In contrast, after years of work using and developing NT applications, we simply get more and more confused about the intent and mechanisms of NT (which change with each release). An NT EDA system and network are simple to set up, but perhaps impossible to master.

Our NT users struggle with problems and issues that lend a perception that this system, although exceedingly complicated, isn't up to snuff for big-project engineering. NT doesn't export graphic processes. Job control and process threading on the network are, at best, hit-or-miss propositions. Even with more security, a typical Unix network is more flexible.

Hardware is also a part of the problem. Although a number of PC manufacturers build very good equipment, the average PC isn't built to the same standards as a Sun or HP workstation. All together, our experience has led us to believe that a "typical" EDA environment built around Windows NT PCs will be less stable, flexible, and useful than an EDA environment built around a comparable Unix network.

Regarding network administration costs, we've found that the long-term costs of keeping a coherent NT network running are comparable to Unix network costs, not a penny cheaper. That's a moot issue, though: The big cost is EDA CAD staff overhead, and that's the same in both cases. Our hardware budget is unchanged because the PC configuration labor costs usually completely eat up the differential in the hardware costs.

Please note that we will continue to use NT-based PCs, because some point tools are cheaper in the PC world. I wish Intel all the best in its quest to encourage Windows NT EDA tool development, but our experience leads me to believe that the people who design Intel's leading-edge processors will likely camp out in their cubicles, chained to their Unix boxes, rather than allow their administrators to trade their coherent Unix EDA network for one based on NT.

Brad Martin
North Shore Circuit Design L.L.P.

Corrections
Several companies were omitted from the Windows EDA Focus Report table:
FPGA and CPLD design: Actel Corp. (Sunnyvale, Calif.), Designer Lite; and Minc Inc. (Colorado Springs, Colo.), PLDesigner-XL
Simulation: Quickturn Design Systems Inc. (Mountain View, Calif.), SpeedSim, which has been added to the on-line version of the table

In addition, MyChip Station from MyCAD (Sunnyvale, Calif.) should have appeared under "IC Layout."

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

integrated system design  December 1997