RTL Designs with AXIS Interfaces

Objective
● Understanding the AXI stream interface protocol
● Learning the implementation insights of AXIS interfaces
using Verilog/System Verilog

Assignment - 1
● Implement an 8-bit register with AXI stream interface on
both inputs and outputs
● Use only the DATA, VALID, READY, and LAST signals in
all the interfaces
● Verify its functionality using testbench in simulation.
Introduction to the module and its functionality

AXI, which means Advanced eXtensible Interface, is an interface

protocol defined by ARM as part of the AMBA (Advanced
Microcontroller Bus Architecture) standard.

The AXI-Stream protocol is a standard interface to exchange data

between connected components. AXI-Stream is a point-to-point
protocol, that connects a single Transmitter and a single Receiver. An
interconnect can be employed to provide connectivity between multiple
AXI-Stream components.

Here in this module we have chosen handshake signaling that mainly

operates with four signals, VALID, READY, DATA, and LAST.

Handshake signaling
This section gives details of the handshake signaling and defines the
relationship of the TVALID and TREADY signals. The TVALID and
TREADY handshake determines when information is passed across the
interface. A two-way flow control mechanism enables both the
Transmitter and Receiver to control the rate at which the data and
control information is transmitted across the interface. For a transfer to
occur, both TVALID and TREADY must be asserted. Either TVALID
or TREADY can be asserted first, or both can be asserted in the same
ACLK cycle. A Transmitter is not permitted to wait until TREADY is
asserted before asserting TVALID. Once TVALID is asserted, it must
remain asserted until the handshake occurs. A Receiver is permitted to
wait for TVALID to be asserted before asserting TREADY. It is
permitted that a Receiver asserts and deasserts TREADY without
TVALID being asserted. The following sections give examples of the
handshake sequence.
1. Handshake with TVALID asserted before TREADY
In Figure 1, the Transmitter presents the data and control
information and asserts TVALID as HIGH. The valid data bytes
and control information from the Transmitter must remain
unchanged once TVALID has been asserted by the Transmitter.
The Receiver can accept the data and control information once
TREADY is HIGH. The transfer takes place once the Receiver
asserts TREADY HIGH. Figure 1 shows the transfer occurs at T3.

Figure 1:
Handshake with
TVALID asserted
before TREADY

2. Handshake with TREADY asserted before TVALID

In Figure 2, the Receiver drives TREADY HIGH before the data
and control information is valid. This indicates the Receiver can
accept the data and control information in a single ACLK cycle. In
this case, the transfer occurs once the Transmitter drives TVALID
HIGH. Figure 2 shows the transfer occurring at T3.

Figure 2:
Handshake with
TREADY
asserted before
TVALID
 3. Handshake with TVALID and TREADY asserted simultaneously
In Figure 3, the Transmitter asserts TVALID HIGH and the
Receiver asserts TREADY HIGH in the same ACLK cycle. In this
case, the transfer takes place in the same cycle, as shown in T2 of
Figure 3.

Figure 3:
Handshake with
TVALID and
TREADY asserted
simultaneously

The TLAST when deasserted, indicates that another transfer can follow.
This means it is acceptable to delay the current transfer to upsize,
downsize, or merge. When asserted, TLAST can be used by a
destination to indicate a packet boundary and it indicates an efficient
point to make an arbitration change on a shared link.

It is not required that arbitration only occur on a TLAST boundary.

TLAST can be used to potentially improve efficiency by keeping
transfers in the same packet together. TLAST can be used to transmit
information between the source and destination. The number of packets
and the number of assertions of TLAST must be preserved between the
Transmitter and Receiver. No explicit signaling of the start of a packet
boundary is given in the protocol.
Finally, the DATA signal is the Data transmitted through this protocol.
In this particular assignment, an 8-bit register holds the data till valid
and ready asserted simultaneously. However, CLOCK and RESET
signals go with regular functionality.

Module Block Design

I/O Details:
Inputs
● [7:0] data
● valid
● ready
● last
● clk
● Reset

Outputs
● [7:0] out
● [3:0] frame_count

Implementation Approach

The implementation approach for the bit8_register module:

Functional Microarchitecture:
The module acts as an 8-bit register that captures input data (data) when
both the ready and valid signals are asserted. It holds the captured data
(out) until the next valid input arrives. Additionally, it keeps track of the
number of frames received (frame_count) based on the last signal.
FSMs (Finite State Machines):
The module does not explicitly use FSMs. However, it implicitly defines
two states:
State 1: Waiting for valid input (ready and valid not asserted)
State 2: Capturing and holding input data (ready and valid asserted)

Algorithms Chosen:
The algorithm chosen is straightforward:
On every positive clock edge, if the reset signal is asserted, the register
is cleared (out becomes 8'h00).
If ready and valid are both asserted, the incoming data is captured into
the out register.
The last signal indicates the end of a frame. When the last is asserted,
the frame_count is incremented by one.

Interface Choice:
The module uses a synchronous interface with the following signals:
data: Input data bus (8 bits) valid: Input data valid signal
ready: Output data ready signal last: Indicates the end of a frame
clk: Clock signal reset: Reset signal
out: Output data bus (8 bits) frame_count: Output frame count
(4 bits)

Pipeline Architecture:
The module does not employ a pipeline architecture. It operates on a
single clock cycle and processes input data when it becomes valid.

Overall, the bit8_register module is a simple register with additional

functionality to count the number of frames received based on the last
signal. It efficiently captures input data when both ready and valid are
asserted and updates the frame count accordingly.
Verification Approach

Test by Developer:
The test approach was a simple Test bench with data being assigned
randomly and control signals, or simply input signals are assigned in
different possible combinations.

Test Report:
Overall Test Statistics
Total number of test cases executed: 6
Total number of passed test cases: 6
Total number of failed test cases: 0

Test case - 1:
Reset is
inserted

Test case - 2:
Ready and
valid are
asserrted
Test case - 3: Ready is deasserted and valid is asserted
Test case - 4: Ready is asserted and valid is deasserted
Test case - 5: Last is asserted

Test case - 6:
Both ready
and valid are
deasserted
Performance Details

Schematic:
https://github.com/Yasshwanhya/FPGA-project/blob/main/ima.pdf

FPGA Resources Occupancy

Deliverables
Source code link:
https://github.com/Yasshwanhya/FPGA-
project/blob/main/mod2_assignment1

Testbench Link:
https://github.com/Yasshwanhya/FPGA-
project/blob/main/mod2_assignment1_tb

References

1. AMBA® AXI-Stream Protocol Specification pdf

2. https://support.xilinx.com/s/article/1053914?language=en_US
3. https://community.arm.com/arm-community-blogs/b/soc-design-
and-simulation-blog/posts/introduction-to-axi-protocol-
understanding-the-axi-interface