DE19914695A1 - System und Verfahren zum Entwickeln eines Codes zur Ausführung durch einen digitalen Signalprozessor - Google Patents

Abstract

Ein Code-Entwicklungssystem zum Entwickeln eines Codes für die Ausführung durch einen digitalen Signalprozessor (DSP), der eine Schaltung zum Durchführen einer Festkomma-Arithmetik aufweist, umfaßt eine Bibliothek mit mehreren ersten Variablentypen, welche Festkomma-Funktionen entsprechen, die numerische Ergebnisse erzeugen, welche gleich numerischen Ergebnissen sind, die von einer Festkomma-Schaltung in dem DSP erzeugt werden. Die Bibliothek umfaßt ferner mehrere zweite Variablentypen, die Gleit-Komma-Funktionen entsprechen, welche den ersten Variablentypen zugeordnet sind, um gewünschte numerische Ergebnisse während der Code-Entwicklung vorzusehen. Das Code-Entwicklungssystem umfaßt einen Compiler, der auf den Entwicklungscode anspricht, um einen Entwicklungsobjekt-Code abhängig von den ersten Variablentypen und den zweiten Variablentypen zu erzeugen. Dann werden Testdaten an den Entwicklungsobjekt-Code geschickt, der mit den ersten und den zweiten Variablentypen erzeugte Daten vorsieht. Diese Ergebnisse können untersucht werden, und der Code kann verändert werden, um die mit den ersten Variablentypen erzeugten Daten näher an die gewünschten Daten zu führen, die mit den zweiten Variablentypen erzeugt werden.

Description

Ein Teil der Offenbarung dieser Patentanmeldung enthält Material, das dem Urheberrechts­ schutz unterliegt. Der Inhaber des Urheberrechts hat keine Einwände gegen die Vervielfälti­ gung der Patentanmeldung oder Patentoffenbarung durch Dritte, so wie sie in den Patentakten oder Aufzeichnungen des Patent- und Markenamtes erscheint, behält sich jedoch jedes wei­ tergehende Urheberrecht vor.

Die Erfindung betrifft im allgemeinen das Gebiet der digitalen Signalprozessoren und spezi­ eller die Entwicklung eines Codes, der von solchen Prozessoren ausgeführt wird.

Viele Computeranwendungen enthalten rechenintensive Operationen, die leistungskritisch sind. Viele Bild- und Sprachverarbeitungsanwendungen müssen z. B. rechenintensive Opera­ tionen, wie eine Filterung, in Echtzeit ausführen. Im allgemeinen verwenden solche Anwen­ dungen einen digitalen Signalprozessor (DSP). Wie allgemein bekannt ist, realisieren DSPs Befehle, die für digitale Signalverarbeitungsanwendungen besonders brauchbar und effizient sind. Ein Beispiel eines DSP ist die TMS320-Serie der von Texas Instruments erhältlichen DSPs. Zusätzlich zu spezialisierten DSPs enthalten bestimmte Allzweck-Mikroprozessoren DSP-artige Befehle, wie den MMX-Befehl, der von bestimmten Prozessoren aus der Pentium­ reihe der von der Intel Corporation erhältlichen Prozessoren realisiert sind.

Traditionell erforderte die Entwicklung von Anwendungen, die auf einem DSP effizient lau­ fen, Software-Entwickler mit großer Erfahrung auf den Gebieten der Assembler-Sprache und der anspruchsvollen numerischen Analyse. Die Entwicklung von höheren Sprachen und com­ puterunterstützte Software-Entwicklungswerkzeuge (CASE-Werkzeuge; computer-aided software engineering) hat die Entwicklung von DSP-Programmen in gewisser Weise verein­ facht. Compiler für Programmiersprachen, wie C, erleichtern die Entwicklung von DSP-Codes, indem sie die Notwendigkeit reduzieren oder sogar eliminieren, daß der Programmie­ rer einen bestimmten DSP in einer Assembler-Sprache programmieren können muß. CASE-Werk­ zeuge, wie das Produkt Simulink, das von der MathLab Corporation erhältlich ist, bieten eine Prototyp-Werkbank für die Entwicklung eines DSP-Codes sowie für den Entwurf von Algorithmen.

