Avalon® Interface Specifications

Download PDF
ID 683091
Date 9/26/2022
Public
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 Adaptation Requirements 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

5.9.1. Data Transfers Using readyLatency and readyAllowance

The following rules apply when transferring data with readyLatency and readyAllowance.

  • If readyLatency is 0, readyAllowance can be greater than or equal to 0.
  • If readyLatency is greater than 0, readyAllowance can be greater than or equal to readyLatency.

When readyLatency = 0 and readyAllowance = 0, data transfers occur only when both ready and valid are asserted. In this case, the source does not receive the sink’s ready signal before sending valid data. The source provides the data and asserts valid whenever possible. The source waits for the sink to capture the data and assert ready. The source can change the data at any time. The sink only captures input data from the source when ready and valid are both asserted.

Figure 25. readyLatency = 0, readyAllowance = 0

When readyLatency = 0 and readyAllowance = 0 the source can assert valid at any time. The sink captures the data from source only when ready = 1.

The following figure demonstrates these events:

  1. In cycle 1 the source provides data and asserts valid.
  2. In cycle 2, the sink asserts ready and D0 transfers.
  3. In cycle 3, D1 transfers.
  4. In cycle 4, the sink asserts ready, but the source does not drive valid data.
  5. The source provides data and asserts valid on cycle 6.
  6. In cycle 8, the sink asserts ready, so D2 transfers.
  7. D3 transfers at cycle 9 and D4 transfers at cycle 10.
Figure 26. readyLatency = 0, readyAllowance = 1

When readyLatency = 0 and readyAllowance = 1 the sink can capture one more data transfer after ready = 0.

The following figure demonstrates these events:

  1. In cycle 1 the source provides data and asserts valid while the sink asserts ready. D0 transfers.
  2. D1 is transferred in cycle 2.
  3. In cycle 3, ready deasserts, however since readyAllowance = 1 one more transfer is allowed, so D2 transfers.
  4. In cycle 5 both valid and ready assert, so D3 transfers.
  5. In cycle 6, the source deasserts valid, so no data transfers.
  6. In cycle 7, valid asserts and ready deasserts, however since readyAllowance = 1 one more transfer is allowed, so D4 transfers.
Figure 27. readyLatency = 1, readyAllowance = 2

When readyLatency = 1 and readyAllowance = 2 the sink can transfer data one cycle after ready asserts, and two more cycles of transfers are allowed after ready deasserts.

The following figure demonstrates these events:

  1. In cycle 0 the sink asserts ready.
  2. In cycle 1, the source provides data and asserts valid. The transfer occurs immediately.
  3. In cycle 3, the sink deasserts ready, but the source is still asserting valid, and drives valid data because the sink can capture data two cycles after ready deasserts.
  4. In cycle 6, the sink asserts ready.
  5. In cycle 7, the source provides data and asserts valid. This data is accepted.
  6. In cycle 10, the sink has deasserted ready, but the source asserts valid and drives valid data because the sink can capture data two cycles after ready deasserts.

Adaptation Requirements

The following table describes whether source and sink interfaces require adaptation.

Table 19.  Source/Sink Adaptation Requirements
readyLatency readyAllowance Adaptation
Source readyLatency = Sink readyLatency Source readyAllowance = Sink readyAllowance No adaptation required: The sink can capture all transfers.
Source readyAllowance > Sink readyAllowance Adaptation required: After ready is deasserted, the source can send more transfers than the sink can capture.
Source readyAllowance < Sink readyAllowance No adaptation required: After ready is deasserted, the sink can capture more transfers than the source can send.
Source readyLatency > Sink readyLatency Source readyAllowance = Sink readyAllowance No adaptation required: After ready is asserted, the source starts sending later than the sink can capture. After ready is deasserted, the source can send as many transfers as the sink can capture.
Source readyAllowance> Sink readyAllowance Adaptation required: After ready is deasserted, the source can send more transfers than the sink can capture.
Source readyAllowance< Sink readyAllowance No adaptation required: After ready is deasserted, the source sends fewer transfers than the sink can capture.
Source readyLatency < SinkreadyLatency Source readyAllowance = Sink readyAllowance Adaptation required: The source can start sending transfers before sink can capture.
Source readyAllowance> Sink readyAllowance Adaptation required: The source can start sending transfers before the sink can capture. Also, after ready is deasserted, the source can send more transfers than the sink can capture.
Source readyAllowance < Sink readyAllowance Adaptation required: The source can start sending transfers before the sink can capture.
Level Two Title