Avalon® Interface Specifications

Download PDF
ID 683091
Date 1/24/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. Introduction to the Avalon® Interface Specifications 2. Avalon® Clock and Reset Interfaces 3. Avalon® Memory-Mapped Interfaces 4. Avalon® Interrupt Interfaces 5. Avalon® Streaming Interfaces 6. Avalon® Streaming Credit Interfaces 7. Avalon® Conduit Interfaces 8. Avalon® Tristate Conduit Interface A. Deprecated Signals B. Document Revision History for the Avalon® Interface Specifications
1. Introduction to the Avalon® Interface Specifications x
1.1. Avalon® Properties and Parameters 1.2. Signal Roles 1.3. Interface Timing 1.4. Example: Avalon® Interfaces in System Designs
2. Avalon® Clock and Reset Interfaces x
2.1. Avalon® Clock Sink Signal Roles 2.2. Clock Sink Properties 2.3. Associated Clock Interfaces 2.4. Avalon® Clock Source Signal Roles 2.5. Clock Source Properties 2.6. Reset Sink 2.7. Reset Sink Interface Properties 2.8. Associated Reset Interfaces 2.9. Reset Source 2.10. Reset Source Interface Properties
3. Avalon® Memory-Mapped Interfaces x
3.1. Introduction to Avalon® Memory-Mapped Interfaces 3.2. Avalon® Memory Mapped Interface Signal Roles 3.3. Interface Properties 3.4. Timing 3.5. Transfers 3.6. Address Alignment 3.7. Avalon® -MM Agent Addressing
3.5. Transfers x
3.5.1. Typical Read and Write Transfers 3.5.2. Transfers Using the waitrequestAllowance Property 3.5.3. Read and Write Transfers with Fixed Wait-States 3.5.4. Pipelined Transfers 3.5.5. Burst Transfers 3.5.6. Read and Write Responses
3.5.2. Transfers Using the waitrequestAllowance Property x
3.5.2.1. waitrequestAllowance Equals Two 3.5.2.2. waitrequestAllowance Equals One 3.5.2.3. waitrequestAllowance Equals Two - Not Recommended 3.5.2.4. waitrequestAllowance Compatibility for Avalon® -MM Host and Agent Interfaces 3.5.2.5. waitrequestAllowance Error Conditions
3.5.4. Pipelined Transfers x
3.5.4.1. Pipelined Read Transfer with Variable Latency 3.5.4.2. Pipelined Read Transfers with Fixed Latency
3.5.5. Burst Transfers x
3.5.5.1. Write Bursts 3.5.5.2. Read Bursts 3.5.5.3. Line–Wrapped Bursts
3.5.6. Read and Write Responses x
3.5.6.1. Transaction Order for Avalon® -MM Read and Write Responses (Hosts and Agents) 3.5.6.2. Avalon® -MM Read and Write Responses Timing Diagram
3.5.6.2. Avalon® -MM Read and Write Responses Timing Diagram x
3.5.6.2.1. minimumResponseLatency Timing Diagram with readdatavalid or writeresponsevalid
4. Avalon® Interrupt Interfaces x
4.1. Interrupt Sender 4.2. Interrupt Receiver
4.1. Interrupt Sender x
4.1.1. Avalon® Interrupt Sender Signal Roles 4.1.2. Interrupt Sender Properties
4.2. Interrupt Receiver x
4.2.1. Avalon® Interrupt Receiver Signal Roles 4.2.2. Interrupt Receiver Properties 4.2.3. Interrupt Timing
5. Avalon® Streaming Interfaces x
5.1. Terms and Concepts 5.2. Avalon® Streaming Interface Signal Roles 5.3. Signal Sequencing and Timing 5.4. Avalon® -ST Interface Properties 5.5. Typical Data Transfers 5.6. Signal Details 5.7. Data Layout 5.8. Data Transfer without Backpressure 5.9. Data Transfer with Backpressure 5.10. Packet Data Transfers 5.11. Signal Details 5.12. Protocol Details
5.3. Signal Sequencing and Timing x
5.3.1. Synchronous Interface 5.3.2. Clock Enables
5.9. Data Transfer with Backpressure x
5.9.1. Data Transfers Using readyLatency and readyAllowance 5.9.2. Data Transfers Using readyLatency
6. Avalon® Streaming Credit Interfaces x
6.1. Terms and Concepts 6.2. Avalon® Streaming Credit Interface Signal Roles 6.3. Avalon® Streaming Credit User Signals
6.2. Avalon® Streaming Credit Interface Signal Roles x
6.2.1. Synchronous Interface 6.2.2. Typical Data Transfers 6.2.3. Returning the Credits
6.3. Avalon® Streaming Credit User Signals x
6.3.1. Per-Symbol User Signal 6.3.2. Per-Packet User Signal
7. Avalon® Conduit Interfaces x
7.1. Avalon® Conduit Signal Roles 7.2. Conduit Properties
8. Avalon® Tristate Conduit Interface x
8.1. Avalon® Tristate Conduit Signal Roles 8.2. Tristate Conduit Properties 8.3. Tristate Conduit Timing
1. Introduction to the Avalon® Interface Specifications
2. Avalon® Clock and Reset Interfaces
3. Avalon® Memory-Mapped Interfaces
4. Avalon® Interrupt Interfaces
5. Avalon® Streaming Interfaces
6. Avalon® Streaming Credit Interfaces
7. Avalon® Conduit Interfaces
8. Avalon® Tristate Conduit Interface
A. Deprecated Signals
B. Document Revision History for the Avalon® Interface Specifications