Solche Werkzeuge befassen sich jedoch nicht mit einem sehr schwierigen Teil des Entwurf­ prozesses - der Verwaltung der Festkomma-Arithmetik. Die Entwicklung von Programmen, welche Festkomma-Fähigkeiten eines DSP effizient nutzen, um numerisch präzise Ergebnisse innerhalb der notwendigen Zeitgrenzen zu erzeugen, ist ein entscheidender Aspekt der DSP-Pro­ grammentwicklung, und sie ist eine der schwierigsten Aufgaben, vor denen DSP-Pro­ grammierer stehen. Eine weitere schwierige Aufgabe ist die Entwicklung von Anwendun­ gen, welche Gleitkomma-Arithmetik verwenden, wenn die Wortlänge des zugrunde liegenden DSP kürzer ist, als erwünscht sein könnte.

In vielen Anwendungen ist es nicht notwendig, die Besonderheiten der Festkomma- Mathematik zu verstehen. Die Verwendung von Gleitkomma-Bibliotheken in solchen An­ wendungen, um einen Gleit-Schaltkreis in einem DSP auszunutzen, vereinfacht die Code- Entwicklung und ist eine akzeptable Lösung. DSPs mit umfangreicher Gleit-Schaltung kosten im allgemeinen mehr als solche ohne diese Unterstützung. Ferner benötigen Gleit- Operationen mit derselben Hardware-Ausstattung mehr Zeit als Festkomma-Operationen. Diese Lösung ist daher nicht akzeptabel, wenn die Anwendung in Echtzeit mit der schnellst­ möglichen Geschwindigkeit oder der kostengünstigsten Hardware-Ausstattung laufen muß. Die Entwicklung von Anwendungen für DSPs fordert in solchen Fällen entweder einen sehr langen Entwicklungsweg oder die Dienste eines schwer zu findenden, besonders erfahrenen DSP-Code-Entwicklers. Hieraus ergeben sich hohe Entwicklungskosten für DSP-An­ wendungen. Es wird daher eine Entwicklungsumgebung benötigt, welche die Entwicklung des DSP-Codes vereinfacht.

Diese Aufgabe wird durch ein System mit den Merkmalen von Anspruch 1 bzw. 2 sowie durch ein Verfahren mit den Merkmalen von Anspruch 3 gelöst.

Gemäß eines Hauptaspekts der Erfindung wird die Code-Entwicklung für einen geplanten DSP (Ziel-DSP; target DSP) mit Hilfe einer Code-Bibliothek verbessert, die Festkomma- Funktionen mit zugehörigen Gleit-Funktionen vorsieht, welche die Festkomma-Funktionen widerspiegeln (shadow). Die Festkomma-Funktionen liefern Ergebnisse, die präzise mit de­ nen übereinstimmen, welche von dem geplanten DSP vorgesehen werden. Die Gleit- Funktionen liefern numerisch präzise Ergebnisse, die als Benchmark-Ergebnisse für den Ver­ gleich mit den Ergebnissen verwendet werden können, die von der Festkomma-Bibliothek vorgesehen werden. Der Code für den geplanten DSP kann dann modifiziert werden, um prä­ zisere Ergebnisse aus den Festkomma-Bibliotheken vorzusehen.

Ein Vorteil bestimmter bevorzugter Ausführungsformen ist, daß die Code-Erzeugung für die Ausführung durch die Festkomma-Schaltung eines DSP vereinfacht wird, indem ein schneller und einfacher Vergleich zwischen gesuchten numerischen Ergebnissen und tatsächlichen Er­ gebnissen, die mit dem Code auf dem geplanten DSP erzeugt werden, vorgesehen wird. Der geplante oder Ziel-Code kann dann schrittweise modifiziert werden, um Ergebnisse zu erhal­ ten, die näher bei den gewünschten Ergebnissen liegen. Wenn davon ausgegangen werden kann, daß der Code akzeptable Festkomma-Ergebnisse liefert, wird der Code neu compiliert, um nur Festkomma-Code zu enthalten. Die Gleit-Funktionen sowie die Debug-Funktionen (für die Fehlersuche) bilden daher keinen Teil des letztendlich erzeugten Codes. Die Code- Entwicklung wird daher einfacher und ermöglicht kürzere Entwicklungszeiten, was zu niedri­ geren Entwicklungskosten führt. Die gesamten, immer wieder auftretenden Systemkosten werden ebenfalls reduziert, weil es einfacher ist, die kostengünstigste Hardware zu verwen­ den, die für eine bestimmte Anwendung benötigt wird.

