JPH08116266A - Coding method, coder, coding device, decoding method, decoder, entropy decoder and initializing method - Google Patents

Abstract

PURPOSE: To attain high speed processing of a coder/decoder and especially the decoder as a system in parallel decoding of non-loss coding data. CONSTITUTION: A coder 600 includes a coder 602 generating code word information 604 in response to data and a rearrangement unit 606 generating a coded data stream in response to the code word information 604. The rearrangement unit 606 includes a run count rearrangement unit in which code words are arranged in the decoding order and a bit pack unit combining variable length code words to obtain a fixed length interleaved code word and outputting it in the order requested by the decoder.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates to the field of data compression and decompression systems, and more particularly to a method and apparatus for parallel encoding and decoding of data in a data compression / decompression system.

[0002] This application is based on US patent application Ser. No. 08/0.
No. 16,035 (Received February 10, 1993, "Method
And Apparatus For Parallel Decoding and Encoding
No. 08 / 172,646 (December 23, 1993, “Method and Apparatus For Parallel Encoding an”
d Decoding of Data ”).

[0003]

BACKGROUND OF THE INVENTION Data compression is widely used today, especially for the storage and transmission of large amounts of data. Conventionally, there are many various data compression methods. Compression techniques can be divided into two broad categories: lossy coding and lossless coding. Lossive coding is coding that results in loss of information and thus does not guarantee a complete reproduction of the original data. Lossless compression preserves all information and compresses the data in a completely reproducible manner.

In lossless compression, input symbols are converted into output codewords. If the compression is successful, the codeword will be represented with fewer bits than the input symbols. The lossless coding method includes a dictionary coding method (for example, Lempel-Ziv method), a run-length coding method, a count coding method, and an entropy coding method.

Entropy coding consists of some lossless coding that attempts to compress the data using known or predicted symbol probabilities to approach the entropy limit.
Entropy codes include Huffman codes, arithmetic codes, and binary entropy codes. The binary entropy coder is a lossless coder that is valid only for binary (yes / no) decisions, which may be represented as highest probability (maximum likelihood) symbols (MPS) and lowest probability symbols (LPS). An example of a binary entropy coder is
There is an IBM Q-coder and a coder called a B-coder. For further information regarding B-coders, see US Pat.
See No. 478 (JD Allen). Also, MJGor
mish and JDAllen, ”Finite State MachineBinary E
ntropy Coding, ”abstract in Porc. Data Compression
See also Conference, 30 March 1993, Snowbird, UT, pg.449. This B-coder is a binary entropy coder that utilizes a finite state machine for compression.

FIG. 1 shows a block diagram of a conventional compression / decompression system using a binary entropy coder. In the case of encoding, the data is context model (CM; cont
ext model) 101. The CM 101 converts input data into a set or series of binary decisions and prepares a context bin for each decision. Both the sequence of binary decisions and the context bins associated with them are more
2 is output. The PEM 102 receives each context bin and produces a probability estimate for each binary decision. Actual probability estimate is usually P class (PC
It is represented by a class called lass). Each P class is used as one probability range. The PEM 102 also determines whether the binary decision (result) is in its predominant state (ie, the decision corresponds to MPS). Bitstream generator (BG) module 1
03 receives as input the probability prediction value (that is, P class) and the determination result as to whether or not the binary decision is dominant. In response, the BG module 103 generates a compressed data stream for representing the original input data and outputs 0 or more bits.

In the case of decoding, the CM 104 gives the context bin to the PEM 105, and the PEM 105 gives the probability class (P class) to the BG module 106 based on the context bin. The BG module 106 is connected to receive the probability class. The BG module 106 returns a bit that indicates whether a binary decision (ie, event) is in its predominant state, depending on its probability class and compressed data. PEM105
Receives the returned bit, updates the probability prediction value based on the bit, and returns the result to the CM 104. The CM 104 receives the returned bits and uses the received bits to generate the original data and update the context bin for the next binary decision.

IBM using binary entropy code
One problem with decoders such as Q-coders and B-coders from the company is that they are slow, especially when implemented in hardware. The operation of these decoders requires a single large slow feedback loop. To restate the decryption process, the context model uses past decrypted data to create a context. The probability prediction module uses that context to create one probability class. The bitstream generator uses the probability class and the compressed data to determine whether the next bit is a likely or a unlikely result. The probability predictor module uses the dominant / inferior result to generate a result bit (and updates the probability predictor for the context). This result bit is used by the context model to update the history of past data.
All these steps are needed for the decoding of only one bit. Since the context model can prepare the next context only after waiting for the result to update its history, the decoding of the next bit must be delayed. It is desirable not to have 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 in order to increase the decoding speed of compressed data.

Another problem with decoders using entropy codes is that variable length data must be processed. Most systems have variable length codewords to be decoded. Alternatively, other systems encode variable length symbols (uncoded data). When processing variable length data, it is necessary to shift the data at the bit level in order to prepare the correct next data for decoding or encoding operations. Bit-level operations on this data stream may require expensive and / or slow hardware and / or software. In addition, the conventional system
It must be done in a time critical feedback loop that limits the decoder performance. It would also be advantageous to eliminate bit-level manipulation of the data stream from the time sensitive feedback loop so that parallelization can be used to increase speed.

The present invention has been made in view of the above-mentioned problems, and an object of the present invention is to provide an improved lossless compression and decompression method and apparatus, and data. It is an object of the present invention to provide a real-time encoding device and a real-time decoding device that perform parallel encoding and decoding. The encoding device and the decoding device of the present invention can provide a balanced parallel entropy system that executes real-time encoding and real-time decoding with high-speed / inexpensive hardware, and this is also included in the object of the present invention. Other objects of the present invention will be clarified by the following description.

[0011]

According to the present invention, there is provided a coding device for use in a compression system having a decoding device for decoding information generated by the coding device. An encoding apparatus of the present invention includes an encoder that generates codeword information according to data. The encoding device also includes a rearrangement unit that produces an encoded data stream in response to the codeword information output from the encoder. This rearrangement unit combines a run-count rearrangement unit for arranging codewords in decoding order with a variable-length codeword into a fixed-length interleaved word, and the fixed-length interleaved word is requested by a decoding device. Includes bit pack units that output in the order specified. The contents described here are only a part of means for solving the problems included in the present invention, and the whole thereof will be described in detail in the following description.

[0012]

DETAILED DESCRIPTION OF THE INVENTION A method and apparatus for parallel encoding and decoding of data is described. In the following description, various specific examples such as the number of bits, the number of encoders, specific probability values, data types, etc. are shown in order to fully understand the preferred embodiments of the present invention. However, one of ordinary skill in the art will appreciate that the invention may be practiced without such embodiments. Also, well-known circuits are not shown in detail but are shown in block diagram form in order not to obscure the present invention.

Much of the following detailed description is provided by algorithms and symbolic representations of operations on data bits in computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. Suppose there is an algorithm, which is generally thought of as a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, but not necessarily, these physical quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise processed. Bit these signals,
Representation of values, elements, symbols, letters, terms, numbers, etc., has proven convenient at times, primarily for conventional reasons.

However, it should be borne in mind that all of these terms and similar terms should be associated with the appropriate physical quantities and are merely convenient labels attached to these physical quantities. As will be apparent from the following description, discussions using terms such as "processing", "operations", "calculations", "judgments", "displays", and the like, unless otherwise specified, refer to physical ( Processes data expressed as electronic quantities and converts them into other data, also expressed as physical quantities, inside a memory or register of a computer system, a similar information storage device, an information transmission device or a display device. , Computer systems or similar electronic computing devices.

The present invention also relates to apparatus for performing the operations herein. This device may be specially constructed for the required purposes, or it may be a general purpose computer selectively driven or reconfigured by a built-in program. The algorithms and displays presented herein are essentially unrelated to any particular computer or other apparatus. Various general purpose machines may be used with programs according to the teachings herein, or it may be convenient to create more specialized equipment for performing the steps of the required method. . The required structure for a variety of these machines will appear from the description below. Moreover, the present invention is not described in the context of a particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described 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 the encoding of data in real time. Similarly, in one embodiment, the decoding device of the present invention performs the decoding of data in real time. The real-time encoder and the real-time decoder together form a balanced coding system.

The present invention provides a system for decoding lossless encoded data in parallel. The data is decoded in parallel using multiple decoding resources. Data (for example, codeword) to be decoded from the data stream is assigned to each of the plurality of decoding resources. This data stream allocation is done quickly while the decoding resources are decoding data in parallel, and the data streams are decoded in parallel.
The data streams are ordered to allow allocation of data so that decoding resources can be efficiently utilized. This is called parallelizing the data. This data ordering allows each decoding resource to decode any or all of the encoded data without waiting for feedback from the context model.

FIG. 2 shows the decoding system of the present invention without the prior art slow feedback loop. The input buffer 204 receives the encoded data (that is, the codeword) and the feedback signal from the decoder 205, and supplies the encoded data to the decoder 205 of the present invention in a predetermined order (for example, in the context bin order), The decoder 205 decodes the encoded data. The decoder 205 includes a plurality of decoders (205A, 205B, 205C, ...).

In one embodiment, the decoders 205A, 205
B, 205C ,. ． ． Are each given data for a group of contexts. Each decoder in the decoder 205 is provided by the input buffer 204 with encoded data for all context bins in the context of the group. Using this data, each of the decoders 205A, 205B, 205C ,. ． ． Produces decoded data for the context bins of the group.
The context model need not associate encoded data with a particular group of context bins.

The decrypted data is stored in the decrypted data storage device 205 (207A, 207B, 207) by the decoder 205.
C ,. ． ． ) Is sent to. The decrypted data storage device 2
07 may store intermediate data, such as run count, which is neither coded nor uncoded data. In this case, the decoded data storage device 207
Stores data in a compact but non-entropy coded form.

Independently operating context model 206
Sends a feedback signal to the decoded data storage device 207, and in response to this feedback signal, the decoded data storage device 207 (207A, 207B, 207)
C ,. ． ． ) Is connected to receive the previously decoded data. Therefore, there are two feedback loops. One is between the decoder 205 and the input buffer 204, and the other is between the context model 206 and the decoded data storage 207. Since the large feedback loop is removed, the decoders (205A, 205A) in the decoder 205 are removed.
B, 205C ,. ． ． ) Can be decoded as soon as the relevant codeword is received from the input buffer 204.

The context model provides the storage portion of the decoding system and divides a data set (eg, image) into various categories (eg, context bins) based on its storage. In the present invention, these context bins are independent segregated ordered datasets.
ts of data). In one embodiment, each group of context bins has its own probability prediction model, and each context bin has its own state (probability prediction model is shared). Therefore, different probability prediction models and / or bitstream generators may be used for each context bin.

In this way, the data is ordered, ie, parallelized, and the data from the data stream is assigned to each decoder for decoding.

<Addition of parallelism to the old entropy coding model> In order to parallelize the data stream, the data is context, probability, tiling, codeword sequence (codeword sequence). Based on any of the above). The rearrangement of the encoded data stream is independent of the parallelization technique, ie the method used elsewhere to parallelize data or probabilities. Given the data segmented by the context model (CM),
The parallel encoder portion of the encoding system of the present invention is shown in FIG.

In FIG. 3, context-dependent (contex
t dependent) The parallel encoding device part includes a context model (CM) 214 and a probability prediction module (PEM) 21.
5 to 217, bit stream generator (BG) 2
It consists of 18 to 220. CM 214 is connected to receive input data. CM214 is PEM215
~ 217 are also connected. The PEMs 215 to 217 are also connected to BGs 218 to 220, which output the code streams 1, 2, and 3, respectively. PEM and B
Each pair of G constitutes one encoder. Therefore,
The parallel encoder shown here has three encoders. Although only three encoders in parallel are shown, any number of encoders may be used.

The CM 214 splits the data stream into various contexts in the same manner as a conventional CM and sends multiple streams to parallel hardware coding resources. Individual contexts or groups of contexts are assigned to separate Probability Prediction Modules (PEMs) 215-217 and Bit Generators (BGs) 218-220.

FIG. 4 is a block diagram of one embodiment of the decoder portion of the decoding system of the present invention. In FIG. 4, BG
221-223, PEM224-226 and CM227.
A context-dependent parallel decoding device with is shown. The code streams 1 to 3 are connected to the BGs 221 to 223, respectively. BG221-223 are PEMs, respectively
It is also connected to 223-226. PEM224-2
26 is a CM2 that outputs the restored input data
It is connected to 27. Inputs are code streams 1-3
Comes from several codestreams shown as One code stream is assigned to each PEM and BG pair. Each of the BGs 221 to 223 returns one bit indicating whether or not the binary decision is dominant, and the PEMs 224 to 226 use the bit to return a decoded bit (for example, binary decision). PEM224 to 226 are BG221, respectively.
~ 223 to indicate which code should be used to generate a data stream from its input code data. The CM 227 generates a decoded data stream by selecting the decoded bits output from the bitstream generator in an appropriate order and reproducing the original data. Thus, CM 227 obtains the decompressed data bits from the appropriate PEM and BG, but actually rearranges the data in the original order. Note that the control for this design flows in the opposite direction to the data stream. BG and PEM CM227 data
Will decode it before it needs it and will continue to lead CM227 by one bit or more. Alternatively, CM 227 requests (but does not receive) one bit from one BG and PEM, and then requests one or more bits from another BG and PEM before utilizing its originally requested bit.

The configuration shown in FIG. 4 is designed to tightly couple the PEM and BG. The IBM Q-coder is a good example of a coder in which PEM and BG are tightly coupled. P
The local feedback loop between EM and BG is
It does not fundamentally limit system performance.

In another design, the PEM may partition the data and send it to multiple BG units in parallel. Then there would be only one CM and PEM, and B
G is connected in parallel. Adaptive Huffman coding and finite state machine coding may be utilized in this way.

PEM for partitioning data and sending to parallel BGs
A similar decoding system using is shown in FIG. In this case, the probability classes are processed in parallel and each bitstream generator is assigned one specific probability class and receives the resulting information. In FIG. 5, encoded data streams 1 to 3 are a plurality of bit stream generators (BG232, BG233, BG23).
4 ,. ． ． ), And these bitstream generators are connected to receive it. Each bitstream generator is connected to the PEM 235. The PEM 235 is also connected to the CM 236. In such a configuration, each bitstream generator decodes the encoded data and the result of the decoding is by the PEM 235 (not by the CM 236).
Selected. Each bitstream generator receives encoded data from sources associated with one probability class (ie, encoded data comes from any context bin). The PEM 235 selects the bitstream generator by probability class. This probability class is dictated by the context bin provided by CM 236 to PEM 235. In this way, the decoded data is generated by processing the probability classes in parallel.

The parallel decoding system of the present invention has many embodiments. In one embodiment, the coded streams corresponding to multiple context bins can be interleaved into one stream ordered by the demands of various coders. In one embodiment of the present invention, the encoded data is 1
The encoded data is ordered so that each coder is constantly supplied with data, even if sent to the decoder as a stream of books. The present invention is effective for all kinds of data including image data.

It is possible to decode coded data in parallel at high speed by using a small and simple encoder which can be inexpensively copied by an integrated circuit. In one embodiment, the encoder is implemented in hardware using a field programmable gate array (FPGA) chip or standard cell application specific integrated circuit (ASCIC) chip. By combining the parallelization method and the simple bit stream generator, it becomes possible to decode the encoded data at a speed higher than that of the conventional decoder while making the compression efficiency equal to or higher than that of the conventional decoding system.

Channel Ordering of Multiple Data Streams There are various design issues and challenges that affect system performance. Some of them are described below.
However, the embodiments shown in FIGS. 3 and 4 (and FIG. 5) use multiple code streams. Parallel channel systems compatible with this embodiment are envisioned. That is, multiple telephone lines, multiple disk drive heads, and so on. For certain applications, only one channel is available or convenient. In fact, when multiple channels are required, bandwidth utilization may be poor because each codestream is bursty.

In one embodiment, the codestreams are concatenated and sent continuously to the decoder. Prefix header (pref
ace header) contains a pointer to the starting bit position of each stream. FIG. 6 shows an example of the structure of such data. In FIG. 6, three pointers 301 to 303 indicate the concatenated code streams 1,
Indicate the start positions of 2 and 3. The complete compressed data file is available in the buffer for the decoder. The codeword is retrieved from the appropriate location via the appropriate pointer when needed. Then, the pointer is updated to point to the next code word of the code stream.

In this method, it is necessary to store one entire encoded frame in the decoder, and actually in the encoder. When a real-time system or a less bursty data flow is needed, two frame buffers in both the encoder and the decoder are banked (ba).
nking).

<Data Order and Codeword Order> It should be noted that the decoder decodes codewords in a uniquely determined order. In the case of parallel encoding, the order of requests for code streams is uniquely determined. Thus, if the encoder can interleave the codewords of the parallel codestream in the correct order, a single codestream will suffice. The codeword is just in time (ju
It is passed to the decoder in the same order on a st-in-time) basis. At the encoder, the model of the decoder determines the order of the codewords and packs the codewords into a single stream. This model may be the actual decoder.

When the data is of variable length, one problem arises with the distribution of the data to the parallel decoding elements. For unpacking a stream of variable length codewords, the codewords must be aligned using bit shifters. Bit shifter, when realized by hardware,
Often expensive and / or slow. The control of the bit shifter depends on the size of individual codewords. The feedback loop of this control impedes fast execution of variable length shift operations. The effect of supplying a single stream to multiple decoders works well if the unpacking of that stream is performed with a single bit shifter that is not fast enough to keep up with multiple decoders. I can't let you do it.

The solution proposed in the present invention separates the problem of distributing encoded data to parallel decoders from the alignment of variable length codewords for decoding. Codewords in independent codestreams are interleaved (inte
rleaved) packed into fixed-length words, called words.
At the decoder end of the channel, these interleaved words can be distributed to parallel decoder units by hardwired high speed data lines and simple control circuitry.

It is convenient to make the length of the interleaved word longer than the maximum length of the codeword, because each interleaved word contains at least enough bits to complete one codeword. One interleaved word includes a codeword and a part of the codeword. FIG. 7 illustrates an example interleaving operation of a set of parallel code streams.

