Help with timequest inputs constraints

[Altera_Forum]

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!

[Altera_Forum]

--- 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

[Altera_Forum]

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?

[Altera_Forum]

--- 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...

[Altera_Forum]

I tried that, no setup relationship is shown, it shows the columns "slack", "from node", "to node", launch clock" and "latch clock", you can see it in the attached screen shot. Maybe its because quartus 8.0 is an old version?

[Altera_Forum]

No it is not showing it? I noticed your adc data launch clk is from pll according to the TQ report and I also noticed you have set that in your sdc file. The launch clk is the virtual clk not pll clk. PLL clk is the latch. May be that is why setup relationship is not shown in the report.

[Altera_Forum]

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...

[Altera_Forum]

--- 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.

[Altera_Forum]

"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 ?

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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?

[Altera_Forum]

--- Quote Start ---  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?  --- Quote End ---    The user should provide relation of virtual clk to base clk (at pin of fpga). This has nothing to do with PLL and internal fpga or clk out pin. Just delay from base clk pin at fpga to virtual clk pin on device. The tool needs that and leave the rest for it. The tool will calculate PLL effect as it generates latch clk at the receiving end  In your case your base clk is 24MHz I believe. yet your device clk is 40. I need to see what setup relationship the tool gets. If you get one clk period or so then that is ok . If you are getting zero or very tight then you need multicycle to correct the tool's behavoiur. If unsure about any failure you need to see the relationship as seen by tool and you coud be surprised sometimes. On the other hand there is no point passing timing when the constraints are wrong. and it is unfair when it fails timing but due to incorrect relationship.

[Altera_Forum]

I tried again to check the setup relationship between those clocks, but unfortunately without success. 

That is what i wrote in the sdc file:  create_clock -period 41.666 -name main_clk_in_24 [get_ports {clk_24_a}]  create_clock -period 20.83 -name usb_if_in_clk_48 [get_ports {clk_usb_if}]  create_clock -period 25 -name adc_clk  derive_pll_clocks set_clock_groups -exclusive   -group [get_clocks {u_fpga|RT_acq_digital_design|clk_manage|u_pll|altpll_component|pll|clk[0]}]   -group [get_clocks {u_fpga|RT_acq_digital_design|clk_manage|u_pll|altpll_component|pll|clk[2]}]  -group [get_clocks {u_fpga|RT_acq_digital_design|clk_manage|u_pll|altpll_component|pll|extclk[0]}]   -group [get_clocks {main_clk_in_24}]   -group [get_clocks {usb_if_in_clk_48}] \  set_input_delay -clock adc_clk -max 10 [get_ports {adc_b*}] -clock_fall set_input_delay -clock adc_clk -min 5 [get_ports {adc_b*}] -clock_fall  I chose "check timing" and got in the report the same columns as before: "Slack", "from node", "to node", launch clock", "latch clock".  Are you sure that Quartus 8.0 can show the setup relationship?

[Altera_Forum]

you better download a free latest version at least to get view of what you want.  

version 8 is too old though it was new at the time of release, with as usual claims of fantastic features.

[Altera_Forum]

O.K i will try to download a newer version, thank you very much for your help!