VHDL

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Die Abkürzung VHDL bedeutet VHSIC (Very High Speed Integrated Circuits) Hardware Description Language und wird zur Entwicklung analoger und digitaler Schaltungen eingesetzt. Sie ist besonders in Europa stark verbreitet, während im angloamerikanischen Raum überwiegend Verilog zur Anwendung kommt.

VHDL als Sprache

VHDL enthält, wie andere typische Programmiersprachen auch, eine Reihe von Konstrukten und Befehlen, die Abläufe und zeitliches Verhalten beschreiben, sowie ferner auch Elemente, die Strukturen und Zusammenhänge definieren. Diese werden genutzt, um das Verhalten und den Aufbau einer Schaltung, z.B. in einem FPGA oder ASIC, zu beschreiben. Dazu enthält sie sowohl Logikonstrukte (Bool'sche Algebra), mathematische Formeln, Bedingungs- und Schleifenkonstrukte. Darüber hinaus enthält sie Befehle, um sowohl Funktionen, als auch Teilschaltungen in Module zusammenzufassen und zu kapseln, um Hierarchien aufbauen zu könne.

Wichtig ist bei VHDL das Verständnis dafür, dass alle ausdrücklichen, zeitlichen Abläufe lediglich während der Simulation so vollzogen werden, wie sie anhand üblicher Regeln der Softwaretechnologie erwartet werden. Bei der Synthese hingegen bleiben einige zeitliche Konstrukte und Zusammenhänge unberücksichtigt und nur die Strukturen selbst werden in die Schaltung übernommen. Damit ist z.B. die Anordnung des Codes in einem Modul aber auch die Ordnung der Prozesse und Reihenfolge von Signalzuweisungen weitgehend unerheblich.

Wesentlich ist die funktionelle Abhängigkeit der Ausgänge von Schaltungsmodulen von ihren Eingängen, sowie der Zusammenhang der Eingänge der Module mit den Ausgängen anderer Module. Diese können jeweils direkt oder über FlipFlops verknüpft werden, wodurch die Informationsweitergabe erst im nächsten Takt erfolgt. Mit dieser grundsätzlichen Topologie sind alle wichtigen Grundfunktionen digitaler Schaltungen darstellbar. Letztlich wird das Verhalten der Chipausgänge in Abhängigkeit der Chipeingänge definiert und dabei alle erdenklichen Zustände, in denen sich die Teilschaltungen befinden können, vollumfänglich beschrieben.

Simulation

Bei der Simulation wird der Code in klassischer Weise kompiliert und ausgeführt. Die Anordnung von Codezeilen kann dabei ebenso relevant sein, wie die zeitliche Steuerung von Modulen, die bestimmte Abhängigkeiten von einzelnen Signalen haben. In dieser Funktion wird VHDL hauptsächlich zum Schreiben von Testbenches und Modellen verwendet. Näheres dazu im Artikel VHDL Testbench.

Synthese

Bei der Synthese wird die Beschreibung von einer Synthesesoftware in eine Netzliste umgesetzt. Der grundlegende Unterschied zur Verwendung von VHDL als Simulationsprache besteht darin, dass man nicht beliebigen Code schreiben kann, sondern sich an bestimmte Strukturen halten muss, die der Synthesizer kennt und in Hardware umsetzen kann. Schleifen z.B. werden zur Compilezeit ausgeführt, um Matritzen, Vektoren oder redundante Strukturen zu beschreiben und besitzen keine zeitliche Relevanz zur Ausführungszeit.

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

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)
  • Möglichst 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 herunter teilen, 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)

FAQ

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.

Synchroner oder asynchroner Reset?

