DE10115883A1

DE10115883A1 - Verfahren und Vorrichtung zur effizienten Konvertierung von Datenratenformaten bei der ATM-Datenübertragung

Info

Publication number: DE10115883A1
Application number: DE2001115883
Authority: DE
Inventors: Harald Protte; Dirk Heistermann; Rolf Kirstaetter; Thomas Wahl
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2001-03-30
Filing date: 2001-03-30
Publication date: 2002-10-17

Abstract

Die Erfindung schafft ein Verfahren zum Konvertieren von Datenratenformaten bei einer ATM-Datenübertragung, wobei zwei zusätzliche Konvertierungsblöcke (601, 602) im Vergleich zu herkömmlichen Arithmetischen Logischen Einheiten (ALU) bereitgestellt werden. Ein Exponentiell-Linear-Konvertierungsblock (601) führt eine Konvertierung von exponentiellen Datenratenformaten (206) in lineare Datenratenformate (301) aus, während ein Linear-Exponentiell-Konvertierungsblock (602) eine Konvertierung von verarbeiteten linearen Datenratenformaten (301-1) in verarbeitete exponentielle Datenratenformate (206-1) ausführt, nachdem die linearen Datenratenformate (301) in einer Datenverarbeitungseinheit (701) verarbeitet worden sind. Für die Konvertierungsprozedur wird in einem Ausführungsbeispiel gemäß der vorliegenden Erfindung ein VHDL-Code eingesetzt.

Description

Die vorliegende Erfindung betrifft allgemein ein Verfahren zum Konvertieren von Datenratenformaten, und betrifft insbesondere ein Verfahren und eine Vorrichtung zur effizienten Konvertierung von Datenratenformaten bei der ATM- Datenübertragung.

Bei der ATM-(Asynchronous Transfer Mode-)Datenübertragung existieren RM-Zellen (Resource Management Cells), um den Datenfluss zu steuern. Die Datenraten in diesen Fällen werden in einem speziellen binären Fliesspunktformat dargestellt, das durch die "Traffic Management Specification" von dem ATM- Forum vorgegeben ist, wobei eine Datenrate R als eine Anzahl von Zellen pro Sekunde ausgedrückt wird. Die Datenrate R wird herkömmlicher Weise durch folgende Gleichung dargestellt:

Hierbei sind entsprechend der Vorgaben des ATM-Forums folgende Vereinbarungen getroffen:
e: Exponent mit einer Größe von 5 Bit,
m: Mantisse mit einer Größe von 9 Bit, und
nz: Null-Marker mit der Größe 1 Bit, welcher anzeigt, ob eine Datenrate Null ist, d. h. nz = 0, oder ob eine Datenrate unterschiedlich von Null ist, d. h. nz = 1.

Derartige Datenraten sind für spezifische Prozessoren, die keine Fliesspunkteinheit aufweisen, nur unter großen Schwierigkeiten oder überhaupt nicht zu handhaben. Die durch die obige Gleichung dargestellten Datenraten müssen einer Datenverarbeitung unterzogen werden, wie beispielsweise einem Größenvergleich, d. h. einem Vergleich, ob beispielsweise eine minimale Datenrate überschritten wird, einer Addition von Datenraten, einer Subtraktion von Datenraten, etc.

Es ist somit ein Nachteil herkömmlicher Verfahren, dass eine Datenverarbeitung von Datenraten in einer herkömmlichen exponentiellen Darstellung sehr aufwendig und zeitraubend sind. Somit ist es notwendig, eine "lineare" Darstellung von Datenraten zu erreichen, wobei die lineare Darstellung in herkömmlichen Prozessoren ohne eine Fliesspunkteinheit verarbeitet werden kann.

Nach dem Stand der Technik existieren Software-Verfahren, um derartige Datenraten von einem exponentiellen Format in ein lineares Format zu konvertieren. Nach einer spezifischen, für den untersuchten Prozess relevanten Datenverarbeitung in einem linearen Format, erfolgt eine Konvertierung in ein exponentielles Format, das der speziellen binären Fliesspunktdarstellung, die durch die "Traffic Management Specification" von dem ATM-Forum vorgegeben ist, entspricht.