These words are interleaved according to the requirements of the decoder. Each independent decoder receives the whole of one interleaved word. The bit-shift operation is performed locally in each decoder to maintain system parallelism. In FIG. 7, the first codeword in each interleaved word is the lowest codeword among the remaining codewords in the codestream set. For example, the first interleaved word originates from codestream 1 and starts with the lowest numbered codeword (ie, # 1). This is followed by the first interleaved word of codestream 2 and then the first interleaved word of codestream 3. However, the next lowest codeword is
It was # 7 that didn't fit into the interleaved words that were already ordered. Therefore, the next word in the stream is the second interleaved word of codestream 2.

In another embodiment, the next set of interleaved words (eg, codeword starting with codeword # 8 of stream 1, codeword starting with # 7 of stream 2, code starting with # 11 of stream 3). The order in which the words are inserted into the interleaved codestream is that the preceding set of interleaved words (eg, codeword # 1 of stream 1).
From the interleaved word having the lowest number, based on the first codeword of the codeword starting with, the codeword starting with codeword # 2 of stream 2, and the codeword starting with codeword # 4 of stream 3 The leading codeword is ordered towards the interleaved word with the highest number. Therefore, in this case, since the interleaved word starting from codeword # 1 was first, the next interleaved word of stream 1 is the first interleaved group of the second interleaved word that is then inserted into the interleaved stream. The next interleaved word of stream 2, followed by the next interleaved word of stream 3. It should be noted that after the second group of interleaved words is inserted in the interleaved stream, the next interleaved word in stream 2 will be the interleaved word next inserted in the stream. This is because codeword # 7 is the lowest codeword in the second set of interleaved words (followed by codeword # 8 of stream 1 and codeword of stream 3). # 11 continues).

Using the actual decoder as a model for the data stream renders most of the design choices and delays for producing an interleaved stream useless. Using the actual decoder is not of great cost in the case of a duplex system with both encoder and decoder. Note that this is generally true for all parallel sets of variable-length (or varying size) data words used in a unique order.

<Code for Parallel Decoding and Kind of Bitstream Generator> The present invention can use an existing coder such as a Q-coder or B-coder as a bitstream generation element connected in parallel. . However, other codes and encoders may be used. The coders and associated codes used in the present invention are simple.

In the present invention, the arithmetic code used in the Q-coder and the multi-state (mult) used in the B-coder.
By using a simple code rather than a complicated code such as i-state) code, some advantages can be obtained. A simple code has the advantages over a complex code in that the hardware configuration is much faster, simpler and requires less silicon.

Another advantage of the present invention is that it can improve coding efficiency. A code that uses a finite amount of state information is
Shannon's entropy limit cannot be satisfied for all probabilities. Conventionally known hardware-implemented coders that can handle multiple probabilities or contexts with a single bitstream generator have some limitations that reduce coding efficiency. Removing those constraints required for multiple contexts or probability classes allows the use of codes that are closer to meeting the Shannon entropy bounds.

<R-Code> The code (and coder) used in one embodiment of the present invention is called an R-code. The R-code is an adaptive code that transforms a variable number of identical input symbols into one codeword. In one embodiment, the R-code is parameterized so that many different probabilities can be handled with a single decoder design. further,
The R-code of the present invention can be decoded simply by high-speed hardware.

In the present invention, the R-code is used to perform encoding or decoding by the R-coder. In one embodiment, the R-coder is a combination of a bitstream generator and a probability prediction module. For example, in FIG. 1, one R-coder may include a combination of probability prediction module 102 and bitstream generator 103 and a combination of probability prediction module 105 and bitstream generator 106.

The code word is a maximum probability (maximum likelihood) symbol (MP
S) represents the run. MPS represents the result of a binary decision with a probability of greater than 50%. The lowest probability symbol (LPS), on the other hand, represents the result of a binary decision with a probability of less than 50%. When two results have equal probabilities, which one is called MPS or LPS?
As long as both the encoder and decoder make the same name, it is not important. The resulting bit sequence in the compressed file is shown in FIG. 49 in relation to a parameter called MAXRUN.

Description will be made in relation to the contents of the table 1 shown in FIG. To encode, the number of MPS in the run is counted by a simple counter. When that count equals the MAXRUN count value, a 0 codeword is sent to the codestream and the counter is reset. When the LPS is found, a bit group N, which is a unique description of the number of MPS symbols before the LPS, is sent to the code stream following the one 1 (note that
There are various ways of assigning the bit group N that describes the run length). Again, the counter is reset. The number of bits required for N depends on the value of MAXRUN.
Also, the one's complement of the codeword may be used.

For decoding, when the first bit of the code stream is 0, the value of MUXRUN is set in the MPS counter and the LPS indication is cleared. And
The 0 bit is discarded. When the first bit is 1, the subsequent bits are examined to extract the bit group N,
An appropriate count (N) is set in the MPS counter,
LPS display is set. Then, the code stream bit group including the 1N code word is discarded.

The R-code is created according to the rules shown in Table 1 of FIG. A certain R-code Rx (k) is defined by MAXRUN. For example, MAXRUN of Rx (k) = X · 2 ^k-1 . Therefore, MAXRUN of R2 (k) = 2 · 2 ^k−1 , MAXRUN of R3 (k) = 2 · 2 ^{k−1, and} so on.

The R-code is a subset of the Golomb code. The Rice code uses only R2 (*) code. The R-code of the present invention can use both R2 (k) and R3 (k), and other Rn (k) codes can be used if desired. In one embodiment, R2 (k) and R3 (k) codes are used. Note that Rn for n = 2 or any odd n (that is, R2, R3, R5, R7, R9, R11,
R13, R15) are present. In one embodiment, the run count r is encoded with N for the R2 (K) code. That is, the run count r is described by k bits,
Therefore, 1N is represented by k + 1 bits. Also, in one embodiment, for the R3 (k) code, the bit group N is n <2.
1 bit indicating whether the ^(k-1) a is either n ≧ 2 ^(k-1),
It may contain k-1 bits or k bits indicating the run count r, so the variable N is represented by a total of k bits or k + 1 bits. In another embodiment, 1 of N
The complement of may be used for the codeword. In this case, M
PS tends to generate codestreams with many 0's,
LPS tends to generate codestreams with many ones.

Table 2 of FIG. 50, Table 3 of FIG. 51, Table 4 of FIG. 52 and Table 5 of FIG. 53 show some efficient R-codes used in one embodiment of the present invention. There is. It should be noted that other run length codes may be used in the present invention. An example of the alternative run length code of the R2 (2) code is shown in Table 6 of FIG. Table 7 in FIG. 55 and table 8 in FIG. 56 show examples of codes used in one embodiment.

<Probability Prediction Model for R-Code> In one embodiment, the R2 (0) code does not code anything. That is, a 0 input is coded 0, a 1 input is coded 1 (or vice versa), so the R2 (0) code is optimal for probabilities equal to 50%. is there. The R2 (1) code of the presently preferred embodiment is 0.707 (70.7).
%), And the R3 (1) code is 0.
Optimal for a probability of 794 (79.4%). R2
(2) The code is optimal for a probability of 0.841 (84.1%). Table 9 in FIG. 57 shows a nearly optimum run length code. Here, the probability skew is defined by probability skew = −log ₂ (LSP).

The code shown in Table 9 is that the probability interval represented by the probability skew transforms the probability space almost evenly even if the k value having a high optimal probability is not subdivided as much as the k value having a low value. Almost optimal.

The probability that a certain R-code is optimal will be described. In reality, it is R2 that fits the entropy curve.
(2) Only code. The actual consideration is that within a certain class, one particular R-code can be used by all other R-codes.
Which probability interval is superior to the code? Table 10 in FIG. 58 shows the probability intervals of the R2 code as
Table 11 in FIG. 59 shows the probability intervals of R2 code and R3.

The probability intervals for the R2 code classes 0 through 12 are shown in Table 10 of FIG.
For example, when only the R2 code is used, R2 (0) is optimal when 0.50 ≦ probability ≦ 0.6180. Similarly, R2 (1) is optimal when 0.6180 ≦ probability ≦ 0.7862.

The answers to the classes of R2 and R3 codes are in table 11 of FIG. For example, when R2 code and R3 code are used, R2 (1) is 0.6180
Optimal when ≤ probability ≤ 0.7549.

R2 (k) for a given k is called a run length code. However, a certain k is optimal only for one probability interval. When encoding in the vicinity of the optimum probability, the R-code of the present invention has 0 codeword and 1N.
It can be seen that the codewords are used almost equally frequently. In other words, the R-coder of the present invention outputs one code and the other code at a half-time ratio. By examining the number of 0 codewords and 1N codewords, it can be determined whether the optimum code is used. That is, if the output of 1N codewords is too large, the run length is too long, and if the output of 0 codewords is too large, the run length is too short.

The probability prediction model used by Langdon examines the first bit of each codeword to determine if the source probability is above or below the current predicted value. GGLang
don, ”An Adaptive Run-Length Coding Algorithm”, I
BM Technical Disclosure Bulletin, Vol.26, No.7B, Dec.
See 1983. Based on this determination, k is increased or decreased. For example, if a codeword indicating MPS is found, the probability prediction value is too low. Therefore, Langdo
According to n, k is incremented by 1 for each 0 codeword. L
The probability estimate is too high when a codeword indicating less than MAXRUN MPS before the PS (ie, a 1N codeword) is found. Therefore, according to Langdon, k is 1 each
It is decremented by 1 for every N codewords.

The present invention enables more complicated probability prediction than the method of simply increasing or decreasing k by 1 for each codeword. The invention includes one probability prediction module state that determines the code to use. Many states may use the same code. Codes are assigned to states using state tables or state machines.

In one embodiment of the present invention, the probability predictor changes state with each output of the codeword. The probability prediction module then increases or decreases the probability prediction value depending on whether the codeword starts with 0 or 1s. For example, "0"
When the codeword is output, the predicted value of the MPS probability increases. On the other hand, when a "1" codeword is output, the predicted value of MPS probability is reduced.

Prior art Langdon coders used only R2 (k) codes and increased or decreased k for each codeword. In contrast, the present invention uses R2 (k) and R3 (k) codes in conjunction with a state table or state machine to adapt the adaptation rate to the application. That is, when there is a small amount of fixed data the adaptation has to be done more quickly to get a more optimal encoding, but when there is a large amount of fixed data the code that achieves better compression for the rest of the data. The adaptation time may be extended so that the choice can be made. It should be noted that when a variable number of state changes occur, the adaptation speed may also be affected by the characteristics specific to the application. Due to the nature of R-codes, probability prediction for R-coders is simple and requires little hardware, but is very powerful. FIG. 40 shows a graph of coding efficiency (code length normalized to entropy) vs. MPS probability. FIG. 40 shows some of the inventive R-
It shows how the coder covers the probability space. As an example, FIG. 40 shows that at an MPS probability of 0.55, the efficiency of the R2 (0) code is 1.01 which is the entropy limit.
Doubling (ie, 1% worse than the entropy limit). In comparison, the efficiency of the R2 (1) code is 1.09 times (9% worse) than the entropy limit.
This example shows that using an incorrect code for this particular low probability case results in a loss of 8% in coding efficiency.

By introducing the R3 (k) code, it is possible to cover a wider probability space with higher efficiency.
An example of the probability prediction state table according to the present invention is shown in FIG. The probability prediction state table shown in FIG. 5 shows both the state counter and the code associated with each state. Note that this table contains positive and negative states. This table is shown to have 37 positive states, including 0 states, and 37 negative states, including 0 states. Negative state is MPS with positive state
Means different. In one embodiment, a negative state can be used when MPS is 1, and a positive state can be used when MPS is 0, or vice versa. Note that the table shown in FIG. 8 is merely an example, and the number of states in the table may be larger or smaller than that, or the state allocation may be different.

Initially, the coder is in state 0, which is 0.
R2 (0) code for 50 probability prediction values. After each codeword is processed, the state counter is incremented or decremented depending on the first bit of that codeword. In one embodiment, codeword 0 increments the value of the state counter and codewords beginning with 1 decrement the value of the state counter. Therefore, every codeword causes a state change by the state counter. In other words, the probability prediction module changes state. However, multiple consecutive states may be associated with the same code. In this case, probability prediction is performed without changing the code for each code word. Stated differently, the states change from codeword to codeword, but in certain cases the states map to the same probability. For example, from state 5 to state-5, all are R2 (0)
The codes are used, and the states 6 to 11 and the states -6 to -11 use the R2 (1) code. By utilizing this state table of the present invention, the probability prediction module can move the same coder non-linearly.

Notice that the lower the probability, the more states with the same R-code. This is done because the efficiency drops significantly when a wrong code is used at a low probability. A characteristic of the run-length code state table is that the state transitions for each codeword. If the state table is designed so that the sign changes each time the state changes, the code switches between a code very close to the entropy efficiency limit and a code very far from the entropy efficiency limit when the state switches at a low probability. . in this way,
Disadvantage in transition between states (in terms of coded data bit number)
May occur. Traditional probability prediction modules, such as Langdon's probability prediction module, suffer from performance due to these disadvantages.

In a high probability run length code,
The disadvantages of incorrect sign are not so great. Therefore, the present invention adds extra states to the low probabilities to increase the changes that switch between the two correct codes, thereby reducing coding inefficiencies.

Note that in one embodiment, the coder has an initial probability prediction state. In other words, the coder starts in one predetermined state, eg state 18. In one embodiment, another state table is used to enable fast adaptation with some states for the first few symbols, and probability prediction for the remaining symbols. Another state table may be used for slow adaptation with fine tuning of the values. This would allow the coder to use more efficient codes more quickly in the encoding process. In another example, the codestream may specify an initial probability estimate for each context. In one embodiment, increments and decrements are not performed according to a fixed number (eg, 1). Instead, the probability prediction state is incremented by a variable number according to the amount of data or the amount of change (stability) of data encountered up to that point. Examples of such tables are tables 21 to 25 in FIGS. 69 to 73 described later.

If the state table is symmetric, as can be seen from the table illustrated in FIG. 8, only half (including 0 state) of the table needs to be stored or implemented as hardware. In one embodiment, to take advantage of this symmetry, state numbers are stored in the form of a sign-magnitude (one) complement. Therefore, this table can be used by taking the absolute value of 1's complement, confirming the state, and checking the sign to determine whether MPS is 1 or 0. This reduces the hardware required to increment and decrement the state. The absolute value of the state is used to index the table, and
This is because the calculation of the absolute value of the one's complement is trivial.
In another embodiment, the state table is replaced with a hardwired or programmable state machine to increase hardware efficiency. The hardwired state-to-code converter is one implementation of the state table.

<Outline of Balanced Parallel Entropy Coding System> The present invention provides a balanced parallel entropy coding system. This parallel entropy coding system performs both real-time encoding and real-time decoding with fast / low cost hardware. The present invention provides real-time compression / decompression of data on a rewritable optical disk or magnetic disk,
Real-time compression of computer network data /
Decompression, such as (but not limited to) real-time compression / decompression of image data in compressed frame storage of multifunctional (eg copier, facsimile, scanner, printer, etc.) machines, real-time compression / decompression of audio data,
It can be used for various lossless coding applications.

Some caution is required when defining the performance of the coding device. Given that the coded data channel is fast enough, it is straightforward to design a coding device that achieves a certain speed for the original data. However, in many applications the goal is for the encoder to make efficient use of the encoded data channel. The utilization rate of the coded data channel depends largely on the maximum burst rate of the original data interface, the speed of the encoder, and the compression rate of the data. These effects must be considered for a rather limited amount of data, which depends on the amount of buffering in the encoder. It is desirable to have a coding device that makes efficient use of the coded data channel, yet maintains the coding rate and high compression ratio, while still accepting the highest burst rates.

The encoding apparatus of the present invention will be described below. A decoding device that may be used with this encoding device is also described.

<Real Time Encoding of the Present Invention> FIG. 9 is a block diagram of the encoding system of the present invention. In one embodiment, the inventive coding apparatus provides real-time coding. In FIG. 9, an encoding system 600 includes an encoder 602 that is connected to a context model (CM) / state memory 603 and that generates encoded data as codeword information 604 according to the original data 601. Codeword information 604 is received by reordering unit 606, which reordering unit 606 reorders memory 60.
Connected with 7. Reordering unit 606 cooperates with reordering memory 607 to generate encoded data stream 608 in response to codeword information 604. It should be noted that this coding system is not limited to processing codewords,
Other embodiments may utilize the teachings of the present invention to process discrete analog waveforms, variable length bit patterns, channel symbols, alphabets, events, and so on.

The encoder 602 includes a context model (CM), a probability prediction machine (PEM) and a bitstream generator (BM). Encoder 60
Context model in 2 and PEM (probability prediction machine)
Are essentially the same as those in the decoder (although the direction of the data flow is different). The bitstream generator of the encoder 602 is similar to the bitstream generator of the decoder and will be described later. Encoder 60
The result of encoding by 2 is 0, which represents the original data.
More than one bit. In one embodiment, the output of 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 comprises a run start indication, a run end indication, a codeword, and an index identifying the run count of this codeword (whether it is contextual or probabilistic class). One embodiment of the bitstream generator of the present invention will be described later.

The rearrangement unit 606 includes an encoder 602.
And receives the bits and control signals (if any) generated by the bitstream generator of the above to generate encoded data. In one embodiment, rearrangement unit 606
The encoded data output from the stream is a stream of interleaved words.

In one embodiment, the rearrangement unit 606 has two
Perform one function. The rearrangement unit 606 moves the codeword group from the end of the run generated by the encoder 602 to the beginning of the run required by the decoder, combines variable length codewords, and interleaves the fixed length. And output them in the proper order required by the decoder.

The rearrangement unit 606 utilizes a temporary rearrangement memory 607. In one embodiment, the temporary reordering memory 607 may exceed 100 Mbytes in size if the encoding is performed on the workstation. In the balanced system of the present invention, the temporary reordering memory 607 is very small (eg, about 1 kbyte) and has a fixed size. Thus, in one embodiment, even if the memory or bit rate required by the decoder is increased (such as when the output is done before the completion of one run), the real-time encoding requires a certain amount of memory. Carried out using. The decoder of the present invention can confirm the effect of the rearrangement unit utilizing limited memory by, for example, implicit signaling, explicit signaling, or in-stream signaling (described below). The reordering unit 606 has finite memory available for reordering, but the "required" memory is unlimited. The effect of limited memory for the queue from the end to the beginning of the run and for the interleaved word reordering must be considered.

In one embodiment, the encoding system (and corresponding decoding system) of the present invention performs encoding (or decoding) using a single integrated circuit chip. In another embodiment, one integrated circuit contains the encoding device (encoder, decoder, memory) of the present invention. A separate memory may be added to assist the encoding. A single multi-chip module or integrated circuit may contain the hardware and memory for encoding / decoding.

The coding system of the present invention may attempt to increase the effective bandwidth by a maximum factor N. When the compression ratio achieved is less than N: 1, the coded data channel is fully utilized but only an increase in effective bandwidth equal to the compression ratio is obtained. When the compression ratio achieved exceeds N: 1, an increase in effective bandwidth is achieved and the extra bandwidth is writable. In each case, the compression ratio achieved is, of course, for the local area of data determined by the amount of buffers present in the coding system.

<Bit Generator for Encoder of the Present Invention> FIG. 10 shows an embodiment of a bit stream generator (also called a bit generator for simplification) of the encoder of the present invention. The bit generator 701 is connected to receive as input one probability class and one uncoded bit (eg MPS or LPS representation). In response to this input, the bit generator 701 outputs a plurality of signals. Two of the outputs are control signals (each codeword represents one run) indicating the start and end of the run, namely the start signal 711 and the end signal 712.
Is. It is possible for a run to start and end at the same time. "Index" when a run starts or ends
Output 713 indicates the probability class (or context) of the uncoded bits. In one embodiment, the index output 713 consists of a combination of probability classes of bits and bank identifications for systems where each probability class is replicated in several memory banks. The codeword output 714 is used to output the codeword from the bit generator 701 when the run is completed.

The memory 702 is a bit generator 70.
Connected with 1 to store run counts for a particular probability class. The bit generator 701 reads the memory 702 using an index (for example, a probability class) during the bitstream generation period. Memory 702
After reading, the bit generator 701 performs bit generation as follows. First, if the run count is 0, the start signal 711 is asserted, indicating the start of a run. If the uncoded bit is LPS, then the end signal 712 is asserted to indicate the end of the run. If the uncoded bit is LPS, the codeword output 714 is set to indicate that the codeword is a 1N codeword, and the run count is cleared, eg 0.
Set to (because it is the end of the run). If the uncoded bit is not LPS, the runcount is incremented and a test is made to determine if the runcount is equal to the code's maximum runcount. When equal to the maximum run count, end signal 712 is asserted, codeword output 714 is set to 0, and the run count is cleared (eg, run count is set to 0). If the test determines that the run count is not equal to the maximum run count of the code, the run count is incremented. Note that the index signal 712 represents the probability class received as input.

In the present invention, 1N codeword is generated by 1
It is done in such a way that the length of the N codewords can be verified without extra information. Table 12 of Figure 60 is a description of the 1N codewords of the R3 (2) codewords for the decoder and encoder.
The decoder determines that the "1" bit in the "1N" codeword is the LSB.
(Least significant bit) and the "N" count part is considered to be in the proper MSB ... LSB order. The decoder order cannot distinguish a variable length codeword from a 0 pad without knowing which code is being used. In the order of the encoder, the codewords are in reverse order, and the position of the most significant "1" bit indicates the length of the "1N" codeword. In order to generate codewords in the order of the encoder, the complements of the count values must be reversed. To achieve this, reverse the 13-bit count and then
It is sufficient to shift so as to align with the LSB. The reordering unit 606 reverses the order of the codewords back into the order of the decoder, as described in detail below. However, in any case, since the rearrangement unit 606 has to perform the shift operation, the rearrangement unit 606 is not complicated by the order inversion of the codeword.

For the R3 code, it is also necessary to indicate whether there is a short count or a long count in the bit following the "1" to generate an "N" codeword.

The present invention enables pipeline processing by using a plurality of memory banks. For example, in the case of a multi-port memory, the memory read operation for the pre-encoding bit is performed, and at the same time, the memory write operation for the previous pre-encoding bit is performed.

<Altra AHDL Sample Design> An embodiment of the bit generator of the encoder of the present invention is composed of an FPGA (field programmable gate array). This design uses R2 code up to R2 (12), R3
Process all signs. The AHDL (Altera Hardware
DescriptionLanguage) source code is shown in FIGS. 41 to 46.

The present design consists of multiple parts as shown in FIG. First, the "ENCBG" 1301 is the main part of the design and has the logic to handle the start, end and sequence of runs. Second, "KEXPAND" 13
02 is a probability class with maximum run length, variable length mask and R
3 Used to expand the length of the code to the length of the first long codeword. "KEXPAND" 1302 has the same function as the decoder of the same name. Third, the "LPSCW" 1303 receives as input the count value and probability class information and generates an appropriate "1N" codeword.

