--- Quote Start ---
Somewhere, you have another constraint targeting the port CLOCK_50_B5B based on the warning you got. Whatever that constraint is is part of what's messing things up.
The failing path report is indicating that clk_100, your virtual clock, is the latch clock for the failing path, implying that the failing path is an output path. Is this correct? Is clk_100 driving whatever device you are feeding? Check your set_input_delay and set_output_delay constraints. Make sure that the correct virtual clock is referenced in them (upstream device virtual clock for set_input_delay; downstream virtual device clock for set_output_delay).
Maybe just post your whole .sdc! That might make it easier to figure this out.
--- Quote End ---
Thank you, sstrell.
Yes, clk_100 (stems from an PLL and source ref clk is CLOCK_50_B6B) is driving also the external hardware, which is connected via hsmc adapter. clk_100 is outputed at ALTDDIO_OUT. And yes, the failing_path is an output path. I already set the constraints for the output path, but only the output delay. This is recommended from the manufacturer of the external hardware interface connected to my desgin. I also have a working example from the manufacturer where failing path are not occuring. :confused:
What confuses me is the use of the word port and pin in vhdl language. I see that the create_clock command uses get_ports at the end, bu in my understandin CLOCK_50_B5B is an input pin and not a port?! I'm also using ALTCLKCTRL IP Cores to promote the outputs of the PLL through the device.
Here is the whole SDC-File.
create_clock -name CLK1 -period 20.0
create_clock -name CLK2 -period 20.0
create_clock -period 10 -name clk_100
derive_pll_clocks
derive_clock_uncertainty
set_output_delay -add_delay -rise -max -clock 6.000
set_output_delay -add_delay -rise -max -clock 6.000
set_output_delay -add_delay -rise -max -clock 6.000
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_false_path -from -to
set_multicycle_path -from {ram_ip_control:ram_ip_control_inst1|avl_address*} -to {ram_ip_control:ram_ip_control_inst1|avl_writedata*} -setup -end 6
set_multicycle_path -from {ram_ip_control:ram_ip_control_inst1|cal_data*} -to {ram_ip_control:ram_ip_control_inst1|avl_writedata*} -setup -end 6
set_multicycle_path -from {ram_ip_control:ram_ip_control_inst1|avl_address*} -to {ram_ip_control:ram_ip_control_inst1|avl_writedata*} -hold -end 6
set_multicycle_path -from {ram_ip_control:ram_ip_control_inst1|cal_data*} -to {ram_ip_control:ram_ip_control_inst1|avl_writedata*} -hold -end 6
Again, CLOCK_50_B5B is only driving PLL of hardmemory controller. This has an additional sdc file (fpga_lpddr2_p0.sdc), which is auto generated. Perhaps herein lies the problem of double constraining the same clk? But then one may wonder how this could create a failing path at the output? CLOCK_50_B5B is not driving the clk_100.
Fitting the log says:
Info (332111): Found 27 clocks
Info (332111): Period Clock Name
Info (332111): ======== ============
Info (332111): 33.333 altera_reserved_tck
Info (332111): 20.000 CLK2
Info (332111): 10.000 clk_100
Info (332111): 20.000 CLOCK_50_B5B
Info (332111): 3.030 DDR2LP_CK_n
Info (332111): 3.030 DDR2LP_CK_p
Info (332111): 3.030 DDR2LP_DQS_n_OUT
Info (332111): 3.030 DDR2LP_DQS_n_OUT
Info (332111): 3.030 DDR2LP_DQS_n_OUT
Info (332111): 3.030 DDR2LP_DQS_n_OUT
Info (332111): 3.030 DDR2LP_DQS_p_IN
Info (332111): 3.030 DDR2LP_DQS_p_OUT
Info (332111): 3.030 DDR2LP_DQS_p_IN
Info (332111): 3.030 DDR2LP_DQS_p_OUT
Info (332111): 3.030 DDR2LP_DQS_p_IN
Info (332111): 3.030 DDR2LP_DQS_p_OUT
Info (332111): 3.030 DDR2LP_DQS_p_IN
Info (332111): 3.030 DDR2LP_DQS_p_OUT
Info (332111): 3.333 pll_inst_100|pll_100_inst|altera_pll_i|general.gpll~FRACTIONAL_PLL|vcoph
Info (332111): 10.000 pll_inst_100|pll_100_inst|altera_pll_i|general.gpll~PLL_OUTPUT_COUNTER|divclk
Info (332111): 3.030 ram_inst1|fpga_lpddr2_inst|fpga_lpddr2_p0_sampling_clock
Info (332111): 3.030 ram_inst1|fpga_lpddr2_inst|pll0|pll_afi_clk
Info (332111): 6.060 ram_inst1|fpga_lpddr2_inst|pll0|pll_afi_half_clk
Info (332111): 15.151 ram_inst1|fpga_lpddr2_inst|pll0|pll_avl_clk
Info (332111): 15.151 ram_inst1|fpga_lpddr2_inst|pll0|pll_avl_phy_clk
Info (332111): 45.454 ram_inst1|fpga_lpddr2_inst|pll0|pll_config_clk
Info (332111): 3.030 ram_inst1|fpga_lpddr2_inst|pll0|pll_dq_write_clk
...
EDIT:
Do I have to use create_generated_clock for clk_100 because clk_100 is not a clock which is coming into the fpga but is created via PLL from another clock?
Could this be the problem and cause that timequest is reporting failing path?
Thank you.
Honored Contributor
