Affect on memory space when switching overlays


I’ve been reading through the docs again trying to wrap my head around how to customize builds using hte Pynq-Z1 board. I’m a little confused as to the affect on the Zynq and OS when switching overlays on the fly or in a build. Once the image is built and the board boots the system (os / zynq) memory space is setup based on the image and up and running. A few bullets highlighting my confusion are below.

  1. What happens when you load different overlays relative to the Zynq memory space. I ask because all of the objects (block, ip) in the PL are memory mapped. This means changing the overlay could drastically change the memory space correct? Doesn’t that cause problems for software running in linux on the zynq because the address of PL objects change and that trickles through to linux by way of physical address through the MMU to virtual addresses?

  2. If you created a custom board and removed all the microblazes (pmods, arduino, hdmi video etc…) does the make process still compile all of then when building? For example if you delete all the PMOD stuff does the build still access and use the microblaze stuff or does it recognize the PMOD microblaze code (c code for uBlaze and drivers etc…) aren’t necessary?

  1. Yes, the memory map can change, but PL peripherals are mapped to user space, so you can allocate and delete memory mapped objects as required.
  2. No, the IP you mention are only used in specific designs. E.g. base, logicstools, etc. As an example, the build flow for the PYNQ-Z1 will build the base and logictools overlays for that board. If you have a custom board and build a different “base” overlay, or remove it, it won’t be built.


Sorry, but the typo “logicstools” brings a giggle . . .

@jessej - ROFL

Ok that was the missing piece - I didn’t realize the PL was mapped to user space.

So what tells the build process whether to build the microblaze stuff? Is it based on the block design TCL file that gets parsed which describes the overlay and what is in the overlay?

Also, do you guys think it would be possible to comment the make file more so I can better understand what the main sdbuild make file is doing? I’ve been trying to get a handle on the process, but the make file (main sd build one in particular) is pretty tough to read. Just a thought I know you guys are busy so not criticizing. For example, if each line had a comment describing the purpose that would be awesome!

I’m not sure exactly what you mean by MicroBlaze “stuff”. There are MicroBlaze processors that can be used in a design, MIcroBlaze cross compiler that gets included in the image, and MicroBlaze driver code and libraries that gets included in the image.
Yes, individual overlays may have MicroBlaze processors in them. (E.g. “base”)
These would get built from the Tcl for that design.
The MicroBlaze cross compiler will be included in the image. This will get built as part of the image build process.
MicroBlaze code and libs will also be built during build process.

We’ll look into better docs/comments for build flow. Thanks for feedback.


Hi Cathal,

Thanks for the response! I apologize for such a vague post. I meant microblaze drivers/libs etc…

I was curious if I did for example a barebones zynq build for the pynq with no uBlazes in the design at all does it still build the supporting microblaze drivers/lib files and include them in the image.

It sounds like the cross compiler, the microblaze code (c code), libs and .bin files will always be built and added to the image regardless of whether your overlay uses them or not correct?

Yes, the compiler/libs will be included in the image. The reasoning is that (1) this is not a large overhead, (2) we are not building the PYNQ image for each bitstream, (3) you shouldn’t need to rebuild the PYNQ image just to use a hardware design with PYNQ.

Even if your current bitstream doesn’t need something in the image, perhaps a future one will.


1 Like