MIN-Fakultät
Fachbereich Informatik
TAMS
UHH > MIN > Informatik > TAMS > Lectures > WS 2020 > Projekte > Mikrorechner Seitenende

Unterlagen

Vorlesungsunterlagen, Datenblätter & Dokumentation und diverse Links - thematisch sortiert. Die Liste wird im Lauf der Veranstaltung aktualisiert...

Aktuell | VHDL | EDA-Programme | Remote arbeiten

Aktuell

Allgemeines Material aus den Plenumsterminen: Foliensätze, Beispieldateien usw.

05.11.2020

VHDL

Allgemeine Dokumentation zu VHDL und Beschreibung der Syntax.

Links

EDA-Programme

EDA für Electronic Design Automation - Hier sind die Anleitungen zur Benutzung der Programme sowie Links zu deren Herstellern.
Hersteller und OpenSource
Intel FPGA (Altera)
Mentor Graphics: ModelSim
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  für die Simulation:  xmvhdl, xmvlog, xmelab, xmsim
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
Ein compilierender VHDL Simulator, auf gcc basierend. Anders als bei den kommerziellen Produkten gibt es keine (kaum) interaktive Simulation und auch die Debug-Möglichkeiten sind stark eingeschränkt. Wenn man aber eine Batch-Simulation laufen lassen kannn kann / will, bietet ghdl einen (fast) kompletten, schnellen VHDL Simulator.

Während freie Software früher immmer nur mit einem Teil der VHDL-Syntax zurechtkam, kann ghdl inzwischen den gesamten Sprachumfang - an einer Stelle hatte ich in meinem Beispiel Probleme (&-Operator, 'workaround' möglich).

Einschränkungen: wie oben schon angedeutet, funktioniert nur eine Batch-Simulation. Daraus ergibt sich:
  • Alle Stimuli müssen in der Simulationsumgebung definiert sein, als durch entsprechende Prozesse getrieben werden
  • Die Simulation muss terminieren, sprich keine neuen Events mehr erzeugen. Dies geht am einfachsten, wenn die VHDL-Prozesse zur Stimuli-Generierung am Ende auf ein finales wait; laufen. Alternativ dazu muss man sonst die Simulation mit dem Parameter --stop-time=... starten.
  • Signale können in eine Datei geschrieben und mit gtkwave (s.u.) analysiert werden. Ein Zugriff auf interne Variablen oder auf den sequenziellen Ablauf in Prozessen ist nur (wenn überhaupt) über Debug-Werkzeuge möglich.
Als Beispiel 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 0.36 auf TAMS-Rechnern mit Ubuntu 16.04 
ghdl -a --workdir=work tlcWalk.vhd
ghdl -a --workdir=work tlcTest.vhd
ghdl -e --workdir=work tlcTest
./tlctest --vcd=tlctest.vcd
gtkwave tlctest.vcd
ghdl 0.37 (aktuell) auf TAMS-Rechnern mit Ubuntu 18.04 
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

Hardware

Dokumentation zu den Hardwareeinheiten, der Prototypenplatine etc.

SRAM Speicher

Altera FPGA Prototypenplatine

Remote auf FBI-Rechnern 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