Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!




======================================================================






Thanks, everybody, for coming to the talk tonight. It's called Space Time Adventures on Navina Introducing Balbir. I'm Andy Isaacson. And I'm Steve Inskeep. First, a little bit about what this talk is about in the beginning. We'll give a little overview about what Navina is. If this is the first year catching that word, that's the open hardware laptop slash dev board. We used to work on this project. Next, an overview of what FPGA is, are and why you might want to use one. Then a little summary of the tools that exist today for working with FPGA. And then finally, our manifesto and an overview of the work we've done on this project to date. So beginning first, here's some background. This is a picture of Navina. It's very exciting if you're just tuning in on this project, it's a completely open hardware laptop. In fact, it just began shipping last week in the very classic style of hardware, as it once was. It ships with a complete booklet of all the associated schematics. So you can go on and know quite a lot about what you're doing with the hardware in this laptop. It has a lot of very powerful hardware, Ethernet, dual USB. You can see some light here. You might recognize the connectors. And most importantly, it has an FPGA right there. So what is an FPGA? An FPGA is? Well, the acronym stands for Field programable Data Array. So coming from the concept of an array of transistor gates that you can reprogram after it's been manufactured to take any arrangement you like. Importantly, it's a programable circuit. So it's a really interesting combination of both software and hardware in that way, which you can use to implement any algorithm you can imagine there. Are there used in short, to solve any computable problem in any computable problem is given, given that you can implement a complete CPU to solve any computable problem that way, why they're better, why you'd want to use one. Is there often salt faster at solving specific problems, especially problems that can b
e computed in a highly parallel way, or in a way that's more gate efficient when you use a dedicated processor for it? So next, a couple of definitions, some terms. These are some words that you want to know when you begin working with FPGA as you hear the first term. LUTTS A lot and it stands for a lookup table. So I'm going to get a skim the surface of the hardware side of this talk about as close as we're going to get in discussing this, if anyone here recalls early electrical engineering, explorations, logic, Gates, you have and or so forth, those are basically a two input lookup tables themselves. You have two inputs and you get something as a result of what those inputs are in an FPGA, you have this concept sort of taken well beyond to the next level. So instead of just two inputs commonly today in Xilinx FPGA is you'll have six and the outputs aren't defined in terms of like standard canonical logic. It's anything that you want it to be. So any input, you can define every output in combinations of six. So that's the smallest unit of computational cell you discuss in terms of FPGA s larger sizes. From there, Logic's else will be your groups of Lutts, along with some flipflops and multiple lecture's. Those are the things that you set that determine how your FPGA will go about doing its computation figures in that logic slices or blocks of two cells or a couple of cells in combination logic blocks are a couple of slices, maybe four. And then zooming out even further, you have the FPGA fabric and that's discussed fairly often. The fabric is you can imagine that these logic blocks are sort of floating around in a C or mesh, which you also program the connections between and the fabric is that physical layer that those blocks are floating in. And finally, a core is the overall definition of how the gates will be assembled. And going a little bit more so you have this FPGA, the how do you go about programing it a are programed in what are called hardware description
 languages else, which are is a human readable source, code language similar to see or other system programing languages. It's similar to other programing languages you'll be familiar with in that it has a toolchain which is much like a compiler and it turns your code into a final bitstream, which is analogous for our purposes to an executable. And that bitstream actually switches the physical connections and describes the physical interconnects inside your chip. Here's an example of an HGL. This is very Verilli. It's one of a couple H.G. Wells. It's the one we actually chose for writing our project. And in fact, Easter, this is actually code we wrote for the earlier project, which became this project. This is part of the 80s encryption algorithm doing a computation, if you're familiar with very like you've already read it and if you're familiar with a girl like you might be able to find the bug in this code. One thing that's interesting about this is if you're familiar with Python or C, you'll notice that that beginning line, the module submits. That looks like a series of arguments. But in fact, those are actual physical inputs here. Those are thought of as wires that connected to other things or wires. You will see more of those, I suppose. And so if you're interested in learning more about Vilborg, we worked through this book and found it very useful. Just a little shout out to weblog by example for those of you looking to go from here and learn more as a counterpoint, felt it prudent to include this video example in evaluating our HDL. We decided we like very like a lot more. But for the sake of completeness, here's what video looks like. VDL just one of many deals. Those terms are not interchangeable. So you write all this code, how do you go about building for the FPGA? What's the process like? It's analogous to compiling, but it exists in several different concrete parts. So the first part is synthesis. And during synthesis, your definition of what you want 
