Exceptions Should Not Be the Rule

As technology has expanded, creating increasingly more complex designs, design flows have remained relatively static. We have been doing the RTL, synthesis, place and route, flow for 15 or so years. There are little tweaks to the process that come along, such as physical synthesis, but radical wholesale changes to the flow have been quite rare.

For instance, one of the Holy Grails of design, that remains elusive, is a higher level of abstraction. There are tools out there that exist, such as System C, but as far as I can tell, their use is limited, and their acceptance is dubious.

What has changed is capacity. The first standard cell designs that I worked on were in the 100K gate range. Now we are looking at 10's of millions of gates.

What is my point? Simply this: as complexity and capacity increases, the ability to handle oddities decreases. This is simply because as the capacity for design size increases, our capacity to handle oddities does not, because they must be addressed individually.

Sure, there are ways to do anything. You can throw in asynchronous logic, or cross coupled gates, or latches, etc. You can put false paths and multicycle paths into your timing analysis. But every time you do something strange, it requires specific consideration. It also has a ripple effect. It affects timing, test, synthesis, and layout.

There is a word used in this business for oddities. They are called exceptions. The implication is that they are "exceptional," that is, out of the ordinary. These exceptions should continue to remain out of the ordinary.

Don't get me wrong. I am not saying, "Don't do anything exceptional!" I once worked for a company that decided they would not do anything unusual. They produced a design that was single clock, single edge, synthesized design, with no exceptions. That was one of the most insipid devices of my career.

At the same time, your exceptions should not be the rule. I once consulted for a company doing static timing analysis. The "exception" file for their device was over ten thousand lines long. It grew to over twenty thousand. We spent a lot more time handling the exceptions than the rest of the design. The number of exceptions also meant that no one really had a good grasp of the situation.

In general, tools do not like exceptions. Whether you want to admit it or not, our design process is largely tools dependent.

So what am I suggesting:

1. Understand clean structured synchronous design. This should be your goal. By the way, if your testability tools like it, it is probably OK.
2. If you are tempted to do something flaky, think again. Be creative. Many times there is a better way to get done what you need to get done.
3. Isolate the exceptions. Put clean boundaries around them. Limit the impact to the logic around it.
4. There are times when you need to have an exception. Limit their number and influence. Understand them. Document them. Make sure everyone on the project knows about them. If there are too many to keep up with, there are probably too many.

Test is not an Afterthought

This may not seem like an important subject to many designers. It is precisely because of this attitude that it is such an important subject. It seems important to me because almost invariably, every project that I work on is cursed at some point by some big brouhaha that boils up around the subject of test.

When I began in this business, test was an afterthought. If you cared at all about fault coverage, you fault graded a part. This consisted of writing a bazillion test vectors and running a bazillion simulations to find out what was tested and what wasn't. It took man years to test parts of any great complexity.

As part complexity increased, all of the sudden, you had to write hundreds of bazillions of vectors and run hundreds of bazillions of simulations. Then DFT entered the scene. Instead of having to invest all of that time and effort, all you had to do was to let the tools do it for you. The problem with this was that it greatly influenced the design practice.

In 1988, I went to work for a large company that built microprocessors. Those were fun times, because anything went. You could cross couple gates. Tri-state buses went everywhere. We had dynamic logic. The design style at that time was to have non-overlapping clocks and use latches.

Sometime about then, a team decided that they would start using this neat new scan methodology stuff. They utilized the same practices they always had, but they also added a slave latch to all of the functional latches to create scan flip-flops, and chained them all together. The result was a scannable design. The difficulty was that much of the design was not controllable, so the scan coverage on that device was about 6%.

Things have improved greatly over the years. Design teams use structured design styles. We understand testability a lot better. But we still get stuck with test issues at the end of the project.

I think there are at least two reasons for this:

1. Test touches everything. It typically touches every register in the device. It affects how you generate your clocks. It affects reset. It affects I/O. There are additional timing constraints and analysis that are devoted to testability.
2. Everyone assumes it is easy. Nothing in this business is easy. If it was, they would have hired a monkey. It is especially not easy if you don't think early about it.

So what do you do about it? Here's my short list of test stuff:

1. Start early. Hire someone who knows what they are doing. At least make someone on the team responsible for test - from the beginning.
2. Define it in the specification. How are you going to multiplex clocks? How many scan chains? How do you control test modes? What is happening to reset during test? What fault models are you going to use? What is your coverage target? How are you testing macros, such as RAM's or register files? Is there embedded IP?
3. Keep an eye on test during the design. If you have a goal of 98% coverage and the tools tell you a block is a 63% coverage, you need to understand why?
4. Treat the test signals with respect. Scan mode is a high fanout net. It probably needs special attention, like clock tree synthesis. Look at the test signals at the top of the design as early as possible.
5. Don't wait until the day you are supposed to tape out to look at test timing. And, don't wait until after you have tape released to run the ATPG tool.
6. Treat your DFT engineer with respect. Remember, it only looks easy. And besides, if he gets ticked off and leaves, you will have to do it.

So, test is a necessary evil, unless you want to write bazillions of functional vectors. DFT actually saves time. But you should think about it - early.