RM-(Resource Management-)Zellen weisen in ATM- Übertragungsverfahren eine große Bedeutung auf. Die Steuerung eines ATM-Netzverkehrs ist grundlegend abhängig von der Fähigkeit des Netzes, geeignete, differenzierte Servicequalität (QoS = Quality of Service) für Netzanwendungen bereitzustellen. Die "Traffic Management Specification" definiert Prozeduren und Parameter, die auf eine Verkehrsverwaltung und auf eine Servicequalität bezogen sind. Eine Verkehrsverwaltung dient hauptsächlich dazu, das Netz und das Endsystem vor eine "Überlauf" zu schützen, um ein Betriebsverhalten im Netz zu verbessern.

Weiterhin ist es wünschenswert, einen effizienten Gebrauch von Netz-Ressourcen zu machen. Bezogen auf eine Service- Qualität für Netzanwendungen sind ATM-spezifisch sechs Service-Kategorien definiert. Für jede ist ein Satz von Parametern vorgegeben, um sowohl den Verkehr, der in dem Netz dargestellt ist, als auch die Service-Qualität zu beschreiben, die von dem Netz gefordert wird, wobei die sechs Kategorien wie folgt lauten:

- CBR Constant Bit Rate = konstante Bitrate
- rt-VBR Real-Time Variable Bit Rate = variable Echtzeit-Bitrate
- nrt-VBR Non-Real-Time Variable Bit Rate = variable Nicht-Echtzeit-Bitrate
- UBR Unspecified Bit Rate = unspezifizierte Bitrate
- ABR Available Bit Rate = verfügbare Bitrate
- GFR Guaranteed Frame Rate = garantierte Rahmenrate.

Unter Bezugnahme auf die fünfte Kategorie (ABR, Available Bit Rate = verfügbare Bitrate) ist eine Datenübertragungsrate bezeichnet, für welche sich die begrenzten ATM-Schicht- Übertragungseigenschaften, die von dem Netz bereitgestellt sind, nach einer Einrichtung einer Verbindung ändern können. Ein Flusssteuermechanismus ist spezifiziert, der unterschiedliche Typen einer Rückführung unterstützt, um die Quellenrate in Reaktion auf ein Ändern der ATM-Schicht- Übertragungseigenschaften zu steuern. Diese Rückführung wird zu der Quelle über spezifische Steuerzellen realisiert, die, wie oben angegeben, als "Resource Management Cells" oder RM- Zellen ("Resource Management Cells, RM-Cells = Ressourcen- Verwaltungszellen") bezeichnet werden.

Somit kommt diesen RM-Zellen bei einer ATM-Übertragung eine besondere Bedeutung zu. Es wird erwartet, dass ein Endsystem, das seinen Verkehr in Übereinstimmung mit der Rückführung anpasst, ein niedriges Zellenverlustverhältnis aufweisen wird und einen fairen Anteil der verfügbaren Bandbreite gemäß einer Netzspezifikations-Zuordnungspolitik erhalten wird. Auf die Einrichtung einer ABR(Available Bit Rate = verfügbare Bitrate)-Verbindung hin wird das Endsystem dem Netz sowohl eine maximal erforderliche Bandbreite und eine minimal einsetzbare Bandbreite übermittelt, wobei erstere herkömmlicher Weise als PCR (Peak Cell Rate = Spitzenzellenrate) und die letztere als MCR (Minimum Cell Rate = minimale Zellenrate) bezeichnet werden. Hierbei erzeugt, in einem Flusssteuerungsmodell für eine verfügbare Bitrate, eine Quelle von Datenzellen Rückwärts-RM-Zellen, die von dem Bestimmungsort zurückgegeben werden und zurück zu der Quelle als Rückwärts-RM-Zellen gesendet werden. Diese Rückwärts-RM-Zellen führen eine Rückführinformation mit sich, die von Netzwerkelementen und/oder von dem Bestimmungsort zurück zu der Quelle bereitgestellt wird.

