Simplest way to connect an AXI bus to an external microcontroller?

[tcachat@metraware.com]

I am designing an AXI bus in a Kintex. The master of the bus will be an external microcontroller. Is there a simple way to drive an AXI Interconnect from a parallel bus with address, data, rd_en, wr_en?

If I understand correctly,

• the AMM Master Bridge (Avalon), might be not so far from my needs, but I do not have 32 bits data width.
• the AXI EPC is for slave peripheral.

Thank you

Ref: Vivado 2019.3, AXI Interconnect 2.1

[joancab]

There is a simple way:

- Get the AXI 4 specification from ARM

- Read it

- Understand the protocol

- Select your "sub protocol" (the set of signals you are going to use) as you may not want the full AXI protocol

- Choose I/O pins in the MCU to implement the AXI port

- Write software to implement the protocol

- Last, and most important: find out it's terribly inefficient. Why? Because your software will probably change one thing at a time, set data, then set valid, then check ready, etc. Even if your clock is 200 MHz, your actual data rate could easily be 1/4 of that, you might even need to write it in assembler to keep a decent speed. Implementing AXI in hardware is fast, you have 100 - 200 MHz out of the box. If your actual goal is data transfer, even a veteran 100 MHz Ethernet will probably be better. Or USB, even 2.0 (480 Mb/s). 

[tcachat@metraware.com]

Thank you @joancab. I do not need to transfer data very fast, but I have a limited number of pins, and I would prefer not to read the AXI 4 specification from ARM.

We have another design with an FPGA and a MCU where we use the Slave SelectMAP to configure the FPGA, and then we have coded a simple parallel port in the FPGA to read/write registers (the MCU has build in parallel interface). It works quite well. But here I need an AXI bus for some IPs.

[vanmierlo]

What does the native bus look like on the external microcontroller? Have you already decided which MCU it will be? Some even have an AXI master.

I recommend not to try to bitbang the AXI protocol on the MCU but instead do the conversion in the FPGA.

[EajksEajks]

tcachat@metraware.com 

The biggest issue you will face is that AXI handles rd/wr address, rd/wr data, ok/ko response asynchronously by using different channels with their own two-way valid/accept handshaking mechanisms. If your MCU has no back-pressure mechanism so that the slave - here your FPGA - can signal when the read or write transaction is complete, it will be difficult to design a robust and efficient MCU-AXI bridge.

For instance, let's assume that you want to read. Your MCU provides the address and waits for the data for a given time. When going to AXI, the address will be sent to the AW channel and you will receive after an undetermined time (although, for a specific design, it might be possible to determine a bound for the response time). How will your MCU know when to sample the read data?

Only way I see ('cause I don't know your MCU protocol) would be to develop a MCU slave peripheral. With the help of some software-mapped register you define/trigger the AXI transaction you'ld like to do, then you poll the content of another register to see whether it's completed or not, if it's OK/KO, what the read data is. Given the probable AXI speed, I guess the AXI transaction will be completed after the 1st poll (which could give the idea to some people to forget to poll and directly read the results ; a very bad idea imo that could lead to hard to find nasty bugs).

[joancab]

If you want to interface two things using a protocol you prefer not to read... well... good luck.

On top of that, if you don't need high speeds and don't have many pins, then I'd suggest a QSPI at 100 MHz, available in many MCUs and readily implementable on FPGA.

[EajksEajks]

Since they put all nearly ARM protocols inside the same document, the ARM IIHI 022H specification is now about 500 pages... You have to have some experience to find your way... nonetheless the AXI protocol itself is easy to understand ; its use in a system is much more tricky. It can be extremely powerful but can also lead to nasty issues.

[joancab]

