Honored Contributor
Honored ContributorI recommend against cutting rise->fall or whatever transfers. If you draw your waveforms, i.e. the launch waveform is probably a 5ns clock with rising at 0 and falling at 2.5, while the latch clock is rising at 1.25 and falling at 3.75. (I'm assuming, but would need to see how the PLL is constrained from derive_pll_clocks.)
If you look at the first rising edge at time 0, it will be analyzed to both registers outside the device, the one clocked on the rising edge at 1.25 and the one clocked on the falling edge at 3.75. Now, if you want to add a false_path, it's to the easier requirement, i.e. the 3.75ns edge. But if you make timing to the 1.25 edge, you've automatically met timing to the 3.75ns edge. So this false path doesn't help close timing at all, and only removes a few paths from the timing report, that would be at the bottom of the slack report. Note that the false path is rise -> fall for setup. You also have to do fall -> rise for setup. For hold, if you trace back, you see similar things but the false path is rise -> rise and fall -> fall. If done correctly, these false paths don't hurt anything. But if done incorrectly, which I have see many times, the user cuts the inside path and has incorrect timing analysis. I guess I'm saying they don't really help, but have the potential to hurt your design. As for not seeing a falling edge, I think you figured out that you were analyzing -from a specific register, while the DDR has two registers, one rising and one falling. Just a generic: report_timing -setup -to_clock [get_clocks { l1_rx_clk_0 }] ... report_timing -hold -to_clock [get_clocks { l1_rx_clk_0 }] ... should do the trick. My major concern is that your output delays are skewed, i.e. 0.4 and 1.2. Is your PLL phase-shifting the clock going out by 90 degrees?
