Source synchronous constraints for both edges in TimeQuest

[Altera_Forum]

I've been working my way through the tutorials and Rysc's document. Unfortunately, the waveforms don't match what I'd expect. I thought I'd see the min-rise output delays from the rising edge of the launch clock to the rising edge of the latch clock, and from the falling edge of the launch clock to the falling edge of the latch clock. The rising edge is always the launch, which seems wrong. 

 Here's what I do: # derive_clocks + correct periods.# for each link, there is an external clock shifted -90 degrees create_clock -name {clock_source} -period 10.000 -waveform { 0.000 5.000 } create_clock -name {l1_clk_in} -period 5.000 -waveform { 0.000 2.500 } }] create_clock -name l1_tx_clk_0 -period 5.000 -waveform { 3.75 6.25 } derive_pll_clocks # HT output clock create_generated_clock -source U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk -name l1_rx_clk_0 l1_clk_out # Cuts the clock output path; the tco can be unconstrained set_false_path -from * -to }] set_input_delay -min -1.000 -clock l1_tx_clk_0 } {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_ctrl_in}]] set_input_delay -max 1.000 -clock l1_tx_clk_0 } {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_ctrl_in}]] set_input_delay -min -1.000 -clock l1_tx_clk_0 } {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_ctrl_in}]] -clock_fall -add_delay set_input_delay -max 1.000 -clock l1_tx_clk_0 } {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_cad_in} {l1_ctrl_in}]] -clock_fall -add_delay set_output_delay -min 0.400 -clock l1_rx_clk_0 } {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_ctrl_out}]] set_output_delay -max 1.200 -clock l1_rx_clk_0 } {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_ctrl_out}]] set_output_delay -min 0.400 -clock l1_rx_clk_0 } {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_ctrl_out}]] -clock_fall -add_delay set_output_delay -max 1.200 -clock l1_rx_clk_0 } {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_cad_out} {l1_ctrl_out}]] -clock_fall -add_delay When I try the reports  # report_timing -from_clock { U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk } -to_clock { l1_rx_clk_0 } -from {xd1000_ht_core:U_HT_CORE|ht_ec:U_HT_EC|ht_link:htxtop_inst|ht_link_wrapper_200:ht_link_wrapper_I|oserdes_altera9_buf:CTLCADLO_OUT_SERDES_I|oserdes_altera9_logic:oserdes_altera_inst|altlvds_tx:altlvds_tx_component|oserdes_altera9_logic_lvds_tx:auto_generated|oserdes_altera9_logic_ddio_out:ddio_out|ddio_outa_0~data_in_reg} -to {l1_cad_out} -hold -npaths 100 -detail full_path -panel_name {Report hold Timing}# report_timing -from_clock { U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk } -to_clock { l1_rx_clk_0 } -from {xd1000_ht_core:U_HT_CORE|ht_ec:U_HT_EC|ht_link:htxtop_inst|ht_link_wrapper_200:ht_link_wrapper_I|oserdes_altera9_buf:CTLCADLO_OUT_SERDES_I|oserdes_altera9_logic:oserdes_altera_inst|altlvds_tx:altlvds_tx_component|oserdes_altera9_logic_lvds_tx:auto_generated|oserdes_altera9_logic_ddio_out:ddio_out|ddio_outa_0~data_in_reg} -to {l1_cad_out} -setup -npaths 100 -detail full_path -panel_name {Report setup Timing}   The first hold relationship is -1.25 ns, which is what I expected, but the next one is -3.75 ns, which is too long. The same is true for setup, but the sign is switched.  My question is either: - How can I constrain the correct edges? or  - Why is this behavior correct?  Thanks, Myles

[Altera_Forum]

Some additional information: 

- Using the native lvds blocks works fine, but I don't have enough clock resources when I use multiple links. - The place and route seems to be trying too hard, and making the SDRAM controller core fail.  Thanks, Myles

[Altera_Forum]

Using this report gives one of the falling edges. I guess I was too specific. Maybe I still have to be more general to see the other falling launch edge? 

  report_timing -setup -panel_name {Report setup Timing} -to }] -to_clock -npaths 100 -detail full_path report_timing -hold -panel_name {Report hold Timing} -to }] -to_clock -npaths 100 -detail full_path

