NL1001317C2 - Method and device for encoding and decoding data. - Google Patents

Description

Method and device for encoding and decoding data.

Field of the invention

The present invention relates to the field of the data compression and decompression systems and in particular the present invention relates to a method and apparatus for encoding and decoding data in compression / decompression systems in parallel.

Background of the invention

Currently, data compression is widely used, especially for storing and transferring large amounts of data. In the prior art, many different data compression techniques exist. Compression techniques can be divided into two broad 15 categories, lossless encoding and lossless encoding.

Non-lossless encoding refers to encoding that results in the loss of information, so there is no guarantee of a perfect reconstruction of the original data. In lossless compression, all information is retained and the data is compressed in a manner that allows perfect reconstruction.

In lossless compression, input symbols are converted to output codewords. If the compression is successful, the code words are represented by fewer bits than the number of input symbols. Lossless encoding methods include dictionary-encoding methods (eg, Lempel-Ziv), run-length encoding, numeric encoding, and entropy encoding.

United States Patent US-A-5,138-315 discloses an apparatus for encoding digital signals into variable length codewords, dividing the original data stream into N parallel-30 paths. The parallelization makes it possible to use different encoding circuits that operate in parallel, so that encoding can take place faster.

Entropy coding consists of an arbitrary lossless coding method which attempts to compress data close to the entropy boundary using known or estimated symbol probabilities. Entropy codes include the Huffman codes, arithmetic codes, and binary entropy codes. Binary entropy encoders are lossless encoders that only work on binary (yes / no) decisions.

1 OU 13 1 7 I

2 gene, often expressed as the most likely symbol (MPS) and the least likely symbol (LPS). Examples of binary entropy encoders include IBM's Q encoder and an encoder known as the B encoder. For more information regarding the B encoder, reference is made to US Patent 5,272,478 entitled "Method and Apparatus for Entropy Coding" (JD Allen), issued December 21, 1993 and assigned to the holder of the present application. Reference is also made to M.J. Gormish and J.D. Allen, "Finite State Machine Binary Entropy Coding", 10 abstract in Proc. Data Compression Conference, March 30, 1993. Snowbird, UT, biz. 449 · The B encoder is a binary entropy encoder that uses a finite state machine for compression.

Figure 1 shows a block diagram of a known compression and decompression system using a binary entropy coding unit. For encoding, data is input into the context model (CM) 101. CM 101 translates the input data into a group or series of binary decisions and provides the context bin for each decision. Both the sequence of binary decisions and the associated context bins are output from the output of the CM 101 to the probability estimation module (PEM) 102. PEM 102 receives each context bin and generates a probability estimate for each binary decision. The current probability estimate is typically represented by a class, referred to as the P class. Each P class is used for a range of probabilities. PEM 102 also determines whether or not the binary decision (result) is in its most likely state (i.e., whether the decision corresponds to the MPS). The bitstream generator (BG) module 103 receives the probability estimate (ie the P class) and the determination whether or not the binary decision was plausible as an input signal. In response, the BG module 103 produces a compressed data stream by delivering zero or more bits to the output as a representation of the original input data.

For decoding, CM 104 supplies a context bin to PEM 105 and 35 PEM IO5 supplies the probability class (P class) to the BG module 106 based on the context bin. BG module 106 is connected to receive the probability class. In response to the probability class and the compressed data, the BG module mni3l7 '3 106 returns a bit indicating whether the binary decision (i.e. the event) is in its most probable state. PEM 105 receives this bit, updates the probability estimate based on the received bit and returns the result to CM 10¾. CM 10¾ 5 receives the return bit and uses the return bit to generate the original data and update the context bin for the next binary decision.

One problem with decoders using binary entropy codes, such as IBM's Q encoder and B encoder, is that they are slow even when implemented in hardware.

Their operation requires a single large slow feedback loop. To reformulate the decoding process, the context model uses previous decoded data to produce a context. The probability estimation module uses the context to produce a probability class. The bitstream generator uses the probability class and the compressed data to determine whether the next bit is the plausible or not plausible result. The probability estimation module uses the plausible / implausible result to produce a result bit (and update the probability estimate for the context). The result bit is used by the context model to update its history of previous data. All of these steps are required to decode a single bit. Although the context model must wait until the result bit has updated its history before it can provide the next context, the decoding of the next bit must wait. It is desirable to avoid the need to wait for the feedback loop to complete before decoding the next bit. In other words, it is desirable to decode more than one bit or codeword at a time to increase the rate at which compressed data is decoded.

Another problem with decoders using binary entropy codes is that variable length data must be processed. In most systems, the codewords to be decoded have variable lengths. Alternatively, other systems encode variable length symbols (unencoded data). When processing variable length data, it is necessary to pass the data at the bit level to provide the correct subsequent data for the decoding or encoding operation. These bit level manipulations on the data stream may require expensive and / or slow hardware and / or software. Furthermore, prior art systems require this pass-through to be performed in time-critical feedback loops that limit the performance of the decoder. It would also be advantageous to remove the bit level manipulation of the data stream from the time critical feedback loops so that parallelization can be used to increase the speed.

The present invention provides a lossless compression and decompression system. The present invention also provides a real-time encoding unit and a real-time decoding unit which encode and decode the data in parallel. The encoder and decoder of the present invention create a balanced parallel entropy system that performs both real-time and real-time decoding in high-speed, low-cost hardware.

Brief description of the invention

The invention relates in one aspect to a method for encoding a data stream comprising the following steps: generating codeword information as a representation of the data stream in response to the data stream, wherein the codeword information comprises a number of codewords and in which further several code words are generated from the data of the data stream which is processed in parallel; generating coded data in response to the codeword information, characterized in that the coded data generating step means that each of the plurality of codewords in the codeword information is output such that the sequence of codewords is output is based on the beginning of the portion of the data stream represented by each codeword.

In another aspect, the invention relates to an encoding system for encoding a data stream, the encoding system comprising an encoder connected to receive the data stream in order to generate codeword information including codewords and wherein further codewords are generated by the encoder. from data that is processed in parallel; and a rearrangement unit coupled to the encoder to generate coded data in response to the codeword information, characterized in that the rearrangement unit is the codewords generated by the encoder

10 0 13 1 T

5 rearranged in a decoding order such that the order of the output codewords is based on the beginning of the portion of the data stream represented by each codeword.

A further aspect of the invention relates to a decoding system 5 for decoding a data stream with a number of codewords generated by an encoding system according to the invention, the decoding system being an entropy decoder, comprising: a number of bitstream generators for receiving the data stream ; and a state table coupled to the number of bitstream generators to provide a probability estimate to the number of bitstream generators, the number of bitstream generators generating a decoded result for each code word in the data stream in response to the probability estimate using an Rn (k) code for multiple values of n, and wherein the state table further includes a first number of permissions and a second number of states, with transitions between different codes in the first number of states being faster when merged into the first number of states than transitions between codes on transition in the second number of states.

In a further aspect, the invention relates to a decoding system for decoding a data stream with a number of codewords, which is generated by an encoding system according to the invention, the decoding system comprising: a shifter for receiving the data stream and for delivering correct aligned coded data; 25 a run-length decoder coupled to the shifter for receiving the properly aligned coded data as codewords for determining the codeword type; a probability estimator coupled to the run-length decoder to determine the run-length decoder code such that the run-length decoder generates a run-length and an indication as to whether the LPS has occurred in response to each code word; the shifter comprising a variable-length shift mechanism for shifting codewords from the data stream; * and a plurality of registers connected for receiving codewords from the data stream in response to the shift mechanism such that the aligned coded data is output as a sequence of code words.

A further aspect of the invention relates to a decoding system for decoding a data stream with a number of codewords, which is generated by a coding system according to any one of claims 28 to 52, wherein the decoding system comprises: a FIFO structure intended for reception of the data; a context model for delivering contexts; a memory coupled to the context model for storing status information 5, the memory providing status information in response to each context provided by the context model; a number of decoders intended to receive coded data from the FIFO structure and the memory for decoding codewords supplied by the FIFO structure using status-in-10 formation from the memory, the number of decoders providing run counts that can be generated for some codes.

A further aspect of the invention relates to a decoding system for decoding a data stream with a number of codewords, generated by an encoding system according to any one of claims 78 to 8l, wherein the decoding system comprises: a context model for providing a context -bin; a memory coupled to the context model to provide a probability status based on the context bin; a memory coupled logic for generating a probability class based on the probability state; a decoder coupled to the logic for generating a release signal based on the probability class; a plurality of bit generators coupled to the decoder and connected to receive the encoded data, each of the plurality of bit generators being for at least one distinct code, wherein the decoder releases one of the plurality of bit generators based on the probability class such that said one of the number of bitstream generators decode the encoded data.

A further aspect of the invention relates to a method of decoding input data encoded with the method of claim 82, comprising the steps of: providing a context bin; accessing a memory using the context bin to obtain a probability state; generating a probability class based on the probability state; releasing one of a plurality of bitgenic retors, each of the plurality of bit generators being allocated to at least one distinct code such that only this one distinct code is used for decoding and such that said one from the number of bitstream generators uses the coded data deco 10013Π 7th.

A further aspect of the invention relates to a method of decoding data encoded with the method of any one of claims 1 to 7. which method comprises the following steps: loading a counter value into a counter associated with each run counter the counter value corresponding to the dimensions of a codeword memory used during encoding when a new run is started, said counter value being loaded when a new codeword is retrieved for each run counter; deciding the counter value every time a code word is retrieved; and resetting the bit generator state associated with each new codeword if the counter is decremented to zero.

A further aspect of the invention relates to a method of decoding data encoded by the method of any one of claims 1 to 7, the method comprising the steps of incrementing a counter value whenever a code word is requested, the counter value containing a current time indication; storing the counter value as a stored time indication if a first code word is started; compare the stored time indication plus the size of an encoding memory with the current time indication; wherein the bit generator state is reset for the first codeword and a second codeword is requested if the current time indication is larger than the stored time indication plus the size of the coding memory.

A further aspect of the invention relates to a method for decoding data encoded with the method according to any one of claims 1 to 7, which method comprises the following steps: storing an index corresponding to a codeword, the index being stored is queued and the index is stored if the codeword is requested; mark the entry of the queued index as invalid; storing the codeword in the entry and marking the entry as valid when the codeword is completed; outputting data from the queue to be decoded, the codeword being output for decoding if the queue input 35 is valid; and outputting data from the queue input and indicating to the decoder that the data is valid if the queue input is marked invalid when outputting data from the queue, the bit generator status information being reset by the decoder in 1001317 8 response on the receipt of data if the queue is marked as invalid.

A final aspect of the invention relates to a decoder for decoding a data stream with a number of codewords, which is generated by an encoding system according to any one of claims 28 to 52, which comprises decoder: a context modeling mechanism for providing contexts; a memory coupled to the context model for storing status information, the memory providing status information in response to each context provided by the context model; and a number of decoders coupled to the memory for decoding codewords using status information from the memory.

Brief Description of the Drawings The present invention will be more fully understood from the detailed description below and from the accompanying drawings of various embodiments of the invention which, however, are not to be construed as limiting the invention to specific embodiments, but serve only for explanation and a better understanding.

Fig. 1 shows a block diagram of a prior art binary entropy encoding and decoding unit.

Fig. 2A is a block diagram of the decoding system of the present invention.

FIG. 2B is a block diagram of an embodiment of the coding system of the present invention.

Fig. 2C is a block diagram of an embodiment of the decoding system of the present invention in which context bins are processed in parallel.

FIG. 2D is a block diagram of an embodiment of the deco system of the present invention with which probability classes are processed in parallel.

Fig. 3 illustrates a non-collapsed code stream of the present invention.

FIG. 4 illustrates an embodiment of the collapsed code stream derived from an example data set.

Fig. 5 shows an example of a probability estimation table and bitstream generator for the R encoder according to the present invention.

Fig. 6 is a block diagram of an embodiment of an encoder according to the present invention.

Fig. 7 is a block diagram of an embodiment of a bitgenic retor according to the present invention.

Fig. 8 is a block diagram of an embodiment of the rearrangement unit of the present invention.

Fig. 9 is a block diagram of an embodiment of the runteling rearrangement unit of the present invention.

FIG. 10 is a block diagram of another embodiment of the run count rearrangement unit of the present invention.

Fig. 11 is a block diagram of an embodiment of the bit pack unit of the present invention.

Fig. 12 is a block diagram of an embodiment of the packing logic of the present invention.

Fig. 13 is a block diagram of an embodiment of the encoding bit generator of the present invention.

Fig. 14A is a block diagram of an embodiment of the decoding system of the present invention.

FIG. 11B is a block diagram of the decodetronity of the present invention.

Fig. 1C is a block diagram of an embodiment of the FIF0 structure of the present invention.

Fig. 15A illustrates an embodiment of the decoding pipeline 25 of the present invention.

Fig. 15B illustrates an embodiment of the decoder of the present invention.

Fig. 16a is a block diagram of an embodiment of the slip-through unit of the present invention.

FIG. 16B is a block diagram of another embodiment of the pass-through unit of the present invention.

Fig. 17 is a block diagram of a system that has an external context model.

Fig. 18 is a block diagram of another system that has an external context model.

Fig. 19 is a block diagram of an embodiment of a decoder according to the present invention.

Fig. 20 is a block diagram of an embodiment of a decoder 1001317 10 unit with separate bit generators.

Fig. 21 is a block diagram of an embodiment of a bit generator according to the present invention.

Fig. 22 is a block diagram of an embodiment of the long run unit of the present invention.

Fig. 23 is a block diagram of an embodiment of the short run unit of the present invention.

Fig. 24 is a block diagram of an embodiment of the initialization and control logic of the present invention.

FIG. 25 is a block diagram of an embodiment for rearranging data using a tracking decoder.

Fig. 26 is a block diagram of another embodiment of a rearrangement unit.

Fig. 27 is a block diagram of another embodiment of a rearrangement unit using a combined queue.

Fig. 28 is a block diagram of a high bandwidth system in which the present invention is applied.

Fig. 29 is a block diagram of an adjusted bandwidth system employing the present invention.

FIG. 30 is a block diagram of a real-time Functioning video system using the present invention.

Fig. 31 illustrates an embodiment of the encrypted data memory according to the present invention.

Fig. 32 is a timing chart of the decoding according to the present invention.

Detailed description of the invention

A method and apparatus for encoding and decoding data in parallel is described. Numerous specific details will be set forth in the following description, such as specific numbers of bits, numbers of coders, specific probabilities, data types, etc., to provide an in-depth understanding of the preferred embodiments of the present invention. It will be clear to the skilled person that the present invention can also be practiced without these specific details. Also known per se circuits are shown in block diagram form and not in detail in order to avoid unnecessary detailing of the present invention.

1001317 11

Some portions of the following detailed descriptions are presented in the form of algorithms and symbolic representations of operations on data bits in a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing techniques to most effectively convey the nature of their work to other experts. An algorithm is here, and generally understood, as a self-coherent series of steps leading to a desired result. These steps require physical manipulations or physical quantities. Generally, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise manipulated. It has sometimes proved easy, mainly for the sake of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like.

However, it should be remembered that all these and similar terms must be associated with the appropriate physical quantities and serve only as suitable labels to be affixed to this quantity. Unless specifically stated otherwise in the following discussions, it will be understood that within the present invention, the discussions in which terms such as "processing" or "computing" or "computation" or "determination" or "display" or the like refer to the actions and processes of a computer system or a similar electronic computer unit, which manipulates and transforms data, represented as physical (electronic) quantities within the registers and memories of the computer system, into other data similarly represented by physical quantities within the memories or registers or other computer system information storage, transmission, or display units.

The present invention also relates to equipment for performing the operations. This equipment may be specially constructed for the required purposes, or it may consist of a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. The algorithms and graphics presented in this description are not inherently related to a particular computer or other device. Various general purpose machines can be used with programs in accordance with what is discussed herein, but it may also be suitable to construct more specialized equipment to perform the required method steps. The required structure for several of these machines will be apparent from the description below. In addition, the present invention is not discussed in connection with a particular programming language. It will be appreciated that a wide variety of programming languages can be used to implement the teachings of the invention discussed herein.

Parallel entropy coding

The present invention provides a parallel entropy coding system. The system includes an encoder and a decoder. In one embodiment, the encoder performs real-time data encoding. At the same time, an embodiment of the decoding unit according to the present invention performs decoding of data in real time. Together, the real-time encoder and decoder form a balanced encoder.

The present invention provides a system that decodes losslessly encoded data in parallel. The data is decoded in parallel using multiple decoding resources. Each of the multiple decoding resources is allocated data (for example, codewords) from the data stream for decoding. The allocation of the data stream is done while the decoding resources simultaneously decode data, thereby decoding the data stream in parallel. In order to allow the allocation of data in such a way that efficient use is made of the decoding resources, the data stream 30 is ordered. This is referred to as parallelizing the data stream. The ordering of data allows each decoding resource to decode some or all of the encoded data without waiting for feedback from the context model.

Fig. 2A illustrates the decoding system of the present invention without the slow feedback loop of the prior art. An input buffer 204 receives coded data (i.e., codewords) and a feedback signal from decoder 205 and supplies coded data in predetermined order (e.g. context bin 1001317 13 order) to decoder 205 of the present invention which decodes the coded data. Decoder 205 includes multiple decoders (e.g., 205A, 205B, 205C, etc.).

In one embodiment, each of the decoders 205A, 205B, 205C, etc. is supplied with data for a group of contexts. Each of the decoders in the decoder 205 is provided with encoded data for each context bin in its group of contexts from the input buffer 204. Using this data, each decoder 205A, 205B, 205C, etc. produces the decoded data for its group from con-10 text-bins. The context model is not required to associate the encoded data with a particular group of context bins.

The decoded data is sent from the decoder 205 from decoded data storage circuit 207 (e.g., 207A, 207B, 207C, etc.). It is noted that the decoded data storage circuit 207 can also store intermediate data that is neither encoded nor decoded, such as run counts. In this case, the data in the decoded data storage circuit 207 is stored in a compact but not entropy encoded form.

The independently operating context model 206 is connected to receive previously decoded data from the decoded data storage circuit 207 (ie, 207A, 207B, 207C, etc.) in response to a feedback signal it sends to the decoded data storage circuit 207. Therefore, there are two independent feedback loops, one between the decoder 205 and the input buffer 204 and a second-25th between the context model 206 and the decoded data storage circuit 207. Since the large feedback loop is eliminated, the decoders in the decoder 205 (e.g. 205A, 205B, 205C, etc.) are able to decode their associated codewords as soon as they are received from the input buffer 204.

The context model provides the memory part of the coding system and divides a data set (eg an image) into different categories (eg context bins) based on the memory. In the present invention, the eontext bins are considered independently ordered datasets. In one embodiment, each group of 35 context bins has its own probability estimation model, and each context bin has its own state (where probability estimation models are common). Each context bin can therefore use a different probability estimation model and / or bitstream 1001317 '1 * 4 generator.

The data is thus ordered, or parallelized, and data from the data stream is allocated to individual encoders for decoding.

5

Adding parallelization to the classic entropy coding model

For the parallelization of the data stream, the data can be divided depending on their context, probability, coverage, codeword sequence (based on codewords), etc. Rearranging the encoded data stream is independent of the parallelization, a method used for parallelizing of data or probability at any other point. A parallel coding portion of an encoding system according to the present invention, fed by data differentiated by the context model (CM) is shown in Fig. 2B.

In Fig. 2B, the context-dependent parallel coding portion includes the context model (CM) 2lk, probability estimation modules (PEMs) 215-217 and bitstream generators (BGs) 218-220. CM 2lk is connected to receive coded input data. CM 21 * 4 is also paired 20 with the PEMs 215-217. PEMs 215-217 are respectively connected to BGs 218-220 which output currents 1, 2 and 3, respectively, at the output. Each pair of a PEM and a BG forms an encoder. The parallel encoding circuit shown therefore comprises three encoders. Although only three parallel encoders are shown, any number of encoders can be used.

CM 21 * 4 divides the data stream into different contexts in the same way as a conventional CM and sends the multiple streams to the parallel hardware encoding resources. Individual contexts or groups of contexts are directed to separate probability estimation units (PEMs) 215-217 and bit generators (BGs) 218-219. Each of the BGs 218-220 outputs an encoded data stream at its output.

Fig. 2b is a block diagram of an embodiment of the deco-35 portion of the decoding system of the present invention. Fig. 2C shows a context-dependent parallel decoding unit provided with the BGs 221-223, the PEMs 22 * 4-226 and the CM 227. The code streams 1-3 are coupled to the respective BGs 221-223. The 10013171 15 BG's 221-223 are also paired with the respective PEM's 224-226. The PEMs 224-226 are connected to the CM 227 which outputs the reconstructed input data. At the inputs are various code streams, shown as the code streams 1-3 · One code stream is assigned asm each a PEM and a BG. Each of the BG 221-223 issues a bit indicating whether the binary decision is in its more likely state, which bit in the PEMs 224-226 is used to output coded bits (e.g., the binary decision). Each of the PEMs 224-226 is associated with one of the BGs 221-223, 10 indicating which code to use to generate data stream based on its input code stream. CM 227 produces a decoded data stream by selecting the decoded bits from the bitstream generators in the correct order, recreating the original data. The CM 227 therefore obtains the decompressed data bit from the appropriate PEM and BG by basically rearranging the data in the original order. It should be noted that the control current for this design runs in the opposite direction to the data flow. The BG and PEM can decode data before the CM 227 needs it and are therefore one or more 20 bits ahead. Alternatively, the CM 227 may request (but not receive) a bit from a BG and PEM and then request one or more bits from other BGs and PEMs prior to using the originally requested bit.

The configuration shown in Figure 2C is designed to permanently couple the PEM and BG 25 together. IBM's Q encoding circuit is a good example of an encoding circuit with PEM and BG coupled. Local feedback loops between the two do not fundamentally limit the behavior of the system.

In another design, the PEM can differentiate the data and send it to parallel BG units. There would then be only one CM and PEM and a number of BG. Haptman adaptive coding and finite state coding can be used in this manner.

A similar decoding scheme using the PEM to differentiate data and send it in parallel to BGs is shown in Figure 2D. In this case, the probability classes are handled in parallel and each bit stream generator is assigned to a specific probability class and receives knowledge of the result. Referring to Fig. 2D, the coded data streams 1-3 1001317 »16 are connected to one of a number of bitstream generators (e.g., BG 232, BG 233, BG 234, etc.) connected for reception. Each of the bitstream generators are coupled to the PEM 235 · PEM 235 is also coupled to CM 236. In this configuration, each of the bit-5 stream generators decodes encoded data and the decoding results are selected by PEM 235 (instead of CM 236). Each of the bitstream generators receives coded data from a source associated with a probability class (i.e., where the coded data can be from any context bin). The PEM 235 selects the bitstream generators using a probability class. The probability class is dictated by the context bin provided to it by the CM 236. In this way, decoded data is produced by processing probability classes in parallel.

Numerous implementations for parallel coding systems according to the invention exist. In one embodiment, the encoded data streams corresponding to the multiple context bins can be collapsed into one stream ordered by the questions of the various encoders. In an embodiment of the present invention, the encoded data is arranged such that each encoder is constantly fed data even if the encoded data is supplied in one stream to the decoder. It is noted that the present invention functions with all types of data, including image data.

By using small simple encoders that can be cheaply multiplied in integrated circuits, the encoded data can be quickly decoded in parallel. In one embodiment, the encoders are implemented in hardware using chips with a field-programmable array of ports 30 (FPGA) or an application-specific integrated circuit chip (ASIC) configured as a standard cell. The combination of parallelization and simple bitstream generators makes it possible to decode the encoded data at rates higher than the prior art decoding units while increasing the compression efficiency of the prior art decoding systems. maintained or even improved.

