VHDL Grundlagen : zwei Prozess Methode

[chris (Gast)]

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?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[chris (Gast)]

>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.

[Strubi (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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... ;-)

[chris (Gast)]

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?

[nfet (Gast)]

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.

[Strubi (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Weltbester FPGA-Pongo (Gast)]

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

[Strubi (Gast)]

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.

[Ale (Gast)]

> UML ?

ich hab gedacht daß die Kacke bleibt  bei den "programmierer" die 
rumclicken programmieren bezeichnen... nicht alles kann man mit einem 
Hammer tuen.

[chris (Gast)]

Interessant finde ich, dass Gaisler in seiner Zwei-Prozessmethode 
exzessiv Variablen benutzt.

Im Gegensatz zur hier empfohlenen Vermeidung von Variablen:
Beitrag "Variable vs Signal"

[Drill Master (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[chris (Gast)]

Ah, ich sehe, er ist hier schon früher in Ungnade gefallen:
Beitrag "Gaisler-Religion?"

[Gustl B. (-gb-)]

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.

[Duke Scarring (Gast)]

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:

...

  signal r, r_in: reg_t;

begin
  comb: process( r, data_in)
    variable v: reg_t;
  begin
    v := r;
    -- user code start here

    v.wire        := data_in;
    data_wire_out <= v.wire;

    data_ff_out   <= v.flipflop;
    v.flipflop    := data_in;

    -- user code end here
    r_in <= v;
  end process;

  seq: process
  begin
    wait until rising_edge( clk);
    r <= r_in;
  end process;

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

[Gustl B. (-gb-)]

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?

[Drill Master (Gast)]

Gustl B. schrieb:
> Und diese Sensitivity List lasse ich grundsätzlich weg

Echt jetzt?

[Gustl B. (-gb-)]

War das eine Scherzfrage? Wenn man die hinschreibt geht die Simulation 
schneller aber es kann sein, dass Simulation und Hardware nichtmehr 
zusammenpassen.

[Drill Master (Gast)]

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?

[J. S. (engineer)]

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.

[Gustl B. (-gb-)]

Also ich lasse die Sensitivity List immer weg. Kombinatorik schreibe ich 
ohne Process hin und getaktetes in einem Process.

[Strubi (Gast)]

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.ä.).

[Gustl B. (-gb-)]

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.

[Strubi (Gast)]

Es gibt da z.B. den Fall des eher 'lazy coding':

process (clk)
begin
    if rising_edge(clk) and ce = '1' then
        do_stuff(..)
    end if;
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...

[Drill Master (Gast)]

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.

[Markus F. (mfro)]

Drill Master schrieb:
> Ja, es ist etwas mühselig diese liste in diesen Fällen aktuell zu halten

in VHDL 2008 schreibt man einfach

.... : process(all)

und guckt die Zeile nie wieder an.

[Gustl B. (-gb-)]

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?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Markus F. (mfro)]

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.

[Martin S. (strubi)]

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.

[Gustl B. (-gb-)]

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 ...

[eddy (Gast)]

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:

entity testbench is
--  Port ( );
end testbench;

architecture Behavioral of testbench is

    signal clk : std_logic;
    signal a : std_logic;
    signal b : std_logic;
    signal c : std_logic;

begin

    process
    begin
        if rising_edge(clk) then
            c <= a and b;
        end if;
    end process;
    
    process
    begin
        clk <= '0';
        wait for 5 ns;
        clk <= '1';
        wait for 5 ns;
    end process;
    
    a <= '0', '1' after 15 ns;
    b <= '0', '1' after 10 ns;
  
end Behavioral;

[Martin S. (strubi)]

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).

[Martin S. (strubi)]

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:

process (clk, ce)
begin
    if rising_edge(clk) and ce = '1' then
        do_stuff(..)
    end if;
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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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:

# Error: COMP96_0078: senslist.vhd : (7, 18): Unknown identifier "std_logic".
# Error: COMP96_0064: senslist.vhd : (7, 18): Unknown type.
# Error: COMP96_0078: senslist.vhd : (8, 16): Unknown identifier "std_logic".
# Error: COMP96_0064: senslist.vhd : (8, 16): Unknown type.
.....

Also gut, man weiß ja, was gemeint ist...

Ok, ein paar Sekunden später warnt der Compiler:

# Warning: DAGGEN_0001: testbench.vhd : (17, 0): Process without explicit
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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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:

FUNCTION rising_edge  (SIGNAL s : std_ulogic) RETURN BOOLEAN IS
BEGIN
    RETURN (s'EVENT AND (To_X01(s) = '1') AND (To_X01(s'LAST_VALUE) = '0'));
END;

[Martin S. (strubi)]

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:

process (clk, ce)
begin
    if ce = '1' and rising_edge(clk) then
        do_stuff(..)
    end if;
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...