Forum Discussion

Honored Contributor

15 years ago

Source synchronous constraints for both edges in TimeQuest

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?

- Why is this behavior correct?

Thanks,

Myles

12 Replies

Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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

Honored Contributor

15 years ago

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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
Thanks for the information. Indeed that is correct but my eyes never spotted the hold false paths correctly from altera examples.
Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
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?

Forum Discussion

Source synchronous constraints for both edges in TimeQuest

12 Replies

Recent Discussions

Duplicate_hierarchy_depth / duplicate_register

Timing analysis - long combinational path

Automatically added negative node for TDS output doesn't work with Agilex 5

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer