DE10115883A1 - Method for efficient conversion of data rate format during ATM data transmission, involves initially converting exponential data rate format into linear data rate format - Google Patents

Abstract

A method of processing an exponential data/bit rate format (206), involves initially receiving an exponential data/bit rate format (206) in an arithmetic logic unit (401) and then converting the exponential data/bit rate format (206) into a linear data/bit rate format (301) by an exponential-linear-conversion block (601). The linear data/bit rate format is then data processed in a data processing unit (701), then the processed linear data/bit rate format (301-1) is converted into a processed exponential data/bit rate format (206-1) by a linear-exponential-conversion block (602). The processed exponential data/bit rate format (206-1) is then outputted. An Independent claim is given for a device for converting data/bit rate formats.

Description

The present invention relates generally to a method for converting data rate formats, and concerns in particular a method and an apparatus for efficient conversion of data rate formats for ATM Data transfer.

In the case of ATM (Asynchronous Transfer Mode) data transmission, there are RM cells (Resource Management Cells) to control the data flow. The data rates in these cases are represented in a special binary floating point format, which is specified by the "Traffic Management Specification" from the ATM forum, wherein a data rate R is expressed as a number of cells per second. The data rate R is conventionally represented by the following equation:

The following agreements have been made in accordance with the requirements of the ATM Forum:
e: exponent with a size of 5 bits,
m: mantissa with a size of 9 bits, and
nz: zero marker with the size of 1 bit, which indicates whether a data rate is zero, ie nz = 0, or whether a data rate is different from zero, ie nz = 1.

Such data rates are for specific processors that have no floating point unit, only under large ones Difficulty or impossible to handle. By the data rates presented above equation must be one  Be subjected to data processing, such as one Size comparison, d. H. a comparison whether, for example, a minimum data rate is exceeded, an addition of Data rates, a subtraction of data rates, etc.

It is thus a disadvantage of conventional methods that a Data processing of data rates in a conventional exponential display very complex and time consuming are. So it is necessary to have a "linear" representation of To achieve data rates, with the linear representation in conventional processors without a floating point unit can be processed.

According to the state of the art, software processes exist to such data rates from an exponential format into one convert linear format. According to a specific, for data processing relevant to the examined process in a linear format, it is converted to a exponential format that of the special binary Floating point representation by the "Traffic Management Specification "specified by the ATM forum.

RM (Resource Management) cells point in ATM Transmission methods are of great importance. The control ATM network traffic is fundamentally dependent on the Ability of the network, appropriate, differentiated Service quality (QoS = Quality of Service) for To provide network applications. The "Traffic Management Specification "defines procedures and parameters based on a traffic management and related to a quality of service are. Traffic management is mainly used to: To protect the network and the end system from an "overflow" improve operational behavior in the network.

Furthermore, it is desirable to make efficient use of network resources. In terms of service quality for network applications, six service categories are defined specifically for ATM. A set of parameters is provided for each to describe both the traffic represented on the network and the quality of service required by the network, the six categories being as follows:

• - CBR Constant Bit Rate = constant bit rate
• - rt-VBR Real-Time Variable Bit Rate = variable real-time bit rate
• - nrt-VBR Non-Real-Time Variable Bit Rate = variable non-real-time bit rate
• - UBR Unspecified Bit Rate = unspecified bitrate
• - ABR Available Bit Rate = available bit rate
• - GFR Guaranteed Frame Rate = guaranteed frame rate.

Referring to the fifth category (ABR, Available Bit Rate = available bit rate) is a data transfer rate for which the limited ATM layer Transmission properties provided by the network are able to change after setting up a connection. A flow control mechanism is specified that supports different types of feedback to the Source Rate in Response to Changing ATM Layer Control transmission properties. This repatriation will to the source through specific control cells that, as indicated above, as "Resource Management Cells" or RM- Cells ("Resource Management Cells, RM-Cells = Resource Administrative cells ").

