 basierend darauf auswandern kann. Es ist mir einfach genügend Clifford zu vorzustellen. Da habe ich auch ein sehr komplexes Thema vorgestellt, von dem ich wenig weiß. Also es geht um FPG. Es gibt einen großen Applaus für Freie und Open Source Verilog zu Bitstream Flow für ICE40 FPG-Aus. Danke. Ich werde euch dieses Thema vorstellen, das heißt konkret, ich werde euch drei Projekte vorstellen, weil es drei Projekte zusammen sind, die zusammengehören. Es gab drei Projekte, die diesen Bitstream Flow angeschaut haben. Es geht einerseits um das Projekt ICE Storm, das geht darum, das Bitstream Format für die FPG-Aus zu reverse-engineeren und zu dokumentieren. Das sind halt diese Formate HX1K und HX8K. Theoretisch sollte es auch Alpe 1K und 8K unterstützen, falls es sowas gibt, weil eigentlich haben die FPG-Aus nur verschiedene Timings, aber das Binalformat sollte kompatibel sein. Vom ICE Storm Projekt haben wir die Dokumentation dieses FPG-Aus. Die gibt es sowohl in menschenlesbarem Form als auch in maschinenlesbarem Form, damit man auch mit anderen Tools damit weiterarbeiten kann, nicht nur als Mensch. Außerdem haben wir davon ein paar Tools, mit denen man die Bitstreams files lesen kann, sie konvertieren kann in andere Formate und hin und her und sie wieder zurück. Das zweite Projekt, das ich euch vorstellen werde, ist ARACHNE PRNR. Das ist ein FPGA Place and Route, also Platzier- und Routing Tools für diese Sorten FPG-Aus. Das passiert auf der Dokumentation vom ICE Storm. Also ich habe zuerst das ICE Storm Dokumentation gemacht und dann hatte ich das Glück, dass ich auch das Place and Route Tool schreiben könnte. Das passiert an der Dokumentation, die ich vorhin geschrieben hatte. Ein weiteres Projekt sind JOSIS. JOSIS ist quasi mein Hautprojekt, an dem ich im Moment am Arbeiten bin seit etwa drei Jahren. JOSIS ist ein riesiges Projekt, aber kurz gesagt ist es eine Verilog-Synthesierungssoftware Suite, das man benutzen kann, um diese Verilog-Files für Netzlisten für verschiedene FPG-Aus oder ICE-Aus zu konvertieren. Es unterstützt auch andere FPG-Aserien und wie gesagt ICEX und kann auch formal verifizieren, ob darüber werde ich nur wenig sprechen. Das letzte ist das EcoBoard. Da gibt es auch eine Demo. Das EcoBoard ist ein Entwicklungsboard. Das hat die Features von diesen FPG-Aus vorgestellt. Die Box, die ihr da seht, ist dann die Demo, die ihr später sehen werdet. Am Ende des Talks. Wie funktioniert der Fluss, der Datenfluss? Das ist ICE Storm. Ein großer Overview. Man fängt mal an mit Quelltext aus Verilog und ein paar Syntheserskripten. Das Syntheserskript liest die Verilog-Dateien und führt ein paar Dinge aus, die dann nötig sind, um es auf das spezifische FPG-Au zu mapen. Das Output, der Ausgang von diesem Miosis, ist dann ein Bliff, weil das ist dann ein einfaches Netzlistenformat. Das ist eines von vielen Formaten. Wir haben ein paar Extensions für das Bliff-File-Format geschrieben, sodass man mehrere Attribute und Parameter einstellen kann. Zum Beispiel die Lookup-Table, wo das Design soll in dem FPG-A. Da kann man zum Beispiel als Parameter einstellen. Dann nehmen wir diese Netliste, das Bliff-File, und geben das weiter ans Arachne. Das ist das PleistandRoute Tool. Wir geben dem Arachne auch ein paar andere Dateien, zum Beispiel physikalische Constraints, wo jeder Pin sein soll am FPG-Au zum Beispiel, also welcher Signal auf welchen Pin gemappt werden soll. Optional kann man auch ein PleistandRoute-Script ihm geben, dass Arachne-Appierner sagt, welche Strategie es nehmen soll, um in welcher Reihenfolge es zum Beispiel das ganze Zeug verarbeiten soll. Das Ausgabe-File von Arachne-Appierner ist also ein iStormTagestee-File. Das ist ein sehr laulebliges Format, und für jedes einzelne Element in dem FPG-A wird dann definiert, also zum Beispiel in Zeile so und so, ist dann das Bit, das diese Funktion erledigt. Und dieses Text-File wird dann weitergegeben an Icepack, dass dieses Text-File unumandeln kann in die Binaire-Repräsentation, also in das Bitstream, das Binaire-File für das FPG-A. Also schauen wir zuerst an das Ice-Storm. Das ist der erste Teil von meinem Talk. Zuerst gebe ich einen kleinen Überblick über die Ice-40 FPG-As. Die FPG-As sind nicht so sehr verbreitet. Viele Leute brauchen Zeilings oder Altera, aber Lattis ist nicht so verbreitet, eher eine Nische. Es ist eine Familie von kleinen FPG-As. Das kleinste hat um die 8.000 Look-Up-Tables, und das ist hier wenig. Das FPG-A selber ist dann ein Ding von Kacheln, Logik-Kacheln, die miteinander verkünft sind, und es gibt verschiedene Look-Up-Tables und Flip Flaps und Rechen-Logik und so weiter. Dann gibt es auch Ram-Kacheln. Zum Beispiel einen Anfang- und Schluss-Form-Ram. Dann gibt es Input-Output-Kacheln, mit denen man das Input-Output macht, was aber auch zum Programmieren benutzt wird und um die Logik auf anderen Ressourcen immer chip und auf dem Ausrat des Chips zu verbinden. Eine hübsche Sache an diesen FPG-As ist, dass es in verschiedenen Packages kommt. Man hat keine Ball-Grader-Rise zum Beispiel, sondern im 144-pin TQ-FP zum Beispiel, dass man auch von Hand löten kann. Und es ist eines der cheapest Development Boards, dass man für diese FPG-As haben kann, kostet weniger als 25 Dollar. Und jemand, der einfach nur rumexperientieren möchte, kann relativ billig an diese Kräte kommen. Und wenn man Low-Level-Zeug machen will, dann ist man damit auch ganz gut versorgt. Und es ist sehr nett, wenn man sowas billiges hat, wo man halt auch Sachen austauschen kann, um es zusammenzufassen. Das FPGA sieht ungefähr so aus. Wir haben hier diese logischen Logikacheln. Da sind die Speicherkacheln. Sie nehmen zwei Reihen ein. Und an der Kante haben wir die ... Und in der Mitte haben wir die ... Und wir haben da diese acht Flip-Flops und acht Übertragsregister und Lookup-Tables. Das ist alles vergrößert, damit wir mehr Details sehen können. Aber das hier ist eigentlich nur ... Es fehlen noch Sachen. Zum Beispiel, da ist noch eine Verbindung, die ... die Lookup-Tabeln verbinden. Und dann die Flip-Flops umgehen. Und rechts unten sieht man das ... Und ich denke, das kostet alles 25 Dollar. Mit Projekt iStorm haben wir eine sehr detaillierte Betrachtung dieser FPGA. Wir haben dieses Low-Level-Tool geschrieben, um mit Bitstreams zu arbeiten. Und wir haben auch ein sehr einfaches Textformat definiert, mit dem man jede Bit-Konfiguration leicht definieren und spezifizieren konnte. Und hier sieht man dieses Text-File. Logic-Tile 9.9. Das sind natürlich die Koordinaten. Und dann hat man diesen Block von 1 und 0. Und wenn man in der Dokumentation nachschaut, dann online sieht man, okay, in der Doku sagt ... Die Doku sagt, dass dieses Bit für die und die Funktionalität steht. Mit den iStorm-Werkzeugen können wir die Binarys und die Text-Tools verarbeiten. Wir können auch eine Text-Datei nehmen und sehen die Binea-Very-Lock-Datei umwandeln. Und als ihr das Feature zum ersten Mal veröffentlicht habt, habe ich auch ziemlich viele Hassmails bekommen, weil ich deren intellektuelle Properties geklaut haben sollte. Und das Projekt ist immer noch nicht völlig fertig. Und der Grund, warum wir das immer alles solo-Level machen ist, weil wir diese Dateien von unseren eigenen Flow erstellen können. Und die Bit-Streams werden dann von den Lesses-Flows produziert. Und dadurch können wir unsere Tools selber verreffizieren. Und dadurch wissen wir, ob der Bit-Stream korrekt ist. Und wir können zufällige Inputs geben und schauen, was der Output ist und schauen, ob das alles hinhaut. Und dann verwendet man halt Joses, um das alles noch weiter zu überprüfen. Also, ihr könnt auf www.clifford.at. slash iStorm, um die Dokumentation zu lesen. Aber eine Warnung. Es ist eine Referenz. Es ist keine Einführung oder Tutorial. Wenn ihr nichts wisst, wie FPGAs funktionieren, dann ist es ziemlich schwer zu lesen. Außer es ist nicht sehr gut strukturiert, leider. Aber es ist auch nicht sehr lang. Es sind nur einige Seiten. Meine Empfehlung ist, wenn ihr wirklich wissen wollt, wie FPGAs funktionieren. Und was jedes Bit bedeutet, dann lest ihr das einfach mal komplett durch. Und dann habt ihr eine Übersicht. Also, es ist eine sehr kleine Dokumentation. Man hat es in etwa einer Stunde gelesen. Es sollte nicht so schlimm sein. Und die Dinge, die da drin sind in dem Projekt, abgesehen von der Dokum, abgesehen von den Tools, ist eben eine geschriebene Dokumentation, die auch einen Überblick gibt. Dann ein autogeneriertes HTML-Dokument. Das gibt euch ein paar Referenzen, was, wer jedes Bit genau meint und macht. Und es gibt eine autogenerierte ASCII-Datenbank, die man dann in anderen Tools weitervermenten kann, zum Beispiel im Arachnepäner. Eine paar Screenshots hier aus dieser Dokumentation. Also, unten links seht ihr ein Teil der geschriebenen Dokumentation, wo die Input-Output-Elemente, Kacheln erwähnt werden und erklärt werden, wie das verbunden ist. Dann seht ihr die Screenshots, mit diesen schönen farbigen Tabellen. Das ist das autogenerierte HTML-Dokument, welches wirklich jedes einzelne Bit dokumentiert. Und das meiste davon, in mehreren verschiedenen Arten, was man machen kann und welches Netz zum Beispiel, so welchen anderen Netzen verbunden werden kann, usw. Oben rechts zum Beispiel für einen Logic-Kachel wurde die ganze Logic Reverser engineered. Ihr seht ein paar ausgegraute Bereiche. Soweit ich das sehe, haben wir das nicht vergessen, sondern diese Bits sind nicht verwendet. Ich bin natürlich nicht 100% sicher, aber ich habe nichts gefunden, das diese Bits verwenden würde, so nämlich an, sie sind nicht benutzt. Und unten rechts seht ihr ein Teil der Interconnect-Dokumentation. Da sieht man zum Beispiel Dinge, dass zum Beispiel diese Verbindungslinien, Verbindungsdingen, ja, weil es ein paar Weise gekreuzt nach außen gehen. Das ist das Projekt ICE-Storm, das Low-Level-Zeug. Es ist natürlich sehr interessant, einfach mal zu sehen, wie das FPGA funktioniert und so weiter. Aber es gibt uns noch nichts, da mit dem ja arbeiten kann und irgendwas cooles mit dem FPGA machen kann. Daher gibt es jetzt den zweiten Teil, das Arachneperner, das Pleistand-Rout-Tool. Das nimmt nun diese Bliff-Netz-Liste und konvertiert sie in eines dieser Text-Files-Text-Formate. Es macht halt diese Operationen, es instanziert Input-Output-Zellen, Clocks, Puffer und so weiter, also ein paar Dinge, die halt praktisch sind mit Pleistand-Rout. Dann macht es Look-Up-Types, Carry-Übertragungs-Logic und so weiter. Und zum Beispiel diese Logic-Blocks, also das FPGA hat halt verschiedene, solcher Logic-Blocks und die Beschreibung, also das Verilog und das muss man irgendwie zusammen mapen. Dann kann das ganze Ding auch noch verifizieren, zum Beispiel, also zuerst platzieren und dann analytisch verifizieren. Wie funktioniert dieses Eingabe-Netz-Listen-Format, das Bliff? Es benutzt die selben Zelltypen, die auch von den Lattice-Tools selber benutzt werden. Wir haben uns dann diese Library gehalten, die vorgegeben ist von Lattice, damit wir unsere eigene Tool-Chine halt mixen können, wie schon erwähnt, damit man halt das Zeug gegenseitig testen kann. Das Bliff ist ein relativ einfaches File-Datei-Format. Da seht ihr zum Beispiel ein Modell, das halt im Verilog war, das ist halt mein Modul. Das hat ein paar Inputs und Outputs. Alle Netze, die benutzt werden, aber keine Inputs und Outputs sind, sind halt einfach intern. Dann dieses Ding ist jetzt, also dieses Modell ist eine simple Look-Up-Tibels mit vier Inputs und einem Out-Eingang und einem Ausgang. Und das macht jetzt in diesem Fall noch eine Initialisierung von dieser Look-Up-Tibel. Dann kann man auch weitere Input-Eingabe der Teilen hineingeben in dieses Erachne. Zum Beispiel eine physikalische Einschränkung. Zum Beispiel, wenn man, ja, es ist auch, das ist wieder eigentlich zu den Lattice-Tools und daher ist es wieder einfach, einfach zu wechseln zwischen unserer Toolchain und der Lattice-Toolschain. Ihr könnt auch das Place und Route-Skript benutzen. Das ist noch etwas experimentell. Und dem könnt ihr zum Beispiel auch manuell sagen, welche, ah, das Skript, da könnt ihr manuell sagen, welche Schritte, welche Reihenfolge ausgeführt werden sollen. Und es gibt auch einen experimentellen Flow, der bereits funktioniert. Und das ist aber eigentlich nicht das, was wir am Schluss zwar wollen, aber mit einem analytischen Placement, weil der analytische weiß nicht genau, wie das FPGA aussieht, sondern das ist ein allgemeiner Ding. Und das ist eigentlich nicht, was wir am Schluss wollen. Die Ausgabe von Erachne-Pianer sind ASCII, wie gesagt, ASCII-Text-Formate, welche dann mit den iStorm-School-Tools konvertiert werden können zu den Low-Level-Formaten. Natürlich kann man auch mehrere Ausgabe-Dateien erstellen, zum Beispiel eines, das alle Platzierungen enthält. Oder wieder eine so eine Blif-Netz-Liste für ein Design, das ihr untersuchen möchtet. Das ist der zweite Part von unserem Flow. Jetzt können wir eine Netzliste nehmen, die es bereits gibt auf dem Chip. Also theoretisch könnten wir es schon sehr minimalistische Designs machen, aber das wollen wir, ist noch nicht sinnvoll in größeren Mengen umsetzbar. Und darum gehen wir jetzt zu Josez, welches mein Hauptprojekt ist. Ja, und das Josez ist zur Umwandlung von InfoZonder. Hier ist eine Übersicht, also man kann Veriloch lesen und andere Dateithypen, man kann auch Sachen rausschreiben und er hat quasi alles wichtigen Features für Veriloch 2005. Auch allerdings, ich habe die Leute, also wenn ich hier jemand daran arbeiten möchte und das wäre schön, und wir werden sehen, was so die nächsten Jahre bringen. Man kann Veriloch Netlist schreiben und man kann auch ein Bliffnetlist schreiben und auch das EDIF-Format kann verwendet werden. Man kann natürlich RTL-Synthese machen und einige Optimierungen benutzen, ein externes Tool welches für Low Level Optimierung verwendet wird. Und ihr könnt auch die verschiedene Zielarchitekturen angeben und ihr könnt formelle Verifikationen durchführen. Und das war echt das, wo ich die meiste Zeit mit verbracht habe, daran gearbeitet habe. Einige sagen, Josus ist wie LLVM für Hardware. Ich mag diese Idee und diese Analogie. Da sind eine Reihe von Projekten momentan, die sozusagen LLVM für Hardware darstellen könnten. Welche Flows existieren tatsächlich? Natürlich sind da mehr Flows, als ich sie implementiert habe. Die meisten sind Projekte von einer einzelnen Person. Die eine Doktorarbeit waren oder das sind die Flows, die mehr generell sind, allgemein. Es gibt zwei elementare Flows. Es gibt Q-Flow und es gibt Control-List 2. Diese wurden bereits verwendet, um Chips auszutapen. Und es wurden auch kommerzielle Chips damit gemacht. Es sind tatsächlich Dinge, die benutzt werden und es sind keine Gedanken-Farimente. Natürlich gibt es die Synthese für ICE 40, worüber ich gerade spreche. Es gibt auch Flowsynthese für Zylings 7-Series FPGAs. Man kann Josus benutzen, um die Synthese zu machen, aber dann muss man andere Tools verwenden, um weiterzukommen. Es gibt auch noch einige formelle Verifikations Flows. Ich denke, der Interessante wäre hier SMT, der verwendet wird, um formelle Verifikationen mit SMT-Solvern verwendet wird. SMT-2 ist das Format, das getestet wird. Man hat zumindest damit keinen Vendor-Lock in, weil ... Also, wie sieht ein Josus-Synthese-Script aus? Wie sieht das aus? Das sieht aus wie so etwas wie hier. Man hat normalerweise einen Allgemeinen-Part, Generic-Part, und danach dann einen spezifischen Fürst-Target, also für die Zielearchitektur. Und das ist halt für das Mapping in der Zielearchitektur zuständig. Natürlich, das sieht sehr aus wie eine kommerzielle ASIC-Toolchain. Und ... Okay, das ist es gerade ein bisschen kompliziert. Also, Josus, das Synth-Commando hat verschiedene Unteroptionen. Wenn man sich zum Beispiel die Nachricht-Hilfe-Message anschaut, sieht man halt diese Unterkommandos wie PROC oder OPCLIN oder memory. Das sind eigentlich nur Sequenzen von anderen Kommandos. Damit macht man halt aus einer hocheffigen Beschreibung eine low-level Descript-Beschreibung. Also, ihr könnt zum Beispiel auch einen beliebigen Punkt unterbrechen und dann das Zwischenresultat anschauen. Formale Verifikationen in Josus, wie ich schon gesagt habe, die Formale Verifikation ist recht ziemlich wichtig für mich. Darum habe ich gerne verschiedene solche Methoden, Formale Verifikationsmethoden in Josus. Wir haben zum Beispiel einen Satz oder welcher Seine, welcher einfache Fragen beantworten kann. Gibt es eine Sequenz von einem Zeitschritten, wo man am Schluss das Signal A-High ist und das Signal B-low ist, zum Beispiel so Zeug kann es. Das braucht man recht oft, wenn man größere FPGA-Design macht, zum Beispiel einen Debugger auf dem Chip direkt, weil man so viele verschiedene Signale hat, die man anschauen muss. Und wenn mir dann jetzt der Unchip-Debugger sagen kann, ja, hey, das Signal ist tatsächlich high und das ist low, und dann kann ich vielleicht sagen, hey, das sollte gar nicht der Fall sein, um einen Chip weiter debuggen. Und, ja, dann synthesiert man das Ganze und nochmals und nimmt mehr. Also, egal. Bei diesem System könnt ihr halt kompliziertere Schritte umgehen und direkt intern debuggen, zum Beispiel. Dann kann ich so eine Kütze stellen, also ich möchte ja verifizieren, dass die Ausgabe formal indentisch ist zur Eingabe und das kann man zum Beispiel mit diesen Meter Circuit machen und das kann der IBC Solver zum Beispiel, kann das dann prüfen. Der letzte Teil oder der Part 4, das ist der Fluss von diesen Tools. Wir können jetzt damit alles implementieren, was wir brauchen, also wie machen wir das? Zuerst brauchen wir ein Entwicklungs-Sport. Zum Glück gibt es viele Entwicklungs-Sports von Lattice, zum Beispiel dieses, und es gibt auch viele Hardware-Entwicklungs-Sports im Allgemeinen. Wir wissen, ja, so eine gute Anzahl davon wurde wahrscheinlich inspiriert von diesen Open-Source-Flow, bevor ich das Ganze publiziert habe. Und im Lunden-Links seht ihr das ICO Board. Das ist ein Projekt, wo ich auch mit dabei bin und das benutze ich daher für die Demo. So sieht das ganze Ding aus. Das ist ein Raspberry Pi und das 8K FPGA ist da drauf und es kann bis zu 20 Input-200-Input-Output-Pins und so weiter, wie es auf einem Slide steht. Also insgesamt eben habt ihr fast 200 Input-Output-Pins und den Raspberry Pi. Und... ...mögliche Anwendungen davon sind. Naja, ihr könnt einfach einen intelligenteren Raspberry Pi machen, der mehr rechnen kann. Ihr könnt den Raspberry Pi als Netzwerkprogrammer benutzen, also für das FPGA. Und eine Idee, die mir ziemlich gefällt ist, ihr könnt HDL-Code erstellen auf dem Raspberry Pi, auf dem Raspberry Pi synthetisieren und dann das FPGA direkt synthetisieren, ohne dass ihr halt einen separaten Programmer benutzen müsst. Jetzt haben wir also ein kleines Demosystem on Chip gemacht. Warum machen wir das? Also zur ersten Mal möchten wir euch überzeugen, dass diese Toolchain tatsächlich funktioniert für nicht triviale, nicht nur Hello World Beispiele und das zweite, ein sehr kleines FPGA. Daher möchte ich auch überzeugen, dass auch ein kleines FPGA mit 8000 Lockup-Tables interessante Sachen machen kann. Darum macht meine Demosystem on Chip. Das Demosystem on Chip benutzt nur etwa 50% der Logikressourcen auf dem FPGA. Also es kann auch... Es ist sicher auch interessant, als Basis für weitere Projekte, was ihr zum Beispiel damit machen könntet. Basis hat einen fully featured 32-bit Prozessor. Also ihr könnt zum Beispiel mit der GCC-Toolchain dann Programme kumpelieren dafür. In dieser Demo ist der Raspberry Pi nur benutzt als Debugger, der mit dem Netzwerk verbunden ist. Er macht sonst nichts. Dies ist ein vereinfachtiges Blockdiagramm dieser Demo. Ihr seht, alle Dinge in Pink sind irgendwas, das auf dem FPGA selber läuft. Die externen Dinge sind zum Beispiel der Raspberry Pi. Zum Beispiel ist dieser auf diesem Bass verbunden, welcher halt Kommunikation ermöglicht zwischen dem Raspberry Pi und dem FPGA. Auf dem FPGA haben wir auch einen On-Chip-T-Bagger. Dann haben wir einen Endpunkt, den man benutzen kann, um den FPGA neu zu programmieren. Es gibt eine Textkonsole. Es gibt ein 32-bit Systembus im FPGA, welcher alle Untersysteme miteinander verbindet. Zum Beispiel all diese Endpunkte, das internes Entendenspeicher, ein Controller für externen Speicher. Wir haben einen Frame Buffer, der die LED Matrix ansteuert, General Purpose Input Output Controller und den Prozessor selber natürlich. Und natürlich haben wir Hoch-Clock-Management. Wie sintetisiert man nun etwas für dieses System-On-Chip? In diesem Fall haben wir einfach ein Mic-File und die relevanten Regeln sind auf der Slide. Zuerst benutzen wir Josis, um den Verilock-Code zu lesen, ihn zu synthetisieren und in ein Bliff-File zu schreiben. Dann rach eine PNR, welches das Bliff-File nimmt und die Placement bis an Bedingungen nimmt und eben das Text-File, das Textformat nimmt und das letzte, welches effektiv das Binary-File erzeugt, das in den FPG-AGD geladen werden kann. Was ihr auch seht, wenn ihr das Projekt anschaut, um die eigene Formware zu erstellen, gibt es auch, ich finde, auch so Micros bereits vorbereitet in dem Projekt. Und das gibt zum Beispiel das Tool-Ico-Rock, das auf dem Raspberry Pi läuft. Also zum Beispiel über SSH auf dem Raspberry Pi, dann nehmt ihr einfach eine Shell, um das Programm zu starten, aber es kann auch direkt als SSH-Befilm genommen werden. Und Ico-Rock liest immer von einer Eingabe und Ausgabe und dann könnt ihr das Binary zum Beispiel lesen und direkt weiterflaschen. Ihr könnt auch den On-Chip-Debagger benutzen, den ich erwähnt habe. Ihr könnt dir einfach an irgendeinen Internet vom FPG anhängen und dann zum Beispiel einen Trigger erstellen, der irgendetwas auslöst. Ihr könnt eine Clock definieren, welche Clock das ihr berücksichtigen wollt, welche ihr ignorieren wollt und in der Standard-Umgebung hat es ein Mic-Debug-Target, das sind dann direkt zum Raspberry Pi verbindet und dann könnt ihr das mit GTK-Wave zum Beispiel darstellen, was das Ding ein- und ausgibt. Irgendwas laufen lassen auf diesem SOC, das sieht dann so aus, wenn es zuerst startet, dann seht ihr den Bootloader, der zeigt das Bild der Floppy an, der Diskette, dann seht ihr ein paar Beispielprogramme, die benutzen die Textkonsole, um mit dem Bootloader zu reden und Texte auszugeben an den Bootloader und schreibt es dann ins S-Ram und führt es aus. Ja, ich denke, wir stellen euch das mal vor. So, so. Ja, something's left? Ja, zum Beispiel. Also, oops, make. Lasst uns einfach mal Bootresetten. Hm, das braucht zu lange. Das war eigentlich genau das, was ich vermeiden wollte. Großartig. Aha. Okay, also. Luckily I didn't suspect the software problem. Glücklicherweise habe ich kein Softwareproblem erwartet. Also, wir sehen jetzt... Lass mich kurz. Das kannst du ein bisschen kleiner machen. Und dann lass uns zum Beispiel hier hingehen. Und nun haben wir hoffentlich das Ganze gestartet oder irgendwas gestartet. Ich kann leider nicht weitermachen, weil ich es nicht hier hab. Also. Good. Okay. Also, wir haben diesen blinkenden Weihnachtsbaum. Lass uns zurück zum FPGA-Verzeihnis gehen und dann zum Debug. Wir haben jetzt 256 Debugzyklen. Jetzt möchte ich sie anzeigen lassen. Was ist nun? Das ist toll. Aha. Okay. Das ist beim zweiten Mal funktioniert's. Nun haben wir einige Debuginformation und mit dem Debugger kann man den Memory-Bus beobachten. Wie der Speicher besorgt wird. Wie mache ich? Ja. Okay, das sind alles Anweisungen, 256 Zyklen. Also, wir können sehen... Es ist also ein nicht triviales System. Und wir haben eine Toolchain, die dazu nutzwerden kann, Dinge mit realen Anwendungsmöglichkeiten zu haben. Applaus. Okay. Gut. Wie sieht es jetzt gegenüber den kommerzinellen Alternativen an? Es gibt Alternativen für Flows von Simplify Pro, dem SBT-Backend. Eines von den beiden Backends benutzt aber was vereinfachtet. Und wir vergleichen das jetzt mit dem PNR. Zuerst ein paar Bemerkungen. Ich benutze eine Version, die bereits ein Jahr alt ist. Der Grund ist, weil es mich so lange gebraucht hat, die Lizenz zu aktivieren. Und ich bin mir nicht sicher, ob die aktuelle Version sich genauso verhält. Und Jose ist nicht so gut, wenn es um die Optimierung von Logik geht. Aber Jose ist sehr gut, wenn es um Speicherverwendung geht. Und das ist auch der Fall hier in der Tabelle. Und bei Jose hatte ich 20 Blockraums. Das andere hat viel mehr Lockup-Tables benutzt, weil sie halt viele für viele Speicherfunktionen Lockup-Tables benutzt. Und komplexere Speicherer wurden halt so implementiert. Ich hoffe, kein Problem. Aber mit diesen 40 FPG-Aus braucht ihr ein Ausgaberegister. Und dann stelle das Ganze jetzt alles neu zu schreiben, sodass es auf allen drei FPG-Aus funktioniert. Ich habe das Ganze etwas verkürzt. Und das interne Blockraum ist jetzt künstlich verkleinert. Und das Ganze müsste jetzt in Logik implementiert werden. Also die gepackten Logikzellen ist, dass Jose etwas schlechter als die anderen zwei. Aber nicht so schlecht. Der Hauptgrund ist, dass Jose im Moment so aggressiv ist mit der Carry-Logik. Es benutzt fast 500 Carry-Zellen. Und die anderen Zellen brauchen nur um die 370. Und weil ich zu aggressiv bin, mit diesen zu instanzieren, dann und einen... Ja, ich bin einfach noch zu ineffizient damit. Und daher braucht es noch zu viel Logik am Schluss. Aber ich denke, es ist nicht so schlimm. Was interessant ist, ist, dass die Synthese ungefähr gleich lange dauert auf allen drei Getesteten. Aber die Implementationszeit ist viel kleiner mit Rachne. Also es ist viel schneller als die proprietären Backends. Viele von diesen... Viele von diesen ist wegen Constarterzeit, wenn die kommerziellen Tools zum Beispiel Laden und die Chip-Konfiguration laden oder so, weil sie Zeug vorkaschen. Und wenn man halt ein fast leeres Design hat, dann kann man ein Bitstream in eineinhalb Sekunden generieren. Und muss das Ganze eigentlich nicht laden. Ein paar Links, wenn... Ja, das schaut am besten auf den Link zu dieser Präsentation. Dann findet ihr das. Die Slides sind schon online dort. Und ich schau noch, ob ich sie auch online beim hier hochladen kann. Aber ja, eben. Clifford.it und Slash Papers, dann werden dir die Links finden. Die Leute, die daran gearbeitet haben an verschiedenen Teilen, die Liste ist halt unvollständig, weil es gibt viele Leute, die halt einen kleinen, aber sehr wichtigen Teil beigetragen haben. Das ist halt immer sehr willkommen, aber können halt nicht alle erwähnt werden. Und wir haben auch eine Assembly hier am 32C3. Also kommt uns doch besuchen zwischen der Blinken-Area, am ersten Stock, dort wo die Podcasts 3D-Drucker und das Ganze ist. Da sind wir. Wir haben auch mehr Apps auf diesem Ding, mit denen ihr rumspielen könnt. Und wir machen auch ein paar Workshops heute Morgen und übermorgen, jeweils um 19 Uhr. Also wenn ihr mit gerne diesen Flow selber ausprobieren möchtet, dann kommt doch bei uns vorbei und registriert euch für die Workshops. Falls ganz viele Leute das Ganze sehen würden wollen, würden wir noch mehr Workshops planen. Und ja, dieses Alkobord ist halt auch ein cooles Projekt, das ich denke, wäre halt schön, um euch zu demonstrieren, was das alles tun kann. Ja, danke. Wir haben etwa zehn Minuten für Fragen und Antworten. Wenn ihr Fragen an Clifford habt, dann kommt bitte zum Mikrofon und so, dass jeder euch hören kann, insbesondere der Leute auf dem Stream. Und wir fangen erst einmal den Signal-Engel-Fragen an. Es geht um partielle Rekonfigurationen von FPGAs. Hat die lettuce FPGA interne Rekonfiguration Sports. Kurze Antwort, nein. Man kann eine teilweise Rekonfiguration machen, aber es gibt ein internes Board namens Warm Boot, mit dem man die FPGAs schon reconfigurieren kann. Es hat bestimmte Pins und andere meinen Trigger-Pin, mit dem kann man bis zu vier Bitstreams ansprechen. Aber man kann es halt, man kann oder kann nicht, weiß ich nicht. Am Anfang hast du ein paar E-Mails erhalten wegen Intellektual Property. Das war die E-Mails nicht von lettuce, sondern vor einem random Typen, der das Halafakete gesehen hat. Und dann hat er das wohl sehr persönlich genommen und dachte, ich sei nach seiner Implement IP Intellektual Property her. Und es hat sich dann erledigt. Dann eine weitere Frage. Chris möchte wissen, ob die Fehlermeldungen verstandlich sind oder ja, noch kryptisch. Das ist eine gute Frage. Ich denke, für die meisten Stufen des Flows könnten die noch besser sein. Ich weiß, es ist für Josef, da gibt es noch viel Raum für Verbesserungen. Zum Beispiel, der Input ist im Fall gar kein Very Low Code, sondern man kriegt einfache Suntagserror in dem und dem Fall, weil das ist halt so, wie der Parse funktioniert. Ja, das Error-Reporting ist noch nicht so ausgereift. Im Normalfall kriegt ihr einen Fehler, den ihr zumindest mit etwas Erfahrung dann ausmerzen könnt. Danke, Mikrofon 5, bitte. Ich möchte wissen, ob das mehr über Ops VHDL unterstützt. Du hast das kurz erwähnt, aber gibt es einen Plan, ob und wann das unterstützt wird? Antwort Nein. Im Moment arbeite ich, also wird daran gearbeitet. Aber es gibt, glaube ich, noch keinen Code dafür. Es gibt zwei Ideen, wie man das unterstützen könnte. Eine ist, man könnte ein neues VHDL Frontend bauen. Der Student, der das machen möchte oder da interessiert würde, ist, würde es so machen. Die andere Möglichkeit ist, dass man einen Art VHDL nach Very Low Übersetzer nehmen würde. Das ist zum Beispiel ein Port von Icarus VHDL, der das machen könnte. Aber man müsste, es geht nicht für alle Files, aber für synthetisierbares VHDL geht es, kann man es in synthetisierbares VHDL übertragen. Vielleicht könnte man dieses Tool sich mal näher anschauen und daraus einen coolen Erkenntnis zu geben für unser Projekt. Aber für mich selber, ich bin eigentlich ganz zufrieden mit Very Low, daher habe ich kein Interesse. Mehr Fragen? Wie stark ist der Prozessor auf der Demo? So Register, Speicher. Es ist ein RISC-5 Prozessor. Wenn du davon noch nie gehört hast, es ist ein recht cooles Projekt. Das Ziel des Projekts ist, dass ein Open Source Prozessor oder eine Open Source Beschreibung ist. Unser Prozessor ist nicht so stark, weil er für Größe optimiert ist. Er hat etwa 2.000 Lockup-Tables auf Xilinx 7 Serien, welches eigentlich meine Lieblingsarchitektur ist. Da braucht es viel weniger Lockup-Tables. Also ja, es ist ein sehr kleiner Prozessor. Aber es braucht ca. 4 Zyklen für jede Instruktion. Aber man kann ihn bis zu 400 MHz schnell laufen lassen. Daher gleicht sich das ein bisschen wieder raus. RISC-5 ist ein Instruktionsset, das halt viele General Purpose Register hat. Also 31 Register hat, ja, 0. Wir haben immer noch etwas Zeit. Wir machen mit dem Mikrofon 4 weiter. Ich finde es toll, dass es so ein Projekt gibt für das Offen und frei ist und auch in der Schule eingesetzt wird. Von der Spezifikation des Prozessor-Pistolen-Output-Pins, dass das alles verfügbar ist und das alles dann zu verstehen, das auch zu lehren. Das ist echt cool. Du hast auch erwähnt, dass Verifikation ein Interessepunkt von dir ist. Und dadurch den Input und den Output verglichen hast, kann man aber auch bei größeren Sachen das Ganze vergleichen. Es gibt Verifikationssachen, die ich auf meinem Prozessor laufen lassen kann. Aber allgemein sind solche Prozessoren schwierig, vom Mail zu verifizieren. Aber es gibt einige Dinge, die ich tu. Also ich habe auch erwähnt, es gibt Configurables, wo man Features an- und ausschalten kann. Und wenn ich zwei Mengen von Features habe, dann habe ich schon mehr Anweisungen, also nur Reihen von Anweisungen an, die ich versuche halt zu schauen, dass diese Teile halt immer das gleiche verhalten haben. Eine Bitte an die Leute, die gerade rein oder rauskommen in den Saal, bitte, seid leise. Ich möchte Danke sagen für die Arbeit für dieses tolle Projekt. Das ist equivalent zur ersten Version von der GNU Compiler Collection. Vielen Dank. Okay, dann bleiben wir beim Mikrofon 4. Großes Projekt, aber was ist mit Zeitvalidation, also Timingvalidation? Also momentan, ist keiner unserer Prozesse wirklich von der Zeit getrieben. Momentan ist es besser, denn die Struktur ... Also im Moment haben wir noch nicht so viele zeitkritische Sachen und es ist, wir arbeiten mehr an Modellen. Das ist fast fertig, aber es gibt noch ein paar technische Schwierigkeiten. Ich denke, es ist jetzt nicht der richtige Moment, um das Ganze zu diskutieren, kommt auch bei uns in der Assembly vorbei. Nochmals eine Frage von den Leuten, die leider nicht da sein können. Was denkt denn Lettis von eurem Open Source Flow? Ich weiß es nicht. Also wenn jemand von Lettis hier ist, dann schaut euch vorbei. Ich würde gerne etwas mehr von Ihnen erfahren, sobald ich einen Timing-Flow habe. Das fehlt im Moment noch. Aber aus meiner Erfahrung, wenn man so etwas einem kommerziellen Anbieter sagt, dann glauben Sie, das meistens zuerst nicht und daher möchte ich zuerst einen kompletten Flow haben und mich dann erst bei Ihnen melden. Wir haben noch zwei Minuten. Also bitte kurze und präzise Fragen. Ist es möglich, ein unabhängiges FPGA zu entwickeln, das mit dem Bitformat kompatibel wäre und das Ganze so zu benutzen? Ich denke, es wäre möglich, aber ... Es wäre halt nicht viel schwieriger, effektiv von Grund aus ein eigenes FPGA zu erstellen und dann diese Tools darauf anzupassen. Es gibt zum Beispiel im Moment Projekte, wo man über solche Dinge nachdenkt, das eigene FPGA zu erstellen. Für mich ist es natürlich interessant, wenn so etwas gehen würde. Dann könnte ich zum Beispiel zeigen, meine Toolchain kann auch tatsächlich was, auch auf dem anderen FPGA. Vor zehn Jahren habe ich das schon mal probiert und Sie haben gesagt, das geht nicht, weil man diese Open-Source-Toolchain nicht hat. Jetzt haben wir eine, jetzt können wir mal schauen, ob es dann gehen würde. Also die letzte Frage. Wäre es möglich, um die Arbeit zu benutzen, um andere Geräte zu reversalenginieren? Also ich habe an die Open-HDL-Designs angeschaut. Diese kann man mit Veriloc bearbeiten. Sorry, nicht ganz verstanden. Das würde aber ein paar Änderungen ... Es würde ein paar Änderungen brauchen, aber es sollte möglich sein für Oberon, wenn ich es sicherlich verstanden habe. Aber wir haben keine Zeit mehr von dem her. Du hast deine Kontaktdetails uns gesagt. Also die Leute hier und auch die Leute, die nicht da sind, können sich bei dir melden. Danke Clifford für den Talk.