What's PR got to do with it?
Ed Lee has been around EDA since before it was called EDA. He cut his teeth doing Public Relations with Valid, Cadence, Mentor, ECAD, VLSI, AMI and a host of others. And he has introduced more than three dozen EDA startups, ranging from the first commercial IP company to the latest statistical … More »
Can timing constraints disasters be averted?
January 14th, 2011 by Ed Lee
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?!?!?!?!
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?
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?
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.
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.
2 Responses to “Can timing constraints disasters be averted?”