PYNQ: PYTHON PRODUCTIVITY FOR ZYNQ

PYNQ Reconfiguration Mechanism?

Hi there,

As the subject suggests, I’m looking for any and all texts describing the FPGA Reconfiguration Mechanism that is implemented by/for PYNQ.

Some background:

  • I’m completely new to PYNQ, with little experience in firmware design.
  • I do have high(er)-level understandings of HDL and how Vivado stitches the various components together.
  • Adding to that, some forms of understanding of Soft-core Processors implemented on FPGAs, e.g. MicroBlaze.

Aside from gaining clarity on the Reconfiguration Mechanism itself, I mainly want to figure out whether Partial Reconfiguration is implemented in some way for this process. Any feedback would be greatly appreciated; please and thank you!

Amish

Could you be more specific? You can use partial reconfiguration with PYNQ.

PYNQ uses FPGA manager for (partial) reconfiguration
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841645/Solution+Zynq+PL+Programming+With+FPGA+Manager

There is an example of partial reconfiguration with PYNQ here

Cathal

Hi Cathal,

Thank you very much for your reply! After reading a bit more (which I should’ve done first), I would like to clarify how Overlay.download('my_file.bit') is implemented, i.e. the programming of the FPGA PL once the Overlay is instantiated.

Thanks again!

Amish

Hi Amish,
You question is quite broad. Can you be more specific?
Maybe if you explain what you are trying to do it would help me understand what you need to know.

Cathal

Hi Cathal,
I seek more detail about the what that method triggers in the firmware. That is, from executing Overlay.download('my_file.bit') in the Jupyter Notebook session:

  • How does the PL react to this function-call?
  • Does the bitstream get packatised and funnelled through the ICAP?
  • Or is it written to an external/off-chip storage device and triggers the FPGA to boot from this storage?
  • Or indeed something altogether different?

I assume the bit-file to be programmed must exist on/be copied to the board before instantiating the Overlay?

Hopefully I’ve refined my question; thank you very much for your replies thus far.

Amish

The bitstream is on the local file system on the SD card. You can copy new bitstreams, or install designs to your board (e.g. pip install).
If only considering the PL, Overlay.download() takes the bitstream, and writes it to the ICAP.

The overlay class does more than this. The HWH or Tcl file corresponding to the bitstream is parsed to capture meta data about the design. This includes information about system including memory map, IP in the design, register maps for IP. For example, the ip_dict is created at this point. Clock information about the new design is determined at this point too, an the PS clocks will be updated before writing the new PL design.

Cathal