Starting with FrontPanel 6.0, FPGA data communication is established by getting the FPGA data port interface from the device after configuring the FPGA with a FrontPanel-enabled bitfile.

Devices support either the FPGADataPortClassic or the FPGADataPortAXI data port and not both.

The data port is intended to be retrieved after the FPGA has been successfully configured with a FrontPanel-enabled bitfile. Once the FPGA is configured, the dataport can be retrieved using one of the following methods of the FrontPanel class:

New in FrontPanel 6.0. The AXI data port provides access to three AXI sub-interfaces for FPGA designs that use the FrontPanel AXI bridge:

• AXI-Lite – 32-bit register-style reads and writes to memory-mapped peripherals.
• AXI-Full – Byte-level, burst-capable access to FPGA block RAM or other memory-mapped regions.
• AXI-Stream – Streaming data transfer between host and FPGA.

• USB Gen 3 device (FX5-, FX10-, and FX20-based devices) such as the SZG-HUB1450

…coming soon…

The classic data port is used on the following product families:

• USB Gen 1 devices (FX2-based, “USB 2.0”) such as XEM3010, XEM3050, XEM6001, XEM6010, XEM7010, etc.
• USB Gen 2 devices (FX3-based, “USB 3.0”) such as XEM6310, XEM7310, XEM8310, XEM8320, XEM8350, etc.
• PCIe device – XEM6110

Once the FPGA has been configured, communication between the application and the FPGA hardware is done through these methods.  The FPGA is connected directly to the bridge device (USB microcontroller or PCIe bridge) on the XEM.  These methods communicate through that connection and require that an instance of the HDL module okHostInterface be installed in the FPGA configuration.

A brief description of the API methods is in the table below.  The way the API and FrontPanel HDL modules communicate is described in more detail later.

All API methods are blocking commands. This means that the call completes before it returns to the caller (your software). Therefore, you can be assured that if you perform two consecutive API calls that update registers on the FPGA, the updates from the first call are complete prior to starting the second call.

The four classic dataport endpoint types (Wire, Trigger, Pipe, and Registers) provide a means by which the PC and FPGA communicate. Each type is suited to a specific type of data transfer and has its own associated usage and rules.

Recall that a wire is used to communicate asynchronous signal state between the host (PC) and the target (FPGA). The okHostInterface supports up to 32 Wire In endpoints and 32 Wire Out endpoints connected to it. To save bandwidth, all Wire In or Wire Out endpoints are updated at the same time and written or read by the host in one block.

All Wire In (to FPGA) endpoints are updated by the host at the same time with the call UpdateWireIns(). Prior to this call, the application sets new Wire In values using the API method SetWireInValue(). The SetWireInValue() simply updates the wire values in a data structure internal to the API. UpdateWireIns() then transfers these values to the FPGA.

All Wire Out (from FPGA) endpoints are likewise read by the host at the same time with a call to UpdateWireOuts(). This call reads all 32 Wire Out endpoints and stores their values in an internal data structure. The specific endpoint values can then be read out using GetWireOutValue().

Note: UpdateWireIns() and UpdateWireOuts() also latch all wire endpoint data at the same time. Therefore, the data available on Wire Out endpoints are all captured synchronously (with the target interface clock). Similarly, the data availble to Wire In endpoints is all latched synchronously with the target interface clock.

Endpoint Width: Wires are 16-bits wide on USB 2.0 devices, 32-bits on USB 3.0 devices, and 32-bits on PCI Express devices. The API interface width is 32 bits. The upper bits are ignored if not supported.

Triggers are used to communicate a singular event between the host and target. A Trigger In provides a way for the host to convey a “one-shot” on an arbitrary FPGA clock. A Trigger Out provides a way for the FPGA to signal the host with a “one-shot” or other single-event indicator.

Triggers are read and updated in a manner similar to Wires. All Trigger Ins are transferred to the FPGA at the same time and all Trigger Outs are transferred from the FPGA at the same time.

Trigger Out information is read from the FPGA using the call UpdateTriggerOuts(). Subsequent calls to IsTriggered() then return ‘true’ if the trigger has been activated since the last call to UpdateTriggerOuts().

Endpoint Width: Triggers are 16-bits wide on USB 2.0 devices, 32-bits on USB 3.0 devices, and 32-bits on PCI Express devices. The API interface width is 32 bits. The upper bits are ignored if not supported.