Thus, these RM cells come to an ATM transmission special meaning too. An end system is expected to that its traffic in accordance with the repatriation will have a low cell loss ratio and a fair share of the bandwidth available a network specification mapping policy is obtained. On  the establishment of an ABR (Available Bit Rate) Bit rate) connection, the end system becomes both the network a maximum required bandwidth and a minimum usable bandwidth transmitted, the former conventionally as PCR (Peak Cell Rate = Peak cell rate) and the latter as MCR (Minimum Cell Rate = minimum cell rate). in this connection generated in a flow control model for an available one Bit rate, a source of data cells reverse RM cells that to be returned from the destination and back to the Source to be sent as reverse RM cells. This Reverse RM cells carry feedback information that of network elements and / or of the destination is provided back to the source.

Here, a network element can provide feedback control information Introduce directly into RM cells when in the forward or Walk backwards direction, or it may be the source Indirectly inform of a trapping by EFCI- (Explicit Forward Congestion Indication-) bits in the Data cell header the cells of the forward information flow inform indirectly, in which case the destination the reverse RM cells based on this Trapping information will update, or it may Generate reverse RM cells. The format used by RM- Cells are shown in Table 0 below. A Data rate information or a data rate representation is in an RM cell in a binary floating point representation indicated as shown in the equation above. Data rates in an RM cell are determined, for example, by the Fields ER (Explicit Cell Rate = explicit cell rate), CCR (Current Cell Rate = current Cell rate) and MCR (minimum cell rate) shown.  

Fig. 2 shows the conventional structure of an exponential data rates format 206, the exponential data rates format 206 wide from a 9-bit wide mantissa 201, of a 5-bit wide exponent 202, from a 1-bit zero marker 203 and a 1-bit wide spare bit area 204 exists. In a conventional manner, a data rate conversion, ie a conversion from an exponential format to a linear format and a conversion from the linear format to an exponential format, is carried out using suitable software codes. In principle, the following processing steps are carried out in a conventional manner for software data rate conversion:

After the preliminary forming, the above. Data rate format representation in a linear format transferred with a granularity, i.e. H. a smallest possible transmission package must be specified. This smallest possible transmission package was for the application set to 16 cells per second. Thus data rates can only be specified in multiples of 16 cells per second. Usually an ATM cell consists of 53 bytes, which is one Corresponds to a total of 424 bits.

This results in a minimum representable data rate unit of 6.784 kbps (= cells per second × 424 bits). The maximum data rate that can be represented in a commonly used 16-bit-wide, linear data rate format is thus (2 ¹⁶ 1) × 16 cells / second = 1 048 560 cells / second, which corresponds to a maximum transmission rate of 444.6 Mbps (= 1 048 560 Cells / second × 424 bits). This results in the following equations as an expression for a data rate with a granularity of 16 cells per second:

In Table 1 below, the principle is one Software data rate conversion from an exponential Data rate format specified by the ATM forum in a 16-bit wide linear format is listed. Table 2 shows a C code for a conversion of the according to Table 1 converted codes from a 16-bit wide linear format into an exponential given by the ATM forum Format.

It should be noted here that a conversion process from an exponential to a linear format requires approximately 16 cycles for a protocol processor without special conversion blocks for a conversion, whereas a conversion from a linear to an exponential format in the worst case takes approximately 110 cycles. It is therefore a disadvantage of methods for data rate conversion according to the prior art that a large area of the read / write memory (RAM = Random Access Memory) must be made available in order to store the software code. Table 3 below shows in more detail an assembler code for converting an exponential data rate format into a linear data rate format, again requiring 16 cycles. Conversely, Table 4 shows in detail an assembler code software program for converting the 16-bit wide linear data rate format to an exponential data rate format. The cycles required according to the conventional method for data rate conversion must be carried out with a signal throughput time of the ALU (Arithmetic Logical Unit)
With

Table 1

Table 3

Table 4

are multiplied, which means that there is a significant time delay using conventional protocol processor ALUs, one of which is shown as an example in FIG. 5. Another disadvantage of methods according to the prior art is that a chip area increases as a result of the necessary provision of RAM memory space.

