Hallo, guten Tag.
Ich finde Processe mit und ohne vorhergehenden Namen und
Klammervariablen :
---------------------------------
test: process(S,E)
begin
....
....
end process test;
----------------------------------
Welche bedeutung haben die?
Das compilieren funktioniert auch.
Wo kann ich überall die Variablen nutzen, die gleich hinter
"architecture" kommen und wo die Variablen die hinter "process" erstellt
werden?
Danke.
:
Bearbeitet durch User
Verdammt, du weißt was jetzt für einen Antwort kommt, oder? Sie fängt mit B an, und hört mich uch auf! Und bis das Buch da ist: https://www.google.de/#q=vhdl+prozess
Da Dieter schrieb: > Verdammt, du weißt was jetzt für einen Antwort kommt, oder? > > Sie fängt mit B an, und hört mich uch auf! ich fand ja vhdl schon immer kurios, aber das hat jetzt ein Badetuch damit zu tun? scnr
Ich weiss du bist ziemlicch schlau... Buch ist da, Ätsch.... Hmmm..., im Buch stehen Beispiele , es steht nichts darüber drin wann von wo auf welche Variablen man zugreifen darf und welchen Stellenwert die Namen vor "process" haben. Gruss
:
Bearbeitet durch User
Solche einfachen Sachen lassen sich aber wirklich mit Literatur klären. >es steht nichts darüber drin wann > von wo auf welche Variablen man zugreifen darf weil da auch auf keine Variablen zugegriffen wird. In deinem Beispiel sind weit und breit keine drin.
Hmmm..., im Buch bei mir sind sehr viele Beispiele....mit den oben genannten. Es wird dort aber nichts über meine Frage beschrieben. Gruss
:
Bearbeitet durch User
Peter Bierbach schrieb: > Hmmm..., im Buch bei mir sind sehr viele Beispiele....mit den oben > genannten. > > Es wird dort aber nichts über meine Frage beschrieben. Sorry, aber Deine Fragen gehören zu den absoluten Grundlagen. Sollten diese tatsächlich nicht in Deinem Buch beantwortet werden, dann schmeiß das Buch weg und probiere z. B. das da: http://de.wikibooks.org/wiki/VHDL (Anm.: Ich habe es nicht komplett durchgesehen, auf einen ersten Blick sieht es aber ganz brauchbar aus) Um Deine Fragen zu beantworten (auch wenn Dir die isolierte Beantwortung dieser nicht weiter hilft, daher: Buch komplett durcharbeiten und verstehen): > Ich finde Processe mit und ohne vorhergehenden Namen und > Klammervariablen : > Welche bedeutung haben die? Namen sind bei Prozessen zunächst erst einmal irrelevant und dienen nur der Übersichtlichkeit. > Das compilieren funktioniert auch. Hardwarebeschreibungscode wird nicht compiliert, sondern synthetisiert. Das ist etwas völlig Anderes. Grundlagen -> Buch. > Wo kann ich überall die Variablen nutzen, die gleich hinter > "architecture" kommen und wo die Variablen die hinter "process" erstellt > werden? Hinter dem Schlüsselwort "process" werden überhaupt keine "Variablen" "erstellt". Stichwort: sensitivity list. Im Allgemeinen arbeitet man auch in synthetisierbarem Code nicht mit Variablen (bzw. sollte es auch tunlichst vermeiden, wenn man nicht 100%ig weiß, was man da tut), sondern mit Signalen. Variablen und Signale verhalten sich unterschiedlich; Grundlagen -> Buch.
Ha...ha.. , dieses Buch wurde hier empfohlen. ------------------- Hinter dem Schlüsselwort "process" werden überhaupt keine "Variablen" "erstellt". Stichwort: sensitivity list. Im Allgemeinen arbeitet man auch in synthetisierbarem Code nicht mit Variablen (bzw. sollte es auch tunlichst vermeiden, wenn man nicht 100%ig weiß, was man da tut), sondern mit Signalen. ------------------- Im Buch werden Variablen sehr oft genutzt , die dann auch konvertiert werden für die Signale ooder auch Signale in Variablen. Scheint dir neu zu sein ??? Allzu groß ist dein Wissen auch nicht. Ich sehe es gibt noch mehr solche wie ich hier. Mit deinem Halbwissen wirst du nicht weit kommen. Gruss
:
Bearbeitet durch User
Peter Bierbach schrieb: > Hallo, guten Tag. > > Ich finde Processe mit und ohne vorhergehenden Namen und > Klammervariablen : > --------------------------------- > test: process(S,E) > begin > .... > .... > end process test; > ---------------------------------- test: ist ein Label, einfach nur eine Marke die auf eine bestimmte Zeile oder konstrukt im quelltext verweist. Das label gibt den process einen Namen. Bei process sind labels optional aber empfehlenswert da sie die code-durchsicht vereinfachen und in der Simulation nützlich sind (http://communities.mentor.com/mgcx/servlet/JiveServlet/previewBody/2324-102-2-5693/HDL-Standards-UG-CAST.rev1b.pdf S.30) > Welche bedeutung haben die? > Das compilieren funktioniert auch. > > Wo kann ich überall die Variablen nutzen, die gleich hinter > "architecture" kommen und wo die Variablen die hinter "process" erstellt > werden? Was wie variablen resp funktionsparameter in C aussieht, sind hier signale. VHDL unterscheidet strikt nach variable und signal. Für den Anfang reicht es auf variable komplett zu verzichten. Signal steht vereinfacht gesprochen für einen "Draht" in der Schaltung. die sensitivity list steuert die abarbeitung des processes. Nur wenn bei einem signal in der sense list ein ereignis auftritt, wird der process vom simulator abgearbeitet ein synchrones D-FF sieht bspw. so aus:
1 | d_ff_here:process(clk) |
2 | begin
|
3 | if rising_edge(clk) then |
4 | if en = '1' then q_out <= d_in; |
5 | end if; |
6 | end if; |
7 | end process d_ff_here; |
nur wenn sich auf der Taktleitung clk was tut, wird der Simulator sich die anweisungen im process anschauen. wenn der takt von '0' auf '1' wechselt (steigende Flanke) und das enable (auch CS Chipselect genannt) auf logisch '1' steht wird der Wert des signls d_in abgespeichert und erscheint ab dann als ausgangssignal q_out. Für den anfang sollte sich nur der Takt (clk) und wenn nötig der asynchrone reset (arst) in der sense liste befinden. Man kann die sense liste auch leer lassen, dann braucht man aber (fast?) zwingend eine wait anweisung im process ... Die funktion der sense liste wird meist im abschnitt Simulation erklärt. Für die Synthese hält man sich an vorgegebene Codemuster (templates) die das Synthesetool versteht, also für getaktetete FF ein process wie oben beispielhaft gezeigt. Sowenig in aller Kürze,
test: process(S,E) Das S und das E können hier alles Mögliche sein, also Variablen, Signale, ... die werden da aber nicht erstellt sondern wo anders im Code. Hier sind die NUR für den Simulator da. Der Simulator guckt, wann sich der Wert davon ändert und berechnet dann den Prozess neu. Wenn du das auf einem FPGA laufen lassen willst, dann ist das total egal, es ist auch generell vermutlich egal weil der Simulator auch ohne das () funktioniert, aber vielleicht mehr rechnen muss. Ich habe bisher nichts negatives gemerkt wenn ich es weggelassen habe.
Gustl, sie sind auch für die Synthese da. Das Synthesetool nutzt die Verkettung der Signale um die Optimierungen über den Code laufen zu lassen. Wenn Du die Liste weglässt, weiss die Synthese nicht, welche Signale im Prozess relevant sind und muss alle durchschauen. Das Prinzipergebnis ist Dasselbe, das Detailergebnis aber geringfügig anders und die Compilezeit kann steigen. Zu den Variablen: Peter, Variablen werden dann verwendet, wann man während der Simulation oder der Synthese komplezierte oder verschachtelte Sachen machen will, die man anders nicht hinschreiben kann. Solange Du keine brauchst, musst Du keine verwenden. zu den " verschiedene Schreibweisen bei "process"" Das vorne ist einfach ein Benennungsmarker
Ui ok Danke, dann werde ich das beachten. Ich leide nämlich unter dem langsamen XST.
Gustl Buheitel schrieb: > Ui ok Danke, dann werde ich das beachten. Ich leide nämlich unter > dem langsamen XST. Naja, bei Xilinx wäre mir das völlig neu, da müsste C.N. erst mal eine Quelle liefern. Dem Synthesizer ist die Sensitivitätsliste egal, da gibts nur eine Warnung.
C. N. schrieb: > Peter, Variablen werden dann verwendet, wann man ... > Solange Du keine brauchst, musst Du keine verwenden. Und wenn du sie brauchst, solltest du sie mit äusserster Vorsicht verwenden: Beitrag "Variable vs Signal" BTW: kauf dir für solche Fragen den Designers Guide to VHDL von Peter Ashenden auch noch. Ashenden sitzt mit drin im VHDL "Normungsgremium". Und, Peter: alle deine Fragen wurden hier im Forum schon mal in aller Ausführlichkeit diskutiert. Warum suchst du nicht einfach ein wenig? Christian R. schrieb: > Dem Synthesizer ist die Sensitivitätsliste egal, da gibts nur eine > Warnung. Nicht mal das. Es ist nur eine Info, dass die Realität nicht zur Simulation passt...
:
Bearbeitet durch Moderator
------------------------------ "Hinter dem Schlüsselwort "process" werden überhaupt keine "Variablen" "erstellt". Stichwort: sensitivity list. ----------------------------- Buch : VHDL-Synthese von Jürgen Reicherdt | Bernd Schwarz Seite 50 ganz unten 4. Auflage : ............. ............. P1: process(CLK) variable TEMP: bit; begin if CLK=.... ....... Ist der Reicherdt und der Schwarz auf der falschen Linie...oder kann es sein das sie auch nur abgeschrieben haben.....? Gruss
:
Bearbeitet durch User
Jaja aber natürlich ist im Buch ein Fehler und die Autoren Abschreiber.....
Peter Bierbach schrieb: > Ist der Reicherdt und der Schwarz auf der falschen Linie... Nein. Du hast den Kopiervorgang vor der interessanten Stelle abgebrochen. Interessant wird es nämlich dort, wo diese Variable namens TEMP (von Englisch temporary = vorübergehend) verwendet wird. Und genau das passiert dort: die Variable wird nur zum "Merken" eines Zwischenergebnisses verwendet... > oder kann es sein das sie auch nur abgeschrieben haben.....? Kann gut sein, dass die beiden einiges übernehmen mussten. Weil VHDL ja schon erfunden war...
:
Bearbeitet durch Moderator
So langsam bekommt die Diskusson den Touch von "Nämlich schreibt man doch mit h." Was ja auch irgendwie stimmt, aber trotzdem am Problem vorbeigeht ;)
C. N. schrieb: > Gustl, sie sind auch für die Synthese da. Das Synthesetool nutzt die > Verkettung der Signale um die Optimierungen über den Code laufen zu > lassen. Wenn Du die Liste weglässt, weiss die Synthese nicht, welche > Signale im Prozess relevant sind und muss alle durchschauen. Das > Prinzipergebnis ist Dasselbe, das Detailergebnis aber geringfügig anders > und die Compilezeit kann steigen. Das ist falsch/Quatsch. Die Sensitivity List ist hautptsächlich für die Simulation wichtig, da sie bestimmt, auf welche Signale der Prozess reagieren soll und in manchen fällen bekommt man damit auch ein unterschiedliches Simulationsergebnis (gewünscht oder manchmal auch nicht). In jedem Fall kann man Performance-Unterschiede in der Simulation haben, wenn man Signale angibt, die nicht notwendig sind. Beispiel ist ein FF. Der Ausgang ändert sich nur, wenn der der Takteingang (und/oder Reset) sich ändert. Deshalb sind Takt und Reset in der Sensitivity List. Gibt man auch den D-eingang in die Sensitivity List, dann wird der Prozess zusätzlich nochmal durchgerechnet, wenn sich D ändert, aber die Berechnung berechnet nicht neues, weil die Rechnung über das if rising_edge() drüberspringt. Für die Synthese wird die Sensitivity List meist ignoriert und leider nicht einmal kontrolliert, weil die Synthese im VHDL Kode nur bestimmte Muster erkennt, z.B. prozess mit internem "if rising_edge(clk)" sagt dem Compiler, dass er ein FF bauen soll. Georg A. schrieb: > So langsam bekommt die Diskusson den Touch von "Nämlich schreibt man > doch mit h." Was ja auch irgendwie stimmt, aber trotzdem am Problem > vorbeigeht ;) Mir kommt vor, es geht schon in Richtung dämlich.
Klaus Falser schrieb: > Die Sensitivity List ist hautptsächlich für die Simulation wichtig, da > sie bestimmt, auf welche Signale der Prozess reagieren soll und in > manchen fällen bekommt man damit auch ein unterschiedliches > Simulationsergebnis (gewünscht oder manchmal auch nicht). Meist ist nur eines der Simulationsergebnisse richtig... ;-) > In jedem Fall kann man Performance-Unterschiede in der Simulation haben, > wenn man Signale angibt, die nicht notwendig sind. Beispiel ist ein FF. Das ist heute nicht mehr der Fall, solche unnötigen Signale erkennt der Compiler und optimiert sie raus. Schlimmer ist aber der andere Fall: Der Compiler nimmt von sich aus nicht automatisch fehlende Signale in die Sensitivliste mit auf...
Lothar Miller schrieb: > Schlimmer ist aber der andere Fall: Der > Compiler nimmt von sich aus nicht automatisch fehlende Signale in die > Sensitivliste mit auf... woran wollte man das auch festmachen, wenn es nötig ist und wann nicht
Ralf schrieb: > woran wollte man das auch festmachen, wenn es nötig ist und wann nicht Wenn ein Signal durch eine Änderung eines (anderen oder des gleichen) Signals geändert wird, dann muss dieses Signal in die Sensitivliste. Man kann z.B. leicht einen Zähler bauen, der mit doppelter Taktfrequenz hochzählt und tadellos simuliert:
1 | process (clk) begin |
2 | counter <= counter+1; |
3 | end process; |
In der Praxis aber totaler Müll ist: http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html Wenn man diese fehlerhafte Sensitivliste korrigiert und so was schreibt:
1 | process (counter) begin |
2 | counter <= counter+1; |
3 | end process; |
Dann merkt auch der Simulator, dass das Schortt ist und nie fertig wird... Bei getakteten Prozessen ist es einfach: nur eine Taktflanke kann eine Änderung anderer Signale bewirken. Deshalb muss nur der Takt in die Sensitivliste. Schlimmstenfalls darf/muss da noch ein asynchroner Reset mit rein.
Hmmm.. ------------------------------ die Variable wird nur zum "Merken" eines Zwischenergebnisses verwendet... ------------------------------ Es geht hier um eine strikte Verneinung diese Variable dort hinzusetzen. Wofür die jetzt verwendet wird im Buch steht hier nicht zur Diskussion. Gruss
Lothar Miller schrieb: >> In jedem Fall kann man Performance-Unterschiede in der Simulation haben, >> wenn man Signale angibt, die nicht notwendig sind. Beispiel ist ein FF. > Das ist heute nicht mehr der Fall, solche unnötigen Signale erkennt der > Compiler und optimiert sie raus. Schlimmer ist aber der andere Fall: Der > Compiler nimmt von sich aus nicht automatisch fehlende Signale in die > Sensitivliste mit auf... Reden wir vom Simulator oder Synthese? Ich sprach von der Simulation. Fällt mir ein bischen schwer zu glauben, dass sich da ModelSim oder ISIM Freiheiten erlauben....
Ist der FPGA euer Lebensunterhalt oder euer Hobby...? Gut das es nur mein Hobby ist... Schimpf...schimpf.. -------------------- Mir kommt vor, es geht schon in Richtung dämlich. -------------------- GRuss
Peter Bierbach schrieb: > Ist der FPGA euer Lebensunterhalt oder euer Hobby...? Sowohl als auch Klaus Falser schrieb: > Reden wir vom Simulator oder Synthese? Sowohl Simulator als auch Synthesen profitieren von einer korrekt eingestellten Sens-Liste, das kann man vermessen. Allerdings ist es kaum zu fühlen. Also praktisch egal. Lothar Miller schrieb: >> woran wollte man das auch festmachen, wenn es nötig ist und wann nicht > Wenn ein Signal durch eine Änderung eines (anderen oder des gleichen) > Signals geändert wird, dann muss dieses Signal in die Sensitivliste. Vorsicht! Man kann Simulationen so aufbauen, dass das ein Signal als Quasi-Takt arbeitet und folglich dürfen die Signale, die dann gesynched werden, NICHT in die Sens Liste! Würde man das weiter zulassen wollen und der Simulator austomatisch alles mitreinnehmen, würden viele Modelle nicht funktionieren und Einschränkungen bestehen. Das darf also nicht sein. Die Sens-Liste hat so wie sie ist, schon ihren Sinn. Wer das eben nicht richtig nutzt, muss halt lernen.
Peter Bierbach schrieb: > Schimpf...schimpf.. > -------------------- > Mir kommt vor, es geht schon in Richtung dämlich. Nur zur Richtigstellung: Das dämlich bezog sich auf auf keine Person, sondern auf diese Diskussion, die aus jedem Ruder läuft und teilweise sinnlos kreuz und quer von Thema zu springt. Punkt.
Weltbester FPGA-Pongo schrieb im Beitrag #3634228: > Vorsicht! Man kann Simulationen so aufbauen, dass das ein Signal als > Quasi-Takt arbeitet und folglich dürfen die Signale, die dann gesynched > werden, NICHT in die Sens Liste! Das geht, darf aber keinem Anfänger empfohlen werden. Denn natürlich kann ich ein Auto mit Schaltgetriebe auch ohne Kupplung fahren. Ein Anfänger tut sich da schwerer und könnte schon mal unerwünschte Effekte im Antriebsstrang hervorrufen... Klaus Falser schrieb: > Lothar Miller schrieb: >>> In jedem Fall kann man Performance-Unterschiede in der Simulation haben, >>> wenn man Signale angibt, die nicht notwendig sind. Beispiel ist ein FF. >> Das ist heute nicht mehr der Fall, solche unnötigen Signale erkennt der >> Compiler und optimiert sie raus. > Reden wir vom Simulator oder Synthese? > Ich sprach von der Simulation. > Fällt mir ein bischen schwer zu glauben, dass sich da ModelSim oder ISIM > Freiheiten erlauben.... Richtig. In der Defaulteinstellung wird für die Simulation alles hergenommen, was in der Sensitivliste steht.
Peter Bierbach schrieb: > Allzu groß ist dein Wissen auch nicht. > Ich sehe es gibt noch mehr solche wie ich hier. > > Mit deinem Halbwissen wirst du nicht weit kommen. http://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
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.