Using Pynq with your Zynq

I recently attended a one-day tutorial about Pynq by Xilinx. While it was on planet Earth I was not familiar with some of these names that sounded alien to me. But I was decided to get some update about the new FPGA offerings by Xilinx company.

I am glad I did as I discovered a wide range of technologies I know nothing about that I reckon can be pretty useful. Unfortunately, becoming an expert on any of them will most likely require many hours of training.

But I can share with you some of what I learned: Pynq is an open-source project by Xilinx to make it easier to use the programmable logic included in some of their SoCs. And that brings us to the second name I have never heard about: Zynq-7000 is a system-on-a-chip (SoC) by Xilinx that bundles an ARM microcontroller with a large FPGA.  In a nutshell, Pynq is a small Linux distribution that runs on a Zynq SoC with access to all the power of the embedded FPGA.

But I guess the question here is what this can be useful for. Right now there are many different single board computers, many based around some flavor of the ARM processor, many of the can run Linux. Raspberry Pi family is probably the most well-known member of that collection. 

FPGAs are not new either and they have become more and more powerful over the years, allowing users to implement from complex logic to complete high-performance hardware pipelines for various number-crunching purposes.  But its development has always been limited to a somehow reduced following.

What was news for me (though these products have been in the market for years) is the idea of pairing a processor running a Linux system with an FPGA and proper drivers so you can handle its configuration and usage from a Python script. And you can do that knowing literally nothing about the tools to create the programmable logic you are about to use.  (Not that such type of knowledge would set you in a bad position though).

One of the ideas that surprised me was that some of the examples would use some additional processors synthesized in the programmable logic to act as I/O coprocessors of the main processor. So that brought me to think that most likely many control systems can be implemented in a similar way. For instance, I am going to explore the use of a Zynq SoC as the controller of a 3D printer, where each motor would be controlled by a soft processor, making possible to choose the type of motor to use for each axis whether a stepper, dc motor or FOC brushless motor and having yet another soft processors to handle the temperature control loops and all coordinated from the main processor that has better access to network and filesystem functions. Whether to use the Klipper or Marlin approach is yet something to be decided. Wish me luck.

As part of the training, we have got a Pynq-Z2 board that, contrary to Arduino IntelGalileo, runs from the USB port, which is great when the number of power sockets is scarce. Still, though USB gives you access to the system shell, some of the most interesting uses will require a network connection using either a Wifi dongle or an Ethernet cable.  Examples are built in Python using Jupyter Notebook technology (web-based documents that combine Python source code and mark-up text).

But while the examples are interesting and useful, getting the most of the SoC may require you to create your own programmable logic design. For that purpose, you would need to get a new set of tools called Xilinx Vivado, but then you venture into an entirely different world, that definitely will show you its ugly face as they seem to have a steep learning curve. The good news is that at least there seems to be a version you could use for free (the free WebPack version). And if you look around you will discover that there are many implementations available you could use without having to reinvent the wheel, like for example a RISC-V core.



Comments

Shauki said…
Might be suitable to implement an open source clone of https://www.keanw.com/2016/05/autodesks-project-escher.html
misan said…
I reckon they developed the whole project with the idea of distributed computation, but that could, of course, adapt it to use a soft processor to handle each nozzle. However, for interfacing purposes, it might still be worth to have really independent processing units linked by a data network.
Shauki said…
I have not yet used OctoPrint, neither Klipper nor Rpitier host. Do you know if any of those can be branched to control several printers at one time?

Popular posts from this blog

VFD control with Arduino using RS485 link

How to get sinusoidal s-curve for a stepper motor

Importing OpenSCAD designs into Onshape