Welcome! Log In Create A New Profile

Advanced

Mixing FPGAs and ARM core with Zynq

Posted by misan 
Mixing FPGAs and ARM core with Zynq
February 01, 2019 01:50PM
I am by no means an FPGA power user and what I have been seeing is not even a new technology, but it seems no one so far has reported any work on the specific direction I am about to suggest.

I have started playing with the idea that yet another type of controller could be based on a more parallel approach than what we are used to. If we think about just stepper pulse generation, it is quite common to use a number of tricks so only one timer is used for that. But if you consider the truth of the matter each stepper should perform each step at a very specific moment in time (GRBL AMASS tries to improve upon that). However, because different limitations most systems will use the main timer and condition the other steppers to the main axis timing.

However, what if we could have a single processor (with more than one timer) allocated to the control of each motor? What if all these processors were hosted in the same chip, using the same codebase and yet operating entirely on their own? What if each one of them could be monitored by an ARM Cortex-A9 core that handles network communications and filesystem access (g-code decoding too)? What if this ARM core is in on that same chip too and runs Linux?

Well, all that seems possible with Zynq-7000 Xilinx SoC. At least, it seems possible to me, but I started stating I am no FPGA wizard, so I might be dead wrong.

That is why I am starting this conversation to get input from you guys.

My impression is that adapting Klipper could be the best way to start, but I reckon such a control architecture could usher in much higher flexibility. For example, it could be possible to replace some of the motor controllers easily, to switch any axis from a stepper motor to a dc motor with an encoder or to a FOC brushless motor. Besides, it seems Xilinx already created the basic plumbing for accessing from Python to the shared memory of the soft processors (or any other programmable logic we might use for motor or temperature control).
Re: Mixing FPGAs and ARM core with Zynq
February 01, 2019 05:14PM
Quote
misan
If we think about just stepper pulse generation, it is quite common to use a number of tricks so only one timer is used for that. But if you consider the truth of the matter each stepper should perform each step at a very specific moment in time (GRBL AMASS tries to improve upon that). However, because different limitations most systems will use the main timer and condition the other steppers to the main axis timing.

Marlin and other 8-bit firmwares do that, but the leading 32-bit firmwares don't. RepRapFirmware keeps track of when the next step pulse for each motor is due, and schedules an interrupt for the time of the soonest one. Smoothieware uses a different scheme, I think it uses a fixed 100kHz step interrupt, and at each interrupt generates all the step pulses that have become due.

Quote
misan
However, what if we could have a single processor (with more than one timer) allocated to the control of each motor? What if all these processors were hosted in the same chip, using the same codebase and yet operating entirely on their own? What if each one of them could be monitored by an ARM Cortex-A9 core that handles network communications and filesystem access (g-code decoding too)? What if this ARM core is in on that same chip too and runs Linux?

Well, all that seems possible with Zynq-7000 Xilinx SoC. At least, it seems possible to me, but I started stating I am no FPGA wizard, so I might be dead wrong.

That's hardware overkill IMO, because it's entirely possible to run both the real time functions and support a good web interface on a single ARM M4 or higher processor running a real time operating system. Or, if you want to support additional functionality such as model visualisation and slicing, one real time processor and one application processor running Linux.

OTOH, if/when the Zynq-7000 is cheap enough, why not? How many motors would it be able to support? We're already designing solutions to support about 30 motors, because customers keep wanting more than our current hardware can support.

The main concern I have with FPGAs for this application is that it's harder to do complex things in them. I think you could program basic trapezoidal linear motion in them easily enough. But what about the quadratic motion needed to support delta printers without segmentation? What about the motion needed to implement pressure advance? What about S-curve acceleration? An ARM core processor has the flexibility to do all of that and lots of other things. With an FPGA I would be worried that a new requirement might come along that won't fit in the FPGA.

Edited 3 time(s). Last edit at 02/01/2019 05:24PM by dc42.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: Mixing FPGAs and ARM core with Zynq
February 01, 2019 06:43PM
Hi dc42,

Thanks for the clarification, I was not aware of that in RepRapFirmware. And I meant in no way that current solutions are bad either. A lot of thought has been given to squeezing every inch of computing power out of 8-bit AVRs. My i3 is still powered by one of them :-)

Quote
dc42
The main concern I have with FPGAs for this application is that it's harder to do complex things in them. I think you could program basic trapezoidal linear motion in them easily enough. But what about the quadratic motion needed to support delta printers without segmentation? What about the motion needed to implement pressure advance? What about S-curve acceleration? An ARM core processor has the flexibility to do all of that and lots of other things. With an FPGA I would be worried that a new requirement might come along that won't fit in the FPGA.

My proposal was more along the lines of using the FPGA to hold existing soft processors (MicroBlaze for example) that are already designed and tested, so programmable logic is mostly wired and not designed from scratch. Each one of these processors would run its own fixed-task firmware written in C or assembler in a completely parallel way from each other. Unfortunately for the moment, I do not know yet how to do that but I am looking into it. Though it will be great if anyone with more knowledge can shine a light. Using a processor means that most of the existing code can easily be ported to such soft cores implemented in the programmable logic. I won't be surprised if more than 30 of such cores can run inside that SoC, however, I reckon there are only 64 GPIO pins, so that might require some sort of interface for motor controllers or port extenders for a 30 motor setup (again with my limited knowledge I find myself unable to tell you how many MicroBlaze cores could really hold but I can see most of a single instance requires less than 1% of FPGAs cells ...).

Regarding prices, I reckon Zynq-7000 SoC cost almost 50 bucks, which is expensive compared with most other processors used now. So far this is just a controller architecture proposal.
Re: Mixing FPGAs and ARM core with Zynq
February 02, 2019 03:03AM
Thanks for the response. I'll look into MicroBlaze. Does that 64 GPIO pins include the network interface, USB, camera etc. or is it additional to those pins?

Edited 1 time(s). Last edit at 02/02/2019 03:05AM by dc42.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: Mixing FPGAs and ARM core with Zynq
February 02, 2019 12:07PM
From datashet [download.siliconexpert.com]

I/O Peripherals and Interfaces
• Two 10/100/1000 tri-speed Ethernet MAC peripherals with
IEEE Std 802.3 and IEEE Std 1588 revision 2.0 support
• Scatter-gather DMA capability
• Recognition of 1588 rev. 2 PTP frames
• GMII, RGMII, and SGMII interfaces
• Two USB 2.0 OTG peripherals, each supporting up to 12 Endpoints
• USB 2.0 compliant device IP core
• Supports on-the-go, high-speed, full-speed, and low-speed
modes
• Intel EHCI compliant USB host
• 8-bit ULPI external PHY interface
• Two full CAN 2.0B compliant CAN bus interfaces
• CAN 2.0-A and CAN 2.0-B and ISO 118981-1 standard
compliant
• External PHY interface
• Two SD/SDIO 2.0/MMC3.31 compliant controllers
• Two full-duplex SPI ports with three peripheral chip selects
• Two high-speed UARTs (up to 1 Mb/s)
• Two master and slave I2C interfaces
• GPIO with four 32-bit banks, of which up to 54 bits can be used with
the PS I/O (one bank of 32b and one bank of 22b) and up to 64 bits
(up to two banks of 32b) connected to the Programmable Logic
• Up to 54 flexible multiplexed I/O (MIO) for peripheral pin assignments
Sorry, only registered users may post in this forum.

Click here to login