Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA(programmable logic)

From: Eli Billauer
Date: Tue Dec 04 2012 - 16:44:11 EST


On 12/04/2012 10:43 PM, Arnd Bergmann wrote:
On Tuesday 04 December 2012, Eli Billauer wrote:
I'm currently writing some documentation which will cover the API and
also help reading the code, I hope. It takes some time...

Until it's done, let's look at a usage example: Suppose that the FPGA's
application is to receive a high-speed bitstream with time multiplexed
data, demultiplex the bitstream into individual channel streams, and
send each channel's data to the host. And let's say that there are 64
channels in original bitstream. So the FPGA has now 64 independent
sources of data.

For that purpose, the Xillybus IP core (on the FPGA) is configured to
create 64 pipes for FPGA to host communication. The names of these pipes
(say, "chan00", "chan01", ...) are also stored in the FPGA.

When the driver starts, it queries the FPGA for its Xillybus
configuration, and creates 64 device nodes: /dev/xillybus_chan00,
/dev/xillybus_chan01, ... /dev/xillybus_chan63.

If the user wants to dump the data in channel 43 into a file, it's just:

$ cat /dev/xillybus_chan43> mydump.dat

I hope this clarified things a bit.

I can't see how the firmware interface would help here.
I think a lot of us (including Greg and me) were confused about
the purpose of the driver, since you did not include much documentation.
I'm really sorry about this. I begin to realize the confusion now, and Xillybus is indeed not a bus.
The request_firmware interface would be useful for loading a model
into the FPGA, but that doesn't seem to be what your driver is
concerned with.
Indeed, Xillybus is not about loading the configuration bitstream for the FPGA.
It's also a bit confusing because it doesn't appear
to be a "bus" in the Linux sense of being something that provides
an abstract interface between hardware and kernel device drivers.

Instead, you just have a user interface for those FPGA models that
don't need a kernel level driver themselves.
I'm not sure I would agree on that. Xillybus consists of an IP core (sort-of library function for an FPGA), and a driver. At the OS level, it's no different than any PCI card and its driver. I call it "generic" because it's not tailored to transport a certain kind of data (say, audio samples or video frames).

In the FPGA world, passing data to or from a processor is a project in itself, in particular if the latter runs a fullblown operating system. What Xillybus does, is supplying a simple interface on both sides: A hardware FIFO on the logic side for the FPGA designer to interface with, and a plain device file on the host's side. The whole point of this project is to make everything simple and intuitive.
This is something
that sits on a somewhat higher level -- if we want a generic FPGA
interface, this would not be directly connected to a PCI or AMBA
bus, but instead connect to an FPGA bus that still needs to be
invented.
For what it's worth, the driver is now divided into three parts: A xillybus_core, a module for PCIe and a module for Open Firmware interface. The two latter depend on the first, of course.
In the user interface side that you provide seems to be on the
same interface level as the USB passthrough interface implemented
in drivers/usb/core/devio.c, which has a complex set of ioctls
but does serve a very similar purpose. Greg may want to comment
on whether that is actually a good interface or not, since I assume
he has some experience with how well it worked for USB.

My feeling for now is that we actually need both an in-kernel
interface and a user interface, with the complication that the
hardware should not care which of the two is used for a particular
instance.
I'm not sure what you meant here, but I'll mention this: FPGA designers using the IP core don't need to care what the transport is, PCIe, AMBA or anything else. They just see a FIFO. Neither is the host influenced by this, except for loading a different front end module.
For the user interface, something that is purely read/write
based is really nice, though I wonder if using debugfs or sysfs
for this would be more appropriate than having lots of character
devices for a single piece of hardware.
And this is where the term "hardware" becomes elusive with an FPGA: One could look at the entire FPGA chip as a single piece of hardware, and expect everything to be packed into a few device nodes.

Or, one could look at each of the hardware FIFOs in the FPGA as something like a sound card, an independent piece of hardware, which is the way I chose to look at it. That's why I allocated a character device for each.

Since the project has been in use by others for about a year (academic users and in the industry), I know at this point that the user interface is convenient to work with (judging from feedback I received). So I would be quite reluctant to make radical changes in the user interface, in particular knowing that it works well and makes UNIX guys feel at home.

Regards,
Eli


Arnd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/