Understanding Avalon® Memory-Mapped Interfaces: A Guide for Beginners

[symmt_Intel]

Overview

This article is written for beginners who have just started developing Field Programmable Gate Arrays (FPGAs) with Intel®, especially those who have started to use the Platform Designer in Intel® Quartus® Prime Software but are not quite sure about the interfaces of Intellectual Property (IP). While there are various types of Avalon® Interfaces (please refer to this page), this article introduces the frequently used Avalon® Memory-Mapped Interfaces and also explains the Avalon Verification IP Suite used for signal verification. Specifically, for Avalon® Verification IP Suite, you can download the test benches by clicking on Avalon Verification IP Suite Design Files here, and we will actually run them. Note that you can run the test benches if you have the Intel® Quartus® Prime Software Standard Edition, so no actual hardware is required.

*In terms of data exchange, the Master⇔Slave relationship often comes up. In this article, we will explicitly state "who is sending the signal" in the explanations to avoid any confusion.

What is Avalon® Interface?

The Avalon® Interface refers to the ports of Intellectual Property (IP), in other words, the 'entrances and exits' for signals such as clock and data. However, it's important to note that in addition to having physical entrances and exits, there are also various rules in place.

Take an airport as an example: there are physical boarding gates for embarking and disembarking, but there are also pre-established ‘rules’ such as which flights are connected to which gates and the specific times for departures and arrivals of airplanes. If these rules are not followed, airplanes cannot travel to and from the airport. The same concept applies to the Avalon® Interface; it represents not just the physical 'entrances and exits', but also defines the protocol (rules) for using these entrances and exits.

So, what kind of protocols exist for the Avalon® Interface? Specifically, there are:

• Avalon® Clock and Reset Interfaces
• Avalon® Memory-Mapped Interfaces
• Avalon® Interrupt Interfaces
• Avalon® Streaming Interfaces
• Avalon® Streaming Credit Interfaces
• Avalon® Conduit Interfaces
• Avalon® Tristate Conduit Interface

and so on. In this session, we will take a closer look at Avalon® Memory-Mapped Interfaces, which is one of the most frequently used interfaces.

Direction

Signal Role	Width	Required	Desctiption
address	1-64	Master → Slave	No	This signal is used for data address specification. Of course, if the Master is asserting the read signal (making the signal active; the opposite, making it inactive, is called deasserting), the Slave cannot determine which data it wants to read unless an address is specified. Similarly, if the Master is asserting the write signal, the Slave cannot decide where it wants to write the data unless an address is specified. However, address specification is not necessary if there is only one register provided on the Slave side.
byteenable	2, 4, 8, 16, 32, 64, 128	Master → Slave	No	This signal is used to specify which bytes of the readdata and writedata you want to read and write. For example, for a 32-bit data, if byteenable=0b0001, it means reading and writing the lower 8 bits, and if byteenable=0b1000, the upper 8 bits are read and written. Especially when the Slave side supports byte-by-byte access, the byteenable signal is used for transmission and reception. If you are using peripherals that are not compatible, please check the access method in the manual.
read	1	Master → Slave	No	If the Master asserts the read signal, the Slave can determine that the Master wants to read data. Additionally, if you only want to perform a write operation, the read signal is not necessary.
readdata	2, 4, 8, 16, 32, 64, 128, 256, 512, 1024	Slave → Master	No	After the Slave receives the read signal from the Master, this data is transmitted from the Slave to the Master. If the read signal is not used, the readdata signal is also not necessary.
response[1:0]	2	Slave → Master	No	This is the reception status signal sent by the Slave. It is used to inform the status of whether the transaction was carried out correctly.
write	1	Master → Slave	No	If the Master asserts the write signal, the Slave can determine that the Master wants to write data. Additionally, if you only want to perform a read operation, the write signal is not necessary.
writedata	2, 4, 8, 16, 32, 64, 128, 256, 512, 1024	Master → Slave	No	The writedata signal is the data that the Master sends simultaneously with the write signal, to be written to the Slave. If the write signal is not used, the writedata signal is also not necessary.

Signal Patterns of Avalon® Memory-Mapped Interfaces

Below, we will take a look at some of the signal patterns described in the manual. We will explain the state of the signals around each cycle.

Typical Read and Write Transfers

This section presents a typical interaction of read and write signals. Pay attention to which of the Master or Slave is asserting each signal.

Image Source: Avalon® Interface Specifications Figure 7. Read and Write Transfers with Waitrequest

