ReOrg Praktikum 1

by

These are notes taken during the ReOrg practical course 2005. Sources are prepared in such a way that tutors can easily check if they were just copied from here. So do yourself a favor and don't copy it.

Versuchsvorbereitung

  1. Was ist VHDL und wozu wird es benutzt?

    VHDL

    VHSIC Hardware Description Language

    VHSIC

    Very High Speed Integrated Circuit

    • Hardware-Beschreibungssprache

    • Spezifizierung Anfang der 80er Jahre

    • Standardisierung 1987 bzw. 1993 vom IEEE

    • Enthält aus "normalen" Programmiersprachen bekannte Dateitypen, Kontrollstrukturen, Prozeduren und dergleichen auch Konzepte, welche spezielle Eigenschaften von Hardware reflektieren

  2. Aus welchen Bestandteilen ist eine VHDL-Beschreibung aufgebaut?

    • Schnittstellenbeschreibung:

      • Schlüsselwort: entity

      • Spezifizierung Ein- und Ausgabe des Systems (Schlüsselwort: port)

      • Definition von Konstanten (Schlüsselwort: generic)

    • Architekturbeschreibung:

      • Schlüsselwort: architecture

      • Realisierung eines Entity (mehrere Realisierungen möglich)

  3. Welche Modellierungssichtweisen beim Design von digitalen Systemen kennt man?

    • Verhaltensmodellierung:

      • Angabe eines Algorithmus in VHDL-Notation

      • Keine interne technische Realisierung (Gatter, Verbindungen, usw.)

      • Optimierung allein dem Compiler überlassen (nicht immer optimal)

    • Datenflussmodellierung:

      • Beschreibung des "Flusses" und der Transformation der Daten von den Eingängen zu den Ausgängen

    • Strukturmodellierung:

      • Beschreibung der Verbindungen der einzelnen Komponenten eines Systemes

      • hierarchische Zusammensetzung eines komplexen Designs aus mehreren eventuell einfacheren Komponenten

  4. Kann man durch Simulation die Korrektheit des parity-Beispiels aus 3.3 beweisen? Wenn ja, warum? Ist so etwas mit Simulation generell (praktisch) möglich? Wo könnten dabei eventuell Probleme auftreten?

    Ja. Das Beispiel aus 3.3 lässt sich beweisen, da es nur 23 (=16) mögliche Eingabewerte existieren. Durch das Testen der verschiedenen Eingabewerte kann man die Korrektheit beweisen, wenn alle Ausgabewerte korrekt sind.

    Generell (praktisch) ist dies nicht immer möglich, da immer alle Eingabewerte betrachtet werden müssten. Dies kann schnell bei Eingabewerten mit höheren Bitstellen zu komplex werden.

    Mögliche Probleme:

    • Eingabewerte zu komplex

    • Einfluss von Hardwareeigenschaften

    • Fehler in der Testbenches/im Vector File

  5. Geben sie die vollständige Entity und Architecture des Addierers aus Aufgabe 3 an!

    ENTITY adder is
          PORT (
                  a, b : in bit_vector(3 downto 0);
                  z : out bit_vector(3 downto 0)
          );
    END adder;
    
    ARCHITECTURE adder_arch of adder is
          SIGNAL s: bit_vector(3 downto 0);
    BEGIN
          PROCESS(a, b)
          VARIABLE
                  cin : bit;
          BEGIN
                  cin := '0';
                  FOR i IN 0 TO 3 LOOP
                          s(i) <= (a(i) XOR b(i)) XOR cin;
                          cin := (a(i) AND b(i)) OR (a(i) AND cin) OR (b(i) AND cin);
                  END LOOP;
    
                  IF cin = '1' THEN
                          z <= "1111";
                  ELSE
                          z <= s;
                  END IF;
          END PROCESS;
    END adder_arch;

Aufgaben