Mixing FPGAs and ARM core with Zynq

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).

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.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

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.

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.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

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

Using an FPGA as a printer controller is something I also thought about. And it might be a good solution for exact and fast movement. But I'm also a absolute beginner when it comes to FPGA.

Having a (soft core) processor for each stepper might be overkill. It is then also necessary to synchronize them. If they are all in the same chip then this is only a software issue.

I would assume an easier and cheaper solution for starting to evaluate FPGAs would be to go with one of the TinyFPGA boards. They are ready to use and comparable cheap. They also come with a completely open source tool chain.

For a start one could use an SPI connection between a µController and the FPGA. Over the SPI the FPGA then gets the move commands and report its state. The whole movement could probably defined as logic functions. So no soft core processor running inside the FPGA.

@DC42 is probably right that S-Curve and other features would complicate the matter fast. Best would probably be to start with one stepper only. Getting that to work probably gives the information needed(# of logic cells used,..) to decide how to move forward.

My understanding is that Klipper does the motion calculation on the host and sends of list of time codes and actions to the client. The client then just executes that list. This is very simplified and probably at least partly wrong. So this might make sense for a Linux + one CPU per stepper approach inside one FPGA. But in that approach you would need to change the host part of Klipper to talk to many clients simultaneously. And might also need to adopt the client.

With the SPI approach it probably makes more sense to use any "normal" Firmware and remove the stepper control stuff and replace it with the SPI->FPGA stuff.

Just my 2c. Would love to hear more if someone learns something new.