Platform Features

Different platform releases can include one or more of the following features. Features use resources in the static region of the platform. Alveo Platforms lists the features supported by each platform.

Table 1. Feature Types
Feature	Description
P2P	Shorthand for PCIe® peer-to-peer communication. Enables direct DMA transfer of data between two Alveo Data Center accelerator cards via the PCIe bus without temporarily buffering data within the host DDR memory. Without this feature the host CPU and memory are used for card-to-card communication. For more information, see XRT documentation on PCIe Peer-to-Peer (P2P).
M2M	Enabling on-card data transfers between card memory resources. Platforms that do not support this feature only transfer memory through host CPU and memory. For more information, see XRT documentation on Memory-to-Memory (M2M) support.
HM	Shorthand for PCIe host memory transfers. The AXI subordinate interface allows the card FPGA to directly read and write to host memory, bypassing the DMA. For more information, see XRT documentation on PCIe host memory.
DFX	Dynamic function eXchange (DFX) technology allows the card to change functionality on the fly without power-cycling the server, which enables some platforms to reconfigure DMA links. Current platforms come in one of two DFX variants. DFX-1RP The PCIe core and the DMA engine are combined and reside in the static region of the platform. These are also known as one stage platforms. DFX-2RP The PCIe core resides in the static region of the FPGA (also known as the base) while the DMA engine is dynamically loaded into a new reconfiguration region used by the shell partition. These are also known as two stage platforms. For more information, see Alveo Platform Loading Overview in XRT Documentation.
GT	Shorthand for Gigabit Transceiver (GT) kernel connection. This platform allows for transceiver connection of user-provided MAC within an RTL-kernel for in-line QSFP networking access.
CT	Platforms supporting clock throttling (CT) allow the card to operate within defined thermal and electrical limits by dynamically adjusting the kernel clock frequency. This feature is disabled by default and must be must be enabled (see xbmgmt configure command). When enabled, clock throttling reduces the kernel clock frequency if either electrical or thermal card sensor values reach or exceed their respective clock throttling threshold. By lowering the clock frequency, clock throttling reduces the required power and subsequently generated heat. Only when all sensor values fall below their respective clock throttling threshold values will the kernel clock be restored to full performance. Clock throttling electrical and thermal thresholds are listed in each respective platform section. Note: All cards, regardless of platform, have clock and card shutdown logic to protect the card by ensuring it operates within its electrical and thermal limits. Clock shutdown is defined below with thresholds also listed in each respective platform section. Card shutdown details can be found in the respective data sheet. Clock shutdown removes the kernel clock (setting frequency to zero) when either electrical or thermal sensor values reach or exceed their respective clock shutdown thresholds. This will reduce both power and subsequently generated heat. However, removing the clocks will cause an AXI firewall trip and may crash the host application. Because the card ends up in an unknown state, the XRT driver will issue a command to reset the card. It typically takes a couple minutes until the card is usable again. Clock shutdown is always enabled and can not be changed. Tip: Review the Linux dmesg command output to determine if a protection was activated. Below is an example of the clock shutdown messaging: `[ 777.531353] clock.m clock.m.23068673: dev ffff97a9e5c3c810, clock_status_check: Critical temperature or power event, kernel clocks have been stopped.`