Timing Closure And Denial

By Ron Craig

I live in a reasonably remote area—defined as more than 10 miles from the nearest Starbucks. Given that I spend a fair amount of time driving, I’m conscious of things like safety and mileage. One thing that has a big impact on both is the health of my tires, and after having a recent replacement set installed I noticed that my ‘local’ tire shop offered things like regular re-inflation, pressure checking, etc. As tempting an offer as this may be, it struck me that there’s somehow something not right in driving more than 15 miles to have the pressure of my tires checked. Wouldn’t it instead make more sense to check them myself before I even emerge from my driveway, avoiding the risks associated with low pressure or bad wear before they really become a problem and prevent me from even reaching the tire shop?

A similar thought came to mind recently as I reviewed the results of a user survey on timing constraints, focused on how they are handled and the issues they cause. Across design teams in more than 30 companies worldwide, it was surprising to see that although more than 90% of engineers admitted regular problems with timing constraints (resulting in tapeout slips and even silicon failure), 70% simply resolved to try harder the next time around and keep using the techniques which were clearly failing them up to this point. It’s also interesting to note that roughly 70% of users rely on their existing back-end tools to point out any mistakes in their timing constraints. They put trust in these tools like I could put trust in my tire shop, but this means putting up with considerable (often undetected) risk on the way there.

The solution in my case is to use a reliable, hand-held tire pressure gauge coupled with some visual inspection. But is there a ‘hand-held pressure gauge’ for timing constraints? Even if there is, there’s a paradox to overcome – the engineer who writes the RTL code is the one who best understands how it should be constrained but doesn’t understand the complexities of timing constraints, whilst the engineer who takes on the role of timing constraints ‘guru’ is so far removed from the original design process that he doesn’t understand the design well enough to constrain it. So perhaps the problem isn’t one of technology at all; maybe this is all about how we allow users to access the technology.

Let’s look at the car maintenance analogy again. I definitely don’t want to take on responsibility for alignment, balancing and the whole host of other things that allow me to get the best (and safest) use of my tires. It is reasonable, however, for me to take on a little responsibility like pressure checking. In the chip design world, this kind of limited empowerment can definitely help RTL designers and engineers at the front end of the implementation process develop something that’s much less likely to turn into a problem further down the road.

Constraints checks should be built into existing customer verification regressions and they shouldn’t add much overhead for the design team. Bad constraints need to be identified and fixed at the source, rather than being used to drive expensive back-end tools. That reduces iterations, avoids tapeout slips, and everyone can sleep better knowing that there are no hidden ‘surprises’ in their timing constraints.

So if I told you that a handheld tire pressure gauge could avoid potential problems many of orders of magnitude more expensive than the cost of the gauge itself – wouldn’t you be crazy not to use one?

Ron Craig is senior marketing manager at Atrenta.