--- Quote Start ---
That's a labour intensive and/or error prone process.
Every time you run a new fit for FPGA1, you need to re-check the tCOs you got. If they're different from the tCOs you've constrained FPGA2 with, then you need to manually check and, if needed, update FPGA2's constrains and run a new fit
If instead you specify reasonable constraints for both FPGAs that meet the conditions I wrote before, then you can just trust TQ to fail your design if something goes wrong.
And if those constrains are well balanced between the FPGAs, you'll probably never have to change them again.
--- Quote End ---
You are right in principle but I don't think so practically with tool's behaviour because DDR takes care of alignment. Moreover remember you may set delay figure to some nonzero and then you target some close range of tCOs as 15 ps between data and its clock. I view setting delay to zero is a constraint by itself rather than deconstraint.
The second fpga is given a false wider margin of tCO and that is why I suggested +/- 2ns instead of actual +15ps. you can further widen that up if timing can pass
Your approach is also worth trying i.e. share the delay figures from start and see if timing passes on both fpgas instead of using my false figures.
Honored Contributor
