This subsystem will configure an FPGA attached to your host by sending it a bitstream you provide. You still have to use your FPGAs vendor tools to generate the bitstream.
One popular use case is for System-on-Chip (SoC) designs that pair a Processor System (PS) with Programmable Logic (PL); once the PS is running the kernel, the FPGA Manager can be used to program the PL fabric from kernel space.
FPGA Manager has another handy feature for FPGA images that implement new peripherals on buses like SPI, I2C, PCI, AXI, etc. These devices are not "discoverable" in the sense that they are capable of communicating to the kernel what driver must be loaded to support them. So in along with a bitstream, FPGA Manager accepts a device tree overlay which indicates to the kernel what drivers to load for the new resources implemented by the configured FPGA. This causes the kernel to probe the requisite drivers after the FPGA configuration has completed. The FPGA manager can also unload drivers for devices implemented in an FPGA that is being reconfigured.
Unfortunately, in LTS kernels 4.9 and 4.14, while SoC vendors include support for their own PL targets, the FPGA Manager subsystem was written as a singleton; once you've configured e.g, the PL, you can't configure additional peripheral FPGAs.
The FPGA Manager in K4.9 and K4.14 worked fine to fully manage a single FPGA through multiple configuration cycles through both the sysfs and the configfs interfaces.
On a system with multiple FPGAs, FPGA Manager would fully manage any one of them, as long as it was the first device it probed. The second probe would partially fail after creating nodes on sysfs, and a third probe would crash the kernel.
For that particular system, the upstream vendor hasn't rolled out K4.19 support yet. My initial impression of the FPGA Manager code in 4.19 is that this may be fixed (that an FPGA Manager looks to be allocated per driver instead of one global singleton) but I haven't backported it for testing yet.
I think the interfaces FPGA Manager are well designed, its seems to be adequately expressive for even exotic uses, but I would love to see the implementation mature a bit.
I know the term but I can’t quite understand how to interpret it in this specific context. Does it mean you can only program an FPGA once? Only one FPGA? One object per bus?
Admittedly, I'm pretty ignorant of FPGA's right now, but I was curious about PCIe based boards a while back and was able to find some moderately priced ones such as
It's around $300, which might not be cheap, but it's certainly more affordable than other I've seen which are very much out of the range of any hobbyists.
I guess it depends on your own definition of worth and what’s worthy of a $$$ signifier of expense, but you can get pretty powerful FPGAs for $100-200 these days, and respectable ones that can serve many use cases for under $100.
Throughput? Programming throughput or I/O? You should be able to saturate the bus. It's all dependent on what kind of processing takes place on either end.
AWS offers FPGAs for rent [1] starting at around 1.50 USD/hr -- perfect if you want to dip your toes in without a huge capital expense.
You can find some shitcoin mining flops that are $300-$400 worth of hardware being sold off for $60 that are PCIe cards. There are a few examples in the LiteX project.
Came across a pretty clear video with an iCE40 and a rasPI showing the concept, though its from 2017. Presumably it would be a similar process to do this with a pci card? https://www.youtube.com/watch?v=nIEB1VAGUcs
One popular use case is for System-on-Chip (SoC) designs that pair a Processor System (PS) with Programmable Logic (PL); once the PS is running the kernel, the FPGA Manager can be used to program the PL fabric from kernel space.
FPGA Manager has another handy feature for FPGA images that implement new peripherals on buses like SPI, I2C, PCI, AXI, etc. These devices are not "discoverable" in the sense that they are capable of communicating to the kernel what driver must be loaded to support them. So in along with a bitstream, FPGA Manager accepts a device tree overlay which indicates to the kernel what drivers to load for the new resources implemented by the configured FPGA. This causes the kernel to probe the requisite drivers after the FPGA configuration has completed. The FPGA manager can also unload drivers for devices implemented in an FPGA that is being reconfigured.
Unfortunately, in LTS kernels 4.9 and 4.14, while SoC vendors include support for their own PL targets, the FPGA Manager subsystem was written as a singleton; once you've configured e.g, the PL, you can't configure additional peripheral FPGAs.