6.15.8. Avalon® Memory Mapped Interface Signal Roles

Intel® Quartus® Prime Pro Edition User Guide: Platform Designer

Download PDF

ID 683609

Date 4/02/2022

Version

Public

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

Visible to Intel only — GUID: nik1412467948258

Ixiasoft

View Details

6.15.8. 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 106. 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: Host A asserts lock and reads 32-bit data that has multiple bit fields. 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> + log₂(<symbols_per_word_of_interface>)` For bursting hosts and agents using word addresses, the `log₂` 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.

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

Intel® Quartus® Prime Pro Edition User Guide: Platform Designer

6.15.8. Avalon® Memory Mapped Interface Signal Roles