Timequest...need expert

[Altera_Forum]

Hi all, 

first of all, sorry for a new thread on this topic, but I don't understant exactly how to proceed...  The FPGA receive clocks and data from an external chip (on another demo board) with the following charcteristics:  1) Clk freq is 60MHz. 2) The data output delay from clock varies from 2 to 5 ns.  These datas come from chip datasheet but (obviously) don't take into account board delays...these relations are valid only for the chip...  I've read many docs on timequest but the topic is stiil not completely clear(the syntax could be wrong):  1) need to generate the clock inside fpga create_clock -name fpga_clk -period 16.6 [get_ports clk_in] 2) need to generate external clock (for the chip providing clock) ... (need some phase relationship???) create_clock -name ext_clk -period 16.6 3) add I/O constraints relative to ext_clk from datasheet set_input_delay -clock ext_clk -max 5.0 [get_ports din*] set_input_delay -clock ext_clk -min 2.0 [get_ports din*]  My questions are: Are those the only constraints I need? How take into account the board delays?  Altera docs start from kwnoledge of board delays and relationship between clock and data...or they use the skew approach...I don't understand how to use my datasheet parameters to implement one of the two methods...  I need help THX in advance Carlo

[Altera_Forum]

Add the board delays from upstream device to FPGA into the input delay. So if the delays are max 200ps and min 100ps, then the max min values would change to 5.2 and 2.1ns. 

 Or are you talking about clock delays? You didn't state how the clock is laid out, i.e. is it a clock generator that feeds both devices, or does the upstream device send a clock with the data? If it's the first one, you can roll those delays into the external delays too. For example, if the max delay would be 5.2 + $Max_clk_delay_to_upstream_chip - $Min_clk_delay_to_FPGA. I add the clock delay to the upstream device because if this gets longer, then the data just comes out later. We subtract the clock delay to the FPGA because as this delay gets longer, it gets easier to meet timing since the FPGA input register is latching the data later in time. I used the specific max and mins to make the -max value the worst case possible.  For the -min, do the opposite, i.e. 2.1 + $Min_clk_delay_to_upstream_chip - $Max_clk_delay_to_FPGA. If it's clock being sent with the data, please describe the relationship more.  Finally, make sure you look at it in TimeQuest and try to understand that. Run: report_timing -setup -npaths 100 -detail full_path -from [get_ports din*] -panel_name "s: din -> *" report_timing -hold -npaths 100 -detail full_path -from [get_ports din*] -panel_name "h: din -> *" Then analyze the waveform view and the Data Path tab. The latch and launch edges are based on your clocks. The iExt delays are the -max and -min values. Everything is based on the FPGA. If you understand that, it goes a long way toward feeling good about your constraint.

[Altera_Forum]

Thanks for the answer....I'm new with timing constraint and I need a little help...:) 

 I need to interface an ULPI transceiver to my FPGA...the transceiver generates clocks and data for the fpga as in the attach...(clock out and data out)  As you can see data follows the rising edge fo clock after min 2 ns and max 5 ns.... I suppose that this should be the input delay (min, max) to impose if we hadn't the delays for the links between transceiver and fpga...this delays are not neglectable and must be taken into account but how???  I could use an FPGA centric method (skew method) to avoid taking into account these delays...but I don't understand how to proceed in this direction...i.e. not knowing board delays means that I don't the relation between clock and data at FPGA input...therefore I don't know how to proceed...  Any help will be welcome...  THX in advance Carlo

[Altera_Forum]

What's the clock rate?  

Technically, if you don't know the board delays you can't do it right. (What if there were 20ns of board skew between clock and data?) Less technically, let's just assume they clock and data are the same delay for now. Unless something is really messed up, that's probably pretty accurate. The nice thing with that is that they cancel out. With that, what you have is correct. Just say 2ns and 5ns. When you look at the timing report -setup, you will see that your setup relationship is the clock period. The data gets to the FPGA 5ns later, and basically that means the FPGA needs to get the data to the register in (clock_period - 5ns) It will also subtract the clock delay in the FPGA, which is correct.

[Altera_Forum]

Sorry...you are right...frequ is 60MHz...16,6 ns.... 

 Thanx Carlo