VHDL falling edge bewirkt rising edge

[J. K. (rooot)]

Hi

Ich hab jetzt begonnen mich ein bisschen in VHDL einzulesen, bevors auf 
der Uni so richtig damit losgeht. Schon steh ich auf vor dem ersten 
Problem:

Mein einfaches Toggle-FlipFlop sollte auf falling-edges reagiern, tut 
aber nur was bei rising-edges.

An was kann das liegen?

MfG
Jürgen


Die beiden sources hab ich mal angehängt. Der enable-Eingang ist zwar 
vorgesehn, aber noch nicht modelliert.

[Falk B. (falk)]

@  J. K. (rooot)

>Mein einfaches Toggle-FlipFlop sollte auf falling-edges reagiern, tut
>aber nur was bei rising-edges.

Wo? In der Simulation oder in Hardware?

Das FlipFlop ist schon OK, nur deine Ausgangszuweisung versaut dir die 
Simulation. Waum ist das so? Dein Prozess wird nur ausgewertet, wenn 
sich clk ändert (sensitivity list). Also wird Y<=outs nur bei der 
steigenden Flanke aktualisiert. Ist der kleine gemeine Unterschied 
zwischen variablen und Signalen. ;-)  In Hardware macht das in deinem 
Beispiel keinen Unterschied.

http://www.mikrocontroller.net/articles/VHDL#Wann_und_warum_verwendet_man_Variablen.3F

Eher so, ausserhalb des Prozesses.

    process(clk)
    begin
      -- compare to truth table
      if falling_edge(clk) then
        outs <= not outs;
      end if;
    end process;

    Y <=outs;

MfG
Falk

[J. K. (rooot)]

Ja, in der Simulation tut es so.

Das kommt davon wenn man mal drauf los bastelt ohne wirklich ne Ahnung 
zu haben....

Danke!

[Sparxx (Gast)]

Ich bin ebenfalls neu un mich verwirrt den Unterschied simulation und 
hardware synthese.

Falk Brunner schrieb:
> In Hardware macht das in deinem
> Beispiel keinen Unterschied.

wie ist das gemeint?Heißt das dass,im Hardware y würde beim falling_edge 
richtig dargestellt?

[Falk B. (falk)]

@  Sparxx (Gast)

>Ich bin ebenfalls neu un mich verwirrt den Unterschied simulation und
>hardware synthese.

Der Compiler für die Hardware erkennt den Fehler, erzeugt im Idealfall 
eine Warnung und macht dennoch das Richtige draus, weil aus Sicht einer 
Hardwaresynthese es keinen Unterschied gibt. Der Simulator ist da 
"pingelig" und reagiert nur auf das, was man ihm sagt, ist auch gut so.
An sich ist die Schreibweise des OP schlechter Stil, denn in einem 
GETAKTETEM Prozess gibt es sinnvollerweise KEINERLEI Anweisungen 
ausserhalb von if rising_edge()

    process(clk)
    begin
      if falling_edge(clk) then
        -- nur hier steht irgendetwas
        outs <= not outs;
      end if;
      -- hier steht in Normalfall NIE etwas
    end process;

>> In Hardware macht das in deinem
>> Beispiel keinen Unterschied.

>wie ist das gemeint?Heißt das dass,im Hardware y würde beim falling_edge
>richtig dargestellt?

Ja.

MfG
Falk

[Sparxx (Gast)]

@  Falk Brunner
 besten Dank.Jetzt ist mir vieles klar geworden.
Mit einem Oszi. hätte aus  FPGA Pins sicherlich erkannt,was im hardware 
wirklich passiert.
Gibt es so "Richtlinien",dass man sich aus einem Simultionsergebnis das 
Hardwareergebnis vorstellen kann?(wenn man kein Oszi hat)

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

Sparxx schrieb:
> Gibt es so "Richtlinien",dass man sich aus einem Simultionsergebnis das
> Hardwareergebnis vorstellen kann?(wenn man kein Oszi hat)
Wenn die Sensitivliste der beteiligten Prozesse richtig beschrieben ist, 
dann sieht das normalerweise GLEICH aus.

