FrontPanel HDL

USB Transport

The USB transport is the connection these boards use to carry FrontPanel data between the host PC and okHost. On these boards the USB link reaches the FPGA through an on-board USB microcontroller that bridges the two, and the behaviors documented here are inherited from that microcontroller rather than from the USB standard by itself. The AXI interface okHost presents, documented on okHost Core, is transport-agnostic.

Bandwidth Modes

On the USB transport you choose a bandwidth mode at build time. The mode selects the AXI data widths, the aclk frequency, and the resulting per-direction throughput. Pick the mode whose Up (FPGA to host) and Down (host to FPGA) figures fit your design. AXI-Lite is always 32-bit with a 64-bit address regardless of mode.

BWMode	s_axis bits (FPGA → host)	m_axis bits (host → FPGA)	m_axi bits (AXI-Full)	aclk MHz	Up (FPGA → host)	Down (host → FPGA)
1	64	8	64	160.00	10G	40M
2	128	8	128	156.25	20G	40M
3	64	32	64	156.25	10G	2.5G
4	8	64	64	125.00	40M	5G
5	32	32	32	160.00	5G	2.5G
6	64	8	64	125.00	8G	40M
7	32	32	32	125.00	4G	2.5G

The M_AXI (AXI-Full) width is independent of both directions. The Up and Down figures are per-direction peaks; the link carries one direction at a time, a consequence of okHost being host-initiated, so do not budget them concurrently.

Each board supports only a subset of modes. To see which, look at which BWMode<N> folders the SDK delivers for that board in the FrontPanel HDL install, at ...\FrontPanel-Platform\FrontPanelHDL\<board>\Vivado-<year>\BWMode<N>\, each holding okHost’s source files. The full folder layout is under Delivery and Files.

The bandwidth mode is fixed at build time, baked into the bitstream by which BWMode<N> sources or IP Core configuration you build.

Because the bus widths are set by the loaded mode, the host API can read them back at runtime with the datapath-width getters: GetDatapathWidthByteCount for AXI-Full, and GetWriteDatapathWidthByteCount and GetReadDatapathWidthByteCount for AXI-Stream. AXI-Lite has none, because it is always 32-bit. The full signatures are in the FrontPanel API reference. These getters matter only if your host application must support more than one mode from the same code; otherwise hardcode the mode’s widths.

Idle Gaps (the Cause)

okHost does not move data continuously. It transfers in chunks with idle cycles between them. The gap shows up on whichever handshake signal okHost drives, so it applies to both directions. The per-interface design responses are on Idle Gaps and FIFO Sizing.

On a write (host to FPGA: AWVALID and WVALID on AXI-Full, TVALID on m_axis), okHost deasserts its driven VALID between chunks.
On a read (FPGA to host: RREADY on AXI-Full, TREADY on s_axis), okHost deasserts its driven READY between chunks.

okHost delivers about 64 KB per chunk with a gap of about 1 µs between chunks. Treat these as ballpark figures. The gaps are inherited from the on-board USB microcontroller that bridges the USB link to the FPGA, not from the USB standard. The handshake stays AXI-compliant throughout. On a write, VALID and the payload are held until READY; on a read, READY may deassert between beats.

For sizing a FIFO, one gap is about 1 µs of your endpoint’s data. At up to 160 MHz and one word per cycle, that is about 160 words. The FIFO-sizing guidance on System Design uses this figure. In practice, AXI-Full is almost always a non-issue except the shared-Subordinate case, and AXI-Stream is the real concern for a fixed-rate endpoint. See Idle Gaps and FIFO Sizing.

Reliable Transfer

okHost’s transport over USB is reliable. The on-board USB microcontroller detects corruption with a CRC and retransmits the affected packet, so a completed operation moved exactly the bytes you sent on a write or requested on a read, and any unrecoverable failure surfaces as an error or timeout. You do not need your own checksum across the link.

Resource Utilization (FPGA Footprint)

okHost consumes FPGA fabric, so budget for it. The figures are board-, speed-grade-, and bandwidth-mode-dependent, so treat them as indicative.

The baseline is the SYZYGY SZG-HUB1450-AU10P (AMD Artix UltraScale+ xcau10p-ffvb676-1-e). These are post-implementation figures for the okHost instance only, from PerfTest builds per mode.

BWMode	LUTs	Registers (FF)	BRAM tiles
1	9,015	8,967	2.5
2	9,926	10,434	2.5
3	9,916	9,309	1.5
4	9,696	8,930	3.5
5	9,404	8,464	1.5
6	9,015	8,967	2.5
7	9,404	8,464	1.5

A BRAM tile is one RAMB36, and a half tile is one RAMB18.

Every build also instantiates two device-unique hard blocks that exist once per FPGA, so your design cannot instantiate them itself: one SYSMON (SYSMONE4, behind the FrontPanel Device Sensors; OMIT_SYSMON omits it so you can manage SYSMON yourself, as under Instantiation Parameters) and one DNA (DNA_PORTE2, exposed on dna and dna_valid, as under Board Ready and DNA Outputs).

Bandwidth Modes

Idle Gaps (the Cause)

Reliable Transfer

Resource Utilization (FPGA Footprint)

See Also