Pipe communication is the synchronous communication of one or more bytes of data. In both Pipe In and Pipe Out cases, the host is the master. Therefore, the FPGA must be able to accept (or provide) data on any time. Wires, Triggers, and FIFOs can make things a little more negotiable.

When data is written by the host to a Pipe In endpoint using WriteToPipeIn(…), the device driver will packetize the data as necessary for the underlying protocol. Once the transfer has started, it will continue to completion, so the FPGA must be prepared to accept all of the data.

When data is read by the host from a Pipe Out endpoint using ReadFromPipeOut(…), the device driver will again packetize the data as necessary. The transfer will proceed from start to completion, so the FPGA must be prepared to provide data to the Pipe Out as requested.

Length Restrictions

When using the Pipes API, the length is specified in bytes. Firmware restrictions put a limitation on the maximum length per transfer. However, this API will automatically perform multiple transfers, if required, to complete the full length. Length must be an integer multiple of a minimal transfer size according to the list below:

Byte Order (USB 2.0)

Pipe data is transferred over the USB in 8-bit words but transferred to the FPGA in 16-bit words. Therefore, on the FPGA side (HDL), the Pipe interface has a 16-bit word width but on the PC side (API), the Pipe interface has an 8-bit word width.

When writing to Pipe Ins, the first byte written is transferred over the lower order bits of the data bus (7:0). The second byte written is transferred over the higher order bits of the data bus (15:8). Similarly, when reading from Pipe Outs, the lower order bits are the first byte read and the higher order bits are the second byte read.

Byte Order (USB 3.0)

Pipe data is transferred over the USB in 8-bit words but transferred to the FPGA in 32-bit words. Therefore, on the FPGA side (HDL), the Pipe interface has a 32-bit word width but on the PC side (API), the Pipe interface has an 8-bit word width.

When writing to Pipe Ins, the first byte written is transferred over the lower order bits of the data bus (7:0). The second byte written is transferred over next higher order bits of the data bus (15:8) and so on. Similarly, when reading from Pipe Outs, the lower order bits are the first byte read and the next higher order bits are the second byte read.

Byte Order (PCI Express)

The HDL pipe endpoints for PCI Express designs are 64-bits wide. The API methods are 8 bits wide for both USB and PCI Express. For PCI Express devices, pipe transfers must be in multiples of 8 bytes.

Block-Throttled Pipe communication is identical to Pipe communication with the additional specification of a block size.

Because the FPGA has the opportunity to stall the transfer by deasserting EP_READY, the call may fail with a timeout.

Length Restrictions

Block sizes and length sizes are determined by two factors:

• Device Firmware – The device microcontroller has limitations based on its internal design architecture.
  • Cypress FX2 – Sometimes referred to as our “USB 2.0” devices. Examples include XEM3001, XEM5010, XEM7010, XEM7001
  • Cypress FX3 – Sometimes referred to as our “USB 3.0” devices. Examples include XEM6310, XEM7310, ZEM5305, ZEM5310.
• USB Connection Speed – The underlying USB connection speed also places limitations on the block sizes. Use the GetDeviceInfo API to retrieve an okTDeviceInfo struct, then inspect the usbSpeed for this information.
  • Full Speed (FS) – Uncommonly slow connection speed (12 Mbps, USB 1.0).
  • High Speed (HS) – Typical USB 2.0 connection speed (480 Mbps).
  • Super Speed (SS) – Only available on USB 3.0 ports (5 Gbps).

Block size is dependent on the device type (firmware) and connection speed. The software APIs will automatically break a transfer into appropriate lengths, when able. However, this will result in more transactions being performed and, therefore, lower performance. To optimize transfers, the following steps should be made, either during system design or algorithmically:

1. Determine the connection speed using the GetDeviceInfo API and inspecting the usbSpeed parameter.
2. Determine an appropriate block size according to the table below. Larger block sizes will perform better.
3. Determine an allowed transfer length according to the table below. Longer transfers will perform better.

Note that some of these restrictions are related to the connection speed. If a USB 3.0 device is connected to a USB 2.0 port, it will be forced to the lower connection speed and therefore have different restrictions. Your gateware and software should recognize this and act accordingly.

The API will return an UnsupportedFeature Error Code if an invalid block size or transfer length is specified.

The RegisterBridge HDL module provides a read / write interface with a 32-bit address range and 32-bit data width. Any address within the range may be read or written. Reads and writes through the API are performed on the hardware in the order provided by the caller and each is performed only after the previous has completed.