Yet another thing about AXI interfaces is that its typical usage is being mapped to a memory area to transfer large data chunks (otherwise that's why AxiLite exists for), implementing that in custom software may not allow using the existent (if existent) DMA peripherals, so having software busy bitbanging data from and to memory... as an exercise of development or understanding how things work, it's ok, but otherwise AXI-in-software is a square wheeled car.

A bit different could be Axi Stream where the MCU might send data as it is produced. AXI Stream is simpler than its memory mapped option. The lack of addresses may not be a problem if data is framed and Tlast is used, as it happens with video (and many other applications)

[tcachat@metraware.com]

Thank you.

We have chosen the MCU, it is an ARM processor with an EBI (build-in) interface, 16-bit address, 16-bit data, WEn, REn, CSn.

Agree with @vanmierlo, I prefer to "do the conversion in the FPGA" (and the AXI bus has too many signals).

@EajksEajks

, you mean I have to write my own MCU slave peripheral?

By the way some time ago I had the inverse problem: we have a design with a Zynq, so the AXI bus was native, but I had to add my own bloc, controlled by the AXI bus. I found answers here
https://forums.xilinx.com/t5/Synthesis/Vivado-Custom-Peripheral-with-AXI-Connecting-Registers/td-p/407841 (and in the links).

[vanmierlo]

If speed is not an issue, I would go for an AXI4-lite master interface inside the FPGA. It is much simpler.

But as already mentioned, it's reading that is the difficult part. An AXI-slave may not be ready to provide the data as fast as the MCU EBI expects it to arrive.

Why are you so reluctant to tell us which ARM MCU you're going to use?

How fast is the EBI?

Does it have any option to wait for the bus to be ready? (EBI_ARDY?)

Wait states?

[tcachat@metraware.com]

@joancab, I do not need to transfer large data chunks. Seems I could use an AXI Protocol Converter (provided by Vivado) to control the AXI4 bus from a Slave AXI4Lite. Would simplify the job.

@vanmierlo, sorry, it is an EFM32 Giant Gecko 11 from Silicon Labs. It has a WAIT signal.

[Rmccarty]

Just out of curiosity, isn't this sort of issue the reason for socs? Xilinx obviously put a lot of effort into the pl-ps interface so one can do hardware acceleration without undo effort.

[vanmierlo · Accepted solution]

Ok, The GG11 has EBI_ARDY so you're good to go.

Do you intend to use multiplexed mode? 16-bit?

Are you planning to use Byte Lanes? Or only allow 16-bit accesses?

At what speed do you intend to run the GG11? 72 MHz? And the FPGA? If the FPGA is not much faster, consider to bring the GG11 clock to the FPGA so you can run the EBI synchronously.

If going for multiplexed mode, you can latch the address bits on EBI_ALE. Then when EBI_WEn activates present them on AWADDR with AWVALID. Or when EBI_REn activates present them on ARADDR with ARVALID. Withdraw AWVALID or ARVALID when AWREADY resp. ARREADY signals.

Also when EBI_WEn activates latch the data and present it on WDATA with WVALID. You must set WSTRB according to the address.

Finally, when EBI_REn activates, set RREADY but keep EBI_ARDY inactive until you receive RVALID. Then copy the upper or lower half of RDATA depending on the address to EBI_AD and withdraw RREADY.

[EajksEajks]

It sounds to me like you do not intend to write any code. I'm not sure there already exists the kind of EBI-AXI bridge you're looking for. You'll have to write your own EBI slave/AXI-Lite master (and therefore read the AXI specification ;-). Fortunately, it seems there is the possibility to have some back pressure (via EBI_ARDY) ; in this case EBI/AXI should go along pretty well.

[joancab]

The easiest ways for connecting a microcontroller via AXI to an FPGA without having to understand to the bottom how AXI works and without writing (and debugging) software for that are:

- Using the Microblaze MCU

- Using a Zynq SoC

[Rmccarty]

Switching to a zynq soc solved all my interconnection problems. The fabric of a 7020 can easily compute the equivalent of 40-50 stm32f7 and connect any output to any input in realtime (32 KHz)

[tcachat@metraware.com]

Thank you very much for all your comments. Of course I will write code, it is my job. And I will have to read (part of) the documentation. I admit I was discouraged by the number of signals of the AXI (but for the Lite version it should be ok).

As mentioned earlier, we have experienced Zynq on some designs in the past. For the present we need a very limited computational power on the MCU side: the FPGA will work fast, not the MCU. A Zynq needs external RAM and Flash, which consumes area, and it has a much higher cost. We are waiting for a "complete" SOC with RAM and Flash inside!

We have also many FPGA designs (Xilinx and others) without AXI bus, and an SPI or parallel bus driven by an MCU.

[vanmierlo]

Well a Zynq can work without external ram as well and only use OCM. And your fpga might also require a flash.

But I agree on area and price. And analog peripherals can also be a factor.