Lothar Miller schrieb in einem anderen thread (Beitrag "VHDL Schulung") >> Wer zB. einen Vortragenden der Gaisler-Religion bekommt, wird später >> ganz erstaunt sein, dass viele FSMs auch in einen Prozess passen... >Und er wird feststellen, dass dann sein Megaprojekt auf einmal auf eine >bildschirmseite passt. >Und er wird noch erstaunter feststellen, dass diese vielen Variablen >nicht zwingend nötig sind, und die Welt nicht besser oder gar einfacher >machen... Das klingt sehr interessant, was gibt mehr darüber zu berichten und zu beschreiben?
>>Und er wird noch erstaunter feststellen, dass diese vielen Variablen >>nicht zwingend nötig sind, und die Welt nicht besser oder gar einfacher >>machen... Das klingt für mich (als häufiger Nutzer der 2-Prozess-Methode) wie jemand, der keine Ahnung von der Materie hat. Bei mir gibt es nämlich nur genau eine Variable. Fritz Jaeger schrieb: > Das klingt sehr interessant, was gibt mehr darüber zu berichten und zu > beschreiben? Hier gibt es das Paper direkt von der Quelle: http://www.gaisler.com/doc/vhdl2proc.pdf Ich empfehle aber ruhig erstmal all die Fallstricke von VHDL auszuprobieren (uninitialisierte Signale, aufwändiges Pflegen von Portlisten, unpassende Sensitivitätslisten, etc. pp.). Sonst kann man später die Vorteile gar nicht genießen. Duke
Duke Scarring schrieb: >>>Und er wird noch erstaunter feststellen, dass diese vielen Variablen >>>nicht zwingend nötig sind, und die Welt nicht besser oder gar einfacher >>>machen... > Das klingt für mich (als häufiger Nutzer der 2-Prozess-Methode) wie > jemand, der keine Ahnung von der Materie hat. Bei mir gibt es nämlich > nur genau eine Variable. Ich vermute, das hast du jetzt genauso ketzerisch gemeint, wie ich auch... > Bei mir gibt es nämlich nur genau eine Variable. Lass mal die Typdefinition sehen... ;-) Duke Scarring schrieb: > uninitialisierte Signale, aufwändiges Pflegen von > Portlisten, unpassende Sensitivitätslisten, etc. pp. All das schaffst du ganz problemlos auch mit der Gaisler-Methode (von der Sensitivliste evtl. mal abgesehen, wobei da dann ja einfach auf alles reagiert wird, das bietet VHDL2008 auch so). Nur, weil du die Fehler vorher schon gemacht hast, sind sie dir bekannt und du gehst ihnen aus dem Weg. Ich behaupte mal ganz frech und gehe eine Wette drauf ein: Ein Anfänger tappt mit der "Gaisler-Methode" in die selben Fallen wie mit der "traditionellen" Methode. Nur werden sie ihm nicht gleich bewusst...
Lothar Miller schrieb: > Ein Anfänger tappt mit der "Gaisler-Methode" in die selben Fallen wie > mit der "traditionellen" Methode. Nur werden sie ihm nicht gleich > bewusst... Da brauchen wir nicht zu Wetten. In diesem Punkt stimme ich Dir vollkommen zu. Lothar Miller schrieb: > Nur, weil du die > Fehler vorher schon gemacht hast, sind sie dir bekannt und du gehst > ihnen aus dem Weg. Deswegen schrieb ich ja auch: Duke Scarring schrieb: > Ich empfehle aber ruhig erstmal all die Fallstricke von VHDL > auszuprobieren Für mich persönlich ist die 2-Prozess-Methode ein Weg um komplexere Designs in Griff zu bekommen. Duke
> > Duke Scarring schrieb: >> uninitialisierte Signale, aufwändiges Pflegen von >> Portlisten, unpassende Sensitivitätslisten, etc. pp. Ich habe mich an synchrone Logik gewöhnt und habe alles an einem CLK. Dann ist das Clk das einzige Signal in der Sensitivitätsliste. Ein Reset-Signal kann auch unitialisierte Signale in einen definierten Zustand setzen. Die Pflege von Portlisten ist das Leid von VHDL. Leider kann man keine Bidirektionalen Bus in VHDL schreiben. Dann könnte man die Arbeit und Pflege in den Fitter schieben. Einfach jedes Signal in den Bus gehen und man hätte nur ein Bussignal in der Portzuweisung. Leider gibt es den Parser nicht.
René D. schrieb: > Die Pflege von Portlisten ist das Leid von VHDL. Die Tools können das heute, z.B.: emacs > VHDL > Update > Sensitivity List (Buffer) Oder mit neueren VHDL-Versionen einfach alles reintun. Ich perönlich bevorzuge ersteres. Ist gerade bei grösseren Prozessen immer auch noch ein Plausibilitätscheck, wenn man sieht, was da alles so in der Sensitivityliste steht.
In VHDL2008 (auch schon ein paar Jahre her) gibt es das Keyword ALL für die Sensitivliste. Das ist dann, wie Gaisler es auch macht: alle Signale in einen Record packen und den in der Sensitivliste angeben. Wenn sich dann irgendein Signal ändert, dann wird jeder Prozess neu berechnet, auch wenns nicht nötig wäre...
und genau das widerspricht wieder anderen Veröffentlichungen und Methoden, um Simulationen zu verkürzen und lenken. Die Portlistenpflege lässt sich über dies auch automatisieren.
Hier wird das Gaisler-Verfahren auch schön erklärt: http://www.gaisler.com/doc/structdes.pdf Ich habe zwei Fragen zu dem Beispiel auf Folie 10: 1. Warum werden im kombinatorischen Prozess alle Signale an die Variable v und erst am Ende an das Signal rin zugewiesen? Warum nicht direkt an rin? (Ich vermute es hat Performance-Gründe...) 2. Um Latches zu vermeiden werden am Anfang des Prozesses alle kombinatorischen Signale mit ihrem jeweiligen letzten Registerwert initialisiert (v:=r). Warum wird das so gemacht? Verbraucht das weniger Ressourcen als die Werte mit Null zu initialisieren?
Jeder muss für sich die Methodik der Beschreibung finden, die für ihn am Übersichtlichsten ist. Ich könnte da auch Möglichkeiten nennen, die ich mir erwarbeitet habe, welche gegen Gaislerprinzipien verstossen, aber sichtbare Vorteile besitzen. Das ist alles weitgehend realtiv, daher halte ich auch den Begriff "Religion" für sehr treffend. Zu deinen Fragen: 1) Ich vermute mal, der Übersicht wegen. 2) Ich vermute, um einen Signalübergang zu erzwingen, der den Latches entgegenwirkt. Latches sind im Übrigen so ein Punkt: Da reagieren viele schon auf das Wort allergisch und übersehen, dass das der Begriff Latch eigentlich falsch gewählt ist, für das, was man verhindern will.
Kritiker schrieb: > Jeder muss für sich die Methodik der Beschreibung finden, die für ihn am > Übersichtlichsten ist. Ich könnte da auch Möglichkeiten nennen, die ich > mir erwarbeitet habe, welche gegen Gaislerprinzipien verstossen, aber > sichtbare Vorteile besitzen. Bist du dir sicher, dass das echte Vorteile und nicht irgendwelche Hacks und Workarounds sind um ein paar Zeilen Code sparen und an die man sich einfach gewöhnt hat? In der Praxis sieht man dann, dass jeder Autor seinen eigenen Stil hat mit eigenen Konventionen. So gesehen finde ich die Gaisler-Methode einen gute Idee um einen einheitlichen, sauberen Code zu schreiben (sofern sich alle Entwickler einen Projektes daran halten). Kritiker schrieb: > 1) Ich vermute mal, der Übersicht wegen. Ich finde eine Zuweisung an das Signal rin sehr viel übersichtlicher. Warum also der Umweg? Kritiker schrieb: > 2) Ich vermute, um einen Signalübergang zu erzwingen, der den Latches > entgegenwirkt. Die Frage bleibt aber: Spart das auch Ressourcen ein gegenüber einer Initialisierung mit Null?
Fridolin schrieb: > Bist du dir sicher, dass das echte Vorteile und nicht irgendwelche Hacks > > und Workarounds sind um ein paar Zeilen Code sparen und an die man sich > > einfach gewöhnt hat? In der Theorie ist das wunderbar. Auch ich habe meine Überlegungen getroffen, begrüsse Codevereinheitlichungen, Konventionen und die Abkehr von altbackenen Geschichten. Und: Ich lehre das auch so. Aber: Das lässt sich in der Praxis meistens nicht machen, weil man die Menschen nur mit Aufwand umerziehen kann. Ich bin darauf angewiesen, mit dem auszukommen, was mir die Kollegen liefern und hinterlassen haben. Ich habe dann selten die Möglichkeit, den Code grossartig zu ändern oder eine andere Codierphilosophie dort einzubringen - so sinnvoll sie für sich gesehen auch wäre. Ich kann auch schlecht einen Mischcode schreiben, wenn es darauf ankommt, mal eben schnell ein Modul hinzuzufügen, wenn es dringend raus muss. Keiner zahlt die Zeit für die Umarbeitung, wenn kein Gegenwert da ist. Der der ist nicht da. Weder, was einen einzelnen Code noch einen ganzen Entwickler und dessen Stil angeht. Klar, Du kannst Dir ein neues Team holen, die alle bei Gaisler waren oder von derselben Hochschule kommen und beim selben Prof waren.
Es gibt aber noch weitere Gründe: Viele Konventionen und Strategien im Leben (nicht nur bei VHDL) sind Ergebnis von Überlegungen, die sich auf das Jetzt beziehen. Sie sind ein optimaler Kopromiss zwischen Aufwand und Gewinn - Kosten und Benefit. Diesem Idealpunkt hinkt die Realität immer weit hinterher, weil sie ihre Historie mitschleppt. Das führt dazu, dass wenn dann endlich jeder auf dem Stand ist, der propagiert wird, dieser dann schon wieder veraltet ist. Das viele VHDL Coden wird ohnehin abnehmen, also wozu noch spezielle Strategien lernen?
Kritiker schrieb: > Das viele VHDL Coden wird ohnehin abnehmen, also wozu noch spezielle > Strategien lernen? Wo geht der Trend deiner Meinung nach hin? Zu Verilog? Ein anderen Beschreibungsform? Oder gar ganz weg von solchen Formen(Chips)? > In der Theorie ist das wunderbar. Auch ich habe meine Überlegungen > getroffen, begrüsse Codevereinheitlichungen, Konventionen und die Abkehr > von altbackenen Geschichten. Und: Ich lehre das auch so. Gibt es hier Beispiele, Scripten, ..., um sich davon ein Bild zu machen, wie dass nach deiner Art aussieht? Vielen Dank im voraus!
Fridolin schrieb: > Ich habe zwei Fragen zu dem Beispiel auf Folie 10: > 1. Warum werden im kombinatorischen Prozess alle Signale an die Variable > v und erst am Ende an das Signal rin zugewiesen? Warum nicht direkt an > rin? (Ich vermute es hat Performance-Gründe...) Nein, es hat Konsistenzgründe! Denn wenn sich im v Struct was ändert, dann könnte es ja sein, dass genau diese Wert "später" im "Programm" nochmal gebraucht würde. Und dann wäre es ungeschickt, wenn zwar das Signal rin es mitbekommen hätte, aber die Variable v nicht... > (Ich vermute es hat Performance-Gründe...) Die Gaislermethode (die insbesondere ehemaligen Softies so schnell einleuchtet) lebt von den lokalen Variablen. Wie und ob der Synthesizer das effizient umgesetzt bekommt, das schert den "Programmierer" dann nicht. Er ist froh, dass sein "Programm" überhaupt läuft. > 2. Um Latches zu vermeiden werden am Anfang des Prozesses alle > kombinatorischen Signale mit ihrem jeweiligen letzten Registerwert > initialisiert (v:=r). Warum wird das so gemacht? Verbraucht das weniger > Ressourcen als die Werte mit Null zu initialisieren? Nein. Es wird so gemacht, dass ein Softie (C-Programmierer) innerhalb des Prozesses seine gelernte "Programmierweise" weiterverwenden kann: 1. der Wert einer Variablen ändert sich sofort bei der Zuweisung, 2. sie kann also gleich danach auf den neuen Wert abgefragt werden und 3. der Prozess wird so von oben nach unten durchlaufen. Mit dem Gaisler-Framework (Structs + lokale Variablen) wird allerdings für Anfänger verschleiert, dass diese "Programmierweise" nichts mit "Hardwarebschreibung" zu tun hat. Sie lernen dann nicht, die Beschreibungsmethode kritisch auf Effizienz zu hinterfragen und schon überhaupt nicht, sie mit anderen Methoden zu vergleichen. Kritiker schrieb: > Das viele VHDL Coden wird ohnehin abnehmen, also wozu noch spezielle > Strategien lernen? Diese Litanei wird schon seit der Internet-Hype gepredigt. Ich erinnere hier an das hochgelobte System-C, das arbeitslosen Softwareentwicklern (die es dann ja zuhauf gab) die "Umschulung" auf Hardwarebeschreibung erleichtern sollte. (Natürlich neben dem Effekt, dass Hochschulen billige Simulatoren hätten haben können...) Beitrag "Gibt es SystemC in freier Wildbahn?"
Moin, ein Informatikprofessor hat mir vor 15 Jahren prophezeit, dass in zehn Jahren keiner mehr Assembler programmieren wird... (um einen Kasten Bier hätte er aber mit mir auch nicht gewettet). Zum Thema, ob 2-process oder whatever für einen Softie einfacher ist, kann ich nur kurz kommentieren: Mit jeder Methode kann man sich ins Knie schiessen und die Wahrscheinlichkeit, dass einem VHDL falsch beigebracht wird, besteht sowieso zu 80%. Sowohl an Hochschulen wie auch an diversen kommerziellen Schulungen. Am weitesten kommt man IMHO, wenn man seine eigenen (oder andere) Designkonstrukte reverse-engineert und auf Logiklevel verstehen lernt. Allerdings ist die 2-process-Methode fast immer der logische Weg, eine komplexe state-machine lesbar aufzuzäumen, und man kommt leichter aus den Anfängerfehlern (clock delay vergessen) wieder raus, ohne den Code zu verunstalten. Als Pragmatiker mag ich Religionen nicht, aber einige Argumente Herrn Gaislers stimmen halt einfach, allerdings würde ich mit Variablen sparsamer umgehen. Als Beispiel mal eine JTAG-State-machine: Aktionen müssen da ausgelöst werden, wenn ein State gerade eintritt oder wenn ein spezifischer State gerade verlassen wurde. Wer das in einem Prozess hinschreibt, macht wohl oder übel bei nunmehr 16 States eine unlesbare Sauerei draus und läuft eher Gefahr, dass die Sache erst mal in der Hardware nicht richtig läuft - bei einem Debug-Port eher ungünstig. Ein häufiger Nebeneffekt der 2 process-Methode ist allerdings gerade, dass sich der Code ganz kompakt synthetisieren lässt. Was die Tools aus Variablen machen, kann man sich im Detail meist zusammenreimen. Man sollte sich halt im Vornherein klar werden, worauf das System optimiert werden soll (Speed/Logikresourcen). Wenn man dann nicht genau weiss, in welche Resourcen ein Variablenkonstrukt umgesetzt wird, sollte man vielleicht nicht von Anfang an in die "Softie-Schreibweise" einsteigen.. Grüsse, - Strubi
Strubi schrieb: > Allerdings ist die 2-process-Methode fast immer der logische Weg, eine > komplexe state-machine lesbar aufzuzäumen, und man kommt leichter aus > den Anfängerfehlern (clock delay vergessen) wieder raus, ohne den Code > zu verunstalten. Als Pragmatiker mag ich Religionen nicht, aber einige > Argumente Herrn Gaislers stimmen halt einfach, allerdings würde ich mit > Variablen sparsamer umgehen. Hi Strubi, sorry, da muss ich widersprechen! In einer 1-Prozess Schreibweise 'weiss' ich ganz genau, dass die Kombinatorik die ich beschreibe in einem FF landet. Das mag jetzt funktional richtig oder falsch sein, aber ich muss mich nicht mit so Sauereien wie Latches, Sensivity-Lists fuer den Simulator, und sonstigem Geraffel rumschlagen! Es gibt einen process mit dem Systemtakt, alles was darin gemacht wird resultiert in einem FF. Einfacher geht es m.M. nach nicht... Und es steht uebrigens auch sehr kompakt auf dem Bildschirm, was denn da so gemacht werden soll. Also halt: Was zusammen gehoert, steht auch zusammen da!
Hi Berndl, ich stimme Dir zu, solange es 'geht', gibt es keinen Grund, eine FSM auf 2-process-Schreibweise aufzublasen. Aber eben genau dann, wenn es nicht mehr auf eine(ok, zwei) Bildschirmseite(n) passt, macht bei einer State-Machine die Aufteilung in state_advance und state_encode-Prozess schon Sinn, wie bei genanntem JTAG-Controller. Sobald's an komplexe State-Machines geht, wo Ergebnisse früh (ohne FF delay) vorliegen müssen, ist IMHO der Punkt erreicht, wo man sich überlegen kann, ob die Dinge in zwei Prozessen nicht besser 'zusammengehören'. Bei einigen Prozessor-Pipelines geht es kaum anders ohne hässliche Hacks. Abgesehen davon ist es für viele, die damals noch 74xx oder 40xx zusammengestöpselt haben, logischer, Prozesse nach ihrer Funktion aufzuteilen (LUT, Encoder, Counter, ...), anstatt einen riesigen process(clk) zu "reverse-engineeren". Das kann natürlich wieder in zuviele Prozesse ausarten. Alles Aspekte, die man auch berücksichtigen muss, im Endeffekt ist's eine Frage der Komplexität. Ab einem gewissen Punkt sollte man sich sogar überlegen, ob man anstatt einer state machine nicht alles noch eleganter in selbstdefiniertem 'microcode' hinschreibt. Das hat so einige Entwicklungs-Vorteile und synthetisiert wunderbar in LUTs. Aber wäre Nummer drei einer 'religiösen Diskussion'...
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.