Diese sowie weitere Merkmale und Vorteile der Erfindung ergeben sich deutlicher aus der folgenden detaillierten Beschreibung bevorzugter Ausführungsformen mit Bezug auf die Zeichnungen. In den Figuren zeigen:

Fig. 1 ein Blockdiagramm einer bevorzugten Ausführungsform, welche die Grundsätze der Erfindung umsetzt; und

Fig. 2 weitere Einzelheiten von Teilen der in Fig. 1 gezeigten Ausführungsform.

Das in Fig. 1 gezeigte Entwicklungssystem 100 erleichtert die Entwicklung eines geplanten oder Zielcodes 102 zur Ausführung durch ein geplantes oder Zielsystem 104. Das Zielsystem 104 umfaßt ein DSP 106, der den Zielcode 102 ausführt, welcher in einem Speicher 108 ge­ speichert ist. Das Zielsystem 104 umfaßt üblicherweise auch eines oder mehrere Eingabe- und Ausgabegeräte (nicht gezeigt). Das Entwicklungssystem 100 ist vorzugsweise als eines oder mehrere gespeicherte Programme realisiert, die von einem digitalen Allzweckcomputer aus­ geführt werden. Von einem Programmierer, der das Entwicklungssystem 100 verwendet, ein­ gegebene Eingaben 110 erzeugen einen Entwicklungs-Sourcecode 112. Die Eingabe des Ent­ wicklungs-Sourcecodes 112 kann auf herkömmliche Weise ausgeführt werden, z. B. mit Hilfe eines herkömmlichen Texteditors, der die Eingabe, Anzeige, Wiedergewinnung und Speiche­ rung von Daten erlaubt. Der Entwicklungsobject-Code 128 wird von einem Compiler 114 über eine Bibliothek 118 erzeugt. Der Zielcode 102 wird von einem Compiler 115 über eine Bibliothek 116 erzeugt. Der Compiler 114 erzeugt auch Code-Entwicklungsinformation 120, welche Debug-Information umfaßt, die zum Debuggen (Fehlersuche) und Analysieren des Entwicklungscodes 112 nützlich ist. Die Debuginformation kann an ein Ausgabegerät 122 ausgegeben werden, z. B. an einen herkömmlichen Computerbildschirm, damit sie von einem Programmierer untersucht und beurteilt werden kann.

Die Bibliothek 116 sieht vorzugsweise Festkomma-Funktionen 124 vor, die von dem Compi­ ler 115 verwendet werden, um den Zielcode 102 zu erzeugen. Die Bibliothek 116, die hier als Runtime Class Library (RCL; Laufzeit-Klassen-Bibliothek) bezeichnet wird, enthält Fest­ komma-Funktionen 124 zum Realisieren variabler Typen, die genau wie der DSP 106 in dem Zielsystem 104 arbeiten. Die RCL 116 kann z. B. den Typ einer vorzeichenbehafteten Bruch­ variablen mit 16 Bit und einem Bereich -1 < = X < 1 enthalten. Mit anderen Worten liegt das binäre Komma zwischen dem Vorzeichen-Bit und den 15 niedrigeren Bits. Typischerweise werden Daten in einem 16-Bit-Festkomma-DSP auf diese Weise dargestellt. Bei einem sol­ chen Variablentyp sind kleine Zahlen (z. B. kleiner als 1/256) aufgrund des Rundens übli­ cherweise ungenau. Große Zahlen gehen üblicherweise entweder in die Sättigung (werden zu ± 1) oder laufen um, abhängig von dem genauen Typ des DSP 106. Durch solche Varia­ blentypen erzeugte Fehler können nach einer Reihe von Operationen mit einer bestimmten Variablen dramatisch zunehmen, so daß die Genauigkeit sinkt, mit der die Zielanwendung arbeitet.