3.2. Avalon® Memory Mapped Interface Signal Roles

Signal roles define the signal types that Avalon® memory mapped host and agent ports allow.

This specification does not require all signals to exist in an Avalon® memory mapped interface. There is no one signal that is always required. The minimum requirements for an Avalon® memory mapped interface are readdata for a read-only interface, or writedata and write for a write-only interface.

The following table lists signal roles for the Avalon® memory mapped interface:

Table 9.   Avalon® Memory Mapped Signal RolesSome Avalon® memory mapped signals can be active high or active low. When active low, the signal name ends with _n.
Signal Role Width Direction Required Description
Fundamental Signals
address 1 - 64 Host → Agent No

Hosts: By default, the address signal represents a byte address. The value of the address must align to the data width. To write to specific bytes within a data word, the host must use the byteenable signal. Refer to the addressUnits interface property for word addressing.

Agents: By default, the interconnect translates the byte address into a word address in the agent’s address space. From the perspective of the agent, each agent access is for a word of data.

For example, address = 0 selects the first word of the agent. address = 1 selects the second word of the agent. Refer to the addressUnits interface property for byte addressing.

byteenable

byteenable_n

2, 4, 8, 16, 32, 64, 128 Host → Agent No Enables one or more specific byte lanes during transfers on interfaces of width greater than 8 bits. Each bit in byteenable corresponds to a byte in writedata and readdata. The host bit <n> of byteenable indicates whether byte <n> is being written to. During writes, byteenables specify which bytes are being written to. Other bytes should be ignored by the agent. During reads, byteenables indicate which bytes the host is reading. Agents that simply return readdata with no side effects are free to ignore byteenables during reads. If an interface does not have a byteenable signal, the transfer proceeds as if all byteenables are asserted.

When more than one bit of the byteenable signal is asserted, all asserted lanes are adjacent.

debugaccess 1 Host → Agent No When asserted, allows the Nios® II processor to write on-chip memories configured as ROMs.
read

read_n

1 Host → Agent No Asserted to indicate a read transfer. If present, readdata is required.
readdata 8, 16, 32, 64, 128, 256, 512, 1024 Agent → Host No The readdata driven from the agent to the host in response to a read transfer. Required for interfaces that support reads.
response [1:0] 2 Agent → Host No

The response signal is an optional signal that carries the response status.

Note: Because the signal is shared, an interface cannot issue or accept a write response and a read response in the same clock cycle.
  • 00: OKAY—Successful response for a transaction.
  • 01: RESERVED—Encoding is reserved.
  • 10: SLVERR—Error from an endpoint agent. Indicates an unsuccessful transaction.
  • 11: DECODEERROR—Indicates attempted access to an undefined location.

For read responses:

  • One response is sent with each readdata. A read burst length of N results in N responses. Fewer responses are not valid, even in the event of an error. The response signal value may be different for each readdata in the burst.
  • The interface must have read control signals. Pipeline support is possible with the readdatavalid signal.
  • On read errors, the corresponding readdata is "don't care".

For write responses:

  • One write response must be sent for each write command. A write burst results in only one response, which must be sent after the final write transfer in the burst is accepted.
  • If writeresponsevalid is present, all write commands must be completed with write responses.
