www.mikrocontroller.net

VHDL

Inhaltsverzeichnis

[Bearbeiten] VHDL als Programmiersprache

VHDL ist im Grunde eine ganz normale Programmiersprache, die kompiliert und ausgeführt werden kann. In dieser Funktion wird VHDL haupsächlich zum Schreiben von Simulationen (Testbenches) verwendet. Näheres dazu im Artikel VHDL Testbench.

[Bearbeiten] VHDL als Hardwarebeschreibungssprache

In VHDL lassen sich auch digitale Schaltungen beschreiben. Die Beschreibung wird von einer Synthesesoftware in eine Netzliste umgesetzt. Der grundlegende Unterschied zur Verwendung von VHDL als Programmiersprache ist, dass man nicht beliebigen Code schreiben kann, sondern sich an bestimmte Strukturen halten muss die der Synthesizer kennt und in Hardware umsetzen kann.

Wie diese Strukturen im allgemeinen aussehen ist weiter unten beschrieben, Details erfährt man in der Dokumentation der Software, z. B. dem XST User Guide.

[Bearbeiten] Grundregeln für synthetisierbaren VHDL-Code

Folgende Grundregeln sollten vor allem Anfänger auf jeden Fall einhalten:

  • Es darf nur zwei Arten von Prozessen geben:
    1. Rein kombinatorische Prozesse (keine Zustandsspeicher):
      • Alle Signale die im Prozess gelesen werden in die sensitivity list eintragen
      • Jedes Ausgangssignal muss in jedem if-Zweig einen von sich selbst verschiedenen Wert zugewiesen bekommen, damit keine Latches entstehen (mein_signal <= mein_signal; ist unzulässig!)
      • Keine Taktflankenabfrage
    2. Rein getaktete Prozesse (Flip-Flops als Zustandsspeicher):
      • Nur Clk und asynchroner Reset in die sensitivity list
      • Maximal ein Reset
      • Nur eine Taktflankenabfrage (rising_edge)
  • Nur ein einziger Takt im gesamten Design, nur steigende ODER fallende Taktflanke auswerten. Um eine Flanke eines anderen Signals zu erkennen, siehe VHDL Flankenerkennung.
  • Keine Takte runterteilen, stattdessen Clock Enable verwenden.
  • Kein "after", "wait for" o.ä. verwenden, das ist nicht synthetisierbar
  • Keine shared variables verwenden
  • Variablen nur dann verwenden, wenn man genau verstanden hat was der Unterschied zu einem Signal ist, und sich das Problem nicht auch mit Signalen lösen lässt
  • Kein IEEE.STD_LOGIC_(UN)SIGNED verwenden, sondern IEEE.NUMERIC_STD (siehe Rechnen in VHDL)

[Bearbeiten] Beispiel: Kombinatorischer Prozess 

process(a,b,c)
begin
  y <= a + b + c;
end process;

[Bearbeiten] Beispiel: Getakteter Prozess ohne Reset 

process(clk)
begin
  if rising_edge(clk) then
    x <= a + b + c;
  end if;
end process;

[Bearbeiten] FAQ

[Bearbeiten] CLK='1' and CLK'event oder rising_edge()?

Frage: Bei der Beschreibung von FlipFlops werden je nach Buch/Programmierer zwei unterschiedliche Konstrukte benutzt:

Variante 1 (klassisch): 

process(clk)
begin
  if clk = '1' and clk'event then
    --snip
  end if;
end process;

und Variante 2: 

process(clk)
begin
  if rising_edge(clk) then
    --snip
  end if;
end process;

Welche ist zu empfehlen?

Antwort: Kurz gesagt bei der Synthese gibt es keine Unterschiede, in der Simulation kleine. Verwende die besser lesbare Variante. Die mit rising_edge() (bzw. falling_edge()) gilt allgemein als die bessere (Lesbarkeit und Simulationsgenauigkeit).