Eine Bibliothek 118, die hier als Prototyp Class Library (PCL; Prototyp-Klassen-Bibliothek) bezeichnet wird, enthält Festkomma-Funktionen, von denen eine bei 125 gezeigt ist, die gleich den Festkomma-Funktionen 124 in der RCL 116 sind. Zu jeder Festkomma-Funktion 125 gehört eine Gleit-Funktion 126, um numerisch präzise Ergebnisse für mathematische Operationen zu liefern, die mit dem Entwicklungscode 112 realisiert werden. Der Compiler 114 erzeugt vorzugsweise einen Entwicklungsobject-Code 128, der mathematische Operatio­ nen, die in dem Entwicklungs-Sourcecode 112 enthalten sind, sowohl in Festkomma-Form als auch in Gleitkomma-Form realisiert. Die Gleitkomma-Funktionen 126 werden "begleitet" (shadowed) von Festkomma-Funktionen 125 oder diesen zugeordnet, um mit dem Compiler 114 automatisch einen Gleitkomma-Code zu erzeugen, der hochpräzise numerische Werte erzeugt, die als Fixpunkte (benchmarks) verwendet werden, mit den der Festkomma-Code verglichen werden kann. Die Differenzen zwischen den numerischen Werten, die von diesen Gleitkomma- und Festkomma-Komponenten des Entwicklungsobject-Codes 28 erzeugt wer­ den, werden von einem Fehlermodul 130 auf eine Weise erzeugt die anhand von Fig. 2 näher erläutert wird.

Fig. 2 zeigt in Form eines Blockdiagramms den Ablauf des Entwicklungsobjekt-Codes 128. Wie gezeigt umfaßt der Entwicklungsobjekt-Code 128 Festkomma-Funktionen 204 und be­ gleitende Gleitkomma-Funktionen 206. Die Festkomma-Funktionen 204 werden mit Hilfe der Festkomma-Bibliothek 125 erzeugt, und die Gleitkomma-Funktionen 206 werden mit Hilfe der Gleitkomma-Bibliothek 126 erzeugt. Wenn der Entwicklungsobjekt-Code 128 erzeugt ist, werden Testdaten 202 zu dem Code 128 geführt, um Festkomma-Ergebnisse 208 und Gleit­ komma-Ergebnisse 210 vorzusehen, die weiterverwendet werden, um die Funktionsfähigkeit und Genauigkeit des Codes 128 zu ermitteln. Dies erfolgt vorteilhaft mit den Modulen 120 und 130. Das Debug-Informationsmodul 120 liefert Information, die bestimmte Aspekte des Codes 128 angibt. Das Modul 120 umfaßt z. B. Flags (Marken), wie Flags für die Sättigung und den Umlauf (wrap-around). Es werden auch Flags vorgesehen, um einen Unterlauf und einen Überlauf anzuzeigen. Die Debug-Information 120 umfaßt vorzugsweise auch eine va­ riable Historie, z. B. die letzten einhundert Werte für einige oder alle Variablen, sowie Flags für die Häufigkeit der Verwendung einer oder mehrerer Variablen.

Das Fehlermodul 130 erzeugt vorteilhaft Werte, welche Differenzen zwischen bestimmten Variablen im Code 128 angeben, der von den Festkomma-Funktionen 204 und den begleiten­ den Gleitkomma-Funktionen 206 erzeugt wird. Zu diesen Werten gehören ein momentaner Fehlerwert für jede Variable, der einen momentanen Fehler zwischen einer Festkomma- Variablen und einer entsprechenden Gleitkomma-Variablen angibt, sowie ein histori­ scher/mittlerer Fehler für jede Variable, der einen quadratischen, mittleren (RMS) Fehler zwi­ schen einer Festkomma-Variablen und einer entsprechenden Gleitkomma-Variablen angibt.

Solche Fehlerwerte für jede der Variablen werden dann als Debug- und Prüfinformation über den Ausgang 122 vorgesehen, damit der Programmierer sie beurteilen kann. Der Programmie­ rer kann darin den Entwicklungscode 112 modifizieren, damit die Festkomma-Bibliothek 116 Festkomma-Ergebnisse 208 erzeugt, die näher bei den begleitenden Gleit-Ergebnissen 210 liegen. Diese Prozedur wird vorzugsweise iterativ ausgeführt, bis die Festkomma-Ergebnisse 208 als akzeptabel angesehen werden. In diesem Fall wird der Compiler 115 dazu verwendet, den Zielcode 102 mit Hilfe der RCL 116 aus dem Entwicklungscode 112 zu erzeugen.

