 Willkommen zu dem Talk über Next PNR, ein Open Source FPGA Plates and Route Tool von Clifford Stoll, Clifford Wolf. Die Übersetzung ist von Flo und ... ... Ploy. Wer immer schon zu dem Talk vorher gehört hat, weiß schon einiges darüber. Next PNR ist Teil von dem Simifloh Projekt und er zeigt dir jetzt ... ... er wird euch jetzt einiges über dieses Open Source FPGA Tooltrain und das Plates and Route Tool erzählen. Ich werde über Next PNR reden, was unser neues FPGA Plates and Route Tool ist. Zum Anfang möchte ich über das Open Source Plates and Route Ecosystem etwas erzählen. Es gibt einige Plates and Route Tools, aber hier geht es um FPGA. So hier gibt es WPA, was es ungefähr 20 Jahre alt ist. Das ist Timing Driven, also zeitgetriebene Algorithmen, das ist ja portierbar. Man kann das leicht von einer FPGA Architektur auf eine andere portieren. Aber der Fokus ist mehr aus Architekturexploration. Man kann Variationen leicht ausprobieren über die Interconnect-Architektur oder sowas. Aber es zählt nicht darauf, Bitstreams und Placements oder Platzierungen für reale FPGAs zu generieren. Denn die realen FPGAs sind nicht so regulär wie die ausgedachten FPGAs, die VPR auf die VPR im Wesentlichen zielt. VPR macht nicht nur Architekturexplorationen von hypothetischen Devices oder Geräten oder Experimente. Wir brauchen etwas, das reale FPGAs zielt. Unser erster Versuch war Erachne, das war nicht zeitgetrieben. Es ging nur darum, erst mal überhaupt ein gültiges Placement und eine gültiges Brouting zu generieren. Aber man konnte nur danach testen, ob es der bestimmte Zeitbeschränkungen erfüllt. Aber das war im Prinzip hat nur als Forti unterstützt. Wir haben darüber nachgedacht, Erachne zu erweitern und es auf zeitgetriebene Algorithmen. Es war nicht so darauf, Architekturen zu portieren, aber es war nicht wirklich darauf ausgelegt, dafür als Forti portiert zu werden. Deshalb haben wir angefangen, ein neues Placement Route Tool zu entwickeln, das wir benutzen können, um neue reale Geräte, die man tatsächlich kaufen kann, zu benutzen. Deshalb haben wir jetzt NextPNR, das ist brandneu. Wir haben dieses Jahr damit angefangen, es ist zeitgetrieben, es ist sehr portierbar. Es ist ein Team-Erford. Meine Projekte sind oft ich in einem kleinen Raum eingeschlossen für ein paar Monate. Dann komme ich raus und sage, guck, was ich getan habe. Bei NextPNR gibt es eine Gruppe von Leuten, die daran arbeiten. Das ist eine wirklich tolle Erfahrung auch für mich. Eine der Sachen, die wir kriegen, nicht nur ich, der ich damit rumspielt, sondern ein Team, ist eine der Effekte, dass wir Features kriegen, die ich bei denen ich nicht gut bin. Eine Sache ist zum Beispiel, wir haben eine GUI, in der man tatsächlich den Scheitplan des Gerätes sehen kann. Aber es arbeitet auch sehr gut mit Makefiles. Die meisten Projekte benutzen die GUI-Ni, die haben einfach ein Makefile oder ein Shellscript. Das ist Aufruft. Es gibt eine API für neue Architekturen. Das ist ein anderer Ansatz, als die meisten Tolls haben. Der normale Ansatz ist, dass es eine Datenstruktur gibt. Das neue Gerät, eine Datenstruktur einfach implementieren. Das haben wir nicht. Stattdessen muss jedes Architektur Backend die gleiche API implementieren. Und diese API wird dann benutzt von dem restlichen Tolls, um diese Architekturdetails darauf zu zugreifen. Ich glaube, ein Grund, dass eine In-Memory, so eine Speicherdarstellung, eine Datenstruktur ist gut, um alle möglichen Target-Geräte zu repräsentieren. Deshalb haben wir diesen Anwalt gewählt. Im Moment haben wir so Unterstützung für IS-4D und für ECP-5. Das sind die, die wir euch empfehlen, dass wir sie benutzen. Es gibt ein generisches Target dazu. Wir wissen nicht genau, ob es funktioniert. Es kann sein, dass es ein bisschen mitgerottet ist. Aber die Idee ist, dass man das benutzen kann, um eine Architektur-Datenbank zur Laufzeit bei einem Palsonskript zu generieren. Damit decken wir auch ein bisschen die Architekturexperimentier-Axpekte ab. Wir haben auch ein paar Experimentellebindungen für Talk und für Sailings Serie 7 Geräten. Aber diese anderen Dinge sind, wo wir nicht empfehlen, dass Leute sie benutzen. Wir empfehlen, ihr könnt euch gerne angucken, wenn ihr daran interessiert seid. Oder wenn ihr daran Zeit darauf verwenden wollt, sie zu verbessern. Aber als Benutzer solltet ihr jetzt nur für IS-4D und ECP-5 das benutzen. Die Folie ist ein bisschen älter. All diese zukünftigen Pläne sind im Prinzip schon implementiert. Wir haben jetzt die Grundrissplanung. Wir haben Designs mit mehreren Uhren und komplexe Designs. Das hier sollte jetzt eigentlich ein Video sein. Und ich habe jetzt die letzte Stunde verbracht. Treestreamer zu S-Trace und Wasserhütten, warum es nicht funktioniert. Aber jetzt um euch zu demonstrieren, dass wir tatsächlich nicht triviale Designs mit diesen Tools implementieren können. Das hier ist ein Design auf dem IS-4D. Da unterstützen wir alle diese Geräte. Und wir haben einen vollständigen Verilog bis zu Bitstream Flow. Wir benutzen Josys für die Synthesis. Josys wird ein JSON-Datei generieren. Diese JSON-Datei wird dann von Next.pnr eingelesen. Und Next.pnr wird so ein .ac file generieren, aus dem Netbitstream generiert wird. Das Board, das ihr hier in diesem nicht gelaufenden Video seht, ist ein Icebreaker FPGA Board. Da gibt es auch eine Crowdsupply Support Kampagne im Moment, um dieses zu finanzieren. Es ist ein Board, um Leuten FPGA Design zu lernen. Wir haben all die Probleme, die wir hatten mit den existierenden Development Boards. Und dann hatten wir all die Dinge, die uns nicht gefallen haben. Und dann haben wir eine Liste gemacht. Was hätten wir gerne von einem Development Board, das wir haben möchten? All die Features hat die mehr brauchen, wenn man nicht gerade ein kommerzielles Gerät brauchen will, sondern einfach, wenn man FPGA Design Leuten beibringen möchte. Und dafür haben wir dieses Board entwickelt. Und IS-4D ist dafür ein schönes Board, das IS-4D ein relativ kleiner FPGA ist. Und wenn man irgendetwas beibringen will, man hat einen riesen FPGA, dann können Leute extrem uneffiziente Designs schreiben und sie merken nie, dass es schlecht ist, weil der FPGA so groß ist, dass es trotzdem funktioniert. Mit dem IS-4D kann man tatsächlich ein Ziel setzen, das ein bisschen herausfordernd ist für die Größe des Gerätes und müssen die Leute tatsächlich lernen, wie man effiziente Designs erzeugt, um es umzusetzen. Ja, ok. Hier nochmal ein Video, das nicht abspielt. Da sieht man, dass es auf ECP5 läuft. Wir haben da Unterstützung für alle diese Geräte hier. Wir haben einen kompletten Verilog zur Bitstreamflow. Man kann Josys brauchen, das erzeugt GenJSys-File, dann liest das Next PNR aus und macht Placent Rout. Mit Project Trellis Infrastruktur macht man Bidgen und Geräteprogrammierung. Im Video, das hier nicht läuft, sieht man, dass Linux auf diesem FPGA draufläuft. Einfach, um zu zeigen, dass Placent Rout für ziemlich nicht triviale Designs funktioniert. Also ein Linux-capable SOC. Wenn das Video laufen wird, dann sieht man, dass man hier mit Shell-Commands LEDs an- und ausmachen könnte. Also, dieses Video fängt halt mit einem schwarzen Frame an. Also, hier würde man sehen ein Xilinx-Devboard. Das blinkt einfach, um euch zu überzeugen, dass wir auch Support haben für diese Xilinx-Geräte. Er ist ein Grund, dafür, dass hier bloß ein einfaches Blinkbeispiel läuft. Weil im Moment haben wir noch ein paar Timing-Probleme, die wir lösen müssen, auf diesen größeren FPGAs. Wir arbeiten daran. Ich bin zuversichtlich, dass wir in dem nächsten Jahr, dass wir dann ganz andere Probleme haben, die noch nicht gelöst sind, aber die, die wir jetzt haben, sind dann wahrscheinlich gelöst. Also im Moment, weil das hier auf Talk aufbaut, sage ich euch kurz, was Talk ist, das ist eine Bibliothek, mit der kann man Placent Rout machen für Experimente und Gates und für zum Beispiel Xilinx-Geräte. Das generiert ein XPL-File. Und das kann man mit den älteren Xilinx-Tools einlesen, den ISI-Tools, um den Bitstream zu generieren. Also ich habe mir noch keinen Ende-zu-Ende-Open-Source-Flow. Aber was wir hier haben, ist aus der schwierigen Teil, im Kontext von XPNR, der Placent-Rout-Teil ist hier gelöst. Und bloß für Bitstream-Generierung müssen wir die Xilinx-Tools benutzen. Aber es sollte nicht allzu schwer sein mit der Project X-Ray-Datenbank, das noch zu bauen. Oder es gibt auch noch neue Tools von Xilinx, damit Leute eigene Bitstreams generieren können. Also Screenshot hier. Wir werden noch mehr GUI am Ende sehen, während der Demo. Also das ist, wie es aussieht, wenn man es im GUI-Mode laufen lässt. Man hat hier eine Device-Ansicht. Das ist das fertige Router der Designs. Man sieht die Play-Cells, man sieht die Netze. Einfach, damit es spannender aussieht, habe ich gewisse hier eingefärbt. Da auf dieser Seite sieht man eine Netz-Liste. Man hat ein Console-Fenster hier unten. Das ist, was normalerweise im Terminal zu sehen wäre, wenn man es sich im GUI-Mode startet. Das sieht man, es ist eigentlich eine Python-Shell. Also die ganzen internen Datenstrukturen, die Algorithmen und so weiter, hat man hier Zugriff drauf. Und da auf der rechten Seite kann man sich die Geräte-Datenbank anschreiben, die die Geräte beschreibt. Und die Netz-Liste kann man hier, die wir versuchen hier zu implementieren. Also Dels, Wires und Pips kann man hier anschauen. Die Eigenschaften dieser Objekte hier. Einige Worte zur Architektur von dem Ganzen, von NEXT-PNR. Wir haben hier Teile, die ich Front-End-Komponenten nennen würde. Gewisse sind geteilt zwischen verschiedenen Architekturen und gewisse sind architekturspezifisch. Also zum Beispiel der Code, der eine Netz-Liste lesen kann, ist geteilt zwischen allen Architekturen. Aber der Packer, in welchen wir Lookup-Tables nehmen und diese in Logic-Cells packen, das ist natürlich architekturspezifisch. Also jeder Architektur braucht einen eigenen Packer. Und wir versuchen natürlich NEXT-PNR so zu designen, dass wir so viel Code wie möglich in die gemeinsamen Teile haben und die Architekturspezifische Pids klein sind. Also für jede Architektur muss man natürlich einen eigenen Packer schreiben. Aber wir versuchen da Infrastruktur bereitzustellen, dass das möglichst einfach ist. Dann gibt es natürlich ein Router, ein Placer. Aber dies ist eventuell verzahnt mit architekturspezifischen Komponenten, die ähnlich sind. Also in gewissen Szenarios haben wir vielleicht verschiedene Routers. Also man hat Architekturspezifische, die bestimmte Clock-Routing-Aufgaben übernehmen und dann folgt darauf einen generischen Router. Also je nachdem, was gut ist für die Architektur, die man im Blickfeld hat. Also diese Architekturen greifen auf eine Datenbank zu, die enthält das Design, auch für das wir Placen im Moment. Und der Zugriff erfolgt über diese Architektur API. Also die Architektur-Datenbank kann für verschiedene Architekturen eine komplett verschiedene Art gespeichert werden. Und man hat hier verschiedene Implementation von diesen Architektur-API. Und man hat aber noch viel mehr Architektur-Databases. Also man hat vielleicht eine Architektur, die eine Implementation von der API hat, aber irgendwie fünf verschiedene Datenbanken dahinter für fünf verschiedene Gerätetypen. Also noch zwei Slides über Nomenklatur, die wir in Next Pianar brauchen. Also nicht so, dass jetzt das hier alles brauchen wird in diesem Talk, aber einfach damit ihr so wisst, was für Sorte von Objekten wir überhaupt mit rumhantieren in Next Pianar. Also es gibt die Sign Database, das ist die Netzliste, die man implementieren will. Da drin hat man Cells, Zellen. Also zum Beispiel Lookup Tables, Logic Cells oder Flip Flops. Die man instanzieren kann auf dem Target Gerät. Jede Zelle hat ein oder mehr Ports, also üblicherweise sind es mehr als einer. Ja und diese Ports können verbunden werden zu Netz. Ein Netz kann zu einem anderen Port von einer anderen Zelle verbunden werden und so machen wir die Konnektivität in einem Design. Wenn wir ein bestimmtes Net anschauen, gibt es ein Port, das treibt dieses Netz an, das nennen wir Source und dann gibt es andere Ports an anderen Zellen und dieser nennen wir Sinks. Und ihr das Net hat genau eine Source und beliebig viele Sinks. Und ein paar von Source und Sink nennen wir eine Arc. Also es ist eine sehr wichtige Entität in der Routing Anwendung, weil der Next-Biener Routing Algorithmus priorisiert einzelne Arcs und WPR kann nur Netz als Ganzes priorisieren. Also das hier ist die Design-Datenbank, die Objekte, die wir da verwalten können. Dann gibt es die Architektur-Datenbank. Der große Unterschied ist ein Architektur-Datenbank, dieser ist statisch. Also ich sage, ich will diesen oder jeden Path auswählen und das ist immer die gleiche Design-Datenbank. Aber mit dem Ausführen von Next-Biener gibt es vielleicht eine andere Netzlist. Also was für Dinge haben wir hier in der Architektur-Datenbank? Wir haben Bells, das heißt ist kurz für Basic Element. Das sind die tatsächlichen Blöcke, die physisch existieren im FPGA. Also der Placement-Teil von Place and Route heißt, für jede Zelle im Design muss man ein entsprechendes Bell in der Hardware finden. Und ähnlich wie bei Parts in der Zelle gibt es hier Pins, an den Bells und dann gibt es Wires. Also die Verbindungen herstellen am Ende und man verbindet diese Wires zusammen und das passiert am Punkten, die PIP heißen, Programmable Interconnect Point. Also jeder PIP ist im Prinzip sozusagen wie ein Source Wire und eine Sing Wire und man kann den PIP aktivieren oder deaktivieren. Und genau wie beim Placement, wo man zwischen Cells und Bells mapped. Das Routing muss dann die Netlist mapen auf PIPs und Wires. Noch etwas anders, das es in dieser Datenbank gibt, sind Gruppen, Groups. Also das gibt es eigentlich nur im GUI, da werden einfach Elemente zusammengruppiert in größere Abschnitte. Also je nach FPGA-Hersteller hat man solche organisatorischen Einheiten mit gewisse Slices und die machen Teils und aus Teils gibt es einen Column. Diese Gruppen kann man halt verwenden dazu, diese Strukturen, die der Hersteller vorsieht, abzubilden. Also nehmen wir an, du hast dein eigen ein FPGA, du baust dein eigen FPGA und dokumentierst ein FPGA oder irgend sowas und du möchtest eine neue Architektur zum Next-PMA hinzufügen. Wie würde das aussehen? Das erste, was du machen, ist ein neues Talk Level Verzeichnis anzulegen und ein bisschen ein CMake Matrix zu der Konfiguration hinzuzufügen, damit es als Architektur im System auftalkt. In dem Directory musst du dann wenigstens zwei Dateien erzeugen. Einer heißt ArcDev.h und anderer ist Arch.h und die implementieren bestimmte Datentypen, die Architektur spezifisch sind. Ein von diesen Datentypen heißt BellID. Verschiedene Architekturen können verschiedene zugrunde liegende Datenstrukturen benutzen um eine BellID zu benutzen. In einer Architektur kann das vielleicht nur ein Integra, weil dem anderen heißt es vielleicht ein Struck, das ein X und eine Y-Koordinate enthält, die eine Position der Teil enthält oder es ist ein Bell-Index, das ist ein Punkt in der Kachel enthalten. Man möchte die kompakteste Darstellung benutzen, die in der Architektur möglich ist, ohne die Flexibilität zu verlieren, alle Typen zu repräsentieren. ArchDev, da gehen die Datentypen hinein und in Arch.h geht eine große Klasse, die einfach nur Arch heißt und diese Klasse muss ungefähr 100 Methoden implementieren, um die Architektur-Datenbank darauf zu zugreifen. Und möglicherweise muss noch ein paar zusätzliche C-Files mit zusätzlichen Funktionen für die Architektur hinzuzufügen. Der wichtigste könnte Main sein. Wir haben nämlich nicht eine Main-Funktion für ein Next-PNA, sondern wenn man CMake laufen lässt, was für eine Art von Next-PNA implementiert, dann gibt es einen Binary für IS-40 und eins geht für ICP-5 und so weiter. Jedes hat eine andere Main-Funktion, weil sie verschiedene Kommandzeilen Argumente haben, die für die Architektur spezifisch sind. Also diese Architektur API, die wir jetzt haben, die stabilisiert sich langsam. Wir haben in der letzten Zeit relativ wenig geändert. Ein paar Sachen werden sich in Zukunft noch ändern, aber langfristig werden wir es einfrieren müssen. Also es wird noch ein bisschen sich verändern. Also implementiert jetzt nicht 100 Architekturen auf einmal, sondern geht ein bisschen vorsichtig. Und wir können auch mit jeder Architektur möglicherweise Dinge finden, die neu sind, die wir in der API rücksichtigen müssen. Deshalb ist es jetzt besser, die Architektur eine nach der anderen zu implementieren und nicht alle auf einmal. Aber wir möchten auch gerne sehr viele mögliche Positionen in dem FWI-Design-Raum abdecken, damit wir sicher sind, dass wir alle Funktionalität, die wir brauchen, tatsächlich haben, wenn wir die Version als 1.0 oder sowas festzuhren. Okay, ungefähr 100 Methoden zu implementieren klingt nach ziemlich viel. Aber die Sache ist, diese Methoden sind alle sehr einfach. In vielen Fällen hast du sowas wie deine In-Memory-Datendarstellung der Architektur in der Datenbank und jede dieser Funktionen ist vielleicht 2 oder 3 Zeilen C-Code, die ein bisschen pointerarithmetic machen, dass die richtige Sache im Speicher nachschlagen und dann gerade die eine Sache, die man nachschlägt, aus dem Speicher liest. Zum Beispiel, es gibt keine GetBellInfo-Funktion, die allen Daten über einen Bell gibt, sondern für jede Information, die man ein interessieren könnte, gibt es einen eigenen Getter. Deshalb gibt es sehr viele Methoden, die man implementieren muss, und jede von ihnen ist sehr einfach und klein. Okay, du möchtest jetzt deine Architektur back-end für Next.pna implementieren. Du möchtest die 100 Methoden schreiben. Als erstes musst du überlegen, wie man die Information im Speicher ablegen muss, die deine Architektur beschreiben. Wir glauben, dass es 3 wichtige Ansätze dafür gibt, wie wir das machen können. Aber das Nette ist, wir haben eine sehr generische Architektur, so wenn du eine vierte Methode findest, die nicht auf der Liste ist, dann kannst du diese vierte Methode hoffentlich hinter der gleichen AP verstecken. Also die 3 Methoden, die wir denken, das irrelevant sind, ist erstens eine komplett flache Datenbank. Das heißt, wir haben irgendwo für jedes Wire, für jedes Pip, für jedes Bell haben wir einen expliziten Punkt in der Datenstruktur. Das heißt aber auch, wenn das Gerät zweimal so groß ist, ist die Datenbank zweimal so groß. Aber auch wenn mein Gerät superirregulär ist, dann können wir halt einfach so das implementieren, haben eine flache Datenbank für eine sehr irreguläre Architektur. Wir benutzen eine flache Datenbank für ICE40. Einfach weil die ICE40 Chips so klein sind, dass es Sinn macht, das so zu machen. Aber wenn du vorstellst, dass dein Gerät größer und größer ein Chip größer und größer wird, wird auch die Datenbank größer und größer. Und das ist nicht mehr wirklich umsetzbar. Und da gibt es verschiedene Ansätze, das umzusetzen. Der nächste Schritt ist, eine deduplizierte Datenbank zu benutzen. Die grundsätzliche Idee dahinter ist, dass ich zuerst eine flache Datenbank erzeuge und dann gucke ich in der flachen Datenbank für Regularitäten, zum Beispiel Wires mit einer bestimmten Layout, einer bestimmten Struktur, oder es gibt eine Menge von Wires wie mit der gleichen physischen Geometrie, nur eine Kachel weiter rechts. Dann können wir diese beiden Einträge zusammenfassen und wir brauchen das nur einmal in dieser Datenbank abzulegen, die von zwei verschiedenen Stellen referenziert sind. Das Nette auf einer deduplizierten Datenbank ist, dass man trotzdem noch mit einer flachen Datenbank anfangen kann. Also wenn dein Chip eine paar Irregularitäten hat, braucht man nichts Speziellen machen. Wenn das halt irgendwo eine Irregularität gibt, dann wird es halt einfach nicht dedupliziert. Die Schwierigkeit dabei ist oder Nachteil, dabei ist der Chip natürlich klein genug sein muss, dass man überhaupt erstmal eine flache Datenbank erzeugen kann, damit man sie dedupliert sehen kann. Für richtig große Chips ist das auch noch keine Option. Für die braucht man etwas, eine Kachelbasierte Datenbank. Da sagt man einfach, okay, dies ist diese Kachelstruktur meines Chips und dann habe ich eine Datenbank mit einem Eintrag für jeden Kacheltyp und dann habe ich eine Datenbank, welche Kachel in dem Chip zu welchem Typ von Kacheln gehört auf dem Chip. Der Vorteil hier ist, wenn der Device doppelt so groß ist, dann wird die Datenbank nur ein klein wenig größere. Wenn man zwei verschiedene Geräte hat in der Chip-Familie, dann ist die Datenbank, die beide von ihnen beschreibt, nur ein klein wenig größer als die Datenbank für einen. Gerade jetzt benutzen wir eine flache Datenbank für AS40 und für die ECP5 eine deduplizierte Datenbank. Und das langfristige Ziel für das S7-Geräte ist eine kachelbasierte Datenbank. Okay, da gibt es eine Python-Appi. Wer hier hat Dinge in Tickle? Ja, ein paar Leute melden sich. Wer fühlt sich darüber schlecht? Die meisten melden sich weiter. Okay, wir haben keinen Tickle. Wir veröffentlichen alle Funktionalität als Python-Appi. Das macht es einfach, Algorithmen zu Prototypen. Man kann schnell etwas ausprobieren. Und wenn es funktioniert, dann kann man überlegen, ob man es schneller machen kann, indem man es in C nach übersetzt. Aber wir benutzen Python auch für Constraint. Wir haben einfache Beschränkungen. Wir haben hier diese Clock-Constraint, also diese Geschwindigkeit oder Zeitbeschränkung. Aber man kann auch tatsächlich Code in Python machen. Der Dinge macht, der alle Cells in einem Design überprüft, ob sie ein bestimmtes Satz von Attributen haben. Und wenn sie diese Attribute haben, kann man bestimmte Platzierungsbeschränkungen hinzufügen. Ich glaube, das ist viel flexibler als andere Ansätze, wenn man größere Designs hat. Und Beschränkungen, wo es schwer ist, eine explizite Liste zu schreiben. Das soll hierhin gehen, das dorthin und so was. Stattdessen schreibt man ein kleines Programm, dass man auf das Design guckt und dann die Beschränkungen anhand von Zellenattributen oder Ähnlichem generiert. Was sind die nächsten Schritte? Als Erstes wollen wir langsam erachne PNR als das wichtigste Place-and-Route-Hol für I-40 ersetzen. Im Project I-Storm. Wir sind schon recht weit damit. Viele der Dinge, die Project I-Storm benutzen, sind schon dabei, nach Next PNR zu ersetzen. Wir wollen darüber nicht zu aggressiv sein, wenn alle gleichzeitig umschalten, dann kriegen wir alle Bug-Reports auf einmal und niemand ist wirklich glücklich. Deshalb brauchen wir keinen zu schnellen Übergang. Wir haben noch viele Ideen, wie man unser Place-and-Route weiter verbessern können. Einige davon sind von konkreten Anforderungen getrieben. Wenn wir zum Beispiel einen of die Ergebnisse gucken, wie wir für Sallings kriegen und sehen, dass wir das reparieren und das und das, damit es verdünftig funktioniert, so gut wie wir es haben wollen. Andere Verbesserungen sind Ideen, die wir einfach mal ausprobieren wollen. Natürlich ist das eine Sache, wo wir nach anderen Leuten suchen, die das benutzen, zum Beispiel als Basis für akademische Forschung. Also, wenn du irgendwelche Ideen hast, wie ein Placer oder ein Router arbeiten soll, dann glaubt, dass es möglich ist, dann ist Next PNR möglich, höffentlich ein gutes Framework um solcher Experimente zu machen. Und außerdem wollen wir das Support für mehr Architekturen haben. Der ganze Punkt ist, dass wir mehr Architekturen unterstützen können. Aber wir möchten halt langsam eine Architektur nach der anderen hinzufügen. Und wir hoffen, dass wir langfristig das mit tatsächlicher Unterstützung von den Herstellern machen können. Damit wir nicht damit anfangen müssen, auf Bitstreams zu starten und versuchen, rauszufinden, was einzelne Bits in dem Bitstream machen. Und ja, sobald wir da sind, haben wir dann hoffentlich Feldhorschraft im Bereich von Place and Route. Ja, ein paar Vergleiche zwischen Erachne PNR und Next PNR. Das ist Next PNR Bench. Die letzte gibt es eine Handvoll Designs da drinnen. Und das hier sind die 10 Durchläufe für die Tools mit verschiedenen zufälligen Zufallszahl-Startwerten. Und auf der linken, links in der Tabelle könnt ihr die maximale Frequenz sehen. Im Prinzip ist, hat ein Next PNR 30% schnellere Designs. Das ist deutlich ein Fortschritt. Auf der rechten Seite könnt ihr aber sehen, es ist etwa 50% bis 100% langsamer ist in der Laufzeit für den Placer, weil es einfach aufwendiger ist, alles Timing, die die Zeit getrieben zu machen. Das hier ist wieder Next PNR gegen Erachne PNR. Wir machen auch noch Backfix. Das ist ein Erachne PNR, aber großem Ganzen ist Erachne PNR. Das ist ein stabiles Vergleich. Und wir vergleichen hier die erreichbare maximale Frequenz verglichen mit Erachne PNR. Wir haben immer die Zeit, die Skrips laufen zu lassen. Hier sieht man, es gibt einige Verbesserungen. Wenn wir diese Rate weiterhalten über das letzte Jahr, dann werden wir so weit sein, dass wir Designs generieren, die schneller sind als physikalisch möglich. Diese Besteigerung wird sich nicht mehr lange erhalten. Ich muss hier noch meine Einstellung ein bisschen ändern. Jetzt sehen wir beide das Gleiche. Das ist nicht groß genug. Seht ihr das? Ich sehe nur die Leute hier vorne, die sagen mir, dass es gut ist. Das erste, was ich euch zeigen möchte, ist das hier. Das benutzt die JOSES, um Synthese für ein einfaches Design zu machen. Dann lasse ich PNR laufen, um das Place and Route zu machen. Das erstellt eine Datei, die dann von Eistorm verwendet wird. Diese drei Befehle hier ist der komplette Flow von Verilog zu Bitstream. Das ist ein kleines Design. Ich schaue mir da mal kurz rein. Das ist einfach, wie das hier dann blinkt. Wer hier hat schon mal mit einem kommerziellen FPGA Flow gearbeitet? Okay. Stellt euch jetzt vor, er nimmt ein kommerzielles Tool und ihr wollt jetzt da ein Blinky Design durch den Flow durchlaufen lassen. Stellt euch vor, wie lange das da braucht. Und jetzt vergleichen wir das mal mit, wie lange mein Ding hier braucht. Das hier war jetzt eine Drittelsekunde. Manche werden jetzt sagen, das ist ja ein sehr kleines Design, dass es nicht was in der Industrie interessant ist. Da ist es eher so, die Fälle spannen, wo es fünf oder zehn Stunden brauchen. Aber ich denke, das verfehlt dem Punkt, den ich hier machen will. Der Punkt ist, jede Anwendung ist verschieden. Und wenn wir ein Open Source Flow haben, heißt das, man kann den Prozess optimieren auf den Aspekt, der für dich wichtig ist. Und bei einem propertären Tool muss man halt mit der Optimierung leben, die der Wender für dich macht. Also das war das. Das ist jetzt ein bisschen größer. Also es geht zum Risk 5 SoC. Das läuft dann auch vom HX8K. Also ich habe die drei auskommentierten, habe ich schon mal ausgeführt. Jetzt können wir direkt zum Next Pianar gehen und das hier laufen lassen. Also das ist jetzt ein HX8K. Das ist ein 8000 Lattice von der Prodyseries. Wir können da rein zoomen. Ich kann da einzelne Dinge auswählen, wie Netze oder Bells. Also was ich jetzt gemacht habe, war, den Packer laufen zu lassen, dieses Icon hier. Und dann sieht man hier, dass das Design, das wir haben, etwa 2000 Zellen hat. Das nächste wäre jetzt ein Timing Budget zuzuweisen. Da gibt es natürlich noch feine aufgelöste Dinge, das zu machen. Aber ich kann jetzt einfach mal sagen, ich lasse das Ganze mit 50 MHz laufen. Dann lasse ich den Placer laufen. So, da kann man zuschauen, wie Zellen rumgeschoben werden. Der Placer Algorithmus ist ein zweistufiger Prozess in der schnellen Stage. Lässt man so relative Platzierungseinschränkungen mal sein. Ich kann hier nicht hochscannen während des Laufs. Dann kommt man zu diesem Punkt hier. Dann schaut man, dass diese ganzen Constraints eingehalten werden. Und von da an lässt man alle diese Constraints unverletzt. Und dann hat man am Ende Placement Post Placement Timing Report. Und der Post Placement Timing Report sieht hier ziemlich gut aus. So, dann lassen wir den Router laufen. Da ist ziemlich schnell, wie man sieht. So, und jetzt sind wir fertig. Und jetzt kann man Bitstream-File schreiben. Oder was auch immer. Und wir sind fertig. So, das ist jetzt das ASC-File. Mit den Ice Storm-Tooms kann man diese Umwandel in einem Bitstream-File. So, ich denke, dann haben wir jetzt noch Zeit für Fragen. Thank you very much Clifford. So, danke Clifford. Wir haben noch viel Zeit für Fragen. Stellt euch zu der Mikrofon hin. Ich bin auf über zwei Dinge neugierig. Was für ein Solver benutzt, das ist ein Constraintsolver. Ist das ein richtiger oder ist es mehr heuristisch? Also, eines der Projekte, an der wir dran sind, versuchen wir ein Solver zu verwenden für Placements. Im Moment haben wir da noch keinen funktionierenden Code. Also, meine Präferenz wäre, in Sachen Solver Glucose oder Kryptomancer zu verwenden. Ja, doch, ich erkenne dich von einem Twitter-Profil. Weil dieses Tool, diesen Block von Logik in der Mitte, wird dann der FBI in der Mitte zu warm werden. Wenn er kalt draußen ist, erzeugt das keinen großen Temperaturgradienten? Nein. Also, der Temperaturgradient, ich meine, es gibt Künde, wegen denen ich die etwas verteilt habe, insbesondere um die Routability zu verbessern, aber wegen den Timing Constraints tendiert es dazu, dass alles nah zusammen ist. Aber dieses Device hier ist vielleicht weniger als ein Quadratmillimeter, die Dice-Size. Also, ja, die Temperatur wird nicht variieren und das ist so ein sehr low-power FPGA. Also, sonst ähnlich warm werden. Also, mindestens verspricht das der Wender. Eine Frage aus dem Internet. Kann man das endgültige Placement in der GUI interaktiv verändern? Nein, in der GUI nicht. Also, ja, mal schauen. Kann man hier Dinge anplacen? Versuche ich das mal gerade schnell? Ja, wo ist die Zelle da? Bounce Cell. Okay. Nee. Also, ich meine, ich kann es hier reinschreiben. C-Takes, Unbind Bell und dann der Name der Bell. Das war irgendwie das hier. X16, Y17, Logic Cell 6. So. Und jetzt ist die Bell wieder verfügbar. Also, wenn dieser Python-Command AI-Game als in der GUI-Zelle dann, ja, dann kann ich sowas in der GUI machen. Noch eine Frage aus dem Internet. Habt ihr darüber nachgedacht, hat der Beschleunigung zu benutzen wie OpenCL oder ähnliches? Ich habe die Frage nicht verstanden. Ja, ich bin mir nicht sicher, was da der Bezug ist zu Place and Route. Ich meine, bei OpenCL Beschleunigung in der Regel läuft ein High-Level-Synthesis-Tool und dann läuft er mit dem Verilog durch diese Synthese. Du meinst du, dass man das für Place and Route verwenden soll? Ah, ja, wir hatten das diskutiert, aber da bis jetzt noch nichts Konkretes rausgekommen. Hallo, du hast gesagt, dass Place and Route zeitgetrieben ist. In Bavardo gibt es auch so Dinge wie Laufzeit optimisiert oder Flächen getrieben. Also Flächen getrieben, das ist eher im Synthese-Tool, da kann das Routing-Tool nicht viel machen. Meistens, dass wir im Moment machen, auf der Synthese-Seite mit Joses, ist eher so nach Flächeneinschränkungen, weil die Timing-Constraints in der Synthese noch nicht drin sind. Die peinlichere Frage für mich wäre jetzt so, haben wir Timing getrieben als Synthese mit Joses, aber zum Glück ist das ein Next-PNR-Talk. Keine weitere Frage aus dem Internet. Ja, ich würde sagen, das beendet diesen Talk. Moment, ich möchte noch kurz was sagen hier. Wir haben in Halle 2 neben der Hardware-Hacking-Area den Open FPGA-Bereich. Wir haben weiße Schirme mit Open FPGA drauf. Also wenn ihr noch Fragen habt, kommt doch vorbei. Wir haben auch Anfänger-Workshops da. Also kommt doch mal vorbei bei uns. Viel zu tun, also habt Spaß damit. Eine Runde Applaus zu unseren Sprecher. Ja!