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:
| 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.
For read responses:
For 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:
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.
|