The Intel^® Stratix^® 10 GX FPGA Development Kit Reference Platform targets a subset of the hardware features available in the Intel^® Stratix^® 10 GX FPGA Development Kit.

Figure 4. Hardware Features of the Intel^® Stratix^® 10 GX FPGA Development Kit

Features of the s10_ref Reference Platform:

• OpenCL Host

  The s10_ref Reference Platform uses a PCIe-based host that connects to the Intel^® Stratix^® 10 PCIe Gen3x8 hard IP core.

• OpenCL Global Memory

  The hardware provides one 2-gigabyte (GB) DDR4 SDRAM daughtercard that is mounted on the HiLo connector and instantiated in the design using Intel^® Stratix^® 10 External Memory Interface IP (J14 in Figure 4).

• FPGA Programming

  Via external cable and the Intel^® Stratix^® 10 GX FPGA Development Kit's on-board Intel^® FPGA Download Cable II interface.

• Guaranteed Timing

  The s10_ref Reference Platform relies on the Intel^® Quartus^® Prime Pro Edition compilation flow to provide guaranteed timing closure. The timing-clean s10_ref Reference Platform is preserved in the form of a precompiled post-fit netlist (that is, the base.qdb Intel^® Quartus^® Prime Database Export File). The Intel^® FPGA SDK for OpenCL™ Offline Compiler imports this preserved post-fit netlist into each OpenCL kernel compilation.

To compile your OpenCL kernel for a specific board variant, include the -board=<board_name> option in your aoc command (for example, aoc -board=s10gx myKernel.cl).

Dependencies

• Intel^® Stratix^® 10 PCIe* hard IP core
• Parameter Settings section of the Intel^® Stratix^® 10 Avalon^® -MM DMA Interface for PCIe Solutions User Guide

The kernel driver uses the Vendor ID, Subsystem Vendor ID and the Subsystem Device ID to identify the boards it supports. The SDK's programming flow checks the Device ID to ensure that it programs a device with a .aocx Intel^® FPGA SDK for OpenCL™ Offline Compiler executable file targeting that specific device.

