Connecting of two FPGAs in synchronous mode.

With manually forced I/O cell registers for both inputs and outputs and manually controlled input and output delay chains, the timing should be the same for every compile. In that case it is acceptable to do the I/O timing analysis by hand if you use reported numbers (not your estimates) in that analysis. But to be proper you should always in every design constrain every path for which the timing matters and designate every path as a false path for which the timing does not matter. Someone maintaining your design later (even you after you've forgotten what you've done) will benefit from those constraints as a form of documentation for what you intended. If you later do something to the design that makes a Fast Input Register or Fast Output Register setting no longer work (synthesis itself can cause this to happen), the reported negative slack will alert you to the resulting timing violation.

Even though you do not have timing constraints at the moment, if you are using the Classic Timing Analyzer you can report the tsu, th, tco, and minimum tco to see whether the timing is what you expected. Your description sounds like your manual estimate is using output-register-to-output-pin and input-pin-to-input-register delays where it should be using tco and tsu. tco and tsu include the clock-path portion of the timing inside the FPGAs, which also accounts for how much the PLL compensation delay differs from the ideal (the PLL output inside the FPGA is probably not exactly aligned with the clock at the PLL input device pin).

Be sure to check the timing with both the slow and fast timing models. You might have lots of margin for tco of the driving device going to tsu of the receiving device with the slow model but have a timing violation for minimum tco of the driving device going to th of the receiving device with the fast model. Remember to include that 1 ns difference from FPGA to FPGA for the clock input pins in the min tco/th check--that clock skew might be causing a hold violation at the receiving device.