your circuits to do is converted to a list of internal connections and the output of that is called your Netlist. Then it moves to a stage called Place in Route. And this is where it gets interesting for me from the electrical engineering perspective, because at pujas are fundamentally two dimensional. And in order to implement the algorithm you want to compute, you have to actually, like, physically lay it out inside this chip. And it's similar, I think, to urban planning in some ways in that you might have two different modules that you need to be in communication with each other. And if you do this part wrong and run like a connection straight between them, they will never be able to communicate. It's also called mapping by some vendors. So the geometric aspect of this is certainly very important. And then subsequent to that, you have the bitstream generation stage where you take your physical layout and your connections and turn it into that file with the switches that turn the chip into what it should be. It's worth noting that bitstream generation seems like it'd be fairly straightforward, but is highly vendor specific. The tools for doing that are fairly proprietary. But as a note, there's some very interesting reverse engineering efforts here to understand and publicly document those systems. Find out more on the Internet. So START described a lot of the hardware of the FPGA and the last part in sort of the system diagram is this idea of an FPGA core. So what is an FPGA core? To be very concrete about it? The core is just a chunk of source code which does something which implements some process or algorithm. It's probably written in very log VDL or possibly in some higher level, more abstract hardware description language, which gets turned into logger VDL on its way into being in the chip. There's one really interesting distinction in the FPGA world between a soft core. Versus a hard core, and FPGA is have over the years evolved such that the vendors realiz
ed many people are spending a lot of their space in the FPGA doing some specific things. So let's just go ahead and put that down on the chip as as hard wired. And that's a hard core. And then if you're implementing something, using the hardware description, language in a log or HGL, that's a soft core, it's software. Now, many people in this industry, when they say core, what they mean is IP core and IP here is intellectual property core. So this is the idea that this source code is owned by someone and they have the right to sell it, to sell that idea, to market it to others. And they can be exclusionary about that, not share it with people they don't want to. So IP here is intellectual property, not Internet protocol, which is what I kind of was hoping when I first saw the phrase IP core. But alas. So it's it's interesting because this this FPGA world, like the community of people who developed refugees, are almost, I would say, mentally poisoned by this term. The fact that the thing that you're building is a core. And while, of course, it's an IP core, that means that I own it. That means that everything that is built is owned by someone. I don't think that's how it has to work. And that's one thing that we were really excited about in this project when we realized that open cause exists. So Open Cause is a website open cause dot org and a project and a philosophy to build free, freely licensed cause for refugees. Amazing project. They've got hundreds of cores, hundreds of different designs. You can customize them, you can integrate them. They have a shared bus interface for many of these, so they work together really well. It's really an amazing example of the free software philosophy in action. So open source is cool and IP courts are less cool, but there's an important concept there. But in the Balbo project we use the word core a little bit differently and we'll talk a lot about accelerator cause and what that exactly is. I'll get into in a little bit, but I
 wanted to put a pin in that here so that everybody's. On the same page, it's the next we'll discuss a little bit more about the environment that this project exists within. From the hardware to the software that currently exists to support FPGA on. So here again is no Viña and this slide exists to give you a sense of how FPGA is are measured, sort of you can see that this has forty three thousand logic cells. That makes it about a medium sized FPGA in the Spartans family. It's got two different kinds of ram here. And then actually the second to last line item here is interesting. It's got a hard core, which is a DSP that DSP forty eight, a digital signal processor built into it, just as Andy was describing. They've chosen to include that here so that it's permanently available. It gives you a bunch of things. You get an 18 by 18 multiplier, an ad or an accumulator, and you don't have to write those things for yourself. They're just there. They're a little bit more zoomed out on the Navina laptop itself. The FPGA is directly connected to the ARM processor via a very fast bus, 16 bits, and we will use that more. And, you know, even as in the course of preparing this talk, like, you know, that's great and everything, but like, why is there an FPGA on, you know, like what what would I want to do with it? And these are not things you might necessarily even want to do with it. These are things you could want to do with it. So you could you know, you could have fun in an attempt to put some Bitcoin mining into action. You could emulate another processor with it so you can have that arm talking to a software processor or some other kind. You can use it for crypto. As I alluded to earlier, our first project was to implement A-S. Our goal then was to accelerate SSL computations on the CPU. You can do code processing and you can also use it for processing over, you know, data you might be acquiring. Actually, the novenas. It's got this amazing analog to digital converter whi