Hierbei kann ein Netz-Element eine Rückführ-Steuerinformation in RM-Zellen direkt einführen, wenn sie in der Vorwärts- oder Rückwärts-Richtung vorbeilaufen, oder es kann die Quelle indirekt von einer Überfüllung informieren, indem EFCI- (Explicit Forward Congestion Indication-)Bits in dem Datenzellkopf die Zellen des Vorwärts-Informationsflusses indirekt informieren, wobei in diesem Fall der Bestimmungsort die Rückwärts-RM-Zellen auf der Grundlage dieser Überfüllungs-Information aktualisieren wird, oder es kann Rückwärts-RM-Zellen erzeugen. Das verwendete Format von RM- Zellen ist in folgender Tabelle 0 dargestellt. Eine Datenrateninformation bzw. eine Datenratendarstellung wird in einer RM-Zelle in einer binären Fliesspunktdarstellung angegeben, wie in der voranstehenden Gleichung gezeigt. Datenraten in einer RM-Zelle werden beispielsweise durch die in der Tabelle 0 gezeigten Felder ER (Explicit Cell Rate = explizite Zellrate), CCR (Current Cell Rate = gegenwärtige Zellrate) und MCR (Minimum Cell Rate = minimale Zellrate) dargestellt.

Fig. 2 zeigt den herkömmlichen Aufbau eines exponentiellen Datenratenformats 206, wobei das exponentielle Datenratenformat 206 aus einer 9-Bit-breiten Mantisse 201, aus einem 5-Bit-breiten Exponenten 202, aus einem 1-Bit- breiten Null-Marker 203 und einem 1-Bit-breiten Reservebitbereich 204 besteht. In herkömmlicher Weise wird eine Datenratenkonvertierung, d. h. eine Konvertierung von einem exponentiellen Format in ein lineares Format und eine Konvertierung von dem linearen Format in ein exponentielles Format, mittels geeigneter Software-Codes durchgeführt. Prinzipiell werden in herkömmlicher Weise für eine Software- Datenratenkonvertierung folgende Verarbeitungsschritte ausgeführt:

Nach der vorbereitenden Umformung wird die o. a. Datenratenformatdarstellung in ein lineares Format übergeführt, wobei eine Granularität, d. h. ein kleinstes mögliches Übertragungspaket spezifiziert werden muss. Dieses kleinste mögliche Übertragungspaket wurde für die Anwendung auf 16 Zellen pro Sekunde festgelegt. Somit können Datenraten nur in Vielfachen von 16 Zellen pro Sekunde angegeben werden. Üblicherweise besteht eine ATM-Zelle aus 53 Bytes, was einer Gesamtanzahl von 424 Bits entspricht.

Somit ergibt sich eine minimale darstellbare Datenrateneinhait von 6,784 kbps (= Zellen pro Sekunde × 424 Bits). Die maximale darstellbare Datenrate in einem üblicherweise verwendeten 16-Bit-breiten, linearen Datenratenformat beträgt somit (2¹⁶ 1) × 16 Zellen/Sekunde = 1 048 560 Zellen/Sekunde, was einer maximalen Übertragungsrate von 444,6 Mbps (= 1 048 560 Zellen/Sekunde × 424 Bits) entspricht. Somit ergeben sich als Ausdruck für eine Datenrate mit einer Granularität von 16 Zellen pro Sekunde die folgenden Gleichungen:

In der nachfolgenden Tabelle 1 ist das Prinzip einer Software-Datenratenkonvertierung von einem exponentiellen Datenratenformat, das von dem ATM-Forum spezifiziert ist, in ein 16-Bit-breites lineares Format aufgelistet. Tabelle 2 zeigt einen C-Code für eine Konvertierung des gemäß Tabelle 1 konvertierten Codes von einem 16-Bit-breiten linearen Format in ein durch das ATM-Forum vorgegebenes exponentielles Format.

