Visible to Intel only — GUID: nik1412467948258
Ixiasoft
Visible to Intel only — GUID: nik1412467948258
Ixiasoft
3.14.8. Avalon® Memory-Mapped Interface Signal Roles
This specification does not require all signals to exist in an Avalon® -MM interface. There is no one signal that is always required. The minimum requirements for an Avalon® -MM 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® -MM interface:
Signal Role | Width | Direction | Required | Description |
---|---|---|---|---|
Fundamental Signals | ||||
address | 1 - 64 | Master → Slave | No | Masters: 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 master must use the byteenable signal. Refer to the addressUnits interface property for word addressing. Slaves: By default, the interconnect translates the byte address into a word address in the slave’s address space. From the perspective of the slave, each slave access is for a word of data. For example, address = 0 selects the first word of the slave. address = 1 selects the second word of the slave. Refer to the addressUnits interface property for byte addressing. |
byteenable byteenable_n |
2, 4, 8, 16, 32, 64, 128 | Master → Slave | 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 master 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 slave. During reads, byteenables indicate which bytes the master is reading. Slaves 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 | Master → Slave | No | When asserted, allows the Nios® II processor to write on-chip memories configured as ROMs. |
read read_n |
1 | Master → Slave | No | Asserted to indicate a read transfer. If present, readdata is required. |
readdata | 8, 16, 32, 64, 128, 256, 512, 1024 | Slave → Master | No | The readdata driven from the slave to the master in response to a read transfer. Required for interfaces that support reads. |
response [1:0] | 2 | Slave → Master | 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 | Master → Slave | No | Asserted to indicate a write transfer. If present, writedata is required. |
writedata | 8, 16, 32, 64, 128, 256, 512, 1024 | Master → Slave | 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 | Master → Slave | No | lock ensures that once a master wins arbitration, the winning master maintains access to the slave 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 master has been granted, that master retains grant until lock is deasserted. A master equipped with lock cannot be a burst master. Arbitration priority values for lock-equipped masters are ignored. lock is particularly useful for read-modify-write (RMW) operations. The typical read-modify-write operation includes the following steps:
lock prevents master B from performing a write between Master A’s read and write. |
waitrequest waitrequest_n |
1 | Slave → Master | No | A slave asserts waitrequest when unable to respond to a read or write request. Forces the master to wait until the interconnect is ready to proceed with the transfer. At the start of all transfers, a master initiates the transfer and waits until waitrequest is deasserted. A master must make no assumption about the assertion state of waitrequest when the master is idle: waitrequest may be high or low, depending on system properties. When waitrequest is asserted, master control signals to the slave must remain constant except for beginbursttransfer. For a timing diagram illustrating the beginbursttransfer signal, refer to the figure in Read Bursts. An Avalon® -MM slave may assert waitrequest during idle cycles. An Avalon® -MM master may initiate a transaction when waitrequest is asserted and wait for that signal to be deasserted. To avoid system lockup, a slave device should assert waitrequest when in reset. |
Pipeline Signals | ||||
readdatavalid readdatavalid_n |
1 | Slave → Master | 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. A slave may assert readdatavalid to transfer data to the master independently of whether the slave is stalling a new command with waitrequest. Required if the master supports pipelined reads. Bursting masters with read functionality must include the readdatavalid signal. |
writeresponsevalid | 1 | Slave → Master | 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. |
Burst Signals | ||||
burstcount | 1 – 11 | Master → Slave | No | Used by bursting masters 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 masters with read functionality must include the readdatavalid signal. For bursting masters and slaves 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 masters and slaves using word addresses, the log2 term above is omitted. |
beginbursttransfer | 1 | Interconnect → Slave | 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. A slave 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.
|