1001317 '17

Channel arrangement of multiple data streams

There are many different design points and problems that affect the behavior of the system. A few of them will be mentioned below. The embodiments shown in fig.

However, 2B and 2C (and 2D) use multiple code streams. Parallel channel systems that can accommodate such an embodiment are conceivable: multiple phone lines, multiple heads on a disk drive, etc. In some applications, only one channel is available or convenient. If multiple channels are required, the bandwidth may be misused due to the burst-like nature of the individual code streams.

In one embodiment, the code streams are merged and sent coherently to the decoder. An introductory heading contains pointers to the starting bit location of each stream. Fig. 3 illustrates an embodiment with this arrangement of data. The three pointers 1310-303 in Fig. 3 point to the start location in the merged code of the respective code streams 1, 2 and 3. The complete compressed data file is available in a buffer of the decoder. If necessary, the codewords of the appropriate location are retrieved via the appropriate pointer. The pointer is then updated to the next code word in the code stream.

It is noted that this method requires that a fully encoded frame be stored in the decoder and, for practical purposes, in the encoder. If a real-time operating system, or a stream with less burst-like data, is requested, two frame buffers can be used for storage in both the encoder and the decoder.

Data order by codeword order It is noted that a decoder decodes codewords in a certain deterministic order. With parallel coding, the order of the questions to the code stream is deterministic. Thus, if the code words of parallel code streams can be interleaved in the correct order at the encoder, a single code stream will suffice. The codewords are delivered to the decoder in the same order on a "just-in-time" basis. At the encoder, a model of the decoder determines the codeword order and packs the codewords in a single stream. This model can be an actual decoder 1001317 18.

A problem in delivering data to the parallel decoder elements arises if the data length is variable. Unpacking a stream of variable length code words requires using a bit shifter to align the code words. Bitver sliders are often expensive and / or slow when implemented in hardware. The control of the bit shifter depends on the dimensions of the particular codeword. This control feedback loop prevents variable length shift from being performed too quickly. The advantages of feeding multiple decoders with a single stream cannot be realized if the process of extracting the stream is performed in a single bit shifter that is not fast enough to keep track of the number of decoders.

The solution proposed in this invention separates the problem of distributing the encrypted

V

data to the parallel encoders and the alignment of the variable length codewords for decoding. The code words in each independent code stream are packaged in fixed length words, referred to as concatenated words. At the decoder end of the channel, these collapsed words can be distributed over the parallel decoders with fast hardwired data lines and a simple control circuit. .

It is convenient if the collapsed word length is greater than the maximum codeword length, so that in each collapsed codeword there are at least enough bits to complete one codeword. The interleaved words can contain multiple code words and parts of code words. Fig. H illustrates the collapse of an example group of parallel code streams.

These words are collapsed depending on the need at the decoder. Each independent decoder receives a fully interlocked word. The bit shift operation is now performed locally at each decoder, thereby maintaining parallelization in the system. It is noted in Fig. 4 that the first codeword in each interleaved word is the lowest remaining codeword in the group 35. For example, the first interleaved words come from code stream 1, starting with the lowest code word (i.e. # 1). This is followed by the first interleaved word in code stream 2 and then by the first interleaved word in code stream 3 · The first 1001317 19 next lowest code word that is not entirely contained in an already ordered interleaved word is # 7- Therefore, the following word in the stream the second word of codestream 2 interlocked.

In another embodiment, the order in which the consecutive 5 group of interleaved words is (eg the codeword starting with codeword # 8 in stream 1, the codeword starting with codeword # 7 in stream 2, the codeword starting with codeword # 11 in stream 3) are included in the interleaved code stream based on the first codeword of the preceding set of interleaved words (eg the 10 codeword starting with codeword # 1 in stream 1, the codeword starting with codeword # 2 in stream 2, the codeword starting with codeword # 4 in stream 3) and ordered from the collapsed word with the first codeword with the lowest number to the collapsed word with the first codeword with the highest number. Therefore, since in this case the interleaved word starting with codeword # 1 was the first, the next interleaved word in stream 1 is the first of the second group of interleaved words to be interleaved in the interleaved stream, followed by the next interleaved word in stream 2 and then the next interleaved word in stream 3 · It should be noted that after the second group of interleaved words has been inserted into the interleaved stream, the next interleaved word in stream 2 will be the next interleaved word to be inserted in the stream because codeword # 7 is the lowest codeword in the second group of 25 words collapsed (followed by codeword # 8 in stream 1 and then codeword # 11 in stream 3)

Using the actual decoder as a data stream model unit solves all design choices and delays in creating the collapsed stream. This is not a major cost for duplex systems that already have both encoders and decoders. It should be noted that this can be generalized to any parallel group of variable length data words (or different sizes) that are included in a deterministic order.

35

Types of codes and bitstream generators for parallel decoding

The present invention may employ existing encoders, such as Q encoders or B encoders, as bitstream 1001317 generating elements that are replicated in parallel. However, other encoders and codes can also be used. The encoders and their associated codes used within the scope of the invention are simple encoders.

In the present invention, using a bitstream generator with a simple code instead of a complex code, such as the arithmetic code used by the Q encoder or the multi-state codes used by the B encoder -ness, benefits. A simple code is advantageous because the hard-10 ware implementation is much faster and easier and requires less silicon than a complex code.

Another advantage of the present invention is that the coding efficiency can be improved. A code using a finite amount of state information cannot perfectly meet the Shannon entropy limit for any probability.

V

Hardware-implemented codes, known in the art, that allow multiple probabilities or contexts to be handled with a single bitstream generator, have limitations that reduce coding efficiency. Removing the constraints necessary for multiple contexts or probability classes allows the use of codes closer to the Shannon entropy boundary.

R codes The code (and encoder) used in an embodiment of the present invention is referred to as the R code. R codes are adaptive codes that convert a variable number of identical input symbols into a code word. In one embodiment, the R codes are parameterized so that many different probabilities can be handled by a single decoder design. In addition, the R codes of the present invention can be decoded by simple and high speed hardware.

According to the present invention, R codes are used by an R encoder to perform encoding or decoding. In an embodiment, the R encoder consists of a combined bitstream generator and probability estimation module. For example, in Fig. 1, an R encoder may comprise the combination of the probability estimation module 102 and bitstream generator 103 1001317-121 and the combination of the probability estimation module 105 and bitstream generator 106.

Code words represent runs of the most likely symbol (MPS). An MPS represents the outcome of a binary decision with a probability of more than 50%. On the other hand, the least likely symbol (LPS) represents the outcome of a binary decision with a probability of less than 50%. It is noted that the two outcomes are equally likely and it is not important whether MPS or LPS is issued as long as both the encoder and the decoder make the same decision. The resulting bit sequence in the compressed file is shown in Table A for a given parameter designated MAXRUN.

15 Table A - Bit Generation Coding

Code word Meaning 0 MAXRUN vein consecutive MPSs IN N consecutive MPSs followed by LPS,

N <MAXRUN

20 For coding, the number of MPSs in a run is counted by a simple counter. If this counter is equal to the MAXRUN counter value, a 0 code word is emitted into the code stream and the counter is reset. If an LPS occurs, a 1 followed by the bits N, which uniquely describe the number of MPS symbols before the LPS 25, is emitted into the code stream. (It should be noted that there are multiple rules for assigning the N bits describing the run length). The counter is reset again. It should be noted that the number of bits required for N depends on the value of MAXRUN. It is further noted that the 1's complement of the 30 codewords can be used.

If the first bit in the code stream is 0, then the value of MAXRUN is input to the MPS counter for decoding and the LPS indication is cleared. The 0 bit is then skipped. If the first bit is 1, then the next bits are examined to find bits 35 N and the correct counter reading (N) is inserted into the MPS counter and the LPS indicator is set. Then, the 1001317 22 code stream bits containing the IN code word are skipped.

R codes are generated according to the rules in Table A. It is noted that the definition of a given R code Rx (k) is defined by MAXRUN. For example: 5 MAXRUN for Rx (k) = x * 2 * '1, so 10 MAXRUN for R2 (k) = 2 * 2k * \ MAXRUN for R3 (k) = 3 * 2 *' 1, etc ...

It is noted that R codes are a subset of the Golomb codes. 15 It should also be noted that Rice codes only use R2 (·) codes. The R codes allow the use of both R2 (k) and R3 (k) codes and other Rn (k) codes if desired. In one embodiment, R2 (k) and R3 (k) codes are used. It is noted that Rn exists for n = 2 and n is equal to any odd number (eg R2, R3, R5. 20 R7, R9. RH, R13. R15) · In one embodiment, for the R2 (k) code the run count r encoded in N; the run count r is described in k bits so that IN is represented by k + 1 bits. Also, in an embodiment for an R3 (k) Code, the bits may contain N 1 bit indicating whether n <2 (> <'1> or n ^ ** "1 * and either k-1 or k 25 bits to represent the to indicate run count r so that the variable N is expressed by a total of k and k + 1 bits In other embodiments, the 1's complement of N can be used in the codeword In this case, the MPS tends to with many zeros and LPS tend to produce code streams with many ones.

Table B, C, D and E show some efficient R codes used in an embodiment of the present invention. It is pointed out that other run length codes can be used within the scope of the invention. An example of an alternative run length-35 code for R2 (2) is shown in Table F. Tables G and H show examples of the codes used in one embodiment.

1001317 23

Table B - R2 (0) Table C - R2 (1)

Uncoded Codeword Uncoded Codeword data data ^ 9 sesse aaacsBssm 0 0 00 o 5 11 01 10 1 11

Table D - R3 (l) Table E - R2 (2)

Uncoded Codeword Uncoded Codeword 10 data data

SSS & SS ^ S ^^^^^^ SSSSS OBBEBSTOnaBSSSSSS ^ B

000 0 0000 o 001 100 0001 100 01 101 001 101 1 11 01 110 15 1 111

Table F - Alternative R2 (2), Table G - Alternative R3 (2) Code

Alternative R2 (2) Preferred R3 (2) 0000 0 000000 0 20 0001 111 000001 1000 001 101 00001 1010 01 110 0001 1001 1 100 001 1011 01 110 25. 1 111 1001317 24

Table Η - Other alternative R2 (2) Code

Preference R2 (2} 0000 0 5 0001 100 001 110 01 101 1 111 10 Alertness estimation model for R codes

In one embodiment, the R2 (0) code does not encode: a 0 at the input is encoded at 0 and a digit 1 at the input is encoded at 1 (or vice versa) and is optimal for probabilities equal to 50%. The R2 (1) code of the preferred embodiment 15 is optimal for probabilities close to 0.707 (i.e.

70.7%) and the R3 (l) is optimal for a .794 probability (79.4%). -The R2 (2) code is optimal for the 0.84l probability (84.1%). Table I below shows the nearly optimal run length code where the probability deviation is defined by the following formula:

Probability deviation = -1og2 (LPS).

1001317 25

Table I

Probability Probability Best Golomb Code Deviation 0.500 1.00 R2 (0) 0.707 1.77 R2 (L) 5 Ο, Μΐ 2.65 R2 (2) 0.917 3.59 R2 (3) 0.958 4.56 R2 (4) 0.979 5.54 R2 (5) 0.989 6.54 R2 (6) 10 0.995 7.53 R2 (7) 0.997 8.53 R2 (8) 0.999 9.53 R2 (9)

It should be noted that the codes are nearly optimal because the probability range, indicated by the probability deviation, occupies the space relatively evenly, although the optimal probabilities in the higher k values do not differ as much as in the lower k values.

Reference is made to the probability where an R code is optimum 20 times. In fact, only R2 (2) satisfies the entropy curve. The real consideration is for what range of probabilities a given R encoder is better than any other R codes in a given class. The following tables provide the probability ranges for the class of R2 codes and the class of R2 and R3 codes.

For the class of R2 codes from 0 to 12 the ranges can be found in table J below. When only R2 codes are used, for example R2 (0) is best if 0.50 £ probability £ 0.6l80. Similarly, R2 (l) is best when 0.6l80 £ probability £ 0.7862.

30 10 U 13 1 7 26

Table · J - R2 codes from 0 to 12 Code Probabilities R2 (0) 0.6180 R2 (l) 0.7862 5 R2 (2) 0.8867 R2 (3) 0.9416 R2 (4) 0.9704 R2 ( 5) 0.9851 R2 (6) 0.9925 10 R2 (7) 0.9962 R2 (8) 0.9981 R2 (9) 0.9991 R2 (10) 0.9995 R2 (ll) 0.9998 15 R2 (12)

For the class of R2 and R3 codes, the solutions are shown in Table K below. For example, when R2 and R3 codes are used, R2 (1) is best if 0.6l80 s probability £ 20 0.7549.

1001317 27

Table K - R2 and R3 codes lengths less than or equal to 13 bits

Code Probabilities R2 (0) 0.6180 5 R2 (l) 0.75 * 19 R3 (l) 0.8192 R2 (2) 0.8688 R3 (2) 0.9051 R2 (3) 0.9321 10 R3 ( 3) 0.951 * 1 R2 (4) 0.9655 R3 (* 0 0.975 * 1 R2 (5) 0.9826 R3 (5) 0.9876 15 R2 (6) 0.9913 R3 (6) 0.9938 R2 ( 7) 0.9956 R3 (7) 0.9969 R2 (8) 0.9978 20 R3 (8) 0.998 * 1 R2 (9) 0.9989 R3 (9) 0.9992 R2 (10) 0.9995 R3dO) 0.9996 25 R2 (ll) 0.9997 R3 (ll) 0.9998 R2 (12) 100 1317 28

An R2 (k) for a fixed k is called a run length code. However, a solid k is only good for a range of probabilities. It is noted that if the code is close to an optimal probability, an R code of the present invention uses a 0 -5 and IN code words of roughly equal frequency. In other words, half of the time, the R encoder of the present invention outputs one code at the output and the other half of the time, the R encoder issues another code. By examining the number of 0 and IN code words, it can be determined whether the best code is used. That is, if too many IN code words are output at the output, the run length is Icing; on the other hand, if too many 0 code words are output, the run length is too short.

The probability estimation model used by Langdon examines the first bit of each codeword to determine if the source probability is above or below the current estimate. See G.G. Langdon, "An Adaptive Run-Length Coding Algorithm," IBM Technical Disclosure Bulletin, Vol. 26, No. 7B, December 1983 · Based on this finding, k is increased or decreased. For example, if a code word indicating MPS is found, the probability estimate is too low. According to Langdon, therefore, k is increased by 1 for every 0 codeword. If a code word indicating less than MAXRUN MPS followed by an LPS (e.g. IN code word) is found, the probability estimate is too high. According to Langdon, k is then reduced by 1 for each IN codeword.

The present invention allows for a more complex probability estimate than a simple increase or decrease of k by 1 with each codeword. The present invention includes a probability estimation module state that determines the code to be used. 30 Many states can use the same code. Codes are assigned to states using a state table or state machine.

In one embodiment of the present invention, the likelihood estimate changes state with each codeword at the output. The probability estimation module therefore increases or decreases the probability estimate depending on whether a codeword starts with a 0 or a 1. For example, if a "0" codeword is output, an increase in the 1001317 1 29 estimate of the MPS -likely place. On the other hand, if a "1" codeword is output, the MPS probability estimate is decreased.

The prior art Langdon encoder uses only R2 (k) codes and increases or decreases k for each code word. The present invention alternately uses R2 (k) and R3 (k) codes in conjunction with the state table or state machine so that the rate of adaptation can be tailored to the application. That is, if there is a small amount of stationary data, then the adaptation must be faster resulting in more optimal encoding, and if there is a larger amount of stationary data present then the adaptation time may be longer so that the encoding can be chosen to achieve better compression of the rest of the data. It is noted that if variable numbers of state changes can occur, application-specific features can also influence the rate of adaptation. Due to the nature of the R codes, the estimate for the R codes is simple and requires little hardware, although it is very powerful. Fig. 33 illustrates the plot of coding efficiency (code length normalized with respect to entropy) as a function of MPS probability. Fig. 33 shows how some of the R codes of the present invention cover the probability space. As an example, Figure 33 shows that for an MPS probability of about 0.55, the efficiency of the R2 (0) code equals 1.01 (or 1% worse than) the entropy limit. In contrast, the R2 (l) code has an efficiency of 1.09 (or 3% worse than) the entropy limit. This example shows that using the wrong code for this particular low probability case causes a &% loss in coding efficiency.

The inclusion of the R3 (k) codes makes it possible to cover a larger probability space with greater efficiency. An example of a probability estimate state table of the present invention is shown in Fig. 5. The probability estimate state table of Fig. 5 shows both a state counter and the code associated with each of the individual states in the table. It is noted that the table has both positive and negative states. As shown, the table has 37 positive states and 37 negative states, including zero states. The negative states indicate a different MPS from the positive 10013Π30 consents. In one embodiment, the negative states can be used if the MPS is equal to 1 and the positive states can be used if the HPS is equal to 0 or vice versa. It is noted that the table shown in Fig. 5 is only an example 5 and that other tables may have more or less states with different state assignment.

Initially, the encoder is in state 0 which is the R2 (0) code (i.e. no code) for a probability estimate equal to 0.50. After processing each codeword, the operator is increased or decreased depending on the first bit of the codeword. In one embodiment, at a code word 0, the value of the state counter is increased; a code word starting with 1 decreases the value of the state counter. Each codeword therefore causes a change in the state of the state counter. In other words, the state of the probability estimation module changes. However, the successive states can be associated with the same code. In that case, the probability estimate is obtained without the codes changing with each code word. In other words, the state is changed for each codeword; however, the condition is depicted in the same probabilities at certain times. For example, states 5 through -5 all use the -R2 (0) code, while states 6 through 11 and -6 through -11 use the R2 (1) code. Using the state table of the present invention, the probability estimate can remain with the same encoder in a non-linear fashion.

It is noted that more states with the same R code are included for the lower probabilities. This has been done because the loss of efficiency if the wrong code is used at 30 lower probabilities is great. The nature of the run-length codes state table is a transition between the states after each code word. When a state table designed to change codes with each state change switches between states with lower probabilities, the code switches between a code very close to the entropy efficiency limit and a code far from the entropy efficiency limit . A state transition core thus result in a penalty (in terms of the number of encrypted data bits). Prior art probability modules, such as the Langdon probability module, lose performance because of this penalty.

In the higher probability run length codes, the penalty for staying in the wrong code isn't that great. Therefore, according to the invention, additional states are added at the lower probabilities, so that changing or switching between two correct states is increased and thereby the coding inefficiency is reduced.

It is noted that in certain embodiments, the encoder 10 may have an initial probability estimation state. In other words, the encoder can start in a predetermined state, for example state 18. In one embodiment, a different state table may be used so that some states will be used for the first symbols to allow for quick adjustment, and a second state table can be used for the remaining symbols with a slow adaptation to allow fine tuning of the probability estimate. In this way, the encoder is able to use a more efficient code faster in the encoding process. In another embodiment, the code stream could specify an initial probability estimate for each context. In one embodiment, the increases and. reductions not made by a fixed number (e.g. 1). Instead, the probability estimate state can be updated with a variable amount depending on the value of the data already processed or the amount of change in the data (stability). Examples of such tables are Tables U-Y described below.

If the state table is symmetrical, such as the example shown in Fig. 5, then only half of it (including the zero state) needs to be stored or implemented in hardware. In one embodiment, the state number is stored in complement form (s) to take advantage of this symmetry. In this way, the table can be used by taking the absolute value of the ones complement number to determine the state and examine the sign to determine whether the MPS is a 1 or 0. This allows a reduction of the hardware needed to raise or lower the state, because the absolute value of the state is used 100131T '32 for indexing the table and calculating the absolute value of the ones complement number trivially is. In another embodiment, for greater hardware efficiency, a power table can be replaced with a wired circuit or a programmable state machine. A wired switch to the code converter is one implementation of the state table.

Overview of the balanced parallel entropy coding system

The present provides a balanced parallel entropy coding system. The parallel entropy coding system includes both real time coding and decoding with high speed and low cost hardware. The present invention can be used in numerous lossless encoding applications, including, but not limited to, real-time compression / decompression of data on recordable optical or magnetic disks, real-time compression / decompression of data in computer networks, in real-time compression / decompression vein image data in a compressed frame memory in a multifunction machine (eg copier, facsimile machine, scaner, printer, etc.) and real-time compression / decompression of audio data.

Specifying the performance of an encoder requires some attention. In a straightforward design, an encoder is designed that achieves a certain speed for the original data from a sufficiently fast coded data channel. In many applications, however, the encoder aims to use the encrypted data channel efficiently. The use of the encoded data channel is affected by the maximum burst rate of the original data interface, the encoding rate and the compression performed on the data. The influence of these effects must be considered on a local amount of data depending on the buffer capacity in the encoder. It is desirable to have an encoder that utilizes your encoded data channel efficiently and yet maintains the encoding rate and a high degree of compression and is also capable of the maximum burst rate.

An encoder according to the present invention is described below. A decoder used in conjunction with the encoder is also described.

1001317 33

Coding Actually according to the present invention

Fig. 6 is a block diagram of the coding system of the present invention. In one embodiment, the encoder performs real-time encoding. Referring to FIG. 6, the encoding system 600 includes an encoding unit 602 coupled to a context model (CM) & state memory 603 for generating encoded information in the form of codeword information 604 in response to the original data 601. The codeword information 60 * 1 is received by a rearrangement unit 606 coupled to a rearrangement memory 607 · In response to the codeword information 604, the rearrangement unit 6θ6 in conjunction with the rearrangement memory 607 generates an encoded data stream 608. coding system 600 is not limited to operations on codewords and in other embodiments may operate on discrete analog waveforms, variable length bit patterns, channel symbols, alphabets, events, etc. within the scope of the present invention.

The encoder 602 includes a context model (CM), a probability estimator (PEM) and a bit stream generator 20 (BG). The context model and the PEM (probability estimator) in the encoder 602 are substantially identical to those in the decoder (except for the data flow direction). The bit generator of the encoder 602 is similar to the decoder bit generator and is described in the following. The result of the encoding by the encoder 602 is an output of zero or more bits representing the original data. In one embodiment, the output from the bitstream generator also includes one or more control signals. These control signals provide a control path for the data in the bitstream. In one embodiment, the codeword information may include a run-start indication, a run-end indication, a codeword, and an index identifying the run count (by context or probability class) for the codeword. An embodiment of the bitstream generator of the present invention is described below.

The rearrangement unit 606 receives the bits and the control signals generated by the bitstream generator (if any) from the encoder 602 and generates encoded data. In one embodiment, the coded data at the output of the rearrangement unit 1001317 34 606 includes a string of interleaved words.

In one embodiment, the rearrangement unit 606 performs two functions. The rearrangement unit 606 moves codewords from the end of runs created by the encoder to the beginning of 5 runs as needed at the decoder and combines variable length codewords into fixed length interleaved words and outputs them in the correct order as required by the decoder.

The rearrangement unit 606 uses a temporary rearrangement memory 607. In an embodiment in which the encoding is performed in a workstation, the temporary rearrangement memory 607 may be more than 100 megabytes in size. In the balanced system of the invention, the temporary storage memory 607 is much smaller (e.g., about 1 Kbyte) and fixed. Thus, in one embodiment, the real-time encoding is performed using a fixed amount of memory, even if it increases the memory required by the decoder or the bit rate (as is the case when an output is output before the completion of a run). The decoder according to the invention is able to determine the influences of the limited memory of the rearrangement unit using, for example, implicit or explicit signaling or signaling in the stream (as will be described below). The rearrangement unit 6Ο6 has a finite memory available for the rearrangement, but the "required" memory is unlimited. Both the influence of the limited memory for the end-run queue to the start-run queue and for rearranging the interleaved words should be considered.

In an embodiment of the invention, the encoding system 30 (and correspondingly also the decoding system) performs an encoding (or decoding) using a single integrated circuit chip. In another embodiment, a single integrated circuit includes the encoding system of the invention including encoder and decoder and memory. A separate external memory can be added to aid encoding. A multi-chip module or integrated circuit may include both the encoding / decoding hardware and the memory.

10013 Vi 35

The coding system according to the invention may attempt to increase the effective bandwidth by a factor of N. If the compression achieved is less than N: 1, the encrypted data channel will be used in its entirety, but the realized effective handwidth increase is only equal to the compression ratio. If the compression achieved is greater than N: 1, then the effective bandwidth is achieved with a writeable extra biindwidth. In either case, the compression achieved must extend over a local area of data defined by the buffer capacity present in the encoding system.

10

The bit generator for the encoder according to the invention

Fig. 7 shows an embodiment of the encoder bit generator according to the invention. Bit generator 701 is connected to receive a probability class and an uncoded bit {e.g. a 15 MPS or LPS indication) as input signals. In response to the input signals, the bit generator 701 outputs multiple signals at its output. Two of the output signals are control signals indicating the beginning and the end of a run (each codeword represents a run), a start signal 7H and the end-sew 712, respectively. It is possible for a run to start at the same time and end. When a run starts or ends, an "index" output signal 713 contains an indication of the probability class (or context) for the uncoded bit. In one embodiment, the index output signal 713 represents a combination of the bit probability class and a bank identifier for systems in which each probability class is replicated in various memory banks. The codeword output signal 71 ^ is used for outputting a codeword by the bit generator 701 upon termination of a run.

A memory 702 is coupled to the bit generator 701 and contains the run count for a given probability class. During bit generation, bit generator 701 reads memory 702 using the index (e.g. probability class). After reading the memory 702, the bit generator 701 performs a bit generation in the following manner. If the run count is equal to zero, the start signal 711 is first set, indicating the start of a run. If the uncoded bit is equal to the LPS then the end signal 712 is energized indicating the end of the run 10013Π36. Even if the uncoded bit is equal to an LPS, the codeword output signal 71 ** is set to indicate that the codeword is an IN codeword and the run counter reading is cleared, for example reset to zero (because it is the end from 5 th run). If the uncoded bit is equal to the LPS, the run counter is incremented and a test determines if the run counter is equal to the maximum run counter for the code. If so, the final signal 712 is energized, the codeword output signal 71 ** is zeroed and the run counter reading is cleared (e.g., 10 the run counter reading is zeroed). If the test indicates that the run counter reading is not equal to the maximum for the code, the run counter is incremented. It is noted that the index signal 713 represents the probability class received as an input signal.

According to the present invention, the generation of IN code words is performed such that their length can be determined without any further information. Table L illustrates IN codeword representations of R3 (2) codewords for the encoding and decoding unit. The decoder expects the "1" bit in an "IN" code-20 word to be equal to the LSB and the "N" counter position portion to be in the correct MSB ... LSB order. In decoding order, a variable length code word are distinguished from leading zeros without knowing which particular code is used In the coding order, the codeword is inverted and the position of the most significant "1" bit indicates the length of the "IN" codewords. in the coding order, the complement of the counter value must be inverted, this can be accomplished by inverting the 13 ~ bit counter position and then shifting it so that it is aligned with the LSB As described in detail below-30 , the bitpack unit reverses the codewords back into the decoding order This reversal of codewords does not cause increasing complexity of the bitpack unit 606 because the shift operation is anyway must be executed.

* 001317! 37

Table L - "IN" codeword representations for R3 (2) codewords

Uncoded Code Reversal of Decoding Order Encoding Order Third Word Counter Value -1-- (Counter Value is Underlined)

5 000000 0 0000000000000 0000000000000 000001 1000 00 OOOOOOOOOQQOl 00000000010QQ

00001 1010 01 000000000Q101 00000000010IQ

0001 1001 10 0000000001Q01 00000000010Q1 001 1011 11 0000000001101 0000000001011

10 01 110 0 OOOOOOOOOOQll 00000000001IQ

1 111 1 0000000000111 0000000000111

For R3 codes, generating "N" code words also requires the bit following the "1" to indicate whether there is a short or long count.

Using multiple memory devices, the invention also enables pipeline methods. In the case of a memory with multiple access ports, a read operation can be performed on the memory for an unencrypted bit while a write operation takes place in the memory for the previous unencrypted bit.

An Altera AHDL sample design

An embodiment of the encoder bit generator according to the invention includes an FPGA. The design covers all R2 and R3 ~ codes 25 to R2 (12). The AHDL (Altera Hardware description language) source code is indicated below.

The design includes multiple parts as shown in Fig. 13. To begin with, the "ENCBG" 1301 is the major part of the design within which there is logic for handling the start, end and progress of runs. Second, "KEXPAND" I302 is used to expand the probability class in the maximum run length, a variable length mask, and the length of the first long codeword for R3 codes. "KEXPAND" 1302 is identical to the decoding function of the same name. Third, the 10013Π38 "LPSCW" 1303 takes a counter value and information surrounds the probability class as input signals and generates the correct "IN" codeword.

The design uses two pipeline stages. During the first pipeline phase, the count is increased, the probability class is expanded, and a subtract and compare is performed for long R3 codewords. All other operations are performed during the second pipeline phase.

10 encbg.tdf TITLE "Bit Generator for the encoder"; INCLUDE "kexpand.inc"; INCLUDE "Ipscw.inc"; 15 SUBDESIGN encbg (k [3..0], r3, bit, count_in [12..0], 100 131 7 39 each: INPUT; start_run, end_run, index [4..0], 5 count_out [12 .. 0], codeword [12..0]: OUTPUT;)

10 VARIABLE

k_q [3..0], r3_q, k_qq [3..0], r3qq, 15 bit_q, bit_q, count_in_q [12..0], start_run, end_run, 20 start_run_q, index [4..0), count_out [ 12..0], count_plus [1 2..0], max_rl [12..0], 25 codeword [12..0]: DFF; kexpand_ ^: kexpand; .

lp $ cw_: lpscw;

30 START

lpscw_.clk = each; k_q []. clk - any; r3_q.clk = each; k_qqQ.dk = each; 35 r3_qq.dk ** each; bit_q.dk = each; bit_qq.dk «= each; count_in_qQ.dk "= each; start_run.dk »= each; 40 end_run.dk - each; start_run_q.dk «each; indexQ.dk = each; count_outQ, clk = each; count_plusQ.dk «each; 45 max_rlQ.dk = each; codewordQ.dk - each; 1001311 ΊΟ k_qf) * ^ Π; r3_q β r3; k_qqü r3_qq "r3_q; 5 t> it_q -bit; bit_qq - bit_q; count_in_qD count_inQ; countjplusO« count_in_q [] + 1; start run - start run q; 10 stat_run_q = (count_in_qQ - 0); index [0] - r3_qq; index [4..1] - k_qq []; 15 kexpand_.k_reg [] * = k_q []; kexpand_.r3_reg * = * r3_q; lpscw_.r3 «r3_q;

Ipscw .k qD - k_q [j; lpscw_.r3_q * = r3_qq; 20 lpscw_.count [] - count_in_q []; lpscw_.mask [] «kexpand_.mask []; lpscw_.r3_splitn «kexpand_.r3split []; lpscw_.maxrl_q [] - max_rl []; inax_rlG “kcxpand .maxrl []; IF (bit_qq) THEN% LPS% end_run - VCC; \ · Count_out [] = 0; codeword [] ~ lpscw .cwQ; 30

ELS1F (count_pIus [] * == max_rl [J) THEN

end_run VCC; count_out [] * = 0; codeword [] = 0;

35 ELSE

end_run = GND; count_outQ “count_plus []; codeword [] ~ 0; END IF; 40 END;

Jpscw.tdf 45 SUBDESIGN lpscw (1001317 'u r3, k_q [3..0], r3_q, count [12..0], 5 mask [11..0], r3_split [10..0], maxrl q [ 12..0], each: input; 10 cw [12..0]: output;)

VARIABLE

temp [12..0]: NODE; Temp rev [12..0]: NODE; temp ~ sh [12..0]: NODE; split [1 1..0]: NODE; r3_long: DFF; count_minus [1 1..0]: DFF; Maskjq [11..0]: DFF; count_q [12..0J: DFF;

GET STARTED

r3 _long.dk = each; count_minus []. clk - any; 25 mask_q []. Clk * = each; count_q []. clk «each; splitflü..O] -r3_splii []; splitlll] = GND; r3_long - (r3) AND (count [1 1..0]. «split []); 30 count_minusQ «= countfl 1..0] - split!]; mask_q [] * = mask []; count_q [] ~ count []; % pipeline internship ---% 35

IF (r3 Young) THEN

temp [11..0] - (count_minus []) XOR mask q [);

ELSE

tempfl 1..0] => count q [l 1..0] XOR mask q []; 40 END IF; temp [12] «GND; temp_rev [0] «tempt 12]; temp_revll) = temp [11]; 45 temp_revI2) »temp 10]; temp_rev [3] - templ9]; temp_rev [4] «temp [8]; .1001311 42 teinp__rev [5] «temp [7]; temp_rev [6] - iemp [6]; temp_rev [7] »temp [5]; tempjrev [8] - temp [4]; 5 tempjrev [9] temp [3]; temp_rev [10] - iemp [2]; temp_rev [ll] - templlj; tempjrev [12] - temp [0];

