The controller is held inactive by the FPGA global set/reset signal. At the completion of configuration, the FPGA configuration system deasserts the global set/reset signal and the controller boots. The controller maintains all five state bits on the Status Interface deasserted through the boot process.
The controller polls its icap_grant input during boot to determine if it has been granted permission to enter the initialization state and begin using ICAP. In implementations for most devices, icap_grant should be tied High. Implementations in Zynq-7000 devices, however, require special handling of the icap_grant signal.
During boot of the Zynq-7000 Processing System (PS), access to the configuration logic in the device is given to the PS through the processor configuration access port (PCAP). This provides a path for the PS bootloader to download a bitstream to the Zynq-7000 Programmable Logic (PL). When the PS bootloader completes, the PS and PCAP remain in control of the configuration logic to support partial reconfiguration of the PL by the PS.
However, while the PS and PCAP are in control of the configuration logic, the PL and ICAP are locked out of the configuration logic. In order for the controller to function, configuration logic access must be transferred to the ICAP. This is accomplished by clearing PCAP_PR (bit 27) in the PS device configuration control register (DEVCFG CTRL, address 0xF8007000). See the Zynq-7000 SoC Technical Reference Manual (UG585) for more information regarding PCAP [Ref 3] . This Figure illustrates how PCAP, ICAP, and PCAP_PR interact.
The controller has no simple method to sense the ICAP is locked out. During the initialization state, the controller polls the ICAP, attempting to read the configuration logic IDCODE register, until it observes the expected vendor identification value. However, if the PS clears PCAP_PR during a controller attempt to access the ICAP, the configuration logic might receive a malformed ICAP transaction. This results in unpredictable behavior of the configuration logic.
To eliminate this possibility, it is necessary for the PS to drive the controller icap_grant input through the GPIO and prevent the controller from entering the initialization state until after PCAP_PR has been cleared. The GPIO used might either be an EMIO from the PS or a GPIO in the PL, but it must be initialized so that the controller observes icap_grant deasserted immediately upon completion of PL configuration.
When software running on the PS has completed all necessary PCAP activity, it clears PCAP_PR and then sets the GPIO connected to the controller icap_grant input, allowing the controller to proceed with initialization. The signal applied to the icap_grant input must be properly synchronized to the icap_clk signal. The software implementation of this behavior is outside the scope of this document. See Zynq-7000 EPP Software Developers Guide (UG821) [Ref 4] and Xilinx OS and Libraries Document Collection (UG643) [Ref 5] , for detailed information about software development for Baremetal and Linux environments.
During the initialization state, status_initialization is TRUE. Initialization includes some internal housekeeping, as well as directly observable events such as the generation of a status report on the Monitor Interface. The specific activities are:
• A first readback cycle during which the frame-level ECC checksums are computed
• A second readback cycle during which the device-level CRC checksum is computed
• An additional readback cycle during which an additional checksum is computed
• An additional readback cycle during which the frame-level CRC checksums are computed and stored in block RAM (only executed if correction by enhanced repair is used)
At the completion of initialization, the controller transitions to the observation state.