hallo zusammen. gibt es irgendwo coding-guidelines, wie man am besten synthesefreundlich programmiert? insbesondere auch, welche teile mit vhdl zwar beschrieben werden können, welche die synthese aber einfach nicht synthetisieren kann, würden mich interessieren. klar, "wait for"-statements machen dabei keinen sinn, aber da wird es wohl noch mehr geben? gruss, seraphe
Some User schrieb: > klar, "wait for"-statements machen > dabei keinen sinn, aber da wird es wohl noch mehr geben? Wait for geht nicht, aber einige überraschende Sachen können Synthesetools durchaus: http://www.lothar-miller.de/s9y/archives/47-wait-im-Prozess.html Ich habe ein paar Postulate, die das Leben einfacher machen:
1 | Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, |
2 | der immer auf dieselbe Flanke aktiv ist. |
3 | Es gibt keinen (und schon gar keinen asynchronen) Reset. |
4 | Externe Signale werden über 2 Flipflops einsynchronisiert. |
5 | Jede Abweichung von diesen Regeln muß fundiert begründet werden können. |
Eigentlich die beliebteste Fehlerquelle ist (neben dem dem asynchronen Reset) das unzureichende einsynchronisieren von externen Signalen: http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren Für Xilinx gibts den XST User Guide, in dem synthetisierbare VHDL-Beschreibungen definiert sind.
Für Xilimx gibt es die XST User Guide, dort steht drinnen welche VHDL Konstrukte unterstützt werden. Ansonsten gibt es die allgemeine Norm IEEE 1076.6, welche Konstrukte definiert, die ein VHDL Compiler für die RTL Umsetzung beherrschen soll.
Wenn ich VHDL für Synthese schreibe, versuche ich mich so weit wie möglich an folgendes zu halten: Prozesse sind entweder rein kombinatorisch oder reine Flip-Flops (natürlich nicht jedes einzelne in einem Prozess, sondern ganze Registerbänke). Und da bin ich ziemlich kompromisslos. Ausser vielleicht bei einfachen Zählern - wobei - auch da versuche ich, mich daran zu halten. Der Grund ist einfach der: Ich will von jedem Flipflop wissen, warum es da ist. Nur so kann ich ganz sicher verhindern, dass der Synti irgendwelches komisches Zeug macht, das eben nicht den klassischen Design-Regeln entspricht. Und wenn ich irgendwo ein FF entdecke, welches ich nicht in voller Absicht hingepflanzt habe, weiss ich, dass ich irgendwo 'nen groben Schnitzer gemacht habe. Mir wurde schon erwidert, dass das für grosse Designs nicht praktikabel sei. Diese Meinung teile ich nicht. Gruäss Simon
Simon Huwyler schrieb: > Mir wurde schon erwidert, dass das für grosse Designs nicht praktikabel > sei. Diese Meinung teile ich nicht. Ich bin vollständig deiner Meinung, Simon. Ich lasse mich auch bei großem Designs nicht davon abschrecken, wissen zu wollen, wofür Flipflops da sind. Es freut mich sehr, dass es auch noch andere Aufrechte gibt. @Lothar: Was meinst Du genau mit: "Es gibt keinen (und schon gar keinen asynchronen) Reset."?
Harald Flügel schrieb: > Es freut mich sehr, dass es auch noch andere > > Aufrechte gibt. Gleichfalls! :-) Wegen dem (asynchronen) Reset: Das ist auch ein immer mal wiederkehrender Streitpunkt unter VHDL Designern. Im ASIC Design ist klar, dass jedes FF resetted werden muss. Das mach in FPGAs (zumindest den RAM-basierten) keinen Sinn, da die FFs ja eh definierte Zustände haben, nachdem das Binary geladen worden ist. Xilinx hat einige Papers darüber geschrieben, dass asynchrone Resets in ihren Produkten oft sehr teuer sind, da ihre Zellen eben nicht dafür ausgelegt sind. Eben, weil man in einem FPGA in aller Regel kein Reset braucht.
Ach ja, von wegen Design-Regeln: Bei der Namensgebung mache ich das so (das ist natürlich individuell): Ein FF hat bei mir immer [signal] als Ausgang und [signal]_next als Eingang. Also z.B. someState und someState_next In der Kombinatorik sehen dann State-Zuweisungen immer irgendwie so aus: someState_next <= .... Auf der Rechten Seite dürfen kene _next-Signale sein. und im FF dann someState <= someState_next Wenn man strickt nach so einer Regel codet, merkt man jeweils sofort, wenn man gerade versucht ist, einen kombinatorischen Loop oder sonstwas Unheiliges zu generieren.
Gut, ich weiß schon dass ich da päpstlicher bin als der Papst. Trotzdem wende ich auch bei allen meinen FPGA-Designs den ASIC-Designflow an. Wenn man den mal verinnerlicht hat, dann kann man gar nicht mehr anders, finde ich. Aber trotzdem nochmal zum Reset. Ich weiß ja nicht, wie das bei Xilinx ist, aber bei Altera gibt es da eine tückische Stelle. Nach dem Laden der Konfiguration sind alle Flipflops 0. Wenn sich das Synthesetool aber entschlossen haben sollte, für ein Flipflop die inverse Funktion zu generieren, dann ist der Zustand des (logischen) Ausgangssignals nach der Konfiguration 1. Damit ist eine FSM zu Beginn möglicherweise in einem undefinierten Zustand. Wenn das passiert (not gate push-back), dann wird das zwar als Warnung gemeldet, aber liest schon alle 695 Warnungen penibel durch? Gut, man kann diese Optimierung auch ausschalten, aber damit wird das Systheseergebnis schlechter. Ein externer Reset, natürlich einsynchroniert, ist daher meines Erachtens für alle FPGA-Design Pflicht. Ich hätte jetzt angenommen, dass das bei Xilinx auch so ist, vielleicht kann ja einer der sehr erfahrenen Xilix-User etwas dazu sagen.
Harald Flügel schrieb: > Was meinst Du genau mit: > "Es gibt keinen (und schon gar keinen asynchronen) Reset."? Du mußt dir grundlegend mal die Frage stellen (lassen): Wofür brauchst du so einen Reset überhaupt? Für den Reset-Taster, um dein Design in einen "ordentlichen" Zustand zu bringen? Sieh dir dazu das WP272 von Xilinx an. Im einzelnen im Beitrag "Xilinx und die Resets" ff. Zusammengefasst: FFs können bei Xilinx in 2 Modi konfiguriert werden: asynchron oder synchron. Und wenn ein asynchroner Reset verwendet ist, dann kostet ein synchroner Set (z.B. bei Zählern) zusätzliche Logik. Speziell zum asynchronen "Generalreset", der von aussen kommt: Das ist prinzipiell ein asynchrones Signal (das asynchronste überhaput)! Und asynchrone Signale gehören einsynchronisiert. Denn: was passiert, wenn du zwar hübsch im Resetzustnad bist, dann aber asynchron den Reset verlässt? Ein paar FFs irgendeiner FSM sehen dann evtl. (abhängig von Laufzeiten im FPGA) noch einen Reset, die anderen legen schon mal los. Das kann böse ins Auge gehen: "Mein Design läuft nur jedes 2. oder 3. mal richtig an." http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Und was sehr sehr böse ist: so ein asynchroner externer Reset reagiert u.U. recht eigenartig auf Störspitzen, die am Reset-Pin auftreten können. Wenn ein sehr kurzer Spike kommt, dann reicht dessen Dauer u.U. nur zum Reset von ein paar FFs, und du hast jedesmal ein anderes Fehlerbild.
Hallo Lothar, jetzt haben wir fast zeitgleich gepostet und reden knapp aneinander vorbei. Ein asynchroner Resets ist Gift, das steht fest. Aber zu deiner Frage: > Du mußt dir grundlegend mal die Frage stellen (lassen): > Wofür brauchst du so einen Reset überhaupt? Für den Reset-Taster, um > dein Design in einen "ordentlichen" Zustand zu bringen? 1. Um Source-Level-Simulation und Gate-Level-Simulation und Reale Welt mit der gleichen Anfangssituation starten zu lassen. 2. Siehe Posting von vorhin (not gate push-back)
Die Resets wurden hier schonmal recht ausfühlich diskutiert (Beitrag "Theoriefrage asynchroner Reset"). Die Xilinx-FPGAs wünschen sich einen synchronen Reset. Die kleinen Alteras (Cyclone) profitieren deutlich von einem asynchronen Reset, der aber tunlichst mit 2 FFs auf die Clockdomain einsynchronisiert werden sollte. Die Stratixe generieren für beide Varianten vergleichbare Designs. Was die Resets (und andere Hardware-bezogene Empfehlungen) angeht, darf man auf keinen Fall reflexartig irgendwelche irgendwo gelesenen oder gelernten Dinge annehmen, sondern man muss sich mit der Zielplattform auseinandersetzen. Und Datenblätter/Whitepapers lesen. Und selber testen. Die Aussage "Bei FPGAs muss der Reset immer xzy sein" ist definitiv falsch!
Harald Flügel schrieb: > 1. Um Source-Level-Simulation und Gate-Level-Simulation und Reale Welt > mit der gleichen Anfangssituation starten zu lassen. Also eigentlich "nur" zur Entwicklung... Das können Lattice und Xilinx zwischenzeitlich mit Defaultzuweisungen erledigen, weil bei SRAM-basierten FPGAs sowieso beim Startup jedes einzelne FF per Handschlag verabschiedet werden muß: [vhdl] signal b : std_logic := '1'; signal v : unsigned(7 downto 0) := x"12"; signal i : integer := 1234; [/vdhl] Ein Gast schrieb: > Die Aussage > "Bei FPGAs muss der Reset immer xzy sein" ist definitiv falsch! Die Aussage "Wenn kein Reset nötig ist, dann weglassen" ist aber definitiv richtig. ;-) Und wie gesagt: gerade Anfänger denken eben nicht darüber nach, sondern "plappern" einfach das nach, was im Lehrbuch (des Professors) steht. Und das ist meist der Technologiestand von vor 10 Jahren...
> Prozesse sind entweder rein kombinatorisch oder reine Flip-Flops D.h. du trennst die Berechnung der neuen Werte auf in einen kombinatorischen Teil und den getakteten Prozess, der nur <=-Zuweisungen hat und kein if bzw. sonstige Berechnungen? Das entspricht wohl grob der Art, die auch zB. Gaisler in seinen Codes (Leon) nutzt. Ich finde den Stil jedenfalls grässlich und nur schwer lesbar. Die Absicht, jedes FF persönlich zu kennen, ist ja auch in Verilog zementiert mit den wires/registers, und da verstehe ich sie auch nicht, das hängt mir irgendwie zu tief an der HW. Ich nehme eine HDL doch deswegen, um von dem niedrigen Level etwas wegzukommen...
Georg A. schrieb: > Ich finde den Stil jedenfalls grässlich und nur schwer lesbar. Zudem führt die 2-Prozess-Schreibweise bei Anfängern ganz gern zur kombinatorischen Schleife: http://www.mikrocontroller.net/search?query=kombinatorische+Schleife&forums[]=9&max_age=-&sort_by_date=1 http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html Simon Huwyler schrieb: > Der Grund ist einfach der: Ich will von jedem Flipflop wissen, warum es > da ist. Blöd nur, dass die Synthese die ganzen Dinger bei Bedarf sowieso einfach wegoptimiert bzw. zusammenfasst... > Prozesse sind entweder rein kombinatorisch oder reine Flip-Flops Von dieser Schreibweise hat VHDL seinen Ruf, eine "geschwätzige" Beschreibungssprache zu sein. Georg A. schrieb: > Ich nehme eine HDL doch deswegen, um von dem niedrigen Level > etwas wegzukommen... Ich auch. Allerdings habe ich immer im Hinterkopf, dass alles, was ich da schreibe später irgendwie in LUTs und FFs abgebildet werden muß.
Auch wenn schon viel über den Reset gesagt wurde, möchte ich noch einen Aspekt anführen. Wer eine digitale Schaltung in einer Hardwarebeschreibungssprache modelliert, der sollte portablen Code schreiben, sofern das keinen unzumutbaren Mehraufwand darstellt. Ich schreibe ja auch keinen Software-Algorithmus, der nur auf dem Prozessor XYZ läuft. Algorithmen und Modelle sollten IMHO lösgelöst von der ausführenden Architektur sein. Natürlich geht das nicht immer, aber man sollte es zumindest versuchen.Und wenn Xilinx einen Weg weiß, wie man Xilinx FPGA ohne Reset betreibt, dann ist das ja ganz hübsch, aber leider ohne Relevanz. Für das Modell einer digitalen Schaltung heißt das aber nicht, dass ich mich von dem entfernen darf, was Hardware an sich ist. Zitat von Lothar: Allerdings habe ich immer im Hinterkopf, dass alles, was ich da schreibe später irgendwie in LUTs und FFs abgebildet werden muß. Zitat Ende. Zustimmung! Besser kann man das nicht sagen. Doch nochmal zurück zum Reset: Es gibt überhaupt keinen sinnvollen Grund, bei einem digitalen Design den Reset-Pin wegzulassen. Unstrittig ist wohl, dass der Reset-Pin nicht an die asynchronen Reset-Eingänge der Flipflops gelegt werden darf. Das Signal am Reset-Pin muss einsynchronisiert und am besten noch mit einem Filter beaufschlagt werden, das mehrere Takte lang eine Reset-Anforderug erkennen muss, bevor es diese an die Flipflops des Design weitergibt. Solche Sachen müssen sein. Aber ein Design ohne Reset-Pin? Da läuft die Source-Level Simulation keine zwei Takte weit! Und vor der Implementierung steht die Simulation.
Ich mach meine entities auch immer mit ansychronem Reset. Der geht dann die ganze Hierarchie durch und wird in der Simulation auch getrieben. In der Synthese wird der Wert dann "oben" einfach auf 0 gesetzt, der ganze Resetbaum selbst fällt weg, aber die initialen Werte bleiben übrig. Einen echten Resetpin habe ich lustigerweise noch nie gebraucht. Keine Ahnung, was ich da falsch mache, allerdings mache ich nur FPGAs ;) Ich finde den expliziten Reset im Prozess auch irgendwie schöner und "konzentrierter" als die Zuweisung bei der Signaldefinition, die ja meistens recht weit weg ist. Soweit möglich versuche ich auch, identisch getaktete, aber eigentlich separate Funktionen in einer Architecture in einzelne Prozesse aufzusplitten, das bringt die Initialisierung noch näher an den Code ran. Aber ist halt wie in anderen Sprachen auch, der eigene Codingstyle ist der Beste und der des anderen ist immer Mist... Aber man könnte sich auf einen Worst-Case-Style einigen, wie man es gar nicht machen sollte :) Da ist IMO der Code von diversen Xilinx-IP-Cores auf Platz 1 der Kraut&Rüben-Hitliste. Selten sowas Unlesbares gesehen. Kapselung jeder Winz-Funktion in Entites mit unzähligen Generics, daraus tieeeefe Hierarchien, bestehend hauptsächlich aus Umverdrahtung der port maps, belang/inhaltslose Ewigkeitskommentare ala "Signal and Type Declarations". Toll, hätte ich jetzt nach dem architecture-Keyword gar nicht erwartet ;)
Harald Flügel schrieb: > ... Unstrittig > ist wohl, dass der Reset-Pin nicht an die asynchronen Reset-Eingänge der > Flipflops gelegt werden darf. Das Signal am Reset-Pin muss > einsynchronisiert und am besten noch mit einem Filter beaufschlagt > werden, das mehrere Takte lang eine Reset-Anforderug erkennen muss, > bevor es diese an die Flipflops des Design weitergibt. Aber nach dem Filtern und einsynchronisieren darf ich das Signal an den asynchronen Reseteingang legen. Bei Architekturen, bei denen die FlipFlops neben dem synchronen Eingang (der normalerweise an der LUT hängt) noch einen asynchronen Eingang haben, kann ich so wertvolle Resourcen sparen. Hier muss das Resetsignal nicht durch die LUT und verbraucht keine wertvollen Eingänge derselben. Dass es auch Architekturen gibt, bei denen das keinen Vorteil bringt, ist ein anderer Punkt...
Harald Flügel schrieb: > Auch wenn schon viel über den Reset gesagt wurde, möchte ich noch einen > Aspekt anführen. Wer eine digitale Schaltung in einer > Hardwarebeschreibungssprache modelliert, der sollte portablen Code > schreiben, sofern das keinen unzumutbaren Mehraufwand darstellt. Spätestens wenn FPGA spezifische Komponenten einsetzt ist der Code nicht mehr portabel. In den meisten Firmen werden ohnehin nur FPGAs von einem Hersteller eingesetzt. Sodass es gar nicht nötig ist, dass man portablen Code erstellen muss. Ich > schreibe ja auch keinen Software-Algorithmus, der nur auf dem Prozessor > XYZ läuft. Algorithmen und Modelle sollten IMHO lösgelöst von der > ausführenden Architektur sein. Natürlich geht das nicht immer, aber man > sollte es zumindest versuchen. Warum? Es kostet nur Zeit und FPGA-Ressourcen. Vor allem setzt es voraus, dass man sich im Vorfeld darum kümmert, welche Funktionen/Eigenschaften auf einer anderen Plattform nicht zur Verfügung stehen. Das ist fernab jeglicher Realität. > Und wenn Xilinx einen Weg weiß, wie man > Xilinx FPGA ohne Reset betreibt, dann ist das ja ganz hübsch, aber > leider ohne Relevanz. > > Für das Modell einer digitalen Schaltung heißt das aber nicht, dass ich > mich von dem entfernen darf, was Hardware an sich ist. Zitat von Lothar: > Allerdings habe ich immer im Hinterkopf, dass alles, was ich da schreibe > später irgendwie in LUTs und FFs abgebildet werden muß. Zitat Ende. > Zustimmung! Besser kann man das nicht sagen. Richtig. Ich habe mich mal hingesetzt und ein mittleres Design für einen Spartan3 von Signal-Initialisierungen auf ein synchrones Reset umgestellt. In der Art
1 | process (clk) |
2 | begin
|
3 | if rising_edge (clk) then |
4 | if reset = '1' then |
5 | Initialisierungen
|
6 | else
|
7 | FSMs und alles weitere |
8 | end if |
9 | end if |
10 | end process |
Das hatte einen deutlich höheren Logikaufwand zur Folge. Da das Reset als zusätzliches Signal in jede Logikfunktion mit eingeht. Wenn es dadurch mehr als vier Signale (Spartan3) für eine Funktion werden, ist eine weitere LUT notwendig. Das Reset habe ich vom Lock der DCM abgeleitet. > > Doch nochmal zurück zum Reset: Es gibt überhaupt keinen sinnvollen > Grund, bei einem digitalen Design den Reset-Pin wegzulassen. Wozu braucht man ein Reset-*Pin*? Bei Prozessoren nur dann, wenn der Programmierer so doof ist und sein Programm in eine endlos-Schleife laufen lässt. Wenn du also nicht in der Lage bist eine Logik zu beschreiben, die nicht in Endlos-Schleifen läuft, dann brauchst du ein externes Reset-Pin, sonst nicht. Ich sehe ein, dass man ein Signal für einen einmaligen definierten Anlauf nach dem Power-Up braucht. Aber eine gutes FPGA-Design braucht kein externes Reset. Wer sollte das auch im normalen Betrieb betätigen? Guten Morgen Tom
Florian V. schrieb: > Aber nach dem Filtern und einsynchronisieren darf ich das Signal an den > asynchronen Reseteingang legen. Bei Architekturen, bei denen die > FlipFlops neben dem synchronen Eingang (der normalerweise an der LUT > hängt) noch einen asynchronen Eingang haben, kann ich so wertvolle > Resourcen sparen. Hier muss das Resetsignal nicht durch die LUT und > verbraucht keine wertvollen Eingänge derselben. > Dass es auch Architekturen gibt, bei denen das keinen Vorteil bringt, > ist ein anderer Punkt.. ... und er hat damit schon Recht, aber leider gibt es wieder ein Aber. Wenn Du die Logik mit einem asynchronen Reset modellierst und die verwendete FPGA-Familie keinen asynchronen Reset bietet, dann erzeugt der Synthesizer eine zusätzliche Schaltung am Ausgang des Flipflops, die das Signal bis zum nächsten Clock auf den Resetzustand hält. Das ist auch nicht gerade optimal. Daher modelliere ich immer mit synchronem Reset, und nur wenn das Timing nicht hinhaut, dann schaue ich mir die kritischen Pfade an, ändere die Modellierung an wenigen Stellen ab, und schreibe das als Kommentar in das Modell. Thomas Reinemann schrieb: > Spätestens wenn FPGA spezifische Komponenten einsetzt ist der Code nicht > mehr portabel. In den meisten Firmen werden ohnehin nur FPGAs von einem > Hersteller eingesetzt. Sodass es gar nicht nötig ist, dass man portablen > Code erstellen muss. Auch das ist selbstredend korrekt. Für mich aber kein Grund, meinen Pfad der Tugend zu verlassen. Um jede spezifische Komponente wird bei mir ein Wrapper gewickelt, sodass man leicht die Komponente darin auswechseln kann. Alle IP-Anbieter gehen diesen Weg, ASIC-Entwickler ohnehin, und ich nutze diese professionelle Methode eben auch im FPGA-Design. Von Softwerkern wird heute verlangt, dass sie ihre Algorithmen auch auf neuen Architekturen zum laufen bringen. Alle Welt stürzt sich derzeit auf Cortex. Sogar uC Hersteller mit eigenen Rechnerarchitekturen springen auf den Zug auf, und die Entwickler müssen folgen. Ich denke, das wird auch mal bei den FPGAs passieren. Es könnte die Notwendigkeit kommen, die geschriebenen Modelle in einer anderen FPGA-Familie zum laufen zu bringen, weil irgendwer irgendwas entschieden hat. Thomas Reinemann schrieb zum architekturunabhängigen Modellieren: > Warum? Es kostet nur Zeit und FPGA-Ressourcen. Vor allem setzt es > voraus, dass man sich im Vorfeld darum kümmert, welche > Funktionen/Eigenschaften auf einer anderen Plattform nicht zur > Verfügung stehen. Das ist fernab jeglicher Realität. Ob ein Design jetzt 13900 oder 14000 Logikelemente braucht, ist ja nur dann wichtig, wenn die Anzahl verfügbarere LE genau dazwischen liegt, also eher selten. Und, völlig klar, man kann sich nicht vorab die Implementierung in allen möglichen FPGA-Familien überlegen. So weltfremd bin ich nicht. Aber eines gibt es immer: kombinatorische Elemente und Register. Das reicht. Thomas Reinemann schrieb dann noch: > Ich sehe ein, dass man ein Signal für einen einmaligen definierten > Anlauf nach dem Power-Up braucht. Aber eine gutes FPGA-Design braucht > kein externes Reset. Wer sollte das auch im normalen Betrieb betätigen? Zustimmung! Was anderes hab ich nie behauptet.
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.