AN 796: Cyclone® V and Arria® V SoC Device Design Guidelines

Download PDF
ID 683360
Date 3/30/2022
Public
Document Table of Contents
Document Table of Contents x
1. Overview of the Design Guidelines for Cyclone® V SoC FPGAs and Arria® V SoC FPGAs 2. Background: Comparison between Cyclone® V SoC FPGA and Arria® V SoC FPGA HPS Subsystems 3. Design Guidelines for HPS portion of SoC FPGAs 4. Board Design Guidelines for SoC FPGAs 5. Embedded Software Design Guidelines for SoC FPGAs A. Support and Documentation B. Additional Information
1. Overview of the Design Guidelines for Cyclone® V SoC FPGAs and Arria® V SoC FPGAs x
1.1. The SoC FPGA Designer’s Checklist 1.2. Overview of HPS Design Guidelines for SoC FPGA design 1.3. Overview of Board Design Guidelines for SoC FPGA Design 1.4. Overview of Embedded Software Design Guidelines for SoC FPGA Design
2. Background: Comparison between Cyclone® V SoC FPGA and Arria® V SoC FPGA HPS Subsystems x
2.1. Guidelines for Interconnecting the HPS and FPGA
2.1. Guidelines for Interconnecting the HPS and FPGA x
2.1.1. HPS-FPGA Bridges 2.1.2. FPGA-to-HPS SDRAM Access 2.1.3. Connecting Soft Logic to HPS Component
2.1.1. HPS-FPGA Bridges x
2.1.1.1. Lightweight HPS-to-FPGA Bridge 2.1.1.2. HPS-to-FPGA Bridge 2.1.1.3. FPGA-to-HPS Bridge
3. Design Guidelines for HPS portion of SoC FPGAs x
3.1. Start your SoC-FPGA design here 3.2. Design Considerations for Connecting Device I/O to HPS Peripherals and Memory 3.3. HPS Clocking and Reset Design Considerations 3.4. HPS EMIF Design Considerations 3.5. DMA Considerations 3.6. Managing Coherency for FPGA Accelerators 3.7. IP Debug Tools
3.1. Start your SoC-FPGA design here x
3.1.1. Recommended Starting Point for HPS-to-FPGA Interface Design 3.1.2. Determining your SoC FPGA Topology
3.2. Design Considerations for Connecting Device I/O to HPS Peripherals and Memory x
3.2.1. HPS Pin Assignment Design Considerations 3.2.2. HPS I/O Settings: Constraints and Drive Strengths
3.3. HPS Clocking and Reset Design Considerations x
3.3.1. HPS Clock Planning 3.3.2. Early Pin Planning and I/O Assignment Analysis 3.3.3. Pin Features and Connections for HPS JTAG, Clocks, Reset and PoR 3.3.4. Internal Clocks
3.4. HPS EMIF Design Considerations x
3.4.1. Considerations for Connecting HPS to SDRAM 3.4.2. HPS SDRAM I/O Locations 3.4.3. Integrating the HPS EMIF with the SoC FPGA Device 3.4.4. HPS Memory Debug 3.4.5. HPS Address Mirroring
3.5. DMA Considerations x
3.5.1. Choosing a DMA Controller 3.5.2. Optimizing DMA Master Bandwidth through HPS Interconnect 3.5.3. Timing Closure for FPGA Accelerators
3.6. Managing Coherency for FPGA Accelerators x
3.6.1. Cache Coherency 3.6.2. Coherency between FPGA Logic and HPS: Accelerator Coherency Port (ACP) 3.6.3. Data Size Impacts ACP Performance 3.6.4. Avoiding ACP Dependency Lockup 3.6.5. FPGA Access to ACP via AXI* or Avalon-MM 3.6.6. Data Alignment for ACP and L2 Cache ECC accesses
4. Board Design Guidelines for SoC FPGAs x
4.1. Board Bring Up Considerations 4.2. Boot and Configuration Design Considerations 4.3. HPS Power Design Considerations 4.4. Boundary Scan for HPS 4.5. Design Guidelines for HPS Interfaces
4.1. Board Bring Up Considerations x
4.1.1. Reserved BSEL Setting
4.2. Boot and Configuration Design Considerations x
4.2.1. Boot Design Considerations 4.2.2. Configuration 4.2.3. Reference Materials
4.2.1. Boot Design Considerations x
4.2.1.1. Boot Source 4.2.1.2. Select Desired Flash Device 4.2.1.3. BSEL Options 4.2.1.4. Boot Clock 4.2.1.5. CSEL Options 4.2.1.6. Selecting NAND Flash Devices 4.2.1.7. Determine Flash Programming Method 4.2.1.8. For QSPI and SD/MMC/eMMC Provide Flash Memory Reset 4.2.1.9. Selecting QSPI Flash Devices
4.2.2. Configuration x
4.2.2.1. Traditional Configuration 4.2.2.2. HPS Initiated Configuration
4.3. HPS Power Design Considerations x
4.3.1. Early System and Board Planning 4.3.2. Design Considerations for HPS and FPGA Power Supplies for SoC FPGA devices 4.3.3. Pin Connection Considerations for Board Designs 4.3.4. Power Analysis and Optimization
4.3.1. Early System and Board Planning x
4.3.1.1. Early Power Estimation
4.3.2. Design Considerations for HPS and FPGA Power Supplies for SoC FPGA devices x
4.3.2.1. Consider the Need to Power Down the FPGA Portion While Keeping the HPS Running 4.3.2.2. Consider Desired HPS Boot Clock Frequency
4.3.3. Pin Connection Considerations for Board Designs x
4.3.3.1. Device Power-Up
4.5. Design Guidelines for HPS Interfaces x
4.5.1. HPS EMAC PHY Interfaces 4.5.2. USB Interface Design Guidelines 4.5.3. QSPI Flash Interface Design Guidelines 4.5.4. SD/MMC and eMMC Card Interface Design Guidelines 4.5.5. NAND Flash Interface Design Guidelines 4.5.6. UART Interface Design Guidelines 4.5.7. I2C Interface Design Guidelines 4.5.8. SPI Interface Design Guidelines
4.5.1. HPS EMAC PHY Interfaces x
4.5.1.1. PHY Interfaces Connected Through HPS Dedicated I/O 4.5.1.2. PHY Interfaces Connected Through FPGA I/O 4.5.1.3. Common PHY Interface Design Considerations
4.5.1.1. PHY Interfaces Connected Through HPS Dedicated I/O x
4.5.1.1.1. RGMII
4.5.1.2. PHY Interfaces Connected Through FPGA I/O x
4.5.1.2.1. GMII/MII 4.5.1.2.2. Adapting to RGMII 4.5.1.2.3. Adapting to RMII 4.5.1.2.4. Adapting to SGMII 4.5.1.2.5. MDIO
4.5.1.3. Common PHY Interface Design Considerations x
4.5.1.3.1. Signal Integrity
5. Embedded Software Design Guidelines for SoC FPGAs x
5.1. Embedded Software for HPS: Design Guidelines 5.2. Flash Device Driver Design Considerations 5.3. SD Card Low Power Mode Design Considerations 5.4. HPS ECC Design Considerations 5.5. HPS SDRAM Considerations
5.1. Embedded Software for HPS: Design Guidelines x
5.1.1. Assembling the Components of Your Software Development Platform 5.1.2. Selecting an Operating System for Your Application 5.1.3. Assembling your Software Development Platform for Linux 5.1.4. Assembling a Software Development Platform for a Bare-Metal Application 5.1.5. Assembling your Software Development Platform for a Partner OS or RTOS 5.1.6. Choosing Boot Loader Software 5.1.7. Selecting Software Tools for Development, Debug and Trace
5.1.1. Assembling the Components of Your Software Development Platform x
5.1.1.1. Golden Hardware Reference Design
5.1.2. Selecting an Operating System for Your Application x
5.1.2.1. Linux or RTOS 5.1.2.2. Bare Metal 5.1.2.3. Using Symmetrical vs. Asymmetrical Multiprocessing (SMP vs. AMP) Modes
5.1.3. Assembling your Software Development Platform for Linux x
5.1.3.1. Golden System Reference Design (GSRD) for Linux 5.1.3.2. Source Code Management Considerations GUIDELINE: Manage your own Git repositories and do not assume the contents of the repositories available on the altera-opensource site remains available. Managing Git repositories can be achieved in many ways, such as using a Git service provider. Some benefits of managing your own Git repositories include build reproducibility, source code management and leveraging the distributed model enabled by Git. GUIDELINE: If you rebuild the Angstrom rootfilesystem and require repeatability, you must keep a copy of the Yocto downloads folder that was used for the build. 5.1.3.3. GSRD for Linux Development Flow 5.1.3.4. GSRD for Linux Build Flow 5.1.3.5. Linux Device Tree Design Considerations
5.1.7. Selecting Software Tools for Development, Debug and Trace x
5.1.7.1. Select Software Build Tools 5.1.7.2. Select Software Debug Tools 5.1.7.3. Select Software Trace Tools
5.4. HPS ECC Design Considerations x
5.4.1. General ECC Design Considerations 5.4.2. System-Level ECC Control, Status and Interrupt Management 5.4.3. ECC for L2 Cache Data Memory 5.4.4. ECC for Flash Memory
5.5. HPS SDRAM Considerations x
5.5.1. Using the Preloader To Debug the HPS SDRAM 5.5.2. Access HPS SDRAM via the FPGA-to-SDRAM Interface
5.5.1. Using the Preloader To Debug the HPS SDRAM x
5.5.1.1. Enable Runtime Calibration Report 5.5.1.2. Change DLEVEL To Get More Debug Information 5.5.1.3. Enable Example Driver for HPS SDRAM 5.5.1.4. Change Data Pattern in Example Driver 5.5.1.5. Example Code to Write and Read from All Addresses 5.5.1.6. Read/Write to HPS Register in Preloader 5.5.1.7. Check HPS PLL Lock Status in Preloader
A. Support and Documentation x
A.1. Support A.2. Software Documentation
B. Additional Information x
B.1. Cyclone® V and Arria® V SoC Device Guidelines Revision History
1. Overview of the Design Guidelines for Cyclone® V SoC FPGAs and Arria® V SoC FPGAs
2. Background: Comparison between Cyclone® V SoC FPGA and Arria® V SoC FPGA HPS Subsystems
3. Design Guidelines for HPS portion of SoC FPGAs
4. Board Design Guidelines for SoC FPGAs
5. Embedded Software Design Guidelines for SoC FPGAs
A. Support and Documentation
B. Additional Information