write

write_n

1 Host → Agent No Asserted to indicate a write transfer. If present, writedata is required.
writedata 8, 16, 32, 64, 128, 256, 512, 1024 Host → Agent No Data for write transfers. The width must be the same as the width of readdata if both are present. Required for interfaces that support writes.
Wait-State Signals
lock 1 Host → Agent No lock ensures that once a host wins arbitration, the winning host maintains access to the agent for multiple transactions. Lock asserts coincident with the first read or write of a locked sequence of transactions. Lock deasserts on the final transaction of a locked sequence of transactions. lock assertion does not guarantee that arbitration is won. After the lock-asserting host has been granted, that host retains grant until lock is deasserted.

A host equipped with lock cannot be a burst host. Arbitration priority values for lock-equipped hosts are ignored.

lock is particularly useful for read-modify-write (RMW) operations. The typical read-modify-write operation includes the following steps:

  1. Host A asserts lock and reads 32-bit data that has multiple bit fields.
  2. Host A deasserts lock, changes one bit field, and writes the 32-bit data back.

lock prevents host B from performing a write between Host A’s read and write.

waitrequest

waitrequest_n

1 Agent → Host No An agent asserts waitrequest when unable to respond to a read or write request. Forces the host to wait until the interconnect is ready to proceed with the transfer. At the start of all transfers, a host initiates the transfer and waits until waitrequest is deasserted. A host must make no assumption about the assertion state of waitrequest when the host is idle: waitrequest may be high or low, depending on system properties.

When waitrequest is asserted, host control signals to the agent must remain constant except for beginbursttransfer. For a timing diagram illustrating the beginbursttransfer signal, refer to the figure in Read Bursts.

An Avalon® memory mapped agent may assert waitrequest during idle cycles. An Avalon® memory mapped host may initiate a transaction when waitrequest is asserted and wait for that signal to be deasserted. To avoid system lockup, an agent device should assert waitrequest when in reset.

Pipeline Signals
readdatavalid

readdatavalid_n

1 Agent → Host No Used for variable-latency, pipelined read transfers. When asserted, indicates that the readdata signal contains valid data. For a read burst with burstcount value <n>, the readdatavalid signal must be asserted <n> times, once for each readdata item. There must be at least one cycle of latency between acceptance of the read and assertion of readdatavalid. For a timing diagram illustrating the readdatavalid signal, refer to Pipelined Read Transfer with Variable Latency.

An agent may assert readdatavalid to transfer data to the host independently of whether the agent is stalling a new command with waitrequest.

Required if the host supports pipelined reads. Bursting hosts with read functionality must include the readdatavalid signal.

writeresponsevalid 1 Agent → Host No

An optional signal. If present, the interface issues write responses for write commands.

When asserted, the value on the response signal is a valid write response.

Writeresponsevalid is only asserted one clock cycle or more after the write command is accepted. There is at least a one clock cycle latency from command acceptance to assertion of writeresponsevalid.

A write command is considered accepted when the last beat of the burst is issued to the agent and waitrequest is low. writeresponsevalid can be asserted one or more clock cycles after the last beat of the burst has been issued.

Burst Signals
burstcount 1 – 11 Host → Agent No Used by bursting hosts to indicate the number of transfers in each burst. The value of the maximum burstcount parameter must be a power of 2. A burstcount interface of width <n> can encode a max burst of size 2(<n>-1). For example, a 4-bit burstcount signal can support a maximum burst count of 8. The minimum burstcount is 1. The constantBurstBehavior property controls the timing of the burstcount signal. Bursting hosts with read functionality must include the readdatavalid signal.

For bursting hosts and agents using byte addresses, the following restriction applies to the width of the address: 

<address_w> >=
                  <burstcount_w> +
log2(<symbols_per_word_of_interface>)

For bursting hosts and agents using word addresses, the log2 term above is omitted.

beginbursttransfer 1 Interconnect → Agent No Asserted for the first cycle of a burst to indicate when a burst transfer is starting. This signal is deasserted after one cycle regardless of the value of waitrequest. For a timing diagram illustrating beginbursttransfer, refer to the figure in Read Bursts.

beginbursttransfer is optional. An agent can always internally calculate the start of the next write burst transaction by counting data transfers.

Warning: do not use this signal. This signal exists to support legacy memory controllers.
Level Two Title