Lines Matching refs:FPGA

3                Xillybus driver for generic FPGA interface
23   -- Host never reads from the FPGA
38 An FPGA (Field Programmable Gate Array) is a piece of logic hardware, which
49 level, even lower than assembly language. In order to allow FPGA designers to
52 FPGA parallels of library functions. IP cores may implement certain
58 One of the daunting tasks in FPGA design is communicating with a fullblown
61 (registers, interrupts, DMA etc.) is a project in itself. When the FPGA's
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
66 FPGA differently than any device on the bus.
74 interface logic for the FPGA, and write a simple ad-hoc driver for the kernel.
80 elementary data transport between an FPGA and the host, providing pipe-like
82 effort solution for mixed FPGA-host projects, for which it makes sense to
85 Since the communication requirements may vary significantly from one FPGA
93 just like any pipe file. On the FPGA side, hardware FIFOs are used to stream
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
147 some data has been submitted and acknowledged by the FPGA. This slows down
149 require data at a constant rate: There is no data transmitted to the FPGA
155 For FPGA to host pipes, asynchronous pipes allow data transfer from the FPGA
160 In summary, for synchronous pipes, data between the host and FPGA is
174 to the user logic at the FPGA. Such a pipe is also seekable on the host API.
176 FPGA side to the seekable stream. Reading or writing to a certain address in
200 Each pipe has a number of attributes which are set when the FPGA component
205 * is_writebuf: The pipe's direction. A non-zero value means it's an FPGA to
206   host pipe (the FPGA "writes").
209   host and FPGA.
235 Host never reads from the FPGA
241 quite likely as a result of an accidental reprogramming of the FPGA while the
248 reading from the device's register space. All communication from the FPGA to
251 invoked. Rather, the FPGA prepares a small buffer which contains short
261 a data channel between the FPGA and the host. The distinction between channels
263 related messages from the FPGA, and has no pipe attached to it.
270 for each channel. For the sake of illustration, let's take the FPGA to host
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
277 the FPGA's buffer control register, allowing the buffer's overwriting. Flow
284 XILLYMSG_OPCODE_RELEASEBUF message, through which the FPGA informs not just
287 But the FPGA will submit a partially filled buffer only if directed to do so
290 the FPGA to submit a DMA buffer as soon as it can. This timeout mechanism
294 A similar setting is used in the host to FPGA direction. The handling of
296 driver to submit all data it has in the buffers to the FPGA, by issuing a
310 The data arrives or is sent at the FPGA as 8, 16 or 32 bit wide words, as
316 FPGA, so the transmission of up to one word may be held until it's fully
319 This somewhat complicates the handling of host to FPGA streams, because
321 the FPGA, and hence can't be sent. To prevent loss of data, these leftover
329 loads and their attributes depend on the Xillybus IP core in the FPGA. During
331 Interface Description Table (IDT), is sent from the FPGA to the host. The
371 catch regarding the FPGA to host direction: The FPGA may have filled a DMA
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
376 XILLYMSG_OPCODE_NONEMPTY messages sent by the FPGA when a channel goes from