The ThunderBus IP core enumerates the GT channel and continuously performs the link management functionality. The user interface to ThunderBus is the standard AXI4-Stream or AXI4 per GT lane. Each GT quad is comprised of four individual TX/RX pairs and allows for data to be sent individually over four lanes. Each lane can support any data width size that the AXI4-Stream or AXI4 interface allows. The line rate of the data sent can be adjusted to accommodate speeds from 0.5 Gb/s up to 28.21 Gb/s with different supported ref clocks. ThunderBus allows for up to four quads to be selected within a super logic region (SLR) which allows for a maximum of up to 16 lanes. It is not possible to have different line rates for each different quad if using multiple quads inside a single ThunderBus instantiation. To use different line rates for different quads, it is recommended to have a separate ThunderBus instantiation for those GT quads.
Integrating ThunderBus into a system
requires some handshaking between the IP core and user data. Before transmitting/enabling the
system, ThunderBus must be enumerated and assert the
core_ready_o signal signifying a ready state per lane. Once
the core is up and the core_ready_o signal is asserted, the
IP transmits/receives the AXI4-Stream/AXI4 data. The user data provided can run at independent clock frequencies into
ThunderBus for each interface. ThunderBus has an optional sideband per lane where you can
provide additional bits of data that gets transmitted intermittently. Using the sideband
causes no decrease in system performance.
To ensure that no data is lost, ThunderBus uses a credit system which provides back pressure to the input data. The cause for back pressure could be many things, such as the receiver not reading the data, receiver reading data slowly, or the input data is sending data faster than the GTs can support.
The data being sent via ThunderBus can
have separate clocks for each lane. The TX clock used to send the data can be different from
the RX clock of the ThunderBus receiving the data.
However, using different clocks will make the performance be limited either by the ThunderBus or the slower of the two user clock frequencies.
While the user clocks can be different for a lane, all other settings must be the same on the
corresponding lane in the receiving ThunderBus. As
such, if 64-bit AXI4-Stream data is sent on the TX with
only tdata, tready, and
tvalid signals, the ThunderBus receiving the data must have its RX data set to the same
configuration.