RapidIO II Intel® FPGA IP User Guide

ID 683444
Date 9/28/2020
Public
Document Table of Contents

4.3.5.2. Pass-Through Interface Signals

The Avalon® -ST pass-through interface includes the following ports:
  • Transmit interface — this sink interface accepts incoming streaming data that the IP core sends to the RapidIO link.
  • Receive data interface — this source interface streams out the payload of packets the IP core receives from the RapidIO link.
  • Receive header interface — this source interface streams out packet header information the IP core receives from the RapidIO link.

Pass-Through Transmit Side Signals

The Avalon® -ST pass-through interface transmit side signals receive incoming streaming data from user logic; the IP core transmits this data on the RapidIO link. The RapidIO II IP core samples data on this interface only when both gen_tx_ready and gen_tx_valid are asserted.

The incoming streaming data is assumed to contain well-formed RapidIO packets, with the following exceptions:
  • The streaming data includes placeholder bits for the ackID field of the RapidIO packet, but does not include the ackID value, which is assigned by the IP core.
  • The streaming data does not include the RapidIO packet CRC bits and padding bytes.
The Avalon® -ST pass-through interface does not check the integrity of the streaming data, but rather passes the bits on directly to the Transport layer. The RapidIO II IP core fills in the ackID bits and adds the CRC bits and padding bytes before transmitting each packet on the RapidIO link.
Table 32.   Avalon® -ST Pass-Through Interface Transmit Side ( Avalon® -ST Sink) Signals
Signal Name Type Function
gen_tx_ready Output

Indicates that the IP core is ready to receive data on the current clock cycle. Asserted by the Avalon® -ST sink to mark ready cycles, which are the cycles in which transfers can take place. If ready is asserted on cycle N, the cycle (N+READY_LATENCY) is a ready cycle.

In the RapidIO II IP core, READY_LATENCY is equal to 0. This signal may alternate between 0 and 1 when the Avalon® -ST pass-through transmitter interface is idle.

gen_tx_valid Input Used to qualify all the other transmit side input signals of the Avalon® -ST pass-through interface. On every ready cycle in which gen_tx_valid is high, data is sampled by the IP core. You must assert gen_tx_valid continuously during transmission of a packet, from the assertion of gen_tx_startofpacket to the deassertion of gen_tx_endofpacket.
gen_tx_startofpacket Input Marks the active cycle containing the start of the packet. The user logic asserts gen_tx_startofpacket and gen_tx_valid to indicate that a packet is available for the IP core to sample.
gen_tx_endofpacket Input Marks the active cycle containing the end of the packet.
gen_tx_data[127:0] Input

A 128-bit wide data bus. Carries the bulk of the information transferred from the source to the sink.

The RapidIO II IP core fills in the RapidIO packet ackID field and adds the CRC bits and padding bytes, but otherwise copies the bits from gen_tx_data to the RapidIO packet without modifying them. Therefore, you must pack the appropriate RapidIO packet fields in the correct RapidIO packet format in the most significant bits of the gen_tx_data bus, gen_tx_data[127:N]. The total width (127 – N + 1) of the header fields depends on the transaction and the device ID width.

