 Welcome to my talk. Yeah, it's about FPGAs for everyone. I want to start with who I am. I'm a research assistant at the Helmut Schmidt University in Hamburg. And I'm always doing stuff with FPGAs. I try to interface FPGAs with operating systems. I create network on troops on FPGAs. And I'm always doing stuff with runtime reconfigurable systems, which is when you reconfigure FPGAs while parts of FPGAs are still running. I've been visiting hacker events since 2007 and have already given some talks about it. Yeah, if you want to contact me, there are the information where you can find me. And yeah, now we start with a, so if you want to find me and want to talk to me, you can find me at Garafel Village. It's, well, at the end of the camp where nobody can hear us, I have some FPGAs with me. So if anyone is interested in looking at them and talk about them, just come by and we can have a chat. So what is this talk about? This talk is about how to couple FPGAs with standard personal computers so that even people who do not know anything about FPGAs can profit from an FPGA. At the moment, if I give an FPGA board to my father or my mother, they won't be able to do anything with it because they do not know how to connect it to an PC. This talk is about a vision I have, how to FPGAs should be interfaced with an PC. And I show you some solutions I come up with in the last month. And I only show you some basic implementation details. And if you want to know more, you can just come by and I can show you all the source code I have. The rest of the talk is organized that I first tell you a bit about FPGAs for the people who do not know anything about it. Then I show you the problems I identified when you want to connect FPGAs to personal computers. And in the last, I show you my solution. And I also have a small demo at the end where I can show you something. So what are FPGAs? You see the picture on the walls. And an FPGA is something, an integrated circuit which is produced as an ASIC or whatever. And it's not static. Normally, if you have a CPU or an SATA controller chip or anything else, the hardware in the chip is static. You cannot change it. But in an FPGA, you are able to change the hardware after production. And so you can create your own integrated circuit at home. You can change it as often as you want. So there's no limit on the times you can reconfigure an FPGA. And yeah, that's the most basic things you have to know about FPGAs to see the benefits you can have in using an FPGA. More details you can have after the talk if you want to know anything about it, come by. Standard usage scenarios for FPGAs are, for example, prototyping. You want to test some integrated circuits. You first debug it, you describe the hardware and anything else before you give the hardware description to be produced in a factory. So you have a few production fails. So if you make a mistake, you get a mistake earlier in your design stage. And yeah, so you can have just a prototype. Another field where FPGAs are very common are low volume productions. So a company who wants to deploy some hardware and only wants to produce 1,000 pieces of hardware, you just take FPGAs because it's much more cheaper than producing ASIC. And you can even update the hardware at your customer. That's a very important thing that you can deploy your hardware, the customer buys it, and after that you can deploy firmware with which changes the hardware inside your product. That's even done with, perhaps anyone knows, that's done with an ICDN card from Fritz from AVM. They created an active ICDN card with a Spartan FPGA on it, and they deployed updates for their firmware. Another field where FPGAs are very, very common are high performance computing. There are a lot of high performance computing centers which just have racks of FPGAs where they're doing computations. There are some companies who develop specialized server systems with integrated FPGAs, for example, to do desk cracking or MD5 cracking or anything like that. They have, for example, there is SiEngine, which developed the Kuba-Gubana system, which is just a server system with 128 FPGAs inside. And they could crack des in some hours, wind with very few power consumption. So why should we care about FPGAs? For example, the hacker community or the people at home. Normally, it's very complicated to produce FPGA designs, so why should we do it? Well, as a hacker, we can use them as cryptographic accelerators. We can use them to faster crack VPA or VPA2 keys. We can accelerate our RES. For example, if it would be available, it would be cool if you start OpenVPN and it could use an FPGA to accelerate their crypto, so the process across in your systems have not so much to do. You can even create some hardware and some hard disk encryption onto the FPGA. You could connect a normal SATA hard disk to an FPGA and do the crypto onto the FPGA and get very fast crypto. And you always could do Bitcoin mining. Well, that's a bit late at the moment. Most of the Bitcoin mining is done on ASIC, so perhaps we should not do it on an FPGA anymore. Another thing you can do is you can accelerate video or graphics. I had a nice conversation on the camp about this HDMI to USB TV project where Tim does a lot of HDMI stuff onto the FPGA, accelerates the graphics onto the FPGA. And you even could do image processing. For example, if you use GIMP, you can have some filters offloaded to an FPGA and do faster image processing. Another thing I try to do at home is hardware firewalling, for example, in network security. You can use the FPGA, for example, in the picture. You see it's an 4-pot, one gigabit ethernet board with an FPGA on it. And you can do hardware firewalling. You drop packets before they reach your stack inside your computers, so nobody can smash the stack, your TCP IP stack. And you can copy incoming or upcoming packets to another interface where you can run your intrusion detection system, or you can create your own switch. And the last thing you can do with FPGAs is you can use them as special purpose devices. For example, you can emulate a USB device to the outside. You can create any other device onto it, for example, a CPU, and use it as an additional CPU within your processor, in your operating system. You can use it as analog didical converters. And you can even do software-defined radio with them if you connect the right hardware to the FPGA board. A typical design, when you try to connect an FPGA to a standard computer system, is that you have an host PC where you have the operating system with all the basic stuff. You have a layer for FPGA access, and you have the actual application. The FPGA access is, in most cases, done with libraries. And still, the host PC does nothing. The host operating system does know nothing about the connected FPGA. On the other side, you have the FPGA with a hardware on it, the component you want to create, the component which should accelerate something from the personal computer. And in between, you have different interconnection protocols, interconnectional physical lines. There are more than I put on the slides here. Yeah. And in this design, you have different problems. For example, you have problems with the hardware. You have always a very complex description of the hardware. You have to know something about VHDL or VaryLock. In the conversation I had with Tim, he mentioned that there are also some languages like where you can write your hardware in Python, and the Python code is then converted to VaryLock or VHDL. And the bitfiles you create for the FPGAs are platform dependent. So you can only put the bitfile you create onto one type of FPGA and not on all the FPGAs available. And the last problem with hardware is there are no standard interfaces. When you create a component onto the FPGA, you have to think about the IO, how to get the data off the FPGA. There are at the moment, I think, no standard for connecting them to general purpose computers. But there are some standards where you connect FPGAs to server systems. You have problems with interconnection networks or the interconnection links. For example, you can use RS232, which is very simple on the one side and very slow on the other side. So for some designs, this will be enough, but in most cases, you want more throughput. There it comes. You can use Ethernet, PCI Express, or USB to get data onto the FPGA. They are very fast, but in most cases, they are very complex on the side of the hardware implementation, but also on the side of the software implementation. Then there's JTAG. There's a lot of support for JTAG in the FPGA community, but this protocol is very slow and very obscure. And it's the only protocol or the most used protocol to configure an FPGA to load the bit file, the configuration of the hardware onto the FPGA. And the last connection scheme is the general purpose I.O. where you can define anything you want. You can just use one wire, two wire, three wire, or anything you want. Well, but there are no standards, so only you can use them if you have defined them. So in general, we can say we could not use an design, for example, an IS accelerator, have a standard APA to connect them to any interconnection scheme and use the interconnection scheme without knowing about it. At the moment, if you want to use an IS accelerator, you have to think about which one of these interconnection schemes you want to use and you have to implement it on your own. There are also problems in the software. If you look at your normal operating system, you have the basic drivers on the bottom. You have the operating system using these drivers to get anything working. You have the layer of FPGA access. In most cases, this is some kind of library. And on top of that, you have the application you want to use. For example, if you want to use an IS accelerator with OpenVPN, the application is OpenVPN. You need an additional library to connect to the FPGA, and OpenVPN would have to use these libraries to connect to the FPGA. SJTEC is the most common way to program or to configure an FPGA. It's very important that an operating system has support for it. At the moment, you need proprietary software for each FPGA vendor to program your FPGA. There are some open source projects available where they implement some generic SJTEC programmer, but they always only support some special devices, not all devices available. Your operating system in your PC does not know anything about FPGAs. Even if you connect the FPGA to the PC, you load a bit file on it. Your operating system, in most cases, does not see the FPGA as a resource to accelerate the operation of the system. And all the FPGA access libraries are always FPGA-dependent. So if you want to port your design into a different FPGA board, in most cases, the FPGA access layer within your software has to be changed. So the main problem we see here is that there are no standard APIs or any standard. So there has to be some standard so that the end user and the developer can use FPGAs in a more convenient way. So you see the slide. At the moment, the good thing is there are, well, in most cases, no standards available for connecting FPGAs with operating systems. So we have not the situation that we design another standard and get an additional one. My solution is that you, for example, for the part, if you design an accelerator on an FPGA, you have to connect your accelerator to a standard network to get access of the FPGA, of board the FPGA. So I designed an OCSN network. OCSN means on-chip switching network. It's a packet switch network. I developed it looking at TCP IP. I like TCP IP, so I tried to create something which is simple to use. And it's not performance I looked at, but usability. So I only get one to three gigabit per second on the FPGA within this packet switch network. But at the moment, it's, for me, enough. I hope that at some time I can accelerate it up to 10 gigabits. But that's in the future. You use everything in this network with IP, UDP-like frames, where you have a frame with an address and a source port, and you have a source address, a destination address, a source port, and a destination port. And with that, you can identify every device on the FPGA. And even you can have a component which provides different services on different parts within this network. I developed one to seven port switches so you can design if you only need two ports. You just design one switch with two ports, so you can save area onto the FPGA. The ports are, if you have a seven-port switch, you can interconnect the switches. I decided to use a tree topology for this network, so you have one root switch. And you connect every other switch down. And yeah, you can see the address scheme. And the root switch is just addressed with one and five zeros. With that, you can even interconnect FPGAs. I have some bridges created so that you can interconnect two FPGAs, for example, through ethernet. And this network would span over two FPGAs. So components onto the FPGAs can communicate with each other to solve complex computations. So you can see here the general design of this network. You have a switch connected different kinds of components. And you have a bridge which abstracts to the used interconnection scheme. At the moment, USB is not supported, but ethernet and RS232 are supported. Yeah, here you can see the current project status, where I'm at the moment. I have the switches available, I have a bridge for RS232, I have an ethernet bridge. I have even a memory mapped IO bridge to connect onboard software processors to this network so you can even communicate from the PC with an onboard soft core processor core running Linux. I have a block RAM component for testing. For example, I can offload data from my PC into the block RAM on the FPGA. Block RAM are some very high-speed RAM components within an FPGA. And I even have reconfigural module components so you can instantiate at runtime different parts of the FPGA. I want to publish it at some time. I want to clean up the code a bit and add in generic ethernet bridge support so you do not need to create different cores for different FPGA boards. You just have to instantiate one component. I want to add the ditchie-land-adapt bridge. Ditchie-land is a vendor of FPGA boards. Perhaps someone I have known about them, they create the Nexus and Atlas FPGA boards, which are very, yeah, they are very small and I won't say cheap, but cheaper than most of the other boards I know. And I want to, they use USB to communicate with components onto the FPGA and I want to create a bridge for USB to these boards. And I want to use an AIS and SHA-1 components just to test my ideas. Another solution, another part of my solution is that I created a Linux JTEC subsystem. Normally you have your Linux base kernel and then you have USB, PCI and serial drivers and then you have USB programmers. The devices where you connect your FPGA and you can configure the bit stream onto the FPGA. So I created JTEC host drivers for, at the moment, for ditchie-land, use a ditchie-land JTEC cables and the silence programming cables, which are available. Yeah, in fact, I created the ditchie-land host drivers. And a student of mine is creating the silence host driver. In the JTEC subsystem, all the functions you need to communicate with components within JTEC are abstracted and then you can have different kinds of device drivers, for example, an FPGA driver for Spartan or WattEx devices, which allow you to configure FPGAs by just cutting the bit stream into a character device within the Linux device stream. Yeah, JTEC is a very obscure and slow protocol. It's a huge registered chain where you connect these devices. You can see on this picture the signals TMS and TCK are connected directly to the devices. They are used to change the state within each device. Each device has an infinite state machine and through the TMS and TCK signals, you can bring the devices in different states to configure them or to get status information. And the TDI and the TDO pins are used to shift data into bitwise, shift bitwise into the devices, and TDO is used to shift out of bitwise. So it's very complex to get information into these devices. This is a finite state machine of JTEC. You can see that there are two chains within, or two paths within this finite state machine, one, one, one, two, three, four, five, six, one path is for shifting data in an instruction register and the instruction register tells the device what you want to do with it and then you have the data register where you can get data out of the devices or write data to the devices. So that's very complex and I had a lot of problems with it during my design of my JTEC host driver. I created a JTEC bus interface so device drivers can communicate with devices within this chain. For example, you have the functions JTEC on and off. So to just turn the JTEC chains on and off, you have to a function to reset the chain and to select the data register and to select the instruction register. For example, if you want to write an instruction into the instruction register, you would just say select JTEC, select instruction register and after that you would say JTEC write and write for example, seven bit of instruction word into it and after that you would call JTEC update to update the JTEC register. And it's the same with the data register. So your device driver, for example, for an FPGA does not need to know how to shift data in and out of this chain. It can just use these functions to simplify the communication with these devices. At the moment, I have the base functionality working. The host driver for Xilinx platform cable USB, one and two are in most cases working. I have a working host driver for Digilent JTEC devices that includes the Nexus FPGA boards, the Atlas FPGA boards and the Digilent cable. I have device driver for on Vertex 5 FPGA for configuring bit files and I also have a device driver for Spartan 6 FPGAs also for configuring bit files. Before I publish it, I want to clean up the code a bit and fix some memory leaks I identified here and I want to include automatic firmware loading for Digilent devices. Digilent devices require a special firmware which their tools bring within the code and if you use a kernel driver, you have to make sure that the special firmware the host driver is built for is loaded prior you can use it. So that's what I want to do. Another part of the solution is I created the on-trips switching network, the NOC onto the FPGA, but this NOC has to have a part within the Linux kernel so you can just communicate with it within Linux. So it's very similar to the JTEC subsystem but an important difference is that on the one side you can have devices within the NetDev subsystem. That means if you connect an FPGA with ethernet to your PC and there's a special packet from the FPGA coming in, the OCSN subsystem can identify this device as an OCSN bridge and can use ethernet to communicate with it. These OCSN host drivers register themselves at the OCSN subsystem and after that you can just write, for example, device drivers for AES or for an encrypted SD card onto the FPGA to use the subsystem. Another important difference is that I created a network driver so you can just use socket programming to communicate with components onto FPGA. You just say to, just if you want to communicate, you use a simple C program and says I want to open a socket, I want to open an OCSN socket and then you say, okay, now I want to send a frame or a packet to this address and this destination port and the subsystem will make sure that the packet is distributed to the FPGA and resived at the right component. The OCSN and bus RP is very much simpler than the JTEC bus RP because you just have transmit frame and reside frame because I'm using frames at this level. So most of the data or the information is encapsulated within the frame, the OCSN frame. The transmit frame and the reside frame function are available to device drivers. So a device can listen to frames, for example, a specific port. That also means that you can use, can write some drivers or a simple C program on your host which simulates, for example, an off FPGA RAM component or an hard disk within a file. So components from the FPGA can query data from your host system just by using simple OCSN frames. Yeah, the current status is that most of the base things are working. I have a host driver for alpha data FPGA boards. They use in PCI express interface. That's a board which is commonly not used by normal users. It's a special military graded FPGA board and it's very expensive. And I have a forex for FN host driver for ethernet connections for 10, 100 megabits and one gigabit. And device drivers for block RAM components and for the OCSN switch where you can query just statistics or reset the switch. I still want to do some code cleanups as always. I want to improve the network throughput. I think I have a big problem at the moment at one point because if I'm using the PCI express interface, I only get, I think, 200 kilobits of data through but I should get at least eight gigabits through it. So I have to look where the fault is. And I want to use Digiland Adapt support so I can use all the Nexus 3 and Atlas boards very easily. So what I'm trying to do is to get some experience for developers and for users. And my desired hardware developer experience is that it's for the developer easy to port hardware to different FPGA boards. You have a lot of components available to just switch the board and you only have to focus your development on the component you are interested in. I want to have that it's easier to reuse code of others. At the moment in most cases, hardware developers just write hardware again because it's hard to understand what other people yet thought about the hardware. And I want to have it that nobody has to think about the interconnection network only if they want. So you can just use interconnection networks which are available and just focus on your, yeah, for example, IS or SHA-1 component or whatever. The desired software developer experience is that you can access FPGAs without big knowledge about it. For example, you have a description how an IS component works and you can just use socket programming or a device driver to access the component and you need no deeper understanding of the FPGA or the interconnection networks. You should use the software developer use access methods they know, for example, socket programming or device drivers. And what I want is that software developers have it easy to integrate hardware acceleration in their products or in their code. For example, you always could accelerate image processing filters for GIMP on an FPGA. That's one thing I want to try in the future. And then the desired user experience comes. I want that a user who has no knowledge about FPGA just start an application and it provides hardware acceleration if an FPGA is connected. I want that he just needs to plug in the FPGA and the operating system decides, oh, cool, there's an FPGA, ah, and the user wants to do, for example, start OpenVPN and now, yeah, there's an FPGA. So I just load an accelerator component onto the FPGA and can offload some work to the FPGA. I want it that it's as easy as using at the moment USB to work with FPGAs for the end user. Yeah, now I try to show you a small demo of my system. So now I will load the Linux JTEC support. I'm just loading the JTEC bus driver. Nothing is happening at the moment. Then I load the JTEC host driver for digital end devices. No, at the moment, I have to manually load the firmware into the digital end board. And now I can insmod the digital end driver. So now you can see here that the JTEC bus has found, no, the digital end driver has found in a digital end device with a firmware version of 3.10 and identifies the product and register it to the JTEC bus driver. And the bus driver scans this chain and just finds for the host one, found one JTEC device with an instruction size of six. And now I load the JTEC Spartan 6 driver. And you can see that the driver identified and Spartan 6 FPGA on the FPGA board. And now I want to program it. So I cat a bit file into the device driver created. And you can see that it's starting the configuration. It's identifying the bit file and it says, well, the bit file is for this FPGA, which on the board. And yeah, then it's loading the bit file, finishes it, says to the FPGA, it should restart. And after that, the FPGA will work. There's actual no to big configuration on the FPGA, just let some LEDs blink. So, and now saying, yeah, I can make an LED blink is I think not so big here in this community. Yeah, that's the JTEC driver and I can show you my OCS N2, but it's at the moment not on my laptop. So I have to connect it to some off-world server. Now I'm on a server at my university where I've implemented it and I can just list all the devices connected on an FPGA connected to this host. So you can see there are some switches available and some echo servers, echo servers are just components which just return the packet I sent to them. It's just for debugging purposes. And now I even can say, for example, OCS N ping and for example, ping this component onto the FPGA and it's just pinging as you would expect it in a TCP IP environment. I even can request information from a switch. I will use this switch. Oh, I think the connection got lost. There it is. So you can just see which ports on the switch are online and which offline and how many packets are have already traveled through the switch. Yeah, not very, can see not very much at the moment. So now I have to get back to my slides. They are gone, not very fast. I think I have just one more slide. So what I showed you is my vision, how to improve developer and user experience. I hope that I get a lot of different ideas from the community, how I should go on and possibly change some things. At the moment, I have the JTAG subsystem as you have seen it available and I have the OCS N subsystem for communication. And if someone wants to help, I'm really open to host and device driver developers and even for ideas to change some parts of my solution. So I'm at the end of my talk. Thank you for your attention and attending my talk and do you have any questions? Hi. Yeah, please go ahead. Thank you for your talk. And the talk reminds me of an idea of 2004 of mine. This was called the Kirtle Accelerator Device and I made the talk at the 21 C3 and as it was in the older building and was a device based of many, so it was an idea to make a device with many FPGAs that are interconnected with links. So in this time, this was parallel and then later we wanted to change it to serial but nobody was interested because there was no Bitcoin and nobody paid a clue on this thing and so the bold project died. But also we had a friend who does also with this project but the project is very, very low but because nobody is interested in this thing. And so my idea with the networking was to use Wishbone. I thought about doing a special Ethernet protocol, so doing Mac layer two and doing Wishbone over Ethernet. So you can do DMA and things like that and use all the Wishbone calls. And so also having a special host interface that does the PCI express to Wishbone over Ethernet. And so you can scale it like that. And so if you have stupid switches that do only Mac switching, you can have your Mac address corresponding somehow to your device and so to the addresses in the Wishbone bus. And so you can make some routing table and say, I want to send a data packet to this device. We are some stupid switches. And so doing memory transfers. And I think this would be a better idea than using your switching thing but would be nice to get your sources to reuse it because then we couldn't combine Bio4DS. Actually, my system can be switched through normal Ethernet switches. All the bridges I have are available are able to use normal switch. So if I wanted it and have all the bots available, I could connect at least 10 of these FPGA bots through Ethernet to my host computer. And Wishbone, I know Wishbone, I looked at it at the beginning of my work but I wanted to have something which is very, very simple and Wishbone starts to get very, very complicated at a certain point of time. So I just dropped Wishbone at the moment. And it's, yes, you can talk about exchanging the network on chip on the FPGA with something different. But for developing in the early stage, it's much more better to use a very, very simple system so you find your faults faster. Regarding the Wishbone on Ethernet, you can make a special call that translates the Wishbone address data lines to some Wishbone over Ethernet transport and you do it somewhere on the FPGA board. And you can also use the interconnects on the FPGA. So you have maybe two FPGA on one card, you have a serial link and you do some ZS thing on the Wishbone bus. And so you have an architecture with some Wishbone cores and so you go from one card to the next card using Ethernet. And the advantage is that it scales much better. So you have all this cores from the Wishbone bus, you can all connect them. And so I think it would be better to have a nice data rate and not using some USB stuff because USB is low. So nobody wants to have this USB on the FPGA. But you have to use the ports which are available to the end user. And if you look at these ports here, the Nexus 3, there's even an Ethernet port available, but most users do not have a switch at home. They have an Ethernet card in their PC. And so you cannot use this Ethernet card to connect them to their host system. So you have to use USB. User do not want to have very much flexibility. You want to have it because you are a developer. And there I understand it. As a developer, I want to have all the flexibility I want to, which is available, but not at the end user. What about developing a special kernel driver that does Wishbone over Ethernet on the Linux kernel? Yeah, you could do that. And so you just send Wishbone over Ethernet packets on your NIC? Yes, that's possible. So maybe it's good to join forces or to find a student who does this? Yeah, would be. So maybe we talk later. We can take later, yeah. So just realize we are a bit over for the next one. Is it a quick question? Yeah, it's two questions, but you answer them as you like. The first question is, are you working with Bunny Huang of the Novena project, which is a fully open hardware laptop running an ARM CPU and it has on the motherboard and FPGA? And the second question is, could you tell us about your Bitfiles development environment and what operating system that is and what you're using? Thank you. I know Bunny. I have talked to him at the last Congress, I think. But at the moment, I have no Novena board available. So, but I want to look at it and try to get it integrated in my system because I think it's a very interesting approach to get FPGAs into the community. And the last thing, my Bitfile, I create FPGAs, FPGA designs at the moment I create, last year I created it in an Eclipse environment with just some Mac files and the normal Xilinx command line tools. And I just switched to Atom for the VHDL editing. Come to the microphone please. The operating system I use is just Linux, Debian Linux. But you're still using the proprietary tools all the time? Yes. Okay, thank you.