The version ID for the s10_ref Reference Platform is 0xA0C7C1E5 (decimal from signed two's compliment is 1597521435).

Before communicating with any part of the FPGA system, the host first reads from this version_id register to confirm the following:

• The PCIe can access the FPGA fabric successfully
• The address map matches the map in the MMD software

Update the VERSION_ID parameter in the version_id component to a new value with every slave addition or removal from the PCIe BAR 4 bus, or whenever the address map changes.

The following image illustrates the platform software stack:

The runtime and Hardware Abstraction Layer (HAL) are part of the Intel^® FPGA SDK for OpenCL™ or Intel^® FPGA RTE for OpenCL. The Host-to-Device Memory Mapped Device (MMD) and PCIe Kernel Driver are delivered as a part of the BSP. Hence, apart from rebranding the BSP, you might need to update some code in the MMD or driver based on changes in the hardware project.

The two header files that describe the hardware design to the software are in the following locations:

• For Windows systems, the header files are in the INTELFPGAOCLSDKROOT\board\s10_ref\source\include folder, where INTELFPGAOCLSDKROOT is the path to the SDK installation.
• For Linux systems, the header files are in the INTELFPGAOCLSDKROOT/board/s10_ref/linux64/driver directory.

Following is a snapshot from INTELFPGAOCLSDKROOT/board/s10_ref/linux64/driver/hw_pcie_constants.h

//Version ID and Uniphy Status
#define ACL_VERSIONID_BAR                    4
#define ACL_VERSIONID_OFFSET            0xcfc0

This driver is installed using the Intel^® FPGA SDK for OpenCL™ install utility.

The s10_ref Reference Platform

• For Windows systems, the driver is in the <path_to_sl0_ref>\windows64\driver folder.

• For Linux, an open-source MMD-compatible kernel driver is in the <path_to_sl0_ref>/linux64/driver directory. The table below highlights some of the files that are available in this directory.

The source codes of an MMD library that demonstrates good performance are available in the INTELFPGAOCLSDKROOT/board/s10_ref/source/host/mmd directory. Refer to the Host-to-Device MMD Software Implementation section in the Stratix V Network Reference Platform Porting Guide for more information.

For more information on the MMD API functions, refer to the MMD API Descriptions section of the Intel^® FPGA SDK for OpenCL™ Custom Platform Toolkit User Guide.

Hardware Considerations

The instantiation process exports the DMA controller slave ports (that is, rd_dts_slave and wr_dts_slave) and master ports (that is, rd_dcm_master and wr_dcm_master) into the PCIe module. Two additional master ports, dma_rd_master and dma_wr_master, are exported for DMA read and write operations, respectively. For the DMA interface to function properly, all these ports must be connected correctly in the board.qsys Platform Designer system, where the PCIe hard IP is instantiated.

At the start of DMA transfer, the DMA Descriptor Controller reads from the DMA descriptor table in user memory, and stores the status and the descriptor table into a FIFO address. There are two FIFO addresses: Read Descriptor FIFO address and Write Descriptor FIFO address. After storing the descriptor table into a FIFO address, DMA transfers into the FIFO address can occur. The dma_rd_master port, which moves data from user memory to the device, must connect to the rd_dts_slave and wr_dts_slave ports. Because the dma_rd_master port connects to DDR4 memory also, the locations of the rd_dts_slave and wr_dts_slave ports in the address space must be defined in the hw_pcie_dma.h file.

The rd_dcm_master and wr_dcm_master ports must connect to the txs port. At the end of the DMA transfer, the DMA controller writes the MSI data and the done status into the user memory via the txs slave. The txs slave is part of the PCIe* hard IP in board.qsys.

All modules that use DMA must connect to the dma_rd_master and dma_wr_master ports. For DDR4 memory connection, Intel^® recommends implementing an additional pipeline to connect the two 256-bit PCIe DMA ports to the 512-bit memory slave. For more information, refer to the DDR4 Connection to PCIe* Host section.

Software Considerations

The MMD layer uses DMA to transfer data if it receives a data transfer request that satisfies both of the following conditions:

• A transfer size that is greater than 1024 bytes
• The starting addresses for both the host buffer and the device offset are aligned to 64 bytes

Two different modules generate the signal for the MSI line. The DMA controller in the PCIe hard IP core generates the DMA's MSI. The PCI Express interrupt request (IRQ) module (that is, the INTELFPGAOCLSDKROOT/board/s10_ref/hardware/s10gx/ip/irq_controller directory) generates the kernel interface's MSI.

For more information on the PCI Express IRQ module, refer to Handling PCIe Interrupts webpage.

Hardware Considerations

In INTELFPGAOCLSDKROOT/board/s10_ref/hardware/s10gx/board.qsys, the DMA MSI is connected internally; however, you must connect the kernel interface interrupt manually. For the kernel interface interrupt, the PCI Express IRQ module is instantiated as pcie_irq in board.qsys. The kernel interface interrupts connections are as follows:

• The kernel_irq_to_host port from the OpenCL Kernel Interface (kernel_interface) connects to the interrupt receiver, which allows the OpenCL kernels to signal the PCI Express IRQ module to send an MSI.
• The PCIe hard IP's msi_intfc port connects to the MSI_Interface port in the PCI Express IRQ module. The kernel interface interrupt receives the MSI address and the data necessary to generate the interrupt via msi_intfc.
• The IRQ_Gen_Master port on the PCI Express IRQ module, which is used to write the MSI, connects to the txs port on the PCIe hard IP.
• The IRQ_Read_Slave and IRQ_Mask_Slave ports connect to the pipe_stage_host_ctrl module on Bar 4. After receiving an MSI, the user driver can read the IRQ_Read_Slave port to check the status of the kernel interface interrupt, and read the IRQ_Mask_Slave port to mask the interrupt.

Software Considerations

The interrupt service routine in the Linux driver checks which module generates the interrupt. For the DMA's MSI, the driver reads the DMA descriptor table's status bit in local memory, as specified in the Read DMA Example section of the Intel^® Stratix^® 10 Avalon-MM DMA Interface for PCIe Solutions User Guide. For kernel interface's MSI, the driver reads the interrupt line sent by the kernel interface.

The interrupt service routine involves the following tasks:

1. Check DMA status on the DMA descriptor table.
2. Read the kernel status from the IRQ_READ_SLAVE port on the PCI Express IRQ module.
3. If a kernel interrupt was triggered, mask the interrupt by writing to the IRQ_MASK_SLAVE port on the PCI Express IRQ module. Then, execute the kernel interrupt service routine.
4. If a DMA interrupt was triggered, reset the DMA descriptor table and execute the DMA interrupt service routine.
5. If applicable, unmask a masked kernel interrupt.

You can set the ACL_PCIE_JTAG_CABLE or ACL_PCIE_JTAG_DEVICE_INDEX environment variables to disable the auto-detect feature and use values that you define.

Cable autodetect is useful when you have multiple devices connected to a single host.

The memory-mapped device (MMD) uses in-system sources and probes to identify the cable connected to the target board. You must instantiate the board_cade_id_0 register block and connect it to Bar 4 with the correct address map. You must also instantiate board_in_system_sources_probes_0, which is an in-system sources and probe component, and connect it to board_cade_id_0 register.

The MMD must be updated to take in the relevant changes. Add the scripts/find_jtag_cable.tcl script to your custom platform.

When the FPGA is being programmed via the Intel FPGA Download Cable, the MMD invokes quartus_stp to execute the find_jtag_cable.tcl script. The script identifies the cable and index number which is then used to program the FPGA through the quartus_pgm command.

In the current version of the s10_ref Reference Platform, all Platform Designer components related to the DDR4 global memory are now part of the INTELFPGAOCLSDKROOT/board/s10_ref/hardware/s10gx/mem.qsys Platform Designer subsystem within board.qsys.

Dependencies

DDR4 external memory interfaces

For more information on the DDR4 external memory interface IP, refer to the DDR3 Board Design Guidelines and DDR4 Board Design Guidelines sections in Intel Stratix 10 External Memory Interfaces IP User Guide.

The OpenCL™ Memory Bank Divider component sits in the datapath of host and FPGA memory. It accepts input from the DMA engine or BAR4 of PCIE and outputs to the FPGA memory. It is mainly useful in OpenCL™ BSPs with multiple memory banks, where it creates a larger memory space. Implementations of appropriate clock crossing and pipelining are based on the design floorplan and the clock domains specific to the computing card. The OpenCL Memory Bank Divider section in the Intel^® FPGA SDK for OpenCL™ Custom Platform Toolkit User Guide specifies the connection details of acl_bsp_snoop and acl_bsp_memorg_host ports.

The DDR4 IP core has one bank where its width and address configurations match those of the DDR4 SDRAM. Intel^® tunes the other parameters such as burst size, pending reads, and pipelining. These parameters are customizable for an end application or board design.

The INTELFPGAOCLSDKROOT/board/s10_ref/hardware/s10gx/board.qsys Platform Designer system uses a custom UniPHY Status to AVS IP component to aggregate different UniPHY status conduits into a single Avalon^® slave port named s. This slave port connects to the pipe_stage_host_ctrl component so that the PCIe host can access it.

A clock crosser is necessary because the kernel interface for the compiler must be clocked in the kernel clock domain. In addition, the width, address width, and burst size characteristics of the kernel interface must match those specified in the OpenCL Memory Bank Divider connecting to the host. Appropriate pipelining also exists between the clock crosser and the memory controller.

To get maximum kernel clock speed for Intel^® Stratix^® 10 devices, custom hyper-optimized CCB and AVMM Bridge are used in this path. The CCB is in mem.qsys and the bridge is stall-free that helps in f_max. The two end points, clock crosser and logic in the kernel supports AVMM stall latency.

The OpenCL Kernel Interface for S10 (kernel_interface) component exports an Avalon^® master interface (kernel_cra) that connects to this slave port. The OpenCL Kernel Interface for S10 component also generates the kernel reset (kernel_reset) that resets all logic in the kernel clock domain. The kernel_interface component also bridges the interrupt signal generated by the kernel to the pcie_irq block.

The Intel^® Stratix^® 10 FPGA Development Kit Reference Platform has one DDR4 memory bank. As a result, the Reference Platform instantiates the OpenCL Kernel Interface component and sets the Number of global memory systems parameter to 1.

It is an IP with AVMM slave and AVMM master, with all wires in between. This means a direct feed-through except that the address is ignored and the AVMM master always outputs address 0 while also outputting a constant 0x1 burst-count. This is important for the PR IP to ensure that the entire PR bitstream is written to the same target address of the PR IP.

The following are other components in the Intel^® Stratix^® 10 GX FPGA Development Kit Reference Platform (s10_ref) that you should familiarize yourself with:

• On-Chip Memory ROM (acds_version_rom): This read-only memory is a placeholder to burn Intel^® Quartus^® Prime software versions during bitstream compile. The version is required for checks during Intel^® FPGA SDK for OpenCL™ Offline Compiler programming flow.
• ACL temperature sensor for S10 (temperature_sensor): It is used to read and report the temperature sensed when using aocl diagnose utility.

Examples of design complexities:

• Designing a robust reset sequence
• Establishing a design floorplan
• Managing global routing
• Pipelining

Optimizations of these design complexities occur in tandem with one another to meet timing and board hardware optimization requirements.

These clock domains include:

• 100 MHz PCIe* clock
• 116 MHz DDR4 clock
• 50 MHz general clock (config_clk)
• Kernel clock that can have any clock frequency

With the exception of the kernel clock, the s10_ref Reference Platform is responsible for the timing closure of these clocks. However, because the board design must clock cross all interfaces in the kernel clock domain, the board design also has logic in the kernel clock domain. It is crucial that this logic is minimal and achieves an F_max higher than typical kernel performance.

These reset drivers include:

• The por_reset_counter in the INTELFPGAOCLSDKROOT/board/s10_ref/hardware/s10gx/board.qsys Platform Designer system implements the power-on-reset. The power-on-reset resets all the hardware on the device by issuing a reset for a number of cycles after the FPGA completes configuration.
• 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 power-on-reset and the perst reset are combined into a single global_reset; therefore, there are only two reset sources in the system (that is, global_reset and kernel_reset). However, these resets are explicitly synchronized across the various clock domains, resulting in several reset interfaces.

Important Considerations Regarding Resets

• Synchronizing resets to different clock domains might cause several high fan-out resets.

  Platform Designer automatically synchronizes resets to the clock domain of each connected component. In doing so, the Platform Designer 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_ddr4. However, they are synchronized to the PCIe and DDR4 clock domains, respectively.

• 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 that is necessary for synchronous resets. In addition, a clock holding in reset might prevent the 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.
  • The ddr4_calibrate IP resets the External Memory Interface controller separately.

• 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 s10_ref Reference Platform, kernel_reset resets all the kernel clock-crossing bridges between DDR on both the m0_reset and s0_reset interfaces.

Dependencies

• Chip Planner
• Logic Lock regions

Intel^® performed the following tasks iteratively to derive the floorplan of the s10_ref Reference Platform:

1. Compile a design without any region or floorplanning constraints in the flat revision.

   Intel^® recommends that you compile the design with several seeds. For more information, refer to Integrating Your Intel Stratix 10 Custom Platform with the Intel FPGA SDK for OpenCL.

2. Examine the placement of the IP cores (for example, PCIe* , DDR4, Avalon^® interconnect pipeline stages and adapters) for candidate locations, as determined by the Intel^® Quartus^® Prime Pro Edition software's Fitter. In particular, Intel^® recommends examining the seeds that meet or almost meet the timing constraints.

For the s10_ref Reference Platform, the PCIe* I/O is located in the lower left corner of the Intel^® Stratix^® 10 FPGA. The DDR4 I/O is located on the top part of the left I/O column of the device. Because the placements of the PCIe and DDR4 IP components tend to be close to the locations of their respective I/Os, you can apply Logic Lock regions to constrain the IP components to those candidate regions.

As shown in this Chip Planner view of the floorplan, the Logic Lock region (freeze_wrapper_inst|pr_region_inst) is spread out between the PCIe I/O and the top region of the left I/O column (that is, the DDR4 I/O area). In case of s10_ref reference platform, the Logic Lock region contains most of the kernel logic. The scatter area (shown in red) depicts the board interface (that is, static region) that is placed outside the ten Logic Lock regions assigned to kernel logic in base.qsf. The following figure illustrates the assignment in base.qsf.

Figure 9.  Logic Lock Regions in base.qsf File in s10_ref Reference Platform

You must create a dedicated Logic Lock region for the OpenCL™ kernel system for your custom platform. Furthermore, if you are logic-locking the board interface logic, ensure that you do not place kernel logic in the board's Logic Lock regions.

Intel^® recommends the following strategies to maximize the available FPGA resources for the OpenCL kernel system to improve kernel routability:

• The size of a Logic Lock region should be just large enough to contain the board logic and to meet timing constraints of the board clocks. Oversized Logic Lock regions consume FPGA resources unnecessarily.
• Avoid creating tightly-packed Logic Lock regions that cause very high logic utilization and high routing congestion.

  High routing congestion within the Logic Lock regions might decrease the Fitter's ability to route OpenCL kernel signals through the regions.

In the case where the board clocks are not meeting timing and the critical path is between the Logic Lock regions (that is, across region-to-region gap), insert back-to-back pipeline stages on paths that cross the gap. For example, if the critical path is between Region 1 and Region 2, lock down the first pipeline stage (an Avalon-MM Pipeline Bridge component) to Region 1, lock down the second pipeline stage to Region 2, and connect the two pipeline stages directly. This technique ensures that pipeline registers are on both sides of the region-to-region gap, thereby minimizing the delay of paths crossing the gap.

Refer to the Pipelining section for more information.

There is no restriction on the placement location of the OpenCL™ kernel on the device. As a result, the kernel clocks and kernel reset must distribute high fan-out signals globally.

In the Platform Designer, you can implement pipelines via an Avalon^® -MM Pipeline Bridge component by setting the following pipelining parameters within the Avalon^® MM Pipeline Bridge dialog box:

• Select Pipeline command signals
• Select Pipeline response signals
• Select both Pipeline command signals and Pipeline response signals

Examples of Pipeline Implementation

• Signals that traverse long distances because of the floorplan's shape or the region-to-region gaps require additional pipelines.

  The DMA at the bottom of the FPGA must connect to the DDR4 memory at the top of the FPGA. To achieve timing closure of the board interface logic at a DDR4 clock speed of 233 MHz, additional pipeline stages between the OpenCL™ Memory Bank Divider component and the DDR4 controller IP are necessary. In the Intel^® Stratix^® 10 GX FPGA Development Kit Reference Platform's board.qsys Platform Designer system, the pipeline stages are named pipe_stage .

  The middle pipeline stage, kernel_ddra_bridge , combines both the direct kernel DDR4 accesses and the accesses through the OpenCL Memory Bank Divider. The multistage pipeline approach ensures that the kernel entry point to the pipeline is neither geared towards the OpenCL Memory Bank Divider, which is close to the PCIe* IP core, nor the DDR4 IP core, which is at the very top of the FPGA.

The driver within the s10_ref Reference Platform can detect a failed calibration via the Uniphy Status to AVS IP, and retrigger calibration through the ddr4_calibrate IP block.

Both the SDK and the BSP contribute to the implementation of the SDK's guaranteed timing closure feature.

The SDK provides the IP to generate the kernel clock, and a post-flow script that ensures this clock is configured with a safe operating frequency confirmed by timing analysis. The SDK imports a post-fit netlist during a top compile that has already achieved timing closure on all non-kernel clocks.

In the import (that is, top) revision compilation, the compilation script compile_script.tcl invokes the INTELFPGAOCLSDKROOT/board/s10_ref/hardware/s10gx/scripts/post_flow_pr.tcl Tcl script in the s10_ref Reference Platform after every Intel^® Quartus^® Prime Pro Edition software compilation using quartus_cdb.

The post_flow_pr.tcl script also determines the kernel clock and configures it to a functional frequency.

Dependencies

Intel^® Quartus^® Prime Pro Edition compiler

Intel^® Quartus^® Prime software provides several mechanisms for preserving the placement and routing of some previously compiled logic and importing this logic into a new compilation. For Intel^® Stratix^® 10 devices, the previously compiled logic is imported into the compilation flow.

The Intel^® Quartus^® Prime Pro Edition compilation flow can preserve the placement and routing of the board interface partition via the exported Intel^® Quartus^® Prime Archive File. base.qar and base.qdb files contain all the database files for the base compilation of root_partition. The s10_ref Reference Platform is configured with the project revisions and partitioning that are necessary to implement the compilation flow. By default, the SDK invokes the Intel^® Quartus^® Prime Pro Edition software on the top revision. This revision is configured to import and restore the base.qdb file, which has been precompiled and exported from a base revision compilation.

When developing your Custom Platform from the s10_ref Reference Platform, it is essential to maintain the flat.qsf, base.qsf, top.qsf, and opencl_bsp_ip.qsf Intel^® Quartus^® Prime Settings Files.

The s10_ref Reference Platform includes two additional partitions: the Top partition and the kernel partition. The Top partition contains all logic, and the kernel partition contains only the kernel logic.

Following are the types of compile flows:

Flat Compile

A flat revision uses the flat.qsf settings file and performs a flat compilation of the entire design (BSP along with kernel generated hardware). The flat.qsf has minimal location constraints, and generally has all of the pin assignments (sourced using device.tcl) and basic settings to compile a hardware design. To compile a flat revision of your BSP, use -bsp-flow=flat modifier option with the aoc command.

Base Compile

A base revision uses the base.qsf settings file to compile the board support package. The base.qsf uses all the flat.qsf settings and adds the required location constraints and Logic Lock regions on top of it. The kernel clock target is relaxed during the base compilation so that the BSP hardware has more freedom to meet timing. A base.qar database is created to preserve the BSP hardware, which is the static region. The revision can be compiled using -bsp-flow=base modifier option with the aoc command.

Top Compile

The top flow, also known as the import compile, is generally the default flow of kernel compiles. It uses the top.qsf settings file for compilation and the base.qar from a base revision compile to import the pre-compiled netlist of the static region. It guarantees the timing closed static region and compiles only the kernel generated hardware. It also increases the kernel clock target to obtain the best kernel maximum operating frequency (f_max).

The order of the application of time constraints is based on the order of appearance of the top.sdc and top_post.sdc files in the flat.qsf file. To ensure proper SDC ordering, the opencl_bsp_ip.qsf file is sourced between top.sdc and top_post.sdc files. All IPs are added to opencl_bsp_ip.qsf during aoc compile flow. This ensures that the SDC order is top.sdc followed by SDCs for the IP components and then top_post.sdc in all aoc compiles.

For each hardware design inside your Custom Platform, your Custom Platform requires a board_spec.xml that describes the hardware to the SDK.

The following sections describe the implementation of these files for the Intel^® Stratix^® 10 GX FPGA Development Kit Reference Platform.

Details of each field in the board_env.xml file are available in the Creating the board_env.xml File section of the Intel^® FPGA SDK for OpenCL™ Custom Platform Toolkit User Guide.

Device

The device section contains the name of the device model file available in the INTELFPGAOCLSDKROOT/share/models/dm directory of the SDK and in the board spec.xml file. The used_resources element accounts for all logic outside of the kernel partition. The value of used_resources for alms equals the difference between the total number of adaptive logic modules (ALMs) used in final placement and the total number of ALMs available to the kernel partition. You can derive this value from the Partition Statistic section of the Fitter report after a compilation. Consider the following ALM categories within an example Fitter report:

Figure 13. Fitter Partition Statistics

The value of used_resources equals the total number of ALMs in l minus the total number of ALMs in freeze wrapper inst|pr_region_inst. In the example above, used_resources = 80273 - 25596 = 54677 ALMs.

Global Memory

In the board_spec.xml file, there is one global_mem section for DDR memory. Assign the string DDR to the name attribute of the global_mem element. The board instance in Platform Designer provides all of these interfaces. Therefore, the string board is specified in the name attribute of all the interface elements within global_mem.

• DDR

  Because DDR memory serves as the default memory for the board that the s10_ref Reference Platform targets, its address attribute begins at zero. Its config_addr is 0x018 to match the acl_bsp_memorg_host0x018 conduit used to connect to the corresponding OpenCL Memory Bank Divider for DDR.

  Attention: The width and burst sizes must match the parameters in the OpenCL Memory Bank Divider for DDR ( memory_bank_divider_ddr4a).

Interfaces

The interfaces section describes kernel clocks, reset, CRA, and snoop interfaces. The OpenCL Memory Bank Divider for the default memory (in this case, memory_bank_divider_ddr4a) exports the snoop interface described in the interfaces section. The width of the snoop interface should match the width of the corresponding streaming interface.

In the order from the longest to the shortest configuration time, the two FPGA programming methods are as follows:

• To maintain the previously programmed state after power cycling, use Flash programming.
• To replace both the FPGA periphery and the core, use the Intel^® Quartus^® Prime Programmer command-line executable (quartus_pgm) to program the device via cables such as the Intel^® FPGA Download Cable (formerly USB-Blaster).

For more information about Intel^® Stratix^® 10 GX FPGA programming flow and board bring-up, refer to the Intel^® Stratix^® 10 Development Kit Initialization guide in the <S10GX_BSP_Directory>/bringup directory.

Windows

The install.bat script is in the <your_custom_platform>\windows64\libexec directory, where <your_custom_platform> points to the top-level directory of your Custom Platform. This install.bat script triggers the install executable to install the SSG Driver on the host machine.

Linux

The install script is located in the <your_custom_platform>/linux64/libexec directory. This install script first compiles the kernel module in a temporary location and then performs the necessary setup to enable automatic driver loading after reboot.

Windows

The uninstall.bat script is located in the <your_custom_platform>\windows64\libexec directory, where <your_custom_platform> points to the top-level directory of your Custom Platform. This uninstall.bat script triggers the uninstall executable to uninstall the SSG Driver on the host machine.

Linux

The uninstall script is located in the <your_custom_platform>/linux64/libexec directory. This uninstall script removes the driver module from the linux kernel.

Without an argument, the utility returns the overall information of all the devices installed in a host machine. If a specific device name is provided as an argument (that is, aocl diagnose <device_name> ), the diagnose utility runs a memory transfer test and then reports the host-device transfer performance.

You can run the diagnose utility for multiple devices (that is, aocl diagnose <device_name1> <device_name2> <device_name3> ). If you want to run the diagnose utility for all devices, use the all option (that is aocl diagnose all).

The list-devices utility is similar to the diagnose utility. It first verifies the installation of the kernel driver and then lists all the devices.