[Altera_Forum]

According to my shallow TimeQuest familiarity, the tool by default checks rise => rise, rise => fall, fall => rise, fall => fall. 

So you need to cut off rise => fall and fall => rise for botj setup and hold

[Altera_Forum]

Thanks for the quick response. 

 I added    set_false_path -setup -fall_from U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk -rise_to l1_rx_clk_0 set_false_path -setup -rise_from U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk -fall_to l1_rx_clk_0 set_false_path -hold -fall_from U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk -fall_to l1_rx_clk_0 set_false_path -hold -rise_from U_HT_CORE|U_HT_EC|htxtop_inst|ht_link_wrapper_I|CTLCADLO_OUT_SERDES_I|oserdes_altera_inst|altlvds_tx_component|auto_generated|lvds_tx_pll|clk -rise_to l1_rx_clk_0 set_false_path -hold -fall_from   And now I see closer to what I expected. I still see three rising launch edges and only one falling launch edge. I thought it would be symmetrical.  I'll try place and route again to see if it has an easier time. The edges that got cut were all edges with large positive slack, so that might not have helped (except for making the timing analysis clearer).  Thanks, Myles

[Altera_Forum]

--- Quote Start ---   So you need to cut off rise => fall and fall => rise for both setup and hold  --- Quote End ---    I actually cut rise=> fall and fall => rise for setup, and rise => rise and fall => fall for hold. That gives me the tightest constraints.  Thanks, Myles

[Altera_Forum]

Thanks for the information. Indeed that is correct but my eyes never spotted the hold false paths correctly from altera examples.

[Altera_Forum]

Maybe that means I got it wrong. 

 I can't tell that setting the false paths makes any difference in timing closure. Too bad, I was hoping that it would.  Myles

[Altera_Forum]

The issue of hold false paths as you last put is correct. 

 I am not sure about your case as there are exceptions depending on the case. Here are some points to check: (1) whether your case is same edge launch/latch or opposite edge launch/latch. This depends on your interface design. (2) whether data is edge aligned (zero delay without PLL or with PLL set to zero). Or that it is not edge aligned (termed centre aligned) (3) you will need to apply exceptions to inputs and outputs (4) you will need to set delay values as required by external delays and device.  You will see examples in the doc AN 433: Constraining and Analyzing Source-Synchronous Interfaces

[Altera_Forum]

--- Quote Start ---    I am not sure about your case as there are exceptions depending on the case. Here are some points to check: (1) whether your case is same edge launch/latch or opposite edge launch/latch. This depends on your interface design. (2) whether data is edge aligned (zero delay without PLL or with PLL set to zero). Or that it is not edge aligned (termed centre aligned) (3) you will need to apply exceptions to inputs and outputs (4) you will need to set delay values as required by external delays and device.  You will see examples in the doc AN 433: Constraining and Analyzing Source-Synchronous Interfaces  --- Quote End ---    1- same edge 2- center aligned  Thanks for the pointer to AN 433. I'll look at it again.

[Altera_Forum]

I 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?

[Altera_Forum]

--- Quote Start ---  I recommend against cutting rise->fall or whatever transfers. ...  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.  --- Quote End ---    I see your point. I'll remove the false path statements. I was trying to make the output simpler.    --- Quote Start ---   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?  --- Quote End ---    Yes it's shifting it.  I think this is probably due to my misunderstanding of the data sheet. I was looking at the clock output skew values, and didn't realize that it included the phase shift.  I guess I should have been looking at the minimum and maximum setup and hold times instead.  So if I have maximum setup and hold times of 175 ns, does that mean that those become the output delays?  Thanks, Myles

[Altera_Forum]

--- Quote Start ---  I've been working my way through the tutorials and Rysc's document.  --- Quote End ---    Rysc,  I appreciate the time you put into the User Guide. I found it very useful. I have some constructive feedback for you, but I can't send you a private message. If you're interested, let me know how you'd like to receive it.  Thanks, Myles