The present design uses two pipeline stages. In the first pipeline stage, counts are incremented, probability classes are expanded, and subtractions and comparisons for long R3 codewords are performed. All other operations are executed in the second pipeline stage.

<Re-arrangement Unit of the Present Invention> FIG. 11 is a block diagram of an embodiment of the re-arrangement unit. In FIG. 11, the rearrangement unit 606 includes a run count rearrangement unit 801 and a bit pack unit 802.
Run count reordering unit 801 moves the end of the run generated by the encoder to the beginning of the run as required by the decoder. On the other hand, bit pack unit 8
02 combines variable-length code words into a fixed-length interleaved word, and outputs it in an appropriate order required by the decoder unit.

A "snooper" decoder can be used to reorder any decoding already in place, in which case the decoder is built into the encoder, which is actually Issue the data requests in the order that the codewords are needed. To support the snoop decoder, runcount reordering may have to be done independently for each stream. For easily mimicable decoders, multiple time stamped queues or a merged queue may be used to allow reordering. In one embodiment, the reordering of each codeword can be done using a queue-like data structure and is independent of how multiple coded data streams are handled. The method of rearranging will be described below.

The first reordering operation performed in the encoder is to reorder each run count so that it is specified at the beginning of the run (the decoder requires it for decoding). So). This reordering is necessary because the encoder does not determine what run count (and codeword) until the end of the run. In this way, the run counts obtained by encoding the data are reordered so that the decoder can properly decode it into a data stream.

Returning to FIG. Rearrangement unit 6 of the present invention
06 comprises a run count rearranging unit 801 and a bit pack unit 802. The runcount sorting unit 801 has multiple inputs, namely the start signal 71.
1, the end signal 712, the index signal 713, and the codeword 714. These signals will be described in more detail in connection with the runcount reordering unit of FIG. Run count reordering unit 801 generates codeword 803 and signal 804 in response to its input. Signal 804 indicates when the run count should be reset. The codeword 803 is received by the bitpack unit 802. Bitpack unit 803 generates interleaved word 805 in response to codeword 803.

The run count rearranging unit 801 and the bit pack unit 802 will be described in more detail below.

<Run Count Rearrangement Unit> As described above, the decoder receives the code word when the head portion of the data encoded in the code word is needed. However, the encoder does not know the identity of the codeword until the end of the data encoded in that codeword.

A block diagram of one embodiment of the runcount reordering unit 801 is shown in FIG. The described embodiment can accommodate four interleaved streams, each interleaved word being 16 bits and the codeword varying in length from 1 bit to 13 bits. In such a case, the reordering unit 606 may be pipelined to process the entire stream. Furthermore, since a coder is used that associates run counts with probability classes, the maximum number of run counts that can be active at any given time is small, which is assumed to be 25 in this example. Note that the present invention uses four interleaved streams, 16-bit interleaved words, and 1-1.
The present invention is not limited to the code word length of 3 bits, and the present invention is also applied when the number of streams is increased or decreased, the interleaved word length is increased or decreased from 16 bits, or the code word length is increased from 1 to 13 bits. You can

In FIG. 12, a pointer memory 901
Is connected to receive index input 713,
Generate address output. This address output is connected to one input of a multiplexer (MUX) 902. M
The remaining two inputs of the UX902 are the head counter 90
3 is connected so as to receive an address issued as a head pointer by 3 and an address issued by a tail counter 904 as a tail pointer. The output of MUX 902 is connected to codeword memory 908 and is used to access the same.

Index input 713 is also connected as one input of MUX 905. Another of MUX905
One input is connected to the codeword input 714. MUX90
The output of 5 is connected to the input of the validity detection module 906 and the data bus 907. The data bus 907 is connected to the input of the code word memory 908 and the MUX 905. The output of the control module 909 is also connected to the data bus 907. The start input 711 and the end input 712 are connected to separate inputs of the control module 909. The output of the validity detection module 906 is the codeword output 803 and the signal 804.
(FIG. 11). Run counter rearranging unit 8
01 also has controller logic (not shown in order not to obscure the invention) for coordinating the operation of its parts.

Again, the index input 71
3 identifies one run. In one embodiment, the index points to one of 25 probability classes. in this case,
It takes 5 bits to express the index. It should be noted that when multiple banks of probability clsk are used, extra bits may be needed to specify a particular bank. In one embodiment, the index input specifies a probability class instead of a run count. The codeword input 714 is a codeword at the end of the run, but otherwise "don't care". Start input 711 and end input 712 are the start of the run
It is a control signal indicating whether it is the end or both. When the run begins and ends at the same time, the run consists of a single uncoded bit.

The run count rearranging unit 801 is
Reorder the run counts generated by the bit generator according to its inputs. The codeword memory 908 stores codewords during rearrangement. In one embodiment, the codeword memory 9
08 is greater than the number of run counts that can be active at the same time. This leads to improved compression. If the codeword memory is smaller than the number of runcounts that can be active at the same time, the actual number of active runcounts will be limited to what can be stored in memory. A system with a good compression ratio has a long run count of 1
During the accumulation of data for one codeword, it is often the case that a large number of codewords with a short run count start (and possibly end). For this reason, it is necessary to use a large memory so that long runs are not forced out before completion.

The pointer memory 901 holds the address of the codeword memory location for the probability class in the middle of one run, and addresses the codeword memory 908 in a random access manner. The pointer memory 901 is
For each probability class that can be in the middle of a run, we have one location for the address of codeword memory 908. When one run ends as a certain probability class, the codeword memory 90 is stored using the address of the certain probability class stored in the pointer memory 901.
8 is accessed and the completed codeword is the codeword memory 90.
8 are written to that location. Up to that point, that location in codeword memory 908 had stored an invalid entry. In this way, the pointer memory 901 stores the location of the invalid codeword for each run count.

Head counter 903 and tail counter 9
04 also supplies an address for accessing the codeword memory 908. The head counter 903 and tail counter 904 can be utilized to address the codeword memory 908 as a queue or circular buffer (eg, first in first out [FIFO] memory). The tail pointer (904) stores the address of the next available location in the codeword memory 908 so that the codeword can be inserted into the codeword memory 908. The head counter 903 stores the address of the codeword to be output next to the codeword memory 908. In other words, the head counter 903 stores the codeword memory address of the codeword to be deleted next from the codeword memory 908. 1 with the location for each possible index (eg probability class) in pointer memory 901
By remembering where the tail pointer (904) was when one run started, the appropriate codeword can be stored in that location in codeword memory 908 when the run ended.

The control module 909 generates a valid signal indicating whether or not a certain entry stores valid codeword data, as a part of the stored data in the codeword memory 908. For example, if its valid bit is a logical 1,
The codeword memory location stores valid data. However, if the valid bit is a logical 0, then the codeword memory location is storing invalid data.
The validity detection module 906 determines whether one memory location stores a valid codeword each time one codeword is read from the codeword memory 908. In one embodiment, the validity detection module 906 checks if the memory location contains a valid codeword or a special invalid code.

When starting a new run, invalid data entries are stored in codeword memory 908. This invalid data entry is stored in the codeword memory 908 to ensure that the codeword for that run is stored in the correct location in memory when the run is complete (to ensure proper ordering that mimics the decoder). Serves as a space store in the stored data stream. In one embodiment, this invalid data entry includes an index via MUX 905 and an invalid indication (eg invalid bit) from control module 909. The address of the codeword memory 908 where the invalid entry is stored is the tail pointer (90
5) and stored in pointer memory 901 as a clue to the location for the run counter in codeword memory 908. The remaining data is the completed run count (e, g., Sorted run count)
As a head pointer (90 in the codeword memory 908).
3) and the tail pointer (904). The maximum number of invalid memory locations is 0 to L-1, where L is the number of run counts. One at the end of one run
When one codeword is completed, its run count is stored in the codeword memory 908 using the address stored in the pointer memory 901.

When a run begins, the index for that run is stored in codeword memory 908, so when codeword memory 908 is full, but that run is not yet complete, the index is Signal 8
Used with 04 to reset the corresponding run counter. In addition to storing the codeword or index in the codeword memory 908, 1 bit (here, "
A "valid" bit) is used to indicate which of these two types of data is stored.

When neither the run is started nor ended, the run count rearrangement unit is in the idle state. When the run is started and not ended and the memory is full, one codeword is output from the codeword memory 908. This output codeword is the head pointer (90
It is a codeword stored in the address related to the probability class held in 3). Then, when a run is started but not ended (whether the memory is full or not), the index input 713 causes the MUX9
It is stored in the address of the code word memory 908 designated by the tail pointer (904) via 05. Then, the tail pointer (904) is set to the index input 7
Pointer memory 901 designated by the data on 13
Address (eg, location in pointer memory 901 for that probability class). After writing the tail pointer (904), the tail pointer (9
04) is incremented.

When the run is ended but the run is not started, the address corresponding to the index stored in the pointer memory 901 is read out and the code for storing the completed code word on the code word input 714 is read. Used as a word memory location.

One codeword is output from the codeword memory 908 when a run is started and ended (ie one run begins and ends at the same time) and the memory is full. Then, when the run is started and ended (whether the memory is full or not), the codeword input 714 is written to the codeword memory 908 address specified by the tail pointer (904). . The tail counter 904 is then incremented (eg, incremented by 1) to hold the next available location.

In the present invention, the run counter rearrangement unit 801 will output codewords at various timings. In one embodiment, the codeword will be output when valid or invalid. The codeword will be output, even when it is invalid, if the memory is full and one run has not completed. Invalid codewords may be output to maintain a minimum rate (ie for rate control) as well. In addition, when the run count rearrangement of all the data is completed, or when the run count rearrangement unit jumps to the center of the code word memory 908 as a result of the reset operation, the code word memory 908
An invalid codeword will be output due to the flush of. In such a case, the decoding device must be aware that the encoding device is operating as such.

As described above, the codeword is output whenever the codeword memory 908 is full. Codeword memory 9
Once 08 is full, every time there is an input to codeword memory 908 (ie, the start of a new codeword), an output from codeword memory 908 will occur. Codeword memory 9
Updating an entry when 08 is full does not cause the output of codeword memory 908. That is, completing one run and writing the resulting codeword to the previously allocated memory location does not cause a memory full output. Similarly, when one run is over and the corresponding address in pointer memory 901 and the address in head counter 903 are the same, the codeword is output immediately and the headcounter is accessed without accessing codeword memory 908. 903 will be incremented. In one embodiment, the tail pointer (904) after increment is the head pointer (903).
A memory full condition occurs when Therefore, when the tail pointer (904) is updated, the controller logic within the runcount reordering unit 801 is updated by the tail pointer (904) and the head pointer (90).
3) are compared, and when they match, it is determined that the codeword memory 908 is full and one codeword must be output. In another embodiment, the codeword will be output before the memory is full. For example, the head pointer (90
If the portion of the queue addressed by 3) contains a valid codeword, that codeword will be output. For that purpose, it is necessary to repeatedly check the head part of the queue and confirm the state of the codeword in it. Note that the codeword memory 908 is emptied at the end of encoding the file.

Using the run count rearranging unit 801, first, the head pointer (90
One codeword is output by reading a value (for example, data) from the address designated in 3). The output of the codeword is controlled and regulated by the controller logic. Validity detection module 906 tests to determine if the value is a codeword. In other words, the validity detection module 906 determines whether the codeword is valid. In one embodiment, the validity detection module 906 examines the validity bit stored in each entry to determine the validity of the entry. If the value is a codeword (ie, the codeword is valid), then the value is output as a codeword. On the other hand, if its value is not a codeword (ie,
If that codeword is invalid), a codeword with a run of MPS that is longer than the current runcount will be output. It will be output because the "0" codeword is the only codeword that accurately represents the current run. After that output, the head pointer (903) is incremented to point to the next location in codeword memory 908. Alternatively, the allowable shortest run length is "1N"
Is used to force the decoder to only check if one codeword was pushed out before sending the LPS.

In one embodiment, runcount reordering unit 801 operates in two clock cycle times. First
In the clock cycle of, the input is loaded into the codeword memory 908. On the second clock cycle, the output of codeword memory 908 occurs.

The codeword will be output whenever the head pointer (903) addresses a valid codeword, but depending on the configuration, it may be desirable to output the codeword only when the buffer is full. Absent. By doing so, the system delay is fixed and does not fluctuate for a certain number of code words. Given that the codeword memory 908 can hold a predetermined number of codewords between the time a run starts and is input and the time it is output, the codeword memory 908 is full. Is not output until,
The delay is the predetermined number of code words. The delay for rearrangement still varies depending on, for example, the amount of encoded data or the amount of original data. If the codeword memory 908 is full before issuing the output, the output will generate one codeword per cycle.

It should be noted that if a location in the codeword memory 908 is marked invalid, its unused bits may be used to store identification information of what runcount the location is. Good (ie, the context bin or probability class that should fill that location is stored there). This information is useful for handling when the memory is full. Specifically, this information can be used to indicate to the bitstream generator that the codeword for that runcount is not complete, and that it is complete. In this case, the decision was made to output an invalid codeword, which may have been caused by a memory full condition. Thus, as the system resets the run counter, this information reveals when the system should resume operation with respect to the bit generator and run count.

Regarding the index input, but due to pipeline processing when multiple bank probability classes are used, the index may contain bank identification information. That is, there may be multiple runcounts for a probability class. For example, 80%
There may be two runcounts for a code, where one is used and the other is then used.

Since codewords are of variable length, they must be stored in codeword memory 908 in such a way that their length can be ascertained. It may be possible to store the size explicitly, but that does not minimize memory usage. In the R-code, since a 1-bit "0" code word can be designated by storing a value of 0 in the memory, the length of the "1N" code word from the first "1" is confirmed by the priority encoder. Can be stored as you can.

If the codeword memory 908 is multi-ported (eg dual ported) then this design can be pipelined to process one codeword per clock. Since any location in codeword memory 908 will be accessible from multiple ports, writing one location in codeword memory 908 (eg, storing invalid or valid codewords) and reading another location (eg, codeword memory 908). Output) and can be done simultaneously. Note that in this case the multiplexer would have to be modified to support multiple data and address buses.

The decoder must do the same whenever the encoder outputs a "0" codeword and whenever it resets the run counter because the codeword memory is full. To do so, the decoder must mimic the codeword memory queue of the encoder. The method will be described later.

To save the power of CMOS devices, "1" is output when a "0" code word is output as an invalid run.
The counter for N "codewords may be disabled, because the decoded" 1N "codeword may be valid, but only the" 0 "codeword may be invalid.

