Honored Contributor
Honored ContributorI have these background info that may help.
1) First check your DAC datasheet. if you are lucky your dac (if advanced type)may have auto timing adjustment. In that case, you can keep TimeQuest relaxed. 2) Your interface is not the classic source synchronous. Your Dac clk is opposite that of its data. For TimeQuest source synchronous modelling, You might consider your virtual clk to represent a non-existing clk that goes to DAC with data. This clk will should cancel the board delay with respect to actual DAC clk(inside DAC). The physical DAC clk travels first to FPGA then data goes back to same clk inside DAC. So adjust phase of this virtual clk accordingly. 3) The important issue to you should be optimisation rather than getting Tsu/Th as requested. Even if Quartus gets your Tsu/Th it must optimise it in the middle of valid timing window!! otherwise there is no point in the whole technology. The optimum point is here: DAC Tsu is .5 and Th is 1.5 (incidentally you might be wrong here, Th is usually very small) then your valid window is 6.7 -(.5 + 1.5) = 4.7. FPGA must output data at the mid point of this valid window i.e. at 1.5 + 4.7/2 = 3.35 with respect to virtual clk edge Th*** valid window***Tsu ------ --------------- ---- ...................|................. I am not used to TimeQuest yet but with classic timing I will set the Tco directly on data and must achieve it. If not I use a PLL until achieved. I agree with the issue of falling/riding edge being not necessry and complicating. Multicycle has no place here.