Die Bibliotheken 116 und 118 sind vorzugsweise in einer objektorientierten Programmier­ sprache, wie C++, realisiert. Eine solche Ausführungsform nutzt die Kapselungs- und Verer­ bungsmerkmale aus, welche die meisten objektorientierten Programmiersprachen aufweisen. Festkomma-Funktionen 125 der PCL 118 sind jeweils als ein Objekt realisiert, das zugeord­ nete oder begleitende Gleitkomma-Funktionen 126 enthält. Den Festkomma-Funktionen 125 ist daher jeweils eine eingekapselte Gleitkomma-Funktion zugeordnet, die von dem Compiler 114 automatisch zu Gleitkomma-Funktionen 206 umgewandelt werden, um Gleitkomma- Ergebnisse 210 zu erzeugen.

Der Compiler 114 hat vorzugsweise die Form eines herkömmlichen C++-Compilers. Vorteil­ haft müssen an dem Compiler 114 aufgrund der Art, wie die PCL 118 realisiert ist, keine Mo­ difikationen vorgenommen werden. Der Begriff "Compiler" wird im vorliegenden Kontext so verstanden, daß er die zum Erzeugen eines Objekt-Codes aus einem Source-Code notwendi­ gen Funktionen umfaßt. Vorzugsweise arbeitet der Compiler 114 so, daß er Festkomma- Funktionen und Gleitkomma-Funktionen 204 und 206 automatisch erzeugt, ohne daß der Pro­ grammierer eingreifen müßte. Zum Zweck der Erläuterung sind die Bibliotheken 116 und 118 in Fig. 1 als getrennte Blöcke dargestellt. Die genaue Realisierung der Bibliotheken 116 und 118 ist nicht entscheidend. Die Bibliotheken 116 und 118 können als eine einzelne Bibliothek oder als zwei Bibliotheken, wie in Fig. 1 gezeigt, oder auf andere Weise realisiert werden. Die Bibliotheken 125 und 126 sollten jedoch für den Compiler 114 zur Verfügung stehen, damit er Festkomma-Ergebnisse und Gleitkomma-Ergebnisse 208 und 210 erzeugen kann.

Zusätzliche Werkzeuge können hinzugefügt werden, um die Entwicklung des DSP-Codes weiter zu erleichtern. Z. B. Werkzeuge die das Betrachten von Variablen erleichtern, können verwendet werden, um die Übersetzung der Variablen durch den Entwickler des Codes zu unterstützen oder zu ersetzen.

Der Betrieb des oben in Bezug auf die Fig. 1 und 2 beschriebenen Systems kann besser ver­ standen werden, wenn man das folgende Beispiel eines rekursiven Filters zweiter Ordnung mit zwei Polen betrachtet. Ein solches Filter kann wie folgt beschrieben werden:

out_n = b2.out_n-2 + b1. out_n-1 + a0.in_n

wobei in der Vektor der Eingangsdaten ist, out ist ein (rekursiv definierter) Vektor aus Aus­ gangsdaten, und b1, b2 und a0 sind Koeffizienten, welche die Frequenzantwort des Filter de­ finieren.

Dies wird als direkte Form der Umsetzung des Filters bezeichnet. Dieses Filter ist ungefähr äquivalent einem analogen LC-Filter. Üblicherweise verhält sich ein solches Filter mit be­ stimmten Koeffizienten nicht gut, wenn es mit arithmetischen Festkomma-Funktionen reali­ siert wird, z. B. mit den durch die Festkomma-Bibliothek 124 wiedergegebenen Funktionen. Diese Koeffizienten entsprechen üblicherweise Filtertypen mit hoher Güte (Q) und niedriger Frequenz.

