Accelerator Functional Unit Developer’s Guide for Intel® FPGA Programmable Acceleration Card

Download PDF
ID 683129
Date 7/20/2020
Public
Document Table of Contents
Document Table of Contents x
1. About this Document 2. Introduction 3. Getting Started with Platform Configuration 4. The Accelerator Functional Unit (AFU) 5. Developing AFUs with the OPAE SDK 6. AFU In-System Debug 7. Accelerator Functional Unit Developer's Guide for Intel® FPGA Programmable Acceleration Card Archives 8. Document Revision History for Accelerator Functional Unit Developer's Guide for Intel® FPGA Programmable Acceleration Card
1. About this Document x
1.1. Intended Audience 1.2. Conventions 1.3. Acronym List for Accelerator Functional Unit Developer’s Guide 1.4. Acceleration Glossary 1.5. Related Documentation
2. Introduction x
2.1. Getting Started with AFU Development 2.2. Base Knowledge and Skills Prerequisites
2.1. Getting Started with AFU Development x
2.1.1. Development Environment References 2.1.2. FPGA Tools and IP Requirements
4. The Accelerator Functional Unit (AFU) x
4.1. AFU Design Components 4.2. Basic Building Blocks
5. Developing AFUs with the OPAE SDK x
5.1. Overview of the OPAE SDK 5.2. Overview of the OPAE Platform for AFUs 5.3. OPAE SDK Design Flow for AFU Development
5.2. Overview of the OPAE Platform for AFUs x
5.2.1. Platform Device Classes 5.2.2. The Platform Interface Manager (PIM)
5.2.1. Platform Device Classes x
5.2.1.1. The clocks Device Class 5.2.1.2. The cci-p Device Class 5.2.1.3. The power Device Class 5.2.1.4. The error Device Class 5.2.1.5. The hssi Device Class 5.2.1.6. The local-memory Device Class
5.2.2. The Platform Interface Manager (PIM) x
5.2.2.1. Interface Transforms 5.2.2.2. Pipelining 5.2.2.3. Clock Crossing
5.3. OPAE SDK Design Flow for AFU Development x
5.3.1. Overview of the Design Flow 5.3.2. Design Flow Details
5.3.1. Overview of the Design Flow x
5.3.1.1. Minimal Flow Example 5.3.1.2. General Flow Example
5.3.1.1. Minimal Flow Example x
5.3.1.1.1. Specify the Platform Configuration 5.3.1.1.2. Design the AFU 5.3.1.1.3. Specify the Build Configuration 5.3.1.1.4. Generate the AF Build Environment 5.3.1.1.5. Generate the AF
5.3.1.2. General Flow Example x
5.3.1.2.1. Generate the ASE Build Environment 5.3.1.2.2. Verify the AFU with ASE
5.3.2. Design Flow Details x
5.3.2.1. Specify the Platform Configuration 5.3.2.2. Design the AFU 5.3.2.3. AFU Design Guidelines 5.3.2.4. Partial Reconfiguration Design Guidelines 5.3.2.5. Specify the Build Configuration 5.3.2.6. Generate the ASE Build Environment 5.3.2.7. Verify the AFU with ASE 5.3.2.8. Generate the AF Build Environment 5.3.2.9. Generate the AF
5.3.2.1. Specify the Platform Configuration x
5.3.2.1.1. Specify the AFU's UUID 5.3.2.1.2. Request a Top-level Interface 5.3.2.1.3. Extend a Top-level Interface 5.3.2.1.4. Request Device Interface Pipelining 5.3.2.1.5. Request Device Interface Clock-crossing 5.3.2.1.6. Specify a Requested Device as Optional 5.3.2.1.7. Specify AFU User Clock Timing
5.3.2.2. Design the AFU x
5.3.2.2.1. Start with a Top-level Module Template 5.3.2.2.2. Including the Platform Device Interface Definitions 5.3.2.2.3. Using the AFU UUID Header File 5.3.2.2.4. Clock Abstraction for the cci-p Device Interface 5.3.2.2.5. Generating an AF Build Environment for Source Development
5.3.2.3. AFU Design Guidelines x
5.3.2.3.1. General Guidelines 5.3.2.3.2. Utilizing Clock Resources 5.3.2.3.3. Interfacing with the FPGA Interface Manager (FIM)
6. AFU In-System Debug x
6.1. Remote Signal Tap Setup and Use
6.1. Remote Signal Tap Setup and Use x
6.1.1. Instrumenting the AFU Design for Signal Tap 6.1.2. Enable Remote Debug and Signal Tap 6.1.3. Generate the Remote Debug Enabled AF 6.1.4. Prepare the Remote Debug Host 6.1.5. Running a Remote Debug Session 6.1.6. Remote Debug Guidelines 6.1.7. Troubleshooting Remote Debug Connections
6.1.5. Running a Remote Debug Session x
6.1.5.1. Connect to the AFU Target 6.1.5.2. Using Signal Tap with a Remote Target Connection 6.1.5.3. Stimulating the Target AFU for In-System Debug 6.1.5.4. Disconnect from the AFU Target
6.1.5.3. Stimulating the Target AFU for In-System Debug x
6.1.5.3.1. Accessing the AFU in Shared Mode
1. About this Document
2. Introduction
3. Getting Started with Platform Configuration
4. The Accelerator Functional Unit (AFU)
5. Developing AFUs with the OPAE SDK
6. AFU In-System Debug
7. Accelerator Functional Unit Developer's Guide for Intel® FPGA Programmable Acceleration Card Archives
8. Document Revision History for Accelerator Functional Unit Developer's Guide for Intel® FPGA Programmable Acceleration Card

