Under what conditions would a JTAG verification failure occur?

Thank you for your reply a_x_h_75.

Do you have two devices in one JTAG chain? Or two separate chains? - We have separate JTAG chains.

Do you have any long, unbuffered traces? - We do have long traces, but as cross-verified against the Max 5 development board, the trace lengths of TCK, TMS, TDI and TDO on our board are lesser than the trace lengths of the development board (about 3000 mils). Our longest trace length is about 2850 mils. We have also ensured the recommended terminations (TCK pull-down to GND with 1k ohm, TDI and TMS pull-up to VCCIO1 with 10k ohm each, TDO floating, DEV_OE and DEV_CLRn unused and tied to GND).

One more point of relevance is that during board fab, the connections from CPLD to JTAG header got mixed up (in the JTAG chains of both devices) - CPLD TMS routed to Header TDO, CPLD TDI routed to Header TCK, CPLD TCK routed to Header TDI and CPLD TDO to Header TMS. As a result, we were forced to make a tiny mating adapter with the JTAG Header to switch the signals correctly. The USB Blaster is connected to this adapter now. This arrangement is temporarily OK since it works with the first device. During our experiments, we have now routed the JTAG signals directly from the CPLD BGA pins (along with termination resistors) to an alternate JTAG header. This was to ensure the reduced trace lengths for the non-working device. But still, no luck.

Do you have any nearby signals causing interference? - There are devices like NVRAM, voltage level translators, opto-isolators nearby. But the working device also has the same kind of devices nearby. Anyhow, we have monitored the VCCIO1, GND, TMS, TCK, TDI and TDO signals during a Program operation and not found any abnormal electrical behavior. Plus, both CPLDs do get detected by the USB Blaster (Device ID & silicon ID read with Auto-detect operation).