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/1025 Thanks!
[Music]
so the next speaker in this Hall is um
Tim mythro he will uh give you an
introduction on Sim flow uh or
basically yes uh finally the GCC for
fpga he's an open source developer a
python guy and uh maybe a few people
know him about uh his other project HDMI
to USB about which there will be another
talk uh later on this Congress so also
get catch that and uh now I can wish you
a lot of fun and a lot of informative uh
takeaways from Tim stat is yours thank
you so firstly um I'm going to give you
a quick uh promo for another project I
do um you may know me from a project
called tomu um that was an arm
microcontroller that fit in your USB
port um since I really love
fpj um we decided to do an fpga in your
USB port um I have a whole bunch of
pre-production Hardware here um if you
help us out I will give you one uh but
be warned uh it does not um have a
bootloader yet I still working on that
um you can use it as a risk 5 CPU if you
want rather than fpga um it runs
micropython that definitely works um and
it has a fully open Source tool chain um
I.E what I'm just about to talk about um
so if you're interested in playing with
it um I'm interested in getting you
Hardware um if you contribute this is a
way I incentivize
people uh so the first question is what
is simow um Sim flow is a fairly new
project you may not have heard of it
before um the first thing and the for
most thing is Simba flow is a
community it's not just me I am not the
person who's done 90% of this work
um there these are all people who have
contributed in some way to the Sim flow
project and this is important to
understand because the reason I'm up
here talking is because we need you to
contribute to sim flow because to get to
where we want to be where we can replace
the proprietary tools with fully open
source equivalent uh there's a huge
amount of work that needs to be done and
I don't have the time to do it all
myself I need everybody in the audience
to contribute in some way to make this
possible
um so that kind of tells you what the
project is but what you probably came
here to uh learn about is more the tool
chain and I've known idea if people in
the audience are fpj experts or not so
I'm going to start at the
basics if you think of software tooling
you kind of have a bunch of software and
then you have a compiler that turns it
into a binary and you can kind of split
the um compiler into a generic front end
which has a bunch of generic
optimizations and then a Target specific
backend like there's an arm back end and
an x86 back end and maybe a myips back
end if you're into that
um but ultimately when you're doing C++
for say
x86
um you take the C++ front uh C++
software you run it through a generic
part that is shared and an x86 back end
and ultimately you're turning C++ file
through this compile step into a binary
that you run on your x86
Hardware um so we can parallel this in
the Eda tooling ecosystem you kind of
have your description of your Hardware
in a language like vhdl verilog or
system verog then you have synthesis
tools which kind of take that and
convert it into the digital logic and
then you have a backend specific part
that converts into if you're doing aex
an image that you convert a chip out of
in fjs into a bit file that you load
into your
fpga and so Sim flow is currently verog
tooling for taking verog and generating
that binary or bit file that goes onto
your fpga end to
end this is the S flow tool
chain as you saw in the title we kind of
described this as GCC for
fpga when I'm talking about that I don't
mean we're taking C and C++ and
converting into verog or directly into
something that runs on the
fpga what I'm using it is as an
analogy some of the core parts of what
Mak GCC GCC is that it's completely free
and open it's crossplatform and
multiplatform and it has a pluggable
interchangeable architecture and so that
is what we mean and we want for Sim flow
we want an endtoend fully free and open
source tool chain we want a toolchain
that targets multiple platforms multiple
types of fpga not just one vendor's fpga
and we want to enable an ecosystem which
has a whole bunch of different attempts
and a different ways of plugging
together the
tooling
so for a bit of history of how we got
here um Clifford wolf who will be giving
the next talk um started us all off with
project ice storm which he actually
presented about at CCC I can't remember
what year and he demonstrated a full
endtoend tool chain that targeted the
lattice ice
40 this was pretty impressive because up
until that time there was always this
idea that doing a fbga tool chain was
too hard for open
source this is obviously silly because
was like they said the same thing it was
too hard to do a c compiler too hard to
do a C++ compiler and every time it kind
of turned out to be wrong and Clifford
delivered us the proof that this was at
least
possible then Clifford just kind of
likes to keep getting stuff done and so
he started a project called project
x-ray targeting the xyx uh Series 7 fpga
the these are much bigger and more
comprehensive fpgas than the ice
40s and this is kind of when Sim flow or
the idea of sim flow um kind of started
all of a sudden we now had two different
parts from two different vendors that we
wanted people to start contributing
to and so I talked to Clifford and we
decided that we what we really need is a
project to bring everything
together and so at 34 C3 last year we
launched what we're calling Simba flow
which was a attempt to Target the both
old ice 40 architecture and the new
series 7 architecture at that time it
was pretty
primitive um but what one of the
important things we did with project
x-ray was to kind of document the
process we were doing for documenting
the bitstream
format and this inspired then project
trellis which is a project to document
the bitstream for the ECP 5 um Alis fpga
which is another uh large
fpga
we originally were targeting a thing
called verog to routing verog to routing
has been around for a long time um but
some people on the team wanted to
basically create a new place and Route
tool from scratch and so the people at
symbiotic Eda launched this new project
called Next PNR as an alternative to
verog to routing um to try and provide
another option for doing place and
Route and so this is what we call the
Sim flow tool Suite this is what enables
you to take a verilog file and convert
it into a bitstream that you can load on
an
fpga going into more
detail
um the first thing you kind of need
to create this tool chain is the
documentation for the bitstream that
goes on the
fpga sadly the fpga vendors don't
provide this documentation for
some interesting regions most of which
don't make a lot of sense um and so this
is where the project I storm project
X-ray and project trellis kind of fit
into they're trying to create
documentation that anybody can use to
create new tools it we kind of consider
them part of the Sim flow project but
other people can uh take the
documentation and Target these fpgas
without having to ask
us then you have the place and Route
tools um we're still continuing down the
line of supporting verog to routing but
we've also got next
pin there's also yosis um yosis I think
is the best example of a really great
open source project um that does
synthesis and we use that as the front
end no matter what the back end is
whether it's next PNR or whether it's
ver log to
routing and then we have this last thing
that um we call the architecture
definitions um the architecture
definitions are highly related to the
bitstream
documentation the bitstream
documentation tells you how to set the
bits to turn on features but it doesn't
necessarily tell you
what those things do or why you might
want to use them or how you might use
them and that's what the architecture
definitions are trying to
do they feed into the place and Route
the place and Route is the part of the
system that tries to figure out how to
map Your Design onto the fpga and so the
architecture definitions
describe the features inside the fpga
and should should feed into verilog to
routing um we're still trying to figure
out how they might feed into next
PNR
um they also feed into the synthesis
because the synthesis needs to know what
things inside the fpga to map
to lastly what we're trying to do is
make these architect architecture
definitions describe the functional
that's actually in the chip so that we
can do verification and testing and
simulation of what is actually going on
inside the
fpga um this should allow us to do
interesting things like formal
equivalence checking to prove that the
design you started with when mapped to
an fpga actually matches and this is
invaluable in proving that our tool
chain actually
works
the other idea is that this
executable uh this architecture
definition is executable documentation
for what the fpga is actually supposed
to be doing and so it should include all
the silly things that for example on the
ice 40 the ice 40
bams uh do not you cannot access the ice
40 BS for the first 40 clock C
after the system powers on that is
something we want to include in our
models because we want to have accurate
simulation of what actually happens so
that you can test things in a say
continuous integration environment
rather than having to load onto
Hardware a lot of that is what we want
to do in practice this is still very
preliminary um we're also hoping to make
it so that you never have to visit a
vendor's website to get the
documentation you need for example if
the um ltis for example became very
hostile to the open source environment
we don't want to have to depend on the
documentation that lce provides about
the features in the fpj we want our own
version of that documentation that
describes what the things are and how to
use them
so that's the
parts what is the actual status of
this so if we're looking at the
bitstreams or the bitstream
documentation
projects this is kind of a summary of
where we're at I'm going to go into more
detail now if you look at the lce ice 40
this is the first project that uh the
documentation was done for um it's
pretty much wide support for all the
features you can find in the ice 40
there's a couple of ice 40 devices that
aren't heavily used that still aren't
supported and so if you want to
contribute we would love your help to
add support for those but pretty much
everything including the logic the block
Rams the blocks the io all that is
already um documented and things you can
use right
now um we also have pretty good verog
models of most of the things some of the
hard IP could use um some good models
which uh demonstrate some of the
peculiar behaviors of some of the hard
IP and we still need some tech
replacement um libraries for example if
you want to use a design design that was
originally targeting the proprietary
tools it would be good to have libraries
which allow you to use the proprietary
Tool uh version on the open source tool
chain but if you're using the open
source tool chain directly you don't
need
those so that's the ice 40 ice 40s are
quite small fpga they're reasonably
simple but they're great for um very
small devices like the fpga tomu that is
inside your USB port obviously there's
not much space um that makes it perfect
for this type of
device if we instead look at the lce ECP
5 um which is Project trellis um Dave sh
started after us on this and yet managed
to somehow finish before us um Dave's
amazing um he has support for pretty
much all the ecp5 Parts out there the
ecp5 goes up to
85,000 logic um for input logic lookup
tables and it has high-speed
transceivers um I
believe the documentation includes the
high-speed transceivers so you can use
them with open source tools um he's
pretty much documented every single bit
that we know of so far maybe there are
some bits that we have yet to see in a
design uh but pretty much
everything um you could think of is
documented again it would be really nice
to have some better verog models um we
have some basic ones but things like the
DSP we don't have a really good model of
what happens internally in the
DSP um and also we still don't have uh
Tech replacement libraries
here if you want to understand exactly
what the bitstream inside the ECP 5
looks like you can actually go and watch
this video um it was give it given at a
conference
about two or 3 months ago called orom
and Dave sha goes into excruciating
detail about exactly how the bitstream
works and some of the very
interesting um decisions around how
things
work
this is the one everybody's probably
here to talk about um I would highly
recommend that if you don't have to use
the xyx 7 Series you really consider the
ECP 5 um most people the ecp5 is a
viable alternative that is cheaper and
better um for open source use cases
and is fully
documented project x-ray however um is
coming along really well um we're mainly
targeting at the moment the TIC
7 um specifically the
ec7
A50 uh but that also includes the 15 and
35t and the kch 7 we have some
experimental support for kch 7 um and
very recently like a week ago some zinc
stuff started landing and our goal is to
support all of the um Series 7 parts
that's the rtech 7 the kex 7 the vertex
7 the all the zincs with a series 7 uh
style
fabric we already have complete
documentation for all the bits in the
clbs or the logic tiles and a
distributed RAM and pretty much all of
the routing
we have partial documentation for Block
Rams and just recently
iobs we still have no documentation for
any of the hard blocks or the
dsps we also don't have very good verog
models for any of these yet um this
would be lovely to have help we also
don't have replacement Tech libraries
for um a lot of the compatibility with
xyx designs I'm assuming most people
here probably have existing xyx designs
that they want to port to the Seri uh to
the open tool chain um these Tech
replacement libraries are very important
for that because there are a lot
of kind of primitive objects that xyx
say exist which don't actually exist but
instead just a configuration of a more
primitive
object so these Tech replacement
libraries would also be
really
awesome so if you look inside a series 7
artech 7 this is kind of all the tiles
that
exist this is about what we understand
already as you can see there's a lot of
green um there's still a lot of red but
it's getting there and this is actually
slightly out of date um probably the iob
should be orange and some of the block
Ram should be orange um so it's
quickly um becoming more and more
green and this is enough to do a lot of
things this is for example the clbs the
logic slices you can see that we have
zero unknown bits for these logic slices
and the slice Ms which are the
distributed memory um we also know all
the bits for those
John McMaster um the person you can see
on the side there um is here at 35 C3 he
is spending most of his time at the open
fbj assembly and he would love to help
you get into bitstream documentation for
the series
7 we're not going to be able to do this
all ourselves um John you know wants to
have a life as well um so he would love
help and like if you for example want to
use the PCI Express hard block we would
love your help documenting it and we
have a pretty good process for doing
this so in summary you can kind of see
that um the these three projects give us
um a semblance of that GCC that we were
talking about we have three types of
fpgas from two different vendors and we
have lots of um bitstream documentation
for many different
parts but because we want to expand this
to every fpga out
there we're doing something interesting
as well
this here if people know their history
you might recognize as probably the
first ever fpg commercial fpga logic
block it comes from the XC
2018 which was um available for the
really awesome unit price of $55 each um
it came with about 64 tiles
um it didn't have any block Ram which is
why there's no documentation for the
block Ram but we have
complete bitstream documentation for
this part and you might ask me why the
hell will you documenting a part that
hasn't been used in 20 years and the
reason is because it's so old it's a
really simple part which allows us to
demonstrate how you might go about
adding support for this part to the tool
chain and that's what we're we're
targeting this um we would love you to
help take this and convert it into a
tutorial that allows you to kind of
understand how you might add a new fpga
to the full Sim flow Suite because we're
very interested in expanding to as I
said every fpga out
there and so this is kind of a full
summary
of what parts we kind of currently
understand the bitstream for uh you
might notice that project 2064 has a lot
of orange because it doesn't have parts
that exist like it doesn't have DSP
blocks or any of these type of
complicated
things and we need your help to do this
we're not going to go and document every
fpga out there because we just don't use
every fpj out there um and so if you're
using an fpj that isn't a xyx 7 Series
um we would love your help in
documenting it and we've kind of come up
with a fairly good Pros process through
these our learnings on how to document
these previous ones that should make it
pretty easy for you to replicate our
success
we would also love for people to look at
for example the Spartan 6 and the
Spartan 3 um these are very popular
fpgas that there's millions and millions
of them out there um I'd very much love
to see support but it's an old part that
I'm probably not going to use in any new
designs and so not something that I'm
currently targeting um we don't have
support for any ala part if there are
altia fans out there um we would love
your help there um there have been some
attempts to document um some our parts
um I don't know the exact status of that
um I believe Robert who was working on
that may be in the audience or maybe
here at CCC somewhere um you should go
and chat to him and see if you can help
get some of that stuff Upstream into
semiflow but just documenting the
bitstream is only like a third of the
battle you also need to create tools to
generate the bitstream and the bitstream
needs to be documented before you can
generate stuff for it
but it's not just enough to document the
bitstream you also need the tooling to
generate the
bitstream and so what's the status of
that
as part of doing the mapping and placing
route you need support in both yosis and
one of the place and Route
tools both the place and Route tools use
yosis as a front end so you're going to
need support in yosis to be part of the
Sim flow tool
genam but both NEX PNR and ver log to
routing a timing driven place and Route
um this is what all the commercial tools
use uh if you've used AR rakna P&R
you'll know that's not a timing driven
place and Route which was another reason
why next p was started as a replacement
for arar to give us timing driven place
and
round and so this is kind of a summary
of
Where um synthesis mapping in place and
Route is kind of
at NEX PNR is probably the best solution
at the moment for lce ice 40 you can
kind of see the awesome guey they have
here the status is that you should just
be using next PNR for lce ice 40 right
now um it should beat a raknar P&R in
everything apart from runtime and even
in runtime it should be pretty
close the people at the um open
fpj um table told me that you should
just be using these tools and Reporting
bugs so if all you do is help us by
using the tools and Reporting bugs that
would be
awesome it would also be good if you
could start updating your tutorials
there's a lot of Open Source tutorials
out there that talk about using Arna for
place and Route it'd be much better if
they talked about using nexp for place
and route
now next
p um is also being used at tutorial
sessions um that the symbiotic Eda team
and uh edden who created this
Icebreaker um board I believe there may
be a few slots left but I'm not sure
they kind kind of were running out um if
you go and beg maybe they'll run a few
more tutorial sessions um I highly
recommend you go along and find out um
this will get you started on one of the
best Dev boards to get started with from
the
experts as well as I said previously the
Tomo fpj is a nice 40 design um and if
you're interested in playing with one of
them I have lots of these here but again
the bootloader doesn't quite work yet so
that's a job for me tomorrow to get that
working um I'd love help I will give you
boards if you have the ability to
help NEX PNR also supports the lce CCP
5 again this is the awesome work of Dave
sha um it supports what I call iot
microcontroller level system on chip
designs um this is things like little
32bit risk5 processors but it scales up
to doing full Linux compatible
microprocessor system on chip uh Dave
has an example of um Linux running on
the open risk 1K running on ECP 5 it's
still early but it's definitely ready if
you want to experiment with it
um Dave told me that again one of the
best things you could do for him is use
the tools and Report the bugs so if you
have a project where you could use the
ecp5 it would be really useful for you
to try your designs and see whether they
work um I would not say make this in
your critical path yet um but it's
definitely um ready for
experimenters and that's kind of what
next PNR supports um Clifford will be
giving a talk next after this talk on
next PNR so you can get all the really
gritty details um I believe some of that
may include even how to add new
architectures to next Pinar um so if
you're interested in that please stay
around then we also have um support for
the lce ice40 in verog to routing and
you can kind of see some images of the
verog to routing guey here showing some
designs as you can see it's a lot less
pretty than the next P&R one this is
kind of the difference between having
academics do goys and other people do
goys
um the lze 40 in verog to routing has
support for logic and block CR
but it only has a really simple iob
model it doesn't have any DSP blocks or
any of the hard block supported yet um
you can definitely do a blinky or a iot
microcontroller sock using verog to
routing but I would not say it's a
Production Tool chain yet um there are
definitely a whole bunch of serious
issues with it we need to fix um like
the fact that it might use more than 4 G
to do a fairly small thing none of this
is
fundamentally caused by verilog routing
more of it is caused by us experimenting
on how to describe these things and
learning along the way and so we would
love your help in improving a lot of
these things um a lot of it is just
Python scripts that generate the routing
graph having those Python scripts be
more efficient or maybe Rewritten and
see if that's so inclined would make a
lot of this much much quicker and use a
lot less Ram um I'm terrible at graph
traversal My Graph traversal is probably
you know end to a th000 um I'd love
people who are better algorithms to come
and like make it n log in or whatever
the correct way to do these things are
um I am not good at that type of thing
it Works um please come and help make it
better
um but the thing you that's probably
more interesting is that we have basic
support for the xyx Artic 7 in verog to
routing with this there's logic and Dam
like distributed Ram this is enough to
do a blinky uh like counter um you can
also do a ram tester that like writes a
whole bunch of values into the
distributed RAM and read them out we
know that because that's what we've been
doing to test whether the distributed
Ram is working again this is not a
production ready tool chain but it's
getting
there we're very very close to having an
iot level microcontroller sock I was
really hoping to get this working before
CC
um but I got distracted by doing tomu
fpga stuff
um this is as I said very close to
working we would love your help in
making it work
um a lot of it is just you know working
through the process and then debugging
when it
fails
um some of it is a little bit
complicated and a little bit fiddly but
a lot of it is just walking through the
process and Reporting where you got
stuck and so most people should be able
to do
that and so this kind of gives you a
summary of where we're at as you can see
um the ice 40 is pretty much well
supported by
everything um project x-ray is currently
only really supported by verilock
routing I know the next p guys uh ch at
the bit to add uh Series 7 support to
next pin um but have kind of been
holding off until we can kind of prove
that it works in FA Lo
routing um if you're using ECB 5 then
next PNR is your best bet because VPR
doesn't support um ecp5 pretty much at
all um and 2064 doesn't work at all yet
um we would love people to
work on the 2064 because it's a great
beginner project and it would really
help us figure out the type of
documentation we need to write for
example how do you add a new tech
mapping to
yosis
um problem with having do been doing
this for like 2 years now is I've
forgotten all the things that you don't
know when you start um so we really need
help from in some ways beginners who are
technical to help write that
documentation and help describe
tutorials on how to add something like
the
2064 two things like next PNR and two
things like verog to
routing
so as I said at the beginning this is a
big project um it's prob
as big if not bigger than GCC and it
needs your help to become
successful we're put in a lot of work
and we're slowly getting there if you
want this to happen faster we need your
help if you know
python I am 100% sure I can find
something for you to do because almost
all scripts are written in
Python if you know C++ there's
definitely a huge amount of stuff you
can do both NEX PNR and VPR are written
in C++ a lot of the shared libraries are
written in C++ we would love your help
improving those some of them of the
things are as simple as writing tests or
improving the input output libraries um
for example the input and output library
for VPR at the moment just reads the
whole file in and then starts processing
it um you don't need to know anything
about how Hardware Works to fix that
problem um that's just a simple event
driven
passer so even if you know nothing about
Hardware if you're a C++ programmer you
can definitely help
us if you're one of these weird people
who know
tickle um we would love your help
because I'm not going to learn tickle um
and pretty much all the Eda tools out
there use
tickle um I know John has an interesting
relationship with tickle from using it
through Vado um I'm sorry that you had
to do that John um so if you know tickle
please help us um pretty much all the
tooling for doing the fuzzing needs at
least some tickle and you could probably
help relieve the stress of tickle on
John um if you know
verog as I said a lot of the simulations
and models are written in verog um we
would love your help doing that as well
as simple designs like even if you
aren't extremely competent with verog
writing things like the simple thing
that reads uh writes a bunch of values
into the Damm and then reads it back and
checks that you know the values it got
were correct we need that type of simple
tests to verify functionality and if you
can write verog you could probably write
that pretty easily and we need a whole
bunch of different types of things like
that that aren't particularly hard to do
but definitely need to be done done and
so you could definitely help
there here's kind of a blast from the
past um if you know
XML um almost all the formats file
formats going into ver routing XML um a
lot of the formats coming out of verilux
routing uh XML um a lot of that is done
by
printf um that would be nice to be
replaced um as well as things like
having um stylesheets which confirm that
your XML you know matches a
description is useful things you can do
or having tools that transform the XML
from one format to another format is
also really useful so you can brush off
those
xlst skills from the late '90s and early
2000s um and help us out
there if you know English which most of
you hopefully do otherwise you're
probably been very bored um you can help
with things like documentation things
like improving the read me improving
like how to get started documentation
improving the website um if you know
JavaScript um I'm terrible at JavaScript
um please come and help make our website
better if you're admin to know things
like Docker um we would love for the
setup to be much much easier um things
like Docker can apparently make that
happen um things like improving our CI
system um with Docker is another way you
could definitely
help if you have time to contribute to
this project I am sure I can find some
way for you to be helpful and the thing
is I've been known to give people
hardware for contributing to my projects
and while I won't promise that I will
give you Hardware um I definitely have a
lot of spare Hardware that maybe you
might find turning up at your place if
you contribute to projects like this
plus you'll get like gratitude from
everybody who's ever had to suffer
through the proprietary
tools so surprisingly I got through this
much faster than I expected um so we're
about 43 mes apparently um I'm going to
go into
questions um I cannot see anybody out
there the lights are quite bright
so you're going to have to wave at me to
do questions or
something first but first thank our
speaker uh for the talk
please do stay around for Clifford's
talk if you want to like understand the
really nitty greet greet nitty-gritty
details about how things like place and
Route work and I'm sure Clifford would
love help with next PNR um I'm sure Dave
sha would love help with next p um it's
a very cool new tool that is less than 6
months old and is already useful for
production
stuff okay uh for the questions remember
to get close to the microphone so we can
hear you and if you really have to leave
do so quietly okay uh microphone one
please yes um how did you reverse
engineer the bitstream
formats
so what we do is document
the bitstream formats so that tools can
be written that are compatible with them
um what we don't do is reverse engineer
the tooling
directly we are forbidden by our legal
advisors from attaching for example GDB
to vado what we are allowed to do is
basically put a lot of input into Vado
and take a lot of bit streams and then
you do this process of
crosscorrelation between the stuff you
put in and the stuff that you got out
and what you're looking for is every
time this feature was on this bit was
set and every time this feature was off
this bit was not set and because you put
in a huge number of designs and you
randomize a lot of the designes that are
going in this correlation approach um
allows you to resolve that bit
uniquely um I'm however no expert on the
bitstream documentation side of things
um John mcmas is done a huge amount of
work on the series 7 documentation and
Dave sha has done a huge amount on the
ecp5 work um both of those guys are here
at Congress and both of them will
probably be around the open
fpga um table most of the time um so if
you really want to go into like the
super detailed about how this works you
can go and talk to them as well if you
go to the project x-ray read the
docs there's every one of the fuzzers
which um document various different bits
like the various bits of the logic block
should have a read me which describes
what it does why it does that and those
type of things um some of the places
would been a bit naughty and did not
include such a read me that's a bug
please log it and we will try and add it
but definitely um we're trying to make
it so that this process is um described
in a bunch of different places to allow
other people to do the same thing on
other fpgas and so please do come and
ask the questions um please do come and
uh tell us where you don't understand
what we're trying to do or how it works
because fixing those things is
definitely what we want to do because
there's no way this scales if only John
and Dave are doing the documentation we
need it to be easy that any un
University student or any person out
there who has the time can find their
favorite fpga and do this
documentation thank you microphone 2
please um is there is there any support
for vhdl in the to
CH sadly
not um there have been a bunch of
attempts to do
vhdl um support in yosis um none of been
successful yet um if you happen to work
for a company that has Deep Pockets uh
symbiotic Eda will actually sell you a
license to um a proprietary library that
does vhdl they didn't write that but it
has been integrated into yosis
um I don't know many people who do vhdl
in the open source world is kind of a
chicken and legegg problem the Source
world doesn't support vhdl so everybody
uses verog and hence the verog support
keeps getting better and the vhdl
support goes nowhere um it would be
awesome if people wanted to work on that
um I personally would say you're
probably better off switching to verog
um I do think vhdl is probably in some
ways a better language but it's not so
much better that I would suggest
spending your life adding support to
yosis for it I mean you'd get my
gratitude if you did but I can't
actually recommend you do
that is there a question from the
internet signal
Angel yes go
ahead um we have two questions from the
internet the first is would it be
feasible to add support for
cplds
um depends what you mean by
cplds pretty much everything these days
people call cplds are actually fpga
mostly
internally um if you mean uh what are
they called um something like
pla logic style devices um there is some
experimental support
for that type of device in
yosis I'm not sure yosis is the right
tool but Clifford will probably be able
to tell you a lot more about whether or
not that's a good idea um I definitely
know that the coolrunner 2 which has
some um experimental support was a cpld
and that does have the um
Andor type system but I'm not an expert
on uh
cplds uh but definitely like most things
these days that people call cpods are
pretty much just fpgas with flash that
allow on chip that allow them to
basically boot instantly um their lck
designs and um have very similar things
to um
fpgas okay um first microphone 2
please can you explain the difference
between uh next PNR and verilog to
routing it seems like there's a lot of
duplication of effort between what
features are supported and which chips
are being
supported so I knew this question would
come up um so I actually have slides for
this
one
so there is a lot of duplication between
next PNR and VPR that is correct um the
first question is um if you just want to
know which one you should use well the
first thing is which device do you want
to use if you want to use an ice 40 I'd
probably recommend using next PNR the um
work there is much more um stable and
like production ready if you want to use
Series 7 at the moment your only choice
is ver routing um if you want to use EB
5 at the moment your only choice is next
Pinner
[Music]
um the reason both exist is that
VPR has been around found for a long
time it was the academic standard for
doing fpga research but because it was
mainly targeted as a research tool it
wasn't really well suited to targeting
real fpj which tend to
have um little bits of area where they
tend to be a bit less regular than you
really want to model when doing research
about for example how big your fpga
should
be um next
p was started because of that uh next p
was an experiment to show that maybe you
could do a place and Route tool from a
fresh start and produce something that's
useful in a short period of time um the
symbiotic Eda team did a really good job
of proving that yes it was um it has a
really cool gooey
and um doesn't suffer from the fact that
it's over 15 years old and so it's
written in modern C++ it doesn't you
know have its own smart pointers and all
these other things that co- bases that
have been around for that long due
um
so that's kind of why this exists
there's still an open question though if
next is going to hit some type of
barrier that VPR has already solved
vpr's been around for a long time and
has already solved a lot of problems
it's solved so many problems that it's
kind of forgotten about half the
problems that solved it's also been used
as the basis for commercial place and
Route tools before um if you know
altia um the quartis tool chain was or
originally based on VPR um that's also
been a little bit of a challenge because
uh you kind of look at VPR it doesn't
quite map to the xyx style of way of
doing things as much because it was much
more heavily influenced by arterior
Design
devices um so that's kind of why these
tools um exist and we actually think
it's healthy to have um some type of
competition
in the open source space if you look at
um GCC and lvm for example GCC has
gotten a huge amount better since llvm
has become a viable competitor to GCC if
you look at like the Improvement in
error messages from like GCC 6 to GCC 9
it's been significantly improved and in
some ways is probably now better than LM
um before that they just didn't care and
they didn't have the competition to
drive that forward and
so that's kind of like a parallel we see
here VPR in this case is probably closer
to the GCC analogy and nexpa is kind of
the lvm one it's kind of the new hot one
that's um started from scratch with all
the learnings vpr's kind of the older
crafty one but has been around forever
um um it was also really good to have
the academics who are doing you know all
this Research into new fpga
architectures and designs to be using
the same set of tools that we're using
for real designs um and so we think
there is also importance in getting the
academics to start targeting real
devices rather than these virtual fake
devices they targeted for the last 20
years because that will help them
provide better research that we can use
in things like
next um so I'm sure Clifford will have
an opinion about whether you should be
using next PNR or VPR um next um I will
give you two guesses about what his
suggestion is um but uh next p only new
it's only been around six 6 months is um
hopefully will standard test of time um
but we don't really know
um so yeah that's kind of why this has
happened it's also like in the open
source World hurting cats is like
impossible I would love to have
everybody work on um you know one
tooling at first um but I don't always
get my wish so um
yeah okay we have time for a quick
question I think there was one from the
internet left uh that's already been
answered perfect then we have one at
microphone
to hi um I was wondering you were
talking about um legal issues
surrounding the reverse engineering of
the bitstream are there any fbga vendors
that are willing to collaborate on this
project or are they generally
hostile there s so there are vendors who
are actively hostile there are vendors
who are kind of neutral and then there
are vendors who are starting to think
that maybe this could
work um no vendor has yet to come to the
support of the open
source um tooling
um I would hope that any vendor that
does would then be well supported by you
guys because
ultimately they care about the number of
sales of
fpgas um they don't care about the
tooling they don't care about anything
else they care about their bottom line
and so it has to be a profitable thing
for them to do um we believe that this
is going to make fpgas way more
accessible and so the f J Market's going
to go grow to you know 100 or a thousand
times the size it is now and so even if
they lose percentage market share
they're going to have a smaller slice of
a much bigger pie and so be making a lot
more money um but they're obviously
skeptical
um they have to you know report to their
shareholders um and so convincing them
is an uphill battle if you have a
project that needs a million
fpgas and are willing to go to a vendor
and say I'm only using your tools uh
only using open source tools um do your
part support it that would be really
helpful um come talk to me um if you
happen to work at a company that would
be willing to buy a million fjs um
please do come talk to to me um I'm sure
there's lots we can discuss about okay
then thank mythro again with a warm
Round of
[Applause]
[Music]
Applause
[Music]
oh