It's the Spec Stupid

I once showed up on a customer site to assist in a design. The manager told me that the plan was to tape release by the end of the month. The next thing that he said was that the updated specification would be available by the end of the day. My knee jerk reaction was that there was no way that they would tape release the chip by the end of the month. If the definition of the chip is changing, the tape release could not be near at hand. The actual tape release was about 6 months away.

The disturbing part of this story, is that this specific design team had its act together a lot better than most design teams I had dealt with. There was a specification. It was being updated.

The concept of a specification is deeply embedded in the design process. So much so, that it often gets ignored. One of my favorite interview questions is something like: "Marketing has brought the design team a list of requirements. They want you to build a widget. What are the steps that you take to do that?" It is a great question, because people will focus where their expertise lies. RTL people will focus on coding and verification. Synthesis people will focus on the RTL to gates process. Back end guys will focus on the gnarly details of LVS, DRC's, and GDSII. Almost no one mentions the specification.

The most fundamental mistake I have seen design teams make is that they fail to do the due diligence required to put a comprehensive plan in place before they begin coding RTL. In the few cases where there is a comprehensive plan, the teams do not "have the time" to go back and update the specification when in the process of debugging or implementing the design, they find that there is a deficiency or discrepancy in the specification. The result is that as the project progresses, the design tends to diverge from the original plan, and no one knows what is going on.

The standard disclaimer: Many of these instances I observed while working as a consultant. In general, people do not hire consultants if things are running smoothly.

A general observation: Things tend to run smoothly for teams with a disciplined approach to their specification. Things do not for teams that do not have a good spec.

Why are Specifications Neglected?

This is only my opinion, but I think these are a few of the factors:

1. Specifications are not fun. You have to wade through a lot of details and fight with a word processor to produce a good spec. It is much more fun just to dive into the design.
2. Engineers don't see this as real work. It is an administrative duty.
3. It is not necessary. I know how to do this. I worked on the last chip.
4. Job security. (No! No! We are all more professional than that!)

I think that the third item above may be true. The problem is that there is usually more that one person working on the chip, or interfacing to it. They do not know what you are thinking.

What needs to go into the Spec?

There needs to be a top level description of the chip, that is, what is the goal of operation. This should include general top level diagrams that include data flow. It should include the overall philosophy for things such as test, reset, and clocking. It should also include the a list of pins and a description of the I/O of the chip.

The block level descriptions are as important as the top level. Each of the blocks themselves should be described functionally. This is the fun and easy part of the spec. What really gets nasty is a detail description of how this block communicates with the rest of the chip. This means that each of the interfaces and pins of the block must be described and detailed. What is the protocol? Is this streaming data? Is there some sort of hand shake or enable? Is the interface synchronous? What are the clock inputs? Are there multiple clock domains?

From a functional perspective, the really important parts of the specification include description of interfaces. But, don't forget the poor soul who has to implement this thing. Provide that person with any information that would help with floorplanning. Be sure and clearly define clock domains or any special test considerations.

In general, there are two important types of information to transmit:

1. Information that describes the work I need to do, so that if I get run over by a bus, the project can continue.
2. Information that other people need to interface to or implement my work.

Finally, when you fix the design, fix the specification. Don't let the two diverge.

Tips:

Be the first guy to finish your block specification. That way you get to drive the interfaces on the design.

OR

Be the last guy to finish your block specification. That way all of the interface definition work will have been done for you.