Issue 160 November 2003
Timing (Analysis) is Everything
A How-To Guide for Timing Analysis

---

AUTOMATIC CAD TOOLS

ASIC designers have been using static timing analysis tools for a long time. Synopsys’s Primetime is an example. The tools go through the entire design and determine if there are any timing violations (with some constraints from the user to minimize false paths). There are static timing analysis tools for board-level design, as well (e.g., BLAST, which was developed by Innoveda). These tools generally cost significantly more than Timing Diagrammer Pro and Timing Designer.

What if a tool shows that you are in error? Is this always true? You may say that timing analysis is too pessimistic and, at times, you may be right. For instance, if the elements in the simplified circuit depicted in Figure 1 are in one FPGA, it is less likely that the data path will exhibit a maximum delay and the clock path will exhibit a minimum delay. This is because they are in the same part, and delays on a chip tend to track each other. The data path may be at the maximum delay but the clock delay will be too. For most other cases, however, it is best to use worst-case timing numbers. 

A PROBLEM SOLVED

At a former employer of mine, we had a problem with a card we were working on. We couldn’t write to some of the address space in one of our ASICs on a new spin of the card. So, after playing with the software to make sure that it was not the cause of the problem, we hooked up the logic analyzer to see what was going on. At first glance, the timing looked fine, and we scratched our heads. But just before we went home late that evening, one of the ASIC designers said that he found it funny that the first write cycle that had worked was the only one that worked. It would have been nicer if he had mentioned that earlier!

When we returned to the lab the next day, we concentrated on looking at the second and subsequent write cycles. One of the control signals to the ASIC was rising at the same time as the clock. Our hypothesis was that the timing wasn’t OK.

We decided to try moving the clock signal in time by delaying the clock. We initially did this by adding a long wire to the clock signal. As a result, the write cycle worked! Well, it mostly worked. Next, we used a footprint-compatible buffer, which was slower and seemed to work well enough for the card to be used by the SW developers and other testers to continue with their work. However, it didn’t explain exactly what was wrong. Why was the control signal so close to the clock signal? Why hadn’t we seen this on the previous version of the card?

We went back to the timing analysis for the previous version of the card, and it showed that there shouldn’t have been any problems. On closer inspection, however, we noticed that the analysis was done to the wrong clock edge. When the timing analysis was changed to the correct clock edge, it immediately flagged that there was a problem.

Why wasn’t there a problem with the previous version of the card? After talking to the software folks, we found out that the same write cycle on the previous version of the card didn’t work either! They had found a way around it, so they didn’t complain too loudly. At that point, we knew that we had a problem that needed to be solved on both circuit cards. The problem with the timing in the circuit was that the clock was being delayed quite a bit because of the load on the clock. The new version of the card added two more loads to the clock line, which, in turn, caused the clock to rise more slowly and arrive coincidently with the control signal.

We looked at the buffer and found another part that was a zero-delay buffer, which meant it had a PLL in it to synchronize the output clocks with the input clock. We put the timing numbers from the new part in the timing analysis, and it worked. We then dead-bugged the part on the board, which was not an easy feat with a number of BGAs. After we had solved a few other problems with the ASIC, the board worked.

Photo 2 shows the timing analysis for the circuit with the old clock buffer. Photo 3 depicts the timing analysis with the zero-delay buffer. (I used Forte Systems’s Timing Viewer, because the analysis was performed in Timing Designer.) 

(Click here to enlarge)

Photo 2—Note the width of the Board Clkout signal. This is the result of it being an ordinary buffer that is heavily loaded on the board. Again, red indicates a timing violation.

 

(Click here to enlarge)

Photo 3—I used a zero-delay clock driver. The area of uncertainty on this clock is significantly less than the Board Clkout signal in Photo 2. Notice the lack of red this time. It works!

CONVINCED YET?

I hope I’ve convinced you of the importance of timing analysis, which you can now perform manually or with a semiautomatic CAD tool. Remember, whether you have a design running at 1 MHz or 1.5 GHz, timing matters!