Zynq-7000 EPP: Does it connect with AXI3 or AXI4?

The short answer

• The P7 ARM processor’s buses run AXI3
• It’s not as important as it seems at first

The supposed conflict

Xilinx have been transferring most of its CoreGen IP cores from all kinds of interfaces to AXI4 over the last few years. With the transaction of Microblaze-related IP cores together with the anticipation for an ARM-based platform to replace the old PowerPC embedded processors, it was somehow obvious that these new Cortex A9 processors would talk with the world through AXI4. But no, they ended up with AXI3, and Xilinx’ documentation seems to prefer hinting that fact, rather than spelling it out loud and clear.

So what’s the difference between AXI3 and AXI4? Well, the most outstanding difference is that AXI4 allows up to 256 beats of data per burst (1 kByte on 32-bit data buses) while AXI3 allows no more than 16 beats (64 bytes on 32-bit data buses). This means that if an AXI4-based IP core is connected as master directly to the Zynq-7000′s AXI wires, it may attempt bursts that the slave will not be able to support. Or more precisely, the burst length signals on AXI3 are only 4 bits, as opposed to AXI4′s counterparts with 8 bits. So the bursts requests won’t go through correctly. As I’ll explain below, this is not likely to happen.

There is a variety of other differences between the bus interfaces, many of which don’t pose a compatibility issue when connecting an existing IP core running AXI4 to an AXI processor, since the newer version is more restrictive in many respects. A summary can be found in chapter 13 of the IHI0022C AMBA specification.

No reason for alarm

On the face of it, this AXI3/4 interconnect conflict is a recipe for a disaster. In reality, the XPS gracefully hides this detail from the innocent design engineer.

The key is in the way XPS requires us to connect an AXI master to the processor: Through an axi_interconnect IP core. These IP cores are always involved, being the embodiment of those colored bus columns displayed in the XPS GUI for connecting and disconnecting modules in a processor design.

As it says in the AXI interconnect IP core’s datasheet (“AXI3 Slave Converted”, page 27 or so) this interconnect module splits bursts larger than 16 beats (regardless of AWCACHE/ARCACHE), if the slave declares itself as AXI3. So if an engineer who is unaware of this AXI version issue just connects an AXI4 IP core to the Zynq processor, it will turn out fine: XPS automatically generates the AXI interconnect IP core, which detects the need for translation, and transparently makes sure the bursts end up on the slave OK.

But sometimes it matters

An interesting case is when there’s a single master and single slave on a bus. If the bus widths are same on both ends, and the bus protocols match, there’s no need for any intermediate logic: The interconnect should consist of just plain wires. Indeed, AXI interconnect IP core’s datasheet describes this situation on its page 8 (or so) under the title “Pass Through”. It’s not just an issue of saving logic and memory for interconnect FIFOs, but the conversion logic also has some combinatoric paths between the master and slave, which may reduce the maximal bus clock frequency. I suppose it’s possible configure the interconnect so it pushes a register in that path, but I never got to investigate that.

This is relevant in particular with custom IP cores. If they are made AXI3 compatible and declared as such (with the C_M_AXI_PROTOCOL parameter in the .mpd file), both logic and some headache can be saved. It’s also important to remember to match the processor’s data bus width to the core’s.

So all in all, this AXI3/4 incompatibility sounds worse than it really is. I’m just left to wonder why this happened at all.