pynq.Overlay() always uses cached .hwh information

[dspsandbox]

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!

[STFleming]

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

[dspsandbox]

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.

• overlay_0.zip
• overlay_1.zip

BR,
Pau

[mariodruiz]

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?

[dspsandbox]

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...

[juanma-rm]

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

[keithpenney]

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.

[NBoumakis]

I had a similar problem after I renamed the .bit and .hwh files. After a quick glance, it seems to me like it caches the path to the bitstream file, but when the file/filename changes it doesn't invalidate the cache. Right now I don't have enough free time to check it out, but I could have a look during the weekend and maybe do a PR?