snap
snap copied to clipboard
Work in progress: Block Design Action
This is an attempt to create an action that consists of a top-level block design. Internally, it uses a copy of the hls_nvme_memcopy action, which is simply wrapped by a Vivado block design.
So ideally, the block design should be usable in the same way as the HLS action (e.g. with regards to the action_wrapper
), however, this doesn't seem to be so easy.
In theory, all configuration parameters that would usually be passed to the HLS component through VHDL generics, should be set on the HLS IP block as customizations.
For example this doesn't work for setting the address widths of the individual AXI master ports of the HLS component, because it's only possible to choose 64 or 32 bits globally.
Somehow related is my current problem: In SNAP, the ID width for the card mem AXI master is 4 -- it's possible to customize the HLS component accordingly (create_bd.tcl, row 18), but I am still getting errors when trying to build a simulation model:
ERROR: [VRFC 10-664] expression has 1 elements ; expected 4 [~/snap/actions/bd_helloworld/ip/ipshared/7152/hdl/vhdl/hls_action.vhd:845]
ERROR: [VRFC 10-664] expression has 1 elements ; expected 4 [~/snap/actions/bd_helloworld/ip/ipshared/7152/hdl/vhdl/hls_action.vhd:858]
ERROR: [VRFC 10-664] expression has 1 elements ; expected 4 [~/snap/actions/bd_helloworld/ip/ipshared/7152/hdl/vhdl/hls_action.vhd:865]
ERROR: [VRFC 10-664] expression has 1 elements ; expected 4 [~/snap/actions/bd_helloworld/ip/ipshared/7152/hdl/vhdl/hls_action.vhd:878]
ERROR: [VRFC 10-664] expression has 1 elements ; expected 4 [~/snap/actions/bd_helloworld/ip/ipshared/7152/hdl/vhdl/hls_action.vhd:885]
This can be reproduced by choosing the BD HelloWorld action in snap_config.
I've been able to work around this issue -- it's probably related to Xilinx SR# 10394170, if I interpret the comments in the HLS action_wrapper correctly.
The setup seems to work fine so far; I've included a mechanism to optionally support DRAM and NVME ports to be generated and connected: HLS will only generate the corresponding ports if the DRAM_ENABLED
and NVME_ENABLED
names are defined. This is automatically done by picking up the values from the SNAP environment settings.
There are still a few rough edges, and the HLS action code is now duplicated in the repository. Maybe there's a more suitable use case for this demo (e.g. a memcopy implemented by using AXI MM2S and S2MM data moving IP blocks)
@rs22 Hi Robert, Just finding this very old pull request that was put aside for some times. Is this still something you want to pursue? We may need to resync it and solve files conflict in this case. Let me know
I still think it would be good to show how a Vivado Block Design-based action can be built with SNAP.
With Metal FS we still have the problem that the cloud build mode does not work because reconfigurable partitions cannot (directly) contain a Block Design. Packaging the Block Design as an IP block might be a workaround for this issue.
I will try to find some time to update this PR in the next weeks, so that we can see whether this works.