Why Some Tools Stick Around

Getting people to change tools or developing environments is like pulling teeth out of a sleeping crocodile. It’s difficult in the best of circumstances, and dangerous at worst.

The problem seems to be one of stubborn attachment coupled with an investment in training that most companies are unwilling to write off. We’ve seen this problem before, and it’s tough to make it go away.

Going back in history, it’s the same reason we’re stuck with a QWERTY keyboard.

The idea behind QWERTY dates back to the 1880s, when typewriter keys used to jam because typists were faster than the machinery. Rather than invent a faster typewriter—something that did happen 70 years later with the IBM Selectric—typewriter makers decided to slow down the typists. Why else would you ever think of putting an ‘S’ under the weakest finger in both hands. The goal was to reduce typing speed by about 20 percent, but once typing teachers had learned the QWERTY keyboard they refused to change. More than 130 years later, we’re still stuck with it.

The same is true of some of the proprietary tools being used by chip developers. While they filled in gaps of commercially available tools when they were first developed, many of them are outdated, klugy or just plain inefficient. The problem is that one group of engineers teaches the next group, and so on. And eventually, no matter how outdated those tools may be, it’s tough to change them out. And if it’s engineering managers who invested time into learning them, they’re far less likely to see the benefits of swapping out what they know in favor of what they don’t know.

In some cases, these tools were developed because the market was too narrow for EDA vendors to make a profit. But tools need to be rethought and re-invented regularly, and budgets for tool development were one of the first things that companies cut, particularly if they weren’t competitive differentiators.

Some EDA tools do offer a competitive advantage. Big companies like IBM and Intel have always developed their own tools for very specific purposes as part of their flows. IBM claims its internally developed tools allow it to get first-time success 95 percent of the time. Intel, likewise, uses its tools to hone its development process and achieve better yields.

Other tools are simply bridges, or they work with outdated processes on older process nodes. And in the worst of all worlds, they work completely in isolation rather than in conjunction with other tools that recognize system-level design needs.

What do you think?