LVDS Sampling Data

[Altera_Forum]

Hi all, 

I have on my board double data rate (DDR) LVDS bus samped by clock of 168Mhz. I sampled the LVDS bus using ALTDDIO mega function. The problem is that i have skew between clock and data of min -500ps and max 500ps, which mean that i need to shift the clock at least 500ps from the data or otherwize. I preffered not to use PLL, is anyone know if i can use timequest constraint for this problem ?, and what the constraint should be? Thanks Guys i.e  I added picture describing the problem.

[Altera_Forum]

create_clock -period 5.952 -name fpga_clk [get_ports fpga_clk] 

create_clock -period 5.952 -name ext_clk derive_pll_clocks ;# (Not doing anything, but I assume you have PLLs doing somethign else) derive_clock_uncertainty set_input_delay -clock ext_clk -max 0.5 [get_ports {LVDS_DATA[*]}] set_input_delay -clock ext_clk -min -0.5 [get_ports {LVDS_DATA[*]}] set_input_delay -clock ext_clk -max 0.5 [get_ports {LVDS_DATA[*]}] -clock_fall -add_delay set_input_delay -clock ext_clk -min -0.5 [get_ports {LVDS_DATA[*]}] -clock_fall -add_delay  ----------- That describes what's going on. Note that the launch and latch clock edges are aligned, which means data sent from say, a rising launch edge, will be clocked in by the falling latch edge(i.e. the next edge). So to get the optimal solution, Quartus has to add delays to the data. You may actually want to capture on the same edge, i.e. have the clock delay be longer. This is probably the case, since your clock delay to the I/O registers will be long but the data delay is short. In that case, you need to tell TQ to do different edge transfers then the default. This is done like so: set_multicycle_path -rise_from [get_clocks ext_clk] -rise_to [get_clocks fpga_clk] -setup 0 set_multicycle_path -fall_from [get_clocks ext_clk] -fall_to [get_clocks fpga_clk] -setup 0 (If you draw out the waveforms and look at the default relationships, this one hopefully makes sense. Be sure to look at how multicycles work on my TQ guide on alterawiki.com.) Finally, the resource the clock uses will be determined by Quartus, but not by timing constraints. It can use a global, regional or local routing(depending on FPGA). They all have different delays and can make a difference.

[Altera_Forum]

--- Quote Start ---  create_clock -period 5.952 -name fpga_clk [get_ports fpga_clk] create_clock -period 5.952 -name ext_clk derive_pll_clocks ;# (Not doing anything, but I assume you have PLLs doing somethign else) derive_clock_uncertainty set_input_delay -clock ext_clk -max 0.5 [get_ports {LVDS_DATA[*]}] set_input_delay -clock ext_clk -min -0.5 [get_ports {LVDS_DATA[*]}] set_input_delay -clock ext_clk -max 0.5 [get_ports {LVDS_DATA[*]}] -clock_fall -add_delay set_input_delay -clock ext_clk -min -0.5 [get_ports {LVDS_DATA[*]}] -clock_fall -add_delay   --- Quote End ---   You create two clocks: the incoming clock connected to pin fpga_clk, and a second clock not connected to a pin. As they have the same period they fully overlap each other? Can't we do it in one go? like :  create_clock -period 5.952 -name fpga_clk set_input_delay -clock fpga_clk -max 0.5 }] set_input_delay -clock fpga_clk -min -0.5 }] set_input_delay -clock fpga_clk -max 0.5 }] -clock_fall -add_delay set_input_delay -clock fpga_clk -min -0.5 }] -clock_fall -add_delay

[Altera_Forum]

Yes, you could. I find it good practice to do a virtual clock when it explains what's going on. (About the only time I don't use a virtual clock is when the FPGA sends a clock off chip, which uses a generated clock on the output port).  

What you have gets the same analysis. The only true difference is that derive_clock_uncertainty will derive different uncertainties between a virtual/external clock and internal clock. Right now it derives uncertainty to the same clock, which will be less. It's probably going to be a 10ps difference, but true. I like the virtual clock for multiple reasons. You can use it as a tag for report_timing, i.e.: report_timing -setup/-hold -from ext_clk... Will report timing on all of these input paths, without having to describe the ports. It's not a big deal here since the inputs are a bus, but on interfaces with 20 different port names, it helps. It also makes sense when looking through timing reports. As soon as I see a launch or latch clock with ext in the name, I know I'm dealing with I/O. Finally, you can do things to the external clock. For example, you can phase-shift it. You can apply set_clock_latency. Although we're not doing any of that, we can.

[Altera_Forum]

--- Quote Start ---  The only true difference is that derive_clock_uncertainty will derive different uncertainties between a virtual/external clock and internal clock. Right now it derives uncertainty to the same clock, which will be less. It's probably going to be a 10ps difference, but true.  --- Quote End ---   But if you use the incoming clock to e.g. clock the data into a fifo, it is the same clock (externally and internally). If the difference of 10 ps is valid, shouldn't the 'derive_clock_uncertainty' be fixed?   --- Quote Start ---  I like the virtual clock for multiple reasons. You can use it as a tag for report_timing, i.e.: report_timing -setup/-hold -from ext_clk... Will report timing on all of these input paths, without having to describe the ports. It's not a big deal here since the inputs are a bus, but on interfaces with 20 different port names, it helps.  --- Quote End ---   But wouldn't "report_timing -setup/-hold -from fga_clk" work as well?

[Altera_Forum]

The FPGA introduces uncertainty in its fabric. That uncertainty can cancel out when both the source and destination is inside the FPGA, so it can be a smaller number. When one clock is outside the FPGA, the uncertainty between that clock and the one in the FPGA is a little higher. To be honest, the time I looked at it, I was using a PLL. I just looked at a small test design I have, and I get the same uncertainty whether using a virtual clock or the FPGA clock. I would still argue it's good practice to do a virtual clock, but not wrong if you don't. (Lots of users don't do the virtual clock and are unaware of it, which is another reason I point it out.) 

 report_timing -setup -from fpga_clk will work if the only paths from fpga_clk are from the I/O. You will minimally also now see the paths from the input registers, which are clocked by fpga_clk, to registers in another domain. If fpga_clk feeds thousands of registers, then you might get thousands, or tens of thousands, of paths listed before you ever see the I/O. I always recommend creating a .tcl script that analyzes "things of interest", which always includes I/O interfaces. Just having: report_timing -setup -npaths 200 -detail full_path -from ext_clk -panel_name "LVDS Inputs||setup" report_timing -hold -npaths 200 -detail full_path -from ext_clk -panel_name "LVDS Inputs||hold" I don't run it all the time, but just to have it accessible in the project directory if I ever want to look at it again is useful.

[Altera_Forum]

Thanks, you are the best. 

If I want to use multicycle solution, should I define fpga_clk? and what fpga_clk means?

[Altera_Forum]

fpga_clk is the clock coming into the FPGA that drives the input registers. I think it was the first line in the sample .sdc.

[Altera_Forum]

so what is the ext_clk and what is the relation between them? what should i define as the input PIN?

[Altera_Forum]

I'm not following. ext_clk is the virtual external clock. The set_input_delay applies the assignment to the input pins(you have to change the name to match your pin names). The default setup relationship between ext_clk and fpga_clk is 5.942ns. A multicycle -setup 0 will make it 0ns. If you run report_timing on the paths, it will tell you what the setup and hold relationships are.

[Altera_Forum]

After reading your user guide everything is clear 

Thanks