Forum: FPGA, VHDL & Co. Flankenerkennung in VHDL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von A. G. (grtu)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich benötige eigentlich dauernd eine Flankenerkennung in VHDL, aber 
jedes mal ein zweites, taktverschobenes Signal zu erzeugen finde ich 
total umständlich. Vor allem, da man keine prozessinternen Signale 
definieren kann, sammeln sich in größeren Entities irgendwann ziemlich 
viele Signale in einer langen Liste an, es wird unübersichtlich und 
ziemlich viel redundante Schreibarbeit. Leider kann man auch keine 
Funktionen benutzen, da man dort keine Signale generieren darf. Eine 
Entity für jede Flankenerkennung zu erstellen wäre ähnlich 
unübersichtlich wie ein zusätzliches Signal. Gibt es da was eleganteres?

Schöne Grüße,
grtu

von Christoph db1uq K. (christoph_kessler)


Bewertung
0 lesenswert
nicht lesenswert
Ich kenne die Flankenerkennung mit einem 2-Bit-Schieberegister (2 
D-Flipflops hintereinander), die erledigt gleichzeitig eine 
Synchronisierung mit einem zentralen Takt. Oder soll es asynchron sein, 
also quasi sofort reagieren?

von A. G. (grtu)


Bewertung
0 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Ich kenne die Flankenerkennung mit einem 2-Bit-Schieberegister (2
> D-Flipflops hintereinander), die erledigt gleichzeitig eine
> Synchronisierung mit einem zentralen Takt. Oder soll es asynchron sein,
> also quasi sofort reagieren?

Ich meine genau so ein 2-Bit-Schieberegister.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
A. G. schrieb:
> ich benötige eigentlich dauernd eine Flankenerkennung in VHDL, aber
> jedes mal ein zweites, taktverschobenes Signal zu erzeugen finde ich
> total umständlich. Vor allem, da man keine prozessinternen Signale
> definieren kann, sammeln sich in größeren Entities irgendwann ziemlich
> viele Signale in einer langen Liste an, es wird unübersichtlich und
> ziemlich viel redundante Schreibarbeit.

Verstehe ich das richtig, dass du viele Flankenerkennungen innerhalb 
einer Entity benötigst?

Dann würde ich das mit for ... generate erschlagen

Wenn du immer mal wieder eine Flankenerkennung benötigst und so eine Art 
library call suchst, da gibts die Komponenten instantzierung (die lässt 
sich dann auch mit for ... generate kombinieren).

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
A. G. schrieb:
> ich benötige eigentlich dauernd eine Flankenerkennung in VHDL, aber
> jedes mal ein zweites, taktverschobenes Signal zu erzeugen finde ich
> total umständlich. Vor allem, da man keine prozessinternen Signale
> definieren kann, sammeln sich in größeren Entities irgendwann ziemlich
> viele Signale in einer langen Liste an, es wird unübersichtlich und
> ziemlich viel redundante Schreibarbeit.
Zeig doch mal, was du da so umständlich machst oder als umständlich 
ansiehst. Wenn du es ganz geschickt machst, dann ist da gar keine 
Sensitivliste im Prozess:
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html
Damit gibts natürlich nur getaktete Prozesse.
Kombinatorik wird dann aber auch ohne Sensitivliste mit nebenläufigen 
Anweisungen erschlagen.

Und ein 2-Bit-Schieberegister geht etwa so:
schieberegister <= schieberegister(0) & eingang when rising_edge(clk);
Das erscheint mir jetzt nicht allzu lang...

Siehe auch:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung

: Bearbeitet durch Moderator
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
A. G. schrieb:
> Vor allem, da man keine prozessinternen Signale
> definieren kann, sammeln sich in größeren Entities irgendwann ziemlich
> viele Signale in einer langen Liste an, es wird unübersichtlich und
> ziemlich viel redundante Schreibarbeit.

Dafür gibt's in VHDL den Block. Damit kann man Signale, die nur lokal 
gebraucht werden, dort definieren, wo sie gebraucht werden.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Damit kann man Signale, die nur lokal gebraucht werden, dort definieren,
> wo sie gebraucht werden.
Ich denke, hier ging es tatsächlich nur um die Sensitivliste, in die 
dann einfach alle Signale reinkommen, die im Modul deklariert werden. 
Oder alle, die im Prozess auftauchen. Obwohl es ein komplett synchroner 
Prozess ohne Reset ist...  ;-)

: Bearbeitet durch Moderator
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Markus F. schrieb:
>> Damit kann man Signale, die nur lokal gebraucht werden, dort definieren,
>> wo sie gebraucht werden.
> Ich denke, hier ging es tatsächlich nur um die Sensitivliste, in die
> dann einfach alle Signale reinkommen, die im Modul deklariert werden.
> Oder alle, die im Prozess auftauchen. Obwohl es ein komplett synchroner
> Prozess ohne Reset ist...  ;-)