Einen Schritt zurück:
Das Problem hier ist eigentlich eine unvollständige Sensitivliste!

Denn in der Sensitivliste eines Prozesses müssen für eine korrekte 
Simulation alle Signale stehen, die zu einer Änderung des Ergebnisses 
führen.

Ich zerpflücke mal den ursprünglichen Prozess und zäume das Pferd von 
hinten auf:

    process(clk)
    begin

       if falling_edge(clk) then    -- mit dem Takt ändert sich was
          outs <= not outs;
        end if;

        Y <=outs;                   -- und mit einer Änderung von outs ändert sich auch was!
 
    end process;

Hier müsste die korrekte Sensitivliste also so aussehen:

    process(clk, outs)
    begin ...

Jetzt klappts auch mit der Simulation.

Achtung:
Man kann zwar solche getakteten und kombinatorischen Prozesse machen, 
aber man kann sich damit auch sehr leicht ein Ei legen. Und daher ist 
die Anmerkung von Falk richtig:
>> An sich ist die Schreibweise des OP schlechter Stil, denn in einem
>> GETAKTETEM Prozess gibt es sinnvollerweise KEINERLEI Anweisungen
>> ausserhalb von if rising_edge()
Allerdings finden sich in gut 95% aller Bücher genau solche Prozesse:

    process(reset, clk)
    begin
      if falling_edge(clk) then
        -- hier steht irgendetwas
      end if;
      if reset='1' then
        -- hier steht auch was
      end if;
    end process;

Was? Sieht unbekannt aus?
Dann mal die gleichwertige Schreibweise:

    process(reset, clk)
    begin
      if reset='1' then
        -- hier steht auch was
      elsif falling_edge(clk) then
        -- hier steht irgendetwas
      end if;
    end process;

BTW:
Ich verwende zur konsequenten Verhinderung von unvollständigen 
Sensitivlisten gern die Prozessschreibweise ohne Sensitivliste:
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html
Dann passiert das oben Beschriebene garantiert nicht.

[Sparxx (Gast)]

@  Lothar Miller
 Sehr gut erklärt,vielen Dank.
 Ich hätte allerdings eine letzte Frage:
bei dieser Variante im Simulator

process(clk)
    begin
       if falling_edge(clk) then 
         outs <= not outs;
       end if;
        Y <=outs;              
    end process;

ist das Signal  am Ausgang y um einer Taktperiode verschoben.Ist dies 
auch der Fall im realen Hardware?
Bei konkurrenten Anweisungen wären die Signale taktgenau.
Nochmals Danke.

[Sparxx (Gast)]

> ist das Signal  am Ausgang y um einer Taktperiode verschoben.Ist dies
> auch der Fall im realen Hardware?

Vergessen sie die  Frage.
hab probiert mit leds und es ist auch taktverschoben.
Danke.

[Falk B. (falk)]

@Sparxx (Gast)

>> ist das Signal  am Ausgang y um einer Taktperiode verschoben.Ist dies
>> auch der Fall im realen Hardware?

>Vergessen sie die  Frage.
>hab probiert mit leds und es ist auch taktverschoben.
>Danke.

Nö, das kannst du gar nicht messen, weil dir der Bezug fehlt.
Das FlipFlop schaltet mit jeder fallenden Flanke um. Wann schaltet dein 
Ausgang. Ich behaupte mal, auch mit der fallenden Flanke. Denn es ist 
UNABHÄNIG von falling_edge() und damit praktisch eine concurrent 
Zuweisung, auch wenn outs in der sensitivity list fehlt.

MfG
Falk

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

Sparxx schrieb:
> Bei konkurrenten Anweisungen wären die Signale taktgenau.
Wie meinst du diese Aussage? Was ist für dich "taktgenau"?