10 CASE k_q [] IS

WHEN 0 -> temp_sh [] * = 0; WHEN 1 => temp_sh [0] «temp_rev [12]; temp_sh [12..1] «0; 15 WHEN 2 -> temp_sh [1..0] «temp_rev [l2..11]; temp_sh [12..2] -0; WHEN 3 = = tempr_sh [2..0] - temp_jev [1 2..10]; temp ^ sh [12..3] = 0; ^ WHEN 4 «> temp_sh [3..0] = temp_revl 12..9]; Temp_sh [12..4] -0; WHEN 5 * => temp_sh [4..0] - temp_rev [12..8]; temp_sh [12..5] - 0; WHEN 6 «=> temp_sh (5..0]» temp_rev [12..7]; temp_sh [1 2..6] - 0; 25 WHEN 7 -> temp_sh [6..0] - temp_rev [12 .. 6]; temp_sh [1 2..77] - »0; • WHEN 8 · .-> temp_sh [7..0] = temp_rev [12..5]; temp_sh [12..8] - 0; WHEN 9 * => temp_sh [8..0] temp_rev [12..4]; 30 temp_sh [12..9] - 0; WHEN 10 »> temp-sh [12..10] = 0; temp_sh [12 .. 10] - 0; WHEN 11 => temp_sh [10..0] - temp_rev [12..2]; temp_sh [12 .. 11] - 0; 35 WHEN 12 -> temp_sh [l 1..0] “temp_rev [12..1); temp sh [12] - GND; END CASE; IF (NOT r3_q) THEN% R2% 40 cwf] - temp sh [] OR maxrl qQ; ELSIF (NOT r3 Young) "THEN 96 R3 SHORT 96 cw [l 1..0] - temp sh [12..f] OR maxrl q [11..0]; cw [12] -GND; ELSE 96 R3 LONG 96

45 cw [1 2..1] - temp sh [1 2..1] OR

(ma> rl_q [l 1..0] AND NOT mask_q [l 1..0]); 1001317 'cw [0] = temp sh [0]; END IF; END; 5 kexpand.tdf TITLE "decoder, k expand logic"; 10 SUBDESIGN kexpand (k_regl3..0], r3_reg 15; input; maxrl [12..0], mask [l 1..0], r3split [10..0] 20: output;

GET STARTED

25 TABLE

k_reg [], r3_reg => maxrl [], mask [], r3split []; 0 -> 1, - - 0, X;

Qn · 1.0 => 2.1 X; 30 1.1 -> 3.1, 1; 2.0 => 4.3, X; 2.1 => 6.3, 2; 3.0 -> 8.7, X; 3.1 -> 12.7, 4; 35 4.0 => 16.15, X; 4.1 -> 24, 15, 8; 5.0 -> 32.31, X; 5.1 => 48.31.16; 6.0 -> 64.63, X; 40 6.1 -> 96.63, 32; 7.0 => 128, 127, X; 7.1 -> 192, 127, 64; 8.0 => 256., 255, X; 8.1 -> 384, 255, 128; 45 9.0 -> 512.511, X; 9.1 -> 768, 511, 256; 10.0 -> 1024, 1023, X; 10, 1 -> 1536, 1023, 512; 11.0 -> 2048, 2047, X; 1001317 44 11, 1 -> 3072, 2047, 1024; 12.0 -> 4096, 4095, X; END TABLE; 5 END;

The rearrangement unit according to the invention

Fig. 8 is a block diagram of an embodiment of the rearrangement unit. In Fig. 8, the rearrangement unit 606 includes a runtle-10 rearrangement unit 801 and a bitpack unit 802. The runtle-rearrangement unit 801 moves code words from the end of a run created by the encoder to the beginning of a run. as requested by the decoder, while the bit pack unit 802 combines variable length codewords into interleaved fixed length words and outputs them in the correct order requested by the decoder at the output.

A "tracking" decoder can be used for rearrangement at any decoder, in which a decoder is used in the encoder and issues data requests in an order in which the code words will be needed at the actual decoder. To support a tracking decoder, it may be necessary to rearrange the run counts independently of each stream. For easy-to-model decoders, multiple time-queues or a single mixed queue can be used to allow the rearrangement. In one embodiment, the rearrangement of each codeword can be accomplished using a queue-like data structure independent of the use of a number of encoded data streams. A description of how the rearrangement can be carried out is given below.

The first rearrangement operation performed in the encoder is to rearrange each of the run counts so that the run count is specified at the beginning of the run (which the decoder requires for decoding). This rearrangement is necessary because the encoder does not determine what a run count (and codeword) is until the end of a run. The resulting run count, produced from the encoding of the data, is thus rearranged so that the decoder is able to properly decode the run counts back into the 1001317 45 data stream.

Referring to Fig. 8, the rearrangement unit 606 of the present invention includes a run count rearrangement unit 801 and a bit pack unit 802. The run count rearrangement unit 801 is connected to receive a plurality of input signals including a start signal 711. an end signal 712, an index signal 713 and a codeword 714. These signals will be described in more detail in connection with the run count rearrangement unit of FIG. 9. In response to the input signals, the run count rearrangement unit 801 generates the codeword 803 and the signal 8θ4. The signal 804 indicates when the run count should be reset. The codeword 803 is received by the bitpack unit 802. In response to the codeword 803, the bitpack unit 802 generates the interleaved words 8515. The run count rearrangement unit 801 and the bitpack unit 802 are described in detail below.

Run count rearrangement unit

As discussed above, the encoder 20 receives codewords when the beginning of the data encoded by the codeword is needed. However, the encoder does not know the identity of the codeword until the end of the data encoded by the codeword is reached.

A block diagram of an embodiment of the run count rearrangement unit 801 is described in Fig. 9. The described embodiment is suitable for four interleaved streams, each interleaved word comprising 16 bits and the code words ranging in length between one and thirteen bits. In such a case, the rearrangement unit 300 can function by a pipeline method to handle all 30 streams. Furthermore, an encoder that associates run counts with probability classes is used such that the maximum number of run counts that can be activated at any one time is small, in this embodiment it is assumed that 25. The invention is not limited to four consecutive scrolled streams, 16-bit scrambled words or code word lengths between 1 and 13 bits, but can be used for more or fewer streams with scrambled words of more or less than 16 bits and code word lengths outside the range of 1 to 13 bits.

1001317 ke

Referring to FIG. 9, a pointer memory 901 is connected to receive an index input signal 713 and produces an address output signal applied to one input of multiplexer (MUX) 902. The other two inputs of the MUX 902 are connected to receive an address in the form of a head pointer of the head counter 903 © n an address in the form of a tail pointer of the tail counter 901 ». The output of the MUX 902 is an address applied to and used to access a codeword memory 908.

The index input signal 713 is also supplied as an input signal to the MUX 905. Another input of the MUX 905 is connected to receive the codeword input signal 71 * 1. The output of the MUX 905 is coupled to an input of a valid detection module 906 and to a data bus 907 · The data bus 907 is coupled to the codeword memory 908 and to an input of the MUX 905. Also coupled to the data bus 907 an output of the control module 909. The start input signal 711 and the end input signal 712 are applied to the separate inputs of the control module 909 · The output signals of the valid detection module 906 are output from the output code word 803 and the signal 80U (fig. 8 ). The run count rearrangement unit 801 also includes control logic (not shown to avoid confusion) for coordinating the operations of the various components of the run count rearrangement unit 801.

For re-iteration, index entry 713 identifies a run. In one embodiment, the index indicates one of the 25 probability classes. In such a case, five bits are required to represent the index. It should be noted that if multiple banks of probability classes are used, additional bits may be required to specify the particular bank. In one embodiment, the index entry identifies the run count probability class. The codeword input 71 ^ enters the codeword when the end of a run occurs and otherwise enters a "don't care" state. The start input signal 711 and * the end input signal 712 are control signals indicating when a run starts, ends or both 35th Run starts and ends at the same time if the run consists of a single uncoded bit.

The run count rearrangement unit 801 rearranges the run counts generated by the bit generator in response to its input signals.

1001317 47

The codeword memory 908 stores the codewords during the rearrangement. In one embodiment, the codeword memory 908 is greater than the number of run counts that can be activated at a time. This leads to better compression. If the codeword memory is less than 5 the number of run counts that can be activated at a time, this would actually limit the number of active run counts to the number that can be held in memory. In a system that provides good compression, it often happens that, while data for one word is accumulated with a long run count, many codewords will start (and perhaps also end) with short run counts. This requires the use of a large memory to prevent the long run from being pushed out before it has ended.

The pointer memory 901 stores codeword memory locations for probability classes that are in the middle of a run and address the codeword memory 908 in a random manner. The pointer memory 901 has a storage location for the address in the codeword memory 908 for any probability class that may be in the middle of a run. Once a run for a given probability class has been completed, the address, 20 dtj for this probability class, is stored in the pointer memory 901, is used to access the codeword memory 908, and the completed codeword is written to that location in the codeword memory 908. Until that time, this location in the codeword memory 908 contained an invalid data. The pointer memory 901 contains the location of the invalid codeword for each run count.

The header counter 903 and the tail counter 904 also provide addresses for accessing the codeword memory 908. The use of the header counter 903 and 8th tail counter 904 makes it possible to address the codeword memory 908 as a queue or circular buffer (ie first in, first from [FIFO] memory). The tail pointer 904 contains the address of the next available location in the codeword memory 908 to allow the insertion of a codeword into the codeword memory 908. The header counter 903 contains the address in the codeword memory 908 of the next codeword to be output. In other words, the header 903 contains the codeword memory address of the next codeword to be removed from the codeword memory 91-8. A location for each possible index 1001317 48 (ie probability class) in the pointer memory 901 is used to hold where the tail pointer 904 was at the start of the run, so that the correct codeword can be placed in that location of the codeword memory 908 at the ending the 5 run.

The control module 909 generates a valid signal as part of the data stored in the codeword memory 908 to indicate whether or not information containing valid codeword data is stored. For example, if the valid bit is in the logic 1 state 10, the codeword memory location contains valid data. However, if the valid bit is in the 0 state, then the codeword memory location contains only invalid data. The validation module 907 determines whether a memory location contains a valid codeword each time a codeword is read from the codeword memory 809. In one embodiment, the validation module 907 detects whether the memory location has a valid codeword or a special invalid code.

At the beginning of a new run, invalid data is entered into the codeword memory 908. The invalid data entered serves as a space block in the stream of data stored in the codeword memory 908, so that the codeword for the run can be stored in memory at the correct location (to ensure proper ordering for the modeling of the decoder) once the run is complete. In one embodiment, the invalid data entered includes the index via MUX 905 and an invalid indication (ie an invalid bit) from the control module 909. The address in codeword memory 908 where the invalid data is stored is given by the tail pointer 904, and then stored in the pointer memory 901 as a reminder of the location of the run count in codeword memory 908. The rest of the data appearing between the head pointer 903 and the tail pointer 904 in the codeword memory 908 as completed run counts (ie, rearranged run counts). The maximum number of invalid memory locations is between 0 and 1-1, where 1 is the number of run counts. If a codeword is completed at the end of a run, the run count is stored in the codeword memory 908 using the address stored in the pointer memory 901.

If a run starts, the index for this run is stored <1 49 in codeword memory 908, so that if the codeword memory 908 is full but the run has not yet been completed, the index is used in conjunction with the signal 804 to reset the corresponding run counter. In addition to storing code words or indices in the code 5 word memory 908, one bit, referred to as the "valid" bit, is used to indicate which of the two types of data is stored.

If no run is started or ended then the run count rearrangement unit is inactive. If a run is started and no run is ended and if the memory is full, a code-10 word is output at the output of the codeword memory 908. The code word that is output is the code word stored in the address contained in the header 903 for this probability class. If a run is started and no run is ended (regardless of whether the memory is full), an index input signal 713 is written into the codeword memory 908 via the MUX 905 at the address indicated by the tail pointer 904 The tail pointer 904 is then written into the pointer memory 901 at an address designated by the data at the index input 713 (ie, at the location in the pointer memory 901 for the probability class). After writing in the tail pointer 904, the tail pointer 904 is raised.

When a run is terminated and no run starts, the address stored in the pointer memory 901 corresponding to the index (probability class) is read and used as the location in the codeword memory for storing the completed codeword through the codeword. entrance 714.

If a run is started and a run is ended (ie a run starts and ends at the same time), and the memory is full, a codeword is output from the codeword memory 908. If then a run is started and ended (regardless of the whether the memory is full), a codeword at input 714 is written into the codeword memory 908 at the address indicated by the tail pointer 904. Thereafter, the tail pointer 904 is incremented so that it now contains the next available location (e.g. increment by 1). According to the invention, the run count rearrangement unit 801 can output code words at different times. In an exemplary embodiment, code words can be issued that are either valid or invalid. Code words that are invalid can be issued 10013Π 50 if a memory full state exists and a run has not yet been completed. Invalid codewords can also be issued to maintain a minimum speed (i.e. for speed control). Also, invalid codewords can be output for flushing the codeword memory 908 if all data has undergone a run-length count rearrangement or if the run-length count rearrangement unit jumps to the center of the codeword memory 908 as a result of a reset operation. It is noted that in such a case the decoder must know that the encoder functions in this way.

As described above, a codeword is output if the codeword memory 908 is full. As soon as the memory is full, when an input signal is output to the codeword memory 908 (i.e. a new codeword is started), an output signal is output from the codeword memory 908. It is noted that an update of an input data does not cause output of output data from the codeword memory 908 if a memory full state exists. That is, the completion of a run followed by writing the resulting codeword into its previously allocated memory location does not cause a memory full signal at the output. Similarly, when a run ends and the corresponding address in the pointer memory 901 and the address in the header 903 are identical, the code word can be output immediately and the header 903 can be incremented without accessing the code word memory 908 . In one embodiment, a memory full state occurs if the tail pointer 90 ^ is equal to the head pointer 903 after the tail counter is incremented. Therefore, once the tail counter 90 ^ is incremented, the control logic in the run count rearrangement unit 801 compares the tail pointer 30 904 with the head pointer 903 and if they are equal, the control logic determines that the codeword memory 908 is full and that a codeword is must be delivered at the exit. In another embodiment, code words can be delivered to the output before the memory is full. For example, if the portion of the queue addressed by the header contains valid code words, this portion can be output. This requires that the beginning of the queue be examined repeatedly to determine the status of the code words contained therein. It is noted that 1001311 51 the codeword memory 908 is emptied at the end of the file encoding.

