General timing constraints workflow?

[Altera_Forum]

I'm having a hard time figuring out how to completely constrain the timings in my Cyclone II device. I'm using the classic timing analyzer in Quartus II 7.2. 

 1) Do i need to constrain every setup and hold time in my design or will this be done automatically? There is a lot of automatically generated code (megafunctions/LPMs), will these automatically meet timings internally?  2) What about I/Os? I'm confused about how to ensure external Tsu and Th (for my SDRAM and other external circuits).  3) Is there some good books about this subject? I really hate Alteras documentation because it is rather skimpy and fragmented. Most books focus on digital design etc but completely skips the important subject on timing closure. I have some 20 books on digital FPGA design but no usable information has been found...  My design appears to work but since i have done nothing to constrain the timings it is just a matter of time before the design will start failing...  Thanks, /John.

[Altera_Forum]

To be completely honest, I would recommend that you transition to the Timequest analyzer. You will spend a few days going through the learning curve but after that, you have much more power to constrain the timing of your design. 

 Spending time learning the Classic timing analyzer at this point would not be the best use of your time. The classic timing analyzer is not supported for Cyclone III, Stratix III and newer parts.  However, to answer some of your questions.   1) The classic timing analyzer will automatically determine the clock frequencies of any clocks driven by PLL's in your design. The analyzer is smart enough to determine what logic uses what clock and will automatically perform setup and hold analysis for all internal nodes pertaining to that clock.  For any clocks that are driven directly from a top-level pin. You must specify the frequency of the clock in the project's timing settings.  2) You use the assignment editor to provide Input Delay, Output Delay, or tSU, tH, tPD, and tCO constraints for all user I/O.  3) Refer to http://www.altera.com/support/software/timing/sof-qts-timing.html (http://www.altera.com/support/software/timing/sof-qts-timing.html)  Really, I know it seems like it's not worth the time but you'll be more satisfied and have higher confidence in your design if you take the time to learn TimeQuest.  Jake

[Altera_Forum]

Thanks Jake. I have taken a look at timequest but it seemed to me that i don't need the fancy stuff at this time since i "just wanted to constrain the timings in the current design".  

 Essentially, i'm trying to figure out why my design fails one out of every five times it runs on the same board. I doubt it has anything to do with I/O timings since all timings look ok when actually measured on my board but i want to rule this out by doing basic constraining of the I/O.  I'm using a Cyclone II and the timing margins are large so the classic timing analyzer should work well enough for this project.  Thanks, /John.

[Altera_Forum]

--- Quote Start ---  I have taken a look at timequest but it seemed to me that i don't need the fancy stuff at this time since i "just wanted to constrain the timings in the current design".  --- Quote End ---    For someone new to both timing analyzers, TimeQuest is almost as simple to learn and use as the Classic Timing Analyzer to accomplish the same thing. With TimeQuest you don't need to worry about the complexities of the "fancy stuff" until you actually need to use those capabilities. When you do need them, you'll be glad you're using TimeQuest because it handles situations that the Classic Timing Analyzer can't or handles them better.     --- Quote Start ---  Essentially, i'm trying to figure out why my design fails one out of every five times it runs on the same board. I doubt it has anything to do with I/O timings since all timings look ok when actually measured on my board but i want to rule this out by doing basic constraining of the I/O.  I'm using a Cyclone II and the timing margins are large so the classic timing analyzer should work well enough for this project.  --- Quote End ---    Anyone with unexplained hardware failures should make sure the design is fully and correctly constrained for timing and does not have something like asynchronous paths not handled properly by the design.  When people think of "large" timing margins, they usually have clock setup in mind for a clock slow relative to what the device can handle. Clock hold is critical for a design running at any speed.  The Classic Timing Analyzer does not enable recovery and removal analysis by default. If anything in the design needs a synchronous deassertion of a reset going to the asynchronous clr or load ports of the registers, then this analysis is necessary.  "Processing --> Start --> Start Design Assistant" might catch problems with improperly handled asynchronous paths and other problems that could cause hardware failures. The messages might not all make sense (file a mySupport service request for anything that needs to be explained better on help pages reached by right clicking the messages). However, the Design Assistant could very well expose the cause of your failures.

[Altera_Forum]

Thanks Brad. I have synchronized my external reset signal through three DFF's a while back. This solved some other sporadic problems. I don't have any other asynchronous inputs and the design assistant flags no problems. I meant by "large timing margin" that the external setup and hold timings are ok as measured by my Logic Analyzer. Internal input setup and hold also looks ok as reported to my LA via the LAI. Still, the design occasional gets the hickups. 

 One warning i get is that i'm using regular output pins as clock outputs to an external FIFO (60 MHz) and to SDRAM (120 MHz). The warning talks about jitter. I have several ns margin on both tsu/th so i can't see how this could cause problems (especially 20% of the times run on the same board).  I have to dig into this step by step - first constraining (and understanding) the timings fully.  Thanks, /John.

[Altera_Forum]

--- Quote Start ---  I have synchronized my external reset signal through three DFF's a while back. This solved some other sporadic problems.  --- Quote End ---    If your design actually has something needing that reset to be synchronized (seems to be the case since some problems went away when you synchronized it), then you definitely need to use recovery/removal analysis. An example is a state machine that could have more than one state bit toggle at the exit from the reset state. It is critical that each potentially toggling state bit see the reset deassertion in the same clock cycle. Synchronizing the reset as you did is necessary. It is also necessary to do the timing analysis to make sure the synchronized reset is stable from the recovery time before the clock edge (like a tsu) until the removal time after the clock edge (like th) right at the register inputs.  If you have more than one clock domain with registers needing recovery/removal analysis, then the reset needs to be synchronized to each of those domains separately.  If you find that you have recovery/removal violations for a reset using global routing, then try making the reset nonglobal. Even a large fan-out using nonglobal routing can be faster than the large global buffer insertion delay.     --- Quote Start ---  I meant by "large timing margin" that the external setup and hold timings are ok as measured by my Logic Analyzer.  --- Quote End ---    If you have used only a logic analyzer and not a scope, check signal integrity at the input pins with a scope. Also check the power pins for dropouts or other noise.     --- Quote Start ---  One warning i get is that i'm using regular output pins as clock outputs to an external FIFO (60 MHz) and to SDRAM (120 MHz). The warning talks about jitter. I have several ns margin on both tsu/th so i can't see how this could cause problems (especially 20% of the times run on the same board).  --- Quote End ---    To minimize jitter, it is best to use a clock output pin that the PLL can drive with a direct connection. The device handbook documents which pins go with which PLLs.  An example where this would matter is an external DDR memory with a clock input that cannot tolerate the jitter potentially added by routing from the PLL to the output pin using anything other than the direct connection.

[Altera_Forum]

Thanks Brad, I will look into all your suggestions. 

 /John.