MIN-Fakultät
Fachbereich Informatik
TAMS
UHH > MIN > Informatik > TAMS > Lectures > SS 2021 > Praktika > 64-661 VHDL Schaltungs- und Systementwurf Seitenende

Unterlagen

Vorlesungsunterlagen, Literaturverweise und diverse Links - thematisch sortiert.
Die Liste wird im Laufe der Veranstaltung aktualisiert...

Aufgabenblätter | VLSI | VHDL | EDA-Programme | Hardwarekomponenten

Aufgabenblätter

VLSI-Entwurf

VHDL

Links
Hamburg VHDL Archive
VHDL Online Syntax, Synthesis und Simulation
VHDL Online Help VHDL Language Reference Guide
VHDL-Online Manual und Referenz
Accellera Systems Initiative
IEEE Hosted EDA web

EDA-Programme

Hersteller und OpenSource
Intel FPGA (Altera)
Cadence
Synopsys
GHDL und GTKWave (OpenSource VHDL-Simulator)
Setup
Um die Initialisierung der Werkzeuge zu vereinfachen, gibt es Shellscripte für bash/sh oder tcsh/csh, die die benötigten Suchpfade und Umgebungsvariablen setzen: 
source $tamsSW/profile.d/edaSetup.sh [tool-list]
source $tamsSW/profile.d/edaSetup.csh [tool-list]
Eingaben für tool-list sind beispielsweise:
ams ldv  für die Simulation:  xmvhdl, xmvlog, xmelab, xmsim
ams ldv syn  für die RT-Synthese + Simulation:  ams_synopsys
alt  für den FPGA Entwurf:  quartus
Cadence Simulation
Um alle temporären Dateien separat zu halten, empfiehlt es sich die VHDL Arbeitsbibliothek work auf ein entsprechendes Unterverzeichnis abzubilden. Dieses kann dann später komplett gelöscht werden. Dazu sind
  1. ein Unterverzeichnis work im aktuellen Verzeichnis anzulegen
  2. die Dateien cds.lib und hdl.var in das aktuelle Verzeichnis zu kopieren

Hier die Schritte zur Simulation der Ampelschaltung aus den Templates: 

xmvhdl -linedebug tlcWalk.vhd tlcTest.vhd
xmelab tlcTest
xmsim -gui tlcTest

ghdl und gtkwave
Zur Nutzung der OpenSource Werkzeuge ghdl und gtkwave folgen hier die Schritte, um zu simulieren und sich die Ergebnisse anzusehen.
Auch hier wird davon ausgegangen, dass ein Unterverzeichnis work erstellt wurde (s.o.).

ghdl und gtkwave sind bereits auf den TAMS-Rechnern vorinstalliert. 

ghdl -a --workdir=work tlcWalk.vhd
ghdl -a --workdir=work tlcTest.vhd
ghdl -e --workdir=work tlcTest
ghdl -r --workdir=work tlcTest --vcd=tlctest.vcd
gtkwave tlctest.vcd

ghdl - Linux vs. Windows
Während ghdl wie oben beschrieben in der Linux Version alle internen Objekte in die Datei für gtkwave schreibt, gibt die Windows Version nur Bit-/Bitvector- und Integer Typen in Standard VCD-Dateien aus. Hier hilft ein internes Datenformat, mit dem dann auch eigene Aufzählungstypen (z.B. Zustandsvariablen von Automaten) ausgegeben werden: 
...
mingw32\bin\ghdl.exe -r --workdir=work tlcTest --wave=tlcTest.ghw
...
Windows Binaries (2.0-dev): zwar ist es mir jetzt nicht gelungen, die 64-bit Binaries von ghdl zum Laufen zu bringen (zusätzliche Compilerinstallation gcc scheint erforderlich), aber die 32-bit Version läuft ohne weiteren Aufwand.

Simulation von Netzlisten
Hier sind noch einmal die Besonderheiten aufgezählt, die beachtet werden müssen, wenn Netzlisten simuliert werden sollen. Entsprechend den beiden Walkthroughs "VHDL-Synthese" und "Simulation von Gatternetzlisten" beziehen sich die Angaben auf folgendes Szenario:
Zielbibliothek  AMS Standardzellprozess  c35b4
Synthesewerkzeug  Synopsys Design-Vision  ams_synopsys
Simulator  Cadence Xcelium  xmvlog / xmvhdl / xmelab / xmsim
Hier die Schritte, zur Simulation der synthetisierten Ampelschaltung tlcWalk.v, Timing tlcWalk.sdf
  1. Suchpfade der Gatterbibliotheken ergänzen 
    cat $tamsSW/ams/vhdlLib/xcelium/c35b4.add >> cds.lib
  2. Bibliotheken in der Simulationsumgebung tlcTest.vhd hinzufügen 
    library c35_corelib;
