Giters

Xilinx / PYNQ

Python Productivity for ZYNQ

Home Page:http://www.pynq.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

pynq.Overlay() always uses cached .hwh information

dspsandbox opened this issue · comments

commented

After migrating to PYNQ 3.0.0, I faced problems when updating existing overlays. Basically, the changes in the .hwh file do not propagate to pynq.Overlay(), which always uses the cached .hwh information.

To reproduce this error:

  1. Create a simple FPGA design & generate overlay
  2. Upload overlay to FPGA
  3. Load overlay within Jupyter Notebook via ol = pyqn.Overlay("bitstream.bit")
  4. Inspect ol.ip_dict
  5. Update the FPGA design (change instance names, addressing...) & generate overlay
  6. Idem to 2
  7. Idem to 3
  8. idem to 4. The displayed information has not changed!
commented

Hi @dspsandbox,

Would you be able to share the .hwh and .bit files you were using for this test? It would be very helpful for recreating the issue.

In the mean time you can call the following between step 5 and 6 to clear and cached data:

from pynq import PL
PL.reset()

Thanks,
Shane

commented

Hi Shane,
thanks you so much for the quick reply, your solutions works :)

Here are the two versions of the same overlay I was using. They include a screenshot of the design, where you can see that the only difference is the instance name of an axi gpio.

BR,
Pau

commented

Hi @dspsandbox,

I am interested in understanding under what circumstances would the hwh change but not the bitstream?
Or are you saying that the bitstream and hwh did change?

commented

Hi @mariodruiz,
I am always updating/changing the whole overlay (i.e .hwh and .bit together). The problem is that, after migrating to PYNQ 3.0.0, any update in the design is not visible within the Jupyter notebook. In other words, pynq.Overlay( ) always returns the IP handles within the first version of my overlay. My assumption was that this is a .hwh cache problem...

commented

Hi. I came here by googling the same behaviour that @dspsandbox reported. This weekend I encountered some weird situations that basically consisted in 1) generating hwh/bit from my Vivado design, 2) loading the corresponding overlay from pynq, 3) then changing some bits in my Vivado design (e.g. changing one axi_dma parameter, or replacing the axi_dma by a axi_vdma) and generating new hwh/bit, 4) loading the new overlay and 5) finding out that the "new overlay" behaved as the old one (e.g. complains of axi_dma transfer length too long, though I had increased the value or not detecting any vdma but a dma when I had just replaced the dma by the vdma). I just realised that restarting and reloading the overlay seems to solve the issue. I will try out doing "PL.reset()" (as rebooting each time I need to load a new overlay takes its time).

Regards

commented

I get the same behavior using PYNQ release 3.0.1 on ZCU208. For several weeks I mistook the bug for an issue with the HWH parser not recognizing some custom IP, but then I made a change to an overlay to delete some existing IP and it still showed up in Overlay.ip_dict despite not being present at all in the HWH file. A power cycle fixed it. I'll try the PL.reset() workaround ASAP, but it'd be nice to squash this bug at its root.