Using a run count rearrangement unit 801, a codeword is output to the output by first reading a value 5 (ie data) from the codeword memory 908 at an address specified by the header pointer 903 · The output of codewords is controlled and coordinated by the control logic . A valid detection module 906 performs a test to determine whether the value is a codeword. In other words, the valid detection module 906 10 determines whether the codeword is valid. In one embodiment, the valid detection module 906 determines the value of each data entry by testing the stored validity bit with each data entry. If the value is a codeword (i.e. the codeword is valid) then the value is output as a codeword. On the other hand, if the value is not a codeword (i.e., the codeword is invalid) then any arbitrary codeword having a run of MPSs can be output at least as long as the current run count. The "0" codeword is a codeword that correctly represents the run count so far and can be output at the output. After the output signal has been output, the head pointer 903 is incremented to the next location in the codeword memory 908 · Alternatively, using the "IN" with the shortest allowable run lengths allows the decoder to check only if a codeword has been issued before issuing an LPS.

In one embodiment, the run-length rearrangement unit 801 operates with a double clock cycle period. In the first clock cycle, input signals are received in the run count rearrangement unit 801. In the second clock cycle, the codeword is output from the memory 908.

Although codewords can be delivered to the output as soon as the head pointer 903 addresses a valid codeword, in some implementations it may be desirable to deliver a codeword to the output only if the buffer is full. This ensures that the system has a fixed delay expressed in numbers of code words, rather than a variable delay. If the memory 908 is able to hold a predetermined number of code words between the time the run was started and entered and the time the output takes place, then the delay is> 1001311 52 number of code words since not executing a output signal until it is full. Therefore, there is a constant delay in codewords. It is noted that the rearrangement delay is still variable in other respects, for example the amount of encoded or original data. By allowing the memory 908 to be filled prior to producing an output value, the output generates a code word per cycle.

It is noted that if a codeword memory location is marked invalid, the unused bits can be used to store an identifier indicating what run count it belongs to (ie the context bin or probability class that the location must fill is stored therein) ). This information is useful in handling the case when the memory is full. In particular, the information can be used to indicate to the bit generator that a code word for a given run length has not been terminated and that it must now be terminated. In such a case, a decision must be made to deliver an invalid code word to the output which may occur due to a memory full state. Thus, if the system resets the run counter then 20 this indicates when, in terms of bit generators and run counters, the system is to restart.

With respect to the input index, if banks of probability classes are used for pipeline reasons, the index may include a bank identifier. That is, there can be multiple run-25 counts for a given probability class. Two run counts can be used for the 80% code using one first and then the other.

Since the codewords have a variable length, they must be stored in the codeword memory 908 in a manner that allows their length to be determined. Although it is possible to explicitly save the size, it does not minimize memory usage. For R codes, storing a zero in memory may indicate a one bit "0" codeword and the "IN" codewords can be stored such that a priority encoder can be used to fix the length from the first "1" bit to set.

If the codeword memory 908 has multiple ports (e.g. two ports), this design can be pipelined to handle one codeword per clock cycle. Since any 1001317 53 arbitrary location in the codeword memory 908 can be addressed from the multiple ports, a location in the codeword memory 908 can be described as when storing an invalid word or codeword, while another word can be read, such as 5 on output of a codeword. It is noted that in such a case, the multiplexers may be modified to support the multiple data and address buses.

When the encoder outputs a "0" codeword and resets a runteller because the codeword memory is full, the decoder must do the same. This requires the decoder to model the codeword queue in the encoder. How this is achieved is discussed in the following.

It is noted that to save power in CMOS implementations, counters at "IN" code words can be deactivated if "0" code words are output for invalid runs. The reason for this is that a decoded "IN" codeword is valid while only a "0" codeword can be invalid.

Alternative embodiment based on context 20 FIG. 10 is a block diagram of another embodiment. Form of a run count rearrangement unit that rearranges received data in accordance with the context (as opposed to the probability class). The run count rearrangement unit 1000 performs a rearrangement using the R codes. Referring to FIG. 10, the rearrangement unit 1000 includes a pointer memory 1001, a head counter 1002, a tail counter 1003, a data multiplexer (MUX) 100, an address MUX 1005, a length calculation block 1006, a valid detection block 1007, and a code word memory 1008. codeword memory 1008 contains the codewords during the rearrangement. The pointer memory 30 1001 contains addresses for codeword memory locations for context bins that are in the middle of a run. The header counter 1002 and the tail counter 1003 allow the codeword memory 1008 to be addressed as a queue or circular buffer in addition to addressing randomly by the pointer memory 1001. For R codes, storing a zero value in the memory can be one indicate bit "0" codeword and "IN" codewords can be stored such that a priority encoder can be used to determine its length from the first "1" bit. The length calculator 1006 10013Π 54 works like a priority encoder. (If other variable length codes are used, it may be more memory efficient to add a ”1” bit to mark the start of a codeword rather than adding log2 bits for explicitly storing the length.) The run count rearrangement unit 1000 also includes background control logic for coordinating and controlling the operation of components 1001-1008.

The operation of the run count rearrangement unit 1000 is similar to that of the run count rearrangement unit which was based on probability estimates. At the start of a new run, an invalid input data including the context bin is written into the codeword memory 1008 at the address indicated by the tail pointer 1003. The address of the tail pointer 1003 is then stored in the pointer memory 1001 at the address 15 of the context bin of the current count. Then, the tail pointer 1003 is incremented. Upon completion of a run, the pointer in the pointer memory 1001 corresponding to the run counter is read from the pointer memory 1001 and the codeword is written in parallel in the codeword memory 1008 at the location indicated by this pointer. If a run does not start and also does not end and if a location in the codeword memory 1008 designated by the address of the head pointer 1002 does not contain valid data, then the codeword addressed by the head pointer is read and output . The head pointer 1002 is then incremented. If a run starts and ends at the same time, the codeword is written into the codeword memory 1008 at the address indicated by tail pointer 1003 and then tail pointer 1003 is incremented.

Similarly, if a run ends and the corresponding address in the pointer memory 1001 and the address in the header 1002 are equal, then the code word can be output immediately and the value in the header 1002 can be incremented without affecting the code word memory 1008 to speak.

For systems with run count "via context", each context requires a memory location in the pointer memory 1001, so that the width of the BG and PEM state memory may be larger to implement this memory. The width of the pointer memory 1001 is equal to the dimensions required for a codeword memory address.

1001317 4 55

The number of locations in the codeword memory 1008 can be chosen by the designer depending on a particular application. The limited size of this memory reduces compression efficiency, so there is a tradeoff between cost and compression. The width of the codeword memory is equal to the size of the largest codeword plus one bit for the valid / invalid indication.

An example of using the R2 (2) code, shown in Table M below, will be used to illustrate the rearrangement. Table N shows the data to be reordered (0 = MPS, 10 more likely symbol; 1 = LPS, less likely symbol), highlighted by context. There are only two contexts. The unencrypted bit number indicates the time in unencrypted bit clock cycles. Start and end of runs are indicated and codewords are shown at the end of the runs.

15

Table M - R2 (2) code Original Code word 0000 0 0001 100 20 001. 110 01 101 1 111) 001 317 56

Table N - Example of data to be encoded

Uncoded Data Context Start / End Codeword bit number of run

I 0 0 S

5 2 0 1 S

3 0 0 4 1 1 E 101 5 0 0

6 0 1 S

10 7 0 0 E 0 8 1 1 E 101

9 0 0 S

10 0 1 S

II 0 0 15 12 I 0 1 13 0 0 14 0 1 15 1 0 E 100 16 0 1 E 0 20

The reorder operation for the example data is shown in Table 0. A codeword memory with four locations 0-3 is used, which is large enough not to cause overflow in this example. Each row shows the state of the system after an operation, which is either the start or end of a run for a given context or the delivery of a codeword. An ”x” is used to indicate memory locations that are “don't care.” For some unencrypted bits, a run has no beginning or end so that the run counter reorder unit is free. For coded bits that end a run, 30 one or more codewords can be issued, causing various system state changes.

10013Π

U) I

s I

bo I

4J I rH rHO

• H o o o _

ZD O rH rH rHO

hi hi • H * r- Ό Ό ι-H I— 0) 0)

hl hl O

c c o

o ”X X x XXXXXXOO tHXXX

____________ ____ hi hi hi hi • Η · Η · Η τ- Ό Ό Ό Ό i — I F — 1 I — I 1— φ φ φ φ hi hi hi hi Ή

C C C C O

CM X X X OOOOrHXXX X X X X

hi C Η w φ Ό CD hi r — 1. .—. ^

Ti 3 <D Ό Ό Ό 4H φ hl C3 '—1 C' —I tH rH φ «XI c <1) 0 53 ο ο oa> * h φτηχοο '-' Ο '-' ^ '-' Χχχχχ a. xxxx £ hi___O_ O________ O ____

9 * Ό rH rH H

Ος, hl hl hl 'i- hi hi · -> hi hi $ 2- Ο · Η * H * H * rH · Η * H * H * H · Η · Η Ο Ό Ό tj Ό £ j Ό Ό U Ό Ό

ζ 5 ι-Η Γ — I> ι — 1 ^ ι — I pH> f— (rH

) Η φ φ φ φ φ φ φφ £ Ό hl hl Ό hl Ό hl hl Τ) hlhl

«Ο C G · Η C · Η C C * H CC

P οοοοφοφοοχχχχχο a> o o o x 0 ----- g— -g -------- -g ---- r. φ φ cd £ c <d <d <d * “5 (OW cn r- - δ hi hi ho

in 5.3 cc

? φ -Η -Η -H

> x CC C

- φρπ Χρ-ι ^ χφγμιμιμιμχχχο cd ooxx s g --- t— Ϊ -------- Έ ---- J si ε s s 1: h 5 n 5 O * -> a

ι <O O O O OXXXXX-O-rr X X X X

o iH ^ φ c

x CO

(0 «H 4->

IQ W rH CM <M (VrriH-crri'lVO'-H rH rH rH rH

c Φ -------- ----

N

1 §

CJrfOO O ORHCMlMCTfVCV Ο O rH

rH tH ο „o o o

. O rH rH rH O rH O rH rH O

ho. .

S4-> 4-> rH 4-> O rH 4-> 4-> o rH

CCOIhO Ό U U Ό Ό

SpcOcOCcOC C CJ Cfl CC

C 4J + J · Η 4J · Η «· Η * j * j · Η -rH

m co in φ to φ φ cn tn α> Φ

Hmm "'> 111 mn imb mm *' - · ιι ·· 1 - n mm ——y ·. ,, ... -

I rH

ΦΟ «0 ho c 4-> 0) a> 4-> Φ hi ΦΤ3 4-> hho-h OrHiMrc '^ rm'X)

Z OJD rH CM O '- = J- IT VO Γ— OO O' rH rH rH rH rH rH rH

10013 * 1 7 58

In Table O, the heading and tail pointers are initialized to zero, indicating that there is nothing in the codeword memory (e.g., a queue). As shown, the pointer memory has two storage locations, one for each context. Each location has "don't care" 5 values prior to bit number one. The codeword memory is shown with a depth of four codewords, all of which initially contain "don't care" values.

In response to the received data for bit number 1, the header pointer continues to point to the codeword memory location 0. Since the decoder 10 expects data, the next available codeword memory location 0 is assigned to the codeword and an invalid value is written into the memory location 0. Since the context is zero, the address of the codeword memory location assigned to the codeword is stored in the pointer memory location for the zero context (pointer memory location 0). Thus, a "0" is stored in the pointer memory location 0. The tail pointer is incremented at the next codeword memory location 1.

In response to the data corresponding to bit number 2, the header continues to point to the first memory location (because there was no output signal causing an increment). Since the data corresponds to the second context, context 1, the next codeword memory location is assigned to the codeword as codeword memory location 1 indicated by the tail pointer and an invalid value is written in this location. The address, codeword location 25 1, is written in the pointer memory location corresponding to context 1. That is, the address of the second codeword memory location is written in the pointer memory location 1. Then the tail pointer is incremented.

In response to the data corresponding to bit number 3, the rearrangement unit is idle because no run is started or ended.

In response to the data corresponding to bit number k, an end of a run is indicated for context 1. Therefore, the codeword * f101 "inscribed in the codeword memory location is assigned to context 1 (codeword memory location 1) as indicated by the pointer memory location for context 1. The head and tail pointers remain the same and the value in the pointer memory location for context 1 will not be reused , and is therefore "don't care".

1001317 59

In response to the data corresponding to bit number 5, the reorder unit is free because no run is started or ended.

In response to the data corresponding to bit number 6, operations of the same type as described above are performed for bit 2.

In response to the data corresponding to bit number 7, the end of the run for the codeword for context 0 occurs. In this case, the codeword "0" is written into the codeword memory location (codeword memory location 0) as indicated by the pointer memory location for context 0 (pointer memory location 0). After that, the value of the pointer memory location will be reused again and so it is "don't care". The codeword memory location indicated by the head pointer also contains valid data. The valid data is therefore output at the output and the header pointer is cremated. Incrementing the heading pointer causes it to point to another codeword memory location containing a valid codeword. This codeword is therefore output at the output and the header pointer is incremented again. It is noted in this example that code words are output when possible, and not when the code word memory is completely full.

The processing by the unencrypted bits continues in accordance with the above described. It is noted that the codeword memory locations are not reserved for use with certain contexts so that codewords for arbitrary contexts can be stored in a given codeword memory location within the encoding of a data file.

The bit pack unit

The bit packing is illustrated in Fig. 4 showing data processed by the reorder unit before and after bit packing. Referring again to Fig. 4, sixteen variable length codewords are shown numbered 1 through 16 to indicate the decoder usage order. Each codeword is assigned to one of three coded streams. The data in each encoded stream is truncated into fixed length words 35 which are referred to as the interleaved words. (It should be noted that a single variable-length core code word is divided into two interleaved words). In this example, the interleaved words are arranged in a single interleaved stream 1001317-160 so that the order of the first variable length codeword (or partial codeword) in a particular interleaved word determines the order of the interleaved word. Other types of classification criteria can be used. The advantage of collapsing the multiple code streams is that a single coded data channel can be used for data transfer and variable length shift can be performed for each stream in parallel or in a pipeline.

The bit pack unit 802 of the present invention receives the variable length code words from the run count reorder unit 801 and packs them into interleaved words. The bit pack unit 802 includes logic to perform the treatment of the variable length code words and a mixed queue type reorder unit to output fixed length interleaved words in the correct order. In an embodiment, the codewords are received from the run count reorder at a rate of up to one codeword per clock cycle. A block diagram of an embodiment of the bit pack unit 802 is shown in Fig. 11. In the following embodiment, four interleaved streams are used, each interleaved word 20 has 16 bits, and the code words range in length from one to thirteen bits. In one embodiment, a single bit pack unit in pipeline configuration is used to handle all flows. If the bit pack unit 802 of the present invention uses a two port memory (or register file), it may output one interleaved word per clock cycle. This may be faster than necessary to keep up with the rest of the encoder.

Referring again to Fig. 11, the bit pack unit 802 includes the pack logic 1101, a flow counter 1102, a memory 1103, tail pointers 1104, and a header counter 1105. The pack logic 1101 is connected to receive the code words and is connected to the flow counter. 1102. The current counter 1102 is further connected to the memory 1103 · The memory 1103 also connects the tail hands 1104 and the head counter 1105. .

The flow counter 1102 keeps track of which interleaved current the current input codeword is associated with. In one embodiment, the flow counter 1102 repetitively counts the currents from 0 to N-1, where N indicates the number of currents. As soon as the current counter 1102 reaches position N-1, it starts counting again at 0. In one embodiment, the current counter 1102 is a two-bit counter and counts from 0 to 3 (for four interleaved flows). In one embodiment, counter 1102 is initialized to zero (via a general reset).

The pack logic 1101 mixes the current input codeword with previous input codewords to form interleaved codewords. The length of each of the code words can vary. The packing logic 1101 therefore packs these variable length code words into fixed length words. The interleaved code words, created by the pack logic 1101, are delivered to memory 1103 in the correct order and stored in this memory 1103 until the correct time to output them again. In one embodiment, memory 1103 is a static random access memory (SRAM) or a sixty-four-word, 16-bit register file.

The interleaved words are stored in memory 1103-15. According to the present invention, the size of memory 1103 is large enough to handle two cases. One case is the normal operating case where one collapsed stream has minimum length codewords and the other collapsed streams have maximum length codewords. This first case requires 3 x 13 = 39 memory locations. The other case is the initialization case where again one stream has code words of minimum or short length and the other code words of maximum or long length. Since 2 x 3 x 13 = 78 memory locations are sufficient for the second case, the action of the PEM allows a more tight bond of 56.

Memory 1103, in conjunction with current counter 1102 and tail pointers 1104, performs the rearrangement. The flow counter 1102 indicates the current flow of a codeword received by the memory 1103. Each interleaved flow is associated with at least one tail pointer. The tail hands 1104 and the head counter 1105 30 rearrange the codewords. The reason for having two tail pointers per stream follows from the fact that the interleaved word N is requested by the decoder if the data in the interleaved word N-1 contains the start of the next codeword. One tail pointer determines the location in memory 1103 for storing the next interleaved word from a given interleaved stream. The other tail pointer determines the location in memory for storing the collapsed word after the next word. This makes it possible to specify the location of the interlocked word N as soon as the decoder interrogation time for the interleaved word N-1 is known. In one embodiment, the pointers consist of eight 6-bit registers (two tail pointers per stream).

In one embodiment, the tail pointers 110 ^ at the start of encoding are set such that the first eight interleaved words (two from each stream) are stored in memory 1103 in a sequence, one for each stream. When the pack logic 1101 after initialization starts with a new collapsed word for a given code-10 stream, the "next" tail pointer is set to the value of the "next" tail pointer, and the "next" tail pointer for the code stream is set to the next available memory location. Therefore, there are two tail pointers for each stream. In another embodiment, only one tail pointer is used for every stream indicating where the next collapsed word is to be stored in memory 1103.

The header counter 1105 is used to determine the memory location of the next interleaved word to be output by the bit pack unit 802. In the described embodiment, the header counter 1105 includes a 6-bit counter which is incremented to deliver a fully collapsed word at a time.

In addition to being used for rearrangement, memory 1103 can also be used as a FIFO buffer between the encoder and the channel. It may be desirable to make this memory larger than is needed for the reordering so that a FIFO substantially full signal can be used to temporarily stop the encoder if the channel cannot keep up with the encoder. A one-bit-per-cycle cannot generate one interleaved word per cycle. If an encoder is well matched to a channel, the channel will not accept one word interleaved every cycle and no FIFO buffering is necessary. A channel that can accept one 16 bit interleaved word per 32 clock cycles can provide a well-adapted design for a 2: 1 effective bandwidth expansion if the compression was 2: 1 or greater.

35

The packing logic of the present invention

A block diagram of the packing logic is shown in Fig. 12. The packing logic 1101 in Fig. 12 comprises a dimension unit 1201, a group of n 0) 3 ^ 7 1.

63 accumulators 1202, a shifter 1203, a multiplexer MUX 1204, a group of registers 1205, and a logic OR gate 1206. The dimension unit 1201 is connected to receive the code words and is connected to the accumulators 1202. Both the accumulators the 5 codewords are also connected to the shifter 1203 · The shifter 1203 is coupled to the multiplexer MUX 1204 and to the logic OR gate 1206. The multiplexer MUX 1204 is also coupled to the registers 1205 and to the output of the logic OR gate 1206. The registers are also coupled to the logic OR gate 1206.

In one embodiment, the code words are input on a 13-bit bus with the unused bits set to zero. These zero unused bits are adjacent to the "1" in "IN" codewords and therefore the priority encoder in the dimension unit 1201 can be used to determine the length of the "IN" codewords 15 and a measure of the Generate "0" code words.

The accumulators 1202 include a number of accumulators, one for each collapsed current. The accumulator for each interleaved stream keeps track of how many bits are already present in the current interleaved word. In one embodiment, each accumulator 20 includes a 4-bit adder (with carry output) and a 4-bit register for each stream. In one embodiment, the adder's output is also the accumulator's output. In another embodiment, the output of the register forms the output of the accumulator. Using the dimensions of the codewords received from the dimension unit 1201, the accumulators determine the number of bits to be shifted to couple the current codeword in the register containing the current collapsed word for that stream.

Based on the counter value of the accumulator, the shifter 1203 aligns the current codeword so that the correct follows any preceding codewords in the collapsed word. The data in the encoder is thus retracted in the decoder order. The output of the shifter 1203 is 28 bits, which refers to the case where a 13-bit codeword must be appended to 15 bits in the current collapsed word, so that bits of the current codeword end up in the higher 12 bits of the 28 bits. that are delivered at the exit. It is noted that the shifter 1203 operates without feedback and thus can be used in a pipeline operation. In one embodiment, the

1001317I

64 slider 1203 a drum slider.

Registers 1205 contain the bits in the current interleaved words. In one embodiment, a 16 bit register for each interleaved stream contains the previous bits in the current interleaved word.

Initially, a code word of a current is received by the shifter 1203, with the dimension unit 1201 communicating the size of the code word to the accumulator corresponding to the current. The accumulator has an initial value of zero that is set through the general reset. Since the accumulator value is zero, the code word is not shifted and then 0F processed using the 0F logic 1206 with the contents of the register corresponding to the stream. In some embodiments, however, IN codewords must be shifted to be correctly extended even at the beginning of a collapsed word. This register is initialized to zero and the result of the 0F operation is inputting the codeword into the rightmost bit positions of the output of 0F logic 1206 and feeding it back through the multiplexer MUX 1204 to become therein stored up to 20 the next code word for the stream. Thus, the shifter 1203 initially functions as a passage unit. It is noted that the number of bits in the first codeword is now stored in the accumulator. Upon receipt of the next codeword for this stream, the value in the accumulator is sent to the shifter 1203 and the codeword 25 is shifted left by that number of bits in combination with any previous input bits in the collapsed word. Zeros are placed in the other bit positions in the shifted word. Bits of the register corresponding to the current are combined with bits of the shifter 1203 using the 0F logic 30 1206. If the accumulator does not produce an output carry indication (for example, a signal), more bits are needed to make the current collapse word and the data resulting from the 0F operation is fed back into the register via the MUX 1204. In one embodiment, the MUX 1204 includes a 2: 1 multiplexer. If the accumulator generates an output carry, the 16 bits of the data at the output of OR logic 1206 form a complete interleaved word and it is then output. The MUX 1204 loads the register with any further bits (e.g. the 12 1001317 65 highest bits of the 28 bits at the output of the shifter 1203) after the first 16 and fills the remainder with zeros.

The control for both the MUX 120¾ and the interleaved word output includes the accumulator output carry signal. In an embodiment, the multiplexer 120¾ comprises sixteen 2: 1 multiplexers, of which ¾ have an input that is always zero.

Reorder options

The present invention provides multiple options for performing the rearrangement on the data. For example, in a multiple code stream system, the code streams must be rearranged into interleaved words as shown in Fig. K. The present invention provides a number of ways to accomplish this rearrangement.

