Help with timequest inputs constraints

--- Quote Start ---

Hi, I'm trying to define input constraints for an input data bus received by an A2D. The launch clock in the A2D is a derived PLL clock which is sent from the FPGA to the A2D and the latch clock is also a derived PLL clock, both clocks are generated by the same PLL and have the same frequency (40MHz), the A2D clock has a phase shift of 180 degrees (The clocks schematic is attached). The A2D data is launched in the A2D clock (the shifted clock) falling edge and latched in the FPGA clock rising edge, the data clock to out delay (in the A2D) is 10ns. My SDC file is attached, I'm not sure what is wrong with it but i'm getting paths with negative setup slack in the timequest analysis results, i have attached a screenshot of the results. What am i doing wrong? Should i define the A2D clock as a virtual clock? Any other ideas? Thanks!

--- Quote End ---

check your setup relationship as it could be zero due to the way clocks relate. if so you need multicycle of 2 for setup, 1 for hold on input registers path

Thanks for your reply, from some reason the timequest doesn't show the setup relationship in the i/o path timing report, the clock skew and data delay are not shown as well (i read the timequest user guide and it seems from its screen shots that those parameters should have been shown). How can i check the setup relationship? I'm using quartus 8.0.

Regarding the multicycle, i think it won't be right since the input data is changed in every clock edge. Maybe i have problems with the clocks definitions? How should I define a clock which is generated by a PLL and sent to an external device which launches the FPGA input data?

--- Quote Start ---

Thanks for your reply, from some reason the timequest doesn't show the setup relationship in the i/o path timing report, the clock skew and data delay are not shown as well (i read the timequest user guide and it seems from its screen shots that those parameters should have been shown). How can i check the setup relationship? I'm using quartus 8.0.

Regarding the multicycle, i think it won't be right since the input data is changed in every clock edge. Maybe i have problems with the clocks definitions? How should I define a clock which is generated by a PLL and sent to an external device which launches the FPGA input data?

--- Quote End ---

go to tools => timequest => update timing => check top failing paths.

The multicycle will be needed if timequest shows setup relationship less than clk period. This is not multicycle for increasing relationship to > 1clk period but to get it to 1 clk period. Let us first see that relationship then we can try explain results. we are talking about different clocks...

There are two PLL clocks- PLL_CLK[2] is the latch clock and PLL_CLK[3] is the launch clock and its shifted in 180 degrees. I tried to set the virtual clock as the launch clock and the setup relationship is still not shown.

How can the timequest know the setup relationship between PLL clock and virtual clock? All it knows about the virtual clock is its frequency (which is identical to the latch clock's frequency) but it knows nothing regarding the phase shift...

--- Quote Start ---

There are two PLL clocks- PLL_CLK[2] is the latch clock and PLL_CLK[3] is the launch clock and its shifted in 180 degrees. I tried to set the virtual clock as the launch clock and the setup relationship is still not shown.

How can the timequest know the setup relationship between PLL clock and virtual clock? All it knows about the virtual clock is its frequency (which is identical to the latch clock's frequency) but it knows nothing regarding the phase shift...

--- Quote End ---

If you declare virtual clock but without any further reference at set_input_delay then it is doing nothing at all and you can delete it.

Your PLL clk(3) sources the ADC and is not the launch clk. The launch clk is that clk(3) as seen at ADC clk input pin (this is not same as clk(3) at fpga)

Your 10 ns tCO is relative to ADC clk pin and it will be wrong to relate it otherwise.

Virtual clk is taken as the launch clk at external device and so your 10 ns relates to virtual clk. Timequest looks at the relationship between virtual clk and base clk that eventually latches at input register (i.e. pll clk(2)) and so it knows about phase details. what it needs is relationship of virtual clk to base clk and that is your entry to make on top of input delay setting.

Try a simple program, set virtual clk as latch clk in terms of phase and speed then set a tiny delay on either and see how faiure is reported.

The use of virtual clk is particularly useful if your data and clk are not coming to fpga in parallel as in your case since you declare virtual clk, set input delat relative to it then leave it to tool to work out relation to latch clk.

"Your PLL clk(3) sources the ADC and is not the launch clk. The launch clk is that clk(3) as seen at ADC clk input pin (this is not same as clk(3) at fpga)"

Why? i guess that because of the following:

1. The clock's routing from the pll output to the fpga clock output pin.

2. The fpga output pin delay.

3. The board delay.

Is that correct?

"what it needs is relationship of virtual clk to base clk and that is your entry to make on top of input delay setting."

Should the input delay in the constraint be calculated as: source_reg_tCO+pll_to_output_pin_routedelay+output_pin_delay+board_route_delay

?

--- Quote Start ---

"Your PLL clk(3) sources the ADC and is not the launch clk. The launch clk is that clk(3) as seen at ADC clk input pin (this is not same as clk(3) at fpga)"

Why? i guess that because of the following:

1. The clock's routing from the pll output to the fpga clock output pin.

2. The fpga output pin delay.

3. The board delay.

Is that correct?

--- Quote End ---

There are two scenarios at input to FPGA:

1) you either receive data with its clock, source synchronous and then set_input_delay is equal to data offset from its clock at fpga pins. So if you know tCO of device and board delays then you can estimate this offset, or actually measure it.

2) use model for launch clk (virtual clk) and enter tCO as given by device data sheet for your set_input_delay relative

Then tell the tool of any time offset between virtual clk and base clk in the waveform description. So you can delay either as required. For example in your case virtual clk is late relative base clk by amount of board delay. This way you don't have to calculate things yourself.

It remains important to find out the setup relationship at failing io

--- Quote Start ---

There are two scenarios at input to FPGA:

For example in your case virtual clk is late relative base clk by amount of board delay. This way you don't have to calculate things yourself.

--- Quote End ---

What about the clock output pin delay and the internal routing delay from the PLL output to the output pin? how can the timequest know those delays? it doesn't know that this virtual clock has also a delay on its way from the pll output to the fpga output (besides the board delay). How can i find those delays?