Ich habe gelesen, dass für größere Designs in VHDL die "Zwei-Prozess-Methode" verwendet wird, weil diese zu mehr Übersichtlichkeit führt. Sie ist im angehängten Dokument ziemlich gut beschrieben. Hat Ihr schon einmal nach diesen Regeln ein Design erstellt?
chris schrieb: > Ich habe gelesen, dass für größere Designs in VHDL die > "Zwei-Prozess-Methode" verwendet wird, weil diese zu mehr > Übersichtlichkeit führt. Ja, das kommt darauf an, wie man es lieber macht. Aber das, was du da verlinkt hast, ist nicht die Zwei-Prozess-Methode, sondern eine Strategie, wie man mit VHDL "sequentiell programmieren" kann. > Hat Ihr schon einmal nach diesen Regeln ein Design erstellt? Such einfach mal hier im Forum nach "Gaisler". Und denk dran: der Mann muss vom Verkauf seiner "Religion" leben.
>Such einfach mal hier im Forum nach "Gaisler". Und denk dran: der Mann >muss vom Verkauf seiner "Religion" leben. Da hat er sich aber schon gut verkauft, die Zwei-Prozess-Methode wird auf Wikipedia erwähnt: https://de.wikipedia.org/wiki/Very_High_Speed_Integrated_Circuit_Hardware_Description_Language ( unter Programmierstile ) Die Ablehnung des Datenfluss Modells stößt mir als LabView-Fan natürlich etwas sauer auf. Insbesondere weil man in den Datenflussmodellen die man als fortgeschrittener LabView-User intensive Strukturen verwendet, die in VHDL als "Record" bezeichnet werden. Damit fällt ein Argument, dass er als Begründung für sein Zwei-Prozess-Modell verwendet, schon mal weg.
chris schrieb: > Hat Ihr schon einmal nach diesen Regeln ein Design erstellt? Täglich. Aber muss das denn sein, dass dieser alte Kaffee immer wieder aufgewärmt wird? Bemühst du auch mal die Suchfunktion, bevor du redundant postest? Apropos: Mit Religion hat das nichts zu tun, und die Göteborger leben ganz gut von wenig spirituellen Aufträgen :-) Wenn man schöne Pipeline-Designs (CPUs) machen will, kommt man an 2-process kaum vorbei. Und vergiss mal Labview bei der ganzen Sache, das hat damit so gar nichts zu tun, das fällt unters Thema "grafisches Programmieren". Fang doch einfach mal zu coden an.
chris schrieb: > Damit fällt ein Argument, dass er als Begründung für sein > Zwei-Prozess-Modell verwendet, schon mal weg. Er braucht/verwendet die Records als "Signalsammlung" um im kombinatorischen Prozess sicher alle nötigen Signale in der Sensitivliste zu haben. Und um sie "einfach" an die lokale Variable übergeben zu können, damit dann ab dort mit VHDL wie mit einer prozeduralen Programmiersprache "programmieren" zu können. Wie gesagt: Gaisler beschreibt in seiner "Zwei-Prozess-Methode" ein komplettes Programmiermodell und verkauft es als die narrensichere Lösung im Umgang mit VHDL. Nichtsdestotrotz legt man sich bei dieser Vorgehensweise durch die dafür nötigen Formalismen eigentlich noch engere Zügel an, als VHDL an sich verlangen würde... Strubi schrieb: > die Göteborger leben ganz gut von wenig spirituellen Aufträgen :-) Sagte ich doch... ;-)
:
Bearbeitet durch Moderator
Autor: Strubi (Gast) >Und vergiss mal Labview bei der ganzen Sache, das >hat damit so gar nichts zu tun, das fällt unters Thema "grafisches >Programmieren". Richtig, und wer sich die History der FPGAs mal genauer anschaut, wird bemerken, dass die Ursprüngliche Designmethode eine grapische war: Since the VHDL code could now be directly synthesised, the development of the models was primarily made by digital hardware designers rather than software engi- neers. The hardware engineers were used to schematic entry as design method, and their usage of VHDL resembled the dataflow design style of schematics ( aus dem obigen Dokument ). Und genau deshalb liegt das Malen der Datenflussprogramme in LabView der Programmierung von FPGAs sehr viel näher als das Coden in Textform. >Fang doch einfach mal zu coden an. Kannst Du bitte in einem anderen Thread posten?
Also ich fand gerade als Anfänger die 2 Prozess Methode sehr angenehm, da sie viele Fehler, die man sonst so machen könnte ausschließt. Man muss sich natürlich ziemlich stoisch daran halten, aber ich fand es angenehm. Sowohl was das Schreiben angeht, als auch das spätere Verständnis des Geschriebenen. Gefühlt arbeitet man damit mehr in Blockdiagrammen, als mit einzelnen Multiplexern.
chris schrieb: > Und genau deshalb liegt das Malen der Datenflussprogramme in LabView der > Programmierung von FPGAs sehr viel näher als das Coden in Textform. Die Zeiten sind längstens vorbei, und so wird auch nicht VHDL gelehrt/praktiziert. Wer es so macht, endet mit einem kaum debugbaren/wartbaren Design. Genau das ist der Gag an einer HDL, dass ein Design wiederverwertbar gestaltet werden kann. chris schrieb: > Kannst Du bitte in einem anderen Thread posten? Wenn du hier was lernen willst, und mit deinen Postings zu Grundlagen um dich wirfst, musst du dir leider etwas Kritik an deiner Vorgehensweise anhören.
chris schrieb: > Richtig, und wer sich die History der FPGAs mal genauer anschaut, wird > bemerken, dass die Ursprüngliche Designmethode eine grapische war: >... The hardware engineers were used to schematic entry as design > method Der Satz sagt letztlich nur "Die Hardware-Designer waren es gewohnt, Schaltungen und Schaltpläne mit 74xx Gattern und Flipflops zu entwerfen." Das hatte erst mal gar nichts mit FPGA Design zu tun. Und logischerweise wurde beim Übergang zum FPGA Design im ersten Schritt dann gleich der RTL Schaltplan mit Gattern und Flipflops gezeichnet. Eben so wie vorher auch.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und logischerweise wurde beim Übergang zum FPGA Design im ersten Schritt > dann gleich der RTL Schaltplan mit Gattern und Flipflops gezeichnet ... was auf den ersten Blick logisch ist und auch insoweit nachzuvollziehen, als dass: 1) die ersten FPGA-Schaltungen auf Gatterebene gebaut wurden und reale Gatter genau so funktionieren wie Logikgatter 2) es die hardware-Entwickler waren, die die ersten FPGAs benutzt haben Heute sind wir 20 Jahren weiter: - FPGA-Schaltungen werden über ihre Funktion beschrieben und immer weniger über boolsche Logik (höchstens in Teilen) - die Funktionen sind komplex und abstrakt, daher taugt eine Strukturbeschreibung (und somit ein Schaltplanwerkzeug) nicht mehr - es wird von Softwareleuten beschrieben Fasst man die drei Punkte zusammen, komme Ich zu dem Schluss: FPGA-Design muss in UML passieren! Von dort aus geht es dann parallel runter in die Funktion und in die Struktur
Weltbester FPGA-Pongo schrieb im Beitrag #5192154: > Fasst man die drei Punkte zusammen, komme Ich zu dem Schluss: > FPGA-Design muss in UML passieren! Gibt's dazu Tools? Ich bin mir nicht sicher, ob der UML-Ansatz wirklich so intuitiv ist für HW. Es gäbe ja ansich IP-XACT, was die Vorteile grafischen Top-Level-Zusammenschaltens mit dem funktionalen Ansatz der Modul-Entwicklung vereint (vereinen sollte). Den anderen Weg von HDL->Schema erledigen Tools wie Synplify ja schon ganz ordentlich, nur halt sehr Schaltplan-spezifisch und weniger im funktionalen Sinne visualisiert.
> UML ?
ich hab gedacht daß die Kacke bleibt bei den "programmierer" die
rumclicken programmieren bezeichnen... nicht alles kann man mit einem
Hammer tuen.
Interessant finde ich, dass Gaisler in seiner Zwei-Prozessmethode exzessiv Variablen benutzt. Im Gegensatz zur hier empfohlenen Vermeidung von Variablen: Beitrag "Variable vs Signal"
chris schrieb: > Interessant finde ich, dass Gaisler in seiner Zwei-Prozessmethode > exzessiv Variablen benutzt. > > Im Gegensatz zur hier empfohlenen Vermeidung von Variablen: > Beitrag "Variable vs Signal" Der Gaisler weiss halt was er tut wenn er Variablen benutzt, ein Anfänger nicht. Und gerade einer der sich VHDL erschliesst in dem er es stur damit vergleicht was ein Konstrukt gleichen namens (bspw. variable) in C bewirken würde, ist noch zu 100% auf Anfängerlevel. Vergiss alles was du von der C-Programmierung kennst und lerne Hardwaredesign mit VHDL from the Scratch. Also Variablen nur in der Simu und in Ausnahmefällen wo du genau weist was dann nach der Synthese rauskommt.
chris schrieb: > Interessant finde ich, dass Gaisler in seiner Zwei-Prozessmethode > exzessiv Variablen benutzt. Ich hatte es schon ein paar mal erwähnt: damit ermöglicht er es, mit VHDL wie mit einer sequentiellen Programmiersprache zu programmieren, weil ja jede Variable sofort nach der Wertzuweisung sofort den neuen Wert übernimmt. Das war es, was C-Programmierer schon lange gesucht haben. > Im Gegensatz zur hier empfohlenen Vermeidung von Variablen: > Beitrag "Variable vs Signal" Du solltest nicht nur oberflächliche Schlagworte gegeneinander ausspielen, sondern du musst schon auch mal kurz drüber nachdenken. Mit der Gaisler-Methode hast du keinerlei Probleme mit Variablen, solange du dich ganz exakt und durchgängig an die vorgegebene Strategie hältst. Denn die Variablen bekommen ja am Anfang jedes "Unterprozesses" einen Ausgangswert zugewiesen und geben den Ergebniswert am Ende wieder ab. Dieses selbstauferlegte Zwangskorsett ist es, was hinterher das "Programmieren in VHDL" ermöglicht. Gaisler verdient dann sein Geld u.a. damit, dein Design aufzuräumen, wenn du dich nicht genau an die reine Lehre gehalten, sondern "unbedacht mal was anders gemacht" hast...
:
Bearbeitet durch Moderator
Wieso Ungnade? Das mit Variablen sieht zwar einfacher aus für Leute die aus der Softwareentwicklung kommen, ist aber dann doch oft ziemlich schwer weil man sich an einige Regeln halten muss. Wenn man stattdessen gleich ohne Variablen eine HDL erlernt ist das einfacher. Mit Signalen kann man auch alles machen, das ist eben Hardware, das kann man sich vorstellen. Was ist eine Variable in Hardware? Das ist weder ein Draht noch ein Flipflop.
Gustl B. schrieb: > Was ist eine Variable in > Hardware? Das ist weder ein Draht noch ein Flipflop. Je nachdem: Wenn ich erst schreibe und dann lese, wird es Kombinatorik. Wenn die Variable erst gelesen und dann geschrieben wird, wird ein Flipflop synthetisiert:
1 | ...
|
2 | |
3 | signal r, r_in: reg_t; |
4 | |
5 | begin
|
6 | comb: process( r, data_in) |
7 | variable v: reg_t; |
8 | begin
|
9 | v := r; |
10 | -- user code start here
|
11 | |
12 | v.wire := data_in; |
13 | data_wire_out <= v.wire; |
14 | |
15 | data_ff_out <= v.flipflop; |
16 | v.flipflop := data_in; |
17 | |
18 | -- user code end here
|
19 | r_in <= v; |
20 | end process; |
21 | |
22 | seq: process |
23 | begin
|
24 | wait until rising_edge( clk); |
25 | r <= r_in; |
26 | end process; |
27 | |
28 | end architecture; |
Ich will im allgemeinen Register haben, um das Timing in den Griff zu bekommen... Inwieweit es günstig ist, als VHDL-Neuling mit der 2-Prozessmethode anzufangen, kann ich nicht beurteilen. Wenn man VHDL betreut lernt und der Betreuer/Prof. Ahnung hat, dürfte das recht effektiv sein. Duke
Also ich habe das nicht geordnet gelernt, aber mittlerweile selber meine Ordnung gefunden. Kombinatorik wird streng von getakteten Sachen getrennt und ich verwende keine Variablen. Ich finde das kann man sich mit Signalen sehr schön vorstellen, fast wie Mechanik, wie Zahnräder die ineinander greifen oder so. Man kann in Takten denken und das geht mit Variablen nicht so einfach wie mit Signalen weil man auf zusätzliche Bedingungen achten muss. Und diese Sensitivity List lasse ich grundsätzlich weg. Gibt es eigentlich irgendetwas was man mit Variablen machen kann das man nicht mit Signalen bauen kann?
War das eine Scherzfrage? Wenn man die hinschreibt geht die Simulation schneller aber es kann sein, dass Simulation und Hardware nichtmehr zusammenpassen.
Gustl B. schrieb: > War das eine Scherzfrage? Nein. Vielleicht hab ich ja was missverstanden. Kann man tatsächlich jede sensitivity list weglassen?! Oder nur in einigen Kontexten/Tools?
Lothar M. schrieb: > chris schrieb: >> Interessant finde ich, dass Gaisler in seiner Zwei-Prozessmethode >> exzessiv Variablen benutzt. > Ich hatte es schon ein paar mal erwähnt: damit ermöglicht er es, mit > VHDL wie mit einer sequentiellen Programmiersprache zu programmieren, > weil ja jede Variable sofort nach der Wertzuweisung sofort den neuen > Wert übernimmt. Das war es, was C-Programmierer schon lange gesucht > haben. Das ist auch ein unschätzbarer Vorteil, wenn es um die Formulierung von Berechnungen, Strukturen und Entscheidungen geht, die zur Synthesezeit gefällt werden müssen und bei denen man nicht auf das Timing des FPGAs angewiesen sein will. Im Prinzip ist es ein Mikrokosmos, der sich zeitmässig unterhalb der Auflösung des FPGA-Taktes abspielt. Die Frage ist halt, wozu man es braucht. Ein klassisches Beispiel das Formulieren von Umrechnungen nach Multiplikationen, bei denen gerundet und Bits weggeworfen werden und dies in Abhängigkeit der gewünschten Aussteuerung des Signals und dessen Auflösung. Das kann man nicht in einer VHDL-Zeile erledigen, sodass der Compiler es zur Compilezeit ausrechnet und es in Kombinatorik vor das FF packt. Da ist das sicher hilfreich, wobei man das natürlich auch mit Signalen tun kann, die man außerhalb des Taktes irgendwo ohne Prozessvorschrift hinschreibt. Damit hat man den Vorteil, die Signale auch im Simulator zu sehen und sich real ausgeben zu lassen, weil sie nicht verschwinden. Ich bevorzuge daher in der Regel die Signalmethode.
Also ich lasse die Sensitivity List immer weg. Kombinatorik schreibe ich ohne Process hin und getaktetes in einem Process.
Gustl B. schrieb: > Gibt es eigentlich irgendetwas was man mit Variablen machen kann das man > nicht mit Signalen bauen kann? Ja, wenn du z.B. Prozeduren mit 'inout' Parametern aufrufst sparen Dir Variablen u.U einiges an Rechenzeit, und zwar besonders dann, wenn du solche Sachen machst: Gustl B. schrieb: > Also ich lasse die Sensitivity List immer weg. Kombinatorik schreibe ich > ohne Process hin und getaktetes in einem Process. Was eigentlich eine sehr schlechte Idee ist, wenn die Designs komplexer werden. Du kannst sogar Gefahr laufen, dass sich dein Simulator aufhängt, weil er gewisse inter-process-Abhängigkeiten nicht mehr sauber auflöst. Zumindest die 'clock' sollte in der SL eines synchronen process sein. Die Tools mahnen dir ja typischerweise an, wenn du was in der SL vergessen solltest ("Simulation/Synthesis mismatch" o.ä.).
Ja den Geschwindigkeitsaspekt hatte ich schon genannt. Aber da hatte ich bisher keine Probleme. Wieso sollte der Simulator inter-process-Abhängigkeiten nicht mehr sauber auflösen können? Keine Sensitivity List ist doch genauso wie wenn ich alle Signale in die Sensitivity Liste eintrage? Ich finde die Toolchain muss das abkönnen.
Es gibt da z.B. den Fall des eher 'lazy coding':
1 | process (clk) |
2 | begin
|
3 | if rising_edge(clk) and ce = '1' then |
4 | do_stuff(..) |
5 | end if; |
6 | end process |
Wenn du 'clk' aus der SL weglässt, wurde bei manchen Tools dieser process bei jeder Aenderung von 'ce' besucht und evaluiert, auch wenn clk nicht toggelt. Jetz lass mal ce oft glitchen und abhängig von weiteren Prozessen sein (gerade bei 2-process kommt das oft vor). Hast du dann ne Menge von diesen Konstrukten, die voneinander abhängig sind, ist der Simulator mächtig beschäftigt. Hast du jetzt noch eine Schleife drin, also dass Signal a und b implizit jeweils voneinander abhängen, kann es lustig werden. Das muss nicht zwingend eine (natürlich verbotene) kombinatorische Schleife sein, man kann schon mit zwei unterschiedlichen Clocks ne Menge Aerger schaffen. Ich hab's in der Vergangenheit zumindest schon geschafft, Modelsim damit abzuschiessen, und GHDL hat auch schon überflüssig Rechenzeit verbraten. Natürlich ist nervig, Diskrepanzen zwischen Syn und Sim zu haben, weil man was in der SL vergessen hat. Aber alles aus der SL weglassen wäre für mich ein no-go und würde mehr Mist in der Sim produzieren. Und es gibt Kunden, die einem sowas um die Ohren hauen...
Gustl B. schrieb: > Also ich lasse die Sensitivity List immer weg. Kombinatorik schreibe ich > ohne Process hin und getaktetes in einem Process. OK, hätte mich gewundert wenn man in kombinatorischen Prozessen die liste weglassen könnte. Ja, es ist etwas mühselig diese liste in diesen Fällen aktuell zu halten und es wäre wirklich ein sinnvolles Feature für einen VHDL editor die liste selbst aus dem body zu erzeugen oder wenigstens durch automatische signalnamvervollständigung zu unterstützen. Verwendest du auch prozesse mit asynchronen reset? Ich vermute, dort passt es mit dem Weglassen auch nicht.
Drill Master schrieb: > Ja, es ist etwas mühselig diese liste in diesen Fällen aktuell zu halten in VHDL 2008 schreibt man einfach
1 | .... : process(all) |
und guckt die Zeile nie wieder an.
Ja super! Und wo ist dann der Unterschied zu keiner Sensitivity List? Keine bedeutet ja nicht leer sondern solle für den Simulator bedeuten, dass er auf alle Signale aufpasst und nicht nur auf ein paar in der Sensitivity List genannte. Drill Master schrieb: > OK, hätte mich gewundert wenn man in kombinatorischen Prozessen die > liste weglassen könnte. Kann man sie auch dort weglassen? Also dient sie auch dort nur der Simulation?
Gustl B. schrieb: > Keine bedeutet ja nicht leer sondern solle für den Simulator bedeuten, > dass er auf alle Signale aufpasst Geht das tatsächlich oder "sollte" es nur? Das wäre nämlich nicht ganz dem mir bekannten VHDL-Standard entsprechend... > Also dient sie auch dort nur der Simulation? Die Sensitivliste ist ausschließlich für die Simulation. Der Synthesizer "nimmt" sich seine Signale und gibt eine Info aus, dass die Simulation nicht mehr zum Syntheseergebnis passt.
:
Bearbeitet durch Moderator
Gustl B. schrieb: > Keine bedeutet ja nicht leer sondern solle für den Simulator bedeuten, > dass er auf alle Signale aufpasst und nicht nur auf ein paar in der > Sensitivity List genannte. das wär' mir neu.
Drill Master schrieb: > Verwendest du auch prozesse mit asynchronen reset? Ich vermute, dort > passt es mit dem Weglassen auch nicht. Das ist noch die härtere Variante als das obige 'lazy coding'. Wenn das kein echter Reset sondern irgend ein kombinatorisches Ergebnis ist, glitcht das auf jeden Fall rum, aber man entdeckt es immerhin schnell, bzw. fängt mit den asynchronen Konzepten typischerweise nicht an. Oder man umgeht das ganze Problem per MyHDL, wo es dedizierte Resetsignale gibt (@always_seq Dekorator), da schaltet man dann nur noch das async-Attribut im Signalkontext um. Drill Master schrieb: > Ja, es ist etwas mühselig diese liste in diesen Fällen aktuell zu halten > und es wäre wirklich ein sinnvolles Feature für einen VHDL editor die > liste selbst aus dem body zu erzeugen oder wenigstens durch automatische > signalnamvervollständigung zu unterstützen. Der Emacs kann das, aber drückt einem auch die idiotische GNU-Formatierung auf. Gustl B. schrieb: > Kann man sie auch dort weglassen? Also dient sie auch dort nur der > Simulation Jo, aber der Prozess wird typischerweise in jeder Zeitscheibe angefahren, ausser dein Simulator löst das intern auf. Mich wundert aber echt, dass sich der bei dir noch nicht aufgehangen hat.
Lothar M. schrieb: > Geht das tatsächlich oder "sollte" es nur? > Das wäre nämlich nicht ganz dem mir bekannten VHDL-Standard > entsprechend... Den Standard kenne ich nicht. Was macht denn der Simulator ohne Sensitivity List? Der berechnet den Process mit jedem Simulationstick neu und nicht nur wenn sich die Signale in der Sensitivity List ändern. So wie eben auch Hardware. Wenn man also alle Signale in die Sensitivity List steckt, dann wird der Process neu berechnet wenn sich eines dieser Signale ändert. Ohne Sensitivity List wird es immer in jedem Simulationsschritt neu berechnet. Gut, ja da ist ein Unterschied, aber vermutlich nur in der Rechenzeit für die Simulation. Lothar M. schrieb: > Die Sensitivliste ist ausschließlich für die Simulation. Der > Synthesizer "nimmt" sich seine Signale und gibt eine Info aus, dass die > Simulation nicht mehr zum Syntheseergebnis passt. Das hatte ich vermutet, also kann man sie auch dort problemlos weglassen. Martin S. schrieb: > Mich wundert aber > echt, dass sich der bei dir noch nicht aufgehangen hat. VIVADO ist halt doch genial^^ Aber Du kannst mir hier gerne mal Code posten den ich dann hier simuliere. Vielleicht schreibe ich eben auch nur sauberen Code ...
Gustl B. schrieb: > Lothar M. schrieb: >> Geht das tatsächlich oder "sollte" es nur? >> Das wäre nämlich nicht ganz dem mir bekannten VHDL-Standard >> entsprechend... > > Den Standard kenne ich nicht. Was macht denn der Simulator ohne > Sensitivity List? Der berechnet den Process mit jedem Simulationstick > neu und nicht nur wenn sich die Signale in der Sensitivity List ändern. > So wie eben auch Hardware. > Wenn man also alle Signale in die Sensitivity List steckt, dann wird der > Process neu berechnet wenn sich eines dieser Signale ändert. Ohne > Sensitivity List wird es immer in jedem Simulationsschritt neu > berechnet. Gut, ja da ist ein Unterschied, aber vermutlich nur in der > Rechenzeit für die Simulation. > > Lothar M. schrieb: >> Die Sensitivliste ist ausschließlich für die Simulation. Der >> Synthesizer "nimmt" sich seine Signale und gibt eine Info aus, dass die >> Simulation nicht mehr zum Syntheseergebnis passt. > > Das hatte ich vermutet, also kann man sie auch dort problemlos > weglassen. > > Martin S. schrieb: >> Mich wundert aber >> echt, dass sich der bei dir noch nicht aufgehangen hat. > > VIVADO ist halt doch genial^^ Aber Du kannst mir hier gerne mal Code > posten den ich dann hier simuliere. Vielleicht schreibe ich eben auch > nur sauberen Code ... Vivado - XSim (meine aktuelle Version ist 2017.2) "hängt sich sofort auf", wenn in der Simulation ein Prozess auftaucht, der weder Sensitivity-List noch eine wait-Anweisung hat. Der Simulator trifft zum Simulations-Zeitpunkt 0 ns auf den Prozess und berechnet die Ergebnisse seiner Zuweisungen. Direkt danach (immernoch zum Zeitpunkt 0 ns) wird der Prozess erneut getriggert und berechnet (weil ja keine eindeutige Trigger-Bedingung definiert wurde und der Prozess nicht per wait suspendiert wird)... und das ganze wiederholt endlos. So ein Prozess verhält sich im Simulator, wie eine Endlosschleife ("while true loop"). Alle Xilinx-Simulatoren, mit den ich gearbeitet habe - angefangen bei ISE 13.irgendwas bis zum aktuellen Vivado - verhalten sich da sehr ähnlich. Die einzige Besserung ist, dass man mittlerweile die "aufgehängte" Simulation per "cancel"-Button beenden kann ohne den Task-Manager bemühen zu müssen (früher war zum Teil ein PC-Neustart per Power-Knopf fällig, weil sich nicht mal mehr der Task-Manager starten liess) habe das gerade mit diesem "Code" ausprobiert:
1 | entity testbench is |
2 | -- Port ( );
|
3 | end testbench; |
4 | |
5 | architecture Behavioral of testbench is |
6 | |
7 | signal clk : std_logic; |
8 | signal a : std_logic; |
9 | signal b : std_logic; |
10 | signal c : std_logic; |
11 | |
12 | begin
|
13 | |
14 | process
|
15 | begin
|
16 | if rising_edge(clk) then |
17 | c <= a and b; |
18 | end if; |
19 | end process; |
20 | |
21 | process
|
22 | begin
|
23 | clk <= '0'; |
24 | wait for 5 ns; |
25 | clk <= '1'; |
26 | wait for 5 ns; |
27 | end process; |
28 | |
29 | a <= '0', '1' after 15 ns; |
30 | b <= '0', '1' after 10 ns; |
31 | |
32 | end Behavioral; |
Gustl B. schrieb: > VIVADO ist halt doch genial^^ Aber Du kannst mir hier gerne mal Code > posten den ich dann hier simuliere. Vielleicht schreibe ich eben auch > nur sauberen Code ... Oergs, ist das dein Ernst, @Vivado? Ich habe den argen Verdacht, dass das Ding noch zuviel Isim-Code enthält...den Simulator habe ich aber gar nicht mehr getestet, flog vorher aus anderen Gründen in die Ecke. Code kann ich nicht posten, sorry. Der "backport" wäre ausserdem eine Menge zu tippen. Aber frühestens dann, wenn du komplexe Designs mit 2 oder gar 3-process-Schreibweise plus mehrere Taktdomänen (dualclock-FIFOs, Graycounter, usw.) in die Simulation steckst, kannst du mit dem process(all) Ansatz ein blaues Wunder erleben. Genau deswegen bin ich komplett auf MyHDL/GHDL umgestiegen und halte mich strikt an eine explizite sensitivity-liste (die mir von MyHDL bei @always_comb eh generiert wird).
eddy schrieb: > Vivado - XSim (meine aktuelle Version ist 2017.2) "hängt sich sofort > auf", wenn in der Simulation ein Prozess auftaucht, der weder > Sensitivity-List noch eine wait-Anweisung hat. Ah, da war jemand schnell! So hatte ich das in Erinnerung. Hatte damals sicher eine Woche verbraten, den Bock im Code (der genaugenommen vom semantischen Standpunkt gar keiner ist) zu finden, der in nem Fremdcodeschnipsel lag, und zwar genau der von oben:
1 | process (clk, ce) |
2 | begin
|
3 | if rising_edge(clk) and ce = '1' then |
4 | do_stuff(..) |
5 | end if; |
6 | end process |
Weil wohl das Tool ne Warnung anmahnte, kam das 'ce' durch den Autor in die SL. So intuitiv angenommen sollte der Simulator erst 'rising_edge(clk)' evaluieren und bei 'false' abbrechen (AND bedingung!). Tat er aber nicht, jedes 'ce' event rief die Sim-Routine auf und aus irgend einem Grund kam bei Isim ein falsches Resultat raus. Muss allerdings sagen, dass das eine komplexere logische Schleife war, mit ebendiesen inter-process-Abhängigkeiten, die nicht eindeutig auflösbar sind. Aehnliches Problem gibt's bei Python/MyHDL aber auch, da kann man sich auch mit zirkularen Referenzen ein schickes Memory-Loch schaffen. Die Frage ist, ob die Reihenfolge der Evaluierung im VHDL-Standard streng definiert ist. Zumindest bei eindeutig synchronen Prozessen würde ich streng auf einem 'process (clk)'-Statement beharren, weil damit auch gleich eindeutig der synchrone Charakter gekennzeichnet ist und der Sim nicht sinnlos Zeit verbrät, mal abgesehen vom Aufhäng-Risiko.
Gustl B. schrieb: > Was macht denn der Simulator ohne Sensitivity List? Gar nichts. Höchstens du hast ein wait im Prozess. Das bewirkt das selbe wie eine Sensitivliste (die ist nämlich ein implizites wait). eddy schrieb: > habe das gerade mit diesem "Code" ausprobiert: Da bekomme ich mit dem Aldec Simulator eine ganze Menge Fehler:
1 | # Error: COMP96_0078: senslist.vhd : (7, 18): Unknown identifier "std_logic". |
2 | # Error: COMP96_0064: senslist.vhd : (7, 18): Unknown type. |
3 | # Error: COMP96_0078: senslist.vhd : (8, 16): Unknown identifier "std_logic". |
4 | # Error: COMP96_0064: senslist.vhd : (8, 16): Unknown type. |
5 | ..... |
Also gut, man weiß ja, was gemeint ist... Ok, ein paar Sekunden später warnt der Compiler:
1 | # Warning: DAGGEN_0001: testbench.vhd : (17, 0): Process without explicit |
2 | or implicit wait statement - possible infinite loop. |
Und nach dem Start hagelt es den Simulator aber dermaßen in die Ecke, dass er sich nicht mehr anhalten oder beenden lässt. Da muss tatsächlich der Taskmanager herhalten... :-o
Martin S. schrieb: > So intuitiv angenommen sollte der Simulator erst 'rising_edge(clk)' > evaluieren und bei 'false' abbrechen (AND bedingung!). Tat er aber > nicht, jedes 'ce' event rief die Sim-Routine auf und aus irgend einem > Grund kam bei Isim ein falsches Resultat raus. Er hätte aber auch bei einem Aufruf wegen des "ce" nicht in das "if" hineinkommen dürfen, denn "rising_edge()" prüft ja auch noch einiges ab:
1 | FUNCTION rising_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN IS |
2 | BEGIN
|
3 | RETURN (s'EVENT AND (To_X01(s) = '1') AND (To_X01(s'LAST_VALUE) = '0')); |
4 | END; |
:
Bearbeitet durch Moderator
Genau.. in das do_stuff kommt er nicht rein (das habe ich mit gdb verifiziert). Aber die Routine wird aufgerufen und verbrät signifikant Zeit. Und wenn der Sim seinen Event-Baum bei der Analyse abarbeitet, evaluiert er bestenfalls das "'event"-Konstrukt zuerst und springt in den betr. process-Runtime-Code nur rein, wenn sich 's' geändert hat. Wenn im obigen Beispiel 'ce' eine höhere Priorität in der Propagationsliste der Ereignisse hat, geht definitiv was schief in der Optimierung. Wenn man es andersrum schreiben würde wie:
1 | process (clk, ce) |
2 | begin
|
3 | if ce = '1' and rising_edge(clk) then |
4 | do_stuff(..) |
5 | end if; |
6 | end process |
würde ein "dummer" Simulator ev. 'ce' zuerst evaluieren, dafür könnte man noch Verständnis haben. Dann müsste der Standard die Reihenfolge der Evaluierung innerhalb 'if' wohl-definieren, aber ob sich dann <Vendor_X/> daran hält...
:
Bearbeitet durch User
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.