My understanding is that an overlay is an FPGA reconfiguration. In that case why should one load a base overlay that loads the intended overlay, as it seems to be the ‘standard’ workflow?
The base overlay is like a reference design or an example. It gives you something to try “out-of-the-box”. It can be used for some projects.
If you don’t want to use it, you can load your own overlay.
I asked this but from a different point of view:
What’s the point of a base overlay which just connects peripherals to the PS? If I wanted to drive peripherals from Linux I could use a Raspberry Pi etc. Surely the Pynq base overlay should show how to take advantage of the PL - the whole point of developing with an FPGA. For example, I expected to see some DSP running in the PL, after taking the audio from the peripheral, controlled by Python, before the results were sent to the PS, not all of the signal processing done in Python.
So - why doesn’t the base system show us example PL solutions interfaced to Python? Even if you expect most end users to just use overlays rather than write them, if you want an ecosystem, you need to get some people on board to write the overlays - and to show them how to do it with tutorial base PL solutions for audio processing, video processing, neural networks, and so on.
I understand why you are asking this, but this wasn’t the intention of the base design.
The base design is intended to do basic demonstration of peripherals in the system. It allows you to try PYNQ out-of-the-box. It is also intended to be used as a starting point for a new design, or to allow you to reuse some of the IP for your own design if useful. It only uses about ~50% of the PL resources. This was intentional, rather than cram it full of extra features.
There is some info about ‘base’ in the introduction here if you haven’t seen it:
The base design as is can still do things that RPi etc. can’t do.
Each Overlay is a few MB. It was intended that you would be able to install new examples easily. E.g. pip install
We also didn’t want to include lots of examples in the PYNQ image, or maintain lots of example for every board. The same design may or may not work well across multiple boards.
There are other examples showing PL use:
But I still feel that the base design is NOT a good starting point for our own (FPGA-based) designs, as it does not give us any clue how to use the PL within them. Taking audio and video, for example, it just sends them through to Python. It does not show us how to get our hands on the audio or video data from within the PL. Yet surely that is why we would be wanting to use an FPGA in the first place.
Also, those other examples are mostly academic research projects, not tutorial material. They are thus not, in general, (i) documented so as to teach, if documented at all, and (ii) intended to show people how to do basic things, to get them up to speed.
I do feel there is a gap here.
Thanks for the feedback. I understand your point.
I guess there was a different intention behind the base overlay to what you want.
Some introductory tutorial material here, but this still may not be what you would like.
We are trying to build out more material. We have been adding some blogs recently highlighting certain aspects of PYNQ. We are open to suggestions for blogs/tutorials.
One thing we are trying to do in these forums and in out material is to focus on things specific to PYNQ and not Zynq/FPGA in general. The Xilinx forums and other resources are available. Obviously there isn’t a hard boundary between these two areas, but we try to direct FPGA questions not related to PYNQ to the Xilinx forums.
Your question about what to do with audio/video data once you get it into the PL may be more appropriate on other forums, but feel free to ask questions here and we can try to help with PYNQ questions and perhaps guide you to better resources related to this elsewhere.
Thanks again Cathal. I did indeed find very useful the 2 tutorials on creating hardware, and using the hardware from Pynq, and that’s how I got started on my own desogn. One or two more advanced ones accesing, from the PL, more advanced hardware than leds and switches would be very welcome. The bit I am getting stuck with (as per my other thread) is: integrating a design which works OK by itself, with Pynq - and is where a tutorial would be very handy. I fully agree you don’t need to replicate stuff just targeting FPGAs or Zynq.
As for my own design - I have a clear plan of what to do with the audio data on the PL side. What is stymieing me at present is a design which works OK if loaded directly as a bitstream, doesn’t, if loaded with Pynq. Clearly there’s some (probably simple) thing I’m overlooking, and having a good working example to follow, or to show what the “secret” is, would be very handy.
Anyway, thanks for listening, and if this persuades you (collectively) to add some such material, it would be gratefully received.