Have you found yourself frustrated at the lack of some decent timing constraints? Perhaps made critical floorplanning and placement decisions only to have them thrown out because someone forgot to mention a tiny detail in the constraints? Often times, the role of timing constraints is marginalized until it's just too late. Instead of assuming the constraints are correct, and getting rid of the attitude "That's not my responsibility" or "I didn't know", let's explore some questions we can ask the Timing Constraint Designer that will help insure quality up front, instead of patching them in later on. Even if you're not responsible for writing the constraints, at least this will help you become more aware of what to look for to avoid a disaster. I'm going to assume right off the bat that you have a wonderful document in your hands that might have the name "Clock and Timing Specification". What's that you say? You never received one? Never heard of such a thing? Indeed more often than not, a document which clearly defines the clocking and timing relationship of a design can also fall by the wayside. That's ok, let's use the same questions to help build a timing specification as well. But it sure would have been nice to have that document, right? Insist on it as soon as possible! I'm going to break the topic into 4 posts as follows:
Part 1 - CLOCKS: The Constraints Backbone
Timing constraints would have nothing to time against if there were no clocks defined. Let's first go over the questions to ask about the clocks and whether the constraints reflect that or not.
"But in school, they never told us that things are not ideal in the real world!"
"You mean I didn't have to spend my entire vacation closing timing on these 10,000 violating paths because they were false?"
"You really think you're passing timing on that clock gate with only 1ps of uncertainty? Sure you don't want a little cushion in that?"
"Management didn't tell you they purchased a PLL that had 350ps of jitter? Hey it was on sale!! What did you expect?"
Now to help check some of these items, I like to run the check timing analysis function in Encounter (check_timing). This helps give a quick and organized report to review and share with whoever is responsible for the constraints.
In the case of clocks, it will help find flops that are not receiving any clocks, spot where clock gating situations occur, or even when multiple clocks are arriving at a destination. All of this can point out big flaws in the constraints or even design.Some of the checks it will do:
What happens if the Clock latency is more than a clock period? What is the thumb rule for constraining the minimum and maximum latency of a clock.
very useful... hoping to read other 3 parts.... :-) Thanks a lot ThomasMoore
Very informative & useful...cant wait to read the next parts..