Visible to Intel only — GUID: ewa1405023256962
Ixiasoft
2.1. Initializing Your Custom Platform
2.2. Removing Unused Hardware
2.3. Integrating Your Custom Platform with the Intel® FPGA SDK for OpenCL™
2.4. Setting up the Software Development Environment
2.5. Building the Software in Your Custom Platform
2.6. Establishing Host Communication
2.7. Connecting the Memory
2.8. Integrating an OpenCL Kernel
2.9. Programming Your FPGA Quickly Using CvP
2.10. Guaranteeing Timing Closure
2.11. Troubleshooting
3.1. Host-FPGA Communication over PCIe
3.2. DDR3 as Global Memory for OpenCL Applications
3.3. QDRII as Heterogeneous Memory for OpenCL Applications
3.4. Host Connection to OpenCL Kernels
3.5. Implementation of UDP Cores as OpenCL Channels
3.6. FPGA System Design
3.7. Guaranteed Timing Closure
3.8. Addition of Timing Constraints
3.9. Connection to the Intel® FPGA SDK for OpenCL™
3.10. FPGA Programming Flow
3.11. Host-to-Device MMD Software Implementation
3.12. OpenCL Utilities Implementation
3.13. Stratix V Network Reference Platform Implementation Considerations
Visible to Intel only — GUID: ewa1405023256962
Ixiasoft
3.6.2. Resets
The FPGA system design includes the implementation of the following reset drivers:
- The por_reset_counter in the board.qsys system implements the power-on-reset. This reset issues a reset for a number of cycles after the FPGA completes configuration. It resets all the hardware on the device.
- The PCIe® bus issues a PERST reset that resets all hardware on the device.
- The OpenCL™ Kernel Interface component issues the kernel_reset that resets all logic in the kernel clock domain.
The first two resets are combined into a single global_reset; therefore, there are only two reset sources in the system. However, these resets are explicitly synchronized across the various clock domains, resulting in several reset interfaces.
Important notes regarding resets:
- Synchronizing resets to different clock domains might cause several high fan-out resets.
Platform Designer (Standard) automatically synchronizes resets to the clock domain of each connected component. In doing so, Platform Designer (Standard) instantiates new reset controllers with derived names that might change when the design changes. This name change makes it difficult to make and maintain global clock assignments to some of the resets. As a result, for each clock domain, there are explicit reset controllers. For example, global_reset drives reset_controller_pcie and reset_controller_ddr3a; however, they are synchronized to the PCIe and DDR3 clock domains, respectively. Because both of these resets have high fan-out signals, they are assigned to global routing in the .qsf file.
- Resets and clocks must work together to propagate reset to all logic.
Resetting a circuit in a given clock domain involves asserting the reset over a number of clock cycles. However, your design may apply resets to the PLLs that generate the clocks for a given clock domain. This means a clock domain can hold in reset without receiving the clock edge necessary for synchronous resets. In addition, a clock holding in reset might prevent propagation of a reset signal because it is synchronized to and from that clock domain. Avoid such situations by ensuring that your design satisfies the following criteria:
- Generate the global_reset signal off the free-running config_clk.
- Never reset the UniPHY controllers.
- Clock the reset controller for the Ethernet PHYs by its free-running reference clock.
- Apply resets to both reset interfaces of a clock-crossing bridge or FIFO component.
FIFO content corruption might occur if only part of a clock-crossing bridge or a dual-clock FIFO component is reset. These components typically provide a reset input for each clock domain; therefore, reset both interfaces or none at all. For example, in the Stratix® V Network Reference Platform, kernel_reset resets all the kernel clock-crossing bridges between DDR, QDR, and UDP on both the m0_reset and s0_reset interfaces.