1. address, byteenable, and read are asserted by the Master. However, since the Slave asserts waitrequest, no data is sent from Slave to Master.
2. Since the Slave asserts waitrequest, no data transfer occurs.
3. The Slave deasserts waitrequest, and data is sent from Slave to Master.
4. The Master completes the reception of readdata.
5. Since both read and write are deasserted, no data transfer occurs.
6. Although the Master continues to send writedata, the Slave does not receive data yet because waitrequest is asserted.
7. Since waitrequest is deasserted, the Slave receives address, byteenable, write, and writedata from the Master.

※ The sections of the signals that are grayed out represent undefined values. ※ Signals are output slightly delayed relative to the rising edge of the clock. For example, if we focus near the rising edge of the first clock, we see that the Master asserts the address, byteenable, and read signals, but they are asserted slightly after the rising edge of the clock. This delay is due to the time it takes for the output to be obtained from the D flip-flop.

Write Bursts

This example demonstrates signal behavior during write operations in burst mode. Burst mode refers to a mode where data is sent continuously. By specifying an address and burst count (the number of consecutive data items to receive or send) at the beginning, you can receive or send burst count number of data items from the address location.

Image Source: Avalon® Interface Specifications Figure 14. Write Burst with constantBurstBehavior Set to False for Master and Slave

1. address, beginbursttransfer, burstcount, write, and writedata are asserted by the Master. However, since the Slave asserts waitrequest, no data is sent from Slave to Master.
2. The Slave asserts waitrequest, so it does not complete reception of writedata.
3. Since the Slave deasserts waitrequest, it receives data 1.
4. Since the Slave deasserts waitrequest, it receives data 2.
5. The Master deasserts write, so the Slave does not receive writedata.
6. Since the Slave deasserts waitrequest, it receives data 3.
7. The Slave asserts waitrequest, so it does not receive writedata.
8. Since the Slave deasserts waitrequest, it receives data 4.

Let's Try Running the Avalon® Verification IP Suite Design Example

The Avalon® Verification IP Suite is a simulation library for observing the signals of Avalon® Interfaces. As shown in the diagram below, you can define a Test Module on the user side and specify what kind of simulation to perform. In the Design Example used for the later section, Downloading the Design Example, the User Test Bench is written in SystemVerilog.

Image Source: Avalon® Verification IP Suite Design Example Figure 1. Verification testbench using Avalon Verification IP Suite.

By utilizing this example design, you will be able to simulate the behavior of your custom hardware design with an Avalon® interface, and check the state of signals and the flow of data. This allows you to verify that the hardware design is functioning as expected, or to identify any issues at an early stage.

Required Environment

Windows 10 21H2 Intel® Quartus® Prime Software Standard Edition

Downloading the Design Example

Please click on ug_avalon_verification.zip here to download the Design Example.

Avalon Verification IP Suite User Guide (PDF) is the manual.

Once the download is complete, unzip the file and make sure it contains the following:

• avlmm_1x1_verilog.zip
• avlmm_1x1_vhdl.zip
• avlmm_2x2_verilog.zip
• avlmm_2x2_vhdl.zip
• ug_avalon_verification.zip

We will only be using avlmm_1x1_verilog.zip, so please unzip this file as well. 

Operating Intel® Quartus® Prime Software

Open Intel® Quartus® Prime Software and click on File > Open.

This will launch the File Explorer. Navigate to avlmm_1x1_verilog/avlm_avls_1x1.qsys, select it, and click "Open".

Platform Designer will start, and the following window will appear. There will be a warning about the IP version, but it is not a problem. Please click Close.

A window will also appear to inform you that the IP has been upgraded. Please click "Close" to close it.

Please click on "Generate HDL..." located at the bottom right of the Platform Designer.

A window for Generation will appear. Please set it up as shown in the image below, and click on "Generate".

When the "Save System Completed" window appears, click "Close" to close it.

When the "Generate Completed" window appears, click "Close" to close it.

Please open Questa from the Windows start menu.

This is the startup screen for Questa.

Navigate to the location of "avlmm_1x1_verilog" in the Transcript, and execute the following command:

> do run_simulation.tcl

As shown in the image below, "run_simulation.tcl" should be included within "avlmm_1x1_verilog".

Please confirm that the simulation results are displayed as follows.

You can zoom in using the 'i' key on your keyboard and zoom out using the 'o' key. If the waveform is difficult to capture, it may be helpful to zoom to an appropriate size for viewing.

Focusing on the avm_write and avm_read signals (the cyan squares) in the gray pane on the left side, you can see that they are divided into four parts marked by red squares:

