Cyclone IV - timing problem with I/O pins sharing Vref

[Altera_Forum]

As a bit of background, here is what I am trying to do. 

 I have a fairly simple synthesizer design hosted on an EP4CE15E22C7N (EQFP), which is driving an AD9744 parallel load DAC. The design is supposed to operate at 100MHz. Architecturally, the DAC and FPGA share a common clock, which is split and fed to both devices. The board designer serpentined the clock traces until they are almost identical - down to literally a couple of mils delta. He was thinking that it would be possible to drive the data from the FPGA to the DAC as if they were fully synchronous. I'm not clear if that was a good idea or not, but at least on the scope, they are right on top of each other.  I have tried to constrain the I/O to the DAC using the SDC file with a set_output_delay command. I did assume the board clock skew was close enough to ignore, calculated an estimate of the trace skew at ~600ps (these are surface traces on FR4, and are about 300-340 mils in length). Tsu on the DAC is 2ns, Th is 1.5ns. In theory, I should have plenty of time to get between the two parts.  set_output_delay -add_delay -clock [get_clocks {Master_Oscillator}] -max 2.600 [get_ports {DAC_Data [*]}] set_output_delay -add_delay -clock [get_clocks {Master_Oscillator}] -min -0.900 [get_ports {DAC_Data [*]}]  When I checked, the failing pins are always the same 4 out of the 14. On closer inspection, they have an alternate Vref function, which I'm assuming is contributing to the larger data delay.  Two questions: 1) did I calculate the set_output_delay command correctly, and  2) Is there anything short of using a slower sample clock I can do to fix this if so?  I am not off by much: -0.382 Composite_Out_q[9] DAC_Data[9] Master_Oscillator Master_Oscillator 10.000 -2.462 5.300 -0.373 Composite_Out_q[3] DAC_Data[3] Master_Oscillator Master_Oscillator 10.000 -2.453 5.300 -0.369 Composite_Out_q[13] DAC_Data[13] Master_Oscillator Master_Oscillator 10.000 -2.449 5.300 -0.356 Composite_Out_q[2] DAC_Data[2] Master_Oscillator Master_Oscillator 10.000 -2.436 5.300  vs  1.614 Composite_Out_q[8] DAC_Data[8] Master_Oscillator Master_Oscillator 10.000 -2.462 3.304 1.614 Composite_Out_q[7] DAC_Data[7] Master_Oscillator Master_Oscillator 10.000 -2.462 3.304  Thanks! -Seth

[Altera_Forum]

Hi Seth, 

 The timing difference of the VREF pins is warned about in the newer handbooks.   I stumbled across this timing issue a while back and created an example design. Take a look at post# 7 in this thread  http://www.alteraforum.com/forum/showthread.php?t=31457  The PDF in that post shows the results of a timing analysis, and shows how the VREF pins are the source of an extra delay.  The VREF pins have additional capacitance on them.  This doesn't really help you solve your problem, but at least it confirms you will see a timing difference when using VREF pins.  Cheers, Dave

[Altera_Forum]

I believe your figure for min should be -2.1 ns. The max of 2.6 ns is ok. The idea is that no data transition should occur between max and min but is allowed between min and max within the 10 ns clock period. 

 This leaves 5.3 ns margin. Even tougher than you already have. I suggest you then look for best timing window for fitter to pass. I mean try sliding the 5.3 ns window across until timing passes (through sdc) and once found then apply a PLL to phase shift your fpga clock to get a match for your figures. You may set those failing pins to different figures. Also make sure you set your outputs to use io registers.

[Altera_Forum]

I think in this case it may be better to punt, and just choose a slower oscillator. Unfortunately, this means physically replacing a part, but we are well over the "minimum" sampling frequency to get adequate results from the synthesizer. The previous incarnation was running fine with a 66MHz sample frequency. Since we have no specific requirement for anything above that, it seems rather pointless to keep fighting the hardware. 

 On the bright side, this does explain the weird signals I was seeing on my scope. The sign bit (bit 13) is one of the bits affected, and there is at least one other high-order bit (9) with the same problem.