Sparxx schrieb:
> hab probiert mit leds und es ist auch taktverschoben.
Wie Falk glaube ich dir das auch nicht. Zeig mal deinen Code, deinen 
Messaufbau und deine Messergebnisse. Es ist vermutlich einfach so, dass 
das Signal mit jeder fallenden Flanke umschaltet...
In der Simulation sieht es aus, wie wenn es mit der steigenden Flanke 
umschalten würde...


Mein Tipp: um etwas Licht im Dunkeln zu haben sieh dir einfach mal den 
RTL-Schaltplan der Synthese an. Dort siehst du, wie der Synthesizer 
deine Beschreibung in Hardware übersetzt hat.

[Sparxx (Gast)]

Sorry,weiß nicht wo ich meinen Kopf hatte,als ich das oben geschrieben 
habe.
Falk Brunner schrieb:
> Wann schaltet dein
> Ausgang. Ich behaupte mal, auch mit der fallenden Flanke.

Genau.

Lothar Miller schrieb:
> Wie meinst du diese Aussage? Was ist für dich "taktgenau"?

Damit meinte ich beim Auftreten der Flanke,beide Signale  dengleichen 
Wert haben.(Siehe Simulationsergebnis).PS:Hier ist der Takt 50 MHz.
Natürlich wenn der Ausgang mit in der Flankenabfrage steht,dann 
übernimmt er seinen Wert eine Taktperiode später.Liege, hoffe ich 
,richtig!!

Lothar Miller schrieb:
> Zeig mal deinen Code,

Mein Code für den Test mit LEDs

 TOGGLE: process (clk_2,out_s)  --clk_2 ist ein 1 Hz Clock  
begin 
  if falling_edge(clk_2)then
    out_s<=not out_s;
--  y_1<=out_s;                 --Diese Variante meinte,taktverzögert     
  end if;
    y_1<=out_s;
end process;
 clk2 <=clk_2;
 y_2 <= out_s; 
 led(9 downto 3)<=(OTHERS=>'0');
 led(2)<= clk_2;
 led(1)<= y_2;
 led(0)<= y_1;

[lkmiller (Gast)]

> taktverzögert...
Das Stichwort "Latency" ist hier das Richtige....

[Sparxx (Gast)]

lkmiller schrieb:
> Das Stichwort "Latency" ist hier das Richtige....

ok verstanden.
Ich hätte noch eine Verständnis Frage:

Lothar Miller schrieb:

    process(clk,out_s)
    begin
       if falling_edge(clk) then    -- mit dem Takt ändert sich was
          outs <= not outs;
        end if;

        Y <=outs;    -- und mit einer Änderung von outs ändert sich auch was!
     end process;

Der Process wird bei jedem Taktflankenwechsel aktiviert,richtig?
Aber "wie oder wann" wird er bei einer Änderung von out_s aktiviert ?

[Duke Scarring (Gast)]

Mach doch da mal zwei Prozesse draus, nachher schreibt das noch jemand 
falsch ab...

process(clk)
begin
   if falling_edge(clk) then    -- mit dem Takt ändert sich was
      outs <= not outs;
   end if;
end process;

process(out_s)
begin
   Y <=outs;    -- und mit einer Änderung von outs ändert sich auch was!
end process;

Und da kannst Du es auch gleich so schreiben:

process(clk)
begin
   if falling_edge(clk) then    -- mit dem Takt ändert sich was
      outs <= not outs;
   end if;
end process;

Y <=outs;    -- und mit einer Änderung von outs ändert sich auch was!

Duke

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

Sparxx schrieb:
> Der Process wird bei jedem Taktflankenwechsel aktiviert,richtig?
Ja, oder doch eher nein...
Du hast noch immer ein Verständnisproblem. Der Prozess wird nicht 
"aktiviert", sondern er "muss neu berechnet werden". Und zwar betrifft 
das nur den Simulator.

> Aber "wie oder wann" wird er bei einer Änderung von out_s aktiviert ?
die Sensitivliste dast:
Bei jeder Änderung von clk oder out_s muss der Prozess vom Simulator 
nochmal berechnet werden.