1. The master asserts the write signal (no burst).
2. The master asserts the read signal (no burst).
3. The master asserts the write signal (burst).
4. The master asserts the read signal (burst).

This allows you to observe how the Avalon® Verification IP Suite behaves under different conditions and signals.

Let’s closely observe the simulation results to see if the Avalon® memory-mapped interface behaves as described in the sections, Typical Read and Write Transfers and Write Bursts. Below, we will explain each part of the four red blocks.

Master Asserts Write Signal (No Burst) Starting at 1.45ns

Let’s take a look at the moment when avm_write is asserted without burst for the first time.

• cycle0: The Master asserts avm_address, avm_burstcount, avm_write, avm_writedata, and avm_byteenable. The Master expects the Slave to receive the writedata. Shortly after (this delay is because it takes time for the Master to send the above signals to the Slave and for signals to come out of the Slave), the Slave asserts waitrequest.
• cycle1: Since waitrequest is asserted, the Slave does not complete receiving data from the Master.
• cycle2: Here, the Slave deasserts waitrequest. Other signals remain constant.
• cycle3: Since waitrequest is deasserted, the Slave finally receives data from the Master.

Master Asserts Read Signal (No Burst) Starting at 2.35ns

• cycle0: The master asserts avm_address, avm_burstcount, avm_write, avm_writedata, and avm_byteenable. The master expects the slave to receive the writedata.
• cycle1: As the slave does not assert waitrequest, it receives the data from the master.
• cycle2: The master asserts avm_address, avm_burstcount, avm_write, avm_writedata, and avm_byteenable again. The master expects the slave to receive the new writedata.
• cycle3: Since the slave does not assert waitrequest, it receives the data from the master. At the same time, the master asserts new address and writedata to send the next piece of data.
• cycle4: As the slave does not assert waitrequest, it receives the data from the master.

Master Asserts Write Signal (Burst) Starting at 7.25ns

• cycle0: The master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable. The master expects the slave to send the read data. Additionally, a bit later, the slave asserts waitrequest.
• cycle1: Since waitrequest is asserted, the slave does not complete receiving data from the master.
• cycle2: waitrequest remains asserted, so the slave does not complete receiving data from the master. The slave deasserts waitrequest.
• cycle3: With waitrequest now deasserted, the slave receives avm_address, avm_burstcount, avm_read, and avm_byteenable from the master.
• cycle4: Neither the master nor the slave assert any signals.
• cycle5: The data requested by the master from the slave in cycle0 arrives at the master.

Master Asserts Read Signal (Burst) Starting at 32.85ns

The number of cycles to check has increased, but please do your best to review the following flow.

• cycle0: Master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable. The Master expects the Slave to send readdata. <b>Note that the burstcount is 3.</b> Shortly after, the Slave asserts waitrequest.
• cycle1: Since waitrequest is asserted, the Slave does not complete receiving data from the Master. The Slave deasserts waitrequest.
• cycle2: With waitrequest deasserted, the Slave receives avm_address, avm_burstcount, avm_read, and avm_byteenable from the Master.
• cycle3: Master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable again, expecting the Slave to send readdata. Shortly after, the Slave asserts waitrequest. Data1 requested by the Master from the Slave in cycle0 reaches the Master.
• cycle4: With waitrequest deasserted, the Slave receives avm_address, avm_burstcount, avm_read, and avm_byteenable from the Master.
• cycle5: Neither Master nor Slave assert any signals.
• cycle6: Data2 requested by the Master from the Slave in cycle0 reaches the Master.
• cycle7: Neither Master nor Slave assert any signals.
• cycle8: Neither Master nor Slave assert any signals.
• cycle9: Neither Master nor Slave assert any signals.
• cycle10: Master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable, expecting the Slave to send readdata. Additionally, Data3 requested by the Master from the Slave in cycle0 reaches the Master. This concludes the transfer of all data requested by the Master from the Slave in cycle0.

Summary

How was it? From the simulation results, I believe you were able to understand the operation of the Avalon® memory-mapped interface. It’s just like how busy person A and busy person B need rules (protocols) to communicate. The same applies to IP; communication is rule-based, and it is very important to understand the rules, such as signaling “wait a moment” (waitrequest) when busy, whether you want to receive (read) or send (write) a message, and so on.

Notices & Disclaimers

Intel technologies may require enabled hardware, specific software, or service activation.

© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Names and brands of other entities may be claimed as the property of others.

For more information, please visit Intel's Benchmark Overview.