Forum Discussion
Altera_Forum
Honored Contributor
9 years agoIn some devices there are delay chains between the IO port and the input/output register, so the fitter can modify those to meet timing. But yes, there's not a whole lot that generally happens. With a source-synchronous interface, especially the outside, the data and clock are generally as closely matched as they can be by default.
The same method can be applied. In the first step, you may not need any constraint at all. For source-synch, the input side(FPGA_B) there tends to be more variation. The reason is that the clock is on a global clock tree and then drives to the input register, while the data comes directly in. They follow two very different paths and delay chains may be necessary to get the alignment you want, and timing constraints will drive the fitter to set those delay chains. For source-synch, I usually try to do symmetric requirements, i.e. I set up my clocks to have a setup relationship of Xns and a hold relationship of -Xns, and then the external delays are +/-Yns. If you do it this way, you can squeeze Y to be as large as you can on either side, then use that to constrain the other FPGA. And one last thing, note that at smaller geometries, the on-die variation gets larger(plus other issues) and so regular source-synchronous interfaces get slower. I used to run DDR registers for source-synchronous Cyclone III interfaces at 600Mbps. 28nm got slower(which is why they added dedicated LVDS SERDES to lower end devices like Cyclone V) and 20nm is even worse. It's hard to run a regular source-sync DDR interface above 200Mbps in Arria 10. (If you use the altlvds block that doesn't require timing constraints, you can go above 1Gbps, and 1.6Gbps with DPA...)