...
  3. Timescale-Direktive in die Verilog-Datei tlcWalk.v einbauen 
    `timescale 1ns/1ps
...
  4. Anpassen der Steuerdatei für die Timing-Annotation: netlist.sdf.cmd 
    COMPILED_SDF_FILE = "tlcWalk.sdf.X",
SCOPE = :tlcI,
LOG_FILE = "tlcWalk.sdf.log";
  5. Code übersetzen, Elaboration und Start der Simulation 
    xmsdfc tlcWalk.sdf
xmvlog -linedebug tlcWalk.v
xmvhdl -linedebug tlcTest.vhd
xmelab -access rwc -sdf_cmd_file netlist.sdf.cmd tlcTest
xmsim -gui tlcTest

Simulationsumgebung

Hardwarekomponenten

Remote auf Rechnern am Informatikum arbeiten

Die nachfolgenden Schritte beschreiben, wie man von seinem heimischen Rechner aus direkt auf Maschinen im Fachbereich arbeitet (mit grafischen Schnittstellen). Technisch gesehen, gibt es zwei Szenarien, wie GUI-Elemente auf dem eigenen Rechner dargestellt werden: X-forwarding oder VNC. Für beide werden hier die grundlegenden Schritte erläutert, die aber beide ein laufendes VPN voraussetzen.

Voraussetzungen

1. X-forwarding

auf dem eigenen Rechner
  1. xhost tams<nn>.informatik.uni-hamburg.de
    erlaubt dem TAMS-Rechner eine Verbindung zum eigenen X-Server.
  2. ssh -Y tams<nn>.informatik.uni-hamburg.de
    ssh Verbindung öffnen, am besten mit dem Start einer Shell, da man in der Regel ja mehrere Befehle eingeben will
in der SSH-Shell
  1. Hier kann jetzt ganz normal gearbeitet werden, wobei GUI-Elemente von gestarteten Programmen zum eigenen Rechner übertragen und dort dargestellt werden. Damit ist auch schon der Nachteil dieser Methode beschrieben. Da die Zeichenbefehle des TAMS-Rechners übertragen und lokal umgesetzt werden, ist, gerade bei langsamen Netzwerkverbindungen, der Bildaufbau sehr "zäh" und man kann zusehen wie Buttons einzeln gezeichnet werden.
  2. Nach dem Ende der Arbeit beendet man die Remote-Shell ganz normal mit exit.

2. VNC-Verbindung

Das VNC-Protokoll ist, ähnlich RDP bei Windows Systemen, eine Möglichkeit komplette Bildschirminhalte Remote darzustellen und den Rechner mit Tastatur und Maus fernzusteuern.
auf dem eigenen Rechner
  1. ssh -Y tams<nn>.informatik.uni-hamburg.de
    ssh Verbindung öffnen, Shell starten
in der SSH-Shell
  1. vncpasswd
    Vor den Start des VNC-Servers wird ein Passwort gesetzt.
  2. vncserver -geometry 1920x1080
    Auf dem Remote-Rechner wird ein VNC-Server gestartet. Dieser stellt eine sehr einfache X-Oberfläche bereit, mit der sich der eigene Rechner (im nächsten Schritt) verbinden kann.
auf dem eigenen Rechner
  1. vncviewer
    Nach Eingabe des Rechnernamens tams<nn>.informatik.uni-hamburg.de und Passworts öffnet sich ein Fenster in dem man mit dem Fenstermanager openbox arbeitet.
  2. zur Beendigung schließt man das Fenster, bzw. (besser) beendet den zuvor gestarteten vncviewer-Prozess.
in der SSH-Shell
  1. vncserver -kill :1
    In der Regel wird beim Start des VNC-Servers dieser automatisch mit Display :1 gestartet. Mit dem Kill wird der immer noch laufende Server beendet.
  2. Dann beendet man die Remote-Shell mit exit

3. SSH Tunnel über die rzssh1

Teilweise gab es Probleme mit der oben beschriebenen Verbindung zum VNC-Server (2. VNC-Verbindung), da viele verschiedene Faktoren das Systemverhalten beeinflussen: Linux-/Windows-Versionen, Firewallkonfigurationen etc. Als Alternative zu obiger Methode kann man auch ein einen SSH-Tunnel über die rzssh1.informatik.uni-hamburg.de laufen lassen, was in dieser Anleitung beschrieben ist.