Steps to constrain a design

[Altera_Forum]

Hello, 

 I'm trying to understand timing constraints and I have a really hard time trying to figure out how this works. The first thing is the representation of setup and hold times.  In my examples I want to transfer data from one register to another register where both registers are clocked by a different clock where one clock frequency is an integer multiple of the other clock frequency. I assume the clock delay to be zero so that the drawings don't get too confusing. https://www.alteraforum.com/forum/attachment.php?attachmentid=8016   Right now I would start with drawing the clocks (these are just some arbitrary clock signals chosen for this example): https://www.alteraforum.com/forum/attachment.php?attachmentid=8017   In this example the destination clock runs at a clock frequency three times lower than the source clock frequency. The setup and hold times are from Equation 7–6 and Equation 7-3 from http://www.altera.com/literature/hb/qts/qts_qii53018.pdf setup check = current latch edge - closest previous launch edge hold check 1 = current launch edge - previous latch edge  hold check 2 = next launch edge - current latch edge  Now if the data is only updated every third clock of the launch clock I guess I would need the timing diagram to be like this: https://www.alteraforum.com/forum/attachment.php?attachmentid=8018  So I would need a start multicycle setup time of 3 and a start multicycles hold time of 2. Is this correct?  If that's so why does the start multicycles hold time only affect the hold check 2 but not the hold check 1? How do I have to interpret the two hold check times? The setup time does make sense to me if I consider this as the time the data has to travel from register 1 to register 2. The hold check times are hard to grasp for me. I guess if the hold check time is positive I don't have to worry that the signal changes before the data was latched? But what about negative hold check times?  How can I tell TimeQuest at which edges the transfer should take place? For example if I want to have an transfer from the rising edge of the launch clock to the falling edge of the latch clock: The default timing diagram would look like this: https://www.alteraforum.com/forum/attachment.php?attachmentid=8014  And what I guess what I want in this example would be this: https://www.alteraforum.com/forum/attachment.php?attachmentid=8015   This is a follow up to the previous question: As I understand it TimeQuest only analyzes rising edge to rising edge transfers per default. When are other edge transfers taken into account (re -> fe, fe -> fe, fe -> re)?   Best regards Martin

[Altera_Forum]

Hi Martin, 

 Here's a tutorial and code on setting up timing constraints for a QSPI Flash.  http://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.pdf http://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.zip  It uses multi-cycle contraints, and shows an evolution of how I came up with those constraints.   Read through it to gain a little more understanding on how to set things up, also read through the code and comments.  You can setup timing constraints on rising and falling clock edges. You can use the waveform view in TimeQuest to confirm you've applied the constraint correctly.  Cheers, Dave

[Altera_Forum]

TimeQuest analyzes all edges, but a register only works on one edge. So if your register clocks data on the rising edge, TimeQuest only analyzes rising edges for that. If it clocks on the falling edge, it only analyzes falling edge transfers. Might I suggest looking at Section 2 of the following User Guide I put together: 

http://www.alterawiki.com/wiki/timequest_user_guide I generally find the most difficult part with hold time is that the default hold relationship follows the setup relationship, so if you add a multicycle -setup, the default hold relationship changes. That's usually the biggest stumbling block.

[Altera_Forum]

--- Quote Start ---   I generally find the most difficult part with hold time is that the default hold relationship follows the setup relationship, so if you add a multicycle -setup, the default hold relationship changes. That's usually the biggest stumbling block.  --- Quote End ---    I think that as direct consequence of internal definitions used by tool i.e.   Setup Check (SC) = current latch – previous launch   Hold Check1 (HC1) = current launch – previous latch   The above definitions assume multicycle of 1 for setup and 0 for hold according to tool's perspective. When user sets multicycle of 2 to setup then that modifies above SC definition of next latch edge by one clock forward as requested. However it does not modify definition of HC1 which will check a launch edge with previous latch edge, this is not right as multicycle requires checking a launch edge with the one before previous latch and so a hold multicycle of 1 is needed to modify the definition backwards by one edge.  Purely a tool issue.

[Altera_Forum]

I wouldn't say it's a tool issue, as that's how SDC constraints are defined and all SDC compliant tools behave that way. I don't know the reason, but I would guess this behavior is to keep with the mantra of behaving as conservatively as possible. By adding a setup multicycle of 2 to a path, saying the setup should be analyzed to the next latch edge, the hold edge is still the most restrictive one. This is the correct analysis when you're not running data at a rate slower than the clock rate, but just transferring data at the full rate between phase-shifted clocks. So in many cases adding a multicycle -setup of 2 without adding a hold multicycle is what the designer wants. 

 One way to think of it is that the multicycle -setup changes which window you're aiming for, but not the data rate. For example, if your launch and latch clocks are edge-aligned 10ns clocks, then the default setup latch edge is at 10ns and the default hold latch edge is at 0ns. The data rate is the difference of these, i.e. 10ns. If you add a multicycle setup of 2, then your setup latch edge is at 20ns and the hold latch edge is at 10ns. You're still transferring data through a 10ns window and can run at the same rate, you just happen to be shooting for the next window. Doing other multicycle -setup values, say 3 or 0, just change which window you're aiming for, but it's always a 10ns window. When you add a multicycle -hold, it changes the size of the window. So back to our multicycle -setup of 2, if you then add a multicycle -hold of 1, your setup latch edge is at 20ns and hold latch edge is at 0ns, resulting in a 20ns data window, so you're running at half the rate. This may not be the technical definition, but it generally holds true. (If the clocks are funky periods, duty cycles with rise-fall, it may not be quite that simple, but I haven't looked into it since that seldom happens)

[Altera_Forum]

My reply was about source synchronous clock path and for this case adding a multicycle of 2 to a path must be associated with hold multicycle of 1 because only then the tool can check the relevant edges. For cases such as phase shifted launch/latch clocks then the user will need to see if they have to design for an extra setup multicycle and whether to add to hold multicycle or not.

[Altera_Forum]

I think for source synchronous, there are cases where you can do a multicycle -setup 2, but you don't want to do a multicycle -hold 1, as that will mean you're running at a lower rater. (I always make sure the clock is shifted into the center of the data window, in which case you don't need to add any multicycles.) I haven't ever added a hold multicycle to a source-sync interface, but don't know what specific case you're talking about.

[Altera_Forum]

--- Quote Start ---  I think for source synchronous, there are cases where you can do a multicycle -setup 2, but you don't want to do a multicycle -hold 1, as that will mean you're running at a lower rater. (I always make sure the clock is shifted into the center of the data window, in which case you don't need to add any multicycles.) I haven't ever added a hold multicycle to a source-sync interface, but don't know what specific case you're talking about.  --- Quote End ---    With delay determined by fitter you cannot guarantee centre aligned clock across all paths in a large design so a hold multicycle is necessary in order for multicycle to be meaningful and helpful. In all my designs of multicycle I do relax both setup and hold otherwise there will will serious violations. There is no place for lower rate running concept here; we are just telling the tool which edges to check.

[Altera_Forum]

Thanks for your replies so far! I have tried to write down everything I learned about timing constraints in the Wiki: timing constraints (http://www.alterawiki.com/wiki/timing_constraints). There's still a lot missing (asynchronous signals for example are missing completely so far) and I would welcome anybody to contribute. The information I've written on the wiki were gathered from all different kinds of sources. If you find errors please fix them! :)