Forum Discussion
Altera_Forum
Honored Contributor
18 years agoDid you fully constrain the I/O timing? All the inputs and outputs of each FPGA need to have maximum and minimum input delay or output delay constraints. (tsu/th/tco/min tco in the Classic Timing Analyzer would work, but input delay and output delay is preferred for either timing analyzer.) Budget the available timing between the driving FPGA and receiving FPGA for each connection.
Are the PLLs doing a divide? If you are going from a register on a half-speed clock in the driving FPGA to a register on a half-speed clock in the receiving FPGA (for example), the half-speed clocks in the two FPGAs might be out of alignment by a full-speed clock period. There is probably some significant clock uncertainty for going from a PLL domain in one FPGA to a PLL domain in another FPGA (even more than going between separate PLLs in the same FPGA). With TimeQuest, you can use virtual clocks for the input delay and output delay constraint clock fields and apply clock uncertainty settings for the transfer between a register on the PLL domain in a given FPGA to/from the virtual clock that effectively represents the clock of the external register that is actually in the other FPGA. An uncertainty setting done this way with virtual clocks won't affect the timing analysis of paths internal to an FPGA (which might themselves need an uncertainty setting, but with a smaller uncertainty value). If you have no idea what I mean by clock uncertainty settings and don't want to read the documentation about it, just make sure you have some positive slack for the I/O timing (I don't know how much is needed--maybe a few tenths of a nanosecond).