RTL Kernels

To satisfy theSDAccelexecution model, an RTL kernel must adhere to the following interface requirements:

• One and only oneAXI4-Liteinterface is used to access control signals and pass arguments.
• At least one of the following interfaces (can have both):
  • AXI4master interface to communicate with memory.
  • AXI4-Streaminterface to communicate between the kernels and/or with the host.
    Note:With the ap_ctrl_nonekernel control interface option, AXI4master interfaces cannot be used.
• At least one clock interface port.

The various interface requirements are summarized in the following table.

RTL kernels can optionally have an interrupt port containing a single interrupt. The port name must be calledinterruptand 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 aninterruptport to the kernel, thekernel.xmlfile needs be updated with this information. Thekernel.xmlis generated automatically when using the RTL Kernel Wizard. For details on updating the file, seeCreate Kernel Description XML File.

The wizard is organized into pages that break down the process of creating a kernel into smaller steps. To navigate between pages, clickNextand selectBack. To finalize the kernel and build a project based on the inputs of the wizard, clickOK. Each of the following sections describes each page and its input options.

The RTL Kernel Wizard configuration dialog box customizes the specification of an RTL kernel by specifying its I/O, control registers, andAXI4interfaces. The next step in the process customizes the contents of the kernel and then packages those contents into aXilinxObject (xo) file. After the RTL Kernel Wizard configuration GUI has completed, aVivadokernel 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. TheAXI4interfaces defined at the top-level file contain a minimum subset ofAXI4signals 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 selectedKernel Type, the contents of the top-level file is populated either with a Verilog example and control registers or an instantiatedIP integratorblock design.

RTL kernels must be packaged as aVivadoIP suitable for use in theIP integrator. See theVivado Design Suite User Guide: Creating and Packaging Custom IP(UG1118)for details on IP packaging inVivado.

The following interface packaging is required for the RTL Kernel:

• TheAXI4-Liteinterface name must be packaged asS_AXI_CONTROL, but the underlying AXI ports can be named differently.
• TheAXI4interfaces must be packaged as AXI4 master endpoints with 64-bit address support.
  Note: Xilinxstrongly recommends that AXI4interfaces be packaged with AXI meta data HAS_BURST=0and SUPPORTS_NARROW_BURST=0. These properties can be set in an IP level bd.tclfile. This indicates wrap and fixed burst type is not used and narrow (sub-size burst) is not used.
• ap_clkandap_clk_2must be packaged as clock interfaces.
• ap_rst_nandap_rst_n_2must be packaged as active-Low reset interfaces.
• ap_clkmust be packaged to be associated with allAXI4-Lite,AXI4, andAXI4-Streaminterfaces.

To test if the RTL kernel is packaged correctly for theIP integrator, try to instantiate the packaged kernel in theIP integrator. In the GUI, it should show up as having interfaces for clock, reset,AXI4-Liteslave,AXI4master, andAXI4slave 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 theBlock Interface Propertieswindow, select the Properties tab and expand theCONFIGtable entry. If an interface is to be read-only or write-only, the unused AXI channels can be removed and theREAD_WRITE_MODEis set to read-only or write-only.

A kernel description XML file needs to be created for each RTL kernel such that it can be used in theSDAccelenvironment. The file must be calledkernel.xml. The XML file specifies kernel attributes like the register map and ports which are needed by the runtime andSDAccelflows. The following is an example of akernel.xmlfile.

The following table describes the format of the kernel XML in detail:

The final step is to package the RTL IP and the associated kernel XML file together into aXilinxobject file (.xo) so it can be used by theSDAccelcompiler. The following example command line packagestest_sincosRTL IP andkernel.xmlinto object file namedtest.xo.

package_xo -xo_path test.xo -kernel_name test_sincos -kernel_xml kernel.xml -ip_directory ./ip/

For additional information on thepackage_xo, see the "package_xo Command" section inSDx Command and Utility Reference Guide(UG1279). Also, for examples on using thepackage_xocommand, see theXilinxGitHubrepository.

TheAXI4interfaces 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 useWRAP,FIXED, or sub-sized bursts.
• Use burst transfer as large as possible (up to 4k byteAXI4protocol 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.

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 ofap_clkcan automatically be scaled to allow kernel to meet timing.
• Two input clocks:ap_clkandap_clk_2
  • Kernel logic can run at either clock frequency.
  • Need proper CDC technique to move from one frequency to another.
  • Bothap_clkandap_clk_2can 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 haveap_clkand optionallyap_clk_2interfaces.
  • 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:

1. RTL external interfaces are clocked atap_clk.
2. The frequency synthesizer can have multiple output clocks that are used as internal clocks to the RTL kernel.
3. You must provide a Tcl script to downgrade the clock resource placement DRCs inVivadoplacement to stop aVivadoDRC 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.
4. Use thexocc --xpoption to specify the above Tcl script for use byVivadoimplementation, after optimization. For example:

   --xp vivado_prop:run.impl_1.STEPS.OPT_DESIGN.TCL.POST={/}

5. Specify the two global clock input frequencies which can be used by the kernels (RTL or HLS-based). Use thexocc --kernel_frequencyoption to ensure the kernel input clock frequency is as expected. For example to specify one clock use:

   xocc --kernel_frequency 250

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

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.

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.

• 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 theVivadoIP 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.