AN 971: JTAG-Over-Protocol Intel FPGA IP

Download PDF
ID 728673
Date 6/14/2022
Public
Document Table of Contents
Document Table of Contents x
1. JTAG-Over-Protocol Intel® FPGA IP Overview 2. JTAG-Over-Protocol Intel® FPGA IP Parameters 3. JTAG-Over-Protocol Intel® FPGA IP Communication with JTAG Server 4. AN 971: JTAG-Over-Protocol Intel FPGA IP Archives 5. AN 971: JTAG-Over-Protocol Intel FPGA IP Revision History
3. JTAG-Over-Protocol Intel® FPGA IP Communication with JTAG Server x
3.1. Etherlink Application TCP/IP Protocol
1. JTAG-Over-Protocol Intel® FPGA IP Overview
2. JTAG-Over-Protocol Intel® FPGA IP Parameters
3. JTAG-Over-Protocol Intel® FPGA IP Communication with JTAG Server
4. AN 971: JTAG-Over-Protocol Intel FPGA IP Archives
5. AN 971: JTAG-Over-Protocol Intel FPGA IP Revision History

3.1. Etherlink Application TCP/IP Protocol

Etherlink Application TCP Sockets

The etherlink application uses five TCP sockets for control and data transfer as follows:
Table 2.  Etherlink Application Socket Connections
Socket Name Direction Role
CONTROL bidirectional Establishing communications

Querying and setting configurations on the etherlink application

H2T_DATA client-to-server Client sends packets to the etherlink application that contain data for the h2t_data stream.
T2H_DATA server-to-client Server sends packets to the client that contain data for the t2h_data stream.
MGMT client-to-server Client sends packets to the etherlink application that contain data for the mgmt stream.
MGM_RSP server-to-client Server sends packets to the client that contain data for the mgmt_rsp stream.
Important: The etherlink application can service a connection to only one client at a time. If you have multiple running clients (like multiple JTAG-Over-Protocol IP instances), you need one running etherlink application per client.

Because there are five sockets that define the connection, there must be a handshake mechanism to prevent a corrupted connection between one etherlink application and potentially multiple clients.

Etherlink Application Connection Handshake Protocol

The connection handshake protocol mandates that the etherlink application sends out a unique handle across to the first socket connected and expects the subsequent four sockets to acknowledge this handle from the client side upon connection.

This connection handshake protocol helps ensure the five sockets connected are all from the same instance of the client driver.

The etherlink application connection handshake protocol is as follows:
  1. A first socket connection is established with the client on an agreed port. This connection is the CONTROL socket.
    The etherlink application sends a welcome message that describes its receive buffer sizes and provides a unique handle: 
    Welcome to INTEL_ST_HOST_EP_SERVER: 
H2T_RX_BUFF_SZ=<size in bytes> 
MGMT_RX_BUFF_SZ=<size in bytes> 
CTRL_RX_BUFF_SZ=<size in bytes>
HANDLE=<id>
    The etherlink application expects the following message from the client to continue: 
    Control HANDLE=<id>

    If the message is as expected, the etherlink application sends out a READY message and proceeds to the next step. If not, the etherlink application sends out a NOT_READY message and waits for a new connection attempt.

  2. A second socket connection is established on an agreed port. This connection is the MGMT socket.
    The etherlink application expects the following message from the client: 
    Management HANDLE=<id>
    The <id> value must match the HANDLE value from the previously established CONTROL socket.

    If the message is as expected, the etherlink application sends out a READY message and proceeds to the next step. If not, the etherlink application sends out a NOT_READY message and waits for a new connection attempt.

  3. A third socket connection is established on an agreed port. This connection is the MGMT_RSP socket.
    The etherlink application expects the following message from the client: 
    Management Response HANDLE=<id>
    The <id> value must match the HANDLE value from the previously established CONTROL socket.

    If the message is as expected, the etherlink application sends out a READY message and proceeds to the next step. If not, the etherlink application sends out a NOT_READY message and the process

  4. A fourth socket connection is established on an agreed port. This connection is the H2T_DATA socket.
    The etherlink application expects the following message from the client: 
    H2T HANDLE=<id>
    The <id> value must match the HANDLE value from the previously established CONTROL socket.

    If the message is as expected, the etherlink application sends out a READY message and proceeds to the next step. If not, the etherlink application sends out a NOT_READY message and waits for a new connection attempt.

  5. A fifth socket connection is established on an agreed port. This connection is the T2H_DATA socket.
    The etherlink application expects the following message from the client: 
    T2H HANDLE=<id>
    The <id> value must match the HANDLE value from the previously established CONTROL socket.

    If the message is as expected, the etherlink application sends out a READY message and proceeds to the next step. If not, the etherlink application sends out a NOT_READY message and waits for a new connection attempt.

  6. If the five socket connections were successful, the etherlink application sends a READY message via the CONTROL socket. If any of the five socket connections where unsuccessful, the etherlink application sends a NOT_READY message via the CONTROL socket and waits for a new connection attempt.

