5.Vorlesung Rechnerorganisation

Transkript

1 29. April Inhalt: 5.Vorlesung Rechnerorganisation Wiederholung aus Digitaltechnik: Allgemeiner Überblick über VHDL (Teil 1) Schwerpunkt Modellierungssichtweisen, insbesondere Strukturbeschreibung

2 29. April Wozu Hardwarebeschreibungssprache? Alternative wäre schaltplanähnliche Repräsentation von Hardware Beschreibungen wären ziemlich unüberschaubar der Blick auf das Wesentliche geht verloren Abläufe (Zustandsautomaten) sind sehr schlecht erkennbar sprachliche Konstrukte lassen sich gut weiterverarbeiten

3 29. April Aber: grafische Repräsentationsformen sind natürlich intuitiver sind zumindest für strukturelle Beschreibungen gut geeignet grafisch dargestellte Zustandsautomaten sind auch weniger fehlerträchtig heute findet man oft grafische Frontends welche VHDL Code erzeugen können man nimmt das, was jeweils geeignet erscheint

4 29. April Gliederung von VHDL Designs in Beschreibung der Außenbeschaltung (Entity) und Beschreibung des inneren Aufbaus (Architecture) im Sinne von: Ich gebe Dir die Außenbeschaltung und sage Dir, wie die Komponente genutzt werden kann, aber ich verrate nicht den inneren Aufbau. (Blackbox, Kapselung von,,intellectual Property )

5 29. April Parametrisierbare VHDL Designs Entities können neben Ports auch sog. Generics besitzen Generics werden wie Ports in einer Liste angegeben Beispiel: entity vieler_und is generic( eingaenge: natural); port( ein: in bit_vektor(eingaenge-1 downto 0), aus: out bit); end vieler_und; es lassen sich zusätzliche Parameter übergeben, welche sogar das äußere Erscheinungsbild (Ports) beeinflussen können

6 29. April Modellierungssichtweisen in VHDL: Datenflussbeschreibung Verhaltensbeschreibung Strukturbeschreibung

7 29. April Datenflussbeschreibung Beschreibung des Designs mehr oder weniger auf Logikgleichungs Level z.b. einfacher 2:1 Multiplexer: S A i1 1 i2 & >=1 Y B & i3 wird mehr oder weniger 1:1 beschrieben

8 29. April Datenflussbeschreibung (weiter) Architecture des MUX als Datenflussbeschreibung: architecture dataflow1 of mux is signal i1, i2, i3 : bit; begin i1 <= not s; i2 <= i1 and a; i3 <= s and b; y <= i2 or i3; end dataflow1;

9 29. April Datenflussbeschreibung (weiter) Architecture des MUX als Datenflussbeschreibung: architecture dataflow1 of mux is signal i1, i2, i3 : bit; begin i1 <= not s; i2 <= i1 and a; i3 <= s and b; y <= i2 or i3; end dataflow1; oder einfacher: architecture dataflow2 of mux is begin y <= (a and not s) or (b and s); end dataflow2;

10 29. April Datenflussbeschreibung (weiter) Problem: Diese Art der Beschreibung ist mühsam, unübersichtlich und fehlerträchtig außerdem ist sie beschränkt auf kombinatorische Sachverhalte (Was machen wir mit Speicherelementen?) ist als allumfassendes Beschreibungsparadigma nicht geeignet

11 29. April Verhaltensbeschreibung wir beschreiben keine Logikgleichungen mehr, sondern geben lediglich das Verhalten an die Beschreibung des Verhaltens sieht (im allg.) wesentlich übersichtlicher aus S A Y B

12 29. April Verhaltensbeschreibung (weiter) Beschreibung des Verhaltens meist auf Art algorithmischer Ebene im Sinne einer Programmiersprache (Prozesse nächste Vorlesung) weniger fehlerträchtig

13 29. April Verhaltensbeschreibung (weiter) Architecture des MUX als Verhaltensbeschreibung: architecture behaviour1 of mux is begin y <= a when s= 0 else b; end behaviour1; oder: architecture behaviour2 of mux is begin process(s,a,b) begin case s is when 0 => y <= a; when 1 => y <= b; end case; end process; end behaviour2;

14 29. April Verhaltensbeschreibung (weiter) Design muss durch Synthesetool auf Datenflussebene (Schaltplan) heruntergebrochen werden man muss sich nicht um den,,kleinkram kümmern

15 29. April Verhaltensbeschreibung (weiter) Design muss durch Synthesetool auf Datenflussebene (Schaltplan) heruntergebrochen werden man muss sich nicht um den,,kleinkram kümmern Aber: man gibt als Designer,,das Ruder aus der Hand (Design wird mehr oder weniger gut oder schlecht umgesetzt)

16 29. April Verhaltensbeschreibung (weiter) Achtung: Synthesetools akzeptieren in der Regel nur einen Subset des in VHDL möglichen um bestimmte Datenflusskomponenten (z.b. D FlipFlops) zu erzeugen, muss man bestimmte Konstrukte anwenden, d.h. Konventionen beachten mehr dazu in nächster Vorlesung