Hierbei ist zu bemerken, dass für einen Protokollprozessor ohne spezielle Konvertierungsblöcke für eine Konvertierung ein Konvertierungsvorgang von einem exponentiellen in ein lineares Format ungefähr 16 Zyklen benötigt, während eine Konvertierung von einem linearen in ein exponentielles Format im ungünstigsten Fall ungefähr 110 Zyklen benötigt. Es ist somit ein Nachteil von Verfahren zur Datenratenkonvertierung nach dem Stand der Technik, dass ein großer Bereich des Schreib/Lese-Speichers (RAM = Random Access Memory) bereitgestellt werden muss, um den Software-Code zu speichern. Nachfolgende Tabelle 3 zeigt detaillierter einen Assembler-Code für eine Konvertierung eines exponentiellen Datenratenformates in ein lineares Datenratenformat, wobei wiederum 16 Zyklen erforderlich sind. Umgekehrt zeigt Tabelle 4 detailliert ein in einem Assembler-Code dargestelltes Software-Programm für eine Konvertierung des 16-Bit-breiten linearen Datenratenformats in ein exponentielles Datenratenformat. Die nach dem herkömmlichen Verfahren zur Datenratenkonvertierung notwendigen Zyklen müssen mit einer Signaldurchlaufzeit der ALU (Arithmetischen Logischen Einheit = Arithmetic Logical Unit)
mit

Tabelle 1

Tabelle 3

Tabelle 4

multipliziert werden, was bedeutet, dass eine erhebliche Zeitverzögerung unter Verwendung von Protokollprozessor-ALUs herkömmlicher Art, von welchen eine als Beispiel in Fig. 5 gezeigt ist, auftritt. Ein weiterer Nachteil von Verfahren nach dem Stand der Technik besteht darin, dass in Folge der notwendigen Bereitstellung von RAM-Speicherplatz eine Chipfläche zunimmt.

Es ist somit eine Aufgabe der vorliegenden Erfindung, eine Datenratenkonvertierung von einem exponentiellen in ein lineares Datenratenformat und eine Datenratenkonvertierung von dem linearen Datenratenformat in ein exponentielles Datenratenformat in effizienter Weise durch zwei spezielle Konvertierungsblöcke innerhalb eines Protokollprozessors bereitzustellen, so dass innerhalb einer Zykluszeit eine Datenratenkonvertierung bzw. -rekonvertierung (exponentiell nach linear bzw. linear nach exponentiell) erreicht werden kann.

Diese Aufgabe wird durch ein Verfahren zum Konvertieren von Datenratenformaten nach Anspruch 1 und eine Vorrichtung nach Anspruch 6 gelöst.

VORTEILE DER ERFINDUNG

Das erfindungsgemäße Verfahren zum effizienten Konvertieren von Datenratenformaten bei der ATM-Datenübertragung nach Anspruch 1 und die Vorrichtung mit den Merkmalen des Anspruchs 6 weisen folgende Vorteile auf.

In vorteilhafter Weise weist das erfindungsgemäße Verfahren zwei in einer ALU eines Protokollprozessors implementierte Befehle bzw. Konvertierungsblöcke auf.

Kern der Erfindung ist ein Verfahren zum Konvertieren eines exponentiellen Datenratenformats in ein lineares Datenratenformat und zum Konvertieren eines linearen Datenratenformats in ein exponentielles Datenratenformat mittels zweier in einem Protokollprozessor implementierter Konvertierungsblöcke.

Gemäß einer bevorzugten Weiterbildung der vorliegenden Erfindung sind die Konvertierungsblöcke für eine Exponentiell-Linear-Konvertierung und für eine Linear- Exponentiell-Konvertierung in einer Arithmetischen Logischen Einheit eines Protokollprozessors einfach zu implementieren.

Gemäß noch einer weiteren bevorzugten Weiterbildung wird durch die Implementierung der Konvertierungsblöcke eine große Flexibilität erreicht. Während ein spezieller Hardware- Konvertierungsblock prinzipiell ebenfalls eine Konvertierung durchführen kann, benötigen die in einer ALU eines Protokollprozessors implementierten Konvertierungsblöcke ein Minimum an Zyklen.

Gemäß noch einer weiteren bevorzugten Weiterbildung sind die beiden speziellen Konvertierungsblöcke in der Arithmetischen Logischen Einheit (ALU) zum Konvertieren von exponentiellen Datenratenformaten in lineare Datenratenformate und zum Konvertieren von linearen Datenratenformaten in exponentielle Datenratenformate in einem VHDL-(= Very High Speed Integrated Circuits Hardware Description Language)-Code bereitgestellt.

