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 8The Device Feature List (DFL) FPGA framework (and drivers according to this 9this framework) hides the very details of low layer hardwares and provides 10unified interfaces to userspace. Applications could use these interfaces to 11configure, enumerate, open and access FPGA accelerators on platforms which 12implement the DFL in the device memory. Besides this, the DFL framework 13enables system level management functions such as FPGA reconfiguration. 14 15 16Device Feature List (DFL) Overview 17================================== 18Device Feature List (DFL) defines a linked list of feature headers within the 19device MMIO space to provide an extensible way of adding features. Software can 20walk through these predefined data structures to enumerate FPGA features: 21FPGA Interface Unit (FIU), Accelerated Function Unit (AFU) and Private Features, 22as 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 52FPGA Interface Unit (FIU) represents a standalone functional unit for the 53interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more 54descriptions on FME and Port in later sections). 55 56Accelerated Function Unit (AFU) represents a FPGA programmable region and 57always connects to a FIU (e.g. a Port) as its child as illustrated above. 58 59Private Features represent sub features of the FIU and AFU. They could be 60various function blocks with different IDs, but all private features which 61belong to the same FIU or AFU, must be linked to one list via the Next Device 62Feature Header (Next_DFH) pointer. 63 64Each FIU, AFU and Private Feature could implement its own functional registers. 65The functional register set for FIU and AFU, is named as Header Register Set, 66e.g. FME Header Register Set, and the one for Private Feature, is named as 67Feature Register Set, e.g. FME Partial Reconfiguration Feature Register Set. 68 69This Device Feature List provides a way of linking features together, it's 70convenient for software to locate each feature by walking through this list, 71and can be implemented in register regions of any FPGA device. 72 73 74FIU - FME (FPGA Management Engine) 75================================== 76The FPGA Management Engine performs reconfiguration and other infrastructure 77functions. Each FPGA device only has one FME. 78 79User-space applications can acquire exclusive access to the FME using open(), 80and release it using close(). 81 82The 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 88More 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 103FIU - PORT 104========== 105A port represents the interface between the static FPGA fabric and a partially 106reconfigurable region containing an AFU. It controls the communication from SW 107to the accelerator and exposes features such as reset and debug. Each FPGA 108device may have more than one port, but always one AFU per port. 109 110 111AFU 112=== 113An AFU is attached to a port FIU and exposes a fixed length MMIO region to be 114used for accelerator-specific control registers. 115 116User-space applications can acquire exclusive access to an AFU attached to a 117port by using open() on the port device node and release it using close(). 118 119The 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 130reset at any time, e.g. during DMA or Partial Reconfiguration. But it should 131never cause any system level issue, only functional failure (e.g. DMA or PR 132operation failure) and be recoverable from the failure. 133 134User-space applications can also mmap() accelerator MMIO regions. 135 136More 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 143DFL 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 163DFL framework in kernel provides common interfaces to create container device 164(FPGA base region), discover feature devices and their private features from the 165given 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 167also abstracts operations for the private features and exposes common ops to 168feature device drivers. 169 170The FPGA DFL Device could be different hardwares, e.g. PCIe device, platform 171device and etc. Its driver module is always loaded first once the device is 172created by the system. This driver plays an infrastructural role in the 173driver architecture. It locates the DFLs in the device memory, handles them 174and related resources to common interfaces from DFL framework for enumeration. 175(Please refer to drivers/fpga/dfl.c for detailed enumeration APIs). 176 177The FPGA Management Engine (FME) driver is a platform driver which is loaded 178automatically after FME platform device creation from the DFL device module. It 179provides 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 191Similar to the FME driver, the FPGA Accelerated Function Unit (AFU) driver is 192probed once the AFU platform device is created. The main function of this module 193is to provide an interface for userspace applications to access the individual 194accelerators, including basic reset control on port, AFU MMIO region export, dma 195buffer mapping service functions. 196 197After feature platform devices creation, matched platform drivers will be loaded 198automatically to handle different functionalities. Please refer to next sections 199for detailed information on functional units which have been already implemented 200under this DFL framework. 201 202 203Partial Reconfiguration 204======================= 205As mentioned above, accelerators can be reconfigured through partial 206reconfiguration of a PR bitstream file. The PR bitstream file must have been 207generated for the exact static FPGA region and targeted reconfigurable region 208(port) of the FPGA, otherwise, the reconfiguration operation will fail and 209possibly cause system instability. This compatibility can be checked by 210comparing the compatibility ID noted in the header of PR bitstream file against 211the compat_id exposed by the target FPGA region. This check is usually done by 212userspace before calling the reconfiguration IOCTL. 213 214 215Device enumeration 216================== 217This section introduces how applications enumerate the fpga device from 218the sysfs hierarchy under /sys/class/fpga_region. 219 220In the example below, two DFL based FPGA devices are installed in the host. Each 221fpga device has one FME and two ports (AFUs). 222 223FPGA 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 230Application 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 232fpga region which represents the FPGA device. 233 234Each 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 246In 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 251with 'n' consecutively numbering all FMEs and 'm' consecutively numbering all 252ports. 253 254The 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 260Add new FIUs support 261==================== 262It's possible that developers made some new function blocks (FIUs) under this 263DFL framework, then new platform device driver needs to be developed for the 264new 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 266modification on DFL framework enumeration code too, for new FIU type detection 267and related platform devices creation. 268 269 270Add new private features support 271================================ 272In 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 274framework, as each private feature will be parsed automatically and related 275mmio resources can be found under FIU platform device created by DFL framework. 276Developer only needs to provide a sub feature driver with matched feature id. 277FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c) 278could be a reference. 279 280 281Open discussion 282=============== 283FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration 284to user now. In the future, if unified user interfaces for reconfiguration are 285added, FME driver should switch to them from ioctl interface. 286