| Copyright © 2011-2012 ARM. All rights reserved. | ARM DDI 0480B |
| Non-Confidential | ID042612 |
 PDF version | |
| Home > Debug Access Port > AXI-AP > AXI-AP functionality |
| |||
| Home > Debug Access Port > AXI-AP > AXI-AP functionality | |||
The following sections describe the AXI-AP functionality:
On AXI-AP reset, the entire AXI-AP module is reset and the transaction history is lost.
ARM recommends that reset must not be asserted while AXI transfer is ongoing, however AXI-AP permits reset to be asserted with the understanding that all transaction history is lost.
On DAP transfer abort, the AXI-AP asserts DAPREADY one cycle after DAPABORT. The DAP transfer abort does not cancel the ongoing AXI transfer.
This section describes the following:
An error response received on the AXI master interface propagates onto the DAP bus as the transfer is completed.
In case of a 64-bit data transfer, a sequence of two reads or writes must be generated on the DAP I/F for a single 64-bit access on the AXI interface. In case of reads, the first read request on DAP I/F sends a read request on the AXI interface while in case of writes, a write access is sent on the AXI interface only after two write requests are received on the DAP I/F.
Therefore, error response received for a read request is for the first read request on DAP I/F while error response received for a write request is for the second write request on the DAP I/F.
After a DAPABORT operation is carried out, and an external transfer is still pending, that is, the transfer in progress bit remains HIGH, all writes to the AXI-AP return an error response and you can ignore it.
AXI-AP writes return an error until the transfer in progress, the TrInProg bit, is cleared when the system transfer completes.
Read requests from DAP I/F must access both the BDx registers of the pair, with the lower numbered register accessed first. For a DRW, it must access it twice to get the entire 64-bit word from AXI interface.
All other accesses such as a read followed by write access to the same or different register, return an error response by asserting DAPSLVERR.
Write requests from DAP I/F must access both the BDx registers of the pair with the lower numbered register accessed first. For a DRW, it must access twice to build a 64-bit packet as write data on the AXI interface.
All other accesses such as a write followed by another R/W access to different register, return an error response.
For example, after accessing DRW, the next access on DAP I/F must be a write to DRW, any other access returns an error response.
Similarly, after accessing BD0, the next access must be a write to BD1, any other access returns an error response.
It is possible to abort a barrier transaction that
has not yet completed. When the abort request is generated, the DAPREADY is asserted HIGH in the next
cycle. However CSW.TrInPrg bit
remains set to indicate the AXI-Interface is busy waiting to complete
the transaction. While the AXI-Interface is busy, a R/W request
to DRW or BDx registers that results
in a transaction on the AXI interface, causes the AXI-AP to return
an error response by asserting DAPSLVERR.
If DAPSLVERR is HIGH and TrInProg is LOW in the CSW Register, the error is from either:
a system error response if registered versions of DBGEN and SPIDEN permit the transfer to be initiated
an AXI-AP error response if registered versions of DBGEN and SPIDEN do not permit the transfer.
Table 4.6. Difference between AXI and AP initiated error response
| Sprot | SPIDEN_registered | DBGEN | Error response from | Reason |
|---|---|---|---|---|
| X | X | 0 | AXI-AP | All transfers blocked |
| 0 | 0 | 1 | AXI-AP | Secure transfers blocked |
| 0 | 1 | 1 | System | Secure transfer produced an error response |
| 1 | X | 1 | System | Non secure transfer produced an error response |
If DAPSLVERR is HIGH and TrInProg is HIGH, then the error is from an access port error response. This case can only occur after the initiation of an abort and the system transfer has not completed.
Table 4.7 shows the implemented features.
Table 4.7. AXI-AP features at a glance
| Feature | Comment |
|---|---|
| AXI4 interface support | - |
| Auto-incrementing TAR | - |
| Stalling accesses | - |
| Access size | 8, 16, 32, or 64 bits. |
| Endianness | Little-endian. |
| Error response | - |
| Packed transfers | - |
| ROM table pointer register | - |
| Long address support | - |
| AXI transfers | Write, read transfers. |
| Burst size of 1 only. | |
| No out-of-order transactions. | |
| No multiple outstanding accesses. | |
| Only aligned transfers are supported. | |
| ACE-Lite | Limited set of commands to support coherency in the system. |
| All transactions to non-shareable memory regions. | |
| Limited subset of transactions to shareable memory regions. | |
| For reads only. The Read-once is supported. | |
| For writes only. The Write-unique is supported. | |
| Barrier transactions |
The AMBA4 AXI compliant Master Port supports the following features:
bursts of single transfer
masters processes one transaction at a time in the order they are issued.
no out-of-order transactions
no issuing of multiple outstanding addresses.
The AXI-AP supports burst length of one transfer
only ARLEN[3:0] and AWLEN[3:0] are always 4’b0000.
Packed 8 or 16-bit transfers are treated as individual burst length of one transfer at the AXI interface. This ensures that there are no issues with boundary wrapping to avoid additional AXI-AP complexity.
Supported burst sizes are:
8-bit
16-bit
32-bit
64-bit.
ARBURST or AWBURST is
always 2’b00.
Because only bursts of one transfer are supported, burst type has no meaning in this context.
AXI-AP supports normal accesses only.
ARLOCK[1:0] and AWLOCK[1:0] signals are always 2’b00.
Unaligned accesses are not supported. Depending on the size of the transfers, addresses must be aligned.
for 16-bit half word transfers:
base
address 0x01 is aligned and AxADDR[7:0] = 0x00
base address 0x02 is retained
and AxADDR[7:0] = 0x02
for 32-bit word transfers:
base address 0x01 to 0x03 is
aligned and AxADDR[7:0] = 0x00
base address 0x04 is retained
and AxADDR[7:0] = 0x04
for 64-bit word transfers:
base address 0x04 is aligned and AxADDR[7:0] = 0x00
base address 0x08 is retained
and AxADDR[7:0] = 0x08
For example, for 16-bit transfers address must be aligned to 16-bit half word boundary, for 32-bit word transfer, address must be word aligned and for 64-bit double word transfer, address must be double word aligned.
32-bit Transactions:
The DAP internal interface is a 32-bit data bus, however 8-bit
or 16-bit transfers can be formed on AXI according to the size field
in the CSW register, 0x000. The AddrInc field
in the CSW Register permits optimized use of the DAP internal bus
to reduce the number of accesses to the DAP. It indicates if the
entire data word can be used to pack more than one transfer. If
packed transfers are initiated, then the address incrementing is
automatically enabled. Multiple transfers are carried out in sequential
addresses, with the size of the address increment based on the size of
the transfer.
An example of the transactions are:
For an unpacked 16-bit write to base address of base 0x2,
that is, CSW[2:0]=0b001, CSW[5:4]=0b01, WDATA[31:16] is written from bits [31:16]
in the DRW register.
For an unpacked 8-bit read to base address of base 0x1,
that is, CSW[2:0]=0b000, CSW[5:4]=0b01, RDATA[31:16] and RDATA[7:0] are
zero, RDATA[15:8] contains read
data.
For a packed byte write at base address of base 0x2,
that is, CSW[2:0]=0b000 and CSW[5:4]=0b10,
four write transfers are initiated, and the order of data being
sent is:
WDATA[23:16], from DRW[23:16] to AWADDR[31:0]=0x00000002
WDATA[31:24],
from DRW[31:24] to AWADDR[31:0]=0x00000003
WDATA[7:0], from DRW[7:0] to AWADDR[31:0]=0x00000004
WDATA[15:8],
from DRW[15:8] to AWADDR[31:0]=0x00000005.
For a packed half word reading at a base address of base 0x2,
that is, CSW[2:0]=0b001, CSW[5:4]=0b10,
two read transfers are initiated:
RDATA[31:16] is stored into DRW[31:16] from ARADDR[31:0]=0x00000002
RDATA[15:0] is
stored into DRW[15:0] from ARADDR[31:0]=0x00000004.
The AXI-AP only asserts DAPREADY HIGH when all packed transfers from the AXI interface have completed.
If the current transfer is aborted or the current transfer receives an ERROR response, the AXI-AP does not complete the following packed transfers and returns DAPREADY HIGH immediately after the current packed transfer.
Table 4.8 shows the valid combinations of AxCACHE and AxDOMAIN.
Table 4.8. Valid combination of AxCACHE and AxDOMAIN values
| AxCACHE | Access Type | AxDOMAIN | Domain Type | Valid |
|---|---|---|---|---|
0000 | Device | 00 | Non-shareable | NO |
0001 | 01 | Inner-shareable | NO | |
10 | Outer-shareable | NO | ||
11 | System | YES | ||
0010 | Non-Cacheable | 00 | Non-shareable | Enabled |
0011 | 01 | Inner-shareable | Enabled | |
10 | Outer-shareable | Enabled | ||
11 | System | YES | ||
010x | - | - | - | NO |
100x | - | - | - | |
110x | - | - | - | |
011x | Write | 00 | Non-shareable | YES |
101x | Through | 01 | Inner-shareable | YES |
111x | Write | 10 | Outer-shareable | YES |
| Back | 11 | System | NO |
| Copyright © 2011-2012 ARM. All rights reserved. | ARM DDI 0480B |
| Non-Confidential | ID042612 |
| PDF version | |
| Home > Debug Access Port > AXI-AP > AXI-AP functionality |