I’m working on a partially reconfigured design using DFX and BDC with the PYNQ-Z2 development kit (PYNQ 3.0.1 Image). As it stands, the design is not working properly for partial bitstreams downloads that use a static logic that was built in a different configuration.
I’ve seen that there is a report of this behavior in the Xilinx Forums:
Upon research in the Xilinx forums, this behavior seems to affect only 7-Series and ZYNQ-7000 SoC devices. It was also reported by a user that the DPR Design works fine on Vivado 2020.2 for a Zynq SoC.
I would like to continue using the PYNQ Framework in order to validate my DPR Design… This way, i intend to downgrade to Vivado 2020.2 to avoid further issues.
My Doubts:
Can i keep using the PYNQ 3.0.1 Image with Vivado 2020.2 bitstreams or should i also migrate to the 2.7 Image Version for compatibility?
Is this a known issue in DFX for Vivado 2022.1 [I’ve seen a few posts on Xilinx forums regarding this problem]?
I would also appreciate input from other users using DFX + PYNQ with Vivado 2022.1 …
We always recommend to use the Vivado version associated to the PYNQ image. However, you can try with a different version of Vivado. When calling the Overlay object you can specify to ignore_version=True.
I haven’t tried this big jump in version, so you may need to try.
However, PYNQ 2.7 does not support BDC. I would recommend instead that you try Vivado 2022.2 and PYNQ 3.0.1.
Good moment to also ask about there is a between version of PYNQ 3.0.0.
So 3.0.0 is a kind of intermediate development version?
I only commonly see user use 2.7 and 3.0.1 and 3.0.0 looks becoming a dead revision to use.
BTW, could highly a bit the major different of 3.0.1 and 3.0.0?
If correctly read both 3.0.x is using Vivado 2022.1.
I’ve tested some Overlays generated in Vivado 2020.2 using HLS IPs (AXI-Stream and AXI-Full) and some of my own RTL IPs (AXI-Stream and AXI-Lite) with PYNQ 3.0.1 Image. Everything seems to be working just fine until now. DMA in Simple Register Mode and AXI Interruption Controller are also working.
As of now, the implementation of my DPR Design with DFX is a work in progress. I’m using the UG947 as a reference for this implementation. Vivado 2020.2 doesn’t support DFX+BDC as the BDC feature is early-access for this particular version.
I would recommend instead that you try Vivado 2022.2 and PYNQ 3.0.1.
Have you tested a DPR design with a ZYNQ-7000 SoC (PYNQ-Z2) with DFX+BDC using Vivado 2022.2? Is it currently working?
Thank you for pointing out, I just used 3.0.1 and 2.7 never even have notice 3.0.0 is in between HAHA =], but 3.0.1 during some testing startup is a bit touchy and slow so I keep using 2.7 until 3.1 or above is release (hope more stable and more bug is fixed).
but 3.0.1 during some testing startup is a bit touchy and slow
Yes, i’ve noticed that and it’s a bit annoying but still more productive to use PYNQ than writing standalone applications and debugging using Vitis in my opinion.
Hey, i’ve seen and studied you tutorial before reading UG947. Thank you for this amazing tutorial!
I do saw someone in this forum working around BDC on DFX designs
What this post had mentioned is BDC could introduce longer regenerate time which abstract method is a better.
However, myself applications and task never involve real room for DFX unless only study and try around behavior. When using FPGA, most cases are testing / R&D purpose, which FPGA is far optimal for large volume product design. =[ over-cost (something like S6+A53 CPU overrun the cost many times)
I do saw someone in this forum working around BDC on DFX designs
Thanks, i will have a look at the post & replies later…
I didn’t mention before but my DPR Design using DFX in PYNQ-Z2 is intended for my graduate research project using a single reconfigurable partition with 3+ reconfigurable modules. The implementation works fine and pr_verify doesn’t report any errors but i was unable to download partial bitstreams from another configuration either using Overlay or the Vivado hardware manager.
Thanks for your input! I will post a follow up later with my results.
I can make sure my tutorial is working fine and all tested under 2.7.
The TCL command is tedious but necessary.
The Python script also need to pay attention Overlay(xxx, xxx, xxx).
I do ask in other post that is there any chance the engine will mix-up the target PR load location (answer should be NO and I think also make sense as it is marked as the PR location ID).
As a follow up… I managed to recreate and validate the previously mentioned DPR design in Vivado 2022.2 without issues. The partial bitstream generation is correct and the design work as expected using PYNQ 3.0.1 Image.
Vivado 2022.1 Partial Bitstream File Information:
Xilinx BIT data - from BD_wrapper;UserID=0XFFFFFFFF;PARTIAL=TRUE;Version=2022.1 - for 7z020clg400 - built 2023/06/13(12:10:12) - data length 0xb8
Vivado 2022.2 Partial Bitstream File Information:
Xilinx BIT data - from BD_wrapper;UserID=0XFFFFFFFF;PARTIAL=TRUE;Version=2022.2 - for 7z020clg400 - built 2023/06/12(15:58:00) - data length 0x167b9c
This is not a PYNQ issue and it is mostly related to DPR designs with ZYNQ-7000 on Vivado 2022.1.
I also make a follow up tutorial on the PR of PYNQ 2.7:
There is a TCL script to auto run the project and both add/sub PR block accordingly.
The only issue in old PYNQ before 3.0.1 is that BDC is not support so block PR cannot easily be done on general compile flow. But diamond zip RTL flow is all good until latest Vivado. Which means if developers are old-school RTL guy and just use off-block connect via RTL there are no issue. Where it is tedious to connect net manually (AXI stuff, but Python script automation can easily do the job right, or CHISEL Scala) =]
