VHDL Very High Speed Integrated Circuit Hardware Description

  • Slides: 128
Download presentation
VHDL Very High Speed Integrated Circuit Hardware Description Language 1 © A. Steininger /

VHDL Very High Speed Integrated Circuit Hardware Description Language 1 © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 2 © A. Steininger / TU Wien

Wiederholung Design-Entry: Möglichkeiten grafisch textuell high-level State-Chart (Zustandsgraph) VHDL, Verilog, System C low-level Schematic

Wiederholung Design-Entry: Möglichkeiten grafisch textuell high-level State-Chart (Zustandsgraph) VHDL, Verilog, System C low-level Schematic Entry ABEL, CUPL (Schaltplan) PALASM Kriterien: n n n 3 A Unterstützung der menschlichen Intuition Effizienz der Darstellung Weiterverarbeitbarkeit durch Computer © A. Steininger / TU Wien

Historisches 1980 implementierungsunabh. Dokumentationssprache für elektronische Systeme (Do. D) 1987 Standardisierung als IEEE 1076:

Historisches 1980 implementierungsunabh. Dokumentationssprache für elektronische Systeme (Do. D) 1987 Standardisierung als IEEE 1076: „VHDL-87“ dann MIL-STD-454 Dokumentation, Simulation und Verifikation für ASICs 1993 Überarbeitung von IEEE 1076: „VHDL-93“ VHDL-93 ist der aktuelle gültige Standard Unterschiede zwischen VHDL-87 und VHDL-93 sind bei „konservativer“ Programmierung vernachlässigbar 4 © A. Steininger / TU Wien

Implementierbarkeit Standard beschreibt Syntax, nicht Implementierung Viele VHDL-Konstrukte nicht in HW umsetzbar In HW

Implementierbarkeit Standard beschreibt Syntax, nicht Implementierung Viele VHDL-Konstrukte nicht in HW umsetzbar In HW implementierbar Synthesetools erwarten bestimmten Codierstil VHDL-Syntax n 5 Beim Programmieren schon „in HW denken“ © A. Steininger / TU Wien

Anwendungen der Sprache Spezifikation & Dokumentation (Mensch/Mensch) Simulation & Synthese (Maschine/Maschine) Design Entry für

Anwendungen der Sprache Spezifikation & Dokumentation (Mensch/Mensch) Simulation & Synthese (Maschine/Maschine) Design Entry für komplexe digitale HW (Mensch/Maschine) Features: § Modularität & Hierarchie § unterschiedl. Abstraktionsebenen § unterschiedliche Datentypen § vielfältige Operationen § parallele und sequentielle Abläufe 6 © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 7 © A. Steininger / TU Wien

Grundelemente eines Design Aufbau einer Design Unit n n n Entity Architecture Configuration Package

Grundelemente eines Design Aufbau einer Design Unit n n n Entity Architecture Configuration Package n n Package Body Library 8 A © A. Steininger / TU Wien

Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5

Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 DATA 6 DATA 7 OE Struktur einer Design-Unit Schnittstelle zur Umwelt (Anschlüsse) Architecture Configuration Zuordnung Architecture - Entity 9 ADDR 0 ADDR 1 ADDR 2 ADDR 3 ADDR 4 ADDR 5 ADDR 6 ADDR 7 ADDR 8 ADDR 9 Funktion, Innenleben © A. Steininger / TU Wien

Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5

Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 DATA 6 DATA 7 OE Struktur einer Design-Unit Schnittstelle zur Umwelt (Anschlüsse) Architecture Configuration Zuordnung Architecture - Entity 10 ADDR 1 ADDR 2 ADDR 3 ADDR 4 ADDR 5 ADDR 6 ADDR 7 ADDR 8 ADDR 9 Funktion, Innenleben © A. Steininger / TU Wien

Entity beschreibt das Interface (= Anschlüsse) der Design-Unit enthält keine Beschreibung der Funktion entspricht

Entity beschreibt das Interface (= Anschlüsse) der Design-Unit enthält keine Beschreibung der Funktion entspricht Schaltsymbol eines Bauteils wichtigstes Element sind die Ports zusätzlich Deklaration von Parametern möglich („Generics“) 11 © A. Steininger / TU Wien

Ports … sind beschrieben durch n n n 12 Namen Richtung Datentyp Richtung RD

Ports … sind beschrieben durch n n n 12 Namen Richtung Datentyp Richtung RD WR IN ja nein OUT nein ja INOUT ja ja BUFFER ja ja Bemerkung nur von einer Quelle beschreibbar © A. Steininger / TU Wien

