Managing Interfaces
Vivado HLS supports two solutions for specifying the type of I/O protocol used:
• Interface Synthesis, where the port interface is created based on efficient industry
standard interfaces.
• Manual interface specification where the interface behavior is explicitly described in
the input source code. This allows any arbitrary I/O protocol to be used.
Interface Synthesis
1 #include "sum_io.h" 2 dout_t sum_io(din_t in1, din_t in2, dio_t *sum) { 3 dout_t temp; 4 *sum = in1 + in2 + *sum; 5 temp = in1 + in2; 6 return 7 temp; 8 }
This example above includes:
• Two pass-by-value inputs in1 and in2.
• A pointer sum that is both read from and written to.
• A function return, the value of temp.
Vivado HLS creates three types of ports on the RTL design:
• Clock and Reset ports: ap_clk and ap_rst.
• Block-Level interface protocol. These are shown expanded in the preceding figure:
ap_start, ap_done, ap_ready, and ap_idle.
• Port Level interface protocols. These are created for each argument in the top-level
function and the function return (if the function returns a value). In this example, these
ports are: in1, in2, sum_i, sum_o, sum_o_ap_vld, and ap_return.
• The design starts when ap_start is asserted High.
• The ap_idle signal is asserted Low to indicate the design is operating.
• The input data is read at any clock after the first cycle. Vivado HLS schedules when the
reads occur. The ap_ready signal is asserted high when all inputs have been read.
• When output sum is calculated, the associated output handshake (sum_o_ap_vld)
indicates that the data is valid.
• When the function completes, ap_done is asserted. This also indicates that the data on
ap_return is valid.
• Port ap_idle is asserted High to indicate that the design is waiting start again.
Block-Level Interface Protocol
By default, a block-level interface protocol is added to the design. These signal control the
block, independently of any port-level I/O protocols. These ports control when the block
can start processing data (ap_start), indicate when it is ready to accept new inputs
(ap_ready) and indicate if the design is idle (ap_idle) or has completed operation
(ap_done).
Port-Level Interface Protocol
The final group of signals are the data ports. The I/O protocol created depends on the type
of C argument and on the default. After the block-level protocol has been used to start the operation of the
block, the port-level IO protocols are used to sequence data into and out of the block.
By default input pass-by-value arguments and pointers are implemented as simple wire
ports with no associated handshaking signal. In the above example, the input ports are
therefore implemented without an I/O protocol, only a data port. If the port has no I/O
protocol, (by default or by design) the input data must be held stable until it is read.
By default output pointers are implemented with an associated output valid signal to
indicate when the output data is valid. In the above example, the output port is
implemented with an associated output valid port (sum_o_ap_vld) which indicates when the
data on the port is valid and can be read. If there is no I/O protocol associated with the
output port, it is difficult to know when to read the data. It is always a good idea to use an
I/O protocol on an output.
Function arguments which are both read from and writes to are split into separate input and
output ports. In the above example, sum is implemented as input port sum_i and output
port sum_o with associated I/O protocol port sum_o_ap_vld.
If the function has a return value, an output port ap_return is implemented to provide the
return value. When the design completes one transaction - this is equivalent to one
execution of the C function - the block-level protocols indicate the function is complete
with the ap_done signal. This also indicates the data on port ap_return is valid and can
be read.
Interface Synthesis I/O Protocols
The type of interfaces that are created by interface synthesis depend on the type of C
argument, the default interface mode, and the INTERFACE optimization directive. The
following figure shows the interface protocol mode you can specify on each type of C
argument. This figure uses the following abbreviations:
•D: Default interface mode for each type.
• I: Input arguments, which are only read.
• O: Output arguments, which are only written to.
• I/O: Input/Output arguments, which are both read and written.
Block-Level Interface Protocols
Port-Level Interface Protocols: AXI4 Interfaces
Port-Level Interface Protocols: No I/O Protocol
Port-Level Interface Protocols: Wire Handshakes
Port-Level Interface Protocols: Memory Interfaces
Interface Synthesis and Multi-Access Pointers
How AXI Works
• Productivity: By standardizing on the AXI interface, developers need to learn only a single protocol for IP.
• Flexibility: Providing the right protocol for the application:
°AXI4 is for memory-mapped interfaces and allows high throughput bursts of up to
256 data transfer cycles with just a single address phase.
°AXI4-Lite is a light-weight, single transaction memory-mapped interface. It has a
small logic footprint and is a simple interface to work with both in design and usage.
°AXI4-Stream removes the requirement for an address phase altogether and allows
unlimited data burst size. AXI4-Stream interfaces and transfers do not have address
phases and are therefore not considered to be memory-mapped.
•Availability: By moving to an industry-standard, you have access not only to the Vivado IP Catalog, but also to a worldwide community of ARM partners.
°Many IP providers support the AXI protocol.
The AXI specifications describe an interface between a single AXI master and AXI slave,
representing IP cores that exchange information with each other. Multiple memory-mapped
AXI masters and slaves can be connected together using AXI infrastructure IP blocks.
The AXI Interconnect is architected using a traditional, monolithic crossbar approach;
Both AXI4 and AXI4-Lite interfaces consist of five different channels:
• Read Address Channel
• Write Address Channel
• Read Data Channel
• Write Data Channel
• Write Response Channel
Data can move in both directions between the master and slave simultaneously, and data
transfer sizes can vary. The limit in AXI4 is a burst transaction of up to 256 data transfers.
AXI4-Lite allows only one data transfer per transaction.
AXI4:
• Provides separate data and address connections for reads and writes, which allows
simultaneous, bidirectional data transfer.
• Requires a single address and then bursts up to 256 words of data.
The AXI4 protocol describes options that allow AXI4-compliant systems to achieve very
high data throughput. Some of these features, in addition to bursting, are: data upsizing
and downsizing, multiple outstanding addresses, and out-of-order transaction processing.
At a hardware level, AXI4 allows systems to be built with a different clock for each AXI
master-slave pair. In addition, the AXI4 protocol allows the insertion of register slices (often
called pipeline stages) to aid in timing closure.
AXI4-Lite is similar to AXI4 with some exceptions: The most notable exception is that
bursting is not supported.
The AXI4-Stream protocol defines a single channel for transmission of streaming data. The
AXI4-Stream channel models the write data channel of AXI4. Unlike AXI4, AXI4-Stream
interfaces can burst an unlimited amount of data.You can split, merge, interleave, upsize, and downsize AXI4-Stream
compliant interfaces.
•Memory-Mapped Protocols: In memory-mapped protocols (AXI3, AXI4, and
AXI4-Lite), all transactions involve the concept of transferring a target address within a
system memory space and data.
Memory-mapped systems often provide a more homogeneous way to view the system,
because the IP operates around a defined memory map.
•AXI4-Stream Protocol: Use the AXI4-Stream protocol for applications that typically
focus on a data-centric and data-flow paradigm where the concept of an address is not
present or not required. Each AXI4-Stream acts as a single unidirectional channel with a
handshaking data flow.
At this lower level of operation (compared to the memory-mapped protocol types), the
mechanism to move data between IP is defined and efficient, but there is no unifying
address context between IP. The AXI4-Stream IP can be better optimized for
performance in data flow applications, but also tends to be more specialized around a
given application space.
•Infrastructure IP: An infrastructure IP is a building block used to help assemble
systems. Infrastructure IP tends to be a generic IP that moves or transforms data
around the system using general-purpose AXI4 interfaces and does not interpret data.
Examples of infrastructure IP are:
° AXI Register slices (for pipelining)
° AXI FIFOs (for buffering/clock conversion)
° AXI Interconnect IP and AXI SmartConnect IP (for connecting memory-mapped IP
together)
° AXI Direct Memory Access (DMA) engines (for memory-mapped to stream
conversion)
° AXI Performance Monitors and Protocol Checkers (for analysis and debug)
° AXI Verification IP (for simulation-based verification and performance analysis)
These IP are useful for connecting IP together into a system, but are not generally
endpoints for data.
Using AXI4 Interfaces
AXI4-Stream Interfaces
An AXI4-Stream interface can be applied to any input argument and any array or pointer
output argument. Since an AXI4-Stream interface transfers data in a sequential streaming
manner it cannot be used with arguments which are both read and written. An AXI4-Stream
interface is always sign-extended to the next byte. For example, a 12-bit data value is sign-extended to 16-bit.
There are two basic ways to use an AXI4-Stream in your design.
• Use an AXI4-Stream without side-channels.
• Use an AXI4-Stream with side-channels.
This second use model provides additional functionality, allowing the optional
side-channels which are part of the AXI4-Stream standard, to be used directly in the C code.
AXI4-Stream Interfaces without Side-Channels
An AXI4-Stream is used without side-channels when the function argument does not
contain any AXI4 side-channel elements.
1 void example(int A[50], int B[50]) { 2 //Set the HLS native interface types 3 #pragma HLS INTERFACE axis port=A 4 #pragma HLS INTERFACE axis port=B 5 int i; 6 for(i = 0; i < 50; i++){ 7 B[i] = A[i] + 5; 8 } 9 }
AXI4-Stream Interfaces with Side-Channels
Side-channels are optional signals which are part of the AXI4-Stream standard. The
side-channel signals may be directly referenced and controlled in the C code using a struct,
provided the member elements of the struct match the names of the AXI4-Stream side-channel signals.
An example of this is provided with Vivado
HLS. The Vivado HLS include directory contains the file ap_axi_sdata.h. This header
file contains the following structs:
1 #include "ap_int.h" 2 template<int D,int U,int TI,int TD> 3 struct ap_axis{ 4 ap_int<D> 5 data; 6 ap_uint<D/8> keep; 7 ap_uint<D/8> strb; 8 ap_uint<U> 9 user; 10 ap_uint<1> 11 last; 12 ap_uint<TI> id; 13 ap_uint<TD> dest; 14 }; 15 template<int D,int U,int TI,int TD> 16 struct ap_axiu{ 17 ap_uint<D> 18 data; 19 ap_uint<D/8> keep; 20 ap_uint<D/8> strb; 21 ap_uint<U> 22 user; 23 ap_uint<1> 24 last; 25 ap_uint<TI> id; 26 ap_uint<TD> dest; 27 };
The following example shows how the side-channels can be used directly in the C code and
implemented on the interface. In this example a signed 32-bit data type is used.
1 #include "ap_axi_sdata.h" 2 void example(ap_axis<32,2,5,6> A[50], ap_axis<32,2,5,6> B[50]){ 3 //Map ports to Vivado HLS interfaces 4 #pragma HLS INTERFACE axis port=A 5 #pragma HLS INTERFACE axis port=B 6 int i; 7 for(i = 0; i < 50; i++){ 8 B[i].data = A[i].data.to_int() + 5; 9 B[i].keep = A[i].keep; 10 B[i].strb = A[i].strb; 11 B[i].user = A[i].user; 12 B[i].last = A[i].last; 13 B[i].id = A[i].id; 14 B[i].dest = A[i].dest; 15 } 16 }
AXI4-Lite Interface
You can use an AXI4-Lite interface to allow the design to be controlled by a CPU or
microcontroller. Using the Vivado HLS AXI4-Lite interface, you can:
• Group multiple ports into the same AXI4-Lite interface.
• Output C driver files for use with the code running on a processor.
The following example shows how Vivado HLS implements multiple arguments, including
the function return, as an AXI4-Lite interface. Because each directive uses the same name
for the bundle option, each of the ports is grouped into the same AXI4-Lite interface.
1 void example(char *a, 2 { 3 #pragma HLS INTERFACE 4 #pragma HLS INTERFACE 5 #pragma HLS INTERFACE 6 #pragma HLS INTERFACE 7 #pragma HLS INTERFACE 8 char *b, char *c) 9 s_axilite port=return 10 s_axilite port=a 11 s_axilite port=b 12 s_axilite port=c 13 ap_vld port=b 14 bundle=BUS_A 15 bundle=BUS_A 16 bundle=BUS_A 17 bundle=BUS_A offset=0x0400 18 *c += *a + *b; 19 }
By default, Vivado HLS automatically assigns the address for each port that is grouped into
an AXI4-Lite interface. Vivado HLS provides the assigned addresses in the C driver files. To explicitly define the address, you can use the
offset option, as shown for argument c in the example above.
After synthesis, Vivado HLS implements the ports in the AXI4-Lite port, as shown in the
following figure. Vivado HLS creates the interrupt port by including the function return in
the AXI4-Lite interface. You can program the interrupt through the AXI4-Lite interface. You
can also drive the interrupt from the following block-level protocols:
• ap_done: Indicates when the function completes all operations.
• ap_ready: Indicates when the function is ready for new input data.
Control Clock and Reset in AXI4-Lite Interfaces
By default, Vivado HLS uses the same clock for the AXI4-Lite interface and the synthesized
design. Vivado HLS connects all registers in the AXI4-Lite interface to the clock used for the
synthesized logic (ap_clk).
Optionally, you can use the INTERFACE directive clock option to specify a separate clock
for each AXI4-Lite port.
- RECOMMENDED: For ease of use during the operation of the design, Xilinx recommends that you do not include additional I/O protocols in the ports grouped into an AXI4-Lite interface. However, Xilinx recommends that you include the block-level I/O protocol associated with the return port in the AXI4-Lite interface.
- IMPORTANT: In an AXI4-Lite interface, Vivado HLS reserves addresses 0x0000 through 0x000C for the block-level I/O protocol signals and interrupt controls.
AXI4 Master Interface
Controlling AXI4 Burst Behavior
Creating an AXI4 Interface with 64-bit Address Capability
Controlling the Address Offset in an AXI4 Interface
Reference
1. Xinlinx UG902
2. Xilinx UG1037, Vivado Design Suite AXI Reference Guide