 Alright I'll just start. Sorry about that, maybe we'll get it working. My name is Moritz Fischer. I work for National Instruments, which is a US-based company in the Ethos research team. We make software-defined radios. Outside of building software-defined radios, which you can learn about in the SDR track that my colleagues are organizing, I am also one of the kernel maintainers for the FPGA Manager framework. The FPGA Manager framework is fairly recent. We started out around Linux 4.4 when we first got merged all the support for the basic framework and Zinc and SOC FPGA. Just gonna work. Okay I'll just keep talking. For Zinc and SOC FPGA, since then we've gotten a bunch of other drivers that got merged. It's pretty interesting because they were from different types of systems. One of them is actually still platform, board file based. There's a bunch of device tree based ones and now new is the PCI express ones, which turned out to be a bit problematic because when we first started out with this framework it was all pretty much based on device tree. Foolishly enough we assumed we'd just get device tree overlays merged really fast because now there is someone that actually needs them. Turns out a lot of things in the kernel break if you just apply device tree overlays so we're still discussing back and forth with device tree maintainers on how to get that merged. So right now it still kind of works only without of tree solutions on top of FPGA Manager framework. Now back to the problem that the FPGA Manager framework is trying to solve. It's basically have a processor that has some sort of FPGA connected to it. So that could be something integrated like the Zinc where you have an ARM processor and an FPGA in one die or from Altera until the same thing called the SOC FPGA. There's also other platforms that are connected via PCI express on a separate card or they're as Thomas is problem where you have a PCI bus that goes off chip then connects to an FPGA and that's another challenge we ran into. So our current problem we have is dealing with different systems. Our current solution we have is basically only more or less working for device tree overlays and device tree based systems. Currently on the list we have a patch set from Intel where they try to support their data center accelerators that works roughly like that. You have a PCI express card that comes up with a base bit stream that contains a PCI express endpoint which then shows up as a PCI express device that then binds a driver and this driver then probes the other things that are in there by means of what they call DFL which is some sort of self-describing compressed version of a device tree more or less. So it describes what kind of hardware is in the FPGA image and then we can go and probe that instantiate platform devices using that and then create a user land interface that is currently very specific to Intel but we're trying to figure out if we can generalize that to make cases work because there's other cases where you have discoverable buses where all we need to do basically is trigger reconfiguration and we can make the other things happen magically again. Yeah it's I'm a bit lost with these slides because I'm trying to remember all the things I wanted to talk about. I also wanted to have time in the end to have discussions and people yell at me for things that don't work. I had three slides in the end that I sort of called the good the bad and the ugly. So the good is definitely that we get more and more actually a system supported. The bad is that we can't really run without any out-of-tree patches which is kind of sad and the ugly is there's some use cases we currently flat out don't support like yours which is just reprogramming an FPGA from user land and then using other kernel interfaces like PCI Express to scan what's in there. Steps that we've taken in that direction is we have split out the device tree specific code and split the FPGA region which I'll soon have slides for as it looks. We've split that out so we hopefully can build on top of that to enable these kind of use cases. So the idea before was that on on boot we would scan the device. Yay! All right. Okay I'll go back to those two pretty there's two things we're addressing anyway. So there's a full right configuration reprogram the full FPGA. There's two cases discoverable non-discoverable. The discoverable one is like where you can probe and see what's actually in the image and there's a non-discoveral one where you need some sort of additional out-of-band description to make sure what happened to tell software what happens. Then there's also partial reconfiguration where you first program the entire FPGA with some sort of base image that creates these sort of slots and in there you have regions that you can then reprogram. So those regions when you reprogram them need bridges that you cut because otherwise the hardware in there might behave somewhat random during reconfiguration and break other things in your design your own. So that's stuff that we also take care of. The history I've sort of talked through a bit out of order because I didn't remember all the facts because I assumed the slide to be here so I'll just skip over that for the sake of brevity. The players in FPGA manager framework basically are three entities. We have managers which basically deals with like how does you how do you actually program the FPGA that might be over spy that might be bit-banging spy that might be talking to a separate block in your SOC that then does a configuration that might be a CPLD that's hanging off that might be something connected to USB so there's a wide variety but we don't really want to talk directly to that. I briefly talked about the bridges which basically separate regions in the FPGA or the entire the entire FPGA during reconfiguration and then there's regions which is basically the thing you want to be talking to in terms of writing software for the framework and they model the part of an FPGA that is reprogrammable okay so if you have a full FPGA that you completely reconfigured out would be one region and if you do partial reconfiguration you might have several regions in there and each region has a reference to an FPGA manager so it knows how to load firmware or how to load a bit stream to that part of the FPGA or the full FPGA and it also has a list of bridges that it needs to disable or enable how does it all fit together basically you have a device has a couple of regions each region has bridges and it has a FPGA manager that lets you reprogram it so in the beginning when you start out with the framework we thought we'd talk directly to FPGA manager turns out talking to regions as an interface is a better idea with device tree based regions basically you can define regions like that you say there's a FPGA region you pass it the reference to a manager you have a firmware name which is your bit stream and then all the green stuff would get applied to the tree via an overlay unfortunately we don't have an interface for that but it does work if you can somehow apply the overlay regions revamped that was the refactoring that I talked about before basically we're trying to separate out the device tree code that all lived in FPGA regions.c split out the OF part for device tree so now we have needed to make it possible to register FPGA regions so this would allow you to bring your own device to bring your own region from a device and also to unregister if your device goes away and then as interface you get FPGA region program FPGA where you pass in the region you want a program and some image info as part of that image info you bring your buffer that comes from wherever so that is again sort of bring your own buffer we hope to enable things like that like Thomas's case where you have an FPGA that's hanging off the SOC with something like that but we still need to look at how exactly make that work from user land then the DFL part I had talked about before without slight also PCI express there's read then then there's a base image that programs is programmed in there it has hardware description this describes what else is in there so basically based on that DFL that we parse we then instantiate bridges and the manager and all the regions where you can then create additional devices that implement the region interface so then you can go and program those the current plan for the Intel case was to have an I octal interface to user land because they have a bunch of other things that anyway need to do for for performance counters and other things that you might want to read from user land so we hope to probably use that for other cases too as I said before we have other cases where we're not entirely sure how to go about because you might have a non-discoverable FPGA hanging off a bus that doesn't like USB and at that point you might not have device tree to describe what's in there so long time ago I had a patch that proof of concept basically attached the header to the bit file that you can then parse to then figure out what's in the FPGA and then instantiate the thing the devices that are in there but that didn't go super far so we're still looking into that again the good as I said representing things with this device tree worked really well using overlays works really well assuming you can do that from user land which we can't the hardware support is growing so we get more and more drivers the bad is that it it doesn't really work currently for non-dt platforms but we're working on that with the Intel Intel patch set as a reference because that's the only platform we have available and the ugly well we currently don't have a user land interface we definitely need to come up with one that works for everyone which is why we don't have one yet some use cases currently don't work but we're working on that but not all this doom and gloom here's a picture of my cat watching TV and let's go to questions questions yes I mean we had long discussions at plumbers about this and then people had different opinions on how well detail overlays work for PCIe and non-dt based platforms think the conclusion was it should work but no one has actually tried it but then Lars Peter Clausen said he did that for a PCIe express card they had so there's definitely people that have done it there's just nothing mainline or patches public yes okay and they're using Xilinx FPJs right yeah so I had talked to the people at Xilinx and asked them to send me hardware which then resulted in not getting anything back so I mean it's like when I develop the code for the zinc for partial reconfiguration I don't have a license for it so how do I test it well I don't I breed the manual I wrote the code and turns out someone else used it and it does work but I mean if I don't have hardware there's nothing I can do well I Alan Tal who's the other maintainer works at Altera and I think he has access to most of the things they do so yeah whether they work with us yes for the zinc yes for zinc MP I think they have in their own tree an FPGA manager driver however that depends on some firmware code that they're I think in the process of upstreaming so ultimately zinc MP should come into place however the whole thing with zinc MP is a bit complex because they have all these different processors and it's not clear who does what for every setup so it's a bit more difficult than for the simple case where you have one processor that's in charge of doing something but yes yes oh no it's for for actually creating the bit streams where you need the license I mean in our use case I can talk about us why we don't do that as a company I mean we sell something to people and everything our whole FPGA code everything is open source and we want people to recreate the images we we make for our hardware but the fact that there's no free license available keeps us from using the feature which otherwise is really cool because you can do things like the Intel DFL things where you don't take down your PCI express link during recon reconfiguration yes yeah but that that's expensive right a block ram yeah that would be so yeah I didn't respond to I didn't reply any repeat any of the questions but the question was like whether you can bake in the image info into the the like the hardware description into the image and yeah that gets you back to the discoverable case because suddenly you can look at what's in there that's what Intel does with the DFL my proposal was to use flat and device tree to sort of standardize so we create a little header that goes on every bit stream and it seemed smarter to me than baking it inside I mean because because storage on your on your SD card or wherever is way cheaper than sacrificing block ram which in smaller FPGAs you run out fast although the workaround we have for that is we have sort of like a revision register that we then read and figure out okay what's loaded I think there was a patch I think we might have let me check on my list yes so the question was if we support CVP for alter our devices if it's on that list I think it is supported but I saw definitely patches for that I don't know at what stage we are with merging them but we're looking at it definitely other questions no all right thanks for your attention