Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pynq.Overlay() always uses cached .hwh information #1409

Open
dspsandbox opened this issue Nov 25, 2022 · 7 comments
Open

pynq.Overlay() always uses cached .hwh information #1409

dspsandbox opened this issue Nov 25, 2022 · 7 comments
Assignees
Labels

Comments

@dspsandbox
Copy link

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 STFleming self-assigned this Nov 25, 2022
@STFleming
Copy link
Collaborator

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
Copy link
Author

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

@mariodruiz
Copy link
Collaborator

mariodruiz commented Nov 25, 2022

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
Copy link
Author

dspsandbox commented Nov 25, 2022

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
Copy link

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

@STFleming STFleming added the bug label May 1, 2024
@keithpenney
Copy link

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants