Ron Craig, Senior Marketing Manager at Atrenta and an expert on the subject of timing constraints, was good enough to sit down with me (Liz Massingill) recently to talk about the subject—what the current problems are and how to fix them. This is the result of my interview with Ron.

Liz: Ron, I was shocked to see, in the survey you conducted, that 94% of designers have timing constraint problems that could stop their current designs dead in their tracks.  But they also don’t see a way to change their current methodology.  WHY?!?!?!?!

Ron: There’s certainly no doubt that timing constraints remain and will continue to be a problem for design teams. The irony is that even though timing constraints are repeatedly an issue, most of these design teams feel that they know how to address all the problems that typically arise. It’s almost that the problems are viewed as less severe if the solutions are known.

Liz: Seems like the problem is more about changing the mindset. But why are designers running into increasing clock domain issues in the first place? Use of more IP?   Process nodes going down to the next level?   More complex designs?

Ron: The key culprit here seems to be IP. With IP, the functionality is reusable but the timing constraints are often not. Third party IP developers may well be experts in what the IP is supposed to do but not necessarily its implementation, leaving design teams with incomplete and inadequate timing constraints. On the other hand, IP reused from another design may well have been constrained in a way that’s not compatible with how you want to use it in your chip – especially if you need to change how the IP behaves. In today’s designs where IP amounts to 70% or more of a typical SoC, you end up with the constraint-driven implementation process becoming increasingly risky.

The process shrinks and more complex designs mean you simply can’t get away with having inadequate timing constraints anymore.

Liz: Well, what can they, ­or more appropriately, their project managers or internal CAD departments do about this increasing problem?

Ron: The key is to introduce more certainty into the whole process. Rather than taking an optimistic, or reactive approach to timing constraints, it makes a great deal of sense to put some effort in up-front to make sure that they are good. Many of our customers have noted that they simply can’t deal with the number of iterations it takes to refine timing constraints during the implementation phase of their projects, so they’re working on finalizing them up front as part of their RTL handoff. The trick for project managers or CAD people will be to introduce a methodology that their front end teams (who aren’t necessarily timing constraint experts) can easily adopt, and this is where comprehensive automated solutions such as SpyGlass-Constraints come into play.

Liz: So why isn’t this happening? Seems to me that an ounce of prevention is worth a pound of cure, as they say.

Ron: Let’s look at the two camps. First of all you have the RTL or front end team, who historically don’t want to take ownership of any part of the implementation process (even they know the design well enough to define its constraints). On the other side of that handoff ‘wall’ you have the back end team who feel that their expertise in this area, coupled with whatever the implementation and timing tools complain about, is enough of a solution. So depending on which side of that wall you sit on, you may feel that it’s either not your problem….or not a problem at all.

Liz: But we know there IS a problem, and it’ll only increase. So where in the design flow should project managers look first for a fix?

Ron: There is often a perception that timing constraints can’t be fully defined until you are actually using them – until you are in the thick of implementation or timing analysis. The problem with this is that your constraints end up being written so that you can close timing, instead of being defined to set the ground rules for timing closure. A classic example of this is the definition of timing exceptions – they’re often defined to mask timing violations, but in most cases they’re not exhaustively verified. A timing exception is a design characteristic, so can be defined and proven up-front before the implementation process even starts. It’s like an architect finalizing the plans after the building is complete. If your objectives aren’t clear how do you know when you are done?

Liz: I see what you are saying—it’s like putting the cart before the horse. Stop me, Ron, if I use another one of these old sayings. I’m dating myself. So who’s out there with technology that can help change the methodology and fix the timing disaster that’s looming?

Ron: It’s been possible to do some rudimentary timing constraint analysis in a range of implementation and STA tools since the advent of timing driven optimization. The problem with this approach, however, is that it’s largely a reactive one, and as a result doesn’t help reduce the risks in your implementation process. More recently, vendors (often ones outside the implementation/STA space) have started to provide solutions that allow the user to check the correctness of their constraints before implementation. What we’ve done with SpyGlass-Constraints is to take it one step further and look how timing constraint analysis is part of the bigger picture of reducing implementation risk. A great example of this is how we use our constraint verification methodology to ensure that data such as clock setup is in good shape before you use it to drive clock domain crossing (CDC) analysis. Again, it’s all about finding the issues up front and reducing risk later.

Liz: Well it’s intriguing…a Titanic-like iceberg of a design problem out there and we’re forging ahead…like the Titanic?

Ron: (laughs) Indeed – though given that the Titanic was built in my home city I always feel the need to point out that this particular disaster came about as a result of pilot error! To take your analogy further, I guess that the ‘iceberg’ here is a failure to close timing. Better guidance will definitely help you avoid that one.

Liz: Who knew? (laughs) Well, where can we learn more about this problem and how to fix it? Oh…and your customer survey…can we get a look at that? Sounds like some compelling information in there.

Ron: Yes, the customer survey was VERY telling and gives us a good leg up on what designers need to close at RTL for the next several generations of designs. In its current form, because we talked to customers, we can’t release it.

However,  Bernard Murphy WILL refer to it at length in his DesignCon panel.

Liz: What panel is that?

Ron: At DesignCon we will be holding a panel on: “The Same Chip Killers keep Delaying your Schedules – What are you doing about it?” moderated by Ed Sperling, editor of System-Level Design. The panelists will discuss a broad range of issues, including timing constraints, the impact of IP etc. that repeatedly cause schedule slips. It will take place on Monday, January 31 at 4:45 p.m.

Liz: Sounds like a crucial discussion.   I’ll be sure to attend!