Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/347 Thanks!
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 be 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 realized 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 which 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 sort 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 for 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 building 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 computer.
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 conclusion, 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.
Currently 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
from 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 on 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.
The 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 that 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 you 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?