Clocks are your friend

I once went to help a design team with their Static Timing Analysis of a chip. When I got there, one of the questions they asked was, "Could you write a script to tell us which clock domains talk to which other clock domains?" At that point it was all that I could do to keep from running from the building.

Why is that? Because, clocks are at the heart of digital design. If you don't understand the clocks, you don't understand the design. A good design team should be able to tell the guy doing the STA exactly which clock domains cross, exactly which signals cross those boundaries, and exactly what design practices have been utilized to make sure that the clock crossings are handled correctly. They should also have thought about how they are going to time those interfaces. Oh well, I guess teams that have their act together don't usually call in the consultants.

What are some suggestions?

Write a Specification

I have talked about this in the past. The point is still valid. You should have a good specification. One of the most important parts of the specification is the clock section. All domains and all crossings should be documented and detailed.

Limit Domains

I have worked with chips that have had about 50 different clock domains. I have worked with chips that have one. Let me assure you the chips with one are a lot easier to work with. I also have to confess that chips with a single clock domain are of limited interest in the market place.

I sometimes think that architects do not go into the design with the concept of limiting the clocking complexity. If you have to have multiple frequencies, limit transitions. Can the transitions all be handled at the periphery of the chip, that is the I/O? Can the core run at a single frequency?

Synchronous Domains

When you have separate domains, can they be treated synchronously? Can you limit the domain crossings so that one is a multiple of the other, so that they can be timed synchronously?

Even if you don't have asynchronous domains, can you pretend? What do I mean? For instance, if you have one domain with a period of 2.0 ns and another domain of 2.27 ns., can you time them at 2.0 and 2.2 ns. The reason for this consideration is that the static timing analysis tool will expand the clocks until they synch. If you use 2.0 and 2.27, the clocks will expand about 200 periods and give up trying. The result is that your static timing will be more compute intensive. If you use 2.0 and 2.2, the clocks will sync after 22 ns, which is a lot less compute intensive. You do need to make sure that this relationship does not mask errors. That is, the closest these clocks will be is 200 ps. In tral life, they are truly asynchronous. Does that allow some signal to sneak through unnoticed? This is unlikely, especially if you have any clock uncertainty. But, you should be aware.

Limit False Paths

Just for the record, I hate false paths. I know that they are necessary sometimes, but there are a couple of issues to be careful of.

First of all, do not use false paths liberally, such as setting a false path from one clock domain to another. Why? Because this habit can mask problems. For instance, you have a data bus that crosses from clock A to clock B. You have created an elaborate FIFO scheme to assure that there is no clock boundary issue with the data bus. You set a false path between the domains. But, you forgot about a control signal that is sent across the boundary. You will never see a problem in STA. Depending on your verification environment, you may not see a problem in functional testing. A better solution would be to set false path for the data bus specifically. If there are no other clock crossings, it will work. If there are some you forgot about, they will get flagged.

Another issue with false paths is that if the constraints are used for synthesis or placement, you could end up with a registers that talk to each other at far ends of the chip. It might be better to use a multicycle path, or specify placement boundary to assure that a reasonable placement takes place.

Your Friend

In my experience, teams that understand their clocking, have their acts together. Those that do not understand, do not have their acts together.

Ultimately the clocks should be your friend. You should get to know them.

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.