5.3.2.1.7. Specify AFU User Clock Timing

The clocks provided to the AFU by the clocks device interface are fixed in frequency except for the following user clocks:
  • uClk_usr
  • uClk_usrDiv2
The AFU specifies the frequency for uClk_usr in its platform configuration file using the following key:value pairs: 
afu-image:clock-frequency-high:[<float-value>|”auto”|”auto-<float-value>”]

afu-image:clock-frequency-low:[<float-value>|”auto”|”auto-<float-value>”]

The above key:value pairs drive timing closure on the user clocks during AF compilation and are used to bound the frequency value configured in the PLL circuits of the target hardware platform that provides the user clocks through the clocks interface. The chosen frequency may vary in each compilation.

Setting the value field to a float number (e.g., 200.0 to specify 200 MHz) drives the AF generation process to close timing within the bounds set by the low and high keys and set in the AF’s JSON metadata to specify the user clock PLL circuit frequency values.

Below is an example of .json file that sets the AFU uClk frequency to 300 MHz and uClk_div2 to 200 MHz. It also operates the CCI-P interface on uClk instead of the default pClk clock domain. 
{
   "version": 1,
   "afu-image": {
      "power": 0,
      "clock-frequency-high": "300",
      "clock-frequency-low": "200",
      "afu-top-interface":
         {
            "class": "ccip_std_afu"
            "module-ports" :
               [
                  {
                     "class": "cci-p",
                     "params":
                        {
                           "clock": "uClk_usr"
                        }
                  }
               ]
         },
      "accelerator-clusters":
         [
            {
               "name": "a_afu",
               "total-contexts": 1,
               "accelerator-type-uuid": "64e38106-4910-4488-ae90-94bfe46abfb3"
            }
         ]
   }
}

Below is an example of .json file that sets the AFU uClk frequency to 300 MHz or below and uClk_div2 to 150 MHz or below. The auto setting allows the build flow to make adjustments to the frequency in the event that timing cannot be met. It also operates the CCI-P interface on pClk and the local SDRAM on the uClk clock domain instead of the default SDRAM domain. 
{
   "version": 1,
   "afu-image": {
      "power": 0,
      "clock-frequency-high": "auto-300",
      "clock-frequency-low": "auto-150",
      "afu-top-interface":
         {
            "class": "ccip_std_afu_avalon_mm"
            "module-ports" :
               [
                  {
                     "class": "cci-p",
                     "params":
                        {
                           "clock": "pClk"
                        }
                  },
                  {
                     "class": "local-memory",
                     "params":
                        {
                           "clock": "uClk_usr"
                        }
                  }
               ]
         },
      "accelerator-clusters":
         [
            {
               "name": "b_afu",
               "total-contexts": 1,
               "accelerator-type-uuid": "233254b9-7db4-42a2-91db-1f1c53d12a76"
            }
         ]
   }
}
Warning: AFU developers must ensure the hardware design meets timing by analyzing the static timing reports in Timing Analyzer. AFU developers must inform software developers of the maximum operating frequency (Fmax) of the user clocks so that the maximum frequency never exceeds. Exceeding the Fmax of any clock leads to indeterministic behavior of the accelerator and potentially the overall system.
Note:

AFUs that use uClk or uClk_div2 may not have accurate timing analysis results shown in the Intel® Quartus® Prime timing summary. This is a result of PLL tuning post compilation that occurs to determine if your AFU meets timing. You must either load the compiled design in Timing Analyzer or view the results of the /build/output _files/timing_report directory. Each of these methods accounts for the uClk and uClk_div2 frequencies being adjusted. To determine if there are any failing paths in your design, you can inspect the file /build/output_files/timing_report/clocks.sta.fail.summary. If this file is empty then there are no timing failures in the design.

Note: There are two clock sources provided for the user clock. Clk_1x and Clk_2x. The high setting controls the Clk_2x and low setting controls the Clk_1x. There is a fixed relationship between these two clocks, except when low clock exceeds 300 MHz, then the high clock frequency matches the low clock frequency.

The "auto" setting enables the auto-timing closure mode during AF generation. The AF generation build process automatically converge on a maximum frequency of operation on the user clocks and generate AF JSON metadata to specify the auto-timing closure frequency achieved to OPAE tools.

You can combine the "auto" mode with an upper bound specification using the "auto-<float-value>" format (e.g., "auto-300" to specify auto-timing closure bounded to 300MHz).

For example, the hello_mem_afu sample AFU synchronizes all interfaces to uClk_usr and uses auto-timing closure mode:

$OPAE_PLATFORM_ROOT/hw/samples/hello_mem_afu/hw/rtl/hello_mem_afu.json

Level Two Title