Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorDDR Output Constraining - "too positive" slack
Hi,
I hope someone knows the solution to the problem that kept me really busy lately :( I have to connect to an RGMII PHY that has the following parameters: tCLK = 8 (ns) TskewR (Data to Clock input Skew) (at the PHY) : min 1.0 max 2.6 (ns) (from the RGMII datasheet) I am supposed to meet the PHY requirements without the use of PLLs. The problem I have is that Quartus gets a "too positive" slack - of more than 1/2 of tCLK - and still reports this slack as correct. In practice this kill sme since data would be captured with the wrong edge. Is there a way to specify a maximum slack? Are my constraints incomplete? Attached is a TimeQuest wave report. I used the following constraints: # ################ # derive_pll_clocks # # derives the pll_out[0] that will be used as output clock create_generated_clock -name mtx_clk_ddr -offset 0 -source {pll_out[0]} [get_ports {mtx_clk_pad_o}] set outclk "pll_out[0]" set outclk_ddr "mtx_clk_ddr" set_false_path -rise_from $outclk -fall_to $outclk_ddr -setup set_false_path -fall_from $outclk -rise_to $outclk_ddr -setup set_false_path -rise_from $outclk -rise_to $outclk_ddr -hold set_false_path -fall_from $outclk -fall_to $outclk_ddr -hold set_output_delay -clock $outclk_ddr -max 2.6 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] set_output_delay -clock $outclk_ddr -min -1.0 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] set_output_delay -clock $outclk_ddr -clock_fall -max -add_delay 2.6 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] set_output_delay -clock $outclk_ddr -clock_fall -min -add_delay -1.0 [get_ports {mtxd_pad_o [*] mtxen_pad_o}] Thanks!11 Replies
Altera_ForumSetup checks only check that your data is at the latch register before the clock. It's the hold check that will determine if it's too fast.
Is this the worst case path? Note that DDR has some paths that can be ignored. For example, your set_output_delay constraints describe two sets of registers capturing data outside of the FPGA. So when the rising edge register in the FPGA launches data at time 0, it sends data to two registers, one which captures it on the falling edge and has a half cycle requirement, and a second one capturing it on the rising edge, and has a full cycle. TimeQuest will time this second path, and it could meet timing by more than a half cycle. Note that it's technically a false path, since the data is captured by the falling edge register, and new data is sent before the next rising edge data is ready to capture, but TimeQuest doesn't know this, and it just times the paths it sees. I used to recommend false pathing this, but it gets complicated, as this rise to rise is a false path for setup, but it's valid on the hold check. In essence, this setup is just less restrictive, and as long as the tighter path is being analyzed, I just ignore the looser one. (I don't know all the details of your clock relationships, so the rise/fall names I've used might be slightly off...)
