Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial axi4 lite support #1

Merged
merged 8 commits into from
Jan 3, 2021
Merged

initial axi4 lite support #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
a838822
cleanup and renaming
hansemandse Dec 3, 2020
f4482d9
update with package object
hansemandse Dec 4, 2020
04ebb1f
more clean up
hansemandse Dec 4, 2020
01ec8a6
add default values
hansemandse Dec 5, 2020
40fe6e0
refactor master
hansemandse Dec 11, 2020
33b0000
update package
hansemandse Dec 11, 2020
e0a3c22
add axi4 lite support
hansemandse Jan 3, 2021
3e7f229
update readme
hansemandse Jan 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions axi4/.gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
# Ignore metals-related temp files
.bloop/
.ionide/
.metals/
.vscode/
project/.bloop/
Expand Down
197 changes: 97 additions & 100 deletions axi4/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,100 +1,97 @@
# Verification of AMBA AXI Interfaced Components
This project focuses on implementation of AXI4 master interface definitions and a small framework providing support for all of the defined transactions from the AXI master's point of view in the protocol.

### Extras
- Functional AXI slave (like above)
- Concurrent interfaces
- AXI Lite interface
- AXI Stream interface (see [here](https://developer.arm.com/documentation/ihi0051/latest/))

## Documentation
The AXI protocol defines five independent channels for reads and writes as listed below. As they are independent, read/write addresses may be transferred to a slave ahead of transferring the data. So-called _transactions_ consist of one or more _tranfers_ across a set of channels. Data is transferred in _bursts_ which consist of one or more _beats_. The protocol also supports multiple outstanding transactions and out-of-order completion by using tagged packets. All channels use simple decoupled ready-valid signalling.

### Channels
The following channels are defined in the AXI4 protocol. ID fields are partly optional in that they do not have to be unique as the interconnect must append master numbers to them to ensure correct operation.
- _Write address channel_ used to initiate a write transaction from master to slave. A transfer contains ID, address, burst length, burst type, cacheability etc. (see page A2-29)
- `AWID [_:0]` ID field
- `AWADDR [_:0]` start address of a write transaction
- `AWLEN [7:0]` number of beats in the burst
- `AWSIZE [2:0]` beat size encoding, i.e. number of bytes per beat is 2^AWSIZE
- `AWBURST [1:0]` one of _FIXED_, _INCR_, or _WRAP_
- `AWLOCK`, `AWCACHE [3:0]`, `AWPROT [2:0]`, and `AWQOS [3:0]` control data protection and quality of service
- _Optional_ `AWREGION [3:0]` allows sharing of a single physical interface for multiple logical regions
- _Optional_ `AWUSER [_:0]`
- `AWREADY` and `AWVALID` handshake signals

- _Write data channel_ used to transfer write data from master to slave. A transfer contains ID, data, byte-wide write enable etc. (see page A2-30)
- `WDATA [_:0]` write data
- `WSTRB [_:0]` write strobe (i.e. one bit per byte of data)
- `WLAST` indicates whether this is the last beat in a burst
- _Optional_ `WUSER [_:0]`
- `WREADY` and `WVALID` handshake signals

- _Write response channel_ used to inform a master about the completion of a write transaction. A transfer contains ID, write status etc. (see page A2-31)
- `BID [_:0]` ID field
- `BRESP [1:0]` write response from the slave; i.e. one of _OKAY_, _EXOKAY_, _SLVERR_, or _DECERR_
- _Optional_ `BUSER`
- `BREADY` and `BVALID` handshake signals

- _Read address channel_ used to initiate a read transaction from slave to master. A transfer contains ID, address, burst length, burst type, cacheability etc. (see page A2-32)
- `ARID [_:0]` ID field
- `ARADDR [_:0]` start address of a read transaction
- `ARLEN [7:0]` number of beats in the burst
- `ARSIZE [2:0]` beat size encoding
- `ARBURST [1:0]` one of _FIXED_, _INCR_, or _WRAP_
- `ARLOCK`, `ARCACHE [3:0]`, `ARPROT [2:0]`, and `ARQOS [3:0]` control data protection and quality of service
- _Optional_ `ARREGION [3:0]` allows sharing of a single physical interface for multiple logical regions
- _Optional_ `ARUSER [_:0]`
- `ARREADY` and `ARVALID` handshake signals

- _Read data channel_ used to transfer read data from slave to master. A transfer contains ID, data etc. (see page A2-33)
- `RID [_:0]` ID field
- `RDATA [_:0]` read data
- `RRESP [1:0]` read response from the slave
- `RLAST` indicates whether this is the last beat in a burst
- _Optional_ `RUSER [_:0]`
- `RREADY` and `RVALID` handshake signals

Additionally, two global signals are used (see page A2-28)
- `ACLK` a shared global clock signal
- `ARESETn` a shared global active-low reset signal

Channel descriptions are available in `./src/main/scala/axi4/Defs.scala`. DUVs must conform to the signal names and interfaces provided to function correctly - hence, their IO should extend either the available master or slave interfaces. To enable this more easily, an AXI master can simply extend the Master class found in `./src/main/scala/axi4/Master.scala`, and vice-versa for AXI slaves for which the relevant class is found in `./src/main/scala/axi4/Slave.scala`.

An example of a black-boxed block-RAM with AXI interface is provided in `./src/main/scala/VivadoAXIMemory.scala` - note, however, that due to copyright of the IP source code, you will need to generate the appropriate IP block within Xilinx Vivado to use the blackbox. A basic tester is provided in `./src/test/scala/VivadoAXIMemoryTester.scala`.

### References
The full public protocol specification is available from ARM [here](https://developer.arm.com/documentation/ihi0022/e/) and in PDF format [here](http://www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf). A good video introduction is available from [ARM's YouTube channel](https://www.youtube.com/watch?v=7Vl9JrGgNwk).

## Notes
The following are taken from the specification.

### Regarding ready-valid interface
- No combinational logic between `Ready` and `Valid` in neither master nor slave components
- A source _may not_ wait until `Ready` is asserted before asserting `Valid`
- A destination _may_ wait until `Valid` is asserted before asserting `Ready`
- Once asserted, `Valid` _must_ remain asserted until a handshake occurs
- If `Ready` is asserted, it _can_ be deasserted before assertion of `Valid`
- Transfers occur at the first rising edge after both `Ready` and `Valid` are asserted
- Address channels _should_ per default have `AWREADY` and `ARREADY` asserted to avoid transfers taking at least two cycles

### Regarding channel relationships
- A write response must always follow the last write transfer in a write transaction
- Read data must always follow the address to which it the data relates
- Write data _can_ appear before or simultaneously with the write address for the transaction

### Regarding transactions
- Bursts _must not_ cross a 4KB boundary (to avoid device address space mapping issues)
- Burst length is in \[1, 256\] for burst type INCR; for all other burst types it is in \[1, 16\]
- Bursts _must_ be completed (i.e. no support for early termination)
- Beat size _must not_ exceed the data bus width of neither the master nor the slave.
- Narrow transfers (i.e. transfers using a subsection of the data bus) are implemented using `WSTRB`
- Byte invariance means that some transfers can be little endian while others can be big endian
- Unaligned transfers are indicated either with the low-order address bits or using `WSTRB`
- Only one response is returned for write transactions, whereas a different response may be returned for each beat in a read transaction - and the entire transaction _must_ be completed regardless of potential errors
- Asserting `AxCACHE[1]` means that a transaction is _modifiable_ and can, for example, be broken down into multiple transactions, combined with other transactions, or fetch more data than requested
- Transaction ordering must be preserved for non-modifiable transactions with the same ID to the same slave (see pages A4-63 to A4-64)

### Regarding multiple transactions
- The ID signals can be used to identify separate transactions that must be returned in order
- AXI4 does _not_ support write data interleaving
# Verification of AMBA AXI Interfaced Components
This project focuses on implementation of AXI4 master interface definitions and a small framework providing support for all of the defined transactions from the AXI master's point of view in the protocol.

## TODO
- AXI Stream interface (see [here](https://developer.arm.com/documentation/ihi0051/latest/))

## Documentation
The AXI protocol defines five independent channels for reads and writes as listed below. As they are independent, read/write addresses may be transferred to a slave ahead of transferring the data. So-called _transactions_ consist of one or more _tranfers_ across a set of channels. Data is transferred in _bursts_ which consist of one or more _beats_. The protocol also supports multiple outstanding transactions and out-of-order completion by using tagged packets. All channels use simple decoupled ready-valid signalling.

### Channels
The following channels are defined in the AXI4 protocol. ID fields are partly optional in that they do not have to be unique as the interconnect must append master numbers to them to ensure correct operation.
- _Write address channel_ used to initiate a write transaction from master to slave. A transfer contains ID, address, burst length, burst type, cacheability etc. (see page A2-29)
- `AWID [_:0]` ID field
- `AWADDR [_:0]` start address of a write transaction
- `AWLEN [7:0]` number of beats in the burst
- `AWSIZE [2:0]` beat size encoding, i.e. number of bytes per beat is 2^AWSIZE
- `AWBURST [1:0]` one of _FIXED_, _INCR_, or _WRAP_
- `AWLOCK`, `AWCACHE [3:0]`, `AWPROT [2:0]`, and `AWQOS [3:0]` control data protection and quality of service
- _Optional_ `AWREGION [3:0]` allows sharing of a single physical interface for multiple logical regions
- _Optional_ `AWUSER [_:0]`
- `AWREADY` and `AWVALID` handshake signals

- _Write data channel_ used to transfer write data from master to slave. A transfer contains ID, data, byte-wide write enable etc. (see page A2-30)
- `WDATA [_:0]` write data
- `WSTRB [_:0]` write strobe (i.e. one bit per byte of data)
- `WLAST` indicates whether this is the last beat in a burst
- _Optional_ `WUSER [_:0]`
- `WREADY` and `WVALID` handshake signals

- _Write response channel_ used to inform a master about the completion of a write transaction. A transfer contains ID, write status etc. (see page A2-31)
- `BID [_:0]` ID field
- `BRESP [1:0]` write response from the slave; i.e. one of _OKAY_, _EXOKAY_, _SLVERR_, or _DECERR_
- _Optional_ `BUSER`
- `BREADY` and `BVALID` handshake signals

- _Read address channel_ used to initiate a read transaction from slave to master. A transfer contains ID, address, burst length, burst type, cacheability etc. (see page A2-32)
- `ARID [_:0]` ID field
- `ARADDR [_:0]` start address of a read transaction
- `ARLEN [7:0]` number of beats in the burst
- `ARSIZE [2:0]` beat size encoding
- `ARBURST [1:0]` one of _FIXED_, _INCR_, or _WRAP_
- `ARLOCK`, `ARCACHE [3:0]`, `ARPROT [2:0]`, and `ARQOS [3:0]` control data protection and quality of service
- _Optional_ `ARREGION [3:0]` allows sharing of a single physical interface for multiple logical regions
- _Optional_ `ARUSER [_:0]`
- `ARREADY` and `ARVALID` handshake signals

- _Read data channel_ used to transfer read data from slave to master. A transfer contains ID, data etc. (see page A2-33)
- `RID [_:0]` ID field
- `RDATA [_:0]` read data
- `RRESP [1:0]` read response from the slave
- `RLAST` indicates whether this is the last beat in a burst
- _Optional_ `RUSER [_:0]`
- `RREADY` and `RVALID` handshake signals

Additionally, two global signals are used (see page A2-28)
- `ACLK` a shared global clock signal
- `ARESETn` a shared global active-low reset signal

Channel descriptions are available in `./src/main/scala/axi4/Defs.scala`. DUVs must conform to the signal names and interfaces provided to function correctly - hence, their IO should extend either the available master or slave interfaces. To enable this more easily, an AXI master can simply extend the Master class found in `./src/main/scala/axi4/Master.scala`, and vice-versa for AXI slaves for which the relevant class is found in `./src/main/scala/axi4/Slave.scala`.

An example of a black-boxed block-RAM with AXI interface is provided in `./src/main/scala/VivadoAXIMemory.scala` - note, however, that due to copyright of the IP source code, you will need to generate the appropriate IP block within Xilinx Vivado to use the blackbox. A basic tester is provided in `./src/test/scala/VivadoAXIMemoryTester.scala`.

### References
The full public protocol specification is available from ARM [here](https://developer.arm.com/documentation/ihi0022/e/) and in PDF format [here](http://www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf). A good video introduction is available from [ARM's YouTube channel](https://www.youtube.com/watch?v=7Vl9JrGgNwk).

## Notes
The following are taken from the specification.

### Regarding ready-valid interface
- No combinational logic between `Ready` and `Valid` in neither master nor slave components
- A source _may not_ wait until `Ready` is asserted before asserting `Valid`
- A destination _may_ wait until `Valid` is asserted before asserting `Ready`
- Once asserted, `Valid` _must_ remain asserted until a handshake occurs
- If `Ready` is asserted, it _can_ be deasserted before assertion of `Valid`
- Transfers occur at the first rising edge after both `Ready` and `Valid` are asserted
- Address channels _should_ per default have `AWREADY` and `ARREADY` asserted to avoid transfers taking at least two cycles

### Regarding channel relationships
- A write response must always follow the last write transfer in a write transaction
- Read data must always follow the address to which it the data relates
- Write data _can_ appear before or simultaneously with the write address for the transaction

### Regarding transactions
- Bursts _must not_ cross a 4KB boundary (to avoid device address space mapping issues)
- Burst length is in \[1, 256\] for burst type INCR; for all other burst types it is in \[1, 16\]
- Bursts _must_ be completed (i.e. no support for early termination)
- Beat size _must not_ exceed the data bus width of neither the master nor the slave.
- Narrow transfers (i.e. transfers using a subsection of the data bus) are implemented using `WSTRB`
- Byte invariance means that some transfers can be little endian while others can be big endian
- Unaligned transfers are indicated either with the low-order address bits or using `WSTRB`
- Only one response is returned for write transactions, whereas a different response may be returned for each beat in a read transaction - and the entire transaction _must_ be completed regardless of potential errors
- Asserting `AxCACHE[1]` means that a transaction is _modifiable_ and can, for example, be broken down into multiple transactions, combined with other transactions, or fetch more data than requested
- Transaction ordering must be preserved for non-modifiable transactions with the same ID to the same slave (see pages A4-63 to A4-64)

### Regarding multiple transactions
- The ID signals can be used to identify separate transactions that must be returned in order
- AXI4 does _not_ support write data interleaving
Loading