Die Synthese schert sich (wie schon erwähnt) einen feuchten Kehrricht um 
die Sensitivliste, bei einer falschen Liste bekommst du bestenfalls eine 
freundliche Info, dass wohl deine Simulation nicht mehr zur Hardware 
passt...

Hier nochmal ein Beispiel für eine unvollständige Sensitivliste:
Bei sowas wie diesem Prozess hier wird die Simulation einen schönen 
Zähler bauen, der mit jedem Tastendruck hochzählt, weil der Prozess vom 
Simulator ja nur bei einer Änderung neu berechnet wird:

   process (taster) begin
      if taster='1' then
          cnt <= cnt+1;
      end if;
   end process;

In der Hardware hast du dir aber eine kombinatorische Schleife gebaut, 
und cnt wird (theoretisch) mit Vollgas hochzählen, solange der Taster 
gedrückt ist...
(BTW: in der Praxis ist das aber nicht der schnellstmögliche Zähler, 
sondern nur ein dubioser Rauschgenerator)
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife

[Sparxx (Gast)]

Duke Scarring schrieb:
> Mach doch da mal zwei Prozesse draus
ok,ist viel übersichtlicher.

Ich habe leider keine Antwort auf meine Frage:
Sparxx schrieb:
> Aber "wie oder wann" wird er bei einer Änderung von out_s aktiviert ?
Sorry wenn ich euch auf die Nerven gehe.
Mir geht es nicht nur zu verstehen und anwenden zu können,sondern auch 
erklären zu können.Grob gesagt habe ich nicht kapiert :)
Deshalb habe ich eine Zeitachse gezeichnet um mein Verständnisproblem zu 
verdeutlichen(Anhang).
Annahme:
1:fallende Taktflanken  t0,t2.. usw sind und die steigenden t1,t3...usw.
2: out_s mit dem Wert A initialisiert wurde und y hat auch A

bei diesem Beispiel:

    process(clk,out_s)
    begin
       if falling_edge(clk) then    -- mit dem Takt ändert sich was
          outs <= not outs;
        end if;
        Y <=outs;  -- und mit einer Änderung von outs ändert sich auch was!
     end process;

bei t0-> Nach der Process neu-Berechnung, wird out_s mit
          (not A)aktualisiert ,y<=A
bei t1-> outs_s hat immer A ,da keine fallende Flanke,y mit (not A)aktu.
bei t2-> out_s wird dem Wert (not A) zugewiesen,y<=(not A).

Wäre das so richtig erklärt?
Mir interessiert vor allem wo die Process-Berechnung beim Ereignis out_s 
auftritt?

[Duke Scarring (Gast)]

Sparxx schrieb:
> Deshalb habe ich eine Zeitachse gezeichnet um mein Verständnisproblem zu
> verdeutlichen(Anhang).
Geht das vielleicht auch als .png-Datei?

[Sparxx (Gast)]

Duke Scarring schrieb:
> Geht das vielleicht auch als .png-Datei?
Ups!!
Die richtige Datei...

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

Sparxx schrieb:
> Mir interessiert vor allem wo die Process-Berechnung beim Ereignis out_s
> auftritt?
Nun, sofort nach dem "ersten" Durchlauf des Prozesses wird festfestellt, 
dass sich out_s geändert hat. Und deshalb folgt, ohne dass die 
Simulationsuhr weiterläuft, eine Neuberechnung mit dem neuen Wert von 
out_s.

Deshalb passiert diese Invertierung von out_s (im ersten 
Prozessdurchlauf) und die "anschliessende" Datenübergabe (im zweiten 
Prozessdurchlauf) eigentlich zum selben Simulationszeitpunkt, nur eben 
im Simulator nacheinander...

[Wat (Gast)]

process(clk)
begin
  if falling_edge(clk) then    -- mit dem Takt ändert sich was
      outs <= not outs;
  end if;
  -- hier darf nichts mehr stehen 
 end process;

Merk dir doch einfach, dass in einem Prozess, in dem ein Takt auf seine 
Flanke hin abgefragt wird (sei es falling oder rising), nach dieser 
if-Anweisung NICHTS mehr stehen darf. Dann steht in der Sens-Liste 
dieses Prozesses nur der Takt (ggf. ein asynchroner Reset).

