SymbiFlow - Finally the GCC of FPGAs!
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 165 | |
| 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 | 10.5446/39225 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
35C3 Refreshing Memories133 / 165
2
5
6
7
8
9
10
11
12
13
15
16
17
22
26
29
30
31
33
37
38
39
40
44
45
48
49
53
54
55
57
59
60
62
65
66
69
70
72
73
74
77
80
82
83
84
85
86
87
89
92
94
100
104
105
106
107
108
111
113
114
115
116
117
119
121
122
123
124
127
132
133
136
139
141
143
144
145
146
148
149
150
154
155
156
157
158
159
160
161
162
163
164
165
00:00
Musical ensembleSoftware developerDataflowOpen sourceProjective planeField programmable gate arrayInformationLecture/Conference
00:59
Digital signal processorComputer hardwareField programmable gate arrayReduced instruction set computingBefehlsprozessorReal-time operating systemProjective planeMicrocontrollerArmField programmable gate arrayBootingComputer hardwareBefehlsprozessorLecture/ConferenceProgram flowchartComputer animation
01:54
Computer hardwareField programmable gate arrayLattice (group)ChainOpen sourceProjective planeDataflowXMLUMLComputer animation
02:52
SoftwareGeneric programmingArmMathematical optimizationJava appletComputer hardwareFormal verificationSoftware testingSimulationLogic synthesisField programmable gate arrayExploratory data analysisSicEquivalence relationDataflowOpen sourceMultiplication signProjective planeMusical ensembleExpert systemSoftwareGeneric programmingFront and back endsCompilerFormal languageHeegaard splittingBinary codeMereologyPhysical systemDescriptive statisticsComputer fileComputer hardwareLogic synthesisDigital electronicsLatent heatMathematical optimizationArmExploratory data analysisLinear programmingDebuggerComputer animationXML
05:02
Computer hardwareSoftware testingFormal verificationField programmable gate arraySimulationSicLogic synthesisFreewareOpen sourceMultiplicationComputing platformBitDataflowMedical imagingComputer fileField programmable gate arrayDampingChainLoginType theoryDifferent (Kate Ryan album)AnalogyMereologyOpen sourceCross-platformCore dumpComputer architectureMultiplicationLecture/ConferenceComputer animation
06:42
WaveTime evolutionLogic synthesisField programmable gate arraySoftware testingFormal verificationSimulationBitCartesian closed categoryLattice (group)Projective planeChainMultiplication signField programmable gate arrayCompilerProof theoryOpen sourceClifford algebraXMLUMLComputer animationProgram flowchartLecture/Conference
07:50
Logic synthesisField programmable gate arraySoftware testingFormal verificationSimulationArchitectureRoutingSeries (mathematics)Multiplication signComputer fileRoutingField programmable gate arrayProjective planeExterior algebraMereologyComputer architectureComputer configurationDampingProcess (computing)Suite (music)Parallel portStreaming mediaBitSeries (mathematics)File formatDataflowComputer animationProgram flowchart
10:20
Suite (music)RoutingLogic synthesisField programmable gate arrayArchitectureSoftware testingFormal verificationSimulationTexture mappingProjective planeChainDialectBitStreaming mediaRoutingMereologyLine (geometry)Fitness functionFront and back endsField programmable gate arrayComputer architecturePhysical systemOpen sourceDataflowLogic synthesisXMLUMLComputer animationProgram flowchart
12:43
Semiconductor memorySoftware testingSimulationRoutingComputer architectureFormal verificationLogic synthesisFunctional (mathematics)Lecture/Conference
13:35
SimulationSoftware testingFormal verificationField programmable gate arrayArchitectureComputer architectureMappingFormal grammarEquivalence relationEndliche ModelltheorieIntegrated development environmentSoftware testingSimulationContinuous integrationCycle (graph theory)Power (physics)Open sourcePhysical systemRevision controlComputer hardwareRoundness (object)Field programmable gate arrayLattice (group)Program flowchart
15:30
Suite (music)Field programmable gate arrayLogic synthesisRoutingBlock (periodic table)LogicDigital signal processorClifford algebraDatabaseSource codeLattice (group)Type theoryEndliche ModelltheorieSingle-precision floating-point formatNP-hardMereologyStreaming mediaBitProjective planeBlock (periodic table)Field programmable gate arrayOnline helpOpen sourceRevision controlLibrary (computing)Endliche ModelltheorieLattice (group)ChainGoodness of fitoutputLogicProgram flowchartComputer animation
17:25
Block (periodic table)Endliche ModelltheorieDigital signal processorNP-hardSource codeLattice (group)Electric currentType theorySeries (mathematics)LogicLink (knot theory)Lie groupElectronic mailing listMereologyTable (information)SpacetimePerfect groupOpen sourceBitEndliche ModelltheorieLattice (group)LogicoutputType theoryLibrary (computing)1 (number)Very-high-bit-rate digital subscriber lineProjective planeComputer animation
18:56
LogicLattice (group)Type theoryElectric currentDigital signal processorSource codeEndliche ModelltheorieSeries (mathematics)Block (periodic table)Partial derivativeVertex (graph theory)Electronic mailing listVideoconferencingDecision theoryOpen sourceMereologyCASE <Informatik>Exterior algebraPrimitive (album)Moment (mathematics)Object (grammar)Library (computing)Goodness of fitSeries (mathematics)Configuration spaceBitRoutingBlock (periodic table)Projective planeEndliche ModelltheorieLogicPartial derivativeSeries (mathematics)Selectivity (electronic)Vertex (graph theory)Online helpChainContext awarenessOpen setTesselationComputer animation
22:00
Series (mathematics)Computer multitaskingBlock (periodic table)Digital signal processorPiInterface (computing)Term (mathematics)LogicRead-only memoryTotal S.A.Series (mathematics)TesselationBlock (periodic table)Green's functionTransport Layer SecurityLogicBitProgram slicingMetreSemiconductor memoryComputer animationXMLDiagramTable
22:58
Series (mathematics)Semiconductor memoryProcess capability indexMultiplication signVideo gameOpen setSeries (mathematics)NP-hardBlock (periodic table)Process (computing)ExpressionOnline helpComputer animationLecture/Conference
23:47
LogicBlock (periodic table)Digital signal processorSource codeEndliche ModelltheoriePhysical systemExecution unitElectric currentType theoryElectronic mailing listCellular automatonField programmable gate arrayType theoryProjective planeField programmable gate arrayDifferent (Kate Ryan album)MereologyLine (geometry)NumberGreatest elementComplete metric spaceShared memoryOpen sourceMultiplication signPiExecution unitBlock (periodic table)LogicTesselationTraffic reportingProgram slicingComputer animation
25:13
Electronic mailing listPhysical systemEndliche ModelltheorieLogicDatabaseExecution unitSource codeElectric currentType theoryField programmable gate arrayCellular automatonSemiconductor memoryMereologyField programmable gate arrayDataflowSymbol tableMusical ensembleSuite (music)ChainRoundness (object)Computer animationLecture/Conference
26:04
LogicBlock (periodic table)Digital signal processorProcess (computing)MereologyOnline helpField programmable gate array1 (number)Projective planeType theoryBlock (periodic table)Goodness of fitComputer animation
26:55
MereologyField programmable gate arrayHand fanDataflowOnline helpComputer animationLecture/Conference
27:58
Texture mappingLogic synthesisArchitectureSoftware testingSimulationStreaming mediaBitRoutingMappingMereologyDataflowMultiplication signChainComputer animation
29:15
Semiconductor memoryLogic synthesisTexture mappingRoutingDigital signal processorBlock (periodic table)RoutingLogic synthesisMappingMoment (mathematics)Lattice (group)Graphical user interfaceBeat (acoustics)Run time (program lifecycle phase)Table (information)Open setField programmable gate arrayLecture/ConferenceComputer animationXMLUML
30:02
ExplosionSign (mathematics)Clifford algebraRoutingOpen sourceSoftware bugExpert systemWhiteboardComputer animation
31:17
Digital signal processorComputer hardwareField programmable gate arrayCellular automatonMalwareIterationInformationMicroprocessorGame controllerProcess (computing)BootingOnline helpWhiteboardLattice (group)Level (video gaming)Scaling (geometry)MicrocontrollerSystem on a chipMicroprocessor32-bitReduced instruction set computingCoprocessorInternet der DingeComputer animationXMLSource code
32:11
Semiconductor memoryExplosionProjective planeSoftware bugLecture/ConferenceComputer animation
32:59
Clifford algebraRoutingGame controllerSystem on a chipDigital signal processorBlock (periodic table)LogicComputer architectureClifford algebraMicrocontrollerLattice (group)Block (periodic table)Graphical user interfaceEndliche ModelltheorieDifferent (Kate Ryan album)Medical imagingProduct (business)LogicChainComputer animation
34:17
Semiconductor memoryRoutingDigital signal processorLogicBlock (periodic table)Scripting languageGraph (mathematics)Online helpType theoryTraverse (surveying)Network topologyAlgorithmLoginLecture/ConferenceComputer animation
35:32
RoutingWell-formed formulaLogicDynamic random-access memorySoftware testingLogicSoftware testingDynamic random-access memoryLevel (video gaming)MicrocontrollerProduct (business)Cartesian closed categoryComputer animationDiagramXMLLecture/Conference
36:23
RoutingSystem on a chipGame controllerLogicDynamic random-access memorySoftware testingDigital signal processorBlock (periodic table)Logic synthesisTexture mappingOnline helpBitProcess (computing)Traffic reportingField programmable gate arraySeries (mathematics)MappingType theoryProjective planeSeries (mathematics)Computer animation
38:45
IcosahedronSemiconductor memoryScripting languageProjective planeOnline helpLibrary (computing)outputScripting languageSoftware testingMoment (mathematics)Computer animationLecture/ConferenceXMLUML
39:58
Semiconductor memoryExploratory data analysisEndliche ModelltheorieSimulationParsingProgrammer (hardware)Moment (mathematics)Computer hardwareProcess (computing)Online helpStress (mechanics)Software testingComputer simulationDynamic random-access memoryType theoryDifferent (Kate Ryan album)File formatEndliche ModelltheorieCommunications protocolLecture/ConferenceComputer animation
42:08
File formatDescriptive statisticsLecture/Conference
43:00
Online helpTask (computing)Online helpWebsiteSystem administratorPhysical systemMultiplication signProjective planeComputer hardwareComputer animationLecture/ConferenceXML
44:05
Semiconductor memoryElectronic mailing listEmailTask (computing)Computer hardwareProjective planeWaveProduct (business)Clifford algebraOnline helpRoutingLecture/ConferenceComputer animation
45:34
Task (computing)Electronic mailing listEmailReverse engineeringoutputProcess (computing)Cross-correlationFile formatDirection (geometry)Streaming mediaBitComputer animation
46:31
Series (mathematics)Multiplication signBitOpen setExpert systemTable (information)Universe (mathematics)Student's t-testField programmable gate arrayBlock (periodic table)Projective planeLogicProcess (computing)Different (Kate Ryan album)Type theoryNumberCross-correlationScaling (geometry)Software bugFuzzy logicUniqueness quantificationSeries (mathematics)Lecture/Conference
49:04
InternetworkingFlash memoryExpert systemOvalVideo gameLibrary (computing)Right angleSlide ruleField programmable gate arrayLogicType theoryBootingDifferent (Kate Ryan album)Open sourceFormal languagePhysical systemComputer animation
53:00
Block (periodic table)RoutingDigital signal processorSeries (mathematics)Multiplication signAxiom of choiceSeries (mathematics)Moment (mathematics)XMLComputer animation
53:49
Graphical user interfaceStandard deviationProcess (computing)Multiplication signBitField programmable gate arrayFrequencyRoutingAreaComputer animation
55:03
Basis <Mathematik>CASE <Informatik>Computer-assisted translationMultiplication signOpen setSpacetimeExistenceType theoryComputer architectureParallel portRoutingSet (mathematics)Pointer (computer programming)BitAnalogyVapor barrierDampingMilitary baseLevel (video gaming)Error messageOpen sourceChainSoftware testingField programmable gate arrayLecture/ConferenceMeeting/Interview
58:55
Graphical user interfaceInternetworkingBitReverse engineeringLevel (video gaming)String (computer science)Projective planePerfect groupNumberField programmable gate arrayRoundness (object)PiMultiplication signProgram slicingTraffic reportingOpen sourceComputer animation
Transcript: English(auto-generated)
00:19
So, the next speaker in this hall is Tim Mithraux.
00:25
He will give you an introduction on SymbiFlow, or basically, yes, finally the GCC for FPGAs. He's an open source developer, a Python guy, and maybe a few people know him about
00:43
his other project, HDMI2USB, about which there will be another talk later on this Congress, so also catch that, and now I can wish you a lot of fun and a lot of informative takeaways from Tim. The statue is yours.
01:00
Thank you. So, firstly, I'm going to give you a quick promo for another project I do. You may know me from a project called Tomu. That was an ARM microcontroller in your USB port.
01:26
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
01:44
have a bootloader yet. I'm still working on that. You can use it as a RISC-V CPU if you want, rather than FPGA. It runs MicroPython. That definitely works. And it has a fully open source toolchain, i.e. what I'm just about to talk about.
02:05
So, if you're interested in playing with it, I'm interested in getting you hardware. If you contribute, this is a way I incentivise people. So, the first question is, what is SymbiFlow?
02:23
SymbiFlow is a fairly new project. You may not have heard of it before. The first thing and foremost thing is, SymbiFlow is a community. It's not just me. I am not the person who's done 90% of this work.
02:42
These are all people who have contributed in some way to the SymbiFlow project. And this is important to understand, because the reason I'm up here talking is because we need you to contribute to SymbiFlow. Because to get to where we want to be, where we can replace the proprietary tools
03:03
with fully open source equivalents, 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.
03:21
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 are FPGA 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
03:40
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,
04:02
if you're into that. But ultimately, when you're doing C++ for, say, x86, you take the C++ software, you run it through a generic part that is shared
04:23
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.
04:43
You kind of have your description of your hardware in a language like the HDL Verilog system Verilog. 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 ASX,
05:02
an image that you convert a chip out of in FPGAs into a bit file that you load into your FPGA. And so, SymbiFlow is currently Verilog tooling for taking Verilog and generating that binary or bit file that goes onto your FPGA end-to-end.
05:28
This is the SymbiFlow toolchain. As you saw in the title, we kind of described this as GCC for FPGAs. When I'm talking about that, I don't mean we're taking C and C++
05:44
and converting it into Verilog or directly into something that runs on the FPGA. What I'm using is, as an analogy, some of the core parts of what makes GCC GCC is that it's completely free and open.
06:03
It's cross-platform and multi-platform, and it has a pluggable, interchangeable architecture. And so that is what we mean and we want for SymbiFlow. We want an end-to-end, fully free and open-source toolchain. We want a toolchain that targets multiple platforms
06:23
multiple types of FPGAs, not just one vendor's FPGA. And we want to enable an ecosystem which has a whole bunch of different attempts and different ways of plugging together the tooling.
06:43
So, for a bit of history of how we got here, Clifford Wharf, who 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.
07:01
And he demonstrated a full end-to-end toolchain that targeted the Lattice Ice 40. This was pretty impressive because, up until that time, there was always this idea that doing a FPGA toolchain
07:24
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's kind of turned out to be wrong. And Clifford delivered us the proof that this was at least possible.
07:47
Then Clifford just kind of likes to keep getting stuff done. And so he started a project called Project X-Ray, targeting the Xylex Series 7 FPGAs. These are much bigger and more comprehensive FPGAs than the Ice 40s.
08:07
And this is kind of when SymbiFlow, or the idea of SymbiFlow, 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.
08:24
And so I talked to Clifford, and we decided that what we really need is a project to bring everything together. And so at 34C3 last year,
08:41
we launched what we're calling SymbiFlow, which was an 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 Project X-Ray
09:02
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 ECP5 Alice FPGA,
09:23
which is another large FPGA. We originally were targeting a thing called Verilog to Routing. Verilog to Routing's been around for a long time. But some people on the team wanted to basically create
09:42
a new place and route tool from scratch. And so the people at Symbiotic EDA launched this new project called NextPNR as an alternative to Verilog to Routing to try and provide another option for doing place and route.
10:02
And so this is what we call the SymbiFlow 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.
10:22
Going into more detail, the first thing you kind of need to create this toolchain is the documentation for the bitstream that goes on the FPGA.
10:42
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 Icestorm, Project X-Ray, and Project Trellis kind of fit into.
11:01
They're trying to create documentation that anybody can use to create new tools. We kind of consider them part of the SymbiFlow project, but other people can take the documentation and target these FPGAs without having to ask us.
11:24
Then you have the place and route tools. We're still continuing down the line of supporting Verilog to Routing, but we've also got NextPNR. There's also YoSIS. YoSIS, I think, is the best example
11:43
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 it's NextPNR or whether it's Verilog to Routing. And then we have this last thing
12:01
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,
12:20
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.
12:42
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 Verilog to Routing.
13:03
We're still trying to figure out how they might feed into NextPNR. They also feed into the synthesis because the synthesis needs to know what things inside the FPGA to map to.
13:21
Lastly, what we're trying to do is make these 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 the FPGA.
13:40
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 toolchain actually works.
14:02
The other idea is that this executable, 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,
14:21
the ICE 40 BRAMs do not, you cannot access the ICE 40 BRAMs 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
14:40
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
15:01
so that you never have to visit a vendor's website to get the documentation you need. For example, if the Lattice, for example, became very hostile to the open source environment, we don't want to have to depend on the documentation that Lattice provides about the features in the FPGA.
15:22
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?
15:45
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 Lattice Ice 40,
16:00
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 still aren't supported. And so if you want to contribute,
16:21
we would love your help to add support for those. But pretty much everything, including the logic, the block RAMs, the hard blocks, the IO, all that is already documented and things you can use right now. We also have pretty good Verilog models of most of the things.
16:41
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,
17:02
it would be good to have libraries which allow you to use the proprietary tool version on the open source toolchain. But if you're using the open source toolchain directly, you don't need those. So that's the Ice 40. Ice 40s are quite small FPGAs.
17:22
They're reasonably simple, but they're great for very small devices like the FPGA Tomu that is inside your USB port. Obviously, there's not much space. That makes it perfect for this type of device. If we instead look at the Lattice ECP5,
17:42
which is Project Trellis, Dave Schar started after us on this and yet managed to somehow finish before us. Dave's amazing. He has support for pretty much all the ECP5 parts out there. The ECP5 goes up to 85,000 logic
18:05
for input logic lookup 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.
18:21
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 Verilog models.
18:42
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 ECP5 looks like,
19:04
you can actually go and watch this video. It was given at a conference about two or three months ago called OrConf, and Dave Shah goes into excruciating detail about exactly how the bitstream works,
19:21
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 Xylek 7 series,
19:42
you really consider the ECP5. Most people, the ECP5 is a viable alternative that is cheaper and better for open source use cases and is fully documented.
20:01
Project X-Ray, however, is coming along really well. We're mainly targeting at the moment the Artex 7, specifically the EC7A50T, but that also includes the 15 and 35T. And the Kintec 7, we have some experimental support for Kintec 7.
20:24
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 Artex 7, the Kintec 7, the Vertex 7,
20:41
there's all the zincs with a series 7-style fabric. We already have complete documentation for all the bits in the CLBs, all the logic tiles, and the distributed RAM, and pretty much all of the routing. We have partial documentation for block RAMs, and just recently, IOBs.
21:05
We still have no documentation for any of the hard blocks or the DSPs. We also don't have very good Verilog models for any of these yet. This would be lovely to have help. We also don't have replacement tech libraries for
21:23
a lot of the compatibility with Xylek's designs. I'm assuming most people here probably have existing Xylek's designs that they want to port to the open toolchain. These tech replacement libraries are very important for that,
21:41
because there are a lot of kind of primitive objects that Xylek 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.
22:01
So if you look inside a series 7 Arctic 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,
22:20
and this is actually slightly out of date. Probably the IOB should be orange, and some of the block RAM should be orange. So it's quickly becoming more and more green. And this is enough to do a lot of things.
22:40
This is, for example, the CLBs, the logic slices. You can see that we have zero unknown bits for these logic slices. And the sliceMs, which are the distributed memory, we also know all the bits for those.
23:03
John McMaster, the person you can see on the side there, is here at 35C3. He is spending most of his time at the OpenFPJ assembly, and he would love to help you get into bitstream documentation for the series 7.
23:23
We're not going to be able to do this all ourselves. John wants to have a life as well, so he would love help. And if you, for example, want to use the PCI Express hard block, we would love your help documenting it,
23:41
and we have a pretty good process for doing this. So in summary, you can kind of see that these three projects give us a semblance of that GCC that we were talking about.
24:01
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 there,
24:26
we're doing something interesting as well. This here, if people know their history, you might recognize as probably the first ever commercial FPGA logic block.
24:42
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,
25:00
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 are 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,
25:22
which allows us to demonstrate how you might go about adding support for this part to the toolchain. And that's what we're targeting this. We would love you to help take this and convert it into a tutorial
25:42
that allows you to understand how you might add a new FPGA to the full SymbiFlow 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
26:06
we kind of currently understand the bitstream for. 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.
26:23
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 a Xilinx 7 series, we would love your help in documenting it.
26:40
And we've kind of come up with a fairly good process through 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,
27:02
the Spartan 6 and the Spartan 3. These are very popular FPGAs. 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.
27:22
We don't have support for any Altira part. If there are Altira fans out there, we would love your help there. There have been some attempts to document some Altira parts. I don't know the exact status of that. I believe Robert, who was working on that,
27:43
may be in the audience or may be here at CCC somewhere. You should go and chat to him and see if you can help get some of that stuff upstream into Simiflow. But just documenting the bitstream is only like a third of the battle.
28:06
You also need to create tools to generate the bitstream. The bitstream needs to be documented before you can generate stuff for it, but it's not just enough to document the bitstream.
28:20
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.
28:45
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 Simiflow tool chain. Both NextPNR and Verilog2Routing are timing-driven place and route.
29:03
This is what all the commercial tools use. If you've used Arachnar PNR, you'll know that's not a timing-driven place and route, which was another reason why NextPNR was started as a replacement for Arachnar to give us timing-driven place and route.
29:22
And so this is kind of a summary of where synthesis mapping and place and route is kind of at. NextPNR is probably the best solution at the moment for Lattice Ice 40. You can kind of see the awesome GUI they have here.
29:44
The status is that you should just be using NextPNR for Lattice Ice 40 right now. It should beat Arachnar PNR in everything apart from runtime, and even in runtime, it should be pretty close.
30:01
The people at the OpenFPJ 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.
30:22
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 Arachnar for place and route. It'd be much better if they talked about using NextPNR for place and route now. NextPNR is also being used at tutorial sessions
30:42
that the Symbiotic EDA team and Esden, 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 go and beg, maybe they'll run a few more tutorial sessions.
31:03
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 TomoFPJ is a nice 4D design,
31:22
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 boards if you have the ability to help.
31:44
NextPNR also supports the Lattice ECP5. Again, this is the awesome work of Dave Schar. It supports what I call IoT microcontroller-level system-on-chip designs.
32:02
This is things like little 32-bit RISC-V processes, but it scales up to doing full Linux-compatible microprocessor system-on-chip. Dave has an example of Linux running on the OpenRISC-1K running on ECP5.
32:21
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 ECP5,
32:40
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 NextPNR supports.
33:03
Clifford will be giving a talk next, after this talk, on NextPNR, so you can get all the really gritty details. I believe some of that may include even how to add new architectures to NextPNR, so if you're interested in that, please stay around.
33:23
Then we also have support for the lattice i40 in Verilog to routing, and you can see some images of the Verilog to routing GUI here showing some designs. As you can see, it's a lot less pretty than the NextPNR one.
33:41
This is kind of the difference between having academics do GUIs and other people do GUIs. The lattice i40 in Verilog to routing has support for logic and block RAMs, but it only has a really simple IOB model.
34:01
It doesn't have any DSP blocks or any of the hard blocks supported yet. You can definitely do a blinky or a IoT microcontroller sock using Verilog to routing, but I would not say it's a production toolchain yet. There are definitely a whole bunch of serious issues with it we need to fix,
34:24
like the fact that it might use more than 4 gig of RAM to do a fairly small thing. None of this is fundamentally caused by Verilog to routing. More of it is caused by us experimenting on how to describe these things and learning along the way.
34:43
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 in C if that's so inclined,
35:01
would make a lot of this much, much quicker and use a lot less RAM. I'm terrible at graph traversal. My graph traversal is probably N to 1,000. I'd love people who are better algorithms to come and make it N log N or whatever the correct way to do these things are.
35:25
I'm not good at that type of thing. It works. Please come and help make it better. But the thing that's probably more interesting is that we have basic support for the Xylex Arctic 7 in Verilog to routing.
35:49
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 writes a whole bunch of values
36:02
into the distributed RAM and read them out. We know that because that's what we've been doing to test whether distributed RAM is working. Again, this is not a production-ready toolchain, but it's getting there. We're very, very close to having an IoT-level microcontroller sock.
36:21
I was really hoping to get this working before CCC, but I got distracted by doing Tomu FPGA stuff. This is, as I said, very close to working. We would love your help in making it work.
36:41
A lot of it is just working through the process and then debugging when it fails. 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.
37:02
Most people should be able to do that. 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 Verilog to routing.
37:23
I know the Next PNR guys are chomping at the bit to add Series 7 support to Next PNR, but have been holding off until we can prove that it works in Verilog to routing. If you're using ECP5, then Next PNR is your best bet,
37:43
because VPR doesn't support ECP5 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,
38:02
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 IOSIS? Problem with having been doing this for two years now is I've forgotten all the things
38:21
that you don't know when you start. 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 to things like Next PNR and to things like Verilog to routing.
38:48
So, as I said at the beginning, this is a big project. It's probably as big, if not bigger, than GCC,
39:00
and it needs your help to become successful. We've 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,
39:25
because almost all our scripts are written in Python. If you know C++, there's definitely a huge amount of stuff you can do. Both Next PNR and VPR are written in C++. A lot of the shared libraries are written in C++.
39:43
We would love your help improving those. Some of the things are as simple as writing tests or improving the input-output libraries. For example, the input and output library for VPR at the moment
40:00
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.
40:22
If you're one of these weird people who know Tcl, we would love your help, because I'm not going to learn Tcl, and pretty much all the EDA tools out there use Tcl. I know John has an interesting relationship with Tcl from using it through Vivado.
40:43
I'm sorry that you had to do that, John. If you know Tcl, please help us. Pretty much all the tooling for doing the fuzzing needs at least some Tcl, and you could probably help relieve the stress of Tcl on John.
41:05
If you know Verilog, as I said, a lot of the simulations and models are written in Verilog. We would love your help doing that. As well as simple designs, like even if you aren't extremely competent with Verilog,
41:22
writing things like the simple thing that writes a bunch of values into the DRAM and then reads it back and checks that the values it got were correct, we need that type of simple tests to verify functionality.
41:42
If you can write Verilog, you could properly 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.
42:02
Here's kind of a blast from the past. If you know XML, almost all the file formats going into Verilog to routing XML, a lot of the formats coming out of Verilog to routing XML, a lot of that is done by printf.
42:23
That would be nice to be replaced. As well as things like having style sheets which confirm that your XML matches a description is useful things you can do, or having tools that transform the XML from one format to another format
42:44
is also really useful. So you can brush off those XLST skills from the late 90s and early 2000s and help us out there. If you know English, which most of you hopefully do,
43:02
otherwise you've probably been very bored, you can help with things like documentation, things like improving the readme, improving how to get started documentation, improving the website. If you know JavaScript, I'm terrible at JavaScript,
43:21
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
43:41
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
44:00
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 gratitude from everybody
44:20
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.
44:42
The lights are quite bright. So you're going to have to wave at me to do questions or something. But first, thank our speaker for the talk.
45:03
Please do stay around for Clifford's talk if you want to understand the really nitty-gritty details about how things like place and route work. And I'm sure Clifford would love help with NextPNR. I'm sure Dave Shah would love help with NextPNR.
45:22
It's a very cool new tool that is less than six months old and is already useful for production stuff. OK. 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.
45:43
OK. Microphone one, please. Yes. 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.
46:03
What we don't do is reverse engineer the tooling directly. We are forbidden by our legal advisors from attaching, for example, GDB to Vivado. What we are allowed to do is basically put a lot of input into Vivado
46:26
and take a lot of bitstreams. 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,
46:44
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 designs that are going in, this correlation approach allows you to resolve that bit uniquely.
47:06
I'm, however, no expert on the bitstream documentation side of things. John McMaster has done a huge amount of work on the Series 7 documentation, and Dave Shah has done a huge amount on the ECP5 work.
47:23
Both of those guys are here at Congress, and both of them will probably be around the OpenFPGA table most of the time. So if you really want to go into the super detailed about how this works, you can go and talk to them.
47:42
As well, if you go to the Project X-Ray read the docs, there's every one of the fuzzes which document various different bits, like the various bits of the logic block, should have a readme which describes what it does,
48:02
why it does that, and those type of things. Some of the places have 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
48:21
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,
48:45
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.
49:04
Thank you. Microphone 2, please. Is there any support for VHDL in the toolchain? Sadly not. There have been a bunch of attempts to do VHDL support in YoSIS.
49:25
None have been successful yet. If you happen to work for a company that has deep pockets, Symbiotic EDA will actually sell you a license to a proprietary library that does VHDL.
49:43
They didn't write that, but it has been integrated into YoSIS. I don't know many people who do VHDL in the open source world. It's kind of a chicken and egg problem. The open source world doesn't support VHDL, so everybody uses Verilog,
50:00
and hence the Verilog 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 Verilog. I do think VHDL is probably in some ways a better language,
50:24
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.
50:44
Is there a question from the internet, signal engine? Yes, go ahead. We have two questions from the internet. The first is, would it be feasible to add support for CPLDs
51:04
Depends what you mean by CPLDs. Pretty much everything these days, people call CPLDs are actually FPGAs, mostly internally. If you mean, what are they called,
51:26
something like PLA logic style devices, there is some experimental support for that type of device in YoSIS. I'm not sure YoSIS is the right tool,
51:42
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 CoolRunner 2, which has some experimental support, was a CPLD and that does have the Andanor type system,
52:05
but I'm not an expert on CPLDs. But definitely like most things these days, that people call CPLDs are pretty much just FPGAs with flash that allow on-chip, that allow them to basically boot instantly.
52:23
They are normally LUT designs and have very similar things to FPGAs. Okay, first microphone 2, please.
52:42
Can you explain the difference between NextPNR 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. So, I actually have slides for this one.
53:01
So, there is a lot of duplication between NextPNR and VPR. 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 an Ice 40, I'd probably recommend using NextPNR,
53:25
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 Verilog to routing. If you want to use ECP5, at the moment, your only choice is NextPNR.
53:45
The reason both exist is that VPR has been around for a long time. It was the academic standard for doing FPGA research,
54:03
but because it 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
54:23
than you really want to model when doing research about, for example, how big your FPGA should be. NextPNR was started because of that. NextPNR was an experiment to show
54:41
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,
55:06
and so it's written in modern C++. It doesn't have its own smart pointers and all these other things that code bases that have been around for that long do. That's kind of why this exists.
55:21
There's still an open question, though, if NextPNR is going to hit some type of barrier that VPR has already solved. VPR has 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 it solved.
55:42
It's also been used as the basis for commercial place and route tools before. If you know Altira, the Quartus toolchain was originally based on VPR. That's also been a little bit of a challenge because you kind of look at VPR.
56:05
It doesn't quite map to the Xylex style of way of doing things as much because it was much more heavily influenced by Altira design devices. That's kind of why these tools exist,
56:20
and we actually think it's healthy to have some type of competition in the open source space. If you look at GCC and LLVM, for example, GCC has gotten a huge amount better since LLVM has become a viable competitor to GCC.
56:42
If you look at the improvement in error messages from GCC 6 to GCC 9, it's been significantly improved and in some ways is probably now better than LLVM. Before that, they just didn't care and they didn't have the competition to drive that forward.
57:02
So that's kind of like a parallel we see here. VPR in this case is probably closer to the GCC analogy and NextPNR is kind of the LLVM one. It's kind of the new hot one that's started from scratch with all the learnings.
57:20
VPR is kind of the older crufty one but has been around forever. It was also really good to have the academics who are doing all this research into new FPGA architectures and designs to be using the same set of tools that we're using for real designs.
57:42
And so we think there is also importance 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 NextPNR.
58:05
So I'm sure Clifford will have an opinion about whether you should be using NextPNR or VPR. Next, I will give you two guesses about what his suggestion is, but NextPNR is only new.
58:20
It's only been around six months-ish. 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 impossible. I would love to have everybody work on one tooling at first,
58:48
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.
59:00
That's already been answered. Perfect. Then we have one at microphone two. Hi. I was wondering, you were talking about legal issues surrounding the reverse engineering of the bitstream. Are there any FPGA vendors that are willing to collaborate on this project? Or are they generally hostile?
59:24
There are levels. 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.
59:44
No vendor has yet to come to the support of the open source tooling. I would hope that any vendor that does would then...
01:00:00
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
01:00:22
FPGAs way more accessible and so the FPGA market is going to grow to a hundred 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
01:00:40
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 FPGAs and are willing to go to
01:01:06
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
01:01:24
do come talk to me. I'm sure there's lots we can discuss about. Okay, then thank Mitro again with a warm round of applause.