One method of rearranging data in collapsed words is to use a tracking decoder as shown in Fig. 25. The multiple run count reorder units 2501A ... N are connected in Fig. 25 to receive the codeword information. along with the code word flow. Each generates an output codeword and an output 20 measure. A separate bit pack logic unit (1101), such as bit pack units 2502A ... N, is connected to receive the output codewords and measures of one of the run count reorder units 2501A ... N. The bitpack logic units 2502A ... N output interleaved words applied to both the MUX 2503 and the tracking decoder 250¾. The decoder 250¾ provides a selection control signal which is received by the MUX 2503 and indicates to the MUX 2503 which word is to be output at the output in the code stream.

Each encoded data stream has a run count reorder unit comprising the run count reorder unit 801 in Fig. 8. Each bit pack unit combines variable length code words into fixed size interleaved words, for example, 8, 16 or 32 bits per word. Each bit pack unit contains registers and shift circuits as indicated above. The decoder 250¾ includes a fully operational decoder (including BG, PEM and CM) that can access the interleaved words from all bitpack units (either on separate buses as shown in Fig. 25 or via a common bus). If the decoder 250¾ has selected an interleaved 1001317 66 word from one of the bit pack units, that word is broadcast in the code stream. Because the decoder on the receive side will poll the data in the same order as the identical tracking decoder, the interleaved words are transmitted in the correct order.

An encoder with a tracking decoder can be attractive in a half duplex system because the tracking decoder can also be used as a normal decoder. An advantage of the tracking decoder approach is its applicability to any deterministic decoder. Other solutions discussed below that do not rely on a tracking decoder use simpler models of the decoder to reduce hardware costs. For the decoders that decode multiple codewords in the same clock cycle, modeling the decoder with 15 less hardware than a decoder itself may be impossible and may not

V

use of a tracking decoder are necessary. As will be described below, simpler models exist for decoders that decode only a maximum of one codeword per cycle.

Another technique for rearranging the data in pipeline-20 decoding systems, which decode a maximum of one codeword per clock cycle, is based on the fact that the only information required to model the decoder encoded data requests is of the order of the code words (considering all code words and not the code words for each code stream separately). If a time marker is associated with each code word entering the run count rearrangement unit, that interleaved word obtained with the bitpacking process with the oldest associated time marker is the next interleaved word to be output.

An exemplary encoding unit for an encoding unit is shown in block diagram form in Fig. 26. In Fig. 26, the encoding system is the same as described in Fig. 25 with the exception of the time marker information provided by each run counting rearrangement unit 2501A. .N is received. This time marking information is also passed on to the bit pack units 2502A ... N. The bit pack units 35 2502A ... N supply the interleaved words to the MUX 2503 and the associated time markers to the logic circuit 2601. The logic circuit 2601 provides a control signal to the MUX 2503 to select the interleaved word to be supplied to the code stream. 10 01 317 67 must be issued.

In this embodiment, the tracking decoder is replaced by a simple comparator operation that determines which of the bitpack units 2502A ... N has a codeword (or part of a codeword) with the oldest time marker. For the MUX 2503 such a system arises as a number of queues with time markers. The logic circuit 26OI simply selects from the various queues. The logic of each of the run count rearrangement units 2503A ... N changes only slightly (relative to the run count rearrangement unit 801) to write a time marker when a run is started. Each run count rearrangement unit 2501A ... N is capable of storing the time marker in the codeword memory. Storing time markers with enough bits to include each codeword in the encoded data stream is sufficient, but in some embodiments less bits can be packed.

A brief description of the steps used for multiple queues with time markers is given below. The description is understandable to those skilled in the art. These are coding operations. No simplifications have been made for cases where a run both starts and ends with the same codeword. Operations can be checked for any encoded symbol (although in practice not all checks are performed). It is assumed that the interleaved words are 32 bits Icing.

25 if (no current codeword for context) {queue time mark Queue (used to determine next queue) queue context pointer queue invalid data 30 assign context to queue input increment queue tail) if (already codeword and MPS ) (increment context-runtel1ing 35) as (MAXRUN or LPS) (queue correct data (context pointer not needed) null pointer fc run count in context memory 40 update probability hero estimate in context memory} as (valid data at the head of next queue YiJ) (.place 32 bits of data on output clear queue input 45 increment queue header) if (any queue is nearly full) (find next queue to put data on output if (less than 32 bits valid data) (5O use context pointer to find the context null pointer I, run count in context memory place MAXRUN codeword in queue data)} 1001317 68

The decoding operations are similar although the codewords do not have to be queued. It is still necessary to save the time mark of the codewords in the queue.

The function of the time markers discussed above is used to store the ordering information of the codewords. An equivalent way to express the same concept is through the use of a single queue for all codewords, i.e. a mixed queue. In a mixed queue system, as shown in Fig. 27, a single run count rearrangement unit 2701 is used for all of the Interleaved flows. The run count rearrangement unit 2701 generates codeword, measure and current output information to the bit pack units 2502A ... N which supply the interleaved words to the MUX 2503 and deliver the position information to the logic circuit 2702 , which sends signals to the MUX 2503 to output interleaved words as part of the code stream.

For arbitrary flows, the run count rearrangement memory contains a collapsed flow ID for each codeword. Each collapsed stream has its own heading pointer. If a bit pack unit needs more data 20, the corresponding header is used to retrieve as many code words as necessary to form a new interleaved word. This can mean viewing many code word memory locations to determine which are part of the correct stream. This can also mean looking at the codeword memory for additional fields in order to implement a linked list.

Another collapsed stream method of the invention utilizes a fixed queue mixed queue. This method uses a single tail pointer as in the case of the mixed queue, so that no time markers are required. Also, multiple headers are used as in the previous case, and therefore there is no overhead in delivering data to a given stream. To achieve this, the assignment of codewords to interleaved streams is performed according to the following rule that applies to N streams: codeword M is assigned to stream M modulo (mod) N. Note that interleaved streams can have codewords from any context bin or probability class in accordance with this method. If the number of 1001317 69 currents is a power of two, then core M mod N are calculated by omitting some of the more significant bits. As an example, it is assumed that the codeword rearrangement memory is addressed with 12 bits and that four interleaved streams are used. The tail pointer is 12 bit long and the two least significant bits identify the code stream for the next codeword. Four 10-bit headers are each implicitly assigned to each of the four possible combinations of the two least significant bits. Both the head and tail hands are incremented as normal binai-10 counters.

In the decoder, the slider is provided with registers that store the interleaved words. The shifter presents correctly aligned coded data to the bit generator. If the bit generator uses part of the encoded data, the shifter 15 is informed. The shifter presents correctly aligned data from the next collapsed stream. If the number of encoded data streams is equal to N, then the shifter N-1 has clock cycles for extending the used data and perhaps requesting another interleaved code word before the particular interleaved stream is reused.

The decoder of the present invention

The present invention includes a decoder that supports the real-time encoder with limited rearrangement memory 25. In one embodiment, the decoder also has reduced memory needs and complexity to maintain a runtime for each probability class instead of each context bin.

An embodiment of the decoding system of the present invention

Pig. 1 * 1A illustrates a block diagram of an embodiment of the decoding hardware of the present invention. In Fig. 1 * 1A, the decoding system 1 * 100 includes a first-in / first-out (FIFO) structure 35 1 * 101, decoding units 1 * 102, a memory 1 * 103 and a context model 1 * 10 * 1. The decoding units 602 comprise a plurality of decoders. The coded data 1 * 110 is received by the FIFO structure 1 * 101. The FIF0 structure 1 * 101 is connected to supply the encoded data 1001317 70 to the decoder 1 * 402. The decoders 1 * 102 are connected to the memory 1 * 403 and to the context model 1 * 40 * 4. The context model 1 * 40 * 1 is also coupled to the memory 1 * 403 · An output of the context model 60 * 4 includes the decoded data 1 * 411.

In the system 1 * 400, the coded data 1 * 410 inputted into the FIFO structure 1 * 101 is arranged and collapsed. The FIFO structure 1 * 401 contains the data in the correct order. The currents are supplied to the decoders 1 * 402. Decoders 1 * 402 request the data from these flows in a serial and deterministic order. Although the order in which decoders 1 * 402 require the encoded data is non-trivial, it is not arbitrary. By ordering the codewords in this order in the encoder instead of the decoder, the encoded data can be collapsed into a single stream. In another embodiment, the encoded data 1 * 410 may contain a single stream of non-collapsed data, with data for 1 each context bin, context class, or probability class added to the data stream. In this case, the FIFO 1 * 410 is replaced by a storage medium 1 * 410 for receiving all the encoded data prior to supplying data to the decoders 1 * 402 so that the data can be correctly segmented.

If the coded data 1 * 410 has been received by the FIFO 1 * 401, the context model 1 * 40 * 4 determines the current context bin. In one embodiment, the context model 1 * 40 * 4 determines the current context bin based on previous pixels and / or bits. Although not shown, the context model 1 * 40 * 4 can use some form of line buffering. The line buffering provides the necessary data, or template, with which the context model 1 * 40 * 4 determines the current context bin. For example, if the context is based on pixel values in the vicinity of the current pixel, the line buffer can be used to store the 30 pixel values of those pixels in the vicinity used to provide the specific context.

In response to the context bin, the decoder 1 * 400 retrieves the decoder state from memory 1 * 403 for the current context bin. In one embodiment, the decoder state includes the probabilities of the probability estimation module (PEM) and the bit generator. The PEM state determines which code to use for decoding new code words. The bit generator permission contains a registration of the bits in the current run. The state is provided to the 1001317 71 decoders 1 * 102 from the memory 1 * 103 in response to an address provided by context model 1 * 10 * 1. The address addresses a location in memory 1 * 103 in which information corresponding to the context bin is stored.

5 Once the decoder state for the current context bin is retrieved from memory 1 * 103, system 1 * 100 determines the next uncompressed bit and processes the decoder state. The decoders 1 * 102 then decode the new codeword if necessary and / or update the run count. The PEM state is updated as necessary as well as the 10 bit generation state. Decoders 1 * 102 then write the new coder state into memory 1 * 103.

Fig. 1 * 1B illustrates an embodiment of a decoder according to the present invention. The decoder of Fig. 1 * 1B includes shift logic 1 * 131. bit generator logic 1 * 132, "new k" logic 1 * 133. PEM 15 update logic 1 * 13 * 1, new codeword logic 1 * 135. PEM state to

V

cache logic 1 * 136, code-to-mask logic 1 * 137. code-to-MaxPL, mask, and R3 split expansion logic 1 * 138. decoding logic 1 * 139. multiplexer 1 * 1 * 10, and run count update logic 1 * 1 * 11. The shift logic 1 * 131 is connected to receive coded input data 20 1 * 1 * 13 as well as status input 1 * 1 * 12 (from memory). The output of the shift logic 1 * 131 is further coupled to an input of the bit generation logic 1 * 132, "new-k." generation logic 1 * 133 and the PEM update logic 1 * 13 *. The bit generation logic 1 * 132 is further connected to receive the status input 1 * 1 * 12 and generates the decoded data at the output to the context model. The new-k logic 1 * 133 generates an output signal which is applied to an input of the code-to-mask logic 1 * 137 · The PEM update logic 1 * 13 * 1 is also connected to the status input 1 * 1 * 12 and generates the status output (to memory). The status input 1 * 1 * 12 is also coupled to the 30 inputs of the new codeword logic 1 * 135 and the PEM status to code logic 1 * 136. The output of the PEM status-to-code logic 1 * 136 is closed for reception by the expansion logic 1 * 138. The output of the expansion logic 1 * 138 is connected to the decoding logic 1 * 139 and to the run count update logic 1 * 1 * 11. A clearer input of the deco-35 logic is connected to the output vein the code-to-mask logic 1 * 137 · The output ve decode logic 1 * 139 is connected to an input vein the MUX 1 * 1 * 10. The lower input of the MUX 1 * 1 * 10 is connected to the status input 1 * 1 * 12. The selection input of the MUX 1 * 1 * 10 is connected to 1001 317 72 connected to the output of the new codeword logic 1435 * The output of the MUX 1440 and of the expansion logic 1438 are coupled to two inputs of the run count update logic l44l along with the output of the code-to-mask logic 1437 · The output of the run-5 count update logic l44l is included in the status output to memory.

The shift logic 1431 inserts data from the encoded data stream. Based on the encoded data stream input and the status input, the bit generation logic 1432 generates decoded data to the context model. New-k logic 1433 also uses the retracted data and the status input to generate a new value of k. In one embodiment, new k logic 1433 uses the PEM state and the first bit of the encoded data to generate a new value of k. Based on the new k value, the code-to-mask logic 1437 generates an RLZ mask for the next code word. The RLZ mask for the next codeword is sent to decoding logic 709 and run count update logic 144l.

The PEM update logic 1434 provides for updating the PEM state. In one embodiment, the PEM state is updated using the current state. The updated state is supplied to the memory. The new codeword logic 1435 determines whether a new codeword is needed. The PEM state-to-code logic 1436 determines the code for decoding using the status input 1442. The code is input to the expansion logic 1438 to generate the maximum run length, the current mask and an R3 split value. Decoding logic 1439 decodes the codeword to produce a run count output value. MUX 1440 selects either the output from the decoding logic 1439 or the status input 1442 to the run count update logic 1444l. The run count update logic 30 1441 updates the run count.

The decoding system 1400 includes a decoder 1430 which operates according to the invention in a pipeline manner. In one embodiment, the decoding system 600 of the invention determines context bins, estimates probabilities, decodes codewords, and generates bits from 35 run counts all in a pipeline fashion. An embodiment of the pipeline structure for the decoding system is shown in Fig. 15A. The embodiment of the pipeline decoding process according to the invention is shown in six steps numbers 1-6 in Fig. 15A.

1001317.

73

In the first stage, the current context bin is determined (1501). In the second stage, after the context bin has been determined, a memory is read (1502) extracting the current context bin decoder status from the memory. As indicated above, the decoder status includes the PEM status and the bit generator status.

In the third stage of the pipeline decoding process according to the invention, a decompressed bit is generated (1503). This allows a bit to be available for the context model. Two other operations take place during the third stage. The PEM status is converted into a code type (1504) and in the third stage also the determination is made whether a new code word is to be decoded (1505).

During the fourth stage, the decoding system processes a codeword and / or updates the run count (1506). Several sub-operations 15 are involved in processing a codeword and updating the

V

run count. For example, a codeword is decoded to determine the next run count or the run count is updated for the current codeword (1506). If necessary, more coded data is retrieved from the input FIFO when decoding new codewords. Another sub-operation that takes place in the fourth stage is updating the PEM status (1507) - Finally, in the fourth stage of the decoding pipeline, the new PEM status is used to determine what the runlength zero code word (is as described) is for the next code if the run count of the current codeword is zero 25 (1508).

During the fifth stage of the decoding pipeline according to the invention, the decoding status with an updated PEM status is written into the memory (1509) and the shift for the next codeword (1510) begins. In the sixth stage, the shift to the next codeword is completed (1510).

The pipeline decoding according to the invention actually starts with a decision whether or not to start the decoding process. This decision is based on whether there is enough data for the decoder of the present invention. If there is not enough FIFO data, the decoding system is stopped. In another case, the decoding system can be stopped if the decoded data is delivered to a peripheral device that is unable to receive all the data at the decoder output during its generation. output signal to the interface of a video display unit with its associated video circuitry, then the video may be too slow so that the decoder must be stopped to allow the video to join.

Once the decision has been made to start the decoding process, the current context bin is determined by the context model. According to the present invention, the context bin is determined by examining previous data. This preliminary data can be stored in line buffers and can contain data from the current line and / or previous lines. For example in a context template for a certain bit. Bits from the line buffer (s) can be designed using a template with respect to the previous data so that the context bin for the current data is selected depending on whether the examined previous data matches the template. These line buffers can be provided with bit shift registers. A template can be used for any bit plane of an n-bit image.

In one embodiment, the context bin is selected by outputting an address to the memory during the next pipeline stage. The address can include a predetermined number of bits, for example three bits, to identify the bit plane. By using three bits, the bit position in the pixel data can be identified. The template used to determine the context can also be represented as part of the address. The bits used to identify the bit plane and the bits identifying the template can be combined to create an address for a specific location in memory that contains the state information for the context bin defined by these bits. By using three bits to determine the bit position in a given pixel and the ten preceding bits in the same position in each of the preceding pixels in the template, a 13 bit context address can be generated.

Using the address created by the context model, the memory (e.g., a RAM) is accessed to obtain status information. The status includes the PEM status. PEM status includes the current probability estimate. Since more than one state uses the same code, the PEM state does not contain a probability class or code designation, but instead an index with a table, such as the table shown in Fig. 5 When using a table as shown in Fig. 5, the PEM status also provides the most likely symbol (MPS) as a means of identifying whether the current PEM status is located on the positive or negative side of the table. The bit generation status may include the counter value and an indication of whether or not an LPS is present. In one embodiment, the MPS value for the current run is also included for decoding the next codeword. According to the present invention, the bit generator status is stored in memory in order to reduce the space required for the run counters. If the cost of space in the system for the counters for each context is low, the bit generation status need not be stored in a memory.

As soon as the fourth stage is completed, the new bit generator status and the PEM status are written into memory. Also in the fifth stage, the coded data stream is shifted to the next codeword. The shift operation is completed in the sixth stage.

Fig. 14C is a block diagram of an embodiment of the F1F0-20 structure 1401 of the invention and illustrates buffered words for two decoders. It is noted that any number of decoders can be supported using what is described herein. As shown, the input data and FIFO are wide enough to contain two words interleaved. The FIFO 251401 includes the FIFO 1460, the registers 1461-62, the MUX and 1463-1464 and the control block 1465. The two input code words are supplied as input words interleaved. The outputs of the FIFO 1460 are linked to the inputs of registers 1461-1462. The inputs of the MUX 1463 are coupled to the outputs of the registers 1461 and 1462. The control block 1465 is connected to supply control signals to the FIFO 1460, registers 1461 and 1462 and MUX-en 1463 and 1464. Interleaved words form the output data (output data 1 and 2) that are supplied to two decoders. Each decoder uses a request signal to indicate that the current word has been used and then a new word is needed. The decoder request signals are applied to the inputs of control block 1465. Control block 1465 also outputs a FIFO request signal to request more data from the memory.

1001317 V

76

Initially, the FIFO and registers 1461 and 1462 are filled with data and a valid flip-flop is set in the controller 1465. As soon as a request occurs, the control block 1465 provides data according to the logic shown in Table P.

5

Table P

Both Request Request Multi- Multi- Next FIFO and valid 1 2 plexer 1 plexer 2 both register valid release KKBsunsas Kssansssc ssbhbbmkmk ^^^^^^ b ^ bb ooo I x * X oo 10 0 0 1 X REG 1462 1 1 0 1 0 REG 1462 X 1 1 0 11 REG 1462 FIFO v 0 1 1 0 0 XX 1 0 1 0 1 X REG 1461 0 0 15 1 1 o REG 1461 X 0 0 1 1 1 REG 1461 REG 1462 1 1 * X means " don't care "20 Fig. 15B illustrates another conceptual view of the decoder of the invention. According to Fig. 15B, (coded) variable length data is input into a decoder. The decoder outputs fixed-length (decoded) data. The output signal is fed back as a delayed feedback signal which is received as an input signal in the decoder. In the decoder according to the invention, a variable length shift is used in the decoding process based on the decoded data available after a certain delay. The feedback delay does not reduce the throughput in the delay-tolerant decoder.

The variable length input data is divided into fixed length interleaved words as described in conjunction with Fig. 4.

The decoder uses the fixed length words as described below with reference to Fig. 16A. The decoder and delay 1001317 77 model a pipeline decoder as described in connection with Figures 15 and 32 or a number of parallel decoders as described in connection with Figures 2A-2D. The present invention therefore provides a delay tolerant decoder. The delay-tolerant decoders of the invention allow for parallel processing of variable length data.

known decoders (e.g. the Huffman decoders) are not delay tolerant. Information from the decoding of all previous codewords is required to perform a variable length shift needed to decode the next codeword. On the other hand, the present invention provides delay tolerant decoders.

Shift in the decoding system. The decoder according to the present invention provides an

V

shift logic for shifting the interleaved words to the appropriate bit generator for decoding. The shifter according to the invention does not require a particular type of "via context" or "via probability" parallel mechanism. An encoder is set which assigns code word M to stream M mod N (MJ N N in the C language), where N is the number of streams. In the present invention, coded data from the current stream is presented until a codeword is requested. Only then is the data transferred to the next stream.

FIG. 16 illustrates an embodiment of the decoder shifter of the invention. The 1600 shifter is designed for four data streams. This allows four clock cycles for each shift operation. The interleaved words are 16 bits and the longest codeword is 13 bits. In FIG. 16, the shifter 1600 includes four registers 1601-1604 connected to receive input signals from the interleaved coded data. The outputs of each of registers I601-1604 are connected to inputs of a MUX I605. The output of the MUX 1605 is coupled to the input of a drum shifter 1606. The output of the drum shifter 1606 is connected to the inputs of a register 1607, a MUX & registers I6O8-I6IO and a unit of measure l6ll. The output of the measuring unit 1611 is coupled to an accumulator 1612. The output of the accumulator I6l2 is fed back and connected to the drum shifter I6O6.

10013Π 78

An output of the register 1607 is connected to an input of the MUX & register I6O8. An output of the MUX & register I6O8 is connected to an input of the MUX & register 1609 · An output of the MUX & register 1609 is connected to an input of the MUX ί. register 5 I610. The output of the MUX & register 1610 carries the aligned encoded data. In one embodiment, registers 1601-1604 are all 16-bit registers, drum shifter I6O6 is a 32-bit to 13-bit drum shifter, and accumulator 1612 is a 4-bit accumulator.

The registers 1601-160 * 1 accept 16-bit words from the FIFO and feed them to the drum shifter l606. At least 32 bits of unencrypted data are each supplied to the drum shifter 1606. The four registers 1601-1604 are initialized with two 16-bit words of encoded data to start. This allows at least one new codeword to be available for each stream.

For R codes, the codeword measure 1611 determines whether an "0" or "IN" codeword is present and if it is an "IN" codeword, how many bits after the "1" are part of the current codeword. The unit of measure, which performs the same function, has already been described with reference to Fig. 12. For other codes, determining the size of a codeword is known in the art.

The shifter 1600 includes a four register FIFO, three of which have multiplexed inputs. Each register of the register group I6O7-I6IO contains at least one codeword and the width of the registers and multiplexers is therefore 13 bits, which corresponds to the longest possible codeword. Each register also has an associated control flip-flop (not shown to avoid confusion) that indicates whether a particular register contains a codeword or waits for the drum shifter I606 to provide a codeword.

30 FIFO will never be empty. Only one codeword can be used per clock cycle and one codeword can be shifted per clock cycle. The delay for performing the shift is compensated because the system defies with four code words. As each codeword is shifted to obtain the aligned coded output 35 data, the other codewords in the registers I6O7-I6IO are shifted down. If the codeword left in the FIFO is stored in the register 1620, the drum shifter 1606 reads codewords from the registers

1001317 A

79 I601-1604 via the MUX 1605 to fill the registers I6O7-I6O9. It is noted that the FIFO may be configured such that the register I6O7 is refilled with the next codeword once its codeword has been shifted to register I6O8.

The drum shifter I606, the codeword size calculator 1611 and the accumulator 1612 handle the variable length shift. The accumulator I6l2 has four registers, one for each encoded data stream, containing the alignment of the current codeword for each data stream. The accumulator 1612 is a four bit accumulator used to control the drum shifter 1606. The accumulator 1612 increases its value by the value received at the input from the codeword measure 1611. If the accumulator 1612 has an overflow (ie, whenever the shift count is 16 or more), registers 1601-1604 are clocked to shift. For the other 16 bit shift, a new 32 bit word is requested from FIFO. The input to the accumulator 1611 is the measure of a codeword, which is determined by the current code and the first one or two bits of the current codeword. It is noted that in some embodiments, registers 20 1601-1604 initialize; rd must be encoded with data before decoding can begin.

