PYNQ: PYTHON PRODUCTIVITY

Zynq on the EBAZ4205

Support
#1

I have set up Pynq with help of this documentation: Yet another EBAZ4205 writeup<br/>#3: PYNQ!

Pynq boots up and I get network communication. I was going through the steps of the Overlay Tutorial. After loading the overlay, the network communication is lost.

The ENET0 is connected via EMIO. So it has to be routed through the PL. The clock for the Ethernet phy is generated by the PS and routed to a PL pin.

As far as I understand the overlays, the overlay will replace the FPGA configuration, which is loaded at system bootup. So I extended the base design and added the “Add” IP block:

grafik
grafik1635Ă—843 84.4 KB

After loading the overlay, the ethernet stops working. This might be due to interruption of the phy clock and the connection between ENET0 and the phy.

Questions:

  • Am I right, that all needed FPGA block need to be reimplemented in the overlay? Or is there a possibility to partially reconfigure the FPGA. So the connection and clock to the ethernet phy is not interrupted?
  • Is there a possibility to reinitialize the ethernet phy in linux during runtime (as a fall back solution)?
#2

Yes, reloading a new Overlay with disrupt the Ethernet. You can replace the default bitstream that loads at boot time with your design.
Yes, partial reconfiguration could be an option to keep the Ethernet alive which re-configuring other parts of the system, but this is a more complicated flow.
I’m not sure about reinitializing the Ethernet. Someone more knowledgeable on the Linux kernel may be able to give you a better answer.
If you have a design, you could try restart the interface.
PYNQ uses the Ethernet interface to communicate with the board. You could use a UART terminal to try restart the Ethernet, and then use PYNQ.

Cathal

1 Like
#3

I made some experiments:

I loaded the “adder.bit” overlay. After that the ethernet was down. Then I loaded the “base.bit” overlay and the ethernet went up again. So I could prove that the ethernet will reconnect, once the clock and EMIO connection is available.

So the problem could be limited to the “adder.bit” file. Questions has been answered. The ethernet can still work (with little interruption), when loading a full bitstream.

I was measuring the frequency for the “adder.bit” of the generated phy clock. Due to rounding issues in the Vivado IP cores a wrong phy clock was generated. The phy clock was a bit off:

  • Input clock of the Zynq is 33,333333Mhz
  • The PLL in the PS does generate a 50MHz clock, but Vivado thinks, it is 49,5MHz. Maybe there are rounding issues in the IPs.
  • The MMCM clock wizard takes the 49,5MHz and does some clock synthesis to 25MHz. The MMCM can generate granular subdivisions of clocks and tries to generate exact 25MHz from 49,5Mhz. The real input clock is 50Mhz. So the generated output clock is higher than 25MHz.

Reconfiguring the clocks solved the problem.

Thank you for your support.

2 Likes
#4

Thanks for posting back the outcome, and great to hear it works for you! :slight_smile:

Cathal

1 Like