SymbiFlow - Finally the GCC of FPGAs!

Video thumbnail (Frame 0) Video thumbnail (Frame 1482) Video thumbnail (Frame 2845) Video thumbnail (Frame 4302) Video thumbnail (Frame 7543) Video thumbnail (Frame 10044) Video thumbnail (Frame 11749) Video thumbnail (Frame 15496) Video thumbnail (Frame 19084) Video thumbnail (Frame 20378) Video thumbnail (Frame 23241) Video thumbnail (Frame 26136) Video thumbnail (Frame 28388) Video thumbnail (Frame 32998) Video thumbnail (Frame 34450) Video thumbnail (Frame 35687) Video thumbnail (Frame 37830) Video thumbnail (Frame 39104) Video thumbnail (Frame 40367) Video thumbnail (Frame 41959) Video thumbnail (Frame 43873) Video thumbnail (Frame 45869) Video thumbnail (Frame 47466) Video thumbnail (Frame 48796) Video thumbnail (Frame 50011) Video thumbnail (Frame 51425) Video thumbnail (Frame 53305) Video thumbnail (Frame 54583) Video thumbnail (Frame 58120) Video thumbnail (Frame 59947) Video thumbnail (Frame 63206) Video thumbnail (Frame 64510) Video thumbnail (Frame 66130) Video thumbnail (Frame 68360) Video thumbnail (Frame 69766) Video thumbnail (Frame 73599) Video thumbnail (Frame 79502) Video thumbnail (Frame 80719) Video thumbnail (Frame 82586) Video thumbnail (Frame 88370)
Video in TIB AV-Portal: SymbiFlow - Finally the GCC of FPGAs!

Formal Metadata

Title
SymbiFlow - Finally the GCC of FPGAs!
Subtitle
A fully FOSS, Verilog to bitstream, timing driven, cross FPGA, usable toolchain.
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
The SymbiFlow project aims to be the "GCC of FPGAs" - a fully open source toolchain supporting, multiple FPGAs from different vendors. Allowing compilation from Verilog to bitstream without touching vendor provided tools, it includes support for large modern FPGAs like the Lattice ECP5 and Xilinx 7 series. These FPGAs can be used for things previously out of reach of FOSS tools, things like high resolution video and many gigabit networking. We have also documented the FPGA bitstreams to allow other new tools and a process for replicating this effort on new types of FPGAs!
Keywords Hardware, Making

Related Material

