 Gut, soll anfangen? Gut, dann fange ich an. Hallo, mein Name ist Clifford Wolf, ich bin Autor von JOSUS und wir haben jetzt einen zwei Stunden Marathon vor uns, wo ich über Vereloxynthese mit JOSUS reden werde, aber auch über formale Verifikationsmethoden mit JOSUS. Gut, das ist das, worüber wir reden werden. Also ich werde zuerst ein bisschen eine Einführung geben in das ganze Themengebiet, falls sich jemand noch nicht wirklich auskennt, wie HDLs funktionieren und wie heutzutage digitale Schaltungen entworfen werden. Und dann werden wir uns diesen zwei großen Blöcken zu widmen. Zunächst werde ich einige Synthese-Flows vorstellen, die JOSUS verwenden und werde dort irgendwie versuchen herzuzeigen, wo sind die Unterschiede, vor allem aber wo sind die Gemeinsamkeiten werden wir feststellen, man kann mit JOSUS eigentlich relativ flexibel sein, viele verschiedene Architekturen als Target haben. Und das schaut eigentlich immer sehr ähnlich, sehr gleich aus, das was man tun muss dafür. An dem zweiten Block schauen wir uns dann die formale Verifikation an, vielleicht nicht ganz so populär wie die Synthese, also wenn ich am Kongress über formale Verifikation gesprochen hätte, hätten sie mir wahrscheinlich nicht in einen Einzelraum gesteckt, aber ich persönlich von mir ist das ein ganz wichtiges Thema, die formale Verifikation. Unter anderem oder nicht zuletzt auch deswegen, weil es in der Synthese zumindest gratis Tools gibt. Also da haben wir, weiß ich, von Xylings und Altiera für FPG As, gibt es Tools, die zumindest nichts kosten, also es ist nicht open so aus, aber wenn jemand einfach nochmal lernen möchte, wie man damit umgeht, dann gibt es da die Möglichkeit. Auf der formalen Verifikation schaut die Sache anders aus, da kenne ich eigentlich kein gratis Tool von irgendeinem Hersteller und meines Wissens nach ist JOSUS da im Augenblick die einzige Möglichkeit interessante Dinge zu machen, ohne irgendwie gleich mehrere 100.000 Euro für Lizenzen in die Hand nehmen zu müssen. Okay, kommen wir zu diesem ersten Teil, der Einführung zu dem Überblick. Also da rede ich jetzt mal schnell drüber, was Verilag eigentlich ist und was Hardware-Beschreibungen in Sprachen sind, was ein Synthesefloh ist, dann was bedeutet Verifikation, Simulation und formale Verifikation und welche Open Source Tools gibt es da im Augenblick. Und dann natürlich zuletzt die Überleitung zu JOSUS. So was ist Verilag? Also Verilag ist eine Hardware-Beschreibung Sprache, eine HDL, das heißt das ist eine Computersprache, so wie eine Programmiersprache eine Computersprache ist, aber diese Computersprache, die Texte, die in dieser Computersprache geschrieben sind, beschreiben kein Programm, sondern sie beschreiben eine Schaltung. Es gibt zwei sehr wichtige HDLs, nämlich VHDL und Verilag und manchmal hört man von Leuten die Theorie, dass Verilag HDL, wie es dann oft genannt wird, dass das VHDL wäre, in eines sind zwei verschiedene Sprachen und wie das so ist, wenn es verschiedene Sprachen gibt, dann gibt es natürlich die Religionskriege zwischen den Angehörigen dieser Sprachen und in diesem Religionskrieg stehe ich persönlich auf der Verilag Front, aber ich kann mich gut vertragen mit VHDL-Leuten, also so ist es nicht. Es gibt auch noch System-Verilag und System-Verilag ist im Grunde ein starker weiteres Verilag, wo einfach viele zusätzliche Features eingebaut wurden. Ursprünglich wurden HDLs verwendet für Tests und für Dokumentationen von Schaltungen, nicht wirklich für die Erzeugung der Schaltung selber, für das Design. Das kam dann erst später, wenn ich da schon so eine Sprache habe und relativ gut verstehe, wie eigentlich der Prozess ist, um von diesem Text in dieser HDL-Sprache für eine Schaltung zu kommen, warum kann ich das nicht automatisieren und dann Programme schreiben, dass das für mich tut, also das ist der historisch Hintergrund. Und viele Dinge, die sehr komisch sind mit den HDLs, wenn man dann irgendwie lernt, wie die dunklen Ecken des Sprachstandards so ausschauen, also die komischen Dinge, die sind meistens durch diese Historie erklärbar, dass das eben ursprünglich gar nicht gedacht war als eine Sprache, mit der man jetzt wirklich das Design macht, sondern eine Sprache, mit der man mal Dokumentation und Test macht. Und ursprünglich hat man dann händisch versucht, eine Schaltung zu machen, die dem, was in diesem HDL-File beschrieben wird, entspricht. Und später hat man dann Programme gemacht dafür. So, und diese Konversion, was das Programm macht, diese Umwandlung von einem HDL-File in eine Schaltung, das nennt man eben die HDL-Synthese. Gut, wie schaut sowas aus? Wie schaut so ein VR-Lock-Text aus? Da habe ich hier ein kleines Beispiel gemacht. Wir haben... Ah, gut. Das wird schwierig. Ich versuche zu beschreiben, ich versuche nicht zu zeigen. Wir haben zuerst, wir haben hier ein Modul, das Modul heißt Exempel 0, also quasi eine Schaltung, Modul heißt im Grunde eine Schaltung oder auch Teilschaltung, weil man hierarchische Designs machen kann, wo man andere Module als Untermodule in einem Modul verwendet. Und dieses Modul hier hat in Summe 6 Pins, nämlich ein Input-Pin, der Clock ist, und dann 5 Output-Pins, der heißt Grey Counter, quasi Grey Counter 0 bis Grey Counter 4, werden diese 5 Pins. Dann habe ich hier einen Parameter, quasi eine Konstante, die ich definiere und 2 Register, nämlich ein, ich nenne sich ein Fast-Counter und Slow-Counter, und in dem Fall zählt mit jedem Takt der Fast-Counter hoch, bis er bei diesem Prescalerwert angelangt ist, und dann wird Fast-Counter wieder auf 0 zurückgesetzt und das Slow-Counter wieder um 1 inkrementiert. Das heißt, alle 100 Zyklen, weil der lokal Param Prescaler auf 100 ist, wird mein Slow-Counter um 1 hochzählen. Das ist das, was dieses Programm macht. Also, mein Ausgang ist aber ein Grey Counter, das heißt, wir müssen diese binäre Zählen noch in ein Grey-Code umwandeln, und Grey-Code umwandeln geht eben relativ einfach, indem ich einen Wert nehme und für X oder R mit dem rechtsgeschifteten Variante, das ist diese untere Zeile, wo ich diesen Grey-Counter-Ausgang definiere. Also, so schreibt man Schaltungen, so schreibt man CPUs. Und dann kommt ein Tool daher und macht das draus. Und das ist jetzt genau die equivalente Schaltung. Das hier ist eine Coarscreen-Schaltung. Coarscreen heißt in dem Fall nur, dass wir nicht Einbit-Signale anschauen und Gatter, die irgendwie Einbit-Signale nehmen und was anderes machen, sondern wir haben hier größere Funktionsblöcke, wie Adir und Vergleiche von ganzen Vektoren und diese Dingen. Gut, also das ist der Prozess, den wir uns anschauen. Wir nehmen einen Text und wir machen draus eine Schaltung. Und dann haben wir eine Schaltung, die in dem Fall hier ein bisschen abstrakt ist, weil wir haben eben hier große Blöcke, wie zum Beispiel ein Adir. Aber man kann sich dann, glaube ich, schon vorstellen, wenn ich mal an dem Punkt bin, dann ist es nicht so schwierig, jetzt dann den Adir zum Beispiel zu ersetzen, durch etwas, was einzelne Gatter verwendet, um funktional genau das Gleiche zu machen. Wenn ich so ein Diagramm erzeugen möchte, mit joses, dann brauche ich nur joses-p und dann kann man ein Skript auf der Kommandezeile angeben, als Argument, und dann das, was da unten steht, prepstrich.show-stretch. Das ist das Programm, das ich verwendet habe, also das joses Skript, das ich verwendet habe und aus dem V-Relog aus der letzten Slide diese Schaltung hier zu machen. Gut, also das ist jetzt HDL-Synthese. Was ist jetzt ein HDL-Synthese Flow? Das ist ein Wort, das man doch recht häufig hört von den ASIC-Leuten und von den FPGA-Leuten, dass sie von Flows reden. Und Flow, das ist nichts anderes, ist eine Reihe von Tools hintereinander geschalten, die dann nicht nur die Synthese machen, sondern wirklich diesen Text, dieses V-Relog-File umwandeln, auf was auch immer ich brauche, auf meiner Zielhardware, das kann ein FPGA-Bitstream sein, das kann ein ASIC-Mask layout sein, was auch immer. Und in der Regel hat man eben so eine Liste von Programmen, wie sie hier stehen, dass man ein Synthese-Tool hat, das nimmt dieses HDL-File und macht daraus eine solche Netzliste. Und die Netzliste ist eben wieder im Grunde eine Tabelle, wo drinnen steht, welche Zellen soll diese Schaltung haben und wie sind diese Zellen miteinander verbunden, aber ohne irgendeine Geometrie-Information. Und dann kommt im nächsten Schritt da so ein Deplacer und der nimmt diese Netzliste und überlegt sich, wo kommen die einzelnen Zellen und die Kabel-Länge haben. Und der muss natürlich dafür berücksichtigen, wie diese Zellen verbunden sind, weil ich möchte einerseits mal die Gesamtkabel-Länge auf meinem Chip die Wire-Length reduzieren, weil ich einfach nicht unendlich viele Routing-Ressourcen habe. Aber dann will ich auch Routing-Congestions vermeiden. Also manchmal gibt es Fälle, da habe ich Dinge, die kann ich sehr nahe zusammen tun und habe ich sehr, sehr kurze Kabel, das sieht aus mit der Anzahl der Metall-Ebernen, die ich habe. Und wenn ich diese Teil der Schaltung ein bisschen weiter auseinander tue und andere Dinge in die Zwischenräume schiebe, dann kann es sein, dass ich meinen Chip besser rauten kann. Das heißt, minimieren der Wire-Länge ist sozusagen nicht das einzige Optimierungsziel an dieser Stelle. Und dann kommt ein Router und der Router nimmt eben dieses Placement, der weiß jetzt, wo welche Zelle ist, er weiß, welche Zelle mit welcher verbunden gehört und der Router entscheidet dann, ob die Wires wirklich sind auf meinem Chip. Wenn ich das habe, dann bin ich eigentlich schon fast fertig. Mich interessiert dann aber in der Regel noch, wie schnell meine Schaltung jetzt tatsächlich ist. Das heißt, ich brauche dann ein Timing-Analyser-Tool. Das nimmt sich diese Informationen von Placer und Router und sagt dann, das Design kann mit so und so viel hundert Megahertz laufen. Und am Schluss brauche ich noch in einem Programm, das die Produktion-Files erzeugt. Also das Bitstream für meinen FPGA oder wirklich die Masken-Files in diesem Prozess. Und so etwas nennt man dann ein Synthese Flow. Also in der Regel, wenn ich jetzt ein Designer bin und ich will einen Chip bauen, dann gehe ich nicht zu einem Hersteller und sage, verkaufe mir ein Synthese Tool und zum anderen Hersteller und sage, verkaufe meinen Placer und zum dritten Hersteller und sage, verkaufe meinen Router, sondern ich kaufe ein Paket, wo das Tools schon alle fertig miteinander integriert sind. Und Josus ist halt mein Synthese Tool. Das heißt, das ist auf dieser Aufzählung hier nur die erste Zeile. Wir haben jetzt einen Open Source Flow. Braucht man dann eben auch noch die anderen Komponenten. Für den 1,40 FPGA haben wir das eben geschafft letztes Jahr. Ich werde das dann kurz auch später noch im Vortrag darüber reden. Gut, also jetzt wissen wir, was ein Flow ist. Wir wissen, wie solche Schaltungen gemacht werden. Ein wichtiger Punkt ist aber immer noch die Verifikation. Also bei FPGAs kann man Sachen ausprobieren und vor allem Leute, die neu beim Spielen sind, die machen gerne – ich würde sagen, es ist ein Fehler – dass sie einfach Schaltungen machen, einen FPGA einspielen und schauen, ob es funktioniert und nicht simulieren. Und ein großer Prozentsatz der Pakreports, die ich zu Josus komme, sind Leute, die auf diese Art und Weise entwickeln, sich nicht erklären können, warum ihre Schalter nicht funktioniert und das muss ein Paket in Josus sein. Also bitte um verreifizieren, ist einfach nur der Prozess herauszufinden, ob meine Schaltung sich gemäß der Spezifikation verheilt. Da gibt es immer noch die andere Probleme herauszufinden, ob die Spezifikation wirklich das spezifiziert, was ich mir vom Big Picture her überlege. Das ist ein eigenes Problem, aber bei Verreifikation ist die Frage entspricht meine Schaltung der Spezifikation. Und ich kann simulieren, das ist das Einfachere, dass ich meinen Design nehme und dann schreibe ich eine Test-Bansch, quasi ein kleines Programm, das bedient die Eingänge meiner Schaltung, schaut ob bei den Ausgängern das Richtige rauskommt. Meistens schreibt man diese Test-Bansches in der gleichen HDL, in der man auch das Design schreibt. Und dafür gibt es dann immer diesen nicht synthesierbaren Subset von der HDL, wo die HDL mehr ausschaut, wenn ich besprache. Und weniger wird eine harte Beschreibungssprache. Und das sind die Teile für die Test-Bansches. Ein Problem ist, dass so wie ich eine halbwegs interessante Schaltung hab, dass ich immer nur einen ganz, ganz kleinen Bruchteil von dem gesamten Raum aller möglichen Inputs simulieren kann. Und man denkt sich, na ja, wenn ich da einen Dividierer zum Beispiel gebaut hab, und ich probiere einfach zufällig 10.000 Zahlen zu dividieren, dann wird, und das passt bei allen 10.000, dann wird das schon passen, was daraus kommt. Erinnert sich jemand an den Pentium F-Diff-Bug? Das war genau, das war genau so was. Da war ein der Floating-Point ohne der Tabelle. Die Tabelle wurde irgendwie zum Dividieren verwendet, was weiß da nicht, wie der intern aufgebaut ist. Aber offenbar war ein Tabelleneintrag falsch. Und die 10.000 zufälligen Zahlenwerte, also daraus natürlich jetzt auch eine Hausnummer, die ich hatte, bei der Unzahl von Werten, die sie sicherlich versucht haben, zu dividieren in ihren Test-Bentures, haben die einfach nie diese eine Zeile in der Tabelle getroffen. Und damit haben die den Chip gemacht und nie gewusst, dass der Chip bei ihren Fehler hat, bis dann irgendjemand in einem Accel-Spreadsheet die falschen Zahlen dividieren wollte und festgestellt hat, na ja, da kommt dir was Falsches raus. Also das heißt, wir können mit Simulation nicht alles erschlagen. Trotzdem sollten wir immer simulieren. Also Simulation sagt uns schon mal sehr, sehr viel. Aber wir sollten zusätzlich zu Simulation auch noch etwas anderes hinüberlegen. Das ist die formale Verifikation. Und in der formalen Verifikation probiere ich vereinfacht gesagt alle Möglichkeiten aus. Aber natürlich kann ich nicht alle Möglichkeiten ausprobieren. Wenn ich irgendwie eine Dividiere habe, der Dividiert mit allen Möglichkeiten ausprobieren werde ich alt. Aber wenn ich jetzt selber mit der Hand, mit mathematischen Mitteln beweisen wollte, dass der Dividierer funktioniert, dann werde ich wahrscheinlich viele Shortcuts finden. Wo ich irgendwie sagen kann, durch dieses Argument kann ich sagen, für die Gruppe von Inputs wird dieser Fehler, den ich suche, nicht auftreten, was auch immer. Und hurra, es gibt Programme, die können sich solche formalen Beschreibungen in Systemen anschauen und können Beweise in denen führen und können das in einer Art und Weise machen, sodass zwar niemand garantieren kann, dass es nicht exponentiell lange dauert, aber in der Regel dauert es nicht exponentiell lange. Außer man macht irgendwelche Dinge, die genau darauf abziehen, diese Programme an die Grenzen zu treiben. Also klassische Sachen, während zum Beispiel Kryptografiekores. Dass so ein Programm könnte theoretisch auch jeden hess sprechen. Aber er braucht gut Blut vor, was probieren kann. Aber für ganz normale Schaltungen funktioniert das sehr gut, dass man hier formal verifiziert. Also welche Tools habe ich jetzt um all das zu tun. Und natürlich viel wichtiger welche Open Source Tools habe ich dafür. Und da habe ich mal diese 4 aufgezählt, weil ich glaube, dass das irgendwie die wichtigsten sind, die man in seinen Baukasten quasi hat. Das wäre einerseits mal Icarus Verelog. Icarus Verelog ist ein Simulator. Und zwar ist es ein Simulator, der auf einem Interpreter aufbaut. Also da gibt es einen Übersetzungsschritt. Aber der Übersetzungsschritt erzeugt dann eine Beschreibungsdatei, die von dem Interpreter geladen wird. Und das heißt, dass mein Design, meine Test-Mensch sehr schnell übersetzt. Weil ich muss nicht wirklich kompilieren, ich muss nur diese Datenstruktur für den Interpreter aufbauen, aber eher langsam ausführt. Am anderen Ende vom Spektrum gibt es Verelator, das ist auch ein Simulator. Das ist aber ein Simulator, der das Design nimmt und nach C++-Code übersetzt und dann durch ein C++-Compiler durchwirft. Und das braucht einige Zeit zum übersetzen, weil ich da auch einmal ein C++-Compiler dazwischen habe. Aber es ist viel schneller beim Ausführen. Ein Nachteil von Verelator noch, je nachdem, wo man steht, kann das vielleicht auch ein Vorteil sein. Die Test-Mensch, die kann man nicht hinter in Verelog schreiben, die müssen ausgeschrieben werden. Und Verelator versteht nur das synthesefähige Subset von Verelog. Das heißt, je nachdem, welche Art von Design ich habe und welche Art von Simulation ich laufen lassen möchte, ist das ein oder andere Programm besser. Wenn ich jetzt irgendwie einen kleinen Core habe und ich will irgendwie nur 1000 Tackzyklen simulieren, weil das reicht mir schon, um die Information zu gewinnen, die ich brauche, dann wird das wahrscheinlich mit Icarus Verelog viel einfacher und unproblematischer gehen. Aber wenn ich jetzt ein komplettes System eine Chip habe und ich will schauen, ob der Linux-Karren erfolgreich bootet, dann werde ich alt werden mit Icarus Verelog und das macht es hin, das mit Verelator zu machen. Das Nette an Verelator ist, man wird nicht mehr wirklich schneller, wenn man auf kommerzielle Tools umsteigt. Also damit wirbt quasi auch Verelator auf der Homepage, zählen so irgendwie die bekanntesten, schnellen, kommerziellen Simulations-Tools auf. Die können dann noch andere Sachen, die können dann auch VHDL und vielleicht andere Features, aber von der Geschwindigkeit her ist Verelator besser. Das ist ganz nett, dass man hier das Spektrum quasi bis zum Ende gehen kann und bei Open Source bleibt. So, wenn ich jetzt diese Simulationen gemacht habe und das sind gelaufen, entweder habe ich in meiner Testbench einfach Print Statements drinnen und dann lese ich den Text und das sagt irgendwie, alles okay. Aber wenn meine Testbench zum Beispiel nicht sagt alles okay, dann kann ich entweder anfangen, mehr Prinzen Statements in meine Testbench einzubauen oder ich will einfach die Wellenformen sehen, zu welchem Taktzügel, welche Leitung hi, welche Leitung low und dann brauche ich einen Viewer dafür und dieser Viewer ist GTK Wave. Also, ich möchte jetzt GTK Wave gar nicht in den Himmel loben, weil es ist kein super tolles Programm, aber es tut was man braucht und das ist wahrscheinlich das möglicherweise eines der besten, das im Augenblick gibt im Open Source umfällt. Aber wenn jemand sagt, er will irgendwie ein Jahr seines Lebens investieren, um sowas zu schreiben, dann glaube ich, könnte man was machen, was viel, viel besser wäre als GTK Wave. Also, ich weiß jemand, Motivation braucht für ein Projekt. So, und last but not least, natürlich Jossos, mein Tool und dort können wir Synthese machen und formale Verifikation und das Tool ist sehr, sehr modular, wie wir es bitte noch sehen werden. Also, wenn man jetzt irgendwie was anderes machen möchte und nicht formale Verifikation, sondern ein drittes Ding, dann wird man das wahrscheinlich auch ganz gut machen können mit Jossos, solange man nur das synthesefähige Subset von Verhealung braucht. Das ist irgendwie die Einschränkung. Gut. Also, wie verwende ich Jossos, wenn Jossos so toll ist, wenn Jossos so normal ist, wie schaut das aus? Jossos wird von Skrips gesteuert und die, das sind einfach Befehle, die nach ausgeführt werden. Es ist Skrips in relativ Fahrt, weil es keine Kontrollstrukturen gibt. Ich kann keine Schleifen bauen, keine If-Statements, sondern nur ein Kochrezept, quasi welche Dinge sollen hintereinander ausgeführt werden. Und da haben wir ein kleines Exampleskript. Wir machen zuerst, wir lesen das Design, also es gibt viele Befehle, die mit Weed Anderscore beginnen, das sind alles Frontlines und hier haben wir offenbar drei Wärreloktateien, die irgendwie mein Design sind und dann rufen wir den magischen Befehl sündauf, der synthetisiert dieses Design, dem sagen wir noch ein Topmodul. Und dann haben wir in dem Fall, weil das ein ASIC-Prozesse ist, offenbar noch zwei weitere Befehle, die das auf ein Liberty-File mapten, dieses Design, was wir dann dort haben. Also Liberty ist einfach in der Teilformat, in dem ASIC-Zelllibris beschrieben werden. Die FF-Flipmap mapt die Flipflops und ABC mapt die Logik. Das heißt, in dem Fall können wir im Logik-Mapping nicht mehr re-timen, es gibt ein bisschen komplizierteres Skrips, der kann und dann auch re-timing machen und Registerbalancing. Ja, und ganz am Schluss das Write-Ediff, weil wir wollen ein Ediff-File schreiben, Ediff ist ein furchtbarer Teilformat, aber es ist sehr beliebt in der Industrie, sehr viele Tools gibt es, die Ediff lesen können. Soweit, schaut das nicht viel anders aus als die Skrips, die man sieht, wenn man ein kommerzielles für diese Tools verwendet. Die schauen natürlich aus, da hat man auch so, wie wäre Logiteil und dann irgendein Synth-Design oder was auch immer und dann schreibt man am Schluss die Resultate. Der große Unterschied hier ist, was dieser Synth-Befilm in dem Fall macht, dieser magische Befehle, das Design synthetisiert. Also wenn man help-synth eingibt, dann kriegt man natürlich eine Help-Message, was dieser Synth-Befilm macht und unter anderem kriegt man diese Information her und das ist die Befehle, die der Synth-Befilm ausführt. Also wir könnten quasi das Skript von vorher nehmen und diesen Synth-Befilm einfach ersetzen durch diese lange Liste von Befehlen. Und jeder von diesen Befehlen macht irgendwas halbwegs überschaubares. Manche dieser Befehle machen ein bisschen weniger überschaubare Dinge, wie zum Beispiel Proc, macht ein weniger überschaubares Ding, ich will gleich genau darauf eingehen, aber das ist nicht so tragisch, weil Proc ist selber nur wieder eine Liste von anderen Befehlen. Das heißt, die Grundidee ist hier, ich habe relativ einfache Passes, die einfache Transformationen auf meinem Design ausführen und wenn ich die in der richtigen Reihenfolge hintereinander ausführe, dann komme ich von meinem Verelock-Design zu, was auch immer mein Ziel ist. Und weil die Überlegung ist, dass diese Passes immer relativ überschaubare Funktionsblöcke sind, kann ich einfach diese Help-Message eingehen und kann relativ gut nachvollziehen, dass der Synth-Befil, diese magische Aufgabe löst, dass er da ein Design synthetisiert. Und natürlich, wenn ich jetzt meinen eigenen Synth-Befil schreiben möchte, der irgendwas anders macht, dann kann ich mich relativ leicht an dem orientieren. Gut. Also, das ist die Einführung. Jetzt wissen wir irgendwie alle so ein bisschen, was über Hardware-Design wird, modernes digitales Design in HDLs, haben ein Grundidee, wie joses so funktioniert, dass wir kommen zu dem zweiten Block, und der zweite Block gesehen, wir schauen uns mehrere Synthese-Flows an, was kann man so machen auf der Synthese-Seite mit joses. Also, wir haben einen Talker am 32, oh, so alt, am 32 C3, oder auf der Fostem gesehen hat, er kennt zum Beispiel dieses Slide, das war das zweite Slide. Da gab es diese Intro nicht, diese Einführung. Ja, das ist der iStorm Flow, Project iStorm, ist irgendwie ein Projekt, das wir letztes Jahr gemacht haben, dass wir den Lattice i40 FPGA hergenommen haben, oder eigentlich die FPGA-Serie und den Speedstream-Format, von den wir reverse-engineered haben, weil das mit den Warten auf der FPGA hersteller, dass die das dokumentieren, und dass wir so erst Tools machen können, das hat irgendwie nicht so funktioniert. Also, also halt suchen. Im Augenblick haben wir von den i40 LP und HX-Serie 1K, 4K und 8K, die sind vollständig dokumentiert. Da glauben wir zu jedem, bitte, dass eine Funktion hat, zu wissen, welche Funktion es hat. Wobei der 4K war easy, es gibt nämlich kein 4K die, das ist ein 8K die Limitierung, die ist in der Software. Also nicht in unsere Software, nur in der Software von Lattice. Und natürlich, wenn ich jetzt diese Dokumentation habe zu den FPGA, dann ist das irgendwie sinnvoll, als nächsten Schritt einen FPGA Flow zu machen, der komplett Open Source ist. Und das ist eben dieser Ice-Darm-Flow. Und das ist das Bild, wie der Ice-Darm-Flow ausschaut, wir haben WRLOX-Sourcen, wir haben ein Syntheskript, das geht in Josus rein, erzeugt ein Blifffile. Erachne.pna, ist das Play-Send-Rout-Tool. Das liest das Blifffile, zusätzliche Constrainsfile, kann auch ein Skript haben, aber meistens verwendet man das Skript nicht. Und das erzeugt dann so ein Ice-Darm-TXT-File. Und das geht dann durch den Programm ins Ice-Pack durch und das erzeugt dann die Binea. Die Binea-Bitstream-Datei, die man in den FPGA einspielen muss. Das ist der Flow. Gut, die Josus-Seite davon schaut relativ einfach aus. Wir machen ein Skript, wir schreiben WRLOX, wo wir unsere ganzen Designsourcen lesen und dann gibt es den einen magischen Befehl, Synth, Anderscore, Iceforte und dem sage ich, was ist das Top-Design und welches Blifffile soll er schreiben. Und natürlich kann ich schreiben, Helpsynth, Iceforte und dann sehe ich die ganze Liste von Befehlen, die da verwendet werden. Das ist alles sehr transparent, was da passiert. Der File-Library, die wir da verwenden für diese Blifter-Datei, die wir schreiben, ist kompatibel mit der Iceforte-Technologie-Library von Lattice. Also man kann auch die gleichen Primitives instanzieren, dass es vergleichsweise einfach Designs zu migrieren von den Lattice-Tools auf den Ice-Tone Flow. Und hier unten so schaut eben so ein Blifffile aus, wer das Blifter-Datei-Format nicht kennt, so ein ASC-File-Format Zeilen passiert, in dem man Netz-Listen und Logik-Funktionen beschreiben kann. Leider hat das ein paar Freiheitsgraden nicht, die wir gerne hätten, zum Beispiel für die Lutz. Möcht man halt irgendwie sagen, auf was soll die Lutz initialisiert sein, was soll die Look-Up-Table sein, die die Lutz implementiert, da braucht man eine Art Parameter, so was gibt es im Bliff nicht, also haben wir da eine Art Parameter-Statement erfunden. Für Lutz könnte man auch immer machen, dass man das in den Namen hinein kodiert und dann hat man da eine SB anders, Kualut 4 anders, K0, 0, 0, 0, 0, 1, 1, was halt da steht. Aber wenn man dann mal eine PLL-Zeile hat, die irgendwie, weiß ich nicht, sicherlich ihre 10 Parameter mindestens hat, dann wird das irgendwie mühsam, das in den Namen zu kodieren, ich glaube, das ist besser. Gut, und der ganze Flow, gesagt, Josus ist nur der erste Schritt, der Josus verwendet für die Synthese im ersten Abschnitt, dann erachne PLA-Aufruft, das liest jetzt so eine Blifter-Teile, das liest ein physischem Strain-File, in dem drinnen steht, welcher I.O.-Name auf welchem Pin am Chip passt und so. Und der schreibt eben so ein ASC-File und dann kommt Icepack, der konviertet das ASC-File nach binary und dann kommt Iceproc, das programmiertes FPGA-Board. Ja, also das ist der I.Stone Flow. Wir haben relativ viel Aufmerksamkeit bekommen mit dem I.Stone Flow, einige Mal auf Hecke.de im letzten Jahr. Das heißt, ich habe relativ viele Online-Diskussionen beobachten können um diesen Flow. Meistens habe ich mich selber zurückgehalten, sondern einfach nur gelesen. Aber was dann immer zuerst kommt ist, aber ja, das sind ja nur diese kleinen Probleme, was da keine wirklich interessanten Probleme lösen. Also haben wir zum Kongress einen etwas umfangreicheren System-on-a-Chip-Design mit einem 32-bit RISC-5-Prozess drinnen und dann kann man mit dem GCC auf der Workstation Code übersetzen und dann auf System-on-a-Chip laufen lassen. Und damit haben wir hoffentlich demonstriert, dass sowohl unser Flow durchaus in der Lage ist, auch echte Dinge zu machen, Real-World-Anwendungen zu implementieren und auch, dass diese Chips, wenn man weiß, was man tut, groß genug sind, um da interessante Dinge zu machen. Also dieses komplette System-on-a-Chip hat nur ungefähr 4.000-8.000 Lutz auf dem FPGA verwendet. Also da ist noch genügend Ressourcen frei um einen zweiten System-on-a-Chip daneben auf dem gleichen Chip zu tun. Was weiß ich? So eine angeblich Real-World-Anwendung hat und so ein Flow und es gibt einen kommerziellen Flow, der das gleiche Architektur-Tagetäter da muss man natürlich ein Vergleich machen. Also wir vergleichen hier 2 kommerzielle Flows für die I-40 FPG-Aus immer mit dem SBT Back-End von Lattice, aber einmal mit Simplify Pro und diese Fronten und einmal mit Lattice LSE der Lattice Synthesis Engine und wirklich interessant ist eigentlich nur die erste Zeile die Packed Logic Cells man kann dann drunter schauen wie viel Lutz und wie viele Flip Flops aber wenn ich irgendwie weniger Lutz und weniger Flip Flops brauche, also das andere Tool, aber ich kann es ja nicht in einer Art und Weise in Logic Cells packen, dass ich am Schluss weniger Logic Cells brauche, dann hat das Tool gewonnen dass mehr Lutz braucht. Und das sehen wir eigentlich hier in den beiden rechten Spalten im Vergleich zwischen Simplify Pro und dem Lattice LSE schon Simplify Pro braucht weniger Lutz und das Lattice LSE braucht weniger Packed Logic Cells das heißt, am Chip ist das Lattice LSE eigentlich besser. Das schlechteste von den drei Tools sind wir, aber wir sehen es ist irgendwie nicht nicht die Welt, ich brauche nicht doppelt so viele Ressourcen wie die kommerziellen Tools und ich sage immer, für die meisten Anwendungen wird das wahrscheinlich ganz gut sein, weil gerade bei so einem FPG-Aus dem I-40 würde man vielleicht schnell mal den größten Chip nehmen und die Ressourcen übrig haben. Und ich sage immer, wenn man wirklich ein Design hat wo man den 8K bis zum letzten Lutz auslasten möchte und die Joses ist nicht gut genug dann ist man hochmotiviert, die Joses zu verbessern das ist ein Open Source Tool. Was ich sehr spannend finde sind die letzten beiden Zeilen hier die Synthesezeit und die Implementation Time. Die Synthesezeit sehen wir ist jetzt Joses nicht irgendwie furchtbar schlecht, das ist auch nicht das Beste aber es ist auch nicht furchtbar schlecht. Aber Implementation Time also das arachne PNA braucht 81 Sekunden wofür das letztes SPT Backend über 400 Sekunden braucht. Und das ist jetzt auf einem etwas schlechteren aber nicht nicht abartig langsamen PC Wir verwenden unter anderem diese Toolchain auf dem Raspberry Pi und am Raspberry Pi macht das dann schon ein Unterschied, ob das in dem Fall dann eben 3 Minuten braucht oder eine Viertelstunde. Also nicht, dass wir es am Raspberry Pi gleichen könnten, weil natürlich das ist Arm und da kann ich die letztes Tools nicht sowieso nicht verwenden, aber selbst wenn ich es verwenden könnte, hätte ich wahrscheinlich ein Geduldproblem bei den Anwändern bei der Implementation Time. So, das ist was, das ich beim Kongress noch nicht hatte, nämlich inzwischen haben wir Timing und alles. Auch auf dem Weg bis jetzt bei jeder Station, wenn ich dann mit den Firmen gesprochen habe oder mit den Profis aus der ESC Szene, sie haben, egal wo ich war, sie haben gesagt, ja gut, aber das wirklich Schwere ist das da und das hast du noch nicht. Und im letzten halben Jahr war quasi ja, das ist ja schön, jetzt hast du Synthese und so, aber das ist keine Timing-Analysis und das wirst du nie hinkriegen. Und jetzt, ja, jetzt haben wir Timing und alles. Also, ich weiß ehrlich gesagt nicht, was das nächste Vorwand sein wird, der dann kommt mit, aber das fehlt ja noch. Aber es gibt sicherlich Leute, die was finden werden und sagen, aber das kannst du noch nicht. Du bist noch drei Lutz schlecht, das ist auch ein kommerzielles Tool. Keine Option, dass ich dich hier verwenden werde. Gut, dass diese Tabelle habe ich gemacht, glaube ich zwei Tage, nachdem ich zum ersten Mal eine funktionierende Timing-Analyse gehabt habe und ich werde ein bisschen darüber reden, aber ich möchte quasi verweggeschicken, wir haben eine funktionierende Timing-Analyse. Auf der FOSSTEM habe ich erklärt, was diese Tabellendinger heißen, dann habe ich hinterher gehört von Leuten, die gesagt haben ja, aber das kann ich noch nicht verwenden, ich habe eine halbe Stunde darüber geredet, dass die Timing-Analyse noch nicht funktioniert und ich habe gedacht, ich habe eine halbe Stunde darüber geredet, zu beschreiben wie gut die Timing-Analyse ist und wie überzeugend diese Resultate sind. Also bitte so rezipieren, ich versuche die Emotionen zu tragen. In der rechten Spalte sehen wir also wir haben drei Designs, in der rechten Spalte sehen wir, dass Design übersetzt mit den Lettestools und dann gehe ich her und fragt das Lettestiming-Tool, wie schnell ist das Design? Das ist die erste Zeile in diesen Dreierblöcken, also beim ersten Design diese 41,74 MHz das ist das, was das Lettestool mir gesagt hat, wie schnell das Design ist und jetzt habe ich meinen Tool gefragt und gefragt, wie schnell ist das Design aber jetzt kommt der Haken, man kann meinen Tool auf zwei verschiedene Arten fragen man kann sagen, gib mir ein Bestestimate was du glaubst, was die Lettestools sagen werden oder gib mir eine sichere, untere Schranke weil reverse engineering von 3MHz ist so ein bisschen eine Sache und in dem Fall ist der Bestestimate statt 41,74 41,75 MHz also ich glaube, bei allen Schwankungen, die wir haben mit was genau ist die Temperatur die ich da jetzt habe und wo bin ich in den Schwankungen vom Fertigungsprozess sind wir mit diesem 0,1 MHz also das ist ein gutes Ergebnis aber wenn man sagt, ich weiß nicht, es hat gesagt es kann 0,1 MHz schneller sein als es eigentlich sein darf dann kann man das konservative die konservative Variante wählen und die sagt dann es ist 41,40 MHz das ist dann die konservative Schätzung also das ist quasi die Schwankungsbreite in der wir uns bewegen bei diesem Timing an der Lettestool und ich glaube, das ist ganz überzeugend dass es ein bisschen Sicherheit gibt ja, das liefert wirklich die Zahlenwerte die man sich erwartet und nicht irgendwelche Fantasie zahlen in der zweiten Spalte von rechts habe ich das gleiche Design mit Josus übersetzt und natürlich komme ich dann auf ein anderes Timing interessanterweise komme ich beim PicoRV32 auf ein besseres Timing was Spallendes weil ich habe zur PicoRV32 geschrieben also meine CPU ist schneller auf meinem Synthesetool aber ich habe die CPU nicht für Josus geschrieben ich habe die CPU geschrieben für Xylings Vivada aber es dürfte quasi irgendwas sein in der Art und Weise wie ich über HDL-Code nachdenke und wie ich glaube dass Optimierung das dürfte irgendwie zusammenpasst ich weiß es nicht vielleicht ist es auch nur ein zufälliger Ausreißer aber ich finde es ja unterhaltsam dass das Design ist, dass es schneller ist und natürlich kann ich jetzt nicht das Lettestool fragen wie schnell es ist also die SB-Time-Zeile aber darunter sehen wir dann die Ergebnisse von meinen für diese Ergebnisse von meinem Tool und wir sehen in manchen Fällen ist es schneller in anderen Fällen ist es langsamer ich würde das gar nicht so strikt vergleichen weil das Lettestool übersetzt mit den Lettestools ist Constraint auf 100 MHz also ist Over Constraint möglicherweise wenn ich das Design von 55 MHz konstruieren würde vielleicht wird dann das Lettestool das wieder besser machen es ging mir weniger mein Vergleich zwischen der JOSUS-Synthese und der Lettestynthese als Prima um die rechte Spalte zu zeigen wir haben ein Timing-Analyser-Tool das absolut vergleichbare Ergebnisse liefert wie das Tool vom Hersteller und damit glaube ich sind wir einen Punkt wo man sagen kann das ist ein produktiv einsetzbarer Flow das war mir wichtig ich habe übrigens immer gesagt zu wie ich Timing-Analyser habe werde ich Lettest kontaktieren weil dann habe ich einen Flow den man produktiv einsetzen kann ich habe das dann auch gemacht nachdem ich die Timing-Analyser veröffentlicht habe das war kurz vor der Fosterm ich habe noch nichts gehört von Lettest vielleicht schreibe ich mal eine freundliche Mail vielleicht haben sie meine Mail vom so und so vielten nicht gesehen gut aber das ist ja nicht alles also wir können noch für andere Architekturen übersetzen und eine dieser Architekturen sind Xylinks 7 Series FBGRs damit arbeite ich in meinem Brot-Beruf relativ viel das heißt ich habe eine gewisse Nähe zu diesen Chips und und wir können Synthese machen also wir können das HDL-Design nehmen und ein Netzlist übersetzen aber das Play ist ein Traut das können wir im Augenblick nicht machen es gibt einige Bemühungen für Xylinks zu machen mit Open Source Tools zum Teil setzen die aber auf XDL Xylinks Design Language eine Low Level Sprache wo bei älteren Xylinks FBGRs es von Xylinks Tools gibt um das noch ein Bitstream-File umzuwandeln und dann tut man eben nicht das Bitstream-File erzeugen sondern das was fast genau gleich ist wie wenn ich schon ein Bitstream-File erzeugen könnte ja was weiß ich aber in dem Fall was ich hier präsentiere machen wir das nicht wir werden keine von diesen von diesen Projekten sondern wir nehmen einfach Xylinks Vivado für Playshandraut und in dem Fall würde ich dann in den Synthese-Script für Vivado entsprechend sagen ReadEdiff für die Ediff-Netzliste die ich aus Joses heraus erzeuge und normalerweise wird man in Vivado mit Synth-Anderscore-Design die Synthese anstoßen wenn das schon alles synthetisiert die Netzliste ist und man will nur noch dass man dann die Playshandraut-Dinge verwendet dann sagt man Link-Design ist nicht besonders gut dokumentiert also aber nachdem ja auch Xylinks andere kommerzielle Tools unterstützt als Synthese Tools muss es da einen Weg geben wenn man ein bisschen gräbt findet man diesen Weg und dann kann man einfach schauen wie sich das was immer durch Joses in dem Fall gut es gibt natürlich wieder help Synth Xylinks und auch das kann wieder interessant sein sich anzuschauen und zu vergleichen was wird da eigentlich gemacht einem ein oder anderen Flow das Interessante finde ich wenn man das Synth Xylinks und das Synth I-40 nebeneinander hinstellt und auch die Files anschaut die quasi mit ausgeliefert werden mit dem Joses die verwendet werden das Synth Xylinks irgendwelche Beschreibungen von den Blockgram-Ressourcen die verfügbar sind in den entsprechenden Baustellen und so das schaut alles sehr ähnlich aus also wenn jetzt quasi jemand das V-Targeten möchte auf einen anderen FPGA dass man an einem Punkt ist an dem man mal was hat was funktioniert vielleicht nicht super performante es nicht die exotischen Device Primitives der Zielarchitektur sinnvoll verwendet da kommt man eigentlich ziemlich schnell hin so ein bisschen was exotischer aus Sileo Green Pack 4 kennt jemand diese Bausteine? es gibt inzwischen noch einen Green Pack 5 wir konzentrieren uns aber jetzt mal auf Green Pack 4 weil Green Pack 4 nämlich 25 Lutz hat 25 Lutz, ganze 25 Lutz und der Green Pack 5 hat weniger so eine Asynchron-State-Maschine hat die konfigurierbar ist und viel über das was man über Lutz löst im einen Fall macht man über diese Asynchron-State-Maschine bei den Green Pack 5s werden die Green Pack 5s auch unterstützt aber die Green Pack 4 ist im Augenblick so das Ziel Synthese gibt es schon da gibt es ein Synth an das Green Pack 4 Commander und bei diesen Beispielen gehen wir doch alle Backends durch weil in dem Fall ist es ein Chasen-File das verwendet wird als Austausch-Format zwischen Josus und den Blaisandraud-Torn und dieses Chasen-Format ist eigentlich das empfohlene Format wenn irgendjemand was machen möchte mit Josus als Frontend und von vornherein weiß das ist das Ziel, ich will nicht irgendwie Interoperabilität und vielen anderen sondern ich will irgendwie schnell die interne Darstellung von Josus in meinen Tool bekommen ist die empfohlene Schnittstelle dieses Chasen-Format gibt es übrigens auch Hard Camel-Josus kennt jemand Hard Camel? das ist Hardware-Entwicklung in OCamel also so wie es irgendwie weiß ich nicht das gibt Mai-HDL für Python das gibt Chissel, das sind Scala das gibt Clash für Haskell und das gibt eben Hard Camel und da gibt es einen Pfad wo ich Währlob nehmen kann und über dieses Hard Camel Josus dann im Hard Camel verwenden kann gut, das war jetzt ein bisschen nix-fußig, ich mache die Folie in der falschen Reihenfolge also der Andrew Sonberg der schreibt den Tool namens OpenFPGA und das soll quasi Playsandraud machen für die GreenPack Force aber auch andere programmierbare Logik-Bausteine also da geht es dann mehr so Richtung CPLDs und so und der GreenPack Force ist sicherlich ein erster interessanter Baustein das zu machen unter anderem darum weil dieser Baustein vollständig vom Hersteller dokumentiert ist also im Datasheet steht drinnen welches Bitwas macht ja, das ist sehr cool wir haben und wir haben eine Videokonferenz gehabt vor einiger Zeit mit den Leuten von Siligio und Yvonne Feuer und Flamme dafür dass es da ein Open Source Flow geben soll unter anderem vielleicht darum weil von dem Hersteller gibt es noch ein Tool wo man Schaltungen zusammenklicken kann das heißt, da gibt es vielleicht auch einen gewissen Leidensdruck dass man da was mit HDLs machen kann ich weiß nicht, ich habe immer vermutet bei den GreenPack Force, vielleicht ist es auch ein bisschen so psychologisch, dass man das dann zusammenklicken kann weil so wie man dann quasi fertig ist mit evaluieren ob man wirklich diesen Chip verwenden möchte hat man so viel Zeit hingesteckt Lutz-Hände miteinander zu verbinden und sich auszurechnen, welche Lutz-Bitmasken man jetzt irgendwie verwenden soll dass man irgendwie schon so einen großen Bye-In hat, dass man sagt ok, wir verwenden es vielleicht mal schauen ok ich habe dann noch zwei andere Beispiele jetzt hier drinnen in meinen Folien zu bisschen obskurren Anwendungen, was man aber noch immer unter dem Überbegriff Schöne These verlassen kann zunächst mal einfach WereLock2pliff also Pliff haben wir vorher schon gehabt das Netzlistenformat, wo ich wirklich Zellen von einer Zielarchitektur habe aber das ist eigentlich nur so ein Nebenbeiding bei Pliff, dass das Pliff der Teilformat das auch kann sondern das Pliff der Teilformat ist eigentlich dazu da wirklich Logik direkt abzubilden also ich habe dort quasi ein eigenes Statement mit einem bezeichneten Namen DotNames DotNames macht eine Lutz, warum auch immer also ich weiß nicht, was der Gedanke dabei war das Statement so zu nennen und ganz ganz viele ältere Tools ältere Open Source Tools die sich mit Logics und These beschäftigen verwenden Pliff als Input Format und auch sehr viele Academic Tools das heißt, da gibt es viele viele Tools die können ganz großartige Dinge aber nur wenn ein Plifffile gibt und niemand hat ein Plifffile für irgendwas, was eine interessante Schaltung wird irgendwie so Test-Benches mit irgendwie kommunatorische Logik und Pliff-Files und so ja und mit Joses kann ich aber hergehen und Joses als universelles Frontend verwenden für alles was Pliff schluckt und kann quasi all diesen Tools ein VeyreLog Frontend geben im einfachsten Fall ist das Umwandeln von VeyreLog nach Pliff so einfach wie dieses Beispiel hier nicht nicht immer das Problem sind Dinge wie Memories Pliff kann nämlich keine Memories das heißt also in dem Fall wäre es nicht einmal ein Problem in dem Fall nehme ich einfach das Memory mache daraus Logik und Flip Flops und dann kann natürlich jedes Tool damit umgehen aber wenn ich jetzt irgendwann einen formalen Beweis führen möchte zum Beispiel und ich habe halt zufällig irgendwie 64 Kilobytes Memory in meinem Design im Augenblick wo ich das umwandle in Logik und Flip Flops habe ich was was die meisten Tools die formale Beweise verstehen nicht wirklich haben wollen und dann wird es ein bisschen schwieriger aber ich würde da die Schuld von sich von beweisen und sagen das Problem ist das Pliff der Di-Format was soll ich machen wenn es keine Memories gibt gut in solchen Fällen kann man aber auch eine andere Strategie wählen nämlich einfach VeyreLog in einfaches VeyreLog umwandeln es gibt nämlich sehr sehr viele Tools die sagen sie können VeyreLog und dann liest mir irgendwie und irgendwie habe ich mich eingedruckt und irgendwie die drei Statements nichts anderes, bei was Anderen Kriegst du einen Sack folgt nicht bei einer Fehlermelok und bei solchen Fällen kann es natürlich ganz spannend sein Josus hat ein VeyreLog Frontend Josus hat ein VeyreLog Backend und das VeyreLog Backend bei Josus kann ich nicht nur verwenden um VeyreLog Netzlisten zu erzeugen aber ich halt nur noch Zellen instanziere sondern ich kann auch noch Memories VeyreLog Errays wieder ausgeben und solche Dinge und solange quasi in dem kleinen kleinen Subseit von VeyreLog was dieses Tool das ich eigentlich verwenden möchte wenn das Memories kann dann brauche ich Memories nicht auf LogicMap bei mir im Josus Script gut wenn man das macht braucht man meistens diese Option Minus NoATRA die hier verwendet wird in VeyreLog wenn ein bisschen mehr VeyreLog macht dann klär man auf Stern das Stern klär man zu mit dem man Attribute auf alles geben kann auf Wires, auf Zellen, auf Blöcke und damit sagt man dann den Tools irgendwie wo es den Blockblutz platzieren soll auf dem Chip oder dass diese Statemachine Hot Encoding verenden soll diese Dinge und viele viele viele von diesen Tools die ein bisschen VeyreLog verstehen die sind völlig überfordert also mit NoATRA gibt da keine Attribute mit aus und ansonsten wirft VeyreLog auf alles ein Attribut drauf das nämlich sagt mit welcher Zeile im ursprünglichen VeyreLog korreliert das was ich jetzt rausschreibe also sehr sehr nützlich außer das Tool mit dem ich es lesen möchte versteht es nicht gut was auch hier interessant ist ist Prep Prep ist so ähnlich wie Synth aber macht keine FineGrain-Synthese und macht nur einige konservative Transformationen das heißt wenn ich im ursprünglichen VeyreLog Code irgendwie Plus geschrieben habe für eine Addition der VeyreLog Code der daraus kommt hat immer noch ein Plus für eine Addition von zwei großen Bitvektoren und nicht irgendwie nur noch Gate-Level-Logic und wenn ich das machen möchte wenn ich auf dieser Core-Screen-Ebene arbeiten möchte haben wir noch die ASIC-Synthese und Custom-Synthese-Flows das werfe ich immer in einen Topf weil die meisten ASIC-Flows sind irgendwie Custom also meistens will man hat man halt genau diese Library von also diese Cell Library von diesem Hersteller und dann hat man irgendwie diese Art von Memory Primitives dann muss ich vielleicht einen kleinen Memory-Mapper dazu machen also ASIC-Scripts werden sehr schnell Custom damit meines dass man nicht nur Dinge hat vor Synth die quasi spezifisch sind für mein Design sondern auch Dinge nach Synth oder Dinge statt Synth also hier wäre ein typisches ASIC-Synthese Script wo ich eben so einen generischen Teil hab oben wo ich mal meinen Design les was ich immer mach und dann rauf ich mal Synth auf und dann habe ich mal eine Logiknetz-Liste von Josus und jetzt will ich aber diese Internet-Darstellung in meine Cell Library umwandeln also auf meine Cell Library mapen und wir verwenden genau das was wir im Slide früher schon gehabt haben nämlich zuerst die FF-Flip-Map um alle Flip-Flops umzuwandeln auf die Art von Flip-Flops die es gibt in der Cell Library und wenn es blöd kommt kann dazu z.B. zusätzlichen Werte einbauen ich zeige mal ich hab irgendwie in meinem Design will ich ein Asynchronous Reset machen das High-Aktiv sondern bei der Cell Library gibt es noch ein Low-Aktives Asynchronous Reset und darum will ich irgendwie zuerst das Flip-Flop mapen weil ich dadurch die Logik verhindere weil ich ein zusätzliches Notgate einbauen aber es gibt Scherze wie man quasi zuerst nur alle Flip-Flops ein bisschen ein bisschen behandeln kann so dass dieses zusätzliche Notgate entsteht und dann mapen wir die Logik und dann noch einmal Flip-Flops um das Timing zu optimieren und dann am Schluss werden die Flip-Flops wirklich gemapped, auch solche Flossen sind möglich gut, ja aber vielleicht will man gar nicht essig Sonthese machen vielleicht will man irgendwas ganz ganz anderes machen dann wird man auch Sonthese Skrips machen die irgendwie so ausschauen die ein Synth oder Prep verwenden und danach irgendwie eine Custom Abfolge von Kommandos die das tun was immer man möchte ich hoffe ich habe ein bisschen das Bild vermittelt dass man mit Josius mehr machen kann das nur sind diese für 1,40 FB Gas obwohl es sind diese für 1,40 FB Gas glaube ich sehr sehr wichtig ist also nicht nur technisch so was zu haben sondern auch politisch so was zu haben wenn du zeigen schau das geht wollen wir vielleicht an der Stelle fünf Minuten Fragen einschieben wenn es irgendwelche Fragen gibt die jetzt noch zu dem Synthesis-Block gehören würden ja ich wiederhole die Frage immer wegen der Kamera da die Frage war nach Timing Constraints im Augenblick gibt es gar keine Möglichkeit wirklich Timing Constraints anzugeben also beim 1,40 Flow du kriegst das Timing was du kriegst es gibt nicht die Möglichkeit das zu constrainen in Asic Flows kannst du Timing Constraints verwenden die auch für die Synthese herangezogen werden aber aber nur für die Logix Synthese also es ist nicht so dass er sagt wenn er die Cross-Gray-Netlist anschaut dann sagt ah bei dem Timing-Ziel verwende ich jetzt diese Art von Lookerhead Adder damit sich das ausgeht an der Stelle ist ihm das Timing noch wurscht wenn immer die gleiche Art von Lookerhead Adder aber wenn er dann in der Logix Synthese ist wenn er der Timing Constraints dort hauptsächlich für Gate Resizing also wenn ich Asic Synthese mache dann habe ich meistens ein Land Gate in meiner Cell Library sondern ich habe 10 Land Gates die unterschiedlich groß sind und die großen Land Gates können mehr Strom am Ausgang erzeugen haben aber größere Kapazitäten am Eingang und dann geht es ein bisschen abwägen wo verwende ich welche Gate Größe um mein Area Requirement hinzubekommen und die Schaltung soll nicht unheimlich groß sein aber auch mein Timing Requirement zu schaffen also in dem Fall können wir Timing Constraints verwenden also wenn du Multiklock verwenden möchtest musst du quasi Hände, Stein Design in Klokdomänen runterbrechen und hoffentlich hast du quasi die Hierarchie so dass es hierarchische Blöcke gibt die nur in einer Glock sind oder du musst alles auf die schnellste Glock Constraints also das sind die Möglichkeiten die es im Augenblick gibt also es gibt ein paar Sachen aber es ist nicht so, dass ich sage wir haben alles gute Frage sonst fragen schlecht es gibt gute Vorsätze ah, danke ja die Frage war nach Systin Werrelok und Systin Werrelok durchschnitzung in Joses und die Antwort ist, es schaut schlecht aus im Augenblick also wir können einige wenige Dinge aus Systin Werrelok ich kann die Sachen die ganz ganz trivial ist always anders KFF zum Beispiel wird unterstützt aber checkt nicht ob wirklich ein Flipflop rauskommt das ist einfach ein Always Bit glaube ich wird zum Beispiel auch unterstützt einfach so ein alias für REC der Plan ist im kommenden Jahr ein bisschen mehr Systin Werrelok Unterstützung einzubauen insbesondere auf Hinblick auf Systin Werrelok Assertations weil halt formale Verifikationen für mich interessant ist und dort also so wie ein Design mal formale Verifikation verwendet verwendet meistens auch ein paar andere Systin Werrelok Features also die Idee ist jetzt mal ein bisschen zu schauen was sind die Dinge die wirklich häufig verwendet werden ich muss noch ein bisschen schauen welche Open Source Systin Werrelok Designs es gibt es schaut eher schlecht aus es gibt Pipe zum Beispiel die sind Systin Werrelok geschrieben aber die meisten Open Source HDL Designs Werrelok Designs sind Werrelok und nicht Systin Werrelok aber die Idee ist quasi so ein bisschen ein Pool anzulegen an Dingen die wir gerne hätten und dann einfach zu sagen Welches Systin Werrelok Features fehlen uns da und dann fangen wir quasi bei den Low Hanging Fruits an und schauen wir weit wir kommen in diesem Jahr also das ist auf der Totuliste aber noch nicht so wie ich es gerne hätte gut okay, dann haben wir ein bisschen Zeit gehabt die Synthese setzen zu lassen und dann machen wir das weiter und wir können natürlich nachher noch ein bisschen mehr Fragen beantworten natürlich auch noch zur Synthese also die Chance ist nicht vorbei gut, formale Verifikation also passen zu der Frage fangen wir wirklich an mit Systin Werrelok also in Systin Werrelok gibt es Essard und Assume und die Essard und Assume Key war der zweiten von Josus unterstützt so da kann man dann zum Beispiel sowas machen wo man sagt Essard property und dann kommt ein property das muss immer true sein technisch gesehen in diesen Klammern bei property steht es ein property und keine expression und ein property kann alles mögliche sein also da kann man auch temporale properties vorkommen in der Sprache das sagt wenn im letzten Taktzyklus das den Wert gehabt hat dann muss in diesem Taktzyklus was auch immer das unterstützen wir im Augenblick noch nicht also im Augenblick ist diese property quasi einfach nur eine Werrelok expression die einfach ausgedeutet wird und immer wahr sein muss und in dem Fall wäre das sogar wahr was wir hier fordern also wir sagen wir Assumen dass A plus 1 gleich B ist damit schränken wir ein bisschen ein welche Dinge wir akzeptieren an den Eingeb einen Input in unserem formalen Beweis in dem Fall stellt sich natürlich die Frage ist das wirklich sinnvoll sowas anzunehmen aber wie auch immer nach dem der Ausgang Y das X oder ist von den Lists significant bits von A und B 1 Größe sein muss das andere da muss Y immer wahr sein weil es muss immer das X oder das 1 zwischen einem 1 und einem 0 das heißt in dem Fall stimmt das und wir können quasi dieses Y-Script das da unten das Leitsteht ausführen und wir bekommen dann auch die Ausgabe dass das immer wahr ist so und jetzt ist der Teil gekommen so ich werde versuchen immer nur entweder dorthin zu schauen oder zu reden schauen wir uns das an das ist das Exempel 0000 wenn ich das ausführe also wenn wir das ausführen dann beweist du uns das diese Prop-Device und sagt Kudde, ist es wahr also wer jetzt nicht jedes Exempel ausführen aber bei manchen Exempels möchte ich irgendwie herzeigen das geht wirklich was da steht es wäre nett ein Programm zu haben dass diese magischen Dinge könnte gut wir haben vorher das Assume-Prop-De und Asset-Prop-De gehabt es gibt auch nur Assume und Asset-Ohne-Prop-De das kann ich in V-Login-Behavioral Code verwenden in einem Always-Block und da hätten wir jetzt hier irgendwie das gleiche Beispiel von vorhanden nur mit einem zusätzlichen Enable-Signal und das ist irgendwie if-Enable und nur wenn Enable war es gilt sowohl die Assumption als auch die Assumption und da wäre eben im Augenblick das ist dann zu haben in der Regel wenn man jetzt was Aufregenderes überprüfen möchte würde man eine State Machine schreiben in einem Always-Block und einfach dort drin an immer nur Assume und Asset verwenden und das Assume-Prop-De und Asset-Prop-De eher selten aber wenn ich das kann, dann ist es easy diese einfache Version von Assume und Asset-Prop-De zu unterstützen also warum nicht also das würde auch cool Idee liefern das würde ich jetzt zum Beispiel nicht ausprobieren gut also der Befehl mit dem ich das jetzt gemacht habe war das Sattbefehl in Joses ich bin der Meinung die allermeisten Synthesitools könnten auf dieser Art und Weise formale Beweise führen ich weiß es nicht weil ich weiß nicht was in diesen kommerziellen Synthesitools drinnen ist ich weiß nur ich habe auch ohne formale Beweise so wie so schon in einem Satt-Solver in Joses drinnen angehabt und wenn ich Dinge habe wie zum Beispiel das heißt es macht Sinn ein bisschen CPU-Züglichen zu investieren um Sachen zu machen wie Resource-Sharing für Memory Ports und wenn man da CPU-Züglichen investieren möchte wenn man einen Satt-Solver anschaut kann es sein, dass diese Memory Ports irgendwie alle gleichzeitig ansehend und wenn nicht, dann kann ich Ports-Share und dieser Satt-Solver der sozusagen sowieso drinnen ist in Joses mit dem man sowieso kleine formale Beweise führt als Teil der größeren Synthesistrategie den habe ich eben exposed über ein eigenes Kommando mit dem ich dann sagen kann welche Satt-Problemen soll er lösen und das Kochrezept quasi ist das auf diesem Slide ich lese mein Design mit ReadWareLog habe ich verwendet ein Parameter Minusformal und Minusformal aktiviert einige System-WareLog Features aber nicht alles was wir aus System-WareLog unterstützen eben im Wesentlichen alles was irgendwie zu System-WareLog ist ja auch schon gehört und außerdem definiert gleich so weil es praktisch ist definiert Minusformal das Defineformal so ich kann in meinem WareLog Code einfach so schreiben ifdefformal und habe dann diesen Code nur aktiv wenn ich die gerade formale Beweise fühe und das Synthesitool das ich ansonsten vielleicht verwenden keine formalen Beweise kennt sich dann nicht an irgendwelchen Keywords weessert wenn mein Design hierarchisch ist dann muss ich es fletten also das Satt-Commander kann nur innerhalb von einem Modul und kann nicht über Modulgrenzen hinweg in hierarchischen Designs arbeiten das geht mit dem Befehl fletten und also das macht man nach Prep vielleicht Prep auf das Slide auch schreiben soll, dann macht Prep und dann macht man Fletten einfach um ein Prep macht und nicht Zünd sind zwei Gründe einerseits mal will man hier ein bisschen konservativer sein also es gibt so ein paar gerade wenn man andefbehaviour richtig simulieren möchte mit der Art und Weise, wie es WareLog ist wie WareLog macht laut dem Sprachstandard will man jetzt nicht allzu komplex Rupterungen machen weil manche von diesen Optimierungen machen dann Dinge, die feind und bei Synthesis ist das okay ich kann jederzeit sagen, dass es andefined ich definiere das auf einen gewissen Wert aber wenn mein formaler Beweis irgendwie zeigen möchte dass an der Leitung nie ein X sein kann dann ist das blöd, wenn ich eine Syntheseoptimierung mache die manchmal X wegwirft und sagt hm, ein Multiplexer zwischen X und was anderem nehmen wir immer das andere das ist zum Beispiel eine Optimierung, die möchte man nicht machen das zweite ist, dass die Art und Weise wie ich einen Audierer zum Beispiel auf Logikmappe ist eine andere wenn ich das tue um Synthese zu machen am Schluss ist es irgendwie ein Chip laufen zu lassen und wenn ich das mache für formale Beweise also ich will da andere Strategien wählen und daran möchte ich gern den Audierer einfach Audierer lassen und das Satz Solver weiß dann schon mein Sat Framework weiß daraus, wie er dem Satz Solver beibringt in eine Art und Weise, die halbwegs effizient ist gut, und dann gibt es ihm den Satz Befehl und der hat eine Riesenpalette von Parametern, also da kann man alle möglichen Beweise machen in dem Fall hätten wir hier dieses klassische Muster vorhanden gehabt, Z Assumes Proof Assert das wäre zum Beispiel zwei typische Parameter, die man hat um mal einen Beweis aufzusetzen in dem Fall habe ich keinen Z Assumes weil ich habe keine Assumptions in meinem Verylog Code und ich möchte gerne die Outputs wissen vielleicht sollte ich kurz darüber reden was ich hier versuche zu beweisen ich habe ein Modul mit einem Input A und einem Output Y und ich schaue und die sind beides seint das ist übrigens eine gute Möglichkeit wenn man gern Bugs finden möchte sind diese Tools, spielt es euch mit seint ich habe es gibt ein Ding das heißt Vlog Camera das ich geschrieben habe das vergleicht die Outputs von unterschiedlichen Z Assumes Proof Asserts das habe ich gemacht, wo ich mir gedacht habe dann kann ich vergleichen was joses macht mit dem was andere Tools machen und ich finde viele Bugs in joses und ich habe auch viele Bugs in joses gefunden aber ich glaube ich habe überproportional mehr Bugs in anderen Tools gefunden so wie ich angefangen habe so Sachen wie seint zu verwenden das ist wirklich kompliziert die Verylog Regeln für seins richtig hinzukriegen also ich habe zwei ich habe zwei Signale Y weiß ich folgendermaßen zu ich schaue ob A kleiner ist als 0 und dann nehme ich minus A also ich flippe das Sein und ansonsten nehme ich A so wie es ist und dann wird man glauben Y muss jetzt immer positiv oder null sein wenn es kleiner als null ist, habe ich das Vorzeichnen getreten und das kann ich dann hier versuchen formal zu beweisen und dann kommt das Tool zurück sehen das hier und sagt mir ich bin ein Idiot aber ich habe das Vorzeichnen nicht verstanden und wenn ich die negativsten negative Zahlen nehme also 1 und dann lauter 0 und ich mache davon minus bleibt das die gleiche Zahl das bleibt die negativste kleine Zahl das heißt diese Annahme die ich hier habe war falsch und dieses Tool hat mir gezeigt dass es einen Schlupfloch gibt durch mein Design auf der Slide habe ich jetzt nur ein paar andere Beispiele was können wir machen dass wir alle möglichen Beweise konstruieren ich kann zum Beispiel Bounded Model Checks machen also die Dinge die man jetzt angeschaut hat die haben alle keinen Internet State gehabt die waren alle Fahrt jetzt haben wir irgendwas mit Internet State mit Flip Flops und ich sage ich will eine Sequenz untersuchen von 50-Tag-Züklern und ich will dass alle Samtions halten und ich will alle Assets prüfen was typisch ist was man machen möchte in einer echten Anwendung dass man Bounded Model Checks macht für eine kleine Anzahl von Tag-Züklern man sieht natürlich sofort schon das Problem nur weil ich bewiesen habe dass meine Eigenschaften für 50 Züklern gültig sind heißt nicht dass die immer gültig sind und das ist in der Tat ein großes Problem bei Formalen Beweisen diesen Sprung zu schaffen wenn ich Systeme habe mit einem Internet State von es hält für N-Züklern also es hält für alle Züklern für alle Zeit es gibt unterschiedliche Strategien das zu machen die einfachste ist Temporal Induction und das kann ich machen mit dem Satz-Befilm was ich im Grunde versuche mit Temporal Induction zu machen ist das gleiche was ich mache mit vollständig Induktion wenn ich einen mathematischen Beweis für bei vollständig Induktion sage ich ich zeige mal dass es für die ersten N natürlich in Zahlen gilt und dann zeige ich dass das natürlich in Zahlen gilt muss es auch für die nächste gelten und damit habe ich quasi mit diesem letzten Schritt, mit dem Nutzungsschritt habe ich das für alle natürliche Zahlen bewiesen das mache ich hier für die Zeitschritte ich beweist das für die ersten N Zeitschritte nach Initialisierung mein property-Gild und dann versuche ich einen Beweis zu führen dass aus das property-Gild für ein Zeitschritte folgt das folgt gilt auch für den nächsten Zeitschritt vollständig Induktion ist das N meistens 1 man zeigt dass es für 1 gilt und man zeigt dass es quasi für den Nachfolger eine Zahl gilt und da muss es für alle Zahlen gelten bei Schaltungen geht das selten dass ich quasi sage für den Reset-State gilt und weil es für irgendeine State gilt muss es für den nächsten State gelten aber für viele viele nicht für alle, aber für viele viele Designs ist das sozusagen sagen kann wenn ich 50 auf einander folgende Zeitschritte habe und in jedem dieser Zeitschritte halten dann habe ich den Space in dem ich befinden kann sehr stark eingeengt und wenn das lang genug ist dann gelingt es mir vielleicht zu beweisen dass es für den nächsten Zeitschritt auch gilt aber für viele Designs geht das nicht ich kann relativ leicht ein Design machen dass Internet ein zweiter sich BitCounter hat und er zählt mal hoch und ändert irgendwie grundlegend das Verhalten von dem Modul wenn der zweiter sich BitCounter auf 2 Milliarden steht das werde ich wahrscheinlich nicht hinkriegen mit einem auktionslänger klein als 2 Milliarden Zeitschritte und das wird schwierig also da vielleicht haben wir am Schluss ein bisschen Zeit im letzten Beispiel kann man solche Sachen ausprobieren also das ist der zweite Beispiel Temporal Induction Proofs wenn so ein Proof Fehl schlägt ist er nicht immer so einfach wie in der letzten Folie die ich gehabt habe dass das Ding einfach sagt ganz klar bei dem Input kann es nicht gehen wenn ich irgendwie eine CPU habe und dann kommt irgendwie ein Nonsens raus und alles sagt, dass mir etwas auf den Inputs war und dazwischen ist diese riesen Wolke von Logical State wird nicht gehen ich brauche irgendwie die Möglichkeit Internet State nachzuvollziehen in einem Gegenbeispiel und ich kann hier zum Beispiel einfach VCD-Files schreiben die kann ich mir mit GTK WF anschauen mit allen Internet-Signalen das ist relativ bequem ich kann auch wie es ist in einem Demax-File ausgeben damit kann ich zwei Dinge machen einerseits kann ich in einem externen Satz holen oder dann versuchen das den gleichen Beweis zu führen das Problem ist das sagt nur noch ja oder nein weil dass ich dann wieder rauskriege was war der Wert von welchem Input zu welchem Zeitschritt und so das kitzelt ich nicht mehr raus aber es ist sehr praktisch wenn ich in der Bewegung einen Plug-in zu schreiben für joses weil der Satz holen der joses verwendet kann über einen Plug-in-Mechanismus ausgetauscht werden und ich will jetzt vielleicht nicht zuerst das ganze Plug-in schreiben und dann ausprobieren ob der andere Satz holen wirklich schneller ist und wenn ja dann schreibe ich das Plug-in und dafür ist das ganz praktisch der Demax-Files raus schreiben zu können die letzte Zeile finde ich sehr schön repräsentativ für die Arten von Dingen die man oft macht und das ist einfach interaktiv also und das ist einer der Dinge die ich auch oft einfach in meinem ganz normalen Job mache ich habe irgendein Design das läuft auf einem Xilinx-FBGA und wir haben Chipscope drauf mit dem wir uns ein paar Signale anschauen und wir sehen dass da was schief geht und dann schaut man sich das Muster an wer Chipscope und sieht quasi zu welchem Zeitpunkt hat welcher Signal welchen Wert gehabt und vergleicht das mit dem Wärrelokot das geht nicht die Schaltung kann nicht in diesen State kommen es gibt keine Möglichkeit dass die Signale die ich nicht sehe machen dass diese Signale diese Werte haben in der Regel liegt man falsch in der Regel gibt es eine Möglichkeit das zu tun aber rausfinden tut muss da nur ein Thema im Chipscope mehr Signale dazu fügt da muss man das Design neu übersetzen wenn man halbwegs anspruchsvolle Designs hat dann kann das schon mal einen Tag laufen Literation pro Tag was ich auch natürlich genauso sagen kann ich kann das Design nehmen und kann sagen lieber Satz Solver ich hätte gerne ein Sequenz von 15 Tagzyklen ich weiß das Signal FU ist immer auf dem Wert 23 und ich weiß irgendwann ist das Signal Never Won auf 1 und ich hätte gerne das das beim Tagzyklen 10 ist schau ob das passieren kann und wenn es passieren kann dann wird das Signal bar und sehr häufig löst das dann diesen Knoten im Gerät und sagt natürlich kann das passieren und man hat einen Tag gewonnen wo man nicht darauf warten muss dass es einen neuen Test FBA Bitstream gibt gut also jetzt habe ich so viel Yabon gemacht dieses Satz Befehlen Jesus es ist so super man kann so tolle Sachen damit machen Bros and cons ein Vorteil ist es ist eingebaut in Jesus also wenn ich eh schon vielleicht Jesus irgendwie verwende meinen Flow gleich dort habe ich die Funktionalität ich muss nicht mein Design wieder in einem anderen Format ausgeben verlier dabei vielleicht irgendwelche Metadaten die mich interessieren könnten und muss es dann in einem anderen Programm neu verarbeiten das ist ein großer Vorteil und ich habe relativ gutes Reporting für Counter Examples erzeugen ich kann Tabellen ausgeben und genau sagen welche Signale mich interessieren viele von den anderen freien Tools das gibt die ich verwenden kann für solche Dinge wenn ich mit Joseph ein entsprechendes File ausgib kann dann sowas nicht sondern die sagen dann ja stimmt oder nein stimmt nicht das hat zum Teil damit zu tun dass das Academic Tools sind und die sind nicht gedacht dass ein User diese Ausgabe sich anschaut sondern die sind gedacht um Wettbewerbe zu gewinnen und zu zeigen dass dieser Algorithmus zum Lösen von einem Problem effizienter ist als der andere Algorithmus zum Lösen von Problem und wenn ich das zeigen möchte dann brauche ich keine brauche ich nicht ein gutes Reporting von Counter Examples und solche Sachen das sind Anwenderdinger das brauche ich nicht um zu zeigen dass mein Algorithmus besser ist aber jetzt habe ich das Problem es gibt ein Open Source Tool mit einem besseren Algorithmus und ich möchte das irgendwie seine Doktorarbeit verteidigen und nicht irgendwie ein Tool zu machen das ich verwenden kann also wir haben gutes Reporting von Counter Examples und es ist einfach solche Art Hock Proofs aufzusetzen wo ich gerade vorher gesagt habe wir sagen Signal Fuhr hat immer den Wert 23 und ansonsten müsste ich ins Währrelock File gehen, müsste irgendwie ein Assume Statement einbauen damit ich quasi diesen Teil-Lösungsraum untersuche das ist das sind leite Dinge, das sind Features die man haben möchte was spricht dagegen zunächst einmal ist das der SMT Solver der dahinter steht weil ich eben Dinge wie Auditionen anzukam und so nennt er IGA SMT Solver ist also der Solver selber weiß nichts über Arithmetrik oder solche Dinge sondern der kennt nur bulche Operationen der kennt nur Gates er kennt nur CNF aber es kommt auch gleich hinaus und es gibt andere Solver es gibt SMT Solver die können das kombinieren mit Wissen über Arithmetrik und können Dinge wo Rechenoperation vorkommt viel viel effizienter lösen das heißt insbesondere wenn ich große Beispiele habe und ich komme in echte Performance Probleme also jetzt brauche ich schon eine Stunde dann ist vielleicht der Punkt erreicht was sinnvoll wäre ein externes Tool zu verwenden was ich oft mach wenn ich einfach nur zeigen möchte dass mein Design funktioniert dass ich mit dem SAT-Kommando in JOSUS kurze Bounded Modelchecks mach weil meistens wenn ich einen Unfug gebaut hab fallen mir die schon am Kopf und wenn die dann sagen okay für 10 Zügel eines sieht alles gut aus dann gehe ich an ein externes Tool das ist vielleicht nicht so gut, dass er auch Reporting hat und sagt ah und ich kann außerdem beweisen es gilt für immer und manchmal passiert es halt dass man in dieser blöden Zwischenzone ist dass man offenbar 50 Zügel braucht um zu zeigen, dass man einen Fehler gemacht hat ein anderes Problem dass wir haben mit diesem SAT-Kommando dass diese Repräsentation die ich da hab die hat keine Theories of Arrays das heißt die kann nicht Memories in einer effizienten Art und Weise modellieren und man muss auch hier wieder alle Memories beim kleinen Design geht das beim großen Design ist das dann problematisch und das hat keine super advanced Proof-Startages, also ich hab diese Temporal Induction und viele kleine Sachen gehen damit, aber ein Algorithmus der zum Beispiel sehr gut ist das IC3 und da gibt es andere Tools die kann man denn und ich kann JOSUS mit diesen anderen Tools gemeinsam verwenden aber ich verliere eben Dinge wie dieses schöne Rhochreporting gut das sind die Vor- und Nachteile die die Moral von dem sollte quasi sein das SAT-Kommando verwenden bis man im Wesentlichen drauf kommt ist es zu langsam weil diese 3 Cons haben alle was damit zu tun dass es zu langsam ist ich hab keinen Hochperfomanten SMT Solver, ich hab keine Theories of Arrays ich hab keine super advanced Proof-Startages solange das SAT-Kommando die Ergebnisse liefert die mich interessieren und nicht einfach eine Stunde lang steht mit ich denke nach, ich denke immer noch nach dann ist es gut, aber wenn man in diese Fostation hinein kommt dann wäre es sinnvoll sich andere Dinge anzuschauen die man machen kann ja es kann man für andere Dinge machen man kann Meter-Surklits bauen ein Meter-Surklit ist ich hab meine Schaltung die ich testen möchte und da sind irgendwie drinnen S-Hirts und jetzt ersetzt sich diese S-Hirts und die S-Hurms durch eine Schaltung die testet ob die S-Hirts und die S-Hurms ob das passt und diese Schaltung baut einen zusätzlichen Ausgang in mein Design ein und dieser Ausgang geht heil, wenn irgendwas falsch ist wenn irgendwas nicht passt die anderen Ausgänge wir verweisen es weg die braucht man eh nicht, dann kann man vielleicht noch ein bisschen Logik weg reduzieren da hat man eine kleinere Schaltung ein Fehler-Ausgang, der sagt irgendwas stimmt nicht und diese Meter-Surklits die kann ich dann in externen Tools beweisen also in A, B, C zum Beispiel von der Berkeley Logik Group oder so die haben EZ3 implementiert das Quantitort heißt PDR und die können dann ein Bliff-File laden und dann kann ich diesen Beweis führen also das ist ein Meter-Surklits sind ein sehr wesentliches Hilfsmittel hier weil ich auf der einen Seite quasi die Verelog-Assertations-Welt hab und hoffentlich Ende des Jahres wird das noch viel, viel besser werden auf der anderen Seite hab ich gute Tools die gute Lösungsalgorithmen haben aber die sind weit weg davon entfernt irgendwie ein Verelog-Front einzuhaben wo ich irgendwie mit system Verelog-Assertations irgendwelche obskurren Dinge beschreiben kann und mit Joses genau in der Mitte kann man diese Dinge eben kombinieren so dazu ein Beispiel wer kennt Xorshift Xorshift Star ist ein semi-Zufallstein Generator und da gibt es Xorshift schaut im Wesentlichen nicht so aus wie diese 3 X- oder Shift-Operationen und Xorshift Star hat dann eben noch diese Multiplikation mit dabei und und wir haben hier einen pittgroßen Statevektor und diese Funktion die uns von einem State in der nächsten State führt die geht von diesen 2 hoch 64 2 hoch 64 minus 1 Möglichkeiten durch der einzige State der nie vorkommt ist 0 der wird nie gewissert, aber alle anderen kommen vor und ich will jetzt quasi beweisen wenn ich den State am Anfang mal auf Versetzer nicht 0 ist 1, 2, 3, 4, 5, 6, 7, 8, 9, das ist so gut wie irgendwas anderes dass ich dann nie den 0 State erreichen kann, das ist der Beweis denn nicht hierfür das Essatz sagt State wird nie 0 sein ja und das kann ich natürlich beweisen mit dem Sat Command wir schon gesehen haben das wäre ein typischer Fall für Temporal Induction, das schreit so nach Temporal Induction das weil genau das wenn ich hier habe wenn ich in einem nicht 0 State bin dann gehe ich wieder in einem nicht 0 State also offensichtlich wenn die Grundannahme hinter dem Essatz stimmt dann ist das schon 1 zu 1 ein Temporal Induction Proof und das geht auch super schnell also da gibt es keinen echten Grund warum ich das nicht mit dem Bild in Sat Command machen möchte das Problem ist ich habe kein Beispiel dass auf ein Slide passt dass ich nicht mit dem Bild in Sat Command machen kann aber glaubt mir es gibt genug Beispiele da kommt man an die Grenzen von dem was möglich ist mit dem Bild in Command und hier unten habe ich genau den gleichen Beweis aber ich führe jetzt mit EBC über diesen IC3 Algorithmus mit dem PDR Commander in EBC um was wir hier machen der Anfang schaut gleich aus ich lese mein WRL um das Grainz in diese zu machen dann wird es anders ich verwende den Meter Befehl um die Schaltung die ich habe in eine Mieterschaltung umzubauen also ich entferne die Asserts in the Samtions und ersetze das durch etwas was einen Ausgang treibt alle anderen Ausgänge werfe ich weg dann wandle ich das in eine Low Level Gate Netzliste um was ich hier hab weil nur das versteht EBC EBC weiß nicht was eine Addition ist also das mache ich mit TechMap und dann optimiere ich nochmal schnell drüber in dem Fall ist das Optimieren sehr wichtig weil nämlich der TechMap Schritt in dem Fall einen 64 Bit Multiplizierer baut und erst später in der Optimierung sieht dass der eine Operant konstant ist und dadurch irgendwie fast den Gesamten finden sich Bit Multiplizierer wieder wegwerft gut und dann schreibe ich ein Blitzfall das kann ich entweder in meinem Top Shell Script das alles steuert einfach ABC aufrufen ich kann aber auch in einem Joses Script mit Rufzeichen ein beliebiges Shell Commander ausführen also ich mache das hier starte ich einfach Joses ABC und ABC hat ebenfalls so ein Scripting Ding wo ich Befehle hintereinander ausführen kann das heißt ich mache ReadBliff auf das BlitzFile das ich gerade geschrieben habe dann mache ich Strasch Structural Hashing für einen End-in-Wertegrafen und dann füge ich dieses PDR Commander aus ja machen wir das vielleicht 30 was das war jetzt wegwerfen von einem Multiplizierer ansonsten wäre es so gewesen gut aber wir sehen am Schluss hier Shell Command Doppelpunkt da wird dann Joses ABC aufgerufen und dann sehen wir hier nur was das bewiesen hat Verification of Invariant wir waren klar aus was Successful das Problem ist wenn es nicht Successful ist ist dort im Wesentlichen was Unsuccessful gut also das das war das genau bevor wir zu dem ich denke interessant dass ein Teil kommen aus dem Spektrum was man mit Joses machen kann in der formalen Verifikation ein kurzer Endschub ist Equivalence Checking also die Sachen die wir bis jetzt uns angeschaut haben sind alle Property Checking dass ich irgendwie sage ich habe eine Schaltung und dann sage ich das ist meine Property und sagen wir ob das stimmt dass diese Property wirklich eine Eigenschaft der Schaltung ist also ob das immer wahr ist und man kann auf die Art und Weise natürlich auch Equivalence Checking machen und man kann sich das gleichstellen ob zwei Module gleich sind dann verbinde ich mache quasi ein Übermodul wo ich beide instanziere die Inputs verbinde ich alle miteinander so dass die Inputs immer gleich sind und die Outputs überprüfe ich auf Gleichheit das ist ein Asset das sagt quasi die Outputs von diesen beiden Modulen müssen immer gleich sein das Problem ist wenn ich eine sehr große Schaltung habe dann kann das schwierig werden und meistens möchte man Equivalence beweisen zwischen zwei Schaltungen die gewisse strukturelle Ähnlichkeiten haben also normalerweise nehme ich nicht einen Equivalence Check um quasi zwei völlig unabhängig voneinander entwickelte Module auf gleiches Verhalten zu prüfen also das kommt natürlich auch vor und dann mache ich im Wesentlichen das was ich gerade vorher beschrieben habe sondern häufig habe ich zum Beispiel das gleiche Modul vor und nach Synthese und ich will zeigen dass es immer noch gleich ist wenn man ein Synthese-Tool schreibt dann ist das sehr wertvoll so ein Werkzeug zu haben und wenn ich aber dieses Problem mir anschaue dann werde ich die gleichen Netznahmen finden ich werde sagen irgendwie ah das Netz vor der Synthese ist dieses Netz nach der Synthese hat immer noch den gleichen Namen und ich kann die große Schaltung die ich habe was jetzt erschlagen die kleine Teilschaltungen die wo ich immer diese Punkte habe wo ich schon weiß ok hier erwarte ich mir dass das Verhalten gleich sein wird weil das ist das gleiche Netz der gleiche Netznahme das ist jetzt keine Erfindung von mir grundsätzlich arbeiten viele Equivalence Check mit Tools nach diesem Nutzern was eine Erfindung von mir ist ist der Weg wie ich das in der Flow einbauen ich beginne mit zwei Modulen natürlich ich will zeigen dass diese Module equivalent sind dann gibt es das Equif Anders Core Make Commander wir sehen das in einem Joso Script auf der rechten Seite den gebe ich diese beiden Module und das baut ein drittes Modul und dieses drittes Modul das beinhaltet alle Zellen aus den beiden ursprünglichen Modulen die Inputs werden natürlich entsprechend die Inputs treiben entsprechend beide Schaltungen einen Outputs gibt es solche 5 Zellen die zwei Inputs haben und einen Output aber irgendwie ein Buffer sind also quasi ein Buffer mit zwei Inputs aber die beiden Inputs müssen immer gleich sein und das mag ich natürlich nicht nur am Output sondern überall in dem Modul wo ich erkenne dass ich zwei Punkte habe die ich korrelieren kann zum Beispiel aufgrund von einer Netznahme und das nette an dieser Darstellung ist dass ich jetzt quasi ein Design hab dass ich in der gleichen Repräsentation halten kann und ich kann wieder eine Sequenz von Kommandos auf das loslassen und ich kann unterschiedliche Strategien verwenden und der Anwender kann sagen ich will diese Strategie fahren oder jede Strategie fahren und da sind diese ganzen Equif-Anderscore-Commandos die es in Joses gibt und da gibt es zum Beispiel Equif-Anderscore-Simple die schaue ich einfach nur habe ich irgendwie diese beiden Cones habe ich quasi gemeinsame Inputs die beide Schaltungen treiben bis ich wieder bei einem gemeinsamen Output lande und dann beweise ich mit dem Satz so wie wir die Equivalent sind so simple ist das Equif-Simple nicht wenn ich das mit allen Parametern und Optionen bewerft ist hat also ich kann auch hier wieder sequenzelle Beweise führen dass ich irgendwie sage in dem Kone kann noch Flip Flops dazwischen sein und dann schau da ob ich irgendwie zeigen kann indem man die letzten Endseitschritte berücksichtigt wenn das nicht reicht kann man sogar Temporland Action machen und dann beweisen von solchen Inseln quasi das ist Equif-Anderscore-Indakt ich kann strukturelle Equivalenz beweisen dass ich einfach schaue sind dort exakt die gleichen Zellen und treiben exakt die gleichen anderen Zellen das ist Equif-Anderscore-Strukt das ist zum Beispiel eine wichtige Komponente in einem Timing-Analyse Reverse Engineering ich kann die Lettestools eine Timing-Netzliste erzeugen lassen ich kann meine Tools eine Timing-Netzliste erzeugen lassen diese Timing-Netzlisten müssen strukturelle Equivalent sein die Zellen heißen anders die Wires heißen anders aber es treibt der gleichen Zelltyp den gleichen anderen Zelltyp und ich kann mich quasi von den Input und Output der Schaltung in die Schaltung hinein vorhandeln und am Schluss zeigen das ist wirklich exakt die gleiche Netzliste Gut, also das ist die Idee bei einem Form Equivalence-Check-In Josef sich diese Equif-Zellen habe dass ich alles in ein Modul zusammenwerfe und sich dann unterschiedliche Kommandos verwenden kann um an dieser Schaltung herum zu kauen bis zu dem Punkt dass ich Kasteln Beweise machen kann wo ich aber sage ich wende mal das Standard-Koch-Rezept an und dann klicke ich bei hier sehen wir am Schluss Equif-Status und wenn ich den Equif-Status sage sagt er mir vielleicht von deinen 100 Equif-Zellen hast du 98 bewiesen und dann kann ich zum Beispiel sagen okay erzeugen wir eine Schaltung wo ich nur die letzten beiden Zellen quasi dran habe die ich beweisen muss und dann beweisen dass das immer noch das gleiche ist, dass das noch Equivalence ist über Tempol, Induction, über Exportnen, Blüfffeil und mit IC3 über was auch immer Gut, wir kommen zu dem spannenden Teil also für mich ist das jetzt das spannende Teil und darum ist es im Schluss wenn man joses installiert gibt es einen Programm namens joses und dann gibt es ein paar zusätzliche Programme die joses Binde Strich irgendwas heißen zum Beispiel gibt es ein joses Binde Strich Config das war ein Package Config Ding wo ich dann sage welchen Compiler muss ich verwenden und welche Cflex wenn ich ein Plugin übersetzen möchte so etwas es gibt aber auch ein joses Binde Strich SMT-BMC SMT-Lib machen wir vielleicht wirklich so das haben wir slide SMT-Lib ist eine Sprache die man verwenden kann um mit SMT-Solver zu reden also SMT-Solver mit zusätzlichen Theories die können dann auch Arithmetrik verstehen und gleich solche Ausdrücke optimieren und normalerweise gehe ich her wenn man formale Verifikation machen möchte wenn man sowas programmieren möchte man nimmt irgendein bestehenden Solver nimmt die C-API von dem und programmiert dann irgendwas was über die C-API mit diesem Solver sehr eng verheiratet ist das hat natürlich den Vorteil dass man viel Dichter integrieren kann ich vielleicht nur dieser Solver hat und kein anderer Solver aber es hat den Nachteil dass man jetzt mit diesem Solver verheiratet ist und SMT-Solver das ist ein Feld das bewegt sich im Augenblick sehr sehr flott also eigentlich will ich nicht mit einem Solver verheiratet sein ich will die Freiheit haben jedes Jahr einen anderen Solver zu verwenden wenn ein anderer besser ist also rede ich mit einem Solver über so eine Sprache und SMT-Lib 2 ist so eine Sprache und alle SMT-Solver unterstützen SMT-Lib 2 es hat einen einfachen Grund es gibt jährliche SMT-Solver-Competitions in denen entschieden wird wer ist der beste SMT-Solver im Land und diese SMT-Solver-Competitions verwenden diese Sprache das heißt jeder Mensch der ein SMT-Solver schreibt implementiert diese Sprache oder nie wird irgendjemand erfahren und ich hänge mich da einfach drauf ich verwende genau das gleiche Interface und für die Art von Beweise die ich hier führen möchte funktioniert das ja ganz hervorragend es gibt viele Beweistrategien wo wir irgendwie Tausende von ganz ganz kleinen Beweisen ausführen möchten wie aufeinander aufbauen und diese Interaktivität kann dann machen, dass es besser ist die CRP von einem SMT-Solver zu verwenden als mit allen SMT-Solver und über so eine Schnittstelle reden zu können die Beweise die ich hier verwende da habe ich meistens relativ große Beweise die lange laufen also in Sekunden und ab dem Augenblick wo ich in Sekunden bin ist das wurscht, dass ich da jetzt irgendwie zwei Prozesse starten muss und die reden über eine Pipe und in der Pipe wird da jetzt irgendwie dieses SMT-Lib 2 Text ausgetauscht gut, also SMT-Lib ist eben diese Sprache und joses kann Werelock Designs nehmen oder Designs aus anderen Quellen ich kann natürlich auch Blifterteil lesen aber in der Regel liest mal Werelock Dateien und kann die dann in SMT-Lib 2 Code Snippets umwandeln das ist noch nicht ein vollständiger SMT-Lib 2 Beweis das ist nur eine Beschreibung der Schaltung die man dann verwenden kann in SMT-Lib 2 und joses SMT-BMC kann so eine Datei nehmen und kann dann darauf Beweise aufbauen speziell kann ich mit joses SMT-BMC wieder zwei Sachen machen ich kann Bounded Model Checks machen und ich kann Time Proland Action machen also das sind die beiden Strategien die ich im Augenblick habe das ist in Python geschrieben es ist ein relativ überschaubares Einflussskript also die Magie steckt sozusagen in dem was joses macht beim Kommilitieren auf SMT-Lib 2 Snippets aber auch wenn es sehr klein sein mag hat trotzdem irgendwie sinnvolle Elemente das heißt ich habe hier 2 Teile ich habe das eigentliche Skript und dann habe ich die SMT-IO Python Library die verwendet werden kann um dieses Snippets zu nehmen und in ein SMT-Solver hinein zu baschen das heißt wenn ich einen eigenen Beweis machen möchte wenn ich ein Signal mal in die IC3 implementieren möchte dann kann man das machen und es gibt eine fertige Infrastruktur man muss dann nur noch den Beweis jetzt nochmal Bounded Model Checks und Temporal Induction so das ist ein kleines Beispiel wie so SMT-Lib 2 Code ausschaut, den ich da erzeuge ich hoffe man kann es bis sie lesen muss ich ehrlich sagen ich habe Probleme von hier hier löse ich mal zur Anschauungszwecken kein Schaltungsproblem, sondern ich löse das Puzzle das da unten auf das Slide ist das war equals Money und jeder Buchstabe steht für eine Ziffer ich darf eine Ziffer nicht zweimal verwenden die Anfangsziffer darf nicht null sein das ist das Problem das ich hier löse und das löse ich indem ich eben so eine SMT-Lib 2 Datei schreibe und dann einen SMT-Solver-Aufhof in der Beispiel Rechs 2 in die Z3 dem gebe ich diese Datei und der sagt mal SAD das ist die Reaktion auf das Gegenende von dem Code drüber und dann ruf ich GetValue auf und die Antwort auf GetValue ist das was wir hier dann ausgleichen, dass er sagt irgendwie diese 3 Zahlen das sind die Werte die wir haben was sehen wir in dem SMT-Lib 2 Code wir sehen wir können also ein paar Setup-Dinge machen wir können Optionen setzen in dem Fall setze ich Produce-Models wenn ich das nicht setze, dann kann er mir noch sagen aber wenn ich ihn dann frag was ist in der Value sagt er das weiß ich nicht das habe ich weggupte mir das heißt wenn ich ihn fragen möchte später nach den Values muss ich am Anfang sagen Produce-Models dann setze ich eine Logic das hier ist die QFLIR also Quantifier-Free-Linear-Integer-Arithmetic das ist einfach die richtige Logik für diese Art von Problem wir verwenden eine andere Logik für die Schaltungen die ich erzeuge oder die Schaltungsbeschreibung für die Regie aus Judo dort verwenden wir QF anders QuaAUFBV und das ist Quantifier-Free-Arrays uninterpreted Functions und Bitvectors das einzige was ich wirklich brauche ist Quantifier-Free und Uninterpreted Functions also die Arrays brauche ich nur wenn man Memories hat die Bitvectors brauche ich nur wenn man Corescreen-Sachen hat und irgendwie noch Addierer und so unmittelbar abbilden möchte in Additionen in SMT-Lib und dann demonstriere ich andere Features die wir haben in SMT-Lib 2 Sprache dass ich irgendwie meine Custom Functions definieren kann wie zum Beispiel hier Four-Digits und Five-Digits sind eben zwei Funktionen die ich definiert hab Four-Digits nimmt 4 Integer und nimmt dann das erste und addiert dazu das zweite mal 10 und das dritte mal 100 und das 14.000 und dann kriege ich halt die Zahl die sich aus diesen Digits zusammensetzt und so in etwa schauen diese SMT-Lib da dahin aus und haben dann das einfachen Beispiels ich hab natürlich hier auch ein nettes Beispiel wo wir das jetzt mit Josus verwenden und ein nicht triviales Ding beweisen also nicht trivial, das kann der Sattkorn natürlich auch beweisen ist kein Problem aber es schaut ein bisschen fucht einflößer aus also die Beispiele die wir bis jetzt gehabt haben in diesem Verilockcode auf der linken Seite sehen wir quasi die obere Hälfte von dem Verilock-Feil das ist das eigentliche Modul um das es geht also da haben wir ein Clock-Input wir haben mehrere Zustandsvariable und wir haben einen Always-Block wo ich je nachdem welches andere Dinge hat Dinge raufzähle und runterzähle und ich behaupte quasi während das so vor sich hinrennt werden diese Properties die wir auf der rechten Seite haben immer erhalten bleiben also ich behaupte der Counter wird immer zwischen 100 und 200 stehen der Counter wird immer gleich sein den Wert Count A plus 149 oder wenn das nicht der Fall ist da wird er gleich sein 161 minus Count B und das sind es stimmt also in dem Fall diese Schaltung macht wirklich diese erfüllt diese obscuren Anforderungen am Schluss sehe ich ja noch einmal ein Always-Block einfach nur um nochmal in Erinnerung zu rufen man muss jetzt nicht ein Asset property verwenden sondern man kann eigentlich beliebig komplexe Always-Blocke verwenden oder drinnen ein Asset und das Jung genauso verwenden in der rechten unteren Ecke sehen wir jetzt das Script mit dem ich das diesen Beweis führ das ist ein Shellscript zuerst rauf ich joses auf wieder eine andere Art joses ein Scriptfile mitzugeben ich kann natürlich Minus mitgeben dann liest es ein Scriptfile von der Eingabe und dann kann ich ein Hier-Dokument verenden ich lehste das Wehr-Lock-File schon langsam kennen wir es Read-Wehr-Lock minus Formal ich verwende Prep um ein bisschen Cross-Clean-Synthesie zu machen und dann verwende ich schon gleich writeSNT2 um so ein SNT2-Cut Snipper daraus zu führen und ich habe gesagt quantifier-free-arrays uninterpretative functions und Bitvectors und die arrays sind optional nur wenn ich Memories habe die Bitvectors sind optional wenn ich Cross-Clean habe man muss die Features extra einschalten damit man nicht irrtümmlich Snipplets erzeugt und da verwendet man solver der kann gar keine Arrays zum Beispiel darum erzwinge ich dass man da Minus Memo könnte sich das noch sparen und da zeige ich jetzt so eine SMT2-Datei das ist der JOSUS-Teil und jetzt kommt dann der JOSUS-SMT-BMC-Teil mit dem ich den formalen Beweis führe über diese Repräsentation der Schaltung der erste Aufrufe macht ein paar 100 Model-Check ich glaube wenn ich keine Schrittanzahl angebe macht er 20 Schritte, wir werden es gleich sehen und das zweite macht Temporland Action da gebe ich eine Maximalanzahl von Schritten an ich glaube die ist auch bei die Fall 20 aber da arbeitet er quasi von oben runter und schaut quasi wie viele Schritte brauche ich nicht damit ich quasi einen unglaublich großen Beweis aufbaue und dann rennt der SMT-Solver Ewigkeiten bis er nachgedacht hat über diesen riesigen Beweis der über 100 Hackzügeln geht und wirklich hätten wir 2 Hackzügeln gereicht das wäre verschwenderisch ich glaube das folgt uns anschauen so und das ist bewiesen also wir sehen hier die 20 Hackzügeln von dem Bounded Model-Check die Zeit hätte ich mal sparen können in dem Fall und er macht quasi einen schrittweise größeren Beweis also er beweist nicht auf einmal alle 20 Zügeln das wäre dumm, weil man ein bisschen was versteht wenn man ein formalen Beweise aufgebaut ist sondern er beweist quasi zuerst den ersten Schritt dass es die SRS alle im ersten Zeitschritt stimmen das ist praktisch wenn ich jetzt den zweiten Zeitschritt beweise dann kann ich auf einmal den ersten Zeitschritt assume ich habe gerade bewiesen das gilt, das heißt ich kann es umdrehen ich kann sagen, ich beweise nicht den ersten beiden den ersten habe ich schon das ist eine Annahme und damit kann ich den Beweis ein bisschen schlanker halten 20 Tackzügeln auf einmal geben und sagen, beweise, dass meine SRS immer halten gut, das ist dieser obere Teil das ist das Ende von dem ersten Aufruf zweiter Aufruf ist Temporal Induction und wir sehen hier wir hätten gar nicht 20 Züklern gebraucht zwei Züklern hätten gereicht auch zwei Züklern hat er bereits bewiesen dass diese Eigenschaften alle stimmen eine Sache die sehr wichtig ist zum Wissen, wenn man mit solchen formalen Beweisen arbeitet die ein bisschen kaum der Intuitiv ist am Anfang ist, dass mehr Asserts einfacher sind also Leute denken sich, ah, ich will das tool nicht zu sehr belasten ich will nur, dass es diese Eigenschaft überprüft aber eigentlich, wenn man sich es überlegt je mehr Asserts ich habe desto mehr Einschränkungen gebe ich ihm auf den State Space und wenn ich Temporal Induction zum Beispiel machen möchte wo ich die Annahme habe wenn ich jetzt schon Endzüklern habe vielleicht kann ich von dem schließen dass im Ende plus ersten Züklern auch alle meine Asserts gelten was es sich zusammen fantasiert für diese ersten Endzüklern ist natürlich ein viel breiterer Raum von Möglichkeiten, wenn ich weniger Asserts habe und das heißt wenn ich jetzt irgendeine dieser Asserts deaktiviere mal die da zum Beispiel sollte das vorher testen sollen das war ein schlechtes Beispiel das Asserts schaue ich auch nicht wichtig aus, oder? ja, das ist wahr also das wird nicht viel bringen so mal schauen der bitte irgendeines von denen muss er wichtig sein also wenn man dann alle Asserts los hat dann ist es auch wieder sehr schnell ich glaube ich tue mich an einen falschen Asserts spielen vielleicht soll ich ihm die oberen lassen mal die weg also jetzt haben wir den Fall jetzt habe ich immer ein paar Asserts weggenommen und er hat nicht nur zwei Taktzüklern gebraucht sondern sechs aber das sieht man quasi, mehr Asserts ist besser und das ist dann eigentlich auch gleich eine gute Abschlussbemerkung an der Stelle zu diesen Asserts dass häufig hat man häufig macht man das nicht von Anfang an dass man Asserts in den Designs einbaut so macht man den Design, wird schon funktionieren und dann hat man ein Problem in der Praxis und denkt sich, hm, vielleicht könnte ich mit formaler Verifikation draufkommen was da schiefrennt und dann habe ich irgendwann mein Design mit tausenden und abertausenden von Seilen und ich weiß es wird ziemlich gut funktionieren mit formaler Verifikation das Problem einzugrenzen wenn das Vollwehr mit Asserts aber wenn ich jetzt nur mein Einassert hineinschreiben möchte für das eine Ding was mich gerade interessiert dann kann es sein, dass mir das auf den Kopf fällt und das vorstellt ok, das war's danke also hinter diesem QR Code oder unter diesem Link sind dann jetzt auch schon die Slides ich werde dir dann nachher auf meiner Website noch verlinken da sind auch zum Download die Examples die, die wir uns angeschaut haben und die, die wir noch auf den Slides gesehen haben falls jemand damit herumspielen möchte ich habe da hinten 3 noch 20 weitere Slides wenn sich jemand für mehr interessiert zu den Grundlagen von den von den Dingen über die wir da gesprochen haben jetzt glaube ich haben wir nicht mehr die Zeit wir haben nur noch ein paar Minuten ich glaube wir können noch ein paar Fragen machen da gibt es noch Fragen oh, ich brauche nicht wiederholen, das ist aber Luxus zu deinem ich hab's allen gehört also, ah, hört man mich ok Pico Risk 5 Design hast du da die Formalen Verifikationsmethoden angewendet in welchen Bereichen kann man da so eine Aussage treffen so grob, so und so viel Prozent sind gecovert oder also nicht so sehr wie ich gerne hätte es gibt zwei Dinge die ich mit Formaler Verifikation mache mit dem Pico RV32 und das ist Teil von dem Pico RV32 Repository gibt es ein Skripsverzeichnis und da gibt es eine Formale Beweise und zwar gibt es beim Pico RV32 eine ganze Reihe von Konfigurationsparametern die Features ein- und ausschalten wie zum Beispiel Interrupt Controller und was ich beweisen möchte ist quasi, dass wenn ich einen dieser Coars gut getestet habe dass der wirklich funktioniert dass ich die anderen Coars übertragen kann weil nichts mehr blöder wenn jetzt unglaublich viele Leute den Coars in FPGAs verwenden und dort natürlich ein Set von Parametern haben und dass wir dann in der Praxis guter Propter Coars, jeder weiß dass funktioniert und dann kommt jemand und sagt ich will in einem ASIC verwenden aber weil ASIC ein bisschen andere Anforderungen hat verwendet ein paar andere Werte für gewisse Parameter überhaupt nicht getesteter Coars weil niemand hat das bis jetzt so gemacht das heißt da wollte ich formale Verifikation verwenden um quasi das gleiche Verhalten zu zeigen und da gibt es zwei Varianten SYNC und ASSYNC SYNC vergleiche zwei Coars die das gleiche extern beobachtbare Timing Verhalten haben und ASSYNC vergleiche zwei Coars die nicht das extern gleiche Timing Verhalten haben das heißt der ASSYNC Test ist da eigentlich aus oder ist es zu Ende dann explodierte Komplisität von dem aber zumindest für 15 Tag Zügel kann ich sagen egal was der Initial Registrinhalt ist egal was der Memoereinhalt ist der gelesen wird über 15 Tag Zügel werden diese Coars nicht divergieren in ihrem Verhalten und das ist relativ stark wenn man sich überlegt damit, dass ich den gleichen Registrinhalt gut Instructions simulieren sozusagen sondern ich würde gleich die Instruktion finden die divergiert und die scheint es nicht zu geben also was mache ich was ich nicht mache bei PicoRV32 ist, dass ich ihm HDL-Co ZIG Asserts hab ich habe da mal ein paar Asserts eingebaut weil ich es für den Vortrag gebraucht hab da wollte ich hier ein echter Coar schneller ein paar Asserts einbauen aber ansonsten habe ich das hier nicht verwendet gut, sonst fragen passt, dann sage ich noch mal Danke für die Aufmerksamkeit ich bin dann auch hier die ganze nächsten Tage und wenn es noch Fragen gibt, einfach zu mir kommen und mit mir plaudern