The etherlink application continues to accept socket connections but replies to them with a SERVER_BUSY message and then closes the connection. This response can help with debugging because a refused connection (if the etherlink application refused any connection after expected five connections) can occur for multiple reasons such as firewall issue or a server not responding.

Control Commands

The etherlink application defines the following commands for querying parameters, changing settings, and checking status. The command are null-terminated ASCII strings sent over the CONTROL socket.

Table 3.  Etherlink Application Control Commands
Command Description

GET_PARAMETER <parameter>

Sets a server-defined parameter.

Parameter names cannot have spaces.

If the command was successful, the etherlink application responds with the parameter value.

If the command failed, the etherlink application responds with a GET_PARAM_FAILURE message. Do not use GET_PARAM_FAILURE as a parameter value.

SET_PARAM <parameter> <parameter value>

Sets a server-defined parameter.

Parameter names cannot have spaces.

If the command was successful, the etherlink application responds with SET_PARAM_ACK.

If the command failed, the etherlink application responds with SET_PARAM_FAIL_ACK.

GET_DRIVER_PARAM <parameter> Gets a driver-defined parameter.

Parameter names cannot have spaces.

If the command was successful, the etherlink application responds with the parameter value.

If the command failed the etherlink application responds with GET_PARAM_FAILURE. Do not use GET_PARAM_FAILURE as a parameter value.

SET_DRIVER_PARAM <parameter> <parameter value> Sets a driver-defined parameter.

Parameter names cannot have spaces.

If the command was successful, the etherlink application responds with SET_PARAM_ACK.

If the command failed the etherlink application responds with SET_PARAM_FAIL_ACK.

DISCONNECT Initiates a disconnect.

The client sends out the DISCONNECT command that tells the etherlink application the session has come to an end.

PING Checks if the etherlink application is running and has basic functioning without sending any data.

The etherlink application responds with PONG.

For any other commands, the etherlink application responds with an UNRECOGNIZED_COMMAND message.

Streaming Protocol Format

After the client and etherlink application have successfully completed the handshake protocol, the following data transfers can occur:
  • The client can send data over the H2T_DATA and MGMT sockets.
  • The etherlink application can send data over the T2H_DATA and MGMT_RSP sockets.

The client should never send a larger protocol packet than the corresponding buffer sizes established with the first socket connection: H2T_RX_BUFF_SZ, MGMT_RX_BUFF_SZ, and CTRL_RX_BUFF_SZ.

The packet format allows for the client (and etherlink application) to split large Avalon® streaming interface packets into multiple protocol packets by using the EOP and SOP bits.
Table 4.  Protocol Packet Format for H2T_DATA and T2H_DATA Sockets
Field ‘0xDEADBEEF’ guard band EOP SOP Connection ID Channel Data Length (Bytes) Data Payload
Mask n/a 0x2 0x1 0xFF 0x0FFF 0xFFFF n/a
Byte number Bytes 0-3 Byte 4 Byte 5 Bytes 6-7 Bytes 8-9 Bytes 10 and greater
Table 5.  Protocol Packet Format for MGMT and MGMT_RSP Sockets
Field ‘0xDEADBEEF’ guard band EOP SOP Reserved Channel Data Length (Bytes) Data Payload
Mask n/a 0x2 0x1 0xFF 0x0FFF 0xFFFF n/a
Byte number Bytes 0-3 Byte 4 Byte 5 Bytes 6-7 Bytes 8-9 Bytes 10 and greater
Level Two Title