--- Quote Start ---
Regarding max delays, kaz suggested to tell FPGA1 that tSU is zero and then to tell FPGA2 max tCO is 2 ns.
But, in fact, by telling FPGA1 that tSU is zero, the fitter may produce a design with a tCO of up to 1 clock period.
Vice versa, by telling FPGA2 that max tCO is 2, the fitter may produce a design which has a tSU of clock period - 2 ns.
--- Quote End ---
Thanks rbugalho for the contributions, however I just run the tool on a tiny project of a PLL plus output data and output clock aligned through DDR outputs. Here are some results of clk/data alignment figures against my random set output delay figures:
clk_out dout io timing
set_output_delay: 0/0 0/0 (max/min) pass
tCO achieved 1.922 1.937 ns
set_output_delay: 0/0 +2/-2 (max/min) fail
tCO achieved 1.973 1.942 ns
set_output_delay: +3/-3 +5,-2 (max/min) fail
tCO achieved 1.973 1.942 i.e. no change
My own observation is that the tool does not read set delays figures as absolute mathematical targets to achieve... not at all. Neither it reports failure if these particular figures are not achieved. Instead it reports on failling paths based on thes figures.
The tool has limited delay graininess and delay limits. It reads delay figures as information to achieve best it can.
In the above example data and clock are aligned well and that is what the DDR design is for. When I enter delay figures then the change is trivial yet timing failure was reported in case2 and 3 because of the information entered. The tool did not want to alter the clk/data relation that much.
As a side note: A user can easily pass io timing by entering wrong figures (false pass) or the reverse get false failure.
Honored Contributor