<Other Embodiments Based on Context> FIG. 1
3 is a block diagram of another embodiment of a runcount reordering unit that reorders received data according to context (as opposed to probability class). This run count rearranging unit 1000 is
-Perform the sorting using the sign. In FIG. 13, the run count rearranging unit 1000 includes a pointer memory 1001, a head counter 1002, and a tail counter 1.
003, a data multiplexer (MUX) 1004, an address MUX 1005, a length calculation block 1006, a validity detection block 1007 and a code word memory 1008. Codeword memory 1008 stores codewords during rearrangement. The pointer memory 1001 stores the address of the codeword memory location for the context bin in the middle of the run. The head counter 1002 and the tail counter 1003 can not only address the codeword memory 1008 as a queue or a circular buffer, but can also be addressed by the pointer memory 1001 in a random access manner. 0 for R-code
Since a 1-bit "0" codeword can be specified by storing the value "0" in the memory, the length of the "1N" codeword from the first "1" can be confirmed by the priority encoder. Can be stored. Length calculation module 1
006 acts like a priority encoder. (If other variable length codes are used, it is better to add a "1" bit to mark the beginning of the codeword to store the codeword length explicitly.
It would be more memory efficient than adding g2 bits. The run count reordering unit 1000 also has controller logic (not shown) for regulating and controlling the operation of its elements 1001-1008.

The operation of the runcount reordering unit 1000 is very similar to the operation of the runcount reordering unit based on probability estimates. When a new run is started, one invalid entry containing the context bin is written to the codeword memory 1008 address specified by the tail pointer (1003). Next, the address of the tail pointer (1003) is changed to the pointer memory 10
01 at the address of the current runcount context bin. And the tail pointer (1003)
Is incremented. When one run is completed,
A pointer corresponding to the run count is read from the pointer memory 1001 and the code word is written to the location of the code word memory 1008 designated by the pointer. It is neither the start nor the end of the run, and when the content of the location of the codeword memory 1008 designated by the head pointer (1002) is invalid data, the codeword addressed by the head pointer (1002) is read and output. It Then, the head pointer (1
002) is incremented. If the start and end of the run occur simultaneously, the codeword is written to the address of the codeword memory 1008 designated by the tail pointer (1003), and then the tail pointer (1003).
Is incremented.

Similarly, after one run ends, the address of the corresponding pointer memory 1001 and the head counter 10
When the address of 02 is the same, the code word can be output immediately, and the value of the head counter 1002 can be incremented without accessing the code word memory 1008.

In the "per context" run count system, each context has a pointer memory 100.
BG and P because it requires one location
The pointer memory 1001 may be realized by expanding the EM state memory. The width of the pointer memory 1001 is equal to the size required for the codeword memory address.

The number of locations of the code word memory 1008 may be selected by the designer in a specific configuration. Limiting the size of this memory lowers the compression efficiency, so that there is a trade-off between cost / compression ratio. The width of the codeword memory is equal to the maximum codeword plus one bit for valid / invalid indication.

The rearrangement will be described using an example of using the R2 (2) code shown in the table 13 of FIG. The table 14 of FIG. 62 shows the data to be sorted, labeled by context (0 = MPS, dominant symbol; 1 = LPS, inferior symbol). There are only two contexts. The pre-encoding bit number indicates the time in the pre-encoding bit clock cycle. The beginning and end of the run are shown, and the codeword is shown at the end of the run.

The sorting operation for this data example is shown in FIG.
3 in Table 15. A codeword memory with four locations 0-3 is used, but in this example this size is sufficient and no overflow occurs. Each row shows the state of the system after one operation, the start or end of a run of a context, or the output of a codeword. "X" means "no need to consider"
Used to indicate memory location. For some uncoded bits, the runcount reordering unit is idle because the run does not begin or end. For coded bits that terminate a run, one or more codewords may be output, which may result in varying system states.

In Table 15 of FIG. 63, the head pointer and tail pointer are initialized to 0, which means that nothing is stored in the codeword memory (eg queue). The pointer memory is represented as having two storage locations, one for each context. Each location stores a "don't care" value before bit number one. The codeword memory is shown as having a depth of 4 codewords, but they are all initially "don't care" values.

For the data received for bit number 1, the head pointer is codeword memory location 0.
Is still instructed. Since the decoder expects data, the next available codeword memory location 0 is assigned to the codeword and the invalid value is written to memory location 0. Since the context is 0, the address of the codeword memory location assigned to the codeword is stored in the pointer memory location for 0 context (pointer memory location 0). Thus, "0" is stored in pointer memory location 0. The tail pointer is incremented to point to the next codeword memory location 1.

For the data corresponding to bit number 2,
The head counter remains pointing to the first memory location (because there was no output to update it). This data corresponds to the second context, context 1, so that the next codeword memory location, codeword memory location 1 pointed to by the tail pointer, is assigned to the codeword and an invalid value is written to it. Be done. That address, codeword memory location 1, is written to pointer memory location 1, which corresponds to context 1. That is, the address of the second codeword memory location is written to pointer memory location 1. Then, the tail pointer is incremented.

For the data corresponding to bit number 3,
The sorting unit is neither the beginning nor the end of the run, so it becomes an idol.

For the data corresponding to bit number 4,
The end of the run is indicated for context 1. Therefore, the code word “101” is written to the code word memory location assigned to context 1 (code word memory location 1) pointed to by the context 1 pointer memory location. It is a "don't care" value because the head and tail pointers remain the same and the value of the pointer memory location for context 1 will not be reused.

For the data corresponding to bit number 5,
The sorting unit becomes idle because the run does not begin or end.

For the data corresponding to bit number 6,
The same type of operation as described above for bit 2 occurs.

For the data corresponding to bit number 7,
The run of the codeword of context 0 ends. In this case, the codeword "0" is written to the codeword memory location (codeword memory location 0) pointed to by the pointer memory location for context 0 (pointer memory location 0). And because the value of this pointer memory location is not used again, it is
It is a value that does not need to be considered. Also, the codeword memory location specified by the head pointer contains valid data. Therefore, this valid data is output and the head pointer is incremented. This causes the head pointer to point to another codeword memory location that stores a valid codeword, so that this codeword is output,
The head pointer is incremented again. Note that in this example, the codeword is output when it is possible, not when the codeword memory is completely full.

As described above, the processing of the uncoded bits is continuously performed. It should be noted that the codeword memory location is not dedicated to a particular context, so codewords from any context can be stored in a particular codeword memory location throughout the encoding of a data file.

<Bit Packing Unit> Bit packing will be described with reference to FIG. FIG. 7 shows the processed data of the rearrangement unit before and after bit packing. Sixteen variable length codewords are shown in FIG. 7, which are numbered 1 to 16 to indicate the order in which they will be utilized in the decoder. Every codeword is assigned to one of the three coded streams. The data in each encoded stream is decomposed into fixed-length words called interleaved words. (Note that one variable-length codeword may be decomposed into two interleaved words.) In this example, the interleaved words are ordered into one interleaved stream, so that a particular interleaved word The order of the first variable-length codeword (or part thereof) in it determines the order of the interleaved words. Other types of ordering criteria may be adopted. The advantage of interleaving multiple coded streams is that a single coded data channel can be used for data transfer and that variable length shift operations can be performed per stream in parallel or in pipelines.

The bit pack unit 802 of the present invention is
It receives variable length codewords from runcount reordering unit 801 and packs them into interleaved words. The bit pack unit 802 includes logic for processing variable length code words and a merge queue type rearrangement unit for outputting fixed length interleaved words in the correct order. In one embodiment, the codeword is at most 1.
Received from the runcount reordering unit at the rate of codewords / clock cycles. Bit pack unit 8
A block diagram of one embodiment of 02 is shown in FIG.
In the embodiment described below, four interleaved streams are used, each interleaved word is 16 bits, and the codeword length varies from 1 bit to 13 bits. In one embodiment, a single bitpack unit is pipelined to handle the entire stream.
If the bit pack unit 802 of the present invention uses a dual port memory (or register file),
One interleaved word can be output per clock cycle. This speed may be faster than the speed required to follow the rest of the encoder.

In FIG. 14, the bit pack unit 8
02 is packing logic 1101 and stream counter 1
102, a memory 1103, a tail pointer 1104, and a head counter 1105. Packing logic 11
01 is connected to receive the codeword and is also connected to the stream counter 1102. The stream counter 1102 is also connected to the memory 1103. Memory 1
A tail pointer 1104 and a head counter 1105 are also connected to 103.

Stream counter 1102 monitors the interleaved word to which the current input codeword is related. In one embodiment, stream counter 1102 may range from 0 to N.
The stream is repeatedly counted up to -1. here,
N is the number of streams. Stream counter 1102
Starts counting from 0 again when it reaches N-1.
In one embodiment, stream counter 1102 is a 2-bit counter that counts from 0 to 3 (for four interleaved streams). In one embodiment, stream counter 1102 is initialized to 0 (eg, by global reset).

Packing logic 1101 merges the current input codeword with the previously input codeword to create an interleaved word. The length of each codeword will vary. Therefore, packing logic 1101 packs these variable length codewords into fixed length words. The interleaved codewords generated by the packing logic 1101 are stored in memory 1 in order.
103 is output to the memory 110 until it is output
3 is stored. In one embodiment, memory 1103 has 64
Static RAM with 16 16-bit words (SRA
M) or a register file.

The interleaved word is stored in the memory 1103. In the present invention, the size of the memory 1103 is large enough to handle two cases. One case is the case of normal operation, in which one interleaved stream has a minimum length codeword and the other interleaved stream has a maximum length codeword. This first case is 3 × 3 = 39
Need memory locations. The other case is
In the case of initialization, one interleaved stream has a minimum length, that is, a short codeword, and the other interleaved stream has a maximum length, that is, a long codeword. For the second case, 2 × 3 × 13
A memory location of = 78 is sufficient, but it can be narrowed down to 56 by the operation of the PEM.

Memory 1103 and stream counter 11
02 and tail pointer 1104 cooperate to perform rearrangement. The stream counter 1102 is the memory 11
Indicates the current stream of codewords being received by 03. Each interleaved stream is associated with at least one tail pointer. The tail pointer 1104 and the head counter 1105 rearrange the codewords. The reason there are two tail pointers per stream is that interleaved word N is requested by the decoding device when the data of interleaved word N-1 contains the beginning of the next codeword. One tail pointer determines the location in memory 1103 that stores the next interleaved word from a given interleaved stream. The other tail pointer determines the location in memory 1103 that stores the next interleaved word of the next interleaved word. This allows the decoder to interleave the word N-
The location of the interleaved word N can be specified when the time of requesting 1 is known. In one embodiment, the tail pointers are eight 6-bit registers (two tail pointers per stream).

In one embodiment, at the beginning of encoding, the tail pointer 1104 ensures that the first eight interleaved words (two words from each stream) are stored sequentially in memory 1103, one from each stream. Is set to.
After initialization, each time packing logic 1101 undertakes a new interleaved word for a codestream,
The "next next" tail pointer is set to the value of the "next next" tail pointer, and the "next next" tail pointer for the code stream is set to the next available memory location. 2 tail pointers
There is one. In another embodiment, only one tail pointer is used for each codestream, the tail pointer pointing to the interleaved word to be stored in memory 1203 next.

The head counter 1105 is used to determine the memory location of the interleaved word output next from the bit pack unit 802. In the described embodiment, the head counter 1105 comprises a 6-bit counter, which is incremented to output an entire interleaved word at a time.

The memory 1103 is used not only for rearrangement, but also as a FIFO buffer between the encoder and the channel. It is desirable to make this memory larger than the memory required for the reordering so that the FIF can be used when the channel cannot follow the encoder.
The signal that O is almost full can be used to stop the encoder. A 1-bit / cycle encoder cannot generate one interleaved word per cycle. If a given encoder is well matched to a channel, that channel will not accept one interleaved word every cycle, so some FIFO buffer is needed. For example,
A channel that can accept one 16-bit interleaved word every 32 clock cycles has a compression ratio of 2: 1.
At this point, it would be a well-matched design for 2: 1 bandwidth expansion.

<Packing Logic of the Present Invention>
A block diagram of the packing logic is shown in FIG.
In FIG. 15, the packing logic 1101 has a size (si
ze) unit 1201, one set of accumulator 120
2, shifter 1203, MUX 1204, a set of registers 1205 and OR gate logic 1206. The size unit 1201 is connected to receive the codeword and is also connected to the accumulator 1202.
These accumulators 1202 and code words are connected to the shifter 1203. Shifter 1203 is MUX1
204 and OR gate logic 1206.
MUX 1204 is also connected to register 1205 and OR gate logic 1206. These registers 1205
Are also connected to OR gate logic 1206.

In one embodiment, codewords are input over a 13-bit bus with unused bits set to zero. Since these unused zeroed bits are adjacent to the "1" in the "1N" codeword, the priority encoder inside the size unit 1201 is used to determine the length of the "1N" codeword, and A size of "0" codeword can be generated.

The accumulator 1202 is composed of a plurality of accumulators, one for each interleaved stream. The accumulator for each interleaved stream keeps a record of the previous number of bits of the current interleaved word. In one embodiment, each accumulator consists of a 4-bit adder (with carry output) and a 4-bit register utilized for each stream. In one embodiment, the output of that adder is the output of the accumulator. In another embodiment, the output of that register is the output of the accumulator. Utilizing the codeword size received from size unit 1201, the accumulator determines the number of bits to shift to concatenate the current codeword to the register holding the current interleaved word of the stream.

Based on the current value of the accumulator, shifter 1203 aligns the current codeword so that it properly follows the previous codeword in the interleaved word. In this way, the data in the encoder is changed to the decoder order. The output of shifter 1203 is 28 bits, which is 13 bits out of 15 bits of the current interleaved word so that the bits from the current codeword will be in the upper 12 bits of the final 28 bits output. Handles the case where the codeword of must be added. Since the shifter 1203 operates without feedback, it can be pipelined. In one embodiment, shifter 1203 comprises a barrel shifter.

Register 1205 stores the bits of the current interleaved word. In one embodiment, a 16-bit register for each interleaved stream holds the previous bit in the current interleaved word.

First, one codeword of one stream is received by shifter 1203, while size unit 1201 indicates the size of that codeword to the accumulator corresponding to that stream. An initial value 0 is set to the accumulator by global reset. Since the accumulator value is 0, the code word is not shifted and is ORed with the contents of the register corresponding to the stream by the OR logic 1206. However, in some embodiments, even at the beginning of an interleaved word, the 1N codewords must be shifted in order to be properly aligned. Since this register is initialized to 0, the result of the OR operation will put the code word into the rightmost bit position of the OR logic 1206 and will be fed back to the register via the MUX 1204 to the next in the stream. The code word is stored. Thus, initially, the shifter 120
3 acts as a passage. The bit number of the first code word is currently stored in the accumulator. When the next codeword for the stream is received, the value of the accumulator is sent to the shifter 1203, and the codeword is shifted left by that number of bits and combined with the bits input before the interleaved word. Zeros are set in the other bits of the shifted word. The bit from the register corresponding to the stream is combined with the bit from shifter 1203 by OR logic 1206. If the accumulator does not give a carry output indication (eg signal),
Since more bits are needed to complete the current codeword, the data obtained by the OR operation is MUX12.
It is returned to the register via 04 and saved. In one embodiment, MUX 1204 is a 2: 1 multiplexer. When the accumulator produces a carry output, the 16-bit data OR'ed by the OR logic 1206 is one completed interleaved word and will be output thereafter. The MUX 1204 puts the first 16
An additional bit (for example, the upper 12 bits of the 28 bits output from the shifter 1203) is loaded following the bit, and 0 is inserted in the remaining bit positions.

The control for MUX 1204 and interleaved word output utilizes the carry output signal from the accumulator. In one embodiment, multiplexer 120
4 consists of 16 2: 1 multiplexers, of which 4 multiplexers have one input always zeroed.

<Sorting Options> The present invention provides various options for sorting data. For example, in a system with multiple codestreams, those codestreams must be reordered into interleaved words as shown in FIG. The present invention provides various methods of accomplishing interleaved permutation.

One method for rearranging data into interleaved words is to use a snooping decoder as shown in FIG. In FIG. 32, a plurality of runcount rearranging units 2501a to 2501n are connected to receive codeword information in addition to the codeword stream. Each runcount reordering unit produces a codeword output and a size output. Separate bit packing logic (1101) units, such as bit pack units 2502a-2502n, are connected to receive the respective codeword and size outputs of runcount reordering units 2501a-2501n. The bit pack units 2502a to 2502n output interleaved words, which are connected to a MUX 2503 and a snooper decoder 2504. Snoop decoder 250
4 outputs a selection control signal, and this selection control signal is MUX2.
Received at 503 and instructing MUX 2503 which interleaved words should be output to the codestream.

There is one runcount reordering unit for each coded data stream, which consists of the runcount reordering unit 801 of FIG. Each bit pack unit combines variable length code words into fixed size, perhaps 8-bit, 16-bit or 32-bit / word interleaved words. Each bit pack unit includes a register and a shift circuit as described above. Snooper decoder 2504 is a fully functional decoder (BG, P
(Including EM and CM), the interleaved words from all bitpack units can be accessed (either by separate buses as shown in FIG. 32, or through a common bus). Each time snooper decoder 2504 selects an interleaved word from a bitpack unit, that interleaved word is sent to the codestream. The decoder on the receiving side requests the data in the same order as the snoop decoder 2504, so the interleaved words are sent out in the proper order.

An encoder with a snooper decoder would be attractive for a half-duplex system, since it could also be used as a normal decoder. One advantage of the method of using a snooping decoder is that it is applicable to any deterministic decoder. Other solutions that do not rely on snoop decoders (see below)
Now we will use a simpler model of the decoder to reduce the hardware cost. In the case of a decoder that decodes multiple codewords in the same clock cycle, it is impossible to emulate the decoder with less hardware than the decoder itself, and it will be necessary to use a snooping decoder. As will be described later, for decoders that decode at most one codeword per cycle, there is a simpler model.

Another method of data reordering for a pipelined decoding system that decodes less than one codeword per clock cycle is the information needed to mimic the encoded data requirements of the decoder. However, it is only knowledge of the order of the codewords (thinking all codewords, not each codeword of each encoded data stream). If each codeword has a time stamp attached to it when it enters the runcount reordering unit, then the oldest timestamped interleaved bitpacked bit is next. It is an interleaved word that should be output to.

An example of an encoder rearrangement unit is shown in FIG. 33 as a block diagram. In FIG. 33, this rearrangement unit is the same as that shown in FIG. 32, except that the time stamp information is also received by each run count rearranging unit 2501a to 2501n. This time stamp information is also sent to the bit pack units 2501a to 2501n. Bitpack units 2502a-2502n provide the interleaved word to MUX 2503 and its associated time stamp to logic 2601. Logic 2601 provides control signals to MUX 2503 to select the interleaved words to output to the codestream.

In this embodiment, the snooper decoder provides a simple comparison to determine which of the bitpack units 2502a-2502n has the oldest time-stamped codeword (or part of the codeword). Has been replaced. Such a system is a MUX2503
To them, it looks like multiple time-stamped queues.
Logic 2601 only makes a selection between queues. Each run count rearranging unit 2501a to 2501n
The logic of is changed slightly (compared to the runcount reordering unit 801) to write a timestamp when the run starts. Each of the run count rearranging units 2501a to 2501n has a function of storing the time stamp in the code word memory. It is sufficient to store a timestamp with enough bits to enumerate all codewords in the encoded data stream,
A smaller number of bits may be used in some embodiments.

A brief description of the steps using multiple time stamped cues is shown in FIG. This description will be understood by those skilled in the art. These are the operations of the encoder. No simplification is made on the case where a run starts and ends with the same codeword. The operation is checked for each encoding of each symbol (although it is not necessary to check all in practice). 3 for interleaved
It is assumed to be 2 bits in size.

The operation of the decoder is similar, but it is not necessary to save the codeword in the queue. It is still necessary to save the codeword timestamp in the queue.

The time stamp function described above is used to store codeword order information. An equivalent way of embodying the same concept is to use a single queue, or merged queue, for all codewords. In a merged queue system, a single runcount reordering unit 2701 is utilized for all interleaved streams, as shown in FIG. The run count sorting unit 2701 is the bit pack unit 2502.
A codeword output, size output, and stream output are output to a to 2502n, and bit pack units 2502a to 2502a to
2502b outputs the interleaved word to the MUX 2503 and the position information to the logic 2702,
Logic 2702 signals the MUX 2503 to output the interleaved word as part of the codestream.

For any stream, the runcount rearrangement memory stores an interleaved stream ID for each codeword. Each interleaved stream has a unique head pointer. When a bitpack unit needs more data, the corresponding head pointer is utilized to retrieve as many codewords as needed to form one new interleaved word. This would require examining many codeword memory locations to determine which locations are part of the proper stream. Alternatively, it may be necessary to utilize a linked list made up of additional fields in the codeword memory.

Another method of interleaving the streams in the present invention utilizes a fixed stream allocation unified queue. This method uses a single tail pointer as it does for merged queues, so no timestamp is required. Also, as in the case described above, since a plurality of head pointers are used, no overhead occurs when outputting data from a certain stream. To do this, codewords are assigned to interleaved streams according to the following rules. That is, in the case of N streams, the codeword M is assigned to the stream M mod N. Note that this method allows the interleaved stream to accept codewords from any context or probability class. If the number of streams is a power of 2, M mod N can be calculated by discarding some of the upper bits. For example, suppose the codeword reordering memory is addressed with 12 bits and four interleaved streams are used. The tail pointer is 12 bits long and its least significant 2 bits reveal the codeword stream for the next codeword. Each of the four 10-bit head pointers is implicitly assigned to each of the four possible combinations of its least significant 2 bits. Both the tail pointer and the head pointer are incremented as ordinary binary counters.

In the decoder, the shifter has a register for storing the interleaved word. The shifter provides the properly aligned encoded data to the bit generator. When the bit generator uses some encoded data, it notifies the shifter. The shifter provides the data of the next interleaved stream by appropriately aligning the data. When the number of encoded data is N, the shifter may use N-1 clocks to shift out the used data, and possibly request another interleaved codeword before the interleaved stream is used again. Ah

<Decoder of the Present Invention> The present invention includes a decoder that supports a real-time encoder with limited permutation memory. In one embodiment, this decoder also has reduced memory requirements and complexity for maintaining run counts for each probability class rather than for each context bin.

<One Embodiment of the Decoding System of the Present Invention> FIG.
7 shows a block diagram of one embodiment of the decoding hardware system of the present invention. In FIG. 17, the decoding system 14
00 is a first-in / first-out (FIFO) structure 1401, a decoder 1402, a memory 1403, and a context model 1
It consists of 404. The decoder 1402 is composed of a plurality of decoders. The encoded data 1410 is connected to be received by the FIFO structure 1401. FIFO structure 1401
It is connected to supply the encoded data to the decoder 1402. The decoder 1402 is connected to the memory 1403 and the context model 1404. The context model 1404 is also connected to the memory 1403.
One output of the context model 1404 is the decoded data 1411.

In the decoding system 1400, the FIFO
The encoded data 1410 input into structure 1401 is ordered and interleaved. FIFO structure 1401 stores the data in the proper order. This stream is passed to the decoder 1402. The decoder 1402
The data of these streams is required in a serially and uniquely determined order. The order in which the decoder 1402 needs the encoded data is not simple, but it is not random. By ordering the codewords in this order at the encoder rather than at the decoder, the encoded data can be interleaved into a single stream. In other embodiments, encoded data 1410 may be a single stream of non-interleaved data,
The data for each context bin, each context class or each probability class is then added to the data stream. In this case, the FIFO structure 1410 is replaced by a storage area that is sent to the decoder after receiving the entire encoded data, so that the encoded data can be divided appropriately.

The encoded data 1410 is the FIFO structure 14
When received at 01, the context model 1404 determines the current context bin. In one embodiment, the context model 1404 determines the current context bin based on previous pixels and / or bits. Although not shown, a line buffer would be provided for the context model 1404. This line buffer provides the data or template that the context model 1404 needs to determine the current context bin. For example, if the context is based on pixel values in the neighborhood of the current pixel, a line buffer would be used to store the pixel values of those neighborhood pixels used to obtain a particular context.

In response to the context bin, decoding system 1400 retrieves the decoder state for the current context bin from memory 1403. In one embodiment, the decoder states include probability prediction module (PEM) states and bit generator states. The PEM state determines the code that should be used to decode the new codeword. The bit generator state keeps a record of the bits in the current run. Decoder state is provided from memory 1403 to decoder 1402 in response to the address provided by context model 1404. This address is the memory 14 that stores the information corresponding to the context bin.
Access 03 locations.

Once the decoder state for the current context bin is retrieved from memory 1403, decoding system 1400 determines the next uncompressed bit and processes the decoder state. The decoder 1402 then decodes the new codeword and / or updates the run count if necessary. PEM
States, if needed, as well as bit generator states
Will be updated. Decoder 1402 then writes the new decoder state to memory 1403.

FIG. 18 shows an embodiment of the decoder of the present invention. In FIG. 18, the decoder 1430 has a shift logic 14
31, bit generation logic 1432, "new k" logic 143
3, PEM update logic 1434, new codeword logic 1435,
PEM state-sign logic 1436, sign-mask logic 14
37, Code-Max RL / Mask / R3 Split Expansion Logic 1438, Decoding Logic 1439, Multiplexer 144
0, run count update logic 1441. Shift logic 1431 is connected to receive encoded data input 1443 as well as status input (from memory). The output of the shift logic 1431 is the bit generation logic 1432, "
New k "logic 1433 and PEM update logic 1434 are connected as inputs. Bit generation logic 1432 is also connected to receive state input 1442 and produces the decoded data output for the context model. The output generated by 1433 is connected to the input of sign-mask logic 1437. PEM update logic 1
434 is also connected to status input 1442 to generate status output (for memory). The status input 1442 is the new codeword logic 1435 and the PEM status-code logic 1436.
Is also connected to the input of. PEM state-sign logic 14
The output of 36 is connected to be received by expansion logic 1438. The output of the expansion logic 1438 is the decoding logic 143.
9 and run count update logic 1441.
The other input of decode logic 1439 is connected to the output of code-mask logic 1437. The output of decode logic 1439 is connected to one input of MUX 1330.
The other input of MUX 1440 is connected to status input 1442. The select input of MUX 1440 is connected to the output of new codeword logic 1435. The outputs of MUX 1440 and expansion logic 1438 are the sign-mask logic 1437.
Is connected to the two inputs of the runcount update logic 1441. Run count update logic 144
The output of 1 is included in the status output to the memory.

Shift logic 1431 shifts in the data from the encoded data stream. Based on the input encoded data, the bit generation logic 1432 generates decoded data and sends it to the context model. The new-k logic 1433 also uses the shift-in data and status inputs to generate a new-k value. In one embodiment, the new k logic 1433 uses the PEM state and the first bit of encoded data to generate the new k value. Based on this new k value, the sign-mask logic 143
7 produces the RLZ mask for the next codeword. The RLZ mask for this next codeword is sent to decoding logic 709 and then to runcount update logic 1441.

The PEM update logic 1434 updates the PEM state. In one embodiment, the PEM state is updated using the current state. The updated state is sent to the memory. New codeword logic 1434 determines if a new codeword is needed. PEM state-code logic 1436 utilizes state input 1442 to determine the code for decoding. This code is sent to the input of expansion logic 1438 for the generation of maximum run length, current mask and R3 split values. Decoding logic 1439 decodes the codeword and provides a run count output. The MUX 1440 is the decoding logic 14
39 output or status input 1442 to send to runcount update logic 1441. Run count update logic 1
441 updates the run count.

The decoding system 1400 of the present invention including the decoder 1430 operates in a pipelined manner. In one embodiment, the decoding system 1400 of the present invention performs context bin determination, probability prediction, codeword decoding, and run count-based bit generation all in a pipelined fashion. FIG. 2 shows an embodiment of the pipeline structure of the decoding system.
0 is shown. In FIG. 20, the pipelined decoding process of the present invention is represented by 6 stages from 1 to 6.

In the first stage, the current context bin is determined (1501). In the second stage, after the context bin determination, a memory read occurs (1502) and the current decoder state for the context bin is retrieved from memory. As mentioned above, the decoder state includes the EMS state and the bit generator state.

In the third stage of the pipelined decoding process of the present invention, one decompressed bit is generated (1503). This makes the bits available to the context bin. Two different operations are performed within the third stage. The PEM state is converted to a certain code type (1504), and it is determined whether a new codeword should be decoded (1505).

During the fourth stage, the decoding system is set to 1
Process one codeword and / or update run count (1506). The processing of codewords and updating of run counts involves several sub-operations. For example, the codeword is decoded to determine the next runcount, or the runcount is updated for the current codeword (150).
6). When decoding a new codeword, further coded data is retrieved from the input FIFO if necessary. Fourth
Another side action that occurs at the stage is the update of the PEM state (1507). Finally, in the fifth stage of the decoding pipeline, when the runcount for the current codeword is 0, what run length 0 codeword (described below) is the next code using the new PEM state. A determination is made (1508). During the fifth stage of the inventive decoding pipeline, the updated decoder state of the PEM state is written to memory (1509) and the shift operation for the next codeword begins (1510). In the sixth stage, the shift operation to the next code word is completed (151
0).

The pipelined decoding operation of the present invention actually starts with determining whether to start the decoding process. This decision is made based on whether there is enough data to provide to the decoder of the present invention. If not enough data is available in the FIFO, the decoding system will stop. In another case, the decoding system may stall when outputting the entire output data of the decoder to the peripheral device that cannot receive during the output. For example, when the decoder is outputting to a video display interface and associated video circuitry and the video is too slow, the decoder must stop to catch up.

When it is determined to start the decoding process,
The current context bin is determined by the context model. In the present invention, this current context bin is determined by examining previous data. This previous data may be stored in the run buffer and may consist of current line and / or previous line data. Using the template for the previous data, the bits out of the line buffer (s) are designed such that the context bin for the current data is selected depending on whether the previous data being examined matches the template. It may be. These line buffers may include bit shift registers. One template may be used for each bitplane of an n-bit image.

In one embodiment, the context bin is selected by outputting an address to memory during the next pipeline stage. This address may include a predetermined number of bits to distinguish the bit planes, for example 3 bits. These 3 bits may be used to identify the bit position of the pixel data. The template used to determine the context is also
It may be expressed as part of that address. The bits for identifying the bit planes and the bits for representing the template may be combined to create the address of a particular location in memory that stores the state information for the context bin defined by those bits. For example, a 13-bit address may be generated using 3 bits to determine the bit position of a particular pixel location and the previous 10 bits of the same location of each previous pixel in the template.

Using the address generated by the context model, the memory (for example, RAM) is accessed and the state information is obtained. This state includes the PEM state. P
The EM state contains the current probability estimate. Since the same code is used in two or more states, the PEM state does not include a probability class or code designation, but includes an index into the table as shown in FIG. Further, when the table as shown in FIG. 8 is used, the PEM state is used as means for identifying whether the current PEM state is on the positive side or the negative side of the table.
The highest probability symbol (MPS) is also provided. The bit generation status may include a count value and an indication of the presence or absence of LPS. In one embodiment, the MPS value for the current run is also included for decoding the next codeword. In the present invention, to reduce the memory space required for the run counter,
The bit generation state is stored in memory. If the cost of the counter space for each context in the system is low, it is not necessary to store the bit generation state in memory.

At the end of the fourth stage, the new bit generation state and PEM state are written to memory. Also, in the fifth stage, the encoded data stream is shifted to the next codeword. This shift operation is completed in the sixth stage.

FIG. 19 is a block diagram of an embodiment of the FIFO structure 1401 of the present invention, which shows buffering of interleaved words when there are two decoders. It should be noted that any number of decoders can be supported by the teaching of the present invention. As shown, the input data and FIFO are wide enough to hold two interleaved words. The FIFO structure 1401 includes a FIFO 1460,
Registers 1461, 1462, MUX1463, 146
4 and control block 1465. Two input codewords are connected as an input interleaved word. FI
The output of FO1460 is connected to the inputs of registers 1461 and 1462. The input of MUX1463 is register 14
It is connected to the outputs of 61 and 1462. Control block 14
65 is a FIFO 1460, registers 1461, 146
2 and MUXs 1463 and 1464 are connected to supply control signals. The output data (output data 1, 2) supplied to the two decoders are interleaved words. Each decoder uses a request signal to indicate that the current word has been used and a new word is needed next. The request signal from this decoder is connected to the input of control block 1465. The control block 1465 also outputs a FIFO request signal to request the next data from the memory.

First, the FIFO 1460 and register 1
461 and 1462 are filled with data and the valid flip-flop in control block 1465 is set. Each time a request is made, the control block 1465 is shown in FIG.
Data is supplied according to the logic shown in Table 16 of FIG.

FIG. 21 shows another conceptual diagram of the decoder of the present invention. In FIG. 21, variable length (encoded) data is input to the decoder. The decoder outputs fixed length (decoded) data. This output is also returned as delayed feedback and received as an input to the decoder. In the decoder of the present invention, the variable length shift used for decoding is based on the decoded data obtained with some delay. This feedback delay does not degrade throughput in delay-tolerant decoders.

The input variable length data is divided into fixed length interleaved words as described with reference to FIG.
The decoder handles fixed length words as described later in FIG. This decoder and delay combination models a pipelined decoder as described in connection with FIGS. 20 and 39, or a plurality of parallel decoders as described in connection with FIGS. 2-5. To do. Thus, the present invention provides a delay tolerant decoder. The delay tolerant decoder of the present invention is capable of parallel processing of variable length data.

Conventional decoders (eg Huffman decoders) are not delay tolerant. The information determined by decoding all previous codewords is needed to perform the variable length shift required to decode the next codeword. On the other hand, the invention provides a delay tolerant decoder.

Shift Operations in Decoding Systems The decoder of the present invention comprises shift logic that shifts to the appropriate bit generator for decoding interleaved words. The shifter (shift logic) of the present invention may be used for any kind of "contextual" or "probability-based" parallelization (para).
llelism) is not required. Stream codeword M into stream M m
Let us assume an encoder assigned to od N (M% N in C language) (N is the number of streams). In the present invention, the encoded data of the current stream is provided until a codeword is requested. Only then is the data switched to the next stream.

