Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
19492 Discussions

Very high interconnect delay

frycoo
Novice
152 Views

Hello,

I came across a strange problem. Bringing it to its simpliest version I got the situation as show below.

rtl.png

Detailed implementation:

impl.png

The device is 10M08SAU169I7G (Quartus17.1 Lite).  Alongside with logic I have output timing constraints as follows:

```tcl

derive_pll_clocks -create_base_clocks -use_net_name
derive_clock_uncertainty

create_generated_clock \
-name FPDL_GEN_CLK \
-source [get_pins {clk_buf_inst|clk_out_buf_inst|gpio_one_bit.i_loop[0].altgpio_bit_i|out_path_ddr.fr_out_data_ddio|clkhi}] \
[get_ports {PPCLK_B}]


set_output_delay -clock [get_clocks FPDL_GEN_CLK] -max 2.5 [get_ports {PVSYNC}]set_output_delay -clock [get_clocks FPDL_GEN_CLK] -min -2.5 [get_ports {PVSYNC}]

```

Only CLK_FPDL has location assignment, everything else is unconstrained.

 

Timing is not met (results below).

timing.png

The question is why is the interconnect delay so high?  How to deal with it?

The curious thing is, when I change output delay constraints clock to c0, the same interconnect is nearly 0.

yours sincerely

PF

0 Kudos
1 Solution
skyjuice
Employee
126 Views

The design has such a high interconnect delay is due to the huge clock skew. In order to meet hold time requirement, the router will need to add additional routing delays. 

 

Why huge clock skew you might ask? That's because this is a cross-clock transfer. 

View solution in original post

2 Replies
skyjuice
Employee
127 Views

The design has such a high interconnect delay is due to the huge clock skew. In order to meet hold time requirement, the router will need to add additional routing delays. 

 

Why huge clock skew you might ask? That's because this is a cross-clock transfer. 

frycoo
Novice
117 Views

Hello skyjuice,

Thanks for putting me on the right tracks. Although I don't know about cross-clock transfer (could you possibly point me to some literature?). What I understand from your response is clock skew is so high, partially, due to use of DDIO buffer (which introduce additional delay to the required path). Removing it and modifying output delays to be referenced to FPGA pin solved the problem.

 

Modified constraints:

set_output_delay \
    -clock [get_clocks pll_quarterRes:pll0|altpll:altpll_component|pll_quarterRes_altpll:auto_generated|wire_pll1_clk[0]] \
    -reference_pin [get_ports PPCLK_B] \
    -max 2.5 [get_ports {PVSYNC}]
 
#set_output_delay -clock [get_clocks FPDL_GEN_CLK] -min -2.5 [get_ports {PVSYNC}]
set_output_delay \
    -clock [get_clocks pll_quarterRes:pll0|altpll:altpll_component|pll_quarterRes_altpll:auto_generated|wire_pll1_clk[0]] \
    -reference_pin [get_ports PPCLK_B] \
    -min -2.5 [get_ports {PVSYNC}]
Reply