You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've started working again with FOS and a PYNQ Z2 board, but I haven't managed to successfuly make my own accelerators communicate with the CPU via Ponq so far.
The tools I used are: Vivado 2018.2 +SDK, Current version of FOS + Pynq v2.3 (v2.3 being the version used in your compilation guide, proof here, line 325)
As I mentionned in Issue #7, I first had some trouble working with the library and the PCAP manager. Eventually thanks to khoapham I've been able to seemingly make it work as I was able to write to the PCAP port via CLI, and use PONQ's acc.load(accel_name) function to load it. I wasn't able to properly check my IP however, as FOS is based on PYNQ v2.3 and there seem to be an odd behaviour with DMA compared with v2.6 which I'm more used to.
Since I'm more experienced with VHDL than HLS, I wrote my own AXI IP to instanciate with the PS which has been verified with PYNQ v2.6 Overlay library. The IP has a slave and master AXIS interface and is connected to the PS via DMA, since as introduced in your Vivado tutorial you are using Ultrascale boards which has both a Slave and Master HP AXI ports, whereas the non-Ultrascale only has a Slave HP AXI port, and Master GP AXI ports. Is this an issue?
I then used the DMA IP to communicate with my IP, the registers as described within SDK (hardware description file) to write my accelerator are the following, written in my accelerator json file:
This has caused me lots of trouble figuring how to properly initiate communication with the accelerator without making the jupyter notebook not responding, and as I was basically starting to writing a whole DMA driver in python I figured I was doing things wrong, since your examples are much more straight forward.
I then backtracked and started over. Below is my workflow for a static design using a Vivado AXIS Fifo IP, connected to the Slave HP port with an AXI-S to Memory Mapped adaptator. I carefully mapped everything on 32 bits bus width as the readme mention this might be an issue. My workflow is based on the tutorial about creating hls ips and usage of static design.
I generated the bin file manually within the SDK by running bootgen -image output.bif -arch zynq -process_bitstream bin, after having created the output.bif file as the tutorial.
Finally, after having reset the board, I uploaded the bit file, bin file, and the following json files to configure the shell and accelerator:
Register map is that of the axi memory map to stream. According to the Vivado Address Editor, I should expect output data in the DDR memory space.
At this point I was able to load the bin files:
But once I try to write in the registers, the kernel dies and restarts:
acc.writeReg("data", 0x00010001) # Data to storeacc.writeReg("control", 0xFFFFFFFF) # WSTRB = FF, TLAST need to be set to 1, other bytes can be left as 1
I'm sure there is something that I'm missing here, or maybe non-ultrascale boards aren't compatible as all your tests seem to be conducted on ultrascale boards. Could you please tell me what am I doing wrong?
Kind regards,
Alexis
The text was updated successfully, but these errors were encountered:
Hello,
I've started working again with FOS and a PYNQ Z2 board, but I haven't managed to successfuly make my own accelerators communicate with the CPU via Ponq so far.
The tools I used are: Vivado 2018.2 +SDK, Current version of FOS + Pynq v2.3 (v2.3 being the version used in your compilation guide, proof here, line 325)
As I mentionned in Issue #7, I first had some trouble working with the library and the PCAP manager. Eventually thanks to khoapham I've been able to seemingly make it work as I was able to write to the PCAP port via CLI, and use PONQ's
acc.load(accel_name)
function to load it. I wasn't able to properly check my IP however, as FOS is based on PYNQ v2.3 and there seem to be an odd behaviour with DMA compared with v2.6 which I'm more used to.Since I'm more experienced with VHDL than HLS, I wrote my own AXI IP to instanciate with the PS which has been verified with PYNQ v2.6 Overlay library. The IP has a slave and master AXIS interface and is connected to the PS via DMA, since as introduced in your Vivado tutorial you are using Ultrascale boards which has both a Slave and Master HP AXI ports, whereas the non-Ultrascale only has a Slave HP AXI port, and Master GP AXI ports. Is this an issue?
I then used the DMA IP to communicate with my IP, the registers as described within SDK (hardware description file) to write my accelerator are the following, written in my accelerator json file:
This has caused me lots of trouble figuring how to properly initiate communication with the accelerator without making the jupyter notebook not responding, and as I was basically starting to writing a whole DMA driver in python I figured I was doing things wrong, since your examples are much more straight forward.
I then backtracked and started over. Below is my workflow for a static design using a Vivado AXIS Fifo IP, connected to the Slave HP port with an AXI-S to Memory Mapped adaptator. I carefully mapped everything on 32 bits bus width as the readme mention this might be an issue. My workflow is based on the tutorial about creating hls ips and usage of static design.
I generated the bin file manually within the SDK by running
bootgen -image output.bif -arch zynq -process_bitstream bin
, after having created the output.bif file as the tutorial.Finally, after having reset the board, I uploaded the bit file, bin file, and the following json files to configure the shell and accelerator:
repo.json
PYNQ_Z2.json
design_1_wrapper.json
Register map is that of the axi memory map to stream. According to the Vivado Address Editor, I should expect output data in the DDR memory space.
At this point I was able to load the bin files:
But once I try to write in the registers, the kernel dies and restarts:
I'm sure there is something that I'm missing here, or maybe non-ultrascale boards aren't compatible as all your tests seem to be conducted on ultrascale boards. Could you please tell me what am I doing wrong?
Kind regards,
Alexis
The text was updated successfully, but these errors were encountered: