Documentation/fpga/dfl.txt

   1 ===============================================================================
   2               FPGA Device Feature List (DFL) Framework Overview
   3 -------------------------------------------------------------------------------
   4                 Enno Luebbers <enno.luebbers@intel.com>
   5                 Xiao Guangrong <guangrong.xiao@linux.intel.com>
   6                 Wu Hao <hao.wu@intel.com>
   7
   8 The Device Feature List (DFL) FPGA framework (and drivers according to this
   9 this framework) hides the very details of low layer hardwares and provides
  10 unified interfaces to userspace. Applications could use these interfaces to
  11 configure, enumerate, open and access FPGA accelerators on platforms which
  12 implement the DFL in the device memory. Besides this, the DFL framework
  13 enables system level management functions such as FPGA reconfiguration.
  14
  15
  16 Device Feature List (DFL) Overview
  17 ==================================
  18 Device Feature List (DFL) defines a linked list of feature headers within the
  19 device MMIO space to provide an extensible way of adding features. Software can
  20 walk through these predefined data structures to enumerate FPGA features:
  21 FPGA Interface Unit (FIU), Accelerated Function Unit (AFU) and Private Features,
  22 as illustrated below:
  23
  24     Header            Header            Header            Header
  25  +----------+  +-->+----------+  +-->+----------+  +-->+----------+
  26  |   Type   |  |   |  Type    |  |   |  Type    |  |   |  Type    |
  27  |   FIU    |  |   | Private  |  |   | Private  |  |   | Private  |
  28  +----------+  |   | Feature  |  |   | Feature  |  |   | Feature  |
  29  | Next_DFH |--+   +----------+  |   +----------+  |   +----------+
  30  +----------+      | Next_DFH |--+   | Next_DFH |--+   | Next_DFH |--> NULL
  31  |    ID    |      +----------+      +----------+      +----------+
  32  +----------+      |    ID    |      |    ID    |      |    ID    |
  33  | Next_AFU |--+   +----------+      +----------+      +----------+
  34  +----------+  |   | Feature  |      | Feature  |      | Feature  |
  35  |  Header  |  |   | Register |      | Register |      | Register |
  36  | Register |  |   |   Set    |      |   Set    |      |   Set    |
  37  |   Set    |  |   +----------+      +----------+      +----------+
  38  +----------+  |      Header
  39                +-->+----------+
  40                    |   Type   |
  41                    |   AFU    |
  42                    +----------+
  43                    | Next_DFH |--> NULL
  44                    +----------+
  45                    |   GUID   |
  46                    +----------+
  47                    |  Header  |
  48                    | Register |
  49                    |   Set    |
  50                    +----------+
  51
  52 FPGA Interface Unit (FIU) represents a standalone functional unit for the
  53 interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more
  54 descriptions on FME and Port in later sections).
  55
  56 Accelerated Function Unit (AFU) represents a FPGA programmable region and
  57 always connects to a FIU (e.g. a Port) as its child as illustrated above.
  58
  59 Private Features represent sub features of the FIU and AFU. They could be
  60 various function blocks with different IDs, but all private features which
  61 belong to the same FIU or AFU, must be linked to one list via the Next Device
  62 Feature Header (Next_DFH) pointer.
  63
  64 Each FIU, AFU and Private Feature could implement its own functional registers.
  65 The functional register set for FIU and AFU, is named as Header Register Set,
  66 e.g. FME Header Register Set, and the one for Private Feature, is named as
  67 Feature Register Set, e.g. FME Partial Reconfiguration Feature Register Set.
  68
  69 This Device Feature List provides a way of linking features together, it's
  70 convenient for software to locate each feature by walking through this list,
  71 and can be implemented in register regions of any FPGA device.
  72
  73
  74 FIU - FME (FPGA Management Engine)
  75 ==================================
  76 The FPGA Management Engine performs reconfiguration and other infrastructure
  77 functions. Each FPGA device only has one FME.
  78
  79 User-space applications can acquire exclusive access to the FME using open(),
  80 and release it using close().
  81
  82 The following functions are exposed through ioctls:
  83
  84  Get driver API version (DFL_FPGA_GET_API_VERSION)
  85  Check for extensions (DFL_FPGA_CHECK_EXTENSION)
  86  Program bitstream (DFL_FPGA_FME_PORT_PR)
  87
  88 More functions are exposed through sysfs
  89 (/sys/class/fpga_region/regionX/dfl-fme.n/):
  90
  91  Read bitstream ID (bitstream_id)
  92      bitstream_id indicates version of the static FPGA region.
  93
  94  Read bitstream metadata (bitstream_metadata)
  95      bitstream_metadata includes detailed information of static FPGA region,
  96      e.g. synthesis date and seed.
  97
  98  Read number of ports (ports_num)
  99      one FPGA device may have more than one port, this sysfs interface indicates
 100      how many ports the FPGA device has.
 101
 102
 103 FIU - PORT
 104 ==========
 105 A port represents the interface between the static FPGA fabric and a partially
 106 reconfigurable region containing an AFU. It controls the communication from SW
 107 to the accelerator and exposes features such as reset and debug. Each FPGA
 108 device may have more than one port, but always one AFU per port.
 109
 110
 111 AFU
 112 ===
 113 An AFU is attached to a port FIU and exposes a fixed length MMIO region to be
 114 used for accelerator-specific control registers.
 115
 116 User-space applications can acquire exclusive access to an AFU attached to a
 117 port by using open() on the port device node and release it using close().
 118
 119 The following functions are exposed through ioctls:
 120
 121  Get driver API version (DFL_FPGA_GET_API_VERSION)
 122  Check for extensions (DFL_FPGA_CHECK_EXTENSION)
 123  Get port info (DFL_FPGA_PORT_GET_INFO)
 124  Get MMIO region info (DFL_FPGA_PORT_GET_REGION_INFO)
 125  Map DMA buffer (DFL_FPGA_PORT_DMA_MAP)
 126  Unmap DMA buffer (DFL_FPGA_PORT_DMA_UNMAP)
 127  Reset AFU (*DFL_FPGA_PORT_RESET)
 128
 129 *DFL_FPGA_PORT_RESET: reset the FPGA Port and its AFU. Userspace can do Port
 130 reset at any time, e.g. during DMA or Partial Reconfiguration. But it should
 131 never cause any system level issue, only functional failure (e.g. DMA or PR
 132 operation failure) and be recoverable from the failure.
 133
 134 User-space applications can also mmap() accelerator MMIO regions.
 135
 136 More functions are exposed through sysfs:
 137 (/sys/class/fpga_region/<regionX>/<dfl-port.m>/):
 138
 139  Read Accelerator GUID (afu_id)
 140      afu_id indicates which PR bitstream is programmed to this AFU.
 141
 142
 143 DFL Framework Overview
 144 ======================
 145
 146          +----------+    +--------+ +--------+ +--------+
 147          |   FME    |    |  AFU   | |  AFU   | |  AFU   |
 148          |  Module  |    | Module | | Module | | Module |
 149          +----------+    +--------+ +--------+ +--------+
 150                  +-----------------------+
 151                  | FPGA Container Device |    Device Feature List
 152                  |  (FPGA Base Region)   |         Framework
 153                  +-----------------------+
 154 --------------------------------------------------------------------
 155                +----------------------------+
 156                |   FPGA DFL Device Module   |
 157                | (e.g. PCIE/Platform Device)|
 158                +----------------------------+
 159                  +------------------------+
 160                  |  FPGA Hardware Device  |
 161                  +------------------------+
 162
 163 DFL framework in kernel provides common interfaces to create container device
 164 (FPGA base region), discover feature devices and their private features from the
 165 given Device Feature Lists and create platform devices for feature devices
 166 (e.g. FME, Port and AFU) with related resources under the container device. It
 167 also abstracts operations for the private features and exposes common ops to
 168 feature device drivers.
 169
 170 The FPGA DFL Device could be different hardwares, e.g. PCIe device, platform
 171 device and etc. Its driver module is always loaded first once the device is
 172 created by the system. This driver plays an infrastructural role in the
 173 driver architecture. It locates the DFLs in the device memory, handles them
 174 and related resources to common interfaces from DFL framework for enumeration.
 175 (Please refer to drivers/fpga/dfl.c for detailed enumeration APIs).
 176
 177 The FPGA Management Engine (FME) driver is a platform driver which is loaded
 178 automatically after FME platform device creation from the DFL device module. It
 179 provides the key features for FPGA management, including:
 180
 181         a) Expose static FPGA region information, e.g. version and metadata.
 182            Users can read related information via sysfs interfaces exposed
 183            by FME driver.
 184
 185         b) Partial Reconfiguration. The FME driver creates FPGA manager, FPGA
 186            bridges and FPGA regions during PR sub feature initialization. Once
 187            it receives a DFL_FPGA_FME_PORT_PR ioctl from user, it invokes the
 188            common interface function from FPGA Region to complete the partial
 189            reconfiguration of the PR bitstream to the given port.
 190
 191 Similar to the FME driver, the FPGA Accelerated Function Unit (AFU) driver is
 192 probed once the AFU platform device is created. The main function of this module
 193 is to provide an interface for userspace applications to access the individual
 194 accelerators, including basic reset control on port, AFU MMIO region export, dma
 195 buffer mapping service functions.
 196
 197 After feature platform devices creation, matched platform drivers will be loaded
 198 automatically to handle different functionalities. Please refer to next sections
 199 for detailed information on functional units which have been already implemented
 200 under this DFL framework.
 201
 202
 203 Partial Reconfiguration
 204 =======================
 205 As mentioned above, accelerators can be reconfigured through partial
 206 reconfiguration of a PR bitstream file. The PR bitstream file must have been
 207 generated for the exact static FPGA region and targeted reconfigurable region
 208 (port) of the FPGA, otherwise, the reconfiguration operation will fail and
 209 possibly cause system instability. This compatibility can be checked by
 210 comparing the compatibility ID noted in the header of PR bitstream file against
 211 the compat_id exposed by the target FPGA region. This check is usually done by
 212 userspace before calling the reconfiguration IOCTL.
 213
 214
 215 Device enumeration
 216 ==================
 217 This section introduces how applications enumerate the fpga device from
 218 the sysfs hierarchy under /sys/class/fpga_region.
 219
 220 In the example below, two DFL based FPGA devices are installed in the host. Each
 221 fpga device has one FME and two ports (AFUs).
 222
 223 FPGA regions are created under /sys/class/fpga_region/
 224
 225         /sys/class/fpga_region/region0
 226         /sys/class/fpga_region/region1
 227         /sys/class/fpga_region/region2
 228         ...
 229
 230 Application needs to search each regionX folder, if feature device is found,
 231 (e.g. "dfl-port.n" or "dfl-fme.m" is found), then it's the base
 232 fpga region which represents the FPGA device.
 233
 234 Each base region has one FME and two ports (AFUs) as child devices:
 235
 236         /sys/class/fpga_region/region0/dfl-fme.0
 237         /sys/class/fpga_region/region0/dfl-port.0
 238         /sys/class/fpga_region/region0/dfl-port.1
 239         ...
 240
 241         /sys/class/fpga_region/region3/dfl-fme.1
 242         /sys/class/fpga_region/region3/dfl-port.2
 243         /sys/class/fpga_region/region3/dfl-port.3
 244         ...
 245
 246 In general, the FME/AFU sysfs interfaces are named as follows:
 247
 248         /sys/class/fpga_region/<regionX>/<dfl-fme.n>/
 249         /sys/class/fpga_region/<regionX>/<dfl-port.m>/
 250
 251 with 'n' consecutively numbering all FMEs and 'm' consecutively numbering all
 252 ports.
 253
 254 The device nodes used for ioctl() or mmap() can be referenced through:
 255
 256         /sys/class/fpga_region/<regionX>/<dfl-fme.n>/dev
 257         /sys/class/fpga_region/<regionX>/<dfl-port.n>/dev
 258
 259
 260 Add new FIUs support
 261 ====================
 262 It's possible that developers made some new function blocks (FIUs) under this
 263 DFL framework, then new platform device driver needs to be developed for the
 264 new feature dev (FIU) following the same way as existing feature dev drivers
 265 (e.g. FME and Port/AFU platform device driver). Besides that, it requires
 266 modification on DFL framework enumeration code too, for new FIU type detection
 267 and related platform devices creation.
 268
 269
 270 Add new private features support
 271 ================================
 272 In some cases, we may need to add some new private features to existing FIUs
 273 (e.g. FME or Port). Developers don't need to touch enumeration code in DFL
 274 framework, as each private feature will be parsed automatically and related
 275 mmio resources can be found under FIU platform device created by DFL framework.
 276 Developer only needs to provide a sub feature driver with matched feature id.
 277 FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
 278 could be a reference.
 279
 280
 281 Open discussion
 282 ===============
 283 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
 284 to user now. In the future, if unified user interfaces for reconfiguration are
 285 added, FME driver should switch to them from ioctl interface.