Wenn das oben angegebene direkte Filterform nicht angemessen arbeitet, können zwei mögli­ che Lösungen untersucht werden. Die erste Lösung besteht darin, für alle oder einige Varia­ blen mit einer Doppelpräzisionsarithmetik zu arbeiten. Dies beeinträchtigt bei den meisten DSPs die Leistung und sollte daher nicht vorschnell in Erwägung gezogen werden. Die zweite Lösung besteht darin, eine alternative Form des Filters einzusetzen, z. B. eine Zustandsvaria­ blen-Formel. Es ist allgemein bekannt, daß IIR-Filter mit Zustandsvariablen numerisch robu­ ster sind als die äquivalente direkte Filterform, insbesondere wenn die Frequenz niedrig und Q hoch ist. Dies ist häufig der Fall bei Bassfiltern für digitale Audioanwendungen. Die Defi­ nition der Zustandsvariablen kann wie folgt ausgedrückt werden:

out_n = a1.in_n + b1.out_n-1-b2.s2_n-1
s2_n = a2.in_n + b2.out_n-1 + b1.s2_n-1

wobei in der Vektor der Eingangsdaten ist, out ist der (rekursiv definierte) Vektor der Aus­ gangsdaten, s2 ist ein interner Zustandsvektor und b1, b2, a1 und a2 sind Koeffizienten, wel­ che die Frequenzantwort des Filters definieren (nicht dieselben Koeffizienten wie im vorher­ gehenden Fall).

Man wird bemerken, daß diese Formel sechs Multiplikationen anstelle der drei Multiplikatio­ nen für den vorhergehenden Fall benötigt. Wenn dieses Filter in einem größeren Programm verwendet wird und das Programm nicht richtig arbeitet, wäre es sehr schwierig zu ermitteln, ob das Filter die Quelle des Problems ist. In einem System, das die oben in Verbindung mit den Fig. 1 und 2 beschriebenen Grundsätze verwirklicht, kann die Quelle des Problems we­ sentlich leichter ermittelt werden, indem die Differenzen zwischen den Werten für die Varia­ blen untersucht werden, die von den Festkomma-Funktionen und den Gleitkomma- Funktionen 204 und 206 erzeugt werden. Dadurch kann auf vorteilhafte Weise viel Entwick­ lungszeit gespart werden.

Das folgende Beispiel eines in C++ geschriebenen Programmes zeigt deutlicher die Vorteile der hier beschriebenen Ausführungsform. Der Code erzeugt auf beide Arten äquivalente Fil­ ter. Zufallsdaten, die den Prüfdaten 202 entsprechen, werden dann durch beide Filter ge­ schickt (die den Festkomma-Funktionen und Gleitkomma-Funktionen 204 und 206 entspre­ chen). Die letzten zehn Ergebnisse werden am Ausgang 122 vorgesehen, um sie betrachten zu können. Die Filter wurden ohne Beachtung der in Fig. 2 gezeigten Art der Analyse geschrie­ ben. Dies findet aufgrund der Struktur der Klassendefinition für die Festkomma-Bibliothek 125 vorteilhaft im Hintergrund statt.

Eine beispielhafte PCL 118, die zum Erzeugen des Entwicklungsobjekt-Codes 128 aus dem oben gezeigten Entwicklungscode 112 verwendet wird, ist unten gezeigt, wobei sie in der Programmiersprache C++ realisiert ist. Drei numerische Typen sind vorgesehen: vorzeichen­ behaftete Brüche mit einem Bereich von ± 1, vorzeichenbehaftete Brüche mit einem Bereich von ± 2, und ein erweiterter Präzisionsakkumulator. Diese stellen eine Untermenge der Bi­ bliothek der üblichen Klassen für einen 16 Bit-DSP mit einem 16 × 16 Multiplizierer und ei­ nem Akkumulator, der größer als 32 Bit ist, dar. Die folgenden Annahmen werden bezüglich der DSP-Architektur getroffen:

• (1) Die Daten umfassen nominell 16 Bit, wobei Brüche dargestellt werden können;
• (2) Multiplikationen sind vorzeichenbehaftet und erzeugen ein 31 Bit-Ergebnis, einschließlich Brüche;
• (3) Die Aufrechnung dieser Produkte erfolgt mit Sicherheits-Bits, um einen Überlauf zu ver­ hindern;
• (4) Das Ergebnis der Aufrechnung wird auf 16 Bit gerundet (durch Addieren von 0,5 lsb) und geht in die Sättigung, wenn es größer als eine logische ± 1 ist.