FIG. 22 shows an embodiment of the shifter for the decoder of the present invention. The shifter 1600 is designed for four data streams. This devotes four clock cycles to each shift operation. The interleaved word is 16 bits and the longest codeword is 13 bits. In FIG. 22,
Shifter 1600 has four registers 1601 connected to receive input from interleaved encoded data.
˜1604. Each output of the registers 1601-1604 is connected as an input to the MUX 1605. The output of MUX 1605 is connected to the input of barrel shifter 1606. Barrel shifter 160
The output of 6 is the register 1607, the MUX and the register 1
608-1610, and size unit 16
It is connected to 11 inputs. Size unit 1611
The output of is connected to the accumulator 1612. The output of the accumulator 1612 is fed back to the barrel shifter 1606. Output of register 1607 is MU
It is connected to the X and register 1608 as one input. The output of MUX and register 1608 is connected as one input to MUX and register 1609.
The output of MUX and register 1609 is connected as one input to MUX and register 1610. MUX
And the output of the register 1610 is the aligned encoded data. In one embodiment, registers 1601
1604 is a 16-bit register, barrel shifter 1606 is a 32-bit-13-bit barrel shifter, and accumulator 1612 is a 4-bit accumulator.

Registers 1601 to 1604 are FIFO registers.
Accepts more 16-bit words and barrels them 1
Input to 606. At least 32 bits of undecoded data are always provided to the barrel shifter 1606. The four registers 1601-1604 are initially 16-bit words,
Two-word coded data is initialized. This ensures that at least one new codeword is always available for each stream.

For R-code, codeword size unit 1
611 determines whether there is a "0" codeword or a "1N" codeword, and if it is a "1N" codeword, determines how many bits after "1" is the part of the current codeword. To do. Size units that provide the same functionality have been described in connection with FIG. The determination of codeword size for other codes is well known in the art.

The shifter 1600 has four registers 160.
It has a FIFO consisting of 6 to 1610, and 3 of these registers 1608 to 1610 have their inputs multiplexed (multiplexed).
have been xed). Since each register of registers 1607 to 1610 holds at least one codeword, the width of these registers and multiplexer is 13 bits corresponding to the longest codeword. Each register 1607-16
10 also has an associated control flip-flop (not shown to avoid clutter). This control flip-flop indicates whether the register holds a codeword or is waiting for barrel shifter 1606 to provide a codeword.

This FIFO is never empty. Only one codeword can be handled per clock cycle, and one codeword can be shifted per clock cycle. Since the system starts four codewords ahead, the delay due to the shift operation is compensated. As each codeword is shifted into the aligned encoded data output, the other codewords in registers 1607-1610 are shifted down. When the code words remaining in the FIFO are stored in the register 1610, the barrel shifter 16
06 is MUX because it fills registers 1607 to 1609.
The code word is read from the registers 1601 to 1604 via 1605. It should be noted that the FIFO may be designed to populate the register 1607 with data as soon as the codeword of the register 1607 is shifted into the register 1608.

The barrel shifter 1606, the codeword size unit 1611 and the accumulator 1612 perform variable length shift processing. The accumulator 1612 has a total of four registers, one for each data stream, which holds an aligned version of the current codeword for each data stream. The accumulator 1612 is a 4-bit accumulator and is used to control the barrel shifter 1606. The value of the accumulator 1612 is the codeword size unit 1
It is incremented by the input value from 611. Accumulator 16
When 12 overflows (for example, every time the shift count becomes 6 or more), the registers 1601-1604
Is clocked and shifted. Every 16-bit shift requires a new 32-bit word from the FIFO. The input of the accumulator 1611 is the codeword size,
This is the current code and the first 1 or 2 of the current codeword.
It depends on the bit. Note that in some embodiments, the decoding operation can be started only after the registers 1601 to 1604 have initialized the encoded data.

When a codeword is requested by the system,
The registers in the FIFO are clocked and the codeword is sent to the output. When the barrel shifter 1606 can issue a new codeword, it is input to the first free register in the FIFO.

In this embodiment, the next codeword signal is received from the bit generator before the stream switching is decided.

When it is not guaranteed that the next codeword signal from this bit generator will be received before the stream switching decision, a look ahead system as shown in FIG. 23 can be used. In FIG. 23, a shifter 1620 utilizing look ahead is shown as a block diagram. The shifter 1620 is a shifter 1 that outputs the current encoded data and the next encoded data.
Has 600. The current encoded data is connected to the inputs of codeword preprocessing logic unit 1621 and codeword processing logic unit 1624. The next encoded data is connected to the input of the codeword preprocessing logic unit 1622. The output of both preprocessing logic units 1621, 1622 is M
Connected to the input of UX1623. The output of MUX 1623 is connected to another input of codeword processing logic unit 1624.

The logic for handling codewords is divided into two parts: codeword preprocessing logic and codeword processing logic. Two identical pipelined pretreatment units 162
The interleaved stream can be shifted after the operation of 1, 1622. One of the pre-processing units 1621, 1622 will generate the appropriate information if the stream is switched, and the other one if the stream is not switched. When the streams are switched, the output of the appropriate codeword preprocessing is sent by MUX 1623 to codeword processing logic 1624, which
24 completes the operation with the appropriate codeword.

Off-Chip Memory and Context Model In one embodiment, it may be desirable to use multiple chips for the external memory or external context model. In such an embodiment, when multiple integrated circuits are used, it is desirable to reduce the delay between generating a bit and making it available to the context model.

FIG. 24 shows a block diagram of an embodiment of a system having an external context model chip 1701 and a decoder chip 1702 having a memory for each context. Note that only the units within the decoder chip that are relevant to the context model are shown. That is, it will be apparent to those skilled in the art that the decoder chip 1702 includes bit generation, probability prediction, and so on. In FIG. 24, the decoder chip 1702 has a 0th-order context model 170.
3, context models 1704, 1705, selection logic 1706, memory control 1707 and memory 17.
Including 08. The outputs produced by the 0th-order context model 1703 and the context models 1704, 1705 are connected to the inputs of the selection logic 1706. Another input of the selection logic 1706 is the external context model chip 17
01 output. The output of select logic 1706 is connected to one input of memory 1708. Memory 170
The other input of 8 is the memory control 1708
The output of is connected.

The selection logic 1706 may include one external context model or one internal context model (eg,
The use of the 0th-order context model 1703, the context model 1704, and the context model 1705) is permitted. The selection logic 1706 allows the use of the internal 0th order context model 1703 when using the external context model chip 1701. Zero-order context model 170
3 provides one or more bits, while
External context model chip 1701 provides the remaining bits. For example, the immediately previous bit will be fed back and retrieved from the 0th order context model 1703, while the previous bits are due to the external context model chip 1701. Thus, time sensitive information remains on the chip. This eliminates off-chip communication delays for newly generated bits.

FIG. 25 shows an external context model chip 1801, an external memory 1803 and a decoder chip 180.
2 is a block diagram of a system having 2. In FIG. 25, some memory address lines are driven by the external context model chip 1801 and the remaining memory address lines are driven by the “0th order” context model in the decoder chip 1802. That is, the context from the immediately preceding decoding cycle is driven by the 0th order context model. This allows the decoder chip to provide context information from the immediately previous decoding cycle with minimal communication delay. Communication delay is allowed because the context model chip 1801 uses only the previously decoded bits and goes beyond the rest of its context information. In many cases, the context information from the immediately preceding decoding cycle is the 0th-order Markov state, and the context information from before it is the higher-order Markov state.
The embodiment shown in FIG. 25 eliminates the communication delay that cannot be avoided when the 0th-order model is realized in the external context model chip 1801. However, there will nevertheless be a delay in the context bin decision for the generated bits due to the decoder chip 1802 and the memory 1803.

It should be noted that other memory architectures may be used. For example, a system in which the context model and the memory are on one chip and the decoder is on another chip may be adopted. Also, some systems may include decoder chips with internal memory used for some contexts and external memory for other contexts.

<Bit Generator Utilizing Memory>
FIG. 26 shows a decoder with a pipelined bit generator that utilizes memory. In FIG. 26, the decoder 1900 includes a context model 1901 and a memory 190.
2, PEM state-consisting of a code block 1903, a pipelined bit generator 1905, a memory 1804 and a shifter 1906. The input of the context model 1901 is the decoded data from the pipelined bitstream generator 1905. The input of shifter 1906 is connected to receive encoded data. The output of the context model 1901 is connected to the input of the memory 1902. The output of memory 1902 is connected to the PEM state-code block 1903. The output of the PEM state-code block 1903 and the aligned coded data output of the shifter 1906 are connected to the input of the bit generator 1905. The memory 1904 is also connected to the bit generator 1905 by a bidirectional bus. The output of the bit generator 1905 is the decoded data.

The context model 1901 outputs one context bin according to the encoded data of its input. Memory 1 using this context bin as an address
902 is accessed and one stochastic state is obtained. The probability state is received by the PEM state-code module 1903, and the PEM state-code module 1903 generates a probability class according to the probability state. The memory 1904 is accessed with this probability class as an address,
A run count is obtained. This run count is received by the bit generator 1905 to generate decoded data.

In one embodiment, the memory 1902 has 1024
It consists of x7-bit memory (1024 is the number of different contexts) and memory 1904 is 25x14-bit memory (25 is the number of different run counts).