Entity – ein Beispiel Name der Entity entity MUX 1 is port (A, B,

Entity – ein Beispiel Name der Entity entity MUX 1 is port (A, B, SEL: in std_logic; Y: out std_logic); end MUX 1; SEL Port-Name Richtung A Datentyp MUX 1 B 13 A Y © A. Steininger / TU Wien

Entity – noch ein Beispiel entity MY_HALFADD is port (A, B: in std_logic; SUM,

Entity – noch ein Beispiel entity MY_HALFADD is port (A, B: in std_logic; SUM, CARRY: out std_logic); end MY_HALFADD; A B 14 A MY_ HALF ADD SUM CARRY © A. Steininger / TU Wien

 Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA

Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 DATA 6 DATA 7 OE Struktur einer Design-Unit Schnittstelle zur Umwelt (Anschlüsse) Architecture Configuration Zuordnung Architecture - Entity 15 ADDR 0 ADDR 1 ADDR 2 ADDR 3 ADDR 4 ADDR 5 ADDR 6 ADDR 7 ADDR 8 ADDR 9 Funktion, Innenleben © A. Steininger / TU Wien

Architecture beschreibt die Funktion einer Design-Unit; dies kann auf unterschiedl. Abstraktionsebenen erfolgen (auch gemischt),

Architecture beschreibt die Funktion einer Design-Unit; dies kann auf unterschiedl. Abstraktionsebenen erfolgen (auch gemischt), und zwar entweder hierarchisch durch Instanzierung bestehender Design-Units. und/oder durch eine Verhaltensbeschreibung in Form paralleler und/oder sequenzieller Abläufe. 16 © A. Steininger / TU Wien

VHDL-Entry im Y-Diagramm Verhalten Register. Transfers Beschreibung der internen Funktion von Blöcken („design units“)

VHDL-Entry im Y-Diagramm Verhalten Register. Transfers Beschreibung der internen Funktion von Blöcken („design units“) sys 17 A Struktur ALU, Register & Signale Beschreibung der Verbindungen zwischen Blöcken cir gate RTL alg Makrozellen & globales Routing Geometrie © A. Steininger / TU Wien

Beschreibung in VHDL Algorithmisch h nc e T Registertransfer y (RTL) ntr s De

Beschreibung in VHDL Algorithmisch h nc e T Registertransfer y (RTL) ntr s De E n g i Logik try n n E älle) g i s f De ezial Speicher µP case A when `1` then next. B <= C; nextstate <= idle; D = NOT E + 16 RAM 8 B PLCC 84 Q 1 GND IO IO-Ctrl RS 232 Interface PS/2 Interface Register & >1 A PS/2 µP IO-Ctrl Counter E C = (D OR B) AND A CPU Control while input Read „Schilling“ Calulate Euro Display „Euro“ rt d. I e d. U p i r (S e dt = R dt Schaltkreis en g ols o T von 18 A Speicher Geometrie C R E G A L U INV 1 OR 2 RS 232 Counter b t s e Inputs : Keyboard Output: Display Funktion: . . . Struktur A 5 A 6 A 7 RW D 1 D 0 VDD System Verhalten ALU Ebene AND 2 x 3 I d 2 I + L 2 C dt © A. Steininger / TU Wien

Architecture – RTL/Verhalten Name der Architecture architecture MUX_RTL of MUX 1 is begin --

Architecture – RTL/Verhalten Name der Architecture architecture MUX_RTL of MUX 1 is begin -- MUX_RTL slct: process(A, B, SEL) Name der Entity begin if SEL ='0' then Y <= A; else Y <= B; end if; end process slct; end MUX_RTL; 19 A © A. Steininger / TU Wien

Architecture – Logik/Verh. architecture MUX_equn of MUX 1 is begin -- MUX_behav Y <=

Architecture – Logik/Verh. architecture MUX_equn of MUX 1 is begin -- MUX_behav Y <= (SEL or A) and (not(SEL) or B); end MUX_equn; Y = (SEL A) ( SEL B) 20 © A. Steininger / TU Wien

Architecture – Logik/Strukt. architecture MUX_struc of MUX 1 is -- need component declarations here

Architecture – Logik/Strukt. architecture MUX_struc of MUX 1 is -- need component declarations here signal i, j, k: std_logic; begin -- MUX_struc u 1: OR 2 port map(A, SEL, i); u 2: INV port map(SEL, j); u 3: OR 2 port map(j, B, k); u 4: AND 2 port map(i, k, Y); end MUX_struc; A i OR 2 B SEL 21 INV OR j 2 AND 2 Y k © A. Steininger / TU Wien

Architecture – Varianten Entity ist fix zugeh. Architecture kann variieren: n Abstraktionsebenen n n

Architecture – Varianten Entity ist fix zugeh. Architecture kann variieren: n Abstraktionsebenen n n 22 Simulationsaufwand „Reife“ des Designs Testbench IP-Cores Arch MUX_RTL Entity MUX 1 Arch MUX_equn Arch MUX_struc Implementierungsvarianten © A. Steininger / TU Wien

 Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA

Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 DATA 6 DATA 7 OE Struktur einer Design-Unit Schnittstelle zur Umwelt (Anschlüsse) Architecture Configuration Zuordnung Architecture - Entity 23 ADDR 0 ADDR 1 ADDR 2 ADDR 3 ADDR 4 ADDR 5 ADDR 6 ADDR 7 ADDR 8 ADDR 9 Funktion, Innenleben © A. Steininger / TU Wien

Configuration Zuordnung einer bestimmten Architecture (MUX_RTL) zu Entity MUX 1 : Name der Configuration

Configuration Zuordnung einer bestimmten Architecture (MUX_RTL) zu Entity MUX 1 : Name der Configuration CFG_A of MUX 1 is for MUX_RTL end for; Name der Entity end CFG_A; Name der aktuell zugewiesenen Architecture 24 A © A. Steininger / TU Wien

Configuration L T R r Entity MUX 1 fo fo r _ X U

Configuration L T R r Entity MUX 1 fo fo r _ X U M Arch MUX_RTL Arch MUX_equn MU X_ s tr uc Arch MUX_struc unterschiedliche Realisierungen einer Funktion können parallel existieren und einfach ausgetauscht werden 25 A © A. Steininger / TU Wien

architecture MUX_RTL of MUX 1 is begin -- MUX_RTL Configuration CFG_AB, of. SEL) MUX

architecture MUX_RTL of MUX 1 is begin -- MUX_RTL Configuration CFG_AB, of. SEL) MUX 1 is slct: process(A, for MUX_RTL begin if SEL end ='0'for; then end CFG_A; Y <= A; is entity MUX 1 else port (A, B, SEL: in std_logic; Y <= B; Y: out std_logic); end if; end MUX 1; end process slct; end MUX_RTL; Entity CS DATA 0 DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 DATA 6 DATA 7 OE Struktur einer Design Unit Configuration ADDR 0 ADDR 1 ADDR 2 ADDR 3 ADDR 4 ADDR 5 ADDR 6 ADDR 7 ADDR 8 ADDR 9 Architecture Diese drei Teile können getrennt oder in einer gemeinsamen Datei abgelegt werden 26 A © A. Steininger / TU Wien

Grundelemente eines Design Aufbau einer Design Unit n n n Entity Architecture Configuration Package

Grundelemente eines Design Aufbau einer Design Unit n n n Entity Architecture Configuration Package n n Package Body Library 27 © A. Steininger / TU Wien

Package Zentrale Stelle wo globale Deklarationen & Definitionen zu finden sind (vgl. include-File) n

Package Zentrale Stelle wo globale Deklarationen & Definitionen zu finden sind (vgl. include-File) n n Konstante User defined Types Component Declarations Sub-Programs Kann von Design-Units aus unterschiedlichen Projekten referenziert werden Ermöglicht konsistente Vorgehensweise in Design-Teams 28 © A. Steininger / TU Wien

Package: Anwendung Comp A Projekt abc Const P Package Datentyp W 29 Projekt xyz

Package: Anwendung Comp A Projekt abc Const P Package Datentyp W 29 Projekt xyz © A. Steininger / TU Wien

Package – ein Beispiel package my_constants is -- define levels to be active high

Package – ein Beispiel package my_constants is -- define levels to be active high constant ACTIVE: std_logic : = '1'; -- define width of counter constant WIDTH : integer : = 8; -- define maximum count constant MAXCNT: std_logic_vector(WIDTH-1 downto 0) : = (others => '1'); end my_constants; 30 © A. Steininger / TU Wien

Package vs. Package Body Package: Schnittstelle für Funktionen, Typen, Komponenten, . . . (vgl.

Package vs. Package Body Package: Schnittstelle für Funktionen, Typen, Komponenten, . . . (vgl. include. h -Datei in C) Package Body: Funktionskörper, Wertzuweisungen für Konstanten, . . . (vgl. include. c -Datei in C) Package Body 31 Projekt xyz Projekt abc © A. Steininger / TU Wien

Grundelemente eines Design Aufbau einer Design Unit n n n Entity Architecture Configuration Package

Grundelemente eines Design Aufbau einer Design Unit n n n Entity Architecture Configuration Package n n Package Body Library 32 © A. Steininger / TU Wien

Einbinden von Libraries Mit der library Anweisung wird eine Bibliothek sichtbar gemacht: library <libname>

Einbinden von Libraries Mit der library Anweisung wird eine Bibliothek sichtbar gemacht: library <libname> Standardmäßig legt der Compiler alle compilierten Design-Units in der Library work ab. Die library Anweisung entspricht somit einer Pfadangabe. Die Library work ist per default sichtbar und muss nicht explizit angegeben werden. 33 © A. Steininger / TU Wien

Zugriff auf Library-Elemente Mit der use Anweisung werden Elemente aus (sichtbaren!) Libraries bekannt gemacht:

Zugriff auf Library-Elemente Mit der use Anweisung werden Elemente aus (sichtbaren!) Libraries bekannt gemacht: use work. my_pack. HA library name package name element name Die Angabe von. all als element name macht alle Elemente der Library bzw. des Packages bekannt. 34 © A. Steininger / TU Wien

Standard Library (STD) Festgelegt durch IEEE-1076 Enthält die Packages standard und textio Package standard

Standard Library (STD) Festgelegt durch IEEE-1076 Enthält die Packages standard und textio Package standard (automatisch sichtbar) n n Grundlegende Datentypen Operatoren Package textio (nicht autom. sichtbar) 35 n Dateitypen n Ein-/ Ausgabeoperatoren © A. Steininger / TU Wien

Package IEEE. std_logic_1164 Typen n std_logic, std_ulogic, . . Operatoren n and, or, not,

Package IEEE. std_logic_1164 Typen n std_logic, std_ulogic, . . Operatoren n and, or, not, . . Konvertierungsfunktionen: n z. B. : To_bit, To_stdlogic, . . . Funktionen n 36 rising_edge, falling_edge, . . . © A. Steininger / TU Wien

Package IEEE. std_logic_arith Typen n signed, unsigned Operatoren n n +, -, *, /,

Package IEEE. std_logic_arith Typen n signed, unsigned Operatoren n n +, -, *, /, ABS, . . <, >, <=, . . . Konvertierungsfunktionen CONV_INTEGER(arg: unsigned) return INTEGER. . 37 © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 38 © A. Steininger / TU Wien

Signale und Datentypen Signale dienen der Kommunikation im Design. Sie sind vergleichbar mit Leitungen

Signale und Datentypen Signale dienen der Kommunikation im Design. Sie sind vergleichbar mit Leitungen in einer Schaltung. Der Datentyp eines Signals beschreibt die Menge von Werten die das Signal annehmen kann. Bei Signalzuweisungen und Operationen müssen die Datentypen zusammenpassen. Die Deklaration des Datentyps erfolgt beim Port port (A, B, SEL: in std_logic; . . . ); …oder bei der Signaldeklaration signal x: std_logic; 39 © A. Steininger / TU Wien

Vordefinierte Datentypen Boolean Bit_vector Character String Integer Real Time 40 {true, false} {'0', '1'}

Vordefinierte Datentypen Boolean Bit_vector Character String Integer Real Time 40 {true, false} {'0', '1'} "00100011" 'a', 'z', 'E', '0', '9' "I like VHDL" 27, -237, 0, 12 -11. 23, 7. 01 E-4, 221. 09 23. 5 ns, 17 ps © A. Steininger / TU Wien

Der Datentyp "Enumerated" Die Menge der zulässigen Werte ist vom Anwender selbst definierbar type

Der Datentyp "Enumerated" Die Menge der zulässigen Werte ist vom Anwender selbst definierbar type my_state is (reset, idle, rd, wr); signal state: my_state; state <= "00"; state <= "reset"; Nur die definierten Werte dürfen zugewiesen werden 41 A © A. Steininger / TU Wien

Signalzuweisung Y <= A Entspricht einem Treiber auf Y A 42 Y © A.

Signalzuweisung Y <= A Entspricht einem Treiber auf Y A 42 Y © A. Steininger / TU Wien

Mehrfache Signalzuweisung Eine mehrfache Signalzuweisung auf das gleiche Signal bedeutet dessen Ansteuerung durch mehrere

Mehrfache Signalzuweisung Eine mehrfache Signalzuweisung auf das gleiche Signal bedeutet dessen Ansteuerung durch mehrere Treiber: Y <= A A Y Y <= B B Y ? Y Für die Simulation ist in diesem Fall eine Signal Resolution nötig. 43 A © A. Steininger / TU Wien

9 -wertige Logik (IEEE Std 1164 -1993) 44 0 strong low Treiberausgang, definiert 1

9 -wertige Logik (IEEE Std 1164 -1993) 44 0 strong low Treiberausgang, definiert 1 strong high L weak low Pull-down H weak high Pull-up X strong unknown Treiberausgang, undef´d. " W weak unknown bus-keeper, uninitialisiert Z high impedance Treiberausgang, tri-state - don't care Pegel bedeutungslos U uninitialized FF-Ausgang, uninitialisiert © A. Steininger / TU Wien

Der Datentyp "std_logic" Die 9 -wertige Logik nach IEEE 1164 ist im Datentyp Standard

Der Datentyp "std_logic" Die 9 -wertige Logik nach IEEE 1164 ist im Datentyp Standard Logic (std_logic) implementiert (Package IEEE. std_logic_1164). Standard Logic bietet eine Signal-Resolution. Diese ermöglicht – im Gegensatz zu anderen Signaltypen wie z. B. Bit oder Integer – eine dem realen Verhalten der elektrischen Signale weitgehend entsprechende Simulation. Standard Logic ist daher für Signale, die in HW realisiert werden sollen, bevorzugt zu verwenden. 45 © A. Steininger / TU Wien

Arrays (Vektoren) Zusammenfassung mehrerer Objekte des gleichen Typs n n n bit std_logic character

Arrays (Vektoren) Zusammenfassung mehrerer Objekte des gleichen Typs n n n bit std_logic character bit_vector std_logic_vector string aufsteigender oder fallender Index signal reg. A: bit_vector(1 to 3); signal addr: bit_vector(2 downto 0); 46 © A. Steininger / TU Wien

Arrays: „Concatenation“ Zusammenfügen von Vektoren (oder Teilen davon) signal addr. L: bit_vector(7 downto 0);

Arrays: „Concatenation“ Zusammenfügen von Vektoren (oder Teilen davon) signal addr. L: bit_vector(7 downto 0); signal addr. H: bit_vector(4 downto 0); signal Waddr: bit_vector(12 downto 0); Waddr <= addr. H & addr. L(4 downto 1) & '0' 47 © A. Steininger / TU Wien

Arrays: Zuweisung erfolgt positionsweise signal addr: bit_vector(2 downto 0); signal reg. A: bit_vector(1 to

Arrays: Zuweisung erfolgt positionsweise signal addr: bit_vector(2 downto 0); signal reg. A: bit_vector(1 to 3); reg. A <= addr; 48 reg. A(1) <= addr(2); reg. A(2) <= addr(1); reg. A(3) <= addr(0); © A. Steininger / TU Wien

Elementweise Zuweisung Für die Zuweisung von Elementen in ein Array gibt es vielfältige Möglichkeiten:

Elementweise Zuweisung Für die Zuweisung von Elementen in ein Array gibt es vielfältige Möglichkeiten: unabh. von der Größe des Array ! X <= (0=>'1', 2=>A, others =>'0'); X <= ('1' & '0' & A & '0'); X <= ('1', '0', A, '0'); X(0 to 1) <= („ 10“); X(2) <= A; signal X: bit_vector(0 to 3); signal A: bit; 49 A © A. Steininger / TU Wien

Operatoren Logische AND, OR, NAND, NOR, NOT, XOR Relationale >, <, >=, <=, =,

Operatoren Logische AND, OR, NAND, NOR, NOT, XOR Relationale >, <, >=, <=, =, /= Schiebeoperatoren sll, srl, sla, sra, rol, ror Arithmetische +, -, *, /, **, abs, mod, rem 50 © A. Steininger / TU Wien

Logische Operatoren NOT, AND, OR, NAND, NOR, XNOR Definiert für ▪ bit ▪ boolean

Logische Operatoren NOT, AND, OR, NAND, NOR, XNOR Definiert für ▪ bit ▪ boolean ▪ std_logic ▪ std_ulogic Y <= (SEL or A) and (not(SEL) or B); Bei Vektor Anwendung bitweise für jeweils entsprechende Elemente 51 © A. Steininger / TU Wien

Relationale Operatoren >, <, >=, <=, =, /= Liefern als Ergebnis Datentyp Boolean Anwendung

Relationale Operatoren >, <, >=, <=, =, /= Liefern als Ergebnis Datentyp Boolean Anwendung meist für if / then /else: if SEL = '0' then Bit-Vektoren haben keine numerische Bedeutung: n n 52 es wird von links kommend bitweise verglichen “ 1001“ ist kleiner als “ 111“ ! © A. Steininger / TU Wien

Arithmetische Operatoren +, -, *, /, ** [Exponent], abs, mod, rem [Rest] Definiert für

Arithmetische Operatoren +, -, *, /, ** [Exponent], abs, mod, rem [Rest] Definiert für ▪ integer ▪ real (nicht mod, rem) ▪ time Y <= A * abs(B-C) + (F**2); Im allgemeinen müssen Operanden (und Ergebnis) gleichen Typ haben 53 © A. Steininger / TU Wien

Kleiner Unterschied … entity OPERATION is port(a, b: in std_logic_vector(0 to 15); y: out

Kleiner Unterschied … entity OPERATION is port(a, b: in std_logic_vector(0 to 15); y: out std_logic_vector(0 to 15)); end OPERATION; architecture F_NAND of OPERATION is begin y <= not (a and b); end F_NAND; 54 architecture F_MULT of OPERATION is begin y <= a * b; end F_MULT; © A. Steininger / TU Wien

… große Wirkung NAND: 16 GE 55 MULT: ca. 2800 GE © A. Steininger

… große Wirkung NAND: 16 GE 55 MULT: ca. 2800 GE © A. Steininger / TU Wien

Attribute Feldbezogene Attribute (Beispiele) n n n a‘left, a‘right a‘low, a‘high a‘range Signalbezogene Attribute

Attribute Feldbezogene Attribute (Beispiele) n n n a‘left, a‘right a‘low, a‘high a‘range Signalbezogene Attribute (Beispiele) n n 56 s‘event s‘stable © A. Steininger / TU Wien

Sequentielle Anweisungen nur innerhalb Process zulässig n Wait Anweisung n If-Then-Else Anweisung n Case

Sequentielle Anweisungen nur innerhalb Process zulässig n Wait Anweisung n If-Then-Else Anweisung n Case Anweisung n Loop Anweisung n Assert Anweisung 57 © A. Steininger / TU Wien

Wait-Anweisungen nicht synthetisierbar Wait for <time> wait for 100 ms; Wait on <event on

Wait-Anweisungen nicht synthetisierbar Wait for <time> wait for 100 ms; Wait on <event on signal from list> wait on A, B, C; Wait until <condition> wait until trig = '1'; Wait [forever] wait; 58 © A. Steininger / TU Wien

If-Then-Else Anweisung Bedingung if A < 0 then -- A < 0 B <=

If-Then-Else Anweisung Bedingung if A < 0 then -- A < 0 B <= 0; elsif A < 3 then -- 0 A < 3 B <= 1; elsif A > 2 then -- A 3 B <= 2; else -- ? ? B <= 3; sequentielle Statements end if; Bei elsif wird der erste gültige Zweig gewählt => Reihenfolge wichtig 59 A © A. Steininger / TU Wien

If-Then-Else Beispiel 1 process(in 1, in 2, in 3) begin -- process if in

If-Then-Else Beispiel 1 process(in 1, in 2, in 3) begin -- process if in 1 = '0' then out 1 <= '0'; else if in 2 = '1' then out 1 <= in 3; else out 1 <= not in 3; end if; end process; 60 MUX 2 MUX 1 © A. Steininger / TU Wien

If-Then-Else Beispiel 2 process (in 1, in 2, in 3) begin -- process if

If-Then-Else Beispiel 2 process (in 1, in 2, in 3) begin -- process if in 1 = '0' then out 1 <= '0'; elsif in 2 = '1' then out 1 <= in 3; else out 1 <= not in 3; end if; end process; 61 © A. Steininger / TU Wien

Case-Anweisung "Objekt" case (a + b) is sequ. Statemt. when 0 => Bereich y

Case-Anweisung "Objekt" case (a + b) is sequ. Statemt. when 0 => Bereich y <= 1; Jeder mögliche when 1 to 3 => Wert des Liste y <= 2; Objekts muss when 4 | 6 => exakt einmal Rest y <= 3; vorkommen when others => (obligat) y <= 4; end case; 62 A © A. Steininger / TU Wien

Case Beispiel process (sel, in 3) begin -- process case (sel) is when "11"

Case Beispiel process (sel, in 3) begin -- process case (sel) is when "11" => out 1 <= in 3; when "10" => out 1 <= not in 3; when others => out 1 <= '0'; end case; end process; 63 © A. Steininger / TU Wien

Loop-Anweisung process (in_vec) variable parity: std_logic: ='0'; begin -- process parity: ='0'; for i

Loop-Anweisung process (in_vec) variable parity: std_logic: ='0'; begin -- process parity: ='0'; for i in 15 downto 0 loop Iterationsparity: =parity xor in_vec(I); vorschrift end loop; -- i sequenzielle out 1 <= parity; Anweisung(en) end process; 64 A © A. Steininger / TU Wien

Loop: Syntheseergebnis Die sequenzielle Anweisung in der Schleife wird mehrfach ausgeführt und generiert daher

Loop: Syntheseergebnis Die sequenzielle Anweisung in der Schleife wird mehrfach ausgeführt und generiert daher mehrfach Hardware 65 © A. Steininger / TU Wien

Assert-Anweisung zur Überprüfung von Bedingungen während der Simulation Bedingung, wenn „false“: assert a /=

Assert-Anweisung zur Überprüfung von Bedingungen während der Simulation Bedingung, wenn „false“: assert a /= 0 report „Dumm gelaufen“Ausgabestring severity error (optional) Severity level [note, warning, error, failure] Abbruchlevel Simulator-abhängig 66 © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 67 © A. Steininger / TU Wien

Wiederholung Modellierung in VHDL Verhalten Struktur Register. Transfers Beschreibung der internen Funktion von Blöcken

Wiederholung Modellierung in VHDL Verhalten Struktur Register. Transfers Beschreibung der internen Funktion von Blöcken („design units“) sys ALU, Register & Signale Beschreibung der Verbindungen zwischen Blöcken cir gate RTL alg Makrozellen & globales Routing …erfolgt jedenfalls in der Architecture 68 A Geometrie © A. Steininger / TU Wien

Strukturmodellierung 69 t h c Deklaration: i l g ö n Welche Komponenten sollen

Strukturmodellierung 69 t h c Deklaration: i l g ö n Welche Komponenten sollen ins Design m r e? eingefügt werden (Anschlüsse, …) g n u r Instanzierung: e i gn! l l e si auch mehrfach, n Komponenten werden d eingefügt, e o D M s Funktion wird nicht wenn nötig; ihre interne r e c(black explizit betrachtet he box) d t his r A Portmapping: c r e a s r e n Verbindungen zwischen den Komponenten (vgl. i e i D h werden hergestellt. Bauteile) n i e © A. Steininger / TU Wien

Beispiel MUX-Kaskade Für die folgende Schaltung ist durch geeignete Instanzierung der Component MUX 1

Beispiel MUX-Kaskade Für die folgende Schaltung ist durch geeignete Instanzierung der Component MUX 1 eine strukturelle Darstellung anzugeben. SEL 2 SEL 1 IN 2 s OUTP IN 3 70 © A. Steininger / TU Wien

Komponentendeklaration 71 entity MUX 1 is port (A, B, SEL: in std_logic; e g

Komponentendeklaration 71 entity MUX 1 is port (A, B, SEL: in std_logic; e g a k Y: out std_logic); c a m. P i n o i t ra a l k end MUX 1; e D iv: t a n r e t Al architecture DEMO of MUX_CASCADE is … component MUX 1 port (A, B, SEL: in std_logic; Y: out std_logic); end component; … end DEMO © A. Steininger / TU Wien

Instanzierung & Port Map 72 architecture DEMO of MUX_CASCADE is signal s: std_logic; component

Instanzierung & Port Map 72 architecture DEMO of MUX_CASCADE is signal s: std_logic; component MUX 1 port (A, B, SEL: in std_logic; Y: out std_logic); end component; begin -- DEMO m 1: MUX 1 port map(IN 1, IN 2, SEL 1, s); m 2: MUX 1 port map(s, IN 3, SEL 2, OUTP); end DEMO; © A. Steininger / TU Wien

Signaldeklaration architecture DEMO of MUX_CASCADE is signal s: std_logic; component MUX 1 port (A,

Signaldeklaration architecture DEMO of MUX_CASCADE is signal s: std_logic; component MUX 1 port (A, B, SEL: in std_logic; Y: out std_logic); end component; begin -- DEMO m 1: MUX 1 port map(IN 1, IN 2, SEL 1, s); m 2: MUX 1 port map(s, IN 3, SEL 2, OUTP); end DEMO; 73 © A. Steininger / TU Wien

Lokale Signale an den Anschlüssen sind in der Entity deklariert => in der Architecture

Lokale Signale an den Anschlüssen sind in der Entity deklariert => in der Architecture keine Deklaration nötig Lokale (=interne) Signale müssen in der Architecture zu Beginn explizit deklariert werden. SEL 2 Entity MUX_CASCADE SEL 1 IN 2 s OUTP IN 3 74 A © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 75 © A. Steininger / TU Wien

Wiederholung Modellierung in VHDL Verhalten Struktur Register. Transfers Beschreibung der internen Funktion von Blöcken

Wiederholung Modellierung in VHDL Verhalten Struktur Register. Transfers Beschreibung der internen Funktion von Blöcken („design units“) sys ALU, Register & Signale Beschreibung der Verbindungen zwischen Blöcken cir gate RTL alg Makrozellen & globales Routing …erfolgt jedenfalls in der Architecture 76 A Geometrie © A. Steininger / TU Wien

Abbildung eines VHDL-Befehls Jeder Befehl wird bei der Synthese auf architecture X of F_AND

Abbildung eines VHDL-Befehls Jeder Befehl wird bei der Synthese auf architecture X of F_AND is entsprechende Hard- begin ware abgebildet. Y <= A and B; end X; Diese Hardware arbeitet permanent. Ein Befehl wird daher nicht nur einmal abgearbeitet, sondern A alle Befehle sind Y B ständig aktiv (vgl. HW) 77 © A. Steininger / TU Wien

Concurrency VHDL-Statements beschreiben Hardware. Funktionseinheiten und sind in der Lage, alle gleichzeitig zu arbeiten.

Concurrency VHDL-Statements beschreiben Hardware. Funktionseinheiten und sind in der Lage, alle gleichzeitig zu arbeiten. VHDL-Anweisungen werden daher grundsätzlich parallel ("concurrent") ausgeführt. Im Gegensatz dazu werden in der Software normalerweise alle Befehle nacheinander ("sequentiell") abgearbeitet. Ein Simulator führt daher in einem Zeitschritt zunächst alle parallelen Anweisungen aus („Delta. Time“), bevor er die Zeit inkrementiert. 78 © A. Steininger / TU Wien

Beispiel zur Concurrency architecture X of SRLT is begin QN <= not(S or Q);

Beispiel zur Concurrency architecture X of SRLT is begin QN <= not(S or Q); Q <= not(R or QN); end X; Funktion in HW: n n n SRLT 1 0 0 U Bei sequentieller Bearbeitung wie in SW: n 1 0 79 A 10 U Statements beschreiben die Struktur Reihenfolge irrelevant Beide Zuweisungen werden ständig und parallel vorgenommen n Reihenfolge ist wichtig ! Anderes Verhalten ! © A. Steininger / TU Wien

Concurrency: weitere Beispiele Y <= Y + 1; SW: Incrementer (Y in Register!) HW:

Concurrency: weitere Beispiele Y <= Y + 1; SW: Incrementer (Y in Register!) HW: Timing Loop / Overflow Y <= not(Y); SW: Inversion HW: Timing Loop / Oszillator 80 Y <= 0; Y <= B + C; SW: Initialisierung von Y HW: Treiberkonflikt Y <= A + B; A <= C + D; SW: Y wird mit altem Wert von A berechnet HW: 2 Addierer in Kaskade; Y verwendet aktuelles A © A. Steininger / TU Wien

Sequenzielle Abläufe werden in VHDL als Process formuliert. Manche Statements sind grundsätzlich nur innerhalb

Sequenzielle Abläufe werden in VHDL als Process formuliert. Manche Statements sind grundsätzlich nur innerhalb eines Process zulässig: n IF / THEN / ELSE n CASE Ein Simulator führt die Anweisungen im Process der Reihe nach durch. 81 <label>: process(<sens>) begin statement 1. . . statement n end process <label> © A. Steininger / TU Wien

Signalzuweisungen im Process Die Auswertung der Signalzuweisungen erfolgt ausschließlich am Ende des Process. Es

Signalzuweisungen im Process Die Auswertung der Signalzuweisungen erfolgt ausschließlich am Ende des Process. Es sind daher auch mehrfache Zuweisungen auf das selbe Signal zulässig, ohne dass sich Treiberkonflikte ergeben. Zur Wirkung kommt nur die jeweils letzte Zuweisung auf ein Signal, alle anderen werden ignoriert (d. h. kommen nicht einmal kurzzeitig zur Wirkung). Zuweisungen von verschiedenen Processes auf das selbe Signal führen jedoch zu Treiberkonflikten. 82 © A. Steininger / TU Wien

Process: ein Beispiel architecture MUX_RTL 2 of MUX 1 is begin -- MUX_RTL 2

Process: ein Beispiel architecture MUX_RTL 2 of MUX 1 is begin -- MUX_RTL 2 Sensitivity slct: process(A, B, SEL) List begin Y <= B; sequentielle if SEL = '0' then Statements Y <= A; end if; Letzte end process slct; ausgeführte end MUX_RTL 2; Zuweisung wird wirksam 83 A © A. Steininger / TU Wien

Signalzuweisung: ein Beispiel Gegeben ist folgender Process, wobei zu Beginn gilt A = 2,

Signalzuweisung: ein Beispiel Gegeben ist folgender Process, wobei zu Beginn gilt A = 2, B = 5, Y = 9, Z = 0: signal A, B, Y, Z: integer; assigmt: process(A, B, Y) begin Y <= B; Y <= A; Z <= Y-1; end process assigmt; Welche Werte haben Y und Z nach einem Durchlauf des Process? 2 8 9 5 0 84 A © A. Steininger / TU Wien

Sensitivity List Processes werden nicht ständig durchlaufen. In der Sensitivity List sind jene Signale

Sensitivity List Processes werden nicht ständig durchlaufen. In der Sensitivity List sind jene Signale anzugeben, bei deren Änderung ("Event") der Simulator den Process von neuem durchlaufen soll. Dies sind bei kombinatorischer Logik alle Signale, die im Process gelesen werden. Die Sensitivity List nur für die Simulation relevant und hat keinen Einfluss auf das Ergebnis der Synthese (nur Warning wenn unvollständig). 85 © A. Steininger / TU Wien

Sensitivity List: ein Beispiel slct: process(A, B, SEL) begin if SEL = '0' then

Sensitivity List: ein Beispiel slct: process(A, B, SEL) begin if SEL = '0' then Y <= A; else Y <= B; end if; end process slct; HW und Simulation verhalten sich unterschiedlich! A B SEL HW Sim 86 A © A. Steininger / TU Wien

Processes und Concurrency Anweisungen im Process: sequentiell unterschiedliche Processes und Anweisungen außerhalb von Processes:

Processes und Concurrency Anweisungen im Process: sequentiell unterschiedliche Processes und Anweisungen außerhalb von Processes: parallel p a r a l l e l statement A PROCESS 1 statement X … statement Z 87 statement B PROCESS k statement R … statement U © A. Steininger / TU Wien

Processes in der Architecture architecture ABSTRACT of EXAMPLE is begin -- ABSTRACT <concurrent statements>;

Processes in der Architecture architecture ABSTRACT of EXAMPLE is begin -- ABSTRACT <concurrent statements>; P 1: process(<sensitivity list>) beliebig viele begin Processes <sequential statements>; end process P 1; beliebig viele <concurrent statements>; concurrent P 2: process(<sensitivity list>) Statements begin <sequential statements>; Reihenfolge end process P 2; irrelevant <concurrent statements>; end ABSTRACT; 88 A © A. Steininger / TU Wien

Variable Lokale Gültigkeit innerhalb eines Process. Nach außen nicht sichtbar. Wertzuweisung erfolgt sofort. Operator

Variable Lokale Gültigkeit innerhalb eines Process. Nach außen nicht sichtbar. Wertzuweisung erfolgt sofort. Operator für Zuweisung ist ": =" anstelle von "<=". Wert wird zwischen zwei Aufrufen des Process beibehalten. Wechselseitige Zuweisung zwischen Variablen und Signalen zulässig, sofern Datentyp übereinstimmt. 89 © A. Steininger / TU Wien

Variable versus Signal Werte zu Beginn: A = 2, B = 5, Y=9, Z=0

Variable versus Signal Werte zu Beginn: A = 2, B = 5, Y=9, Z=0 signal A, B, Y, Z: integer; assigmt: process(A, B, Y) signal A, B, Z: integer; assigmt: process(A, B) variable Y: integer; begin Y : = B; Y : = A; Z <= Y-1; end process assigmt; begin Y <= B; Y <= A; Z <= Y-1; end process assigmt; Werte nach dem Process: (1) Y = 2, Z = 8 (2) Y = 2, Z = 1 90 A Y = 2, Z = 1 © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 91 © A. Steininger / TU Wien

Codierung eines Multiplexers architecture GOOD_ONE of MUX 1 is begin -- GOOD_ONE slct: process(A,

Codierung eines Multiplexers architecture GOOD_ONE of MUX 1 is begin -- GOOD_ONE slct: process(A, B, SEL) begin if SEL ='0' then Bedingung Y <= A; IF-Zweig else Y <= B; end if; ELSE-Zweig end process slct; end GOOD_ONE; 92 A © A. Steininger / TU Wien

Codierung eines Latch architecture BAD_ONE of MUX is begin -- BAD_ONE slct: process(A, SEL)

Codierung eines Latch architecture BAD_ONE of MUX is begin -- BAD_ONE slct: process(A, SEL) begin if SEL ='0' then Y <= A; Bedingung -- KEIN ELSE-ZWEIG d. h. alten Wert halten, wenn Bedingung nicht end if; erfüllt ist. end process slct; end BAD_ONE; 93 A © A. Steininger / TU Wien

Codierung eines Flip-Flop architecture GOOD_ONE of FLIPFLOP is begin -- GOOD_ONE nur clk in

Codierung eines Flip-Flop architecture GOOD_ONE of FLIPFLOP is begin -- GOOD_ONE nur clk in der sync: process(clk) begin Sensitivity-List ! if clk'event and clk = '1' then outp <= data; end if; kein ELSE-Zweig end process sync; end GOOD_ONE; 94 A © A. Steininger / TU Wien

Synchr. & Asynchr. Reset asynchroner if asyn_rst = '0' then Reset outp <= '0';

Synchr. & Asynchr. Reset asynchroner if asyn_rst = '0' then Reset outp <= '0'; else if clk'event and clk = '1' then if syn_rst = '0' then synchr. outp <= '0'; Reset else outp <= data; end if; Sensitivity List enthält end if; clk und asyn_rst, end if; nicht jedoch syn_rst 95 A © A. Steininger / TU Wien

Clock Enable sync: process(clk) begin if clk'event and clk = '1' then outp <=

Clock Enable sync: process(clk) begin if clk'event and clk = '1' then outp <= next_data ; end if; Hilfssignal, wird end process sync; asynchron ermittelt new_data: process(data, enable, outp) begin if enable = '1' then next_data <= data; else next_data <= outp; end if; end process new_data; 96 A © A. Steininger / TU Wien

Asynchroner Teiler entity tff is port(clk: in std_logic; q: inout std_logic); end tff; entity

Asynchroner Teiler entity tff is port(clk: in std_logic; q: inout std_logic); end tff; entity takt is port(clk: in std_logic; q: inout std_logic); end takt; architecture A of tff is begin -- Toggle Flip-Flop work: process(clk) begin if (clk'event and clk = '1') then q <= not(q); end if; end process work; end A; architecture B of takt is signal x, y : std_logic; -- component declaration tff begin tff 1: tff port map(clk=>clk, q=>x); tff 2: tff port map(clk=>x, q=>y); tff 3: tff port map(clk=>y, q=>q); end B; 97 © A. Steininger / TU Wien

Asynchroner Teiler – Probleme Wird Q in ein Taktnetz eingespeist ? Q ist gegenüber

Asynchroner Teiler – Probleme Wird Q in ein Taktnetz eingespeist ? Q ist gegenüber CLK stark verschoben, Delay ist jedoch unbestimmt. 98 © A. Steininger / TU Wien

Binärer Zähler: Entity Zu entwerfen ist ein synchroner 8 -Bit Zähler: Libs und packages

Binärer Zähler: Entity Zu entwerfen ist ein synchroner 8 -Bit Zähler: Libs und packages library IEEE; use IEEE. std_logic_1164. all; sichtbar machen use work. my_constants. all; entity syn_counter is port( clk: in std_logic; cnt: inout std_logic_vector(WIDTH-1 downto 0); oflo: out std_logic; rst: in std_logic; ); end syn_counter; 99 A © A. Steininger / TU Wien

Binärer Zähler: Package library IEEE; use IEEE. std_logic_1164. all; Lib und packages sichtbar machen

Binärer Zähler: Package library IEEE; use IEEE. std_logic_1164. all; Lib und packages sichtbar machen package my_constants is -- define levels to be active high constant ACTIVE: std_logic : = '1'; -- define width of counter constant WIDTH : integer : = 8; -- define maximum count constant MAXCNT: std_logic_vector(WIDTH-1 downto 0) : = (others => '1'); end my_constants; 100 A © A. Steininger / TU Wien

Binärer Zähler: Architecture 1 library use use IEEE; Lib und packages IEEE. std_logic_1164. all;

Binärer Zähler: Architecture 1 library use use IEEE; Lib und packages IEEE. std_logic_1164. all; sichtbar machen IEEE. std_logic_UNSIGNED. all; work. my_constants. all; architecture nice of syn_counter is signal next. Cnt: std_logic_vector(WIDTH-1 downto 0); Signaldeklaration begin -- <process count_syn: synchronous capture of next state> -- <process value_update: asynchronous next-state-logic> Hier werden noch 2 Prozesse eingefügt end nice; 101 A © A. Steininger / TU Wien

Binärer Zähler: Architecture 2 count_syn: process(clk, rst) begin if rst = ACTIVE then asynchroner

Binärer Zähler: Architecture 2 count_syn: process(clk, rst) begin if rst = ACTIVE then asynchroner cnt <= (others => '0'); Reset else if clk'event and clk = '1' then synchron cnt <= next. Cnt; übernehmen end if; end process count_syn; 102 A © A. Steininger / TU Wien

Binärer Zähler: Architecture 3 value_update: process(cnt) Kein else-Zweig Aber Default-Zuweisung begin next. Cnt <=

Binärer Zähler: Architecture 3 value_update: process(cnt) Kein else-Zweig Aber Default-Zuweisung begin next. Cnt <= cnt + '1'; Zählen ohne oflo <= not ACTIVE; Overflow if cnt = MAXCNT then next. Cnt <= (others => '0'); Overflow behandeln oflo <= ACTIVE; end if; end process value_update; 103 A © A. Steininger / TU Wien

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung

Überblick Historie & Anwendung Grundelemente des Design Syntax: Signale, Datentypen & Operatoren Strukturelle Modellierung & Hierarchie Verhaltensmodellierung: parallele und sequenzielle Abläufe Codierungsbeispiele Testbench 104 © A. Steininger / TU Wien

Zweck einer Testbench Jede sinnvolle Hardware muss in ihrer Anwendung mit der Umwelt interagieren

Zweck einer Testbench Jede sinnvolle Hardware muss in ihrer Anwendung mit der Umwelt interagieren (Inputs & Outputs). Um ein Design funktional zu testen noch bevor die HW gefertigt ist, muss es in eine (virtuelle) Umgebung eingebettet werden, die den Bedingungen im Betrieb möglichst gleicht. Diese Einbettung zu schaffen, ist Aufgabe der Testbench. Sie hat typisch folgende Aufgaben: n n 105 Generieren des Taktes Anlegen eines Reset und Initialisierung der Eingänge Simulation von Eingangssignalen bzw. Sequenzen davon ggf. Auswertung von Outputs © A. Steininger / TU Wien

Wiederholung Simulation & Testbench Stimuli Design Trace File Testbench Design wird als Modul in

Wiederholung Simulation & Testbench Stimuli Design Trace File Testbench Design wird als Modul in größeres Design (Testbench) eingebettet und erhält so Stimuli für die Eingänge bei der Simulation. Die Testbench ist stets auf dem Top-Level, und das zu testende Design ist als Component eingebettet 106 A © A. Steininger / TU Wien

Aufbau einer Testbench Die Testbench besteht wie jede Design Unit aus Architecture, Entity und

Aufbau einer Testbench Die Testbench besteht wie jede Design Unit aus Architecture, Entity und Configuration. Die Testbench ist hierarchisch auf dem Top Level und hat keine Inputs und Outputs. Das zu testende Design wird als Component instanziert und die Signale entsprechend angeschlossen (port map). Die Testbench dient nur der Simulation und wird später nicht in Hardware gefertigt. Sie muss daher nicht synthetisierbar sein. 107 © A. Steininger / TU Wien

Reset und Initialisierung Reset muss zu Beginn lang genug anliegen n n mindestens 1

Reset und Initialisierung Reset muss zu Beginn lang genug anliegen n n mindestens 1 Taktperiode + Einschwingzeiten wirkt bei Simulation und Hardware gleich Initialisierung von Eingängen/Signalen n direkt z. B. über Maskierung y <= a and reset; n über Default bei der Deklaration wirkt NUR bei Simulation, später keine Auswirkung auf die Hardware! signal x : std_logic : = '0'; 108 © A. Steininger / TU Wien

Testbench – ein Beispiel (1) library use use IEEE; IEEE. std_logic_1164. all; IEEE. std_logic_UNSIGNED.

Testbench – ein Beispiel (1) library use use IEEE; IEEE. std_logic_1164. all; IEEE. std_logic_UNSIGNED. all; work. my_constants. all; entity testbench is end testbench; Keine Ports => Entity trivial architecture behav of testbench is constant clock_period : time : = 100 ns; signal clock, reset, overflow : std_logic; signal count : std_logic_vector(WIDTH-1 downto 0); 109 A © A. Steininger / TU Wien

Testbench – ein Beispiel (2) component syn_counter is port( clk: in std_logic; cnt: inout

Testbench – ein Beispiel (2) component syn_counter is port( clk: in std_logic; cnt: inout std_logic_vector(WIDTH-1 downto 0); oflo: out std_logic; rst: in std_logic ); Design als Component deklariert end component ; begin DUT: syn_counter port map Instanzierung des Design (clock, count, overflow, reset); 110 A © A. Steininger / TU Wien

Testbench – ein Beispiel (3) Clock. Generator: process begin clock <= '1'; wait for

Testbench – ein Beispiel (3) Clock. Generator: process begin clock <= '1'; wait for clock_period/2; Takt generieren (Process läuft endlos !) clock <= '0'; wait for clock_period/2; end process Clock. Generator; 111 A © A. Steininger / TU Wien

Testbench – ein Beispiel (4) Waveforms: process begin reset <= ACTIVE; Reset aktivieren wait

Testbench – ein Beispiel (4) Waveforms: process begin reset <= ACTIVE; Reset aktivieren wait for (2. 1*clock_period); für > 2 Taktzyklen reset <= not ACTIVE; -- bei Bedarf hier weitere Zuweisungen auf Signale wait for (2**WIDTH + 1) * clock_period; Zähler-Überlauf abwarten assert false report "test finished" severity error; end process Waveforms; Simulation abbrechen end behav; 112 A © A. Steininger / TU Wien

Modellierung von Delay Zuweisung einer Verzögerung in VHDL Y <= A after 25 ns;

Modellierung von Delay Zuweisung einer Verzögerung in VHDL Y <= A after 25 ns; Wird vom Simulator für die Behavioral Simulation berücksichtigt Ist jedoch nicht synthetisierbar und wird daher bei der Synthese verworfen (Warning) Nach der Synthese bzw. dem PPR werden ohnedies Default-Werte bzw. backannotierte Delays verwendet. 113 © A. Steininger / TU Wien

Testbench - Simulation 114 © A. Steininger / TU Wien

Testbench - Simulation 114 © A. Steininger / TU Wien

Wiederholung Moore-State Machine Feedback INPUT Next. State. Logic Ableitung des nächsten Zustands aus aktuellem

Wiederholung Moore-State Machine Feedback INPUT Next. State. Logic Ableitung des nächsten Zustands aus aktuellem Zustand und Eingängen 115 Next State Current State Output Logic Register synchroner Zustandswechsel OUTPUT Ableitung der Ausgänge aus aktuellem Zustand © A. Steininger / TU Wien

State-Machines in VHDL Funktionen der FSM Prozesse in VHDL (1) synchroner Zustandswechsel (1) Synchroner

State-Machines in VHDL Funktionen der FSM Prozesse in VHDL (1) synchroner Zustandswechsel (1) Synchroner Teil (2) Berechnung des nächsten Zustandes (2) Next-State-Logic (asynchroner Process) (3) Berechnung der Ausgänge (3) Output Logic (asynchroner Process) 116 © A. Steininger / TU Wien

Ampel: Package library IEEE; use IEEE. std_logic_1164. all; package ampel_const is type state is

Ampel: Package library IEEE; use IEEE. std_logic_1164. all; package ampel_const is type state is (Xgrn, Xyel, Xred, Xry); constant constant GREEN: YELLOW: REDYEL: ACTIVE: std_logic_vector(0 std_logic: ='1'; to to 2): ="100"; 2): ="010"; 2): ="001"; 2): ="011"; end ampel_const; 117 © A. Steininger / TU Wien

Ampel: Entity library IEEE; use IEEE. std_logic_1164. all; entity ampel is port( clk :

Ampel: Entity library IEEE; use IEEE. std_logic_1164. all; entity ampel is port( clk : in std_logic; reset : in std_logic; timer_puls: in std_logic; Handshake mit timer_ack: inout std_logic; externem Timer lights_X: out std_logic_vector(0 to 2); lights_Y: out std_logic_vector(0 to 2) ); end ampel; 118 © A. Steininger / TU Wien

Externer Timer: Handshake Time Ref timer_puls timer_ack Der externe Timer generiert, abgeleitet von einer

Externer Timer: Handshake Time Ref timer_puls timer_ack Der externe Timer generiert, abgeleitet von einer Zeitreferenz, Pulse timer_puls die jeweils bis zur Quittierung durch timer_ack aktiv bleiben. 119 © A. Steininger / TU Wien

Ampel: Architecture (1) library IEEE; use IEEE. std_logic_1164. all; use work. ampel_const. all; architecture

Ampel: Architecture (1) library IEEE; use IEEE. std_logic_1164. all; use work. ampel_const. all; architecture simple of ampel is signal phase, next. Phase: state; signal next. Timer_ack: std_logic; begin --< process syn_phase: synchroner Teil > --< process next_phase: Next-State-Logic > --< process output: Output Logic > end simple; 120 © A. Steininger / TU Wien

Ampel: Architecture (2) syn_phase: process(clk, reset) begin if reset = ACTIVE then phase <=

Ampel: Architecture (2) syn_phase: process(clk, reset) begin if reset = ACTIVE then phase <= Xyel; timer_ack <= not ACTIVE; else if clk'event and clk = '1' then phase <= next. Phase; timer_ack <= next. Timer_ack; end if; end process syn_phase; 121 © A. Steininger / TU Wien

Ampel: Architecture (3) next_phase: process(timer_puls, phase, timer_ack) begin Default next. Phase <= phase; Assignments

Ampel: Architecture (3) next_phase: process(timer_puls, phase, timer_ack) begin Default next. Phase <= phase; Assignments next. Timer_ack <= not ACTIVE; if timer_puls = ACTIVE then next. Timer_ack <= ACTIVE; if timer_ack = not ACTIVE then case phase is when Xyel => next. Phase <= Xred; when Xred => next. Phase <= Xry; when Xry => next. Phase <= Xgrn; when others => next. Phase <= Xyel; end case; end if; end process next_phase; 122 © A. Steininger / TU Wien

Ampel: Architecture (4) output: process(phase) begin case phase is when Xgrn => when Xred

Ampel: Architecture (4) output: process(phase) begin case phase is when Xgrn => when Xred => when Xry => when others => lights_X lights_Y <= <= GREEN; RED; GREEN; REDYEL; YELLOW; REDYEL; end case; end process output; 123 © A. Steininger / TU Wien

Zusammenfassung (1) VHDL ist eine standardisierte Sprache, die für die Beschreibung von Hardware verwendet

Zusammenfassung (1) VHDL ist eine standardisierte Sprache, die für die Beschreibung von Hardware verwendet wird. Der Standard bezieht sich auf die Syntax. Viele syntaktisch richtige Konstrukte sind zwar simulierbar jedoch nicht in Hardware implementierbar. Ein Design wird in VHDL beschrieben durch n Entity (Anschlüsse) n Architecture (Funktionsbeschreibung) und n Configuration (Zuordnung Entity/Architecture) 124 © A. Steininger / TU Wien

Zusammenfassung (2) Mittels eines Package können Konstante, Funktionen etc. global definiert werden. Ein Package

Zusammenfassung (2) Mittels eines Package können Konstante, Funktionen etc. global definiert werden. Ein Package muss vor seiner Verwendung sichtbar gemacht werden. Über Libraries können vordefinierte Packages eingebunden werden, wie z. B. std_logic_1164. Die Funktionsbeschreibung in der Architecture kann entweder in der Struktur- oder in der Verhaltensdomäne erfolgen. Die Möglichkeit in der Struktubeschriebung, bestehende Entities als Components einzubinden, erlaubt ein hierarchisches Design. 125 © A. Steininger / TU Wien

Zusammenfassung (3) Die Kommunikation innerhalb des Designs erfolgt über Signale. Jedes Signal muss bei

Zusammenfassung (3) Die Kommunikation innerhalb des Designs erfolgt über Signale. Jedes Signal muss bei der Deklaration ein Signaltyp zugewiesen werden, der die Menge jener Werte beschreibt, die das Signal annehmen darf. Neben den im Standard vordefinierten Datentypen gibt es auch den Typ „enumerated“. 126 © A. Steininger / TU Wien

Zusammenfassung (4) Ein wesentliches Konzept in VHDL ist die Concurrency: Im Normalfall laufen alle

Zusammenfassung (4) Ein wesentliches Konzept in VHDL ist die Concurrency: Im Normalfall laufen alle Anweisungen parallel ab. Einen sequentiellen Ablauf von Anweisungen erreicht man nur innerhalb eines Process. Im Process erfolgt die Zuweisung von Signalen erst ganz am Ende, die von Variablen jedoch sofort. Die Sensitivity-List des Process führt jene Sig-nale an, bei deren Änderung der Process im Simulator erneut durchlaufen wird. 127 © A. Steininger / TU Wien

Zusammenfassung (4) Die Testbench schafft eine virtuelle Umgebung, in die das Design für den

Zusammenfassung (4) Die Testbench schafft eine virtuelle Umgebung, in die das Design für den Test eingebettet wird. Sie wird ebenfalls in VHDL formuliert, braucht jedoch nicht synthetisierbar zu sein. 128 © A. Steininger / TU Wien