An RTL module must use a single input Avalon® streaming interface. That is, a single pair of ready and valid logic must control all the inputs. You have the option to provide the necessary Avalon® streaming interface ports but declare the RTL module as stall-free. In this case, you do not have to implement proper stall behavior because the
creates a wrapper for your module. Refer to
Object Manifest File Syntax of an RTL Module
for additional information.
You must handle
signals properly if your RTL module has an internal state. Refer to
for more information.
The RTL module must work correctly regardless of the kernel clock frequency.
RTL modules cannot connect to external I/O signals. All input and output signals must come from a SYCL kernel.
An RTL module must have a
port, and Avalon® streaming interface input and output ports (that is,
). Name the ports as specified here.
RTL modules that communicate with external memory must have Avalon® memory-mapped interface port parameters that match the corresponding Custom Platform parameters. The
does not perform any width or burst adaptation.
RTL modules that communicate with external memory must behave as follows:
They cannot burst across the burst boundary.
They cannot make requests every clock cycle and stall the hardware by monopolizing the arbitration logic. An RTL module must pause its requests regularly to allow other load or store units to execute their operations.
RTL modules cannot act as stand-alone SYCL kernels. RTL modules can only be helper functions and be integrated into a SYCL kernel during kernel compilation.
Every function call that corresponds to RTL module instantiation is completely independent of other instantiations. There is no hardware sharing.
Do not incorporate kernel code into a SYCL library file. Incorporating kernel code into the library file causes the offline compiler to issue an error message. You may incorporate helper functions into the library file.
An RTL component must receive all its inputs at the same time. A single
input signifies that all inputs contain valid data.
You can only set RTL module parameters in the
<RTL module description file name>.xml
specification file and not in the SYCL kernel source file. To use the same RTL module with multiple parameters, create a separate
tag for each parameter combination.
You can only pass data inputs to an RTL module by value via the SYCL kernel code. Do not pass data inputs to an RTL module via pass-by reference, structs, or channels. In the case of channel data, pass the extracted scalar data.
Passing data inputs to an RTL module via pass-by reference or structs causes a fatal error to occur in the offline compiler.
The debugger (for example, GDB for Linux) cannot step into a library function during emulation if the library is built without the debug information. However, irrespective of whether the library is built with or without the debug data, optimization and area reports are not mapped to the individual code line numbers inside a library.
Names of RTL module source files cannot conflict with the file names of
IP. Both the RTL module source files and the compiler IP files are stored in the
<kernel file name>/system/synthesis/submodules
directory. Naming conflicts causes existing compiler IP files in the directory to be overwritten by the RTL module source files.
The compiler does not support
files. You must manually parse nested
files to create a flat list of RTL files.
It is very difficult to debug an RTL module that works correctly on its own but works incorrectly as part of a SYCL kernel. Double check all parameters under the
<RTL object manifest file name>.xml
All compiler area estimation tools assume that RTL module area is 0. The compiler does not currently support the capability of specifying an area model for RTL modules.