TimeQuest Passes Hardware Fails

[Altera_Forum]

Hello Timequest user community. 

   I have been scratching my head trying to figure out where I am going wrong with a timing problem I have recently experienced on an FPGA. The circuit in the attached "Circuit and waveforms.jpg" shows a simplified version of a circuit that I am attempting to constrain using Timequest. The circuit is designed to align the rising edge of a pulse with "Source Clock", which is external to the FPGA. To achieve this two external flip flops are used to sample the pulse. Each flip flop is clocked by a delayed version of Source Clock. One flip flop is clocked by a clock that is delayed by 13.268ns relative to Source Clock and the other is clocked by a clock that is delayed by 13.468ns relative to Source Clock. The flip flops in the FPGA are used to capture the results of the two external flip flops. They are clocked from a clock that is delayed by 10.48ns relative to Source Clock. In operation the pulse is delayed through the "Pulse Delay" block until the first non-zero value read from the flip flops in the FPGA will be 0 and 1 for the start of the pulse. 0 for the external flip flop that is clocked by the 100ps advanced clock (13.268) and 1 for the external flip flop that is clocked by the 100ps delayed clock (13.468). Simple right? (Sorry about the arbitrary numbers but I wanted to include my screen captures so had to use the real values.)  To constrain this in Timequest one would use the following constraints..... # for the FPGA clock create_clock -name {FPGA_LATCH_CLOCK} -period 20 -waveform 10.48 20.48 [get_ports {FPGA_LATCH_CLOCK}]# for DFF delayed clock (0.1ns offset) create_clock -name DFF1_CLOCK -period 20 -waveform 13.268 23.268# for DFF delayed advanced (-0.1ns offset) create_clock -name DFF2_CLOCK -period 20 -waveform 13.468 23.468# to allow quartus to analyse the timing  set_input_delay -min 0.614 -clock DFF1_CLOCK [get_ports FPGA_DFF1_IN] set_input_delay -max 1.331 -clock DFF1_CLOCK [get_ports FPGA_DFF1_IN] set_input_delay -min 0.614 -clock DFF2_CLOCK [get_ports FPGA_DFF2_IN] set_input_delay -max 1.331 -clock DFF2_CLOCK [get_ports FPGA_DFF2_IN]  The numbers used for the min and max input delay are based on worst case component variation and trace length differences   Up until recently this has been working well. The FPGA has always have passed timing and I've never experienced a problem with the circuit. But the circuit failed the other day and the timing passed? I set the circuit up as shown in the timing diagrams in the attached jpg. The pulse occurred well before the rising edge of the respective external flip flop clock edges and I verified that the output of both external flip flops were rising high on the "same" clock edge using an oscilloscope. But the first value latched by the FPGA flip flops was 0 and 1 (rather than 1 and 1 as expected for this condition). The answer seems to be that one of the FPGA flip flops is not meeting timing, particularly setup time. I have verified this with a signaltap. I was also able to verify this by delaying the FPGA_LATCH_CLOCK (using the Delay clock network) out to around 11.3ns (increase of around 800ps) and then the FPGA/Circuit started to work, in that the FPGA flip flops captured the expected 1,1 from the external flip flops.  But Timequest tells me there is loads of headroom and I need an image that will recompile successfully. Attached are pictures of the Timequest setup and hold reports for the offending flip flop (only the one of the pair that is failing in hardware). Please note that the clocks and registers are not the same name as my simplified example but it should be reasonably obvious.  I figure I must be doing the constraints wrong but everything seems to look OK to me. I have verified the respective clock offsets with an oscilloscope. They look fine at around 10 and 13ns.    Has anyone had any experience testing/verifying Timequest in this way. Any ideas/help would be greatly appreciated.