Communication between multiple FPGAs is a key requirement for emulation and prototyping systems, as well as in many other use cases. The High-Speed Transceiver Pin Multiplexing (HSTPM) IP provides a solution to mux general purpose I/O (GPIO) across Xilinx gigabit transceivers.
Integrating the HSTPM IP core into
a system requires some handshaking between the IP core and user data. Before
transmitting/enabling the system, HSTPM must be
enumerated and assert the COREREADY signal signifying a ready
state. In multilane mode, there is no specific sequence for linkup and the core can only
transmit/receive data unless all the lanes are linked up. When the core is up and COREREADY is asserted, the IP waits for the first active edge of
the synchronous clock before packetizing and transmitting the data. The receiver is not
synchronized with the synchronous clock but is activated upon receiving the start-of-frame
(SOF) packet from the GTs. After the packet is detected, the subsequent data beats are
presented on user data until end-of-frame (EOF) is received. Each GT Quad comprise of four
individual TX/RX pair and allows for data to be sent individually over four lanes. Each lane
can support data beat size ranges from 32 bits up to 8192 bits in step of 32-bit or 64-bit
depending on the line rate and phy data width. The line rate of the data sent can also be
adjusted to accommodate speeds from 0.5 Gb/s up to 28 Gb/s. In multilane mode, selection of
line rate is restricted to the instance of the IP, i.e., within an IP instance; you cannot
select multiple line rates for individual lanes.
The HSTPM core has an optional UltraFast mode where the core provides minimum link management functionality and enables you to build custom logic around the core to transmit and receive the data.
As with any high-speed communication between devices, error checking is an important component. The HSTPM IP provides parity errors. The framing errors detect an error if data packets are lost when a transmission is expected, whereas the parity error is in case of single bit errors during transmissions or bit flips due to characterization.
The data being sent via HSTPM must be driven on a synchronous clock, which must be synchronized between devices. This is a hard requirement in emulation systems and the HSTPM block does not require any special requirements other than a synchronous clock. The HSTPM core is architected to allow for some skew in the data being received. This is achieved by leaving some guard bands within packetization and de-packetization as an additional feature. A guard band acts like a buffer to accommodate any delays in the data being received.