Crossing clock domains, PLL and TimeQuest

[Altera_Forum]

Hi everybody, 

 I worked on one project with one global clock f = 50 MHz. Then I had to modify this project. All logic inside is the same, but now, part of the project is working with clock f = 100 MHz (changed from f = 50 MHz) and the second part, is working, as before, with clock f = 50 MHz. Both clocks are generated from the same PLL in FPGA (Cyclone IV).   The problem is that I have a lot of signals which go from one clock domain to the second one (both directions) and TimeQuest shows setup violations. I have not much experience in TQ and clock domains, so I have a few basic questions.  1. I know that I should use FIFOs to properly transfer data between two domains when clocks are asynchronous. But what in situation mentioned above, when I have two related (synchronous) clocks from the same source (PLL), and first clock is just two times faster than the second one? Should I use FIFOs to send signals between domains in situation like this?  If no FIFOs are needed, how should I constrain those signals? I see three options:  a) do nothing, and TimeQuest will analyze project properly without any additional constraints (just constrain both clocks)  b) set multicycle paths between clocks   c) set clocks as asynchronous and set false paths between them. Which solution is the best?  And what to do when I have two clocks form the same PLL, but not in so simple relation (e.g. clk1 = 50 MHz and clk2 = 155 MHz)?  2. If option a) is corret (I don’t have to use FIFOs and add any new constraints in TQ), it means that something is wrong with my design (because of setup violations), right? So I have to redesign the project?  3. Assume that I have two clocks with the same frequency (in my example 50 MHz), but from two different sources (two different PLLs or two external). When I want to send data from one clock domain to another one, should I use FIFO (probably yes)? Or maybe I have to only constrain properly these paths? If yes, how?  4. Basic situation. Two clocks asynchronous, but some signals are sent between those domains. Of course without FIFO. How to constrain those paths? Use false paths? Use multicycle paths? I’ve found those answers in other similar topics on this forum. Which way is the best? Are there any general rules?  If somebody could explain this… I am totally confused…

[Altera_Forum]

There are two cases: either the clocks are synchronous to each other or they're asynchronous. 

 Being synchronous means that the relative position of their edges is known or can be calculated with a limited uncertainty and thus, TimeQuest can analyse the timings. Being asynchronous means that relative position of the edges is not known, so TQ can't analyse the timing.  To know if two clocks are synchronous or not, you need to figure out if you can know where their relative edges are or not. PLL output clocks are synchronous to their input clock. Even if you use two different internal PLLs feb by the same input clock, their outputs are synchronous to the input and among themselves. On the other hand, two clocks from two different crystals are asynchronous. Even if they have the same nominal frequency, their frequency won't be exactly the same and their relative phase will be unknown.  Asynchronous clock are harder to deal with but simple to summarize: you're working without safety net. You have no timing analysis there and your design may suffer meta-stability. What you need to do is to design using proper asynchronous clock domain crossing techniques to minimize meta-stability, such as a DCFIFO with 2 or more stages or synchronizer register chains. And you need to use exclude those paths from timing analysis using set_false_path or set_clock_groups, as any analysis of them would be non-sense (and it also prevents Quartus from recognizing synchronization register chains).  Synchronous clocks, which is your case, is simpler to use: TQ can analyse the timings and you can trust it. All you need to do is to constrain the clocks properly. Which in case of internal PLLs, means adding derive_pll_clocks and derive_clock_uncertainty to the .sdc.  Now, having a properly constrained design doesn't mean it will get timing closure, which is what you're experiencing. To fix those setup failures, you need to look at the failing paths timing and logic. Maybe you need to add some registers to the design to split the worse paths. Or maybe you need to set some multi-cycle exceptions to relax the timings requirements on those paths.  If you think you can add multi-cycle exceptions, take a look at this: http://www.scribd.com/doc/14475172/multi-cycle-paths

[Altera_Forum]

There's a great app note that helps address this: http://www.altera.com/literature/an/an545.pdf 

 We usually use 2 FF synchronizers, with a relaxed set_max_delay on the first FF. The guide above says you can false path it, but I'd rather give it some amount of time for setup.

[Altera_Forum]

Thanks a lot guys. It is more clear for me now. 

I have just started looking into recommended literature.    But I have new question.    --- Quote Start ---   To fix those setup failures, you need to look at the failing paths timing and logic. Maybe you need to add some registers to the design to split the worse paths. Or maybe you need to set some multi-cycle exceptions to relax the timings requirements on those paths.   --- Quote End ---   How can I know which way I should go? From what does it depend?

[Altera_Forum]

Multicycles can do multiple things(look at TimeQuest User Guide on alterawiki.com), but most of the time users saying multicycle mean opening the window. So if I have a 10ns setup relationship(let's say both clocks are 10ns period), then a multicycle -setup 2(and multicycle -hold 1) will make the setup relationship 20ns while the hold relationship is 0ns. So now data can transfer anywhere between 0-20ns. This gives you twice as much margin to meet timing, but your data throughput is half, since you can only get data through every other cycle. The most common scenario is where a designer creates a clock enable from a toggle flip-flop, so the source and destination registers toggle every other cycle. 

The key to this kind of multicycle is that you've designed for it, and now the default setup relationship is too restrictive. If it doesn't jump out at you right away that you've designed something that can be multicycled, then most likely it can't be. (Of course, there are exceptions to everything...)