Wer es genau wissen will: Die klassische Variante ist nur korrekt für Signale die nur die Werte '1' und '0' annehmen können. Bei Signalen vom Typ std_logic (der Standardtyp für Signale) werden Flanken erkannt, die tatsächlich keine sind. Zum Beispiel beim Treiben eines PullUps ('H' -> '1' keine tatsächliche Flanke aber für clk = '1' and clk'event) oder beim Simulationsstart ohne Initialisierungswert für die Signale ('U' -> '1').(Signale mit Initialisierungswert werden so deklariert: signal a: std_logic := '0'; ). Die Funktionen rising_edge() und falling_edge() konvertieren den std_logic Wert vor dem Vergleich auf '1' bzw. '0' und simulieren so keine Flanke wo in der echten Hardware auch keine ist.

[Bearbeiten] Wann und warum verwendet man Variablen?

  • Variablen sind als Zwischenergebnisse / Synonyme für aus Kombinatorik gewonnene Werte / Signale zu verstehen. Sie erhalten jeweils "sofort" nach der Zuweisung ihren neuen Wert, der direkt an anderer Stelle genutzt werden kann - so, als läge eine direkte Verdrahtung vor. Die Nutzung von Variablen entkoppelt somit jegliche Berechung von den zeitlichen Randbedingungen, speziell dem Takt. Damit ist es möglich, komplexe Architekturen und Modellverhalten innerhalb von Simulationen ohne einen Zeitverlust zu berechnen, siehe Beispiele unten.
  • Signale erhalten ihren neu zugewiesenen Wert dagegen erst nach dem vollständigen Abarbeiten eines Prozesses, praktisch nach einem Delta-Delay oder nach einer spezifizierten Zeit. Sie repräsentieren eine physikalische Signalkette mit tatsächlichem Datenfluss. Während Variablen daher in einem Prozess gleich weiterverwendet werden können, sind Signale faktisch erst mit dem nächsten Takt aktuell (das Delta-Delay führt dazu, dass der Wert für diesen Durchlauf noch nicht gilt, der nächste Durchlauf des getakteten Prozesses passiert dann erst einen Clockcycle später.
  • Bei asynchronen Prozessen wird der Prozess bei der Verwendung von Signalen dann nochmals gestartet ... (oder so oft, so viele voneinander abhängige Signalzuweisungen drin sind), bei Variablen wird er in einem Durchlauf berechnet (Simulationszeit!).

Beispiele:

[Bearbeiten] Beispiel 1 

-- Nutzung von Signalen
-- die letzte Anweisung ist gültig und überschreibt alle vorhergehenden Anweisungen
 
-- steht real in der Signaldefinition über begin
signal a: std_logic;
 
process(clk)
begin
  if rising_edge(clk) then
    a <= a and b;
    a <= a and c;
  end if;
end process;
 
-- Ergebnis: a <= a and c, die Zeile zuvor wird ignoriert 


-- Nutzung von Variablen
-- Aufeinanderfolgende Anweisungen werden sofort logisch wirksam und in die neue Anweisung einbezogen, die Anweisungen werden somit verkettet
 
process(clk)
  variable a: std_logic;
begin
  if rising_edge(clk) then
    a := a and b;
    a := a and c;
  end if;
end process;
 
-- Ergebnis: a <= a and b and c, Verkettung der Anweisung wie in normalen Programmiersprachen
  • Es kann recht unübersichtlich werden, wenn man eine komplexe Berechnung hat und diese mit vielen Klammerebenen verschachtelt direkt in der Signalzuweisung beschreibt. Hier kann es besser sein, den Wert "nach und nach" über Variablen "zusammenzubauen" und erst am Schluss auf ein Signal zuzuweisen.
  • Manchmal möchte man gemeinsame Teilausdrücke vorab berechnen, z. B. 
  Sig1 := A + B;
  Sig2 := C + D;
  Sig3 := E + F;
  Result1 <= Sig1 - Sig2;
  Result2 <= Sig1 - Sig3;

ist i.d.R. besser als 

  Result1 <= (A + B) - (C + D);
  Result2 <= (A + B) - (E + F);

Wenns komplexer wird, ist es auch einfacher, daran was zu ändern.

  • Verschiedenen Synthesetools können manchmal mehr, manchmal weniger gut optimieren. So kann man z. B. durch das Zusammenfassen eines Teilausdruckes eine bessere Optimierung erreichen (Stichwort Resource-Sharing). Z.B.: 
  if (opcode = add) then
    res <= a+b;
  else -- opcode = sub
    res <= a-b;
  end if;

oder 

  if (opcode = add) then
    var1 := b;
  else
    var1 := -b;
  end if;
  res <= a+var1;

Im ersten Fall wird ggf. ein Addierer und ein Subtrahierer (noch'n Addierer) eingebaut und das Ergebniss gemultiplext, im zweiten Fall wird eventuell nur ein Addierer eingebaut und der b-Eingang des Addierers gemultiplext. Sind a und b beispielsweise 32-Bit-Vektoren, dann macht das HW-mäßig schon was aus. Gute Synthesetools sollten dies aber mittlerweile automatisch machen, so das in beiden Fällen dasselbe rauskommt (war nicht immer so). (BTW, ich selber tendiere normalerweise zur ersten Variante, da besser lesbar - und man die HW-Implementierung nicht notwendigerweise vorwegnehmen soll, aber da hat jeder seine eigene Meinung zu ...)


[Bearbeiten] Beispiel 2

Bei Analogen Filtern ist es oft notwendig, iterative Schleifen zu verwenden, um die Ergebnisse zu erlangen. Nur die Verwendung von Variablen und Loops gestattet es, komplexe Rechenergebnisse von "analoger" Reaktionsgeschwindigkeit vom Simulator zu erlangen, ohne Simulationszeit oder gar Takte vergehen zu lassen.

[Bearbeiten] Geschwindigkeit

Simulatoren rechnen i.d.R. mit Variablen schneller als mit Signalen. Hat man also viele Prozesse mit Signalen vs. Variablen in einem großen Design, dann kann das schon was ausmachen ... Siehe auch oben bei asynchronen Prozessen, die mit Signalen ggf. wesentlich öfters durchlaufen werden. Auch wenn also ein System mit Signalen abzubilden ist, so empfiehlt sich der Einsatz von Variablen mitunter dennoch.

Ausnahme: I.d.R. sind nur auf Signalen und getakteten Prozessen basierende Modelle voll und leicht synthesierbar. Soll z. B. ein Modell in einem HIL System getestet werden, ist die Verwendung von Signalen mit entsprechender Berücksichtigung des timing angezeigt.

[Bearbeiten] Kodierschaltungen

Kodierschaltungen (Coder) sind Schaltungen mit einem mehrstelligen Ein- und Ausgang. In der Schaltung werden keine FF oder andere Speicher benutzt. Ein typisches Beispiel ist die Wandlung einer Binärzahl in eine Binär Codierte Dezimalzahl. Eine sehr übersichtliche Schreibweise benutzt ein Konstanten-Feld.

Vor- und Nachteile verschiedener VHDL-Varianten einen Coder zu beschreiben werden hier besprochen.

[Bearbeiten] If außerhalb eines Prozesses?

If-Bedinungen sind außerhalb eines Prozesses nicht möglich. Lösung: 

 vector_or <= '0' when oder_vector = X"0000" else '1';

Dies nennt der Fachman bedingte Zuweisung (conditional assignment).

[Bearbeiten] Alle Leitungen auf "0000.." bzw "1111..." setzen?

Auf null setzen: 

count <= (others => '0');

Auf eins setzen: 

count <= (others => '1');

[Bearbeiten] Vergleich eines std_logic_vector mit einer Konstanten

Um einen std_logic_vector auf "00000..." oder "1111..." zu vergleichen, kann die (others => '0') Schreibweise nicht verwendet werden, weil die Vektorbreite dabei nicht definiert ist. Hier muss also ein Bereich angegeben werden: 

if VECTOR = (15 downto 0=>'0') then..

oder 

if VECTOR = (VECTOR'range=>'0') then...

Diese Schreibweise gilt universell für alle Libs.

Werte ungleich "000.." und "1111..." müssen bei Verwendung der NUMERIC_STD.ALL etwas aufwendiger umgewandelt werden (hier der Wert 77): 

if VECTOR = std_logic_vector(to_unsigned(77,VECTOR'length)) then...

Wird die herstellerabhängige Synopsis-Lib STD_LOGIC_UNSIGNED.ALL verwendet, kann auch einfach so geschrieben werden: 

if VECTOR = 0 then...

Genauso einfach geht ein Vergleich auf z. B. den Wert 77: 

if VECTOR = 77 then...

[Bearbeiten] Report von std_logic_vector

Report kann nur Strings verarbeiten, deswegen muss ein std_logic_vector in einen String verwandelt werden: 

report integer'image(to_integer(unsigned(rdata)));

[Bearbeiten] parallel -> seriell: Schieberegister oder Multiplexer?

[Bearbeiten] Links

[Bearbeiten] Kurzreferenzen

[Bearbeiten] Online-Bücher

http://de.wikibooks.org/wiki/VHDL

[Bearbeiten] Deutsch

[Bearbeiten] English

Von „http://www.mikrocontroller.net/articles/VHDL“
webmaster@mikrocontroller.net – Impressum – Nutzungsbedingungen – Werbung auf Mikrocontroller.net