Folgende Regeln gelten bei der Überlegung, ob man einen asynchronen Reset verwenden sollte:

  • In FPGAs führt die Nutzung von Resetfunktionen in aller Regel zu einem erhöhten Resourcenverbrauch. Mitunter werden Taktnetze belegt.
  • Asynchrone Resets bedürfen besonderer Behandlung, damit die negative RST-Taktflanke nicht genau zur Clk-Flanke kommt, da dies zu inkonsistenten Startbedingungen der FFs im FPGA führen kann.
  • Viele FPGAs können per Init-Kommando in VHDL initialisiert werden und benötigen zum Anlaufen gar keinen (Re)set - weder synchron noch asynchron.
  • Oft benötigen FPGAs aus Betriebssicherheitsgründen einen synchronen Reset inmitten des Betriebs durch eine Instanz wie einen Controller, wenn ein Fehler detektiert wurde. In diesen Fällen ist ein asynchroner Reset unnötig.
  • asynchrone Resets sollten nur an von einander unabhängigen Punkten der Schaltungselektronik angewendet werden, wie z.B. an verschiedenen Chips, wo man ohnehin keine totale Synchronität unterstellt und Massnahmen zum sicheren Anlaufen aller Schaltungsteile ergreifen muss.
  • asynchrone Resets müssen in jeder einzelnen domain getrennt eingetaktet werden, um sie sicher in synchrone Resets zu überführen
  • Innerhalb eines FPGAs sollten asynchrones Resets an z.B. PLLs geführt werden, damit deren Reset nicht von einer zweiten PLL abhängig ist.
  • Sollen FPGAs in ASICs übersetzt werden und dort unbedingt ein asynchroner Reset verwendet werden müssen, können asynchrone Resets bedingt compilierbar eingebaut werden, sodass sie im FPGA nicht zwangsläufig aktiv sein müssen

Standardresetpfad in FPGAs

Ein probates und meistens sehr gut funktionierendes Design sieht folgendermassen aus:

  • externer asynchroner Reset vom IO-PAD (bei nReset über Inverter) direkt im Top-Level an die Master-PLL / bzw den Haupt-DCM, genannt "PLL1"
  • Die "PLL1" generiert neben den Takten ein LOCKED-Signal, das in invertierter Form als Reset für diese domain benutzt wird. Aus dem aynchronen Reset wird dadurch mittels des LOCK-Signals ein interner, synchroner Reset
  • Dieser interne Reset wird in jeder einzelnen Teildomain dieser PLL zweimal einsynchronisiert, um lokale Reset-Signale zu erzeugen. Damit werden die Auswirkungen metastabiler Zustände verhindert, die bei der negativen Resetflanke entstehen könnten, falls die Taktflanken der erzeugten PLL-Takte genau auf dieser Flanke liegen
  • Der interne Reset der "PLL1" versorgt zudem auch alle weiteren PLLs der anderen Domains, die sich ihren lokalen Reset auf dieselbe Weise generieren. Der in der domain der PLL1 synchrone reset wirkt bei diesen PLLs quasi asynchron.

Damit wird sichergestellt dass alle PLLs einen eigenen Reset bekommen und sie danach definitiv anlaufen. Es ist nun wichtig, dass beachtet wird, dass der exakte Zeitpunkt der Resets der unterschiedlichen Domains unbekannt ist. Daher müssen die locked-signale dieser Domains gfs wieder einsynchronsiert werden, damit in der Master-Domain bekannt ist, wenn alle Teilschaltungen angelaufen sind und das Design "starten" kann.

Bei kritischen Applikationen muss gegebenenfalls auch noch dafür gesorgt werden, dass in der Phase zwischen Start des FPGAs und Arbeiten aller PLLs alle FPGA-Ausgänge auf einem passenden Pegel gehalten werden.

