This website uses cookies. By using this site, you consent to the use of cookies. For more information, please take a look at our Privacy Policy.
Home > FPGA Technology > FPGA > 7 series FPGA power-up configuration flow - FPGA Technology

7 series FPGA power-up configuration flow

Date: Apr 26, 2021

Click Count: 2410

FPGA configuration pins description

1、CFGBVS

If VCCO0 is connected to 2.5V or 3.3V, CFGBVS is connected to VCCO0.

If VCCO0 is connected to 1.5V or 1.8V, CFGBVS is connected to GND.

It is recommended that bank0, bank14, and bank15 have the same VCCO voltage to avoid I/O Transition at the End of Startup (recommended configuration according to the following table)

FPGA-1.png

2、M[2:0]

Mode configuration pins, according to the following table to select.

FPGA-2.png

3、PROGRAM_B (input)

Active low, when it is low, the configuration information is cleared and the configuration process will be carried out again. Keeping PROGRAM_B low at power-up will not keep the FPGA configuration in reset. Instead, INIT_B is used to delay the power-up configuration sequence.

4INIT_B (inout)

The FPGA drives this pin low when the FPGA is in a configuration reset state, when the FPGA is initializing (clearing) its configuration memory, or when the FPGA detects a configuration error. During power-up, INIT_B can be held low externally to stop the power-up configuration sequence at the end of the initialization process. When a high level is detected at the INIT_B input after the initialization process, the FPGA continues with the rest of the configuration sequence indicated by the M [2:0] pin setting.

5、VCCBATT

VCCBATT is a battery backup power supply for the FPGA's internal volatile memory, which is used to store the AES decryptor key. If the decryption key in the volatile key store is not required, connect this pin to GND or VCCAUX.


Use the EMCCLK pin to load the program at full speed

Since the CCLK pin has tolerance, you can use the EMCCLK pin, which is a more accurate clock than CCLK. The following steps are required to enable this function.

1. Enable ExtMasterCclk_en bitstream generation option

2. define the EMCCLK target voltage. bank 14 has another pin that defines the IOSTANDARD. The voltage defined on BANK 14 is automatically applied to EMCCLK. use the BITSTREAM.CONFIG.EXTMASTERCCLK_EN property to set the ExMasterCclk_en option in Vivado


FPGA loading timing

Power-up Timing Diagram

FPGA-3.png

Power-up Timing Diagram

FPGA-4.png

Power-up configuration flow

FPGA-5.png

The configuration process is decomposed into 8 steps.

1、Power-up

The 7 series device requires power to the VCCO_0, VCCAUX, VCCBRAM and VCCINT pins. At power-up, the VCCINT power pin must provide 1.0V or 0.9V (for -2L) power. In JTAG mode, any I / O power supply other than VCCO_0 is not required to power the 7 Series FPGA configuration. VCCO_14, VCCO_15, or both must also be provided when configuration mode using multi-function pins (i.e., Serial, Main BPI, SPI, SelectMAP) is selected. After power-up, the PROGRAM_B pin can be reconfigured by switching it low.

Application: This step can be used to reload the FPGA using the watchdog circuit, or to control the FPGA reload by other devices (DSP, CPLD, etc.).

FPGA-6.png

2、Clear configuration memory

After the device is powered up, the PROGRAM_B pin is pulsed low, and the configuration memory is sequentially cleared after using the JTAG JPROGRAM command or IPROG command, or during a fallback retry configuration sequence. The block RAM is reset to its initial state and the flip-flop is reinitialized by asserting a Global Set Reset (GSR). During this period, the I / O is placed in the high resistance state by using the global tri-state (GTS) except for a few configuration output pins, which are internally pulled up if PUDC_B is low. INIT_B is driven low internally during initialization and then used for power-up cases after TPOR, while TPL is used for other cases. If the INIT_B pin is held low from the outside, the device will wait during initialization until the pin is released and the TPOR or TPL delay is satisfied.

3Sample M2:0 pins

