1 2 ========================================== 3 Xillybus driver for generic FPGA interface 4 ========================================== 5 6 Author: Eli Billauer, Xillybus Ltd. (http://xillybus.com) 7 Email: firstname.lastname@example.org or as advertised on Xillybus' site. 8 9 Contents: 10 11 - Introduction 12 -- Background 13 -- Xillybus Overview 14 15 - Usage 16 -- User interface 17 -- Synchronization 18 -- Seekable pipes 19 20 - Internals 21 -- Source code organization 22 -- Pipe attributes 23 -- Host never reads from the FPGA 24 -- Channels, pipes, and the message channel 25 -- Data streaming 26 -- Data granularity 27 -- Probing 28 -- Buffer allocation 29 -- The "nonempty" message (supporting poll) 30 31 32 INTRODUCTION 33 ============ 34 35 Background 36 ---------- 37 38 An FPGA (Field Programmable Gate Array) is a piece of logic hardware, which 39 can be programmed to become virtually anything that is usually found as a 40 dedicated chipset: For instance, a display adapter, network interface card, 41 or even a processor with its peripherals. FPGAs are the LEGO of hardware: 42 Based upon certain building blocks, you make your own toys the way you like 43 them. It's usually pointless to reimplement something that is already 44 available on the market as a chipset, so FPGAs are mostly used when some 45 special functionality is needed, and the production volume is relatively low 46 (hence not justifying the development of an ASIC). 47 48 The challenge with FPGAs is that everything is implemented at a very low 49 level, even lower than assembly language. In order to allow FPGA designers to 50 focus on their specific project, and not reinvent the wheel over and over 51 again, pre-designed building blocks, IP cores, are often used. These are the 52 FPGA parallels of library functions. IP cores may implement certain 53 mathematical functions, a functional unit (e.g. a USB interface), an entire 54 processor (e.g. ARM) or anything that might come handy. Think of them as a 55 building block, with electrical wires dangling on the sides for connection to 56 other blocks. 57 58 One of the daunting tasks in FPGA design is communicating with a fullblown 59 operating system (actually, with the processor running it): Implementing the 60 low-level bus protocol and the somewhat higher-level interface with the host 61 (registers, interrupts, DMA etc.) is a project in itself. When the FPGA's 62 function is a well-known one (e.g. a video adapter card, or a NIC), it can 63 make sense to design the FPGA's interface logic specifically for the project. 64 A special driver is then written to present the FPGA as a well-known interface 65 to the kernel and/or user space. In that case, there is no reason to treat the 66 FPGA differently than any device on the bus. 67 68 It's however common that the desired data communication doesn't fit any well- 69 known peripheral function. Also, the effort of designing an elegant 70 abstraction for the data exchange is often considered too big. In those cases, 71 a quicker and possibly less elegant solution is sought: The driver is 72 effectively written as a user space program, leaving the kernel space part 73 with just elementary data transport. This still requires designing some 74 interface logic for the FPGA, and write a simple ad-hoc driver for the kernel. 75 76 Xillybus Overview 77 ----------------- 78 79 Xillybus is an IP core and a Linux driver. Together, they form a kit for 80 elementary data transport between an FPGA and the host, providing pipe-like 81 data streams with a straightforward user interface. It's intended as a low- 82 effort solution for mixed FPGA-host projects, for which it makes sense to 83 have the project-specific part of the driver running in a user-space program. 84 85 Since the communication requirements may vary significantly from one FPGA 86 project to another (the number of data pipes needed in each direction and 87 their attributes), there isn't one specific chunk of logic being the Xillybus 88 IP core. Rather, the IP core is configured and built based upon a 89 specification given by its end user. 90 91 Xillybus presents independent data streams, which resemble pipes or TCP/IP 92 communication to the user. At the host side, a character device file is used 93 just like any pipe file. On the FPGA side, hardware FIFOs are used to stream 94 the data. This is contrary to a common method of communicating through fixed- 95 sized buffers (even though such buffers are used by Xillybus under the hood). 96 There may be more than a hundred of these streams on a single IP core, but 97 also no more than one, depending on the configuration. 98 99 In order to ease the deployment of the Xillybus IP core, it contains a simple 100 data structure which completely defines the core's configuration. The Linux 101 driver fetches this data structure during its initialization process, and sets 102 up the DMA buffers and character devices accordingly. As a result, a single 103 driver is used to work out of the box with any Xillybus IP core. 104 105 The data structure just mentioned should not be confused with PCI's 106 configuration space or the Flattened Device Tree. 107 108 USAGE 109 ===== 110 111 User interface 112 -------------- 113 114 On the host, all interface with Xillybus is done through /dev/xillybus_* 115 device files, which are generated automatically as the drivers loads. The 116 names of these files depend on the IP core that is loaded in the FPGA (see 117 Probing below). To communicate with the FPGA, open the device file that 118 corresponds to the hardware FIFO you want to send data or receive data from, 119 and use plain write() or read() calls, just like with a regular pipe. In 120 particular, it makes perfect sense to go: 121 122 $ cat mydata > /dev/xillybus_thisfifo 123 124 $ cat /dev/xillybus_thatfifo > hisdata 125 126 possibly pressing CTRL-C as some stage, even though the xillybus_* pipes have 127 the capability to send an EOF (but may not use it). 128 129 The driver and hardware are designed to behave sensibly as pipes, including: 130 131 * Supporting non-blocking I/O (by setting O_NONBLOCK on open() ). 132 133 * Supporting poll() and select(). 134 135 * Being bandwidth efficient under load (using DMA) but also handle small 136 pieces of data sent across (like TCP/IP) by autoflushing. 137 138 A device file can be read only, write only or bidirectional. Bidirectional 139 device files are treated like two independent pipes (except for sharing a 140 "channel" structure in the implementation code). 141 142 Synchronization 143 --------------- 144 145 Xillybus pipes are configured (on the IP core) to be either synchronous or 146 asynchronous. For a synchronous pipe, write() returns successfully only after 147 some data has been submitted and acknowledged by the FPGA. This slows down 148 bulk data transfers, and is nearly impossible for use with streams that 149 require data at a constant rate: There is no data transmitted to the FPGA 150 between write() calls, in particular when the process loses the CPU. 151 152 When a pipe is configured asynchronous, write() returns if there was enough 153 room in the buffers to store any of the data in the buffers. 154 155 For FPGA to host pipes, asynchronous pipes allow data transfer from the FPGA 156 as soon as the respective device file is opened, regardless of if the data 157 has been requested by a read() call. On synchronous pipes, only the amount 158 of data requested by a read() call is transmitted. 159 160 In summary, for synchronous pipes, data between the host and FPGA is 161 transmitted only to satisfy the read() or write() call currently handled 162 by the driver, and those calls wait for the transmission to complete before 163 returning. 164 165 Note that the synchronization attribute has nothing to do with the possibility 166 that read() or write() completes less bytes than requested. There is a 167 separate configuration flag ("allowpartial") that determines whether such a 168 partial completion is allowed. 169 170 Seekable pipes 171 -------------- 172 173 A synchronous pipe can be configured to have the stream's position exposed 174 to the user logic at the FPGA. Such a pipe is also seekable on the host API. 175 With this feature, a memory or register interface can be attached on the 176 FPGA side to the seekable stream. Reading or writing to a certain address in 177 the attached memory is done by seeking to the desired address, and calling 178 read() or write() as required. 179 180 181 INTERNALS 182 ========= 183 184 Source code organization 185 ------------------------ 186 187 The Xillybus driver consists of a core module, xillybus_core.c, and modules 188 that depend on the specific bus interface (xillybus_of.c and xillybus_pcie.c). 189 190 The bus specific modules are those probed when a suitable device is found by 191 the kernel. Since the DMA mapping and synchronization functions, which are bus 192 dependent by their nature, are used by the core module, a 193 xilly_endpoint_hardware structure is passed to the core module on 194 initialization. This structure is populated with pointers to wrapper functions 195 which execute the DMA-related operations on the bus. 196 197 Pipe attributes 198 --------------- 199 200 Each pipe has a number of attributes which are set when the FPGA component 201 (IP core) is built. They are fetched from the IDT (the data structure which 202 defines the core's configuration, see Probing below) by xilly_setupchannels() 203 in xillybus_core.c as follows: 204 205 * is_writebuf: The pipe's direction. A non-zero value means it's an FPGA to 206 host pipe (the FPGA "writes"). 207 208 * channelnum: The pipe's identification number in communication between the 209 host and FPGA. 210 211 * format: The underlying data width. See Data Granularity below. 212 213 * allowpartial: A non-zero value means that a read() or write() (whichever 214 applies) may return with less than the requested number of bytes. The common 215 choice is a non-zero value, to match standard UNIX behavior. 216 217 * synchronous: A non-zero value means that the pipe is synchronous. See 218 Synchronization above. 219 220 * bufsize: Each DMA buffer's size. Always a power of two. 221 222 * bufnum: The number of buffers allocated for this pipe. Always a power of two. 223 224 * exclusive_open: A non-zero value forces exclusive opening of the associated 225 device file. If the device file is bidirectional, and already opened only in 226 one direction, the opposite direction may be opened once. 227 228 * seekable: A non-zero value indicates that the pipe is seekable. See 229 Seekable pipes above. 230 231 * supports_nonempty: A non-zero value (which is typical) indicates that the 232 hardware will send the messages that are necessary to support select() and 233 poll() for this pipe. 234 235 Host never reads from the FPGA 236 ------------------------------ 237 238 Even though PCI Express is hotpluggable in general, a typical motherboard 239 doesn't expect a card to go away all of the sudden. But since the PCIe card 240 is based upon reprogrammable logic, a sudden disappearance from the bus is 241 quite likely as a result of an accidental reprogramming of the FPGA while the 242 host is up. In practice, nothing happens immediately in such a situation. But 243 if the host attempts to read from an address that is mapped to the PCI Express 244 device, that leads to an immediate freeze of the system on some motherboards, 245 even though the PCIe standard requires a graceful recovery. 246 247 In order to avoid these freezes, the Xillybus driver refrains completely from 248 reading from the device's register space. All communication from the FPGA to 249 the host is done through DMA. In particular, the Interrupt Service Routine 250 doesn't follow the common practice of checking a status register when it's 251 invoked. Rather, the FPGA prepares a small buffer which contains short 252 messages, which inform the host what the interrupt was about. 253 254 This mechanism is used on non-PCIe buses as well for the sake of uniformity. 255 256 257 Channels, pipes, and the message channel 258 ---------------------------------------- 259 260 Each of the (possibly bidirectional) pipes presented to the user is allocated 261 a data channel between the FPGA and the host. The distinction between channels 262 and pipes is necessary only because of channel 0, which is used for interrupt- 263 related messages from the FPGA, and has no pipe attached to it. 264 265 Data streaming 266 -------------- 267 268 Even though a non-segmented data stream is presented to the user at both 269 sides, the implementation relies on a set of DMA buffers which is allocated 270 for each channel. For the sake of illustration, let's take the FPGA to host 271 direction: As data streams into the respective channel's interface in the 272 FPGA, the Xillybus IP core writes it to one of the DMA buffers. When the 273 buffer is full, the FPGA informs the host about that (appending a 274 XILLYMSG_OPCODE_RELEASEBUF message channel 0 and sending an interrupt if 275 necessary). The host responds by making the data available for reading through 276 the character device. When all data has been read, the host writes on the 277 the FPGA's buffer control register, allowing the buffer's overwriting. Flow 278 control mechanisms exist on both sides to prevent underflows and overflows. 279 280 This is not good enough for creating a TCP/IP-like stream: If the data flow 281 stops momentarily before a DMA buffer is filled, the intuitive expectation is 282 that the partial data in buffer will arrive anyhow, despite the buffer not 283 being completed. This is implemented by adding a field in the 284 XILLYMSG_OPCODE_RELEASEBUF message, through which the FPGA informs not just 285 which buffer is submitted, but how much data it contains. 286 287 But the FPGA will submit a partially filled buffer only if directed to do so 288 by the host. This situation occurs when the read() method has been blocking 289 for XILLY_RX_TIMEOUT jiffies (currently 10 ms), after which the host commands 290 the FPGA to submit a DMA buffer as soon as it can. This timeout mechanism 291 balances between bus bandwidth efficiency (preventing a lot of partially 292 filled buffers being sent) and a latency held fairly low for tails of data. 293 294 A similar setting is used in the host to FPGA direction. The handling of 295 partial DMA buffers is somewhat different, though. The user can tell the 296 driver to submit all data it has in the buffers to the FPGA, by issuing a 297 write() with the byte count set to zero. This is similar to a flush request, 298 but it doesn't block. There is also an autoflushing mechanism, which triggers 299 an equivalent flush roughly XILLY_RX_TIMEOUT jiffies after the last write(). 300 This allows the user to be oblivious about the underlying buffering mechanism 301 and yet enjoy a stream-like interface. 302 303 Note that the issue of partial buffer flushing is irrelevant for pipes having 304 the "synchronous" attribute nonzero, since synchronous pipes don't allow data 305 to lay around in the DMA buffers between read() and write() anyhow. 306 307 Data granularity 308 ---------------- 309 310 The data arrives or is sent at the FPGA as 8, 16 or 32 bit wide words, as 311 configured by the "format" attribute. Whenever possible, the driver attempts 312 to hide this when the pipe is accessed differently from its natural alignment. 313 For example, reading single bytes from a pipe with 32 bit granularity works 314 with no issues. Writing single bytes to pipes with 16 or 32 bit granularity 315 will also work, but the driver can't send partially completed words to the 316 FPGA, so the transmission of up to one word may be held until it's fully 317 occupied with user data. 318 319 This somewhat complicates the handling of host to FPGA streams, because 320 when a buffer is flushed, it may contain up to 3 bytes don't form a word in 321 the FPGA, and hence can't be sent. To prevent loss of data, these leftover 322 bytes need to be moved to the next buffer. The parts in xillybus_core.c 323 that mention "leftovers" in some way are related to this complication. 324 325 Probing 326 ------- 327 328 As mentioned earlier, the number of pipes that are created when the driver 329 loads and their attributes depend on the Xillybus IP core in the FPGA. During 330 the driver's initialization, a blob containing configuration info, the 331 Interface Description Table (IDT), is sent from the FPGA to the host. The 332 bootstrap process is done in three phases: 333 334 1. Acquire the length of the IDT, so a buffer can be allocated for it. This 335 is done by sending a quiesce command to the device, since the acknowledge 336 for this command contains the IDT's buffer length. 337 338 2. Acquire the IDT itself. 339 340 3. Create the interfaces according to the IDT. 341 342 Buffer allocation 343 ----------------- 344 345 In order to simplify the logic that prevents illegal boundary crossings of 346 PCIe packets, the following rule applies: If a buffer is smaller than 4kB, 347 it must not cross a 4kB boundary. Otherwise, it must be 4kB aligned. The 348 xilly_setupchannels() functions allocates these buffers by requesting whole 349 pages from the kernel, and diving them into DMA buffers as necessary. Since 350 all buffers' sizes are powers of two, it's possible to pack any set of such 351 buffers, with a maximal waste of one page of memory. 352 353 All buffers are allocated when the driver is loaded. This is necessary, 354 since large continuous physical memory segments are sometimes requested, 355 which are more likely to be available when the system is freshly booted. 356 357 The allocation of buffer memory takes place in the same order they appear in 358 the IDT. The driver relies on a rule that the pipes are sorted with decreasing 359 buffer size in the IDT. If a requested buffer is larger or equal to a page, 360 the necessary number of pages is requested from the kernel, and these are 361 used for this buffer. If the requested buffer is smaller than a page, one 362 single page is requested from the kernel, and that page is partially used. 363 Or, if there already is a partially used page at hand, the buffer is packed 364 into that page. It can be shown that all pages requested from the kernel 365 (except possibly for the last) are 100% utilized this way. 366 367 The "nonempty" message (supporting poll) 368 --------------------------------------- 369 370 In order to support the "poll" method (and hence select() ), there is a small 371 catch regarding the FPGA to host direction: The FPGA may have filled a DMA 372 buffer with some data, but not submitted that buffer. If the host waited for 373 the buffer's submission by the FPGA, there would be a possibility that the 374 FPGA side has sent data, but a select() call would still block, because the 375 host has not received any notification about this. This is solved with 376 XILLYMSG_OPCODE_NONEMPTY messages sent by the FPGA when a channel goes from 377 completely empty to containing some data. 378 379 These messages are used only to support poll() and select(). The IP core can 380 be configured not to send them for a slight reduction of bandwidth.