Standard IP Interfaces
This document describes the standard set of interfaces used by NetFPGA-10G platform IP.
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:
Control & Status Interface
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:
|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:
|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|
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_<signal name>|
Data Path Interface
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.
|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|
|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|
|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|
- 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 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:48]: 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
- 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 definition is as follows (from Bit 0 to Bit 7)
|Bit 0||Bit 1||Bit 2||Bit 3||Bit 4||Bit 5||Bit 6||Bit 7|
- On NetFPGA-10G card, Port 0 means the port nearest to the PCIe bus.
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.
Signal Naming for Stream Interfaces:
The Xilinx AXI Streaming Protocol Specification v 1.9 suggests the following naming conventions for AXI Stream ports on IP:
<BusInterfaceName> ::= <Role>_<ClassName>[_<BusName>]
<PortName> ::= [<ChannelName>]<SignalName>[_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:
Port Name Examples:
Full Name Example:
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.