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.