Mit den 16 Bit-Datentypen werden zwei verschiedene logische Bereiche unterstützt, einer mit dem binären Komma rechts des Vorzeichen-Bits (unterstützt ± 1) und der andere mit dem binären Komma um ein oder mehr Bit nach rechts verschoben (unterstützt logisch ± 2). Für die Ausgabe der wahren und momentanen Werte ist bei dieser Demonstrationsversion nur eine sehr minimale Darstellungsoperation enthalten. Im erzeugten Code werden üblicherweise der I/O-Strom sowie Funktionen zum Ableiten verschiedener statistischer Werte unterstützt. Wenn der Code an einen tatsächlichen DSP gerichtet wird, wird eine andere Bibliothek (PCL 116) verwendet, an die diese mathematischen Debug-Werkzeuge nicht angehängt sind.

Die Ausführung des obigen Filters mit den beschriebenen Bibliotheken führt zu dem unten gezeigten Ergebnis. Man beachte, daß die Ausgangswerte zeigen, daß bei der direkten Filter­ form (direct form filter) wesentlich größere Rundungsfehler auftreten.

Direktform-Ergebnisse

val = 0.0155029 error (ls bits) = 385.077 rms error (ls bits) = 253.226
val = 0.0153809 error (ls bits) = 391.346 rms error (ls bits) = 253.403
val = 0.0153198 error (ls bits) = 397.181 rms error (ls bits) = 253.589
val = 0.0151672 error (ls bits) = 402.794 rms error (ls bits) = 253.783
val = 0.0149231 error (ls bits) = 408.035 rms error (ls bits) = 253.985
val = 0.0145874 error (ls bits) = 412.617 rms error (ls bits) = 254.194
val = 0.0141602 error (ls bits) = 416.53 rms error (ls bits) = 254.409
val = 0.0138245 error (ls bits) = 420.685 rms error (ls bits) = 254.63
val = 0.0134583 error (ls bits) = 425.074 rms error (ls bits) = 254.857
val = 0.0130615 error (ls bits) = 429.264 rms error (ls bits) = 255.091.

Zustandsvariablen-Ergebnisse

val = 0.0038147 error (ls bits) = 2.07748 rms error (ls bits) = 3.5345
val = 0.00350952 error (ls bits) = 2.34605 rms error (ls bits) = 3.53351
val = 0.00326538 error (ls bits) = 2.18081 rms error (ls bits) = 3.5324
val = 0.00292969 error (ls bits) = 1.79441 rms error (ls bits) = 3.53109
val = 0.00253296 error (ls bits) = 2.0353 rms error (ls bits) = 3.5299
val = 0.00204468 error (ls bits) = 1.61672 rms error (ls bits) = 3.5285
val = 0.00149536 error (ls bits) = 1.52983 rms error (ls bits) = 3.52707
val = 0.0010376 error (ls bits) = 1.68464 rms error (ls bits) = 3.52571
val = 0.000549316 error (ls bits) = 2.0742 rms error (ls bits) = 3.52455
val = 3.05176e-005 error (15 bits) = 2.26359 rms error (ls bits) = 3.52352.

Die Einheiten der Fehler entsprechen dem niedrigstwertigen Bit (lsb), und man kann erken­ nen, daß bei dem beispielhaften Filteraufbau die Zustandsvariablen-Formel wesentlich präzi­ ser ist.

Wie oben erläutert, kann in den Klassenobjekten zusätzlich zu Fehlern andere nützliche In­ formation für die Entwicklung oder Fehlersuche enthalten sein (gezeigt als Code- Entwicklungsinformation 120 in den Fig. 1 und 2). Zusätzlich können den Klassen Debug- Werkzeuge hinzugefügt werden, um statistische Ergebnisse abzuleiten und anzuzeigen (diese Werkzeuge würden nach dem Kompilieren mit der RCL keine Funktionen ausführen). Für Fehlersuch-Zwecke ist es möglich, den präzisen Wert für einige Variablen zu verwenden, um die Quelle eines numerischen Problems zu identifizieren.

