Hallo liebe Gemeinde! Ich habe einen Prozessor in Verilog beschrieben, er umfasst knapp 1500 Zeilen Code. Nun wollte ich den mal synthetisieren (bisher hab ich immer nur auf der Verhaltensebene simuliert) und musste feststellen, dass XST nach 30 Stunden CPU-Zeit und knapp 400 MB RAM (von 512 MB) immer noch am werkeln war. Ich habs jetzt erstmal abgebrochen, weil mir das so nichts bringt. Was ist die Ursache dafür (und kann man da was dran ändern)? Was ich mir als Ursachen vorstellen könnte: - Das Design besteht aus mehreren ineinandergreifenden Zustandsmaschinen und ist komlpett in einem Modul untergebracht. - XST hat sich weggehängt (Es gab allerdings immer mal wieder ein paar Ausgaben) - Der RAM ist so klein, daß der Vorgang extrem ausgebremst wird (Die HDD-Lampe war aber kaum an) Wäre echt toll, wenn ihr mir als Anfänger mit ein paar Praxiserfahrungen aushelfen könntet. :-) Viele Grüße, Markus
Hi, ich weiß aber von unserem VHDL Prof., dass er bei seinem Rechner auf mind. 4GB Speicher und möglichst schnellen Prozessoren besteht und eine Synthese dann auch immer nochmal stunden dauern kann. Darüber hinaus ist wohl XST eher ineffizient (dafür aber kostenlos). Leonardo Spektrum soll angeblich im Ergebnis deutlich besser sein. Obs schneller läuft, weiß ich aber auch nicht. Persönlich hatte ich noch keine größeren Projekte, so dass ich dir nur vom hörensagen berichten kann. Ich hoffe, dass dir das wenigstens ein bischen weiterhilft. Gruß, Thomas
Das XST Tool läuft auch auf "kleinen" Maschinen ganz anständig. Die Synthese ist sowieso nicht der zeitraubenste Teil, sondern das Place & Route. Selbst bei größeren Modulen läuft die Synthese oft relativ schnell durch, bei mir auf dem Lappi mit 735 Centrino & 512MB RAM hatte ich noch nie Probleme damit. Das einzige was ich mir vorstellen kann, dass es Teile gibt, wo er an der Optimierung abstirbt. Sowas hatten wir mal bei Leonardo Spectrum (wär mit jedem anderen auch so gewesen) als ein Clocktemplate alle FF in einem FPGA Bereich allokiert hat. Da hat die Optimierung (die da eigentlich keine war, weil da gabs nichts zu optimieren ;-)) 10 Minuten oder mehr gedauert...
Hallo Markus, wenn die Synthese so lange dauert, ist höchstwahrscheinlich was in deinem Code falsch bzw. für die Synthese nicht geeignet. Auf meinem PIII mit 800 MHz und 256 MB RAM dauert die Synthese von etwa 1000 Zeilen etwa 2 Minuten. Im Gegensatz zu Software-Compilern ist die Synthesezeit natürlich unter Umständen nicht mal annähernd proportional zur Größe des Quellcodes. Bei sehr großen Entwürfen kann ich mir schon vorstellen, dass auch ein moderner Rechner mehrere Stunden rechnet, wobei für die Synthese meines Erachtens keine gigantischen Mengen Speicher nötig sind, eher später für das Place&Route. Darf ich mal fragen, ob du von der Software-Seite kommst? Da du dich als Anfänger bezeichnest, vermute ich, dass du "Software" beschrieben hast und keine "Hardware" und dass daher dein Entwurf einfach praktisch nicht synthetisierbar ist - dass du das alles in einer Datei hast, spricht auch sehr dafür. Daher zwei Tips: 1. Klein anfangen! 2. Kleine Module machen, erst mal einzeln synthetisieren und schauen, was rauskommt. Ein HDL-Modul, welches sich nicht in kleinere von maximal 100 Zeilen zerlegen lässt, ist höchstwahrscheinlich unbrauchbar (Ausnahmen bestätigen die Regel-aber nicht bei Anfängern). Gruß, Thomas
Hallo! Ja, mein Entwurf ist offenabr äusserst schwer bis gar nicht zu synthetisieren. Ich habe mal den PicoBlaze übersetzt, der war in ca. 2 Minuten komplett implementiert. Dort haben sie allerdings auch nur vorgefertigte Einheiten benutzt und kein generisches Veriog. Der Knackpunkt ist vermtlich die Zustandsmaschine, die sich um die Befehle kümmert. Die hat ca. 75 Zustände (für jeden Befehl einen) und wenn der Aufwand für die Synthese hierbei womöglich exponentiell wächst, dauert das natürlich unangenehm lange. :-) Beim beschreiben synchroner Hardware tue ich mich irgendwie schwer. Kennt einer von euch dazu ne Einführung, wie man das synthesefreundlich beschreibt? Danke für eure Hilfe! Viele Grüße, Markus @Thomas: Ich bin eigentlich irgendwo zwischen Soft- und Hardware, aber ich habe deutlich öfter (sequentuielle) Prozessoren programmiert als ich Hardware beschrieben habe. Du dürftest also recht haben mit deiner Annahme. Allerdings lässt sich ein Prozessor schlecht in kleine Blöcke zerlegen finde ich. (Ja, das muss gleich beim ersten mal ein ganzer Prozessor sein, sorry ;)
Moin... > Beim beschreiben synchroner Hardware tue ich mich irgendwie schwer. > Kennt einer von euch dazu ne Einführung, wie man das > synthesefreundlich beschreibt? Würde malsagen, das ist der Grund für die extreme Zeit. Wenn du nicht synchron zu einem Takt arbeitest, brichst du der Synthese den Hals da die Anzahl der Zeitbeziehungen explodiert. Ein Takt für alles, steuern kannst/musst du mit enables/select, dann kommt auch was brauchbares raus,. -- SJ
Hallo noch mal Markus, ein Prozessor besteht sehr wohl aus sehr vielen unterscheidbaren Einheiten. Du musst dir schon mal überlegen, wie dein Entwurf so etwa in Hardware aussehen wird/soll. Was soll alles gleichzeitig ablaufen, was nacheinander, was auf mehrere Takte verteilt werden etc.? Irgendwo wird es sicher einen Befehls-Pfad geben, ggf. mit verschiedenen Stufen (Pipelining), und sicher einen Datenpfad. Bei einer von-Neumann-Architektur gehen beide teilweise ineinander über, sollten sich aber dennoch weitgehend unabhängig voneinander beschreiben lassen. Schließlich wird es einen Teil geben, der die Befehle dekodiert und Steuersignale für Befehls- und Datenpfad sowie externe Module erstellt. Aus einer einfach abgeschriebenen bzw. in Verilog umgeschriebenen Tabelle mit Maschinencodes wird nie ein synthetisierbarer Prozessor entstehen - schließlich liegt die Kunst des Prozessor-Baus ja gerade darin, die Abarbeitung der Befehle zeitlich so zu organisieren, dass ein halbwegs schneller Prozessor bei realisierbarem Platzbedarf entsteht. Unabhängig davon, ob es sich um ein FPGA oder einen "echten" Prozessor handelt. Ohne Kenntnisse über den Aufbau und die Funktionsweise von Prozessoren ist dein Vorhaben absolut aussichtslos. Für den Einstieg kannst du dir ja mal meinen Prozessor hier anschauen (Thread: 16-bit Mikroprozessor). Wenn du den vollständig verstanden hast, verstehst du sicher, warum dein Entwurf nicht synthetisierbar ist und kannst das vielleicht ändern. Gruß, Thomas
Hallo Thomas und natürlich auch alle anderen, :) ich wollte euch wenigstens noch mitteilen, was ich rausgefunden habe. Daß die Synthese so lange gedauert hat, lag wohl daran, daß der Optimizer sich verlaufen hat zwischen all den tausenden Zellen des distributed RAMs. Da auf diesen nicht synchron zugegriffen wurde und sonst auch keinerlei constraints gestellt waren gabs da wohl nahezu beliebig viel zu optimieren. Mit BlockRAMs geht das schon viel besser. Ich wäre ja froh, wenn es ein richtiger[tm] Prozessor werden würde, den man sich nahezu "nach belieben" in kleine Module aufteilen kann und dann alle verdrahtet. Das dies aber eine 0-Adress Architektur ist, kommt dem Befehlsdekoder die größete Bedeutung zu, der Rest besteht aus Stacks und dem gekonnten Hin- und herschieben zwischen diesen. Dazu kommt noch, daß die Sprache (CIL) nie für eine Hardwarerealisierung gedacht war und entsprechend ineffizient zu implementieren ist. Aber mehr als zu funktionieren braucht es glücklicherweise nicht. :) Viele Grüße, Markus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.