We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 32653

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


The I/O's in the Spartan-3/-3E/-3A/-3AN/-3DSP Family 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.

(This applies to all Xilinx FPGAs)

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 IOB's 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 enabled 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 the 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, 3-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 the PROG_B pin is pulsed, GTS signal will move out of the device and as this global signal reaches each IOB, it will 3-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 3-state the output buffer.

So, if GHIGH reaches the IOB before GTS, the IOB circuitry will be disabled before the driver is 3-stated.

The IOB might actively drive if the 3-state signal to the OBUF is driven by the inverted 3-state signal.

In FPGA Editor, the T1 g_ibuf for the 3-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.


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 set up 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).




Answer Number 问答标题 问题版本 已解决问题的版本
34104 Configuration Design Assistant N/A N/A
AR# 32653
创建日期 06/04/2009
Last Updated 10/22/2014
状态 Active
Type 综合文章
  • Spartan-3A
  • Spartan-3A DSP
  • Spartan-3AN
  • More
  • Spartan-3E
  • Spartan-3
  • Less