Is tool pricing a red herring or substitute for other issues? No one would accept a car or house where the doors and windows only open or close under specific conditions. Most houses and cars have fairly clear operating characteristics, as well as commonly accepted user interfaces and standards for functionality. But some houses are different. Sarah Winchester, the heiress to the rifle company fortune, moved to San Jose and started to build a house in the 1880ýs, now known as the Winchester Mystery House. She believed that as long as the house was still under construction, she wouldnýt die; she continued to build for upwards of 40 years. The house has a multitude of rooms and many architectural oddities, such as a room designed for entry only (no doorknobs on the inside of the doors). Some of the stairs donýt go anywhere and some doors open to walls instead of into another room.

In some ways, EDA software is like the Winchester Mystery House. The need for more functions and capabilities causes tools to require more complex interfaces, interfaces that are badly handled currently by command-line interfaces and pull-down menus. The tools seem to have a general set of operating conditions which force users to tolerate inconsistent user interfaces, cryptic error messages, and an overall lack of interoperabilityýwhile still claiming to work to available standards. Some companies seem to delight in being different. Recall, Daisyýs Dspice used an emitter-collector-base node description, while everyone else was using an emitter-base-collector designation. Yes, Dspice was Berkeley Spice compatibleýthat is, after you renumbered all of the base and collector nodes, and needless to say, we no longer have Daisy to kick around.

The ever-increasing complexity of tools makes for strange operating conditions. To overcome some of the difficulties, engineers write long, complex scripts to automate the setting of the internal variables. These scripts do automatically run the tool, but also fix the operations into a single mode, possibly excluding some of the newest features in the tools. Some companies, to prove they are on the leading edge of design, wonýt accept any software that isnýt delivered by two application engineers, who bring two or three 3-inch binders of known bugs and workarounds with the CDs, and the expectation of at least two days of installation effort. These people delight in trying to figure out how to use the deeply buried features and special functions within the tools. Other companies, possibly more mature, wonýt accept any software that does require an AE to install it. After the software is installed and working with the rest of the tools in the system, the users then take up to 9 months to learn how to use it.

Because of the complexity and the fact that engineers will never accept a one-size-fits-all design structure, all tools must enable some amount of personalization. The tools perform difficult and complex work, true, but that doesnýt require or excuse the tool vendorsý poor user interfaces. An acknowledgement of this generally poor user interface design is the increase in tcl/tk (terminal control language), which allows users to customize and personalize the user interface. This trend is even starting to apply to some of the highly criticized Windows tools. Although we continually hear the engineering community denigrate Windows, and almost any tools that run on Windows, the reality is that most Windows programs donýt require massive hacking of the operating system to set mutually exclusive software switches (as required by the application software vendor) to work together. This arrogant attitudeýthat the software vendor is the one to determine the optimal settings for system-level environmental variablesýdiscourages tool interactions and interoperability. Why canýt vendors set up the tools to work within a default environment and allow the users to change the variables within the tool?