When a code word is requested by the system, the V registers are clocked into the FIFO so that the code words move to the output. When the drum shifter I6O6 is ready to issue a new code 25 word, it is multiplexed into the first empty register in FIFO.

In this embodiment, the following code word signal is received from the bit generator before the decision to switch flows is made.

If the next codeword signal from the bit generator is not guaranteedly received prior to the decision to switch vein current, a forward looking system such as the system shown in Fig. 16B may be used. In Fig. 16B, a forward looking sliding unit 1620 is shown in block diagram form. The shift unit I62O includes a shifter 1600 which outputs the currently encoded data and the next encoded data. The current coded data is supplied to an input of a logical code word preprocessing unit 1621 and an input to a codeword processor 1001317 <80 operating unit 1624. The following coded data is supplied to an input of a logical codeword preprocessing unit 1622. The outputs of the two logical preprocessing units 1621 and 1622 are connected to the inputs of a MUX 1623. The output of the MUX 5 1623 is coupled to another input of the codeword processing logic 1624.

The logic using the codeword is divided into two parts, the codeword preprocessing logic and the codeword processing logic. Two identical pipeline preprocessing units 1621-1622 operate before the interleaved stream can be shifted. One of the pre-processing units 1621-1622 generates the correct information when power is switched and the other generates the information when power is not switched. When the power is switched, the output of the correct codeword preprocessing unit is multiplexed by the MUX 1623 to the codeword processing logic 1624 which completes the operation on the correct codeword.

Non-chip memory and context models

In one embodiment, it may be desirable to use multiple chips 20 for external memories or external context models. In these embodiments, it is desirable to reduce the delay between generating a bit and having the bit available in the context model if multiple integrated circuits are used.

FIG. 17 illustrates a block diagram of an embodiment of a system with both an external context model chip 1701 and an encoding chip 1702 with memory for each context. It is noted that only the units relevant to the context model are shown in the coding chip; It will be apparent to those skilled in the art that the encoding chip 1702 provides bit generation, probability estimation, etc. The encoding chip 1702 of Figure 17 includes a zero order context model 1703. context models 1704 and 1705, selection logic 1706, a memory controller 1707, and a memory 1708. The zero order context model 1703 and the context models 1704 and 1705 generate output signals applied to the inputs of the selection logic 1706. The other input of the selection logic 1706 is connected to an output of the external context model chip 1701. The output of the selection logic 1706 is connected to an input of a memory 1708. Also coupled 1001317 81 to an input of the memory 1708 is an output of the memory controller 1707 ·

The selection logic 1706 allows to use either an external context model or an internal context model (e.g., the 5 zero order context model 1703. context model 1704, context model 1705). The selection logic 1706 makes it possible to use the internal zero order portion of context model 1703 even if the external context model I7OI is used. The zero order context model 1703 provides one or more bits while the external context model chip 1701 provides the remainder. For example, the immediately preceding bits can be fed back and retrieved from the zero order context model 1703 while the preceding bits go to the external context model 1701. In this way, the time-critical information remains on the chip itself. This eliminates the off-chip communication delay for recently generated 15 bits.

Fig. 18 is a block diagram of a system with an external context model 1801, an external memory 1803 and an encoding chip 1802. According to FIG. 18, some memory address lines are driven by the external context model 1801 while others are driven by the "zero order" 20 context model in the decoding chip. 1802. That is, the context of the immediately preceding decoding cycle is controlled by the zero order context model. This allows the decoding chip to provide immediate past context information with minimal communication delay. The context model chip 1802 precedes the rest of the context information by using bits decoded further in the past to allow the communication delay. In many cases, the contextual information from the immediate past is a zero-order Markov state, and the contextual information from the further past is a higher-order Markov state. The embodiment shown in Fig. 18 eliminates the communication delay inherent in implementing a zero-order model in the external context model chip 1802. However, there may still be a delay from context bin determination to bit due to the decoding chip 1802. and the memory 1803.

It is noted that a different memory architecture can be used. For example, a system is used with the context model and the memory in one chip and the encoder in another chip. The system may also include an encoding chip with 1001317 an internal memory used for some contexts and an external memory used with other contexts.

82

Bit generators using a memory 5 19 shows a decoder with a pipeline bit generator using a memory. In Fig. 19, the decoder 1900 includes a context model 1901, memory 1902, PEM status-to-code block 1903. pipeline bit generator 1905. memory 1904 and shifter 1906. The decoded data from the pipeline bit generator 1905 is supplied to the input of context model 1901. The inputs of the shifter I9O6 are connected to receive the encoded data. The output of the context model 1901 is connected to an input of the memory 1902. The output of the memory 1902 is connected to the PEM status-to-code 1903. The output of the PEM status-to-code 1903 and the aligned coded output data from the shifter 1906 is applied to the inputs of the bit generator 1905 · The memory 1904 is also coupled to the bit generator 1905 using a bidirectional bus. The decoded data is at the output of the bit generator 1905.

The context model 1901 outputs a context bin at the output in response to the encoded data at its inputs. The context bin is used as the address for addressing the memory 1902 based on the context bin to obtain a probability status. The probability status is received by the PEM status-25 to code module 1903 which generates the probability class in response to the probability status. Then, the probability class is used as the address to access memory 1904 to obtain the run count. The run count is then used by the bit generator 1905 to produce the decoded data.

In one embodiment, memory 1902 includes a 1024 x 7 bit memory (where 1024 is the number of different contexts) while memory 1904 includes a 25 x 14 bit memory (where 25 is the number of different run counts).

Since the bit generator states (run counts, etc.) are associated with probability classes, not context bins, there is a further pipeline delay before a bit is available with the context model. Since updating a bit generator status requires multiple clock cycles (the delay due to repeated access to * 1001311 83 the bit generator status memory), multiple blt generator states will be used for each probability class. For example, if the pipeline is six clock cycles, the bit generator status memory will have six entries per probability class. A counter is used to select the correct memory location. Even with multiple data entries per probability class, the size of the memory will generally be smaller than the number of contexts. The memory can be implemented with either multiple SRAM banks or a multiple input 10 port register file.

Because one run count may be associated with a number of contexts, an embodiment must upgrade the probability estimate of one or more contexts. In one embodiment, the PEM state of the context causes the end of a run. Updated 15.

V

Instead of reading, modifying and writing a run count before it can be read again, a run count can be used once the modification is complete.

Fig. 32 illustrates a time chart of the decoding operation in an embodiment of the invention. In Fig. 32, a three cycle deodorizing operation is shown. The signal names are listed in the left column of the time diagram. The validity of the signal is indicated by a band during the cycle (or part thereof). In some instances, the unit or logic responsible for generating the signal or delivering the valid signal is shown adjacent to the valid signal indication in a dotted line. In addition, examples of specific elements and units are indicated on a number of points. It is noted that each part of the signal extending into another cycle only indicates the validity of that signal for that period of time in which the signal shown extends into the other cycle. Also, certain signals are shown as being individually valid for more than one cycle. ”An example of this is the temporary runtime signal valid at a point at the end of the second cycle and then again during the third cycle. It is noted that this indicates that the signal is only recorded at the end of the cycle. A list of dependencies is further shown in Table Q below, which table shows the dependencies * 2 0 u "i" 1 7 84 between the same or previous clock cycle and the current time at which the signal is specified as valid.

Table Q