It is therefore an object of the present invention to provide a Data rate conversion from an exponential to a linear data rate format and a data rate conversion from the linear data rate format to an exponential Data rate format in an efficient manner through two special Conversion blocks within a protocol processor to be provided, so that a Data rate conversion or conversion (exponential after linear or linear after exponential) can.

This task is accomplished through a process for converting Data rate formats according to claim 1 and an apparatus according to Claim 6 solved.

ADVANTAGES OF THE INVENTION

The inventive method for efficient conversion of data rate formats in ATM data transmission Claim 1 and the device with the features of Claim 6 have the following advantages.

The method according to the invention advantageously has two implemented in an ALU of a protocol processor Commands or conversion blocks.

The essence of the invention is a method for converting a exponential data rate format into a linear Data rate format and for converting a linear  Data rate format in an exponential data rate format by means of two implemented in a protocol processor Conversion blocks.

According to a preferred development of the present Invention are the conversion blocks for one Exponential-linear conversion and for a linear Exponential conversion in an arithmetic logic Unit of a protocol processor easy to implement.

According to yet another preferred development a big one by implementing the conversion blocks Flexibility achieved. While a special hardware In principle, the conversion block is also a conversion in an ALU need one Protocol processor implemented conversion blocks Minimum number of cycles.

According to yet another preferred development, the two special conversion blocks in arithmetic Logical unit (ALU) for converting exponential Data rate formats in linear data rate formats and Convert linear data rate formats to exponential Data rate formats in a VHDL - (= Very High Speed Integrated Circuits Hardware Description Language) code provided.

According to yet another preferred development the exponential data rate format corresponds to that through the ATM forum (Traffic Management Specification) Data rate format.

DRAWINGS

Embodiments of the invention are in the drawings shown and in the following description explained.  

The drawings show:

Fig. 1 is a block diagram of a conversion and a re- conversion of data rates formats according to an embodiment of the present invention;

Fig. 2 shows the structure of an exponential data rates format as specified by the ATM Forum by "Traffic Management Specifications";

Fig. 3 is a linear, 16-bit wide data rates format according to an embodiment of the present invention;

Fig. 4 is a block diagram of a core of a protocol processor;

FIG. 5 shows a block diagram of an arithmetic logic unit (ALU = Arithmetic Logical Unit) of the core of a protocol processor according to the prior art shown in FIG. 4;

Figure 6 is an arithmetic logic unit (ALU = Arithmetic Logical Unit) of a core of a protocol processor, which is extended by two inventive conversion blocks. and

Fig. 7 is a block diagram of an embodiment of the method according to the invention.

DESCRIPTION OF THE EMBODIMENTS

Fig. 1 illustrates a block diagram of a conversion and a re-conversion of data rates formats according to an embodiment of the present invention.

The flowchart shown in FIG. 1 clearly shows how an exponential data rate format that is ATM forum compatible is processed. In an input step S101, an exponential ATM format is entered and fed to an exponential-linear conversion step SiO ₂ , where an exponential-linear conversion is carried out, the method of conversion being described below. The linear data rate format is then fed to a data processing step S103, in which data processing can be carried out which is required to compare data rate formats with one another or with predetermined data rate formats, to add data rate formats, to subtract data rate formats, etc.

After data processing in a data processing step S103, the result is fed to a linear-exponential conversion step, ie a conversion step S104. Here, the linear data rate format 301-1 obtained by the exponential-linear conversion step S102 and processed by the data processing step S103 is converted into a processed exponential data rate format 206-1 , as will be described below. The converted processed exponential data rate format 206-1 is then output in an output step S105 in order to be further processed in ATM-compatible procedures.

Fig. 2 shows the structure of an exponential data rates format as specified by the ATM Forum by "Traffic Management Specifications".

The exponential data rate format 206 shown in FIG. 2 corresponds to the ATM standards and has a length of 16 bits, the first nine bits (bits 1-9 ) being assigned to a mantissa, the next five bits (bits 10-14 ) to one Exponents are assigned, the next bit (bit 15 ) represents a zero marker and the last bit (bit 16 ) is held as a reserve bit.

The exponential data rate format takes the following form:

