Visible to Intel only — GUID: nmm1467936137491
Ixiasoft
4.5.2.1. Transmit User Data Interface Examples
The following examples illustrate how to use the Interlaken IP core TX user data interface:
Packet Mode Operation Example
This example illustrates the expected behavior of the Interlaken IP core application interface transmit signals during a packet transfer in packet mode.
Figure 20. Packet Transfer on Transmit Interface in Packet ModeThe figure illustrates a packet mode data transfer (eight word) of 179 bytes on the transmit interface into the IP core. In this mode, the Interlaken IP core ignores the itx_sob and itx_eob input signals.
To start a transfer, you assert itx_sop[1] when you have data ready on itx_din_words. At the following rising edge of the clock, the IP core detects that itx_sop[1] is asserted, indicating that the value on itx_din_words in the current cycle is the start of an incoming data packet. When you assert itx_sop[1], you must also assert the correct value on itx_chan to tell the IP core the data channel source of the data. In this example, the value 2 on itx_chan tells the IP core that the data originates from channel number 2.
During the SOP cycle (labeled with data value d1) and the cycle that follows the SOP cycle (labeled with data value d2), you must hold the value of itx_num_valid[7:4] at 4'b1000. In the following clock cycle, labeled with data value d3, you must hold the following values on critical input signals to the IP core:
- itx_num_valid[7:4] at the value of 4'b0111 to indicate the current data symbol contains seven 64-bit words of valid data.
- itx_eopbits[3] high to indicate the current cycle is an EOP cycle.
- itx_eopbits[2:0] at the value of 3'b011 to indicate that only three bytes of the final valid data word are valid data bytes.
This signal behavior correctly transfers a data packet with the total packet length of 179 bytes to the IP core, as follows:
- In the SOP cycle, the IP core receives 64 bytes of valid data (d1).
- In the following clock cycle, the IP core receives another 64 bytes of valid data (d2).
- In the third clock cycle, the EOP cycle, the IP core receives 6 full words (6 x 8 = 48 bytes) and three bytes of valid data, for a total of 51 valid bytes.
The total packet length is 64 + 64 + 51 = 179 bytes.
Back-Pressured Packet Transfer Example
This example illustrates the expected behavior of the Interlaken application interface transmit signals during a packet transfer with back pressure.
Figure 21. Packet Transfer on Transmit Interface with Back PressureThe figure illustrates timing diagram for packet mode data transfer with back-pressure on the transmit interface.
In this example, the Interlaken IP core accepts the first four data symbols (256 bytes) of a data packet. The clock cycles in which the application transfers the data values d2 and d3 to the Interlaken IP Core are grace-period cycles following the Interlaken IP core's de-assertion of itx_ready.
The Interlaken IP core supports up to 4 cycles of grace period, enabling you to register the input data and control signals, as well as the itx_ready signal, without changing functionality. The grace period supports your design in achieving timing closure more easily. In any case you must ensure that you hold itx_num_valid at the value of 0 when you are not driving data.
You can think of this interface as a FIFO write interface. When itx_num_valid[7:4] is nonzero, both data and control information (including itx_num_valid[7:4] itself) are written to the transmit side data interface. The itx_ready signal is the inverse of a hypothetical FIFO-almost-full flag. When itx_ready is high, the Interlaken IP core is ready to accept data. When itx_ready is low, you can continue to send data for another six to eight clock cycles of tx_usr_clk.
Interleaved Mode Example
In Interleaved Mode, you are responsible for scheduling the burst. You need to drive an extra pair of signals, Start of Burst (SOB) and End of Burst (EOB), to indicate the burst boundary. You can send the traffic in packet order or interleaved order, if you set the SOB and EOB flags correctly to establish the data boundaries.
Figure 22. Packet Transfer on Transmit Interface in Interleaved Single Segment ModeThe figure shows the timing diagram for an interleaved data transfer (eight word) in Interleaved mode.
This example illustrates the expected behavior of the Interlaken IP core application interface transmit signals during data transfers from the application to the IP core on the TX user data transfer interface in interleaved single segment mode. Since only the single segment mode is supported in interleaved mode, the itx_sob[1] and itx_num_valid[7:4] are valid signals.
In cycle 1, the application asserts itx_sop[1] and itx_sob[1], indicating that this cycle is both the start of the burst and the start of the packet. The value the application drives on itx_chan indicates the data originates from channel 2.
In cycle 2, the application asserts itx_eob, indicating the data the application transfers to the IP core in this clock cycle is the end of the burst. (itx_chan only needs to be valid when itx_sob[1] or itx_sop[1] is asserted). itx_num_valid[7:4] indicates all eight words are valid. However, the data in this cycle is not end of packet data of that channel. The application is expected to transfer at least one additional data burst in this packet, possibly interleaved with one or more bursts in packets from different data channels.
Cycle 3 is a short burst with both itx_sob[1] and itx_eob asserted. The application drives the value of three on itx_num_valid[7:4] to indicate that three words of the eight-word itx_din_words data bus are valid. The data is packed in the most significant words of itx_din_words.The application drives the value of 4'b1011 on itx_eopbits to indicate that the data the application transfers to the IP core in this cycle are the final words of the packet, and that in the final word of the packet, only three bytes are valid data. The value the application drives on itx_chan indicates this burst originates from channel 4.
In cycle 4, the itx_num_valid[7:4] signal has the value of zero, which means this cycle is an idle cycle.
In cycle 5, the application sends another single-cycle data burst from channel 2, by asserting itx_sob[1] and itx_eob to indicate this data is both the start and end of the burst. The application does not assert itx_sop[1], because this burst is not start of packet data. itx_eopbits has the value of 4'b0000, indicating this burst is also not end of packet data. This data follows the data burst transfered in cycles 1 and 2, within the same packet from channel 2.
In cycle 6, the application sends a start of packet, single-cycle data burst from channel 3.
In cycles 7 and 8, the application sends a two-cycle data packet in one two-cycle burst. In cycle 8, the second data cycle, the application drives the value of two on itx_num_valid[7:4] and the value of 4'b1011 on itx_eopbits, to tell the IP core that in this clock cycle, the two most significant words of the data symbol contain valid data and the remaining words do not contain valid data, and that in the second of these two words, only the three most significant bytes contain valid data.
In Interleaved Mode, you can transfer a packet without interleaving if the channel number does not toggle during the same packet transfer. However, you must still assert the itx_sob and itx_eob signals correctly to maintain the proper burst boundaries.
If you do not drive the itx_sob and itx_eob signals, the Interlaken IP Core does not operate properly and the transmit FIFO may overflow, since in this mode the internal logic is looking for itx_sob and itx_eob assertion for insertion of proper burst control words.