Gemäß noch einer weiteren bevorzugten Weiterbildung entspricht das exponentielle Datenratenformat dem durch das ATM-Forum (Traffic Management Specification) vorgegebenen Datenratenformat.

ZEICHNUNGEN

Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert.

In den Zeichnungen zeigen:

Fig. 1 ein Blockdiagramm einer Konvertierung und einer Re- Konvertierung von Datenratenformaten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

Fig. 2 den Aufbau eines exponentiellen Datenratenformates entsprechend den Vorgaben des ATM-Forums nach "Traffic Management Specifications";

Fig. 3 ein lineares, 16-Bit-breites Datenratenformat gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

Fig. 4 ein Blockdiagramm eines Kerns eines Protokollprozessors;

Fig. 5 ein Blockdiagramm einer Arithmetischen Logischen Einheit (ALU = Arithmetic Logical Unit) des in Fig. 4 gezeigten Kerns eines Protokollprozessors nach dem Stand der Technik;

Fig. 6 eine Arithmetische Logische Einheit (ALU = Arithmetic Logical Unit) eines Kerns eines Protokollprozessors, die um zwei erfindungsgemäße Konvertierungsblöcke erweitert ist; und

Fig. 7 ein Blockbild eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens.

BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE

Fig. 1 verdeutlicht ein Blockdiagramm einer Konvertierung und einer Re-Konvertierung von Datenratenformaten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Bei dem in Fig. 1 gezeigten Flussdiagramm ist deutlich, wie ein exponentielles Datenratenformat, das ATM-Forum-kompatibel ist, verarbeitet wird. In einem Eingabeschritt S101 wird ein exponentielles ATM-Format eingegeben und einem Exponentiell- Linear-Konvertierungsschritt SiO₂ zugeführt, wo eine Exponentiell-Linear-Konvertierung vorgenommen wird, wobei das Verfahren einer Konvertierung untenstehend beschrieben werden wird. Anschließend wird das lineare Datenratenformat einem Datenverarbeitungsschritt S103 zugeführt, in welchem eine Datenverarbeitung durchgeführt werden kann, die erforderlich ist, um Datenratenformate untereinander oder mit vorgegebenen Datenratenformaten zu vergleichen, Datenratenformate zu addieren, Datenratenformate zu subtrahieren, etc.

Nach einer Datenverarbeitung in einem Datenverarbeitungsschritt S103 wird das Ergebnis einem Linear-Exponentiell-Konvertierungsschritt, d. h. einem Konvertierungsschritt S104 zugeführt. Hier wird das durch den Exponentiell-Linear-Konvertierungsschritt S102 erhaltene und durch den Datenverarbeitungsschritt S103 verarbeitete lineare Datenratenformat 301-1 in ein verarbeitetes exponentielles Datenratenformat 206-1 konvertiert, wie untenstehend beschrieben werden wird. Anschließend wird das konvertierte verarbeitete exponentielle Datenratenformat 206-1 in einem Ausgabeschritt S105 ausgegeben, um in ATM-kompatiblen Prozeduren weiterverarbeitet zu werden.

Fig. 2 zeigt den Aufbau eines exponentiellen Datenratenformates entsprechend den Vorgaben des ATM-Forums nach "Traffic Management Specifications".

Das in Fig. 2 dargestellte exponentielle Datenratenformat 206 entspricht den ATM-Standards und weist eine Länge von 16 Bits auf, wobei die ersten neun Bits (Bit 1-9) einer Mantisse zugeordnet werden, die nächsten fünf Bits (Bit 10-14) einem Exponenten zugeordnet werden, das nächste Bit (Bit 15) einen Null-Marker darstellt und das letzte Bit (Bit 16) als ein Reservebit vorgehalten wird.

Das exponentielle Datenratenformat nimmt dabei die folgende Form an:

