AWS FPGA Hardware Development Kit (HDK) ======================================= Table of Contents ----------------- - `HDK Overview <#hdk-overview>`__ - `Getting Started <#getting-started>`__ - `Quick Start HW and SW Example: Host-to-FPGA Communication via the OCL Interface <#quick-start-hw-and-sw-example-host-to-fpga-communication-via-the-ocl-interface>`__ - `Build Accelerator AFI using HDK Design Flow <#build-accelerator-afi-using-hdk-design-flow>`__ - `Step 1. Setup Development Environment <#step-1-setup-development-environment>`__ - `Step 2. Clone Developer Kit Repository <#step-2-clone-developer-kit-repository>`__ - `Step 3. Setup Environment for HDK Design Flow <#step-3-setup-environment-for-hdk-design-flow>`__ - `Step 4. Build CL Design Check Point (DCP) <#step-4-build-cl-design-check-point-dcp>`__ - `Step 5. Explore Build Artifacts <#step-5-explore-build-artifacts>`__ - `Step 6. Submit Generated DCP for AFI Creation <#step-6-submit-generated-dcp-for-afi-creation>`__ - `Step 7. Load Accelerator AFI on F2 Instance <#step-7-load-accelerator-afi-on-f2-instance>`__ - `Step 8. Validate your AFI using Example Runtime Software <#step-8-validate-your-afi-using-example-runtime-software>`__ - `AFI PCIe IDs <#afi-pcie-ids>`__ - `CL Examples <#cl-examples>`__ - `cl_axil_reg_access <#cl-axil-reg-access>`__ - `cl_sde <#cl-sde>`__ - `cl_dram_hbm_dma <#cl-dram-hbm-dma>`__ - `cl_mem_perf <#cl-mem-perf>`__ - `CL_TEMPLATE - Create your own design <#cl-template-to-create-your-own-design>`__ - `CL Example Hierarchy <#cl-example-hierarchy>`__ - `Design <#design>`__ - `Verification <#verification>`__ - `Software <#software>`__ - `Build <#build>`__ - `HDK Common Library <#hdk-common-library>`__ - `/shell_stable <#shell-stable>`__ - `/verif <#verif>`__ - `/ip <#ip>`__ - `/lib <#lib>`__ - `Next Steps <#next-steps>`__ HDK Overview ------------ The HDK design flow enables developers to create RTL-based accelerator designs for F2 instances using AMD Vivado. HDK designs must be integrated with Small Shell, which does not include a built-in Direct Memory Access (DMA) engine and offers full resources in the top Super Logic Region (SLR) of the FPGA to developers. Getting Started --------------- Quick Start HW and SW Example: Host-to-FPGA Communication via the OCL Interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The `cl_axil_reg_access `__ example is the recommended starting point for new HDK developers. It demonstrates host-to-FPGA register communication using the `OCL AXI-Lite interface <./docs/AWS-Shell-Interface-Specification.html>`__ by implementing a simple 32-bit adder: the host writes two operands to FPGA registers, triggers the addition, and reads back the result. The example can be run by following the steps: 1. Build and ingest the `cl_axil_reg_access <./cl/examples/cl-demo/cl-axil-reg-access/README.html>`__ example by following the `Build Accelerator AFI using HDK Design Flow <#build-accelerator-afi-using-hdk-design-flow>`__ section below 2. `Load the AGFI <#step-7-load-accelerator-afi-on-f2-instance>`__ generated by the ``create-fpga-image`` command 3. Follow the `cl_axil_reg_access software runtime instructions <./cl/examples/cl-demo/cl-axil-reg-access/README.html#software-runtime>`__ to compile and run a test, for example ``./test_sum`` Build Accelerator AFI using HDK Design Flow ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section provides a step-by-step guide to build an F2 AFI using the HDK design flow. The flow starts with an existing Customer Logic (CL) example design. Steps 1 through 3 demonstrate how to set up the HDK development environment. Steps 4 through 5 show the commands used to generate CL Design Checkpoint (DCP) files and other build artifacts. Steps 6 and 7 demonstrate how to submit the DCP file to generate an AFI for use on F2 instances. Step 1. Setup Development Environment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Developers can either use the `AWS-provided developer AMI <./../User-Guide-AWS-EC2-FPGA-Development-Kit.html#fpga-developer-ami>`__ for F2 or their `on-premise development environment <./docs/on-premise-licensing-help.html>`__ for this demo. Step 2. Clone Developer Kit Repository ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: bash git clone https://github.com/aws/aws-fpga.git Step 3. Setup Environment for HDK Design Flow ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The `hdk_setup.sh `__ script needs to be sourced for each terminal and takes ~2 minutes to complete when first run. .. code-block:: bash cd aws-fpga source hdk_setup.sh After the setup is done successfully, you should see ``AWS HDK setup PASSED``. Sourcing ``hdk_setup.sh`` does the following: - Verifies a supported Vivado installation - Sets up all environment variables required by the HDK design flow - Generates IP simulation models for CL examples - Downloads all required shell files from a shared S3 bucket Step 4. Build CL Design Check Point (DCP) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ After the HDK design environment is set up, you are ready to build a design example. Run the following commands to build CL DCP files in Vivado. This tutorial uses the `cl_sde `__ example. The same steps can be used for any other `CL examples `__. .. code-block:: bash cd hdk/cl/examples/cl_sde export CL_DIR=$(pwd) cd build/scripts ./aws_build_dcp_from_cl.py -c cl_sde The Shell supplies two base clocks to the CL: a 250MHz ``clk_main_a0`` clock and a 100MHz ``clk_hbm_ref`` clock. However, the CL can run at higher frequencies using locally generated clocks. F2 Developer Kit offers an `AWS Clock Generation (AWS_CLK_GEN) IP <./docs/AWS-CLK-GEN-spec.html>`__ that you can leverage in your design to generate CL clocks with frequencies specified in the `Clock Recipes User Guide <./docs/Clock-Recipes-User-Guide.html>`__. Run the command below to build a DCP with desired clock recipes: .. code-block:: bash cd hdk/cl/examples/cl_mem_perf export CL_DIR=$(pwd) cd build/scripts ./aws_build_dcp_from_cl.py -c cl_mem_perf --aws_clk_gen --clock_recipe_a A1 --clock_recipe_b B2 --clock_recipe_c C0 --clock_recipe_hbm H2 **NOTE**: The `cl_sde `__ example does not contain the AWS_CLK_GEN component. This command uses the `cl_mem_perf `__ example to demonstrate the AWS_CLK_GEN usage. A few more notes on `aws_build_dcp_from_cl.py `__: - Use ``--mode small_shell`` option to build CL designs with Small Shell. - Use ``--cl `` option to build a different CL design. This is default to ``cl_dram_hbm_dma``. - Use ``--aws_clk_gen`` option to annotate the use of `AWS clock generation block <./docs/AWS-CLK-GEN-spec.html>`__ and `customer clock recipes <./docs/Clock-Recipes-User-Guide.html>`__. - Use ``--no-encrypt`` option to disable encryption of the design’s source code and DCPs. Encryption, enabled by default, may impede debugging as errors from encrypted envelope do not provide meaningful information. - The script also allows developers to pass different Vivado directives as shown below: - ``--place ``: Default to ``SSI_SpreadLogic_high`` placement strategy. Please refer to `Vivado User Guide `__ for supported directives. - ``--phy_opt `` : Default to ``AggressiveExplore`` physical optimization strategy. Please refer to `Vivado User Guide `__ for supported directives - ``--route `` : Default to ``AggressiveExplore`` routing strategy. Please refer to `Vivado User Guide `__ for supported directives. - Run ``./aws_build_dcp_from_cl.py --help`` to see more build options available in building CL designs. Step 5. Explore Build Artifacts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ While Vivado is running, a build log file ``YYYYY_MM_DD-HHMMSS.vivado.log`` will be created in ``$CL_DIR/build/scripts`` to track the build’s progress. DCP build times will vary based on the design size and complexity. The examples in the development kit take between 30 to 90 minutes to build. After the design is finished building, the following information will be shown at the bottom of the log file: .. code-block:: bash tail ... AWS FPGA: (16:05:44): Finished building design checkpoints for customer design cl_sde ... INFO: [Common 17-206] Exiting Vivado at ... Generated post-route DCP and design manifest files are archived into a tarball file ``.Developer_CL.tar`` and saved in the ``$CL_DIR/build/checkpoints/`` directory. All design timing reports are saved in the ``$CL_DIR/build/reports/`` directory. ⚠️ If Vivado cannot achieve timing closure for the design, the post-route DCP file name will be marked with ``.VIOLATED`` as an indicator. Developers need to refer to the DCPs and timing reports for detailed timing failures. ⚠️ The build process will generate a DCP tarball file regardless of the design’s timing closure state. However, in case of a DCP with timing failures, the design’s functionality is no longer guaranteed. Therefore, the AFI created using this DCP should be used for testing purpose ONLY. The following warning is shown in this case: .. code-block:: text !!! WARNING: Detected a post-route DCP with timing failure for AFI creation. Design functionalities are NOT guaranteed. Step 6. Submit Generated DCP for AFI Creation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Once developers have built their DCP, they may submit their FPGA design for AFI creation. Before doing so, an IAM role capable of S3 and EC2 access must be attached to the instance where the DCP will be submitted from. See the `Setting Up IAM Roles for Use with the AWS EC2 FPGA Development Kit <../developer-resources/Setting-up-IAM-roles-for-devkit-use.html#afi-creation-permissions>`__ guide for the required permissions. 1. Execute the `create_afi.py utility `__ from anywhere within the ``aws-fpga`` repository: - ``$AWS_FPGA_REPO_DIR/hdk/scripts/create_afi.py`` - May require a Python virtual environment which can be started with: ``source $AWS_FPGA_REPO_DIR/hdk/scripts/start_venv.sh`` 2. OR: Upload the DCP to S3 and specify all fields to the ``aws ec2 create-fpga-image`` utility according to instructions in `Manual AFI Creation <./docs/Amazon-FPGA-Images-Afis-Guide.html#option-2-manual-afi-creation>`__ **NOTE: Additional information about AFI’s and surrounding tools can be found in the** `Amazon FPGA Images (AFIs) Guide <./docs/Amazon-FPGA-Images-Afis-Guide.html>`__ Step 7. Load Accelerator AFI on F2 Instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Now that your AFI is available, it can be tested on an F2 instance. The instance can be launched using any preferred AMI, private or public, from the AWS EC2 AMI Catalog. AWS recommends using AMIs with `similar OS and kernel versions <../User-Guide-AWS-EC2-FPGA-Development-Kit.html#fpga-developer-ami>`__ to those of our developer AMIs. Now you need to install the FPGA Management tools by sourcing the ``sdk_setup.sh`` script: .. code-block:: bash cd aws-fpga source sdk_setup.sh Once the tools are installed, you can load the AFI onto a slot on the F2 instance. It is a good practice to clear any previously loaded AFI from that slot: .. code-block:: bash $ sudo fpga-clear-local-image -S 0 AFI 0 No AFI cleared 1 ok 0 0x10212415 AFIDEVICE 0 0x1d0f 0x9048 0000:00:1e.0 You can also invoke the ``fpga-describe-local-image`` command to learn which AFI, if any, is loaded onto a particular slot. For example, if the slot is cleared (``slot 0`` in this example), you should get an output similar to the following: .. code-block:: bash $ sudo fpga-describe-local-image -S 0 -H Type FpgaImageSlot FpgaImageId StatusName StatusCode ErrorName ErrorCode ShVersion AFI 0 No AFI cleared 1 ok 0 0x10212415 Type FpgaImageSlot VendorId DeviceId DBDF AFIDEVICE 0 0x1d0f 0x9048 0000:00:1e.0 If ``fpga-describe-local-image`` API call returns a status ``busy``, the FPGA is still performing the previous operation in the background. Please wait until the status is ``cleared`` as above. Now, let’s load your AFI onto the FPGA on ``slot 0``: .. code-block:: bash $ sudo fpga-load-local-image -S 0 -I agfi-0925b211f5a81b071 AFI 0 agfi-0925b211f5a81b071 loaded 0 ok 0 0x10212415 AFIDEVICE 0 0x1d0f 0x9048 0000:00:1e.0 **NOTE**: *The FPGA Management tools use the AGFI ID (not the AFI ID).* Now, you can verify that the AFI was loaded properly. The output shows the FPGA in the ``loaded`` state after the FPGA image “load” operation. The ``-R`` option performs a PCI device remove and rescan in order to expose the unique AFI Vendor and Device Id. .. code-block:: bash Type FpgaImageSlot FpgaImageId StatusName StatusCode ErrorName ErrorCode ShVersion AFI 0 agfi-0925b211f5a81b071 loaded 0 ok 0 0x10212415 Type FpgaImageSlot VendorId DeviceId DBDF AFIDEVICE 0 0x1d0f 0x9048 0000:00:1e.0 Step 8. Validate your AFI using Example Runtime Software ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Each CL example includes a runtime software binary, located in the ``$CL_DIR/software/runtime/`` subdirectory. Executing the software requires the corresponding AFI to be loaded onto the FPGA. This step demonstrates runtime software execution using the ``CL_SDE`` example. .. code-block:: bash # Ensure the $CL_DIR is pointing to the CL_SDE example directory $ cd $CL_DIR/software/runtime/ $ make ... Logical Core 1 (socket 0) forwards packets on 1 streams: RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 io packet forwarding packets/burst=32 nb forwarding cores=1 - nb forwarding ports=1 port 0: RX queue number: 1 Tx queue number: 1 Rx offloads=0x0 Tx offloads=0x0 RX queue: 0 RX desc=0 - RX free threshold=0 RX threshold registers: pthresh=0 hthresh=0 wthresh=0 RX Offloads=0x0 TX queue: 0 TX desc=0 - TX free threshold=0 TX threshold registers: pthresh=0 hthresh=0 wthresh=0 TX offloads=0x0 - TX RS bit threshold=0 Press enter to exit Telling cores to stop... Waiting for lcores to finish... ---------------------- Forward statistics for port 0 ---------------------- RX-packets: 10771136 RX-dropped: 0 RX-total: 10771136 TX-packets: 8160479 TX-dropped: 2610689 TX-total: 10771168 ---------------------------------------------------------------------------- +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++ RX-packets: 10771136 RX-dropped: 0 RX-total: 10771136 TX-packets: 8160479 TX-dropped: 2610689 TX-total: 10771168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Done. Stopping port 0... Stopping ports... Done Shutting down port 0... Closing ports... Done Bye... AFI PCIe IDs ------------ Customers can customize the PCIe IDs for generated AFIs, including Vendor ID (VID), Device ID (DID), Subsystem Vendor ID (SVID) and Subsystem Device ID (SSID), to facilitate the proper driver binding. These PCIe IDs are required for the AFI generation process and must be defined in the `cl_id_defines.vh `__ file under each example. Here is an example in the ``CL_SDE`` example: .. code-block:: verilog // CL_SH_ID0 // - PCIe Vendor/Device ID Values // 31:16: PCIe Device ID // 15: 0: PCIe Vendor ID // - A Vendor ID value of 0x8086 is not valid. // - If using a Vendor ID value of 0x1D0F (Amazon) then valid // values for Device ID's are in the range of 0xF000 - 0xF0FF. // - A Vendor/Device ID of 0 (zero) is not valid. `define CL_SH_ID0 32'hF002_1D0F // CL_SH_ID1 // - PCIe Subsystem/Subsystem Vendor ID Values // 31:16: PCIe Subsystem ID // 15: 0: PCIe Subsystem Vendor ID // - A PCIe Subsystem/Subsystem Vendor ID of 0 (zero) is not valid `define CL_SH_ID1 32'h1D51_FEDC When a DCP tarball file gets generated, the IDs are included in the `manifest file <./docs/AFI-Manifest.html>`__ within the tarball: .. code-block:: bash pci_device_id=0xF002 pci_vendor_id=0x1D0F pci_subsystem_id=0x1D51 pci_subsystem_vendor_id=0xFEDC CL Examples ----------- All examples have the following features: - Simulation model, tests, and scripts - Xilinx Vivado implementation scripts for generating bitstream `cl_axil_reg_access `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The cl_axil_reg_access example demonstrates basic host-to-FPGA register communication using the OCL AXI-Lite interface. It implements a simple 32-bit adder with control/status registers. Verification tests are included for register access patterns, arithmetic correctness, control/status handshaking, error handling, and reset behavior. See `cl_axil_reg_access `__ for more information. `cl_sde `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The cl_sde example implements the Streaming Data Engine (SDE) IP block into FPGA custom logic to demonstrate the `Virtual Ethernet Application <../sdk/apps/virtual-ethernet/README.html>`__. See `cl_sde `__ for more information `cl_dram_hbm_dma `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The cl_dram_hbm_dma example demonstrates the use and connectivity for many of the Shell/CL interfaces and functionality. The OCL (AXI-Lite) interface is used for general configuration, the PCIS (AXI4) interface is used for data traffic from the host to DDR and HBM DRAM channels in the CL (initiated by the host), and the PCIM (AXI4) interface is used for data traffic between the host and the CL (initiated by the CL). See `cl_dram_hbm_dma `__ for more information `cl_mem_perf `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The cl_mem_perf is a reference design for F2 where the objective is to demonstrate fine tuned data paths to HBM and DDR to achieve maximum throughput to the memories. The example also demonstrates datapath connectivity between Host, AWS Shell, Custom Logic (CL) region in the FPGA, HBM and DDR DIMM on the FPGA card. See `cl_mem_perf `__ for more information `CL_TEMPLATE `__ to Create your own design ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CL_TEMPLATE is targeted to help customers create a new CustomLogic example. Users can update the design, verification, and build flow to meet their needs without having to tear down a separate example. We recommend going through other CL examples before creating a new CL. All of the design files and tests can be compiled, simulated, built, and deployed on hardware (without any modifications). Users can add/update design files, add new verification tests, and add new build directives to meet their needs. A full guide on creating your own CL design can be found in `CL_TEMPLATE `__ To create a new CL example: .. code-block:: bash export NEW_CL_NAME='New CL Name' cd hdk/cl/examples ./create_new_cl.py --new_cl_name ${NEW_CL_NAME} CL Example Hierarchy -------------------- The following sections describe common functionality across all CL examples. `CL_TEMPLATE `__ can be used as a reference for what features are available in all CL examples; as well as what’s required to verify, test, and build. Design ~~~~~~ - All CL examples store the design files under ``/hdk/cl/examples/$CL_DIR/design/`` - For example: `/hdk/cl/examples/CL_TEMPLATE/design/ `__ - All IP designs available by default are stored in `/hdk/common/ip/cl_ip/ `__ - More can be added from the Xilinx Vivado IP catalog Verification ~~~~~~~~~~~~ - All CL examples utilize infrastructure found under `/hdk/common/verif/ `__ - Simulation libraries are generated under ``/hdk/common/verif/ip_simulation_libraries/`` - All examples should list out the ``/hdk/cl/examples/$CL_DIR/verif/tests/`` and ``Makefile.tests`` - For example $AWS_FPGA_REPO_DIR/`hdk/cl/examples/CL_TEMPLATE/verif/tests/ `__ - and `CL_TEMPLATE Makefile.tests `__ - All HDK examples support a SH_DDR with 64GB access with an optional user controlled auto-precharge mode. Users can select the DDR access modes as follows: .. code-block:: bash export TEST_NAME=test_ddr # To Run simulations with a 64 GB DDR DIMM make TEST=${TEST_NAME} USE_64GB_DDR_DIMM=1 # To Run simulations with a 64 GB DDR DIMM and DDR core with user controlled auto-precharge mode make TEST=${TEST_NAME} USE_AP_64GB_DDR_DIMM=1 **NOTE**: Please refer to `Supported_DDR_Modes.md <./docs/Supported-DDR-Modes.html>`__ for details on supported DDR configurations. After adding new design IPs, make sure to add the new simulation ``COMMON_LIBLISTS`` in $AWS-FPGA/`hdk/common/verif/tb/scripts/Makefile.common.inc `__ ⚠️ **Required for XSIM and Questa simulations** - Make sure to add the new simulation libraries to ``COMMON_LIBLISTS`` in $AWS_FPGA_REPO_DIR/`hdk/common/verif/tb/scripts/Makefile.common.inc `__ - This is required for XSIM and Questa simulations - These libraries can be found in $AWS_FPGA_REPO_DIR/`hdk/common/ip/cl_ip/cl_ip.ip_user_files/sim_scripts `__ followed by ``"IP_NAME"/"SIMULATOR"/"IP_NAME".sh`` - After adding new IP’s to $AWS_FPGA_REPO_DIR/`hdk/common/ip/ `__ the simulation libraries need to be recompiled - Run ``make regenerate_sim_libs =1`` Software ~~~~~~~~ All software runtime code can be found under the ``software`` directory. Build ~~~~~ - All CL examples utilize infrastructure found under $AWS_FPGA_REPO_DIR/`hdk/common/shell_stable/build `__ - Users can modify the following files to meet their build requirements: - `synth_CL_NAME.tcl `__ - top level script that reads design, IP, and constraint files - `cl_synth_user.xdc `__ - synthesis build constraints specific to that example - `cl_timing_user.xdc `__ - timing build constraints specific to that example - `small_shell_cl_pnr_user.xdc `__ - place and route constraints specific to that example’s small shell build For more information on `synth_CL_NAME.tcl `__ see: - `synth_cl_header.tcl `__ - `synth_cl_footer.tcl `__ After adding new design IPs: - Make sure to add the new ``.xci`` files to your `synthesis TCL script `__ HDK Common Library ------------------ This directory includes the shell versions, scripts, timing constraints and compile settings required during the AFI generation process. Developers should not modify or remove these files. `/shell_stable `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The `shell_stable `__ contains all the IPs, constraints and scripts for each shell release. `/verif `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The `verif directory `__ includes reference verification modules to be used as Bus Functional Models (BFM) as the external interface to simulate the CL. The verification related files common to all the CL examples are located in this directory. It has models, include, scripts, tb directories. The `verif models directory `__ includes simple models of the DRAM interface around the FPGA, shell, and card. You can also find Xilinx protocol checkers in this directory. The `verif scripts directory `__ includes scripts needed to generate DDR models and other scripts needed for HDK setup. The `verif include directory `__ includes sh_dpi_tasks.vh needed for DPI-C. The `verif tb directory `__ includes top level test bench related files common for all the CL examples. The verif ip_simulation_libraries directory is created during runtime and includes the simulation libraries and CL IP compilation for all supported simulators. `/ip `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The `ip directory `__ includes basic IP that is used by CL’s. `/lib `__ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The `lib directory `__ includes basic “library” elements that may be used by CL’s. - aws_clk_gen.sv - Generate clocks and resets to the CL design - aws_clk_regs.sv - Houses all the Control/Status Regs for AWS_CLK_GEN design - axi_clock_conv.sv - AXI-4 bus clock converter - axil_to_cfg_cnv.sv - Convert AXIL transaction into a simple CFG bus - axis_flop_fifo.sv - Flop based FIFO for AXI-Stream protocol - bram_1w1r.sv - BRAM (1 write/1 read port) RTL model. - bram_wr2.sv - BRAM (2 read/write ports) RTL model. - ccf_ctl.v - Clock crossing FIFO control block (pointers, address generation, etc…) - cdc_async_fifo.sv - Async FF-based FIFO for CDC - cdc_sync.sv - Single- or Multi-bit Synchronizer based on Xilinx XPM - flop_ccf.sv - Flop based clock crossing FIFO. - flop_fifo.sv - Flop based FIFO. - flop_fifo_in.sv - Flop based FIFO, where input is flopped by common flops (can be used for input signal registering). - ft_fifo.v - Flow through FIFO. - ft_fifo_p.v - Flow through FIFO to be used with pipelined RAM. - gray.inc - Gray code - hbm_wrapper.sv - Wrapper for HBM IP - interfaces.sv - Generic interfaces (AXI-4, AXI-L, etc…) - lib_pipe.sv - Pipeline block. - macros.svh - Instantiation macros (AXI-4, AXI-L, etc…) - mgt_acc_axl.sv - Used by AWS provided sh_ddr.sv - mgt_gen_axl.sv - Used by AWS provided sh_ddr.sv - ram_fifo_ft.sv - Ram based FIFO - rr_arb.sv - Round robin arbiter. - srl_fifo.sv - Shift register based fifo. - sync.v - Synchronizer - xpm_fifo.sv - Synchronous clock FIFO Next Steps ---------- - Start with the introductory `cl_axil_reg_access <./cl/examples/cl-demo/cl-axil-reg-access/README.html>`__ example to learn host-to-FPGA register access via the OCL interface - Review the `cl_dram_hbm_dma <./cl/examples/cl-dram-hbm-dma/README.html>`__ and `cl_sde `__ examples - `Run RTL Simulations <./docs/RTL-Simulation-Guide-for-HDK-Design-Flow.html>`__ on the example designs - Dive deep into `Shell interface specifications <./docs/AWS-Shell-Interface-Specification.html>`__ and `PCIe Memory map <./docs/AWS-Fpga-Pcie-Memory-Map.html>`__ - Create your own designs/Port F1 designs to F2 systems - Try the `Virtual JTAG XVC debug flow <./docs/Virtual-JTAG-XVC.html>`__ and understand the `shell timeout behavior <./docs/How-To-Detect-Shell-Timeout.html>`__ - (Optional) After creating your accelerator design, `create your own runtime AMI <../developer-resources/runtime-ami-builder/README.html>`__ Additional HDK Documentation ---------------------------- .. toctree:: :maxdepth: 1 docs/AWS-Shell-Interface-Specification docs/AWS-Shell-ERRATA docs/shell-floorplan docs/How-To-Detect-Shell-Timeout docs/AWS-CLK-GEN-spec docs/Clock-Recipes-User-Guide docs/AWS-CLI-FPGA-Commands docs/AWS-Fpga-Pcie-Memory-Map docs/Supported-DDR-Modes docs/RTL-Simulation-Guide-for-HDK-Design-Flow docs/Amazon-FPGA-Images-Afis-Guide docs/List-AFI-on-Marketplace docs/AFI-Manifest docs/on-premise-licensing-help docs/XDMA-Install docs/Virtual-JTAG-XVC docs/IPI-GUI-Vivado-Setup docs/IPI-GUI-AWS-IP docs/IPI-GUI-Examples docs/IPI-GUI-Flows `Back to Home <../index.html>`__