Principles of FPGA IP interconnect

Within an FPGA design team, developers may have many ideas on how data should be transferred between IP blocks. IP may be developed in-house, by consultants, by the FPGA vendors, or IP may be purchased from 3rd party vendors. Unfortunately, there is no single standard for interfacing between such IP, and a tremendous amount of time is generally being wasted by developers constantly inventing new interfaces, and by others trying to understand them and adapt to them.

In this article, I will explain the basics of how FPGA IP should be interconnected, and then suggest a standard that may be used by all FPGA designers for most designs.

Data transfer with a handshake

Let’s start with a simple example, transferring data along with sof (start-of-frame) and eof (end-of-frame) from a source interface on IP A to a sink interface on IP B:

Fig 1. Example of IP interconnect with source and sink interfaces

Note that ready is the only signal directed from sink to source. All other signals are directed from source to sink. The ready signal is used to provide backpressure/throttling of the stream of data.

Signals data, sof and eof are transferred from source to sink when the following 3 conditions are met:

The generalized data transfer

All signals within the information channel must be valid and stable while signal valid is asserted. Transfer of information happens when condition 1, 2 and 3 above are all met. This is indicated by the bottom waveform.

Beats, channels and transactions

A beat is a single cycle transfer from a source to a sink. The examples above both show 4 beats.

A channel is a collection of signals that share common timing properties and possibly a handshake mechanism. In the examples above, data, sof, eof, valid and ready are all part of the same channel.

A transaction is the transfer of a frame or packet, using one or more beats.

Modes of a channel

If valid or ready are constantly asserted, we may consider this modes of the channel.

If the sink is always able to receive, the ready signal is constantly asserted and may be omitted. The following simplified timing diagram may be used:

Fig 4. ready assumed to be constantly asserted and therefore omitted

If the source is always able to send, the valid signal is constantly asserted and may be omitted. The following simplified timing diagram may be used:

Fig 5. valid assumed to be constantly asserted and therefore omitted

Additional compatibility requirements

For compatibility with standards such as Avalon or AXI there are 3 additional requirements that should be met:

After the source asserts valid, then valid must remain asserted until the handshake has taken place.

After the sink asserts ready, the sink is allowed at any time to de-assert ready without waiting for the handshake.

The source is not allowed to wait for the ready signal from the sink before asserting valid.

This is an example of an illegalde-assertion of valid:

Fig 6. Illegal de-assertion of valid before the handshake

This is an example of an allowed de-assertion of ready:

Fig 7. De-assertion of ready is allowed at any time.

Standards to the rescue

As mentioned earlier, there is no single standard for interfacing between IP. Fortunately, de facto standards exists such as Avalon used by Altera and AXI4 used by both Altera and Xilinx.

AXI4, being developed and pushed by ARM, seems to have the most momentum. AXI4 is well defined and is the basis for most new infrastructure IP designed by Xilinx (and many by Altera). Therefore, AXI4 should be your IP interface standard of choice. By having your FPGA developers agreeing on using AXI4 as their standard, their precious time may be redirected towards developing functionality rather than debugging of interfaces.

If you design with Xilinx, then Xilinx has a huge range of ready-made and free AXI4 infrastructure IP, which can save you a huge amount of time by not having to re-invent such IP blocks.

AXI4-Stream interconnect standard

AXI4-Stream is based on the same principle as outlined above. The main points to consider are:

In AXI4-Stream terminology, master is synonymous to source.

In AXI4-Stream terminology, slave is synonymous to sink.

An IP may have any number of master or slave interfaces.

For any channel, there is a single TREADY signal directed from slave to master.

All other signals in the channel are directed from master to slave.

Most signals are optional.

The following timing diagram is an example utilizing all signals as defined in the AXI4-Stream specification, most of which are optional:

AXI4 and AXI4-Lite

In addition to the AXI4-Stream interface described above, ARM has defined protocols for memory mapped interconnects. These are called AXI4 and AXI4-Lite.

The nice thing about these protocols, is that they are based on the very same channel scheme as described above. The difference is that more channels are utilized. The 5 channels are write address, write data, write response, read address and read data, supported by 5 pairs of VALID/READY:

The master and slave interfaces both include multiple source and sink interfaces.

An IP may have any number of master or slave interfaces.

Note the terminology difference between AXI4/AXI4-Lite and AXI4-Stream:

In AXI4/AXI4-Lite terminology, master/slave is synonymous to initiator/target.

In AXI4-Stream terminology, master/slave is synonymous to source/sink.

The number of individual signal in the AXI4/AXI4-Lite standards may seem large, but now that you know the principles of channel design you can easily design IP that follows any of the AXI4 class protocols.