Fig. 3 zeigt ein lineares, 16-Bit-breites Datenratenformat gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Das in Fig. 3 gezeigte lineare Datenratenformat besteht in dem hier gezeigten Ausführungsbeispiel der vorliegenden Erfindung aus 16 Bit, d. h. 2¹⁶ Zustände sind möglich, wobei die Linear-Format-Bitstellen fortlaufend mit den Bezugszeichen 302-1 (LSB), . . . 302-16 (MSB) bezeichnet sind.

Das so erhaltene lineare Datenratenformat 301 steht für eine Datenverarbeitung zur Verfügung, wobei ein wesentlicher Vorteil darin besteht, dass dieses lineare Datenratenformat mit herkömmlichen Protokollprozessoren ohne Fliesspunktdarstellung einfach zu verarbeiten ist, im Gegensatz zu dem exponentiellen Datenratenformat, das durch diese Prozessoren im allgemeinen nicht verarbeitbar ist.

Eine Konvertierung des exponentiellen Datenratenformates 206 in ein lineares Datenratenformat 301 und eine Konvertierung des linearen Datenratenformats 301 in ein exponentielles Datenratenformat 206 wird in dem beschriebenen Ausführungsbeispiel des erfindungsgemäßen Verfahren durch spezifische Konvertierungsblöcke in der Arithmetischen Logischen Einheit (ALU) des Protokollprozessors durchgeführt, die untenstehend unter Bezugnahme auf die Fig. 4 und 6 sowie die Tabellen 5 und 6 beschrieben werden.

In dem in Fig. 4 veranschaulichten Blockschaltbild ist ein Kern eines Protokollprozessors gezeigt, wobei zur Vereinfachung der Beschreibung nachfolgend nur jene Teile erklärt werden, auf die sich die vorliegende Erfindung beziehen.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung werden für die Arithmetische Logische Einheit (ALU = Arithmetic Logical Unit) zwei zusätzliche Konvertierungsblöcke bereitgestellt. Die in Fig. 4 in Blockform gezeigte Arithmetische Logische Einheit 401 ist in den Fig. 5 und 6 detaillierter dargestellt. Hierbei zeigt Fig. 5 eine herkömmliche Arithmetische Logische Einheit 401, wie sie üblicherweise in Protokollprozessoren eingesetzt wird.

Bei dem in Fig. 6 veranschaulichten Blockbild sind zwei zusätzliche Konvertierungsblöcke 601 und 602 im Vergleich zu der in Fig. 5 verdeutlichten Arithmetischen Logischen Einheit (ALU) enthalten. Der Konvertierungsblock 601 stellt einen Exponentiell-Linear-Konvertierungsblock dar, in welchem eine Konvertierung von exponentiellen Datenratenformaten in lineare Datenratenformate durchgeführt wird, wobei in dem hier dargestellten Ausführungsbeispiel insbesondere eine Konvertierung von einem exponentiellen Datenratenformat 206, welches beispielsweise in Fig. 2 gezeigt ist, in ein lineares Datenratenformat 301, welches beispielsweise in Fig. 3 gezeigt ist, durchgeführt wird. Für die Konvertierungsprozedur wird in diesem Ausführungsbeispiel gemäß der vorliegenden Erfindung ein VHDL (= Very High Speed Integrated Circuits Hardware Description Language)-Code eingesetzt. VHDL-Codes sind beispielsweise aus: "Bäsig, Jürgen: Entwicklung digitaler Systeme mit VHDL - Einsatz und Anwendung von VHDL zur Simulation und zur Synthese von digitalen Systemen, Eigenverlag, 1999, ISBN 3-00-005081-7" bekannt. Die nachfolgende Tabelle 6 verdeutlicht einen VHDL- Code, der in dem Exponentiell-Linear-Konvertierungsblock 601 implementiert ist, um eine Konvertierung von einem exponentiellen Datenratenformat in ein lineares Datenratenformat durchzuführen, während in der nachfolgenden Tabelle 5 ein VHDL-Code dargestellt ist, der in dem Linear- Exponentiell-Konvertierungsblock 602 implementiert ist, um eine

Tabelle 5

Tabelle 6

Konvertierung eines linearen Datenratenformates in ein exponentielles Datenratenformat durchzuführen.

