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 is to customize the contents of the kernel and then package 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 will 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 Kernel Type selected, the contents of the top-level file is populated either with an Verilog example and control registers, or an instantiated IP integrator block design.

RTL Kernel Type Project Flow

The RTL kernel type delivers a control register module and an example portion. Care should be taken if the control register module is modified to ensure it still aligns with the kernel.xml file located in the imports directory of the Vivado kernel project. The example portion may be discarded or used as a starting port for custom logic. The example consists of a simple adder function, and an AXI4 read master and an AXI4 write master. Each defined AXI4 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 16KB of data, performs a 32 bit “add one” operation, and then writes out 16KB of data back in place (writes to same starting pointer as the read address.)

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. For each AXI interface, a DMA and math operation sub-blocks are created to provide an example of how to control the kernel execution. The example uses the MicroBlaze AXI4-Stream interfaces to control the AXI DataMover IP to create an example identical to the one in the RTL kernel type. Also, included is an SDK project to compile and link an ELF file for the MicroBlaze core. This ELF file is loaded into the Vivado® kernel project and initialized directly into the MicroBlaze Instruction memory. The following steps can be used to modify the MicroBlaze processor program:
  1. If the design has been updated, you may need to run the Export Hardware option. The option can be found in the File->Export->Export Hardware menu location. When the export Hardware dialog appears, click OK.
  2. The SDK application can now be invoked. Select the File->Launch SDK option from the Vivado menu.
  3. When the Xilinx SDK GUI appears, 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.
  4. From the project explorer, the source files can be found under the <Kernel Name>_control/src section. Modify these as appropriate.
  5. When updates are complete, compile the source by selected the menu option Project->Build All Check for errors/warnings and resolve if necessary.
  6. The ELF file is automatically updated in the GUI.
  7. Run simulation to test the updated program and debug if necessary.

Simulation Testbench

A SystemVerilog simulation test bench is generated, this will exercise the kernel to ensure its operation is correct. It is populated with the checker function to verify the “add one” operation. This generated testbench can be used as a starting point in verifying the kernel functionality. It will write/read from the control registers and execute 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 the Vivado Flow Navigator->Run Simulationoption located on the left hand side of the GUI and selected the Run Behavioral Simulation option. 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.

Out of Context Synthesis

The Vivado kernel project is configured to run synthesis and implementation in Out Of Context (OOC) mode. An XDC file is populated in the design to provide default clock frequencies for this purpose. Running synthesis is useful to determine whether the kernel will synthesize without errors. It will also provide estimates of utilization 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, then the kernel must be packaged as netlist. To run out of context synthesis, click the Run Synthesis option from the Vivado Flow Navigator->Synthesis 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 will have 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 use 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 will expect the binary container as the argument to the program. This can be automatically specified by checking the Automatically add binary container(s) to arguments checkbox in the Run Configuration->Arguments option 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 will instantiate the kernel, allocate the buffers, set the kernel arguments, execute the kernel, then collect and check the results for the example “add one” function.

Generate 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.

To begin the process, click the Generate RTL Kernel option from the Vivado Flow Navigator->Project Manager menu. A pop-up dialog box opens with three main packaging options:
  • 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 (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 retarget the new device and it must be regenerated from the source. If the design contains a block design, then 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, then 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 the OK button, 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 will use those outputs, regardless if they are stale. The kernel 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, then the example host code called main.c and kernel 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 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. Choosing the Edit Existing Kernel Contents option re-opens the Vivado Project, and you can then modify and generate the kernel contents again. Choosing the Re-customize Existing Kernel Interfaces option will re-visit the RTL Kernel Wizard configuration dialog box. Options other than Kernel Name can be modified and the previous Vivado Project is replaced.

Note: Important: all files and changes in the previous project will be lost when the updated Vivado kernel project is generated.