5.1.3.2. Source Code Management Considerations

The GSRD build process relies on several git trees that are available online, including:

Table 10.  Git Tree Link
Git Tree Link
Intel SoC FPGA Linux Kernel

https://github.com/altera-opensource/linux-socfpga

Intel SoC FPGA Linux designs

https://github.com/altera-opensource/linux-refdesigns

Intel SoC FPGA Angstrom recipes https://github.com/altera-opensource/angstrom-socfpga
Note: Intel® provides Linux* enablement, upstreams to mainline and collaborates with the Linux* community. Intel® provides two kernel versions, the latest stable kernel (N) and latest LTSI kernel (M) and drops support for previous Linux* kernel versions (N-1, M-1). At any point in time the (N, N-1, M, M-1) versions are available from the kernel repository. Older kernel versions are removed.

GUIDELINE: Manage your own Git repositories and do not assume the contents of the repositories available on the altera-opensource site remains available. Managing Git repositories can be achieved in many ways, such as using a Git service provider. Some benefits of managing your own Git repositories include build reproducibility, source code management and leveraging the distributed model enabled by Git.

The GSRD uses the Angstrom rootfilesystem, built using Yocto recipes. The recipes pull in various open source package sources, and build them into the rootfilesystem. Because some of these recipes are generic, and do not refer to a specific version, the end result may be different from one build to another.

GUIDELINE: If you rebuild the Angstrom rootfilesystem and require repeatability, you must keep a copy of the Yocto downloads folder that was used for the build.

Level Two Title