• Example Timing Diagrams
• Read Transactions
• Points to note:
• Write Transactions
• Points to note:
• Resulting Test Cases
• Useful References
• Acronyms

The aim is to derive the test scenarios required for a successful FPGA implementation of an AXI4-Lite general purpose I/O (GPIO) component. The AMBA® AXI and ACE Protocol Specification by ARM is precise but not necessarily helpful in the regard.

Example Timing Diagrams

Read Transactions

The AMBA® AXI and ACE Protocol Specification explains the read transactions as a dependency graph as follows.

Whilst correct, I find the absence of example timing diagrams unhelpful. The following timing diagram illustrates how the above dependencies might play out. The timing scenarios meet these dependencies, and illustrate how they might work in practice. Note any version of the timing diagrams might be used with your component, so no assumptions should be made about which scenario to test against, test against all of them all the time.

Points to note:

When address and data are asserted simultaneously they can be applied to the RAM or decode logic directly. When the data is delayed with respect to the address, then the address must either be held, by keeping arvalid low, or retained in a register. When retaining the address in a register, a clock cycle delay is incurred is making it available which is fine as long as the data is at least one cycle delayed, but if the data is simultaneous to the address, it will now be too early. The specific cases requiring most care are a delay of 0 or 1 cycles between address and data.

• *ready and *valid signals can be raised in either order. In fact the standard requires neither to wait for the other to avoid deadlock. Therefore there can be some delay in completing the transaction until both signals are asserted.
• The *data value is the slave's response to the master's *addr value request, meaning the value follows in subsequent clock cycles.

Write Transactions

The AMBA® AXI and ACE Protocol Specification explains the read transactions as a dependency graph as follows.

The following timing scenarios meet these dependencies, and illustrate how they might work in practice. Note any version of the timing diagrams might be used with your component, so no assumptions should be made about which scenario to test against, test against all of them all the time.

Points to note:

• (As with reads) *ready and *valid signals can be raised in either order. In fact the standard requires neither to wait for the other to avoid deadlock. Therefore there can be some delay in completing the transaction until both signals are asserted.
• The master can supply the *data earlier than, at the same time as, or later than the *addr. This might come as a surprise since all documentation diagrams show the *data following the *addr.
• The write response from the slave, bresp, follows the master's write request to confirm success.

Resulting Test Cases

Construct test cases to explicitly test the following:

1. *valid asserted before *ready.
2. *ready asserted before *valid.
3. *addr and *data provided simultaneously.
4. *data provided one clock cycle after the *addr, then two, then three etc. The range is important here to avoid assumptions made whilst coding. The one clock cycle delay is a specific case that needs to be covered for a "data flow" vice state machine implementation. The former needs to handle any registering of the *addr and it becoming readable from the register as the *data arrival delay varies from 0 to several clock cycles.

Useful References

1. AMBA AXI and ACE Protocol Specification
2. Xilinx's AXI Reference Guide, UG761 (v14.3) November 15, 2012
3. Xilinx's Support Forum: AXI Basics 1 - Introduction to AXI

Acronyms

AMBA

Advanced Microcontroller Bus Architecture

AXI

Advanced eXtensible Interface

GPIO

General Purpose Input Output