Timing constraints dont appear to work on Strobed outputs

[Altera_Forum]

Hello, 

I have the following SDC constraints defined, which are just a test to constrain three signals from my FPGA feeding a TI DSP :   Output signals from FPGA to DSP: had[1], had[0], hrnw  # create setup hold board delays from TI DSP datasheet:  # DSP Setup & Hold timing HAS Strobe low before HCNTL[1:0] and hrnw set HAS_Setup 5 set HAS_Hold 3# set max and min est DSP to FPGA delays set Max_fpga2dsp 2 set Min_fpga2dsp 1 set HASOutputDelayMax [expr $HAS_Setup + $Max_fpga2dsp] set HASOutputDelayMin [expr $HAS_Hold + $Min_fpga2dsp]  # Setup clocks  # Set period for EHPI base clock set ehpi_base_period 25.201# create constraint for input clock pin to PLL create_clock -name inclk0 -period $ehpi_base_period [get_ports inclk0] derive_pll_clocks set_clock_groups -asynchronous  -group {inclk0  EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] }# Create Generated Clock for STROBE write output HAS# create_generated_clock -name HAS_STROBE -source EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0] [get_ports has_n] create_generated_clock -name HAS_STROBE -source [get_pins {EHPI_PLL_inst|altpll_component|auto_generated|pll1|clk[0]}] [get_registers {bidir_interface:uut|has_n}]   derive_clock_uncertainty  # Setup output constraints on three output signals: had[1], had[0], hrnw  # *************************************************************************************************************# Constrain EHPI to DSP CTRL strobed output paths# *************************************************************************************************************# Output MAX delay on HAS bus : using EHPI Virtual Address strobe set_output_delay -clock HAS_STROBE -max $HASOutputDelayMax [get_ports {had[0] had[1] hrnw}]# Output MIN delay on HAD bus : using EHPI Virtual Address strobe set_output_delay -clock HAS_STROBE -min $HASOutputDelayMin [get_ports {had[0] had[1] hrnw}]   I compiled the design...run TimeQuest....and get the following report after generation of all reports :   report_timing -setup -npaths 100 -detail full_path -to_clock HAS_STROBE -panel_name "HAS_STROBE||setup" Info: Report Timing: No setup paths were found Info: -to_clock [get_clocks {HAD_STROBE}] Info: -setup Info: -npaths 100 Info: -detail full_path Info: -panel_name {setup} 0 0.000   I was expecting to see three setup paths here ....anybody know what is wrong ?   Also, how would i tell TimeQuest that the Strobe clock usues a negative edge ?   Many thanks for your help ! :)

[Altera_Forum]

As far as I know, Timequest checks the tSU/tH on any path between two internal fpga registers.  

 Though an external device input registers or external device output registers are part of the same RTL chain from designer perspective but timequest does not report on these external paths as violations but rather as tSU/tH on fpga input registers or tCO on its output registers and it is left up to you to check if it is ok.   Thus many designs may seem passed timing falsley if you enter wrong external requirement figures. This is very common...  The same applies to recovery/removal and unless reset is generated internaly then timequest has no idea about when it changes. Though I think there is a way to inform it using max/min input delay on reset pin.

[Altera_Forum]

Hi Kaz, 

Yes thanks for the response....and i get your drift ! You have to be careful to extracty the rigt timing values form the datasheet , and know how to apply them correctly in SDC format. Its very easy to misinterpret this data and get it wrong, so the FPGA passes tming analysis but because the constraints dont match reality, it still fails in the ral world.   cheers :)