Wann und warum verwendet man Variablen?

  • Variablen sind als Zwischenergebnisse / Synonyme für aus Kombinatorik gewonnene Werte / Signale zu verstehen. Sie erhalten, wie auch aus der Softwareentwicklung bekannt, jeweils "direkt" nach der Zuweisung ihren neuen Wert, der damit sofort an jeder anderen Stelle gültig ist und genutzt werden kann - so, als läge eine direkte Verdrahtung vor. Die Nutzung von Variablen entkoppelt somit jegliche Berechnung von etwaigen zeitlichen Randbedingungen, speziell dem Takt. Damit ist es möglich, komplexe Architekturen sowie innerhalb von Simulationen das Modellverhalten abschnittsweise zu formulieren, ohne einen Zeitverzug zwischen den einzelnen Blöcken zu erhalten. Siehe die 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 gfs nochmals gestartet ... (oder so oft, so viele voneinander abhängige Signalzuweisungen enthalten sind), bei Variablen wird er in einem Durchlauf berechnet. Dies hat einerseits Auswirkungen auf die Simulationszeit und andererseits das Ergebnis. Sofern richtigerweise Variablen benutzt wurden, ist dies ein Vorteil, weil die Simulationszeit sinkt. Falls richtigerweise Signale verwendet wurden, um ein benötigte Zeitverhalten abzubilden, ist der Umweg über Zwischensignale eher kontraproduktiv.
  • Die Benutzung von Variablen gegenüber Signalen hat in jedem Fall dann Vorteile im Bereich der Ausführungszeit bei Simulationen, wenn umfangreiche Berechnungen nötig sind, die ansonsten mit Vektoren durchgeführt werden müssten.


Beispiele:

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.
  Var1 := A + B;
  Var2 := C + D;
  Var3 := E + F;
  Result1 <= Var1 - Var2;
  Result2 <= Var1 - Var3;

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

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.

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.

Anfängerprobleme

Anfänger meinen oft, die unmittelbare Zuweisung eines Werts an eine Variable im Prozess gewinnbringend nutzen zu können. So werden dann ausgiebig Variablen verwendet, und eines der Hauptprobleme von Variablen übersehen: sie können nicht in der Sensitivliste eines Prozesses aufgeführt werden. Von diesem Nebeneffekt sind insbesondere speichernde Variablen betroffen. Im Beitrag http://www.mikrocontroller.net/topic/117630 sind dort ein paar Beispiele aufgeführt.
Das Hauptproblem an diesem Verhalten ist, dass die (fehlerfreie) Simulation nicht mehr zum Syntheseergebnis (das ebenfalls fehlerfrei und ohne Warnungen erzeugt wurde) passt.

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.

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'; -- (Die Vergleichs-Konstante wird hier in Hex geschrieben.)

Dies nennt der Fachmann bedingte Zuweisung (conditional assignment), es ist eine der nebenläufigen Anweisungen von VHDL. Daneben gibt es zu ähnlichem Zweck eine select-Anweisung: 

 with vector select
   bit_pos <= "00" when "0001",
              "01" when "0010",
              "10" when "0100",
              "11" when "1000",
              "00" when others;

Für sperrige Fälle, die sich partout nicht lesbar und/oder elegant mittels dieser nebenläufigen Zuweisungen formulieren lassen, bietet sich entweder ein kombinatorischer Prozess an oder man verpackt die Zuweisung in eine Funktion. In beiden Fällen kann man dann den Ergebnisvektor schrittweise mit if-Abfragen zusammenbauen.

Alle Leitungen auf "0000.." bzw "1111..." setzen?

Auf null setzen: 

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

Auf eins setzen: 

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

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

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

parallel -> seriell: Schieberegister oder Multiplexer?

Weitere Informationen

Artikel

<ncl style=compact maxdepth=2 headings=bullet headstart=2 

     showcats=1 showarts=1>VHDL</ncl>

Forum

Kurzreferenzen

Bücher

  • J. Ritter, P. Molitor: "VHDL: Eine Einführung", ISBN 3827370477
  • J. Reichardt, B. Schwarz: "VHDL-Synthese: Entwurf digitaler Schaltungen und Systeme", ISBN 3486581929
  • P. J. Ashenden: "The Designers Guide to VHDL", ISBN 1558606742

Online-Bücher

Deutsch

English

Diskussionen

VHDL-Beispiele

Abgerufen von „https://www.mikrocontroller.net/index.php?title=VHDL&oldid=104149“