I Don't Know What You Do - It Must Be Easy

Not long ago, I had the opportunity to entertain an analog designer from another organization. He would be coming to our office for training on digital design techniques. He would spend the morning with me for me to train him how to do the front end standard cell flow.

My first reaction was one of deep indignation. How was I to train him to do something that I have spent the last 20+ years learning how to do, in about four hours. When I calmed down, I decided we could at least do an overview of how a typical flow takes place.

So, in a short four hours, I discussed hardware descriptor languages, simulation, structured design techniques, synthesis, test insertion, logic equivalence, static timing analysis, automatic test pattern generation, back annotation, and probably some other stuff. By the time I got through, he said, "I didn't realize there was so much to this."

This event called to mind an idea that I have mulled over for years - We tend to marginalize the jobs of people we know little about. Some examples:

1. How many times have I said something like, "It's just software. It must be easy."
2. I once worked for a company that had a peer review system. It was a two tiered system. One tier for those who worked closely with you. The other for those who were acquainted with your work. The votes for those acquainted with my work always tended be much more "average."
3. The concept in modern business practice of the generic "resource."

A disturbing trend during the current economic downturn seems to be to lay-off the experts because they cost so much. I think this shows corporate America's marginal view of the expert.

'Nuff said.

Comfort Zone

I am convinced that one of the major impediments to improvement in the industry is inertia.

Engineers are like much of the rest of the population. The tend to want to stay where they are comfortable. A couple of examples:

I worked for a company in the early 90's that was a full custom house. It became obvious that the time to market requirements would not support that style of design, and so the organization transitioned to standard cell methodology. There was resistance from many in the organization that thought, "This will never work." The leaders who were pushing this new philosophy were demonized in the trenches. Many engineers were drug kicking and screaming into a new design paradigm. Ultimately, the result was a successful product line which could be modified and retargeted much faster than a full custom design.

More recently I was in an organization that built a DDR interface. The design team custom built a bit lane. I suggested that they could save a lot of time if they use an automatic place and route tool to connect the bit lanes. The response was that the would lay it out by hand. Why -- Because they knew how to do it that way. The result: The part taped out. But it took much longer on that interface than necessary. Additionally, the learning that could have taken place in that exercise has been postponed. So, the next time the team works on a similar interface, all the barriers to improved productivity will still be in place. The sort of thinking that took place on that device could ultimately drive that organization into oblivion. Oh, by the way, that part taped out in 2007.

So, in general, processes do not improve unless they have to. Some reasons why they might have to:

1. It just doesn't work. People don't do the same things at 45 nm that they used to do at 0.5 micron, because the same things just don't work. An aspect of this is the existence of constantly changing requirements. One of the big drivers in the past has been time to market. Speed and power have also been big drivers. After all, necessity is the mother of invention.


2. Obsolescence. Tools have morphed over the years. I cannot do the same things I did 15 years ago, because the tools have changed. For instance, Design Compiler does not support dc_shell scripts. They have moved to tcl. There was a cry that went out from the design community when this happened, because much of what they were doing became obsolete. But in one way, Synopsys did the industry a great favor, because it forced the industry to revisit how they did things.


3. Visionary. There is a balance between getting products out the door and trying out new things -- between the grindstone and the ivory palace. An organization needs someone who sees the big picture and pushes the design teams out of their comfort zone. Since I have mostly been a grindstone kind of guy in my career, sometimes the visionary types really irritate me. But the truth is, we need them.
   

The real trick in all this is to find the balance between reuse and innovation.