5 Name__ Unit * Dependencies ** register file 1__CM __ {previous bit, CM shift register) status to code__CM__ register file 1_ drum shift SH {accumulator register, unaligned ___ coded data registers} _ measure SH output drum shifter (aligned ___ coded data) {K, R3} _ 10 accumulator SH size {previous accumulator register ___ value} _ register file 2 BG __ {K, R3 registered} _ q (codeword required) BG__ register file 2 code to {mask, BG (X, R3 registered} maxRL, R3split) ___ 15 generator bit BG register file 2 drum shifter -output (aligned coded data) code to (mask, maxRL, R3split) _________________ {register file 1, registered MPS} decode BG drum shifter output (align the coded data) ___code to (mask, maxRL, R3split) _ PEM table__PEM __ (X , R3 registered} _ β (PEM update) ** PEM {registered: PEH table output, current LPS, continue} _ -1 (run count BG {registered: codew required last updated) registered, Tcun count, current LPS, ___ continue} _ γ (continue, update BG {registered: required codeword, of current LPS___runtelling, current LPS, continue} _

* CM = context model, SH = shifter, BG = bit generator, PEM

25 = probability estimation machine.

** '{italic} indicates the dependencies of the previous clock cycle.

in one embodiment, most combinatorial logic for updating the PEM status is performed in the "PEM 30 table" step, "PEM update" is simply a multiplex operation.

mni3l7 85

Implicit signaling

In certain embodiments, the decoder must model the encoder finite registration buffer. In one embodiment, this modeling is accomplished with implicit signaling.

As previously stated with respect to the encoder, when a codeword is started in the encoder, space is reserved in the appropriate codeword buffer in the order in which the codewords are to be placed on the channel. When the last space in the buffer is reserved for a new codeword, some codewords are placed in the compressed bitstream regardless of whether or not they are fully determined.

If a partial codeword is to be completed then a codeword can be chosen that is short and correctly specifies the 15 symbols received so far. For example, if in an R coding scheme 1 it is necessary to complete a codeword for a series of 100 MPSs in a runcode with a maximum run length of 128 premature, the codeword for the 128 MPSs is used at core because this correctly specifies first 100 symbols.

On the other hand, a codeword specifying the 100 MPSs followed by an LPS can be used. When the code word is complete, it is removed from the rearrangement buffer and added to the code stream. This makes it possible to place previously completed code words in the code stream. If the forced completion of a partial codeword results in the removal of a codeword from the full buffer, then the encoding can proceed. If a buffer is still full, the next code word must be completed again and added to the code stream. This process continues until the buffer that was full is no longer full. The decoder can model the encoder for implicit signaling using a counter for each memory location with bit generator status information.

In one embodiment, each run counter (probability class in this example) has a counter the same size as the 35 head or tail counters in the encoders (e.g., 6 bits). Each time a new run is started (a new codeword is fetched), the corresponding counter is loaded with the code word memory size. All counters are decremented each time a run is started (a new codeword is retrieved 1001 317 86). Any counter that reaches zero will clear the corresponding run counter (and reset the LPS flag present).

5 Options bi-1 signaling for finite memory

The real time encoding of the invention requires the decoder to handle runs of MPSs that are not followed by an LPS and do not have the maximum run length. This happens when the coding unit starts a run of MPSs but does not have sufficiently limited rearrangement memory to wait until the run is complete. This state requires a new codeword to be decoded the next time this context bin is used and this state must be signaled to the decoder. Three potential ways of modifying the decoder are described below.

If the buffer is full, the run count for the context bin or probability class that is forced to be issued must be reset. To perform this efficiently, it is useful to store the context bin or probability class in the codeword memory. Since this is only necessary for runs that do not yet have an associated codeword, the memory used to store the codeword can be shared. Instead of forcibly delivering an incomplete code word, in some systems bits can be forcibly entered in the context / probability class of the (or any) code word present in the buffer when the buffer is full. The decoder detects this and uses the corresponding (wrong) context bin or probability class.

Signaling in the stream uses codewords to signal the decoder. In one embodiment, the R2 (k) and R3 (k) 30 code definitions are modified to include the non-maximum length runs of MPS, which are not followed by an LPS. This can be implemented by adding one bit to the codeword to occur at the lowest probability. This allows a unique decodable preposition for non-maximal length run-counts. Table R shows a replacement for the R2 (2) codes that allow signaling in the flow. The drawbacks of this method are that the decoding logic for the R code has to be changed, and this decreases the compression every time a code word with the lowest probability 1001317 87 occurs.

Table R

Original data Code word 5 0000 0 0001 1000 001 101 01 110 1 111 10 000 100 100 00 100 101 0 10011

In some embodiments, the decoder performs an implicit signaling using time markers. A counter keeps the current "time" by incrementation each time a codeword is requested. Also, when a codeword is started, the current "time" is stored in a memory associated with the codeword. Whenever a codeword is used after the first time, the corresponding stored "time" value plus the encoder rearrange buffer measure is compared to the current "time". If the current "time" is greater, an implicit signal is generated so that a new code word is requested. In this way, the limited rearrangement memory in the encoder is simulated. In one embodiment, enough bits for "time" values are used to number all code words.

To reduce the required memory, the number of bits used for the time marks is kept to a minimum. If the time markers use a small number of bits so that the time-30 values can be reused, ensure that all old time markers are noted before the counter starts reusing times. Suppose N is the largest of the number of address bits for the queue or bit generator status memories. Time markers with N + 1 bits can be used. The bitgener 1001317 88 rator status memory must support multiple accesses, for example, two read and two write operations per decoded bit. A counter is used to cycle cyclically through the bit generator state memories, which counter is incremented once for each decoded bit. Any memory location that is too old is cleared, so a new codeword is retrieved when needed in the future. This guarantees that all time markers are checked before a time value is reused.

If the bit generator status memory is smaller than the queue, the counting speed (the time marker counter) and the required memory bandwidth can be reduced. That's because each time marker (one per bit generator status memory) only needs to be checked once per number of cycles required to use the entire queue. Storing time markers in different memories can also reduce the required memory bandwidth. In a system using "0" code words for partial runs, the time markers need not be checked for "IN" code words. In a scheme using "IN" codewords for partial runs, the time marker should only be checked prior to generation of an LPS.

In some embodiments, the implicit signaling is implemented with a queue during the decoding. This method can be useful in a half duplex system in which the encoding hardware is available during decoding. Queue operation is substantially the same as during encoding. When a new codeword is requested, the index is queued and marked as invalid. When the data vein a codeword is completed, its input in the queue is marked as valid. While data is being queued to make way for new 30 code words, if the extracted data is marked invalid, the bit generator status information for this index is cleared. This erase operation may require the bit generator status memory to be able to support an additional write operation.

In contrast, explicit signaling communicates a buf-35 ferrite overflow as compressed data. An example is having a helper context bin used once for each normal context bin decoding or twice for each codeword to be decoded. Bits decoded from the auxiliary context bin indicate 1001317 δ9 whether the new codeword-needed state occurs and a new codeword to be decoded for the corresponding normal context bin. In this case, the code words for this special context must be correctly rearranged. Since the use of this context is a function of something known to the rearrangement unit (typically it is used once for each codeword), the memory required to rearrange the auxiliary context can be limited or implicitly modeled. The possible codes allowed for this help context can also be limited.

10 Implicit signaling models the coded unit's bounded buffer when the decoding for generating a signal indicates that a new codeword is to be decoded. In one embodiment, the time marker is maintained for each context. In one embodiment, the encoder rearrange buffer with limited dimensions of the encoder is modeled directly. Since in a half duplex system the rearrangement circuits in the encoder are available during decoding, they can be used to generate signals for the decoder.

Exactly how implicit signaling is obtained depends on the details of how the encoder recognizes and treats a full buffer state. For a system using a fixed-allocation mixed queue, using multiple v headers gives choices for what "buffer full" means. Based on a particular design for the encoder, a suitable model can be designed.

The following relates to the encoding operation and a model for use by the decoder in a mixed queue with fixed current allocation, in parallel per probability system. For example, it is assumed that the rearrangement buffer has 256 locations, that 4 interleaved streams are used, and each interleaved word contains 16 bits. If the buffer 256 contains input data, an input data must be output to a bit packer (e.g. a bit pack unit) before the input data for the 257th code word can be queued. If necessary, data entered can be compulsorily released earlier.

In some systems, removing the first data entry in the buffer requires removing enough bits to complete a fully collapsed word. Therefore, if 1-bit code 1 (j 0 i Ö i 7 90 words are possible), the removal of the codeword 0 may also require the removal of the codewords 4, 8, 12 ..... 52, 56, 60 for 16 bit interleaved To ensure that all these buffer inputs have valid input data, input required 5 because the memory is full can be performed at address 64, 192 places from the location where a new code word is entered (256 - 16 x 4 = 192).

There is a counter in the decoder for every probability. If a new codeword is used to start a run, the counter is loaded with 192. Each time a new codeword is used at any probability, all counters are decremented. When a counter reaches zero, the run length is reset to zero for that probability (and the LPS present flag is reset).

15 It may be useful to use multiple RAM banks (multi-port memory, fast memory simulation, etc.), one bank per encrypted data stream. This allows all bit pack units to receive data simultaneously so that reading multiple code words for a given stream does not interfere with reading by other streams.

In other systems, multiple bit pack units must arbitrate about a single memory based on the codeword order stored in the buffer. In these systems, the removal of a buffer does not have to mean the completion of a collapsed word. Each bit pack unit typically receives a fraction of a collapsed word successively. Each bit pack unit receives at least a number of bits equal to the shortest codeword length (e.g. 1 bit) and a maximum number of bits equal to the longest codeword length (e.g. 13 bits). Interleaved words cannot be issued until they are completed and must be issued in the order of initialization. In this example, a bit pack unit may need to buffer 13 interleaved words, this is the maximum number of interleaved words that can be completed with maximum length code words while another stream is busy with an interleaved word containing minimum length code words receive.

A system where each code word requires two write operations and one memory read operation may be less desirable for a hardware implementation than a system that requires two write operations

1001317 I

91 and perform two reading operations. If desired in the four stream example system, bit pack units 1 and 2 could share a memory read cycle and bit pack units 1 and 3 could share the other read cycle (or any other arbitrary combination). Since this would not reduce the dimensions of the required buffer, a high transfer rate in the bitpack unit is thereby possible. This makes it possible for the bitpack units to make better use of the capacity of the encrypted data channel.

10 Fixed size memory systems

An advantage of a system that has multiple bit generator states per probability class is that the system can support lossy encoding when the fixed size memory has an overflow. This can be useful for frame compression image compression 15 and other applications that can only store a limited amount of encoded data.

For fixed size memory systems, the multiple bit generator states are assigned to a portion of the data for each probability. For example, each of the eight states can be assigned 20 to a particular bit plane for eight bit data. In this case, a shifter is also assigned to each part of the data as opposed to shifters that sequentially provide the next codeword. It is noted that the data need not be divided per bit plane. Also, no encoding 25 is performed in the encoder, each part of the data is simply subjected to a bit pack operation. Memory is allocated to each part of the data.

Encrypted data memory management is presented for systems that store all data in fixed size memory and for systems that transfer data in a channel with a maximum allowable bandwidth. In both systems, an elegant relegation to a system with loss is desirable. Different data streams are used for data with different importance, so that less importing data streams can be stored or not broadcast if there is not enough storage or bandwidth available.

If memory is used, the encoded data must be stored in such a way that it is accessible in such a way that the less importing data streams can be disregarded without losing the possibility of decoding the important data streams.

100Ί3Π * 92

Because the encoded data has a variable length, a dynamic memory allocation can be applied. Fig. 31 shows an example of a dynamic memory allocation unit for three encrypted data streams. A register file 3100 (or other storage medium) contains a pointer for each data stream plus another pointer for indicating the next free memory location. Memory 3101 is divided into fixed size pages.

Initially, each pointer assigned to a stream indicates the start of a memory page, and the free pointer indicates the next available memory page. Encrypted data from a particular stream is stored in the memory location addressed by the corresponding pointer. The pointer is then incremented to the next memory location.

When the pointer reaches the maximum for the current page, the following occurs. The address of the beginning of the first free page (stored in the free pointer) is stored with the current page (either as part of the encrypted data memory or a separate memory or register file is used). The current pointer is set on the next free page. The free hand is incremented. These actions assign a new memory page to a particular stream and provide links so that the allocation order can be determined during decoding.

If all pages in memory are in use and more data is coming out of the stream that is more important than the least important data in memory, one of three things can happen. In all three cases, the memory allocated to the least important data stream is reassigned to the more important data stream and no data from the less important data stream is stored.

30 First, the page currently used by the least important data stream is simply assigned to the more important data. Since most typical entropy encoders use internal status information, all the least important data previously stored on that page is lost.

Second, the page now in use by the least important stream is simply assigned to the more important data stream. In contrast to the previous case, the pointer is set at the end of the page, and while the more important 100131 "93 data is written into the page, the corresponding pointer is decremented. This has the advantage that the least important data is at the beginning of the page. page is kept if the more important data stream does not need the entire page.

5 Third, instead of the current page with the least important data, any other page with less important data can be reassigned. This requires that the encoded data for all pages be encoded independently, which can reduce the achievable compression. It is also necessary that the unencoded data 10 be identified corresponding to the beginning of all pages. Because any page with less important data can be disregarded, greater flexibility in elegant encoding degradation at a loss is possible.

The third alternative may be especially attractive in a system 15 that achieves a fixed compression rate over areas of the image. A specified number of pages can be assigned to an area of the image. Whether or not less important data is retained depends on the compression achieved in a particular area (the memory allocated to an area should not be fully utilized if the lossless compression required less than the amount of allocated memory). Achieving a fixed amount of compression on an area of the image can support arbitrary access to the image areas.

The ability to write data into each page from both ends can be used to better utilize the total amount of available memory in the system. If all pages are assigned then any page that has enough free space at the end can be allocated for use from that end. The ability to use both ends of a page must be weighed against the cost of tracking the location where the two types of data meet (this is different from the case where one of the data types was not important and could simply be overwritten).

We now consider a system in which data is transferred in a channel instead of being stored in a memory. Fixed size memory pages are used but only one page is required per stream. (Perhaps two if ping-pong operations are required to provide a buffer for the channel 1001317 94 so that one page can read the other while writing). When a memory page is full, it is transferred in the channel and the memory location can be reused once the page has been transferred. In some applications, the page size of the memory may be equal to the size of the data packets used in the channel or a multiple of the packet dimensions.

In some communication systems, for example ATM (asynchronous transfer mode), the packets can be assigned priorities. ATM has two priority levels, a primary and a secondary level. Secondary packets are only transferred if sufficient bandwidth is available. A threshold can be used to determine which flows are primary and which are secondary. Another method would be to use a threshold in the encoder so that no streams less important than a threshold are emitted.

Separate bit generators for each code

Fig. 20 is a block diagram of a system with separate bit-20 generators for each code. The decoding system 2000 of FIG. 20 includes the context model 2001, memory 2002, PEM status-to-code block 2003. decoder 2004, bit generators.2005A ... N, and shifter 2006. The output of context model 2001 is connected to an input from memory 2002. The output from memory 2002 is connected to an input of PEM 25 status-to-code block 2003 · The output of PEM status-to-code block 2003 is coupled to an input of the decoder 2004. The output of decoder 2004 is coupled to the enable input of the bit generators 2005A ... N. The bit generators 2005A ... N are connected to receive coded data output signals from the 2006 shifter.

Context model 2001, memory 2002 and PEM status-to-code block 2003 act as their counterparts in fig. 19. Context model 2001 generates a context bin. Memory 2002 issues a probability status based on the context bin. ” The probability status is received by the PEM status-to-code block 2003 which generates a probability class for each probability condition. Decoder 2004 releases one of the bit generators 2005A ... N when decoding the probability class. (It should be noted that the 2004 decoder is an M to 2M decoder circuit similar to a 7 * 1x138 3 ^ 8 decoder known per se 10013Π 95, not being an entropy coding decoder). Because each code has a separate bit generator, some bit generators can use other than R codes. In particular, a code for probabilities near 60% can be used to better frame the probability space between R2 (0) and R2 (1). Table S, for example, gives such a code.

Table S

Uncoded data Code word ΒΗΗΜΜΗΗη ············· Η · Β ^^ Μ · Β ·· ^ Η ···· Μ ··· 10 0 0 0 0 0 0 0 1 0 1 0 1 10 1 11, 15 If necessary to achieve the desired rate, pre-decoding of one or more bits can be performed to ensure that the decoded data is available quickly. In order to avoid the need to update a large run count with each clock cycle, in some embodiments both the codeword decoding 20 and the long code run count are partitioned.

The bit generator for R2 (0) codes is straightforward. A codeword is requested every time a bit is requested. The generated bit is simply the codeword {via an exclusive 0F function combined with the MPS).

Short run length codes, for example R2 (1), R3 (1), R2 (2) and R3 (2) are treated in the following manner. All bits in a codeword are decoded and stored in a state machine containing a small counter (1, 2 or 3 bits, respectively) and an LPS bit present. The counter and the LPS present bit act as an R-code decoder.

%

For long codes such as R2 (k) and R3 (k) for k> 2, the bit generators are partitioned into two units as shown in Fig. 21. In Fig. 21, a bit generator structure for R2 (k) codes with k> 2 is shown with a short run unit 2101 and a long run unit 2102.

Although the structure is intended for use with R2 (k> 2) codes, its operation is similar for R3 (k> 2) codes (as will be apparent to those skilled in the art.

The short run unit 2101 is connected to receive a release signal and a codeword [0 ... 2] as inputs in the bit generator and an all zero signal and a "zero count" signal (indicating a zero counter position) both of the long run unit 2102. In response to these input signals, the short run unit 2101 outputs a decoded bit at the output as well as a subsequent signal indication, signaling that a new code word is needed. The short run unit 2101 also generates a counter enable signal, a counter load signal and a counter max signal to the long run unit 2102. The long run unit 2102 is also connected such that the code word [k ... 3] is input to the bit generator. being received.

The short run unit 2101 handles runs up to 4 in length and is similar to an R2 (2) bit generator. In one embodiment, the short run unit 2101 is equal for all R2 (k> 2)

V

codes. The purpose of the long run counter 2102 is to determine when the last 1-4 bits of the run are delivered to the output. The long run unit 2102 has inputs, AND logic, and a counter that varies in size by k.

An embodiment of the long run counter unit 2102 is shown in Fig. 22. The long run unit 2102 shown in this figure includes the EN logic 2201 which is connected. for receiving the codeword [k - 3] and outputting a all-one signal as logic 1 if all bits in the codeword are equal to 1, indicating that the current codeword is an IN codeword and that the run count is less than 4. The NON logic 2202 is connected such that it receives and inverts the codeword. The output of NON logic 2202 is connected to an input of a bit counter 2203. The bit counter 2203 additionally receives a counter enable 30 signal, a counter load signal and a counter max signal. In response to the input signals, the bit counter 2203 generates a counter zero signal.

In one embodiment, counter 2203 is a k-2 bit counter and is used to break down long run counts into runs of four 35 MPSs and a possible remainder. The counter enable signal indicates that four MPSs have been output and the counter is to be decremented. The counter load signal is used in decoding "IN" codewords and causes the counter to be loaded 1001317 - 97 with the complement of the codeword bits kt / m · The counter max signal is used in decoding "0" codewords and loads the counter with its maximum value. A counter zero output signal indicates that the counter is at zero.

An embodiment of the short run counter unit 2101 is shown in Fig. 23. In Fig. 23, the short run counter unit includes a control module 2301, a two-bit counter 2302 and a three-bit counter 2303. The control module 2301. receives a release signal, the code word [0 ... 2] and the all-one signal as well as the counter zero signal from the long run counter unit. The two-bit counter is used for counting four bit-runs for MPSs that are part of longer runs. An R2 (2) counter and an LPS bit (three bits in total) 2303 is used to generate the 1-4 bits at the end of a run. The enable input indicates that a bit must be generated on the bit output. The counter zero input, if not set, indicates that a run of four MPSs should be output. As soon as the MPS counter 2302 reaches zero, the counter enable output is set. When the counter zero input is set, either the R2 (2) counter is used with the LPS or a new code word is decoded and the next output is set.

If the new codeword is decoded, the actions performed are determined by the codeword at the input. If the input has a "0" codeword, the MPS counter 2302 is used and the counter max output is energized. For "IN" codewords, the first three bits of the codeword are loaded into the R2 (2) counter and LPS 2303 and the counter load output is energized. When the all-one input signal occurs, the R2 (2) counter and LPS 2303 are used to generate bits; in other cases, the MPS counter is used until a counter zero input occurs.

From a system perspective, the number of codes must be small for the system to function properly, typically 25 or less. The dimensions of the multiplexer required for the bit output signals and subsequent codeword output signals and the decoder for releasing a particular bit generator must be limited for fast operation. Also, the fan-out of the shifter's codeword should not be too high for a fast operating speed.

100131771 98

Separate bit generators for each code allow for pipeline operation. If all code words resulted in at least two bits, the processing of the code words in pipeline operation could be performed in two cycles instead of one. This makes it possible to double the speed of the decoder if the bit generators form the limiting parts of the system. One way to achieve this is to have the run-length zero codeword (the codeword that only indicates an LPS) followed by one bit, which is the next unencrypted bit. This can be referred to as an RN (k) + 1 code and always encodes at least two bits. R2 (0) codewords and perhaps some of the other short codewords may not need to be pipelined for speed reasons.

Individual bit generators lend themselves for use with implicit signaling. Implicit signaling for finite memory encoding can be accomplished in the following manner. Each bit generator has a counter that is the size of a queue address, for example 9 bits for a queue with a size of 512. Whenever a new code word is used by a bit generator, the counter is loaded with the maximum value. Whenever a random bit generator requests a codeword, the counters of all bit generators are decremented. Each time a counter reaches zero, the status of the corresponding bit generator is cleared (for example, the MPS counter, the R2 (2) counter and the LPS and the long run length counter are cleared). Since this erasure can take place even if a certain bit generator is not enabled, there is no problem with outdated counters.

Memory initialization for each context bin

In cases where the memory for each context bin contains probability estimation information, additional memory bandwidth may be required to initialize the decoder (eg, the memory) very quickly. Rapid initialization of the decoder can be a problem if the decoder has many contexts and they all have to be brought into the initial state. If the decoder supports many contexts (IK or more 35) and the memory is not generally reset, an unacceptably large number of clock pulse cycles may be required to reset the memory.

In order to quickly reset the contexts, some embodiments of the present invention use an additional bit, referred to herein as the initialized status bit, and stored with each context. Thus, an extra bit is stored with the PEM status (e.g. 8 bits) for each context.

The memory for each context bin and the initialization control logic are shown in Fig. 24. The context memory 2401 in Fig. 24 is coupled to a register 2402. In one embodiment, register 2402 includes a one bit register that has the correct current status. for the initialized status bin. The register 2402 is connected to one input of the exclusive OR logic 2403. The other input of the exclusive 0F logic 2403 is coupled to an output of the memory 2401. The output of the exclusive 0F logic 2403 is a valid signal and is applied to one input of control logic 2404. Other inputs of control logic 2404 receive the output from counter 2405 and the context bins signal.

t

An output of control logic 2404 is applied to the selection inputs of MUXs 2406-2407 and an input of counter 2405 · Another output of control logic 2404 is coupled to the selection input of MUX 2408. The inputs of the MUX 2406 20 are coupled to the output of the counter 2405 and the context-bir indication. The output of MUX 2406 is coupled to memory 2401. The inputs of MUX 2407 receive the new PEM status and zero. The output of the MUX 2407 is coupled to one input of the memory 2401. The output of the memory 2401 and the initial PEM-25 status are applied to the input of MUX 2408. The output of MUX 2408 carries the PEM status output signal .

The value in register 2402 is complemented every time a decoding operation (i.e. every data set, not every decoded bit) occurs. The exclusive 0F logic 2403 compares the validity of the addressed memory location with the register value to determine whether the addressed memory location is valid for this decoding operation. This is performed using the exclusive 0F logic 2403 to check whether the initialized status bit matches the correct state in register 2402. If the data in memory 2401 is not valid, control logic 2404 causes the data to pass through the status-to-code logic is ignored and the initial PEM state is used instead. This is accomplished using the MUX 2408. When a new PEM status 4001317 100 is written into memory, the initialized bit is set to the current value of the register so that it will be considered valid when it is accessed again.

Each entry in the context bin memory must have an initialized status bit set to the current value of the register before another decoding operation can begin. The counter 2 * 105 steps through all memory locations to ensure that they are initialized. When a context bin is used but its PEM status is not updated, an unused write cycle 10 can be used to test or update the memory location pointing to the counter 2 * 105. If, after completion of a decoding operation, the counter 2 * 105 has not reached a maximum value, the remaining contexts are initialized before the start of the next operation. The following logic is used to control the operation.

writeJt - false; counter - 0; alljnitiallzed - false; while (counter <maximum context bln + 1) read PEM state trom conlext memory H ((counter - «context bin read) and (writeJl)) writejt - talse 20 counter - counter + 1

If ((PEM state changed) write new PEM state else If (writejt) write initial PEM state to mefnpry location "counter counter - counter + 1 else read memory location" counter 25 K (initialized bit in read location Is in wrong state) writejt true else counter - counter + 1 alljnitiallzed - true; while (decoding) read PEM state from context memory 3 ° if (PEM state changed) .write new PEM state PEM wet fast adaptation

The PEM used in accordance with the invention may include an adaptation scheme 35 to allow rapid adaptation regardless of the amount of data available. By doing this, the invention initially allows the decoding to adapt faster or the slower to adapt as more data is available, this as a means of providing a more accurate estimate. Furthermore, the PEM can be fixed In a field-programmable array of ports (FPGA) or In an ASIC implementation of a PEM status table / machine.

The tables T-Y below describe a number of probability estimation machines. Some tables do not use the R3 codes or use long codes to reduce hardware costs. All tables except Table T use "fast adaptive" special states for fast adaptation at the start of encoding until the first LPS occurs. These quick 10 adaptation states are shown in italics in the tables. If, for example, referring to table U, the decoding starts then the current state is the 0 state. If an MPS occurs, the decoder switches to state 35 · As long as MPSs occur, the decoder continues upward from state 35. with a possible transition to state 28. If an LPS occurs at any 15 time, the decoder goes from the ascending fast adaptive states to a state that represents the correct probability state for the data received so far.

It is noted that, after a certain number of MPSs have been received, for each table the decoder leaves the fast adaptive states. In the desired embodiment, once the fast adaptive states have been exited, no return is possible apart from restarting the decoding process. In other embodiments, the status table may be designed to re-enter these rapidly adapting states to allow for faster adaptation. The invention allows the decoder to access more "skewed" codes more quickly, taking more advantage of the improved compression. It is noted that the quick adaptation can be eliminated for a given table by changing the table input data for the current state 0 such that the table has only transitions over one state up or down depending on the data input.

For all tables, the data for each status is the code for that status, the next status for a positive update (up), and the next-35 status for a negative update (down). Asterixes indicate those states in which the MPS should be changed in a negative update.

1001317 102

Table T

House I Code Op Neer House Code Op Neerige I full full- full next- next next next 5th state state state state state position 0 r2 (0) 1 0 * 18 r3 (3) 19 17 1 r2 (0) 2 0 19 r2 (4) 20 18 2 r2 (0) 3 1 20 r3 (4) 21 19 3 r2 (0) 4 2 21 r2 (5) 22 20 10 4 r2 (0) 5 3 22 r3 (5) 23 21 5 r2 (0) 6 4 23 r2 (6) 24 22 6 r2 (l) 7 5 24 r3 (6) 25 23 7 r2 (l) 8 6 25 r2 (7) 26 24 8 r2 (1) 9 7 26 r3 (7) 27 25 15 9 r2 (l) 10 8 27 r2 (8) 28 26 10 r2 (l) 11 9 28 r3 (8) 29 27 11 r2 (l) 12 10. 29 r2 (9) 30 28 12 r3 (l) 13 11 30 r3 (9) 31 29 13 r3 (l) 14 12 31 r2 (10) 32 30 20 14 r3 (i) 15 13 32 r3 (io) 33 31 15 r2 (2) 16 14 33 r2 (11) 34 32 16 γ3 (2) 17 15 34 I Γ3 (11) 34 33 17 γ2 (3) 18 16

25 * switch to MPS

*

10013Π I

Table U

103

Hui- Code Op Neer Hui-Code Op Neerige full full full- full next- next next- 5th state- state state- state state state 0 I r2 (0) 35 35 * 22 r3 (5) 23 21_ 1 I r2 (0) 2 1 * 23 r2 (6) 24 22 2 r2 (0) 3 1 24 r3 (6) 25 23 -------- 3 r2 (0) 4 2 25 r2 (7) 26 24 10 4 r2 (0) 5 3 26 r3 (7) 27 25 5 r2 (0) 6 4 27 r2 (8) 28 26 -------- 6 r2 (l ) 7 5 28 r3 (8) 29 27 7 r2 (1) 8 6 29 r2 (9) 30 28 _8__r2 (1) 9 7 30 r3 (9) 31 29 15 9 r2 (1) 10 8 31 r2 (10) 32 30 10 r2 (l) 11 9 32 | r3 (10) 33 31 11 r2 (D 12 10 33 | r2 (ll) 34 32 12 __r3 (1) 13 11 34 r3 (ll) 34 33 13 r3 (l) 14 12 35 r2 (0) 36 1 * 20 14 r3 (l) 15 13 36 r2 (l) 37 2 15 r2 (2) 16 14 37 r 2 (2) 38 4 16 r3 (2) 17 15 38 r2 (3) 39 6 17 r2 (3) 18 16 39 r2 (4) 40 10 18 r3 (3) 19 17 40 r2 (5) 4l 16 25 19 r2 (4) 20 18 41 r2 (6) 42 19 20 r3 (4) 21 19 42 r2 (7) 43 22 21 r2 (5) 22 20 43 r2 (8) 28 25 11317

* switch to MPS

Table V

104

Hui- Code Op Neer Hui-Code Op Neerige full- full- full- next- next next- next 5 state state state state state state

mm / tmMMB

0 r2 (0) 35 35 * 22 r2 (5) 23 21 1 r2 (0) 2 1 * 23 r2 (6) 24 22 2 r2 (0) 3 1 24 r2 (6) 25 23 ------ - 3 r2 (0) 4 2 25 r2 (7) 26 24 10 4 r2 (0) 5 3 26 r2 (7) 27 25 5 r2 (0) 6 4 27 r2 (8) 28 26 6 r2 (1) 7 5 28 r2 (8) 29 27 7 r2 (1) 8 6 29 r2 (9) 30 28 8 r2 (l) 9 7 30 r2 (9) 31 29 15 9 r2 (l) 10 8 31 r2 (10) 32 30 10 r2 (1) 11 9 32 r2 (10) 33 31 11 r2 (l) 12 10, 33 g r2 (ll) 33 32 12 r2 (l) 13 11 13 r2 (2) 14 12 35 r2 (0 ) 36 1 # 20 14 r2 (2) 15 13 36 r2 (l) 37 2 15 r2 {2) 16 14 37 r 2 (2) 38 4 16 r2 (2) 17 15 3Ö r2 (3) 39 6 17 r2 (3) 18 16 39 r2 {4) 40 10 18 r2 (3) 19 17 40 r2 (5) 4l 16 25 19 r2 (4) 20 18 41 r2 (6) 42 19 20 r2 (4) 21 19 42 r2 {7) 43 22 21 r2 (5) 22 20 43 r2 (8) 28 25

1001317 A

* switch to MPS

105

Table W

House Code Op Neer House I Code Op Neerige full- full- full- next- next- next- next 5- state- state state- state stand 0 r2 (0) 35 35 * 22 r2 (5) 23 21 1 r2 (0) 2 1 * 23 r2 (6) 24 22 2 r2 (0) 3 1 24 r2 (6) 25 23 3 r2 (0) 4 2 25 r2 (7) 26 24 10 4 r2 (0) 5 3 26 r2 (7) 27 25 5 r2 (0) 6 4 27 r2 (8) 28 26 6 r2 (1) 7 5 28 r2 (8) 29 27 7 r2 (1) 8 6 29 r2 (9) 30 28 _8__r2 (1) 9 7 30 r2 (9) 31 29 15 9 r2 (1) 10 8 31 r2 (10) 32 30 10 r2 (1) 11 9 32 r2 (10) 33 31 11 __r2 (l) 12 10 33 | r2 (ll) 34 32 12 r3 (l) 13 U 34 r2 (11) 34 33 13 r3 (l) 14 12 35 r2 (0) 36 1 * 20 14 r3 (l) 15 13 36 r2 (l) 37 2 15 r2 (2) 16 14 37 r 2 (2) 38 4 16 r3 (2) 17 15 38 r2 (3) 39 6 -------- 17 r2 (3) 18 16 39 r2 (4) 40 10 18 r3 (3) 19 17 40 r2 (5) 4l 16 25 19 r2 (4) 20 18 41 r2 (6) 42 19 20 r3 (4) 21 19 42 r2 (7) 43 22 21 r2 (5) 22 20 43 | r2 (8) 28 25

* switch to MPS

1001317

Table X.

106 ---- ----

Hui- Code Op Neer Hui-Code Op Neerige full full full- full next- next next- 5th state- state state- state state stand 0 r2 (0) 35 35 * 22 r3 (5) 23 21 1 r2 (0) 2 1 * 23 r2 (6) 24 22 2 r2 (0) 3 1 24 r3 (6) 25 23 3 I r2 (0) 4 2 25 | r2 (7) 26 24 10 4 r2 (0) 5 3 26 I r2 (7) 27 25 5 r2 (0) 6 4 27 I r2 (7) 27 26 _6__r2 (l) 7 5 7 r2 (1) 8 6 _8__r2 (l) 9 7 15 9 r2 (l) 10 8 10 r2 (l) 11 9 11 r2 (l) 12 10 12 r3 (l) 13 11 13 r3 (l) 14 12 35 r2 (0) 36 1 * 20 14 r3 (l) 15 13 36 r2 (l) 37 2 15 r2 (2) 16 14 37 r 2 (2) 38 4 16 r3 (2) 17 15 36 r2 (3) 39 6 17 r2 (3) 18 16 39 r2 (4) 40 10 18 r3 (3) 19 17 40 r2 (5) 4l 16 25 19 r2 (4) 20 18 41 r2 (6) 42 19 20 r3 (4) 21 19 42 r2 (7) 25 22 21 r2 (5) 22 20 _j_

* switch to MPS

107

Table Y.

House Code Op Neer House I Code Op Neerige next full I next full next next I next state 5 state I state state I state state 0 r2 (0 ) 35 35 * 22 r2 (5) 23 21 1 r2 (0) 2 1 * 23 r2 {6) 24 22 2 r2 (0) 3 1 24 r2 (6) 25 23 3 r2 (0) 4 2 25 | r2 (7) 26 24 10 4 r2 (0) 5 3 26 r2 (7) 27 25 5 r2 (0) 6 4 27 r2 (7) 28 26 6 r2 (1) 7 5 28 r2 (7) 28 27 7 r2 (1) 8 6 _8__r2 (l) 9__7_ 15 9 r2 (l) 10 8 10 r2 (1) 11 9 11 r2 (l) 12 10 12 r2 (l) 13 11 13 r2 (2) 14 12 35 | r2 (0) 36 1 * 20 14 r2 (2) 15 13 36 I r2 {l) 37 2 15 r2 {2) 16 14 37 r 2 (2) 38 4 16 r2 (2) 17 15 38 r2 (3) 39 6 17 r2 (3) 18 16 39 r2 {4) 40 10 18 r2 (3) 19 17 40 r2 (5) 4l 16 25 19 r2 (4) 20 18 41 r2 (6) 42 19 20 r2 (4) 21 19 42 r2 (7) 25 22 21 r2 (5) 22 20 43 r2 (8) 28 25

* switch to MPS

1001317 108

Adding a quick adaptation to the probability estimate only helps at the beginning of the encoding process. Other methods can be used to improve adaptation during encoding if the context bin statistics change faster than what can be maintained by the previously described PEM state tables.

One method of maintaining rapid adaptation throughout the encoding is to add an acceleration term to the PEM state update. This acceleration can be incorporated into a PEM state table by repeating each code a constant number of times (e.g. 8). Then an acceleration term M (e.g., a positive integer) can be added or subtracted from the current state during the update. If M is equal to 1, the system works the same as without acceleration and the slowest adaptation 15 takes place. If M is greater than 1, a faster adaptation takes place. Initially, M can be set to a value greater than 1 to provide an initial fast adaptation.

A method according to the invention for updating the value of M is based on the number of consecutive code words. For example, if a predetermined number of code words occur sequentially, the value of M is increased. For example, if four consecutive code words are "0" "0" "0 '", 0 "or" 1N "" 1N "" 1N "" 1N "then the value of M is increased. On the other hand, an alternating code pattern can be between" 0 "and "IN" codewords are used to decrease the value of M. If, for example, four consecutive codewords are "0" "1N" "0" "1N" or "IN" "0" "IN" "0" then the value of M. decreased.

Another method of acceleration uses permission tables in which each code is repeated S times where S is a positive integer. S is an inverse acceleration parameter. If S 30 is equal to 1, the adaptation is faster and if S is greater than, the adaptation is slower. The value of S can initially be set to 1 to obtain a quick initial adaptation. Using a similar method as described above, the value of S can be "updated if four consecutive code words are 35" 0 "" 0 "" 0 "" 0 "or" IN "" IN "" IN "" IN ". In such a case, the value of S is reduced. In contrast, if the four consecutive code words are "0" "1N" "0" "1N" or "1N" "0" "1N" "0" then the value of S is increased.

10 o 131 7 Ί 109

The definition of consecutive code words can have various meanings. In a "per context" system, the consecutive code words can refer to consecutive code words in a context bin. In a "per probability" system, consecutive code words can refer to consecutive code words in a probability class. Alternatively, in both systems, consecutive code words can generally refer to consecutive code words (with no reference to context bin or probability class). For these three examples, the number of memory bits required to maintain a codewords history equal to 3 x number con text bins, 3 x number probability classes, respectively 3 · Maintaining an acceleration for each context bin core provides the best adaptation. Because a poor tracking process is often the result of a global change in the unencoded data, determining a global acceleration can also provide good adaptation.

Svsteem applications

An advantage of any compression system is to reduce the storage requirements for a set of data. The parallel system according to the invention can replace any application currently running with a lossless coding system and can be applied to systems operating on audio, text, databases, computer executable software or other digital data, signals or symbols. Examples of lossless encoding systems include facsimile compression, database compression, bitmap graphics compression, and transformation coefficient compression in image compression standards such as JPEG and MPEG. The present invention allows for a small efficient hardware implementation and relatively fast software implementations making it a good choice even for applications that do not require high speed.

The real advantage that the invention has over the prior art is the ability to operate at very high speeds especially in decoding. In this way, the invention can make full use of very high-speed channels, such as high-speed computer networks, satellites and terrestrial broadcasting channels. Fig. 28 illustrates such a system in which broadcast data or a high-speed computer network supplies data to the decoding system 2801 which decodes the data in parallel to produce 1001317 * 110 output data. Current hardware entropy (such as the Q encoder) would slow throughput through these systems. All these systems are designed at great cost to have a wide bandwidth. It is anti-productive to use a decoder with a low throughput speed. The parallel system of the invention not only suits these high bandwidths, but actually increases the effective bandwidth because the data can be transferred in compressed form.

The parallel system of the invention is also applicable to obtain a more effective bandwidth from medium speed channels such as ISDN, CD-ROM and SCSI. Such a bandwidth adjustment scheme is shown in Fig. 29, while data from sources such as CD-ROM, Ethernet, SCSI (Small Computer Standard Interface) or other similar sources is fed to the decoding system 2901, which receives and decodes the data to provide an output signal. These channels are still faster than some current encoders. Often these channels are used to operate a data source that requires more bandwidth than the channel has, such as real-time video or computer-based multimedia. The system of the present invention can fulfill the role of hand width adjuster.

The system of the invention is an excellent choice for an entropy encoder that is part of a real-time video system such as the HDTV (High Definition Tele-25 vision) standard and the MPEG video standard. Such a system is shown in Fig. 30. In Fig. 30, the real-time video system includes a decoding system 3001 that receives the compressed image data. The system 3001 decodes the data and outputs its output to a lossy decoder 3002. The lossy decoder 3002 may be the transformed color conversion and sub-sampling portion of HDTV or MPEG decoder. The monitor 3003 can be a television receiver or a video monitor.

Although various changes and modifications are possible in the invention, it will be apparent to those skilled in the art after reading the above description that the embodiments shown by way of example are merely illustrative of the invention in no way limiting the invention. . Therefore, the references to details of the invention do not limit the scope 10013) 7

Ill of claims claiming only those features which are considered essential to the invention.

% 1001317

Claims (101)

A method for encoding a data stream comprising the following steps: generating codeword information as a representation of the data stream in response to the data stream, wherein the codeword information comprises a number of codewords and in which further several codewords are generated from the data of the data stream that is processed in parallel; generating coded data in response to the codeword information, characterized in that the coded data generating step means that each of the plurality of codewords in the codeword information is output such that the sequence of codewords is based on the output at the beginning of the portion of the data stream represented by each code-15 word. The method of claim 1, wherein each of the plurality of codewords is outputted at the beginning of each run. The method of claim 1, wherein the step of generating coded data further comprises combining codewords 20 of variable length in fixed length data structures. The method of claim 3t wherein each of the fixed length data structures comprises a collapsed word. The method of claim 1, further comprising outputting coded data such that the codewords are ordered in the decoding order. The method of claim 1, further comprising the step of ordering the code words. The method of claim 1, wherein the step of generating codeword information comprises the following steps: generating the probability state of a codeword; selecting a bit generation code based on the probability state; accessing a memory to obtain a run count belonging to the probability class. Encoding system for encoding a data stream, the encoding system comprising: 10013Π an encoder (602) connected to receive the data stream to generate codeword information (604) including codewords and further comprising multiple codewords through the encoder (602) is generated from data that is processed in parallel; 5 and a rearrangement unit (606) coupled to the encoder (602) for generating encoded data (608) in response to the codeword information (6θ4), characterized in that the rearrangement unit (606) is the one provided by the encoder (602) generated code words rearranged in a decoding order such that the order of the code words at the output is based on the beginning of the portion of the data stream represented by each code word. Encoding system according to claim 8, wherein the rearrangement unit (6-6) stores the codewords such that the codeword size V is indicated. The coding system of claim 9. wherein IN codewords are rearranged such that the most significant "1" bit indicates the length of each codeword. The coding system of claim 8, 9 or 10, wherein the recast unit (606) comprises: at least one run count rearrangement unit (801) for generating each of said number of codewords (803) in the codeword information at the beginning. of each run; and at least one bit pack unit (802) for combining variable length code words (803) into fixed length data structures. The coding system of claim 11, wherein each of the fixed length data structures comprises a collapsed word (805). Encoding system according to claim 8, wherein the rearrangement unit (606) orders the code words (803). Encoding system according to claim 13, further provided with a memory (607) connected to the rearrangement unit (606) to store code words (803) in an order. Encoding system according to claims 8 to 14, wherein the encoding unit (602) comprises: a context model (2l4); a probability estimator (215-217) coupled to the context model (214); and, 1001317 a bit generator structure (218-220) coupled to the probability estimator (215-217) to generate a codeword 1 response to the data stream. The coding system of claim 15, wherein the coding unit (602) further comprises a memory (603) for storing a plurality of counts, and wherein the memory (603) is accessed using probability classes from the probability estimator ( 215-217), in order to provide one of a number of run lengths to the bit generator (218-220) to be output as part of the codeword information (6θ4). The coding system of claim 15, wherein the bit generator structure comprises: a bit generator (701) for supplying codeword information (714) in response to an index and an MPS / LPS indication; and 15 a memory (702) coupled to the bit generator (701) for providing a run count to the bit generator, the bit generator (701) reading the memory (702) based on the index and outputting a bit generation based on the data is obtained by reading from memory (702). The coding system of claim 17, wherein the codeword information comprises a first signal (711) indicating whether the MPS / LPS indication includes the start of a run, a second signal (712) indicating whether the MPS / LPS indication includes the end of a run, and an output codeword (714). Encoding system according to claim 11, wherein the at least one bit pack unit (802) comprises bit pack logic (1101), which arranges the interleaved words to generate the encoded data stream as interleaved words ordered according to the Nth preceding code word in each interleaved word of each flow. The coding system of claim 11, wherein the rearrangement unit (606) includes a tracking decoder (2504) for selecting interleaved words to be output in the encoded stream. » An encoding system according to claim 20, wherein the rearrangement unit (606) comprises a plurality of run count rearrangement units (2501a..N) coupled to a plurality of bitpack units (2502a..N), each of the plurality of bitpack units (2502a..N) interleaved words generates and the tracking decoder (2504) selects an interleaved word from the number of interleaved words as an output in the code stream. The coding system of claim 11, wherein the codeword information comprises a time marker and the rearrangement unit (606) further comprises logic (2601) for interleaving words based on the associated time markers. Encoding system according to claim 22, wherein the rearrangement unit (606) comprises a number of run count rearrangement units (2501a..N) coupled to a number of bit pack units (2502a..N) and wherein further the logic (2601) ensures that the interleaved words are output based on an associated time marker. Encoding system according to claim 23, wherein the interleaved words are output based on the oldest time marker. The coding system of claim 11, wherein a single queue supplies code words to a plurality of bitpack units (2502a..N) and wherein the plurality of bitpack units (2502a..N) generates interleaved words to be output as part of the code stream . The coding system of claim 25, wherein the single queue comprises a single run-length rearrangement unit (2701) and wherein the logic (2702) determines the next interleaved word to be output as a code stream. Encoding system according to claim 11, wherein a single queue 25 supplies codewords to a single bit pack unit. An encoding system according to any one of claims 11 to 27 for use in a compression system having a decoder for decoding information generated by the encoder (602), the plurality of fixed length data structures outputted in an order specified by the decoder is requested. The coding system of claim 28, wherein the run-length rearrangement unit (801) further comprises: a first memory (908) for storing code words; a first indicator (903) and a second indicator (904) for addressing the first memory (908) as a queue, the first indicator (903) pointing to a first input indicated as output of the first memory (908) and the second indicator (904) points to a second input data designated as a next available and unallocated memory location in the first memory (908). The coding system of claim 29, further comprising a pointer memory (901) for storing address information corresponding to lokatles in the first memory (908) currently destined for storing code words for each index. The coding system of claim 30, wherein each index indicates a probability class. Encoding system according to claim 30, wherein each index indicates at least one context. The coding system of claim 28, wherein each codeword entry in the first memory (908) includes a validity indication and further wherein a codeword is output from the first memory (908) when the first indicator (903) is the address of it specifies codeword and the validity indication for the codeword 1 indicates its validity. 3 ^. Encoder according to claim 28, wherein the bit pack unit (2302a..N) comprises bit pack logic, further comprising a number of accumulators (1202) and a number of registers (1205), each of the plurality of registers (1205) being associated with one of the number of accumulators (1202) and one of the number of currents, each register (1205) is for storing a collapsed word for its associated current and each accumulator (1202) indicates the next location in the associated register for storage of the current code word for the stream such that each code word for one out of the number of streams is appended to the contents of the register (1205) associated with said one of the number of streams based on the value in the associated accumulator (1202). Encoding system according to claim 3 * 0 further comprising a shifter (1203) coupled to the number of accumulators (1202) for shifting code words in response to the at least one signal from the number of accumulators (1202), wherein code words are shifted to append to the contents of one of the plurality of registers (1205) based on an accumulator value in order to pack the portions of at least two code words in each interleaved word. The coding system of claim 28, further comprising a plurality of pointers (110 * 0 corresponding to a plurality of interleaved data streams, each of the plurality of pointers (1104) indicating a location in the rearrange memory (1103) for the next interleaved one word for each of the number of flows. The coding system of claim 28, wherein the rearrangement unit (606) further comprises a finite memory. 38. The coding system of claim 9. wherein the system further comprises a state table connected to provide a probability estimate based on the indices, the state table comprising a first number of states and a second number of states, each of the states corresponds to a code, and in which further transitions between different codes corresponding to the first number of states occur faster at transitions between states in the first number of states than transitions between different codes corresponding to the second number of states V if transitions occur in the second number of states. Encoding system according to claim 38, wherein the first number of states is used only for a predetermined number of indices. The coding system of claim 38 wherein the first number of states is used only for a predetermined number of indices initially indicating the state table. The coding system of claim 38, wherein each vein the first number of states is associated with an R2 code. The coding system of claim 39 wherein the first number of states includes at least one transition to the second number of states such that the state table transitions to the second number of states from the first number of states after a predetermined number of indices. The coding system of claim 38, wherein each of the first number of states is associated with a different code. 44. The coding system of claim 38, wherein the state table transitions from one of the first number of states to one of the second number of states occur in response to a least likely symbol. The coding system of claim 38, wherein the state machine increases in state in response to a most likely symbol. 46. The coding system of claim 38 wherein each code in the 1001317 state table is repeated a predetermined number of times and the transition between permissions of the consent table occurs is based on an acceleration term that is modifiable such that a first transition rate between state during a first time period is different. is of a second transfer rate during a second time period. The coding system of claim 46, wherein state table updates include modifying the PEM state by incrementing or decrementing the acceleration term. The coding system of claim 47, wherein no adaptive acceleration occurs if the acceleration term comprises a predetermined number. Encoding system according to claim 47, wherein the acceleration term is updated based on the number of consecutive code words. The coding system of claim 49, wherein consecutive code V words comprise consecutive code words in a context. The coding system of claim 49, wherein consecutive code words comprise consecutive code words in a probability class. The coding system of claim 47, wherein the acceleration term is updated based on the number of alternating code words. A decoding system for decoding a data stream having a plurality of codewords generated by an encoding system according to any one of claims 38 to 52, wherein the decoding system 25 is an entropy decoder, comprising: a number of bitstream generators for receiving the Datastream; and a state table coupled to the number of bitstream generators to provide a probability estimate to the number of bitstream generators, the number of bitstream generators generating a decoded result for each codeword in the data stream in response to the probability estimate using an Rn (k ) code for multiple values of n, and in which the state table further comprises a first number of states and a second number of states, with transitions between different codes in the first number of states being faster at transitions in the first number of states than transitions between codes at transition in the second number of states. 1Ω01317 The decoding system of claim 53, wherein the first number of states each includes an R2 (k) code. Decoding system according to claim 53 ». where the first number of states is used only during initialization. The decoding scheme of claim 53 wherein each code in the state table is repeated a predetermined number of times and wherein transitions between states of the table occur based on an acceleration stera that is modifiable such that a first transition rate between states differs during a first 10 period of time is of a second transition speed during a second time period. The decoding system of claim 56, wherein state table updates include modifying the PEM state by an acceleration term. Decoding system according to claim 57, wherein no adaptive acceleration takes place if the acceleration term contains a predetermined number. The decoding system of claim 57, wherein the acceleration term is updated based on the number of consecutive code words. The decoding system of claim 57, wherein the acceleration term is updated based on the number of alternating code words. 61. A decoding system for decoding a data stream having a number of codewords generated by an encoding system according to any one of claims 28 to 52, wherein the decoding system comprises: a shifter (1600) for receiving the data stream and for outputting of correctly aligned coded data; 30, a run-length decoder coupled to the shifter for receiving the properly aligned coded data as codewords for determining the codeword type; a probability estimator coupled to the run length decoder 'to determine the run length decoder code such that the run length decoder generates a run length as well as an indication as to whether the LPS has occurred in response to each code word; wherein the shifter (1600) includes a variable length shift mechanism for shifting codewords from the 1001317 data stream; and a plurality of registers (I601-1604) connected for receiving codewords from the data stream in response to the shifting mechanism such that the aligned coded data is output as a series of codewords. The decoding system of claim 61, wherein a portion of the registers (1601-1604) is connected to receive data from another portion of the registers (1601-1604) or the data stream. The decoding system of claim 61, wherein the variable shift mechanism comprises a drum shifter (1606) for shifting data from the stream in a plurality of registers. 64. The decoding system of claim 61, wherein the shifter (1600) includes a FIFO having a plurality of registers (I6O7-I6IO), each of the registers {1607-1610) receiving data from the interleaved encoded data and at least one of the plurality of registers is for receiving codewords from another of said plurality of registers. The decoding system of claim 6l, wherein the shifter comprises: a first plurality of registers (1601-1604) connected to receive the codeword data, each of the first plurality of registers being connected to one distinct stream from the plurality of streams; a multiplexer (1605) which receives at its input codeword data from each of the first number of registers (1601-1604) and outputs codewords from one of the plurality of streams at the output; a drum shifter (1606) coupled to the output of the multiplexer (1605) to shift codeword data from the multiplexer so that it is output as aligned coded data; logic (1611, 1612) coupled to the drum shifter (I6O6) to indicate the number of bits by which the code word is to be shifted; and a FIFO having a plurality of registers (I607 ~ 16100) connected to receive codewords from said multiplexer (1605), the FIFO having a plurality of registers (I607 ~ 16100) and each of the plurality of registers (1607- 1610) at its input receives data from the Interleaved encoded data and at least one of the plurality of registers is intended to receive codewords from another of the plurality of said registers. 10013) 7 66. Decoding system for decoding a data stream having a plurality of codewords generated by an encoding system according to any one of claims 28 to 52, wherein the decoding system comprises: a FIFO structure (1401) intended for receiving the data ; a context model (1404) for providing contexts; a memory (1403) coupled to the context model (1404) for storing status information, the memory (1403) providing status information in response to each context provided by the context model (1404); a plurality of decoders (1402) for receiving encoded data from the FIFO structure (1401) and the memory (1402) for decoding codewords supplied by the FIFO structure using status information from the memory (1402), the number of 15 decoders (1402) provides run counts that can be generated for a number of codes. The decoding system of claim 66, wherein the encoded data supplied to the plurality of decoders (1402) by the FIFO structure (1401) is independent of the context and of the probability class. The decoding system of claim 66, wherein the decoder (1402) comprises a run counter memory for. storing run counts and further providing access to run count memory based on the probability class. The decoding system of claim 66, wherein the FIFO structure (1401) includes a plurality of outputs, one for each decoder (1402). 70. The decoding system of claim 69. wherein the FIFO structure (1401) comprises a pair of multiplexers (1463, 1464) and control logic (1465) for selecting from the pair of multiplexers (1463, 1464) to ensure that a code word is provided to each decoder (1402). The decoding system of claim 70, wherein the pair of multiplexers (1463, 1464) is selected by the control logic (1465) based on requests received from one of the plurality of decoders (1402). The coding system of claim 16, wherein the memory (603) has fixed dimensions disregarding coded data of less importance if the memory (603) has just fixed dimensions overflowing. 1001317 Encoding system according to claim 72, wherein the memory (603) has a number of storage areas and encoded data stored in each of the plurality of areas comprises encoded data having a different level of import. 5 7 * 1. Encoding system according to claim 73, wherein encoded data of one importance level is stored in at least one memory area of the memory (603) containing data of another importance level. Encoding system according to claim 7 **, wherein the coded data 10 of said one importance level overwrites the coded data of the other importance level in the at least one memory area of the memory (603). 76. A method according to any one of claims 1 to 7, wherein during the encoding of data a number of contexts are initialized with the following steps: initialize ve the number of contexts whereby each of the contexts is addressed based on a counter value; obtaining a PEM state in the current context, this obtaining step comprising the following steps: obtaining a memory indication for each context indicating the PEM state; determining whether the obtained memory location is valid for the current operation by comparing the current context number with the counter value, the data being determined valid if the counter value indicates that the location has already been initialized; using an initial PEM state for the context and ignoring the current PEM state for a context if the data of the addressed memory location is not valid; and using the currently assigned PEM status for context 30 if the data is valid. The method of claim 76, further comprising the step of enrolling a new PEM status if the PEM status is changed. % The coding system of claim 8, comprising: a context model for providing a context bin; a memory coupled to the context model to provide a probability state based on the context bin; a logic coupled to the memory to generate a probability class 1001317 based on the probability state; an encoder coupled to the logic for generating a release signal based on the probability class; 5 a plurality of blt generators coupled to the decoder and connected to receive the input data wherein each of the plurality of bitgenerators is assigned to at least one distinct code with the encoder releasing one of the plurality of bit generators based on the probability class such that the at least one encodes the input data from the number of bitstream generators. An encoder according to claim 78, wherein at least one of the plurality of bit generators encodes data using an R code and at least one of the plurality of bit generators encodes data using a non-R code. The encoder of claim 78, wherein short run-length bit generators function as R-code encoders. The encoder of claim 78, wherein long run length bit generators comprise a short run unit and a long run unit, the short run unit treating codes of a first predetermined length and the long run unit any remaining bits and determines which, if any, of the remaining bits are output at the output. The method of claim 1, comprising the steps of: providing a context bin; Accessing a memory using the context bin to obtain a probability status; generating a probability class based on the probability status; releasing one of a number of bit generators, each of the bit generators being assigned to at least one distinct code such that only this one distinct code is used for encoding such that said one of the number of bit stream generators encodes the input data. 83. A decoding system for decoding a data stream having a number of codewords generated by an encoding system according to any one of claims 78 to 81, wherein the decoding system comprises: a context model (2001) for providing a context bin; 1001317 12 * »a memory (2002) coupled to the context model (2001) to provide a probability status based on the context bin; logic (2003) coupled to memory (2002) for generating a probability class based on the probability state; a decoder (200 * ») coupled to the logic (2003) for generating a release signal based on the probability class; a plurality of bit generators (2005a..N) coupled to the decoder 10 (200 * ») and connected for receiving the encoded data, each of the plurality of bit generators (2005a..N) being for at least one distinct code, wherein the decoder (200 * ») releases one of the number of bit generators (2005a..N) based on the probability class such that said one of the number of bitstream generators (2005a..N) decodes the encoded data. 8 * ». The decoding system of claim 83, wherein at least one of the plurality of bit generators (2005a..N) decodes data using an R code and at least one of the plurality of bit generators (2005a..N) decodes data using a non-R -code. The decoding system of claim 83, wherein short run length bit generators (2005a..N) function as R code decoders. The decoding system of claim 83, wherein long run length bit generators (2005a..N) comprise a short run unit (2101) and a long run unit (2102), the short run unit (2101) having 25 codes with a the first predetermined length and the long run length unit (2102) handles all remaining bits and determines which, if any, of the remaining bits to be output at the output. 87. A method of decoding input data encoded with the method of claim 82, comprising the steps of: providing a context bin; accessing a memory using the context bin to obtain a probability state; Generating a probability class based on the probability state; releasing one of a number of bit generators, each of the number of bit generators being assigned to at least one undercurrent code such that only this one distinct code is used for decoding and such that said one from the number of bit stream generators is the encoded data decodes. 88. A method of decoding data encoded in the method of any one of claims 1 to 7, the method comprising the steps of: loading a counter value into a counter associated with each runner, wherein the counter value corresponds to the dimensions of a codeword memory used during encoding when a new run is started, which counter value is loaded when a new codeword is retrieved for each run counter; decrementing the counter value each time a codeword is retrieved; and resetting the bit generator state associated with each new code word if the counter is decremented to zero. The method of claim 88, wherein each run counter corresponds to a PEM status. The method of claim 88, wherein each run counter corresponds to a context bin. 91 · Method for decoding vein data encoded with the method according to any one of claims 1 to 7. The method comprises the following steps: incrementing a counter value each time a code word is requested, the counter value having a current time indication. contains; storing the counter value as a stored time indication if a first code word is started; comparing the stored time indication plus the size of an encoding memory with the current time indication; 30 wherein the bit generator state for the first codeword is reset and a second codeword is requested if the current time indication is larger than the stored time indication plus the size of the coding memory. 92. The method of claim 91. wherein the stored time indication comprises a time marker. The method of claim 91, further comprising the step of reusing the stored time indication for the next codeword. 1001317 91 * A method for decoding data encoded by the method according to any one of claims 1 to 7. which method comprises the following steps: storing an index corresponding to a codeword, wherein the index is stored in a queue and the index is stored if the codeword is requested; mark the entry of the queued index as invalid; storing the codeword in the entry and marking the entry as valid when the codeword is completed; Outputting data from the queue to be decoded, the code word being issued for decoding if the queue entry is valid; and outputting data from the queue input and indicating to the decoder that the data is valid if the queue input is marked invalid when outputting data from the queue, wherein the bit generator status information is reset by the decoder in response to receipt of data if the queue is marked as invalid. A decoder for decoding a data stream having a number of 20 codewords generated by an encoding system according to any one of claims 28 to 52 comprising decoder: a context modeling mechanism for providing contexts; a memory (1708) coupled to the context model (1703, 1704, 1705) for storing status information, the memory (1708) providing status information in response to each context provided by the context model (1703, 1704, 1705); and a plurality of decoders coupled to the memory (1708) for decoding codewords using status information from the memory (1708). The decoder of claim 95, wherein the context modeling mechanism includes a plurality of integrated circuits (1701, 1702). The decoder of claim 96, wherein the number of decoders decodes the codewords using a number of R codes and wherein the number of 'R codes includes at least one non-maximum length run of most likely symbols that are not are followed by a least likely symbol. The decoder of claim 97 wherein non-maximum length run counts have a unique decodable preposition. 1001317 The decoder of claim 96, wherein the context modeling mechanism includes at least one context model that provides contexts from one of the plurality of integrated circuits (1701) and at least one context model that provides contexts from a second of the plurality of integrated circuits (1702) . The decoder of claim 99, wherein the at least one context model on the at least one of the plurality of integrated circuits comprises a zero order context model (1703). The decoder of claim 96, wherein contexts of the plurality of integrated circuits (1801, 1802) are directly applied to the memory (1803) - 102. The decoder of claim 96, wherein a first part of a first context is provided by one integrated circuit (1801) and a second part of the second context is provided by a second integrated circuit (1802). The coding system of claim 17. wherein the bit generator status of the bit generator (701) is updated and further wherein the bit generator (701) is reused prior to writing the updated state into memory (702). An encoding system according to claim 103, wherein the bit generator (701) is reused during the modifying phase of a read modifying write cycle. Encoding system according to claim 17, wherein the bit generator (701) generates a non-minimal length run count with reuse prior to writing an updated state into memory (702). 106. The coding system of claim 17, wherein the bit generator (701) encodes data using R codes defined such that each run length is followed by at least one uncoded bit such that two code words of the same run length are never in a row. decoded. The decoder of claim 95, wherein at least one of the plurality of decoders comprises a delay-tolerant decoder. 108. The decoder of claim 107, wherein at least one of the plurality of decoders performs a variable length shift based on the decoded data available after a delay. The decoder of claim 107, wherein each of the plurality of decoders receives variable length data at the input. 1001317 110. The decoder follows claim 109 * wherein the plurality of decoders decode the variable length input data in parallel. The decoder of claim 107, wherein the decoder number output is divided into interleaved, fixed length words. 1001317