The following resource is accompanying material for the video
Video is cited by the following resource
Dataflow Open source Information Software developer Projective plane Musical ensemble Field programmable gate array
Digital signal processor Reduced instruction set computing Arm Projective plane Real-time operating system Field programmable gate array Microcontroller Field programmable gate array Befehlsprozessor Computer hardware Befehlsprozessor Computer hardware Booting
Dataflow Open source Computer hardware Lattice (group) Chain Projective plane Field programmable gate array UML
Dataflow Digital electronics Open source Computer file Multiplication sign Generic programming Mereology Logic synthesis Arm Formal language Front and back ends Heegaard splitting Exploratory data analysis Latent heat Sic Software Computer hardware Linear programming Mathematical optimization Descriptive statistics Physical system Arm Projective plane Debugger Java applet Expert system Generic programming Field programmable gate array Equivalence relation Compiler Logic synthesis Exploratory data analysis Software Computer hardware Software testing Formal verification Musical ensemble Mathematical optimization Simulation
Dataflow Freeware Computer file Open source Field programmable gate array Login Mereology Medical imaging Sic Different (Kate Ryan album) Analogy Core dump Damping Multiplication Computer architecture Multiplication Cross-platform Open source Field programmable gate array Bit Logic synthesis Type theory Computer hardware Chain Computing platform Software testing Formal verification Simulation
Open source Multiplication sign Projective plane Field programmable gate array Field programmable gate array Compiler Logic synthesis Wave Proof theory Lattice (group) Time evolution Chain Formal verification Software testing Cartesian closed category Simulation
Dataflow Suite (music) Suite (music) File format Multiplication sign Projective plane Parallel port Field programmable gate array Bit Field programmable gate array Streaming media Logic synthesis Architecture Process (computing) Exterior algebra Computer configuration Formal verification Software testing Damping Series (mathematics) Simulation Routing Computer architecture Routing
Dataflow Open source Texture mapping Streaming media Field programmable gate array Mereology Logic synthesis Front and back ends Architecture Computer architecture Physical system Routing Dialect Suite (music) Projective plane Fitness function Field programmable gate array Bit Line (geometry) Logic synthesis Chain Formal verification Software testing Simulation Routing
Functional (mathematics) Simulation Mapping Field programmable gate array Semiconductor memory Logic synthesis Equivalence relation Architecture Formal verification Formal grammar Formal verification Software testing Software testing Simulation Computer architecture
Simulation Open source Field programmable gate array Continuous integration Field programmable gate array Mereology Power (physics) Revision control Architecture Roundness (object) Lattice (group) Integrated development environment Computer hardware Formal verification Software testing Cycle (graph theory) Endliche Modelltheorie Simulation Physical system
Digital signal processor Open source Database Online help Streaming media Field programmable gate array Revision control Goodness of fit Type theory Clifford algebra Logic Endliche Modelltheorie Routing Source code NP-hard Suite (music) Block (periodic table) Projective plane Field programmable gate array Bit Logic synthesis Single-precision floating-point format Logic Lattice (group) Chain output Endliche Modelltheorie Block (periodic table) Library (computing)
Digital signal processor Perfect group Open source Decision theory 1 (number) Electronic mailing list Mereology Type theory Lattice (group) Very-high-bit-rate digital subscriber line Logic Endliche Modelltheorie Source code NP-hard Link (knot theory) Bit Type theory Logic Lie group Lattice (group) output Endliche Modelltheorie Block (periodic table) Table (information) Electric current Spacetime Library (computing) Series (mathematics)
Context awareness Digital signal processor Open source Online help Primitive (album) Electronic mailing list Open set Mereology Goodness of fit Type theory Logic Selectivity (electronic) Vertex (graph theory) Endliche Modelltheorie Series (mathematics) Partial derivative Source code Series (mathematics) Block (periodic table) Tesselation Moment (mathematics) Bit Exterior algebra Personal digital assistant Logic Chain Vertex (graph theory) Partial derivative Configuration space Endliche Modelltheorie Object (grammar) Block (periodic table) Electric current Library (computing) Series (mathematics)
Metre Digital signal processor Tesselation Block (periodic table) Transport Layer Security Bit Term (mathematics) Total S.A. Pi Read-only memory Semiconductor memory Logic Green's function Program slicing Interface (computing) Logic Computer multitasking Block (periodic table) Series (mathematics)
NP-hard Process (computing) Block (periodic table) Multiplication sign Expression Video game Process capability index Online help Open set Series (mathematics) Semiconductor memory Series (mathematics)
Source code Execution unit Digital signal processor Block (periodic table) Tesselation Projective plane Execution unit Cellular automaton Field programmable gate array Electronic mailing list Field programmable gate array Mereology Complete metric space Type theory Type theory Different (Kate Ryan album) Logic Logic Endliche Modelltheorie Block (periodic table) Physical system Electric current
Source code Suite (music) Dataflow Execution unit Cellular automaton Database Field programmable gate array Electronic mailing list Field programmable gate array Semiconductor memory Mereology Symbol table Type theory Chain Logic Endliche Modelltheorie Physical system Electric current
Type theory Goodness of fit Digital signal processor Process (computing) Block (periodic table) Projective plane Logic 1 (number) Online help Field programmable gate array Block (periodic table) Mereology
Dataflow Texture mapping Online help Bit Streaming media Mereology Hand fan Logic synthesis
Architecture Dataflow Mapping Texture mapping Multiplication sign Chain Software testing Semiconductor memory Mereology Simulation Routing Logic synthesis
Digital signal processor Run time (program lifecycle phase) Mapping Open source Texture mapping Moment (mathematics) Open set Field programmable gate array Logic synthesis Software bug Logic synthesis Graphical user interface Explosion Block (periodic table) Table (information) Routing Routing
Sign (mathematics) Digital signal processor Process (computing) Clifford algebra Computer hardware Expert system Field programmable gate array Online help Whiteboard Booting
Game controller Scaling (geometry) Cellular automaton Microcontroller Semiconductor memory Reduced instruction set computing Coprocessor 32-bit Microprocessor Malware Iteration Microprocessor Energy level Information System on a chip
Explosion Clifford algebra Projective plane Software bug Computer architecture
Scripting language Game controller Digital signal processor Graph (mathematics) Block (periodic table) Microcontroller Online help Semiconductor memory Product (business) Medical imaging Graphical user interface Lattice (group) Logic Different (Kate Ryan album) System on a chip Chain Logic Endliche Modelltheorie Block (periodic table) Routing
Type theory Algorithm Digital signal processor Graph (mathematics) Well-formed formula Network topology Logic Block (periodic table) Traverse (surveying) Routing
Game controller Dynamic random-access memory Microcontroller Bit Online help Dynamic random-access memory Product (business) Process (computing) Logic System on a chip Logic Energy level Software testing Software testing Cartesian closed category Traffic reporting Routing
Type theory Digital signal processor Mapping Texture mapping Projective plane Online help Bit Series (mathematics) Block (periodic table) Routing Logic synthesis
Scripting language Scripting language output Online help Software testing Icosahedron Semiconductor memory XML Library (computing)
File format Moment (mathematics) Stress (mechanics) Online help Dynamic random-access memory Semiconductor memory Parsing Programmer (hardware) Type theory Exploratory data analysis Different (Kate Ryan album) Computer hardware Endliche Modelltheorie Software testing Endliche Modelltheorie Simulation Communications protocol
File format Descriptive statistics
Online help System administrator Multiplication sign Computer hardware Projective plane Website Online help Task (computing) Physical system
Email Wave Projective plane Computer hardware Online help Electronic mailing list Semiconductor memory Routing Task (computing) Product (business)
Email Cross-correlation Process (computing) File format output Bit Electronic mailing list Streaming media Task (computing) Reverse engineering
Slide rule Open source Multiplication sign Flash memory Field programmable gate array Student's t-test Open set Number Formal language Cross-correlation Different (Kate Ryan album) Internetworking Oval Series (mathematics) Booting Physical system Scaling (geometry) Block (periodic table) Projective plane Expert system Bit Type theory Process (computing) Logic Universe (mathematics) Video game Right angle Table (information) Library (computing)
Axiom of choice Area Standard deviation Digital signal processor Multiplication sign Moment (mathematics) Bit Field programmable gate array Frequency Graphical user interface Process (computing) Series (mathematics) Block (periodic table) Routing Routing
Vapor barrier Open source Mapping Military base Multiplication sign Set (mathematics) Parallel port Bit Field programmable gate array Open set Type theory Graphical user interface Pointer (computer programming) Personal digital assistant Analogy Chain Software testing Damping Computer-assisted translation Error message Routing Spacetime Computer architecture
Open source Multiplication sign Projective plane Shared memory Bit Field programmable gate array Mereology Number Pi Roundness (object) Internetworking String (computer science) Program slicing Energy level Musical ensemble Traffic reporting Reverse engineering
[Music] so the next speaker in this hall is Tim mithril he will give you an introduction on Simbi flow or basically yes finally the GCC for FPGAs he's an open source developer a Python guy and maybe a few people who know about his other project HDMI to use be about which there will be another talk later on this Congress so also get catch that and now I can wish you a lot of fun and a lot of informative takeaways from Tim statues yours
so firstly I'm going to give you a quick
promo for another project I do you may know me from a project called Tommy that was an arm microcontroller that in your
USB port since I really love FPGAs we decided to do an FPGA in your USB port I
have a whole bunch of pre-production Hardware here if you help us out I will give you one but be warned it does not have a bootloader yet I am still working on that you can use it as a risk 5 CPU if you want rather than FPGA it runs
micro Python that definitely works and
has a fully open source tool chain ie
what I'm just about to talk about so if you're interested in playing with it I'm interested in getting you hardware if
you contribute this is a way I incentivize people so the first question
is what is Simba fly seen before it's a fairly new project you may not have heard of it before the first thing and foremost thing is
Simba flow is a community it's not just me I am not the person who's done 90% of this work day these are all people who are contributed in some way to the Simba flow project and this is important to understand because the reason I'm up here talking is because we need you to
contribute to Simba flow because to get to where we want to be where we can replace the proprietary tools with fully open source equivalents this 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
[Music] so that kind of tells you what the project is but what you probably came here to learn about is more the toolchain and I have no idea if people in the audience at F PG experts or not so I'm gonna 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 compiler into a generic front end which has a bunch of generic optimizations and then a target specific back end like there's an arm back end and an x86 back end and maybe a mips back end if you're into that but ultimately when you're doing C++ for say x86 you take the C++ front a C++ software you run it through a generic part that are shared and an x86 back end and ultimately you're turning C++ files through this compile step into a binary that you run on your x86 hardware so we can parallel this in the EDA tooling ecosystem you kind of have your description of your hardware in a language like VHDL very log a system very log then you have synthesis tools which kind of take that and convert it into the digital logic and then you have a back-end specific part that converts it into if you're doing SX
and image that you convert a chip out of in FPGA into a bit file that you load into your FPGA and so Simba flow is
currently verilock tooling for taking ver log and generating that binary or bit file that goes onto your FPGA into end this is the simply float or chain
as you saw in the title we can't
describe this as GCC for FPGAs when I'm
talking about that I don't mean we're taking C and C++ and converting into Verilog 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 make GCC GCC is that it's completely free and open its cross-platform and multi platform and it has a pluggable interchangeable architecture and so that is what we mean and we want for simply flow we want an end-to-end fully free and open-source tool chain we want a tool chain that targets multiple platforms multiple types of FPGAs not just one vendors fpga and we want to enable an ecosystem which has a whole bunch of different attempts and the different ways of plugging together the tooling so for a bit of
history of how we got here
Clifford Worf will be giving the next talk started us all off with project icestorm which he actually presented about at CCC I can't remember what year and he demonstrated a full end-to-end 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 fpga tool chain was too hard for open-source this is obviously silly because like they said the same thing it was too hard to do a C compiler it's 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 could project x-ray targeting biz ilex series seven FPGAs these are much bigger and more comprehensive FPGAs than the ice 40s and this is kind of when Simbi flow or the idea of simba flow kind of started all of a sudden we now had two different paths 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 calling simple 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 but one of the important things we did with proto 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 v alice fpga which is another large fpga we originally were targeting a thing could very log two routing parallel to routings been around for a long time 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 NEX PNR as an alternative to Verilog to routing to try and another option for doing place and route and so this is what we call the Simba flow tool suite this is what enables you to take a very log file and divert it into a bit stream that you can load on an FPGA going into more detail the first
thing you kind of need to create this tool chain is the documentation for the bit stream 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 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 Simba flow project but other people can take the documentation and target these FPGAs without having to ask us then you have the place and wrap tools we're still continuing down the line of supporting fair locks or routing but we've also got next Pienaar there's also Joseph Joseph I think is the best example of a really great open source project that does synthesis and we use that as the front end no matter what the back end is whether its next PNR or whether it's very long to routing and then we have this last thing that we call the architecture definitions 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 that 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 feed into very logs routing we're still trying to figure out how they might feed into necks PNR they also feed into the synthesis because the synthesis needs to know what things inside the FPGA to mapped it lastly what we're trying to do is make these architecture architecture definitions describe the functionality that's actually in the chip so that we can do verification and testing and simulation of what is actually going on
inside their pga this should allow us to do interesting things like formal equivalence checking to prove that the design you started with when maps to an FPGA actually matches and this is invaluable improving there out toolchain actually works the other idea is that this executable this architecture definition is executable documentation for the FPGA is actually supposed to be doing and so it should include all the silly things that for example on the ice for tea the
ice for TB Rams do not you cannot access the eyes for TB rounds for the first 40 clock cycles 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 it onto hardware a lot of that is what we want to do in practice this is still very preliminary we're also hoping to make it so that you never have to visit a vendors website to get the documentation you need for example if the lattice for example became very hostile to open source environment we don't want to have to depend on the documentation that laddus provides about the features in the fpga 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 bit streams or the bit stream documentation projects this is kind of a
summary of where we're at I'm gonna go
into more detail now if you look at the
ladder size 40 this is the first project that the documentation was done for 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's 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 hard blocks the i/o all that is already documented and things you can use right now and we also have pretty good verilock models of most of the things some of the hard IP could use some good models which demonstrate some of the peculiar behaviors of some of the hard IP and we still need some tech replacement libraries for example if you want to use a design that was originally targeting the proprietary tools it would be good to have libraries which allow you to use the proprietary tool version on the open source tool chain but if you using the open source tool chain directly you don't need those so that's nice for tea ice for these are quite small FPGAs they're reasonably simple but they're great for very small devices
like the FPGA Tom ooh that is inside your USB port obviously is not much space that makes it perfect for this type of device if we instead look at the lattice EC b5 which is perfect trellis Dave sha started after on this and yet managed to somehow finish before us Dave's amazing he has support for pretty much all the ECP five parts out there DCP five goes up to 85,000 logic for input logic look-up tables and it has high-speed transceivers I believe the documentation includes the high speed transceivers so you can use them with open-source tools 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 the design but pretty much everything you could think of is documented again it would be really nice to have some better very old models 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 and also we still don't have tech replacement libraries here if you want to understand
exactly what the bitstream inside the ec p5 looks like you can actually go and watch this video it'll give it given at a conference about two or three months ago called a conf and Dave char goes into excruciating detail about exactly how the bitstream works and some of the very interesting decisions around how things work this is the one everybody's
probably here to talk about I would highly recommend that if you don't have to use the Select 7 series you really consider the EC p5 most people the EC p5 is a viable alternative that is cheaper and better for open-source use cases and is fully documented Bridget x-ray however is coming along really well we're mainly targeting at the moment the Arctic's seven specifically the ec7 a 50 t but that also includes the 15 and 35 T and the context 7 we have some experimental support for context 7 and very recently like a week ago some zinc stuff started landing and our goal is to support all of the series 7 parts that's the Artic 7 the Kintex 7 the vertex 7 there's all the zinc's with the series 7 style fabric we already have complete documentation for all the bits in the co B's 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 I Arby's we still have no documentation for any of the hard blocks or the DSPs we also don't have very good verilock models for any of these yet this would be lovely to have help we also don't have replacement tech libraries for a lot of the compatibility with Silex designs I'm assuming most people here probably have existing Silex designs that they want to port to the seri r2 the open tool chain these tech replacement libraries are very important for that because there are a lot of kind of primitive objects that Silex 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 artic 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 there's still a lot of red but it's getting there and this is actually slightly out of date probably the IOB should be orange and some of the block Rams should be orange so it's quickly becoming more and more green and this is enough to do a lot of things this is for example the CEO beast
and logic slices you can see that we have zero unknown bits for these logic slices and the slice M's which are the distributed memory we also know all the bits for those John McMaster the person
you can see on the side there is here at 35 c3 he is spending most of his time at the open FPGA assembly and he would love to help you get into bitstream documentation for the series 7 will not kind of be odd to do this all ourselves John you know wants to have a life as well 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 these these three projects give us 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 bitstream documentation for many different parts but because we want to expand this to every FPGA out
we're doing something interesting as well this here if people know their history you might recognize as probably the first-ever FPGA commercial FPGA logic block it comes from the XE 2018 which was available for the really awesome unit price of 55 each it came with about 64 tiles 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 were 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 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 symbol 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 you might notice that project 20 64 has a lot of orange because it doesn't have paths 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 FPGA out there and so if you're using an FPGA that isn't as I like 7-series we would love your help in documenting it and we've kind of come up with a fairly good Prosser 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 six in the Spartan three these are very popular FPGA is that there's millions and millions of them out there 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 and we don't have support for any out here apart if there are out to your fans out there we would love your help there there have been some attempts to document some our tira parts I don't know the exact status of that I believe Robert who was working on that maybe in the audience or maybe here at GCC somewhere you should go and check to him and see if you can help get some of that stuff upstream into semi flow but just documenting the bitstream
is only like a third of the battle you also need to create tools to generate the bit stream and the bit stream needs to be documented before you can generate stuff for it but it's not just enough to document the bit stream you also need the tooling to generate the bit stream and so what's the status of that
as part of doing the mapping and placing route you need support in both Yosef and one of the place and route tools both the place and route tools use Yosef as a front-end so you're going to need support in Yosef to be part of the Simba flow tool chain both next PNR and Vera log to routing a timing driven place and route this is what all the commercial tools use if you've used a Ratner PNR you'll know that's not a timing driven place around which was another reason why next PNR was started as a replacement for Iraq now to give us
timing driven place and route and so this is kind of a summary of where
synthesis mapping and place and route is kind of act next PNR is probably the
best solution at the moment for laddus ice 40 you kind of see the awesome GUI they have here the status is that you
should just be using next PNR for latter size 40 right now it should beat a Ratna PNR in everything apart from runtime and even in runtime it should be pretty close the people at the open fpga 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 a rack now for place and route it'd be much better if they talked about using NEX PNR for place and route now next Pienaar is also being
used at tutorial sessions that the symbiotic idat and estin who created this icebreaker board I believe there may be a few slots left but I'm not sure they kind of were running out if you gone big maybe they'll run a few more tutorial sessions I highly recommend you go along and find out 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 FPGA is a nice forty design 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 I'd love help I will give you balls if you have the ability to help next beam
are also supports the ladder CC p5 again this is the awesome work of Dave sharp
it supports what I call IOT microcontroller level system on chip designs this is things like little 32-bit risc 5 processors but it scales up to doing full Linux compatible microprocessor system-on-chip
dave has an example of Linux running on the open risk 1k running on a CP 5 it's still early but it's definitely ready if you want to experiment with it 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 ECP 5 it would be really useful for you to try your designs and see whether they work I would not say make this in your critical path yet but it's definitely ready for experimenters and that's kind of what next Pienaar
supports clifford will be giving a talk next after this talk on next P&R so you can get all the really gritty details i believe some of that may include even how to add new architectures to necks peanut so if you're interested in that please stay around then we also have
support for the lattice ice 40 in Verilog to routing and you can kinda see some images of the verilux routing GUI here showing some designs as you can see it's a lot less pretty than the next P in r1 this is kind of the difference between having academics to gooeys and other people do gooeys the latter size 4 to e in Verilog the routing has support for logic and block Rams but only has a really simple IOB model it doesn't have any DSP blocks or any of the hard block supported yet you can definitely do a blinky or a IOT microcontroller sock using Verity routing but I would not say it's a production tool chain yet there
are definitely a whole bunch of serious issues with it we need to fix like the fact that it might use more than 4 Giga RAM to do a fairly small thing none of this is fundamentally caused by Verrill l2 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 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 I'm terrible at graph traversal my graph to tree traversal is probably you know into a thousand I'd love people who have better algorithms to come in like make it n log in or whatever the correct way to do these things are I am not good at that type of thing it works please come and help make it better but the thing
you that's probably more interesting is that we have basic support for the Silex art x7 in Vera lotta routing with this
there's logic and DRAM like distributed RAM this is enough to do a blinky like a counter 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 to train 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 CCC
but I got distracted by doing tamir FPGA stuff this is as I said very close to working we would love your help in making it work a lot of it is just you know working through the process and then debugging when it fails some of it is a little bit complicated 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 the ice 40 is pretty much well supported by everything project x-ray is currently only really supported by verilock 2 routing I know the next PNR guys chomping at the bit to add series 7 support to next Pienaar and but have kind of been holding off until we can kind of prove that it works in parallel chaotic if you're using ECB 5 then next peon ours your best bet because vpr doesn't support ECB 5 pretty much at all and 2064 doesn't work at all yet 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 your sis problem with having don't been doing this for like two years now is I've forgotten all the things that you don't know when you start 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 to 2064 to things like next PNR and to things like very logged routing so as i said at the beginning
this is a big project it's probably 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 a hundred percent sure I can find something for you to do because almost all our scripts are written in Python if you know C++ there's definitely a huge amount of stuff you can do but next PNR and BPR are written in c++ a lot of the shared libraries original 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 for example the input and output library for VP are at
the moment just reads the whole file in and then starts processing it you don't need to know anything about how Hardware works to fix that problem that's just a simple event-driven parser 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 Tico we would love your help because I'm not going to learn tickle and pretty much all the EDA tools out there use tickle I know John has an interesting relationship protocol from using it through the vaad oh I'm sorry that you had to do that John so if you know tickle please help us 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 if you know verilock as i said a lot of the simulations and models are written in vera log we would love your help doing that as well as simple designs like even if you aren't extremely competent with vera log writing things like the simple thing that reads writes a bunch of values into the DRAM 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 vera log 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 and so you could definitely help there he is kind of a blast from the past if you know XML almost all the formats fire
formats going into Verrill to routing XML a lot of the formats coming out of very lots routing XML a lot of that is done by printf that would be nice to be replaced as well as things like having style sheets which confirm that your XML you know matches a description that is useful things you can do or having tools that transfer and XML from one format to another format is also really useful so you can brush off those excel ste skills from the late 90s and early 2000s and help us out there if you know English which most of you hopefully do otherwise
you've probably been very bored you can help with things like the documentation things like improving the readme improving like how to get started
documentation improving the website if you know JavaScript I'm terrible at JavaScript please come and help make our website better if you're a sysadmin and know things like docker we would love
for the setup to be much much easier things like docker can apparently make that happen things like improving our CI system with docker is another way you
could definitely help if you have time
to contribute 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
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 so we're about 43 minutes apparently I'm going to go into questions 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 for the time please do stay around for Clifford's talk if you want to like understand the really Nitti greet greet nitty gritty details about how things like place and route work and I'm sure Clippard would love help with next B&R I'm saw Dave Shar would love help with Nick's PNR it's a very cool new tool that is less than six months old and is already useful for production stuff okay 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 mark on one please yes how did you reverse engineer the bitstream formats so what we do is document the bitstream format so that tools can be written that are compatible with them what we don't do is reverse engineer the tooling directly we forbidden by our legal advisers from attaching for example gdb to Vivaro what we are allowed to do is basically put a lot of input into serve our dough and take a lot of bit streams and then you do this process of cross correlation
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 randomized a lot of the designs that are going in this correlation approach allows you to resolve that bit uniquely and I'm however no expert on the bitstream documentation side of things John master is done a huge amount of work on the series seven documentation and Dave Shah has done a huge amount on the ECP five work both of those guys are here at Congress and both of them will probably be around open FPGA table most of the time 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 buzzers which document various different bits like the various bits of the logic block should have a readme which describes what it does why it does that and those type of things some of the places we've been a bit naughty and did not include such a readme that's a bug please log it and we will try and add it but definitely we're trying to make it so that this process is 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 please do come and 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 university student or any person out there who has the time can find their favorite FPGA and do this documentation microphone to
please Sarah any support for VHDL in the tool shed sadly not there been a bunch of attempts to do VHDL support in nurse's none of being successful yet if you happen to work a company that has deep pockets symbiotic EDA will actually sell you a license to a proprietary library that does VHDL they didn't write that but it has been integrated into Joseph I don't know many people who do VHDL in the Oba source world it's kind of a chicken and egg problem the open-source world doesn't support VHDL so everybody uses very log and hence the verilock support keeps getting better and the VHDL support goes nowhere it would be awesome if people wanted to work on that I personally would say you're probably better off switching to verilock I do think the HBO's probably in some ways a better language but it's not so much better that I would suggest spending your life adding support to uses for it I mean you'd get my gratitude if you did but I can't actually recommend you do that it's the question from the internet signal engine yes we have two questions from the internet the first is would it be feasible to add support for CPLDs depends what you mean by CP Odie's pretty much everything these days people call CP o DS are actually FPGAs mostly internally if you mean what are they called something like PLA logic style devices um there is some experimental support for that type of device in nurse's I'm not sure yosef 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 I definitely know that the cool runner 2 which has some experimental support was a CP OD and that does have the Endon or type system but I'm not an expert on CP o DS but definitely like most things these days that people call CP o DS are pretty much just FPGAs with flash that allow on chip that allow them to basically boot instantly they're normally luck designs and have very similar things to FPGAs ok first microphone to please can you explain the difference between next PR and verilock 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 will come up so I actually a slides for this one so there
is a lot of duplication between X P n R and V P R that is correct the first question is 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 a nice 40 I'd probably recommend using XP NARR the work there is much more stable and like production-ready if you want to use series 7 at the moment your only choice is very lotta routing if you want to use easy b5 at the moment your only choice is next peanut the reason both exist is
that vpr has been around for a long time it was the academic standard for doing FPGA research but because I was mainly targeted as a research tool it wasn't really well-suited to targeting real FPGAs which tend to have little bits of area where they tend to be a bit less regular then you really want to model when doing research about for example how big your FPGA should be next Pienaar was started because of that next PNR 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 the symbiotic EDA team did a really good job of proving that yes it was it has a really cool GUI and 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 code bases that have been around for that long do so that's kind of why this exists there's still an open question though if next PNR is gonna 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 a solve 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 if you know our tira the Quartus tool chain was originally based on vp r that's also been a little bit of a challenge because you kind of look at vp r it doesn't quite map to the silac style of way of doing things as much because it was much more heavily influenced by our Terra design devices so that's kind of why these tools exist and we actually think it's healthy to have some type of competition in the open-source space if you look at GC seeing lrvm 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 six to GCC nine it's been significantly improved and in some ways is probably now better than LVM 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 VP R in this case is probably closer to the GCC analogy and next been ours kind of the LLVM one it's kind of the new hot one that's started from scratch with all the learnings VPR's kind of the older crafty one but has been around forever it was also really good to have the academics we're doing you know all this research into new FPGAs architectures and designs to be using the same set of tools that were using for real designs and so we think there is also important in getting academics to start targeting real devices rather than these virtual fake devices they've targeted for the last 20 years because that will help them provide better research that we can use in things like next V&R so I'm sure cliff that will have an opinion about whether you should be using next P now VP our next I will give you two guesses about what his suggestion is but next P now selling years only been around six six months hopefully it will stand to the test of time but we don't really know so yeah that's kind of why this has happened it's also like in the open source world herding cats is like impossible I would love to have everybody work on you know one tooling at first but I don't always get my wish so yeah okay we have time
for a quick question I think there was
one from the internet left that's already been answered perfect then we have one at microphone - hi I was wondering you were talking about legal issues surrounding the reverse engineering of the bit string are there any FPGA vendors that are willing to collaborate on this project or are they generally hostile there are levels so their 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 no vendor has yet to come to the support of the open-source tooling 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 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 we believe that this is going to make FPGAs way more accessible and so the fbj market is gonna go grow to you know a hundred or a thousand times the size it is now and so even if they lose percentage market share they're gonna have a smaller slice of a much bigger pie and so be making a lot more money but they're obviously skeptical they have to you know report to their shareholders and so convincing them is an uphill battle if you have a project that needs a million FPGA and are willing to go to a vendor and say I'm only using your tools only using open-source tools do your part support it that would be really helpful come talk to me if you happen to work in a company that would be willing to buy a million FPGAs please do come talk to me I'm sure there's lots we can discuss about okay then thank me throw again with a warm round of applause [Applause] [Music] [Music]
Feedback