Standard IP Interfaces
This document describes the standard set of interfaces used by NetFPGA-10G platform IP.
Version: 0.6
AMBA 4 AXI4-Stream Protocol Specification v 1.0
UG761 AXI Reference Guide
Use of interface standards is essential to the platform's goal of enabling rapid prototyping of networking applications. It increases IP interoperability, and therefore IP reuse. Developers are strongly encouraged to employ these interfaces whenever possible.
The NetFPGA-10G platform's standard interfaces themselves strictly adhere to a widely used interface standard released originally by ARM called AXI4, and later refined by Xilinx. The language used in this document to describe the platform's standard interfaces is inherited from these documents. Readers are encouraged to read the AMBA AXI4-Stream Protocol Specification which defines the original standard, as well as the Xilinx AXI Streaming Protocol Specification which places some restrictions on the original AMBA AXI4-Stream Specification for Xilinx applications (staying within the bounds of the original AMBA AXI4-Stream Spec).
We currently specify and support the following set of interfaces:
-
Control & status interface: We use the Xilinx standardized AXI4 lite interface which is derived from the AMBA4 bus specification
-
Data path interface: We use the Xilinx AXI4 streaming interface (contiguous and aligned strobes) which is derived from the AMBA4 bus specification. We use specific default settings for different type of bandwidth requirements and added conventions for the transport of packet meta data. This is described in more detail below.
We suggest that for debug 32bit vectors of type out are added to the modules (named "debug"). These can then be connected on the top level to LEDs or Chipscope pcores.
Background material on AXI4 interfaces can be found at:
http://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf
We use an AXI4 lite protocol which is a simple read/write interface, single beat access, with 32bit address and 32bit data. It is basically implemented through 5 FIFO channels: read data, read address, write data, write address and write response. Components inside the FPGA design with AXI lite interface can be connected to the AXI4 lite interconnect in which all peripherals reside within a flat address space. Both PCIe and micorblaze act as masters on this interconnect and can write and read all peripherals. Addresses can be assigned manually, however EDK can automatically create an address map for all peripherals connected to this control/status network.
AXI lite interface signals:
Channel **Signal ** **Status ** **Description **
write address AWADDR required write address - see AXI spec.
AWVALID required write address valid - see AXI spec.
AWREADY required
write address flow control - see AXI spec
write data WDATA required write data - see AXI spec
WSTRB required write data byte strobe - see AXI spec
WVALID required write data valid - see AXI spec
WREADY required write data flow control - see AXI spec
write response BRESP required write response - see AXI spec
BVALID required write response valid - see AXI spec
BREADY required write response flow control - see AXI spec
read address ARADDR required read address - see AXI spec
ARVALID required read address valid - see AXI spec
ARREADY required read address flow control - see AXI spec
read data RDATA required read data - see AXI spec
RRESP required read response - see AXI spec
RVALID required read data valid - see AXI spec
RREADY required read data flow control - see AXI spec
clock/reset ACLK required clock - see AXI spec., can be shared between multiple interfaces on the same components
ARESETN required low active reset - see AXI spec, can be shared between multiple interfaces on the same components
The interface can be parameterized in the following way:
**Parameter name ** **Description ** Default Type
C_BASEADDR AXI Base Address
integer
C_HIGHADDR
AXI High Address
integer
C_AXI_ADDR_WIDTH
AXI address bus width
32
integer
C_AXI_DATA_WIDTH AXI data bus width 32 integer
C_AXI_PROTOCOL AXI flavour AXI4LITE string
The following table summarizes the naming conventions: ( refers to the names in the table above)
**AXI Type ** **Direction ** **Signal name **
AXI Lite Master M_AXI_
Slave S_AXI_
A data path interface is a pre-configured Xilinx AXI4 Streaming Protocol v1.9 compliant stream whereby meta-data is conveyed through the TUSER field. To achieve compatibility between IP blocks that stem from many different users, it is vitally important that all users comply to the following guidelines:
The following is a specification for the data path interface: first we show a compact and precise form (called Spec Savy Description) for those who have read the Xilinx AXI Streaming Protocol Specification v 1.9, and the second (called Quick Synopsis) is a quick listing of the required signals, parameters, and notes.
Required Signals:
**Signal ** **Status ** **Description **
ACLK required clock - see AXI spec., can be shared between multiple interfaces on the same components
ARESETN required active low reset - see AXI spec., can be shared between multiple interfaces on the same components
Signal Bit Width **Description **
TVALID 1 master to slave flow control signal - see AXI spec.
TDATA C_DAT_DATA_WIDTH data signal - see AXI spec.
TREADY 1 slave to master flow control signal - see AXI spec.
TSTRB C_DAT_DATA_WIDTH/8 byte enable signal - see AXI spec.
TLAST 1
indicates end of packet - see AXI spec.
TUSER fixed to 128 carries meta data in the first data beat of the packet
Parameters:
**Parameter name ** **Description ** Details Type Default(s)
C_[MS]_AXIS_DATA_WIDTH
bit width of TDATA (see AXI spec) must be a multiple of 8 integer
8,32,64,256
C_[MS]_AXIS_TUSER_WIDTH bit width of TUSER (see AXI spec) fixed width integer 128
Notes:
* TSTRB is an "aligned strobe" (see Xilinx AXI spec.). Translation: Within a packet transfer, invalid bytes (indicated by TSTRB LOW) may ONLY be sent contiguously together at the tail end of a packet.
* Byte order is defined in ARM AXI Stream Spec, _i.e._ the first byte appears in TDATA[7:0], and TSTRB[0] is always a '1'. **Note**: This is **opposite to** what is adopted in NetFPGA-1G.
* C_[MS]_AXIS_DATA_WIDTH is 8 for 1Gbps transport, 32 for 4Gbps transport, 64 for 10Gbps transport, 256 and 40Gbps transport.
* There should be a C_M_AXIS_DATA_WIDTH parameter if an AXI4 Slave master interface is present, and a separate C_S_AXIS_DATA_WIDTH for any AXI4 Slave interface — even if both constants have the same value (as would usually be the case).
Transport of meta-data through TUSER:
All meta data that is associated with a packet is to be conveyed through the TUSER field in the 1st cycle of data transmission - so completely aligned with the first data word in TDATA.
We differentiate between predefined meta data fields of which there a 3, and user-definable ones.
The TUSER field is allocated in the following way:
TUSER[15:0]: length of the packet in bytes
TUSER[23:16]: source port: identifies the port at which the packet was received. Note that each port is one-hot, i.e. encoded as an individual bit (and a maximum of 8ports is supported.)
TUSER[31:24]: destination port: identifies the port from which the packet is to be transmitted. Note one-hot encoding, and that multicast is possible as each port is associated with each bit. (A maximum of 8 ports is supported.)
TUSER[47:32]: user definable meta data slot 0
TUSER[63:32]: user definable meta data slot 1
TUSER[79:64]: user definable meta data slot 2
TUSER[95:80]: user definable meta data slot 3
TUSER[111:96]: user definable meta data slot 4
TUSER[127:112]: user definable meta data slot 5
Notes:
* _source port_ and _destination port_ are one-hot encoded, _i.e._ each bit of the field represents a different port.
* even-numbered bits represent physical Ethernet (MAC) ports, and odd-numbered bits represent PCI queues (_i.e._ host interfaces).
The "user definable meta data slot" is a 16bit wide field and there can be a maximum of 6 as shown above in the TUSER bit definition.
Each 16bit slot consists of a 4bit type and a 12bit value field. The type field specifies what type of meta data is stored in the value field.
User defined meta data slot [15:12]: type
User defined meta data slot [11:0]: value
The user can define his own meta data by allocating a specific type for it (the allocation will be administrated over this wiki).
However the users' IP must be able to parse for his type on any of the defined 6 locations. In other words, the location of the meta data is not guaranteed to a specific slot.
Furthermore, to be compliant, the users' IP must guarantee to forward any meta data that is conveyed in the predefined slots.
The support of an ERROR or ABORT signal is currently deferred to a later stage.
The Xilinx AXI Streaming Protocol Specification v 1.9 suggests the following naming conventions for AXI Stream ports on IP:** **
_
Where:
::= []
::= [][_n]
Without confusion, ChannelName can be omitted in DAT channel.
Where for NetFPGA-10G:
* <Role> ::= "M" | "S" ;
* <ClassName> ::= "AXIS" ;
* <BusName> ::= <any-valid-name> ;
* <ChannelName> ::=<any-valid-name>;
* <SignalName> ::= "TVALID" | "TDATA" | "TSTRB" | "TREADY" | "TLAST" ;
* <any-valid-name> ::= <alpha> , <zero-or-more-alpha-numeric> ;
Bus Interface Name Examples:
M_AXIS_DPI0
M_AXIS_ENCRYPT
S_AXIS_VIDEO
S_AXIS_AUDIO
Port Name Examples:
TDATA
LEN_TDATA
SRCPRT_TDATA
DSTPRT_TDATA
ERR_TVALID
Full Name Example:
M_AXIS_VIDEO
M_AXIS_VIDEO_LEN
However, please note that this is a changing specification, and already newly released IP is following a different grammar. For instance, they sometimes swap the ordering of the ClassName and Role (creating AXIS_M instead of M_AXIS), and sometimes omit the BusName completely.