Since bit generator states (runcounts, etc.) are associated with probability classes and not context bins, there is an additional pipeline delay before the bits are available to the context model. Multiple clock cycles (bit generator state memory revisit (revi
Because of this, multiple bit generator states will be used for each probability class. For example, if the pipeline is 6 clock cycles, the bit generator memory will have 6 entries per probability class. A counter is used to select the appropriate memory location. Even with multiple entries per probability class, the size of this memory will usually be less than the number of contexts. This memory may be implemented with multiple banks of SRAM or a multi-ported register file.

Since one runcount may be associated with multiple contexts, in some embodiments the probability prediction state of one or more contexts must be upgraded. In one embodiment, the PEM state of the context that ends the run is updated.

Only after the run count has been read, modified and written can it be read again, and the run count can be reused as soon as the modification is complete.

FIG. 39 is a timing chart of the decoding operation in the embodiment of the present invention. FIG. 39 shows a 3-cycle decoding operation. Signal names are listed on the left side of the timing diagram. The signal is valid for a certain cycle period by indicating a bar during that cycle (or part thereof). In some cases,
The unit or logic responsible for generating or supplying a valid signal is shown in the vicinity of the valid signal, surrounded by a dotted line. At times, examples of specific elements and units disclosed herein are also presented. It should be noted that some of the signals may extend into the next cycle, but only during the period represented as extending into that other cycle.
It means that the signal is valid. Also, certain signals are represented as if they were intermittently valid for more than one cycle. An example of such a signal is a temporary runcount.
Signal, which is valid at the end of the second cycle and also valid during the third cycle. This indicates that this signal was simply held in a register at the end of the cycle. A dependency list is also shown in Table 17 of FIG. 65, which reveals the dependency relationships that the signal has been defined to be valid from the same clock cycle or the previous clock cycle to the present time.

Implicit Signaling In some embodiments, the decoder must mimic the finite reordering buffer of the encoder. In one embodiment, this simulation is an implicit cue (im
Explicit signaling).

As described above with respect to the encoder, at the beginning of a codeword in the encoder, in the appropriate buffer, in the order in which the codewords are output to the channel, the space for that codeword. Is secured. When the last space in a buffer is reserved for a new codeword, some codewords may or may not be completely fixed.
It is put out in a compressed bitstream.

When an incomplete codeword must be completed, a short codeword that correctly represents the previously received symbol may be used. For example, in the case of an R-code system, when it is necessary to complete the codewords for 100 consecutive MPSs in one run code having the longest run length of 128, the codewords for 128 MPSs are used. You may This is because the codeword correctly represents the first 100 MPSs.

Alternatively, 100 followed by one LPS
Codewords representing MPSs may be used. When this codeword is complete, it may be removed from the reordering buffer and added to the codestream. This also allows the previously completed codeword to be output to the codestream. Encoding can continue if one codeword is removed from the full buffer by forcing one incomplete codeword to complete. When one buffer is still full, the next codeword must be completed again and added to the codestream. This process continues until the buffer that was full is no longer full. The decoder may mimic the encoder for implicit signaling using one counter for each bit generator state information memory location.

In one embodiment, each run counter (each probability class in this example) has a counter of the same size (eg 6 bits) as the head or tail counter in the encoder. Each time a new run is started (a new codeword is fetched), the corresponding counter is loaded with the size of the codeword memory. Every time one run is started (one codeword is taken), all counters are decremented. When any counter becomes 0, the corresponding run count is cleared (and the LPS present flag is cleared).

<Option for Finite Memory Cue Method> According to the real-time decoding of the present invention, the decoder is required to process the runs of the MPS that are not followed by the LPS and are not the maximum run length. This is what happens
The encoder has begun to run MPS, but it is not possible to wait until the run is complete due to lack of finite reordering memory. This situation must be signaled to the decoder since it requires a new codeword to be decoded the next time this context bin is used. Three ways to modify the decoder are described below.

The run count of a context bin or probability class that is forced out when the buffer is full is
Must be reset. In order to achieve this efficiently, it is effective to store the context bin or probability class in the codeword memory. The memory used to store codewords is sharable because this is only needed for runs that do not yet have an associated codeword. Note that on some systems, instead of forcing an incomplete codeword when the buffer is full,
Bits can be pushed into the context / probability class of pending codewords in the buffer. The decoder detects this and handles the corresponding (wrong) context bin or probability class.

In-stream signalin
g) uses codewords to signal the decoder. In one embodiment, the definition of the R2 (k), R3 (k) code is modified to include a run of non-maximum length MPS that is not followed by an LPS. This can be realized by adding 1 bit to the code word generated with the lowest probability. This gives a uniquely decodable prefix for non-maximum length run counts. The table 18 of FIG. 66 shows the replacement of the R2 (2) code capable of in-stream signaling. The disadvantage of this method is that the R-code decoding logic has to be changed and the cost of compression is incurred each time the least probable codeword occurs.

In one embodiment, the decoder uses a time stamp to perform implicit signaling. The current "time" is monitored by incrementing the counter each time one codeword is requested. Also, each time a codeword begins, the current "time" is saved in the memory associated with that codeword. After a codeword is first used, the current stored "time" value plus the size of the reordering buffer in the encoder is now "
Compared with the "time". If the current "time" is greater, one new code is required by the implicit signal. Thus, the limited permutation memory in the encoder In one embodiment, enough bits are used for the "time" value to enumerate all codewords.

In order to reduce the required memory, the number of bits for the time stamp can be suppressed to the minimum. If the time value is reused because the time stamp uses fewer bits, care must be taken to ensure that all old time stamps are recorded before the counter starts reusing the time. The larger bit number of the queue address bit and the bit generator state memory address bit is N. A time stamp of N + 1 bits can be used. The bit generator state memory must support multiple accesses, perhaps two read and two write accesses per bit decoded. A counter is used to cycle through the bit generator state memory, one for every one bit decoded.
Increment times. Memory locations that are too old are cleared so that new codewords can be retrieved for future use. This ensures that all time stamps are checked before the time value is reused.

When the bit generator state memory is smaller than the queue, the counting (time stamp counter) rate and the required memory bandwidth can be reduced. This is because each time stamp (one per bit generator state memory) must be checked once every cycle required to use the entire queue. Also, storing the time stamps in a separate memory may reduce the required memory bandwidth. In a system that uses a "0" codeword for partial runs,
There is no need to check the time stamp for the 1N "codeword. In systems that use the" 1N "codeword for partial runs, the time stamp must be checked only before the LPS is generated.

In one embodiment, implicit cues are implemented using one queue during the decoding period. This method may be useful in half-duplex systems where coding hardware is available during decoding. The operation of this cue is almost the same as the encoding period. When a new codeword is requested, its index is queued and marked invalid. When the data for one codeword is finished, the cue entry is marked valid. When data is removed from the queue to make room for a new codeword, if the data is marked invalid, the bit generator state information from that index is cleared. This clear operation may require the bit generator state memory to be able to support extra write operations.

On the other hand, explicit signaling
Reports buffer overflow as compressed data. One example has an auxiliary context bin,
This auxiliary context bin is used once for each standard context bin decoding or once for each decoded codeword. The bits decoded from the auxiliary context bins indicate if a condition requiring a new codeword occurs and the new codeword must be decoded in the corresponding standard context bin. In this case, the codewords of this special context must be properly reordered. Using this ancillary context is needed for the ancillary context reordering, as utilization is a function known to the reordering unit (typically it is used once for each codeword). Memory can be implicitly limited or simulated. Also, the codes that can be allowed for this auxiliary context can be limited.

Implicit signaling mimics the encoder's limited buffer to generate a signal at decoding that indicates that a new codeword must be decoded. In one embodiment, one timestamp is maintained for each context. In one embodiment, the encoder's finite size reordering buffer is directly simulated. In a half-duplex system, the permutation circuit of the encoder will be available during the decoding period, so that the permutation circuit will be used to generate its signal for the decoder.

To be exact, the method for realizing the implicit signal method is
It depends on the specific way the encoder recognizes and handles the buffer full condition. In the case of a system using a merged queue with a fixed allocation, it is possible to select a plurality of types of contents meaning "buffer full" by using a plurality of head pointers. Given a design as an encoder, an appropriate model can be designed.

[0225] The operation of the encoder and the decoder,
A model for a fixed-stream-allocation-probabilistic parallel merging queue is described below. In this example, assume that the reordering buffer has 256 locations, four interleaved streams are used, and each interleaved word is 16 bits. 2 in the buffer
When there are 56 entries, the 257th codeword cannot be queued until one entry is output to the bit-packing portion (eg, bit-pack unit). If necessary, you may make an entry before that.

In some systems, removing the first entry requires removing enough bits to complete an entire interleaved word. Therefore,
If a 1-bit codeword is possible, in the case of a 16-bit interleaved word, to remove codeword 0, codewords 4, 8, 12, ..., 52, 56, 60 must also be removed. It will not happen. To ensure that all of these buffer entries have valid entries, you can force one entry until the memory is full, 192 locations away from the location where the new codeword is placed. , At address 64 (256-16 × 4 = 19
2).

The decoder has one counter for each probability. The counter is loaded with 192 when a codeword is used to start a run. Whenever one new codeword is used, every counter is decremented. No matter which counter reaches 0, the run length for that probability is 0
Is set to (and the LPS presence flag is cleared).

It may be convenient to use a plurality of RAM banks (multi-port memory, simulations using high speed memory, etc.), one bank for each encoded data stream. In this way, all bitpack units can receive data at the same time so that reading multiple codewords for one stream does not interfere with reading by another stream.

In other systems, multiple bit pack units must arbitrate for one memory based on the order in which the codewords are stored in the buffer.
In such a system, removing one entry from the buffer may not complete an interleaved word. Each bit pack unit is typically 1
Receives one interleaved part in turn. Each bit pack unit receives at least as many bits as the shortest codeword length (eg 1 bit) and at most as many bits as the longest codeword length (eg 13 bits). Interleaved words cannot be sent until they are complete, and must be sent in the order of initialization. In this example, one bitpack unit would have to buffer 13 interleaved words. The thirteen is the maximum number of interleaved words that can be completed with the maximum length codeword when another stream has one pending interleaved word that is receiving the minimum length codeword.

A system in which every codeword requires two writes and one read of the memory is less desirable to implement in hardware than a system that performs two writes and two reads. It may be.
If this is required in the 4-stream example system, bitpack unit 1 and bitpack unit 2 share one memory read cycle and bitpack unit 1 and bitpack unit 3 the other memory read cycle. Will be shared (or any other combination). This may not reduce the required buffer size, but it will increase the transfer rate to the bitpack unit. This will allow the bitpack unit to make better use of the capacity of the encoded data channel.

<System with fixed memory size> 1
One advantage of a system with multiple bit generator states per probability class is that it can support lossy coding when a fixed size memory overflows. This may be advantageous for image compression to the frame buffer and other applications that store only a certain amount of data.

In a system with fixed size memory, multiple bit generator states for each probability are each assigned to a portion of the data. For example, for 8-bit data, each of the eight states could be assigned to one particular bitplane. In this case also, one shifter is assigned to each piece of data, rather than the shifters providing the next codeword in sequence. Note that the data does not have to be divided into bit planes. Also,
In the encoder, no interleaving is done and each piece of data is simply bit packed. Memory is assigned to each piece of data.

A memory management method for encoded data for a system that stores all data in a fixed size memory and a system that transmits data in a channel having an allowable maximum bandwidth will be described. In either of these systems, a gradual transition to a lossy system is desired. Is it possible to store less important data when sufficient storage space or bandwidth is not available,
Alternatively, different data streams are used for different weights of data so that they cannot be transferred.

When the memory is used, the encoded data is stored so that the encoded data can be accessed so that the less important data stream can be discarded without impairing the ability to decode the important data stream. There must be. Since the encoded data is of variable length, dynamic memory allocation can be used. FIG. 38 shows an example of dynamic memory allocation for three encoded data streams. The register file 3100 (or another storage area) holds not only the pointer for each stream but also another pointer for indicating the next free memory location. Memory 3101 is divided into fixed size pages.

Initially, each pointer assigned to one stream points to the beginning of one page of memory, and the empty pointer points to the next available page of memory. The encoded data for a particular stream is stored in a memory location addressed by a corresponding pointer. This pointer is then incremented to point to the next memory location.

When the pointer reaches the maximum value for the current page, the following operations are performed. The current page is stored at the first address (stored in the empty pointer) of the next empty page. (A portion of the encoded data memory or another memory or register file may be used.) The current pointer is set to point to the next free page. Free pointers are incremented. These operations allocate a new page of memory to a particular stream and link it so that the allocation order can be determined during decoding.

When all pages of memory are in use and there is more data from one stream that is more busy than the least busy data in memory, then one of three actions is taken. Will. In all three cases, the memory allocated to the least important data stream is reallocated to the more important data stream and no more data from the least important data stream is stored.

One is that the page currently being used by the lowest-duty stream is simply assigned to the higher-duty data. Since the most common entropy coders utilize internal state information, the lowest severity data previously stored on the page is lost.

On the other hand, the page currently used by the lowest-usage data is simply assigned to the higher-usage data. However, unlike the previous case,
The pointer is set so as to point to the end of the page, and the corresponding pointer is decremented as more highly important data is written to the page. This has the advantage that if the heavy duty data stream does not require the entire page, the lowest weight data at the beginning of the page is saved.

[0240] Third, instead of reallocating the current page of the lowest-usage data, any page of the lowest-usage data is reallocated. This requires the encoded data to be encoded independently for every page, which can reduce the compression rate achieved.
In addition, it is necessary to identify the uncoded data corresponding to the beginning of all pages. Since any page of the least important data can be discarded, an increase in flexibility in gradual transition to lossy coding can be obtained.

This third option would be particularly attractive for systems that achieve constant compression over multiple regions of the image. A specified number of memory pages can be allocated to an area of the image. Whether less important data is stored can be determined by the compression ratio achieved in a particular area. (The memory allocated to an area will not be used if less memory is needed for lossless compression.) A constant compression ratio for one area of the image. By accomplishing this, random access to the image area can be supported.

The function of writing data from both ends of each page can be used to improve the utilization rate of the entire memory available in the system. When all pages have been allocated, a page with sufficient free space at one end can be allocated to be used from that end. The ability to utilize both ends of the page must be weighed against the cost of managing locations where two types of data collide. (This is the case if one data type is not important and may simply be overwritten.) Now consider a system in which data is transmitted in channels rather than stored in memory. Fixed size memory pages are used, but only one page per stream is needed. (Alternatively, if ping-pong operation is required such that one page can be read and output while the other page is being written to perform buffering for the channel, then two pages are required for each stream. When a page of memory is full, that page is transmitted on the channel,
The memory location is reusable immediately after transmission of the page. In some applications, the page size of memory can be the size of the data packet used by the channel, or many times the packet size.

In a certain type of communication system, for example, ATM (asynchronous transfer mode), a packet can be given priority. ATM has two priority levels, primary and secondary. Secondary packets are transmitted only when sufficient bandwidth is available. Thresholds can be used to determine which streams are primary and which are secondary. The other method is to set a threshold to prevent the transmission of streams that are less important than a certain threshold.
It will be used in the encoder.

<Bit Generator Separated for Each Code> FIG. 27 is a block diagram of a system having a bit generator separated for each code. 27, the decoding system 2000 includes a context model 2001, a memory 2002, a PEM state-code block 2003, a decoder 2004, and bit generators 2005a to 20a.
It consists of 05n and shifter 2006. The output of the context model 2001 is connected to the input of the memory 2002.
The output of the memory 2002 is the PEM state-code block 20.
03 input. PEM state-code block 2
The output of 003 is connected to the input of the decoder 2004.
The output of the decoder 2004 is the bit generator 200.
Connected as enables for 5a-2005n. Bit generators 2005a-2005n are also connected to receive the encoded data output of shifter 2006.

Context model 2001, memory 20
02 and PEM state-code block 2003 is shown in FIG.
Works the same as the corresponding part inside. The context model 2001 generates a context bin. Memory 200
2 outputs the probability state based on the context bin. This stochastic state is received in the PEM state-code block 2003, which produces one probability class for each stochastic state. Decoder 2004 decodes the probability class and enables one of bit generators 2005a-2005n. (Note that the decoder 2004 is M: 2 ^M similar to the well-known 74 × 138 3: 8 decoder.
This is a decoder circuit. Not an entropy decoder. Note that there is a separate bit generator for each code, so some bit generators may use codes other than the R-code. In particular, codes for probabilities near 60% may be used to better cover the probability space between R2 (0) and R2 (1). For example,
Table 19 in FIG. 67 shows such a code.

If necessary to achieve the required speed,
Pre-decoding of 1 bit or more may be performed to ensure that the decoded data can be used quickly. In one embodiment,
Both the decoding of codewords and the run counting for long codes are split so that the long run count may not be updated every clock cycle.

The bit generator for the R2 (0) code is uncomplicated. One codeword is required every time one bit is required. The generated bits are only codewords (ORed with MPS).

Codes for short run lengths, eg R
2 (1), R3 (1), R2 (2), R3 (2) are treated as described below. All the bits in one codeword are decoded and stored in a state machine consisting of a small counter (1, 2 or 3 bits) and LPS with bits. This counter and L
The PS present bit works like an R-code decoder.

For long codes such as R2 (k) and R3 (k) (k> 2), the bit generator is split into two units as shown in FIG. In FIG. 28,
The structure of a bit generator for R2 (k) (k> 2) having a short run unit 2101 and a long run unit 2102 is shown. Note that although this structure is for the R2 (k> 2) code, the operation is similar for the R3 (k> 2) code (and this will be apparent to those skilled in the art).

The short run unit 2101 receives the enable signal and the code word [0..2] as inputs to the bit generator, and the long run unit 2102 receives an "all 1" signal and a "count 0" signal (count is 0). Connected to receive). In response to these inputs, the short run unit 2101 indicates the decoded bits and a new code word next.
and t signal display are output. The short run unit 2101 also generates a count enable signal, a count load signal and a count max signal and sends them to the long run unit 2102. The long run unit 2102 also uses the codewords [k ...
3] is received as an input to the bit generator.

The short run unit 2101 handles runs up to length 4 and is similar to the R2 (2) bit generator. In one embodiment, the short run unit 2101 uses R2 (k>
2) It is the same for all symbols. Long run unit 210
The purpose of 2 is to determine when the last 1-4 bits of the run should be output. Long run unit 2102
Has a counter whose size varies with inputs, AND logic, and k.

An example of a long run (count) unit 2102 is shown in FIG. In FIG. 29, the long run unit 2102 has an AND logic 2201. This AND logic 2201 is connected to receive the codeword [k ... 3], and outputs an "all 1" signal of logic 1 when all the bits in the codeword are 1
The current codeword is a 1N codeword and the run count is 4
Indicates that it is less than. NOT logic 2202 is also connected to receive and invert the codeword.
The output of NOT logic 2202 is connected to one input of bit counter 2203. The bit counter 2203 is also connected to receive the count enable signal, the count load signal and the count max signal. The bit counter 2203 generates a count 0 signal according to those inputs.

In one embodiment, the bit counter 2203 is a k-2 bit counter, which provides a long run count
It decomposes into a run of 4 MPSs, and possibly some excess. Count enable signal is 4 MPS
Is output, indicating that the counter should be decremented. The count load signal is used when decoding "1N" codewords and loads the counter with the complement of codeword bits k-3. The count max signal is "
Used when decoding a 0 "codeword, it loads the counter with its maximum value. The count 0 signal indicates that the counter is zero.

An example of a short run (count) unit 2101 is shown in FIG. In FIG. 30, the short run (count) unit 2101 includes a control module 2304, a 2-bit counter (MPS counter) 23.
02 and 3-bit counter (R2 (2) counter and LP
S) 2303. The control module 2301 receives the enable signal, the code word "0 ... 2", the all 1 signal and the count 0 signal from the long run (count) unit. The 2-bit counter 2302 is used to count the 4-bit MPS runs that are part of the long run. The R2 (2) counter and LPS bits (3 bits total) 2303 are used to generate 1 to 4 bits at the end of the run. The enable input directs the bit output to output one bit. The count 0 input indicates that a run of 4 MPS will be output when not asserted. Whenever the MPS counter 2302 reaches 0, the counter enable output is asserted. When count 0 input is asserted, R2 (2)
Either a counter and LPS 2303 is used, or a new codeword is decoded and the next output is asserted.

The operation performed when the new codeword is decoded is determined by the codeword input. Input is "
If it is a 0 "codeword, the MPS counter 2302 is used and the count max output is asserted. In the case of a" 1N "codeword, the first 3 bits of that codeword are R2 (2).
The counter and LPS 2303 are loaded and the count load output is asserted. The R2 (2) counter and LPS 2303 are used to generate bits when the All-1 input is asserted, otherwise the MPS Counter 2302 is used until the Count0 input is asserted.

Looking at the system as a whole, the number of codes must be small for the system to operate well,
Normally, it should be less than 25. The size of the multiplexer required for bit output and codeword output,
The size of the decoder that enables a particular bit generator must be limited for high speed operation.
Also, the fanout of codewords from the shifter should not be too large for high speed operation.

The bit generator separated for each code word is capable of pipeline processing. If all codewords result in more than one bit, the processing of codewords could be pipelined in two-cycle units rather than one cycle. That way, if the bit generator were the speed limiting part of the system, the speed of the decoder would double. One way to accomplish this is to add a runlength 0 codeword (a codeword that simply represents one LPS) followed by one bit, the next undecoded bit.
These are called RN (k) +1 codes, for example, and will always encode more than one bit. Note that the R2 (0) code, and perhaps some of the other short codewords, need not be pipelined for speed.

The separate bit generator lends itself well to use in implicit signaling. The implicit signaling method for encoding using finite memory can be achieved by the following method. Each bit generator has one counter,
The size of this counter is the same size as the queue address, for example 9 bits when a 512 size queue is used. 1 by one bit generator
Each time one new codeword is used, the maximum value is loaded into that counter. When any bit generator requests a codeword, the counters of all bit generators are decremented. When a counter reaches 0, the corresponding bit generator state is cleared (eg, the MPS counter, R2 (2) counter and LPS, and the long run count counter are cleared). This is done even when a bit generator is not enabled, so there is no problem with the status counter.

<Initialization of memory for each context bin>
If each context bin memory holds probability prediction information, then extra memory bandwidth may be needed to initialize the decoder (eg, the memory) very quickly.
If the decoder has many contexts, and not all of these contexts need to be cleared, then initializing the decoder quickly can be a challenge. When the decoder supports many contexts (1K or more) and the memory cannot be cleared entirely, an unacceptably high number of clock cycles will be required to clear the memory.

To quickly clear the context,
Some embodiments of the present invention use special bits (referred to herein as initialization state bits) that are stored with each context. Therefore, this special bit is
It is stored with the PEM state (eg 8 bits) for each context.

The memory and initialization control logic for each context bin is shown in FIG. In FIG. 31, the context memory 2401 is connected to the register 2402. In one embodiment, register 2402 is a 1-bit register, which indicates the currently appropriate state for the initialized state bin. Register 2402 is XOR
Connected to one input of logic 2403. XOR logic 2
The other input of 403 is connected to the output of memory 2401. The output of XOR logic 2403 is a valid signal and is also connected to one input of control logic 2404.
The other input of control logic 2404 is connected to the output of counter 2405 and the context bin signal. Control logic 2
One output of 404 is connected to the select inputs of MUX 2406, 2407 and the input of counter 2405. Another output of control logic 2404 is connected to the select input of MUX 2408. The input of MUX 2406 is connected to the output of counter 2405 and the context bin signal. The output of MUX 2406 is connected to memory 2401. The input of MUX 2407 is connected to the new PEM state and 0. The output of MUX 2407 is connected to the input of memory 2401, and the output of memory 2401 and the initial PEM
The state is connected to the input of MUX 2408. MUX24
The 08 output is the PEM status output.

Each time one decoding operation is performed (that is, for each data set, not for each decoded bit), the value in register 2402 is inverted. XOR logic 2403 compares the value of the accessed memory location with the register value to determine if the accessed memory location is valid for the decoding operation.
This is done by the XOR logic 2404 by checking that the initialization status bits match the appropriate status in register 2402. If the data in memory 2401 is not valid, control logic 2402 causes the state-sign logic to ignore the data and use the initial PEM state instead. This is done by MUX 2408.
Since the initialization bit is set to the current value of the register when a new PEM state is written to memory, that initialization bit will be considered valid when it is accessed again.

Only after the initialization state bits of all context bin memory entries have been set to the current value of the register can the next decoding operation begin. Counter 2405 sequentially specifies all memory locations to make sure it has been initialized. When a context bin is used but its PEM state is not updated, the unused write cycles may be used to test or update the memory location indicated by counter 2405. After the completion of one decoding operation, if the counter 2405 has not reached the maximum value,
The remaining contexts are initialized before starting the next operation. The logic shown in FIG. 48 is used to control this operation.

<High-speed adaptive PEM> The PEM used in the present invention is irrespective of the available data amount.
An adaptation scheme may be included that allows faster adaptation. By doing so, the present invention adapts the decoding operation initially faster and then slowly as more data is available to obtain a more accurate prediction. Further, the PEM may be fixed in a PEM state table / machine configured with a field programmable gate array (FPGA) or ASIC.

Tables 20 to 20 shown in FIGS. 68 to 73
25 describes some probabilistic prediction state machines. In some of the tables, R3 codes are not used or long codes are not used to reduce hardware costs. Tables 21-25, other than table 20, utilize a special "fast adaptation" state for quick adaptation at the beginning of the encoding until the first LPS occurs. These fast adaptation states are italicized in the table. For example, referring to the table 21 in FIG. 69, the current state is state 0 at the start of decoding. When MPS appears, the decoder is in state 3
Transition to 5. As long as the MPS appears, the decoder is in state 35
To the upper side, and finally to the state 28. When LPS appears somewhere, the decoder exits from the fast adaptation state shown in italics and transitions to a state that represents a stochastic state suitable for the data received so far.

Note that in each table, the decoder exits the fast adaptive state after receiving a certain number of MPSs. In the preferred embodiment, once the fast adaptive states are exited, there is no way to return to those states other than restarting the decoding operation. In other embodiments, the state table may be designed to re-enter these fast adaptation states to allow faster adaptation. The present invention allows the decoder to reach faster skew codes faster, which would probably benefit from improved compression. It should be noted that, regarding a specific table, by changing the entry for the current state 0 of the table so that the table transitions up or down by one state according to the input data,
Fast adaptation can be omitted.

In all of these tables, the data for each state is the code for that state, the next state at the time of positive direction update (upward), and the next state at the time of negative direction update (downward). The asterisk indicates that the MPS has to be changed with a negative update.

The addition of fast adaptation to probability prediction only helps at the beginning of the encoding. If the context bin statistics change more quickly than the PEM state table described above, another method can be used to improve adaptation during the coding period.

One way to maintain fast adaptation throughout the encoding operation is to add an acceleration condition to the PEM state update. This acceleration can be incorporated into the PEM state table by repeating each code a certain number of times (eg, 8 times). In this case, the acceleration condition M (for example, a positive integer) can be added to or subtracted from the current state at the time of updating. When M is 1, the system behaves exactly the same without acceleration, with the slowest adaptation. When M is greater than 1, a faster adaptation is done. Initially, M is 1 for initial fast adaptation.
Will be set to a larger value.

One method of the present invention for updating the value of M is based on the number of consecutive codewords. For example, when a certain number of codewords appear consecutively,
The value of M is increased. For example, four consecutive codewords are "0""0""0""0", or "1"
When N "" 1N "" 1N "" 1N ", the value of M is increased, while" 0 "codeword and"
Switching to the 1N "codeword may be used to reduce the value of M. For example, 4 consecutive 4
Whether each codeword is "0""1N""0""1N",
Or when it is "1N""0""1N""0",
The M value is reduced.

Another acceleration method uses a state table in which each code is repeated S times. However, S is a positive integer. S is an inverse acceleration parameter. The adaptation is fast when S is 1, and slow when S is larger. Initially, the value of S is set to 1 in order to perform initial fast adaptation.
May be set to. By a method similar to the one described above,
The value of S may be updated when four consecutive codewords are "0""0""0""0" or "1N""1N""1N""1N". In this case, the value of S is reduced. On the other hand, four consecutive codewords
0 "" 1N "" 0 "" 1N "or" 1N ""
When 0 "" 1N "" 0 ", the value of S is increased.

The definition of consecutive codewords can have several meanings. In a "contextual" system, consecutive codewords will refer to consecutive codewords in the same context bin. In the “probability-based” system,
Consecutive codewords will refer to consecutive codewords in the same probability class. Alternatively, in either of these systems, a continuous codeword may generically refer to a continuous codeword (no distinction between context bins or probability classes). In the case of these three examples, the number of memory bits required to store the history of codewords is 3 × the number of context bins, 3 × the number of probability classes, and 3, respectively.
The best adaptation would be possible if it supports acceleration per context bin. Tracking often deteriorates due to global changes in data before encoding, so
Good adaptation can also be obtained by judging acceleration globally.

System Application One advantage of the compression system is that it requires less memory for the data set. The parallel system of the present invention is suitable for all applications currently being made fast by lossless coding systems.
Alternatively, it may be applied to voice, documents, databases, computer-executable or otherwise digital data, signals or symbols processing systems. Typical lossless coding systems include facsimile compression systems, database compression systems, bitmap graphic image compression systems, and transform coefficient compression systems in image compression standards such as JPEG and MPEG. The present invention can be implemented by small-scale and efficient hardware, and
It can also be implemented by relatively high-speed software, which is optimal for applications that do not need to be high-speed.

A practical advantage of the present invention over the prior art is that very fast operations are possible, especially decoding operations. Thus, high speed computer networks and costly high speed channels such as satellite or terrestrial broadcast channels can be fully utilized. FIG. 35 shows such a system. Broadcast data or high-speed computer network data is given to a decoding system 2801, which decodes the data in parallel and sends output data. Using current hardware entropy decoders (such as Q-coders) would reduce the throughput of these systems. All of these systems are designed to have high bandwidth and high cost. It is unproductive for the decoder to reduce throughput. The parallel system of the present invention not only accommodates these high bandwidths, but also actually increases the effective bandwidth because the data can be transmitted in a compressed form.

The parallel system of the present invention also includes ISDN,
It can be applied to obtain more effective bandwidth from moderately high speed channels such as CD-ROM and SCSI. Such a bandwidth matching system is shown in FIG. 36, which includes CD-ROM, Ethernet, SCSI (Small).
Computer Standard Interface) and other similar sources of data are connected to a decryption system 2901 that receives the data, decrypts it, and produces an output. These channels are much faster than some current coders. Often, these channels are used to service data sources that require more bandwidth than the channel has, such as real-time video and computer-based media. The system of the present invention can serve to match bandwidth.

The system of the present invention is a high-definition television (H
It is most suitable as an entropy coder section for real-time video systems such as DTV) and MPEG video standards. Such a system is shown in FIG.
In FIG. 37, this real-time video system is
Decoding system 300 to which compressed image data is connected
One. The decoding system 3001 decodes the data and then outputs the data to the lossy decoder 3002. Lossy decoder 3002 may be part of the transform, color transform and sub-sampling of HDYV or MPEG decoders. Monitor 3003 may be a television or video monitor.

[0277]

As can be understood from the above detailed description, according to the present invention, the problems of the prior art can be solved, and a device for encoding or decoding data at a high speed, a device for encoding or decoding data. It is possible to provide a device for performing parallel processing, a device for performing real-time encoding or decoding, and the like, and it is possible to obtain such a large effect that such a device can be realized by inexpensive hardware.

[Brief description of drawings]

FIG. 1 is a block diagram of a conventional binary entropy encoding device and decoding device.

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

FIG. 3 is a block diagram of an encoding system of the present invention.

FIG. 4 is a block diagram of one embodiment of a parallel decoder of the present invention that processes context bins in parallel.

FIG. 5 is a block diagram of an embodiment of a parallel encoder of the present invention that processes probability classes in parallel.

FIG. 6 is a diagram showing a non-interleaved code stream of the present invention.

FIG. 7 is a diagram showing an example of a data set and an interleaved code stream.

FIG. 8 is a diagram showing an example of an R-coder probability prediction table of the present invention.

FIG. 9 is a block diagram of an embodiment of an encoding device of the present invention.

FIG. 10 is a block diagram of an embodiment of a bit generator of the present invention.

FIG. 11 is a block diagram of an embodiment of a rearrangement unit of the present invention.

FIG. 12 is a block diagram of an embodiment of the run count rearranging unit of the present invention.

FIG. 13 is a block diagram of another embodiment of the run count rearranging unit of the present invention.

FIG. 14 is a block diagram of an embodiment of a bit pack unit of the present invention.

FIG. 15 is a block diagram of one embodiment of packing logic of the present invention.

FIG. 16 is a block diagram of an embodiment of a bit generator for an encoder of the present invention.

FIG. 17 is a block diagram of an embodiment of the decoding system of the present invention.

FIG. 18 is a block diagram of the decoder of the present invention.

FIG. 19 is a block diagram of one embodiment of the FIFO structure of the present invention.

FIG. 20 is a diagram showing an embodiment of a decoding pipeline of the present invention.

FIG. 21 is a conceptual diagram of a decoder of the present invention.

FIG. 22 is a block diagram of an embodiment of a shifter of the present invention.

FIG. 23 is a block diagram of another embodiment of the shifter of the present invention.

FIG. 24 is a block diagram of an example of a system having an external context model.

FIG. 25 is a block diagram of another example of a system having an external context model.

FIG. 26 is a block diagram illustrating one embodiment of a decoder of the present invention having a pipelined bit generator.

FIG. 27 is a block diagram showing one embodiment of a decoder of the present invention having a separated bit generator.

FIG. 28 is a block diagram of an embodiment of a bit generator for a decoder of the present invention.

FIG. 29 is a block diagram of an embodiment of the long run unit of the present invention.

FIG. 30 is a block diagram of an embodiment of a short run unit of the present invention.

FIG. 31 is a block diagram of one embodiment of initialization and control logic of the present invention.

FIG. 32 is a block diagram of one embodiment of a rearrangement unit that uses a snooping decoder.

FIG. 33 is a block diagram of another embodiment of the rearrangement unit.

FIG. 34 is a block diagram of one embodiment of a rearrangement unit that uses a merge queue.

FIG. 35 is an illustration of a high bandwidth system utilizing the present invention.

FIG. 36 is an illustration of a bandwidth matching system utilizing the present invention.

FIG. 37 is a block diagram of a real-time video system utilizing the present invention.

FIG. 38 is a diagram showing one embodiment of the encoded data memory of the present invention.

FIG. 39 is a decoding timing chart of the present invention.

FIG. 40 is a graph of coding efficiency versus MPS probability.

[FIG. 41] A of a bit generator for encoder of the present invention
It is a figure which shows HDL source code.

42 is a diagram showing a continuation of the AHDL source code shown in FIG. 41. FIG.

43 is a diagram showing a continuation of the AHDL source code shown in FIG. 42. FIG.

FIG. 44 is a diagram showing a continuation of the AHDL source code shown in FIG. 43.

45 is a diagram showing a continuation of the AHDL source code shown in FIG. 44. FIG.

FIG. 46 is a diagram showing a continuation of the AHDL source code shown in FIG. 45.

FIG. 47 is a diagram showing C language source code related to a queue with a time stamp.

FIG. 48 is a diagram showing C language source code related to context initialization.

FIG. 49 is a table showing codewords by R code and their meanings.

FIG. 50 is a table of R codes.

FIG. 51 is an R code table.

FIG. 52 is a table of R codes.

FIG. 53 is a table of R codes.

FIG. 54 is a table of R codes.

FIG. 55 is an R code table.

FIG. 56 is a table of R codes.

FIG. 57 is a comparison table of probability, probability skew, and optimal Golomb code.

FIG. 58 is a comparison table of R2 codes and probability intervals.

FIG. 59 is a comparison table of R2 codes and R3 codes and probability intervals.

FIG. 60 is a table illustrating 1N codewords of R3 (2) code.

FIG. 61 is a comparison table of code words and data of R2 (2) code.

FIG. 62 is a table showing an example of a data encoding operation.

FIG. 63 is a table showing an example of a rearrangement operation.

FIG. 64 is a table showing control logic of a FIFO structure like a decoder.

FIG. 65 is a table of a signal dependency list associated with a decoding timing diagram.

FIG. 66 is a table of R2 (2) codes capable of in-stream signaling.

FIG. 67 is a table showing codes other than the R code.

FIG. 68 is a PEM status table.

FIG. 69 is a PEM status table.

FIG. 70 is a PEM status table.

FIG. 71 is a PEM status table.

FIG. 72 is a PEM status table.

FIG. 73 is a PEM status table.

[Explanation of symbols]

204 Input Buffer 205 Decoder 206 Context Model 207 Decoded Data Storage Device 214 Context Model 215, 216, 217 Probability Prediction Modules 218, 219, 220 Bit Stream Generator 221, 222, 223 Bit Stream Generator 224, 225, 226 Probability Prediction Module 227 Context model (CM) 232, 233, 234 Bitstream generator 235 Probability prediction module 236 Context model 600 Encoder 601 Original data 602 Encoder 603 CM / state memory 604 Codeword information 606 Rearrangement unit 607 Rearrangement memory 608 Code Data 701 Bit generator 702 Memory 801 Run count rearrangement unit 802 Bit pack unit 901 Pointer memory 902 Multiplexer 903 Head counter (pointer) 904 Tail counter (pointer) 905 Multiplexer 906 Validity detection module 908 Code word memory 909 Control module 1000 Run count rearrangement unit 1001 Pointer memory 1002 Head counter (pointer) 1003 Tail Counter (pointer) 1004, 1005 Multiplexer 1006 Length calculation block 1007 Validity detection block 1008 Codeword memory 1101 Packing logic 1102 Stream counter 1103 Memory 1104 Tail pointer 1105 Head counter 1201 Size unit 1202 Accumulator 1203 Shifter 1204 Multiplexer 1205 Register 1206 OR logic 1400 Decoding system 1401 FIFO structure 1402 Decoder 1403 Memory 1404 Context model 1460 FIFO 1461, 1462 registers 1463, 1464 Multiplexer 1465 Control block 1600 shifters 1601, 1602, 1603, 1605 register 1605 Multiplexers 1606 Barrel shifter 1607, 1607, 1607. , 1061 register 1611 size unit 1612 accumulator 1620 shifter 1621, 1622 codeword pre-processing logic 1623 multiplexer 1624 codeword processing logic 1701 CM chip 1702 decoder chip 1801 CM chip 1802 decoder chip 1803 memory 1900 decoder 1901 context model 1902 Memory 1903 PEM State-Code Module 1904 Memory 1905 Pipelined Bit Generator 1906 Shifter 2000 Decoder 2001 Context Model 2002 Memory 2003 PEM State-Code Module 2004 Decoder 2005 Bitstream Generator 2006 Shifter 2101 Short Run (Count) Unit 2102 Long Run ( Count) Unit 2201 AND logic 2202 NOT logic 2203 bit counter 2302 counter (MPS counter) 2303 counter (R2 (2) counter and LPS) 2401 context memory 2402 register 2403 XOR logic 2404 control logic 2405 counter 2406, 2407, 2408 multiplexer 2501 run Count sorting unit 2502 bit pack unit 2503 multiplexer 2504 snooper decoder 2601 logic 2701 run count reorder unit 2801 decoding system 2901 decoding system 3001 decoding system 3002 lossy decoder 3003 monitors 3100 register file 3101 memory

─────────────────────────────────────────────────── ─── Continuation of the front page (51) Int.Cl. ⁶ Identification number Internal reference number FI Technical indication location H04N 7/24 (72) Inventor James Diallen USA California 94025 Menlo Park Sand Hill Road 2882 Ricoh Corporation (72) Inventor Martin Pee Borrick, California, USA 94025 Menlo Park Sand Hill Road 2882 Ricoh Corporation

Claims (121)

[Claims] 1. A coding method for coding a data stream, comprising the step of generating codeword information representing the datastream in response to the datastream, wherein the codeword information is A plurality of code words, and a plurality of code words are generated by processing data of the data stream in parallel, and each of the plurality of code words in the data stream is generated by each code word of the data stream. , Including outputting in an order based on the first part of the part represented by
An encoding method comprising a step of generating encoded data according to the codeword information. 2. The encoding method according to claim 1, wherein each of the plurality of codewords is output at the beginning of each run. 3. The encoding method according to claim 1, wherein the encoded data generating step further includes combining variable length codewords into a fixed length data structure. 4. The encoding method according to claim 3, wherein each of the fixed length data structures is composed of one interleaved word. 5. The encoding method according to claim 1, further comprising the step of outputting the encoded data such that the codewords are ordered in decoding order. 6. The encoding method of claim 1, further comprising the step of ordering the codewords. 7. The encoding method according to claim 1, wherein the code word information generating step generates a probability state of a code word, a bit generating code is selected based on the probability state, and a memory is accessed. And then obtaining a run count associated with the stochastic state. 8. An encoding device for encoding a data stream, comprising an encoder connected to receive the data stream and producing code word information consisting of code words, wherein the code A plurality of codewords are generated by parallelizing the data by the encoder, and the rearrangement unit is connected to the encoder and generates encoded data according to the codeword information; Here, the rearrangement unit arranges the codewords generated by the encoder in a decoder order such that the output order of the codewords is based on the first part of the part of the data stream represented by each codeword. Encoding device that rearranges. 9. The encoding device according to claim 7, wherein the rearrangement unit stores the codeword so that the codeword size can be known. 10. The encoding device according to claim 9,
An encoding device, wherein 1N codewords are rearranged so that the most significant "1" bit indicates the length of each codeword. 11. The encoding apparatus according to claim 8, wherein
The reordering unit combines one or more runcount reordering units to generate each of the plurality of codewords in the codeword information at the beginning of each run, and a fixed length data structure by combining variable length codewords. An encoding device comprising one or more bit pack units according to claim 1. 12. The encoding device according to claim 11, wherein each of the fixed length data structures is composed of one interleaved word. 13. The encoding device according to claim 11, wherein the rearrangement unit rearranges codewords. 14. The encoding apparatus according to claim 13, further comprising a memory connected to the memory for storing codewords in a certain order. 15. The encoding system according to claim 8, wherein the encoder generates a codeword according to a context model, a probability prediction machine connected to the context model, and the data stream. And a bit generator structure connected to a probability prediction machine. 16. The encoding device according to claim 15, wherein the encoder further comprises a memory for storing a plurality of run counts, the memory being accessed by using a probability class given by the probability prediction machine. An encoding device, wherein a run count of the plurality of run counts is provided to the bit generator structure to be output as part of the codeword information. 17. The encoding device according to claim 15, wherein the bit generator structure is an index and an M.
A bit generator that provides codeword information according to PS / LPS display and a memory connected to the bit generator for giving a run count to the bit generator, the bit generator including the memory based on the index. And a bit is generated based on the data obtained by the reading. 18. The encoding device according to claim 17, wherein the code word information includes a first signal indicating whether or not the content of the MPS / LPS display is the start of a run, and MPS / L.
Second indicating whether or not the content of the PS display is the end of the run
And a codeword output. 19. The encoding apparatus according to claim 11, wherein the bit pack unit rearranges interleaved words to generate an encoded data stream according to N codewords in each interleaved word of each stream. And an encoding device for generating an ordered interleaved stream. 20. The coding device according to claim 11, wherein the rearrangement unit has a snooping decoder for selecting interleaved words output to a code stream. 21. The encoding apparatus according to claim 20, wherein the rearrangement unit includes a plurality of runcount rearrangement units connected to a plurality of bitpack units, each of the plurality of bitpack units being interleaved. An encoding device for generating a word, wherein the snooping decoder selects an interleaved word as an output to the code stream from the plurality of interleaved words. 22. The encoding device of claim 11, wherein the codeword information includes a time stamp and the reordering unit further comprises logic for outputting an interleaved word based on the associated time stamp. An encoding device characterized by. 23. The encoding device of claim 22, wherein the reordering unit comprises a plurality of runcount reordering units connected to a plurality of bitpack units, the logic relating interleaved words to a time. An encoding device which outputs based on a stamp. 24. The encoding device according to claim 23, wherein the interleaved word is output based on the oldest time stamp. 25. An encoder according to claim 11, wherein a single queue supplies a code word to a plurality of bit pack units, the plurality of bit pack units being output as part of the code stream. An encoding device for generating a Do word. 26. The encoding apparatus of claim 25, wherein the single queue includes a single runcount reordering unit and logic determines the next interleaved word to output as the codestream. An encoding device characterized by. 27. The coding device according to claim 11, wherein a single queue supplies the codewords to a single bit pack unit. 28. An encoder that generates codeword information according to data, and a rearrangement unit connected to the encoder, the rearrangement unit including encoded data according to the codeword information. A stream count rearrangement unit for generating a stream, the rearrangement unit arranging each codeword in the first part of the corresponding data, and receiving the codeword from the runcount rearrangement unit to combine the variable length codewords. A plurality of fixed length interleaved words, and a bit pack unit connected so as to output the plurality of fixed length interleaved words in the order required by the decoder,
An encoder for a compression system having a decoder for decoding the information generated by the encoder. 29. The encoding apparatus according to claim 28, further comprising a memory for storing codewords during rearrangement. 30. The encoding apparatus according to claim 28, wherein the encoder further includes a context model, a probability prediction mechanism connected to the context model, and a bitstream generator connected to the probability prediction mechanism. An encoding device characterized by. 31. The encoding device of claim 30, wherein the runcount reordering unit further comprises a first memory for storing codewords and a first memory for addressing the first memory as a queue. One indicator and a second indicator, the first indicator pointing to a first entry designated as an output of the first memory, and the second indicator next to the first memory. An encoding device which points to a second entry designated as an available and unallocated storage location of the. 32. A pointer memory for storing address information corresponding to a location in the first memory currently designated for storing a codeword for each index. 31. The encoding device according to item 31. 33. The coding apparatus according to claim 32, wherein each index indicates one probability class. 34. The encoding device of claim 32, wherein each index points to at least one context. 35. The encoding device according to claim 28, wherein the rearrangement unit includes a codeword memory queue for storing codewords, a head pointer indicating at least one codeword to be output, and And a tail pointer pointing to at least one memory location for inserting a codeword into the codeword memory queue. 36. The encoder of claim 35, wherein each codeword entry of the codeword memory queue includes a validity indication and the head pointer when one codeword is output from the codeword memory queue. Is an address of the codeword, and the validity display of the codeword displays the validity of the codeword. 37. The encoding apparatus of claim 28, wherein the bitpack unit has bitpack logic for receiving codewords from the rearrangement unit and integrating the codewords into interleaved words for multiple streams. An encoding device characterized by the above. 38. The encoding apparatus according to claim 37, wherein the bit pack logic has a plurality of accumulators and a plurality of registers, each of the plurality of registers being one accumulator and the plurality of accumulators. Associated with one of the streams
Each register stores an interleaved word for its associated stream, and each accumulator indicates the next location for storing the current codeword for that stream in its associated register, thereby An encoding device, wherein each codeword for one stream in a stream is added to the contents of a register associated with the one stream based on the value of the associated accumulator. 39. Connected to the plurality of accumulators,
Further comprising a shifter that shifts the codeword in response to at least one signal from the plurality of accumulators, the codeword being added to the contents of one of the plurality of registers based on the one accumulator value. 39. The encoding device as claimed in claim 38, which is shifted in such a way that at least two codeword parts are packed into each interleaved word. 40. The encoding apparatus according to claim 37, further comprising a rearrangement memory for storing interleaved words in an order specified by the decoder. 41. The permutation for a next interleaved word further comprising a plurality of pointers corresponding to a plurality of interleaved data streams, the plurality of pointers each corresponding to a respective stream in the plurality of streams. The encoding device according to claim 40, characterized in that a location in memory is designated. 42. A plurality of runcount reordering units are further provided, each of the plurality of runcount reordering units being associated with one of the encoded data streams, and an interleaved word for each encoded data stream. 29. The code of claim 28, further comprising: a plurality of bitpack units for generating a, and a decoder for selecting an interleaved word emanating from the plurality of bitpack units as the decoded output. Device. 43. A plurality of runcount reordering units, each of the plurality of runcount reordering units being associated with one of the encoded data streams, the plurality of codewords and the plurality of codes. A plurality of bit pack units for generating time stamps associated with each of the words and also for generating each interleaved word for each encoded data stream; and each of the interleaved words for each of the interleaved words 29. The encoding device of claim 28, further comprising logic for selecting based on a time stamp. 44. The encoding apparatus according to claim 43, wherein the logic selects an interleaved word including a codeword having an oldest time stamp. 45. The encoding device according to claim 28, wherein the bit pack unit is one of a plurality of streams.
A plurality of bit packing units connected to receive a code word from one of the plurality of bit packing units, and further includes logic for selecting an interleaved word to be output from each of the plurality of bit packing units based on the next stream. An encoding device characterized by the above. 46. The encoding device according to claim 28, wherein the rearrangement unit further has a finite memory. 47. A coding device for processing data, comprising: an index generator for generating an index based on the data; and a state table connected to provide a probability prediction value based on the index. , The state table includes a first plurality of states and a second plurality of states, each state corresponding to one code, and the first plurality of states.
Transitions between different symbols corresponding to the first plurality of states during transitions between the states of the plurality of states of the second plurality of states during transitions between states of the second plurality of states. A coding device that occurs faster than the transition between different codes corresponding to. 48. The coding device of claim 47, wherein the first plurality of states is used only for a predetermined number of indexes. 49. The coding device of claim 47, wherein the first plurality of states is used only for a predetermined number of indexes that initially index the state table. 50. The coding device of claim 47, wherein each of the first plurality of states is associated with an R2 code. 51. The coding apparatus as set forth in claim 48, wherein the first plurality of states includes at least one transition to the second plurality of states, so that the state table stores the predetermined number of indexes. A coding device, characterized by making a transition from the first plurality of states to the second plurality of states later. 52. The coding device of claim 47, wherein each of the first plurality of states is associated with a different code. 53. The coding apparatus of claim 47, wherein the state table is responsive to a least-probability symbol from a state in the first plurality of states to a state in the second plurality of states. A coding device characterized by a transition to. 54. The coding device of claim 47, wherein the state table raises states in response to highest probability symbols. 55. A coding device for processing data, comprising: an index generator for generating an index based on the data; and a state table connected to provide a probability prediction value based on the index. The state table includes a plurality of states, each state corresponds to one code, all the codes in the state table are repeated a predetermined number of times, and the transition between states of the state table becomes a correctable acceleration condition. A coding device, wherein the first rate of state transitions in the first period is different than the second rate of transitions in the second period. 56. The coding device of claim 55, wherein updating the state table comprises modifying a PEM state by increasing or decreasing the acceleration condition. 57. The coding apparatus according to claim 56, wherein adaptive acceleration is not performed when the acceleration condition is a predetermined number. 58. The coding apparatus according to claim 56, wherein the acceleration condition is updated based on the number of consecutive codewords. 59. The coding device according to claim 58, wherein the consecutive codewords are consecutive codewords in the same context. 60. The coding device according to claim 58, wherein the consecutive codewords are consecutive codewords in the same probability class. 61. The coding apparatus according to claim 56, wherein the acceleration condition is updated based on the number of alternating codewords. 62. An entropy decoder for decoding a data stream composed of a plurality of codewords, the plurality of bitstream generators for receiving the datastream, and the probability prediction value for the plurality of bitstream generators. A state table connected to the plurality of bitstream generators to provide R for multiple n values.
An n (k) code is used to generate a decoding result for each codeword in the data stream according to the probability prediction value, and the state table includes a first plurality of states and a second plurality of states. An entropy decoder comprising, wherein inter-code transition occurs faster when transitioning in the first plurality of states than during transitioning in the second plurality of states. 63. The entropy decoder of claim 62, wherein each of the first plurality of states is R2 (k).
An entropy decoder including a code. 64. The entropy decoder of claim 62, wherein the first plurality of states are utilized only during initialization. 65. An entropy decoder for decoding a data stream consisting of a plurality of codewords, wherein the entropy decoder comprises a plurality of bitstream generators for receiving the datastream, and a probability prediction value based on an index. A state table connected thereto, wherein the state table has a plurality of states, each of the plurality of states corresponds to one code, and all the codes in the state table have a predetermined number of times. Again, the state-to-state transitions of the state table occur based on a modifiable acceleration condition such that the first rate of inter-state transitions in the first period is different from the second rate of transitions in the second period. Entropy decoder. 66. The entropy decoder according to claim 62, wherein all codes in the state table are repeated a fixed number of times. 67. The entropy decoder of claim 66, wherein updating the state table comprises modifying PEM states according to acceleration conditions. 68. The entropy decoder according to claim 67, wherein adaptive acceleration is not performed when the acceleration condition is a predetermined value. 69. The entropy decoder according to claim 67, wherein the acceleration condition is updated based on the number of consecutive codewords. 70. The entropy decoder according to claim 67, wherein the acceleration condition is updated based on the number of alternating codewords. 71. A decoder for decoding a plurality of interleaved words, the shifter for receiving the data stream and outputting properly aligned encoded data, the properly aligned encoding. A run length decoder connected to the shifter for receiving data as a code word and determining a code word type, and an indication as to whether or not the run length decoder and the run length have appeared according to each code word. To produce,
A probability prediction machine connected to the run length decoder for determining a code for the run length decoder, wherein the shifter comprises a variable length shift mechanism for shifting codewords from the data stream. A decoder having a plurality of registers connected to receive codewords from the data stream in response to the shift mechanism such that the aligned and aligned codeword data is output as a sequence of codewords. . 72. The decoder of claim 71, wherein some registers in the plurality of registers are connected to receive data from another register in the plurality of registers or from the data stream. A decoder characterized in that. 73. The decoder of claim 71, wherein the variable length shift mechanism includes a barrel shifter for shifting data from the data stream into the plurality of registers. 74. The decoder of claim 71, wherein the shifter comprises a FIFO having a plurality of registers, each of the plurality of registers receiving the interleaf word as an input, and the plurality of registers. A decoder, wherein at least one register therein is connected to receive a codeword from another register in the plurality of registers. 75. The decoder of claim 71, wherein the shifter is coupled to receive codeword data, each shifter being coupled to a separate stream of the plurality of streams.
Connected to receive the codeword data from each of the first plurality of registers as inputs, and output the codeword from one register of the first plurality of registers at a time. A multiplexer, a barrel shifter connected to the output of the multiplexer for outputting the codeword data from the multiplexer as shifted and aligned codeword data, and for indicating the number of bits to shift the codeword, A logic having a logic connected to the barrel shifter and a FIFO having a plurality of registers connected to receive a codeword from the multiplexer, each of the plurality of registers receiving as input data from the interleaved word. , And at least one register in the plurality of registers is another register in the plurality of registers. Decoder, characterized in that it is connected to receive the codewords from. 76. A decoding device for decoding data, a FIFO structure connected to receive the data, a context model for providing context, and state information connected to the context model. A memory for storing, the memory providing state information in response to each context provided by the context model, and coupled to receive encoded data from the FIFO structure and state information from the memory, A plurality of decoders for decoding a code word given from the FIFO structure using state information given from the memory, the plurality of decoders providing run counts for a plurality of codes. Decryption device. 77. The decoding device according to claim 76,
A decoding device, wherein the FIFO structure supplies encoded data to the plurality of decoders regardless of context and probability class. 78. The decoding device according to claim 76,
A decoding device, wherein the decoder has a run count memory for storing a run count, and the run count memory is accessible based on a probability class. 79. The decoding device according to claim 76,
Decoding device characterized in that the FIFO structure supplies data to two decoders. 80. The decoding device according to claim 76,
Decoding device characterized in that the FIFO structure has a plurality of outputs, one for each decoder. 81. A decoding device according to claim 80,
Decoding device characterized in that the FIFO structure comprises a pair of multiplexers and control logic for selecting the pair of multiplexers to ensure that one codeword is supplied to each decoder. 82. The decoding device according to claim 81,
A decoding device, wherein the pair of multiplexers is selected by the control logic based on a request received from one of the plurality of decoders. 83. A coding device for coding input data, comprising a coding unit connected to receive the input data for generating the coded data as a plurality of streams. Encoded data is assigned to the plurality of streams based on a set of criteria and has a fixed size memory connected to the encoding unit for storing the plurality of encoded data streams, An encoding device in which low-degree encoded data is discarded when the fixed size memory overflows. 84. The encoding device according to claim 83, wherein the memory has a plurality of storage areas, and code word data stored in each of the plurality of storage areas has different levels of importance. An encoding device comprising: 85. The encoding device according to claim 84, wherein the encoded data of one duty level is stored in the storage area of at least one of the memories storing the encoded data of another duty level. An encoding device characterized by the above. 86. The encoding device according to claim 85, wherein the coded data of the certain degree of importance level is overwritten on the coded data of the other degree of importance level in the at least one storage area. An encoding device characterized by. 87. A method for initializing a plurality of contexts of a system during encoding of data, comprising the step of initializing the plurality of contexts, wherein each context in the plurality of contexts. Is accessed based on the counter value and has a step of obtaining the PEM state of the current context, the step of obtaining the PEM state includes accessing a storage instruction for each context indicating the PEM state, The number of the current context is compared to the counter value to determine if the accessed memory location is valid for the current operation, the counter value indicating that the location has been initialized. Sometimes determining that the data is valid, and using the initial PEM state for the context , Ignoring the current PEM state for the context when the accessed memory location is not valid, and using the currently allocated PEM state for the context if the data is valid, initial Method. 88. The initialization method of claim 87, further comprising writing a new PEM state when the PEM state changes. 89. A decoder for decoding input data, the context model for providing a context bin and connected to the context model for providing a stochastic state based on the context bin. A memory, a logic connected to the memory for generating a probability class based on the probability state, a decoder generating an enable signal based on the probability class, and the coded data connected to the decoder A plurality of bit generators connected to receive the plurality of bit generators, each of the plurality of bit generators being dedicated to at least one unique code, the decoder being based on the probability class. By enabling one bit generator in the A decoder for decoding the encoded data. 90. The decoder of claim 89, wherein at least one bit generator in the plurality of bit generators decodes data using an R-code and at least one bit generator in the plurality of bit generators. Decoder for decoding data using a code other than the R-code. 91. The decoder of claim 89, wherein the short run length bit generator acts as an R-code decoder. 92. The decoder according to claim 89, wherein the long run length bit generator comprises a short run unit and a long run unit, and the short run unit handles a code of a predetermined first length. A decoder, characterized in that the long run unit handles the remaining bits and determines if there are any bits to be output. 93. Providing a context bin; accessing a memory to obtain a probability state using the context bin; generating a probability class based on the probability state; Enabling one bit generator, each of the plurality of bit generators is dedicated for at least one unique code, and only the at least one unique code is used for decoding. A decoding method for decoding input data, in which one bit generator decodes encoded data. 94. An encoder for encoding input data, a context model for providing context bins, and a context model for providing stochastic states based on the context bins. A memory, logic connected to the memory for providing a probability class based on the probability state, a decoder generating an enable signal based on the probability class, and connected to the decoder to receive the input data A plurality of bit generators connected to each other, each of the plurality of bit generators being dedicated for at least one unique code, the decoder being one of the plurality of bit generators based on the probability class. Enabling one bit generator causes the one bit generator to Encoding the data, encoder. 95. The encoder of claim 94,
At least one bit generator in the plurality of bit generators encodes data using an R-code,
An encoder, wherein at least one bit generator in the plurality of bit generators encodes data using a code other than an R-code. 96. The encoder of claim 94,
Encoder characterized in that the bit generator for short run length acts as an R-code encoder. 97. The encoder of claim 94,
A long run length bit generator comprises a short run unit and a long run unit, the short run unit handles a code of a predetermined first length, the long run unit handles the remaining bits, and the remaining bit An encoder characterized by determining, if any, of the bits of the bit to be output. 98. A method of encoding input data, the method comprising: providing a context bin; accessing a memory to obtain a probability state using the context bin; and generating a probability class based on the probability class. Generating, and enabling one bit generator in the plurality of bit generators, each of the plurality of bit generators being dedicated to at least one code and only the at least one code being An encoding method used for encoding, wherein the one bit generator encodes the input data data. 99. A method for decoding encoded data composed of a plurality of code words, comprising the step of loading a count value into a counter associated with each run counter, wherein the count value is a code value. Corresponding to the size of the codeword memory used when a new run begins during conversion, the count value is loaded when a new codeword is fetched for each run counter, and the codeword is fetched. Each time the counter value is decremented, and the bit generator state associated with the new codeword is cleared when the counter decrements to 0. 100. The decoding method of claim 99, wherein each run counter corresponds to one PEM state. 101. A decoding method according to claim 99, wherein each run counter corresponds to one context bin. 102. A method for decoding coded data consisting of a plurality of codewords, the method comprising: incrementing a counter value including a current time indication each time one codeword is requested; Storing the counter value as a stored time display at the beginning of the word, and comparing the stored time display plus the size of the encoder memory with the current time display. Is greater than the storage time representation plus the size of the encoder memory, the bit generator state for the first codeword is cleared to the second
Decoding method, which requires the codeword of. 103. The decoding method according to claim 102, wherein the stored time display comprises one time stamp. 104. The decoding method of claim 102, further comprising the step of reusing the stored time representation for subsequent codewords. 105. A method for decoding encoded data composed of a plurality of codewords, comprising storing an index corresponding to the codeword in a queue when the codeword is requested; Marking the entry of the index as invalid; storing the codeword in the entry when the codeword is completed, marking the entry valid, and outputting the data to be decoded from the queue If the queue entry is valid, the codeword is output for decoding, and data is output from the queue entry, and if the queue entry is marked invalid at that time, the data is output. Instructing the decoder to be invalid, and receiving the data from the queue marked as invalid Bit generator state is cleared by issue unit, decoding method. 106. A decoding device for decoding encoded data, comprising: a context model mechanism comprising a plurality of integrated circuits for providing context; and a context model mechanism for storing state information. A memory connected to the context model mechanism for providing state information according to each context, and a plurality of memories connected to the memory for decoding a codeword using the state information provided by the memory. A decoder for decoding the codeword using the plurality of R-codes, the plurality of R-codes performing a non-maximum length run of the highest probability symbols not followed by the lowest probability symbols. A decoding device including at least one. 107. The decoding device of claim 106, wherein the count of non-maximum length runs has a uniquely decodable prefix. 108. A decoding device for decoding a codestream having a plurality of codewords, comprising: a context model mechanism comprising a plurality of integrated circuits for providing context; and a context model for storing state information. A memory connected to the context model mechanism for providing state information according to each context provided by the mechanism, and a memory for decoding a codeword using the state information provided by the memory A decoding device having a plurality of connected decoders. 109. The decoding device according to claim 108, wherein said context model mechanism provides at least one context model which provides a context from one integrated circuit in said plurality of integrated circuits, and in said plurality of integrated circuits. At least one that provides context from another integrated circuit
And a context model. 110. The decoding device according to claim 109, wherein the at least one context model on the one integrated circuit side in the plurality of integrated circuits includes a zero-order context model. 111. The decoding device according to claim 108, wherein a context is directly applied to the memory from the plurality of integrated circuits. 112. The decoding device of claim 108, wherein the first portion of the first context is provided by one integrated circuit and the second portion of the first context is provided by another integrated circuit. A decoding device characterized by the above. 113. The encoding device of claim 17, wherein the bit generator state of the bit generator is updated and the updated bit generator is reused before being written to the memory. Encoding device. 114. The encoding device of claim 113, wherein said bit generator makes one read-correction-
An encoding device, characterized in that it is reused during the correction stage of a write cycle. 115. The encoding device of claim 17, wherein the bit generator produces a non-minimum length run count when it is reused before writing to the updated memory. apparatus. 116. The encoding device of claim 17, wherein the bit generator encodes data using an R-code that is determined such that each run length is followed by at least one uncoded bit. , An encoding device characterized in that two codewords having the same run length are not continuously decoded. 117. A decoding device for decoding a code stream having a plurality of code words, comprising: a context model mechanism for providing contexts; and contexts for storing state information and provided by the context model mechanism. And a plurality of decoders connected to the memory for decoding a codeword using the state information provided by the memory. And at least one of the plurality of decoders is a delay tolerant decoder. 118. The decoding device according to claim 117, wherein at least one of the plurality of decoders performs a variable length shift based on decoded data available after a certain delay. Decoding device. 119. The decoding device according to claim 117, wherein each of the plurality of decoders receives variable length data as an input. 120. The decoding device according to claim 119, wherein the plurality of decoders decode variable-length input data in parallel. 121. The decoding device according to claim 117, wherein outputs of the plurality of decoders are divided into fixed-length interleaved words.