When the INIT_B pin is high, the device samples the M [2:0] mode pin and starts driving CCLK if it is in master mode. At this point, the device starts sampling the configuration data input pin on the rising edge of the configuration clock. For BPI and SelectMAP modes, the bus width is initially x8, which is reflected in the status register. After the bus width detection sequence, the status register is updated. The mode pins are sampled again only when reconfiguration is performed by re-powering up or down or by setting PROGRAM_B.

4Synchronization

For the BPI, Slave SelectMAP and Master SelectMAP modes, the bus width must be detected first. Slave Serial, Master Serial, SPI and JTAG modes ignore the bus width detection mode. A special 32-bit synchronization word (0xAA995566) must then be sent to the configuration logic. The synchronization word warns the device of upcoming configuration data and aligns the configuration data with the internal configuration logic. Any data on the configuration input pins before synchronization is ignored, except for the "bus width auto-detect" sequence. Synchronization is transparent to most users because all configuration bitstreams (BIT files) generated by the tool include the bus width detection mode and the synchronization word.

Synchronization detection signal

FPGA-7.png

5Checking the device ID

After device synchronization, the device ID check must be passed before the configuration data frame can be loaded. This prevents the use of bitstreams formatted for different devices for configuration. If an ID error occurs during configuration, the device will attempt to perform a fallback reconfiguration. The device ID check is built into the bitstream, making this step transparent to most designers. The device ID check is performed through commands in the bitstream to the configuration logic, not through the JTAG IDCODE register.

FPGA-8.png


ID annotations

6Load data

After loading the synchronization word and checking the device ID, the configuration data frame is loaded. This process is transparent to most users.

7Cyclic redundancy checksum

When loading a configuration data frame, the device calculates a cyclic redundancy check (CRC) value from the configuration packet. After loading the configuration data frame, the configuration bitstream can issue a checksum CRC command to the device, followed by the expected CRC value. If the CRC value calculated by the device does not match the expected CRC value in the bitstream, the device pulls INIT_B low and aborts the configuration. The CRC checksum is included in the configuration bitstream by default.

For encrypted bitstreams (when the BITSTREAM.ENCRYPTION.ENCRYPT attribute is yes), the CRC checksum is disabled and HMAC verifies the encrypted bitstream data. Errors in the bitstream data are reported as HMAC errors in the BOOTSTS register.

If a CRC error occurs during the mode configured as FPGA as configuration host, the device can attempt to perform a fallback reconfiguration. In BPI and SPI modes, if the fallback reconfiguration fails again, the BPI / SPI interface can only be resynchronized by pulsing the PROGRAM_B pin and restarting the configuration process from the beginning. The JTAG interface still responds and the device remains active, only the BPI / SPI interface is inoperative.

Series 7 devices use a 32-bit CRC checksum. The CRC checksum is designed to catch errors when transmitting the configuration bitstream. There are cases where the CRC checksum may miss errors in transmitting the configuration bitstream: certain clocking errors (e.g., double clocking) may cause a loss of synchronization between the 32-bit bitstream packet and the configuration logic. After the loss of synchronization, no subsequent commands are understood, including the command to check the CRC. In this case, the configuration fails due to DONE Low and INIT_B High, because the CRC is ignored. In BPI mode asynchronous reads, the address counter eventually overflows or underflows to cause wrap-around, which triggers a fallback reconfiguration. The BPI synchronous read mode does not support wrap-around error conditions.

8Start

After loading a configuration frame, the bitstream instructs the device to enter the boot sequence. The boot sequence is controlled by an 8-phase (phases 0-7) sequential state machine. The startup paramter performs the tasks listed in the table below. The specific phases of each boot event are user programmable.

FPGA-9.png

FPGA-10.png

The start sequence can be forced to wait for the MMCM to lock or to match the DCI with the appropriate option. These options are typically set to prevent DONE, GTS, and GWE from being set (preventing device operation) until the MMCM locks and/or DCI matches.

