Verifikation nachrichtentechnischer Systeme mit Systemsimulation
Transcription
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