Fig. 3 shows a linear, 16-bit wide data rates format according to an embodiment of the present invention.

In the exemplary embodiment of the present invention shown here, the linear data rate format shown in FIG. 3 consists of 16 bits, ie 2 ¹⁶ states are possible, the linear format bit positions being designated continuously with the reference symbols 302-1 (LSB). , , 302-16 (MSB).

The linear data rate format 301 thus obtained is available for data processing, a major advantage being that this linear data rate format is easy to process with conventional protocol processors without floating point representation, in contrast to the exponential data rate format, which is generally not processable by these processors ,

A conversion of the exponential data rate format 206 into a linear data rate format 301 and a conversion of the linear data rate format 301 into an exponential data rate format 206 is carried out in the described exemplary embodiment of the method according to the invention by specific conversion blocks in the arithmetic logic unit (ALU) of the protocol processor, which are described below with reference to Figs. 4 and 6 and the tables 5 and 6.

A core of a protocol processor is shown in the block diagram illustrated in FIG. 4, only the parts to which the present invention relates being explained below for the purpose of simplifying the description.

According to an exemplary embodiment of the present invention, two additional conversion blocks are provided for the arithmetic logic unit (ALU = Arithmetic Logical Unit). The arithmetic logic unit 401 shown in block form in FIG. 4 is shown in greater detail in FIGS. 5 and 6. Here, FIG 5 as it is one used in protocol processors Fig., A conventional arithmetic logic unit 401.

The block diagram illustrated in FIG. 6 contains two additional conversion blocks 601 and 602 compared to the arithmetic logic unit (ALU) illustrated in FIG. 5. The conversion block 601 represents an exponential-linear conversion block in which a conversion of exponential data rate formats into linear data rate formats is carried out, in the exemplary embodiment shown here in particular a conversion from an exponential data rate format 206 , which is shown for example in FIG. 2, in a linear data rate format 301 , which is shown for example in FIG. 3, is carried out. In this exemplary embodiment, a VHDL (= Very High Speed Integrated Circuits Hardware Description Language) code is used for the conversion procedure in this exemplary embodiment. VHDL codes are known for example from: "Bäsig, Jürgen: Development of digital systems with VHDL - Use and application of VHDL for the simulation and synthesis of digital systems, Eigenverlag, 1999, ISBN 3-00-005081-7". Table 6 below illustrates a VHDL code implemented in the exponential-linear conversion block 601 to perform a conversion from an exponential data rate format to a linear data rate format, while the following table 5 shows a VHDL code shown in FIG linear to exponential conversion block 602 is implemented by one

Table 5

Table 6

Conversion of a linear data rate format to a perform exponential data rate format.

Fig. 7 shows a block diagram of an embodiment of the inventive method. First, an exponential data rate format 206 is received in an arithmetic logic unit 401 . In a subsequent conversion step, the exponential data rate format 206 is converted into a linear data rate format 301 by means of an exponential-linear conversion block 601 . After data processing of the linear data rate format 301 in a data processing unit 701 , the processing of the processed linear data rate format 301-1 into a processed exponential data rate format 206-1 takes place by means of a linear exponential conversion block 602 and finally the processed exponential data rate format 206-1 is output.

As illustrated in Table 1 above, a conventional exponential linear conversion step using conventional software in the worst case requires a number of 16 cycles to convert an ATM compatible data rate format to a linear data rate format. Even less favorable with regard to a number of cycles to be processed is the case of the linear-exponential conversion step shown in Table 2, in which 110 cycles are required in the worst case using conventional software. The conversion times for a typical ALU throughput time (ALU = Arithmetic Logical Unit = 5 ns) are thus in the worst case for an exponential-linear conversion step

16 × 5 ns = 80 ns,

while for a linear-exponential conversion step using conventional software in the worst case a conversion time of

110 × 5 ns = 550 ns