Fig. 7 zeigt ein Blockbild eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens. Zunächst wird ein exponentielles Datenratenformats 206 in einer Arithmetischen Logischen Einheit 401 empfangen. In einem anschließenden Konvertierungsschritt wird das exponentielle Datenratenformat 206 in ein lineares Datenratenformat 301 mittels eines Exponentiell-Linear-Konvertierungsblocks 601 konvertiert. Nach einer Datenverarbeitung des linearen Datenratenformats 301 in einer Datenverarbeitungseinheit 701 erfolgt eine Konvertierung des verarbeiteten linearen Datenratenformats 301-1 in ein verarbeitetes exponentielles Datenratenformat 206-1 durch einen Linear-Exponentiell-Konvertierungsblock 602 und schließlich eine Ausgabe des verarbeiteten exponentiellen Datenratenformats 206-1.

Wie in obenstehender Tabelle 1 veranschaulicht, ist für einen herkömmlichen Exponentiell-Linear-Konvertierungsschritt mittels herkömmlicher Software im ungünstigsten Fall eine Anzahl von 16 Zyklen erforderlich, um ein ATM-kompatibles Datenratenformat in ein lineares Datenratenformat zu konvertieren. Noch ungünstiger bezüglich einer Anzahl zu verarbeitender Zyklen ist der in Tabelle 2 dargestellte Fall des Linear-Exponentiell-Konvertierungsschritt, bei welchem mittels herkömmlicher Software im ungünstigsten Fall 110 Zyklen erforderlich sind. Die Konvertierungszeiten betragen für eine typische ALU-Durchlaufzeit (ALU = Arithmetic Logical Unit = Arithmetische Logische Einheit) von 5 ns somit im ungünstigsten Fall für einen Exponentiell-Linear- Konvertierungsschritt

16 × 5 ns = 80 ns,

während für einen Linear-Exponentiell-Konvertierungsschritt mittels herkömmlicher Software im ungünstigsten Fall eine Konvertierungszeit von

110 × 5 ns = 550 ns

erforderlich ist. Auf der anderen Seite ist jedoch, wenn eine Exponentiell-Linear-Konvertierung und eine Linear- Exponentiell-Konvertierung in einem Exponentiell-Linear- Konvertierungsblock 601 bzw. einem Linear-Exponentiell- Konvertierungsblock 602 durchgeführt wird, lediglich jeweils eine einzige Durchlaufzeit (5 ns) der ALU zu berücksichtigen, wozu sich in dem hier aufgeführten Ausführungsbeispiel der vorliegenden Erfindung ein maximaler Konvertierungszeitgewinn "eponentiell nach linear" vom Faktor 16 und ein maximaler Konvertierungszeitgewinn "linear nach exponentiell" vom Faktor 110 ergibt.

Neben diesem sehr wichtigen Vorteil eines Zeitgewinns bei einer Konvertierung bzw. einer Konvertierung von Datenratenformaten ergibt sich auch ein Hardware-Vorteil, wie untenstehend beschrieben wird.

Gemäß dem Ausführungsbeispiel der vorliegenden Erfindung wird ein zusätzlicher Flächenbedarf an Hand einer 0,18 µm- Technologie berechnet. Somit benötigt eine ALU ohne speziell implementierte Exponentiell-Linear-601- und Linear- Exponentiell-602-Konvertierungsblöcke einen zusätzlichen Code-RAM (Random Access Memory = Schreib/Lese-Speicher) von 0,095 mm². Die Größe der ALU ohne die speziell implementierten Exponentiell-Linear-601-und Linear Exponentiell-602- Konvertierungsblöcke gemäß Fig. 5 beträgt 0,033236 mm². Damit ergibt sich eine Gesamtfläche für zusätzliche Code-RAM und ALU von:

0,033236 mm² + 0,095 mm² = 0,126236 mm²,

während eine ALU mit dem erfindungsgemäßen Exponentiell- Linear-Konvertierungsblock 601 und dem erfindungsgemäßen Linear-Exponentiell-Konvertierungsblock 602 lediglich eine Fläche von 0,038448 mm² benötigt.

