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.

General Digital Integrated Circuit Design Philosophy

This blog has been created to share the experiences and lessons I have learned from a rather long (and growing) career in the IC design industry.

What qualifies me to do this?

I have been in the electronics industry for about 25 years, and have seen a lot of things happen. The last 21 years of this career have been focused on IC design. I have worked in full custom design houses as well as ASIC houses. Approximately 7 of the last 10 years of my career, I have worked as a Consultant for one of the large Semiconductor EDA vendors. During that period, I saw a lot of things. (Many of them, I would like to forget) The first design I worked on was a 100K gate standard cell design, that was considered huge. The current design I am working on is 10's of millions of gates range.

I have seen a some good practices. I've seen a lot of bad bad ones.

Why am I doing this?

I recently read something that said I should blog. So, I decided that I would step into the current millennium. If you get something out of it, that's great. If I get something out of it, that's OK, too.

Whatever, this has the potential of becoming the tome of knowledge/lessons learned during my career.

Why Philosophy?

My general experience is that many problems created in the design industry stem from the fact that designers tend to loose site of the big picture. Oftentimes, they are so focused on the details of the problem that they can't see larger issues. After all, the devil is in the details.

It is true that the devil is in the details, but if the details drag you away from your high level philosophy, this can create some real headaches.

For instance, I recently took a trip with my family. We travelled from our home in Texas to Kentucky. I went to the web and printed out the one page map that showed the basic route. I-30 to I-40 to I-65. This was the high level plan, the basic philosophy of how we would approach the trip. On the way, there were some details. They are called cities. For the cities, I printed out other maps, to help guide my way across.

In general, the requirement when I reached a city was to find my way across it. If I focus on the details, that is, how to get across the city, I could in all probability very efficiently cross each city I come to. But if I do not also pay attention to the purpose of crossing the city, that is the philosophy, the top level plan, this could complicate the trip greatly.

What do I mean: When I get to Nashville, it would probably be easier just to stay on I-40 to get across town. The detail would be completed. I would lobby my family for some extra recognition for the next review cycle. But, the top level plan says I should come out of Nashville on I-65. Now I have to find a way to get from I-40 to I-65, outside the city. This might take hours.

Lesson: Although the straight path through Nashville may be the technologically superior (more elegant) solution to cross the city, and we eventually would end up in Kentucky, there was a much better solution in the context of the big picture.

Other Lesson: I can't forget about the details. There has to be a balance. But, I think that a clear understanding of the over all picture makes the details much simpler to navigate.

Limitations:

My expertise is in the Spec to RTL to Synthesis to P&R realm with some verification thrown in. I am not a custom designer. I am not an analog designer.


The Bottom Line

I hope someone out there in the ether enjoys these ruminations. I will.