RTL Kernels
Many hardware engineers have existing RTL IP (including Vivado® IP integrator based designs), or just feel comfortable implementing a kernel in RTL and develop it using Vivado. SDAccel™ allows RTL designs to be used, however they must adhere to the software and hardware requirements to be used within the tool flow and runtime library.
Requirements for Using an RTL Design as an RTL Kernel
An RTL design must meet both interface and software requirements to be used as an RTL kernel within the SDAccel framework.
It might be necessary to add or modify the original RTL design to meet these requirements, which are outlined in the following sections.
Kernel Interface Requirements
To satisfy the SDAccel execution model, an RTL kernel must adhere to the following interface requirements:
- One and only one AXI4-Lite interface is used to access control signals and pass arguments.
- At least one of the following interfaces (can have both):
- AXI4 master interface to communicate with memory.
- AXI4-Stream interface to
communicate between the kernels and/or with the host.Note: With the ap_ctrl_none kernel control interface option, AXI4 master interfaces cannot be used.
- At least one clock interface port.
The various interface requirements are summarized in the following table.
Port or Interface | Description | Comment |
---|---|---|
ap_clk | Primary clock input port |
|
ap_clk_2 | Secondary optional clock input port |
|
ap_rst_n | Primary active-Low reset input port |
|
ap_rst_n_2 | secondary optional active-Low reset input |
|
interrupt | Active-High interrupt. |
|
s_axi_control | One and only one AXI4-Lite slave control interface |
|
AXI4_MASTER | One or more AXI4 master interfaces for global memory access |
|
Kernel Software Requirements
RTL kernels have the same software interface model as OpenCL™ and C/C++ kernels. That is, they are seen by the host application as functions with a void return value, scalar arguments, and pointer arguments. For instance:
void mmult(unsigned int length, int *a, int *b, int *output)
The SDAccel execution model dictates the following:
- Scalar arguments are directly written to the kernel through an AXI4-Lite slave interface.
- Pointer arguments are transferred to/from memory.
- Kernels are expected to read/write data in global memory though one or more AXI4 memory map and/or stream directly between the host and kernel.
- Kernels are controlled by the host application through the control register (shown below) through the AXI4-Lite slave interface.
If the RTL design has a different execution model, it must be adapted to ensure that it can be completed in this manner.
The following table defines the required register map for a kernel to be used
within the SDAccel environment. The control register is
required by all kernels while the interrupt related registers are only required for designs with
interrupts. All user-defined registers must begin at location 0x10
; locations below this are reserved.
Address | Name | Description |
---|---|---|
0x0 | Control | Controls and provides kernel status. |
0x4 | Global Interrupt Enable | Used to enable interrupt to the host. |
0x8 | IP Interrupt Enable | Used to control which IP generated signal are used to generate an interrupt. |
0xC | IP Interrupt Status | Provides interrupt status. |
0x10 | Kernel arguments start at address 0x10 | Includes scalars and global memory arguments. |
The definition of the Control register bits differs depending on which of the following three modes of operation the kernel is operating (see Vivado Design Suite User Guide: High-Level Synthesis (UG902) for detailed descriptions of these modes of operation).
ap_ctrl_none
(that is, free-running kernels)ap_ctrl_hs
(that is, sequential kernels)ap_ctrl_chain
(that is, pipelined kernels)
The developer chooses the mode of operation of the kernel by complying with the definition of the respective Control registers defined below.
ap_ctrl_none
For ap_ctrl_none
mode, the kernel
starts as soon as it is out of reset and never stops. For streaming kernels only
(see Streaming Interfaces).
Bit | Name | Description |
---|---|---|
31:0 | Reserved | Reserved |
ap_ctrl_hs
In ap_ctrl_hs
mode, the driver
writes a 1 in ap_start
and waits for both ap_start
to be deasserted (guaranteeing the input data
is fully processed) and ap_done
to be asserted
(guaranteeing the output data is fully produced). The definition of the Control
register bits under this mode of operation is given in the following table.
The ap_ctrl_hs
kernels can and should only be
restarted after they are done. They do not allow pipelined/overlapping
execution.
Bit | Name | Description |
---|---|---|
0 | ap_start | Asserted by host when kernel can start processing data. Cleared by kernel on handshake with ap_ready. |
1 | ap_done | Asserted by kernel when it has finished producing output data. Cleared on read by host. |
2 | ap_idle | Asserted by kernel when it is idle (deprecated). |
3 | ap_ready | Asserted by kernel when it has finished processing input data. Self-cleared immediately. |
6:4 | Reserved | Reserved |
7 | auto_restart1 | If asserted, ap_start is held asserted by the kernel. Read/write access by the host. |
31:8 | Reserved | Reserved |
|
ap_ctrl_chain
In ap_ctrl_chain
mode of
operation, the driver asserts ap_start
and waits
for either:
ap_start
to be deasserted (guaranteeing the input data is fully processed) therefore allowing to start the next batch orap_done
to be asserted (guaranteeing the output data is fully produced) then assertsap_continue
(to allow the kernel to continue operation)
This mode is recommended if pipelined execution is desired. The
definition of the Control register bits for ap_ctrl_chain
mode is given in the following table.
Bit | Name | Description |
---|---|---|
0 | ap_start | Asserted by host when kernel can start processing data. Cleared by kernel on handshake with ap_ready. |
1 | ap_done | Asserted by kernel when it has finished producing output data. Cleared by kernel on handshake with ap_continue. |
2 | ap_idle | Asserted by kernel when it is idle (deprecated). |
3 | ap_ready | Asserted by kernel when it has finished processing input data. Self-cleared immediately. |
4 | ap_continue | Asserted by host when kernel can proceed with operation. Cleared immediately by kernel. |
6:5 | Reserved | Reserved |
7 | auto_restart1 | If asserted ap_start and ap_continue are held asserted. Read/write access by the host. |
31:8 | Reserved | Reserved |
|
Interrupt Registers
The following interrupt related registers are only required if the kernel has an interrupt.
Bit | Name | Description |
---|---|---|
0 | Global Interrupt Enable | When asserted by the host along with any of the IP Interrupt Enable bit, this interrupt is enabled. Read/write access by the host. |
31:1 | Reserved | Reserved |
Bit | Name | Description |
---|---|---|
0 | Channel 0 (ap_done) | When asserted along with the Global Interrupt Enable bit, interrupt will be asserted on ap_done assertion. Read/write access by host, and read only by kernel. |
1 | Channel 1 (ap_ready) | When asserted along with the Global Interrupt Enable bit, interrupt will be asserted on ap_ready assertion. Read/write access by host, and read only by kernel. |
31:2 | Reserved | Reserved |
Bit | Name | Description |
---|---|---|
0 | Channel 0 (ap_done) | Kernel asserts this interrupt status bit when an interrupt is asserted due to ap_done. If you disable interrupt on ap_done, this bit is never asserted by the kernel. Host must clear this bit by writing 1. |
1 | Channel 1 (ap_ready) | Kernel asserts this interrupt status bit when an interrupt is asserted due to ap_ready. If you disable interrupt on ap_ready, this bit is never asserted by the kernel. Host must clear this bit by writing 1. |
31:2 | Reserved | Reserved |
Interrupt
RTL kernels can optionally have an interrupt port containing a single interrupt.
The port name must be called interrupt
and be
active-High. It is enabled when both the Global Interrupt Enable (GIE) and Interrupt
Enable Register (IER) bits are asserted. Further, the interrupt is cleared only when
writing a one to asserted bits of the IP Interrupt Status Register.
If adding an interrupt
port to the kernel, the
kernel.xml file needs be updated with this information.
The kernel.xml is generated automatically when using the
RTL Kernel Wizard. For details on updating the file, see Create Kernel Description XML File.
RTL Kernel Wizard
The RTL Kernel Wizard automates some of the steps that need to be taken to ensure that the RTL IP is packaged into a kernel that can be integrated into a system in SDAccel.
The benefit of the wizard are:
- Automates some of the steps that must be taken to ensure that the RTL IP is packaged into a kernel that can be integrated into a system in SDAccel.
- Steps you through the process of specifying your software function model and interface model for the RTL kernel.
- Generates an RTL wrapper for the kernel that meets the RTL kernel interface requirements, based on the interface information provided.
- Automatically generates the AXI4-Lite interface module including the control logic and register file. The AXI4-Lite interface module is included in the generated top level RTL Kernel wrapper.
- Includes in the wrapper an example kernel IP module that you need to replace with your RTL IP design. The RTL IP developer must ensure correct connectivity between RTL IP with a wrapper template.
- A kernel.xml file is generated to match the software function prototype and behavior specified in the wizard.
The RTL Kernel Wizard generates a Vivado project containing an example design consisting of a simple adder RTL IP, called VADD. In addition, it generates an associated RTL wrapper matching the desired interface, control logic and register map (described above) based on the user Wizard input. You can use this wrapper to wrap your RTL IP into an RTL kernel accessible by theSDAccel framework.
If you do use the generated wrapper, you need to replace the generated RTL IP (VADD) with your RTL IP and connect to the wrapper.
The connections include clock(s), reset(s), AXI4-Lite interface, memory interfaces, and optionally streaming interfaces. The number of connections will be based on the interface information provided to the kernel wizard (for example, choosing two AXI4 memory interfaces). It is necessary to manually make these connections to your IP and validate the design.
The RTL Kernel Wizard generates a Vivado project for the top-level RTL kernel wrapper and the generated files. This enables you to easily update and optimize the RTL kernel.
Furthermore, the RTL Kernel Wizard also generates a simple test bench for the generated RTL kernel wrapper and a sample host code to exercise the example RTL kernel. This example test bench and host code must be modified to test the your RTL IP design accordingly.
Using the RTL Kernel Wizard is described in the following subsections.
Launching the RTL Kernel Wizard
The RTL Kernel Wizard can be launched with two different methods: from the SDx™ Development Environment or from the Vivado Integrated Design Environment (IDE). The SDx Development Environment provides a more seamless experience by automatically importing the generated kernel/example host code back into the SDx project.
- Launch the SDx Development Environment.
- Create an SDx Project (Application Project Type).
- Click .
To launch the RTL Kernel Wizard from Vivado IDE, perform the following:
- Create a new Vivado project choosing the same device as exists on the platform you intend to target. If you do not know your target device, choose the default part.
- Go to the IP catalog by clicking the IP catalog button.
- Type
wizard
in the IP catalog search box. - Double-click SDx Kernel Wizard to launch the wizard.
Using the RTL Kernel Wizard
The wizard is organized into pages that break down the process of creating a kernel into smaller steps. To navigate between pages, click Next and select Back. To finalize the kernel and build a project based on the inputs of the wizard, click OK. Each of the following sections describes each page and its input options.
RTL Kernel Wizard General Settings
Kernel Identification
The following are three settings in the General Settings tab.
- Kernel name
- The kernel name. This will be the name of the IP, top-level module name, kernel, and C/C++ functional model. This identifier shall conform to C and Verilog identifier naming rules. It must also conform to Vivado IP integrator naming rules, which prohibits underscores except when placed in between alphanumeric characters.
- Kernel vendor
- The name of the vendor. Used in the Vendor/Library/Name/Version (VLNV) format described in the Vivado Design Suite User Guide: Designing with IP (UG896).
- Kernel library
- The name of the library. Used in the VLNV. Must conform to the same identifier rules.
Kernel Options
- Kernel type
- An RTL kernel type consists of a Verilog RTL top-level module with a Verilog control register module and a Verilog kernel example inside the top-level module. The block design kernel type also delivers a Verilog RTL top-level module, but instead it instantiates an IP integrator block diagram inside of a Verilog RTL top-level module. The block design consists of a MicroBlaze™ subsystem that uses a block RAM exchange memory to emulate the control registers. Example MicroBlaze software is delivered with the project to demonstrate using the MicroBlaze to control the kernel.
- Kernel control interface
- Selects the kernel mode of operation. Choices include
ap_ctrl_hs
,ap_ctrl_none
, andap_ctrl_chain
. For more information, see Kernel Software Requirements.
- Enable MicroBlaze debug (Only available on select configurations)
- Adds a MicroBlaze Debug Module (MDM) to a Block Design Kernel type example. The boundary scan interface of the MDM module is connected to the top-level of the kernel. The debug interface is connected to the MicroBlaze instance. This option is only available for platforms that support system debug over the Xilinx® Virtual Cable and if the Kernel type is set as Block Design.
Clock and Reset Options
- Number of clocks
- Sets the number of clocks used by the kernel. Every kernel has a primary
clock and reset called
ap_clk
andap_rst_n
. All AXI interfaces on the kernel are driven with this clock and reset. When selecting Number of clocks to 2, a secondary clock and related reset are provided to be used by the kernel internally. The secondary clock and reset are calledap_clk_2
andap_rst_n_2
, respectively. This secondary clock supports independent frequency scaling and is independent from the primary clock. The secondary clock is useful if the kernel clock needs to run at a faster or slower rate than the AXI4 interfaces, which must be clocked on the primary clock. When designing with multiple clocks, proper clock domain crossing techniques must be used to ensure data integrity across all clock frequency scenarios.
- Has reset
- Specifies whether to include a top-level reset input port to the kernel. Omitting a reset can be useful to improve routing congestion of large designs. Any registers that would normally have a reset in the design should have proper initial values to ensure correctness. If enabled, there is a reset port included with each clock. Block Design type kernels must have a reset input.
Scalar Arguments
Scalar arguments are used to pass control type information to the kernels. Scalar arguments cannot be read back from the host. For each argument that is specified, a corresponding register is created to facilitate passing the argument from software to hardware. See the following figure.
- Number of scalar kernel input arguments
- Specifies the number of scalar input arguments to pass to the kernel. For each number specified, a table row is generated that allows customization of the argument name and argument type. There is no required minimum number of scalars and the maximum allowed by the wizard is 64.
Scalar Input Argument Definition
The following is the scalar input argument definition:
- Argument name
- The argument name is used in the generated Verilog control register module as an output signal. Each argument is assigned an ID value. This ID value is used to access the argument from the host software. The ID value assignments can be found on the summary page of this wizard. To ensure maximum compatibility, the argument name follows the same identifier rules as the kernel name.
- Argument type
- Specifies the data type, and hence bit-width, of the argument. This affects the register width in the generated Verilog module. The data types available are limited to the ones specified by the OpenCL C Specification Version 2.0 in "6.1.1 Built-in Scalar Data Types" section. The specification provides the associated bit-widths for each data type. The RTL wizard reserves 64 bits for all scalars in the register map regardless of their argument type. If the argument type is 32 bits or less, the RTL Wizard sets the upper 32 bits (of the 64 bits allocated) as a reserved address location. Data types that represent a bit width greater than 32 bits require two write operations to the control registers.
Global Memory
Global memory is accessed by the kernel through AXI4 master interfaces (see the following figure).
Each AXI4 interface operates independently of each other, and each AXI4 interface can be connected to one or more memory controllers to off-chip memory such as DDR4. Global memory is primarily used to pass large data sets to and from the kernel from the host. It can also be used to pass data between kernels. See the Memory Performance Optimizations for AXI4 Interface section for recommendations on how to design these interfaces for optimal performance. For each interface, example AXI master logic is generated in the RTL kernel to provide a starting point and can be discarded if not used.
In the Global Memory dialog box, you can specify the Number of AXI master interfaces present on the kernel. The maximum is 16
interfaces. For each interface, you can customize an interface name, data width, and the number
of associated arguments. Each interface contains all read and write channels. The default names
proposed by the RTL kernel wizard are m00_axi
and m01_axi
. If not changed, these names will have to be used when
assigning a DDR bank through the --sp
option.
AXI Master Definition (Table Columns)
- Interface name
- Specifies the name of the interface. To ensure maximum compatibility, the argument name follows the same identifier rules as the kernel name.
- Width (in bytes)
- Specifies the data width of the AXI data channels. Xilinx recommends matching to the native data width of the memory controller AXI4 slave interface. The memory controller slave interface is typically 64 bytes (512 bits) wide.
- Number of arguments
- Specifies the number of arguments to associate with this interface. Each argument represents a data pointer to global memory that the kernel can access.
Argument Definition
- Interface
- Specifies the name of the AXI Interface that the corresponding columns in the current row are associated with. This value is not directly modifiable; it is copied from the interface name defined in the previous table.
- Argument name
- Specifies the name of the pointer argument as it appears on the function prototype signature. Each argument is assigned an ID value. This ID value is used to access the argument from the host software. The ID value assignments can be found on the summary page of this wizard. To ensure maximum compatibility, the argument name follows the same identifier rules as the kernel name. The argument name is used in the generated Verilog control register module as an output signal.
Streaming Interfaces
The streaming interfaces page allows configuration of AXI4-Stream interfaces on the kernel. Streaming interfaces can be used for bus connections between kernels or to/from the host (on certain QDMA-based platforms only). For kernel-to-kernel communication, the AXI4-Stream signal set and protocol should match between kernels. Streaming interfaces used for direct host-to-kernel and kernel-to-host communication must follow a strict protocol and signal declaration. The QDMA AXI4-Stream protocol uses the TDATA/TKEEP/TLAST signals of the AXI4-Stream protocol. Stream transactions consists of a series of transfers where the final transfer is terminated with the assertion of the TLAST signal. The following figure shows the configuration options. Stream transfers to/from the host must adhere to the following:
- AXI4-Stream transfer occurs when TVALID/TREADY are both asserted.
- TDATA must be 8, 16, 32, 64, 128, 256, or 512 bits wide.
- TKEEP (per byte) must be all 1s when TLAST is 0.
- TKEEP can be used to signal a
ragged tail when TLAST is 1. For example, on a
4-byte interface, TKEEP can only be
0b0001
,0b0011
,0b0111
, or0b1111
to specify the last transfer is 1-byte, 2 bytes, 3 bytes, or 4 bytes in size, respectively. - TKEEP cannot be all zeros (even if TLAST is 1).
- TLAST must be asserted at the end of a packet.
- TREADY input/TVALID output should be low if kernel is not started to avoid lost transfers.
- Number of AXI4-Stream interfaces
- Specifies the number of AXI4-Stream interfaces that exist on the kernel. A maximum of 32 interfaces can be enabled per kernel. Xilinx recommends keeping the number of interfaces as low as possible to reduce the amount of area consumed.
Stream Settings
- Name
- Specifies the name of the interface. To ensure maximum compatibility, the argument name follows the same identifier rules as the kernel name.
- Mode
- Specifies the direction of the interface. A read only interface
is an AXI4-Stream slave interface and can be
sent data with the
clWriteStream
API. A write only interface is an AXI4-Stream master interface and the host can receive data from the interface with theclReadStream
API.
- Width (bytes)
- Specifies the TDATA width (in bytes) of the AXI4-Stream interface. This interface width is limited to 1 to 64 bytes in powers of 2.
Summary
This section summarizes VLNV, the software function prototype, and hardware control registers created from options selected in the previous pages. The function prototype conveys what a kernel call would be like if it was a C function. See the host code generated example of how to set the kernel arguments for the kernel call. The register map shows the relationship between the host software ID, argument name, hardware register offset, type, and associated interface. Review this section for correctness before proceeding to generate the kernel.
Finalizing and Generating the Kernel from the RTL Wizard
If the RTL Kernel Wizard was launched from SDx, after clicking OK, the example Vivado project opens.
If the RTL Kernel Wizard was launched from Vivado, after clicking OK do the following:
- When the Generate Output Products window appears, select Global synthesis options and click Generate, then click OK.
- Right-click the .xci file in the Design Sources View in Vivado, and select Open IP Example Design.
- In the open example design window, select an output directory (or accept default) and click OK. This opens a new Vivado project with the example design in it.
- You can now close the current Vivado project from which the RTL Kernel Wizard was invoked.
Interrupt
By default, the RTL Kernel Wizard creates a single interrupt port, named interrupt
, along with the interrupt logic in the Control
Register block. This is reflected in the generated Verilog code and the associated
component.xml and kernel.xml files.
The interrupt is active-High and is enabled by setting both the Global Interrupt Enable (GIE) and Interrupt Enable (IER) registers. By default, the IER uses the internal ap_done and ap_ready signals to trigger an interrupt.
An interrupt is cleared when all the defined bits of the ISR register are zero as triggered by a toggle on write command..
RTL Kernel Wizard Vivado Project
The RTL Kernel Wizard configuration dialog box customizes the specification of an RTL kernel by specifying its I/O, control registers, and AXI4 interfaces. The next step in the process customizes the contents of the kernel and then packages those contents into a Xilinx Object (xo) file. After the RTL Kernel Wizard configuration GUI has completed, a Vivado kernel project is generated and populated with the files necessary to create an RTL Kernel.
The top-level Verilog file contains the expected input/output signals and parameters. These top-level ports are matched to the kernel specification file (kernel.xml) and when combined with the rest of the RTL/block design becomes the acceleration kernel. The AXI4 interfaces defined at the top-level file contain a minimum subset of AXI4 signals required to generate an efficient, high throughput interface. Signals omitted inherit optimized defaults when connected to the rest of the AXI system. These optimized defaults allow the system to omit AXI features that are not required, saving area and reducing complexity. If starting with existing code that contains AXI signals not listed in the port list, it is possible to add these signals to the top-level ports and the IP packager will adapt to them appropriately.
Depending on the selected Kernel Type, the contents of the top-level file is populated either with a Verilog example and control registers or an instantiated IP integrator block design.
RTL Kernel Type Project Flow
The RTL kernel type delivers a top-level Verilog design consisting of control register and Vadd sub-modules example design. The Vadd sub-module, shown in the following figure, consists of a simple adder function, an AXI4 read master, two AXI4-Stream interfaces, and an AXI4 write master. Each defined AXI4 interface has an independent example adder code. The first associated argument of each interface is used as the data pointer for the example. Each example reads 16 KB of data, performs a 32-bit add one operation, and then writes out 16 KB of data back in place (the read and write address are the same). Care should be taken if the Control Register module is modified to ensure that it still aligns with the kernel.xml file located in the imports directory of the Vivado kernel project. The example sub-module can be replaced with your custom logic or used as a starting point for your design.
The Vadd sub-module, shown in the following figure, consists of a simple adder function, an AXI4 read master, and an AXI4 write master. Each defined AXI4add one operation, and then writes out 16 KB of data back in place (the read and write address are the same). interface has independent example adder code. The first associated argument of each interface is used as the data pointer for the example. Each example reads 16 KB of data, performs a 32-bit
The following table describes important files relative to the root of the
Vivado project for the kernel, where <kernel_name>
is the name of the kernel chosen in
the wizard.
Filename | Description | Delivered with Kernel Type |
---|---|---|
interface has independent example add<kernel_name>_ex.xpr | Vivado project file | All |
imports directory | ||
<kernel_name>.v | Kernel top-level module | All |
<kernel_name>_control_s_axi.v | RTL control register module | RTL |
<kernel_name>_example.sv | RTL example block | RTL |
<kernel_name>_example_vadd.sv | RTL example AXI4 vector add block | RTL |
<kernel_name>_example_axi_read_master.sv | RTL example AXI4 read master | RTL |
<kernel_name>_example_axi_write_master.sv | RTL example AXI4 write master | RTL |
<kernel_name>_example_adder.sv | RTL example AXI4-Stream adder block | RTL |
<kernel_name>_example_counter.sv | RTL example counter | RTL |
<kernel_name>_exdes_tb_basic.sv | Simulation test bench | All |
<kernel_name>_cmodel.cpp | Software C-Model example for software emulation. | All |
<kernel_name>_ooc.xdc | Out-of-context Xilinx constraints file | All |
<kernel_name>_user.xdc | Xilinx constraints file for kernel user constraints. | All |
kernel.xml | Kernel description file | All |
package_kernel.tcl | Kernel packaging script proc definitions | All |
post_synth_impl.tcl | Tcl post-implementation file | All |
sdx_imports directory | ||
src/host_example.cpp | Host code example | All |
makefile | Makefile example | All |
<kernel_name>_ex.sdk/<kernel_name>_control/src directory | ||
kernel_control.h | MicroBlaze C header file | Block Design |
kernel_control.c | MicroBlaze C file | Block Design |
<kernel_name>_ex.sdk/<kernel_name>_control/Debug directory | ||
<kernel_name>_control.elf | MicroBlaze elf file | Block Design |
<kernel_name>_ex.src/sources_1/<kernel_name>_bd directory | ||
<kernel_name>_bd.bd | Vivado Block Diagram file | Block Design |
Block Design Kernel Type Project Flow
The block design kernel type delivers an IP integrator block design (BD) as the basis of the kernel. A MicroBlaze processor subsystem is used to sample the control registers and to control the flow of the kernel. The MicroBlaze processor system uses a block RAM as an exchange memory between the Host and the Kernel instead of a register file.
- If the design has been updated, you might need to run the Export Hardware option. The option can be found in the OK. menu location. When the export Hardware dialog opens, click
- The software development kit (SDK) application can now be invoked. Select Vivado menu. from the
- When the Xilinx SDK GUI opens, click X just to the right of the text on the Welcome tab to close the welcome dialog box. This shows an already loaded SDK project underneath.
- From the Project Explorer, the source files are under the <Kernel Name>_control/src section. Modify these as appropriate.
- When updates are complete, compile the source by selecting the menu option . The ELF file is automatically updated in the GUI.
- Run simulation to test the updated program and debug if necessary.
Simulation Test Bench
When a SystemVerilog simulation test bench is generated, this exercises the kernel to ensure its operation is correct. It is populated with the checker function to verify the add one operation. This generated test bench can be used as a starting point in verifying the kernel functionality. It writes/reads from the control registers and executes the kernel multiple times while also including a simple reset test. It is also useful for debugging AXI issues, reset issues, bugs during multiple iterations, and kernel functionality. Compared to hardware emulation, it executes a more rigorous test of the hardware corner cases, but does not test the interaction between host code and kernel.
To run a simulation, click Run Behavioral Simulation. If behavioral simulation is working as expected, a post-synthesis functional simulation can be run to ensure that synthesis is matched with the behavioral model.
located on the left hand side of the GUI and selectOut-of-Context Synthesis
The Vivado kernel project is configured to run synthesis and implementation in out-of-context (OOC) mode. A Xilinx Design Constraints (XDC) file is populated in the design to provide default clock frequencies for this purpose. Running synthesis is useful to determine whether the kernel synthesizes without errors. It also provides estimates of usage and frequency. The kernel should be able to run through synthesis successfully before it is packaged.
Otherwise, errors occur during linking and it could be harder to debug. The synthesized outputs can be used when packaging the kernel as a netlist instead of RTL. If a block design is used within the kernel, the kernel must be packaged as a netlist. To run OOC synthesis, click Run Synthesis from the menu.
Software Model and Host Code Example
A C++ software model of the example add one operation is provided in the imports directory. It has the same name as the kernel and has a cpp file extension. This software model can be modified to model the function of the kernel. In the packaging step, this model can be included with the kernel. When using SDx, this allows software emulation to be performed with the kernel. The Hardware Emulation and the System Linker always uses the hardware description of the kernel.
In the sdx_imports directory, example C
host code is provided and is called main.c
. The host
code expects the binary container as the argument to the program. This can be
automatically specified by selecting Automatically add binary
container(s) to arguments in after the host code is loaded into the SDx GUI. The host code then loads the binary as part of the init
function. The host code instantiates the kernel,
allocates the buffers, sets the kernel arguments, executes the kernel, and then collects
and checks the results for the example add one function.
Package RTL Kernel
After the kernel is designed and tested in Vivado, the final step for generating the RTL kernel is to package the Vivado kernel project for use with SDx.
- A source-only kernel packages the kernel using the RTL design sources directly.
- The pre-synthesized kernel packages the kernel with the RTL design sources with a synthesized cached output that can be used later on in the flow to avoid re-synthesizing. If the target platform changes, the packaged kernel might fall back to the RTL design sources instead of using the cached output.
- The netlist, design checkpoint (DCP), based kernel packages the kernel as a block box, using the netlist generated by the synthesized output of the kernel. This output can be optionally encrypted if necessary. If the target platform changes, the kernel might not be able to re-target the new device and it must be regenerated from the source. If the design contains a block design, the netlist (DCP) based kernel is the only packaging option available.
Optionally, all kernel packaging types can be packaged with the software model that can be used in software emulation. If the software model contains multiple files, provide a space in between each file in the Source files list, or use the GUI to select multiple files using the CTRL key when selecting the file.
After you click OK, the kernel output products are generated. If the pre-synthesized kernel or netlist kernel option is chosen, then synthesis can run. If synthesis has previously run, it uses those outputs, regardless if they are stale. The kernel Xilinx Object .xo file is generated in the sdx_imports directory of the Vivado kernel project.
At this point, you can close the Vivado
kernel project. If the Vivado kernel project was
invoked from the SDx GUI, the example host code
called main.c
and kernel Xilinx Object (.xo) files are
automatically imported into the SDx source
folder.
Modifying an Existing RTL Kernel Generated from the Wizard
From the SDx GUI, it is possible to modify an existing generated kernel. By invoking the Xilinx RTL Kernel Wizard menu option after a kernel has been generated, a dialog box opens that gives you the option to modify an existing kernel. Selecting Edit Existing Kernel Contents re-opens the Vivado Project, and you can then modify and generate the kernel contents again. Selecting Re-customize Existing Kernel Interfaces revisits the RTL Kernel Wizard configuration dialog box. Options other than Kernel Name can be modified and the previous Vivado project is replaced.
Manual Development Flow for RTL Kernels
Using the RTL Kernel Wizard to create RTL kernels is highly recommended; however RTL kernels can be created without using the wizard. This section provides details on each step of the manual development flow. The three steps to package an RTL design as an RTL kernel for SDAccel applications are:
- Package the RTL block as Vivado IP.
- Create a kernel description XML file.
- Package the RTL kernel into a Xilinx Object (.xo) file.
These steps are an automated use of the RTL Kernel Wizard. A fully packaged RTL Kernel is delivered as an .xo file with a file extension of .xo. This file is a container encapsulating the Vivado IP object (including source files) and associated kernel XML file. The .xo file can be compiled into the platform and run in hardware or hardware emulation flows.
Packaging an RTL Block as Vivado IP
RTL kernels must be packaged as a Vivado IP suitable for use in the IP integrator. See the Vivado Design Suite User Guide: Creating and Packaging Custom IP (UG1118) for details on IP packaging in Vivado.
The following interface packaging is required for the RTL Kernel:
- The AXI4-Lite interface name must
be packaged as
S_AXI_CONTROL
, but the underlying AXI ports can be named differently. - The AXI4 interfaces must be
packaged as AXI4 master endpoints with 64-bit address support.Note: Xilinx strongly recommends that AXI4 interfaces be packaged with AXI meta data
HAS_BURST=0
andSUPPORTS_NARROW_BURST=0
. These properties can be set in an IP level bd.tcl file. This indicates wrap and fixed burst type is not used and narrow (sub-size burst) is not used. ap_clk
andap_clk_2
must be packaged as clock interfaces.ap_rst_n
andap_rst_n_2
must be packaged as active-Low reset interfaces.ap_clk
must be packaged to be associated with all AXI4-Lite, AXI4, and AXI4-Stream interfaces.
To test if the RTL kernel is packaged correctly for the IP integrator, try to instantiate the packaged kernel in
the IP integrator. In the GUI, it should show up as
having interfaces for clock, reset, AXI4-Lite slave,
AXI4 master, and AXI4 slave only. No other ports should be present in the canvas view. The
properties of the AXI interface can be viewed by selecting the interface on the canvas.
Then in the Block Interface Properties window,
select the Properties tab and expand the CONFIG
table
entry. If an interface is to be read-only or write-only, the unused AXI channels can be
removed and the READ_WRITE_MODE
is set to read-only or
write-only.
There are two methods to mark constraints as late processing order:
- If the constraints are given in a .ttcl file, add
<: setFileProcessingOrder "late" :>
to the .ttcl preamble section of the file as shown below:<: set ComponentName [getComponentNameString] :> <: setOutputDirectory "./" :> <: setFileName $ComponentName :> <: setFileExtension ".xdc" :> <: setFileProcessingOrder "late" :>
- If the constraints are given in a .xdc file, then add the four lines starting at
<spirit:define>
below in the component.xml. The four lines in the component.xml need to be next to the area where the .xdc file is called. In the following example, my_ip_constraint.xdc file is being called with the subsequent late processing order defined.<spirit:file> <spirit:name>ttcl/my_ip_constraint.xdc</spirit:name> <spirit:userFileType>ttcl</spirit:userFileType> <spirit:userFileType>USED_IN_implementation</spirit:userFileType> <spirit:userFileType>USED_IN_synthesis</spirit:userFileType> <spirit:define> <spirit:name>processing_order</spirit:name> <spirit:value>late</spirit:value> </spirit:define> </spirit:file>
Create Kernel Description XML File
A kernel description XML file needs to be created for each RTL kernel such that it can be used in the SDAccel environment. The file must be called kernel.xml. The XML file specifies kernel attributes like the register map and ports which are needed by the runtime and SDAccel flows. The following is an example of a kernel.xml file.
<?xml version="1.0" encoding="UTF-8"?>
<root versionMajor="1" versionMinor="6">
<kernel name="sdx_kernel_wizard_0" language="ip_c" vlnv="mycompany.com:kernel:sdx_kernel_wizard_0:1.0" attributes="" preferredWorkGroupSizeMultiple="0" workGroupSize="1" interrupt="true">
<ports>
<port name="s_axi_control" mode="slave" range="0x1000" dataWidth="32" portType="addressable" base="0x0"/>
<port name="m00_axi" mode="master" range="0xFFFFFFFFFFFFFFFF" dataWidth="512" portType="addressable" base="0x0"/>
</ports>
<args>
<arg name="axi00_ptr0" addressQualifier="1" id="0" port="m00_axi" size="0x8" offset="0x010" type="int*" hostOffset="0x0" hostSize="0x8"/>
</args>
</kernel>
</root>
The following table describes the format of the kernel XML in detail:
Tag | Attribute | Description |
---|---|---|
<root> | versionMajor | Set to 1 for the current release of SDAccel. |
versionMinor | Set to 6 for the current release of SDAccel. | |
<kernel> | name | Kernel name |
language | Always set it to ip_c for RTL
kernels. |
|
vlnv | Must match the vendor, library, name, and version attributes in the
component.xml of an IP. For example, If component.xml has
the following tags:
The vlnv attribute in kernel XML must be set to:
|
|
attributes | Reserved. Set it to empty string. | |
preferredWorkGroupSizeMultiple | Reserved. Set it to 0. | |
workGroupSize | Reserved. Set it to 1. | |
interrupt | Set equal to "true" (that is,. interrupt="true") if interrupt present else omit. | |
<port> | name | Port name. At least an AXI4 master
port and an AXI4-Lite slave port are required. The
AXI4-Stream port can be optionally specified to stream
data between kernels. The AXI4-Lite interface name must
be S_AXI_CONTROL . |
mode |
|
|
range | The range of the address space for the port. | |
dataWidth | The width of the data that goes through the port, default is 32 bits. | |
portType | Indicate whether or not the port is addressable or streaming.
|
|
base | For AXI4 master and slave ports, set to
0x0 . This tag is not applicable to AXI4-Stream
ports. |
|
<arg> | name | Kernel argument name. |
addressQualifier | Valid values:
|
|
id | Only applicable for AXI4 master and slave ports.
The ID needs to be sequential. It is used to determine the order of kernel arguments. Not applicable for AXI4-Stream ports. |
|
port | Indicates the port to which the arg is
connected. |
|
size | Size of the argument. The default is 4 bytes. | |
offset | Indicates the register memory address. | |
type | The C data type for the argument. For example, int*,
float* . |
|
hostOffset | Reserved. Set to 0x0 . |
|
hostSize | Size of the argument. The default is 4 bytes. | |
memSize | Not applicable to AXI4 master and slave ports. For AXI4-Stream ports, |
|
The following tags specify additional information for AXI4-Stream ports. They are not applicable to AXI4 master or slave ports. | ||
<pipe> | For each pipe in the compute unit, the compiler inserts a FIFO for buffering the data. The pipe tag describes configuration of the FIFO. | |
name | This specifies the name for the FIFO inserted for the AXI4-Stream port. This name must be unique among all pipes used in the same compute unit. | |
width | This specifies the width of FIFO in bytes. For example,
0x4 for 32-bit FIFO. |
|
depth | This specifies the depth of the FIFO in number of words. | |
linkage | Always set to internal. | |
<connection> | The connection tag describes the actual connection in hardware either from the kernel to the FIFO inserted for the PIPE or from the FIFO to the kernel. | |
srcInst | Specifies the source instance of the connection. | |
srcPort | Specifies the port on the source instance for the connection. | |
dstInst | Specifies the destination instance of the connection. | |
dstPort | Specifies the port on the destination instance of the connection. |
Package RTL Kernel into Xilinx Object File
The final step is to package the RTL IP and the associated kernel XML file
together into a Xilinx object file (.xo) so it can be used by the SDAccel compiler. The following example command line packages test_sincos
RTL IP and kernel.xml
into object file named test.xo.
package_xo -xo_path test.xo -kernel_name test_sincos -kernel_xml
kernel.xml -ip_directory ./ip/
For additional information on the package_xo
, see the "package_xo
Command" section in SDx
Command and Utility Reference Guide (UG1279). Also, for examples on
using the package_xo
command, see the Xilinx
GitHub repository.
Designing RTL Recommendations
While the RTL Kernel Wizard assists in packaging RTL designs for use within the SDx flow, the underlying RTL kernels should be designed with recommendations from the UltraFast Design Methodology Guide for the Vivado Design Suite (UG949).
These topics are described in the following subsections.
Memory Performance Optimizations for AXI4 Interface
The AXI4 interfaces typically connects to DDR memory controllers in the platform.
For best performance from the memory controller, the following is the recommended AXI interface behavior:
- Use an AXI data width that matches the native memory controller AXI data width, typically 512 bits.
- Do not use
WRAP
,FIXED
, or sub-sized bursts. - Use burst transfer as large as possible (up to 4k byte AXI4 protocol limit).
- Avoid use of deasserted write strobes. Deasserted write strobes can cause error-correction code (ECC) logic in the DDR memory controller to perform read-modify-write operations.
- Use pipelined AXI transactions.
- Avoid using threads if an AXI interface is only connected to one DDR controller.
- Avoid generating write address commands if the kernel does not have the ability to deliver the full write transaction (non-blocking write requests).
- Avoid generating read address commands if the kernel does not have the capacity to accept all the read data without back pressure (non-blocking read requests).
- If a read-only or write-only interfaces are desired, the ports of the unused channels can be commented out in the top level RTL file before the project is packaged into a kernel.
- Using multiple threads can cause larger resource requirements in the infrastructure IP between the kernel and the memory controllers.
Managing Clocks in an RTL Kernel
An RTL kernel can have up to two external clock interfaces; a primary clock,
ap_clk
, and an optional secondary clock, ap_clk_2
. Both clocks can be used for clocking internal logic.
However, all external RTL kernel interfaces must be clocked on the primary clock. Both primary
and secondary clocks support independent automatic frequency scaling.
If you require additional clocks within the RTL kernel, a frequency synthesizer such as the Clocking Wizard IP or MMCM/PLL primitive can be instantiated within the RTL kernel.
Thus your RTL kernel can use just the primary clock, both primary and secondary clock, or primary and secondary clock along with an internal frequency synthesizer. The following shows the advantages and disadvantages of using these three RTL kernel clocking methods:
- Single input clock:
ap_clk
- External interfaces and internal kernel logic run at the same frequency.
- No clock domain crossing (CDC) issues.
- Frequency of
ap_clk
can automatically be scaled to allow kernel to meet timing.
- Two input clocks:
ap_clk
andap_clk_2
- Kernel logic can run at either clock frequency.
- Need proper CDC technique to move from one frequency to another.
- Both
ap_clk
andap_clk_2
can automatically scale their frequencies independently to allow the kernel to meet timing.
- Using a frequency synthesizer inside the kernel:
- Additional device resources required to generate clocks.
- Must have
ap_clk
and optionallyap_clk_2
interfaces. - Generated clocks can have different frequencies for different CUs.
- Kernel logic can run at any available clock frequency.
- Need proper CDC technique to move from one frequency to another.
When using a frequency synthesizer in the RTL kernel there are some constraints you should be aware of:
- RTL external interfaces are clocked at
ap_clk
. - The frequency synthesizer can have multiple output clocks that are used as internal clocks to the RTL kernel.
- You must provide a Tcl script to downgrade the clock resource placement DRCs
in Vivado placement to stop a Vivado DRC error from occurring. An example of the Tcl command
follows:
set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets pfm_top_i/static_region/base_clocking/clkwiz_kernel/inst/CLK_CORE_DRP_I/clk_inst/clk_out1
Note: This constraint should be edited to reflect the shell clock structure of your platform. - Use the
xocc --xp
option to specify the above Tcl script for use by Vivado implementation, after optimization. For example:--xp vivado_prop:run.impl_1.STEPS.OPT_DESIGN.TCL.POST={<PATH>/<TCL Script>}
- Specify the two global clock input frequencies which can be used by the
kernels (RTL or HLS-based). Use the
xocc --kernel_frequency
option to ensure the kernel input clock frequency is as expected. For example to specify one clock use:
For two clocks, you can specify multiple frequencies based on the clock ID. The primary clock has clock ID 0 and the secondary has clock ID 1.xocc --kernel_frequency 250
xocc --kernel_frequency 0:250|1:500
TIP: Ensure that the PLL or MMCM output clock is locked before RTL kernel operations. Use the locked signal in the RTL kernel to ensure the clock is operating correctly.
xocc
will return an error like the following:
ERROR: [VPL-1] design did not meet timing - Design did not meet timing. One
or more unscalable system clocks did not meet their required target
frequency. Please try specifying a clock frequency lower than 300 MHz using
the '--kernel_frequency' switch for the next compilation. For all system
clocks, this design is using 0 nanoseconds as the threshold worst negative
slack (WNS) value. List of system clocks with timing failure.
In this case you will need to change the internal clock frequency, or optimize the kernel logic to meet timing.
Quality of Results Considerations
The following recommendations help improve results for timing and area:
- Pipeline all reset inputs and internally distribute resets avoiding high fanout nets.
- Reset only essential control logic flip-flops (FFs).
- Consider registering input and output signals to the extent possible.
- Understand the size of the kernel relative to the capacity of the target platforms to ensure fit, especially if multiple kernels will be instantiated.
- Recognize platforms that use Stack Silicon Interconnect (SSI) Technology. These devices have multiple die and any logic that must cross between them should be FF to FF timing paths.
Debug and Verification Considerations
- RTL kernels should be verified in their own test bench using advanced verification techniques including verification components, randomization, and protocol checkers. The AXI Verification IP (VIP) is available in the Vivado IP catalog and can help with the verification of AXI interfaces. The RTL kernel example designs contain an AXI VIP-based test bench with sample stimulus files.
- The hardware emulation flow should not be used for functional verification because it does not accurately represent the range of possible protocol signaling conditions that real AXI traffic in hardware can incur. Hardware emulation should be used to test the host code software integration or to view the interaction between multiple kernels.