Although AMD Vitis is widely used for targeting High-Level Language support, Vivado remains the mainstream FPGA development tool in the industry.
In the Vivado GUI, you can add multiple Verilog files and constraints files to construct a complete design as shown below.
To simplify FPGA development, Vivado offers versatile out-of-the-box IPs. Users can create a .bd file and utilize the GUI to add IP icons, enabling the straightforward and convenient creation of design schematics. Additionally, Verilog files can be also be added into the schematic as a module icon. Vivado automatically infers interfaces and suggests various connection options for users. This development process is known as the IP-Integration (IPI) project flow shown below.
At this moment, Rapidstream mainly accepts text-based input sources as shown below.
Design modules can be represented by .v, .tcl, or .xci (Xilinx Compile IP) files. Interface information can be described within the Verilog code as outlined in getting_started/mixed_sources. Alternatively, if your modules are compiled using vitis_hls, you can provide .rpt or .xml files.
from rapidstream import RapidStreamHLS, get_u50_default_device
# We create a RapidStream Pro project called "build":
rs = RapidStreamHLS(f"{CURR_DIR}/build")
# Use the predefined U50 virtual device:
rs.set_virtual_device(get_u50_default_device())
# Add all the source files
rs.add_vlog_files(list_of_vlog_file_paths)
rs.add_hls_tcl_ip_file(list_of_ip_tcl_paths)
rs.add_xci_files(list_of_tcl_file_paths)
rs.add_hls_report_dirs(list_of_hls_rpt_paths)The input sources for RapidStream are similar to those used in a text-based Vivado project. Consequently, RapidStream can naturally support text-based Vivado projects. Users only need to add all the source files to the RapidStreamHLS class variable.
The source files for an IPI Vivado project differ inherently from those of a text-based Vivado project, necessitating their transformation into a RapidStream-compatible format. However, versatile IPs are vendor-specific, making this transformation challenging. Additionally, there is no need for RapidStream to optimize these IPs, as they have already been highly optimized by the vendors. Therefore, we divide the complete IPI project into two independent IPI projects: the shell IPI project and the Custom Logic (CL) IPI project, as shown below.
The shell IPI project encompasses only the essential components for data communication across the FPGA fabric, CPU host, and High-Bandwidth Memory (HBM). The custom logic includes an empty Verilog instance that creates 32 256-bit AXI3 master buses, which connect to all the HBM AXI buses. Additionally, it includes an AXI4 slave bus and an AXI-Lite bus. Three independent clocks drive the XDMA clock domain logic, the kernel clock domain logic, and the HBM clock domain logic.
The custom logic (CL) instantiates all the user kernels generated by HLS or manual design. The AXI-full slave bus passes through an asynchronous crossbar to access the HBM AXI buses, enabling access to the entire 8GB high-bandwidth memory. The remaining 31 AXI3 buses of the HBM can be utilized by the AXI master buses from all the kernels as needed. The AXI-Lite slave bus also passes through a crossbar to drive the control AXI-Lite buses of all the kernels, facilitating control operations such as configuring address offsets, starting, and stopping the kernels.
The shell ipi project will be compiled to a shell.dcp file which act as an input source. The cl ipi project will be processed by IPI Project Converter we provide to transform the CL ipi project into a bunch of Verilog files, XCI and report files which can be taken by rapidstream as inputs. Ripidstream will optimize the design described by cl ipi project and generate the post-route dcp as output.
The shell IPI project will be compiled into a shell.dcp file, which serves as an input source. The CL IPI project will be processed by the IPI Project Converter we provide, transforming the CL IPI project into a collection of Verilog files, XCI files, and report files, which can be used by RapidStream as inputs. RapidStream will then optimize the design described in the CL IPI project and generate the post-route DCP as the output.
In summary, we recommend moving vendor-related designs that do not require optimization to the shell IPI project, while placing the target logic to be optimized into the CL IPI project. This way, the CL IPI project can be transformed and optimized by RapidStream.
These tutorials target various FPGA devices. The table below lists the tutorials available, and the features and flows showcased in all of these tutorials.
</tbody>
| Design | Developer | Platforms | Sources | Purpose |
| CNN13x2 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x4 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x6 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x8 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x10 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x12 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x14 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |
| CNN13x16 | AutoBridge | U50 | Vitis HLS | An HLS accelerator for the convolutional neural network kernel. |