Die Sensitivliste heisst bei mir meist ...(all).

Das ist einigermassen überschaubar ;).

von A. G. (grtu)


Bewertung
0 lesenswert
nicht lesenswert
Mir ging es nicht um die Sensitivliste, sondern um die Deklaration am 
Beginn der Architecture.

Lothar M. schrieb:
> Und ein 2-Bit-Schieberegister geht etwa so:schieberegister <=
> schieberegister(0) & eingang when rising_edge(clk);
> Das erscheint mir jetzt nicht allzu lang...

Das ist mir schon klar. Auch wenn es nicht lang ist, es ist dennoch 
etwas, das man prinzipiell automatisieren bzw. abstrahieren könnte. Ich 
denke der einzige Weg wäre aber, wie schon geschrieben wurde, als 
Entity.

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
A. G. schrieb:
> Mir ging es nicht um die Sensitivliste, sondern um die Deklaration am
> Beginn der Architecture.
>
> Lothar M. schrieb:
>> Und ein 2-Bit-Schieberegister geht etwa so:schieberegister <=
>> schieberegister(0) & eingang when rising_edge(clk);
>> Das erscheint mir jetzt nicht allzu lang...
>
> Das ist mir schon klar. Auch wenn es nicht lang ist, es ist dennoch
> etwas, das man prinzipiell automatisieren bzw. abstrahieren könnte. Ich
> denke der einzige Weg wäre aber, wie schon geschrieben wurde, als
> Entity.

Nein. Kombiniere, was bereits gesagt wurde:

Nehmen wir mal an, Du hast eine architecture wie folgt:
architecture arch of xyz is
    -- Hunderte von Signalen
    signal async_signal : std_ulogic;
    signal sync_signal  : std_ulogic;
begin
    -- Hunderte von Instanzierungen und Logiken

    -- und irgendwo 199 Zeilen weiter unten brauchst Du plötzlich
    -- ein Sync-Register (das Du sonst nirgendwo brauchst, so dass
    -- eine separate Entity als Overkill erscheint.
    -- Dann nimm' einen Block:

    sync_block: block
        constant SYNC_LENGTH : integer := 2;
        -- Block-Lokale Signale
        signal sync_register : array (SYNC_LENGTH downto 0) of std_ulogic;
    begin
        sync_register <= sync_register(sync_register'length - 1) & async_signal when rising_edge(clk);
        sync_signal <= sync_register(sync_register'high);
    end block sync_block;
end architecture arch;

Das Schieberegister ist so hübsch versteckt (genau dort, wo es gebraucht 
wird) und nach aussen siehst Du nur, was Du aussen brauchst. Mit dem 
(einfachen) Beispiel ist der Nutzen natürlich begrenzt, so ein Block hat 
aber m.E. vielerlei Verwendungsmöglichkeiten, um ein Design sehr viel 
lesbarer zu machen. Sieht man viel zu wenig, finde ich.

von A. G. (grtu)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Nein. Kombiniere, was bereits gesagt wurde:

Stimmt, das sieht gut aus. =)

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
A. G. schrieb:
> Markus F. schrieb:
>> Nein. Kombiniere, was bereits gesagt wurde:
>
> Stimmt, das sieht gut aus. =)

Prima.

P.S.: ich sehe gerade, dass ich da noch zwei blöde Fehler eingebaut 
habe, aber die erkläre ich hiermit zum didaktischen Kniff und Du darfst 
sie selber finden ;)

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ich denke, hier ging es tatsächlich nur um die Sensitivliste, in die
> dann einfach alle Signale reinkommen, die im Modul deklariert werden.

Naja, je mehr temporäre Zwischensignale man erzeugen muss, desto mehr 
sprechende Namen muss man sich einfallen lassen. VHDL verleitet dann 
noch dazu, sehr deutlich sprechende Namen zu verwenden...

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> VHDL verleitet dann
> noch dazu, sehr deutlich sprechende Namen zu verwenden...

Was nicht von Nachteil ist :-)

Für die Flankenerkennung haben wir den Artikel.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
A. G. schrieb:
> ich benötige eigentlich dauernd eine Flankenerkennung in VHDL
Auf den zweiten Blick frage ich mich: warum denn eigentlich "dauernd"?
Eine Flankenerkennung samt Einsynchronisierung brauche ich ja nur beim 
Wechsel der Taktdomäne (z.B. um asynchrone externe Signale einzutakten). 
Innerhalb einer Taktdomäne arbeite ich mit Clock-Enables, die jeweils 
nur 1 Taktzyklus lang aktiv sind. Auf solche Signale muss ich dann keine 
Flankenerkennung mehr machen.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sollte man nicht mal ein FAQ machen, was die meisten Fragen angeht?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.