The DONE signal is released by the start sequencer on a user-indicated cycle, but the start sequencer does not continue until the DONE pin actually sees a logic high. The DONE pin is an open-drain bidirectional signal. By releasing the DONE pin, the device stops driving the logic low and pulls up on the pin through the internal pull-up resistor. By default, DONE_PIPE is enabled to add registers between the DONE pin and the configuration logic.

FPGA-11.png

Signals associated with the boot sequence generator

FPGA-12.png

Signal Timing Associated with the Startup Sequence Generator

By default, DONE is released in phase 4 of startup and DONE_PIPE is enabled to add an additional delay clock cycle. DONE indicates that configuration is complete and all data has been loaded, but some additional clock cycles need to be applied to ensure that the boot sequence completes correctly to phase 7, the end of boot. DONE is a conservative number of clock cycles required after 24; this will explain the most common use cases. The bitstream options LCK_cycle or Match_cycle will add an undefined number of additional clock cycles.

In the Spartan-7, Artix-7, and Kintex-7 families, if the VCCO of the bank is 1.8V or lower, then there are multi-function configuration pins on the I / O bank and the pins on that bank are low or floating, and then the inputs may have a 0-1-0 transition to interconnect logic during configuration startup. Since this transition occurs after the GWE enables the internal logic, it may affect the internal state of the device after configuration. After EOS (end of boot), the transition occurs a CFGCLK. To avoid this transition, set VCCO_14 and VCCO_15 to 2.5V or 3.3V, or drive the pins externally high (see Table 5-13). Otherwise, the logic should be designed to ignore these affected input signals until at least 200 ns after a CFGCLK following an EOS rising edge. CFGCLK and EOS can be monitored using STARTUPE2.


Configuration file formats

The burn configuration file includes four types, among which MCS, BIN and HEX files are solidified files, which are directly burned to the external memory of FPGA.

FPGA-13.png


MultiBoot

7 series FPGA MultiBoot and backup function supports updating system in the field. Bitstream images can be dynamically upgraded in the field. FPGA MultiBoot function can switch images in real time. When an error is detected during MultiBoot configuration, the FPGA can trigger a fallback function to ensure that a known good design can be loaded into the device

When a fallback occurs, an internally generated pulse resets the entire configuration logic, except for the dedicated MultiBoot logic, the hot boot start address (WBSTAR) and boot status (BOOTSTS) registers. This reset pulse pulls INIT_B and DONE low, clears the configuration memory, and restarts the configuration process from address 0 and drives the revision select (RS) pin to 00. After the reset, the bitstream will overwrite the WBSTAR start address.

During configuration, the following errors may trigger a fallback: IDCODE error, CRC error, watchdog timeout, BPI address wrap-around error.

Fallback can also be enabled using the bitstream option ConfigFallback. Ignore embedded IPROG during fallback reconfiguration. Disable the watchdog timer during fallback reconfiguration. If the fallback reconfiguration fails, the configuration stops and both INIT_B and DONE remain low.


BPI - Hardware RS Pin Design Considerations

In BPI mode, the RS pins need to be connected to the high address bits and a pull-up resistor on one of the RS pins is connected to the high address line. With this hardware implementation, the system does not include WBSTAR addresses and the bitstream options are the same for each image.

Dual-use RS pins are disabled by default. The RS pin is driven low during fallback in BPI or Master SelectMAP mode, but is not driven low during SPI mode. For the initial MultiBoot system, the RS pins are connected to the high address bits of the flash memory and are tied high or low via pull-up or pull-down resistors, respectively. At power-up, the system is directed to the high address space defined by the pull-up resistor and address line connections on the RS. During fallback, the RS pin is driven low and the device is bootstrapped from address space 0. The RS pin should be connected to the system-defined high bit address to allow full bit files to be stored in each memory segment.


Multi-FPGA JTAG Daisy Chain

FPGA-14.png


<< Previous: Basic knowledge of FPGA architecture and applications

<< Next: Xilinx-7 Series FPGA high-speed transceiver use learning

Need Help?

Support

If you have any questions about the product and related issues, Please contact us.