gen_tx_empty[3:0] Input This bus identifies the number of empty bytes on the final data transfer of the packet, which occurs during the clock cycle when gen_tx_endofpacket is asserted. The number of empty bytes must always be even.
gen_tx_packet_size[8:0]23 Input Indicates the number of valid bytes in the packet being transferred. The IP core samples this signal only while gen_tx_startofpacket is asserted. User logic must ensure this signal is correct while gen_tx_startofpacket is asserted.
The required format of the TX header information on the gen_tx_data bus for both device ID widths derives directly from the RapidIO specification. You must include the header information in the clock cycle in which you assert gen_tx_startofpacket.
Note: The ackID field is filled by the IP core, and the eight-bit device ID fields are not extended with zeroes, in contrast to the destinationID and source ID fields in gen_rx_hd_data.
Table 33.  RapidIO Header Information Format on gen_tx_data Bus
Field gen_tx_data Bits
Device ID Width 8 Device ID Width 16
ackID[5:0] [127:122] [127:122]
VC [121] [121]
CRF [120] [120]
prio[1:0] [119:118] [119:118]
tt[1:0] [117:116] [117:116]
ftype[3:0] [115:112] [115:112]
destinationID[<deviceIDwidth>–1:0] [111:104] [111:96]
sourceID[<deviceIDwidth>–1:0] [103:96] [95:80]
specific_header [95:...] [79:...]
Table 34.  specific_header Format on gen_tx_data Bus
ftype Field gen_tx_data Bits
Device ID Width 8 Device ID Width 16
2, 5 ttype[3:0] [95:92] [79:76]
size[3:0] [91:88] [75:72]
transactionID[7:0] [87:80] [71:64]
address[28:0] [79:51] [63:35]
wdptr [50] [34]
xamsbs[1:0] [49:48] [33:32]
6 address[28:0] [95:67] [79:51]
Reserved [66] [50]
xamsbs[1:0] [65:64] [49:48]
7 XON/XOFF [95] [79]
FAM[2:0] [94:92] [78:76]
Reserved[3:0] [91:88] [75:72]
flowID[6:0] [87:81] [71:65]
soc [80] [64]
824 ttype[3:0] [95:92] [79:76]
size[3:0] [91:88] [75:72]
transactionID[7:0] [87:80] [71:64]
hop_count[7:0] [79:72] [63:56]
config_offset[20:0] [71:51] [55:35]
wdptr [50] [34]
Reserved[1:0] [49:48] [33:32]
9 single segment and start cos[7:0] [95:88] [79:72]
S [87] [71]
E [86] [70]
Reserved[2:0] [85:83] [69:67]
xh [82] [66]
O [81] [65]
P [80] [64]
streamID[15:0] [79:64] [63:48]
9 continuation cos[7:0] [95:88] [79:72]
S [87] [71]
E [86] [70]
Reserved[2:0] [85:83] [69:67]
xh [82] [66]
O [81] [65]
P [80] [64]
9 end cos[7:0] [95:88] [79:72]
S [87] [71]
E [86] [70]
Reserved[2:0] [85:83]  
xh [82][69:67] [66]
O [69:67[81] [65]
P [80] [64]
length[15:0] [79:64] [63:48]
9 extended packet cos[7:0] [95:88] [79:72]
Reserved[1:0] [87:86] [71:70]
xtype[2:0] [85:83] [69:67]
xh [82] [66]
Reserved[1:0] [81:80] [65:64]
streamID[15:0] [79:64] [63:48]
TM_OP[3:0] [63:60] [47:44]
Reserved [59] [43]
wildcard[2:0] [58:56] [42:40]
mask[7:0] [55:48] [39:32]
parameter1[7:0] [47:40] [31:24]
parameter2[7:0] [39:32] [23:16]
10 Reserved[7:0] [95:88] [79:72]
transactionID[7:0] [87:80] [71:64]
info[15:0] [79:64] [63:48]
11 msglen[3:0] [95:92] [79:76]
ssize[3:0] [91:88] [75:72]
letter[1:0] [87:86] [71:70]
mbox[1:0] [85:84] [69:68]
msgseg[3:0] or xmbox[3:0] [83:80] [67:64]
13 ttype[3:0] [95:92] [79:76]
size[3:0] [91:88] [75:72]
transactionID[7:0] [87:80] [71:64]
Table 35.   Avalon® -ST Pass-Through Interface Receive Side ( Avalon® -ST Source) Data SignalsFollowing are the Avalon® -ST pass-through interface receive side payload data signals. The application should sample payload data only when both gen_rx_pd_ready and gen_rx_pd_valid are asserted.
Signal Name Type Function
gen_rx_pd_ready Input Indicates to the IP core that the user’s custom logic is ready to receive data on the current cycle. Asserted by the sink to mark ready cycles, which are cycles in which transfers can occur. If ready is asserted on cycle N, the cycle (N+READY_LATENCY) is a ready cycle. The RapidIO II IP core is designed for READY_LATENCY equal to 0.
gen_rx_pd_valid Output Used to qualify all the other output signals of the receive side pass-through interface. On every rising edge of the clock during which gen_rx_pd_valid is high, gen_rx_pd_data can be sampled.
gen_rx_pd_startofpacket Output Marks the active cycle containing the start of the packet.
gen_rx_pd_endofpacket Output Marks the active cycle containing the end of the packet.
gen_rx_pd_data[127:0] Output A 128-bit wide data bus for data payload.
gen_rx_pd_empty[3:0] Output This bus identifies the number of empty two-byte segments on the 128-bit wide gen_rx_pd_data bus on the final data transfer of the packet, which occurs during the clock cycle when gen_tx_endofpacket is asserted. This signal is 4 bits wide.
Table 36.   Avalon® -ST Pass-Through Interface Receive Side ( Avalon® -ST Source) Header SignalsFollowing are the Avalon® -ST pass-through interface receive side header signals. The application should sample header data only when both gen_rx_hd_ready and gen_rx_hd_valid are asserted.
Signal Name Type Function
gen_rx_hd_ready Input Indicates to the IP core that the user’s custom logic is ready to receive packet header bits on the current clock cycle. Asserted by the sink to mark ready cycles, which are cycles in which transfers can occur. If ready is asserted on cycle N, the cycle (N+READY_LATENCY) is a ready cycle. The RapidIO II IP core is designed for READY_LATENCY equal to 0.
gen_rx_hd_valid Output Used to qualify the receive side pass-through interface output header bus. On every rising edge of the clock during which gen_rx_hd_valid is high, gen_rx_hd_data can be sampled.
gen_rx_hd_data[114:0] Output A 115-bit wide bus for packet header bits. Data on this bus is valid only when gen_rx_hd_valid is high.
Table 37.  RapidIO Header Fields in gen_rx_hd_data Bus
Field gen_rx_hd_data Bits Comment
pd_size[8:0] [114:106] Size of payload data, in bytes.
VC [105] Value = 0. The RapidIO II IP core supports only VC0.
CRF [104] This bit sets packet priority together with prio if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
prio[1:0] [103:102] Specifies packet priority.
tt[1:0] [101:100] Transport type. The value of 0 indicates 8-bit device IDs and value of 1 indicates 16-bit device IDs.
ftype[3:0] [99:96] Format type. Represented as a 4-bit value.
destinationID[15:0] [95:80] For packets with an 8-bit device ID, bits [95:88] (bits [15:8] of the destinationID) are set to 8’h00.
sourceID[15:0] [79:64] When ftype[3:0] has the value of 7, this field is used as the tgtDestinationID field. For packets with an 8-bit device ID, bits [79:72] (bits [15:8] of the sourceID) are set to 8’h00.
specific_header[63:0] [63:0] Fields depend on the format type specified in ftype.
Table 38.  specific_header Fields on gen_rx_hd_data Bus
ftype Field specific_header Bits
2, 5 ttype[3:0] [63:60]
size[3:0] [59:56]
transactionID[7:0] [55:48]
address[28:0] [47:19]
wdptr [18]
xamsbs[1:0] [17:16]
Reserved[15:0] [15:0]
6 address[28:0] [63:35]
Reserved [34]
xamsbs[1:0] [33:32]
Reserved[31:0] [31:0]
7 XON/XOFF [63]
FAM[2:0] [62:60]
Reserved[3:0] [59:56]
flowID[6:0] [55:49]
soc [48]
Reserved[47:0] [47:0]
8 ttype[3:0] [63:60]
status[3:0] or size[3:0] [59:56]
transactionID[7:0] [55:48]
hop_count[7:0] [47:40]
config_offset[20:0] [39:19]
wdptr [18]
Reserved[17:0] [17:0]
9 cos[7:0] [63:56]
S [55]
E [54]
xtype[2:0] [53:51]
xh [50]
O [49]
P [48]
streamID[15:0] [47:32]
TM_OP[3:0] [31:28]
reserve [27]
wildcard[2:0] [26:24]
mask[7:0] [23:16]
parameter1[7:0] [15:8]
parameter2[7:0] [7:0]
10 ttype[3:0] [63:60]
status[3:0] [59:56]
transactionID[7:0] [55:48]
info_msb[7:0] [47:40]
info_lsb[7:0] [39:32]
crc[15:0] [31:16]
Reserved[15:0] [15:0]
11 msglen[3:0] [63:60]
ssize[3:0] [59:56]
letter[1:0] [55:54]
mbox[1:0] [53:52]
msgseg[3:0] or xmbox[3:0] [51:48]
Reserved[47:0] [47:0]
13 ttype[3:0] [63:60]
status[3:0] [59:56]
transactionID[7:0] or target_info[7:0] [55:48]
Reserved[47:0] [47:0]
23 This signal is not defined in the Avalon® Interface Specifications. However, it refers to data being transferred on the Avalon® -ST sink interface.
24 In MAINTENANCE response packets, which have ftype value 8, replace the config_offset and wdptr fields with additional reserved bits.