Hi Folks - I’ve been using PYNQ as a quick way to test newly developed communications IP blocks. The notebook workflow has been great for productivity! I’m to the point of having to integrate ADC/DAC/radio into the design, and have been looking at options for bringing Analog Devices hdl + drivers into PYNQ.
One possible way is to just take the ADI hdl into the existing test bench, but them I’m faced with having to figure out the ADI no-OS software stacks, eg for the AD936x.
Another way is to use some/all of the ADI iio ecosystem, but here I have the unknowns of whether the ADI linux drivers from Kuiper Linux will plug right into Xilinx kernels.
At some point, I’m kind of wishing I had a zcu208/zcu111 just so I don’t have to solve for this integration, but this seems like a useful skill to have in the toolbox.
So with the preamble out of the way, what have others done to integrate ADI transceivers, ADC/DAC into Pynq based workflow? I’m down the path of no-OS right now, but figured I would ask peers what they’ve done before I allocate the time to solve no-OS. My skill development platform at this moment is an AD9364 fmcomms4 + zcu104 w/Pynq. I’ve already ported the ADI fmcomm2 hdl to the zcu104.
Thanks – Rick Spanbauer
2 Likes
@rspanbauer
I had tried such idea.
However the folks how create the ADI drivers do modified the xlnx kernel.
So if you need such support you really need merge two kernel together and gvimdiff all those files.
I will suggest not to do in such way and simply install via compile or direct bin in PYNQ kernel.
Also the released revision between ADI and PYNQ is wonderfully douched the same Vivado and Vitis version. AKA no common kernel could be shared.
The HDL itself as you already know is that the DMA is a old custom build on 2019 if not wrongly remember. Such that this is why they changed the driver a bit.
Either AD9361 or whatever FMCOMMS variant you used, PYNQ itself is treaded as a form of HDL overlay handler.
So lets consider this way if a overlay already consume over 80% of 7020 then what’s the point of the need of PYNQ and Kuiper itself also support Python-based GNURadio.
When comes to larger FPGA it is reasonable to do so.
But as mentioned from the beginning, the kernel itself is real major headache, unless you really good at Linux kernel it is bloody harsh and life killing.
Wish you all the luck and ENJOY~
2 Likes
Exactly - you hit on all the pain points of concern, i.e. custom kernels, divergent versions of Vivado, Petalinux vs ADI kernel, and so on.
To this, I add just one more complication - I’m not looking to stream through libiio + ADI hdl. Likely that’s just a waypoint to verify the radio itself (fmcomms4 installed in a zcu104 7u7
board). I used Pynq’s composable pipeline to actually test the sdr blocks, which turned
out to be very convenient, i.e. test each block in turn, then pipeline then together, continue
testing, and so on.
Microphase has an integration of PYNQ with their 7z020/AD936x board - I seem to recall that
is an iio approach to integration with Python.
For now, I’ll probably stay the course with the ADI hdl, and use the no-OS driver to manage
the AD9364. I see that PYNQ has device tree support, so hopefully that means I can just run
the stock PYNQ kernel, and add any 9364 dts as needed, versus just going at it directly
using mmio. Really, end of the day, I’m looking for IQ samples out of the 9364, with the rest
of the sdr IP accessible to Python to facilitate design & testing.
2 Likes
@rspanbauer
Indeed, no-OS is just couples of C++ code and could run with minimum restrictions between Vivado.
So simply said you are borrowing PYNQ as a overlay loader (replace the need of JTAG).
Other than that not really huge different on conventional FPGA development flow/
Which should takes minimum of effort to make things work.
Great~
Enjoy~