17 29. April Strukturbeschreibung mit Datenfluss oder Verhaltensbeschreibung lassen sich noch keine Schaltungshierarchien realisieren Designs lassen sich nicht richtig strukturieren und Einzelteile lassen sich nicht wiederverwenden (abgesehen von Prozeduren) ebenfalls lässt sich das Einbinden fertiger Funktionsblöcke (IP Cores) nicht ermöglichen eine Strukturbeschreibung bietet genau diese Features

18 29. April Strukturbeschreibung (weiter) z.b. Multiplexer aufgebaut aus Gatter Komponenten: (ist mehr akademischer Natur und hier nicht gerade geeignet ;-) S C1 (nicht) i1 C2 i2 A (und) C4 (oder) Y B C3 (und) i3

19 29. April Strukturbeschreibung (weiter) verwendete Komponenten (bzw. deren Entities) müssen im Vereinbarungsteil der Architekturbeschreibung vereinbart werden (mittels component Deklarative) Vereinbarung kann auch in externen Packages erfolgen Beispiel für Komponentendeklaration: component nicht port ( i : in bit; o : out bit); end component;

20 29. April Strukturbeschreibung (weiter) Jeder Komponenten Typ wird exakt einmal vereinbart!!! unser Multiplexer benötigt also drei verschiedene Komponenten: nicht, und, oder Einbinden (Instantiieren) der Komponenten erfolgt mittels des port map() Konstrukts

21 29. April Strukturbeschreibung (weiter) 2 Arten der Verwendung von port map(): positional port binding (Reihenfolge der angschlossenen Signale muss mit der Reihenfolge in der Entity übereinstimmen) C1: nicht port map(s, i1);

22 29. April Strukturbeschreibung (weiter) 2 Arten der Verwendung von port map(): positional port binding (Reihenfolge der angschlossenen Signale muss mit der Reihenfolge in der Entity übereinstimmen) C1: nicht port map(s, i1); named port binding (für jeden Port wird individuell angegeben, welches Signal angeschlossen wird) C1: nicht port map(i => s, o => i1); mehr Schreibaufwand, aber übersichtlicher

23 29. April Strukturbeschreibung (weiter) Multiplexer Code: architecture structure of mux is signal i1, i2, i3 : bit; component nicht port ( i : in bit; o : out bit); end component; component und port ( i1, i2 : in bit; o : out bit); end component;

24 29. April component oder port ( i1, i2 : in bit; o : out bit); end component; begin C1: nicht port map(i => s, o => i1); -- named binding C2: und port map(i1 => i1, i2 => a, o => i2); -- named binding C3: und port map(s, b, i3); -- positional binding C4: oder port map(i2, i3, y); -- positional binding end structure; (positional und named port bindings sind natürlich willkürlich gewählt worden)

25 29. April Strukturbeschreibung (weiter) Einbinden von generischen Parametern analog zu port map() mittels generic map() named oder positional binding ist ebenfalls möglich Beispiel,,vieler_und : Gate: vieler_und generic map (eingaenge => 4) port map (ein => ein, aus => aus); instantiiert vieler_und mit 4 Eingängen

26 29. April Strukturbeschreibung (weiter) Fallstricke / typische Fehler: Namen der Ports von eingebundenen Entities sind rein formale Namen und haben mit den angeschlossenen Signalen in keinster Weise etwas zu tun!!! Ebenso bezieht sich die Vereinbarung von Komponenten (component Deklarative) lediglich auf eine formale Komponente, und hat nichts mit deren späteren Instantiierung zu tun (trifft auch für die Anzahl der Instantiierungen zu)!!!

27 29. April Mischung von Beschreibungsparadigmen ist problemlos möglich VHDL erlaubt die Benutzung aller drei Modellierungssichtweisen innerhalb einer Architecture

28 29. April Zu diversen Vereinbarungen einfache Signalvereinbarungen (bit, bit_vector, std_logic, std_logic_vector) kennen wir bereits außerdem interessant für uns: Verwendung von Aufzählungstypen, z.b. type test_type is (eins, zwei, drei, vier); signal bla : test_type; was das VHDL Tool daraus macht, ist seine Sache

29 29. April Vereinbarung natürlicher Zahlen, z.b. signal counter : natural range 0 to 255; daraus wird sozusagen ein 8-Bit Vektor Vereinbarung von Konstanten, z.b. constant null : std_logic_vector(1 downto 0) := "00"; constant eins : std_logic_vector(1 downto 0) := "01"; constant zwei : std_logic_vector(1 downto 0) := "10"; constant drei : std_logic_vector(1 downto 0) := "11"; unter Umständen übersichtlicher

30 29. April Morgen: nähere Betrachtung der Verhaltensbeschreibung insbesondere die Handhabung von Prozessen