Gast
#3114740
Guten Morgen, mir liegt ein VHDL-Code vor, in welchem viele dieser Konstrukte sind:
1 | |
2 | |
3 | |
Die Abfrage macht für mich gar keinen Sinn.
1 | |
sollte doch genau das gleiche tun, oder täusche ich mich da?
|
Anzeige
|
Doofe Frage: Signal vor dem Löschen abfragen?
Gast
#3114740
Guten Morgen, mir liegt ein VHDL-Code vor, in welchem viele dieser Konstrukte sind:
Die Abfrage macht für mich gar keinen Sinn.
sollte doch genau das gleiche tun, oder täusche ich mich da? @Jens Langecker (Gast) >mir liegt ein VHDL-Code vor, in welchem viele dieser Konstrukte sind: >if (meinSignal = '1') then > meinSignal <= '0'; >end if; Das ist nur eine Zuweiseung. Es kann an anderes Stellen im Prozess noch mehr Zuweisungen an die Variable geben, wo diese gesetzt wird. >Die Abfrage macht für mich gar keinen Sinn. > meinSignal <= '0'; >sollte doch genau das gleiche tun, oder täusche ich mich da? Du täuschst dich. Denn hier wird die Variable immer gelöscht. Im obigen Beispiel ist das nicht so, sondern nur, wenn sie vorher gesetzt war. Sowas nutzt man zur Speicherung von Informationen (Flags). Ein Prozess setzt das Signal auf 1, wenn er Daten bereitgestellt hat. Ein zweiter Prozess erkennt das und liest die Daten, gleichzeitig löscht er das Flag. (Jaja, Signale kann man nur innerhalb eines Prozesses schreiben, aber das ist ein anderes Thema) Falk Brunner schrieb: > Zuweisungen an die Variable Hmmm, da ist weit&breit keine zu sehen. Zum Glück... ;-) Denn sonst wäre der Sachverhalt ein ganz Anderer. Jens Langecker schrieb: > mir liegt ein VHDL-Code vor, in welchem viele dieser Konstrukte sind: > if (meinSignal = '1') then > meinSignal <= '0'; > end if; > Die Abfrage macht für mich gar keinen Sinn. > meinSignal <= '0'; > sollte doch genau das gleiche tun, oder täusche ich mich da? Du hast Recht. Es kann aber noch ein andere Gedankengang dahinterstecken. Wenn es z.B. so aussieht
dann ist das einfach nur zum Verdeutlichen des Sachverhalts, dass meinSignal erst dann 0 wird, wenn meinAnderesSignal den Wert von irgendwas übernommen hat. Natürlich wird der Synthesizer dabei die if-Abfrage für meinSignal herausoptimieren....
Gast
#3114834
Danke. Falk Brunner schrieb: > > Du täuschst dich. Denn hier wird die Variable immer gelöscht. Im obigen > Beispiel ist das nicht so, sondern nur, wenn sie vorher gesetzt war. Es handelt sich um Signale und nicht um Variablen. Es macht doch keinen Unterschied, ob ich ein Signal auf 0 setze, welches schon auf 0 steht. Lothar Miller schrieb: > Es kann aber noch ein andere Gedankengang dahinterstecken. Definitiv nicht. Es sind wirklich immer diese 3-Zeiler,
ohne sonst etwas dabei.
Gast
#3114865
Jens Langecker schrieb: > Es sind wirklich immer diese 3-Zeiler [...] ohne sonst etwas dabei. ... Dann ist es auch wirklich sinnlos und du hast Recht mit deiner Annahme, dass es durch ein einfaches meinSignal <= '0'; ersetzbar wäre. Jens Langecker schrieb: > Es sind wirklich immer diese 3-Zeiler, ohne sonst etwas dabei. Ab hier würde ich mir Sorgen um das restliche Design machen... Jens Langecker schrieb: > Lothar Miller schrieb: >> Es kann aber noch ein andere Gedankengang dahinterstecken. > Definitiv nicht. > Es sind wirklich immer diese 3-Zeiler,if (meinSignal = '1') then > meinSignal <= '0'; > end if; > ohne sonst etwas dabei. Kann es vielleicht sein, dass meinSignal wo anders nochmal abgefragt wird oder solange er auf High ist irgendein Modul aktiviert ist? Vielleicht reagiert sogar irgendein Modul auf die pos. oder neg. Flanke vom meinSignal. Poste mal zur Not mehr Quell-Code, denn so kann man schwer eine Aussage treffen. Cihan
Gast
#3114890
Jens Langecker schrieb: > mir liegt ein VHDL-Code vor, in welchem viele dieser Konstrukte sind:if (meinSignal = '1') then > meinSignal <= '0'; > end if; > > Die Abfrage macht für mich gar keinen Sinn. meinSignal <= '0'; > sollte doch genau das gleiche tun, oder täusche ich mich da? Du täuscht Dich, es mag vielleicht das selbe tun, ist es aber nicht. Abhängig von dem drumherum (ich nehme an getakteter process) beschreibt der Dreizeiler den invertierten RESET Eingang eines FF; der Einzeiler dagegen einen auf '0' geklemmten D eingang eines D-FF. Die unterschiedliche Beschreibung kann zu unterschiedliche großen Designs führen. siehe http://www.xilinx.com/support/documentation/white_papers/wp275.pdf Bild 6 und 8. Ein FF kann auf verschiedene Weisen gelöscht werden, selbes funktionales Ergebnis (Verhalten) unterschiedliche Resourcennutzung (LUT, Routing). VHDL ist eben eine Hardwarebschreibungssprache und kein Programmiersprache. MfG,
Gast
#3114917
Hier mal ein vereinfachter Ausschnitt aus dem Programm:
Es geht um das Signal "Go" und die Zeilen
Gast
#3114945
Jens Langecker schrieb: > Hier mal ein vereinfachter Ausschnitt aus dem Programm: Zu stark vereinfacht, GO wird in den geposteten Zeilen nirgends gesetzt. Karl Könner schrieb: > Die unterschiedliche Beschreibung kann zu unterschiedliche großen > Designs führen. Es kann sogar die exakt gleiche Beschreibung und nur die Reihenfolge der Zuweisung zu einem anderen Ergebnis führen: http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html
Gast
#3115019
Smuliere einfach mal:
versus die Variante ohne das "überflüssige" if
Lattice User schrieb: > Smuliere einfach mal: > >
> > versus die Variante ohne das "überflüssige" if > >
In dem ersten Fall wird Go auf HIGH gesetzt und erst wieder LOW gesetzt, wenn es im nächsten Takt auf HIGH ist. Im zweitem Fall bleibt GO immer auf LOW, da GO <= '0'; als letzte Zuweisung in einem Process zugewiesen wird. Cihan
Gast
#3115023
Lattice User schrieb: > Zu stark vereinfacht, GO wird in den geposteten Zeilen nirgends gesetzt. Ups! Doof. Egal, meine Frage ist beantwortet. Danke euch allen! Evtl. hat das auch was mit der Simulation zu tun. Da gibts ja neben 0 und 1 noch mehr Werte...
Gast
#3116039
Lothar Miller schrieb: > Es kann aber noch ein andere Gedankengang dahinterstecken. Wenn es z.B. > so aussieht if (meinSignal = '1') then > meinSignal <= '0'; > meinAnderesSignal <= irgendwas; > end if; > dann ist das einfach nur zum Verdeutlichen des Sachverhalts, dass > meinSignal erst dann 0 wird, wenn meinAnderesSignal den Wert von > irgendwas übernommen hat. > Natürlich wird der Synthesizer dabei die if-Abfrage für meinSignal > herausoptimieren.... Hm nicht ganz ... eher umgekehrt, meinAndresSignal wird erst dann aktualisiert, wenn (irgendwo mal) meinSignal auf 1 gesetzt wurde ... und dann wird das if auch nicht wegoptimiert, das gilt dann für meinAnderesSignal (und meinSignal ist ne Art Semaphore dazu ...) Karl schrieb: > dann wird das if auch nicht wegoptimiert, das gilt dann für > meinAnderesSignal Ich meinte das selbe: >> Natürlich wird der Synthesizer dabei die if-Abfrage für meinSignal >> herausoptimieren... Klar darf die Abhängigkeit zwischen meinSignal und meinAnderesSignal nicht wegoptimiert werden. Nur der Selbstbezug von meinSignal kann evtl. herausoptimiert werden. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|