VHDL falling edge bewirkt rising edge

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

1

    process(clk)

2

    begin

3

      -- compare to truth table

4

      if falling_edge(clk) then

5

        outs <= not outs;

6

      end if;

7

    end process;

8

9

    Y <=outs;

MfG
Falk

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.

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

1

    process(clk)

2

    begin

3

      if falling_edge(clk) then

4

        -- nur hier steht irgendetwas

5

        outs <= not outs;

6

      end if;

7

      -- hier steht in Normalfall NIE etwas

8

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

1

    process(clk)

2

    begin

3

4

       if falling_edge(clk) then    -- mit dem Takt ändert sich was

5

          outs <= not outs;

6

        end if;

7

8

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

9

10

    end process;

Hier müsste die korrekte Sensitivliste also so aussehen:

1

    process(clk, outs)

2

    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:

1

    process(reset, clk)

2

    begin

3

      if falling_edge(clk) then

4

        -- hier steht irgendetwas

5

      end if;

6

      if reset='1' then

7

        -- hier steht auch was

8

      end if;

9

    end process;

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

1

    process(reset, clk)

2

    begin

3

      if reset='1' then

4

        -- hier steht auch was

5

      elsif falling_edge(clk) then

6

        -- hier steht irgendetwas

7

      end if;

8

    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)

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

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

1

   process (taster) begin

2

      if taster='1' then

3

          cnt <= cnt+1;

4

      end if;

5

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

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.

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

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.

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.