How to make bus skew in a reasonable range with FPGA port

[skyworld_cy]

Hi,
I'm working with Xilinx Vertex 7. There is ADC bus input to the FPGA and DAC bus output from FPGA. Is there a good way to make these bus skew within a reasonable small range, for example, the difference of the routing length for each bit of the bus is less than 100ps? in that way, all data bit will arrive the end at the "same" time. Thanks.

 

[FvM]

Permitted skew depends on ADC data rate and output skew. You want to achieve some margin for the FPGA input logic, but no reason to make it excessive. What's the ADC and DAC data rate?

 

[skyworld_cy]

ADC works with two channels, one channel samples at rising edge while other channel at falling edge. Both channel works at 125MHz.
DAC works with two channels, too. Both channel works at DDR way with clock at 250MHz.

 

[ads-ee]

Xilinx Virtex 7 FPGAs have IODELAY cells that can be used to skew inputs and outputs by increments that are based on either a 300MHz or 200(?)MHz clock.

I'd look into using that if you need a precise tuning of some input or output delay between pins. This is the same logic used by the FPGA to deal with skew for DDR3/4 memory soft IP cores and "training" the dq byte delays.

 

[dpaul]

Xilinx Virtex 7 FPGAs have IODELAY cells that can be used to skew inputs and outputs by increments that are based on either a 300MHz or 200(?)MHz clock.

200MHz for Series7

 

[skyworld_cy]

Thanks for suggestions with idelay/odelay cells. In fact I have tried that but I don't like that way. The reason is that I need to build up many control registers for those delay settings plus I have measure what kind of delay setting should be. That is a tedious job.
Is there a way to use constraints, such as set_input/output_delay, set_max_delay, etc to finish this skew balance job through checking with timing report?

 

[ads-ee]

You would normally have those kinds of constraints anyway.

High speed DDR buses use the iodelay because you can't get the tools to fix skew to the resolution that is required by an 800 Mhz interface. As you are only running at 250 MHz I doubt you need to do any kind of fine skew control.

 

[skyworld_cy]

Of course I have those kinds of constraints in the design. But those constraints can't promise you always get skew balanced bus. That is the reason why I come to ask for help: is there a good way to use constraints to balance bus skew in IO port with FPGA?

 

[ads-ee]

Short answer is no, the P&R tools will meet the timing constraints you specify.

If your timing constraints tell the tools that you have a window of 500ps because you have input/output delay constraints that use up 3.5ns of the 4ns transfer window, when all you require is an input/output delays that uses up 2ns of that window to meet worst case delays, then you have over-constrained the design and should expect the P&R to 1. fail, 2. do poorly, 3 take forever to finish, 4. complete with no issues.

Personally I would get the board layout person to give me a table of the trace lengths and I'd get (or extract) the package die-pin delays. Add those up and put that into the idelay/odelay setting for each pin. You can add something like that from a constant/parameter/`define file you include into your HDL. Along with that I would force the design to use the I/O registers to avoid any placement issues. If your design doesn't have flip-flops directly driving or receiving from the external device then change it so it does.

--- Updated Jul 31, 2020 ---

The point of the above solution is to ensure consistency between P&R runs and not having to over-constraint the input/output delays.

 

[skyworld_cy]

thanks for your comment. I agree with you that trace delay should be checked when setting input/output delay constraints. In fact I also set position constraint so that input/output registers are the nearest one when connecting to the in/out ports. These helps to generate "repeatable" bitfiles. But there are cases that some registers belongs to one clock region while others belongs to other clock region even when they're captured with the same clock, this will cause added skew. Manually adding some path delay is quite tedious in R&D process. That is what I don't want. So I'm trying to find if there is a good way to do some "impossible" things.

 

[ads-ee]

Virtex7 has I/O cell registers, why are you using flip-flops in the slices? The routing delay from the "nearest" slice isn't the same on every bank at every position, and the tools didn't always route them the same (though the tools may have improved over the 5-6 years, since I last had to deal with this issue).

If you are worried about clock skew between banks then put the output flip-flops in the I/O and put them on a separate clock network (use a PLL to output a 0 phase delay clock at the same frequency as the clock running the logic that feeds the outputs (the tools will handle the synchronous clock domain transfer between the logic and the I/O clock. The I/O clock delay difference between the banks should be as close as you will ever be able to manage (if you really needed that level of precision you should have kept them all in the same bank and or balanced the load of the clock network between the two banks, i.e. had the same number of outputs in both banks). If you have to, add more I/O registers to the design on unused pins if you can to help increase the I/O clock load on that bank.

The whole point of any of this is to get rid of variability so you can lock down the odelay values for design and make them constants, which you will not need to adjust on a per board basis (removing the need for any registers to control them).