Lines Matching +full:host +full:- +full:only
10 - Introduction
11 -- Background
12 -- Xillybus Overview
14 - Usage
15 -- User interface
16 -- Synchronization
17 -- Seekable pipes
19 - Internals
20 -- Source code organization
21 -- Pipe attributes
22 -- Host never reads from the FPGA
23 -- Channels, pipes, and the message channel
24 -- Data streaming
25 -- Data granularity
26 -- Probing
27 -- Buffer allocation
28 -- The "nonempty" message (supporting poll)
35 ----------
50 again, pre-designed building blocks, IP cores, are often used. These are the
59 low-level bus protocol and the somewhat higher-level interface with the host
61 function is a well-known one (e.g. a video adapter card, or a NIC), it can
63 A special driver is then written to present the FPGA as a well-known interface
67 It's however common that the desired data communication doesn't fit any well-
73 interface logic for the FPGA, and write a simple ad-hoc driver for the kernel.
76 -----------------
79 elementary data transport between an FPGA and the host, providing pipe-like
80 data streams with a straightforward user interface. It's intended as a low-
81 effort solution for mixed FPGA-host projects, for which it makes sense to
82 have the project-specific part of the driver running in a user-space program.
91 communication to the user. At the host side, a character device file is used
93 the data. This is contrary to a common method of communicating through fixed-
111 --------------
113 On the host, all interface with Xillybus is done through /dev/xillybus_*
125 possibly pressing CTRL-C as some stage, even though the xillybus_* pipes have
130 * Supporting non-blocking I/O (by setting O_NONBLOCK on open() ).
137 A device file can be read only, write only or bidirectional. Bidirectional
142 ---------------
145 asynchronous. For a synchronous pipe, write() returns successfully only after
154 For FPGA to host pipes, asynchronous pipes allow data transfer from the FPGA
156 has been requested by a read() call. On synchronous pipes, only the amount
159 In summary, for synchronous pipes, data between the host and FPGA is
160 transmitted only to satisfy the read() or write() call currently handled
170 --------------
173 to the user logic at the FPGA. Such a pipe is also seekable on the host API.
184 ------------------------
194 which execute the DMA-related operations on the bus.
197 ---------------
204 * is_writebuf: The pipe's direction. A non-zero value means it's an FPGA to
205 host pipe (the FPGA "writes").
208 host and FPGA.
212 * allowpartial: A non-zero value means that a read() or write() (whichever
214 choice is a non-zero value, to match standard UNIX behavior.
216 * synchronous: A non-zero value means that the pipe is synchronous. See
223 * exclusive_open: A non-zero value forces exclusive opening of the associated
224 device file. If the device file is bidirectional, and already opened only in
227 * seekable: A non-zero value indicates that the pipe is seekable. See
230 * supports_nonempty: A non-zero value (which is typical) indicates that the
234 Host never reads from the FPGA
235 ------------------------------
241 host is up. In practice, nothing happens immediately in such a situation. But
242 if the host attempts to read from an address that is mapped to the PCI Express
248 the host is done through DMA. In particular, the Interrupt Service Routine
251 messages, which inform the host what the interrupt was about.
253 This mechanism is used on non-PCIe buses as well for the sake of uniformity.
257 ----------------------------------------
260 a data channel between the FPGA and the host. The distinction between channels
261 and pipes is necessary only because of channel 0, which is used for interrupt-
265 --------------
267 Even though a non-segmented data stream is presented to the user at both
269 for each channel. For the sake of illustration, let's take the FPGA to host
272 buffer is full, the FPGA informs the host about that (appending a
274 necessary). The host responds by making the data available for reading through
275 the character device. When all data has been read, the host writes on the
279 This is not good enough for creating a TCP/IP-like stream: If the data flow
286 But the FPGA will submit a partially filled buffer only if directed to do so
287 by the host. This situation occurs when the read() method has been blocking
288 for XILLY_RX_TIMEOUT jiffies (currently 10 ms), after which the host commands
293 A similar setting is used in the host to FPGA direction. The handling of
300 and yet enjoy a stream-like interface.
307 ----------------
318 This somewhat complicates the handling of host to FPGA streams, because
325 -------
330 Interface Description Table (IDT), is sent from the FPGA to the host. The
342 -----------------
367 ----------------------------------------
370 catch regarding the FPGA to host direction: The FPGA may have filled a DMA
371 buffer with some data, but not submitted that buffer. If the host waited for
374 host has not received any notification about this. This is solved with
378 These messages are used only to support poll() and select(). The IP core can