Arbeitsbereich Technische Aspekte Multimodaler Systeme

Unterlagen

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

Aktuell | VHDL | EDA-Programme | Hardware | Remote arbeiten

Aktuell

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

14.10.2021

Foliensatz: "Einführung", 1,9Mi pdf
Foliensatz: "Rechnerarchitekturen: ISA / Pipelining / Speicherhierarchie", 2,2Mi pdf
Foliensatz: "VHDL-Einführung / HDL-Übersicht", 476Ki pdf
introVHDL.tgz - Beispiele der VHDL-Folien und "Templates" für die Simulation

VHDL

Allgemeine Dokumentation zu VHDL und Beschreibung der Syntax.

"VHDL Kompakt", 558Ki pdf - die Syntax und viele VHDL Beispiele
introVHDL.tgz - Beispiele der VHDL-Folien und "Templates" für die 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

ein Unterverzeichnis work im aktuellen Verzeichnis anzulegen
die Dateien cds.lib und hdl.var in das aktuelle Verzeichnis zu kopieren

Hier die Schritte zur Simulation der Ampelschaltung aus den VHDL-Beispielen:

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:

...
....\bin\ghdl.exe -r --workdir=work tlcTest --wave=tlcTest.ghw
...

Windows Binaries (2.0-dev): bei mir funktionieren die 64-bit Binaries von ghdl nicht, bzw. sie erzeugen nur leere vcd/ghw-Dateien. Die 32-bit Version läuft; hier sind lokale Kopien [21.Okt.2021] der Archive

Hardware

Dokumentation zu den Hardwareeinheiten, der Prototypenplatine etc.

SRAM Speicher

sramSim.tgz enthält ein Simulationsmodell eines einfachen SRAM (ohne Timing). Über Dateiein- / -ausgabe kann der Speicher einfach initialisiert werden.

`sram1.vhd`	Simulationsmodell des Speichers - bidirektionaler-/Tristate-Datenbus
`sram2.vhd`	Simulationsmodell des Speichers - getrennte Lese- und Schreib-Datenbusse, sollte hier benutzt werden!
`instMem.dat`	Beispieldatei: Speicherinhalt
`procTest.vhd`	Beispieldatei: Benutzung

Dieses RAM dient erst einmal dazu, die Prozessorhardware mit einem ersten (einfachen) Simulationsmodell zu versorgen. Später, bei der weiteren Umsetzung auf die Prototypenplatine, wird der Speicher dann durch quartus generierte Modelle ersetzt.

Altera FPGA Prototypenplatine

"DE0-Nano User Manual" ist das Manual zu der Prototypenplatine. In den nachfolgenden Archiven ist es jeweils auch in dem Unterverzeichnis doc enthalten.
de0Board.tgz enthält die Templates um die Platine für eigene Entwürfe zu benutzen: de0Board.xxx. In dem Verzeichnis doc stehen die Manuals und die Datenblätter der Komponenten.
de0cDisplay.tgz ist ein Beispiel zur Ansteuerung des LCD (Character-) Displays und kann als Ergänzung des eigenen Entwurfs integriert werden.
memory.tgz enthält Beispiele für RAM und ROM, jeweils mit 10-bit Adressen (ja Eure Entwürfe können natürlich mehr) und 32-bit Wortbreite. Interessant sind die mif-Dateien, die die initialen Werte RAM, bzw. die Inhalte ROM, vorgeben. Die müsst Ihr an eigene Entwürfe anpassen!
Die ROM/RAM-Speicher werden von Altera quartus aus generiert: IP Catalog dann Library - Basic Functions - On Chip Memory.
de0-mikrorechner.tgz Beispielprojekt für den kompletten 32-bit Prozessor: alle Projektdateien für die RT-Level Simulationen (sramSim), den Quartus Speicher (memory), die Platine mit dem Display (cDisplay) und das top-level Quartus Projekt (de0Board).
Es fehlen "nur noch" die Dateien des eigenen Prozessors, siehe README...
20-altera.rules Udev Regeln für Linux Systeme, damit normale Benutzer Zugriff auf die USB-Blaster haben. Unter /etc/udev/rules.d abzulegen.

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).

Voraussetzungen

Im Nachfolgenden wird allerdings ein Linux vorausgesetzt. Außerdem muss VNC-Client Software installiert sein, beispielsweise in Ubuntu-Systemen: xvnc4viewer oder remmina mit entsprechendem Plugin.
Bei Windows Systemen muss man differenzieren, welche Services und Protokolle genutzt werden sollen.
- SSH-Verbindung: ist direkt mit "Bordmitteln" von Windows möglich: Eingabeaufforderung / Power-Shell
- 1. X-Forwarding: hier braucht man Software, die einen X-Server bereitstellt - Tipp: SmarTTY oder MobaXterm, beides sind kommerzielle Produkte, für die aber eine Privat-/Testnutzung möglich ist.
- 2. VNC-Client: es gibt zahlreiche Programme für Windows, wie: TightVNC, RealVNC, UltraVNC ...
Aufbau einer VPN-Verbindung
Da der Fachbereich von extern nur über einen einzigen Rechner zugänglich ist (rzssh1.informatik.uni-hamburg.de), sollte dieser nicht für ein Login genutzt werden (Bottleneck!), sondern ein VPN gestartet werden, Beschreibung unter: https://www.inf.uni-hamburg.de/inst/irz/it-services/private-devices/vpn-clients.html
Laufende Rechner bei TAMS: für X- oder VNC-Verbindungen sind folgende Rechner erreichbar.
tams191, tams192 ... tams199
Wegen Updates-/Sicherungen etc. kann es sein, dass einzelne Rechner kurzfristig nicht erreichbar sind, dann sollte man den Nächsten probieren.
Tipp: nach dem Einloggen mit who nachsehen, wie viele andere Nutzer auf den Maschinen sind, so dass sich nicht alle auf einem PC "drängeln".
ACHTUNG: seit dieser Woche (03.11.2021) sind die Rechner so konfiguriert, dass Ihr nach dem Einloggen mit einem lokalen Verzeichnis arbeitet. Das ist deutlich schneller als die Dateien auf dem Dateiserver zu nutzen, hat aber auch zur Folge, dass
- es keine Backups gibt!
- beim nächsten Login auf einem anderen Rechner, die Daten nicht da sind!
Wenn ihr euch eingeloggt habt, ist das Login-Verzeichnis des Informatik-Dateiservers unter infhome erreichbar. Für die praktische Arbeit solltet man also
- entweder (wie vorher) direkt auf dem Dateiserver arbeiten: cd infhome
- oder die Daten vorher, bzw. hinterher kopieren, z.B.: rsync -av infhome/sourceDir .
  bzw. rsync -av sourceDir infhome

Realisierung

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 immer ein laufendes VPN (s.o.) voraussetzen.

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 -l <username> 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 -l <username> 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.

`ams ldv`	für die Simulation:	xmvhdl, xmvlog, xmelab, xmsim
`alt`	für den FPGA Entwurf:	quartus