Ein serieller Hochgeschwindigkeits Bus Controller ASIC

TAP – Ein universell einsetzbares
Analysewerkzeug für den Entwurf digitaler
Signalprozessoren
H. Nachtnebel1, N. Kerö1 und W. Kausel2
1
Technische Universität Wien, Institut für Allgemeine Elektrotechnik und Elektronik,
Gußhausstraße 27/359-10, A-1040 Wien
E-Mail: {nachtneb, keroe}@iaee.tuwien.ac.at
2
Universität für Musik und darstellende Kunst Wien, Institut für Wiener Klangstil,
Singerstraße 26, A-1010 Wien.
E-Mail: [email protected]
Abstract
Diese Arbeit beschreibt die Entwicklung eines universell einsetzbaren CADWerkzeugs zur Analyse und Verifikation von digitalen Signalprozessoren. Bei der
Entwicklung der Transfer Analysis Package wurde besonderes Augenmerk auf
den modularen Aufbau sowie die möglichst einfache Einbindung von unterschiedlichen Digitalsimulatoren gelegt. Es stehen Programme zur Signalgenerierung,
zur Datenkonversion sowie zur digitalen Datenanalyse im Zeit und Frequenzbereich zur Verfügung. Der Einsatz von TAP in der Entwicklung von Signalprozessoren wird an zwei Beispielen kurz beschrieben.
EINLEITUNG
Durch die rasante Entwicklung der Mikroelektronik hat sich die digitale Signalverarbeitung
gegenüber der analogen auf vielen Gebieten durchgesetzt. Die Halbleiterindustrie bietet
immer leistungsfähigere digitale Signalprozessoren (DSPs) an, für deren effizienten Einsatz
ausgereifte Entwicklungswerkzeuge wie Assembler, Debugger, Hochsprachencompiler und
Simulatoren zur Verfügung stehen. Um sowohl eine möglichst hohe Rechengeschwindigkeit
zu erreichen als auch die Vielseitigkeit des Prozessoren nicht einzuschränken, verfügen DSPs
über zum Teil sehr aufwendige Architekturen. Sie enthalten mehrere Datenbusse, parallele
Multiplizierer-Akkumulierer-Einheiten, sowie eigene Module für spezielle Operationen. Die
den Erfolg eines Produktes maßgeblich bestimmende Entwicklungszeit kann zwar durch den
Einsatz von Standard-DSPs entscheidend verkürzt werden, die Produktionskosten sind jedoch
im Vergleich zu einer applikationsspezifischen Lösung deutlich höher.
Falls die Produktionsstückzahlen es erfordern, wird daher statt eines DSPs ein eigener IC für
die Lösung einer digitalen Signalverarbeitungsaufgabe – ein sogenannter applikationsspezifischer digitaler Signalprozessor (ASSP) – entwickelt. Es wird eine auf die Applikation
optimierte Architektur entworfen und dadurch die den Preis maßgeblich bestimmende
Chipfläche im Vergleich zu Standard-DSPs wesentlich verringert. Der Entwurf von ASSPs
wird zwar durch moderne CAD-Programme immer besser unterstützt, erfordert aber
wesentlich mehr Entwicklungsschritte als die Programmierung eines DSPs. In Abb.1 ein
typischer Entwurfsablauf dargestellt.
5.) Gate Level
N li
4.) Silicon Compilation
Technologie
3.) RTL Beschreibung
Architektur
2.) Architektursynthese
1.) Systembeschreibung
Idee
Abb. 1 Entwurfsablauf eines ASSP
Zuerst wird der Algorithmus auf Systemebene beschrieben und durch Simulation verifiziert.
Anschließend wird eine geeignete Architektur entworfen und eine Beschreibung auf RegisterTransfer-Level (RTL) des ASSP erstellt. Dieser Schritt kann durch Synthese-Programme wie
den Behavioural-Compiler von Synopsys® zwar schon teilweise automatisiert werden, die
Ergebnisse sind jedoch denen erfahrener ASSP-Designer noch deutlich unterlegen. Die in
einer Hardware-Beschreibungssprache (Verilog oder VHDL) erstellte Architektur wird
neuerlich durch Simulation verifiziert. Mittels eines Silicon-Compilers wird eine Gate-LevelNetzliste erzeugt und der Entwurfsablauf mit dem automatischen Layout den ICs abgeschlossen. Selbstverständlich müssen auch die Ergebnisse aller automatisch durchgeführten
Entwurfsschritte mittels Simulation verifiziert werden.
Für die Überprüfung werden je nach Entwurfsschritt unterschiedliche Simulationsprogramme
verwendet. Im Idealfall wird die Korrektheit des Algorithmus (die Übereinstimmung mit der
Spezifikation) nur auf Systemebene manuell überprüft. In allen weiteren Schritten werden
lediglich die Simulationsergebnisse automatisch mit denen der Systemsimulation verglichen.
Dieser Ansatz ist in der Praxis aber nur selten anwendbar, weil ein Algorithmus für die
digitale Signalverarbeitung, je nach dem auf welcher Ebene man ihn beschreibt, unterschiedliche Anfangsbedingungen aufweist, die sich beispielsweise im Einschwingverhalten von
digitalen Filtern bemerkbar machen. Ein automatischer Vergleich von Simulationsergebnissen
wird dadurch sehr erschwert bzw. sogar teilweise unmöglich gemacht.
Für eine effiziente Verifikation wird daher statt der oben beschriebenen „bit-true“ Methode in
jeder Beschreibungsstufe lediglich überprüft, ob die Spezifikationen erfüllt werden („data
sheet compliant“). Im Rahmen dieser Arbeit wurde mit der Transfer Analysis Package (TAP)
ein Analysesystem entwickelt, das diese Art der Verifikation weitestgehend automatisiert. In
der Folge werden die Anforderungen an so ein System beschrieben und die einzelnen Programmgruppen sowie deren Aufbau vorgestellt. Schließlich wird an Hand von zwei Beispielen der Einsatz der TAP-Package im praktischen ASSP-Entwurf gezeigt.
ANFORDERUNGEN AN EIN ANALYSESYSTEM
Der Entwicklung von TAP ging eine eingehende Untersuchung des Programmpakets Ptolemy
[1] voraus. Die daraus gewonnene Erkenntnisse über die Unzulänglichkeiten von Ptolemy als
universelles Analyseprogramm für den ASSP-Entwurf waren ausschlaggebend, eine eigne
Entwicklung zu beginnen. Ptolemy ermöglicht es innerhalb einer graphischen Benutzeroberfläche ein Design auf Systemebene zu modellieren und sein Verhalten genau zu analysieren.
Ptolemy verfügt zwar über sehr ausgereifte Analysemethoden – es stehen Funktionen zur
Signalgenerierung, zur Signalauswertung im Zeit- und Frequenzbereich sowie zur
graphischen Darstellung zur Verfügung – hat aber folgende entscheidende Nachteile: Die
Verarbeitungsgeschwindigkeit ist einerseits im interpretierenden Modus (SDF-Domain) viel
zu langsam, andererseits ist auch der Übergang auf kompilierte C-Programme nicht ohne
größere Einschränkungen und Schwierigkeiten möglich. Schließlich ist die Einbindung
externer Simulatoren unzureichend unterstützt, weil der Benutzer für jeden Simulator eigene
Interfaceprogramme erstellen und in Ptolemy einbinden müßte.
Die Transfer Analysis Package erfüllt folgende Anforderungen:
Plattformunabhängigkeit
Moderne Digitalsimulatoren sind nicht mehr auf UNIX-Workstations beschränkt sind sondern
werden –wie zum Beispiel V-System von Model Technology – vermehrt unter Windows-NT®
angeboten. Es war daher unbedingt notwendige Forderung, daß alle Programme sowohl unter
UNIX als auch unter Windows-NT lauffähig sein müssen. Es wurde daher C++ als
Programmiersprache gewählt und soweit wie möglich auf betriebssystemspezifische Erweiterungen verzichtet.
Modularer Aufbau mit einheitlichem Struktur
TAP besteht aus eine Vielzahl von einzelnen Programmen die alle über ein einheitliches
Command-Line Interface verfügen. Der Datenaustausch zwischen den Programmen erfolgt
über Streams (stdin und stdout), wodurch „Pipes“ verwendet werden können. Dadurch ist es
nicht mehr notwendig, die Ergebnisse jedes Berechnungsschritts in zum Teil sehr großen
Dateien zwischenzuspeichern.
Leichte Erweiterbarkeit
Besonderer Wert wurde auf die leichte Erweiterbarkeit der Programmsammlung gelegt. Um
die Erstellung neuer Programme so weit wie möglich zu vereinfachen, wurde ein eigener
Command-Line Parser Generator entwickelt, auf den in der Folge noch kurz eingegangen
werden soll.
PARSER-GENERATOR FÜR DAS COMMAND-LINE INTERFACE
Für jedes Programm der TAP werden zum Teil zahlreiche Optionen benötigt. Als Beispiel
seien die Eingabeparameter des Signalgenerators stim aufgeführt:
Usage: stim [options] < infile > outfile
Options:
-help
-freq double
-adjust int
-periods int
-phase double
[Hz]
[rad]
generates this help screen
signal frequency (approximate)
adjust frequency for
0=any, 1=int, 2=odd
number of periods
number of signal periods in buffer
initial phase for sine wave
<act>
(1023.44 Hz)
(2)
<off>
(0 rad)
-lev double
-ovlev double
-vpeak double
-sample double
-dc double
-noise double
-step double
-Alaw
-Ulaw
-lin int
-square vpeak freq
double vpeak
double freq
-rep int
-len int
-extend int
-merge
-query
-info
-stat char*
[dBm0]
[dBm0]
[V|units]
[Hz]
[V]
[V]
[V]
signal level relative to vpeak
(0 dBm0)
overflow level corresponding to vpeak
(0 dBm0)
peak value (corresponding to 3.14/3.17 dB)(1 V|units)
sampling rate
(8000 Hz)
dc offset
(0 V)
white noise RMS (normal distributed)
(0 V)
ramp generator step
(0 V)
enable A-law quantiser G.711
<off>
enable U-law quantiser G.711
<off>
linear PCM representation
(0)
sqare wave
<off>
peak value
frequency
[times]
repeat each sample
(1 times)
[samples] buffer length
(1024 samples)
[samples] extend buffer length with settling time (0 samples)
merge (add) with data from standard input<off>
output actual frequency and periods
<off>
print actual settings to statistic
<off>
write program statistics to file
<off>
Neben einer Titelzeile und einer Programmbeschreibung müssen für ein TAP-Programm
folgende Elemente für jede Option definiert werden:
Name,
Typ der Argumente der Option,
Variablenname innerhalb des Programms,
Text, der die Option kurz beschreibt,
Text der die physikalische Einheit des Arguments beschreibt,
Funktionen zur Überprüfung der Eingabewerte der Option (zB. Wertebereich)
Initialisierung (default value)
Um die Bedienung zu vereinfachen, sollten alle Optionen abgekürzt werden können.
Es wurden einige Lösungen wie beispielsweise OPTGEN von Panagiotis Tsirigotis untersucht. Da von keinem Werkzeug alle Anforderungen erfüllt werden konnten, wurde ein
eigener Parser-Generator entwickelt. Für alle Programme werden die oben genannten Informationen in einer Beschreibungsdatei spezifiziert, mit der das Programm dsc2clp einen
vollständige Command-Line-Parser für ein TAP-Programm erzeugt. Für das oben genannte
Signalgenerator-Programm ist ein Teil der Beschreibungsdatei nachfolgend angeführt:
Beschreibung eines Programms in Textform
application Stim {
message "Testprogramm 1.0, Copyright (c) 1997 by BARRY. All rights reserved";
description "Dieses Programm erzeugt eine Schwingung und schreibt sie in die Ausgabedatei";
option Länge {
description "Gibt die Länge der Ausgabe an";
argument Buffer {
description "[Samples]";
type int;
}
}
option Amplitude {
description "Gibt die Amplitude der Schwingung an";
argument Value {
description "[Volt]";
type double;
}
}
}
Eine genaue Beschreibung des Parser-Generators ist in [2] zu finden. Es ist geplant, den
Parser-Generator als Public-Domain-Programm verfügbar zu machen.
ELEMENTE DER TAP
Die TAP besteht folgenden Gruppen von Programmen
Signalgeneratoren
Programme zur Modellierung analogen Schaltungsteile (zB: Σ∆-Wandler)
Datenkonversions- und Skalierungsprogramme
Programme für die Analyse im Zeitbereich (Digitale Filter: FIR, IIR, SINC...) [4]
Programme für die Analyse im Frequenzbereich (FFT und Fensterfunktionen [5])
Programme zur Datenauswertung und graphischen Darstellung (zB rms, plot)
Für die graphische Darstellung wurde unter Windows-NT das Programm gnuplot [3] unter
UNIX pxgraph [1] eingesetzt. Für den ASSP-Entwurf werden typischerweise weitere TAPProgramme zur Generierung von Daten oder zur Modellierung von analogen Komponenten
von Entwickler erstellt.
VERIFIKATION EINES MEHRKANAL-CODEC MITTELS TAP
Für einen mehrkanaligen Codec-ASIC für Telekommunikationsanwendungen wurde die
komplette Verifikation auf allen Entwurfschritten mittels TAP durchgeführt. Es wurden alle
Übertragungscharakteristika sowohl auf RTL-Ebene als auch auf Gate-Level mit einer Serie
von Einzelsimulationen verifiziert. Es waren dies unter anderem die Verzerrung als Funktion
der Aussteuerung und die relative Verstärkung als Funktion der Eingangsfrequenz. Für
letztere ist ein typisches Blockdiagramm in Abb. 2 dargestellt.
Sine Wave
Freq 1031.25 Hz
Clip
Remove DC
Remove Prolog
DUT
VHDL
Sigma Delta Modulator
Window
Psopho
Window
NUTALL
DFT
Band Pass Filter
300 - 3400Hz
Ideal Band Rej. Filter
1031.25Hz +/- 156Hz
Ideal Band Pass Filter
1031.25Hz +/- 156Hz
rms
rms
dB - dBref
Rms Noise
rms
dB - dBref
dB - dBref - Level
dB - dBref
dB - dBref - Level
Rms Selective
Rms Selective
Deviation
Rms Wideband
Rms Wideband
Deviation
Scale Factor
_
+
Distortion
Selective
_
+
Distortion
Wideband
Abb. 2 Verifikation eines ASSP mittels TAP
ENTWURF EINES ASIC FÜR EINEN KAPAZITIVEN WINKELSENSOR
Am Institut für Allgemeine Elektrotechnik und Elektronik der TU-Wien wurde ein neuartiger
kapazitiv messender Drehwinkelsensor entwickelt [6, 7]. Für den Einsatz im KFZ ist es aus
Kosten- und Zuverlässigkeitsgründen unbedingt notwendig, die komplette Elektronik zur
Ansteuerung und Auswertung in einen ASIC zu integrieren. Für diese Aufgabe wurde ein
eigener µController, der im Rahmen dieser Tagung vorgestellt wird [8], entworfen.
Um die Verifikation des Entwurfs zu vereinfachen, wurde TAP sowohl um ein Modell des
Sensors selbst als auch in der ersten Entwicklungsphase um ein C-Modell des Auswertealgorithmus erweitert. Weiters konnte der Einfluß von verschiedenen Dezimationsfiltern auf
das Ausgangssignal genau studiert werden. Sobald der Entwurf auf RTL-Ebene fertiggestellt
war, wurde zur Verifikation das C-Modell gegen den Verilog-Simulator ausgetauscht. Es
mußten lediglich die Ein- und Ausgangsdaten entsprechend formatiert bzw. skaliert werden.
ZUSAMMENFASSUNG
Mit der Transfer Analysis Package steht dem DSP- und ASSP-Entwickler ein sehr leistungsfähiges Werkzeug zur Verfügung, mit dem eine einheitliche Verifikation während aller
Entwurfsschritten durchgeführt werden kann. Durch den modularen Aufbau sowie die Möglichkeit, in einfacher Weise neue Module zu entwickeln, können selbst komplexe digitale
Systeme mit der TAP analysiert und verifiziert werden.
Es ist geplant, die TAP um ein graphisches User-Interface zu erweitern und dieses Werkzeug
anschließend mit allen Grundmodulen der Allgemeinheit als Public-Domain-Package zur
Verfügung zu stellen.
LITERATURVERWEISE
1. “Ptolemy: A Framework for Simulating and Prototyping Heterogeneous Systems”,
J. Buck, S. Ha, E. A. Lee, D. G. Messerschmitt, Int. Journal of Computer Simulation,
Jan. 1994
2. “Entwurf eines portablen Analysesystems für anwendungsspezifische Signalprozessoren”,
H. Nachtnebel, Diplomarbeit, TU-Wien, 1997.
3. “GNUPLOT – An Interactive Plotting Program”, T. Williams, C. Kelley, Version 3.5,
ftp://ftp.dartmouth.edu/pub/gnuplot, 1993
4. “Fast Algorithms for Digital Signal Processing”, R. E. Blahut, Addison-Wesley
Publishing Company, New York 1985
5. “Some Windows with Very Good Sidelobe Behavior”, A. H. Nuttall, IEEE Transactions
on Acoustics, Speech, and Signal Processing, Vol. ASSP-29, No. 1, pp. 84-90, Feb. 1981
6. “A Capactive Finger-Type Angular-Position and Angluar-Speed Sensor”, G. Brasseur,
Proceedings of the IMTC`98, May 18-20 1998
7. “A Measurement Algorithm for Capacitive Speed Encoder with a Modified Front-End
Topology”, T. Fabian and G. Brasseur, submitted for publication in IEEE Transactions
on Instrumentation and Measurement Technology.
8. “Ein skalierbarer µController-Core für die digitale Signalverarbeitung ”, H. Pommer, N.
Kerö und W. Kausel, Austrochip´98