How does TimeQuest Analysis determine Launch edge & Latch edge?

[Altera_Forum]

I have to clocks generated from PLL. 

CLKA is 80Mhz, CLKB 100MHz.  I noted that the launch edge is 10ns and latch edge is 12.5ns in setup time report from CLKB to CLKA.  How does TimeQuest Analysis determine Launch edge & Latch edge between two different clock, such as two asynchronous clock?

[Altera_Forum]

If CLKA and CLKB are coming from the same PLL, I think they're consider synchronous (they are generated from the same clock with certain relationship). Therefore, TimeQuest is able to determine the launch & latch edge. For asynchronous clock, I don't think TimeQuest has a way to determine it since the 2 clocks relationship is unknown. So you need to set false path for asynchronous clock domain crossing to tell the TimeQueste not to analyze those paths. Hope it helps.

[Altera_Forum]

Do you mean that it is designer's responsibility to ensure that the circuit handles any clock domain crossing appropriately? And TimeQuest Analysis can't do anything helpful for asynchronous clock??

[Altera_Forum]

The best way to figure this out is to draw the waveforms. Then finding the tightest requirement where an edge on the latch clock is greater than an edge on the launch clock. So if going from CLKA to CLKB, we draw the launch clock (A) with launching edges at 

0, 12.5, 25, 37.5, 50, 62.5, 75, 87.5, 100... Then we draw the latch clock (B) with latching edges at: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100... So let's look at a couple launch to latch edges. Launching at 0ns, the nearest latch edge greater than 0 is 10ns, for a setup requirement of 10ns. Launching at 12.5ns, the nearest latch edge greater than 12.5 is at 20, for a requirement of 8.5ns. Continuing in this manner, the closest edges are 37.5 -> 40ns, for a setup requirement of 2.5ns. In the reverse direction, the closest are 10 -> 12.5, once again for a requirement of 2.5ns.  A couple quick notes: 1) I find this method much more understandable than equations(equations that deal with periodic functions are usually confusing). I draw them out and just look for the most restrictive edges.  2) The difference is the important thing. You had an earlier post where the launch edge is at 60ns and latch is at 62.5ns. I'm not sure why this occured, but the difference is still 2.5ns so the analysis is the same as if the launch was at 10 and latch at 12.5ns. (Clocks are periodic.) 3) Explaining this, I always get asked, what happens if the launch clock is 10ns and the latch is 1.234ns(i.e. they are not related). TimeQuest will find the most restrictive edges, and you end up with a launch of 643010.00 and a latch of 643010.001, for a 1ps setup requirement(I made those numbers up, but you get the point). The more important question is what should the requirement be? The answer is that they're asynchronous and the user needs to cut timing between the clocks and design for this.

[Altera_Forum]

David, 

I don't think I saw your second question. TimeQuest(and the fitter using TimeQuest) will try to meet your requirements. But if two clocks are asynchronous, what would a valid requirement be? Since there is no common relationship between the clocks, there is no possible delay that would satisfy all conditions. So for asynchronous clocks, the designer needs to tell TimeQuest they are asynchronous and it basically ignores them, as does the fitter. (The fitter will still try to optimize the path to use the least amount of routing as possible, so you generally get a decent fit, but it's not going to sacrifice placement/routing of a valid path to help these asynchronous paths). Asynchronous transfers are generally out of the realm of static timing analysis and up to the user to properly design for, so that the circuit can handle "any relationship" between the clocks/data and still work. An asynchronous FIFO does this. Handshaking schemes usually do this. There are other situations(like synchronizing an asynchronous signal, etc.).

[Altera_Forum]

--- Quote Start ---  Asynchronous transfers are generally out of the realm of static timing analysis and up to the user to properly design for, so that the circuit can handle "any relationship" between the clocks/data and still work. An asynchronous FIFO does this. Handshaking schemes usually do this. There are other situations(like synchronizing an asynchronous signal, etc.).  --- Quote End ---    Wow...I get lots of info from your answer, thanks a lot! Also could you tell me some book related to the information quoted above.  Thanks you and thanks altera forum again!

[Altera_Forum]

I wouldn't know any books. Probably the biggest issue with a book is that the user has specific constraints, where the most of the solutions wouldn't apply and could be skipped. Also, I've never seen a solution that someone else says they don't like and have their own methodology.  

Some common ones: a) Using an asynchronous FIFO, usually Altera's megawizard. This is best for data transfers, and can usually maintain the bandwitdh of the two sides. The only issue is over/underflows need to be dealt with. (Done outside of the FIFO) b) Synchronization. This is usually a single signal(or a group of individual signals where we don't care if they are captured on different clock cycles, like pushbuttons). A common method is to double register these into the other clock domain to reduce metastability. A tight timing requirement between the two registers is recommended, but often not done. c) Handshaking - Done a lot because they are robust, but they usually require multiple clock cycles for every bit of data. If throughput isn't a concern, these work well. I don't have an example available, as I mainly do the first two.  After that it gets very scenario specific. For example, if the receive side is at a higher clock rate than the data, you can oversample. If the two clocks are equivalent(guaranteed 1:1 edge ratio) over time but unkown phase relationships, then a phase-compensation FIFO will work(which is simpler than an asynchronous FIFO). I would figure out what your requirements are and go from there(or ask more questions here), rather than try to understand them all.

[Altera_Forum]

For using an asynchronous FIFO (if you're interested), the following application note gives you high-level concept & example of using DCFIFO for asynchronous clock domain interfacing. 

 http://www.altera.com/literature/an/an473.pdf

[Altera_Forum]

OK. 

My design has only one path that crossing clock domain. Pls see the following source code:  architecture WithoutStrobeOutput of FREQMeasure_PeriodCounterDuringStrobe is signal s_cnt : integer range 0 to (GEN_T_STROBE_WIDTH * GEN_MAX_TARGET_FREQUENCE); signal s_counter_clear : std_logic := '1'; signal s_clearstep : std_logic; begin counter_clear_gen: process (IN_CLK, IN_STROBE) begin if (s_clearstep = '1') then s_counter_clear <= '0'; elsif(rising_edge(IN_STROBE)) then s_counter_clear <= '1'; end if; if(rising_edge(IN_CLK)) then s_clearstep <= s_counter_clear; end if; end process; counter_operation: process (IN_CLK, s_counter_clear, IN_STROBE) begin if (s_counter_clear = '1') then s_cnt <= 0; elsif (IN_STROBE = '1') then if (rising_edge(IN_CLK)) then s_cnt <= s_cnt + 1; end if; end if; end process; OUT_COUNTERVALUE <= s_cnt; end WithoutStrobeOutput;  The pre-simulation result as the following picture shows: http://blogimg.chinaunix.net/blog/upfile2/080109112932.jpg   The DarkRed codes is where the crossing clock path exist. Could you help me on this issue?  P.S. The IN_STROBE & IN_CLK are unrelated clocks.  Thanks a lot :)

[Altera_Forum]

--- Quote Start ---  ... counter_clear_gen: process (IN_CLK, IN_STROBE) begin ... end process; counter_operation: process (IN_CLK, s_counter_clear, IN_STROBE) begin ... end process;   ...  P.S. The IN_STROBE & IN_CLK are unrelated clocks.  --- Quote End ---     Any single process should have only one clock in the sensitivity list. Look at a VHDL book or the Quartus handbook for coding style recommendations. The handbook chapter and one suggested book are at http://www.alteraforum.com/forum/showthread.php?t=1025.