ch lets you get in. Stahmann Software is is 500 mega samples per second actually often tell me it's fast enough for you. It's also great for doing the Navina has additional boards, for example, a software defined radio. You might use it for video or image processing, things of that sort. So now a little bit about the ecosystem of open source tools that you could use for targeting the FPGA, for building your course, shout out to the creators and maintainers of all of these products. First, this is Yosses. Yosses is something we're actually extremely excited about. It exists not in the same space as Balboa, but in a very complementary space. It strives to be what I think the proprietary tools that you can get today, like Xilinx, Issie and so forth to do that, but in a free way. It is not a complete replacement to date. It has. It can get you through synthesis. It has the start of plays and root system, and it doesn't do bitstream generation. But we're hopeful that with a couple of Xilinx extensions, Yosses could get there. It's also worth noting that this project has existed for about, I think, only two years and I think has been sort of worked on by like one guy so far. So it's pretty amazing how far it's come. It's opensource. It has a very large toolchain and also output's to any S.A. FPGA backing. Next, a quick word about my Jen, if you attended previous school, you might be familiar with this board called the Milky Mist. I like the Milky Mist a lot because its sole purpose in life was to do really beautiful video generation using an FPGA. And the team that worked on that produced a lot of useful software as well, including this, which is a python toolbox for building hardware. It lets you write a high level description of your circuit in Python and then outputs for a log or VDL. It's also used in actual projects, which is a strong plus. We just thought we'd include a little example of what the code looks like for this in the following three examples. So you can s
ort of get a sense for what it would be like. It's a basic Mildren example. My HDL is a project that I like a whole lot. We ended up writing directly in very large, but we considered writing in my HDL. It is rather than being a tool box for targeting hardware, it is. You're actually designing hardware with Python. It has a lot of docs. Their website is is really good. And I really liked what the developers of this project put into their website. To support people who would want to use it to program their hardware is sort of like just a Python syntax for very long. And it also runs and gives either very logger video, you're your choice. So here's a snippet of a my HDL project. One thing I really like about this example is it's a very well documented style. All of their documentation is like this. And finally, Chisel Chisel is very different from the previous two examples, it strives to let you design hardware in a embedded in Schola code. It's often one to one with very log that you'd be writing, but their philosophy is very different and their philosophy is really what's most interesting. It's actually produced by a UC Berkeley group led by Jonathan Bacharach. And one thing that's really interesting is that Risk five, which is new, completely open CPU was written entirely in chisel, so that's pretty cool. There's a paper associated with Chisel that's pretty great, which goes into further depth about the tension between having a general purpose, hardware, description, language versus having a domain specific language for describing your hardware. And here's an example of that scholar code describing Harvard. All right, so you might ask, like, why we need a free toolchain, like other than free software is as great. One problem is that a lot of the proprietary tools are sort of monolithic and they seem a little creaky. And our hope is that a free FPGA toolchain would not only let you flexibly target any FPGA you might be working with, it will also lay the groundwork fo
r new hardware description, language experiments, which I think is part of what chiselers getting out in their paper about the tension between current monolithic HGL faster built targeting FPGA is today is notoriously takes a long time. Are Xilinx our fastest selling IAC build to about 40 seconds, which is all day. You know, it's enough time to go get a new cup of coffee and you can only drink so much coffee. And then finally, longevity. The idea here is that free software has a greater lifespan than any proprietary software vendors come and go. You don't want to be locked in. Jaeschke has been around for a really long time. We think something like that could exist. So we promised you space time adventures. So here's the space time picture from Wikipedia. Like Wikipedia a lot. In order to get into the space time adventures, we have to set the stage a little bit. Roll back and look at the history. Let's go back to nineteen sixty five, nineteen seventy computers existed. Everyone had read a newspaper article about computers, but how did a computer come to solve an actual problem in nineteen sixty five? Well you had this computer with the CPU and you have a team of programmers who are going to build an application for this computer. That's CPU, that's computer hardware, that application are going to exist together, that there's going to be a fixed thing which exists at the end of this project, which is solving that problem, whatever that problem is, maybe it's a banking application. So this bank is going to have this computer and it's going to be their computer. So you have the CPU and you have the team of programmers and maybe the team of programmers realizes that the CPU doesn't quite do what they want. So they they ask, well, let's just change the CPU, let's add an instruction to it. So now the CPU gains the ability to do binary code of decimal because that's what they were going to do in this bank banking application. And the team of application programmers are bui
lding for this computer. So they write in, of course, in the assembly language for this computer, for the CPU with its new custom instruction. And that application is obviously only going to run on this computer, the one in Poughkeepsie you wouldn't necessarily think of also running it on the computer in Minneapolis. So that application and that computer are bound together and the peripherals as well. The printer gets wired into the computer. The computer is modified to talk to the peripheral. And so now you have a printer and maybe a tape drive attached. And now you have this this object which has been created, which which solves this problem. It's really cool. It solves the problem. This was really cool, especially at the time. But it's it's monolithic, it does exactly one thing, so rolling forward a little bit, nineteen seventy to 1972 is the year that Eunuch's was released in a portable form, a new operating system, not the first operating system, not the first operating system to provide the features that it provided. But I would argue at this point, clearly of clearly the most successful, long lived, really groundbreaking operating system units brought in amazing innovations for software modularity. Unix really popularized multitasking. So you could have multiple programs running on a single CPU. This was kind of crazy in nineteen seventy two. Why would you do that. How, how could you do that in a way that actually works. Unix also introduced virtual memory. You no longer had to map the physical addresses directly and programed your overlays so that the thing that set your code would fit on on the machine. And kind of most revolutionary Unix was programed in a high level language, at least what was considered high level at the time. Programing Language C. This is just amazing. I mean, it's hard looking back today to imagine how amazing it was that that. This underlying technology enabled component reusability for software development. I mean, wow. Such compute
r. So we gained a ton of infrastructure software developers, and it was a really long, drawn out, painful process, not everyone got it at the beginning. The idea that reusability, small components, pieces working together in the service of the goals of the final user of the computer would actually be a good thing. And some of these technologies today are so taken for granted that it's hard to even remember that they exist as discrete, controversial at the time, technologies, virtual memory, very controversial. I started my career at Quray, the super computer company, and I had coworkers who remembered this battle. Now, virtual memory is a fad. It's never going to take off. Timesharing the fact that you could have multiple users using the same CPU simultaneously, I mean, looks good in a research paper, but who's actually going to deploy that production operating systems with these APIs? Like you can just call things and things happen in a semi reliable manner and you get bug fixes and your application just keeps calling thing functioning. It works better. How does it even how does it even happen? Networking. I just call socket and TCP does a bunch of packets under the hood and it's its amazing device drivers that TCAP layer isn't talking directly to the Internet cart. It's going through several layers of abstraction. We write all of these tools that we're building these days in high level languages and they all rest on the foundation of compilers that turn our expressive thoughts into into discrete actions on the hardware. And we have libraries have these vast libraries of software. Some of it's really terrible. Some of it's better, some of it's very new and won't last for very long. And others other parts of it are like Lindback and we're still learning code that was written in nineteen seventy three. It's amazing when you think about it, how will this infrastructure has really separated us from where we were at the beginning of the computer revolution? In conclusio
n, I can wrap it up and say that we don't program to bare metal anymore. We've managed to move up layers of abstraction and have gotten a lot of capability as a result. So now, given that background, it's time to tell you the manifesto of our project, our vision is to let us do more than one thing at a time on the FPGA and to do so flexibly. Or in other words, writing and using an FPGA accelerator core can and should be as easy as writing a high performance C application. I actually expected laughter rather than applause there, because I blame our test audience, because as far as those of you in the audience, you've done this no writing on High-Performance, the application is no easy matter, but imagine trying to do that in assembly. It would be a lot more work. So I wanted to emphasize that the goal of the Ballboy Project is to build dynamic, reconfigurable computing. And each of those words matters. It's dynamic because. What the hardware is doing at any specific time can be changed with the flip of a switch. It's reconfigurable because what you've expressed as the accelerator core can be moved around the FPGA to optimize resources or to allow room for another accelerator core to be loaded. And it's computing because Bilboa is focused on the idea of enabling computational acceleration on FPGA. FPGA is are also amazing because they have fantastic IO capabilities. They have really fast digital IO, really fast analog IO. Those are awesome. Those are fantastic. I'm glad they exist. I totally use things that have FPGA in them. But that's not what the Bilboa project is about. It's not the killer app for me. So Bilboa is. Getting down to the actual nuts and bolts of the system that we've built and that we're planning to build ballboy is a library and some control software which runs on the CPU of the platform. And the control software makes sure that the FPGA is doing its job and that the apps are able to access it correctly. And Bilboa is also a bus and management layer
 on the FPGA. Implemented in a log which you can plug into you as a developer of a accelerator core can plug into when you're writing the score. And we hope that it will provide infrastructure and useful management so that. This job becomes a lot easier. The Navina Hardware platform looks a lot like this in block diagram, leaving out some of the complicated bits. We're a little bit further in than we were in the last slide that had this picture on it. The FPGA and the ARM CPU are connected by that fast bus. Both the FPGA and the ARM have their own dram associated with them. The ARM CPU has the standard complement of interfaces USB, gigabit, Ethernet, HDMI and so on. The FPGA also has IO up at the top for those times when you just have to get out into the outside world and now diving in to see how the software maps onto this physical architecture. We've got the Balboa's system here in the FPGA world. We have the Balboa bus, which provides the management and the interconnect. We have many different cores running on the FPGA simultaneously and then on the software side. Interface, the interface is mediated by Leyb Bilboa and talking to Alibaba, we have the management software, FPGA Deman and any apps that are trying to use the FPGA cause accelerator cores to compute their favorite function. The Naveena. Laptop is amazing. It has this really quite large FPGA, I say huge here and I should quantify that. There's enough room on the FPGA to have two full thirty two bit CPUs running simultaneously with plenty of room to spare. So there's a huge, unexplored territory here of things that could be done with the FPGA. And it's time to go exploring. And it's a brave new world. So here's the vision where we can go and why having Balbo will be cool and is pretty cool already, Balbo provides interoperability of the accelerator course so you can. Use multiple cores simultaneously on a single FPGA. And it also. We're hoping that we will that the tooling will improve over time. Current
