Hallo liebe mikrocontroller - Community, Ich beschäftige mich noch nicht allzu lange mit VHDL und hätte da mal eine ganz grundsätzliche Frage. Folgende Problemstellung: Ich habe meinen ersten Testentwurf von meinem Design und möchte diesen jetzt ganz einfach erweitern. Dabei ist es so, dass mein Design jetzt so erweitert werden soll, dass die bestehenden Komponenten meist 3-mal identisch benötigt werden (3 Phasen). Sprich es sollen die bestehenden Komponenten (also es sind Counter, EdgeDetectroen und StateMachine) einfach 3-mal parallel laufen, natürlich mit 3 unterschiedichen Eingängen. Ich frage mich jetzt gerade ob ich meine Etities jetzt einfach um 2 zusätzliche Processes erweitern soll oder ob es besser ist für die weiteren 2 Komponenten jeder Art (also es sind Counter, EdgeDetectroen und StateMachine) jeweils einen neue Entity anzulegen welche ich alle in meiner Top-level Entity instanziiere? Was wären die Vor- bzw Nachteile der beiden Herangehensweisen? LG, Daniel
Daniel C. schrieb: > Was wären die Vor- bzw Nachteile der beiden Herangehensweisen? Du legst ein Modul (=Entity) an, das 1 Phase bedient. Von dieser instatiierst du in einem zweiten (Top-Level-)Modul die nötigen 3 Komponenten. Etwa so wie ich das mit der Totzeit-Generierung hier für 2 Phasen gemacht habe: http://www.lothar-miller.de/s9y/archives/58-Totzeit-fuer-H-Bruecke.html Dann musst du nämlich nur 1 Phase komplett durchsimulieren und kannst diese dann als "bereits fertig" in deinem Design mehrfach einsetzen.
:
Bearbeitet durch Moderator
Oder du packst die ganze Logik für eine Phase in einem Entity und dann instantiierst den Phasen-Block in einem Generate Statement: e.g. im Anhang
Lothar, als blutiger Anfaenger haette ich eine vermutlich banale Frage zu Deinem Beispiel:
1 | architecture Behavioral of Totzeit is |
2 | signal delay : integer range 0 to tdead-1 := 0; |
3 | begin
|
Warum ist delay vom Typ signal? Ich dachte signal wird nur dann eingesetzt, wenn die Schnittstelle damit mit der Aussenwelt kommuniziert. In deinem Beispiel tut delay dies aber nicht. Haette man delay auch als variable deklarieren können?
Mehmet K. schrieb: > Haette man delay auch als variable deklarieren können? Hier der Link zum Klassiker: Beitrag "Variable vs Signal" Duke
Mehmet K. schrieb: > Ich dachte signal wird nur dann eingesetzt Nein. Variablen sind es, die nur ausnahmsweise und gezielt eingesetzt werden. Auch wenn sie so ein "schönes" Verhalten haben und den neuen Wert "sofort" übernehmen. Oder kurz: VHDL-Anfänger aus der Softwareecke setzen die Dinger gern ein, weil man damit so einfach "programmieren" kann.
:
Bearbeitet durch Moderator
Ich bin zwar nicht der TO, aber auch Anfänger. Lothar M. schrieb: >> Ich dachte signal wird nur dann eingesetzt > Nein. Variablen sind es, die nur ausnahmsweise und gezielt > eingesetzt werden. Auch wenn sie so ein "schönes" Verhalten haben und > den neuen Wert "sofort" übernehmen. Aber warum denn? Den von Duke Scarring verlinkten Artikel habe ich gelesen, aber darin kann ich keine überzeugenden Argumente für Signale finden.
Markus K. schrieb: > aber darin kann ich keine überzeugenden Argumente für Signale finden. Drehen wir den Spieß mal um: wenn du darin keine überaus überzeugenden Argumente für Variablen findest, dann nimm Signale. Oder andersrum: Ein Signal ist der übliche Informationsträger in VHDL. Variablen haben "Sonderfunktionen". > Den von Duke Scarring verlinkten Artikel habe ich gelesen, aber darin > kann ich keine überzeugenden Argumente für Signale finden. Lies ihn nochmal und frag, wenn du etwas nicht verstehst. Mal eine Frage: Was gefällt dir an Variablen so gut?
Lothar M. schrieb: > Mal eine Frage: > Was gefällt dir an Variablen so gut? Es ist so wie Du sagst: Wenn man einen Softwarebackground hat, dann fühlen die sich sehr viel natürlicher an als Signale. Ich bin gerne bereit Signale zu verwenden, wenn diese Vorteile haben. Bis jetzt sehe ich die Vorteile aber eher bei den Variablen. Insbesondere auch, dass man dabei komplexere Ausdrücke einfach aufspalten kann und der Compiler macht die Hilfsvariablen dann hinterher wieder weg. Um auf den empfohlenen Thread einzugehen: Hier Beitrag "Re: Variable vs Signal" argumentiert Falk, dass die beiden unterschiedliches Zuweisungsverhalten haben und das Anfänger verwirre. Ich denke, ich habe das schon verstanden: Bei Signalen gewinnt die letzte Zuweisung und bei Variablen darf man den Wert sofort verwenden. Ich sehe es eigentlich eher so, dass Signale Anfänger verwirren und nicht die Variablen. Hier Beitrag "Re: Variable vs Signal" argumentierst Du, dass die Simulation fehlerhaft wird, wenn man einen Wert von Variable auf Signal umstellt und dabei die Sensitivity-Liste nicht erweitert und auch noch die Compilerwarnung ignoriert. Ja, muss man halt drauf achten. Danke für den Hinweis. Deswegen aber auf Variablen (weitgehend) zu verzichten halte ich für übertrieben. Hier Beitrag "Re: Variable vs Signal" hast Du ein Beispiel, bei dem die Variante mit Variablen[1] schneller ist als die Variante mit Signalen[2]. Erst die ausformulierte Variante mit Signalen[3] wird auch parallelisiert. Das deute ich eher als Argument für Variablen. Diesen Beitrag Beitrag "Re: Variable vs Signal" habe ich nicht verstanden. Allerdings hatte ich auch nicht vor, solchen Code zu schreiben, sondern die Signale immer am Ende des Prozesses zuzuweisen und immer eine clock zu verwenden. Ich vermute, dass das
1 | process(din) |
2 | variable var: std_logic; |
3 | begin
|
4 | res1 <= var; |
5 | var := din; |
6 | res2 <= var; |
7 | end process; |
das Gleiche ist wie das da:
1 | process(din) |
2 | variable var: std_logic; |
3 | begin
|
4 | var := din; |
5 | res1 <= var; |
6 | res2 <= var; |
7 | end process; |
Jedenfalls was die Synthese angeht. Die Simulation sieht das wohl anders. Insgesamt kann ich nicht wirklich Argumente gegen Variablen erkennen. Man muss zwei verschiedene Werte-Verhalten lernen und beim Umstellen von Variablen auf Signale aufpassen was man tut. Im Gegenzug dazu werde ich nicht grübelnd vor sowas sitzen (Beispiel auch von Dir):
1 | process begin |
2 | wait until rising_edge(clk); |
3 | signalA <= '1'; |
4 | if signalA='1' then |
5 | signalB <= not signalB; |
6 | end if; |
7 | signalA <= '0'; |
8 | end process; |
Ich verstehe zwar, was da passiert (oder eben nicht passiert), aber ich bin mir auch sicher, dass ich trotzdem früher oder später sowas schreiben werde.
Markus K. schrieb: > Insgesamt kann ich nicht wirklich Argumente gegen Variablen erkennen. Ich bin kein "Variablenverkäufer" und muss nicht davon leben, dass möglichst viele Variablen verwendet werden. Aber eines ist klar: der Simulator ist der Debugger eines HDL Designs. Und wenn es eine Möglichkeit gibt, in der Simulation etwas falsch zu machen, dann lasse ich das bleiben. Aus Erfahrung. Aber da darf gern jeder seine eigenen Erfahrungen machen... > Insgesamt kann ich nicht wirklich Argumente gegen Variablen erkennen. Mein Ansatz ist andersrum: wenn ich keine spürbaren Vorteile sehe, dann nehme ich keine Variablen. In einem Prozess sind Signale nämlich extrem pflegeleicht, weil ihre Abfrage keine Reihenfolge braucht. Ein Signal bleibt während des gesamten Prozesses unverändert. Markus K. schrieb: > Ich verstehe zwar, was da passiert (oder eben nicht passiert), aber ich Die Abfrage erfolgt während des gesamten Prozesses auf den initialen Wert von a. Die Zuweisungen greifen erst am Prozessende nach den Motto "die letzte Signalzuweisung gewinnt". > bin mir auch sicher, dass ich trotzdem früher oder später sowas > schreiben werde. Du willst gar nicht wissen, welche seltsamen Verhaltensweisen damit Variablen hinbekommst...
:
Bearbeitet durch Moderator
Markus K. schrieb: > Ich denke, ich habe das schon verstanden: Bei Signalen gewinnt die > letzte Zuweisung und bei Variablen darf man den Wert sofort verwenden. > Ich sehe es eigentlich eher so, dass Signale Anfänger verwirren und > nicht die Variablen. Du musst noch einen Denkschritt nachvollziehen: Nämlich dass ein Simulator typischerweise eventbasiert arbeitet. D.h. ändert sich ein Signal, kümmert sich irgend ein Handler darum (guckst du 'concurrent' versus 'sequential' statements in der HDL-Semantik). Und wenn du dann nachvollziehst, was der Synthesizer aus diesen Statements macht (angefangen mit 'Primitiven' wie : Flipflop, LUT, Multiplexer) stellst du fest, dass diese Abstraktion recht nah an der Hardware ist. Und das willst du, aus zur Genüge vorgekauten Gründen: Stimmt die Simulation, soll auch die HW entsprechend laufen. Dass da VHDL einem eine Menge Möglichkeiten liefert, sich ins Knie zu schiessen, ist wieder so ein Thema, dafür gibts aber Tools, die Designregeln überprüfen, obige Konstrukte schmeissen bei mir einen roten Blob der schreit: Nix gut. So generell bin ich ein Freund von: Schreib hin, was es macht (oder nutze copy/paste, aber halt' es explizit). Alles andere geht in Richtung Obfuscation und macht Kollegen, die deinen Code allenfalls debuggen müssen, das Leben schwer.
Markus K. schrieb: > Hier Beitrag "Re: Variable vs Signal" hast Du ein Beispiel, bei dem die > Variante mit Variablen[1] schneller ist als die Variante mit > Signalen[2]. Erst die ausformulierte Variante mit Signalen[3] wird auch > parallelisiert. Das ist noch in der Stufe vor der Optimierung. Letztendlich wird diese gesamte Funktion in jedem Fall in 1 einzige LUT gepackt und ist immer gleich schnell. > Das deute ich eher als Argument für Variablen. Nennt sich auch "schönsaufen"... ;-) Nein, im Ernst, das "Hauptproblem" hier ist das übliche: du hast bisher Software gemacht und möchtest möglichst im selben erprobten Stil ein FPGA "programmieren". Variablen scheinen dir bekannt und deshalb geeignet, diese Vorgehensweise umzusetzen. Allerdings wird das (wie hier schon mehrmals erlebt) schiefgehen. Je später desto schlimmer. Mein Vorschlag: du solltest du beim Verfassen einer VHDL-Beschreibung explizit versuchen, Signale zu verwenden. Dann fällt dir immer wieder mal auf, dass du für die Hardwarebeschreibung andere Mechanismen und eine andere Denkweise brauchst.
Lothar M. schrieb: > Nein, im Ernst, das "Hauptproblem" hier ist das übliche: du hast bisher > Software gemacht und möchtest möglichst im selben erprobten Stil ein > FPGA "programmieren". Einer der Gründe dafür, dass ich Hardwarebeschreibungen in VHDL statt Verilog erstelle, besteht darin, dass sich VHDL stark von den C-artigen Sprachen unterscheidet. Dies führt nämlich dazu, dass die rote Warnlampe ständig blinkt: "Achtung, Du beschreibst gerade Hardware!". Bei meinen bisherigen FPGA- und CPLD-basierten Designs entwickele ich die Hardwarebeschreibung und die zugehörige Microcontroller- oder Softcore-Firmware gleichzeitig, d.h. wenn ich z.B. ein Peripherieregister definiere, schreibe ich sofort auch die entsprechenden Zugriffsfunktionen (in C/C++). Daher wäre mir Verilog an dieser Stelle manchmal zu C-artig.
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.