Access NEON coprocessor from programmable logic in Zynq

Question

For the past few days I've been thinking about the neon coprocessor in the Zynq SoC and I have a question, is it possible to send instructions to the neon from the PL side of the SoC?

Imagine I have an application with lots of mathematical operations, and I've used up all the DSP slices in the programmable logic. I guess I could offload some operations to the PS, or find a way to share DSP slices between operations (a few cycles for each). I started thinking that maybe I could offload it to the PS and the PS would send it to the neon coprocessor, which would keep on doing what it has to do and when the data is ready it would send it back to the PL (probably not how the neon coprocessor works, but it's just for example).

As it's possible to see, my next thought was to find out if I could maybe send instructions to the neon coprocessor from the PL side of things. It would be really helpful if it's possible but I haven't found any documentation stating if this is possible, and I've also not been able to find someone that has tried to experiment whit this.

You could probably say that if I have an application that cannot be properly fulfilled wit the available 220 DSP slices, then I should get another one that tends to my needs. But this thought came to me in the shower and it is completely hypothetical. There's no such application that demands so many calcuations (well ... there are, but not any applications that I want to develop).

So, does anybody know if this is possible?

Answer 1

I doubt that this is possible purely with programmable logic as the NEON SIMD engine accesses internal registers and the instructions come from the main instruction stream. There is no way to access either of these from PL. However, what you might be able to do is set up the NEON load/store instructions to read from and write to PL mapped address space and then write some code to drive the NEON coprocessor.

Answer 2

The answer to this is: "sort of, but it's a lot of work".

The PS and PL on the zynq are interconnected using a number of AXI4 interfaces, with varying speed and coherency capabilities. These interfaces can be used as a mechanism to implement a register interface, or transfer data between the PS and PL. There is no inherently native way to pass-off processing to the PS purely because of the opposite natures of the PS and PL, but it would be possible to design a mechanism in between to covert the PL tasks into those the PS would be able to perform. This is where the "lot of work" comes in.

It would be necessary to split the work up in a logical way such that the processing performed is mostly suitable for the architecture (PS or PL) and that they are mostly kept separate from eachother. For example, the PL may pass some data off to the PS for processing, while it continues on the next round of data.

This is an issue of design rather than anything else. It's necessary to use the supplied interfaces between PS and PL to optimise the use of both sets of resources in the optimal way for your application.