Verifikation nachrichtentechnischer Systeme mit Systemsimulation

GI/ITG/GME Workshop, Paderborn 9.-11. März 1998, HNI-Verlagsschriftenreihe, Bd. 36, S. 175 -184
Verifikation nachrichtentechnischer Systeme mit
Systemsimulation und HW/SW-Cosimulation
Uwe Knöchel, Ulrich Tannert, Jürgen Haufe, Peter Schwarz
Fraunhofer-Institut für Integrierte Schaltungen,
Außenstelle EAS Dresden
Zeunerstraße 38, D-01169 Dresden
Zusammenfassung
Der Beitrag zeigt die Erfahrungen beim praktischen Entwurf und bei der Verifikation eines
Algorithmus zur Echokompensation und beschreibt dessen Abbildung auf eine Zielarchitektur.
Neben der Überprüfung der funktionellen Richtigkeit des Algorithmus stehen bei der Verifikation vor allem Untersuchungen zur benötigten Zahlengenauigkeit und zur erreichbaren Grenzfrequenz im Mittelpunkt. Um einen durchgängigen Designflow zu gewährleisten, haben wir
uns bereits bei der Systemverifikation für eine VHDL-Umgebung entschieden. Eine Bibliothek nachrichtentechnischer Standardbaugruppen vereinfachte den Einsatz eines VHDL-Simulators zur Systemsimulation. Zur deutlichen Erhöhung der Effizienz der verwendeten
kommerziellen Tools wurden Ergänzungstools entwickelt. Dazu zählen vor allem das Interface
des OAK-Debuggers zu VHDL-Simulatoren und das Waveformdisplay ADDA zur Darstellung analoger und digitaler Signalverläufe in einer Simulationsumgebung.
1
Einleitung
Moderne Systeme der Nachrichtentechnik zeichnen sich durch Komplexität und Vielgestaltigkeit ihrer Subsysteme aus. Analoge und digitale Signalverarbeitung, Filterfunktionen im NFund HF-Bereich sowie Kodier- und Dekodierverfahren zur Erhöhung der Übertragungsqualität
charakterisieren u.a. die Anforderungen an den Entwurf. Der Rechnereinsatz beim Entwurf
derartiger Systeme erfordert leistungsfähige Simulationsverfahren und flexible Modellierungsansätze. Neue Anforderungen ergeben sich bei Systemrealisierungen als HW/SW-Codesign.
Der Entwurf und die begleitenden Verifikationsschritte können eingeteilt werden in Systementwurf und Implementierung. Beim Systementwurf sind bei der Verifikation eines verwendeten Algorithmus Fragen wie funktionale Korrektheit, Stabilität und Genauigkeit zu betrachten.
Bei der Verifikation der Implementierung stehen neben Fragen der korrekten Abbildung des
entworfenen Systems in eine Realisierung vor allem die Untersuchung von Geschwindigkeit
bzw. Grenzfrequenz sowie die Leistungsaufnahme der gefundenen Implementierung im Vordergrund.
Im Beitrag wird exemplarisch die Verifikation eines Echocancelers [1] als einem typischen
nachrichtentechnischen System vorgestellt. Echocanceler werden zur Unterdrückung von
Echos u.a. im Modem eingesetzt. Für den Systementwurf wird als Systemmodell des Echocanceler eine Transversalfilterstruktur gewählt. Die Implementierung des Echocancelers erfolgt
als C-Code auf einem DSP (OAK-Architektur [11]). Für die Verifikation verwenden wir eine
VHDL-Simulationsumgebung. Wir zeigen, daß bereits auf Systemebene der Einsatz dieser
VHDL-Umgebung sehr gute Ergebnisse bei der Untersuchung typischer Systemeigenschaften
bringt. Die entworfene Softwarerealisierung des Echocancelers wird durch HW/SW-Cosimulation gemeinsam mit einem VHDL-Modell der HW-Umgebung verifiziert, in die der OAKProzessor eingebettet ist.
175
2
Verifikationsmethodik
Designflow und Verifikationmethodik
Die benutzte Verifikationsmethodik für ein System und der zugrunde liegende Designflow zur
Entwicklung eines Systems bedingen sich gegenseitig. Zusätzlich wird die Wahl von den verfügbaren Entwurfs- und Verifikationstools beeinflußt. Als Verifikationstools haben nach wie
vor Simulatoren die größte Bedeutung. Für den Entwurf und die Verifikation des Echocancelers verwendeten wir den Designflow aus Bild 1.
Entwurfsschritt
Verifikation
Systementwurf
Systemkonzept
cN(k)=cN(k-1)+a sign{e(k-1)*x(k-1)}
Echocanceler
Systemmodell
1/T
c0
1/T
c1
Systemsimulation:
1/T
c2
c3
Ptolemy,
COSSAP, SPW
+
VHDL-Simulator
(mit zusätzlichen
Bibliotheken)
HYBRID
NOISE
RAU_GAU
FALT
P3_FILE=ECHO03
Testbench
1
3
RESTECHO
ECHOCAN
ECHOCANCELER
Systemimplementierung
DSP-Code
HW/SWPartitionierung
HW/SWModell
DSP-Code
Code
RAM
Data
RAM
Source
Hybrid
HW/SWCosimulation
MMIO
Interface
OAK
Bild 1: Designflow und Verifikationsmethodik
176
WAIT
Controller
Display
Das Systemkonzept wird zunächst als simulierbares Systemmodell beschrieben [2]. Für die
System-Verifikation nachrichtentechnischer Systeme sind z.B. die Systemsimulatoren Ptolemy
[3], COSSAP [4] und SPW [5]) geeignet, die einen großen Modellvorrat für Anwendungen in
der Nachrichtentechnik besitzen. Die Verifikation der Systemimplementierung hingegen
erfolgt meist mit einem VHDL- oder VERILOG-Simulator (dynamische RTL- und Gattersimulation) und mittels statischer Timinganalyse. Im Interesse eines durchgängigen Designflows
haben wir auf o.g. Systemsimulatoren wie COSSAP und SPW verzichtet. Stattdessen wurde
die Verifikation für Systementwurf und Implementierung mit einem VHDL-Simulator untersucht. Damit wird eine doppelte Modellierung des Systems für unterschiedliche Simulatoren
vermieden. Für den Einsatz in der Nachrichtentechnik müssen die VHDL-Simulatoren jedoch
durch geeignete Modellbibliotheken ergänzt werden. Zusätzlich wird durch Verhaltensmodelle
eine Testumgebung (im Beispiel Source und Hybrid) modelliert. Die VHDL-Systemsimulation
gibt zu einem frühen Zeitpunkt Informationen über die Leistungsfähigkeit des gewählten
Systemkonzepts.
Nach der erfolgreichen Systemsimulation erfolgt die HW/SW-Partitionierung. Die Software
für den im Beispiel verwendeten DSP wird unter Verwendung des in der Systemsimulation
eingesetzten Verhaltensmodells manuell erzeugt, kann aber u.U. auch automatisch generiert
werden. Einige CAE-Systeme bieten dafür Werkzeuge an. Die HW/SW-Cosimulation gestattet
nun die Erprobung der gewählten Implementierung und gibt u.a. über das Timingverhalten
aufschluß. Die Testumgebung wird durch den Systemsimulator bereitgestellt und kann somit
wiederverwendet werden. Dem Entwickler werden komfortable Werkzeuge, wie Debugger
sowie analoge und digitale Waveform-Displays zur Verfügung gestellt.
VHDL-Systemsimulation
Die Modellierung des Systems als VHDL-Modell erfolgt unter Verwendung einer Bibliothek
mit Verhaltensmodellen nachrichtentechnischer Standardbaugruppen [7], [8]. Sie enthält u.a.
Modelle für Signalquellen, Übertragungskanäle, Modulatoren und Filter [9]. Damit können
alle Komponenten der Transversalfilterstruktur (vgl. Bild 4) und der Testbench im zugehörigen
VHDL-Modell durch jeweils ein Bibliotheksmodell ersetzt werden. Für Genauigkeitsuntersuchungen stehen Modelle einer parametrierbaren Festkommaarithmetik zur Verfügung, die eine
Festlegung der Wortbreite und des Integeranteils der Festkommazahl sowie das Rundungsund Überlaufverhalten der Operatoren erlauben. Mit diesem Systemmodell können die Einflüsse der Zahlengenauigkeit auf das Verhalten des ausgewählten Algorithmus effizient untersucht werden.
HW/SW-Cosimulation
Ziel der HW/SW-Cosimulation ist die Verifikation der OAK-Software im Wechselspiel mit der
Hardware, in die der OAK-Prozessor eingebettet ist. Schwerpunkt ist die experimentelle Ermittlung der Grenzfrequenz, die von den zur Verfügung stehenden Hardwareressourcen und dem erzeugten C-Code beeinflußt wird. Wie die Abarbeitung der Software in die HW/SWCosimulation einbezogen wird, hängt im wesentlichen von der Art des Prozessormodells ab [6].
Das Prozessormodell bestimmt entscheidend die Hardware/Software-Schnittstelle, die Art und
Weise der Softwareabarbeitung während der Simulation, die Simulationsperformance und Genauigkeit sowie die Beobachtbarkeit interner Zustände in Software und Hardware (HW- und
SW-Debugging).
Für die Verifikation des C-Codes für die OAK -Architektur wurde der kommerziell verfügbare
OAK-Simulator (Instruction Set Simulator) mit integriertem OAK-Debugger Oakdbg [12] mit
dem VHDL-Simulator Leapfrog durch ein bit- und taktgenaues Interface gekoppelt [10]. Die
Kopplung von Oakdbg mit Leapfrog erlaubt den gemeinsamen Test des entwickelten C-Codes
des Echocancelers zusammen mit einem VHDL-Modell seiner HW-Umgebung. Hauptvorteil
177
der Kopplung ist, daß der OAK mit seinem gesamten Bus-Timing als bitgenaues und taktzyklusgenaues Modell im Leapfrog-Simulator als VHDL-Komponente verfügbar ist. Die Komplexität des Gesamtsystems kann beherrscht und der Rechenzeitbedarf gesenkt werden, da der
Modellierungaufwand für den OAK-Prozessor reduziert wird. Der Vorteil vom OAK-Simulator/Debugger (hohe Simulationsgeschwindigkeit) und vom VHDL-Simulator (hohe TimingGenauigkeit) können gleichermaßen genutzt werden.
Gemischt analoge/digitale Waveformausgabe mit unserem Inhouse-Tool ADDA [14] und
simultane HW/SW-Debuggingmöglichkeiten erleichtern eine Verifikation und Fehlersuche
deutlich.
3
Der Echocanceler
3.1
Prinzip
Das Hauptproblem einer Vollduplexübertragung über eine Zweidrahtleitung ist das in der
Gabelschaltung (Hybrid) auftretende Übersprechen des Sendesignals auf das Empfangssignal.
Im Bild 2 ist das Übertragungssystem mit zwei Transceivern (A und B) und einem Kanal dargestellt.
Source
A
Sink
Sendesignal
Echocanceler
Restecho
Sink
Hybrid
Channel
Hybrid
Echocanceler
B
Source
Echo
Bild 2: Echokompensation bei einer Vollduplexübertragung
Bei nichtidealer Impedanzanpassung zwischen der Gabelschaltung und der angeschlossenen
Leitung wird ein Teil des Sendesignals der Station A in den eigenen Empfangszweig rückgekoppelt, im folgenden als Echo bezeichnet. Durch Einsatz des Echocancelers kann das zu
erwartende Echo geschätzt und vom Sendesignal der Station B subtrahiert werden. Während
der Adaptionsphase des Echocancelers ist das Sendesignal der Station B gleich Null, deshalb
genügt im folgenden die Betrachtung eines Transceivers (Teilsystem A im Bild 2). Für das
Schätzen des Echos stehen verschiedene adaptive Verfahren der digitalen Signalverarbeitung
zur Verfügung, die sich hinsichtlich Realisierungsaufwand und Genauigkeit unterscheiden [1].
Die erreichbare Genauigkeit hängt dabei sowohl vom verwendeten Algorithmus als auch von
Art und Wortbreite der auf der Zielhardware eingesetzten Arithmetik ab. Die Ressourcen der
Hardware bedingen außerdem die erreichbare Grenzfrequenz des Systems.
3.2
Zielarchitektur
Der OAK DSP Core [11] ist ein 16-Bit Festkomma-DSP für Telekommunikations-Anwendungen. Er kommt beispielsweise in Handy, Fast-Modems und Faxgeräten zum Einsatz. Für die
Verifikation von OAK-Applikationen werden neben Verilog- und VHDL-Modellen (RTL und
Gatter) der bereits genannte OAK-Instruction-Set-Simulator mit integriertem Debugger sowie
ein OAK-Emulator angeboten.
Der OAK-Kernel beinhaltet 4 parallele Execution Units (Computation Unit, Bit Manipulations
Unit, Data Addressing Arithmetik Unit, Program Control Unit). Durch die 4-stufige PipelineArchitektur werden die Instruktionen in minimaler Zykluszeit ausgeführt. Es können maximal
178
64K Datenspeicher (lokal und extern) und 64K Programmspeicher adressiert werden. Weiterhin stehen 4 externe Register als Nutzerinterface zur Verfügung. Außer Memory Mapped I/O,
bitseriellem I/O verfügt der OAK über Waitstate-Support, DMA und diverse Interrupts. Der
Clock-Generator erzeugt einen nichtüberlappenden 2-Phasentakt..
Clock
Phi 1
Phi 2
Sendesignal
SRC
External
Register
Data RAM
MMIO
Interface
Local RAM
DST
Echo
Restecho
Address Bus
Data Bus
Prog. Address
Code RAM
WAIT
Controller
OAK
Kernel
Prog. Data
Interrupt
serial I/O
OAK
Bild 3: Zielarchitektur des Echocancelers
Die Kommunikation zwischen OAK und Umgebungshardware erfolgt für den Echocanceler
über das MMIO-Interface (Memory Mapped IO)
3.3
Verifikation
Systemsimulation
Zur Verifikation des Echocancelers wird ein vereinfachtes Systemmodell (Bild 4) verwendet.
Das in der Gabelschaltung entstehende Echo ist im Hybrid-Modell durch ein Transversalfilter
modelliert. Für den Echocanceler wurde ebenfalls eine Transversalfilterstruktur gewählt, die
Filterkoeffizienten cN werden nach dem Signum-Algorithmus bestimmt. Als Stimulus x(k)
wurde Weißes Gaußsches Rauschen verwendet.
Sendesignal
Source
x(k)
Echocanceler
Restecho
1/T
c0
e(k)
1/T
c1
Hybrid
Echo
1/T
1/T
c2
a0
c3
1/T
a1
1/T
a2
a3
Echo-Pfad
Echocanceler
Übersprechen in der Gabelschaltung,
im Hybridmodell durch
Transversalfilter modelliert
Adaptive Koeffizientenschätzung
Signum-Algorithmus
cN(k)=cN(k-1)+α sign{e(k-1)*x(k-1)}
Bild 4: Systemsimulation des Echocancelers
179
Die Ergebnisse der Systemsimulation (Bild 5) zeigen den Einfluß der Festkommaarithmetik
auf das Verhalten des Echocancelers. Bei einem günstig gewählten Zahlenformat (a) kann das
Echo gut kompensiert werden. Nach einer Einschwingzeit von ca. 15 ms hat sich das adaptive
Filter ausreichend gut an die Schnittstelle Transceiver-Kanal angepaßt. Bei ungeeigneter Parameterwahl treten Überlauferscheinungen auf, die die Funktion des Algorithmus beeinträchtigen (b).
100
100
50
50
0
0
-50
-50
-100
-100
-150
0
0.005
0.01
0.015
0.02
0.025
t/s
0
0.005
0.01
0.015
0.02
0.025
t/s
b) Festkomma 16 Bit mit 8 Bit Integeranteil
a) Festkomma 16 Bit mit 9 Bit Integeranteil
Bild 5: Restecho der Systemsimulation
HW/SW-Cosimulation
Die Kopplung des OAK-Debuggers mit dem VHDL-Simulator Leapfrog erlaubt den gemeinsamen Test des entwickelten C-Codes mit einem Modell der späteren HW-Umgebung. Bild 6
zeigt den Aufbau der VHDL-Testbench zur Durchführung der HW/SW-Cosimulation.
Clock
Source
Hybrid
Phi 1 Ph 2
Sendesignal
SRC
Data RAM
External
Register
Local RAM
DST
MMIO
Interface
Echo
Restecho
Address Bus
Data Bus
Prog. Address
Code RAM
Echocanceler
C-Code
Prog. Data
Interrupt
serial I/O
OAK
Kernel
WAIT
Controller
OAK
VHDL
Display
VHDL
Bild 6: Testbench für die HW/SW-Cosimulation
Die HW/SW-Cosimulation erlaubt die Gesamtsimulation von SW- und HW-Komponenten und
schafft eine einheitliche Debug-Umgebung (Bild 7). Hauptvorteil ist die Darstellung des
Timingverhaltens von HW- und SW-Komponenten.
180
VHDL
Source
Hybrid
MMIO
Interface
VHDL-Debugger
OAK
WAIT
Controller
Display
-
Waveform-Display
ADDA-Display
OAK-Debugger
Bild 7: HW/SW-Cosimulation und Debugmöglichkeiten
Die Ergebnisse der HW/SW-Cosimulation (Bild 8) zeigen die experimentelle Bestimmung der
Grenzfrequenz des Echocancelers. Die Grenzfrequenz beschreibt die maximale Sample-Rate,
die die Implementierung verarbeiten kann. Bei Cosimulation unterhalb der Grenzfrequenz ist
die Ausführungszeit des Algorithmus auf dem OAK geringer als die Abtastzeit der Eingangssignale. Der OAK wartet, bis neue Daten zur Verfügung stehen. Dazu wird mit Hilfe des WAITControllers der OAK in den Wait-Zustand versetzt. Bis zum Erreichen der Grenzfrequenz
adaptiert der Algorithmus (a). Bei Überschreiten der Grenzfrequenz (b) kann der OAK nicht
mehr alle Daten verarbeiten, es kommt zum Auslassen von Samples und es erfolgt keine Adaption.
b) Sample-Rate größer als Grenzfrequenz
a) Sample-Rate kleiner als Grenzfrequenz
Bild 8: Restecho der HW/SW-Cosimulation
3.4
Ergebnisse
Die Verifikation des Echocancelers nach der vorgestellten Methodik erbrachte:
•
experimenteller Nachweis der funktionellen Korrektheit des Algorithmus
•
experimentelle Bestimmung der optimalen Wortbreite der Festkommaarithmetik
•
experimentelle Bestimmung der Grenzfrequenz von 12 kHz des Algorithmus auf der
zugrunde gelegten Zielarchitektur.
181
Es konnte durch Simulation gezeigt werden, daß die beabsichtigte Zielarchitektur geeignet ist,
die geforderten Systemparameter des Echocancelers zu erfüllen.
3.5
Rechenzeiten
In Bild 9 sind die Simulationszeiten für VHDL-Systemsimulation und HW/SW-Cosimulation
für den Echocanceler zusammengestellt. Zur Bewertung dieser Simulationszeiten wurden in
Bild 9 zusätzlich zur HW/SW-Cosimulation mit der beschriebenen Kopplung von Oakdbg mit
Leapfrog zwei weitere Rechenzeiten angegeben. So wurde an Stelle der o.g. Kopplung das
vollständige OAK-VHDL-Modell (RT-Ebene) in der Testbench verwendet. Weiterhin wurde
die Abarbeitungszeit des C-Codes des Echocancelers auf Oakdbg ohne VHDL-Kopplung
gemessen. Die dargestellten Rechenzeiten gelten für jeweils 100 Restechoberechnungen auf
einer SUN Sparc20 unter Verwendung von Leapfrog als VHDL-Simulator. Die Berechnung
eines Restecho benötigt in der Implementierung ca. 2500 OAK-Zyklen. Durch die hohe Simulationsgeschwindigkeit von Oakdbg werden bei der vorgestellten Kopplung von Oakdbg mit
Leapfrog deutlich geringere Simulationszeiten benötigt als bei der reinen VHDL-Simulation
mit dem OAK-VHDL-Modell.
Elapsed Simulation Time [sec]
4619
4000
1000
0
985
66
System
Simulation
8
HW/SW OAK VHDL
Cosimulation Modell
Oakdbg
Konfiguration
Bild 9: Vergleich der Rechenzeiten bei unterschiedlichen Konfigurationen
4
Implementierung des Cosimulators
Zur effektiven Durchführung der HW/SW-Cosimulation wurde der OAK-Simulator/Debugger
Okadbg mit dem VHDL-Simulator Leapfrog gekoppelt [10]. Der prinzipielle Aufbau des
Cosimulators ist in Bild 10 dargestellt. Beide Simulatoren laufen als getrennte Unix-Prozesse
auf einem Host. Die Kommunikation zwischen den Simulatoren erfolgt über semaphor-gesteuerte Shared-Memory-Zugriffe. Dadurch ist maximale Simulationsperformance erzielbar.
Im folgenden soll die Kopplung aus Leapfrog-Sicht und aus Oakdbg-Sicht erläutert werden:
Leapfrog-Sicht
Für die Simulation mit Leapfrog wurde die OAK-Entity als C-Modell implementiert mit folgenden Eigenschaften:
•
Pinorder wie VHDL RTL-Modell des Halbleiterherstellers [11]
•
taktzyklusgenaues und bitgenaues Interface
•
zulässige Signalwerte am OAK-Interface: 0,1,Z.
182
Innerhalb der Kopplung arbeitet Leapfrog als Master und Oakdbg als Slave, d.h. Oakdbg wird
von Leapfrog aufgerufen. Alle Inputs am OAK-Interface werden zuvor in den Shared Memory
übertragen und stehen Oakdbg zur Verfügung. Als Instruction Set Simulator interpretiert
Oakdbg je Aufruf genau eine OAK-Assemblerinstruktion. Dabei sich ergebende externe Ausgangssignale werden wieder über den Shared Memory an Leapfrog übergeben und im OAK CModell in entsprechende Leapfrog-Signalwerte umgewandelt.
Oakdbg-Sicht
Der OAK-Simulator besitzt eine offene C-Schnittstelle, die eine Kommunikation mit Drittprogrammen zu festgelegten Punkten innerhalb der Simulationsschleife gestattet. Zwei dieser
Kommunikationspunkte sind in Bild 10 mit PreFetch und PostExec dargestellt (Beginn und
Ende der Interpretation einer OAK-Instruktion). In PreFetch wartet Oakdbg auf die Freigabe
durch Leapfrog (Semaphor RunOak). Nach Freigabe durchläuft er bis PostExec die Simulationsschleife. Dabei generierte OAK-Interfacesignale werden im Shared Memory abgelegt.
Während dieser Zeit wartet Leapfrog (Semaphor OakReady). Nach PostExec beginnt der
Zyklus wieder von vorn. Der “reguläre” Ablauf wird durch Steuersignale am OAK-Interface
(Interrupts, Reset, Wait, Float, ...) beeinflußt.
RunOak
...
.... ....
PreFetch
Shared Memory
PostExec
....
OakReady
OAK
...
taktzyklus- und bitgenaues
Interface
Leapfrog
....
Oakdbg
Bild 10: Prinzip der Kopplung von Oakdbg und Leapfrog
5
Zusammenfassung und Ausblick
Wir haben im Beitrag die Erfahrungen beim praktischen Entwurf und bei der Verifikation eines
Algorithmus zur Echokompensation und dessen Abbildung auf eine Zielarchitektur vorgestellt.
Neben der Überprüfung der funktionellen Richtigkeit des Algorithmus standen bei der Verifikation vor allem Untersuchungen zur benötigten Zahlengenauigkeit und zur erreichbaren
Grenzfrequenz im Mittelpunkt. Um einen durchgängigen Designflow zu gewährleisten, haben
wir uns bereits bei der Systemverifikation für eine VHDL-Umgebung entschieden. Eine
Bibliothek nachrichtentechnischer Standardbaugruppen vereinfachte den Einsatz eines VHDLSimulators zur Systemsimulation. Zur deutlichen Erhöhung der Effizienz der verwendeten
kommerziellen Tools wurden Ergänzungstools entwickelt. Dazu zählen vor allem das Interface
des OAK-Debuggers zu VHDL-Simulatoren und das Waveformdisplay ADDA zur Darstellung analoger und digitaler Signalverläufe in einer Simulationsumgebung.
183
Bei der Systemsimulation komplexer Systeme, die aus einer Vielzahl von Subkomponenten
wie dem dargestellten Echocanceler bestehen, ist die Simulationsleistung der VHDL-Simulatoren zu gering. Ebenso ist der Umfang der angebotenen VHDL-Bibliotheken für nachrichtentechnische Komponenten im Vergleich zu angepaßten Simulatoren wie COSSAP und SPW
begrenzt. Aus diesem Grunde haben wir eine Schnittstelle zwischen COSSAP, Logiksimulatoren und Analogsimulatoren entwickelt [15], um für die Gesamtsimulation komplexer nachrichtentechnischer Systeme die jeweils adäquaten Tools und Bibliotheken nutzen zu können. Die
Einbeziehung von Instruction Set Simulatoren (mit Debuggern) wie Oakdbg in diese Entwurfsumgebung ist Ziel weiterer Arbeiten.
6
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
Literatur
Lee, E. A.; Messerschmitt, D. G.: Digital Communication. Kluwer Academic Publishers,
Boston, Dortrecht, London 1994
Jeruchim, M.C.; Balaban, P.; Shanmugan, K.S.: Simulation of Communication Systems.
Plenum Press, New York, London 1992
Lee, S.; Rabaey, J.: A Hardware-Software Cosimulation Environment. Proc. Int'l Workshop Hardware-Software Co-Design, 1993
COSSAP Overview and User Guide. Synopsys Inc., 1995
SPW - The DSP Framework. Designer/BDE User‘s Guide. Cadence Systems Inc., 1994
Rowson, J. A.: Hardware/Software Co-Simulation. Proc 31th ACM/IEEE DAC, 1994,
439-440
Garbe, H.; Kaminski, R.; Scholz, S.: Bibliothek nachrichtentechnischer Modelle,
Tagungsband zum Workshop „Modellierung und Simulation in der Nachrichtentechnik“.
Dresden, Nov. 1995
Knöchel, U.: Bibliothek mathematischer Grundfunktionen für die Simulation nachrichtentechnischer Systeme. Diplomarbeit, TU Dresden / FhG EAS Dresden 1994
Simm, U.: Modelldokumentation der VHDL-Modelle, FhG IIS/EAS Dresden 1996
Haufe, J.; Tannert, U.: Kopplung des Leapfrog/OAK-Debugger Oakdbg
Bericht FhG IIS/EAS Dresden 1997
DSP CORE SPCE, Siemens AG. 1995
User Manual OAKDBG, DSP Group Inc., 1996
Handbuch: Nachrichtentechnischer Simulator (NTS), Modelldokumentation der
KOSIM-Modelle, FhG IIS/EAS Dresden 1995
Haufe, J.; Winkler, F.: Frameworkeinbindung und Erweiterung des Ausgabetools
ADDA. Tagungsband zum Workshop „Modellierung und Simulation in der Nachrichtentechnik“. Dresden, Nov. 1995
Einwich, K.; Schwarz, P.; Trappe, P.; Zojer, H.: Simulatorkopplung für den Entwurf
komplexer Schaltkreise der Nachrichtentechnik. 7. ITG Fachtagung „Mikroelektronik
für die Informationstechnik“, Chemnitz, 18./19. März 1996, 139-144
184