Claims (3)

1. System zum Entwickeln eines Festkomma-Codes zur Ausführung durch einen digita­ len Signalprozessor, welcher eine Schaltung zum Ausführen von Festkomma- Arithmetik aufweist, mit folgenden Merkmalen:
eine Bibliothek, die mehrere erste Variablentypen enthält, wobei jeder erste Varia­ blentyp numerische Ergebnisse erzeugt, die gleich numerischen Ergebnissen sind, welche von der Schaltung zum Ausführen der Festkomma-Arithmetik erzeugt werden, wobei die Bibliothek ferner mehrere zweite Variablentypen aufweist, wobei bestimm­ ten der ersten Variablentypen entsprechende zweite Variablentypen zugeordnet sind und die zweiten Variablentypen gewünschte numerische Ergebnisse liefern; und
ein Compiler, der auf Funktionen anspricht, welche die ersten Variablentypen spezifi­ zieren, um einen Objekt-Code zu erzeugen, der die Funktionen umfaßt, die in Über­ einstimmung mit den ersten Variablentypen und den zweiten Variablentypen realisiert sind.

2. Code-Entwicklungssystem zum Entwickeln eines Zielcodes zur Ausführung durch eine Festkomma-Arithmetik-Schaltung in einem digitalen Signalprozessor, mit fol­ genden Merkmalen:
eine Prototyp-Klassenbibliothek, die eine Menge aus Datenobjekten umfassend eine erste Menge aus Funktionen zum Vorsehen erster arithmetischer Ausgangswerte, die im wesentlichen ähnlich der arithmetischen Schaltung sind, und eine zweite Menge aus Funktionen zum Vorsehen zweiter arithmetischer Ausgangswerte umfaßt, wobei die zweiten arithmetischen Ausgangswerte durch eine höhere Genauigkeit gekenn­ zeichnet sind als die ersten arithmetischen Ausgangswerte, und wobei wenigstens ei­ nigen Funktionen aus der ersten Menge entsprechende Funktionen aus der zweiten Menge zugeordnet sind; und
ein Compiler, der auf den Entwicklungs-Code und die Prototyp-Klassenbibliothek anspricht, zum Erzeugen eines Objekt-Codes, der die erste Menge aus Funktionen, welche in dem Entwicklungs-Code spezifiziert sind, und die Funktionen der zweiten Menge aus Funktionen, welche der ersten Menge aus Funktionen zugeordnet sind, umsetzt.

3. Verfahren zum Entwickeln eines Zielcodes zur Ausführung durch einen digitalen Ziel­ signalprozessor, welcher eine Festkomma-Verarbeitungsschaltung enthält, mit folgen­ den Verfahrensschritten:
Erzeugen eines Entwicklungsobjekt-Codes aus einem Entwicklungssource-Code als eine Funktion einer Bibliothek aus Funktionen, wobei die Funktionen mehrere Fest­ komma-Funktionen zum Erzeugen von Code erfassen, um numerische Daten zu er­ zeugen, welche gleich numerischen Daten sind, die von der Festkomma- Verarbeitungsschaltung erzeugt werden, wobei die Funktionen ferner mehrere Gleit­ komma-Funktionen zum Erzeugen von Codes erfassen, um gewünschte numerische Daten zu erzeugen, wobei die Gleitkomma-Funktionen entsprechenden Festkomma- Funktionen zugeordnet sind;
Erzeugen von Testergebnissen durch Verwenden des Entwicklungsobjekt-Codes zum Verarbeiten von Testdaten, wobei die Testergebnisse eine erste Menge aus Testergeb­ nissen, die mit den Festkomma-Funktionen erzeugt werden, und eine zweite Menge aus Testergebnissen, die mit den Gleitkomma-Funktionen erzeugt werden, umfassen;
Modifizieren des Entwicklungssource-Codes, damit der Entwicklungsobjekt-Code Testergebnisse erzeugt, welche Differenzen zwischen der ersten Menge aus Tester­ gebnissen und der zweiten Menge aus Testergebnissen minimieren; und
Erzeugen des Zielcodes als eine Funktion des modifizierten Entwicklungssource- Codes und der Festkomma-Funktionen.