is required. On the other hand, however, if an exponential-linear conversion and a linear-exponential conversion are carried out in an exponential-linear conversion block 601 and a linear-exponential conversion block 602 , respectively, only a single lead time (5 ns) the ALU must be taken into account, for which purpose in the exemplary embodiment of the present invention listed here there is a maximum conversion time gain "eponially to linear" by a factor of 16 and a maximum conversion time gain "linear to exponential" by a factor of 110.

In addition to this very important advantage of saving time at a conversion or a conversion from Data rate formats also result in a hardware advantage such as is described below.

According to the exemplary embodiment of the present invention, an additional area requirement is calculated using 0.18 μm technology. Thus, an ALU without specially implemented exponential-linear-601 and linear-exponential-602 conversion blocks requires an additional code RAM (Random Access Memory = read / write memory) of 0.095 mm ² . The size of the ALU without the specially implemented exponential-linear 601 and linear exponential-602 conversion blocks according to FIG. 5 is 0.033236 mm ² . This results in a total area for additional code RAM and ALU of:

0.033236 mm ² + 0.095 mm ² = 0.126236 mm ² ,

during an ALU with the inventive Exponentiell- linear conversion block 601 and the linear-exponential conversion block 602 according to the invention, only an area of 0.038448 mm ^{2 are} required.

Here, the area 0.038448 mm ² must be provided for the ALU, while according to the prior art, an additional area of 0.095 mm ² , as stated above, must be provided for additional code RAM. This corresponds to an area gain of

0.128236 mm ² - 0.038448 mm ² = 0.089788 mm ² ,

or an area reduction of 70%.

A moderate increase in the critical path length of the ALU is accepted, a synthesis time using a synopsis being used to calculate a throughput time of an ALU as shown in FIG. 5 at 4.9 ns, while a throughput time of an ALU with the conversion blocks 601 and 602 according to the invention is calculated at 5.0 ns. This increase in a lead time of 0.1 ns or 2% can be neglected.

Although the present invention has been described above preferred embodiments has been described, it is not limited to this, but in a variety of ways modifiable.  

LIST OF REFERENCE NUMBERS

In the figures, identical reference symbols designate identical or functionally identical components.

Claims (6)

1. Procedure for processing an exponential data rate format with the following steps:

• a) receiving an exponential data rate format ( 206 ) in an arithmetic logic unit ( 401 )
• b) converting the exponential data rate format ( 206 ) to a linear data rate format ( 301 ) by an exponential-linear conversion block ( 601 );
• c) data processing of the linear data rate format ( 301 ) in a data processing unit ( 701 );
• d) converting the processed linear data rate format ( 301-1 ) into a processed exponential data rate format ( 206-1 ) by a linear-exponential conversion block ( 602 ); and
• e) Output the processed exponential data rate format ( 206-1 ).

2. A method for converting data rate formats according to claim 1, characterized in that the conversion blocks ( 601 , 601 ) for an exponential-linear conversion and for a linear-exponential conversion can be easily implemented in an arithmetic logic unit ( 401 ) of a protocol processor , 3. A method for converting data rate formats according to one or both of claims 1 and 2, characterized in that great flexibility is provided by the implementation of the conversion blocks ( 601 , 602 ). 4. A method for converting data rate formats according to one or more of claims 1 to 3, characterized in that the conversion blocks in the arithmetic logic unit ( 401 ) for converting exponential data rate formats into linear data rate formats and for converting linear data rate formats into exponential data rate formats in one VHDL (= Very High Speed Integrated Circuits Hardware Description Language) code are provided. 5. Procedure for converting data rate formats to one or more of claims 1 to 4, characterized, that the exponential data rate format corresponds to that used by the ATM Forum (Traffic Management Specification) Data rate format corresponds. 6. Device for converting data rate formats with:

• a) an exponential-linear conversion block ( 601 ) in an arithmetic logic unit ( 401 ) for converting an exponential data rate format ( 206 ) into a linear data rate format ( 301 );
• b) a data processing unit ( 701 ) for processing the linear data rate format ( 301 ); and
• c) a linear-exponential conversion block ( 602 ) in the arithmetic logic unit ( 401 ) for converting a processed linear data rate format ( 301-1 ) into a processed exponential data rate format ( 206-1 ).