 Hallo, ihr hört den Vortrag Simbi Flow, ein GCC Compiler für FPGAs in der Übersetzung von Stefan und Tatzelbrum. Vielen Dank. Zuerst. Ich werde euch eine kleine Einführung in ein anderes Projekt geben. Ihr könnt euch vielleicht erinnern an mein Projekt TUMU, ein Mikrocontroller, der in euren OSB Anschluss reinpasst. Und wir haben uns entschieden, wir wollen FPGA in ein USB Stecker einbauen. Ich habe ein bisschen Hardware hier. Wenn ihr uns helfen wollt, dann kann ich euch eingeben. Aber Achtung, es gibt noch kein Bootloader. Ihr könntet das als eine RISK 5 CPU verwenden. Es läuft FU Python drauf. Es gibt eine total quelloffene Toolchain dafür namens Simbi Flow. Wenn ihr damit spielen wollt, ich bin sehr darin interessiert euch Hardware zukommen zu lassen. Damit möchte ich die Leute motivieren, was zu tun. Also die erste Frage ist, was ist Simbi Flow? Es ist ein relativ neues Projekt. Vielleicht habt ihr davon noch nicht gehört. Das erste, was das Wichtigste ist, Simbi Flow ist eine Community. Es ist nicht nur ich. Ich habe zwar ungefähr 90 Prozent der Arbeit bisher getan, aber das sind Leute, die in irgendeiner Art zu dem Projekt beigetragen haben. Das ist sehr wichtig zu verstehen. Ich stieh hier oben, weil wir weitere Leute brauchen, die Simbi Flow benutzen, damit wir das erreichen können, was wir erreichen möchten. Es gibt jede Menge Arbeit zu tun. Ich habe nicht die Zeit, das alles selber zu machen und ich möchte, dass ihr alle hier im Publikum möglichst viel dazu beitragt. Das ist also das Projekt, was ihr aber wahrscheinlich wissen wollt, ist, wie die Toolchain funktioniert. Ich weiß nicht, wie viele von euch FPGA Experten sind. Ich fang mal am Anfang an. Wenn man Software entwickelt, dann hat man eine ganze Reihe von Tools und man hat ein Compiler. Der Compiler hat normalerweise ein generisches Frontend, das einen bestimmten Quellcode versteht und dann gibt es ein Backend, das daraus Maschinencode für spezifische Prozessoren erzeugt. Zum Beispiel, wenn man C++ für X86 macht, dann nimmt man die C++ Software, lässt sie durch den generischen Teil des Compilers laufen und das Backend macht dann daraus ein Binnere-Programm, das ausgeführt werden kann. In der EDA-Tool-Sicht sieht das ganz ähnlich aus. Es gibt verschiedene Sprachen, VHDL, Verilog und so weiter. Dann gibt es Synthese-Tools, die die Logik aufarbeiten und dann gibt es ein Backend für verschiedene Hardware-Systeme, ASIC, die das Ganze in echter Hardware gießen, FPGA, in die man den Code laden kann. Simbiflow ist im Moment ein Verilog Frontend und erzeugt ein Bitfile für einen FPGA. Das ist die Simbiflow-Toolchain. Wie ihr im Titel schon gesehen habt, beschreiben wir das als eine Art GCC für FPGAs und was bedeutet GCC in diesem Zusammenhang. Das bedeutet nicht, dass wir C oder C++ in Verilog übersetzen und das dann direkt laufen lassen, sondern das ist ein Analog, um die coolen Teile von GCC auf unser Projekt zu übertragen. GCC ist komplett offen und frei. Es ist Cross-Pod-Form, es ist Multi-Plattform, es hat eine sehr gut erweiterbare Architektur und diese Attribute möchten wir auch gerne für Simbiflow haben. Wir möchten gerne eine Open Source-Toolchain haben. Die Toolchain soll verschiedene FPGAs als Targets unterstützen und wir wollen nicht nur FPGAs unterstützen, sondern möglichst auch andere Hardware und wir möchten, dass das möglichst flexibel zusammengestöpselt werden kann. Ein bisschen Geschichte von Simbiflow. Im nächsten Talk hiernach gibt es eine Übersicht über Projekt IceDorm und er hat eine Toolchain vorgestellt, die die Lattice 40 FPGA als Target unterstützt hat und das war ziemlich beeindruckend, denn eine FPGA Toolchain zu erstellen, die Idee war, dass es viel zu hart ist, dass man das als Open Source Projekt machen kann. Aber wie wir alle wissen, es gab Momente, wo Leute geglaubt haben, dass ein C++-Compiler als Open Source selber zu erstellen zu schwierig sein würde und wie sie gesehen haben, haben Leute bewiesen, dass es doch geht. Und dann hat er ein Projekt X-Ray entwickelt und das hatte dann Serie 7 FPGAs als Ziel unterstützt. Das ist die Idee von Simbiflow angefangen hat. Wir hatten plötzlich zwei verschiedene Teile von zwei verschiedenen Herstellern, die wir bei denen wir Leute beitragen lassen wollten. Wir haben mit Clifford geredet. Wir haben entschieden, dass, was wir wirklich brauchen, ein Projekt ist, um alles zusammenzubringen. Da haben wir also bei der letzten 34 C3 angefangen mit Simbiflow angefangen. Das war ein Versuch, um den alten als 40 Architektur und die neue Serie 7 Architektur zu behandeln. Als wir mit Projekt X-Ray gemacht haben, war der Prozess auf gewisse Weise zu dokumentieren und das Bitstream-Format zu dokumentieren. Das hat uns inspiriert. Das Projekt Trellis inspiriert. Das ist ein Projekt, um den Bitstream zum ECP5 zu dokumentieren. Das ist ein ganz großes FPGA. Wir haben ursprünglich ein Verilog to Routing ins Ziel gefasst. Manche Leute im Team wollten ein neues Place and Rout Werkzeug von Grund aufbauen. Die EDA Leute haben dann Next PNR angefangen, als eine Alternative von Verilog zum Routen, um eine andere Option zu machen, um Place and Rout durchzuführen. Das ist, was wir die Simbiflow Tool Suite nennen. Das ermöglicht euch, ein Verilog-File zu nehmen und das in ein Bitstream umzusetzen, den ihr auf ein FPGA laden könnt, um mehr in Details zu gehen. Das erste, was wir brauchen, um diese Toolchain herzustellen, ist die Dokumentation von allen Bitstreams, die in die FPGAs gehen. Leider stellen die Hersteller das nicht zur Verfügung für interessante Gründe. Viele von denen haben keinen Sinn. Das ist, wie das Projekte iStorm X-Ray und Trellis da reinpassen. Um Dokumentationen zu generieren, die jeder benutzen kann, um neue Werkzeuge zu bauen. Wir betrachten das als Teil des Simbiflow Projekts, aber andere können diese Dokumentationen nehmen und auf diese FPGAs zielen, ohne mit uns das zu koordinieren. Das sind die Routing Tools. Wir unterstützen immer noch Verilog to Routing und wir unterstützen jetzt aber auch Next-PNR und das gibt auch JOSIS. Das ist unserer Meinung nach das beste Beispiel eines wirklich genialen Open Source Projekts, das Synthese Dude macht. Wir benutzen das als Frontend, egal welches Backend wir benutzen, ob das Next-PNR oder Verilog to Routing. Als Letztes haben wir diese Architekturdefinitionen, die Architekturdefinitionen hängen eng zusammen mit der Bitstream Dokumentation. Die Bitstream Dokumentation sagt euch, wie man die Bit setzen muss, wie man Features anschaltet. Es sagt nicht notwendigerweise, was diese Dinge dann auch tun oder warum man die verwenden wollte oder wie man die verwenden sollte. Das ist was die Architekturdefinitionen versuchen zu bereitzustellen. Die geben Eingabe zum Place und Rout. Das ist das Teil des System. Das versucht ein pures Design auf das FPGA abzubilden. Die Architekturdefinitionen beschreiben die Features im FPGA und sollten Eingabe sein zu Verilog to Routing und wir versuchen immer noch rauszufinden, wie man das am besten in Next-PNR einbauen. Die geben auch Eingabe zu der Synthese, weil die Synthese wissen muss, welche Teile im FPGA auf welche Dinge im FPGA abgebildet werden muss. Als Letztes versuchen wir diese Architekturdefinitionen, die Funktionalität im Chip zu beschreiben, sodass wir dann Verifikationen und Test und Simulation dessen, was da im FPGA passiert, durchzuführen. Das ermöglicht uns interessante Dinge zu tun, wie formale Equivalenz-Berberprüfungen, dass das Design mit dem Formelner angefangen hat und das was auf dem FPGA ist, dass das tatsächlich übereinstimmt und dass man das beweisen kann, dass diese Toolchain tatsächlich funktioniert. Die andere Idee ist, dass diese Architekturdefinitionen tatsächlich ausführbare Dokumentationen sind, also genau definiert, was da tatsächlich passiert. Und dazu gehören alle komischen Sachen, wie auf dem Eis 40, das DRAM da drauf zum Beispiel, das im Eis 40 kann man das DRAM auf das DRAM nicht zugreifen, in den ersten 40-Klock-Zyklen. Und das ist natürlich wichtig, wenn man hinterher das Design tatsächlich testen will und das also in der Simulation zu testen und nicht erst in die Hardware laden zu müssen, um dann zu probieren, ob es geht. Im Moment ist das Ganze noch sehr vorläufig. Wir versuchen das so einzurichten, dass man nie auf die Hersteller-Website gehen muss, um zu verstehen, was ein bestimmter Chip tatsächlich kann. Lettis stellt sich im Moment sehr widerspenstig auf gegenüber Open Source Tools und sie möchten eigentlich nicht, dass Leute zu viel darüber lernen, wie die Hardware funktioniert. Das sind die Teile. So, was ist jetzt der Status? Wenn wir uns mal den Bitstream angucken und die Bitstream-Dokumentation, das ist die Zusammenfassung, wo wir gerade stehen. Wenn wir uns den Lettis Eis 40 anschauen, das sind die Geräte, die wir dokumentiert haben, sehr große Unterstützung für all das, was in vielen Eis 40-Teilen zur Verfügung steht. Wenn ihr uns helfen wollt, wir möchten gerne weitere Features unterstützen. Wir haben eine ganze Reihe von Bausteinen bereits dokumentiert und das kann man jetzt alles benutzen. Wir haben sehr gute Verilogmodelle für einige der HardRP-Blocks. Da brauchen wir vielleicht noch ein bisschen bessere Modelle. Da gibt es ein paar Besonderheiten, die vielleicht den Modellen noch nicht so gut abgebildet sind und wir brauchen noch ein paar Ersatz für ein paar Libraries. Da wäre es sehr schön, wenn wir Libraries hätten, mit denen wir die proprietaryen Tools verwenden können oder die Open Source Tools. Sind aber nicht notwendig, wenn ihr nur die Open Source Tools verwenden wollt. Der Eis 40 ist relativ klein, aber die Serie ist ziemlich toll für sehr kleine Geräte. Zum Beispiel für unser Tomo-Projekt. Da haben wir nicht so viel Platz und das ist ziemlich klasse für den Eis 40. Für den Lattice ECP5, den wir mit Projekt Trellis bearbeiten, die haben nach uns angefangen und die haben es trotzdem geschafft vor uns fertig zu sein. Da ist so ziemlich alles drin, was es in den verschiedenen Serien gibt. Es geht bis zu 85.000 Zellen hoch und hat Hochgeschwindigkeit Transceivers. Ich glaube, die Dokumentation enthält die High Speed Transceiver und Open Source Tools. Er hat so ziemlich jedes einzelne Bit, von dem wir wissen, bis jetzt dokumentiert. Vielleicht müssen wir noch manche Bit rausbekommen, aber so ziemlich alles ist dokumentiert. Es wäre wirklich gut, wenn man etwas bessere Verilogmodelle hätte. Wir haben base Grundsätzliche Wohnt, aber von DSP gibt es nicht wirklich ein gutes Modell, was da intern im DSP, im digitalen Signalprozessor, basiert. Wir haben auch noch keine Technologie-Resat-Libraries. Wenn ihr verstehen wollt, was da tatsächlich im Bitstream passiert, von was wir der ECP5 Bitstream anguckt, dann guckt euch dieses Video an. Das ist Jodben P O A C ECP5. Das ist oft an der Konferenz vor zwei bis drei Monaten präsentiert worden. Das geht in exzessives Detail, wie dieser Bitstream funktioniert. Es gibt da einige interessante Entscheidungen, wie das funktioniert. Das ist das Projekt, worüber jeder reden will hier. Ich empfehle dringend, falls ihr die Seelings-Serie 7 nicht benutzen wollt, benutzt die ECP5-Serie. Für die meisten Leute ist das ECP5 eine praktisch kable Alternative, die billiger und besser ist für Open-Source-Benutzer-Fälle, Anwendungsfälle. Es ist vollständig dokumentiert. Project X-Ray macht gute Fortschritte. Wir zielen hauptsächlich auf Artics 7 Gerät-Devices, spezifisch der EC7a50T, also auch 15T und 35T, also exzess 7a60T. Kintex 7 haben wir auch etwas erfahren mit. Und vor einer Woche etwa, okay, mit Syncstaff, unser Ziel ist, dass wir alle Serie 7 Teile unterstützen, also Artics 7, Kintex 7, Vertex 7 und Sync. Alles mit dieser Architektur. Wir haben schon eine vollständige Dokumentation für alle Bits in den COBs, in den Logikblöcken, im verteilten Rahmen und so ziemlich alles routing. Wir haben teilweise Dokumentationen für Blockgramm und von IOBs, IOWaffern, weiß nicht. Wir haben immer noch keine Dokumentation für Hardblocks oder den digitalen Signalprozessor. Wir haben bis jetzt noch keine guten Verilogmodelle für alles, das wäre wunderbar, wenn wir da Hilfe hätten. Wir haben auch noch keine Ersatz-Tech-Libräries für die Kompatibilität mit den Sylings Designs und Tools. Meisten Leute hier haben existierende Sylings Designs, die sie portieren wollen, die sie auf unsere Toolchains übertragen möchten. Da sind diese Tech Replacement Libraries wirklich important, wirklich wichtig. Das sind primitive Objekte, die Sylings behauptet, dass sie existieren, die existieren aber nicht, aber das ist nur eine Konfiguration von mehr, von primitiveren Objekten. Diese Ersatz-Libräries, die Tech Replacement-Libräries sind auch wichtig. Wenn man in so ein Serie 7 Artics, 7,50 Tee reinguckt, dann sieht man jetzt die ganzen Teils, die ganzen Ziegel. Das ist, was wir alles verstehen, also das ist schon eine ganze Menge Grün. Es ist immer noch einiges rot, das verstehen wir noch nicht, aber wir kommen zum Ziel. Die IO-Profo sollten orange sein und das Blockraum sollte orange sein. Es wird immer grüner. Und damit kann man schon eine ganze Menge anstellen. Das zum Beispiel sind die COBs, die logischsten Blöcke. Wir haben also null unbekannte Bits für diese Logikblöcke. Slice M ist das verteilte Memory. Da weiß man auch schon alle Bits davon. John McMaster, den du hier auf der Seite sehen kannst, ist hier auf der 35C3 und er ist die meiste Zeit auf Offen-FBGA-Assembly und er hilft euch gerne da in die Bitstream-Dokumentation reinzukommen für den CS7. Wir können das nicht alles selber machen. John möchte auf jeden Fall auch Hilfe haben und wenn jemand von euch zum Beispiel den PCI Express Hardware-Block verwenden will, dann helfen wir euch das zu dokumentieren und wir haben einen ziemlich guten Prozess um das zu tun. Also zusammengefasst. Ihr seht, dass die drei Projekte uns eine Menge bereits geben. Wir haben diese Art von GCC für FPGA-As, für Geräte für Hardware von zwei verschiedenen Herstellern. Wir haben Bitstream- Dokumentation für sehr viele verschiedene Teile und wir möchten das erweitern für im Prinzip jedes FPGA, dass es gibt. Da machen wir was relativ Interessantes. Das ist, wenn ihr euch an die Geschichte erinnert, das ist das erste kommerzielle FPGA-Logic-Block. Das ist ein Chip, der XC2118 heißt. Hat 50 bis 80 Dollar gekostet. Es gibt keine Dokumentation. Wir haben Bitstream-Dokumentation für dieses sehr alte Teil und warum zum Teufel dokumentiert ihr sowas, was es in 20 Jahren nicht benutzt wurde, was man wahrscheinlich nicht mehr kaufen kann. Das Schöne ist, dass es ein so einfaches Teil, dass wir daran sehr gut demonstrieren können, wie man Unterstützung für genau dieses Modell tatsächlich hinzufügen kann. Und deswegen ist es für uns eins der Targets, dass wir unterstützen und wir möchten daraus ein Tutorial machen, mit dessen Hilfe man verstehen kann, wie man Simiflow entsprechend ergänzen kann um neue Teile. Und das hilft hoffentlich, dass wir dann tatsächlich auf alle mögliche Hardware als Zielsystem kommen können. Das ist das, was wir im Moment an Bitstream verstehen. Ihr seht, das Projekt 2064 hat eine ganze Reihe Sachen nicht. Deswegen ist da einiges nicht grün. Wir brauchen unbedingt eure Hilfe. Wir können das gar nicht alles selber machen. Und wenn ihr also ein FPGA benutzt, der noch nicht vollständig dokumentiert ist, dann würden wir uns sehr freuen, wenn ihr uns dabei unterstützt. Und wir haben ein Prozess entwickelt, wie man diese Dokumentationen durchführen kann und wie ihr unsere Erfolge für eure Hardware nachvollziehen könnt. Wir freuen uns auch sehr, wenn Leute sich mit den Ceilings Spartan 6 und 3 beschäftigen. Die werden sehr häufig verbaut und dementsprechend wäre es toll, wenn es die Unterstützung dafür geben würde. Man wird das wahrscheinlich nicht mehr für ein neues Design verwenden, aber da die so verbreitet sind, wäre das sehr schön. Es gibt auch eine Menge Parts von Altera. Es gibt Leute, die angefangen haben, Altera Bauteile zu dokumentieren. Robert hat angefangen, damit angefangen, das zu dokumentieren. Der ist vielleicht auch irgendwo hier und wenn ihr euch also für Altera interessiert, dann solltet ihr Kontakt mit ihm aufnehmen. Aber den Bitstream zu dokumentieren ist ungefähr nur ein Drittel des ganzen Kampfes. Wir brauchen Tools, die den Bitstream tatsächlich erzeugen können. Der Bitstream muss natürlich dokumentiert sein, bevor man mit der Erzeugung anfangen kann, aber es reicht eben auch nicht aus, ihn nur zu dokumentieren. Wir brauchen tatsächlich Tools, um ihn erzeugen zu können. So, wie sieht es da aus? Wie weit sind wir da? Als Teil von Mapping und Place and Route haben wir zwei Tools und beide verwenden Justus als Frontend. Also man braucht auf jeden Fall Unterstützung in Justus für ein neues Bauteil. Beide Place and Route Tools sind Timing Driven, also abhängig von der Signalpropagation im Teil. Das ist auch ein Grund, warum Next PNA gestartet wurde, um genau diese Timing Driven Geschichte zu machen. Das ist der Status, wo wir gerade stehen für die verschiedenen Komponenten. Next PNA ist wahrscheinlich das beste Tool, um Lettas I-40 Teile zu erzeugen. Der Status ist, man sollte das für I-40 einfach benutzen. Es sollte alles tun, was Rachnik kann. Es sollte ziemlich genau das selbe Ergebnis erzeugen und die Leute beim Open FPGA-Tool-Tisch haben mir gesagt, das Beste benutzt es einfach und reported bugs, wenn ihr auf Probleme stoßt. Wenn ihr Open Source Tutorials habt, die Arachne verwenden, dann wäre es toll, wenn ihr die aktualisieren könntet und auf Next PNA umstellen könntet. Wir haben hier Tutorial Sessions für verschiedene E-Tools. Die haben ein Board gemacht und hier gibt es noch ein paar Plätze bei den Tutorials. Wenn ihr nicht fragt, dann machen die vielleicht sogar noch ein paar mehr Sessions. Lauft rüber und sprecht sie an. Wenn ihr damit anfangen wollt, dieses Development Board ist eines der besten, mit dem man anfangen kann. Wir haben auch ein Tomo, das auch auf I-40 basiert. Ich habe ein paar hier. Der Bootloader funktioniert zwar noch nicht, aber das ist auch eine gute Möglichkeit, um direkt loszulegen. Wenn ihr nicht fragt, wenn ihr verspricht zu helfen, dann gebe ich euch gerne ein Board. Next PNA unterstützt auch Lattice ECP-5. Das ist die tolle Arbeit von Dave Scha. Es unterstützt, was ich IoT Mikrocontroller nenne und es läuft bis hin zu Linux Mikroprozessor Teilen. David hat ein Beispiel, wo auf dem ECP-5 ein Linux auf dem RISC Vive Core läuft. Es ist noch ein bisschen früh, aber es funktioniert und das Beste, was ihr machen könnt, ist die Tools zu verwenden und Bugs zu melden. Wenn ihr ein Projekt habt mit dem ECP-5 verabt, dann wäre es sehr hilfreich, wenn ihr euer Design mit unseren Tools ausprobiert, steckt das noch nicht in den kritischen Projektfahrt, aber man kann damit auf jeden Fall experimentieren. Das ist, was Dex in PNA im Moment unterstützt und im folgenden Talk gibt es von Cliff ganz viele Details, wie man Next PNA benutzt und vielleicht sogar, wie man Next PNA um weitere Teile erweitern kann. Dann haben wir auch Unterstützung für den iS 40 in Verilog und ihr seht hier ein Screenshot vom Verilog Routing GUI und das ist der Unterschied, wenn Akademiker ein GUI Design vs. wenn normale Leute ein GUI Design. In Verilog Routing für das iS 40 haben wir Logik und Blockarm. Es hat ein sehr einfaches IOB-Modell, keine DSP-Blocke. Man kann Blinky bauen oder ein IoT Mikrocontroller mit dem Verilog Routing, jetzt aber noch nicht produktionsreif. Es gibt ein paar größere Probleme, die wir auf jeden Fall noch fixen müssen. Man braucht im Moment mehr als 4 GB RAM, um selbst ein relativ kleines Design zu machen. Das ist nicht so sehr ein Problem von Verilog to Routing, sondern das hat mehr damit zu tun, wie wir im Moment die Sachen modellieren und beschreiben. Und da würden wir uns sehr über eure Hilfe freuen, das weiter zu verbessern. Das meiste sind Python-Skripte, die den Routing-Grafen erzeugen und vielleicht wäre es hilfreich, das in C zu implementieren, dann wäre das Ganze sehr viel schneller und würde vielleicht auch weniger RAM verbrauchen. Die Grafentraversion ist im Moment nicht besonders effizient. Leute, die da bessere Algorithmen kennen, die das besser machen oder vielleicht sogar korrekt machen, das ist nicht so ganz meine Stärke, es funktioniert, aber bitte kommt und helft es besser zu machen. Das Interessantere vielleicht ist, dass wir grundlichen Support für Artics 7, für Verwerkeloktoraten nach Routing haben, mit dem gibt es Logik und D-Ram oder verteiltes RAM. Damit kann man Blinky machen und ein Sailor machen. Man kann damit auch einen RAM-Tester machen. Der Muster ins verteilte RAM reinschreibt und wieder ausliest. Das ist, was wir machen, um zu überprüfen, ob das verteilte RAM funktioniert. Das ist aber noch nicht fertig für Produktionen, aber wir kommen dahin. Wir sind sehr nah dran an einem Internet of Things Mikrocontroller System und Chip. Ich hatte sehr gehofft, das Forms Kongress zum Laufen zu bringen, aber ich bin abgelenkt worden mit FPGA Staff. Das ist ganz knapp Form funktionieren und eure Hilfe wäre sehr erwünscht. Eine ganze Menge ist einfach, um durch den Prozess durchzugehen und debaggen, wo es schief geht. Manches ist etwas kompliziert oder ein bisschen fitselig. Eine Menge ist einfach, durch den Prozess durchzugehen und Fehler zu finden und die meisten Leute sollten in der Lage sein, das zu tun. Das gibt euch jetzt eine Zusammenfassung, wo wir sind. Wie ihr sehen könnt, ist 40 mit allem unterstützt. Projekt X-Rays nur von Verilog zu Routing unterstützt. Ich kenne die NextPNR Leute, aber die versuchen CS7, versuchen zu NextPNR zu einzubauen, aber wir müssen noch beweisen, dass man das konvertieren kann. Falls er ECP5 benutzt, dann ist NextPNR das beste, was es gibt. Andere unterstützt das nicht und 64 funktioniert noch gar nicht. Es wäre sehr schön, wenn andere Leute da an dem 2064 arbeiten würden. Das ist ein gutes Anfängerprojekt und es würde uns wirklich helfen, welche Art von Dokumentationen wir brauchen, wir schreiben müssen, um zum Beispiel zu beschreiben, wie man eine neue Technologie-Mapping zu Josef dazu machen kann. Wir brauchen wirklich Hilfe von Anfängern, technische Hilfe, um die Dokumentation zu schreiben und wie man Tutorials schreibt, wie man 2064 in NextPNR einbaut und Verilog zu Routing einbaut. Wie ich am Anfang gesagt habe, ist das ein großes Projekt, ist so groß und vielleicht noch größer als GnuCC Compiler und um erfolgreich zu sein braucht das eure Hilfe. Wir bringen die ganze Arbeit rein und wir kommen da langsam hin. Wenn das schneller gehen soll, dann brauchen wir eure Hilfe. Falls ihr Python könnt, bin ich 100 Prozent sicher, dass ich was für euch finde, was ihr tun könnt, weil fast alles kript in Python geschrieben worden sind. Falls ihr C++ könnt, dann könnt ihr definitiv helfen, weil WPR und NextPNR und manche Libraries sind in C++ geschrieben. Also wir würden eure Hilfe wirklich mögen. Das ist manchmal so einfach wie einfach Testschreiben oder die Input-Output-Libraries verbessern, zum Beispiel Input-Output-Libraries für WPR. Liest das ganze File ein und bearbeitet es dann. Man braucht dann nichts über Hardware zu wissen, um dieses Problem zu lösen. Das ist einfach ein eventgetriebener Parson, der da geht und benötigt ist. Selbst falls ihr nichts über Hardware wisst, weil ihr C++ Programmierer seid, dann könnt ihr uns wirklich helfen. Falls ihr eine von den Irren seid, die Tickle kennen, dann würden wir wirklich eure Hilfe mögen, weil du kannst Tickle, ich lerne kein Tickle, weil alle EDA-Tools bis jetzt Tickle benutzen. John hat eine interessante Beziehung mit Tickle. Okay, John hat da etwas Schwierigkeiten gehabt, weil sie TTR kennt, dann hilft uns, weil alle Werkzeuge für das fitzliche brauchen, Tickle. Und da könnt ihr unseren Stress abbauen von den Leuten, die das machen wissen. Falls ihr Verilog könnt, eine Menge Simulationen und Modellen sind in Verilog geschrieben worden, da würden wir eure Hilfe lieben. Und die einfache Designs, selbst falls ihr nicht besonders kompetent mit Verilog sind, falls es darum geht, falls ihr was schreibt, was ein paar Werte ins DRAM reinschreibt und sie zurückliest und dann verifiziert, wie diese einfachen Tests brauchen, um zu verifizieren, dass das alles funktioniert. Und falls ihr Verilog schreiben könnt, dann könnt ihr das wahrscheinlich ganz einfach schreiben und wir brauchen eine ganze Menge verschiedene Sachen wie das, die nicht besonders schwierig sind, aber die einfach gemacht werden müssen. Und da könnt ihr wirklich helfen. Hier ist ein aus der Vergangenheit, kennt der XML, weil fast alle Formaten, die wir haben, sind, die in Routing reingehen, sind XML. Ich weiß nicht, ob die Verilog zur Routing Formate sind, XML sind, manche sind Kundev. Das wäre nett, wenn man das alles ersetzen könnte, wie Teile, wie Stylesheets, die feststellen, die sicherstellen, dass das XML eine Beschreibung erfüllt und Werkzeuge, die XML von einem Format in ein anderes übersetzen werden, auch sehr hilfreich. Ihr könnt diese XLS-T von den späten 90ern früher 2000ern wieder auffrischen und uns da helfen. Falls ihr Englisch könnt, was hoffentlich alle können, sonst seid ihr sehr gelangweilt oder hört ihr auf die Übersetzung, dann könnt ihr Übersetzungen schreiben, Rhythmes verbessern, Webseite verbessern. Falls ihr Javascript kennt, ich bin furchtbar mit Javascript, kommt und helft uns, die Webseite zu verbessern. Falls ihr Sysadmin seid und Sachen wie Docker kennt, dann wäre es, wir würden gerne ein viel einfacher Setup einfacher zu haben. Also Docker kann das passieren machen, leichter machen, damit Docker könnte uns auch definitiv helfen. Falls ihr Zeit habt, dann kann ich etwas finden für euch, dass ihr hilfreich sein könnt. Ich bin dafür bekannt, Leuten Hardware zu geben, dafür, dass ihr beim Projekt helft. Ich habe definitiv viel übrige Hardware, das bei euch auftauchen könnte, falls ihr zu Sachen wie das dem beitragen könnt. Und ihr bekommt den Dank von allen, die jemals durch diese, die durch die proprietären Tools sich durchquellen mussten. Überraschenderweise bin ich sehr, sehr viel schneller durchgekommen durch diesen Tag als erwartet. Das sind bei 443 Minuten. Jetzt gehen wir über zu den Fragen. Ich kann noch niemanden sehen, weil die Lichter so hell sind. Also ihr müsst mir winken. Okay, reiht euch bei den Mikrofonen auf. Erst mal danke dem Vortragenden für den Vortrag. Bleibt noch für Cliffords Talk, weil sie die wirklichen Details verstehen wollt, wie das Place and Route funktionieren. Clifford würde wirklich gerne Hilfe mit NextBanner haben und Dave würde auch gerne Hilfe mit NextBanner haben. Das ist ein schönes neues Tool, das weniger als sechs Monate alt ist und das ist schon Produktionsreif. Okay, für die Fragen geht an die Nähe, nein, die Mikrofone dran. Geht ruhig raus, falls ihr wirklich müsst. Mikrofon 1. Wie habt ihr die Bitstream-Formate reverse engineered? Was wir machen, ist die Bitstream-Formate dokumentieren, damit die Werkzeuge kompatibel damit sind. Was wir nicht machen, ist die Werkzeuge direkt reverse engineered. Unsere Alte haben uns verboten, GDB an Bravado anzuhängen. Was wir dürfen, ist eine ganze Menge Eingabe, Eingabe in Bravado zu tun und die Bitstream rauszunehmen und dann eine Kreuzkorelation machen zwischen dem, was wir reintun und dem, was rauskommt. Und was wonach wir schauen ist, jedes Mal, wenn dieses Feature an war, war dieses Bit gesetzt und jedes Mal, wenn das Feature aus war, war dieses Bit nicht gesetzt. Und weil wir eine Menge Designs reintun und weil wir viel zufällig machen, ist der Korrelationsansatz, erlaubt uns dieser Korrelationsansatz, dieses Bit, eindeutig zu edifizieren. Ich bin kein Experte über die Bitstream-Dokumentation. John, aber John Master hat eine Menge Arbeit, Serie 7 Dokumentation gemacht und Dave Schau hat eine riesen Dokumentation an DCP5 gemacht und beide sind hier beim Kongress und beide werden beim Open FPGA Tisch die meiste Zeit sein. Also falls ihr wirklich in die tiefen Details gehen wollt, wie das funktioniert, dann müsst ihr mit denen reden, könnt ihr mit denen reden. Und wenn ihr durch das Projekt X-Ray Dokumentation geht, jedes, jeder Flitzel, jeder Flitz von den Logikblocks dokumentieren sollte ein Rhythmie haben, was es tun, warum es das tut und diese Sachen, diese ganzen Dinge. Manche Sachen sind noch nicht dokumentiert, also das sind bugs, ja bitte dokumentiert das und wir machen das definitiv so, dass der Prozess beschrieben ist in verschiedenen Stellen, um anderen zu ermöglichen, das auf anderen FPGAs zu machen, also bitte kommt und fragt Fragen, bitte sagt uns, wo ihr Sachen nicht versteht, wie es fast funktioniert oder warum das tun soll, weil diese Sachen zu reparieren ist wirklich etwas, ist was wir wirklich brauchen, weil nur wenn John, wenn nur John und Dave das machen, dann skaliert das nicht hoch, wir brauchen das, wir müssen das machen, dass jeder Student oder jeder Stud-, jeder Vorausen kann, dass sein Lieblings-FPGA finden kann und die Dokumentation machen kann. Mikrofon 2, gibt es schon Unterstützung für VHDL? Bis jetzt noch nicht, es gab ein paar Versuche, VHDL Unterstützung in Joses einzubringen, bis jetzt war noch keine erfolgreich, falls er für eine Firma arbeitet, die viel Geld hat, dann verkauft er jemand die Lizenz für eine proprietäre Bücherei für VHDL, das ist in Joses integriert. Ich kenne wenig Leute, die VHDL in der Open Source Welt benutzen, das ist so ein Hohen und Ei Problem, in der Open Source Welt benutzen viele Verilog und deswegen wird der Support besser und für VHDL fällt da ein bisschen unterm Teppich, es wäre ganz toll, wenn Leute daran arbeiten wollten. Ich würde persönlich sagen, ihr seid besser dran mit Verilog, ich glaube, wie jetzt die L's in mancher Art die bessere Sprache, aber es ist nicht so viel besser, dass ich vorschlagen wollte, dass ihr euer Leben für Joses Support für VHDL zu verwenden. Ich kann das nicht empfehlen. Gibt es eine Frage aus dem Internet? Ja. Es gibt zwei Fragen aus dem Internet zuerst. Gibt es, wie es möglich, Unterstützung für CPLDs hinzuzufügen? Hängt davon ab, was er unter CPLDs versteht. So ziemlich alles, was diese Tage CPLD genannt wird, sind eigentlich FPGAs intern. Falls ihr meint, wie heißt das, eine PLA, Programmative Logic Arrays, diese Art von Devices. Es gibt da experimentelle Unterstützung für diese Art von Dingen in Joses. Ich weiß nicht, ob Joses das richtige Tool ist, aber Clifford kann euch da mehr erzählen, ob das eine gute Idee ist oder nicht. Ich weiß ganz bestimmt der CoolRunner 2 Experimental Support hat. Das ist ein CPLD und das hat diese Endgate-Orgate-Systeme auf Architektur. Die in CPLDs üblich ist, aber die meisten Dinge heutzutage, die CPLDs genannt werden, sind eigentlich FPGAs mit Flash. Die ermöglichen, dass man das Gerät, also vom Chip Flash booten kann und hat letztes intern und das ist sehr ähnlich wie FPGAs. Okay, zuerst mein Mikrofon 2. Kannst du den Unterschied zwischen Next-NP und VeryLock-to-Routing erklären? Es ist nicht ganz klar, was da unterstützt wird. Ah, das habe ich erwartet, da habe ich dir davon, Slides dafür. Es gibt eine Menge Duplikations zwischen Next-PNR und VeryLock-to-Routing, die erste Frage ist, wenn ihr wissen wollt, welches Benutz man das erste ist, welches Device möchte ich da benutzen. Falls ihr IS-40 benutzt, dann benutzt Next-PNR, weil das alles stabiler ist und produktionsreich ist. Falls ihr Serie 7 benutzen wollt, geht nur VeryLock-to-Routing. Wenn der ECW 5 benutzt ist, dann ist die einzige Wahl Next-PNR. Der Grund, warum beide existieren, ist, dass WPA für eine lange Zeit schon da war. Das war der akademische Standard für um FPGA Forschung zu tun. Aber weil das hauptsächlich ein Forschungswerkzeug war, war es nicht wirklich geeignet, um echte FPGAs zu benutzen. Die, die ein bisschen Fläche haben, die weniger regulär ist als das, was das Modell für Anforschung ist, die man benutzt in Forschung, um festzustellen, wie groß ein FPGA ist. Next-PNR ist deswegen gestartet worden. Das war ein Experiment, um zu zeigen, dass man vielleicht so ein Rout-Tool machen kann, vom Anfang an, dass in kurzer Zeit benutzt ist. Das gab es ein EDA-Team, das gezeigt hat, dass es wirklich benutzt ist. Es hat wirklich ein gute GUI, gebrafische Benutzeroberfläche. Es leidet nicht darunter, dass es mehr als 50, 15 Jahre alt ist. Es ist mit modernem C++ geschrieben worden. Das hat also Smart-Pointe und das Zeug. Also, das ist warum das existiert. Es ist immer noch eine offene Frage, ob Next-PNR auf ein Hindernis stößt, dass WPA schon überwunden hat. WPA war, es gibt seit Langem und hat eine Menge Probleme schon gelöst. Es hat so viele Probleme schon gelöst, dass es die halbe Hälfte Probleme vergessen hat, die es gesolft hat. Und das hat bis benutzt worden für kommerzielle Plays und Rout-Tools genutzt worden, falls der Alt-Toolchain auf WPA basiert. Das ist etwas schwierig, weil wenn man auf WPA kurscht, dann wird das nicht richtig abbildbar auf Xilinx, weil es sehr mit Alt-Thera-Devices zu tun hat. Und das ist weswegen diese Tools beide existieren. Es ist aber gesund, um einen Wettbewerb zu haben im Open-Source-Raum. Ein Wettbewerb zu haben, wenn man PCC und AVM anschaut und PCC ist sehr viel besser geworden seit LLVM eine Alternative geworden ist. Wenn man den Fortschrind von PCC6 nach PCC9 anschaut, ist es sehr viel besser geworden. Es ist besser als LLVM. Vorher haben sich die GCC-Leute nicht darum gekümmert und es gab keinen Wettbewerb, um das voranzutreiben. Das ist so eine Parallele zwischen WPA. WPA ist näher am GCC-Standard dran und XPNWS ist näher an LLVM dran. Es ist das Neue, das von Anfang an angefangen worden ist. WPA ist als Alter und hat schon ein paar Macken. Es ist wirklich gut, dass man Forscher hat in der Uni, die FPGA-Architekturen und Würfe forschen, dass sie die gleichen Tools benutzen, die man verwirkliche Designs benutzt. Dieser Feedback ist auch gut, um Akademiker dazu zu bringen, wirkliche Devices zu zielen und anstatt diese Spielmodelle zu benutzen, die sie in den letzten 20 Jahren benutzt haben. Das gibt einfach bessere Forschung, die man dann in XPNWS benutzen kann. Clifford hat das sichere Meinung dazu, ob man XPNWS oder WPA benutzen soll. Ich lasse euch zweimal raten, was seine Wahl ist. XPNWS gibt es erst seit sechs Monaten. Hoffentlich übersteht das den Test der Zeit. Warum das passiert ist. Es ist in der Open Source, Katzen zu treiben, unmöglich. Es wäre schön, wenn alle an einem Werkzeug arbeiten würden, aber ich kriege nicht immer, was ich mir wünsche. Es gibt noch eine Frage aus dem Internet, die ist schon beantwortet worden. Dann noch eine Frage von Mikronummer 2. Du hast darüber gesprochen, dass es rechtliche Fragen gibt rund um das Reverse Engineering der Geschichten. Gibt es Hersteller, die mit euch zusammenarbeiten wollen oder sind sie da eher feindlich gesend? Es gibt verschiedene Levels, verschiedene Ebenen. Es gibt Hersteller, die wirklich feindselig sind. Es gibt Hersteller, die neutral sind und dann gibt es Hersteller, die anfangen, sich zu denken, dass das eigentlich funktionieren könnte. Kein Hersteller hat bis jetzt, es ist bis jetzt so weit gekommen, dass er uns und Open Source Menschen unterstützt, dass er Open Source Werkzeuge unterstützt. Ich würde hoffen, dass jeder Hersteller, der das macht, dann von euch unterstützt wird. Weil was die sich kümmern ist, wie viele FPGA sie verkaufen, die kümmern sich nicht um die Werkzeuge. Das muss schon die profitabel sein, dass sie das machen. Wir glauben, dass das FPGA viel zugänglicher macht und dass der FPGA-Markt wächst um zwei bis drei Größen und dann wächst, also 100 bis 1000 mal größer wird. Und selbst falls sie den Marktanteil verblussen, also kriegen sie einen größeren Marktanteil von einem größeren Kuchen, aber die sind immer noch skeptisch. Die müssen ihren Aktionärenbericht erstatten und die zu überzeugen ist schwierig. Und falls ihr ein Projekt habt, das eine Million FPGAs braucht und zu einem Hersteller geht, ich möchte nur Open Source Tools benutzen, unterstützen eure Teile das, das würde wirklich helfen. Dann redet mit mir, falls ihr in einer Firma arbeitet, die eine Million FPGAs kaufen wollten, dann kommt zu mir. Es gibt sich eine Menge, wie wir über das reden könnten. Vielen Dank. Noch mal Applaus. Ihr habt gehört den Vortrag