ly we're using the vendor toolchain and it's not great, although it's getting better as we figure it out and learn the ins and outs. FPGA is currently aren't as useful as they could be. Many Navina users don't have any plans to use their FPGA because they don't understand what it could possibly be useful for. So we think that with some infrastructure, the Balbo infrastructure, the FPGA, I'm going to be there will be a lot more useful. Now, one point that it took me a while to get to here is that the point of Bilboa is not building the tools and the compilers. The point of Elbo is really to allow us to use the FPGA efficiently with less overhead of doing so. It doesn't matter to me if my FPGA can run something really fast, if it's a lot of work for me to set up, I can't even begin to tell you how many cool FPGA boards I have that I bought because FPGA is are cool and they're sitting in my closet because they're too much work to set up. The point of Bilboa is to let us do more than one thing at a time on the FPGA and to do that flexibly. So the goals of the ballboy project. Is that you developers, right, cause in your chosen HDL currently, I would recommend long because the alternatives aren't completely baked, but I can see paths to a better future. You get fast direct access to the core. Bilboa just sets things up and then gets out of the way. You get standard interfaces for both the core and the application. I spent several months at the beginning of my of this a project trying to figure out how the heck I was supposed to connect the very blog that I was writing to the software that I wanted it to talk to. And most importantly to me, is that with Bilboa, the end user chooses what runs and when drawing a connection back to how software reconfigure ability completely changed the world today, no one would think of having a single purpose computer that costs an enormous amount of money and only does one thing. The person who's using the computer chooses what it's doing
. And with Balbo, what we can do. The same for FPGA is the authors of Accelerated Course and the authors of applications that use them can build something, can build some components in the Unix philosophy, build something small that does one thing well, and the end user gets to decide when and where that runs and what it does. Taking it places that the original author never could have dreamed of. So how far along on this ambitious vision are we today? Frankly, after we started this talk, after we started this project most of a year ago, we're not as far along as I had hoped I would be at Congress this year. But we have some really encouraging results. We do have multiple cores running on the FPGA one at a time, so we can bring up one to one core, run with it for a while and then say, I'm done with this, I'm going to start a different core and start that. And the Navina system continues running flawlessly. Apps using the Balbo system can and map the core and get direct access to the registers exposed by the accelerator core. And we're doing this all currently without a kernel driver. I'm not sure that we can keep this up. I think that a kernel driver is going to be a critical part of the system in the medium to long term. But for now, everything can be done from a usual end process running as root YOLO. So that's the current status of the ballboy project. So at this point, we're going to discuss what's coming up next for us on the project and what we'd like to see happen. So first, some issues. Yeah, so the introduction of timesharing and virtual memory, in addition to enabling enormous kinds of productivity and creativity, also brought in some security challenges. Now you have resource exhaustion issues. You can use a computer because there are multiple things running and maybe one of them is trying to prevent another one from running. Similar many similar kinds of problems can happen. What should we call this? What should we call this seven security issues? I don't
 know. There are challenges, things that could happen on an FPGA if you're doing it, or seven awesome hacks. So seven ideas for potential security problems or awesome hacks, which I hope someone at a future Congress will present on the first one electromagnetic coupling. There's this amazing paper by Adrian Thompson from 1996 called An Evolved Circuit. The full title is actually a little poem, but it didn't fit in our slide. The picture here is a picture of the circuit which which he evolved. And there is some gray oh, they're completely unreadable. Unfortunately, they're not visible. Yeah, there's some gray squares up there. Don't turn around around the edges of that circuit. They're not connected. And according to the documentation of the FPGA, unconnected, unconnected, functional blocks shouldn't be able to affect the outcome of the circuit at all. Shouldn't be able to, according to the documentation. Turns out that if you remove any of those functional blocks from the design, the circuit stops working. The documentation isn't telling me the complete truth, I'm shocked, shocked. An interesting side note here. So this paper is amazing, I recommend that everyone read it. It was on the Web for like 15 years. It's totally incredible paper, really well done with some high quality nineteen ninety six web design. It's great. And the University of Sussex restructured the website in 2013, and now that paper is no longer on their website. The links on Google go nowhere. Adrien's paper is only available on archive dot. So a shout out to the Internet archive. Even the academics are trying to delete the web. It's important for us because, of course, have never really been shared on the same FPGA before. So the question this raises is whether you could create an appropriate antenna in hardware to snoop on other processes being computed on the same FPGA seems like it should be possible. Documentation says it won't work, but. Second awesome hack, that bitstream, that is output f
