lkml.org 
[lkml]   [2012]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
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
>
>




\
 
 \ /
  Last update: 2012-12-04 23:21    [W:0.108 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site