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/1026 Thanks!
[Music]
so the next talk is has the subject the
next PNR F fpga place and Route tool and
it will be given to you by Clifford wolf
who is a very active member of the uh
project I storm and whoever uh listened
to the uh talk before already got
step-by-step introduced to his work um
and uh basically he will tell you now
something about an open source fpga tool
chain so give a warm hand of Applause to
Clifford
wolf thanks so I'm going to talk about
the next next PNR which is our yeah next
open source place and rout to uh for for
fpgas um so to get us started I'm going
to talk about the ecosystem of Open
Source place and rout tools that we have
right now fpga place and rout tools
there are obviously a couple of Asic
place and rout tools as well so there is
um VPR which is um about 20 years old um
it has timing driven algorithms it's
fairly portable um in terms of porting
it from one fpg a architecture to
another but the focus of VPR is more on
architecture exploration so it allows
you to easily uh try out different
variations of your interconnect
architecture things like that um but
it's not
really
aimed at creating bitstreams uh creating
uh placements and routes for real world
fpgs because the real world fpgs they
actually are not as regular as the
madeup fpj that VPI is targeting um and
yeah so we needed something else to um
not only do architecture exploration of
on theoretical devices maybe um do some
um experiments uh for new placement of
routing
algorithms but for targeting real
devices we needed something else um so
when we did project iom we wrote Our Own
placeand route tool just for that which
was called arak PNR it by now it's about
3 years old um it was not timing driven
so it would just create a valid routing
uh a valid placement for your design and
afterwards you could run timing analysis
and you could learn how fast it is but
you couldn't really tell the tool
actually this net should meet this
timing constraint so please take this
into consideration when you place stuff
when you wrote stuff um and it really
only supported ice 40 so um we thought
about maybe taking aak PNR and extended
it to more timing driven algorithms to
architectures Beyond ice 40 but it was
really written just dedicated for the
ice for the architecture and it was not
really meant to be a portable tool um
yeah so given this situation we decided
we want to have a new place and rout
Tool uh that we can use on our way
forward to creating open source tools to
Target actual uh devices that you can
buy development balls that you could use
so we started next PN it's brand new um
so we started working on this this year
um it's uh timing driven um it's very
portable um and it's a team effort uh
which is completely new for me so if you
follow my my projects usually my
projects are I lock myself in the dark
room for a couple of months and then I
emerge and say look what I've done um
but now we have a couple of people all
working on that and it's a um it's a
really great experience for me um yeah
um one of the things that we get when
it's not just me fiddling with something
but a team of people we get the kind of
features that I'm not really good at
implementing so for example we have a
GUI uh and you can actually see the
schematic of the device and and zoom in
and I'm going to show you this um but of
of course uh it still works very well
with make files um and of course most of
the uh projects never use the GUI you
just run it in a make file or a shell
script and it does what it's supposed to
do um there is an API for supporting new
architectures which is a similar
dissimilar approach to what many other
tools do so the regular approach would
be to have a common data structure and
you just have to create this data
structure in memory that this describes
your target uh device we don't have that
um instead every architecture back end
must implement the same API and then
this API is used by the algorithms to
access the architecture database um and
the reason we do that is because we
think or I think um that one in memory
representation um might not be
universally a good representation for
all different Target devices that we
want to support
and I'm going to talk about a little bit
uh on the later slide um so right now we
have uh support for ice 40 and ECP 5 uh
so these are the things that we actually
recommend you to use um there are also
some some other things that are ongoing
so we have uh a so-called generic Target
um I'm not quite sure if it actually
builds right now it might have bit
rotted a little bit but the idea is that
you can use this to um generate a
architecture dat database on the Fly
using a python script and with this we
can also cover a little bit the
architecture exploration um aspect of
things um we also have a experimental
binding to torque which allows us to do
uh place and route for seven series
silence devices for example um but those
are the things that we don't recommend
everyone out there use this is more the
kind of stuff that uh we encourage you
to have a look at if you're really
interested and maybe if you would like
to uh spend some time um improving those
things yourself but as a user um right
now we are good for generating uh um
designs for ice40 and
ecp5 um yeah and some of the future all
of those future plans here are already
implemented uh so this is a reused
slide so we we we have uh we have floor
planning now we support multiclock
designs we do support
complex constraints like relative
placement constraints and stuff like
that okay um so this is actually
supposed to be a video and I spent the
last hour uh s tracing G streamer to
figure out why it doesn't really work uh
but I guess you can see what the video
shows uh um so just to demonstrate you
that we can actually do non-trivial
designs uh using this this tools so this
is an example for I40 on the ice the uh
side of things we support all of those
uh devices here um and we have a full
verilog to bit Stream flow so we use uh
users for synthesizing the design and
users in this setup will generate a Chas
file and then this Chas file is uh read
in by next PNR and next PNR will create
one of those uh ASC files uh for iorm
and then iorm will read that file and
generate the actual bitstream um the
board that you see in this non-playing
video is an icebreaker fpga board and
it's the board that we are right now uh
pushing so there's a crowd Supply uh uh
campaign right now that we are pushing
as a platform for teaching people fpga
design um so we've worked with a couple
of different death ports over the last
uh few years um and then we took all the
uh the pevs we had with the different uh
development parts and created a list of
requirements what we think a good death
board should have be if the target
application is not necessarily
prototyping commercial products or
something like that but instead if the
application is teaching people um um
yeah fpga design from uh from scratch
and personally I really like I4 as an
architecture for that because I40 is a
fairly small fpj uh because when you um
do do some teaching projects and you
have a ridiculously large fpga people
can write ridiculously inefficient
designs and it will still fit and they
will never learn that actually your
seven seven segment decoder should not
take 150,000 Gates um whereas with an
ice 40 you can actually set a goal that
is a little bit challenging for the size
of the device and then people have
actually to learn how to make efficient
designs in to achieve that goal
okay so here's another video that
doesn't play um this one demonstrates
that we can work on on ECP 5 so we have
support for I think for all of those
devices uh but David will will know it
better
um and yeah we have a full VAR to bit
flow again so we can use youres for
synthesis again this will generate a
Chason file and then we can read that
Chason file in next PNR next PN will do
place and rout and then we're using uh
the project Tris uh uh infrastructure
for for bit generation and act device
programming and in the video that
doesn't play you actually see Linux
running on an S so running in that fpga
um just to demonstrate that we can
actually uh do place and route for yeah
fairly non-trivial designs like a Linux
capable s so um and if the Linux would
play you would actually see that we can
use shell commands to turn on and off
the LEDs on the death
board okay so this video apparently
starts with a black frame
uh but that video just CHS uh uh an uh
exiling death board blinking um to
convince you that we have all support
for theiling devices
um there is a reason why the video that
you don't see see shows a a little
blinking example and not Linux capable s
so uh because right now we still have a
couple of of timing issues to figure out
with targeting the the larger fpj um
yeah but we are working on that and I'm
very confident that like um by the end
of next year uh we might have completely
different things where we say oh this is
the stuff that we can't do yet but this
of course yeah not not a big deal
um okay yeah right now because this is
based on talk I should tell you what
talk is talk is a library that can be
used to do place and Route um
experiments I would G say for fory link
devices uh and this will generate a
so-called xdl file which is something
that you can read into the old ayling
tools the isse tools uh to actually
generate the bit string uh so we don't
have a full end to end open source flow
uh here right now however what we have
is something that uh picks out the
difficult part for the context of next p
which is actually place and Route and
only for the bitstream generation we
need to uh defer to ISA in this case but
it shouldn't be too difficult to set up
something similar using the project
x-ray database and or using silence
rapid ride which is a rather new thing
from sinks that would allow people to
generate custom bit
strs
okay um
screenshot uh we will we will see more
of the GUI at the end in during the demo
um but uh yeah this is what it looks
like when you when you run it in um in
GUI mode uh we have a um device view uh
in this case it's a placed and routed
design so we can actually see the placed
cells we can see individual Nets just to
make the screenshot more interesting I
decided to color some of the Nets in um
the thing that we see on the left is a
the carry chain for example um the menta
uh Nets um you see we have a console
window where you see the stuff that
would just be visible on the normal
terminal console if you wouldn't started
in GUI mode um and at the bottom you can
see this is actually a python uh shell
and that would allow you to access um
all the internal data structures and uh
uh kick off all the the algorithms and
stuff like that and the right hand side
of the screen is dedicated to something
that will allow you to investigate
both the um device database that
describes the architecture that we're
targeting but also the net list that we
are trying to implement on that um
architecture so Bells wires Pips that
would be the device specific categories
of objects and sales and net that would
be the net list
um okay
um few words about the overall
architecture of uh of next PNR so we
have a couple of what I would call Front
End uh components um some of them are
common which means shared between
different architectures and others are
architecture specific so for example the
code that can read a net list is common
we need the same code to work for all
the architectures but the Packer for
example where we take individual for
example lookup tables and pack them into
larger logic cells this is something
that is architecture specific specific
every architecture would need um its own
Packer and of course we are trying to
design next PNR in a in a way so that we
can move as much code as possible to the
to the common bits and reuse them in the
architecture specific pits so on the one
hand for each architecture you will need
to write your own Packer but then on the
other hand we try to provide the
infrastructure that makes it fairly easy
to do so um yeah then there is a router
of course and the Placer um but they
might be inter Le with with similar
things that are architecture specific so
in uh in a couple of scenarios for
example you might have different routers
uh you have architecture specific
routers that do specific clock routing
tasks or things like that and then you
might follow that with the generic
router that routes uh all the ordinary
Nets that are remaining uh depending on
what uh what is good for the
architecture that you're um targeting
and those architectures um they access a
database that contains the design that
we are placing right now the netlist and
it accesses the architecture database
through this architecture API um and
that means that the architecture
database itself can be stored in a very
different way for different
architectures um and this this is
indicated in this picture we see we have
a couple of different implementations of
that AR architecture API but then we
have even more architecture databases
because we might have one architecture
that has one implementation of the API
but then five different databases in the
back for the five different device types
that are available in the family that we
targeting okay so I have two slides
about uh nomenclature that we use within
next PNR um it's not so much because I'm
going to use this nomenclature a lot in
the in the slides that follow but more
to give you a better impression about
what are the kinds of objects that we
are managing in next PNR um so that's
the reason why why I'm talking about
this so there is the design database
that's the net list we would like to
implement on the target architecture and
in this thing we have cells which are
just the um things like lookup tables or
logic cells or or flip-flops um that you
can instantiate on your target device
and each of those cells
has one or more ports I guess most cells
have more ports but there are some that
actually have only one
um and then those ports can be connected
to Nets and this net of course can be
connected to another Port of another
cell and that's how we see the
connectivity of the entire design uh
when we looking at a specific net um
there is one part on one cell that is
driving that net and we call that a
source and then there are more other
ports from possibly other cells and we
call those
SNS um and each net has exactly one
source but it can have an arbitary
number of syns um and the uh a source
sync pair we call that an arc because
and that's a very important um entity in
the routing algorithm because um the
next PNR routing algorithm is actually
um um prioritizing individual arcs uh
whereas VPR for example can only priors
Nets as a whole um okay uh so this is
the designed database side of of things
the objects that we can manage here and
then there is the architecture database
um the big distinction here of course is
that the architecture database is static
so I say I would like to Target this or
that part and then it's always going to
be exactly the same database whereas
when with each run of next p I might
give it potentially different net list
and a different design to implement okay
uh what kind of things do we have in the
architecture database there we have
bells uh short for basic elements and uh
these are the the actual things that
physically exist in your fpga so the
placement part of place and Route
essentially is finding an assignment for
each cell in your design to a bell in
your
chip um and similar to the ports on the
cells we have pins on bells um and um
yeah then we have wires that uh make up
the interconnect of the Chip And we have
ways of of connecting those wires
together in a very Dynamic fashion and
those things are called Pips
programmable interconnect points so each
pip essentially has like a as a a source
wire and a sink wire um and I can
activate pip or deactivated pip and
similar to placement being creating a
mapping between cells in your designs
and bells routing means creating a
mapping from all the Nets in your
designs to wires and Pips on the on the
chip and then there is another thing in
our architecture database which is
called groups and groups are not used by
anything except by the GUI they're just
a means to yeah group things into larger
units so usually when you look at an
fpga depending on the vendor you might
have organizational units like slices
and then a couple of slices make up a
tile and then those tile maybe make up a
column and stuff like that and you can
use those groups to um yeah um um
preserve this kind of structure in the
GUI so say you have a fpj you buil your
own fpj uh you document it uh an fpga um
something like that and you would like
to add a new architecture to next PNR
what would that look like so the first
thing you would need to do is create a
new top level directory in the uh next
P&R code base uh and add a little bit of
cmake magic uh
to to make it appear as architecture
um and then in this directory that you
created you need to add um at least two
files one is called ar. and the other
one is called ar. and ar. contains a
couple of data types that are
architecture specific for example one of
those data types is called Bell ID um
and different architectures might use
different uh um underlying data
structures to represent the B ID so on
one architecture it might just be an
integer on another architecture it might
be in struct with an X and a y
coordinate identifying your tile and
then another integer that is like the
Bell index within that tile and we want
uh each architecture to be able to use
like the most compact representation
possible in that architecture without
losing uh flexibility that we need to
support really large devices and the way
we do that is by making all those data
types architecture specific data types
um and then each architecture can choose
whatever they want and the C compiler
will try to do its best to actually
implement the thing C++
compiler so AR death that's where the
data types go and then ar. H uh that's
where one big class goes which is called
AR and this class has to implement about
100 different methods that are this
architecture database
API um and then you might need to add a
couple of additional files C files with
additional functions for architecture
the most important one here might be
main uh because we actually don't have
one main function for next PNR um
instead so you when you run Cake you
tell cake what kind of next PNR
implementation you would like to build
there's one binary next pn- ice40 and
other binary next pn- ECP 5 and each of
them has a different main functions
because we might have different common
line arguments and stuff like that
specific to different architect
es okay so the this architecture API
it's settling down right now we haven't
changed much lately there are still a
few things that I want to change um
longterm we need we need to freeze it
somehow um but it's still a little bit
moving so don't Implement like 100
architectures at the same time right now
goe it slowly one by one also with each
architecture we add we might identify a
new thing that we actually need as
functionality in that architecture API
because of that we are trying to
implement one architecture after the
other rather slowly but we also want to
cover a lot of different spots in the
overall fpga design space so that we are
sure that we have all the Implement all
the functionality in place by the time
we say okay this is not the Frozen I
don't know 1.0 version of this
API okay so um implementing about 100
methods sounds like a
lot um but the thing is that those
methods are very very basic so in many
cases you have something like your
inmemory representation of the
architecture of the architecture
database and then each of those function
is maybe two or three lines of of C code
just doing a little bit of Point
arithmetic to look up the right thing in
the memory and then read whatever the
the thing is that you're quering with
the function um because there is no get
Bell info function for example that
would give us all the information about
a bell instead for each attribute that
you might be interested in there is a
different uh geta method and because of
that you have a lot of methods that you
need to implement but each of them is
relatively simple and
small
okay
so say you would like to implement your
your architecture backend for next PNR
um you would like to write this 100
methods um but first you need to figure
out how to store the information in
memory that makes up your target
architecture database um and we think
there are three main approaches how to
do that
um but the nice thing is we have a very
generic architecture so uh if you
identify a fourth method that's not on
the list and hopefully you can hide
those this fourth method behind the same
API and everything is fine so the three
methods that we think are relevant are a
completely flat
database um so that means uh we have an
explicit entry in our database somewhere
for each and every wire for each and
every pip and each and every Bell
in our device um and that means if the
device is twice as large the database is
twice as large um but it also means if
my device is super
irregular then we can also
just implement it here and have a flat
database for a very irre irregular
architecture and we use a flat database
for I40 simply because the I40 chips are
small enough so that it makes sense to
just have a flat data
but as you can imagine when your chip
becomes larger and larger your database
becomes larger and larger uh and at some
point this is not really feasible
anymore so there are two different
approaches to solve this issue um and
the next step would be to have a
duplicated database the basic idea
behind the duplicated database is that
we first create a flat
database and then we look in that flat
database for
regularities for example a wire with a
certain layout or structure and maybe
there is a separate uh wire with the
same physical geometry just one tile to
the right and then we can merge these
two entries and we only need that once
in our database referenced from two
different uh locations um the nice thing
about the D duplicated D duplicated
database is that you can still start
with a flat database so if your chip has
a couple of
irregularities you don't need to do
anything special Whenever there is an
irregular structure on your chip it will
just fail to duplicate and everything
will be fine um but the downside is your
chip must be at least small enough so
that it's feasible to generate a flat
database in the first place and then we
can D duplicate it and for really large
chips that's not really an option so for
really large chips you have to use a
different approach which I call a tile
based database
and with a tile based database you say
this is the tile structure behind my
chip and I have a small database in
essence for each and every tile type and
then I just have a large table that tell
tells me which tile in my chip is of
which type and the nice thing here of
course is if your device is twice as
large the database is only a tiny bit
larger um and if you have two different
devices in your uh um in your chip
family the database that covers both of
them might only be a tiny bit larger
than the database that covers only one
of the
two and yeah right now we are using ice
40 a flat database for I 40 for ECP 5 we
use a d duplicated database and the
long-term goal for support for kiling
seven series devices is a tile based
database
okay there's a python API
um who here has written things in tickle
at one point in their life who feels bad
about
it yeah so so we decided we don't like
go with the industry standard we don't
have tickle we just expose everything we
have to python um that will make it easy
to do uh prototyping of algorithm stuff
like that on the one hand you can just
try stuff out in Python first and if it
really works then you can see uh if you
can make it perform better by rewriting
it in C but we also use Python for um
for constraints essentially so there are
some simple constraints that you can set
like this clock constraints here that
just tell tells the tool what the clock
frequencies on on different clock Nets
um but you can also write actual code in
Python that stuff stuff stuff like
iterating all the cells in the design
and then checking if those cells have a
certain attribute set um and if they
have a certain attribute set then add
them to a certain placement constraint
um so um I think that this is um much
more flexible than other approaches
especially if you have larger designs
and and constraints where it's really
hard to explicitly write a list saying
this should go here this should go there
instead you would like to have a small
program that just looks at the design
and then extracts the placement
information from other hints that are
already there using things like cell
attributes or just hierarchical names of
objects in your
design so what are the next steps for
the project uh first of all of course we
would like to slowly replace arak PNR as
the main place and R tool for ice for
ice4 project ior um I think you're
actually quite far with this many of the
uh the things that
use project iorm are already switching
to next PNR um we don't want to be too
aggressive about that because uh when
when everyone switches at once we get
like all the bu reports at once um but
I'm fairly happy with the with the rate
of progress by for moving people from
arak PNR to use uh next PNR well of
course there are many many ideas that we
have how to further improve our Placer
and and and router um some of them are
driven by by concrete needs that we for
example look at the results that we get
on on Kinks and um then say okay we need
to fix this and this and this to make it
work as good as we want it to work and
other of those improvements are just um
ideas stuff that we would like to try
out
um and of course this is also something
where we are looking for other people uh
using this for examples a basis for
academic research and and many other
things um so if you have any any
ideas how a Placer should work how a
router should work and you would like to
try out if it's feasible to actually
build a place or a router that uses this
kind of algor then hopefully next PNR is
a good framework to do this kind of uh
experiments yourself yeah and of course
support for more architectures the whole
point is that we want to have something
that is pable to many many architectures
um so we will just add slowly one
architecture after the other um and we
hope that long term we can do that with
actual support from vendors so we don't
have to start by staring at bitstreams
and uh figuring out what individual bits
do just to support stuff in our placant
route tool um yeah and once we got that
hopefully we will have world domination
for the small world of fpga place and
Route
tools
yeah some comparisons between arak PNR
and next PNR um so this is um next PN
bench right now there are only um like a
couple of designs in there um and this
are like 10 runs with each two with
random seat values um and then the
average um so you can see on the uh left
column in this table in the center the
max
frequency uh on average uh next P&R has
a 30% better timing result than arak PNR
so that's definitely an improvement but
on the right hand side you see on
average it's like 50% to 100% slower
than Rak PN I guess that's the price you
pay for actually doing everything timing
driven but um I have something more
about this uh in in the demo as
well
um so this here is
um
um next PNR against rakna PNR so we
still do BU fixes in arak PNR but for
the most part arak PNR is like a pretty
stable artifact um so we are comparing
the quality of results in terms of
Maximum frequency against arak PNR on
more or less regular intervals you can
see more or less whenever I have time to
run the
scripts um and yeah you can see it's um
kind of improving so I guess if we can
keep up the overall rate of improvement
for like another year then we will
produce Des uh designs that are faster
than physically possible so um yeah we
can't keep up that rate of improvement
for another year we already pretty close
on uh on what can actually be done okay
um it's time for a little demo um for
this I need
to um change my settings a little bit
hopefully that
works okay yes so we can both see the
same thing
now
um this is not large
enough how is
that good I can only see the people in
the front and the people in the front
tell me it's good
so
so the first thing I'd like to show you
is this here um so that runs users to
run synthesis for a really really small
Blinky design and then we run next PNR
to do the place and route for that and
this will create a ASC file that is a
file format used by iorm and then we use
ice pack to actually generate the
bitstream so these three commands are
the entire flow from verog to a bit
string um and it's a small design so
it's just uh like this blinks on an I
stick um so who here has
already had any experience with a
commercial
fpga um
flow okay so I I'd like to to imagine if
you take the commercial tool of your
choice and run a blinky design from vog
to bitstream that you can program the
entire flow how long this will take and
we will compare it what you have in your
head with we have
here so that was a third of a
second
um and some people will say yeah but
this a super smart design that's not the
thing that the industry is interested
the industry is interested if it takes
like 5 hours or 10 hours to do place C
out for a really large design but I
think that's exactly missing the point
the point is that every application is
different and then you have an open
source flow then you can optimize it for
whatever imple whatever aspect is
important to you and if you have a close
to then you just have to live with
whatever the um optimization goals are
that the vendor is setting uh for you
okay so that was that
um
so this is now a much larger design uh
it's a Pik rv32 a 32 bit risk 5 S O um
running in an HX um 8K um I did already
run the three commanded out commands
before so we can go directly into next
PN if I when I run
that thing here okay um so this is a um
HX 8K a 8 ,000 uh L device from the
ice40 series uh we can uh zoom in here
um I can select individual things here
like Nets or
Bells
um so what I did now was I run the run
the Packer this icon here um and you can
see the design that we have has about
almost 2,000 cells um next thing in the
flow would be to assign a timing budget
and of course there are more fine grain
ways to do that but now we just say make
the whole thing run with 50 MHz and it's
just all the clocks are now constrained
to 50 MHz um then we need to run the uh
the
Placer we can actually watch the Placer
moving uh cells around the Placer
algorithm as we use it here as a
two-stage process uh in the first stage
we leave um the relative placement
constraints for stuff like carry chains
looser and then we strengthen this
iteratively and then we reach um okay I
can't scroll up while it's running so
then we reach this point here where we
legalize them and make sure that the
Carri chains are actually intact and
from that point onward we uh always
leave all those uh constraints intact
and then we end up with the placement
and the post placement uh timing report
and at least the post placement timing
report looks pretty good for 50 MH
Target here I'm quite happy with that
um yeah then we run the router um and
the router is fairly fast as you can see
and we done now we can if you want write
the bitstream file um
whatever and uh we
done
so why is it
[Applause]
not so this is the ASC file we just
wrote and then we can use the ior tools
to convert that uh into a bitstream
file okay um so I guess with that I'll
open it up for
[Music]
questions
thank you very much Clifford so we have
ample amount of time for questions
please line up at the microphones and
remember to uh have them closely to to
your mouth so uh we can understand you
so microphone one please yeah thank
you I'm pleas about one two things one
of them is what kind constraint solware
do you use is it a constraint sare and
and is it like a proper one or is it
more like a
realistic so we are uh one of the
projects that we're pursuing right now
is looking into using sub servers for
placement um right now we don't really
have uh a working code for that um my
personal preference as for Sol as that
would probably be glucose or crypt minad
um the ofp min oh yeah yeah I I I
recognize you from your
Twitter so uh microphone one again well
since the tool generates this sort of a
blob of logic in the middle want the
fbga overheat in the middle middle while
being uh basically cold on the outside
so wouldn't it generate a huge
temperature
gradient um no
um uh so the temperature gradient is not
really there are reasons why I would
like to uh uh to have things fanned out
a little bit more of a wider area um
specifically to help with uh with
routability
um but especially if you give it timing
constraints it like tends to put
everything uh closer together um but I
mean this device
maybe I would guess it's less than a
square MIM die size and it
has the temperature should not really
very much although this is a ultra low
power fpj so it shouldn't get warm
anyways at least that's what the vendor
promises a question from the
internet yes thank you
can you modify final placement in the
GUI
interactive uh not in the guy so you can
can you unplace things in the GUI that
might be possible I'm not
sure where is the cell bound
cell
um no I mean I can I can hear right what
is it um
unbind the bell and then the name of the
Bell which was like this
here um
X6 y 17 logic cell 6 I
guess
and now the Bell is available so if
typing this python command counts as in
the GUI then yes you can do things in
thei
okay any more questions from the
internet uh yes have you thought about
um utilizing Hardware
acceleration um as open CL or
something I didn't quite understand the
question hard acceleration like open
yeah I mean um I'm not quite sure how it
relates to place and Route um because
usually when you do open CL acceleration
you would like like to run it through
something like a high level synthesis
tool then you end up with verilog and
then you run that vilog through your
regular synthesis chain or do you mean
using it for a place and
Route so we did have discussions about
that but uh nothing concrete right
now so microphone to
please all so you said the um place and
Route is completely timing driven in
viado there are also strategies like
like runtime optimized or area driven
are this also possible so the area
driven stuff is usually more in the
synthesis tool there's not that much
what the placant rout tool can do um and
I would say most of the things we do
right now on the synthesis size with
users is actually more area driven
because right now we don't really have
to the timing constraints in in in
synthesis so uh um the more embarrassing
question for me would be uh do we have a
timing driven synthesis in youres yet
but luckily this is an next p
talk okay another question from the
[Applause]
internet no thanks okay I would say this
concludes this talk and the Q&A session
so let me just uh close with uh there is
an area in over in in Hall two next to
the hardware hacking area it's the open
fpga area we have white umbrellas that
have open fpga written on them so if you
have any questions just come find us
there and we also do um beginners
workshops with this Icebreaker boards
okay now I'm
done lot of stuff to be done so uh have
fun with that and let's give a warm hand
of Applause to our speaker again
[Music]
oh