^

AR# 32653 Spartan-3/-3E/-3A/-3AN/-3DSP Families - I/Os glitch during power up or down, or a PROG_B pulse

The I/Os in the Spartan-3/-3E/-3A/-3AN/-3DSP Family FPGAs, like all Xilinx FPGAs, should not be monitored until after POR on Power Up or after power rails are at the recommended operating conditions for both Power Up and Power Down scenarios. If the system is monitoring these I/Os, the following design considerations should be taken into consideration.

For more FPGA Device Specific Issues and other Configuration Related Articles, see (Xilinx Answer 34104).

Xilinx officially recommends that IOBs are ignored and not monitored unless the device is fully configured and operational. This guideline will lend itself to a design suggestion of using the DONE pin to get IOB behavior valid interfacing other components on the board.

Power Up:

If Vcco is powered up after Vccint and Vccaux, the IOBs will have the pullup enable during the rising edge of Vcco between POR and when Vcco = Vccint. Typically, this will be in the range of 0.7V to 1.2V and the pullup value will be Irpu specified in the data sheet (approx. 8K ohms). To avoid this issue, power up Vcco prior to Vccint and Vccaux, or use a strong pulldown on critical signals such as resets to keep the signals below Vilmax for downstream devices. This condition is occurring before the HSWAP pin is being registered by the IOBs, as the HSWAP pin is only valid after all the power supplies are stable.

Power Down:

If Vcco is powered down first, the exact same behavior as power up will occur. When Vcco is reduced below Vccint, the pullup will be enabled to Irpu until POR is triggered, typically at 0.7V.

If Vccint is powered down first, the level shifters in the IOB might not be able to hold a logic Low as Vccint is reduced from below the recommended operating condition to the POR value. During this phase, it is possible for the IOB to have the pullups enabled or drive High or Low. To work around this issue, tri-state output buffers, power down Vccaux first, and use a strong pulldown on the pin.

PROG_B Pulse:

If the HSWAP pin is unused, the tools will place a pulldown on this signal along with all unused I/Os. When PROG_B pin is pulsed, GTS signal will move out of the device and as this global signal reaches each IOB, it will tri-state the IOBs. The pullups in the IOB will be set based on HSWAP pin which is pulled Low and this will enable the pullups. The pullups will be enabled until the GTS signal reaches the HSWAP pins. To work around this issue, instantiate HSWAP in the design and place a pullup on the pin.

There can also be a race condition between GHIGH and GTS when PROG_B is pulsed. In this scenario, GHIGH will reach IOB pins before GTS. GHIGH will disable the logic controlling the IOB, and GTS will tri-state the output buffer. So, if GHIGH reaches the IOB before GTS, the IOB circuitry will be disabled before the driver is tri-stated. The IOB might actively drive if the tri-state signal to the OBUF is driven by the inverted tri-state signal. In FPGA Editor, the T1 g_ibuf for the tri-state control of an output buffer can be controlled by T1 or T1_B. If T1_B is used, the IOB might glitch High. To ensure this does not occur, use the T1 signal and invert the signal at the source as well.

ISE 11.3 and later supports the exclusion of the T1_B sites from the tools for the S-3E and S-3A/AN devices. To enable this feature set the following environment variable.

XIL_MAP_NO_IOB_BUFINV_PUSH set to ?1?

Designs can be tested for the GHIGH to GTS race condition by issuing the AGHIGH command via JTAG on a configured device. Issuing the AGHIGH command on a configured device will assert the GHIGH signal and simulate the race condition where GHIGH reaches the IOB before GTS. Attached are ".svf" files that will issue the AGHIGH command for a Spartan-3E and Spartan-3A device. These files are currently setup for single device chains. If multiple devices are in the chain, the TIR, TDR, HIR, and HDR commands need to be adjusted (Xilinx Support can help with this).

http://www.xilinx.com/txpatches/pub/utilities/fpga/32653.zip

AR# 32653
Date Created 06/04/2009
Last Updated 03/17/2010
Status Active
Type
Feed Back