Alle weiteren Abbildungen an Out-Ports deiner Komponente oder an andere 
Signale nimmt du einfach separat vor (entweder wie vorgeschlagen in 
einem separaten Prozess, in einer block-Anweisungen oder einfach 
concurrent). Dann gibt es keine Verständnisprobleme mehr, und der 
VHDL-Stil ist auch besser!


VG, Wat

[Sparxx (Gast)]

Lothar Miller schrieb:
> Und deshalb folgt, ohne dass die
> Simulationsuhr weiterläuft

Aha,jetzt kapiere ich es,glaub ich.
Also solange Events auftreten,sagen wir es hätte noch 2 Events 
stattgefunden,
würde die Simulationsuhr stoppen,bis der Process alles neu berechnet 
hatte.und nicht für jeden Event an einer anderen Zeit stoppen.ist es so 
richtig?
War meine obige Überlegung annähernd richtig? !!

Danke an allen!

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

Sparxx schrieb:
> nicht für jeden Event an einer anderen Zeit stoppen.ist es so richtig?
Ja, jetzt passt es...

> War meine obige Überlegung annähernd richtig? !!
Ich blicke da nicht so ganz durch, und vermute, du meinst das hier zum 
Zeitpunkt t0 wegen einer fallenden Flanke am Takt:
>> bei t0-> Nach der Process neu-Berechnung

Ich würde es so beschreiben:
1. es kommt eine fallende Flanke am clk
2. dadurch wird für out_s ein neuer Wert berechnet
3. der Prozess läuft aber mit dem alten wert von out_s weiter
4. Y ändert sich nicht
5. am Ende des Prozesses wird out_s dieser neue Wert zugewiesen

6. out_s hat sich geändert, deshalb muss der Prozess neu berechnet 
werden
7. keine flanke am clk --> die if-Klammer wird nicht bearbeitet
8. es wird für Y ein neuer Wert berechnet
9. am Ende des Prozesses wird der neu berechnete Wert an Y zugewiesen

Das passiert alles zum selben Simulationszeitpunkt.

[Sparxx (Gast)]

Lothar Miller schrieb:
> Ich blicke da nicht so ganz durch
war echt ein richiger Wirrwarr :)Tut mir Leid.

Lothar Miller schrieb:
> du meinst das hier zum
> Zeitpunkt t0 wegen einer fallenden Flanke am Takt:

Ja,das meinte ich.

Gruß

[J. K. (rooot)]

Wie hätte man das Bsp. jetzt richtig (und sauber) gemacht? Mit einer 
Variable im process? Oder wie gezeigt mit einer erweiterten Sensitivity 
List?

Funktionieren tun natürlich mehrere Wege, aber was ist besser/warum? Im 
Netz findet man natürlich auch verschiedene Lösungwege.

mfg
Jürgen

[Christian R. (supachris)]

J. K. schrieb:
> Wie hätte man das Bsp. jetzt richtig (und sauber) gemacht? Mit einer
> Variable im process? Oder wie gezeigt mit einer erweiterten Sensitivity
> List?

Wurde ja schon gesagt. Die kombinatorische Zuweisung am besten außerhalb 
des Prozesses oder notfalls in einem eigenen Prozess. Du beschreibst mit 
dem getakteten Prozess ein oder mehrere FlipFlops. Da gehört diese 
Zuweisung nicht dran.

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

J. K. schrieb:
> Wie hätte man das Bsp. jetzt richtig (und sauber) gemacht?
Das hat schon die erste Antwort von Falk aufgezeigt.
> Mit einer Variable im process?
Nur zur Fokussierung: eine Variable hat mit diesem Thema rein überhaupt 
gar nichts zu tun...  Sie hilft auch nicht!
> Oder wie gezeigt mit einer erweiterten Sensitivity List?
Das war nur, um zu zeigen, wofür die Sensitivliste da ist, und wie man 
die Simulation wieder mit der Realität in Einklang bringen kann.