Hierbei muss die Fläche 0,038448 mm² für die ALU bereitgestellt werden, während nach dem Stand der Technik eine zusätzliche Fläche von 0,095 mm², wie voranstehend angegeben, für zusätzlichen Code-RAM bereitgestellt werden muss. Dies entspricht einem Flächengewinn von

0,128236 mm² - 0,038448 mm² = 0,089788 mm²,

bzw. einer Flächenreduktion von 70%.

Eine moderate Erhöhung in der kritischen Weglänge der ALU wird in Kauf genommen, wobei mit einer Synthese mittels Synopsis eine Durchlaufzeit einer wie in Fig. 5 gezeigten ALU zu 4,9 ns berechnet wird, während eine Durchlaufzeit einer ALU mit den erfindungsgemäßen Konvertierungsblöcken 601 und 602 zu 5,0 ns berechnet wird. Diese Erhöhung einer Durchlaufzeit von 0,1 ns bzw. 2% kann vernachlässigt werden.

Obwohl die vorliegende Erfindung vorstehend anhand bevorzugter Ausführungsbeispiele beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Weise modifizierbar.

Bezugszeichenliste

In den Figuren bezeichnen gleiche Bezugszeichen gleiche oder funktionsgleiche Komponenten.

Claims

1. Verfahren zum Verarbeiten eines exponentiellen Datenratenformats mit den folgenden Schritten:

a) Empfangen eines exponentiellen Datenratenformats (206) in einer Arithmetischen Logischen Einheit (401)
b) Konvertieren des exponentiellen Datenratenformats (206) in ein lineares Datenratenformat (301) durch einen Exponentiell- Linear-Konvertierungsblock (601);
c) Datenverarbeitung des linearen Datenratenformats (301) in einer Datenverarbeitungseinheit (701);
d) Konvertieren des verarbeiteten linearen Datenratenformats (301-1) in ein verarbeitetes exponentielles Datenratenformat (206-1) durch einen Linear-Exponentiell-Konvertierungsblock (602); und
e) Ausgeben des verarbeiteten exponentiellen Datenratenformats (206-1).

2. Verfahren zum Konvertieren von Datenratenformaten nach Anspruch 1, dadurch gekennzeichnet, dass die Konvertierungsblöcke (601, 601) für eine Exponentiell-Linear-Konvertierung und für eine Linear- Exponentiell-Konvertierung in einer Arithmetischen Logischen Einheit (401) eines Protokollprozessors einfach implementierbar sind.

3. Verfahren zum Konvertieren von Datenratenformaten nach einem oder beiden der Ansprüche 1 und 2, dadurch gekennzeichnet, dass durch die Implementierung der Konvertierungsblöcke (601, 602) eine große Flexibilität bereitgestellt wird.

4. Verfahren zum Konvertieren von Datenratenformaten nach einem oder mehreren der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Konvertierungsblöcke in der Arithmetischen logischen Einheit (401) zum Konvertieren von exponentiellen Datenratenformaten in lineare Datenratenformate und zum Konvertieren von linearen Datenratenformaten in exponentielle Datenratenformate in einem VHDL-(= Very High Speed Integrated Circuits Hardware Description Language)-Code bereitgestellt werden.

5. Verfahren zum Konvertieren von Datenratenformaten nach einem oder mehreren der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das exponentielle Datenratenformat dem durch das ATM- Forum (Traffic Management Specification) vorgegebenen Datenratenformat entspricht.

6. Vorrichtung zur Konvertierung von Datenratenformaten mit:

a) einem Exponentiell-Linear-Konvertierungsblocks (601) in einer Arithmetischen Logischen Einheit (401) zur Konvertierung eines exponentiellen Datenratenformats (206) in ein lineares Datenratenformat (301);
b) einer Datenverarbeitungseinheit (701) zur Verarbeitung des linearen Datenratenformats (301); und
c) einem Linear-Exponentiell-Konvertierungsblock (602) in der Arithmetischen Logischen Einheit (401) zur Konvertierung eines verarbeiteten linearen Datenratenformats (301-1) in ein verarbeitetes exponentielles Datenratenformat (206-1).