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
- Blatt 1 "Schaltnetze und Schaltwerke - Simulation" (112Ki pdf)
- Blatt 2 "Schaltnetze und Schaltwerke - Synthese" (98Ki pdf)
- Blatt 3 "Entwurf einer Weckuhr" (112Ki pdf)
- Blatt 4 "Eine DCF77 gesteuerte Weckuhr" (215Ki pdf)
VLSI-Entwurf
- "VLSI- und Systementwurf / Methoden und Werkzeuge" Foliensatz, 59 Seiten (1,1Mi pdf).
VHDL
- "VHDL Kompakt" - die Syntax und viele VHDL Beispiele, 124 Seiten (569Ki pdf).
- "VHDL-Einführung / HDL Übersicht" Foliensatz, 70 Seiten (475Ki pdf).
- VHDL-Beispiele aus dem Foliensatz und "Templates" zu den Aufgabenblättern
- 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
- "VHDL-Synthese" (1,2Mi pdf)
- "VHDL- und mixed-mode Netzlistensimulation" (165Ki pdf)
- 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 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
- 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
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 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
Simulationsumgebung
- Für die Simulation der fertigen Uhr, noch ohne DCF77, gibt es mit tstClock3.vhd eine Simulationsumgebung, die Alarm- und Uhrzeit stellt, den Alarm aktiviert und simuliert, bis der Alarm angeht.
- In den Templates des Praktikums vlsiPrak.tgz, bzw. der Hardware dcfClock.tgz, ist eine Simulationsumgebung tstClock.vhd enthalten, die den gesamten Entwurf simuliert (s.u.).
Hardwarekomponenten
- Die Implementation des DCF-Weckers erfolgt auf einer Altera Prototypenplatine: DE0-Nano. Entsprechend den Praktikumsaufgaben 3 und 4 wurde eine kleine (externe) Platine erstellt, die an die FPGA-Platine angeschlossen werden kann.
- dcfClock.tgz ist ein
Archiv, das für einen Entwurf gemäß Aufgabenblatt 4 zwei Arten
"Wrapper" bereitstellt.
- In dem Verzeichnis simRT ist mit tstClock.vhd eine Simulationsumgebung vorgegeben, die eine relativ umfangreiche Simulation steuert: Alarmzeit und Uhrzeit einstellen, Alarm aktivieren, Synchronisation mit DCF-Signal von dcf77.vhd, Auslösen und Abschalten des Alarms.
- Die Dateien auf Hauptebene de0Board.xxx implementieren den DCF-Wecker mit Hilfe der Prototypenplatine. Das vordefinierte Quartus-Projekt de0Board bildet die Signale des eigenen Entwurfs auf die Anschlüsse der Hardware ab.
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
- 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
- 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.
- 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
1. X-forwarding
auf dem eigenen Rechner
- xhost tams<nn>.informatik.uni-hamburg.de
erlaubt dem TAMS-Rechner eine Verbindung zum eigenen X-Server. - 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
- 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.
- 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
- ssh -Y tams<nn>.informatik.uni-hamburg.de
ssh Verbindung öffnen, Shell starten
in der SSH-Shell
- vncpasswd
Vor den Start des VNC-Servers wird ein Passwort gesetzt. - 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
- 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. - zur Beendigung schließt man das Fenster, bzw. (besser) beendet den zuvor gestarteten vncviewer-Prozess.
in der SSH-Shell
- 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. - Dann beendet man die Remote-Shell mit exit