Standard IP Interfaces

Document Description

This document describes the standard set of interfaces used by NetFPGA-10G platform IP.

Background

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).

Standard Interfaces

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

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:

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_<signal name>
	Slave	S_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.

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: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

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 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
MAC0	CPU0	MAC1	CPU1	MAC2	CPU2	MAC3	CPU3

• 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>_<PortName>

Where:

<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:

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.