rom the toolchain and then fed to the FPGA over a hardware interface, it's a stream of bits. It's a language in in the in the in the hash tag, it's called Lansac. The idea of tweaking inputs to a given interpreter to find unexpected behavior. And that interpreter, the FPGA bitstream is a language with an interpreter implemented in hardware in the FPGA fabric. What happens if you give that interpreter unexpected input? Do we get weird results? I bet we do. It's only gotten trusted input so far. Which leads to the second option, bitstream exploits in our pre talk prep, we talked to someone who's actually done some reverse engineering in this space labs, and he pointed out that the bitstream apparently can fairly easily be configured to connect power directly to ground. And everyone who laughed has let out the magic smoke at some point by doing exactly that, probably some really interesting, fairly expensive experiments that need to be run there. You two can talk to us about the Navina hardware firms are very good. It's true. The best protocol, the FPGA on the Navina and the city on the Nubeena are connected with this A.I.M. bus. Some acronym doesn't matter what it says. It's a bus. It's pretty complicated because it has a very sophisticated protocol with very strict timing, timing requirements. So when the CPU asks the FPGA for a given memory address, the FPGA has a responsibility to return an answer within a certain number of clock cycles. And if the FPGA doesn't return, the CPU might crash. Might Hangu ask me how I know? Ask me how many times I Powerset cycled my dev hardware, either the core, the accelerator core on the FPGA or the app might be able to trigger this. So there's some really interesting fuzzing work to be done. Hopefully we can't let things on fire as it is as easily at that part of the protocol that leads into the fifth awesome hack malicious apps. Once I have an app with access to an FPGA accelerator core, it's talking over that Yamba's to the Balbo
 bus on the FPGA. What can the app do to trigger unexpected behavior now? Most things are pretty robust. I'm sure that if you do normal things from your app, then nothing bad will happen. But what happens if the app issues and unaligned read to the FPGA? Maybe it works, right? Maybe we see some really interesting behavior. Had a joke there, but I've lost it. Another awesome hack timing attacks. One of the reasons that figures are so cool is that you get down to the cycle, the clock cycle, fifty megahertz or one hundred megahertz or two megahertz, accurate timing information. When something happens, you can know exactly when it happened. Sounds like a great way to build a timing attack on a software algorithm. If I can extract the exact cycle when some IO happened, I can probably find out some really interesting things about your cache misses the layout of your a key table. Your RSA implementation should be a lot of fun. And the 7th awesome hack is hardware back doors. Now there's this interesting idea that some people have bandied about for why we should switch to FGS. And to make this make any sense, I have to put on my paranoid tinfoil hat and say, you know, I'm worried that the NSA might have put a backdoor in my Intel CPU's A.I.S instructions. And I'm going to fix this by not using an Intel c.p.u to do my critical secure computation. Instead, I'm going to use. Our I look fine here in the NSA had nothing to do with that, I'm sure I'm not so sure. So I'm going to use a soft spot. It's written in very long, I can look at it, read the source code and convince myself that it's correct and I can look at the bitstream and convince myself that it's correct. You, the NSA have not back toward my toolchain and I'm running on an FPGA, which is just a sea of gates. Everything should be fine, right? I can trust that they didn't backdoor every gate on this FPGA. It turns out the urban planning metaphor was very accurate. You can't just put the parts of your soft CPU anywhere o
n the FPGA fabric. If you have an FPGA, the ACLU and any accelerators that you put are going to end up in a fairly small set of places on that fabric. So if I am the NSA and I'm in charge of factoring in FPGA so that it will be able to snoop on the eskies of a soft CPU, implement that and then FPGA, I can probably manage to do it. Turns out Shadforths the back doors. In short, the back doors will probably still work if they exist at all, which they don't, because I took off my tinfoil hat and their slides are back, so that's good. As far as the rest of Balbo goes, we could use your help. We'd love to have people join your project. And we're going to wrap up by describing seven things that we would like to have help working on. So our current proof of concept is just one core at a time. We can build the accelerator core and synthesize it and loaded onto the FPGA. But as a next step, one goal of the project is to make it really easy to take multiple cores, synthesize them into a single fixed bitstream and load that onto the FPGA. Pretty straightforward, Hadayet. A little bit more kudret could use some help. Dynamic reconfiguration of refugees is a really interesting area. Now most people who are using FPGA is reconfigure the whole thing at once. You can figure at one time and now you're FPGA is a software software, defined radio. And you if you need to do something else with it, if you want to use it as a Bitcoin miner, you stop using it as a software defined radio and load the Bitcoin mining bitstream. And now it's a Bitcoin miner. Well, it would be really cool if I could have the software defined radio taking up two thirds of the FPGA and dynamically decide, oh, I would like to use Bitcoin mining, load the Bitcoin core on the remaining space and go from there and then decide, oh, I need to do some secure, I need do lots of crypto. So I'm going to unload my Bitcoin mining rig and load up a crypto accelerator without stopping the SDR. This is theoretically possible. T
he documentation says that it should work. Haven't gotten to working yet, having multiple cores on the FPGA, running on the FPGA, simultaneously using the bus between the FPGA and the CPU in a fair manner. So we need bus arbitration. And related to that, allowing multiple apps to use the FPGA but simultaneously will require some software work on the Unix side, on the winning side to let the map mappings interoperate cleanly. The Balbo FPGA, the Navina FPGA has a bunch of really cool IO and we should be able to use that. That's just a matter of teaching the Balbo a framework about those resources and giving it a management layer. And related to that, using the RAM, that ram that's attached to the FPGA currently, if you wanted to use that in a Balbo core, you would have to do a bunch of hand coding and very log. That should be easier. There's no reason for it to be as complicated as it is. And the last and perhaps I think the most important is that we should be able to implement cause for Bilboa. Using higher level language does not have any right very ourselves because writing for our log is kind of a pen. So here's how you join. I will admit that when we found out our talk was accepted, we hastily whipped up a wiki, etc.. You can join the conversation on Twitter with our cool hashtag and we hope to see you join. Finally, I will say that the Bilboa FPGA GitHub is of special note. Cleanaway, check it out. We'd love your feedback today. The best way to get in touch is via Twitter, which we'll use to bootstrap to email. Thank you so much. Special thanks to everyone who helps us with this project. And the creators of Levine are in fact in the room. It's very exciting and we hope to spur a huge amount of. Work and excitement on this project. So thank you. OK, thank you very much. We still have some minutes left, but to anybody left for questions, so as usual, please line up behind the microphones in the room. I think the first question goes to you. So start. One thing tha
t we never explain in our talk is the name Bilboa. Where does that name come from? And he wants me to answer where the name comes from. I don't know if you all read Bunny's blog as closely as I do, but we learned that Navina, the name of the laptop is in fact the name of a Singaporean Emirati station, somewhere apparently close to where he lives. We just thought we'd shoot one back. Balboa is, we think, the equivalent part stop in San Francisco. So whenever you're passing through Balboa Park Station, a little not think about it. OK, first question from here is yes, about a bit of question about the numbers. And earlier, like you said, Novenas features an ADC, but two times five Nomikos a bit. So there's one gigabyte per second. How much of this benefit is available over those Bilboa interface between FBG and ARM? The question is how much bandwidth is available between the F.J. and the arm or between the epigenome between the FPGA and the on the the the FPGA suffers. I'm not an expert in this area, but I can address the question. The question is we have a lot of samples coming in to the ADC converter, analog to digital converter, and only a smaller amount of bandwidth available to the CPU. You what you end up doing in a case where you're doing something like that is doing some kind of downsampling or processing in the FPGA to reduce the samples to site to a rate that the CPU can accept. And there's a lot of work. That's one of the primary things that software defined radio is do. So for that kind of thing, SDR expertize the people to talk to you, okay, you can you can build a digital converter and a number, of course, later in the FPGA and build over the phone. Right, exactly. Yeah. OK, can I please remind everybody that we're still in Q&A, so please keep the volume down and please if you have to leave to it quietly. Otherwise we can't hear anything. These are questions from the phone from just outside. This is really cool and exciting. What kind of applications do y
ou think would be most suited in terms of, I don't know, performance, but what are peak performance and how would it compare to GPU acceleration in terms of what you can do with it? So GPU acceleration. The question is GPU acceleration versus FPGA acceleration. What applications are well suited for for FPGA is the one thing that springs immediately to mind is anything where the timing matters a lot. So we started out with this project doing a yes GCM because it turns out that the GCM mode of A-S requires hardware support in order to be secure. You can write software that does GCM, but it will nearly inevitably have a timing information leak. With hardware, you can avoid the timing information leak. So there's a case where it matters a lot. Another answer would be I'm personally very excited about the potential additional uses of Navina as the sole scope and just off the cuff. I can imagine a project where you're sampling a high speed circuit and you have some action that the FPGA takes by sampling that and outputting any lives in an iota of white world. But that would be something I would think was pretty cool. Next question. When swapping out cost is distastefully process to do have to Roussos, I can't we can't hear you. Could you speak a little closer to Mike? Very close to the mic. When you when you're swapping. Of course, it's a state fully preserved to do you have to continue from a safe state when you're switching between? Course, yes. When you're switching back to one used before. Yeah. Excellent question. Is state preserved or do you restart in a new state? Was the question exactly. The I don't want to answer incorrectly here, so I'm taking a second when switching between, cause if the core has state in the in its FPGA circuit, that state needs to be preserved. When you swap back what else you can preserve state at a higher level where the application or rather the library, the ballboy library preserves the transaction before it's sent to the to the FPGA so 
that when it's swapped back in, you can restart that calculation. One good way to define the future is to help us write it, and thanks for giving a talk on the nice project, really. So although I don't a new project, I'm wondering how heavily tied is the Balboa architecture to the way to the how tight is the Boardwalk project to the way that the now has the FPGA attached to the process or how possible is it to add a piece of hardware? So our goal is to be able to sorry. The question is how heavily tied is Balboa to Nubeena and specific? And our answer I think is that our goal is to target any FPGA. Ultimately, at present we're using Navina as a dev work platform to get started. You need somewhere. That's exactly right. And I'll expand on it by saying that you need somewhere to run the software component of this. That doesn't have to be an arm CPU attached to Rambus. One of the goals of having the abstraction layer is that you could have different interconnects. And I hope that someone will make a computer I can actually afford, which has an FPGA on the hyper transport directly attached to an Opteron or similar computer. Quray actually makes a supercomputer like this. They started like ten million dollars in the interim. An interesting project you might want to look at is the Zinc FPGA platform, which has a hard core CPU on board for very high speed throughput between the FPGA part and the CPU part. And another possible starting point. That's a great starting, a great next step. And the last next step is that I really want to see the Bilboa architecture or something like it running on a soft CPU that's running on the FPGA while reconfiguring its own FPGA. And if we can. Yo, dog. Thank you. Sorry, I have to cut it short here, because we ran out of time and the next topic is going to be really crowded. We want all of your questions will be outside. All right. So all people that are having some questions, please go to my Web site and again, asking for a. Applause. Thank
 you very much. One last request, could someone could someone please make a free Twitter replacement so I can stop using Twitter as my primary means of talking to people about stuff like this?