JP2005348410A - Compression equipment and its method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a DCT/inverse DCT equipment and method in which high-speed operation implemented. <P>SOLUTION: It is DCT equipments 1118-1126 which has a combinational circuit 1138, which does not have a middle clocked memory circuit, which performs DCT operation with an arithmetic circuit 1122 connected to a transposed matrix memory 1118, The combinational circuit has a predetermined number of stages 1158-1164, sequentially arranged for performing the DCT, Moreover, the DCT equipment may have a multiplexing machine 1124, which multiplexes an input data and an output data of the transposed matrix memory 1118. Moreover, it is desirable to have a control circuit 1116 which controls a performance of the DCT equipment. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

The present invention relates to a decoder that decodes a variable-length code with zero or more unencoded variable-length bit fields inserted, and a decoder that does not change some of the codes. The present invention also relates to a discrete cosine transform (DCT) apparatus that uses a data path without a pipeline or storage means and can operate at high speed.

  In general, large amounts of data are compressed and decompressed for a variety of reasons, including use in several stage means of variable length encoding such as electrical transmission, storage, retrieval and Huffman encoding. Huffman coding A. Huffman's paper, “A Method for the Construction of Minimum Redundancy Codes” Proc. IRE, 40: 1098, 1952 (Non-Patent Document 1). In many cases, the variable-length code in the coded bit string is discontinuous, and other uncoded bit fields are inserted. This bit field represents control and / or format information and / or provides additional information to the encoded data, including marker headers, marker codes, stuff bytes, padding bits and included additional bits such as JPEG encoded data, etc. To do.

  In variable-length encoding, different input codes are assigned different length codes based on the probability of occurrence of input data so that statistically frequent input codes can be assigned shorter codes than less frequent data. assign. Infrequent input codes are assigned longer codes. Code assignment is done either statistically or adaptively. In the case of statistical allocation, the same output code is given to certain data regardless of which data block is processed. In the case of adaptive assignment, output codes are assigned based on statistical analysis of a particular set of input blocks or data blocks and expected changes between blocks (or between block sets).

  A serious problem arises when fast variable length decoding is required. The problem arises particularly when the encoded data sequence includes uncoded variable length bit fields into which the encoded data is inserted (interleaved), such as the JPEG standard. The great difficulty in high-speed decoding of such variable-length encoded data is that after the decoding of the data (encoded) in which the length of a specific unencoded bit field continues as in the JPEG standard is complete. This occurs when it cannot be determined. In general, direct pipeline processing cannot be used with a decoder because the start position of the next encoded data is not known until after the decoding of the subsequent code is completed.

  Existing solutions are too slow for many applications, but require several steps (clock cycles) to decode one input data, or use more than one symbol with iterative units. Is pseudo-simultaneously decoded in one stage (clock cycle). However, the addition of further decoding blocks often renders such decoders economically unbalanced, and also does not provide the necessary and sufficient speed. This is because the start of the next decoder still depends on the processing result of the previous decoder, which determines the beginning of the next input data, so that the multiple decoders do not operate in full parallel. It is. As a result, even if multiple symbols are decoded in one stage (clock cycle), the stage (clock period) is relatively long and too slow for many applications as an overall decoder.

  Thus, there is clearly a need for a decoder for variable length codes interleaved with variable length uncoded bit fields that solves one or more of the problems of conventional decoders. Specifically, the discrete cosine transform (DCT) apparatus shown in FIG. 77 first performs 1-DDCT on an 8 × 8 pixel block row by performing a complete two-dimensional (2-D) transform of an 8 × 8 pixel block. It will be realized. Then, another 1-DDCT is performed on a column of 8 × 8 pixel blocks. Specifically, such an apparatus includes an input circuit 1096, an arithmetic circuit 1104, a control circuit 1098, a transposed matrix memory circuit 1090, and an output circuit 1092.

  The input circuit 1096 accepts 8-bit pixels from the 8 × 8 block. Input circuit 1096 is connected to arithmetic circuit 1104 by intermediate multiplexers 1100 and 1102. Arithmetic circuit 1104 performs arithmetic operations on either rows or entire columns of 8 × 8 blocks. The control circuit 1098 controls all other circuits and implements the DCT algorithm. The output of the arithmetic circuit is connected to a transposed matrix memory 1090, a register 1095, and an output circuit 1092. The transposed matrix memory is connected to a multiplexer 1100 that supplies an output to the next multiplexer 1102. Multiplexer 1102 also receives input from register 1094. The transposed matrix memory 1090 receives 8 × 8 block data in rows and generates data in columns. The output circuit 1092 supplies the DCT coefficients that are made into 8 × 8 pixel data blocks.

  In a typical DCT device, the arithmetic circuit is the most complex, so basically the speed of the arithmetic circuit 1104 determines the overall speed. The arithmetic circuit 1104 in FIG. 77 is configured by dividing the arithmetic processing into several stages described below with reference to FIG. These stages 1114, 1148, 1152, and 1156 can be realized in one circuit by a collection of commonly used ones such as an adder and a multiplier. However, such a circuit 1104 has a disadvantage that it is slower than an optimized circuit because a single circuit used in common constitutes a plurality of stages. This includes storage means used to store intermediate results. The time allotted as a clock cycle for such a circuit must be equal to or greater than the time of the slowest stage in the circuit, and the overall time can be longer than the sum of all stages. Because there is.

  FIG. 78 shows a typical arithmetic data path as part of a 4-stage DCT in the apparatus shown in FIG. The diagram does not reflect the actual configuration, but reflects the function. Each of the four stages 1144, 1148, 1152, and 1156 is composed of one reconfigurable circuit. Each of the four arithmetic stages 1144, 1148, 1152, 1156, which is 1-DDCT, is reconfigured per cycle. In this circuit, each of the four stages 1144, 1148, 1152, and 1156 uses a collection of commonly used ones (adder and multiplier), minimizing hardware.

  However, the disadvantage of this circuit is that it is slow compared to the optimized one. Each of the four stages 1144, 1148, 1152, and 1156 is composed of the same set of adders and multipliers. The clock period is determined by the slowest stage, which in this example is 20 ns in block 1144. Adding the delay of input and output multiplexers 1146 and 1154 (2 ns each) and the delay of flip-flop 1150 (3 ns), the total time is 27 ns. Thus, this DCT element can operate at 27 ns.

  Pipelined DCT elements are also well known. The problem with this configuration is that the configuration requires a large amount of hardware. The present invention does not provide the same performance or processing speed, but provides a very good performance versus size compromise. In addition, it offers a speed advantage over most of the current DCT elements. Thus, there is a clear need for improved DCT / inverse DCT methods and apparatus that can solve one or more of the problems of the prior art. In particular, there is a clear need for a method and apparatus that can reduce the time required for a central arithmetic circuit to calculate the required results in a DCT / inverse DCT apparatus and improve the overall performance of the DCT or inverse DCT.

D. A. Huffman, “A Method for the Construction of Minimun Redundancy Codes”, Proc. IRE, 40: 1098, 1952)

  The first of the present invention is to decode data encoded by a plurality of variable-length codes interleaved with variable-length non-encoded bit fields and a plurality of data blocks having non-encoded fixed-length non-encoded fields. A plurality of fixed length uncoded fields, a plurality of variable length codes interleaved with a variable length uncoded bit field and a variable length uncoded bit field, and a plurality of data blocks The fixed-length encoded data input between the pre-processing unit that outputs a plurality of position signals indicating the positions of a plurality of fixed-length uncoded fields and the variable-length encoded data that is input between the fixed-length uncoded fields is fixed. The position signal is synchronized with the data to be decoded so that it is output from the decoding apparatus during the position signal corresponding to the long uncoded field. A decoding apparatus comprising a transfer means for to pass into force.

  Preferably, the first processing unit includes a first barrel shifter set and a first register, and processes a plurality of variable length codes interleaved with a variable length uncoded bit field, and a second barrel shifter set; A second processing unit that has a second register and processes a plurality of position signals indicating the positions of a plurality of fixed-length non-encoded fields in the plurality of data blocks, wherein the first and second processing units are The decoding apparatus is the same, and the outputs of the first and second barrel shifter sets and the first and second processing units receive the same control signal.

  As another preferred configuration, the output of the second processing unit that processes the position signal indicating the position of the fixed-length uncoded field is removed from the data stored in the data register at the time of decoding. It is a decoding apparatus used for determining the size of Furthermore, as another preferable configuration, the preprocessing unit removes a plurality of fixed-length uncoded fields, and a plurality of variable lengths interleaved with a variable-length uncoded bit field and a variable-length uncoded bit field. Whether the code is a plurality of fixed-length codes composed of a plurality of fixed-length bit fields and one fixed-length bit field is passed or removed in the pre-processing field or passed in the pre-processing field The decoding device has a tag to be output, and the tag is output so as to exist before or after the marker indicating the fixed-length uncoded field.

  More preferably, the data block is Huffman encoded. A second aspect of the present invention is a plurality of data blocks each having data encoded by a plurality of variable length codes interleaved with a variable length non-encoded bit field and a fixed length non-encoded field that is not encoded. And a plurality of variable length codes interleaved with a variable length non-encoded bit field and a variable length non-encoded bit field, and a plurality of data A preprocessing step for outputting a plurality of position signals indicating positions of a plurality of fixed-length non-encoded fields in the block; and decoded data of variable-length encoded data input between the fixed-length non-encoded fields. The position signal is synchronized with the data to be decoded so that it is output from the decoding device during the position signal corresponding to the fixed length uncoded field. A decoding method and a transfer step of to pass to the output of Goka device.

  Preferably, using a first processing unit having a first barrel shifter set and a first register, processing a plurality of variable length codes interleaved with variable length uncoded bit fields, and a second barrel shifter set And a second processing unit having a second register, and further comprising a step of processing a plurality of position signals indicating the positions of a plurality of fixed-length uncoded fields in the plurality of data blocks. This is a decoding method in which the processing units are the same, and the outputs of the first and second barrel shifter sets and the first and second processing units receive the same control signal.

  Furthermore, the size of the non-encoded variable length field that is removed at the time of decoding from the data stored in the data register according to the output of the second processing unit that processes the position signal indicating the position of the fixed-length non-encoded field A decoding method further comprising the step of determining. Preferably, in the preprocessing unit step, a plurality of fixed-length uncoded fields are removed, and a plurality of variable-length codes interleaved with a variable-length uncoded bit field and a variable-length uncoded bit field are As a plurality of fixed-length codes consisting of fixed-length bit fields, and having a tag indicating whether one fixed-length bit field is passed or removed in the preprocessing field or passed in the preprocessing field The tag is a decoding method for outputting the tag so as to exist before or after the marker indicating the fixed-length non-encoded field.

  The data block is preferably Huffman-encoded. In the following detailed description, attention should be paid to FIGS. 82 to 91 and related descriptions as well as other descriptions.

"table of contents"
1.0 Brief Description of Drawings 2.0 Table List 3.0 Preferred and Other Embodiments 3.1 Overview of Multiple Stream Architecture 3.2 Host / Coprocessor Queuing 3.3 Coprocessor Register Description 3.4 Multiple Stream Formats 3.5 Current Active Stream Determination 3.6 Current Active Stream Fetch Instruction 3.7 Instruction Decode and Execution 3.8 Instruction Controller Register Update 3.9 Register Access Semaphore Meaning 3.10 Instruction controller 3.11 Local register file module description 3.12 Register read / write processing 3.13 Memory area read / write processing 3.14 C bus structure 3.15 Coprocessor data type and data Operation 3.16 Data normalization process 3.1 Image processing 3.17.1 Synthesis 3.17.2 color space conversion instruction a accelerator card. Single output color space (SOGCS) conversion mode b. From multiple outputs to spatial mode 3.17.3 LPEG encoding / decoding a. Encoding b. Decoding 3.17.4 Table index 3.17.5 Data encoding instruction 3.17.6 High-speed DCT device 3.17.7 Huffman decoding 3.17.8 Image conversion instruction 3.17.9 Convolution instruction 3 .17.10 Matrix multiplication 3.17.11 Tone (halftone)
3.17.12 Hierarchical image format decompression 3.17.13 Memory copy instruction a. General data movement instruction b. Local DMA instructions 3.17.14 Flow control instructions 3.18 Accelerator card module 3.18.1 Pixel organizer 3.18.2 MUV buffer 3.18.3 Result organizer 3.18.4 Operand organizers B, C
3.18.5 Main data path unit 3.18.6 Data cache controller and cache a. Normal cache mode b. Single output general color space conversion mode c. Multiple output general color space conversion mode d. JPEG encoding mode e. Low speed JPEG decoding mode f. Matrix multiplication mode g. Disable mode h. Invalidation mode 3.18.7 Input interface switch 3.18.8 Local memory controller 3.18.9 Other modes 3.18.10 External interface controller 3.18.11 Peripheral interface controller Table index Table 1: Register Description Table 2: Opcode Description Table 3: Operand Type Table 4: Operand Description Table 5: Module Setup Order Table 6: C Bus Signal Definition Table 7: C Bus Transaction Type Table 8: Data Manipulation Register Format Table 9: Desired Data type Table 10: Explanation of symbols Table 11: Composition processing Table 12: Address composition for SOGCS mode Table 12A: Instruction coding table for color space conversion Table 13: Minor opcode encoding for color conversion instruction Table 14: Huffman and quantization table stored in data cache Table 15: Fetch address Table 16: Huffman encoding table Table 17: Bank address for Huffman and quantization table Table 18: Instruction word-minor opcode field Table 19: Instruction word-minor opcode field Table 20: Instruction operand-result word Table 21: Instruction word Table 22: Instruction operand-result word Table 23: Instruction word table 24: Instruction operand- Result Word Table 25: Instruction Word-Minor Opcode Field Table 26: Instruction Word-Minor Opcode Field Table 27: Fraction Table Description of preferred and other embodiments "
In the preferred embodiment, hardware rasterization is gained by using two independent instruction streams by a hardware accelerator. Thus, while the first instruction stream is preparing to print the current page, the next instruction stream can prepare to print the next page. Hardware resources can be used particularly efficiently when the hardware accelerator can operate at a speed higher than the output device.

In the preferred embodiment, a configuration using two instruction streams is shown. However, a configuration using two or more instruction streams is also possible, and an advantage of using more streams can be obtained in view of hardware trade-off. By using two streams, the hardware resources of the raster image coprocessor can be used to transfer the current page, band, strip, etc. to the printing device depending on the output device, while the next page, band, strip, etc. Be always involved in preparation.
3.1 General Configuration of Multiple Stream Architecture FIG. 1 is a diagram schematically illustrating a computer hardware configuration 201 that includes a preferred embodiment. Configuration 201 includes a standard host computer system consisting of a host CPU 202 connected to host storage memory 203 via a bridge 204. The host computer system is provided with general computer system functions such as an operating system program, an application, and an information display. The host computer system is connected to a standard PCI bus 206 via a PCI bus interface 207. Note that the PCI standard is a well-known industry standard, and most commercially available computer systems, particularly systems incorporating the Microsoft Windows ™ operating system, include a PCI bus 206. By using the PCI bus 206, it is easy to add one or more PCI cards (for example, 209) further including the PCI bus interface 210, other devices 211, local memory 212, etc. to the configuration 201 for use. Become.

In the preferred embodiment, a raster image accelerator card 220 is provided to speed up graphics processing expressed in a page description language. The raster image accelerator card (comprising the PCI bus interface 221) is designed to operate in the form of a shared memory that is loosely coupled to the host CPU 202, like the other PCI cards 209 and the like. If necessary, the image accelerator card 220 can be further added to the host computer system. The raster image accelerator card is for accelerating a complicated and large amount of operation processing in the raster image processing operation.
(A) Synthesis (b) Generalized color space conversion (c) JPEG encoding / decoding (d) Huffman, run length, predictive encoding / decoding (e) Hierarchical image (TM) decoding (f) Generalized affine image Conversion (g) Small kernel convolution (convolution)
(H) Matrix operation (i) Halftone processing (j) Batch arithmetic / memory copy operation The raster image accelerator card 220 further includes a local memory 223 connected to the raster image coprocessor 224. The raster image coprocessor 224 is the host CPU 202. The raster image accelerator card 220 is activated based on the command from Here, the coprocessor 224 is preferably an application specific LSI (ASIC). The raster image coprocessor 224 also has the ability to control at least one required printer device 226 via the peripheral interface 225. Furthermore, the image accelerator card 220 can also control input / output devices such as a scanner. In addition, the accelerator card 220 is provided with a general external interface 227 connected to the raster image coprocessor 224, and can also perform monitoring and testing. .

  In the execution mode, the host CPU 202 transmits a series of commands and data via the PCI bus 206, and the raster image coprocessor 224 performs image generation processing. The transmitted data is stored not only in the local memory 223 but also in the cache 230 in the raster image coprocessor 224 or the register 229 in the coprocessor 224.

  FIG. 2 shows the raster image coprocessor 224 in more detail. The coprocessor 224 is for accelerating the processing described above, and includes a plurality of parts under the control of the instruction control unit 235. In order for the coprocessor to communicate with the outside world, a local memory control unit 236 for communicating with the local memory 223 of FIG. 1 is provided. The peripheral interface control unit 237 is used for communication with a printer device, and uses a standard format such as a Centronics interface standard format or another video interface format. The peripheral interface control unit 237 is internally connected to the local memory control unit 236. The local memory control unit 236 and the external interface control unit 238 are connected via the input interface switch 252, and the input interface switch 252 is connected to the instruction control unit 235. The input interface switch 252 is also connected to the pixel organizer 246 and the data cache controller 240. The input interface switch 252 is for switching data from the external interface control unit 237 and the local memory control unit 236 and transferring the data to the instruction control unit 235, the data cache control unit 240, and the pixel organizer 246.

  The external interface control unit 238 is provided in the raster image coprocessor 224 to communicate with the PCI bus 206 in FIG. 1 and is connected to the command control unit 235. Further, in order to perform a test diagnosis and input a clock signal and a global signal, another module 239 connected to the instruction control unit 239 and operating in cooperation with the coprocessor 224 is provided.

  The data cache 230 operates under the control of the connected data cache control unit 240. Data cache 230 is used in a variety of applications, but is primarily used to store recently used values that are likely to be subsequently used in coprocessor 224. In the speed-up process described above, a plurality of data streams are processed mainly by the JPEG encoder / decoder 241 and the main data path unit 242. The parts 241 and 242 are connected to the pixel organizer 246 and the two operand organizers 247 and 248 in parallel. The processed streams from the parts 241 and 242 are transferred to the result organizer 249, where they are processed and reformatted if necessary. Since there are many cases where it is desired to record intermediate results, a multi-use value (MUV) buffer 250 is provided between the pixel organizer 246 and the result organizer 249 in addition to the data cache 230. The result from the result organizer 249 is output to the external interface control unit 238, the local memory control unit 236, and the peripheral interface control unit 237 if necessary.

  As shown by the dotted lines in FIG. 2, the additional (third) data path unit 243 is “in parallel” with the other two data paths, such as the JPEG encoder / decoder 241 and the main data path unit 242. It is also possible to connect. It is also possible to configure four or more data paths. Note that although the paths are connected "in parallel", they do not operate in parallel, but only one path operates at a time.

  The overall design of the ASIC in FIG. 2 was made based on the following idea. First of all, it is essential that a print page does not cause small or temporary image quality degradation. Even if such small image quality degradation is present in the video signal, it is not perceived by the human eye. However, in printed matter, the image quality may be permanently noticeable on the printed page and become noticeable. Because. Furthermore, if there is a delay before reaching the printer, white unprinted parts may be formed on the page while the page is moving through the printer, which is unsightly. Therefore, providing results with high quality and high speed is essential, and an approach that relies on the high speed of hardware is preferable to an approach that uses software.

  Second, if all the various operation steps (algorithms) necessary to execute the printing process are listed and the corresponding hardware is listed for each step, the total amount of hardware becomes enormous. It will be very expensive. In addition, the operation speed of hardware is essentially limited by the rate at which data necessary for processing is fetched or data generated by processing is transferred. That is, the operating speed is limited by the bandwidth of the interface.

  On the other hand, in the overall ASIC design, when the total amount of hardware is schematically represented, various parts of the necessary hardware are (a) overlapping, and (b) are executed simultaneously. It is based on the surprising fact that it never happens. In particular, this point is conspicuous in the overhead in transferring data before processing the data.

  From this point of view, through some steps, we decided to reduce the amount of hardware while making all parts of the hardware as active as possible. In the first step, it was recognized that image operations often require the same basic type of iterative computation. Therefore, when data is input in the form of a stream, the processing unit is configured to perform a specific process, a long data stream is processed, and then the processing unit is reconfigured to match the required processing type. If the data stream is quite long, the time required for reconstruction will be negligibly short compared to the overall processing time, thus improving throughput.

  In addition, if a plurality of data processing paths are provided, it is possible to eliminate a waste of time required for reconfiguration by reconfiguring one path while using other paths. That is, while the main data path unit 242 is performing more general processing, if there is JPEG encoding / decoding such as the part 241 in another data path, or if there is an additional part 243, entropy coding or More specialized processing such as Huffman coding can be performed.

  Furthermore, data can be fetched or transferred to a processing site while processing is in progress. In addition, by standardizing and unifying various types of data, the speed can be further increased, and hardware resources can be used effectively. Accordingly, it is possible to reduce the overall overhead related to fetching and transferring data.

  What is important here is that the coprocessor 224 is executed under the control of the host CPU 202 (FIG. 1). In this regard, the instruction control unit 235 controls the entire coprocessor 224. The instruction control unit 235 operates the coprocessor 224 through a control bus 231 called CBus (C bus). The CBus 231 is connected to each of the modules 236-250 including the set register (231 in FIG. 1) in each module, and enables the entire operation of the coprocessor 224. In order to make FIG. 2 easier to see, FIG. 2 does not show connections from the control bus 231 to the respective modules 236-250.

FIG. 3 shows a schematic layout 260 of available module registers. The layout 260 includes a register 261 and an instruction control unit 235 for overall control of the coprocessor 224. The coprocessor module 236-260 includes a similar register 262.
3.2 Host / Coprocessor Queuing According to the architecture described above, it can be seen that sufficient coordination between the host processor 202 and the image coprocessor 204 is required. However, since the solution to this is general and is not specific to the above-described architecture, the following description will be given assuming a more general computing hardware environment.

  Modern computer systems require some form of memory management to perform dynamic memory allocation. In systems with one or more coprocessors, a technique is needed to synchronize between dynamic memory allocation and memory usage by the coprocessor. A typical computer hardware configuration includes a CPU and a special coprocessor, each sharing a series of memory groups. In such a system, only the CPU is the only part of the system that can dynamically allocate memory. When the CPU allocates memory for use by the coprocessor, the coprocessor is free to use the memory until it becomes unnecessary and freed by the CPU. That is, some synchronization is required between the CPU and the coprocessor to ensure that the memory is freed after the coprocessor finishes using the memory. Although various solutions have been shown for this synchronization, it is not necessarily preferable in terms of performance.

  Using statically allocated memory can avoid synchronization problems, but it becomes impossible to dynamically adapt the use of memory resources. Similarly, it is possible to block the CPU and wait until the coprocessor finishes executing the process, but it loses parallelism and sacrifices overall system performance. An interrupt signal for informing the end of processing from the coprocessor can be used, but if the throughput of the coprocessor is very high, a large processing overhead occurs.

  In addition to high performance requirements, such systems must flexibly cope with dynamic memory starvation. In many computer systems, various memory size configurations are possible, but in a system with many memories, it is important to maximize performance by making the best use of effective resources. Similarly, a system with a minimum memory size configuration should be able to operate satisfactorily with a small amount of memory, and the performance should be gracefully degraded at least in the event of a memory shortage.

  To solve these problems, there is a need for a synchronization mechanism that maximizes system performance and dynamically adapts the coprocessor's memory usage to system capacity and complexity of processing to be performed. FIG. 4 shows a preferred configuration for synchronizing the (host) CPU and the coprocessor. The reference numbers in the figure are the same as those used in the description of FIG.

  In FIG. 4, the CPU 202 controls all memory management in the system. The CPU 202 allocates memory 203 for use by itself or the coprocessor 224. The coprocessor 224 has a graphics specific instruction set and can execute instructions 1022 from the memory 203 shared with the host processor 202. Each of these instructions can write the result 1024 to the shared memory 203 and can also read operands from the memory 203. Here, the amount of the memory 203 required to store the operand 1023 of the coprocessor instruction and the result 1024 depends on the complexity and type of processing.

  The CPU 202 also performs processing for generating an instruction 1022 to be executed by the coprocessor 224. In order to maximize parallelism between CPU 202 and coprocessor 224, instructions generated by CPU 202 are queued as shown at 1022 and then executed in coprocessor 224. Each instruction in the queue 1022 can refer to the operand 1023 and the result 1024 in the shared memory 203 allocated by the host CPU 202 for the coprocessor 224.

  As shown in FIG. 5, an instruction generation unit 1030, a memory management unit 1031 and a queue management unit 1032 are connected to perform these processes. All these modules are executed as a single process on the host CPU 202. An execution instruction in the coprocessor 224 is generated in the instruction generation unit 1030, and an area for the operand 1023 of the instruction generated using the service of the memory management unit 1031 and the result 1024 is allocated. The instruction generation unit 1030 uses the service of the queue management unit 1032 to queue instructions to be executed by the coprocessor 224.

  When each instruction is executed in the coprocessor 224, the CPU 202 can release the memory allocated for the operand of the instruction by the memory management unit 1031. The result of one instruction can also be the operand of the next instruction, after which the memory is released by the CPU. Rather than sending an interrupt signal and releasing the memory as soon as the coprocessor 224 finishes the instruction, the cleanup mechanism is activated at some point after the coprocessor 224 finishes the instruction, and the resources required for processing the instruction are reduced. The system releases. The point in time when the cleanup mechanism is activated depends on the relationship between the memory management unit 1031 and the queue management unit 1032 and dynamically depends on the amount of available system memory and the amount of memory required for each coprocessor instruction. Can be adapted.

  FIG. 6 is a diagram schematically showing the configuration of the coprocessor instruction queue 1022. The instruction group is inserted into the pending instruction queue 1040 by the host CPU 202, read by the coprocessor 224, and executed. When the execution process in the coprocessor 224 is completed, the instruction is transferred to the cleanup queue 1041, and after the coprocessor 224 finishes the process, the resources required by the instruction are released.

  The instruction queue 1022 itself is configured as a fixed or dynamic variable size circular buffer. The instruction queue 1022 separates instruction generation by the CPU 202 and execution of instructions in the coprocessor 224. The operand and result memory of each instruction are allocated by the memory management unit 1031 (FIG. 5) in response to a request from the instruction generation unit 1030 at the time of instruction generation. Memory allocation for newly generated instructions activates the cooperative operation of the memory manager 1031 and queue manager 1032 described below, and the system automatically adapts to the amount of available memory and the complexity of the instructions I can do it.

  The instruction queue management unit 102 can wait until the coprocessor 224 finishes executing the instruction generated by the instruction generation unit 1030. However, if the instruction queue 1022 and the memory 203 allocated by the memory management unit 1031 are sufficiently large, there is no need to wait for the coprocessor 224 at all, or at least until all instruction sequences are completed. For large jobs, these waiting times can be several minutes, so the effect is great. However, peak memory usage can easily exceed available memory. At this time, a cooperative operation is started between the queue management unit 1032 and the memory management unit 1031.

  The time when the instruction queue management unit 1032 is instructed to “clean up” the completed instruction and release the dynamically allocated memory may be determined as appropriate. When the memory management unit 1031 detects that the available memory is decreasing or has run out, the queue management unit 1032 is instructed to perform cleanup processing, and the coprocessor 224 releases memory that is no longer used. Take measures. As a result, the memory management unit 1031 can satisfy the memory request for the newly generated instruction from the instruction generation unit 1030 without the CPU 202 waiting for the coprocessor 224 or synchronizing with the coprocessor 224.

  If the memory management unit 1031 issues a request to clean up the end instruction to the queue management unit 1032, but the memory management unit 1031 does not free enough memory to satisfy the new request of the instruction generation unit, the memory management unit 1031 Requests the unit 1032 to wait until a part of the pending command in the pending command queue 1040, for example half, is completed. This blocks CPU 202 processing until some of the coprocessor 224 instructions are complete. When some of the coprocessor 224 instructions are finished, the operands of these instructions are released, and enough memory is available to satisfy the request. By waiting for only some of the instructions being processed, at least some instructions are in the pending instruction queue 1040 and the coprocessor 224 is always running. In many cases, by cleaning up a part of the pending instruction queue 1040 on which the CPU 202 waits, sufficient memory for the memory management unit 1031 is released, and the request of the instruction generation unit 1030 can be satisfied.

  Even in the special case where the coprocessor 224 waits for half of the pending instructions to finish executing, for example, when the memory sufficient to satisfy the request has not been released, the memory management unit 1031 will send all pending coprocessor instructions. Take the last measure of waiting until finished. Except for very large and complex jobs that exceed the current memory capacity of the system, this frees up sufficient resources to satisfy the request of the instruction generator 1030.

  Through such cooperative operation of the memory management unit 1031 and the queue management unit 1032, it is possible to efficiently maximize the throughput in the memory amount 203 given to the system. With more memory, the need for synchronization is reduced and greater throughput can be obtained. Conversely, in the case of less memory, the coprocessor 224 often waits until the processing using the scarce memory 203 is completed, and the performance deteriorates although it operates even if there is little available memory.

The processing steps performed by the memory management unit 1031 when the request from the instruction generation unit 1030 is satisfied are summarized below. Each step is executed in sequence, and after the step, the memory management unit 1031 checks whether sufficient memory 203 is available to satisfy the request. If sufficient memory is available, the request is satisfied and the step ends. If not, proceed to the next step and proceed to more radical processing to satisfy the request.
1. 1. Try to satisfy the request with available memory 203 2. Clean up all finished instructions. 3. Wait for some pending commands to finish Wait for all pending instructions to finish Note that waiting for a different part of the pending instruction (eg, 1/3 or 2/3) or using a lot of memory to satisfy the request. Other options can be used, such as waiting for a specific command.

  In FIG. 7, in addition to the cooperative operation between the memory management unit 1031 and the queue management unit 1032, the queue management unit 1032 may synchronize with the coprocessor 224 when the fixed-length instruction queue buffer 1050 overflows. it can. FIG. 7 shows such a situation, and the pending instruction queue 1040 is a queue of instructions having a length of ten. Since the latest instruction to be added has the largest number, the latest instruction is stored in position 9 when the area overflows. The next command input to coprocessor 224 is waiting at position 0.

When the area overflows, the queue management unit 1032 waits until the coprocessor 224 finishes, for example, half the processing of the pending command. By this standby, sufficient area necessary for a new instruction that is normally inserted by the queue management unit 1032 is released. The operation of the queue management unit 1032 when scheduling a new instruction is as follows.
1. 1. Test whether enough space remains in the instruction queue 1040. 2. If there is not enough space left, wait until the coprocessor finishes a certain number of instructions. Inserting a new instruction into the queue The operation of the queue management unit 1032 instructed to wait for a certain instruction to end is as follows.
1. 1. Wait until the coprocessor 224 indicates that the instruction is complete When there is a finished instruction that has not been cleaned up, the operation of the instruction generation unit 1030 when generating a new instruction that deletes the next finished instruction from the queue is as follows.
1. 1. Requests memory management unit 1031 for memory required for instruction operand 1023. 2. Generate instructions to transfer. An example in which the above-described operation process is transferred in the form of pseudo code is shown below.

Memory management ALLOCATE_MEMORY
BEGIN
If there is not enough memory available to satisfy the IF request, THEN cleans up all the terminated instructions.
If there is not enough memory available to satisfy the IF request, call THEN WAIT_FOR_INSTRUTION and wait for the end of half the pending instruction.
If there is not enough memory available to satisfy the IF request, output a THEN error and return. ENDIF Return the allocated memory. Queue management SCHEDULE_INSTRUTION
BEGIN
If there is not enough space in the IF instruction queue, THEN waits for a certain number of instructions until the coprocessor finishes ENDIF Adds new instructions to the queue END
WAIT_FOR_INSTRUTION (i)
BEGIN
Wait until instructed by the coprocessor that instruction i has finished WHILE There are instructions that have finished but have not been cleaned up DO
IF The next finished instruction has a cleanup function. THEN Calls the cleanup function. ENDIF Deletes the finished instruction from the queue. DONE
END
Instruction generator GENERATE_INSTRUTIONS
BEGIN
Call ALLOCATE_MEMORY and allocate the memory required for the instruction operand in the memory management unit. Generate a transfer instruction. Call SCHEDULE_INSTRUTION, transfer the coprocessor instruction to the queue management unit, and execute it. END
3.3 Coprocessor Register Description As described in FIGS. 1 and 3, the coprocessor 224 includes a plurality of registers for executing each instruction stream.

For the modules in FIG. 2, Table 1 shows the names, types and descriptions of the registers used in the coprocessor 224, and Appendix B describes the fields of each register.
Register description

Of these registers, the following are worth noting.
(A) Instruction pointer registers (ic_ipa and ic_ipb). These register pairs store virtual addresses of currently executing instructions. Instructions are fetched and executed in ascending order of virtual addresses. A jump instruction is used when the control moves to a discontinuous virtual address. Each instruction is given a 32-bit sequence number, and the sequence number is incremented by one for each instruction. The sequence number is used in both the coprocessor 224 and the host CPU 202 to synchronize instruction generation and execution.
(B) End registers (ic_fna and ic_fnb). These register pairs store the sequence number of the finished instruction.
(C) ToDo registers (ic_tda and ic_tdb). These register pairs store the sequence numbers of the queued instructions.
(D) Interrupt registers (ic_inta and ic_intb). These register pairs store the sequence numbers to be interrupted.
(E) Interrupt status registers (ic_stat.a_primed and ic_stat.b_primed). These register pairs store a prime bit which is a flag for starting an interrupt when the interrupt and end register match. This bit is stored in the same manner as other interrupt enable bits and other state / configuration information in the interrupt status (ic_stat) register.
(F) Register access semaphores (ic_sema and ic_semb). The host CPU 202 must obtain a semaphore prior to register access that requires high speed to the coprocessor 224, that is, one or more register writes. On the other hand, register access that does not require high speed can be executed at any time. A drawback associated with obtaining a semaphore by the host CPU 202 is that execution of the coprocessor is suspended until the currently executing instruction is completed. The register access semaphore is configured as one bit of the configuration / status register of the coprocessor 224. These registers exist in the register area of the instruction control beauty. As described above, each sub-module of the coprocessor includes a configuration / status register, and the register is set in normal instruction execution. All these registers are represented on the register map, and many are implicitly modified in instruction execution. The host can know the contents of these registers via the register map.
3.4 Multiple Stream Format As described above, the coprocessor 224 executes one of two independent instruction streams for maximum effective use of resources and for high speed output to external peripheral devices. . Typically, one instruction stream corresponds to the current output page that the output device needs at the right time, and the second instruction stream is a module of the coprocessor 224 when the other instruction stream is paused. Is used. Here, the most important point is to output necessary output data at a suitable time, and to make maximum use of resources for preparation of subsequent pages, bands, and the like. Thus, the coprocessor 224 is designed to execute two instruction streams (hereinafter referred to as A and B) that are completely independent but executed in the same way. The instructions are preferably generated by software running on the host CPU 202, transferred to the raster image accelerator card 220, and executed by the coprocessor 224. In normal operation, one of the instruction streams (stream A) operates at a higher priority than the other instruction stream (stream B). The instruction stream or queue is written to one or more buffers in the host RAM 203 (FIG. 1). The buffer is allocated at the start time, and is fixed to the physical memory of the host 203 during execution of the application. Each instruction is preferably stored in a virtual memory environment of the host RAM 203, and the raster image coprocessor 224 performs conversion from a virtual address to a physical address, and determines a corresponding physical address in the host RAM 203 as the position of the next instruction. To do. These instructions are sequentially stored in the local memory of the coprocessor 224.

FIG. 8 is a diagram showing the formats of two streams A and B stored in the host RAM 203. The formats of streams A and B are essentially the same. A simple execution model in the coprocessor 224 consists of:
* Two instruction virtual streams of A stream and B stream * Normally, only one instruction is executed at a certain point. * Either stream can have priority or "round robin" priority. * Alternatively * You can "lock" one of the streams to ensure that it is executed regardless of the stream priority and the instruction executability of the other stream * Either stream is empty May be * Either stream may be unavailable * Either stream is "overlapping" with the execution of the next instruction unless the subsequent instruction is "overlapping" * Each instruction has a "unique" sequence number that increments by 32 bits. * Each instruction is an interrupt or instruction * In order to minimize the influence of the delay of the external interface, an instruction may be fetched in advance. The instruction control unit 235 controls the entire execution of the coprocessor 224. In order to fetch an instruction from the host RAM 203 when necessary, a coprocessor instruction execution model is implemented. For each instruction, the instruction control unit 235 decodes the instruction, configures various registers in the module via the CBus 231, and performs processing for causing the corresponding module to execute the instruction.

FIG. 9 is a diagram showing the instruction execution cycle executed by the instruction control unit 235 in a simple form. The instruction execution cycle consists of four main stages 276-279. In the first stage 276, it is checked whether the instruction is pending in the instruction stream. If it is pending, the instruction is fetched 277, decoded and executed 278, and the register is updated 279.
3.5 Determining the current active stream In the first stage, two steps must be performed.
1. 1. Determine if the instruction is pending Determining which instruction stream to fetch next To determine which instruction is pending, examine the following possibilities:
1. 1. Whether the instruction control unit is enabled 2. Whether the instruction control unit is paused due to an internal error or interrupt. Whether there are any pending external error conditions 4. Whether A or B stream is locked Whether either stream sequence number is enabled Whether or not either stream has a pending instruction The pseudo code shown below shows an algorithm for determining whether an instruction is pending based on the above rules. This algorithm can be implemented as hardware in the instruction control unit 235 via a state transition machine using a known technique.

If not in error mode, in operation mode, in bypass mode, in self-diagnostic mode, if A stream is locked and not inactive if A stream is in operation mode, Instruction is in pause or in A stream "
Instruction is pending else instruction is not pending end if
else if B stream is locked and not inactive if B stream is in active mode and “Sequence number of B stream is inactive or there is an instruction in B stream”
Instruction is pending else instruction is not pending end if
else / * stream is not locked * /
if A stream is not paused in active mode and “Sequence number of A stream is paused or there is an instruction in A stream”
Instruction is pending else instruction is not pending end if
end if
else / * Interface control unit is not running * /
Instruction not pending end if
If no command is pending, the command control unit 235 will be "spinned" or idle until a pending command is found.

The next state is examined to determine which stream is active and which stream is to be executed next.
1. 1. Which stream is locked? 2. Which priority is given to the A and B streams, and which is the last instruction stream executed? 3. Which stream is running? Which stream has a pending instruction The following shows the pseudo code implemented by the instruction control unit and how to determine the next active stream.

if A stream is locked The next stream is A
else if B stream is locked The next stream is B
else / Neither stream is locked * /
if A stream is in active mode and “A stream sequence number is paused or there is an instruction in A stream” and “B stream is in active mode and“ B stream sequence number is paused or B If there is no instruction in the stream, the next stream is A
else if B stream is in operation mode and “B stream sequence number is paused or there is a pending command in B stream” and “A stream is in operation mode and“ A stream sequence number is paused ” ,
Or, if there is no instruction in the A stream, the next stream is B
else / * Neither stream has instructions * /
if pri = 0 / * A high, B low * /
The next stream is A
else if pri = 1 / * A low, B high * /
The next stream is B
else if pri = 2or3 / * round robin * /
if the last stream is A
The next stream is B
else
The next stream is A
end if
end if
end if
end if
Since conditions are constantly changing, all conditions need to be examined in a short time.
3.6 Fetch Instruction for Current Active Stream When the next active instruction stream is determined, the instruction control unit 235 fetches an instruction using the address in the corresponding instruction pointer register (ic_ipa and ic_ipb). However, if a valid instruction already exists in the prefetch buffer in the instruction control unit 235, the instruction control unit 235 does not fetch the instruction.

The instruction in the prefetch buffer becomes valid when the following conditions are met.
1. 1. The prefetch buffer is valid. The instruction in the prefetch buffer is from the same stream as the current active stream The validity of the contents of the prefetch buffer is represented by the prefetch bit in the ic_stat register, which is when the instruction prefetch is successful Set to Note that external writing to any register of the instruction control unit 235 invalidates the contents of the prefetch buffer.
3.7 Decoding and Executing Instruction When an instruction is fetched and accepted, the instruction control unit 235 configures the register 229 of the coprocessor 224 to decode the instruction and execute the instruction.

  The instruction format used in the raster image coprocessor 224 differs from the conventional processor instruction set in that instruction generation is performed by instructions from the host CPU 202 and is a direct overhead to the host. Further, since the instruction is stored in the host RAM 203 and transferred to the coprocessor 224 via the PCI bus 206 of FIG. 1, the instruction should be as small as possible. Preferably, coprocessor 224 is initiated by a single instruction. It is also desirable to retain the flexibility of the instruction set as much as possible in order to be able to cope with future changes to the maximum extent. In addition, the instructions executed in the coprocessor 224 are preferably applicable to long streams of operand data so that optimum performance is obtained. As the instruction decoding “philosophy” used by the coprocessor 224, the “general instruction” is decoded simply and at high speed, and the operation of the coprocessor 224 is also fine for “unusual” processing. Designed to allow the host system to control.

  FIG. 10 shows a single instruction 280 format consisting of 8 words each of 32 bits. Each instruction includes an instruction word (opcode) 281 and an operand or result type data word 282 indicating the type of operand. Addresses 283-285 for the three operands A, B, C are also included along with the result address 286. Further, an area 287 is also included for storing information relating to instructions used by the host CPU 202.

  FIG. 11 is a diagram showing a structure 290 of the instruction opcode 281 of the instruction. The instruction opcode is 32 bits long, and main opcode 291, complementary opcode 292, interrupt (I) bit 293, partial decode (Pd) bit 294, register length (R) bit 295, lock (L) bit 296, length 297 including. A description of each field of the instruction word 290 is shown in the following table.

  Opcode explanation

  By setting the I bit field 293, the instruction can be coded such that execution of the instruction is interrupted and paused when the instruction is finished. This interrupt is called an “instruction end interrupt”. The partial decode bit 294 is a bit such that when the partial decode bit 294 bit is set and an operation mode is set in the ic_cfg register, various modules are microcoded prior to instruction execution as described below. Provides partial decoding function. The lock bit 296 is used for processing that requires one or more instructions to start. In this case, various registers are set prior to the instruction and the current instruction stream is "locked" for the next instruction. When the L bit 296 is set, the next instruction is fetched from the same stream when the instruction ends. The length field 297 is a general definition of each instruction, is defined as the number of necessary “input data items” or “output data items”, and is 16 bits long. In the case of processing for a stream of input data items of 64,000 items or more, the R bit 295 is set and the input length is obtained from the po_len register in the pixel organizer 246 of FIG. The register is set immediately before such an instruction.

In FIG. 10, the number of operands 283 to 286 required for a certain instruction is variable depending on the instruction type used. The following table shows the number of operands and length definitions for each instruction type.
Operand type

FIG. 12 shows the data word of FIG. 10 for a three operand instruction, the data word format 300 of the operand descriptor 282, and the data word format 301 for a two operand instruction. The following table details the encoding of the operand descriptor.
Operand descriptor

  In the above table, in the constant data address mode, the coprocessor 224 fetches or calculates one internal data item and uses this item as the instruction length of the operand. In the tile address mode, the coprocessor 224 cycles through some data to obtain a “tile effect”. If the L bit in the operand descriptor is zero, it means that the data is short and the data item is present in the operand word.

  In FIG. 10, each operand / result word 283-286 includes a 32-bit virtual address indicating the starting position of the operand / result in which the value or data of the operand itself is stored. The instruction control unit 235 in FIG. 2 decodes the instruction in two stages. First, it is checked whether the main opcode of the instruction is valid. If the main opcode (FIG. 11) is invalid, an error is generated. Next, by setting various registers via the CBus 231, the instruction control unit 235 executes the instruction and performs the operation specified in the instruction. Some instructions do not have a register to set.

  The registers of each module are divided into several types according to the operation. First, there is a status register type, which is “read only” from other modules and “read / write” by the module containing the register. Next, the first type of configuration register (hereinafter config1) is “read / write” externally from the module and “read only” from the module containing the register. These registers are generally used when storing large type configuration information such as address values. The second type of configuration register (hereinafter config2) can be read and written from all modules, but can only be read from the module containing the register. This register type is used when bitwise addressing of a register is required.

  There are various types of control type registers. The first type (hereinafter, control 1 register) can be read / written by all modules (including modules including registers). The Control1 register is used when storing large control information such as an address value. Similarly, the second type of control register (hereinafter, control 2) is set for each bit.

  The last register type (interrupt register) is set to 1 by the module containing the register and contains a bit in the register that can be reset to zero by externally writing a “1” to the set bit. These types of registers are used to handle interrupt / error signals from the respective modules.

  Each module of the coprocessor 224 sets the c_active line on the CBus 231 when an instruction is being executed and is busy. For this reason, the instruction control unit 235 can take the “OR” of the c_active line from each module on the CBus 231 and grasp the time point when the instruction is completed. The local memory control module 236 and the peripheral interface control module 237 can execute an overlap instruction, and include a c_background line that is activated when the overlap instruction is executed. The overlap instruction is a “local DMA” instruction that transfers data between the local memory interface and the peripheral interface.

  The execution cycle of the overlap local DMA instruction is different from the execution cycle of other instructions. When the overlap instruction is executed, the instruction control unit 235 checks whether the overlap instruction has already been executed. If the overlap instruction already exists, or if the overlap instruction is in the inoperative mode, the instruction control unit 235 waits for the instruction to end before proceeding to execute the instruction. If there is no overlap command and the operation mode is set, the command control unit 235 immediately decodes the overlap command, configures the peripheral interface control unit 237 and the local memory control unit 236, and executes the command. After completing the configuration of the registers, the instruction control unit 235 updates the registers (end register, status register, instruction pointer, etc.) without waiting for the instruction to end in the conventional sense. At this time, if the end sequence number is the same as the interrupt sequence number, the “overlap instruction end” interrupt signal is not output but the signal is simply prepared. The “overlap instruction end” interrupt signal is output when the overlap instruction is completely completed.

When the instruction is decoded, the instruction control unit prefetches the next instruction while executing the current instruction. For most instructions, the time required to execute an instruction is considerably longer than the fetching and decoding of the instruction. The instruction control unit 235 prefetches an instruction when the following conditions are met.
1. The currently executing instruction is not interrupted or paused. 2. The instruction currently being executed is not a jump instruction. 3. The next instruction stream can be prefetched. If there is another pending instruction, the instruction control unit 235 determines that prefetching is possible, issues a request to the next instruction, places it in the prefetch buffer, and validates the buffer. When the processing is advanced so far, the instruction control unit 235 does nothing until the currently executed instruction is ended, and only checks the c_active and c_background lines on the CBus 231 for the end of the instruction.
3.8 Instruction Controller Register Update When the instruction is complete, the instruction controller 235 updates the register to reflect the new state. This process must be performed at high speed to avoid synchronization problems with external access. This high-speed update process is performed according to the following procedure.
1. Obtain the appropriate register access semaphore. When the semaphore is occupied by an agent external to the instruction control unit 235, the instruction execution cycle waits until the semaphore is released, and the process proceeds after being released.
2. Appropriate register updates. If the instruction is not an appropriate jump instruction, the instruction pointers (ic_ipa and ic_ipb) are increased by the size of the instruction. In the case of a jump instruction, the jump destination value is loaded into the instruction pointer. Therefore, if the sequence number is the operation mode, the end registers (ic_fna and ic_fnb) are increased.

The status register (ic_stat) is also updated appropriately to reflect the new state. If necessary, the pause bit may be set. When an interrupt occurs and the pause for the interrupt becomes active or an error occurs, the instruction control unit 235 pauses. Pause is activated by setting the instruction stream pause bits (a_pause and b_pause) in the status register. When resuming instruction execution, these bits must be reset to zero.
3. Send c_end signal on CBus 231 for a clock cycle time to inform other modules in coprocessor 224 that the instruction is complete.
4). Send interrupts if necessary. Interrupts are sent in the following situations.
a. When the “sequence number end” interrupt occurs. That is, when the end register (ic_fna and ic_fnb) sequence number matches the interrupt sequence number. At this time, an interrupt is prepared, the sequence number enters the operation mode, and an interrupt occurs. Or
b. The finished instruction is coded to interrupt at the end. In this case, the interrupt mechanism is activated.
3.9 Register Access Semaphore Semantics A register access semaphore is a mechanism that provides fast access to multiple instruction control registers. Examples of registers that require high-speed access include the following.
1. Instruction pointer registers (ic_ipa and ic_ipb)
2. ToDo registers (ic_tda and ic_tdb)
3. End registers (ic_fna and ic_fnb)
4). Interrupt registers (ic_int and ic_intb)
5). Pause bit (ic_cfg) in configuration register
The foreign agent can read all registers safely at any time. Also, the external agent can write to all registers at any time, but the external agent must first obtain a register access semaphore so that the instruction control unit 235 does not update the values in these registers. . The instruction control unit cannot update the value in the register while the register access semaphore is declared externally. In addition, the instruction control unit 235 updates all the above-described registers during one clock cycle in order to maintain high speed.

As described above, when the sequence mechanism is in the operation mode, a 32-bit “sequence number” is assigned to each instruction. The instruction sequence number increases sequentially and is wrapped from 0xFFFFFFFF to 0x00000000. When an external write is made to the interrupt registers (ic_inta and ic_intb), the instruction control unit 235 immediately performs the following comparison and update.
1. If the interrupt sequence number (value in the interrupt register) is “larger” (modulo operation) than the end sequence number (value in the end register) of the same stream, the instruction control unit prepares the “sequence number end” preparation bit in the status register By setting (a_primed and b_primed bits in ic_stat), the “sequence number end” interrupt mechanism is prepared.
2. If the interrupt sequence number is “smaller” than the end sequence number, an overlap instruction is being executed in the stream, and the interrupt sequence number is the same as the last overlap instruction sequence number (the value in the ic_loa or ic_lob register) The instruction control unit prepares an “overlapping instruction sequence number end” interrupt mechanism by setting the a_ol_primed or b_ol_primed bit in the ic_stat register.
3. If the interrupt sequence number is “smaller” than the end sequence number, an overlap instruction is being executed in the stream, and the interrupt sequence number is not the same as the last overlap instruction sequence number, the interrupt sequence number indicates the end instruction. As a result, no interrupt mechanism is prepared.
4). If the interrupt sequence number is “smaller” than the end sequence number and the overlap instruction is not being executed in the stream, the interrupt sequence number indicates the end instruction, and no interrupt mechanism is prepared.

The external agent can set the interrupt preparation bits (a_primed, a_ol_primed, b_primed, b_ol_primed bits) in the status register, and can activate and cancel the interrupt mechanism independently.
3.10 Command Control Unit FIG. 13 is a diagram showing the command control unit 235 in more detail. The instruction control unit 235 includes an execution control unit 305 that processes an instruction execution cycle and manages overall execution control of the coprocessor 224. The execution control unit 305 manages overall execution control of the instruction control unit 235, determines an instruction sequence, fetches and prefetches instructions, decodes instructions, and updates an instruction control register. The instruction control unit further includes an instruction decoder 306. The instruction decoder 306 receives the instruction from the prefetch buffer 307 and decodes it as described above. The instruction decoder 306 also performs processing for configuring instructions in other coprocessor modules and executing instructions. The prefetch buffer control unit 307 manages reading and writing from the prefetch buffer in the prefetch buffer control unit, and also manages an interface between the instruction decoder 306 and the input interface switch 252 (FIG. 2). . The prefetch buffer control unit 307 also manages updating of the two instruction pointer registers (ic_ipa and ic_ipb). Access to the CBus 231 (FIG. 2) from the instruction control unit 235, various modules 239 (FIG. 2), and the external interface control unit 238 (FIG. 2) is “CBus” which performs arbitration between access requests of three modules. This is performed in the arbitration unit 308. The request is transferred by CBus 231 to the register units of various modules.

FIG. 14 is a diagram showing the execution control unit 305 of FIG. 13 in more detail. As described above, the execution control unit manages the processing of the instruction execution cycle 275 in FIG. 9, and particularly performs the following processing.
1. Determine which instruction stream to fetch the next instruction from,
2. Start fetching the instruction,
3. Instructs the instruction decoder to decode the instruction stored in the prefetch buffer,
4). Decide and start prefetching the next instruction,
5). Determine the end of the instruction,
6). When the instruction is finished, the register is updated.

  The execution control unit includes a large core state machine 310 (hereinafter referred to as a central part) that manages the entire instruction execution cycle. FIG. 15 is a diagram showing a state transition diagram of the central part 310 for managing the above instruction execution cycle. In FIG. 14, the execution control unit includes an instruction prefetch logic unit 311. This part determines whether there is an instruction to be executed and which instruction stream the instruction belongs to. The start 312 and prefetch 313 states in the transition diagram of FIG. 15 use this information to obtain instructions. The register management unit 317 in FIG. 14 monitors the register access semaphores of both instruction streams and performs a process of updating all necessary registers in each module. The register management unit 317 also performs processing for comparing the end registers (ic_fna and ic_fnb) with the interrupt registers (ic_inta and ic_intb) and determining whether or not the “sequence number end” interrupt should be performed. Further, the register management unit 317 also performs interrupt preparation processing. The overlap instruction unit 318 manages the end process of the overlap instruction through management of an appropriate status bit in the ic_stat register. The execution control unit further includes a decoding interface unit 319 that performs an interface between the central unit 310 and the instruction decoder 306 of FIG.

  FIG. 16 shows the instruction decoding unit 306 in more detail. The instruction decoder constitutes a coprocessor and performs processing for executing instructions in the prefetch buffer. The instruction decoder 306 comprises an instruction decode sequencer 321 composed of a large state machine that is a combination of many small state machines. The instruction sequencer 321 communicates with the CBus dispatcher 312 that sets the registers in each module. Further, the instruction decoding sequencer 321 transmits related information such as instruction validity and instruction overlap status to the execution control unit. Here, the instruction validity check is to check whether the instruction opcode is a reserved opcode.

  FIG. 17 is a diagram showing the instruction dispatcher sequencer 321 of FIG. 16 in more detail. The instruction dispatcher sequencer 321 includes an overall sequence control state machine 324 and a continuous module-by-module sequencer state machine (eg, 325 or 326). A per-module configuration sequencer state machine is provided for each module to be configured. Overall, the state machine defines the coprocessor microprogramming of modules. A state machine (eg, 325) instructs the CBus dispatcher to set various registers using the entire CBus and configures various modules for processing. In order to write to a particular register, the execution of the instruction must be started. In general, execution of instructions requires more time than the sequencer 321 configures the coprocessor registers for processing. Appendix A shows the microprogramming process performed by the instruction sequencer of the coprocessor and the format set up by the instruction sequencer 321.

  Actually, the instruction decoding sequencer 321 does not constitute all the modules in the coprocessor for each instruction. In the following table, the module configuration order for instruction classes is as follows: pixel organizer 246 (PO), data cache controller 240 (DCC), operand organizer B247 (OOB), operand organizer C248 (OOC), main data path 242 (MDP). The result organizer 249 (RO), the JPEG encoder 241 (JC), and other modules are shown. Modules such as the external interface control unit 238 (EIC), local memory control unit 236 (LMC), instruction control unit 235 itself (IC), input interface switch 252 (IIS), miscellaneous module (MM), etc. are subjected to instruction decoding processing. It is never configured inside.

  Module startup sequence

  In FIG. 17, each module configuration sequencer (for example, 325) performs necessary register access processing and manages to configure a specific module. The overall sequence control state machine 324 manages the overall operation of the module configuration sequencer in the order described above. FIG. 18 is a diagram showing the overall sequence control for activating the related module configuration sequencer according to the above table as a state transition diagram 330. Each module configuration sequencer controls the CBus dispatcher to change the register contents in order to set various registers during execution of the module.

FIG. 19 is a diagram showing the prefetch buffer control unit 307 of FIG. 13 in more detail. The prefetch buffer controller includes a prefetch buffer 335 for storing a single coprocessor instruction (6 × 32 bit word). The prefetch buffer has one write port controlled by the IBus sequencer 336 and one read port for sending data to the instruction decoder, execution control unit, and instruction control unit CBus interface. The IBus sequencer 336 monitors the bus protocol at the connection of the prefetch buffer 335 to the input interface switch. An address management unit 337 that generates an address for fetching an instruction is also provided. The address management unit 337 has a function of selecting one of ic_ipa or ic_ipb and connecting it to the bus to the input interface switch, and a function of increasing one of ic_ipa or ic_ipb based on from which stream the last instruction is fetched And a function of storing the jump destination address in the ic_ipa and ic_ipb registers. The PBC control unit 339 controls the prefetch buffer control unit 307 as a whole.
3.11 Description of Module Local Register File As shown in FIG. 13, each module including the instruction control module itself includes an internal set of the register 304 described above together with the CBus interface control unit 303 shown in FIG. A process of accepting the request and updating the internal register in response to the request is performed. The module is controlled by writing to the register 304 in the module via the CBus interface 302. The CBus adjustment unit 308 (FIG. 13) determines which of the instruction control unit 235, the external interface control unit, and the miscellaneous module controls the CBus, operates as a CBus master, and writes / reads a register.

  FIG. 20 is a diagram showing a standard configuration of the CBus interface 303 used in each module. The standard CBus interface 303 includes a register file 304 that receives read requests and write requests from the CBus 302 and is updated via 341 by various submodules in the module. Further, a control line 344 for updating the memory area of the submodule including reading of the memory area is provided. The standard CBus interface 303 behaves as a CBus destination and accepts read requests and write requests for the memory objects of the register 304 and other submodules.

  A “c_reset” signal 345 sets all registers in the standard CBus interface 103 to a default state. However, “c_reset” does not reset the state machine that controls the exchange of signals between itself and the CBus master. Therefore, even if “c_reset” is transmitted during the CBus process, the process ends in some form. The “c_int” 347, “c_exp” 348, and “c_err” 349 signals are generated from the contents of the modules err_int and err_int_en registers based on the following equations.

Signals “c_sdata_in” and “c_svalid_in” 345 are data / valid signals from the previous module in the module row, and signals “c_sdata_out” and “c_svalid_out” 350 are to the next module in the module row. Data / valid signal. The functions of the standard CBus interface 303 include the following.
1. 1. Register read / write management 2. Read / write management of memory area 3. Test mode read / write management Submodule monitoring / update management 3.12 Register read / write management The standard CBus interface 303 accepts register read / write requests and bit set requests that flow on the CBus. There are the following two types of CBus commands managed by the standard CBus interface.
1. Type A
In type A, other modules operate to read / write 1, 2, 3, and 4 bytes to the register in the standard CBus interface 303. In a write operation, a data cycle occurs in the clock cycle immediately after the instruction cycle. The register write / read type fields are “1000” and “1001”, respectively. The standard CBus interface 303 decodes the instruction and checks whether the instruction points to the address of the module or is a read / write operation. In a read operation, the standard CBus interface 303 uses the “reg” field of the CBus process to select which register output is connected to the “c_sdata” bus 350. In a write operation, the standard CBus interface 303 writes data to the register selected using the “reg” field and the “byte” field. When the read operation ends, the standard CBus interface returns “c_svalid” 350 at the same time as returning the data. When the writing operation is completed, the standard CBus interface 303 sends “c_svalid” 350 and returns a response.
2. Type C
In type C, another module writes one bit or a plurality of bits to one byte in one register. Instruction and data are combined into one word.

The standard CBus interface 303 checks the instruction to see if the instruction points to the module address. Further, the “reg”, “byte”, and “enable” fields are decoded to generate a necessary enable signal. Also, the data field of the instruction is extracted, and the extracted data is transferred to all 4 bytes of the word. This causes the necessary bits to be written to the enable bits in all enable bytes. No response is necessary for this operation.
3.13 Memory Area Read / Write Management The standard CBus interface 303 accepts memory read / write requests on the CBus. When a memory read / write request is received, the standard CBus interface 303 checks whether the request points to the module address. Then, by decoding the address field of the instruction, the standard CBus interface generates an appropriate address and an address strobe signal 344 to the submodule that performs memory read / write. In a write operation, the standard CBus interface transfers the byte enable signal from the instruction to the submodule.

  The operation of the standard CBus interface 303 is to decode the type field of the CBus instruction on the CBus 302 so that in the next cycle the data is captured in the register file 304 or transferred to another submodule 344. The read / write control unit 352 generates appropriate enable signals for the register file 304 and the output selector 353. If the CBus instruction is a register read operation, the read / write control unit 352 enables the output selector 353 and selects the correct register output to the “c_sdata bus” 345. If the instruction is a register write operation, the read / write control unit 352 enables the register file 304 and then selects data in a cycle. If the instruction is a read / write of a memory area, the read / write control unit 352 generates an appropriate signal 344 and controls a memory area managed by the module. The register file 304 includes four parts: a register selection decoding unit 355, an output selector 353, an interrupt 356, an error 357, an exception 358 generation unit, an unmask error generation unit 359, and a register unit 360 that constitutes a register of a module. . The register selection decoding unit 355 decodes the signals “ref_en” (register file enable) “write” and “reg” from the read / write control unit 352, and generates a register enable signal for enabling a certain register. The output selector 353 selects correct register data for register read processing in accordance with the output of the signal “reg” from the read / write control unit 352, and outputs it to the c_date_out line.

The exception generation units 356 to 359 generate output error signals (for example, 347 to 349 and 362) when an error is detected during input. The method for calculating each output error is as described above. The register unit 360 can be of various types as required as discussed in Table 5 when describing the configuration of the register set.
3.14 CBus Configuration As described above, the CBus (control bus) controls each module as a whole by transferring information for setting registers in the standard CBus interface of each module. As is clear from the description of the standard CBus interface, CBus has the following two purposes.
1. 1. Control bus that drives each module RAM, FIFO, access bus for status information in each module The CBus controls the module by setting configuration registers in the module using an instruction-address-data protocol. In general, registers are set for each instruction, but modifications can be made at any time. The CBus collects status information and other information and requests data from various modules to access RAM and FIFO data.

The CBus is driven for each process by one of the following three methods.
1. Instruction control unit 235 during instruction execution (FIG. 2)
2. External interface controller 238 (FIG. 2) when executing the target (slave) mode bus operation
3. When the external CBus interface is configured, in any case of the external device, the drive module is a CBus source module, and all other modules are possible destination modules. The instruction control unit performs bus adjustment processing.

The following table shows one definition of a CBus signal that is suitable for use in the preferred embodiment.
CBus signal definition

The CBus c_iad signal contains address data and is driven by the controller in two different cycles.
1. Instruction cycle in which CBus instruction and address are driven on c_iad (c_valid high)
2. Data cycle in which data is driven on c_iad (write operation) or c_sdata (read operation) (c_valid low)
For a write operation, the data for the instruction is placed on the c_iad bus immediately after the instruction cycle. In the case of a read operation, the target module for the read operation drives the c_sdata signal until the data cycle is completed.

In FIG. 21, the bus includes a 32-bit instruction-address-data field. This field has the following three types (370 to 372).
1. The type A operation (370) is used to read / write a register in the coprocessor and a data area of each module. These operations are generated by the external interface control unit 238 executing the target mode PCI cycle, the instruction control unit 231 configuring the coprocessor for the instruction, and the external CBus interface.

In these operations, the clock cycle immediately after the instruction cycle is the data cycle.
2. Type B operation (371) is used in diagnostic mode to access local memory and generate cycles on the general interface. These operations are generated by the external interface control unit or the external CBus interface executing the target mode PCI cycle. The data cycle can be any time after the instruction cycle, and the data cycle is returned from the destination module using the c_svalid signal.
3. Type C operation (372) is used to set each bit in the module's register. These operations are generated by an instruction control unit 231 and an external CBus interface that constitute a coprocessor for instructions. In Type C operation, there is no data cycle, and data is included in the instruction cycle.

The type field of each instruction is an encoding of the associated CBus process according to the following table.
CBus processing type

  The byte field is used to set a bit in the register. The module field is a field for designating an address destination module of an instruction on the CBus. The register field is a field for designating which register in the module is updated. The address field is used for designating an address such as RAM or FIFO, which is a field for designating a memory part to be operated. The enable field is a field that enables a selected bit in a selected byte when a bit setting instruction is used. The data field contains bit data that is written to the byte to be updated.

As described above, the CBus includes, for each module, a c_active line that is sent when the module is executing an instruction. The command control unit can know the end time of the command based on this signal. In addition, the CBus includes a c_background line that operates in the background mode for each module, together with reset, error detection, and reset for performing interrupts, errors, and interrupt lines.
3.15 Coprocessor Data Type and Data Manipulation In FIG. 2, to simplify the operation of the coprocessor unit 224, particularly the main computational operations in the JPEG encoder 241 and the main data path coprocessor, Use a data model that differentiates between external and internal formats. The external data format is a data format that appears on an external interface of a coprocessor such as a local memory interface or a PCI bus. Conversely, the internal data format is a format that appears between the main functional modules of the coprocessor 224. FIG. 22 is a diagram schematically showing various input / output formats. The input external format 381 is an input format to the pixel organizer 246, operand organizer B247, and operand organizer C248. These organizers reformat the input external format into an input internal format 382 that is input to the JPEG encoder 241 and the main data path unit 242. These two functional units output the output data in the output internal format, and the result organizer 249 converts the output internal format into the desired output format 304.

  In the embodiment, the external data format is divided into three types. The first type is a “pack stream” of data consisting of a continuous stream with up to four channels per data, each channel consisting of 1, 2, 4, 8 or 16 bit samples. is there. The pack stream is used to represent pixels, data to be converted into pixels, collected bits, and the like. The coprocessor uses little endian byte addressing and big endian bit addressing in the byte. FIG. 23 shows a first example of the pack stream format. Here, each object 387 includes three channels of channel 0, channel 1, and channel 2 of 2 bits for each channel. The data arrangement of this format is 388. In the next example 390 of FIG. 24, a 4-channel object 395 is shown with each data object having a 32-bit word and 8 bits per channel. In the third example 395 of FIG. 25, a channel object 396 is shown having 8 bits per channel starting at bit address 397. Of course, depending on the application, the actual width and number of data channels will vary.

  The second type of external data format is an “unpacked byte stream”, which is a sequence of 32-bit words such that only one byte in each word is valid. An example of this format is shown as 399 in FIG. 26, where only a single byte 400 in each word is used. Further external data formats are represented by objects classified as “other” formats. Generally, these data objects are large tabular data such as a color space conversion table and a Huffman encoding table.

  The coprocessor uses four internal data types. The first type is a “packed byte” format, which consists of a 32-bit word of 4 active bytes, excluding the last 32-bit word. FIG. 27 shows an example 402 of packed byte format in which a word is 4 bytes. The next data type shown in FIG. 28 is the “pixel” format, which consists of a 32-bit word 403 with 4 active byte channels. This pixel format is interpreted as four channel data.

  The next internal data type shown in FIG. 29 is an “unpacked byte” format, where each word is a format consisting of one active byte channel 405 and three inactive byte channels. In this case, the active byte channel occupies the smallest byte. Other internal data objects are classified as “other” data formats. Input data in external format is converted to an appropriate internal format. FIG. 30 shows the conversion form from the external format 410 to the input format 411 executed by various organizers. FIG. 31 shows a conversion form from the internal format 412 to the external format 413 executed by the result organizer 249.

  Hereinafter, the process for executing the conversion will be described in more detail. First, conversion from the external format of the input data to the internal format is shown in FIG. Initially it is an external other format 416, which simply passes through various organizers. Next, the external unpack byte format 417 performs unpack normalization 418 to generate a format 419 called an internal unpack byte. The unpack normalization 418 process performs a process of removing inactive 3 bytes from the external unpacked byte stream. FIG. 33 shows the unpacking normalization process. Of the inputs having 4 byte channels, only one byte channel has a valid result in the output format 419, and a state where simple bytes are output. Show.

  In FIG. 32, pack normalization 421 processing performs processing for converting an element object in the external pack stream 422 into a byte stream 423. If the size of each element of the channel is less than or equal to bytes, the sample is interpolated to an 8-bit value. For example, when converting a 4-bit unit into a byte unit, a 4-bit value 0xN is converted into a byte value 0xNN. In the case of an object of 1 byte or more, truncation is performed. The input object sizes supported by the stream 422 are 1, 2, 4, 8, and 16 bit sizes. Note that these depend on the total width of data objects and words in the system to which the present invention is applied.

  FIG. 34 shows a state of pack normalization 421 when input data 422 in a 3-channel object format having 2 bits is input for each channel (as in the data format 386 of FIG. 23). The output data is in the byte channel format 423. At this time, if necessary, an “interpolation process” is performed on each channel to generate 8-bit samples.

  In FIG. 32, the pixel stream is then sent to one of a pack process 425, an unpack process 426, and an element selection process 427. FIG. 35 shows an example of the pack process 425, which simply shows that the inactive byte channel is removed and a byte stream packed into 4 active bytes per word is generated. That is, a single valid byte stream 430 is compressed into a format 431 having 4 active bytes per word. The unpacking process 426 is almost the opposite of the packing process, and the unpacked byte is the smallest byte of the word. FIG. 36 shows how the packed byte stream 433 is unpacked and a result 434 is obtained.

  FIG. 37 shows the element selection 427 process, which is a process of selecting N elements from the input stream, where N is the number of input channels per unit. Unpacking is used when generating “prototype pixels”, eg, 437. Note that the pixel channel is filled from the smallest byte. FIG. 38 shows a state where input data of the format 436 is converted by the element selection unit 427 and a prototype pixel format 437 is generated.

  When element selection is performed, element replacement processing 440 (FIG. 32) is performed. FIG. 38 shows a state of the element replacement process, and shows a state in which the selected element is replaced with a constant value stored in the internal data register 441 and the output element 242 is generated as in the example. In FIG. 32, the outputs of the processing stages 425, 526, and 440 are sent to the lane swap processing 444. As shown in FIG. 39, the lane swap process is a process of multiplexing a certain lane to another lane for each byte, and includes a process of copying a certain lane to another lane. In the example of FIG. 38, channel 3 and channel 1 are exchanged, and channel 3 is duplicated to channel 2 and channel 1.

  In FIG. 32, when the lane swap process 444 is completed, the data stream may be stored in the multi-use value RAM 250 before being read again and transferred to the duplication process 446. The duplication process 446 is simply a process for duplicating a data object. FIG. 40 shows that the duplication process 446 is applied to the pixel data, and the duplication factor is 1.

  FIG. 41 shows a state in which replication processing is applied to packed byte data. FIG. 42 shows the processing of the result organizer 249 for converting data from the output internal format 383 to the output external format 384. This process includes the same processes 424, 425, 426, and 440 as the conversion process shown in FIG. Contains. The element non-selection process 451 shown in FIG. 43 is the reverse process of the element selection process of FIG. 37, and unnecessary data is deleted. For example, in FIG. 43, only the three valid channels being entered are retrieved and packed into data items 456.

  The denormalization process shown in FIG. 44 performs substantially the opposite operation of the pack normalization process 421 shown in FIG. In the denormalization process, a process for converting each object or data item that has been handled in byte units into a non-byte value is performed. The byte addressing process 453 of FIG. 42 performs a reconfiguration process for each byte necessary for byte addressing. In the external unpacked byte output stream, a minimum of 2 bits of the stream address corresponds to the active stream. In byte addressing process 453, when an external unpacked byte is used (FIG. 45), the output stream is remapped from one byte channel to another channel byte. When an external packed stream is used (FIG. 46), the byte addressing module 453 remaps the starting address of the output stream as shown.

The write mask process 454 of FIG. 42 is shown in FIG. This is a process of masking a channel (for example, 460) having a pack stream that is not written. The applied input / output data type conversion is determined based on the contents of the following data manipulation registers.
* Pixel organizer data operation register (po_dmr)
* Operand Organizer B and Operand Organizer C data operation registers (oor_dmr, ooc_dmr)
* Result organizer data operation register (ro_dmr)
Each data operation register for an instruction is set by the following two methods.
1. 1. Set using standard techniques to write to coprocessor registers immediately before instruction execution. In the instruction decoding process, which is set by the coprocessor itself based on the current instruction, the coprocessor examines the instruction word of data and the contents of the data word and determines how to set various data manipulation registers. Perform with other processing. Note that not all combinations of instructions and operands are valid. Some instructions specify an operand format. An instruction with an inappropriate operand will produce an “undefined” result, but may terminate without an error. If the “S” bit in the corresponding data descriptor is 0, the coprocessor sets the data manipulation register to reflect the current instruction.

FIG. 48 shows the format of the data operation register. The following table shows the various bit formats in the register shown in FIG.
Data manipulation register format

  Multiple internal / external data types may be used in each one instruction. All combinations of operands, results, and instruction types are valid, but only some of these combinations produce meaningful results. Table 9 shows specific combinations of expected operands and result data types for each instruction. Table 9 summarizes the expected data types in the external / internal format.

  Expected data type

The symbols used in Table 9 are as follows.
Symbol description

3.16 Data Normalization Circuit FIG. 49 shows a computer graphics processor that includes three main functional blocks. The three main functional blocks are pixel organizer 246 and operand organizer B, data normalization unit 1062 in C247, 248, central data engine in main data path 242 or JPEG unit 241, and programming agent 1064 in instruction control unit 235. is there. The operation of the data normalizer 1062 and the central graphics engine is determined by the instruction stream 1064 to the programming agent 1064. For each instruction, the programming agent 1064 performs a decoding process and outputs internal control signals 1067 and 1068 to the other blocks in the system. For each input data word 1069, the normalization unit 1062 formats the data based on the current instruction and sends the processing result to the central graphics engine 1063 where further processing is performed.

  The data normalization unit simply means a pixel organizer and operand organizers B and C. These organizers include a data normalization circuit that properly normalizes the input data and then sends the results to the central graphics engine in a JPEG encoding or main data path. The central graphics engine 1063 operates on standard format data that is 32 bit pixels. Therefore, the normalization unit performs processing for converting the input data into a 32-bit pixel format. The input data word 1069 to the normalization unit also has a 32-bit width, but may be in the format of packed elements or unpacked bytes. A packed element input stream consists of consecutive objects in a data word such that the data object is 1, 2, 4, 8, 16 bytes wide. On the other hand, the unpacked byte input stream consists of 32-bit words such that only 8-bit bytes are valid. Further, the pixel data 11 generated by the normalization unit is composed of 1, 2, 3, and 4 effective channels whose channels are defined with an 8-bit width.

  FIG. 50 is a diagram illustrating a specific hardware configuration of the data normalization unit 1062. The data normalization unit 1062 includes a FIFO buffer (FIFO) 1073, a 32-bit input register (REG1), a 32-bit output register (REG2), a normalization multiplexer 1075, and a control unit 1076. After the input data word 1069 is stored in the FIFO 1073, it is latched in (REG1) 1074 until all input bits are converted to the desired output format. Normalization multiplexer 1075 includes 32 combinational switches that select the bits from the value in (REG1) 1074 and the current output of (FIFO) 1073 to generate a pixel that is latched into REG2. That is, the normalization multiplexer 1075 has x [63. . 32] and x [31. . 0] and two 32-bit input words 1077, 1078 as inputs.

  By using such a technique, it is possible to improve the overall throughput of the apparatus, particularly when the FIFO has at least two valid data words in instruction processing. This is due to the technique of fetching data words from memory. The desired data word or object may be spread or “wrapped” into adjacent input data words in the FIFO buffer, but by using the input register 1074, elements from adjacent data words in the FIFO buffer are used. Complete input data can be reconstructed, and additional storage and bit strip processing required prior to the main data manipulation processing stage can be omitted. Such a configuration is a great advantage when a plurality of similar types of data words are input to the normalization unit.

  The control unit updates the enable signals REG1_EN1080 and REG2_EN [3. . 0] 1081 and a signal for controlling the FIFO 1073 and the normalizing multiplexer 1075 are also generated. The programming agent 1064 in FIG. 49 sends the following configuration signal to the data normalization unit 1062. FIFO_WR4 signal, normalization factor n [2. . 0], bit offset b [2. . 0], channel count c [1. . 0] and external format (E). Input data is written into the FIFO 1073 by sending out a FIFO_WR signal 1085 every clock cycle in which valid data exists. If the area is not available, the FIFO sends a fifo_full status flag 1086. Given 32-bit input data, an external format signal is used to check whether the input is packed stream format (E = 1) or unpacked byte (E = 0). When E = 1, the normalization factor is the size of each element of the pack stream. That is, n = 0 indicates a 1-bit width element, n = 1 indicates a 2-bit width element, n = 2 indicates a 4-bit width element, n = 3 indicates an 8-bit width element, and n> 3 indicates a 16-bit width element. The channel count is also the maximum number of consecutive input objects that are formatted every clock cycle to generate a pixel with the desired number of valid bytes. Specifically, c = 1 is a pixel where only the minimum byte is valid, c = 2 is a pixel where a minimum of 2 bytes is valid, c = 3 is a pixel where a minimum of 3 bytes is valid, c = 0 is all 4 bytes is a valid pixel.

When the pack stream is composed of elements having a width of 8 bits or less, the bit offset is a value stored in REG1 x [31. . 0] is determined. If the bit offset is a deviation from the largest bit of the first input byte, the output data byte y [7. . 0] is given by the following equation.
If n = 0,
y [i] = x [7−b] When 0 ≦ i ≦ 7 When n = 1,
y [i] = x [7−b] When i = 1, 3, 5, 7 y [i] = x [6-b] When i = 0, 2, 4, 6 When n = 2,
y [3] = x [7-b]
y [2] = x [6-b]
y [1] = x [5-b]
y [0] = x [4-b]
y [7] = y [3]
y [6] = y [2]
y [5] = y [1]
y [4] = y [0]
If n = 3,
y [i] = x [i] When 0 ≦ i ≦ 7 When n> 3,
y [7. . . 0] = x [15. . . 8]
Output data byte y [15. . 8], y [23. . 16], y [31. . The formula for generating [24] is similar.

  Note that the above method has been extended so that an output array of any length can be generated by inputting the elements of the input stream, performing the required number of times of duplication processing, and generating a standard width output object. it can. The processing order of input elements may be little endian or big endian. In the above example, since the process always starts from the maximum bit of the input byte, the big endian element order is used. When using little-endian order, the bit offset must be redefined as the value for the smallest bit of the input byte. When the input element width is equal to or larger than the standard output width, the output element is generated by truncating the input element, generally by deleting an appropriate number of minimum bits. In the above equation, by selecting the maximum byte of a 16-bit data object, the 16-bit input element is truncated to generate an 8-bit wide standard output.

  The control unit in FIG. . 0] and c [1. . 0] and b [2. . 0] is used to generate a selection signal for the normalization multiplexer and an enable signal for REG1 and REG2. Also, since the FIFO may be empty during an instruction, the control unit selects the current bit position in_bit [4. . 0] and the current byte position out_byte [4. . 0] is stored. When the processing is completed, the control unit in_bit [4. . 0] and the position of the final object of REG1 are detected, and the FIFO read operation is started by sending a FIFO_RD signal in one clock cycle when the FIFO is not empty. The signals fifo_empty and fifo_full are FIFO status flags, and fifo_empty = 1 when the FIFO does not have valid data, and fifo_full = 1 when the FIFO is full. In the clock cycle in which FIFO_RD is sent, REG1_EN is sent and new data is taken into REG1. There are four REG2 enable signals, one for each byte of the output register. The control unit performs the decrypted c [1. . 0], the number of effective elements waiting for processing in REG1, and the minimum value among the three values of the number of unused channels in REG2, thereby obtaining REG2_EN [3. . 0] is calculated. When E = 0, there is only one valid element in REG1. The number of channels occupying REG2 is decoded c [3. . 0], the complete output word is obtained.

  In the preferred embodiment of the present invention, the circuit area occupied by the device of FIG. 50 is greatly increased by adding a function to limit the bit offset parameter, such as using only a part of the offset used in the control unit and the normalization multiplexer. Can be reduced. This offset limiting function depends on the normalization factor, and operates according to the following equation.

b_trunc [2. . . 0] = 0 When n ≧ 3 = b [2. . . 0] When n = 0 = b [2. . . 1] When n = 1 = b [2] & “00” When n = 2 (“&” indicates a bit-by-bit combination process)
By such processing, in FIG. 50, MUX0, MUX1,. . . The size of each normalization multiplexer indicated by MUX 31 is reduced from 32-1 when the limiting function is not used to the maximum size 20-1 when the bit offset is limited. By reducing the size, the circuit speed can be improved.

As described above, the preferred embodiment includes an efficient circuit for converting data into several normalized formats.
3.17 Accelerator Card Image Processing Operation In FIG. 2 and Table 2, the instruction control unit 235 “executes” an instruction resulting in an operation executed in the coprocessor 224. The instructions to be executed include various instructions that perform useful functions in the main data path unit 242. One of these useful instructions is a synthesis process.

3.17.1 Composition FIG. 51 is a diagram illustrating a composition model implemented in the main data path unit 242. The composite model 462 generally includes three data input sources and output data (sink) 463. One input source is the output 463 and pixel data 464 from the same counterpart in memory. It also includes an instruction operand 465 used as a data source such as color and opacity. Here, the color and opacity may be flat, blend, pixel, or tile. It should be noted that flat and blend are generated by the blend generation unit 467 because they are generated faster than fetching via input / output. In addition, the input data also includes attenuation data 466 that attenuates operand data 465.

  As described above, normal pixel data consists of four channels, each channel being 1 byte wide. Here, 1 byte of the highest address is an opaque channel. For the operation and usefulness of the synthesis process, refer to standard articles such as the commentary paper “Thomas Porter and Tom Duff” Compositing Digital Images ”in Computer Graphics, volume 18, number 3, July 1984”.

  The coprocessor can also use premultiplied data. Pre-multiplication is a process of multiplying each color channel and the opaque channel in advance. Therefore, two optional pre-multipliers 468 and 469 are provided, and when necessary, the opaque channels 470 and 471 and the color data are pre-multiplied to obtain pre-multiplied outputs 472 and 473. The synthesizer 475 synthesizes two inputs based on the current instruction data. Table 11 below shows the synthesis operators.

  Compositing operation

  Here, (aco, ao) represents a pre-multiplied pixel of color ac and opacity ao. R is an offset value, and “wc” is a wrapping / clamping operator described below. Note that the synthesizing unit 475 also includes the reverse operation of each operator in the above table. The clamp / wrapping unit 476 is a processing unit for clamping or wrapping data within the limit value 0 to 255. Further, if necessary, the data can be subjected to an optional “ample multiplication” 477 and can be returned to the original pixel value. Finally, output data 463 is generated and returned to the memory.

  FIG. 52 shows an instruction format sent to the main data path unit when performing the synthesis process. If the X field in the main opcode is 1, the addition operator is applied according to the above table. If this field is 0, instructions other than the addition operator are applied. The Pa field is a field indicating whether to pre-multiply the first data stream 464 (FIG. 51). Also, the Pb field indicates whether to pre-multiply the second data stream 465, and the Pr field indicates whether to “amplify” the result using the part 477. The C field indicates whether to wrap or clamp, overflow or underflow within the range 0-255, and the “com-code” field indicates which operator is applied. The addition operator can also use the offset register (mdp_por). This offset is subtracted from the result of the addition operation before the wrapping / clamping process is performed. In the addition operator, the com-code field is a field indicating whether to enable each channel of the offset register.

  The previously described standard instruction word encoding 280 of FIG. 10 is modified for composite operands. Since the destination of the output data is the same as the original source, the operand A is always the same as the result word. Therefore, operand A can describe operand B longer than operand B. Like other instructions, the A descriptor in the instruction describes the input format and the R descriptor defines the output format.

  FIG. 53 shows an instruction word format of the blend instruction as a first example 470. The blending process is defined by a start value 471 and an end value 472 for each channel. Similarly, FIG. 54 shows a tile instruction format defined by a tile address 476, a start offset 477, and a length 478. All tile addresses and sizes are specified on a byte-by-byte basis. The tile processing is performed in a modular manner, and FIG. 55 is a diagram for explaining the fields 476 to 478 in FIG. The tile address 476 specifies the start address of the tile memory, the tile start offset 477 specifies the first byte used at the start of the tile, and the tile length 478 specifies the entire tile length to be wrapped.

In FIG. 51, color elements and opacity may be attenuated by an attenuation value 466. The attenuation value is obtained by the following three methods.
1. Software can specify flat attenuation by including an attenuation factor in the operand C word of the instruction.
Bitmap attenuation with 2.1 on and 0 off can be used with software that identifies the address of the bitmap in the operand C word of the instruction.
3. Byte map attenuation may be provided at the byte map address of the operand C word of the instruction.
4). Bitmap attenuation can be performed using ON software when set to 1, and OFF when set to 2.

The attenuation value is an unsigned integer from 0 to 255, so the premultiplied color channel is
Coa = Coa × A / 255
Is multiplied by the attenuation factor. Where A is the attenuation factor and Co is the premultiplied color channel.

3.17.2 Color Space Conversion Instruction In FIG. 2 and Table 2, the main data path unit 242 and the data cache 230 mainly perform color conversion processing. The color space conversion performs conversion processing from a first color space format (for example, a format suitable for RGB color display) to a second color space format (for example, a format suitable for CYM or CYMK printing). The color space conversion process is designed to support all color spaces, and an instruction control unit 235 that can be used in any function from one dimension to multi-dimension is connected to the main data path unit 242, the data via the CBus 231. The cache control unit 240, the input interface switch 252, the pixel organizer 246, the MUV buffer 250, the operand organizer B247, the operand organizer C248, and the result organizer 249 are configured and controlled to operate in the color conversion mode. In this mode, an input image composed of a plurality of lines of pixels is sent to the main data path unit 242 for each pixel line as a pixel stream. The main data path unit 242 (FIG. 2) receives the pixel stream from the input interface switch 252 via the pixel organizer 246 and performs color space conversion processing for each pixel. In addition, an interval table and a fraction table are loaded in advance in the MUV buffer 250, and a color conversion table is loaded in the data cache 230. The main data path 242 accesses these tables via the operand organizers B and C, converts pixels from, for example, the RGB color space to the CYM or CYMK color space, and sends the converted pixels to the result organizer 249. The main data path unit 242, the data cache 230, the data control unit 240, and other devices described above are controlled by the command control unit 235, in a single output general color space (SOGCS) conversion mode or a multiple output general color space. It operates in either mode of (MOGCS) conversion mode. For details of the data cache control unit 240 and the data cache 230, refer to the items of “data cache control unit and cache” 240 and 230 (FIG. 2).

An accurate color space conversion process is a complex nonlinear process. For example, the color space conversion process from an RGB pixel to a single primary color element (ie, cyan) in the CYMK color space is theoretically linear, but is actually nonlinear in an output device that mainly outputs the pixel color element. Sex will occur. The same applies to color space conversion processing from RGB pixels to other main color elements (yellow, magenta, black) in the CYMK color space. That is, nonlinear color space conversion is generally used to compensate for nonlinearity that occurs in each color element. Due to the nonlinearity of such a complex color conversion process, a complicated transfer function is incorporated or a lookup table is used. For example, given an input color space of 24-bit RGB pixels, a lookup table that maps these pixels to 8-bit primary color elements (cyan) of the CYMK color space requires more than 16 megabytes. Similarly, a look-up table for mapping 24-bit RGB pixels to four 8-bit main color elements in the CYMK color space is 64 megabytes or more and requires a huge capacity. In contrast, the main data path 242 (FIG. 2) uses a look-up table stored in the data cache 230, associates a rough output color value with a point in the input color space, and interpolates the output color value. To get an intermediate output.
a. Single Output General Color Space (SOGCS) Conversion Mode For both single and multiple output color conversion modes (SOGCS) and (MOGCS), the RGB color space consists of 24-bit pixels with 8-bit red, green and blue elements. Each RGB dimension of the RGB color space is divided into 15 sections, and the length of each section is set to be an inverse function of the nonlinearity from the RGB of the printer to the CYMK color space. That is, when the transfer function shows strong nonlinearity, the length of the section is shortened, and when the transfer function is close to linear, the length of the section is increased. In order to know the nonlinear part of such a transfer function, it is desirable to accurately check the color space of each output printer. However, it is also possible to approximate or model the transfer function based on the know-how and the measured characteristics of the printer type (eg ink jet). For each color channel of the input pixel, the position in 15 sections of the color element value is determined. Two tables are used in the main data path unit 242 to determine in which section the input color element value exists and to determine a position in the section in which the input color element value exists. Of course, different tables may be used for output printers having different transfer functions.

  As described above, each dimension of RGB is divided into 15 sections. That is, the RGB color space has a three-dimensional lattice structure divided by sections, and input pixels at both ends of the section are coarsely arranged in the input color space. Furthermore, only output color values in the output color space corresponding to both ends of the section are stored in the lookup table. Therefore, the output color value of the input color pixel is obtained by determining the output color value corresponding to both ends of the section where the input pixel exists and interpolating the output color value based on the position in the section. This approach can reduce the need to use a large capacity memory.

  FIG. 56 shows an example 480 in which the corresponding section and the position in the section are determined for the input RGB color pixel. The conversion process is executed using the section table 482 and the intra-section position table 483 for each 8-bit input color channel of 24-bit input pixels. In FIG. 56, an 8-bit input color element 481 is obtained by displaying decimal number 4 in binary format, and this 8-bit input color element 481 is used as a lookup to the section table or the intra-section position table. The section table 482 outputs one of the sections from 0 to 14 in which the input color element value 481 exists in 4 bits. Similarly, the intra-section table 482 indicates the position in the section where the input color value element 481 exists. The intra-section table stores 8-bit values in the range of 0 to 255, and this value is interpreted as a fraction of 256. Therefore, in the case of the input color value element 481 in which the decimal number 4 is expressed in binary, the output value 0 is generated by looking up the section table 482. Also, by looking up the input value 4 in the intra-section position table 483, an output value 160 representing the fraction 160/256 is generated. As can be seen from the section table 482 and the intra-section position table 483, the section lengths are not uniform. As described above, the section length is determined by the nonlinearity of the transfer function.

  As described above, by using the section table and the intra-section position table for each RGB color element, three section outputs and three intra-section position outputs can be obtained. The section / intra-section position table for each color element is loaded into the MUV buffer (FIG. 2) and accessed by the main data path 242 when needed. FIG. 57 shows the configuration of the MUV buffer 250 in the color conversion process. The MUV buffer 250 (FIG. 57) is divided into three regions 488, 489, and 490, each corresponding to each color element. Each area (for example, 488) is further divided into a 4-bit section table and an 8-bit intra-section position table. The 12-bit output 492 is extracted from the MUV buffer 250 for each input color channel by the main data path unit 242. In the above example of a decimal 4 single input color element, the 12-bit output is 000001010000.

  FIG. 58 is a diagram showing an example of interpolation processing. Interpolation processing is mainly processing from one three-dimensional space 500 (for example, RGB color space) to another color space (for example, CMY or CMYK). Pixels P0 to P7 are coarsely present in the RGB input color space and have corresponding output color values CV (P0) to CV (P7) in the output color space. The output color element value of the input pixel Pi located between the pixels P0 to P7 is determined as follows. First, both ends P0, P1,. . . , P7. Next, intra-section position elements frac_r, frac_g, and frac_b are determined, and finally interpolation is performed between output color values CV (P0) to CV (P7) corresponding to both ends of P0 to P7 using the intra-section position elements. To do.

In the interpolation processing, first, red (R) direction one-dimensional interpolation is performed, and values of temp11, temp12, temp13, and temp14 are obtained from the following equations.
temp11 = CV (P0) + frac_r (CV (P1) −CV (P0))
temp12 = CV (P2) + frac_r (CV (P3) -CV (P2))
temp13 = CV (P4) + frac_r (CV (P5) -CV (P4))
temp14 = CV (P6) + frac_r (CV (P7) -CV (P6))
Next, in the interpolation process, temp21 and temp22 are obtained by using the following formula, and one-dimensional interpolation in the green (G) direction is calculated.

temp21 = temp11 + frac_g (temp12-temp11)
temp22 = temp13 + frac_g (temp14−temp13)
Finally, a final color output value is obtained based on the following equation, and final dimension interpolation in the blue (B) direction is performed.
final = temp21 + flag_b (temp22−temp21)
There are often cases where the input and output ranges do not match. Here, if the output range is narrower than the input range, it is often necessary to clamp the range at both ends. That is, undesirable distortions often occur when converting colors around the ends of the range. FIG. 59 illustrates an example in which this problem occurs, and shows a state in which an input range value is one-dimensionally mapped to an output range value. Here, it is assumed that the output value for the input value is determined at points 510 and 511. If the maximum output value is clamped at point 512, point 511 must be an output of this magnitude. Accordingly, when two points 510 and 511 are interpolated, the line 515 becomes an interpolation line, and the output value 517 corresponds to the input point 516. However, when the output value is a point 518 when there is no range restriction, this method is not always the optimum color mapping. The interpolation line 510 and 518 generates an output value 519 for the input point 516. In order to avoid this problem, the difference between the two output values 517 and 519 is often a noticeable distortion, especially when printing colors around the end of the range. It can be calculated in space and scaled or clamped to an appropriate range using the following formula.

In FIG. 58, the interpolation processing is executed in either the SOCGS conversion mode for converting RGB pixels into a single output color element (for example, cyan) or the MOGCS mode for converting RGB pixels into all output color elements simultaneously. When color conversion is performed on each pixel in the image, millions of pixels are independently color-converted. Therefore, in order to operate at high speed, it is desirable to quickly find eight values (P0-P7) around the input value.

  As described in FIG. 57, the main data path unit 242 takes out a 12-bit output composed of a 4-bit section part and an 8-bit section position part for each color input channel. The main data path unit 242 combines the 4-bit sections of the red, green, and blue channels, and generates a single 12-bit address (IR, IG, IB) as indicated by 520 in FIG. FIG. 60 is a data flow diagram showing how a single output color element 563 is obtained from a single 12-bit address 520. The 12-bit address 520 is first sent to the address generation unit of the data cache control unit 240 such as the generation unit 1881 (FIG. 141), and eight 9-bit lines for the memory banks (B0, B1,..., B7). / Byte address 521 is generated. The data cache (FIG. 2) is divided into eight independent memory banks 522, each addressed independently by eight line / byte addresses. Conversion from the 12-bit address 520 to the 8-line / byte address in the address generation unit is performed according to the following table.

  Address composition in SOGCS mode

  Here, BIT [8: 6], BIT [5: 3], and BIT [2: 0] indicate 6 to 8 bits, 3 to 5 bits, and 0 to 2 bits, respectively, of the 9-bit bank address. R [3: 1], G [3: 1], and B [3: 1] indicate the first to third bits of the 4-bit section IR, IG, IB of the 12-bit address 520. Regarding the memory bank 5 in Table 12, the mapping from 12 bits to 9 bits will be described in detail. The 1 to 3 bits of the 4-bit red section Ir in the 12-bit address 520 are mapped to the 6 to 8 bits of the 9-bit address B5, and the 1 to 3 bits of the 4-bit green section Ig are added to add 3 of the 9-bit address B5. 1 to 5 bits of 4-bit blue section Ib are mapped to 0 to 2 bits of 9-bit address B5.

  Eight line / byte addresses 521 are used as addresses to corresponding memory banks 522 consisting of 512 × 8 bits, and corresponding 8-bit output color elements 523 are latched from each memory bank 522. According to this addressing process, the output color values CV (P0) to CV (P7) corresponding to the end points P0 to P7 may be different addresses in the memory bank. For example, a 12-bit address 0000 0000 0000 can obtain the same bank address of 000 000 000 in all banks. Thus, different bank addresses are obtained in the banks 6, 4, 2, and 0 so that the bank address is 000 000 001. In this way, eight single output color values CV (P0) to CV (P7) surrounding the input pixel value are obtained simultaneously from each memory bank, and the output color value is prevented from being duplicated in the memory bank. Can do.

  FIG. 61 shows a memory bank configuration of the data cache 230 used in the single color conversion mode. Each memory bank consists of 128 line entries, and each line entry is 32 bits long and consists of 4 × 8 bit memories 533-536. The upper 7 bits of the memory address 521 are used to determine the corresponding data string in the memory address and latch 542 as the memory bank output. The lower 2 bits are a byte address and are input to the multiplexer 543 and are used to determine which 4 × 8 bit entry is selected 544 as an output. Data for each of the eight memory banks is output every clock cycle and sent to the main data path unit 242. That is, the data cache control unit receives a 12-bit byte address from the operand organizer 248 (FIG. 2), and outputs an 8-bit output color value for interpolation processing in the main data path unit 242 to the operand organizers 247 and 248.

  In FIG. 60, the main data path unit 242 (FIG. 2) executes the interpolation process in three steps. In the first step in the main data path unit, the multiplication / addition unit (for example, 550) receives the color value output from the corresponding memory bank (for example, 522) and the red interval position element 551, and the first step of the above formula To calculate four output values. The output of the first step (eg, 553, 554) is sent to the second step 556 and the output 558 is calculated according to the previous equation of the second step using the frac_g input 557. Finally, the final output color 563 is calculated based on the previous equation using the second step outputs 558 and 559 and the frac_b input 562.

The processing shown in FIG. 60 is pipelined in order to obtain the maximum throughput as a whole. Further, the technique of FIG. 60 is used when a single output color element 563 is required. For example, the method of FIG. 60 is used when a cyan color element of an output image is first generated and then a cache table between passes is reloaded to generate magenta, yellow, and black elements of the output image. This is particularly suitable for 4-pass printing processing in which each output color is an independent pass.
b. Multiple Output General Color Space Mode The coprocessor 224 also operates in the MOGCS mode, but the MOGCS mode operates in much the same way as the SOCGS mode except for a few points. In the MOGCS mode, the main data path unit 242, the data cache control unit 240, and the data cache in FIG. 2 cooperate to output the four main color elements to be output simultaneously. This requires four times the size of the data cache 230, but in order to save storage space, in the MOGCS operation mode, the data cache control unit 240 uses only 1/4 of all output color values in the output color space. Store. The remaining output color values in the output color space are stored in a low speed external memory and retrieved when needed. Note that the present apparatus and method are based on the surprising fact that the miss rate of the coarse color conversion table in the cache system is very small. This is based on the finding that in many color images, the dispersion of color values between one pixel and another pixel is small. Also, there is a very high probability that the coarse output color value will be the same in neighboring pixels.

  FIG. 62 illustrates a technique by which the coprocessor performs multiple channel cache color conversion. After each input pixel is decomposed into color elements, the corresponding interval table value (FIG. 56) is determined as described above, and three 4-bit intervals such as Ir, Ig, and Ib570 are obtained. The combined 12-bit number 570 is converted according to Table 12 above to obtain eight 9-bit addresses. The address (eg, 572) is remapped as described below in FIG. 63 and the corresponding memory bank 573 is looked up to obtain four color output channels 574. Memory bank 573 can be a 512 × 32 bit entry as a whole, but stores a 128 × 32 bit entry. The memory bank 573 forms part of the data cache 230 and is used as a cache as will be described with reference to FIG.

  FIG. 63 shows how the 9-bit bank input 578 is remapped to 579, and the alias of the memory pattern can be removed by changing the order of bits 580-582. This can reduce the probability that adjacent pixel values are aliased to the same cache element. The reconstructed memory address 579 is used as an address to a corresponding memory bank (e.g., 585), each consisting of 128 entries of 32 bits. By accessing the memory 585 using the 7-bit line address, an output latched 586 is obtained for each memory bank. Each memory bank (eg, 585) has an associated tag memory consisting of 128 entries of 2 bits each. The 7-bit line address is also used to access the corresponding tag in this tag memory 587. By comparing the maximum 2 bits of address 579 with the corresponding tag in tag memory 587, it is determined whether the output color value is stored in the cache. The maximum 2 bits in the 9-bit address correspond to the maximum bits in the red and green data sections (see Table 12). Therefore, in the MOGCS mode, the RGB input color space is efficiently divided into four quadrants in the red and green dimensions, and a maximum of two bits of the 9-bit address designate quadrants in the RGB input color section. That is, the output color value is efficiently divided into four quadrants designated by two bit tags. For this reason, the color output values corresponding to each tag value of a certain line are located apart from each other in the output color space, and the alias of the memory pattern can be reduced.

  If the two bit tags do not match, the data cache controller records a cache miss and the required memory read is activated by the data cache controller along with the cache lookup process. Note that the cache lookup process is stopped until all values of the line corresponding to the 2-bit tag entry are read from the external memory and stored in the cache. This process includes a process of reading a related line of the color conversion table stored in the external memory. 63 is executed for each memory bank (for example, 573) in FIG. 62, and depending on the contents of the cache, it may take time until the result (for example, 586) is output from the memory bank. The eight 32-bit sets of data 586 are then transferred to the main data path section (242), and the three steps 590-592 of the interpolation process described above (FIG. 62) are performed simultaneously and pipelined on all color channels. Four color writing forces 595 to be sent to the printer device are generated.

  According to experiments, since the cache miss rate in a general image is a cache line fetch for each pixel having an average of 0.01 to 0.03, the cache mechanism shown in FIGS. 62 and 63 is effective. It is shown. By using such a cache mechanism, in many cases, the demand for memory access outside the data cache can be greatly reduced.

The instruction encoding in the two color space conversion modes (FIG. 10) performed by the coprocessor has the following structure.
Instruction coding in color space conversion.

FIG. 64 shows instruction field encoding in the color space conversion instruction. Minor opcode encoding in the color conversion instruction is as follows.
Minor opcode coding in color conversion instructions

  FIG. 65 shows a method of converting an RGB pixel stream into CYMK color values in the MOGCS mode. In step S1, a 24-bit RGB pixel stream is input to the pixel organizer 246 (FIG. 2). In step S2, as described with reference to FIGS. 56 and 57, the pixel organizer 246 determines the 4-bit interval value and the 8-bit interval position of each input pixel using the lookup table. The section value of the input pixel and the position in the section indicate in which section the input pixel exists and in the section. In step S3, the main data path unit 242 combines the 4-bit sections of the red, green, and blue elements of the input pixel to generate a 12-bit address word, and the 12-bit address word is converted into the data cache control unit 240 (FIG. 2). ) In step S4, as described in Table 12 and FIG. 62, the data cache control unit 240 converts the 12-bit address word into eight 9-bit addresses. These eight addresses indicate the positions of the eight output values CV (P0) -CV (P7) in the memory bank 573 (FIG. 62). In step S5, the data cache control unit 240 (FIG. 2) remaps the eight 9-bit addresses as described in FIG. In this manner, the maximum bits of the 4-bit section of red and green are mapped to the maximum 2 bits of the 9-bit address.

  In step S6, the data cache control unit 240 compares the maximum 2 bits of the 9-bit address with the 2-bit tag in the memory 587 (FIG. 63). If the 2-bit tag does not match the maximum 2 bits of the 9-bit address, the output color values CV (P0) -CV (P7) do not exist in the cache memory 230. Accordingly, in step S7, the output color value corresponding to the 2-bit tag entry is read from the external memory into the data cache 230. When the 2-bit tag matches the maximum 2 bits of the 9-bit address, the data cache control unit 240 takes out the eight output color values CV (P0) -CV (P7) in the manner described with reference to FIG. . In this way, the eight output color values CV (P0) -CV (P7) surrounding the input pixel are fetched from the data cache 230 by the main data path unit 242. In step S7, the output color values CV (P0) -CV (P7) are interpolated in the main data path unit 242 using the position in the section determined in step S2, and the interpolated output color value is output.

  Here, it is obvious to the expert that the storage area of the data cache capacity can be reduced by further dividing the RGB color space and the corresponding output color value into four quadrants or more, for example, 32 blocks. When dividing into 32 blocks, the storage capacity of the data cache may be only 1/32 blocks of the output color value. It is also clear to the expert that the data cache mechanism used in the MOGCS mode can also be used in the single output general conversion mode. Also in this case, the storage area of the data cache can be reduced.

3.17.3 JPEG encoding / decoding The benefits of encoding and storing images are immeasurable, especially in terms of memory savings and image transfer rates from one location to another. Various widely distributed standards for image coding have emerged. One very popular standard is the JPEG standard, but a detailed description of the JPEG standard can be found in the prominent book “JPEG: Still Image Data Compression Standard” by Pennebaker and Mitchell, published in 1993 by Van Nostrand Reinhold. I want. Coprocessor 224 stores images using a subset of the JPEG standard. The advantage of the JPEG standard is that a large compression rate can be obtained while maintaining the image quality. Of course, other standards may be used to store the compressed image. The JPEG standard is a standard well known to experts, and various products implementing JPEG that can be used for ASICS are commercially available from manufacturers including JPEG core products and the like.

  The coprocessor 224 has a function of JPEG encoding / decoding an image composed of 1, 3, and 4 color elements. The one-color element image may or may not be a mesh. That is, one color element can be extracted from either mesh data or non-mesh data. As an example of mesh data, there are three color elements for each pixel data (that is, RGB for each pixel data), and as an example of non-mesh data, each color element of the image is stored separately and each color element is processed independently Data that can be used. In the case of a three-color element image, the coprocessor 224 assumes that the three-color channel is encoded to a minimum of 3 bytes and uses one pixel per word.

  The JPEG standard divides an image into small two-dimensional parts called minimum coding parts (MCUs). Here, each minimum coding part is processed independently. The JPEG encoder (FIG. 2) may be a 16-pixel by 8-pixel vertical MCU of a downsampled image, or a 8-pixel by 8-pixel vertical MCU for a non-downsampled image.

  FIG. 66 shows a technique for down-sampling a three-element image. The original pixel data 600 is stored in the MUV buffer 250 (FIG. 2) in a pixel format in which each pixel 601 is composed of Y, U, and V elements in the YUV color space. This data is first converted into an MCU part consisting of four data blocks 601-604. The data block includes various color elements, blocks 601 and 602 are directly sampled Y elements, and blocks 603 and 604 are U and V elements subsampled in the example of FIG. Here, the coprocessor 224 has two types of subsampling functions. One is direct sampling without filtering, which leaves odd pixel data and deletes even pixel data. It is also possible to filter the U and V elements by taking the average of adjacent values.

  Another JPEG subsampling is the four-color channel subsampling shown in FIG. In this subsampling, a pixel data block of 16 × 8 pixels 610 has four elements 611 that include an opacity element (O) in addition to the normal Y, U, V elements. This pixel data 610 is also subsampled as in FIG. However, in this case, data blocks 612 and 613 are created using an opaque channel.

FIG. 68 is a diagram illustrating the JPEG encoder 241 of FIG. 2 in more detail. The JPEG encoder / decoder 241 performs both JPEG encoding and decoding. The encoding process receives block data from the pixel organizer 246 (FIG. 2) via the bus 620. Block data is stored in the MUV buffer 250 and processed for each block. The JPEG encoding process is divided into a number of distinct steps. These steps are
1. Execute discrete cosine transform in DCT unit 621
2. Quantization of DCT output 622
3. 3. Arrangement of DCT coefficients by zigzag scanning executed by the quantizer 622 4. DC DCT coefficient predictive coding and AC DCT coefficient Runlenx coding performed in coefficient encoder 623 Variable length encoding of the output of the coefficient encoder performed by the Huffman encoder 624. The output is sent to result organizer 629 (FIG. 2) via multiplexer 625 and Rbus 626.

  The JPEG decoding process is the reverse of the JPEG encoding operation. That is, the JPEG decoding process includes a process of inputting a JPEG block compressed from Bus 620. The compressed data is sent to the Huffman encoder 624 via the Bus 630, and the data is decoded into a DC difference and an AC run length. The data is then sent to a coefficient encoder 623 where AC and DC coefficients are decoded and returned to normal scanning. Thereafter, the quantizer 622 multiplies the quantized value corresponding to the DC coefficient to perform inverse quantization of the DC coefficient. Finally, the DCT unit 621 performs inverse discrete cosine transform to restore the original data, which is sent to the result organizer via the Bus 631 and the multiplexer 625 and Bus 626. The JPEG encoder 241 operates in the normal manner via the standard Cbus interface 632, including registers set by the instruction controller to initiate operation of the JPEG encoder. Also, the quantizer 622 and the Huffman encoder 624 require a table, which is loaded from the data cache 230 when necessary. The table data is accessed via the Obus interface unit 634. Here, the Obus interface unit 634 is connected to the operand organizer B 247 and interacts with the data cache control unit 240.

  The DCT unit 621 performs discrete cosine transform and inverse discrete cosine transform on the pixel data. Regarding DCT, various types of DCT transformation implementation methods are known, and although described in “Still Image Data Compression Standard” (same as above), DCT 621 is described in detail in the following section “High-Speed DCT Device”. The high-speed method described is used. In the DCT conversion operation, The Transactions of the IEICE, vol. E71, no. 11, November 1988, page 1095, a DCT conversion technique based on the paper “A Fast DCT-SQ Scheme for Images” by Arai et al. Can also be used.

  The quantizer 622 operates by performing quantization and inverse quantization of the DCT coefficient, and extracting a related value from the corresponding table stored in the data cache via the Obus interface unit 634. In the quantization process, the input data stream is divided by the value read from the quantization table in the data cache. This division is implemented as a fixed point multiplication. In the inverse quantization process, the data stream is multiplied by the value in the inverse quantization table.

  FIG. 69 is a diagram illustrating the inverse quantization 622 in more detail. The quantizer 622 includes a DCT interface 640 that passes data to the DCT module 621 via the local bus and receives data from the DCT module 621. In the quantization process, the quantizer 622 receives two DCT coefficients every clock cycle. These values are written into one of the quantizer internal buffers 641, 642. Buffers 641 and 642 are buffers having two ports for buffering input data. In the quantization process, the coefficient data from the DCT submodule 621 is stored in one of the buffers 641 and 642. When the buffer becomes full, data is read out from the buffer by zigzag scanning, and is multiplied by the multiplier 643 with the quantized value received via the Obus interface unit 634. This output is transferred to the coefficient encoder 623 (FIG. 68) via the coefficient encoding interface 645. While these processes are being performed, the coefficient of the next block is written in another buffer. In the JPEG decoding process, the quantization module performs the inverse quantization process by multiplying the decoded DCT coefficient by the value stored in the table. Since quantization and inverse quantization operate exclusively, the multiplier 643 is used for both quantization and inverse quantization. Note that the position of the coefficient in the 8 × 8 block is used as an index to the inverse quantization table.

  Similar to the quantization process, two buffers 641 and 642 are used to buffer the input coefficient data from the coefficient encoder 623 (FIG. 68). Data is multiplied by the quantized value and written to the buffer in reverse zigzag scan order. When the buffer is full, two dequantized coefficients are simultaneously read from the buffer in the normal order and sent to the DCT submodule 621 (FIG. 68) via the DCT interface 640. Accordingly, the coefficient encoder interface module 645 serves as an interface with the coefficient encoder, and sends data to the encoder via the local bus and reads data from the encoder. This module reads data from the buffer in zigzag scan order at the time of encoding, and writes data to the buffer in reverse zigzag scan order at the time of decoding. Both the DCT interface module 640 and the CC interface module 645 can read and write from the buffer. Therefore, the address / control multiplexer 647 is used to determine which buffer each interface is operating under the control of a control module 648 consisting of a state machine to control all the modules of the quantizer. ,decide. The multiplier 643 may multiply the quantization table value by the DCT coefficient using a 16 × 8 two's complement multiplier.

In FIG. 68, the coefficient encoder 623 performs the following functions.
(A) Predictive encoding / decoding of DC coefficient in JPEG mode (b) Run coefficient encoding / decoding of AC coefficient in JPEG mode It should be noted that the coefficient encoder 623 performs pixel encoding at a required time separately from the JPEG mode operation. It can be used for predictive encoding / decoding and memory copy operations. The coefficient encoder 623 performs DC / AC coefficient prediction / Runlenx encoding / decoding as defined in the Pink Book. In addition to JPEG AC coefficient runlenx encoding / decoding as defined in the JPEG standard, a standard predictive encoding / decoding function is also provided.

  The Huffman encoder 624 performs Huffman encoding / decoding of the JPEG data string. In the Huffman coding mode, the Runlenx-encoded data is received from the coefficient encoder 623, and a Huffman stream of packed bytes is generated. In the Huffman decoding mode, the Huffman stream is read from the Pbus interface 620 in a packed byte format, and the Huffman decoded coefficient is sent to the coefficient encoding module 623. The Huffman encoder 624 uses a Huffman table stored in the data cache and accessed via the Obus interface 634. Alternatively, the Huffman table can be configured at high speed by hardware.

When using a data cache in Huffman encoding, the eight banks of the data cache store data tables as described in detail below for each table.
Huffman and quantization table stored in data cache

In FIG. 70, the Huffman encoder 624 is mainly composed of two independent blocks of an encoder 660 and a decoder 661. Both blocks 660, 661 share the same Obus interface via the multiplexer module 662. Each block has its own input and output, and only one of the blocks is active at a time, depending on the function performed by the JPEG encoder.
a. Encoding In encoding in the JPEG mode, a variable length code (up to 16 bits for each code) is assigned to a DC difference value or an AC run-length value using a Huffman table. The assigned code is sent from the CC submodule to the HC submodule. Also, the Huffman table must be previously loaded from the data cache before the operation starts. Then, the variable length code is combined with other bits of the DC and AC coefficients sent from the CC submodule to generate a packed byte format. If X'FF bytes are obtained as a result of the pack processing, X'00 bytes are inserted. When an RSTm marker is required, a marker is inserted. At this time, a byte stuffing process with “1” bit of the last Huffman code, and when the stuffed byte becomes X′FF X'00 byte insertion processing is performed. Whether a RSTm marker is required is indicated by the CC submodule. In addition, the HC submodule inserts an EOI marker at the end of the image in accordance with an instruction with the “last” signal on the Pbus-CC slave interface. In the EOI marker insertion processing, the same pack processing, clogging processing, and insertion processing as the RSTm marker are required. Finally, the output stream is sent to the result organizer 249 as packed bytes and written to external memory.

In the non-JPEG mode, data is sent from the CC submodule (Pbus-CC slave interface) to the encoder as unpacked data. Each byte is independently encoded using a table pre-loaded into the cache (similar to JPEG mode), variable length symbols are packed into packed byte format and sent to result organizer 249. The last byte of the output stream is padded with 1.
b. Decoding Decoding algorithms include high speed (real time) and low speed. The high-speed algorithm operates only in the JPEG mode, and the low-speed algorithm operates in both JPEG mode and non-JPEG mode.

  The fast JPEG Huffman decoding algorithm maps Huffman symbols to either DC difference values or AC run-length values. This is designed to be particularly suitable for JPEG, and assumes that the example Huffman tables (K3, K4, K5, K6) are used during encoding. Note that these tables are embedded in the hardware so that they can be decoded without referring to the cache memory. Such a decoding process assumes a case where a decoded image must be printed while guaranteeing a certain data rate. The data rate of the HC submodule that decodes a band (block delimited by RSTm markers) is approximately one DC / AC coefficient in one clock cycle. Between the HC sub-module and the CC sub-module, it may take one clock cycle to delete the X'00 insertion byte from the data stream, but this is strongly dependent on the data.

  The Huffman decoder operates in high speed mode and extracts one Huffman symbol every clock cycle. The high-speed Huffman decoder is described in the following “decoder of variable length code”. The Huffman decoder 661 has a low-speed decoding algorithm based on a heap, and has a structure 670 shown in FIG.

  For the JPEG encoded stream, the stripper 671 removes the X'00 insertion byte, the X'FF padding byte, and the RSTm marker and sends the Huffman symbol to the shifter 672 along with the other combined bits. Note that this process is not performed for an Huffman-only encoded stream. The first step in Huffman symbol decoding is to look up the 256 entries in the HUFVAL table stored in the cache addressed with the first 8 bits of the Huffman data stream. If this value is the true length of the corresponding Huffman symbol, the value is transferred to the output formatter 676, and the symbol length of the decoded value and the number of additional bits are fed back to the shifter 672, and the associated additional bits are replaced. The new start part of the Huffman stream that is transferred to the output formatter 676 and sent to the decoding unit 673 is aligned. Here, the number of additional bits is a function of the decoded value. If the first lookup did not result in a decoded value, i.e. if the Huffman symbol was 8 bits or more, the heap address was calculated and matched or until the "inappropriate Huffman symbol" condition was met Continue heap (positioned in the cache) access. If the lookups match, the same processing as described above is performed, and an interrupt state is entered when the “inappropriate Huffman symbol” condition is satisfied.

The decryption algorithm based on the heap is as follows.
Loop to end of image Set symbol length N to 8 Store first 8 bits of input stream in INDEX Fetch HUFVAL (INDEX) If HUFVAL (INDEX) == 00xx000111. . (ILL)
Sending “inappropriate Huffman symbol” signal exit
elseif HUFVAL (INDEX) == 1nnn eeee eeee
e-(HIT)
nnn bits are transferred to eeeeeeee as value Symbol length N = decimal (nnn) is transferred / * 000 is symbol length 8 * /
Input stream adjustment break
else / * HUFVAL (INDEX) == 01iii iiiiii iii
i-(MISS)
HEAPINDEX == set to iii iiiiii (assuming heap base is 0)
Set N = 9 If 9th bit of input stream is 0 Increase HEAPINDEX by 1 fi
VALUE = HEAP (HEAPINDEX) fetch (9th bit code)
Loop
If VALUE == 0001 0000 1111-(NL)
Sending “inappropriate Huffman symbol” signal exit
else Value VALUE === 1000 eeee eeee
Transfer eeeeee as a value Transfer symbol length N Adjust input stream break
else / * VALUE == 01iii iiiiiiiii-(
MISS)
Set N = N + 1 (HEAPINDEX = ii iiiiii
ii)
If the Nth bit of the input stream is 0
Increase HEAPINDEX by 1 fi
VALUE = HEAP (HEAPINDEX) fetch pool
pool
The stripper 671 deletes the X′00 insertion byte, the X′FF padding byte, and the RSTm marker from the input JPEG 671 encoded stream, and transfers the “clean” Huffman symbol to the shifter 672 along with the concatenated additional bits. In Huffman-only coding, there are no other additional bits, so in this mode the transferred stream consists only of Huffman symbols.

  The shifter 672 block includes a 16-bit output register, and transfers the next Huffman symbol to the decoding unit 673 (in the bit stream in the order of MSB to LSB). The symbol is often 16 bits or less, but it is left to the decoding unit 673 to determine how many bits to analyze. The shifter 672 receives feedback 678 from the decoding unit 673, that is, the current symbol length and the additional bit length following the current symbol (in JPEG mode), and appropriately aligns the start time of the next symbol in the shifter 672.

  The decryption unit 673 has a core of an algorithm based on a heap, and is connected to the data cache via the Obus 674. The decoding unit 673 includes a data cache fetch block, a lookup value comparison unit, a symbol length counter, a heap index addition unit, and an additional bit number decoding unit (decoding is performed based on the decoded value). Here, the fetch address is interpreted as follows.

  Fetch address

  The output formatter block 676 decodes 8-bit values (stand-alone Huffman mode), and combines 24-bit values, additional bits, and RSTm marker information into 32-bit words (JPEG mode). The additional bits are transferred to the output formatter 676 by the shifter 672 after the decoding unit 673 determines the start position of the additional bits for the current symbol. The output formatter 673 also includes a 2 deep FIFO buffer that uses a 1 word delay to predict the final value word. In the decoding process, the shifter 672 (both high speed and low speed) may attempt to decode the padding bit at the end of the input bitstream. Such a state is normally detected by the shifter, and instead of sending an “inappropriate symbol” interrupt, a “forced termination” signal is sent. When an active “kill” signal is sent, the output formatter 676 sends the last one decoded word (still in the FIFO) as “last” and the more recent word that does not belong to the decoded stream. delete.

  FIG. 72 shows details of the Huffman encoder 660 in FIG. The Huffman encoder 660 maps byte data to Huffman symbols via a lookup table, and includes a lookup table accessed from the encoding unit 681, shifter 682, output formatter 683, and cache. The input value 685 is encoded by the encoding unit 681 using the encoding table stored in the data cache. As the tables, two tables, that is, a table including a corresponding code and a table including a code length are required for each value to be encoded. However, when encoding a symbol, the cache 230 may be accessed only once. In JPEG compression, a separate table is required for each AC coefficient and DC coefficient. Further, when subsampling is performed, a separate table is required for each subsample element and non-subsample element. Non-JPEG compression requires only two tables (code and size). The code is processed by shifter 682 to construct the output stream at the bit level. The shifter 682 also performs RSTm and EOI marker insertion processing, which is byte padding processing when necessary. Then, the data bytes are transferred to the output formatter 683, and an insertion process with X'00 bytes, a stuffing process with X'FF bytes and FF bytes prior to the marker code, and a packed byte formatting process are performed. In the non-JPEG mode, only the packed byte format processing is performed.

  Since the X′FF byte insertion process is performed by the shifter 682, the output formatter 683 needs to know which byte from the shifter 682 is the marker in order to insert the X′FF byte forward. This is done by providing in the shifter 682 a tag register corresponding to the byte. Each marker present at a byte boundary is tagged by a shifter 682 in the marker insertion process. The combination processing unit 683 does not perform insertion processing after the X "FF" byte preceding the marker. The tag is shifted in synchronization with the main shift register.

The Huffman encoder uses 4 or 8 tables in JPEG compression and uses 2 tables directly for Huffman encoding. The table used is shown below.
Table used in a Huffman encoder

3.17.4 Table Indexing The Huffman table is stored locally in the coprocessor data cache 230. The data cache 230 is configured as a 128 line direct mapping cache with each line consisting of 8 words. Each word in the cache line can be addressed independently, and this feature is used by the Huffman decoder to access multiple tables simultaneously. Since the table is small (≦ 256 items), an index to multiple tables can be included in the 32-bit address field of Obus.

As described above, in the JPEG low-speed decoding mode, a data cache is used to store various Huffman tables. The format of the data cache is shown below.
Bank address of Huffman / quantization table

  Prior to execution of the JPEG instruction in the JPEG encoder 241 (FIG. 2), an appropriate image width value must be set in the image dimension register (PO_IDR) or (RO_IDR). As with other instructions, the length of the instruction is related to the number of input data items to be processed. This includes any padding data and is related to the subsampling options and number of color channels used.

  All instructions issued by the coprocessor 224 use two functions to limit the amount of output data generated. These functions are most effective when the input and output data sizes are different, and are particularly effective when the output data size is unknown as in JPEG encoding / decoding. These functions determine whether to write the output data or simply delete the data while making it appear that the instruction was properly executed. By default, this feature is turned off and is turned on by enabling the appropriate bit in the RO_CFG register. However, the JPEG instruction provides a special option for setting this bit. Note that when using JPEG compression, the coprocessor 224 preferably supports “delete” and “restrict” functions of output data.

  The deletion / limitation process will be described with reference to FIG. The input image 690 has a certain height 691 and a certain width 692. Here, there are often situations where only one part of the image is of interest and the other part is irrelevant to printing. However, the JPEG encoding system targets 8 × 8 pixel blocks. For this reason, there are cases where the width of the image does not become a multiple of 8, or the region of interest constituting the MCU 695 does not exactly match the boundary. Therefore, the output deletion register RO_CUT determines the number of output bytes to be deleted in the first part 696 of the output data stream. The output restriction register RO_LMT determines the maximum number of output bytes to be generated. This maximum number of output bytes includes bytes that are not written to memory based on the result of the delete register. By such processing, it is possible to obtain a final output byte in which data after the final output byte 698 is not output.

  There are two cases where the deletion and restriction functions in the JPEG decoder are particularly effective. The first case is a case where one part 700 of one strip 701 of the decoded image is extracted or decompressed as shown in FIG. The second case is when a plurality of complete strips (eg, 711, 712, 713) need to be extracted or decompressed in the entire image 714 as shown in FIG.

FIG. 76 shows the instruction format and field encoding of the JPEG instruction. A description of the minor opcode field follows.
Instruction word-minor opcode field

3.17.5 Data Encoding Instructions Coprocessor 224 preferably has the capability to use a portion of the JPEG encoder of FIG. 2 for other purposes. For example, Huffman coding is used not only in JPEG but also in other compression methods. It is also desirable that a data encoding instruction for controlling the Huffman encoder only for hierarchical image decoding is provided. Furthermore, the Runlenx encoder / decoder and the predictive encoder can also be used independently with similar instructions.

3.17.6 High Speed DCT Device In a conventional discrete cosine transform (DCT) device as shown in FIG. 77, first, a one-dimensional DCT is performed in the column direction of 8 × 8 blocks, and then an 8 × 8 pixel block. Further, two-dimensional transformation of 8 × 8 pixel blocks is performed by further one-dimensional DCT in the row direction. Such a device generally includes an input circuit 1096, an arithmetic circuit 1104, a control circuit 1098, a replacement memory circuit 1090, and an output circuit 1092.

  Input circuit 1096 receives 8-bit pixels from an 8 × 8 block. The input circuit 1096 is connected to the arithmetic circuit 1104 via the intermediate multiplexers 1100 and 1102. Arithmetic circuit 1104 performs arithmetic processing on complete columns or rows of 8 × 8 blocks. The control circuit 1098 controls all other circuits and executes the DCT algorithm. The output of the arithmetic circuit is sent to the replacement memory 1090, the register 1095, and the output circuit 1092. The replacement memory is further connected to a multiplexer 1100 that sends the output to the next multiplexer 1102. The multiplexer 1102 also receives data from the register 1094. The replacement circuit 1090 inputs 8 × 8 block data in a column format and outputs data in a row format. Output circuit 1092 outputs DCT coefficients for an 8 × 8 block of pixel data.

  In a normal DCT device, the arithmetic circuit 1104 is the most complex, so the speed of the arithmetic circuit 1104 determines the overall device speed. The arithmetic circuit 1104 in FIG. 77 generally performs arithmetic processing by dividing the arithmetic processing into a plurality of processing stages as described with reference to FIG. Thus, a single circuit is used that performs each processing stage 1144, 1148, 1152, 1156 using normal resources such as adders and multipliers. Such an arithmetic circuit 1104 has the disadvantage that it is slower than the optimum speed because a single common circuit is used to perform the various processing steps of the circuit 1104. This also includes storage means for storing intermediate results. Since the clock cycle time of the circuit must be at least the slowest circuit stage, the overall processing time can be more than the sum of the time required for each processing stage.

  FIG. 78 shows a normal arithmetic data path in the apparatus shown in FIG. 77, and shows a part of processing for performing DCT in four processing stages. In addition, this figure does not show actual implementation but shows functions. Each of the four processing stages 1144, 1148, 1152, 1156 is constructed as a single reconfigurable circuit. For each cycle, each of the four processing stages 1144, 1148, 1152, 1156 of the one-dimensional DCT is reconfigured. In this circuit, each of the four processing stages 1144, 1148, 1152, and 1156 uses a pool of common resources (such as an adder and a multiplier), thereby reducing the hardware scale.

  However, the disadvantage of this circuit is that the speed is not optimal. Each of the four processing stages 1144, 1148, 1152, 1156 is composed of the same pool of adders and multipliers. Therefore, the clock period is determined by the slowest processing stage (in this example, 20 ns of block 1144). Adding the delay of the input and output multiplexers 1146 and 1154 (2 ns each) and the delay of the flip-flop 1150 (3 ns) gives a total delay of 27 ns. Therefore, this DCT configuration operates at a maximum speed of 27 ns.

  Pipelined DCT configurations are also well known. The disadvantage of this configuration is that it requires a large amount of hardware. From the viewpoint of throughput, the configuration of the present invention does not reach the pipeline configuration, but exhibits extremely good performance / size characteristics and speed characteristics as compared with most current DCT configurations. FIG. 79 is a diagram showing a configuration of a preferred discrete cosine transform unit used in a JPEG encoder (FIG. 2) in which pixel data is input to the input circuit 1126 and stores a sequence of 8-bit pixel data. . The replacement memory converts column format data into row format data in order to perform the second pass of the two-dimensional discrete cosine transform. The memory from the input circuit 1126 and the replacement memory 1118 is multiplexed in the multiplexer 1124 and the output data is sent to the arithmetic circuit 1122. The result of the arithmetic circuit 1122 is sent to the output circuit 1120 after completion of the second pass. The control circuit 1116 controls the flow of data in the discrete cosine transform device.

  In the first pass of the discrete cosine transform process, transformed image coefficients that are inversely transformed into column data or pixel data of an image to be transformed are sent to the input circuit 1126. In this path, the multiplexer 1124 is set by the control circuit 1116, and data is sent from the input circuit 1126 to the arithmetic circuit 1122. FIG. 80 is a diagram showing the configuration of the arithmetic circuit 1122 in more detail. In the case of executing the forward discrete cosine transform, the result of the forward circuit 1138 that performs the forward discrete cosine transform is selected by the multiplexer 1124. Here, the multiplexer 1124 is set by the control circuit 1116. In the case of executing the inverse discrete cosine transform, the output from the inverse circuit 1140 is selected by the multiplexer 1142 based on the setting of the control circuit 1126. In the first pass, each column vector is processed by arithmetic circuit 1122 (which is set appropriately by control circuit 1166), and then the vector is written to replacement memory 1118. When all 8 column vectors in the 8 × 8 block have been processed and written to the replacement memory 1118, the second pass of the discrete cosine transform is started.

  In the second pass of the forward or inverse discrete cosine transform, the row format vector is read from the permutation memory 1118 and sent to the arithmetic circuit 1122 via the multiplexer 1124. In this path, the multiplexer 1124 is set by the control circuit to ignore the data from the input circuit 1136 and transfer the row vector data from the permutation memory 1118 to the arithmetic circuit 1122. The multiplexer 1142 in the arithmetic circuit 1122 sends the result data from the inverse circuit 1140 to the output of the arithmetic circuit 1122. When the result from the arithmetic circuit 1122 is obtained, the output circuit 1120 captures the result based on a command from the control circuit 1116 and outputs it at a subsequent time.

  The arithmetic circuit 1122 is a combinational circuit in that it does not have a storage part for storing intermediate results. Since the control circuit 1116 knows the time required for data to be output from the input circuit 1136 via the multiplexer 1124 or the arithmetic circuit 1122, the time point when the result vector from the output of the arithmetic circuit 1122 is taken into the output circuit 1120 Can be indicated accurately. The advantage of not having intermediate storage in the arithmetic circuit 1122 is that the time required for data exchange with the intermediate storage element can be omitted, and the time required for data to pass through the arithmetic circuit 1122 is an internal processing stage. It can be mentioned that all the sums are not N times that of the processing stage requiring the maximum time (as in a conventional discrete cosine transform device). Here, N is the number of processing stages in the arithmetic circuit.

  FIG. 81 shows that the overall delay is simply the sum of four processing stages 1158, 1160, 1162, 1164, 20 ns + 10 ns + 12 ns + 15 ns = 57 ns, which is faster than the circuit of FIG. According to such a circuit, the entire system clock cycle can be shortened. In the circuit of FIG. 81, if 4 clock cycles are required to obtain the result, the minimum execution time is 57/4 ns (14.25 ns) in the entire DCT system, and in FIG. 78, the DCT clock cycle is 27 ns. In view of the fact that it is not obtained, it can be seen that the performance is greatly improved.

  In actual execution of the present DCT apparatus, TheTransactions of the IEICE, vol. E71, no. By Yukihiro Arai, Takeshi Agui, Masayuki Nakajima et al. 11, the DCT algorithm shown in the paper “Fast DCT-SQ Method for Images” published on page 1095 of November 1988 can also be used. By executing this algorithm by hardware, it can be easily arranged in the arithmetic circuit 1122 in the present DCT apparatus. Similarly, other DCT algorithms can be placed in the arithmetic circuit 1122 as hardware.

3.17.7 Huffman Decoder The following example relates to a technique and apparatus for variable length codes in which bit fields of various lengths are interleaved. In particular, embodiments of the present invention provide efficient, fast, single processing stage (clock cycle) decoding of variable length encoded data. Here, it is assumed that the data that is not variable-length-coded but arranged is already deleted from the encoded data stream in another preprocessing block. Further, the position information of the deleted byte aligned data is sent to the decoder output simultaneously with the data to be decoded. It also provides for byte alignment remaining in the preprocessed input data, fast detection and deletion of non-variable length encoded bit fields.

  In the preferred embodiment of the present invention, it is desirable to have a high speed Huffman decoder capable of decoding JPEG encoded data at a rate of one Huffman symbol per clock cycle between marker codes. This can be realized by a technique of separating and removing a marker header, a marker code, and an insertion byte that are byte-aligned and not Huffman-coded from input data in another preprocessing block. When the byte aligned data is removed, the input data is sent to the data shift combinational circuit block, the data decoding register is continuously inserted, and the data is sent to the decoding part. The marker position removed from the original input data is sent to the marker shift block, and the marker position bit is shifted simultaneously with the input data shifted in the data shift block.

  The decoding unit decodes the encoded bit field input from the data decoding register by the combinational circuit. The output of the decoding unit is the decoded value (v) and the actual length (m) of the input code. Here, m is n or less. Also, the length (a) of the variable length bit field is output. Here, a is a value of 0 or more. Since the variable length bit field is not Huffman encoded, it is immediately Huffman encoded. The bit field of length n in the input of the decoding unit has a length longer than the actual code. The decoding unit determines the actual code length (m) and transfers it to the control block together with the length of the other bits (a). The control block determines the shift value (a + m) and activates the data / marker shift block to shift the input data in preparation for the next decoding cycle.

  In the device of the present invention, any combination of ROM, RAM, PLA, etc., as long as the decoded value, the actual length of the input code, and the length of the bit field that is not Huffman-coded are output within a predetermined time. The decoding part of the circuit can be used. In this embodiment, the decoding unit outputs a predictive coding DC coefficient value and an AC run-lens value as defined in the JPEG standard. Further, as defined in the JPEG standard, the bit field that is not Huffman-coded and removed from the input data simultaneously with the decoded value indicates additional bits that determine the values of the DC and AC coefficients. Other types of non-Huffman-encoded bit fields removed from the data in the data decoding register include padding bits preceding the byte alignment marker in the original input data stream as specified in the JPEG standard. is there. These bits are detected by the control block checking the contents of the padding area of the data register. The padding area consists of k maximum bits of the data register and is indicated by the presence of marker bits in the maximum bits of the marker register. If all bits in the padding area are the same (1 in the JPEG standard), it is determined as a padding bit and removed from the data register without being decoded. The data and the contents of the marker register are updated for the next decoding cycle.

  The apparatus embodiment includes an output block for formatting output data in response to the requirements of the preferred embodiment of the present invention. The output block is a signal indicating the position of the corresponding non-encoded bit field such as an additional bit in JPEG, the input byte aligned as in the marker in JPEG, or the unencoded bit field. At the same time, the decoded value is output.

  The data decoded by the JPEG encoder 241 (FIG. 2) is JPEG compatible and is not a variable-length encoded bit field called “additional bit” and a variable-length encoded called “padding field”. A knit field, consisting of a variable length Huffman coded code interleaved with a fixed length, byte aligned, uncoded bit field called "marker", "insert byte", "padded byte". FIG. 82 shows typical input data.

  83 and 84 show the overall configuration and data flow in the Huffman decoder of the JPEG encoder 241. FIG. FIG. 83 shows the configuration of a JPEG data Huffman decoder in detail. The stripper 1171 removes the marker code (codes FFXXhex and XX are non-zero), inserts a byte (code FFhex), and packs a byte (code 00hex following the code Ffhex). These are all byte-aligned elements of the input data and are sent to the stripper as 32-bit words. The maximum bit of the first word to be processed is at the beginning of the input bitstream. In the stripper 1171, the byte aligned bit fields are removed from the input data before the Huffman code decoding process is actually performed in the downstream part of the decoder.

  Input data is input to the stripper 1171 as one 32-bit word per clock cycle. The numbering of input bytes 1211 from 0 to 3 is shown in FIG. If the byte of number (i) is removed because it is an insertion byte, a padding byte or a marker, the remaining bytes of 0 from number (i-1) are shifted to the left at the output of the stripper 1171 and the number (i ) Is reduced by one. At this time, byte 0 becomes an “irrelevant” byte. The validity of the bytes output from the stripper 1171 is encoded by another output tag 1212 shown in FIG. Bytes that are not removed by the stripper 1171 are output left-justified in the stripper. Each byte being output is tagged with a tag indicating whether the corresponding byte is valid (passes stripper 1171), invalid (removed by stripper 1171), or valid and after the marker. The tag 1212 controls the loading of data bytes into the data register 1182 through the data shifter, and controls the loading of the marker position into the marker register 1183 through the marker shifter. The same method is executed even when one byte or more is deleted from the input word. That is, all remaining valid bytes are left justified and the corresponding output tag indicates the validity of the output byte. FIG. 85 shows output byte and output tag examples 1213 for various combinations of input bytes.

  In FIG. 83, the roles of the pre-shifter and post-shifter blocks 1172, 1173, 1180, and 1181 are to load data continuously to the data register and marker register when there is sufficient free space in the data register 1182 and marker register 1183. That is. The data shifter and marker shifter block are composed of a pre-shifter block and a post-shifter block, which are the same and controlled in the same way. The difference is that the data shifter processes the data from the stripper 1171 whereas the marker shifter processes only the tag and outputs the marker position to the decoder simultaneously with the decoded Huffman value. The outputs of the post-shifters 1180 and 1181 are directly transferred to the corresponding registers 1182 and 1183 as shown in FIG.

  86 also shows a data preshifter 1172, but the data preshifter 1172 adds 32 zeros to the minimum bit 1251 to the data from the stripper 1171 and expands the data to 64 bits. The extension data is then shifted to the right by a 64-bit wide barrel shifter 1252 by the number of bits currently present in the data register 1182. At this time, the number of bits is given from the control logic 1185 that always knows how many valid bits exist in the data 1182 and marker 1183 registers. The barrel register 1252 then transfers the 64 bits to a multiplexer block 1253 consisting of 64 2 × 1 basic multiplexers 1254. Each basic 2 × 1 multiplexer 1254 receives one bit from the barrel shifter 1252 and one bit from the data register 1182. Data register bit is output when the bit in the data register is valid. On the other hand, if it is invalid, the bit of the barrel shifter 1252 is output. The control signals to all the basic multiplexers 1254 are the pre-shifter control bits 0. . . 5 is decoded from the shift control 1 signal of the control block. The output of the basic multiplexer 1254 is sent to the barrel shifter 1255 and is shifted to the left by the number of bits given by the 5-bit control signal shift control 2 as shown in FIG. These bits indicate the number of bits used for decoding the current data in the data register 1182, and the padding to be deleted if the current decoding Huffman code length and the number of additional bits following or the padding bits are detected. If the number of bits or the number of valid bits in the data register 1182 is equal to or less than the number of bits to be deleted, 0 is added. In this manner, the data output from barrel shifter 1255 will include new data loaded into data register 1182 after a single decoding cycle. The contents of the data register 1182 are shifted out of the register so that the maximum bits are decoded, and the 0, 8, 16, 24, 32 bits from the stripper 1171 are added to the data register 1182 and so on. If there are not enough bits in the data register 1182 to decode, if there is data from the stripper 1171, it is loaded in the current cycle. If there is no data from the stripper 1171 in the current cycle, the decoded bits from the data register 1182 are deleted if the number of bits is sufficient, and the contents of the data register 1182 are not changed unless the number of bits is sufficient.

  The marker preshifter 1173, the post shifter 1181, and the marker register 1183 are the same parts as the data preshifter 1172, the data post shifter 1180, and the data register 1182, respectively. The data flow in the parts 1173, 1181, 1183 and the data flow between these parts are also the same as the data flow between the parts 1172, 1180, 1182. A similar control signal is sent from the control unit 1185 to both site sets. The difference between these parts is the types of input data of the marker preshifter 1173 and the data preshifter 1172 and how the contents of the marker register 1183 and the data register 1182 are used. As shown in FIG. 88, the tag 1261 from the stripper 1171 is input as an 8-bit word, and 2 bits are allocated for each data byte going to the data register 1182. According to the encoding method shown in FIG. 85, the maximum bit of a 2-bit tag indicating a byte that is valid and is at the rear of the marker is 1. Only the maximum bit positions of the four tags sent simultaneously from the stripper 1171 are sent out as the input 1262 of the marker preshifter 1173. In this way, the input to the marker preshifter includes a bit in which 1 indicating the position located at the rear of the marker is set in the data bit encoded first. At the same time, they mark the position of the first encoded data bit followed by a marker in the data register 1182. The synchronous behavior of the marker position bit in the marker register 1183 and the data bit in the data register 1182 allows the control block 1185 to detect and delete padding bits and to simultaneously detect the marker position and the decoder position of the decoder. Can be sent to output. As described above, the two pre-shifters (data 1172 and marker 1173), the post-shifter (data 1180 and marker 1181), and the register (data 1182 and marker 1183) are given the same control signal. Is possible.

  The decoding unit 1184 (also shown in FIG. 89) inputs up to 16 bits of the data register 1182, decodes the Huffman value, the current input code length to be decoded, and the additional bit length following the input code (decoding (Which is a function of the value) is sent to the combinational circuit decoding unit 1184 for extraction. The additional bit length becomes clear when the corresponding previous Huffman symbol is decoded, and becomes the start position of the next Huffman symbol. Therefore, to maintain the rate at which one value is decoded per clock cycle, the Huffman value must be decoded in the combinational circuit block. As shown in FIG. 89, the decoding unit inputs a 16-bit token from the data register 1182 and generates a Huffman value (8 bits), a corresponding Huffman-encoded symbol (4 bits), and an additional bit (4 bits). It is desirable to provide four PLA style decoding tables hardwired as such combinational circuit blocks.

  The padding bit deletion process is performed in an actual decoding process when a padding bit string is detected in the data register 1182 in the padding bit decoding unit which is a part of the control unit 1185. FIG. 90 shows a padding bit decoding unit. It is checked whether or not there is a marker position bit among the 8 maximum bits of the marker registers 1183 and 1242. When the marker position bit exists, all the bits in the data registers 1182 and 1241 corresponding to the bits preceding the marker bit in the marker register 1242 are determined as the current padding area. It is checked whether or not the contents of the current padding area are all 1 by the padding bit detection unit 1243. If all the bits in the current padding area are 1, it is determined as a padding bit and is deleted from the data register. Here, the deletion process is performed by shifting the contents of the data registers 1182 and 1241 (at the same time, the marker registers 1183 and 1242) to the left in one clock cycle using the corresponding shifters 1172, 1173, 1180, and 1181. This process is the same as the normal decoding mode except that no decoded value is output. If all the bits in the current padding area are not 1, a normal decoding cycle is executed instead of a padding bit deletion cycle. As described above, the padding bit is detected every cycle, and when the padding bit exists in the data register 1182, it is deleted.

  FIG. 87 shows the control unit 1185 in detail. The central part of the control unit is a register 1223, which holds the current number of effective bits in the data register 1182. The number of valid bits in the marker register 1183 is always equal to the number of valid bits in the data register 1182. The control unit performs three functions. The first function is the calculation of the new number of bits in the data register 1182 stored in the register 1223. The second function is generation of control signals to the shifters 1172, 1173, 1180, 1181, 1186, 1187, the decoding unit 1184, and the output format unit 1188. The third function is detection of padding bits in the data register 1182 as described above.

  The new number of bits (new_nob) in the data register 1182 adds the current number of bits in the data register 1182 (nob) to the number of bits (nos) that can be loaded from the stripper 1171 in the current cycle, and the data register 1182 in the current cycle. Is calculated by subtracting the number of bits to be deleted (nor). Here, the current cycle is a decoding cycle or a padding bit deletion cycle. Therefore, the new number of bits is calculated as follows:

new_nob = nob + nos-nor
These processes are executed by the adder 1221 and the subtractor 1222. If no data is input from the stripper 1171 in the current cycle, (nos) is zero. Further, when there are not enough bits in the data register 1182, that is, the decoding process is not performed in the current cycle because the number of bits in the data register is less than or equal to the sum of the current code length from the control unit 1185 and the subsequent additional bit length In addition, (nos) is 0. The value (new_nob) can exceed 64 and it is checked in block 1224 if it exceeds. In such a case, the stripper 1171 is stopped and no new data is loaded. Multiplexer 1233 is used to zero the number of bits loaded from stripper 1171. Here, a signal for stopping the stripper 1171 is not shown. The signal “padding cycle” from the decoding unit 1231 controls the multiplexer 1234 to select the number of padding bits or the number of decoded bits (length of sign bit and additional bit) as the number of bits to be deleted (nor). If the comparator 1228 determines that the number of decoded bits is equal to or greater than the number of bits (nob) in the data register, the number of effective bits to be shifted supplied to the multiplexer 1234 is set to zero in the NAND gate 1230. That is, (nor) is set to zero, and no deletion of data register bits is performed. The output of the multiplexer 1234 is also used to control the post shifters 1182 and 1183. The width of the data register 1182 is set so as to avoid a deadlock state. That is, it is set so that an area sufficient to accommodate the maximum number of bits from the stripper 1171 is reserved in the data register, or a sufficient number of effective bits is deleted as a result of the decoding / padding bit deletion cycle.

  Calculation of the number of bits to be deleted in the decoding cycle is performed in adder 1226. The operand is input from the combinational circuit decoding unit 1184. Since the code length of 16 bits is encoded as “0000” in the decoding unit, the “ou_reduce” logic 1225 encodes “0000” to “10000” to obtain the current unsigned operand. This operand and the output of subtractor 1227 provide a control signal to output format shifters 1186 and 1187.

  Block 1229 is used to detect the EOI (end of image) marker position. The EOI marker itself is deleted in the stripper 1171, but there is a padding bit that is the last bit of the data that existed at the position preceding the EOI marker before being deleted by the stripper 1171. The comparator 1229 checks whether the number of bits in the data register 1182 stored in the register 1223 is 8 or less. If it is 8 or less, new data is not input from the stripper 1171 (the data register 1182 holds the remaining bits of the data portion to be decoded), and the padding area before the EOI marker from which the remaining bits are deleted Will indicate the size. Further processing of the padding area, deletion of the padding bits, and the like are the same as the procedure used in the case of the padding bits before the RST marker described above.

  The barrel shifters 1186 and 1187 and the output format unit 1188 have allocations that support them, and various implementations can be considered according to the embodiments. It may also not be implemented at all. The control signals for these are given from the control unit 1185 as described above. The additional bit preshifter 1186 receives 32 bits from the data register and shifts to the left by the currently decoded Huffman code length. In this way, all additional bits following the currently decoded code will be positioned to the left with the output of the barrel shifter 1186 and sent as input to the barrel shifter 1187. The additional bit post shifter 1187 adjusts the additional bit position from the left alignment to the right alignment in the 11-bit field used as the data output format and also shown in FIG. The additional bit field is expanded from bit 8 to bit 18 in the output word format 1196, and some of the maximum bits may be invalid depending on the actual number of additional bits. This number of bits is encoded into 1196 bits 0 to 3 as specified in the JPEG standard. When a different format is used as the output data format, the barrel shifters 1186 and 1187 and their functions are changed according to the format.

  The output format block 1188 performs a process of packing the decoded value. In the JPEG standard, a DC / AC coefficient (1196, bits 0 to 7), a DC coefficient instruction bit (1196, bit 19), and an additional bit post given from the control unit 1185 are used. An additional bit (1196, bits 8 to 18) given from the shifter 1187 and a marker position bit (1196, bit 23) given from the marker register 1183 are processed into a word according to the format shown in FIG. The output formatting unit 1188 also addresses functional requirements regarding the output interface of the decoding unit. The implementation of the output format section is usually changed accordingly when the output interface is changed as a result of different functional requirements. The Huffman decoder described above provides a very effective decoding process and realizes a high-speed decoding process.

3.17.8 Image Conversion Instructions These instructions are for performing a general affine transformation of the source image. The process of generating a part of the converted image is roughly divided into two areas. One is to determine which part of the source image is associated with the current output scan line, and the other is to perform the necessary sub-sampling / interpolation process to generate an output image for each pixel.

  FIG. 92 shows a flowchart of the steps 720 required to calculate the target pixel value, assuming that the appropriate region of the source image has been decoded. First, if subsampling has been performed, the subsample is considered in 721. Next, two processes such as another interpolation process 722 and another sub-sampling process are usually implemented. Usually, interpolation and subsampling are separate steps, but interpolation and subsampling may be performed together. In the interpolation process, first, surrounding four pixels are searched, and whether or not the pre-multiplication 723 is necessary is determined before performing the bilinear interpolation 724. Since the bilinear interpolation processing 724 generally has a very large amount of calculation, this restricts the image conversion processing operation. The final step in calculating the target pixel value is the process of adding the bi-linearly interpolated subsamples from the source image. The summed pixel values are integrated 727 in various ways to produce a target image pixel 728.

The instruction word code for the image conversion instruction is shown in FIG. 93, and the minor opcode field is described in the following table.
Instruction word: minor opcode field

Instruction operands and result fields are described below.
Instruction operand and result word

Operand A refers to a data structure known as a “kernel descriptor” that describes all the information necessary to define the actual transformation. This data structure is in one of two formats (defined by the L bit of the A descriptor). FIG. 94 shows the long code format of the kernel descriptor, and FIG. 95 shows the short code format. The kernel descriptor describes the following information:
1. Source image start coordinate 730 (unsigned fixed length, 24.24 resolution). The position (0, 0) is the upper left of the image.
2. Horizontal 731 and vertical 732 (subsample) delta (2's complement, fixed length, 24.24 resolution)
3. A 3-bit bp field 733 indicating the position of a binary point in a fixed-length matrix coefficient described later
4). Integration matrix coefficient 735 (if present). These are the “variable” point resolution (2's complement) of 20 binary points, which are the positions of the binary points implicitly specified by the bp field.
5). An rl field 736 indicating the number of remaining words in the kernel descriptor. This value is obtained by subtracting 1 from the product of the number of columns and the number of rows.

  Although the kernel coefficients of the descriptor are arranged for each column, adjacent columns are arranged in the reverse direction so as to perform a zigzag scan. In FIG. 96, operand B consists of a pointer to an index table that points to the scan line of the source image. As shown in FIG. 96, the structure of the index table is such that the operand B 740 points to the index table 741, and the index table points to the scan line (eg, 742) of the source image pixels that are required. In general, the index table and source image pixels are cacheable and are located in local memory.

  Operand C holds the horizontal / vertical subsample rate. The horizontal / vertical subsample rate is defined by the dimensions of the subsample weight matrix specified when the C descriptor is present. The dimensions of the matrices r and c are encoded in the data word of the image conversion command as shown in FIG. The channel N of the result pixel P [N] is calculated based on the following equation:

  Internally, the integral value is held as 36 binary points for each channel. The position of the binary point in the field is specified by the BP field. The BP field indicates the number of bits ahead of the integration result to be deleted. The 36-bit integral value is expressed as a signed 2's complement number and is clamped or wrapped as specified. FIG. 98 shows an example of interpretation of the BP field in the coefficient code.

3.17.9 Convolution Instructions A convolution process applied to a rendered image applies a two-dimensional convolution kernel to a source image to generate a result image. The convolution process is usually used in edge sharpening and various image filters. The convolution process is implemented in the coprocessor 224. In the image conversion process, the kernel is shifted by the kernel width for each output pixel, whereas in the convolution process, one source pixel is moved for each output pixel. This is the same processing as the image conversion processing.

  If the source image has the value S (x, y) and the nxm convolution kernel has the value C (x, y), the nth channel of the S and C convolution H [n] is

  Given in. Here, iε [0, c], jε [0, r]. The meaning of the offset value, the resolution of the intermediate result, and the meaning of the bp field are the same as those of the image conversion command. FIG. 99 is a diagram illustrating an example in which the convolution kernel 750 applies the source image 751 to generate a result image 752. Source image address generation and output pixel calculation are performed in the same manner as the image conversion command. The command operand is also in the same format as image conversion. FIG. 100 shows the instruction word code of the convolution instruction, and the following table describes the various fields.

  Instruction word

3.17.10 Matrix multiplication Matrix multiplication is used for color space conversion processing in which there is an affine transformation relationship between two color spaces. Matrix multiplication is defined by the following equation.

Matrix multiply instruction operands and result words have the following format:
Instruction operand and result word

Figure 101 shows instruction word codes for matrix multiplication instructions, and the following table shows minor opcode fields.

3.17.11 Halftoning The coprocessor 224 includes a multilevel dither for halftoning. Values between 2 and 255 are meaningful halftone levels. The halftoning data can be either bytes (one channel from unmesh or mesh data) or pixels (mesh) as long as the screen is mesh or unmesh corresponding. Up to 4 output channels (or 4 bytes from the same channel), packed bits that are packed together or unpacked into 1 code per byte (in case of 2 level halftone) or code (2 output levels or more) In case of)

The output halftone value is calculated using the following formula:
(P × (l−1) + d) / 255
Here, p is a pixel value (0 ≦ p ≦ 255), l is the number of levels (2 ≦ l ≦ 255), and d is a dither matrix value (0 ≦ d ≦ 254). Operand codes are as follows.
Instruction operand and result word

In the command word code, the minor opcode specifies the number of halftone levels. The operand B code is for a halftone screen and is encoded in the same way as tile synthesis.
3.17.12 Hierarchical image format decoding The hierarchical image format decoding process includes a plurality of steps. These steps are horizontal interpolation, vertical interpolation, Huffman decoding, and residual fusion. Each step is executed with a separate instruction. In the Huffman decoding step, the remaining value added to the interpolated value from the interpolation step is Huffman encoded. Therefore, the JPEG decoding unit is used in Huffman decoding.

  FIG. 102 shows the horizontal interpolation process. The output stream 761 has twice the data of the input stream 672, and the last data value 763 is duplicated 764. FIG. 103 shows an example in which quadruple horizontal interpolation is performed. In the second step of hierarchical image format decoding, the pixel sequence is upsampled vertically by a factor of 2 or 4 by linear interpolation. In this step, one pixel column is operand A and the other column is operand B.

  In the case of vertical interpolation, the output data stream has the same number of pixels as the input stream in both cases of double and quadruple. FIG. 104 shows an example of vertical interpolation in which two input data streams 770 and 771 are used to generate a double interpolation output stream 772 and a quadruple interpolation output stream 773. In the case of pixel interpolation, the interpolation process is performed separately for each of the four channels of the four channel pixels.

  The remainder fusion process includes byte-by-byte addition of the two data streams. The first stream (operand A) is a base value stream, and the second stream (operand B) is a residual value stream. FIG. 105 shows two input streams 780 and 781 and an output stream 782 corresponding to the case where the remaining part fusion processing is used.

FIG. 106 shows the instruction word code of the hierarchical image format instruction, and details of the minor opcode field are shown in the following table.
Instruction word-minor opcode field

3.17.13 Instruction Copy Instructions These instructions are divided into two separate groups.
a. General Data Movement Instructions These instructions use a normal data flow path within the coprocessor 224 consisting of an input interface module, input interface switch 252, pixel organizer 246, JPEG encoding unit 241, result organizer 249, and output interface module. In this case, the JPEG encoding module sends the data directly without processing.

Other commands for data manipulation operations include the following.
-Packing and unpacking of sub-byte values (bits, 2-bit values, 4-bit values) into bytes-Packing and unpacking bytes within a word-Alignment-Byte lane swapping and duplication-Memory clear-Duplicate value data The operation is performed by a combination of a pixel organizer (input) and a result organizer (output). In many cases, these instructions are used in combination with other instructions.
b. Local DMA instruction No data manipulation is performed. As shown in FIG. 2, data transfer (bidirectional) is performed between the local memory 236 and the peripheral interface 237. These instructions are the only instructions whose execution overlaps with other instructions. At most one of these instructions can be executed simultaneously with a “non-overlapping” instruction.

In the memory copy operation, the operand A indicates data to be copied, and the result operand indicates the target address of the memory copy instruction. In the general-purpose memory copy instruction, the data manipulation operation to the input is defined by the operand B, and the operation to the output operand word is defined by the operand C.
3.17.14 Flow Control Instructions Flow control instructions are a group of instructions for controlling various parts of the instruction execution model as shown in FIG. Flow control instructions include conditional jumps or unconditional jumps that allow movement from one virtual address to another when the instruction stream is executed. A conditional jump instruction is determined by masking the associated field with a coprocessor or register and comparing it with a predetermined value. Thereby, the generality of the instruction can be maintained. In addition, flow control instructions also include wait instructions that are used to synchronize between overlapping and non-overlapping instructions or as part of microprogramming.

FIG. 107 shows the code of the flow control instruction. The following table describes minor opcodes.
Instruction word-minor opcode field

  In a jump instruction, the operand A word specifies the target address of the jump instruction. If the S bit of the minor opcode is set to 0, operand B specifies a coprocessor register and is used as the source of the condition. The value of the operand B descriptor designates the register address, and the value of the operand B word is a value for comparing the register contents. The operand C word specifies a bit-wise mask applied to the result. In other words, the jump instruction condition is true if the following bitwise expression is satisfied.

(((Register_value xor Operating B) and Operating C) = 0x00000000)
Further, the instruction is used for register access for sufficient control at the microprogramming level.
3.18 Accelerator Card Modules Various modules are further described in FIG.

3.18.1 Pixel Organizer The pixel organizer 246 specifies the address of the data stream from the input interface switch 252 and stores it in the buffer. Input data is stored in the internal memory of the pixel organizer or stored in the MUV buffer 250. After all necessary data processing for the input stream is completed, the input stream is passed to the main data path 242 or the JPEG encoder 241 as necessary. The operation mode of the pixel organizer can be configured by a normal CBus interface. Pixel organizer 246 operates in one of five modes as specified by the PO_CFG control register. These modes are as follows:
(A) Idle mode: A mode in which the pixel organizer 246 does not operate.
(B) Sequential mode: A mode in which input data is stored in the internal FIFO, and the pixel organizer 246 generates a 32-bit address of the data and requests data from the input interface switch 252.
(C) Color space conversion mode: A mode in which the pixel organizer buffers pixels for color space conversion. Further, the interval and fraction value stored in the MUV buffer 250 are requested.
(D) JPEG compression mode: A mode in which the pixel organizer 246 stores image data in the MUV buffer in the MCU format.
(E) Convolutional operation and image conversion mode: a mode in which the pixel organizer 246 stores matrix coefficients in the MUV buffer 250 and communicates them to the main data path 242 if necessary.

  Pixel organizer 246 uses MUV buffer 250 for operation of both main data path 242 and JPEG encoder 241. In color space conversion, the interval and fraction table is stored by the MUV RAM 250 and is accessed as 36-bit data (4 color channels) × (4 bit interval value and 8 bit fractional value). For image conversion and convolution operations, MUV RAM 250 stores matrix coefficients and associated configuration data. The coefficient matrix is limited to 16 rows × 16 columns, and the width of each coefficient is a maximum of 20 bits. MUVRAM 250 requires one coefficient per clock cycle. In addition to the coefficient data, control information such as binary points, source start coordinates, subsample delta, etc. must also be communicated to the main data path 242. This control information is fetched by the pixel organizer 246 prior to the matrix coefficients.

  In JPEG compression, the pixel organizer 246 uses the MUV buffer 250 to double buffer the MCU. In order to improve the performance of JPEG compression, it is desirable to use a double buffer technique. One half of the MUV RAM 250 is written using data from the input interface switch 252. On the other hand, the other half is read by the pixel organizer to obtain data to be sent to the JPEG encoder 241. The pixel organizer 246 performs horizontal sub-sampling of the color components where needed, and pad the MCU if the input image size is not an integer multiple of the MCU.

  The pixel organizer 246 also formats the input data including the byte lane swap, normalization, byte replacement, byte pack and unpack, and copying operations described above with reference to FIG. Operations are performed as needed by setting pixel organizer registers. In FIG. 108, the pixel organizer 246 will be described in more detail. The pixel organizer 246 operates according to the control of its own register set included in the CBus interface control unit 801, and the CBus interface control unit 801 is connected to the instruction control unit 235 via the global CBus. The pixel organizer 246 includes an operand fetch unit 802, and requests operand data required by the pixel organizer 246 from the input interface switch 252. The start address of the operand data is specified by the PO_SAID register set immediately before execution. The PO_SAID register may hold immediate data according to the specification by the L bit of the PO_DMR register. The current address pointer is stored in the PO_CDP register and is increased by its burst length if requested by the input interface switch. When data is fetched into the MUV RAM 250, the current offset of the data is concatenated with the base address of the MUV RAM 250 specified by the PL_MUV register.

  A FIFO 803 is used to buffer the sequential input data fetched by the operand fetch unit 802. The data operation unit 804 executes various operations as described in FIG. The output of the data operation unit is transmitted to the MUV address generation unit 805. The MUV address generation unit 805 transmits the data to one of the MUV RAM 250, the main data path 242, and the JPEG encoder 241 according to the configuration register. Pixel organizer controller 806 is a state machine that generates the necessary control signals for all sub-modules of pixel organizer 246. Among the necessary signals, signals for controlling communication on various bus interfaces are also included. The pixel organizer control unit outputs diagnostic information required by the other module 239 in accordance with the setting of the status register.

  109 shows the operand fetch unit 802 of FIG. 108 in more detail. The operand fetch unit 802 includes an instruction bus address generation unit (IAG) 810 and includes a state machine that generates a request to fetch operand data. This request is sent to the request arbitration unit 811. The request arbitration unit 811 arbitrates between the request of the address generation unit 810 and the request of the MUV address generation unit 805 (FIG. 108), and inputs the winning request ( MAG) interface switch 252. Request arbitration unit 811 includes a state machine for handling requests. This uses the FIFO count unit 814 to monitor the state of the FIFO and determine when the next request should be dispatched. The byte enable generation unit 812 receives the information of the IAG 810 and generates a byte enable pattern 816 that specifies a valid byte in each operand that the input interface switch 252 returns. The byte enable pattern is stored in the FIFO along with associated operand data. When the MAG request and the IAG request arrive at the same time, the request arbitration unit 811 processes the MAG request with priority over the IAG request.

  In FIG. 108, the MUV address generation unit 805 operates in several different modes. In these modes, the first is the JPEG (compression) mode. In this mode, input data for JPEG compression is supplied by the data operation unit 804, and the MUV buffer 250 is used as a double buffer. The MUV RAM 250 address generation unit 805 generates an MUV buffer address suitable for storing the input data processed by the data operation unit 804. The MAG 805 generates a read address for retrieving color component data from the stored pixels and operates to form an 8 × 8 block for JPEG compression. The MAG 805 handles the case where the MCU partially overlaps the image. FIG. 110 shows an example of a padding operation performed by the MAG 805.

  In normal pixel data, the MAG 805 stores four color components in the same address in four 8-bit RAM MUV RAMs 250. In order to simultaneously retrieve data from the same color channel, the MCU data is barrel shifted left and then stored in the MUV RAM 250. The number of bytes shifted to the left of the data is determined by the lower 2 bits of the write address. For example, FIG. 111 shows a data structure in which 32-bit pixel data is arranged in the MUV RAM 250 when sub-sampling is not required. In 3-channel or 4-channel interleaved JPEG mode, subsampling of the input data may be selected. In the multi-channel JPEG compression mode with subsampling, the MAG 805 (FIG. 108) performs subsampling before 32-bit data is stored in the MUV RAM 250 for optimal performance of the JPEG encoder. Of the first four input pixels, only the first and fourth channels stored in the MUV RAM 250 contain useful data. The second and third channel data is subsampled and stored in the pixel organizer 246 registers. In the next four input pixels, the second and third channels are filled with subsampled data. FIG. 112 shows an example of MCU data configuration in the multi-channel subsampling mode. MAG treats all single channel unpacked data exactly like multi-channel pixel data. An example of single channel pack data read from the MUV RAM is shown in FIG.

  While the input MCU is stored in the MUV RAM by the write process, the read process reads 8 × 8 blocks from the MUV RAM. In general, the block is generated by the MAG 805 by four coefficients by sequentially reading data for each channel. In the pixel data and the unpacked input data, the stored data is organized as shown in FIG. Thus, to synthesize an 8 × 8 block of unsampled pixel data, the read process reads the data from the MUV RAM while skewing. FIG. 114 shows an example of such a process. FIG. 114 shows a reading sequence for four channel data, and it can be seen that the storage format of the MUV RAM 250 facilitates reading multiple values from the same channel simultaneously.

  In the color conversion mode, the MUV RAM 250 is used as a cache for storing intervals and fractional values, and the MAG 805 serves as a control unit for the cache. MUV RAM 250 caches three color channel values. Here, each color channel has 256 pairs of 4-bit intervals and fractional values. A MAG 805 is used to obtain the value from the MUV RAM 250 at each pixel output through the DMU. When this value is not available, the MAG 805 issues a memory read request to fetch the missing interval and fractional values. In order to effectively use the bandwidth, a method of fetching a large number of entries is used instead of a method of fetching only one entry per request.

  For image conversion and convolution operations, the MUV RAM 250 stores MDP matrix coefficients. The MAG scans all matrix coefficients stored in the MUV RAM 250. At the beginning of the image conversion and convolution instruction, the MAG 805 issues a request to the operand fetch unit so that the operand fetch unit fetches the kernel description “header” (FIG. 94) and the first matrix coefficient of the bust request. .

  115 shows the MUV address generation unit (MAG) 805 in FIG. 108 in more detail. The MAG 805 includes an IBus request module 820 that multiplexes IBus requests. The IBus request is generated by an image conversion control unit (ITX) 821 and a color space conversion (CSC) control unit 822. This request is sent to an operand fetch unit that is adapted to execute the request. Since the pixel organizer 246 operates in one of the image conversion mode and the color space conversion mode, no arbitration is required between the control units 821 and 822. The IBus request module 820 derives information from the associated pixel organizer including the bust address and bust length necessary to generate a request to the operand fetch unit.

  The JPEG control unit 824 includes two state machines, a JPEG write control unit and a JPEG read control unit, and is used in the JPEG mode. The two control units operate simultaneously and synchronize with each other by using an internal register. In the JPEG compression operation, the DMU outputs MCU data and stores it in the MUV RAM. The JPEG write control unit is responsible for horizontal padding and pixel subsampling control, and the JPEG read control unit is responsible for vertical padding. Horizontal padding is performed by stopping DMU output, and vertical padding is performed by rereading the 8 × 8 block that has already been read.

  The JPEG write controller tracks the current position of the DCU and DMU output pixels in the source image and uses that information to determine when to stop the DMU for horizontal padding. When the MCU is written to the MUV RAM 250, the JPEG write controller sets or resets an internal register to indicate whether the MCU is at the right edge of the image or at the lowest edge of the image. Based on the contents of the register, the JPEG read control unit determines whether vertical padding is necessary or whether the last MCU of the image has been read.

  The JPEG write control unit tracks the DMU output data and stores the DMU output data in the MUV RAM 250. The controller stores the current position of the input pixel using a register set. This information is used when the DMU output is stopped and horizontal padding is performed. When all the MCUs have been written to the MUV RAM 250, the control unit writes the MCU information to the JPEG-RW-IPC register so that it can be subsequently used by the JPEG read control unit.

  After the last MCU has been written to the MUV RAM 250, this controller enters the SLEEP state and remains in that state until the current instruction is finished. The JPEG read control unit reads 8 × 8 blocks from the MCU stored in the MUV RAM 250. In the multi-channel pixel, the control unit reads the MCU several times, and extracts different bytes in each readout from each pixel stored in the MUV RAM.

  This control unit detects whether to perform vertical padding using information provided by JPEG-RW-IPC. The vertical padding is performed by reading the previous 8 bytes read from the MUV RAM 250 again. The image conversion control unit 821 reads the kernel descriptor from the IBus and transmits the kernel header to the MDP 242. And po. The matrix coefficient is scanned the number of times specified by the len register. In the image conversion and convolution instructions, all data output by PO246 is fetched directly from the IBus and is not communicated to the DMU.

  The first 8 bits of the first matrix coefficient fetched immediately after the kernel header represent the number of remaining matrix coefficients to be fetched. The kernel header is passed directly to MDP without modification, but the matrix coefficients are sign extended before being passed to MDP. Pixel subsampler 825 includes two identical channel subsamplers, each operating on one byte of the input word. When the associated configuration register is not activated, the pixel subsampler simply copies its input to its output. On the other hand, when the configuration register is activated, the subsampler subsamples the input data by averaging or decimating the input data.

  The MUV multiplexing module 826 selects MUV read and write signals from the currently active controller. The internal multiplexing unit selects a read address output via various control units using the MUV RAM 250. The MUV RAM write address is stored in the 8-bit register of the MUV multiplexing module. The control unit using the MUV RAM 250 performs control for determining the next MUV RAM address and loads the write address register.

  The MUV effective access module 827 is used by the color space conversion control unit to determine whether the current pixel output interval and fractional value by the data manipulating unit are available in the MUV RAM 250. When one or more color channels are missing, the MUV valid access module 827 communicates the associated address to the IBus request module 820 and loads the interval and fractional values in burst mode. When a cache miss is serviced, the MUV valid access module 827 sets an internal valid bit representing the set of interval and fractional values fetched so far.

  The copy module 829 copies the input data as many times as determined by the internal pixel register. The input stream will be stopped while the copy module is copying the current input word. The PBus interface module 830 is used to retime the pixel organizer 246 to the main data path 242 and the JPEG encoder 241 and vice versa. Finally, the MAG control unit 831 generates a signal for initiating various submodules and a signal for shutting down. The MAG control unit 831 also multiplexes the main data path 242 and the input PBus signal from the JPEG encoder 241.

3.18.2 MUV Buffer In FIG. 2, the pixel organizer 246 is interrelated with the MUV buffer 250, as is apparent from the above description. The reconfigurable MUV buffer 250 supports various processing modes including simple lookup table mode (mode 0), multiple lookup table mode (mode 1), and JPEG mode (mode 2). In each mode, the buffer stores different types of data objects. For example, data words stored in a buffer, values in various search tables, single channel data, and multiple channel data are data objects. In general, data objects have different sizes. In addition, data objects stored in the reconfigurable MUV buffer 250 can actually be accessed in various ways depending on the operating mode of the buffer.

  Data objects are often encoded before they are stored in order to make the various methods necessary to write back and store different types of data. The method used to code the data object is determined by the size of the data object, the format of the data object being represented, how the data object is written back from the buffer, and the configuration state of the memory module formed on the buffer. The

  FIG. 116 is a block diagram of components used to implement a reconfigurable MUV buffer 250. The reconfigurable MUV buffer 250 includes an encoder 1290, a storage device 1293, a decoder 1291, and an address read / rotation signal generator 1292. When a data object is input to the input data stream 1295, the data object is encoded into internal data by the encoder 1290 and placed in the internal data stream 1296. The encoded data object is stored in the storage device 1293.

  When decoding the stored data object, the encoded data is retrieved from the storage device by means of an encoded data output stream 1297. The encoded data on the encoded data output stream 1297 is decoded by the decoder 1291. The decrypted data object appears on the output data stream 1298.

  A write address 1035 to the storage device 1293 is given by the MAG 805 (FIG. 108). Write addresses 1299, 1300, and 1301 are also given by MAG 805 (FIG. 108) and distributed to storage devices 1293 by address read / rotation signal generator 1292. The address read / rotation signal generator 1292 also generates input / output rotation signals 1303 and 1304 for the encoder and decoder, respectively. Write enable signals 1306 and 1307 are provided from an external source. A processing mode signal 1302 provided by the controller 801 (FIG. 108) is connected to an encoder 1290, a decoder 1291, an address read / rotation signal generator 1292, and a storage device 1293. The increment signal 1308 increments an internal counter in the address read / rotation signal generator and may be used in the JPEG mode (mode 2).

  If the reconfigurable MUV buffer 250 is in simple look-up table mode (mode 0), the buffer 250 essentially operates like a single mode memory module. Data objects can be stored in and retrieved from the buffer in a manner essentially similar to accessing a memory module.

  When the reconfigurable MUV buffer 250 is operating in the multiple lookup table mode (mode 1), the buffer 250 is divided into a plurality of tables using a maximum of three search tables stored in the storage device 1293. . The search table can be accessed simultaneously and independently. In one example, interval and fraction values are stored in a storage device 1293 in multiple lookup table mode, which is indexed using the lower 3 bytes of the input data stream 1295. Each of the 3 bytes is issued to an independent search table stored in the storage device 1293.

  When an image is JPEG compressed, the image is converted into an encoded data stream. Pixels are extracted from the original image in MCU format. The MCU is read from left to right and from top to bottom of the image. Each MCU is recombined into a number of 8 × 8 blocks. A number of 8x8 blocks are extracted from the MCU. The MCU depends on several factors such as the color component of the original image, the multi-channel JPEG mode, the need for sub-sampling. The 8 × 8 block is then forward DCT (FDCT), quantized and entropy coded. In the case of JPEG compression, the encoded data is read sequentially from the data stream. The data stream is subjected to entropy decoding, inverse quantization, and inverse DCT (IDCT). The output of the IDCT process is an 8 × 8 block. Multiple 8x8 blocks are integrated to reconfigure the MCU. When using JPEG compression, a large number of 8 × 8 blocks depend on the aforementioned factors. The reconfigurable MUV buffer 250 is also used when decomposing an MCU into a large number of 8 × 8 blocks or reconfiguring a large number of 8 × 8 blocks into an MCU.

  When the reconfigurable MUV buffer 250 is processing JPEG mode, the input data stream 1295 to the buffer 250 includes pixels that are JPEG compressed or a single component that is JPEG compressed. It is out. The output data stream of the buffer 250 includes a JPEG decompression processed single channel data block or JPEG decompression processed pixel data. In this JPEG compression example, the input pixel can be configured up to four channels of Y, U, V, and O. When a specified number of pixels have been processed as a completed pixel block, extraction of a single component data block can begin. Each single component data block consists of data consisting of pixels of the same channel stored in a buffer. Thus, in this example, up to four single component data blocks can be extracted from one pixel data block. In this specific example, when the reconfigurable MUV buffer 250 is processing in JPEG mode (mode 2) for JPEG compression, multiple unit minimum codes (MCUs) are each of 64 single or multiple channels. Pixels can be stored in a buffer, and a number of 64 byte long single channel component data blocks can be extracted from each MCU stored in the buffer. For example, while the buffer 1289 is in JPEG mode (mode 2) for performing JPEG decompression, the output data stream is composed of output pixels having a maximum of four components Y, U, V, and O. When the required number of completed single component data blocks have been written to the buffer, pixel data can be extracted. Bytes from four single component data blocks corresponding to different color components are retrieved as output pixels.

  FIG. 117 is a detailed view of the encoder 1290 of FIG. In pixel block decompression, each input data object is encoded by byte-wise rotation before being stored in the storage device 1293 (FIG. 129). The magnitude of the rotation is determined by the input rotation control signal 1303. In this example, when the pixel data is a maximum of 4 bytes, 32-bit 4-input 1-output multiplexers 1320 and 1325 are used to select one of the 4 possible input pixel rotations. For example, if the four bytes of a pixel are labeled as (3, 2, 1, 0), the rotation of this pixel is (3, 2, 1, 0) (0, 3, 2, 1) (1, 0, 3, 2) (2, 1, 0, 3) The four encoded bytes are output to the storage device 1290.

  When the buffer is in a mode other than JPEG mode (mode 2), for example, single lookup table mode (mode 0), multiple lookup table mode, no byte-wise rotation is necessary and for input data objects I can't. In the latter case, the input data object is disturbed by rotation by ignoring the input rotation control signal having a no-rotation value. This value 1323 is The 2-input 1-output multiplexer 1321 generates the control signal 1326 by selecting the input rotation control signal 1303 and the no-operation value 1323. The current processing mode 1302 is compared to the pixel block decomposition mode value to generate a multiplexer select signal. . A 4-input 1-output multiplexer 1320, controlled by signal 1326, selects one of the four rotations of the input data object and generates an encoded dominant data object on the encoded input data stream 1326.

  FIG. 118 is a circuit diagram of a combinational circuit that implements a decoder 1291 that decodes the encoded output data stream 1297. The decoder 1321 operates in essentially the same manner as the encoder. The decoder manipulates data only when the data buffer is in JPEG mode (mode 2). The lower 32 bits of the encoded output data object in the lower encoded data stream 1297 are passed to the decoder. The data is decoded using the rotation in the byte direction in the reverse sense of rotation by the encoder 1290. A 32-bit 4-input 1-output multiplexer is used to select one of four possible types of encoded data. For example, if a 4-byte input pixel is labeled as (3, 2, 1, 0), the rotation type of this pixel is (3, 2, 1, 0) (2, 1, 0). , 3) (1, 0, 3, 2) (0, 3, 2, 1) are possible. The output rotation control signal 1304 is used when the buffer is a pixel block decomposition node and when no operation value is ignored in other operation modes. The no operation value 1333 is 0. The 2-input 1-output multiplexer 1331 generates the signal 1334 by selecting the output rotation control signal 1304 and the no-operation value 1333. The current processing mode 1302 is compared to the value of the pixel block decomposition mode to generate a multiplexer select signal 1332. A 4-input 1-output multiplexer 1330 controlled by signal 1334 selects four types of rotations of the encoded output data object on the encoded output data stream 1297 and generates output data on the output data stream 1298. To do.

  In FIG. 116, the method of generating the internal read address used in the circuit is selected by the processing mode 1302 of the reconfigurable MUV buffer 250. In the single lookup table mode (mode 0) and the multiple lookup table mode (mode 1), the read address is generated by the MAG 805 (FIG. 108) in the form of external read addresses 1299, 1300, 1301. In the simple lookup table mode (mode 0), the memory modules 1380, 1381, 1382, 1383, 1384, and 1385 (FIG. 121) process together on the storage device 1293. The write address and the read address given to the memory modules 1380 to 1385 (FIG. 121) are essentially the same. That is, the storage device 1293 only needs to supply one read address and one write address to the external circuit, and uses internal logic to distribute these addresses from the memory module 1380 to the empty 1385 (FIG. 121). In mode 0, the read address is given by the external address 1299 (FIG. 116) and distributed to the internal address 1348 (FIG. 121) with essentially no change. External read addresses 1349, 1350, and 1351 (FIG. 121) are not used in mode 0. The write address is given by the external write address 1305 (FIG. 116) and is connected to the write address of each memory module 1380-1385 (FIG. 121) essentially without modification.

  Here, the configuration of the three lookup tables in the multiple lookup table mode (mode 1) is shown. When the three tables are accessed independently, the encoded input data is also written to the joule at the same time from 1380 to 1385 (FIG. 121), thus requiring one index for each of the three tables. Become. Three indexes from memory module 1380 to 1385 (FIG. 212), ie, read addresses, are provided by storage device 1293. These read addresses are distributed to the appropriate memory modules 1380 to 1385 using internal logic. In a manner essentially similar to that in the single lookup table mode, the externally provided write address is connected to the addresses of the respective memory modules 1308 to 1385 without any substantial change. As a result, in the multiple lookup table mode (mode 1), the external read addresses 1299, 1300, and 1311 are distributed to the internal read addresses 1348, 1349, and 1350, respectively. The internal read address 1352 is not used in mode 1. The internal address generation method used in the JPEG mode (mode 2) is different from the method described above.

  FIG. 119 is a circuit diagram of a combinational circuit that implements a read address and rotation signal generation circuit 1292 for a reconfigurable data buffer in JPEG mode (mode 2) in which JPEG compression is performed. In the JPEG mode (mode 2), the signal generator 1292 uses the outputs of the component counter 1340 and the data byte counter 1341 to calculate the internal read address of the memory module including the storage device 1293. The component block counter 1340 generates the number of component blocks extracted from the pixel data block stored in the storage device. The number of blocks is given by multiplying the output of the data byte counter 1341 by four. Specifically, the internal read addresses 1348, 1349, 1350, and 1351 in the pixel block decomposition mode are calculated as follows. The component block counter is used to calculate the offset values 1343, 1344, 1345, 1347, and the output data byte counter 1341 is used to generate the base read address 1354. The offset value 1343 is 1358 added to the base read address 1354, and the added value is the internal read address 1348 (or 1349, 1350, 1351). The offset value of the memory module generally takes a different value for the simultaneous reading executed in the multiple memory modules, but is essentially the same in the extraction of the component block. The base address 1354 used to calculate the four internal read addresses in the pixel data block decomposition mode is similar. The increment signal 1308 is used as an increment signal for the component byte counter. The counter is incremented for every successful read. Component block counter increment signal 1356 is used to increment component block counter 1340 after a data block has been successfully retrieved from the buffer for single calibration.

  The output rotation control signal 1304 (FIG. 116) is taken from the output of the component block counter and the output of the output data byte counter and is essentially the same method as the generation of the internal address. The output of the component block counter is used to calculate the rotation offset 1347. The output rotation control signal 1304 is given by the least significant 2 bits of the sum of the rotation offset 1355 and the base read address 1354. The input rotation control signal is given by the least significant 2 bits of the external write address 1305 as in the example of the address and rotation control signal generator.

  FIG. 120 is another address generator 1292 used to reconstruct multi-channel pixel data from single component data stored in a reconfigurable MUV buffer 250. In this case, the buffer is in JPEG mode (mode 2) for JPEG decompression. In this case, the single component data block is stored in the buffer and the pixel data block is retrieved from the buffer. In this example, the write address to the memory module is provided by the external write address 1305 without any substantial modification. Single component blocks are stored in contiguous memory. The input rotation control signal 1303 in this example is simply set by the least significant 2 bits of the write address. Pixel counter 1360 is used to maintain a record of the number of pixels extracted from a single component block stored in the buffer. The output of the pixel counter is used to generate read addresses 1348, 1349, 1350, 1351 and an output rotation control signal 1304. In general, the read address is different for each module constituting the storage device 1293. In this example, the read address consists of two parts: a single component block index 1362, 1363, 1364, 1365 or 1365 and a byte index 1361. An offset is added to bits 3 and 4 of the output pixel counter to calculate a single component block index for a particular block. In general, offsets 1366, 1367, 1368, and 1369 are different for each read address. Bits 2 to 0 of the pixel counter are used as a byte index 1361 of the read address. The read address is the result of the combination of the single component block index 1362, 1363, 1364, 1365 or 1365 and the byte index 1361 as shown in FIG. In this example, the output rotation control signal 1304 is generated by bits 4 and 3 of the pixel counter output without any substantial change. The increment signal 1308 is used as a pixel counter increment signal for incrementing the pixel counter 1360. Pixel counter 1360 is incremented when a pixel is successfully retrieved from the buffer.

  FIG. 121 shows the structure of the storage device 1293. The storage device 1293 can have three 4-bit wide memory modules 1383, 1384, and 1385 and three 8-bit wide memory modules 1380, 1381, and 1382. The memory module is a 36-bit word in single lookup table mode (mode 0), a 12 × 3-bit word in multiple lookup table mode (mode 1), a 32-bit pixel in JPEG mode (mode 2) or 4 × Can be combined to store 8-bit single component data. Typically, each memory module is associated with a different portion of the encoded input and output data streams (1296 and 1297). For example, the memory module 1380 has a data input port connected to bits 0 to 7 of the encoded input data stream 1296 and a data output port connected to bits 0 to 7 of the encoded output data stream 1297. . In this example, the write addresses of all memory modules are connected together and share the same value at the same time. On the other hand, the read addresses 1386, 1387, 1388, 1390, and 1391 of the memory module shown in FIG. 121 are given by the read address generator 1292, and these generally take different values. In the example, a common write enable signal is used to issue a write enable signal to all 8-bit memory modules, and a second common write enable signal is used to issue a write enable signal to all 4-bit memory modules. Used to put out.

  122 is a circuit diagram of a combinational circuit for generating read addresses 1386, 1387, 1388, 1389, and 1390 for accessing memory modules in the storage device 1293. FIG. Each encoded input data object is broken into partial parts, and each part is stored in an independent memory module of the storage device. Thus, typically, the write address of all memory modules in all processing modes is essentially the same, and virtually no logic is required to calculate the write address of the memory module. On the other hand, the read address is usually different for each process, and is different for each memory module in each processing mode. All bytes in the output data stream 1298 of the reconfigurable MUV buffer 250 are unit component data extracted from the pixel data stored in the JPEG compressed JPEG mode (mode 2) buffer, or JPEG decompressed JPEG It must contain pixel data stored in the mode's buffer and extracted from single component data. The request for output data is satisfied by the generation of four read addresses 1348, 1349, 1350, 1351 to the buffer. In the multiple lookup table mode (mode 1), a maximum of 3 lookup tables are stored in the buffer, so up to 3 read addresses 1348, 1349, 1350 are required to index the 3 lookup tables. . The read addresses of all memory modules are the same as in the single lookup table mode (mode 0), and only the read address 248 is used in this mode. The example of the control circuit shown in FIG. 122 uses a buffer processing mode signal and a maximum of four read addresses in order to calculate the read addresses 1386-1391 of each of the six memory modules constituting the storage device 1293. The read address generator 1292 uses external read signals including external address buses 1348, 1349, 1350, and 1351 as input signals, and generates internal read addresses 1386, 1387, 1389, and 1390 of memory modules that constitute the storage device 1293.

  FIG. 123 is a diagram illustrating how 20-bit matrix coefficients are stored in the buffer 250 when the buffer 250 is in the single lookup table mode. In this case, when a data object is written to a reconfigurable MUV buffer, no encoding is normally performed on the data object on the cache. The matrix coefficients are stored in 8-bit memory modules 1380, 1381, 1382. Bits 7 to 0 of the matrix coefficient are stored in the memory module 1380, bits 15 to 8 are stored in the memory module 1381, and bits 19 to 16 are stored in the lower 4 bits of the memory module 1382. Data objects stored in the buffer as needed for the remainder of the instruction are retrieved many times. In the single lookup table mode, the read and write addresses for all memory modules are essentially the same.

  FIG. 124 is a diagram showing how table entries are stored in the buffer in the multiple lookup table mode (mode 1). In this case, three search tables are stored in the buffer, and each search table has a 4-bit interval value and an 8-bit decimal value. Usually, the interval value is stored in a 4-bit memory module, and the decimal value is stored in an 8-bit memory module. In this case, the three search tables 1410, 1411 and 1412 are stored in the memory banks 1380 and 1383, 1381 and 1384, and 1382 and 1385, respectively. In the past separation, the invalid control signals 1306 and 1307 (FIG. 121) can write the interval value to the storage device 1293 without affecting the decimal value stored in the storage device. A decimal value can be written in an essentially similar manner without affecting the interval value.

  FIG. 125 shows how pixel data is written to the reconfigurable MUV buffer 250 in JPEG mode (mode 2), which breaks the pixel data block into single element data blocks. The storage device 1293 is integrated as four 8-bit memory banks including memory modules 1380, 1381, 1382, 1383, and 1384 including memory modules 1338 and 1384 that are handled in an integrated manner in the same manner as the 8-bit memory modules. . The memory module 1385 is not used in the JPEG mode (mode 2). A 32-bit encoded pixel is broken down into four bytes, each stored in a different 8-bit memory module.

  FIG. 126 is a diagram showing how a single component data block is stored in the storage device 1293 in the single component mode. The storage device 1293 is integrated as four 8-bit memory banks including memory modules 1380, 1381, 1382, 1383, and 1384 including memory modules 1338 and 1384 that are handled in an integrated manner in the same manner as the 8-bit memory modules. . The memory module 1385 is not used in the JPEG mode (mode 2). A 32-bit encoded pixel is broken down into four bytes, each stored in a different 8-bit memory module. In this case, a single component block consists of 64 bytes. When a single component block is written to the subbuffer, a different amount of byte rotation is applied to each. The 32-bit encoded pixel data is retrieved by reading different single component data blocks in the buffer.

  See the Pixel Organizer section for more details on how to control the reconfigurable data buffer 250. In the above example, reconfigurable indicates that the data buffer is used for processing data related to different instructions. A reconfigurable data buffer with three processing modes has been revealed. Different address generation techniques are required in each of the buffer processing modes. Single lookup table mode (mode 0) is used to store matrix coefficients in a buffer in image conversion. The multiple lookup table mode (mode 1) is used to store a number of interval and fraction search tables in a buffer in multi-channel color space conversion (CSC). The JPEG mode (mode 2) is used for decomposing MCU data into 8 × 8 single component blocks or recombining 8 × 8 single component blocks into MCUs in JPEG compression and JPEG decompression, respectively.

3.18.3 Result Organizer The MUV buffer 250 is also used in the result organizer 249. The result organizer 249 buffers and formats the main data path 242 or JPEG coder 241 stream. The result organizer 249 is also related to the compression, uncompression, denormalization, byte lane swap, and reorganization of the result data described in FIG. Further, the result organizer 249 transfers the results in response to requests from the external interface controller 238, the local memory controller 236, and the peripheral interface controller 237.

  When in JPEG decompression mode, result organizer 249 uses MUV RAM 250 to double buffer the image data of JPEG coder 249. When JPEG decompression is performed using the data of the JPEG coder 241 written in the half of the MUVRAM 250, the double buffer performs the performance when the image data written in the other half is output to the designated storage location at the same time. I can give you.

  The 1, 3 and 4 channel image data is passed to the result organizer 249 while performing JPEG decompression in the form of an 8x8 block containing 8 bit components from the same channel. The result organizer stores these blocks in the MUVRAM 250 in a specified order, and stores the mesh of the channel as it is reading data from the MUVRAM 250 for multi-channel interleaved images. For example, in 3-channel JPEG compression using YUV, the JPEG coder 241 outputs three 8 × 8 blocks in the order of Y, then U, and finally V. The meshing is done by taking out each block or one component and constructing the pixels in the form of (YUVX). Here, X is an unused channel. Byte swapping is performed when output channel swapping is required. The result organizer must also perform the necessary sub-sampling process for the reconstruction of the chroma data of the decompressed output data. This implies that each program channel is repeated to generate.

  Returning to FIG. 127, details of the results organizer 249 of FIG. 2 are shown. The result organizer 249 is based around the normal standard CBus interface 840 that contains the register file of the registers that are set for the process. The processing of the result organizer 249 is the same as that of the pixel organizer 249, but reverse data operation is performed. The data manipulation unit 842 performs byte lane swapping, component substitution, component release, and denormalization on the data generated by the MUV address generator 805. The executed processing is described as described above with reference to FIG. 42, and processing is performed according to various fields set in the internal register. FIFO queue 843 buffers the output data before it is output using RBus control unit 844. The RBus control unit 844 includes an address decoder and an address generator. The address for the storage module is stored in an internal register in addition to the required number of output bytes. Furthermore, the internal RO_CUT register determines how many output bytes are missing before being sent on the byte stream of the output bus. In addition, the RO_LMT register determines the maximum number of data items to be output using the next data after the output restriction is stopped. The MAG 805 generates an address of the MUVRAM 250 at the time of JPEG decompression. MUVRAM 250 is used to double buffer the output from the JPEG coder. The MAG 805 meshes the components in the MUVRAM 250 depending on the internal configuration register, and outputs a single channel containing pixels, three channels, and four channels. Since byte lane swapping is required before storing the pixel data in place, the data obtained from MUVRAM 250 is passed through the data manipulation unit. When the result organizer 249 is not in JPEG mode, the MAG 805 simply sends the data of the PBus receiver 845 directly to the data manipulation unit 842.

3.18.4 Operand organizers B and C
Returning to FIG. 2 again, the two independent operand organizers 247 and 248 have a data buffer function of the data cache control 240 and a function of transferring data to the JPEG coder 241 or the main data path 242. Operand organizers 247 and 248 operate in various modes.
(A) Idle mode in which operand organizer responds only to CBus request (b) Direct mode when data of current instruction is stored in internal register of operand register (c) Sequential address and data cache controller 240 by operator organizer A sequential mode that generates data when the buffer is full.

The processing mode of multiple main data paths 242 requires at least one of the operand organizers to be in sequential mode. These modes, including compositing, in Operand Organizer B247 are necessary for buffer pixels that are composited using other images. The operand organizer C248 is used for a synthesis process for attenuating the values of the respective data channels. In the halftone mode, the operand organizer B247 buffers 8-bit matrix coefficients, and in the hierarchical image format decomposition mode, the operand organizer B247 buffers both vertical interpolation and residual fusion instruction data.
(D) In steady mode, the operand organizer B assembles a single internal data word and repeats that word a number of times specified by the internal register.
(E) In the tile mode, the operand organizer B buffers the data constituting the pixel tile.
(F) In the random mode, the operand organizer directly transfers the address of the MDP 242 or JPEG coder 241 to the data cache controller.

  The internal length register determines the number of items generated by each of the operand organizers 247, 248 when processing in sequential, tile, and steady modes. Each of the operand organizers 247, 248 holds the number of data items processed so far and stops when it reaches a value determined by an internal register. Each operand organizer is more reliable for the format of input data using byte lane swapping, component substitution, compression / uncompression / normalization functions. The requested process is configured using internal registers. Further, each of the operand organizers 247 and 248 is configured to restrict data items.

  In FIG. 128, a more detailed configuration of the operand organizer (247, 248) is shown. Operand organizers 247 and 248 include a normal standard CBus interface and a register 850 that controls the entire operand organizer. Further, the OBus control unit 851 is connected to the data cache controller, generates addresses in sequential, tile, and steady modes, generates control signals that enable communication with the OBus interface of the operand organizers 247 and 248, and records the past of the input stream. Controls the data manipulation unit that performs normalization, iteration, etc., which requires a state saved from the clock cycle. When the operand organizers 247, 248 are in sequential or tile mode, the OBus controller unit 851 sends a request for data to the data cache controller. At this time, the address is determined by the internal register.

  Each operand organizer further includes a 36-bit wide FIFO buffer 852 that is used to buffer data from the data cache controller 240 in various modes of processing. The data operation unit 853 performs the same function as the function corresponding to the data operation unit 804 of the pixel organizer 246.

  The main data path / JPEG coder interface 854 distributes data and addresses exchanged by the main data path and the JPEG coder modules 242 and 241 in the normal processing mode. The MDP / JC interface 854 sends data from the data manipulation unit 853 to the main data path and a process configured to repeat the data. In the color conversion mode, units 851 and 854 are bypassed to establish fast access to the data cache controller 240 and the color conversion table.

3.18.5 Main Data Path Unit The features of the following embodiments relate to an image processor that provides a low-cost computer architecture capable of performing a plurality of image processing operations at high speed. Furthermore, the image processor aims to provide a flexible computer architecture that can be configured to perform image processing operations that were not originally defined. Another object of the image processor is to provide a computer architecture that has a lot of the same logic and that makes the design process simple and cheap.

  The computer architecture includes a control register block, a decoding block, a data object processor, and flow control logic. The control register block stores all information relating to image processing operations. The decoding block decodes the information into constituent signals and constitutes an input data object interface. The input data object interface receives and stores data objects from the outside. These data objects are distributed to the data object processors. In certain image processing operations, the input data object interface may generate the addresses of the data objects so that the source of these data objects can provide the correct data objects. The data object processor performs arithmetic operations on the received data object. The flow control logic controls the data object flow in the data object processing logic.

  In particular, the data object processor can comprise several identical data object sub-processors, each sub-processor processing a part of the input data object. The data object subprocessor connects several identical multi-function arithmetic units that perform arithmetic operations on that part of the data object, post-processing logic that processes output data objects, and multi-function arithmetic units and post-processing units Multiplexing logic. The multifunctional arithmetic unit comprises a storage device for calculated data objects. This storage is enabled or disabled by the flow control logic. The multi-function arithmetic unit and the multiplexing logic are constituted by constituent signals generated by the decoding logic.

  Note that the configuration signal from the decoding logic can be changed by an external programming agent. Through this mechanism, any multi-functional block and multiplexing logic can be individually configured by an external programming agent to configure the image processor to perform image processing operations not previously defined. to enable. These and other features of the embodiments of the present invention are described in detail below.

  In FIG. 2, as described above, the main data path unit 242 performs all data operation operations and commands other than JPEG data encoding. These instructions include composition, color space conversion, image conversion, convolution, matrix multiplication, halftone processing, memory copying, and hierarchical image format decompression. Main data path 242 receives pixel and operand data from pixel organizer 246 and operand organizers 247, 248 and sends the result output to result organizer 249.

  FIG. 129 is a block diagram of the main data path unit 242. The main data path unit 242 is a general-purpose image processor, and includes an input interface 1460, an image data processor 1462, an instruction word register 1464, an instruction word decoder 1468, a control signal register 1470, a register file 1472, and a ROM 1475.

  The instruction control unit 235 moves the instruction word to the instruction word register 1464 through the bus 1454. Each instruction word includes information such as the type of image processing operation to be performed and a plug for selecting various options of the image processing operation. The instruction word is carried to instruction word decoder 1468 via bus 1465. Thus, the instruction control unit 235 can instruct the instruction word decoder 1468 to decode the instruction word. Upon receiving the instruction, the instruction decoder 1468 decodes the instruction word into a control signal. These control signals are then carried to control signal register 1470 via bus 1469. The output of the control signal register is then connected to the input interface 1460 and the image data processor 1462 via the bus 1471.

  The instruction control unit 235 can also write directly to the control signal register 1470 to make the main data path unit 242 more flexible. As a result, anyone who is familiar with the structure of the main data path unit 242 can perform the detailed configuration of the main data path unit 242, and the main data path unit 242 can perform image processing operations not described in the instruction word. It can be executed.

  If the instruction word cannot accommodate all the information necessary to execute the desired image processing operation, the instruction control unit 235 stores all the necessary information that cannot be accommodated in some selected registers of the register file 1472. Can write. This information is communicated to input interface 1460 and image data processor 1462 via bus 1473. In certain image processing operations, the input interface 1460 may update the contents of the selected register in the register file 1472 to reflect the current state of the main data path unit 242. When a problem occurs when executing an image processing operation, the command control unit 235 can easily find the problem using the above-described features.

  When the decoding of the instruction word is completed and the desired control signal is loaded into the control signal register, the instruction control unit 235 can instruct the main data path unit 242 to start executing the desired image processing operation. Upon receiving this instruction, the input interface 1460 begins to receive data objects from the bus 1451. Input interface 1460 begins to receive operand data from operand bus 1452 or operand bus 1453, depending on the type of image processing operation being performed, or generates an address for the operand data to generate operand bus 1452 or operand bus. Start receiving operand data from 1453. The input interface 1460 stores and rearranges input data according to the output of the control signal register 1470. When performing calculations such as affine image transformation operations and convolution operations, the input interface 1460 also generates coordinates to be fetched via buses 1452 and 1453.

  The image data processor 1462 performs main arithmetic operations on the data objects that have been rearranged by the input interface 1460. Image processor 1462 performs interpolation between two data objects performed with a predetermined interpolation factor, multiplication of the two data objects, and division of the result divided by 255, normal multiplication and addition for the two data objects, data Perform operations such as truncation of the fractional part of the object with various precisions, clamping the data object to a certain maximum value, clamping the data object to a certain minimum value, scaling and clamping of the data object. be able to. Control signals on bus 1471 control which of the arithmetic operations described above is performed on the data object, the order of its operations, and the like.

  ROM 1475 has a dividend of 255 / x truncated in 8.8 format, where x is a number from 0 to 255. The ROM 1475 is connected to the input interface 1460 and the image data processor 1462 via the bus 1476. The ROM 1475 is used for operations such as generating a short length blend, multiplying the data object by 255 and dividing the result by another data object.

  The number of operand buses, eg 1452, is limited to 2, but is sufficient for the majority of image processing operations. FIG. 130 shows the input interface 1460 in more detail. The input interface 1460 includes a data object interface unit 1480, operand interface units 1482 and 1484, an address generation state unit 1486, a blend generation state unit 1488, a matrix multiplication state unit 1490, an interpolation state unit 1494, a data synchronization unit 1500, an arithmetic unit 1496, Other registers 1498 and data distribution logic 1505 are provided.

  The data object interface unit 1480 and the operand interface units 1482 and 1484 receive data objects and operands from the outside. Both of the interface units 1482 and 1484 are configured by control signals from the control bus 1515. The interface units 1482 and 1484 have a data register including the data object / operand just received, and output a VALID signal when both of the data registers are valid. Outputs of the data registers of the interface units 1482 and 1484 are connected to the data bus 1505. The VALID signals of the interface units 1482 and 1484 are connected to the flow bus 1510. When configured to fetch operands, operand interface units 1482 and 1484 receive the address from arithmetic unit 1496, matrix multiply state unit 1490, and the output of the data register of data object interface unit 1480, among which The necessary address is selected according to the control signal from the control bus 1515. In some cases, particularly when there is no need to receive and store data from the outside, the data registers of operand interface units 1482 and 1484 store data from the output of the data register of data object interface unit 1480 or arithmetic unit 1496. It can be configured as follows.

  The address generation state machine 1486 controls the arithmetic unit 1496 in the affine image conversion operation and the convolution operation, and calculates the next coordinate to be accessed of the source image. Address generation state machine 1486 waits for the START signal on control bus 1515 to be set. When the START signal of the control bus 1515 is set, the address generation state machine 1486 releases the STALL signal to the data object interface unit 1480 and waits for the data object to arrive. Note that the address generation state machine 1486 sets the counter to be the same as the number of kernel descriptor data objects that the address generation state machine 1486 needs to fetch. The output of the counter is decoded and becomes an enable signal for the data registers of the operand interface units 1482 and 1484 and the other registers 1498. When the VALID signal is activated from the data object interface unit 1480, the address generation state machine 1486 starts to decrement the counter, and the next part of the data object is latched into a different register.

  When the counter reaches zero, address generation state machine 1486 instructs operand interface unit 1482 to begin fetching index table values and pixels from operand interface unit 1484. The address generation state machine 1486 loads two counters each having the number of rows and the number of columns. At all clock edges and when not stopped by a STALL signal from operand interface 1482, etc., the counter is decremented and outputs the remaining rows and columns. The arithmetic unit 1496 then calculates the next coordinates to be fetched. When both counters reach zero, the counters are reloaded with the number of rows and columns, and the arithmetic unit 1496 is configured to look for the upper left corner of the next matrix.

  If interpolation is used to determine the true value of a pixel, address generation state machine 1486 reduces the number of rows and columns every two clock cycles. This is done using a 1-bit counter whose output is used as an enable for the row and column counters. After the matrix has been scanned once, the stateer sends a signal that decrements the length counter count. When the counter reaches 1 and the final index table address is sent to the operand interface unit 1482, the state machine issues a final signal and resets the start bit.

  The blend generation state machine 1488 controls the arithmetic unit 1496 to generate a sequence from 0 to 255 for the blend length. This number sequence is used as an interpolation factor for interpolating between the blend start value and the blend end value. The blend generation state machine 1488 determines which mode (jump mode or step mode) should be executed. If the blend length is 256 or less, the jump mode is used, otherwise the step mode is used.

  The blend generation state machine 1488 performs the following calculation and sets the result in the registers (reg0, reg1, reg2). If the brand lamp is in step mode with a predetermined length, 511-length to reg0 (24 bits), 512-2 * length to reg1 (24 bits), and end-start to reg2 ( 4 × 9 bits). When the ramp is in jump mode, 0 is reg0 (24 bits), 255 / (length-1) is reg1 (24 bits), and end-start is reg2 (4x9 bits). Latch.

  In the step mode, the following processing is executed in each cycle. When reg0> 0, reg1 is added to reg0, and the result is stored in reg0. Another incrementer can be enabled, in which case the output is increased by one. When reg0 ≦ 0, 510 is added to reg0, and the result is stored in reg0. Incrementers are not increased. The output of the incrementer is a ramp value.

  In the jump mode, the following processing is executed in each cycle. Add reg1 to reg0. The output of the addition is 24 bits and is output in a fixed decimal point format of 16.8. The addition output is stored in reg0. If the first bit of the fractional result is 1, the integer part is increased. The lower 8 bits of the integer part of the incrementer is a ramp value. The ramp value, that is, the output of reg2 and the blend start value are sent to the image data processor 1462 to generate a ramp.

  The matrix multiplication state unit 1490 performs linear color space conversion on the input data object using the conversion matrix. The transformation matrix is 4 × 5 dimensions. The first through fourth columns are multiplied by the four channels of the data object, and the last column contains the ordinary coefficients to be added to the sum of products. When the START signal from the control bus 1515 is activated, the matrix multiplication state machine operates as follows.

1) Generate line numbers for fetching the ordinary coefficients of the transformation matrix from the buses 1482 and 1484. The other register 1498 is enabled so that the ordinary coefficient can be stored.
2) A 1-bit flip-flop is provided that generates line numbers and uses them as addresses when fetching half of the matrix from buses 1482 and 1484. It also generates a “MAT_SEL” signal that selects from half of the data object to be multiplied by half of the matrix.

3) When there is no data object input from the data object interface unit 1480, the process ends.
Interpolation state machine 1494 performs horizontal interpolation of data objects. In horizontal interpolation, the main data path unit 242 receives a data object stream from the bus 1451 and interpolates between adjacent data objects. Then, a data object stream that is twice or four times as long as the original stream is output. Since data objects can be packed into bytes or pixels, interpolation state machine 1494 performs a different operation in each case to maximize throughput. Interpolation state machine 1494 operates as follows.

1) Generate an INT_SEL signal so that the data distribution logic 1503 rearranges the input data objects and interpolates for the correct data object pair.
2) Generate an interpolation factor for interpolating between adjacent data object pairs.

3) Generate a STALL signal that prevents the data object interface 1480 from accepting the data object anymore. This is necessary because the output stream is longer than the input stream. The STALL signal is sent to the flow bus 1510.
The arithmetic unit 1496 includes a licking circuit that performs arithmetic calculation, and is configured by a control signal of the control bus 1515. This is only used by two commands: affine image transformation and convolution and blend generation in synthesis.

In the affine image conversion and the convolution operation, the arithmetic unit 1496 performs the following operation.
1) Calculate the next x and y coordinates. To calculate the x coordinate, the arithmetic unit 1496 uses an adder to add the horizontal and vertical delta x components to the current x coordinate, or uses a subtracter to calculate the horizontal and vertical delta x components from the current x coordinate. To pull. To calculate the y coordinate, the arithmetic unit 1498 uses an adder to add the y component of the horizontal or vertical delta to the current y coordinate, or uses a subtractor to calculate the y component of the horizontal or vertical delta from the current y coordinate. To pull.

2) Add the y coordinate to the index table offset to calculate the index table address. When using interpolation to determine the original value of the pixel, the sum is further increased by 4 to determine the index entry.
3) Add the x coordinate to the index table entry to determine the pixel address.

4) Subtract 1 from the length count.
In blend generation, the arithmetic unit 1496 operates as follows.
1) In step mode, calculate an internal variable of the ramp generation algorithm using a single ramp adder. On the other hand, one other adder is used to increase the ramp value when the interval variable is greater than zero.

2) In jump mode, only one adder is required to add the jump value to the current ramp value.
3) In jump mode, fractions are truncated.
4) At the beginning of ramp generation, subtract the start of the brand from the end of the brand.

5) Subtract 1 from the length count.
The other register 1498 provides an extra storage space other than the data register in the data object interface unit 1480 and the operand interface units 1482 and 1484. Other registers 1498 are typically used to store internal variables or buffer past data objects from the data object interface 1480. The register 1498 is configured by a control signal of the control bus 1515.

  The data synchronization unit 1500 is configured by a control signal of the control bus 1515. When the data synchronization unit 1500 provides a STALL signal to the data object interface unit 1480 and the operand interface units 1482 and 1484, when an interface unit receives a partial data object that other interfaces do not have, The interface part is stopped until all other interfaces receive data.

  The data distribution logic 1505 is responsible for data objects from the data bus 1510 and the register file 1472 in response to control signals on the control bus 1515 including the MAT_SEL signal from the matrix multiplication state unit 1490 and the INT_SEL signal from the interpolation state unit 1494. Rearrange via bus 1530. The rearranged data is output to the bus 1461.

  FIG. 131 shows the image data processor 1462 of FIG. 129 in more detail. The image data processor 1462 includes a pipeline control unit 1540 and a number of color channel processors 1545, 1550, 1555, and 1560. All color channel processors receive input from bus 1565 driven by input interface 1460 (FIG. 131). All the channel processors and the pipeline control unit 1540 are configured by control signals from the control signal register 1470 via the bus 1472. All color channel processors may also receive input from the register file 1472 and ROM 1475 of FIG. The outputs of all color channel processors and pipeline controllers are grouped into a bus 1570 that forms the output 1455 of the image data processor 1462.

  Pipeline controller 1540 controls the flow of data objects for all color channel processors by enabling or disabling registers for all color channel processors. The pipeline control unit 1540 includes a register pipeline. The form and length of the pipeline are configured by a control signal from the bus 1471, and the form of the pipeline of the pipeline control unit 1540 and that of the color channel processor are the same. The pipeline control unit receives the VALID signal from the bus 1565. In each pipeline stage of the pipeline control unit 1540, when the input VALID signal is activated and the pipeline stage is not stopped, the pipeline stage activates the register enable signal for all color channel processors and the input VALID. Latch the signal. Then the output of the latch, i.e. the VALID signal, moves to the next pipeline stage. In this way, the movement of data objects in the pipeline is simulated and controlled without using a data storage device.

  Color channel processors 1545, 1550, 1555, and 1560 perform the main arithmetic operations on the input data object, and each processor is responsible for one channel of the output data object. In the preferred embodiment, the number of color channel processors is limited to four because most pixel data objects have a maximum of four channels.

  Within the color channel processor is the part that processes the pixel's opacity channel. Although not shown in FIG. 131, there is additional circuitry connected to the control bus 1471, and the color channel processor converts the control signal from the control bus 1471 to correctly handle the opaque channel. This is because in certain image processing operations, the operation on the opaque channel is slightly different from the operation on the color channel.

  FIG. 132 shows the color channel processors 1545, 1550, 1555, 1560 in more detail (generally indicated as 1600 in FIG. 132). Each color channel processor 1545, 1550, 1555, 1560 includes a processing block A1610, a processing block B1615, a big adder 1620, a fraction truncation unit 1625, a clamp or wrapper 1630, and an output multiplexing unit 1635. Yes. The color channel processor 1600 passes the control signal from the control signal register 1470 via the bus 1602, the enable signal from the pipeline control unit 1540 via the bus 1604, and the information from the register file 1472 via the bus 1605. Then, the data object from the other color channel processor is received via the bus 1603 and the data object from the input interface 1460 is received via the bus 1601.

  Processing block A 1610 performs some arithmetic operations on the data object from bus 1601 and outputs the partially calculated data object to bus 1611. Processing to be performed by the processing block A 1610 for the image processing operation will be described below. In compositing, processing block A 1610 multiplies the data object from data object bus 1451 by opacity, interpolates between the blend start value and blend end value by the interpolation factor from input interface 1460 of FIG. 129, and the operand of FIG. Either pre-multiply operands from bus 1452 or multiply the blend color by opacity. Then, the multiplication for the pre-multiplied operand or blend color data is attenuated.

  In general color space conversion, processing block A 1610 interpolates between four color table values using two fractional values from bus 1451 of FIG. In an affine image transformation and convolution operation, processing block A1610 premultiplies the source pixel color by the opacity and interpolates between pixels in the same row using the fractional part of the current x coordinate.

  In linear color space conversion, processing block A 1610 pre-multiplies the source pixel color by opacity and multiplies the pre-multiplied color data by a transform matrix coefficient. In horizontal interpolation and vertical interpolation, processing block A 1610 interpolates between two data objects.

  In the residual margin, processing block A1610 adds two data objects. Processing block A 1610 includes a number of multifunction blocks 1640 and processing block A glue logic 1645. Multifunction block 1640 is configured by control signals and can perform one of the following functions.

  Addition / subtraction is performed on two data objects. Communicate one data object. Interpolate between two data objects by some interpolation factor. Premultiply color by opacity. Multiply two data objects and multiply the product by a third data object.

  Add / subtract two data objects and pre-multiply the result by opacity. The registers of the multifunction block 1640 are enabled or disabled by an enable signal from the bus 1604 generated by the pipeline controller 1540 of FIG. Processing block A glue logic 1645 receives data objects from bus 1601 and data objects from bus 1603 and the outputs of some multifunction block 1640 and sends them to the inputs of other selected multifunction blocks 1640. . The processing block A glue logic 1645 is also configured by a control signal from the bus 1602.

  Processing block B 1615 performs arithmetic operations on the data object from bus 1601 and the partially calculated data object from bus 1611 and outputs the partially calculated data object to bus 1616. Processing performed by the processing block B1615 for the image processing operation will be described below. In composition with a non-positive operator, processing block B1615 multiplies the preprocessed data object from data object bus 1451 and the operand from operand bus 1452 by the composite multiplicand from bus 1603 and 8.8. The output of the ROM, which is the format 255 / opacity value, is multiplied by the clamped / wrapped data object.

  In composition with a positive operator, processing block B1615 adds the two preprocessed data objects. Further, in the opaque channel, subtract 255 from the sum, multiply the difference by the offset, and divide the product by 255. In general color space conversion, processing block B1615 interpolates between four color table values using the two fractional values from bus 1451 and partially interpolates from processing block A1610 using the remaining fractional values. Interpolate between the determined color value and the previous interpolation result.

  In the affine image transformation and convolution operations, processing block B1615 interpolates between the partially interpolated pixels using the fractional part of the current y coordinate and multiplies the interpolated pixels by the subsample weight matrix coefficients. . In linear color space conversion, processing block B1615 pre-multiplies the source pixel color by opacity and multiplies the pre-multiplied color by a transform matrix coefficient.

  The processing block B1615 includes a large number of multifunction blocks and a processing block B glue logic 1650. The multifunction block is similar to that of processing block A 1610, but the processing block B glue logic 1650 accepts data objects from buses 1601, 1603, 1611, 1631 and the output of the selected multifunction block. These are sent to the input of the selected multifunction block. The processing block B glue logic 1650 is also configured by a control signal from the bus 1602.

  Big adder 1620 combines some of the partial results from processing block A 1610 and processing block B 1615. This is done from the input interface 1640 via the bus 1601, from the processing block A 1610 via the bus 1611, from the processing block B 1615 via the bus 1616, and from the register file 1472 via the bus 1605, respectively. And outputs the result coupled to bus 1621. The big adder 1620 is also configured by a control signal of the bus 1602.

  The big adder 1620 can be configured differently according to various image processing operations. The operation in the predetermined image processing operation of the big adder 1620 will be described below. In a synthesis with a non-positive operator, big adder 1620 adds the two partial products from processing block B1615.

  In a composite with a positive operator, when offset enable is activated, big adder 1620 subtracts the sum of the preprocessed data objects with offsets from the opacity channel. In the affine image transformation / convolution operation, the big adder 1620 accumulates the product from the processing block B1615.

  In the linear color space conversion, in the first cycle, the big adder adds the two matrix coefficients / data object product and the ordinary coefficient. In the second cycle, add another two matrix coefficient / data object products to the sum of the previous cycle. The fraction truncation (rounding) unit 1625 receives the input from the big adder 1620 via the bus 1621 and truncates the fractional part of the output. The number of bits representing the fractional part is indicated by the BP signal on the bus 1605 from the register file 1472. The following table shows how to interpret the BP signal. The truncated output is provided on bus 1626.

  Fraction table

The fraction truncation unit 1625 performs two operations other than fraction truncation.
1) Determine if the truncated result is negative.
2) Determine if the absolute value of the truncated result is greater than 255.
The clamp or wrapper 1630 receives input from the fraction truncation unit 1625 via the bus 1626 and performs the following operations in that order.

  Find the absolute value when the option to find the absolute value of the truncated result is enabled. Clamp data object underflow to a certain minimum value and data object overflow to a certain maximum value. The output multiplexing unit 1635 selects the final output among the output of the processing block B of the bus 1616 and the output of the clamp or wrapper of the bus 1631. Although some final processing is also performed on the data object, the operation performed for a predetermined image processing operation will be described below.

  In synthesis without pre-multiplication with non-positive operators, the multiplexer 1635 combines several outputs of processing block B 1615 to form a data object without pre-multiplication. In pre-multiplication synthesis with non-positive operators, the multiplexer 1635 passes the output of the clamp or wrapper 1630.

  In composition with positive operators, the multiplexer 1635 combines several outputs of processing block B 1630 to form a data object result. In the general color space conversion, the multiplexing unit 1635 applies a translation / clamp function to the output data object. In other operations, the multiplexer 1635 passes the output of the clamp or wrapper 1630.

  FIG. 133 shows one multifunction block, such as 1640, in more detail. The multi-function block 1640 has a mode detection unit 1710, two addition operand logic units 1660 and 1670, three multiplexing logic units 1680, 1685, and 1690, a two-input addition unit 1675, and two addends. A two-input multiplication unit 1695 and a register 1705 are provided.

  The mode detection unit 1710 receives the MODE signal 1711 from the control signal register 1470 in FIG. 129 and the two SUB signals 1712 and the SWAP signal 1713 from the input interface 1460 in FIG. 129. Mode detection unit 1710 decodes these signals and generates control signals that are communicated to addition operand logic units 1660 and 1670 and multiplexing logic units 1680, 1685, and 1690. This control signal configures the multifunction block 1640 to perform various operations. Multifunctional block 1640 has eight modes.

1) Addition / subtraction mode: Input 1655 is added to input 1665 or subtracted from input 1665 in accordance with SUB signal 1712. Furthermore, the inputs can be swapped according to the SWAP signal 693.
2) Bypass mode: Bypass the input 1655 to the output.
3) Interpolation mode: Interpolates between inputs 1655 and 1665 using input 1675 as an interpolation factor. According to the SWAP signal 1713, the inputs 1655 and 1665 can be swapped.

4) Pre-multiplication mode: The input 1655 is multiplied by the input 1675, and the result is divided by 255. The output of INC register 1708 tells the next stage whether the result of this stage on bus 1707 should be increased to obtain the correct result.
5) Multiplication mode: The input 1655 is multiplied by the input 1675.

  6) Addition / subtraction and pre-multiplication modes: add input 1665 to input 1655 or subtract from input 1655, multiply the result by input 1675, and divide this product by 255. The output of INC register 1708 tells the next stage whether the result of this stage on bus 1707 should be increased to get the correct result.

  The add operand logic units 1660 and 1670 determine the one's complement for the input as necessary to allow subtraction by the adder. Adder 1675 adds the outputs of addition operand logics 1660 and 1670 on buses 1662 and 1672 and outputs the sum to bus 1677. Multiplexing logic 1680, 1685, and 1690 chooses the multiplicand and addend that are appropriate to perform the desired function. These are all configured by a control signal of the bus 1714 from the mode detection unit 1710.

  A multiplication unit 1695 having two addends multiplies the input from the bus 1682 by the input from the bus 1677. Then, the sum of the inputs from buses 1687 and 1692 is added to the product. Adder 1700 adds the upper 8 bits of the output of multiplier 1695 to the lower 8 bits of the output of multiplier 1695. The carry of adder 1700 is latched in INC register 1701. INC register 1701 is enabled by signal 1702. The register 1705 stores the product from the multiplication unit 1695. This is also enabled by signal 1702.

FIG. 134 shows a block diagram of the composition operation. This compositing operation receives three input data streams.
1) Accumulated pixel data: In this accumulator model, it is derived from the same location where the result was stored.
2) Composite operand: Consists of color and opacity. Both color and opacity can be flat, blend, pixel, or tile.

3) Attenuation: Attenuates operand data. The attenuation can be a flat bitmap or a byte map.
Pixel data typically consists of four channels. The three channels form the pixel color. The remaining channel is pixel opacity. Pixel data may or may not be premultiplied. When the pixel data is premultiplied, each color channel is multiplied by the opacity. When a pixel is pre-multiplied, the formula of the composition operation becomes simple. Therefore, pixel data is usually pre-multiplied and then synthesized with other pixels.

  Table 1 shows the synthesis instructions executed in the preferred embodiment. Each instruction operates on pre-multiplied data. (Ac0, a0) is the premultiplied pixel color ac and opacity a0, r is the “offset” value, wc () is the wrap / clamp operator, and A reverse operator for each operator is also implemented. The composite model also has an accumulator on the left side.

The composite block 1760 in FIG. 134 includes three color sub-blocks and an opaque sub-block. Each color sub-block operates on one color channel and an opaque channel of the input pixel to obtain the color of the output pixel. The above operation is shown below in the form of pseudo code.
PIXEL Composite (
IN color A, color B: PIXEL;
IN opacity A, opacity B: PIXEL;
IN comp_op: COMPOSITE_OPERATOR)
(
PIXEL result;
IF if comp_op is rover, rin, rout, ratop
swap colorA and colorB;
swap opacityA, opacityB;
END IF;
IF comp_op is over, rover, loado, or pl
THEN to be s
X = 1;
ELSE IF comp_op is in, rin, atop, or rat
THEN to be op
X = opacityB;
THEN if ELSE IF comp_op is out, rout, or xor
X = not (opacity B);
ELSE IF comp_op is loadzero, loadc, or
THEN to be loadco
X = 0;
END IF;
If IF comp_op is over, rover, atop, ratop, or xor, then
Y = not (opacity);
ELSE IF comp_op is plus, loadc, or load
if it is co
Y = not (opacity);
ELSE IF comp_op is plus, loadc, or load
if it is co
Y = 1;
ELSE IF comp_op is in, rin, out, rout, lo
adzero or loado THEN
Y = 0;
END IF;
result = coloA * X + colorB * Y;
RETURN result;
Since the instructions 'load' and 'loado' have different meanings for opaque channels, the above code is different in the opaque sub-block.

  Block 1765 in FIG. 134 clamps or wraps the output of block 1760. When block 1765 is configured to clamp, all values less than the minimum allowed value are kept to the minimum value and all values greater than the maximum allowed value are kept to the maximum allowed value. When block 1765 is configured to swap, the following equation is calculated:

((X−min) mod (max−min)) + min,
Here, min and max mean the minimum value and the maximum value allowed in the color. As the minimum value and the maximum value, 0 and 255 are desirable. Block 1770 in FIG. 134 pre-multiplies the result from block 1765. This pre-multiplies the pixel by multiplying the pre-multiplied color value by 255 / o. Here, o means opacity after synthesis. The value 255 / o is obtained from the ROM in the synthesis engine. Values in ROM are stored in 8.8 format, and fractional parts are rounded. The result of the multiplication is stored in 16.8 format. This result is rounded to 8 bits to produce the inverse premultiplied pixels.

The brand generation unit 1721 generates a brand of a specific length having a specific start value and end value. This is done over the following two stages:
1) Ramp generation 2) Interpolation In ramp generation, the synthesis engine generates a sequence that increases linearly from 0 to 255 with respect to the length of the instruction. There are two ramp generations: a “jump” mode with a length of 255 or less and a “step” mode with a length greater than 255. The mode is determined by the upper 24 bits of length. In jump mode, the ramp value increment is at least 1 per clock cycle. In the step mode, the increment of the ramp value is a maximum of 1 every clock cycle.

  In jump mode, the composition engine uses 8.8 format ROM to determine the step value 255 / (length-1). This value is added to the 16-bit accumulator. The accumulator output is truncated at 8 bits to form a sequence. In step mode, the composition engine uses an algorithm similar to Bresenham's line drawing algorithm. The algorithm is shown below.

Void line draw (length: INTERGER)
{
d = 511-length;
incrE = 510;
incrNE = 512-2 * length;
ramp-0;
for (i = 0; i (length; i ++)
{
if d (= 0 then
d + = incrE;
else {
d + = incrNE;
ramp ++;
}
}
}
The following formula is then used to generate the brand from the lamp:

Blend = ((end-start) × ramp / 255) + sta
rt
Truncation is performed for division by 255. The above equation requires two adders and a block that "pre-multiplies" (for end-start) with each channel ramp. Another image processing that the main data path unit 242 can perform is general color space conversion. Generalized color space conversion (GCSC) uses piecewise tri-linear interpolation to determine the output color value. It is desirable to perform conversion from a three-dimensional input space to a one-dimensional or four-dimensional output space.

  In some cases, the accuracy of tri-linear interpolation at the gamut edges is a problem. This problem becomes significant in printing devices that are sensitive to near edges. To avoid this problem, the GCSC can be selectively computed in the extended output color space and scaled and clamped within the appropriate range using the following equation:

Other image processes that the preferred embodiment can perform are image conversion and convolution operations. In image conversion, the source image is scaled, rotated, and skewed. In the convolution operation, the pixels of the source image are sampled with a convolution matrix to produce the target image. In order to generate a scan line in the target image, the following steps are necessary.

1) Inversely transform the scan line of the target image as shown in FIG. This makes it possible to identify the pixels of the source image that are necessary to generate the scan line of the target image.
2) Decompress the necessary part of the source image.
3) Invert the horizontal and vertical sub-sampling distances and start x, y coordinates of the target image back to the source image.

4) Transmit the above information to the processing unit, perform necessary sub-sampling and interpolation, and obtain the pixel of the output image.
Subsampling, interpolation, writing of the target pixel, etc. are performed by the preferred embodiment, and calculations of the relevant parts in the source image, the subsampling frequency to be used, etc. are performed by the host application.

  FIG. 136 is a block diagram of the necessary steps in the calculation of the target pixel value. FIG. 136 assumes that the necessary source image pixels are available. The final step in calculating the target pixel is to add up all the subsamples that have been linearly interpolated from the source image. FIG. 137 shows a block diagram of the image conversion engine extracted by appropriate settings in the main data path unit 242. The image conversion engine 1830 includes an address generation unit 1831, a pre-multiplication unit 1832, an interpolation unit 1833, an accumulation unit 1834, truncation, clamping, and a logic unit 1835 for obtaining an absolute value.

The address generation unit 1831 generates the x and y axes of the source image necessary for constructing the result pixel. This also generates an address for obtaining an index offset from the pixels of the input index table 1815 and the image 1810. The address generation unit 1831 reads the kernel descriptor before generating the x and y axes of the source image. There are two types of kernel descriptor formats, which are shown in FIG. The kernel descriptor is
1) Start coordinates of source image (unsigned fixed point, 24.24 accuracy). The position (0, 0) is the upper left corner of the image.

2) Horizontal, vertical subsample delta (2's complement, 24.24 precision)
3) A 3-bit bp field indicating the position of the binary point in the fixed-point matrix coefficient. FIG. 150 shows the definition of the bp field and its description.
4) Accumulated matrix coefficients. This is a "variable" decimal point precision with 20 binary positions (2's complement), and the position of the binary point is implicitly defined by the bp field.

5) An rl field indicating the remaining number of words in the kernel descriptor. This value is the same as the number of rows multiplied by (number of columns minus 1).
In the short kernel descriptor, the other parameters excluding the constant part of the start coordinate of x have the following values.
fraction of start coordinate of x <−0,
start coordinates of y <−0,
Horizontal delta <-1.0,
Vertical delta <−1.0.
After the address generator 1831 is configured, the current coordinates are calculated. There are two methods for this depending on the dimension of the subsample matrix. If the dimension of the subsample matrix is 1 × 1, the address generator 1831 adds the horizontal delta to the current coordinates until sufficient coordinates are obtained.

  If the dimension of the subsample matrix is not 1 × 1, the address generator 1831 adds a horizontal delta to the current coordinates until one row of the matrix is completed. Thereafter, the address generation unit 1831 adds a vertical delta to the current coordinates in order to obtain the coordinates of the next line. The address generator 1831 subtracts the horizontal delta from the current coordinates until the end of one or more columns to determine the next coordinate. Thereafter, the address generator 1831 adds the vertical delta to the current coordinates and repeats this process. The diagram at the top of FIG. 150 shows how to access the matrix. With this structure, the matrix is scanned zigzag and the current x, y axes are calculated by this method, so fewer registers are required. The accumulated matrix coefficients must be arranged in a similar order in the kernel descriptor.

  After generating the current coordinates, the address generator 1831 adds the y-axis to the index table base address to determine the index table address (if the source pixel is interpolated, the address generator 1831 also determines the next index table. There is a need). The index table base address points to the index table entry at (y + 0). After obtaining the index offset from the index table, the address generator 1831 adds it to the x coordinate. This sum is used when determining one pixel from the source image (two pixels if the source pixel is interpolated). If the source pixel is interpolated, the address generator 1831 adds the x coordinate to the next index offset to obtain two or more pixels.

  A similar method is used in the convolution operation when obtaining the coordinates for image conversion. The only difference from the convolution operation is that the starting coordinate of the matrix at the next output pixel is a horizontal delta away from the starting coordinate of the matrix at the previous pixel. In image transformation, the starting coordinate of the matrix at the next pixel is separated by a horizontal delta from the coordinates of the upper rightmost pixel of the matrix at the previous output pixel.

  In FIG. 139, the middle diagram shows the difference. The premultiplier 1832 multiplies the pixel color channel and the opaque channel if necessary. Interpolator 1832 interpolates the source pixel to determine the true color of the required pixel. It takes 2 pixels from the source image memory, interpolates using the fractional part of the current x coordinate, and enters the result into a register. Then take two pixels in the next column of the source image memory and also interpolate using a fraction of x. Thereafter, the interpolation unit 1833 interpolates this interpolation value and the previous interpolation value using the fractional part of the current y coordinate.

Accumulator 1834 performs two tasks.
1) Multiply the matrix coefficient by the pixel.
2) Output the accumulated value of the above results for all matrices to the next stage. The initial value of the accumulation unit 1834 is initialized to 0 or a specific value according to the channel.

  Block 1835 truncates the output of accumulator 1834 and limits underflow or overflow values to a maximum or minimum value if necessary. If necessary, the absolute value of the output may be obtained. In the output of the accumulation part, the position of the binary point is specified by the bp field of the kernel descriptor. The bp field indicates the number of bits to be discarded in the accumulation result. This is shown in the bottom diagram in FIG. This accumulated value is treated as a signed two's complement.

  Another image processing operation that can be performed by the main data path unit 242 is matrix multiplication. Matrix multiplication is used for color space conversion when there is an affine relationship between the two spaces. This is the difference from general color space conversion (based on cubic linear interpolation). The result of the matrix multiplication is defined by:

  Here, ri is the result pixel and ai is the A operand pixel. The size of the matrix must be 5 columns and 4 rows. FIG. 140 is a block diagram of a multiplier-adder that performs matrix multiplication in the main data path unit 242. This includes a multiplication unit for multiplying the pixel channel by a matrix coefficient, an adder for adding the results, and a logic unit for clamping the output value and obtaining an absolute value as necessary.

  Two clock cycles are required to complete the matrix multiplication. A multiplexing unit is set for each cycle so that the data of the multiplication unit and the addition unit are correctly selected. In the 0th cycle, the least significant 2 bytes of the pixel are selected by the multiplexing units 1851 and 1852. The coefficient is then multiplied by the two columns on the left side of the matrix, the matrix coefficient in the 0th line in the cache.

  In the first cycle, the upper 2 bytes of the pixel are selected by the top multiplexer. The coefficient is then multiplied by two columns on the right side of the matrix. The result of the multiplication is added 1854 to the result of the last cycle. The sum in the adder is truncated 1855 to 8 bits. The “operand logic unit” 1856 rearranges the output of the multiplier so that the input of the adder 1854 becomes four. This performs a rearrangement to allow the addition to the result of the multiplier and output the correct product of 24-bit coefficients and 8-bit pixel components.

  “AC logic part” 1855 truncates the least significant 12 bits of the output of the adder, and obtains the absolute value of the result of the truncation according to the setting. Then, depending on the setting, the result is clamped or wrapped. When the “AC logic” is set to clamp, all values less than or equal to 0 are suppressed to 0, and all values greater than or equal to 255 are suppressed to 255. When the “AC logic part” is set to wrap, the lower 8 bits of the constant part are output.

  The main data path unit 242 can also be set to perform image processing other than the above. A computer architecture that can reduce the cost by design reuse and can quickly perform various image processing operations will be described below. Since this computer architecture is flexible, even if it is an external programming agent, as long as it is familiar with the architecture, it is possible to configure the computer so that image processing operations that were not originally predicted can be executed. In addition, since the core of the design mainly consists of several multifunctional blocks, the design effort can be significantly reduced.

3.18.6 Data Cache Control Unit and Cache The data cache control unit 240 includes a 4 kilobyte read data cache 230 in the coprocessor 224. Data cache 230 is arranged as a direct map RAM cache, and any of the same length lines in external memory can be directly mapped to the same length and same line in cache memory 230 (FIG. 2). . This line in the cache memory is called a normal cache line, and the cache memory is composed of a large number of such cache lines.

  Data cache controller 240 services data requests from two operand organizers 247, 248. First, it is confirmed whether the data exists in the cache 230. Otherwise, the data is fetched from external memory. The data cache controller 240 has a programmable address generator, which allows the data cache controller 240 to operate in several different addressing modes. There is also a special addressing mode in which the address of the requested data is created by the data cache control unit 240. In this mode, data of up to 8 words (256 bits) can be sent to the operation organizers 247 and 248 simultaneously.

  The cache RAM consists of 8 independently addressable memory banks (addressed by different line addresses). Required for some special addressing modes where data from each bank is united to 256 bits. This arrangement can serve up to eight 32-bit requests simultaneously if they come from different banks.

The cache operates in the following modes described in detail later. If necessary, all caches can be automatically populated. 1. Normal mode 2. Single output general color space conversion mode Multi-output general color space conversion mode 4. JPEG encoding mode Low speed JPEG decoding mode 6. Matrix multiplication mode Desable mode 8. Invalidation Mode FIG. 141 shows the address, data, control flow and data cache 230 of the data cache control unit 240 in FIG.

  The data cache 230 includes the direct map cache described above. The data cache control unit 240 includes a tag memory 1872 having a tag entry in each cache line, and the tag entry has the most significant part of the external memory address to which the cache line is currently mapped. A line valid state memory 1873 indicating whether the current cache line is valid is also provided. The initial state of all cache lines is invalid.

  The data cache controller 240 can simultaneously service data requests from the operand organizer C247 (FIG. 2) and the operand organizer C248 (FIG. 2) through the operand bus interface. In operation, one or both of the operand organizers 247, 248 (FIG. 2) provides an index 1874 and issues a data request signal 1876. Address generator 1881 generates one or more complete external addresses 1877 for index 1874. The cache controller 1878 is requested by examining the tag memory 1872 for the tag address of the generated address 1877 and examining the line valid state memory 1873 to see if the associated cache line is valid. It is determined whether the stored data exists in the cache 230. When the requested data is present in the cache memory 230, an acknowledgment signal 1879 is sent to the associated operations organizer 247, 248 along with the requested data 1880. When the requested data does not exist in the cache memory 230, the requested data 1870 is fetched from the external memory through the input bus interface 1871 and the input interface switch 252 (FIG. 2). Data 1870 is fetched by outputting request signal 1882 and providing the address 1877 at which the requested data 1870 was generated. Acknowledge signal 1883 and requested data 1870 are sent to cache controller 1878 and cache memory 230, respectively. The cache line associated with that cache memory 230 is then updated with new data 1870. The tag address of the new cache line is also written into the tag memory 1872 and the line valid state 1873 in the new cache line is activated. Acknowledge signal 1879 is sent along with data 1870 to the associated operand organizer 247 or 248 (FIG. 2).

  In FIG. 142, the memory configuration of the data cache 230 is shown. The data cache 230 has 128 cache lines C0,. . . , C127 are arranged as a direct map cache. The cache RAM is a memory bank B0,. . . , B7, each memory bank has 128 32-bit bank lines, and each cache line Ci has eight memory banks B0,. . . Eight bank lines B0i,. . . , B7i.

  FIG. 143 shows the configuration of the generated external memory address. The generated address is a 32-bit word consisting of a 20-bit tag address, a 7-bit line address, a 3-bit bank address, and a 2-bit byte address. The 20-bit tag address is used to compare the tag address with the tag stored in tag memory 1872. The 7-bit line address is used for the address of the associated cache line in the cache memory 1870. The 3-bit bank address is used as the address of the associated memory bank in the cache memory 1870. The 2-bit byte address is used for the address of the associated byte on the 32-bit bank line.

  FIG. 144 shows a block diagram of the structure of the data cache control unit 240 and the data cache 230. Here, the 128 × 256 bit RAM constitutes a cache memory 230, which consists of eight memory banks capable of separate addressing of 128 × 32 bits. This RAM has a writable port (write), a write address port (write_addr), and a write data port (write_data). Further, it has a readable port (read), eight read address ports (read_addr), and eight read data output ports (read_data). A write enable signal is generated from cache control block 1878 to allow simultaneous writing to all memory banks of cache memory 230. If necessary, the data cache 230 is updated with data of one or more lines from the external memory through a write data port (write_data). One line of data is written by providing a line address to the write address port (write_addr) and using the 8: 1 multiplexer MUX. The 8: 1 multiplexer MUX selects a line address from the external address generated under the control of the data cache control unit (addr_select). A readable signal is generated from cache control block 1878 to allow simultaneous reading into all memory banks of cache memory 230. In this manner, data of eight different bank lines are read simultaneously from the eight read data ports (read_data) according to the respective line addresses provided to the eight write address ports (read_addr) of the memory bank of the cache memory 230. be able to.

Each bank of cache memory 230 has a programmable address generator 1881. This allows simultaneous access to the eight different locations from the eight related memory banks. Each address generator 1881 has a dcc mode input, an index packet input, a base address input, and an address output for setting the operation mode of the address generator 1881. The operating mode of the programmable address generator 1881 is:
(A) A signal to the dcc mode input puts each address generator 1881 in random access mode and the external memory address is provided to the index packet input and output to the address output of one or more address generators 1881 Random access mode;
(B) JPEG encoding and decoding, color space conversion, matrix multiplication mode, where the signal to the dcc mode input causes each address generator 1881 to be in the appropriate mode. In this mode, each address generator 1881 receives an index to the index packet input and generates an index address. Depending on the mode of operation, the address generator can generate up to eight different external memory addresses.

  The eight address generation units 1881 are composed of eight different logic circuits, and each is composed of a dcc mode and an index having a base address as an input and an external memory address as an output. The base address register 1885 stores the current base address which is a combination of index packets, and the dcc mode register 1888 stores the current operation mode (dcc mode) of the data cache control unit 240.

  The tag memory 1872 is composed of a single block, 128 × 20 bit multi-port RAM. This RAM has one write port (update-line-addr), one writable port (write), and eight read ports (tag0_data,..., Tag7_data). This is done by determining the tag address of the line of one or more generated memory addresses currently stored in the eight address generators 1881 (read0line-addr, ..., read7line-). 8 simultaneous lookups in addr). The current tag addresses of these lines are output from the ports (tag0-data,..., Tag7-data) to the tag comparison unit 1886. A tag write signal is generated by the cache control block 1872 as necessary to allow writing of the port (update-line-addr) to the tag memory 1872.

  The 128-bit line valid memory 1873 maintains the valid state of each cache line in the cache memory 230. This includes one write port (update-line-addr), one writable port (update), eight read ports (read0line-addr, ..., read7line-addr), eight readable ports (linevalid0,. , Linevalid7) is a 128 × 1 bit memory. As with the tag memory, this determines in the eight address generator 1881 the line valid state saved in the current line for each line address of one or more generated memory addresses. This allows eight simultaneous lookups for the port (read0line-addr, ..., read7line-addr). The current line valid bit of this line is output from the port (linevalid0, ..., linevalid7) to the tag comparison unit 1886. If necessary, a write signal for enabling writing from the port (update-line-addr) to the line valid state memory 1873 is generated from the cache control block 1878 at the write port of the line valid state memory 1873.

  The tag comparison unit 1886 includes eight tag comparators. The tag_data input for receiving the tag address currently saved in the tag memory 1872 of the line accessed by the line address of the currently generated external address, the current generation Tag_addr input for receiving the tag address of the external memory address generated, dcc_input for receiving the current operation mode signal (dcc_mode) for setting the tag address part to be compared, accessed by the line address of the currently generated external address Line_valid input for receiving the line valid state currently saved in the line valid state memory 1873 in the line. The comparison unit 1886 has eight hit outputs for each of the eight address generation units 1881. When the tag address of the generated external memory address matches the contents of the tag memory 1872 at the position accessed by the line address of the generated external memory, the hit signal and the line valid status bit 1873 for that line are set. Is output. In this embodiment, the data structure saved in the external memory is small, and the most significant bits of the tag address are all the same. Therefore, only the least significant bit where the tag address changes needs to be compared. This is made possible by setting the current operation mode signal (dcc_mode) so that the tag comparison unit 1866 compares the least significant bit where the tag address changes.

  When the data in the cache memory 230 can be accessed, the cache control unit 1878 receives a request (proc_req) and a notification (proc_ack) from the operands B247 and C248. Depending on the operation mode, data of different addresses is requested from up to eight banks of the cache memory 230. When the requested data can be accessed from the cache memory 230, the tag comparison unit 1886 issues a hit to the line of that memory. In response to the issued hit signal (hit0,..., Hit7), the cache control unit 1878 generates a readable signal at the port (cache_read) and enables the cache line from which the hit signal is issued to be read. . When a request (proc_req) 1876 is issued instead of a hit signal (hit0,..., Hit7), the external memory address of the data cache line is sent to the external memory together with the generated request (ext_req). This cache line is written to the eight banks of the cache memory 230 through which input (ext_data) is possible. In this case, the tag information is also written in the tag memory 1886 of the line address, and the line status bit 1873 of the line is output.

  Data from the eight banks of the cache memory 230 is output through several multiplexers in the data organizer 1892 and positioned in the output data packet 1894 in a predetermined manner. In one operation mode, the data organizer 1892 uses the current operation mode signal (dcc_mode) and the byte address (byte_addr) of the generated external memory address to generate 8 bits from 8 32-bit words output from 8 memory banks. A word can be selected and output. In other modes, the data organizer 1892 directly outputs the eight 32-bit words output from the eight memory banks. As described above, the data organizer arranges and outputs this data in a predetermined system.

The request is made in the next stage.
1) The processing unit sends an address to the processing unit interface in the cache control unit 1878 to request packet data.
2) The eight address generation units 1881 generate addresses of each block of the cache memory according to the operation mode.

3) The tag position of the generated address is compared with the tag address saved in the 4 blocks of the 3-port tag memory 1886 and positioned by the line portion corresponding to the 8 generated addresses.
4) If they match and the line valid state 1873 for that line is issued, the requested data is considered to be in the cache memory 230.

5) The non-existent data is fetched via the external bus 1890, and the eight blocks of the cache memory 230 are updated with the contents of the data line from the external memory. The tag address of the new data is written into the tag memory 1886 and the line valid state 1873 for that line is issued.
6) If all the request data is present in the cache memory 230, it appears in the processing unit in the determined packet format.

  As described above, all parts of the coprocessor 224 (FIG. 2) include the standard CBus interface 303 (FIG. 20). Details of the standard CBus interface registers of the data cache control unit 240 and the cache 230 are described in B42 to B46 of Appendix B. The setting of this register controls the operation of the data control unit 240. For simplicity, only two registers (base_address and bcc_mode) are shown in FIG.

If the data cache control unit 240 and the data cache 230 are valid, the data cache control unit initially invalidates all cache lines and operates in the standard mode. At the end of a certain instruction, the data cache controller 240 and the cache 230 are always switched to the standard operation mode. All modes except the “Invalidate” mode have an option of “Auto-fill and validate”. By setting 1 bit in the dcc_cfg2 register, all caches can start from the address saved in the base_address register. During this operation, data requests from the operand organizers B, C247, 248 are suspended. The cache is valid after this operation is finished.
a. Standard Cache Mode In this mode, the two memory organizers provide the external memory address of the requested data. The address generation unit 1881 outputs the external memory address, and checks whether it exists in the memory cache 230 using the internal tag memory. If both requested data are not present in the cache 230, data is requested from the input interface switch 252. Round robin scheduling is employed in response to persistent and simultaneous requests.

For a simultaneous request, if a data item is present in the cache, it will be located in the 32 bits behind the requested data bus. Other data is requested externally through the input interface switch.
b. Single Output General Color Space Conversion Mode In this mode, a request is issued from the operand organizer part B in a 12-bit byte address format. As shown in FIG. 60, the requested data item is an 8-bit color output value. The 12-bit address is input to the index_packet input of the address generator 1881, and the eight address generators 1881 generate a 32-bit external memory address in the format shown in FIG. The bank, line, and byte addresses of the generated address are determined by Table 12 and FIG. The external memory address is interpreted as eight 9-bit line and byte addresses, which are used to refer to the eight bank bytes of RAM. The cache is accessed by the main data path 242 for interpolation to the operand organizer to determine the 8-byte value of the bank returned on the aforementioned principle shown in FIG. Since all the single output general color value tables fit in the cache memory 230, it is desirable to load the single output color value table into the cache memory 230 before applying the single color conversion mode.
c. Multi-output general color space conversion mode In this mode, a 12-bit word address is received from the operand organizer B247. The request data item is the 32-bit color output value described above with reference to FIG. The 12-bit address is input to the index_packet input of the address generator 1881, and the eight address generators 1881 create eight different 32-bit external memory addresses in the format shown in FIG. The line and tag address of the external memory address are determined by Table 12 and FIG. As described above with reference to FIG. 63, the external memory address is interpreted as eight 9-bit addresses having 9-bit addresses divided into 7-bit line addresses and 2-bit tag addresses. If the tag address is not found, the cache stops until the appropriate data is loaded from the input interface switch 252 (FIG. 2). If the data is available, the output data is output to the operand organizer section.
d. JPEG encoding mode In this mode, tables and the like necessary for the JPEG encoding mode are saved in the bank of the cache RAM. Table storage is described in the JPEG encoding mode (Tables 14 and 16).
e. Low Speed JPEG Decoding Mode In this mode, data is generated according to Table 17.
f. Matrix multiplication mode In this mode, the cache is used to access 256 bytes of data.
g. Disabled mode In this mode, all requests are passed to the input interface switch 252.
h. Invalidate Mode In this mode, all cache contents are invalidated by clearing the line valid status bit.

3.18.7 Input Interface Switch In FIG. 2, the input interface switch performs allocation to adjust request data from the pixel organizer unit 246, the data cache control unit 240, and the instruction control unit 235. This also transmits necessary addresses and data to the external interface controller 238 and the local memory controller 236.

  The input interface switch 252 stores the setting in the register of either the base address or the memory object in the host memory map. Since 20 address bits are required, this is a virtual address aligned on a page boundary. In response to requests from the pixel organizer unit, data cache control unit, and instruction control unit, the input interface switch 252 first subtracts the coprocessor base address bits from the upper 6 bits of the data start address. If this result is negative or the upper 6 bits of this result are not 0, it means that the PCI bus is a desirable transmission destination.

If the upper 6 bits of the result is 0, it means that the data map represents the memory location of the coprocessor. Thereafter, the input interface switch checks the next 3 bits to determine if the coprocessor position is correct. The legal position of the coprocessor is
1) 16 megabytes occupied by the general interface starting from offset 0x01000000 from the coprocessor base address.

  2) 32 megabytes occupied by the local memory controller (LMC) starting from offset 0x02000000 from the base address of the memory object of the coprocessor. A request to point to an illegal coprocessor location is considered an error by the input interface switch. The PCI bus is a data source for addresses other than the area occupied by the memory object of the coprocessor. The input interface switch uses the i source signal to inform the EIC whether the request data is from the PCI bus or the general interface.

  After the address decryption process, the legitimate request is transmitted to the appropriate IBus interface. The EIC and LMC transmit data to the input interface switch when the i-ack signal is output. However, since the input interface switch does not count the number of input words, the i-oe signal controlled by the pixel organizer unit, the command control unit, and the data cache control unit must monitor when the current data transmission ends. Don't be.

  The input interface switch 252 adjusts three modules: a pixel organizer unit, a data cache control unit, and an instruction control unit. They can request data at the same time, but since there are only two physical resources, the request is not processed directly. The adjustment technique used for the input interface switch is based on priority and can also be programmed. A control bit in the setting register of the input interface switch specifies the relative priority of the instruction control unit, data cache control unit, and pixel organizer unit. Requests from lower priority modules are accepted if there are no requests to access the same resource from the other two modules. Given at least two request issuers with the same priority, it becomes necessary to use a round-robin technique to determine the issuer from which the request is accepted.

  Since it is not possible to access one source immediately, the input interface switch needs to store the address and burst length of the requested data and see if it prefetches the data provided by the requester. If there is no IBus process in a process for a certain source, an adjustment process for determining priority is required.

  FIG. 145 shows details of the command interface switch 252. In addition to the standard CBus interface and the register file 860, the switch 252 has two IBus transceivers 661 between the address decoder 863 and the adjustment unit 864. The address decoder 863 performs address decoding in response to a request received from the pixel organizer unit, data cache control unit, and instruction control unit. The address decoder 863 checks whether the address is valid and remaps the address as necessary. The adjustment unit 864 determines which request is transmitted from the IBus transceiver 661 to the IBus transceiver 662. The priority is programmable.

The IBus transceivers 861 and 862 have multiplexing and demultiplexing functions and a tri-state buffering function for enabling communication from other interfaces to the input interface switch.
3.18.8 Local Memory Control Unit In FIG. 2, the local memory control unit 236 is responsible for all of the control of the local memory and the processing of access requests between the local memory and the modules in the coprocessor. The local memory control unit 236 responds to a write request from the result organizer 249 and a read request from the input interface switch 252. Furthermore, it responds to read and write requests from the peripheral interface controller 237 and normal general CBus inputs. The local memory control unit uses a programmable priority system and further employs a FIFO buffer to maximize throughput.

  In the present invention, in addition to a first-in first-out (FIFO) buffer, a multi-port burst dynamic memory controller is used to decouple ports from the memory array. FIG. 146 shows a block diagram of a 4-port burst dynamic memory controller according to the first embodiment of the present invention. The circuit includes two write ports (A1944 and B1946) and two read ports (C1948 and D1950) that require access to the memory array 1910. The data path of read ports 1948 and 1950 exits the memory array 1910 via separate FIFOs 1936 and 1938, whereas the data path from the two write ports passes through separate FIFOs 1920 and 1922 via the multiplexer 1912. Go to memory array 1910. The central control unit 1932 drives all control signals necessary for the interface to the dynamic memory 1910 and adjusts the entire port access. The refresh counter 1934 determines the required time of the dynamic memory refresh cycle for the memory array 1910 and adjusts these together with the controller 1932.

  Preferably, data reads and writes to memory array 1910 are performed at twice the rate of transfer from write ports 1944, 1946 to FIFO 1920, 1922, or from FIFO 1936, 1938 to read ports 1948, 1950. As a result, the time required to transfer data to or from the memory array 1910 relative to the time required to transfer data through the write and read ports 1944, 1946, 1948, 1950 (both memory system bottlenecks Is as short as possible.

  Data is written to the memory array 1910 via one of the write ports 1944, 1946. The circuits connected to the write ports 1944 and 1946 will only recognize the FIFOs 1920 and 1922 with an initial value of zero. Data transfer through the write ports 1944, 1946 proceeds smoothly until the FIFOs 1920, 1922 are full or the burst is complete. When data is first written to the FIFO 1920, 1922, the control unit 1932 arbitrates with other ports for accessing the DRAM. When access is obtained, data is read from the FIFOs 1920, 1922 at the highest rate and written to the memory array 1910. A burst write cycle to the DRAM 1910 is initiated only when a preset number of data words are stored in the FIFOs 1920, 1922, or when a burst from the write port is completed. In either case, the burst to DRAM 1910 proceeds from the time it was granted and continues until FIFOs 1920, 1922 are empty or there are cycle requests from higher priority ports. In either event, data is written uninterrupted from the write port to the FIFO 1920, 1922 until the FIFO is full or the current burst ends and a new burst starts. In the latter case, the new burst will not proceed until the previous burst is written to DRAM 1910 with FIFOs 1920, 1922 empty. In the former case, data transfer is resumed as soon as the first word is read from the FIFO 1920, 1922 and written to the DRAM 1910. Since the data transfer from the FIFO 1920, 1922 is at the highest rate, the write ports 1944, 1946 can be stalled only when the control unit 1832 is interrupted by a cycle request from another port. It is desirable to keep any interruption to data transfer from the write ports 1944, 1946 to the FIFO 1920, 1922 as minimal as possible.

  Read ports 1948 and 1950 operate in the reverse order. When the read port 1948, 1950 issues a read request, a DRAM cycle is requested immediately. If permission for this request is obtained, the memory array 1910 is read and data is written to the corresponding FIFOs 1936, 1938. As soon as the first data word is written to the FIFO 1936, 1938, it can be read by the read ports 1948, 1950. Thus, although there is an initial delay to obtain the first data word, there is probably no further delay in the subsequent acquisition of successive data words. The DRAM read is terminated when there is a higher priority DRAM request, the read FIFO 1936, 1938 is full, or the read ports 1948, 1950 no longer request data. Once reading is completed in this way, it is not resumed until there is room in the number of data words preset in the FIFOs 1936, 1938. Once the read port finishes the cycle, any data remaining in the FIFO 1936, 1938 is discarded.

  To keep the DRAM control above the minimum value at all times, until the preset number of data words has been transferred (or the corresponding FIFO 1920, 1922 is empty or the read FIFO 1936, 1938 is full) Until) the re-arbitration to DRAM access is limited so that the burst is not interrupted. All access ports 1944, 1946, 1948, 1950 have corresponding burst start addresses, which are latched in the counter 1942 at the start of the burst. This counter holds the current address for the transaction for the port, and even if the transfer is interrupted, it can be restarted at the correct memory address. Only the address of the currently active DRAM cycle is selected by multiplexer 1940 and sent to row address counter 1916 and column address counter 1918. The low order N bits of the address are input to column counter 1918, while the upper address bits are input to row counter 1916. The multiplexer 1914 outputs a row address from the row counter 1916 to the memory array 1910 during the DRAM row address time, and sends a column address from the column counter 1918 during the DRAM column address time. Row address counter 1916 and column address counter 1918 are loaded into memory array DRAM 1910 at the start of any burst. This is true at both the beginning of the port cycle and the duration of the interrupted burst. The column address counter 1918 is incremented after the transfer to the respective memory occurs, and the row address counter 1916 is incremented when the column address counter 1918 changes to zero. In the latter case, the burst is terminated and must be resumed with a new row address.

  In this example, it is assumed that memory array 1910 includes 4 × 8 bit byte lines and constitutes 32 bits per word. In addition, there is a set of 4-byte write enable signals 1950, 1952 corresponding to each write port 1944, 1946, where data is individually written to each 8-bit portion of each 32-bit data word in the memory array 1910. To be. Since any byte in each word written to the memory array 1910 can be arbitrarily masked for writing data, it is necessary to store write enable information together with each data word in the corresponding FIFO 1926, 1928. is there. These FIFOs 1926, 1928 are controlled by the same signals used to control the write FIFOs 1920, 1922, but only 4 bits are used instead of the 32 bits required to write data to the FIFOs 1920, 1922. Similarly, the multiplexing unit 1930 is controlled in the same manner as the multiplexing unit 1912. The selected write enable is input to the control unit 1932, and the control unit uses these pieces of information to synchronize with the write data input to the memory array 1910 by the multiplexing unit 1912 and to address the addressed word in the memory array 1910. Selectively enabling or disabling writing to

  The configuration in FIG. 146 operates under the control of the control unit 1932. FIG. 147 is a state diagram showing details of the operation of the control unit 1932 in FIG. 146. After power-up and upon completion of reset, the state machine is forced into the IDLE 100 state, in which all DRAM control signals are inactive, and the multiplexing unit 1914 sends the row address to the DRAM array 1910. send. When a refresh or cycle request is detected, a transition is made to the RASDEL 19162 state. When there are no cycle requests and refreshes at the next clock edge, the state machine returns to the IDLE1900 state. Otherwise, when the DRAM tRP (RAS precharge timing limitation) cycle is satisfied, the state is changed to the RASON 1966 state, and at this time, the row address strobe signal RAS is at a low level. After tRCD (RAS to CAS delay timing limitation) is satisfied, the state transitions to the COL1968 state, and the multiplexing unit 1914 is switched to select the column address to be input to the DRAM array 1910. At the next clock edge, the transition is made to the CASON 1970 state, and the DRAM column address strobe (CAS) signal becomes active low. Once tCAS (CAS active timing limit) is satisfied, the transition is made to the CASOFF 1972 state, where the DRAM column address strobe (CAS) is again inactive high. Here, if more data words are to be transferred and if a higher priority cycle request or refresh is imminent or too fast to re-arbitrate, then tCP (CAS pre- When the (charge timing limit) period is satisfied, the state returns to the CASON 1970 state, and the DRAM column address strobe (CAS) becomes active low again. If there is no further data word transfer or re-arbitration occurs and a higher priority cycle request or refresh is imminent, tRAS (RAS active timing limit) and tCP (CAS precharge timing limit) If both are satisfied, the RASOFF 1974 state is transitioned instead. In this state, the DRAM row address strobe (RAS) signal becomes inactive high. At the next clock edge, the state machine returns to the IDLE 1860 state and prepares for the start of the next cycle.

  When a refresh request is detected in the RASDEL2 1964 state, transition to the RCASON 1980 state is made once tRP (RAS precharge timing restriction) is satisfied. In this state, the DRAM column address strobe becomes active low and DRAM CAS is started before the RAS refresh cycle. At the next clock edge, a transition is made to RRASON 1978 and the DRAM row address strobe (RAS) is active low. When tCAS (CAS active timing limit) is met, a transition is made to RCASOFF 1976 and the DRAM column address strobe (CAS) goes inactive high. Once tRAS (RAS active timing limit) is met, a transition is made to RASOFF 1974, the DRAM row address strobe (RAS) goes inactive high, effectively ending the refresh cycle. The state machine continues the above behavior for a normal DRAM cycle and transitions to the IDLE 1960 state.

  The refresh counter 1934 shown in FIG. 146 is simply a counter, and generates a refresh request signal at a fixed rate once every 15 microseconds, or at a rate determined by a special DRAM manufacturer's request. When a refresh request is issued, the request continues to issue until it is acknowledged by the state machine of FIG. This acknowledgment occurs when the state machine enters the RCASON 1980 state and continues in that state until the state machine detects removal of the refresh request.

  FIG. 148 shows the operation of the arbiter 1924 of FIG. 146 in pseudocode form. This section describes how to determine which of the four cycle request issuers are allowed to access the memory array 1910, and a mechanism for modifying the cycle requester's priority to maintain fairness in access. ing. The symbols used for these codes are illustrated in FIG.

  Each request issuer has 4 bits representing the priority of the request. The upper 2 bits are preset to the general priority by the configuration value set in the general configuration register. The lower 2 bits of the priority are stored in a 2-bit counter updated by the arbitrator 24. In determining the winner of the arbitration, the arbitrator 1924 simply compares each requester's 4-bit value and grants access to the highest requestor. When the requester is allowed to cycle, the value of the priority counter of the lower 2 bits becomes zero, and the lower 2 of the other requesters having the same upper 2 bit priority value and the lower 2 bit priority value lower than the winner All bit priority counts are incremented by one. As a result, the requester permitted to access the memory array 1910 now has the lowest priority among the requesters having the same upper 2-bit priority value. The priority value of the lower 2 bits of the requester whose priority value of the upper 2 bits is different from that of the winner is not affected. The value of the upper 2 bits of the priority determines the general priority of the requester, and the value of the lower 2 bits realizes a fair arbitration scheme between requesters having the same higher priority. By using this scheme, partial replacement from fixed priority (high-order 2 bits of each requester is unique) connected in hardware and partial hardware connection (not all, but some high-order 2 bits) Various arbitration schemes can be realized, ranging in priority (different from the others) and strictly fair replacement (the priority values of all the upper 2 bits are the same).

  FIG. 149 shows the structure of priority bits for each requester and how to use the bits. Here, the meaning of the symbols used in FIG. 148 is also defined. In the above embodiment, the various FIFOs 1920, 1922, 1938, and 1936 are 32 bits wide and 32 words deep. This depth provides a good line compromise between efficiency and circuit area consumed. However, the depth value can be changed to meet the needs of a particular application as performance changes.

Also, the 4-port configuration shown here is just one example. Even providing a single FIFO buffer between the memory array and either the read or write port can be beneficial. However, using a large number of read and write ports will provide the highest speed improvement.
3.18.9 Other Modules The other modules 239 are coprocessor 224 operations, reset synchronization, error and interrupt signal multiplexing by passing internal diagnostic signals to external pins as needed, CBus internal and external forms Generation and selection of clocks for interfacing, multiplexing of internal and general bus signals to the general / external Cbus output pins. Of course, the operation of the other module 239 differs depending on the clocking requirements and implementation details of the ASIC technology used.

3.18.10 External Interface Controller The features of the invention described below relate to a method and apparatus for providing virtual memory in a host computer having a coprocessor that shares virtual memory. Embodiments of the present invention seek to enable a coprocessor to operate in virtual memory mode in conjunction with a host processor.

  In particular, the coprocessor can operate in the virtual memory mode of the host processor. The coprocessor includes a virtual memory-to-physical memory mapping device that can reference the virtual memory table of the host processor, and converts the instruction address generated by the coprocessor to the corresponding physical address in the memory of the host processor. Map. Rather, the virtual memory to physical memory mapping device forms part of a computer graphic coprocessor for generating graphic images. The coprocessor includes a number of modules that can perform various complex operations on the image. The mapping device is responsible for the interaction between the coprocessor and the host processor.

  An external interface controller (EIC) 238 provides an interface to the coprocessor PCI bus and general bus. Further, the external interface control unit also provides memory management that connects between the internal virtual address space of the coprocessor and the physical address space of the host system. The external interface control unit 238 operates as a master on the PCI bus when reading data from the host memory in response to a request from the input interface switch 252 or writing data to the host memory in response to a request from the result organizer 249. . Access to the PCI bus is implemented in accordance with the standard of “PCI Local Bus Specification, draft 2.1” PCI special interest group, 1994.

  The external interface control unit 238 arbitrates simultaneous requests for PCI transactions from the input interface switch 252 and the result organizer 249. Arbitration should be configurable. The types of requests received include reading one or fewer cache lines of the host coprocessor at a time, reading a cache line between one and two rows of the host, and reading two or more cache lines. included. Unlimited length writing is also implemented by the external interface controller 238. Further, the external interface control unit 238 optionally performs prefetching of data.

  The construction of the external interface controller 238 includes memory management that provides address mapping from virtual memory to host physical memory for all coprocessor internal modules. This mapping is completely transparent to the module requesting access. When the external interface control unit 238 receives an access request to the host memory, the external interface control unit 238 initializes the memory management unit and converts the requested address. If the memory management unit fails to translate the address, in some cases, one or more PCI Bus transactions will result in completing the address translation. This means that the memory management unit itself can be another source of requests for transactions from PCI Bus. When the burst requested by the input interface switch 252 or the result organizer 249 exceeds the virtual page boundary, the external interface control unit 238 automatically activates the memory management unit to correctly re-map all virtual addresses.

The memory management unit (MMU) (915 in FIG. 150) is based on 16 lookaside buffers (TLBs). The TLB acts as a cache for virtual to physical address mapping. The following operations are possible in TLB.
1) Compare: Given a virtual address, the TLB returns either the corresponding physical address or the TLB miss signal (if there is no valid entry matching the address).

2) Replacement: A new virtual-to-physical mapping is written to the TLB in place of existing or invalid entries.
3) Invalidation: When a virtual address is given, the matched entry is invalidated if it matches the TLB entry.
4) Invalidate all: Invalidate all TLB entries.

5) Read: The virtual and physical addresses of the TLB entry are read on a 4-bit address basis. Used for testing only.
6) Write: The virtual and physical addresses of the TLB entry are written on a 4-bit address basis.
The entries in the TLB have a format as shown in FIG. Each valid entry includes a 20-bit virtual address 670, a 20-bit physical address 671, and a flag indicating whether or not the corresponding physical page can be written. The allowable page size of the entry is 4K bytes. Registers in the MMU can be used to mask up to 10 bits of addresses used for comparison. This supports TLB pages up to 4M bytes. Since there is only one mask register, all TLB entries refer to pages of the same size.

  The TLB uses a “Least-Recently Used” (LRU) replacement algorithm. The new entry is overwritten with the entry with the longest time. This is because it was last written or matched in comparison. This only applies if there are no invalid entries. If there is an invalid entry, it is written to the invalid entry before it is overwritten.

  FIG. 152 shows the flow of the TLB comparison operation. The received virtual address 880 is divided into three parts 881-883. Since the lower 12 bits 881 are always part of the offset within the page, they are sent directly to the corresponding physical address bits 885. The next 10 bits 882 are either an offset portion or a page number portion depending on the page size, as set by the mask bits. A zero value in the mask register 887 indicates that the bit is part of the page offset and should not be used for TLB comparisons. The 10 address bits are logically “ANDED” with the 10 mask bits to give the lower 10 bits of the virtual page number 889 for the TLB lookup. The upper 10 bits 883 of the virtual address are directly used as the upper 10 bits of the virtual page number 889.

  The 20-bit virtual page number generated in this way is sent to the TLB. If this matches one of the entries, the TLB returns the number of the position that matched the corresponding physical page number 872. The physical address 873 is generated from the physical page number using the mask register 887 again. The upper 10 bits of the physical page number 872 are directly used as the upper 10 bits of the physical address 873. The next 10 bits of the physical address 872 are selected as 875 from either the physical page number (when the corresponding mask bit is 1) or the virtual address (when the mask bit is 0). The lower 12 bits 885 of the physical address are given directly from the virtual address.

  Finally, the LRU buffer 876 is updated according to the match to indicate the use of the matched address. A TLB miss occurs when the input interface switch 252 or the result organizer 249 requests access to a virtual address that does not exist in the TLB 872. In this case, the MMU must fetch the requested virtual-to-physical translation from the page table in the host memory 203 and write it to the TLB before proceeding with the requested access process.

  The page table is a hash table of the host main memory. Each page table entry is composed of two 32-bit words in the format shown in FIG. The second word constitutes the upper 20 bits for the physical address and the lower 12 bits are reserved. The upper 20 bits of the corresponding virtual address are given in the first word. The lower 12 bits include a valid (V) bit and a writable (W) or “read only” bit, and the remaining 10 bits are reserved.

  The page table entry basically includes the same information as the TLB entry. Extra flags in the page table are reserved. The page table itself is normally distributed over a plurality of pages in the main memory 203, and is generally adjacent to the virtual space and is not in contact with the physical space. The MMU includes a set of 16 page table pointers set by software, each of which is a 20-bit pointer to a 4K byte memory area containing the page table portion. This means that the coprocessor 224 supports a 64K byte size page table and has 8K page mapping. In a 4 Kbyte page size system, this means a mapped virtual address space of up to 32 Mbytes. Rather, the page table pointer always refers to a 4 Kbyte memory area regardless of the page size used for the TLB.

The MMU operation after the TLB miss is shown as 690 in FIG. 154 as follows.
1. A hash function 892 on the virtual page number 891 that does not exist in the TLB is executed to generate a 13-bit index in the page table.
2. The page table pointer 895 is selected using the upper 4 bits 894 of the page table indexes 894 and 896.

3. Concatenate the 20-bit page table pointer 895 and the lower 9 bits of the page table index 896, and set 000 to the lowest 3 bits (because the page table entry occupies 8 bytes in the host memory), request The generated physical address 890 of the page table entry is generated.
4). Starting from the physical address 898 of the page table entry, 8 bytes are read from the host memory.

  When the 5.8-byte page table entry 900 is returned to the PCI bus, if the VALID bit is set to 1, the virtual page number is compared with the original virtual page number that caused the TLB miss. If they do not match, the next page table entry is fetched using the above process (the physical address is incremented by 8 bytes). This process continues until a matching virtual page number page table entry is found or an invalid page table entry is encountered. If an invalid page table entry is encountered, a page fault error is issued and processing stops.

  6). If a page table entry with a matching virtual page number is found, the replacement operation writes the complete entry to the TLB. The new entry is placed in the TLB location pointed to by LRU buffer 876. The TLB comparison operation is then performed again, and the original requested host memory access can be processed following the success. When a new entry is written to the TLB, the LRU buffer 876 is updated.

The hash function 892 embodied in the EIC 238 uses the following equation for a 20-bit virtual page number (vpn).
index = ((vpn >> S1) XOR (vpn >> S2) XOR (vpn >> S3)) &Ox1fff;
Here, S1, S2, and S3 are independently programmable shift amounts (positive or negative) and can take four values.

  If the linear search of the page table crosses the 4K byte boundary, the MMU automatically selects the next page table pointer and continues the search at the correct physical memory location. This operation includes wrapping from the end of the page table to the beginning. The page table always contains at least one null entry so that the search is always terminated.

  Each time software replaces a page in host memory, it must add a page table entry for the new virtual page and delete the entry corresponding to the replaced page. Also, old page table entries should not be cached in the coprocessor 224 TLB. This is done by performing a TLB invalidation cycle within the MMU.

  An invalidation cycle is a virtual page number that is invalidated along with a bit that causes invalidation work, and is accomplished through a register write to the MMU. This register write is accomplished either directly by software or through an instruction interrupted by an instruction decoder. Invalidation work is done on the TLB for the provided virtual page number. When a TLB entry is matched, the entry is marked invalid and the LRU table is updated so that the invalidated position is used in the next replacement operation.

  The pending invalidation work has a higher priority than any pending TLB comparison. When the invalidation operation is completed, the MMU clears the invalidation bit to notify that the next invalidation processing is possible. If the MMU cannot find a valid page table entry for the requested virtual address, this is called a page fault. The MMU issues an error signal and stores the virtual address that caused the fault in a register accessible to the software. The MMU enters the idle state and waits until the error is resolved. When the interrupt is cleared, the MMU starts working again with the next requested transaction.

  A page fault is also issued when a write operation is performed on a page marked read-only (not marked writable). The external interface control unit (EIC) 238 responds to a transaction request from the input interface switch 252 and the result organizer 249 addressed to the general bus. Each request module indicates whether the current request is for a general bus or a PCI bus. Unlike using a common bus for communication between the input interface switch 252 and the result organizer 249, an EIC operation for a general bus request is completely separated from an operation for a PCI request. Furthermore, the EIC 238 is also compatible with a Cbus transaction type that directly addresses the general bus space.

  FIG. 150 shows the structure of the external interface control unit 238. The IBus request passes through the multiplexing unit 910, and the multiplexing unit 910 directs the request to an appropriate internal module based on the destination of the request (PCI or general bus). The request for the general bus is sent to the general bus control unit 911 which also has the RBus and CBus. Since the general bus and PCI bus requests on the RBus use different control signals, a multiplexing unit is not required for this bus.

  An IBus request directed to the PCI bus is handled by an IBus driver (IBD) 912. Similarly, RBus requests to PCI are handled by an RBus receiver (RBR) 914. The IBD 912 and RBR 914 send the virtual address to a memory management unit (MMU) 915 that returns the physical address. The IBD, RBR, and then the MMU can each request PCI transactions, which are generated and controlled by the PCI master mode controller (PMC) 917. The IBD and MMU request only PCI read, and the RBR requires only PCI write.

  A separate PCI target mode controller (PTC) 918 processes all PCI transactions addressed to the coprocessor as a target. This sends a CBus master mode signal to the command controller, allowing access to all other modules. Since the PTC sends the returned CBus data to the PCI bus via the PMC, control of the PCI data bus pins comes from a single source.

  CBus transactions addressed to the EIC register and module memory are handled by the standard CBus interface 7. All submodules get the bit from the control register and return the bit to the status register. These are located inside the standard CBus interface. Parity generation and checking for PCI bus transactions is handled by a parity generation and checking (PGC) module 921 that operates under the control of the PMC and PTC. The generated parity is sent to the PCI bus in the same manner as the parity error signal. The result of the parity check is also sent to the PTC configuration register for error reporting.

  FIG. 155 shows the structure of the IBus driver 912 of FIG. The accepted IBus address and control signal are latched 930 at the beginning of the cycle. The OR gate 931 detects the start of the cycle and generates a start signal to the control logic 932. The upper address bits of latch 930 that form the virtual page number are loaded into counter 935. The virtual page number is sent to the MMU 915 (FIG. 150) that returns the physical page number latched in 936.

  The physical page number and lower virtual address bits are recombined by mask 937 to form address 938 for the PCI request to PMC 717 (FIG. 102). A burst count for the cycle is also loaded into the counter 939. The prefetch operation uses a different counter 941, an address latch, and a comparison circuit 943. The data returned from the PMC is loaded into the FIFO 944 with a marker that indicates whether the data is part of a prefetch. When data becomes available in the previous part of FIFO 944, it is read out via latches 945 and 946 and clocked out by logic. Read logic 946 also generates an IBus acknowledgment signal.

  Central control block 932 controls the sequential processing of all address and data elements, including the state machine, and then the interface to the PMC. The virtual page number counter 935 is the page number bit from the IBus address and is loaded with the start of the IBus transaction. The upper 10 bits of this 20-bit counter always come from an accepted address. For the lower 10 bits, each bit is loaded from the accepting address if the corresponding mask bit 937 is set to 1, otherwise the counter bit is set to 1. The 20 bit value is sent to the MMU interface.

  In normal operation, virtual page numbers are not used after initial address translation. However, if the IBD detects a burst page boundary crossing, the virtual page counter is incremented and another conversion is performed. Since the low order bits that are not part of the virtual page number are set to 1 when the counter is loaded, a simple increment to a 20 bit value results in an actual page number field increment. After being incremented, mask bit 937 is again used to set up the counter for the next increment.

  The physical address is latched 936 whenever the MMU returns a valid physical page number after translation. The mask bits are used to correctly combine the returned physical page number with the original virtual address bits. The physical address counter 938 is loaded from the physical address latch 936. This is incremented each time a word is returned from the PMC. Each time it is incremented, the counter is monitored to determine if the transaction is about to cross a page boundary. The mask bits are used to determine which bits of the counter are used for comparison. When the counter detects that the number of words remaining in the page is two or less, it signals the control logic 932 to terminate the current PCI request after two data transfers and, if necessary, a new address Request conversion. The counter is reloaded after a new address translation and the PCI request resumes.

  The burst counter 939 is a 6-bit down counter that is loaded with the IBus burst value at the start of a transaction. This is decremented each time a word is returned from the PMC. When the counter value is two or less, a signal is sent to the control logic 932, so that after two data transfers, the PCI transaction can be terminated (unless prefetching is possible).

  The prefetch address register 943 is loaded with the physical address of the first word of any prefetch. When a subsequent IBus transaction starts and then the prefetch counter indicates that at least one word has been successfully prefetched, the first physical address of the transaction is compared to the value of the prefetch address. If they match, the prefetch data is used to satisfy IBus takeover and a PCI transaction request begins at the address after the last prefetched word.

  The prefetch counter 941 is a 4-bit counter and is incremented to the same count as the depth of the maximum input FIFO every time a word is returned by the PMC during the prefetch operation. When a subsequent IBus transaction matches the prefetch address, the prefetch count is added to the address counter and then subtracted from the burst counter so that a PCI request can be started at the required location. Instead, if the IBus transaction needs only a portion of the prefetched data, the length of the requested burst is subtracted from the prefetch count, then added to the latched prefetch address, and the remaining prefetch data is further Held to satisfy the request.

  The data FIFO 944 is an asynchronous fall-through FIFO of 8 words × 33 bits. Data from the PMC is written to the FIFO along with a bit indicating whether the data is part of a prefetch. Data from the leading edge of the FIFO is read from the FIFO and sent to the IBus as soon as it becomes available. The logic that generates the data read signal operates in synchronization with clk and generates an IBus acknowledgment output. When the transaction is satisfied with prefetched data, a signal from the control logic provides the read logic with information on the number of prefetched data to be read from the FIFO.

  FIG. 156 shows the structure of the RBus receiver 914 of FIG. Control is split between two state machines 950, 951. Write state machine 951 controls the interface to RBus. Input address 752 is latched at the start of the RBus burst. Each data word in the burst is written to FIFO 754 with a byte enable. When the FIFO 954 becomes full, the write logic 951 cancels the r-ready, preventing the organizer from writing any more words.

  Write logic 951 notifies main state machine 950 of the start of the RBus burst via a resynchronization start signal, preventing the organizer from writing any more words. The upper address bits forming the virtual page number are loaded into the counter 957. The virtual page number is sent to the MMU, and a physical page number 958 is returned from the MMU. The physical page number and the low order bits of the virtual address are recombined according to the mask and loaded into the counter 960 to provide the address for the PCI request to the PMC. Data and byte enables for each word of the PCI request are clocked out of the FIFO 954 by the main control logic 950 that also handles all PMCM interface control signals. The main state machine indicates active via the busy signal, which is resynchronized back to the write state machine.

  The write state machine 951 detects the end of the RBus burst using the r-final. Then, the data loading to the FIFO 954 is stopped, and the main state machine is notified that the RBus burst has ended. The main state machine continues the PCI request until the data FIFO is empty. It then cancels busy and causes the write state machine to start the next RBus burst.

  Returning again to FIG. 150, the memory management unit 915 is responsible for converting virtual page numbers to physical page numbers for the Ibus driver (IBD) 912 and the RBus receiver (IBR) 914. FIG. 157 shows details of the memory management unit. A 16-entry translation lookaside buffer (TLB) 970 receives input data from the TLB address logic 971 and sends back output. The TLB control logic 972 that contains the state machine receives requests buffered in the TLB address logic from the RBR or IBD. When a request is received, it selects the input source and the work done by the TLB. Valid TLB operations are compare, invalidate, all invalidate, write and read. The source of the TLB input address includes an IBD and RBR interface (for comparison work), a page table entry buffer 974 (for TLB miss service), or a register in the TLB address logic. The TLB returns the status of each work to the TLB control logic. The physical page number from a successful comparison operation is sent back to the IBD and RBR. The TLB maintains a record of the most recently accessed (LRU) location, which is useful for the TLB address logic as a location for write operations.

  If the comparison operation fails, the TLB control logic 972 signals the page table access control logic 976 to initiate a PCI request. The page table address generator 977 uses the internal page table pointer register to generate a PCI address based on the virtual page number. Data returned from the PCI request is latched into the page table entry buffer 974. When a page table entry matching the requested virtual address is found, the physical page number is sent to the TLB address logic 977, after which the page table access control logic 976 notifies the page table access is complete. The TLB control logic 972 then writes a new entry in the TLB and starts the comparison operation again.

  Register signals to and from the SCI are resynchronized 980 in both directions. The signal goes back and forth to all submodules. The module memory interface 981 decodes access to the TLB and page table pointer memory elements from the standard CBus interface. TLB access is read-only and uses TLB control logic to obtain data. The page table pointer can be both read and written, and is directly accessed by the module memory interface. These paths also include a synchronization circuit.

3.18.11 Peripheral Interface Control Unit FIG. 158 shows an example of the peripheral interface control unit (PIC) in FIG. 2 in detail. The PIC 237 operates in one of several modes for transferring data to or from an external peripheral device. The basic mode is
1) Video output mode: In this mode, data is transferred to the periphery under the control of the external video clock and clock data enable. The PIC 237 sends an output clock and a clock enable sign at the required timing for the output data.

2) Video input mode: In this mode, data is transferred to the periphery under the control of external video clock and clock data enable.
3) Centronics mode: This mode transfers data to and from the periphery according to the standard protocol defined in the IEEE 1284 standard.
The PIC 237 separates the external interface protocol from internal data sources and destinations as needed. The internal data source writes data to a single stream of output data and is transferred to the external peripheral device according to the selected mode. Similarly, all data from the external periphery is written to a single input data stream and used to satisfy the requested transaction for one of the possible internal data destinations.

  There are three possible sources of output data: LMC 236 (using ABus), RO249 (using RBus), and general CBus. PIC 237 responds to transactions from these data sources only one at a time. Transactions from one source are completely terminated before the next source is considered. In general, only one data source should be active at any given time. When two or more sources become active, they are processed in order of priority of CBus, ABus, and RBus.

  As usual, the module operates under the control of the standard CBus interface 990, which contains PIC internal registers. Furthermore, the CBus interface 992 can access and control peripheral devices via the coprocessor 224. The ABus interface 991 can also handle memory interactions with the local memory controller. In addition to the result organizer 249, the ABus interface 991 and the CBus interface 992 both send data to the output data path 993, which includes a byte-wide FIFO. Access to the output data path is controlled by an arbitrator that always checks which source has priority or ownership over the output stream. The output data path interfaces the bidet with the output controller 994 and the Centronics controller 997 depending on which is enabled. Each module 994, 997 reads one byte at a time from the internal FIFO of the output data path. The Centronics controller 997 implements a standard Centronics data interface for controlling peripheral devices. The video output control unit includes logic for controlling the output pad in accordance with a required video output protocol. Similarly, video input controller 998 includes logic to control any video input standard being used. The video input controller 998 outputs to the input data path unit 999, which again data and byte wide inputs written asynchronously into the FIFO one byte at a time by either the video input controller 998 or the Centronics controller 997 again. Configure the FIFO.

  The data timer 996 includes various counters and is used to monitor the current state of the FIFO in the output data path 993 and the input data path 999. From the above, it appears that with a coprocessor, it is possible to execute dual stream instructions to simultaneously generate multiple images or multiple portions of a single image. The primary instruction stream is used to obtain an output image of the current page, and the secondary instruction stream can be used to begin rendering the next page while the primary instruction stream is idle. As a result, in the operation in the standard mode, the image of the current page is rendered and then compressed using the JPEG coder 241. When the image needs to be printed, the coprocessor 241 uses the JPEG coder 241 twice to decompress the JPEG encoded image. It is possible to execute instructions for the construction of the next page or band during idle time when no more JPEG decoded image portions are required from the output device. In general, this process increases the rate at which images are generated due to the operational overlap of the coprocessors. In particular, when the coprocessor 224 is used, printing is performed by a printer attached to the coprocessor, and as a result, the rendering speed is increased, so that a benefit can be obtained in terms of speeding up the image processing operation.

  It will be apparent from the foregoing that the preferred embodiment is one embodiment of the present invention and that modifications obvious to those skilled in the art can be made without departing from the scope of the invention.

Appendix A
Coprocessor microprogramming
This section details the operations performed in the coprocessor each time a new instruction is executed. All self-configuration performed by the coprocessor during instruction execution is accomplished by reading / writing internal registers, and therefore the coprocessor can be fully implemented using the external C bus interface or the PCI bus interface by the host. Microprogramming is possible. However, in the case of microprogramming using a host, it is generally expected that it will be difficult due to the problem of host synchronization. This chapter assumes that the reader has sufficient knowledge of the coprocessor in the following respects:
1. Execution model
2. Instruction set and coding
3. Register set
4). Internal structure
A. 1 General matters
A1.1 General information on coprocessor setup
For all instructions other than control instructions and local DMA instructions, the data flow within the coprocessor is essentially under the control of the pixel organizer. The pixel organizer is responsible for fetching the beginning of the input data stream, counting the data, and determining when the last data was fetched. The other modules in the coprocessor basically simply respond to the data sent.
A1.2 Module configuration order
Not all modules are set up on a per instruction basis. Some modules are not configured at all during instruction decoding. The module configuration order is always the order of PO, DCC, OOB, OOC, MDP, JC, RO, and PIC.
A1.3 Other register settings
If an instruction is encoded including setting a certain register value, that register is set by microprogramming according to the following order:
1. If there is no other register set in the module that has the register to be set, that register is set before any other register setting.
2. If there is another register set in the module having the register to be set, that register is set immediately before the _cfg register of the module after the other registers are set.
A1.4 Coding of inconsistent instruction operands
Many instructions specify operands and result data types, so if other data types are specified, they return a meaningless result. For each operand, the coprocessor determines the format of the target operand in the following procedure.
1. If the internal format of the operand is specialized for one pixel (compressed byte or uncompressed byte), the corresponding operand organizer is set to reflect this. The data cache controller is not configured and therefore the operation continues in normal mode.
2. If the internal format of the operand is specialized for “other forms”, the coprocessor generates the operand format from the instruction. Operand B and C are forward. “Other forms” are not originally specified for operand A, and the coprocessor behavior is not defined. The corresponding operand organizer is in bypass mode, and the data cache controller is set to manage the resulting format of operand data. Microprogramming is reasonably independent between various modules.
A1.5 Pseudo-instruction grammar
• The order of instruction execution is determined by the leftmost number.
• Register names are written in Helvetica Bold.
-Register field is register. indicated by field.
I and D indicate an instruction word and a data word that are currently decoded, respectively.
A, B and C are currently decoded operand word A and operand word
B, operand word C.
A_descriptor, B_descriptor, and C_descriptor indicate the data word descriptor of the instruction currently being decoded.
R indicates the result word of the instruction currently being decoded.
“X: Y” indicates a connection between X and Y.
“@X” indicates the register number X of the coprocessor.
“Cbus (X)” indicates execution of C bus operation X.
・ ” ^* “Cbus (X)” indicates data received by the C bus operation X.
・ ” ^* X ″ represents a virtual memory address X.
・ "??" indicates an unknown value or an unknown value.
“Set” indicates the setting of the data manipulation register.
A. 2 Composition operators
note:
1. Major opcodes are 0xC and 0xD
2. The ambiguity is considered to be the byte at the highest address (ie, the highest byte).
3. The accumulator or operand may be premultiplied.
4). The result may be non-premultiplied.
5). The instruction length is defined by the number of input pixels.
A. 3 color space conversion
note:
1. The input space is always three dimensional. By default, it is the channel of the three lowest pixels. Ambiguity is eliminated.
2. The format of the color table is either one that contains one output channel or one that contains four output channels.
A. 4 JPEG instructions
note:
1. The opcode is 0x2.
2. Operand C may be a register to be shut down.
3. There are many options.
・ Do subsampling or not.
・ Do or do not filter.
• 1, 3 or 4 scans.
4). These instructions are associated with a number of registers that are set prior to instruction execution.
A. 4.1 Elongation
Note: 1. The following registers must be set before executing the instruction.
Ro_idr: Output image dimension number register
Ro_cut: Output cut register
Ro_lmt: Output restriction register
A. 4.2 Compression
note:
1. The following registers must be set before executing the instruction.
Po_idr: Output image dimension number register
Jc_rml: interval of restart marker
Ro_cut: Output cut register
Ro_lmt: Output restriction register
A. 5 Data coding
note:
1. All data coding operations are handled in the same way for both compression and decompression. These operation settings are almost the same as in JPEG.
2. Possible encoding operations
・ Huffman coding
・ Predictive coding
3. Possible decoding operations
・ High-speed Huffman decoding
・ Slow Huffman decoding
Packbits decoding (version A)
Packbits decoding (version B)
・ Predictive decoding
4). Operand C may be a register for setting.
5). The following registers must be set before executing the instruction.
Ro_cut: Output cut register
Ro_lmt: Output restriction register
A. 6 Conversion and convolution
1. Opcodes are 0x4 (convolution) and 0x5 (conversion).
2. The coprocessor performs operations that are supersets necessary for each of image conversion and image convolution. The only difference between image conversion and image convolution is that as far as the coprocessor is concerned, the kernel step size is the kernel size (horizontal and vertical) in image conversion, whereas the step size is one source pixel in convolution. That is.
3. option:
-Snap to neighboring pixels and interpolation
・ Pixel (kernel) accumulation or not
Whether to perform pre-multiplication of source pixels
-Final result clamping, wrapping, absolute value
4). Note: Conversion and convolution cannot be performed in place. That is, if the source pointer and destination pointer are the same, the contents are destroyed.
A. 7 Matrix multiplication
note:
1. Opcode is 0x3
2. option:
Whether to perform pre-multiplication of source pixels
・ Clamping, wrapping and absolute value of the final result
Operand C may be written to the register
A. 8 Halftone processing
note:
1. Opcode is 0x7
2. Options are halftone level values only
3. This can be done on pixels or bytes as long as the halftone screen is properly meshed or unmeshed.
A. 9 Memory copy
note:
1. The opcode is 0x92. This instruction uses a completely separate mechanism to complete the memory copy operation.
General data transfer instructions use the normal data flow in the coprocessor and can use various functions using the data manipulation units in the PO and RO.
Peripheral DMA instructions use a direct connection between PIC and LMC. This means that data cannot be manipulated and can be executed simultaneously with subsequent instructions.
A. 9.1 General-purpose data transfer
A. 9.2 Peripheral DMA transfer
note:
1. It may or may not be concurrent. This is handled by the IC.
2. Operand C may be a register to be set
3. Since PIC is a module that handles data, this instruction is different from other “active” instructions.
A. 10 Photo CD extension
This group of commands consists of three different operations: horizontal interpolation, vertical interpolation and remainder fusion. The setting method of the vertical interpolation and the remainder fusion is the same. The opcodes for all these instructions are 0x9.
A. 10.1 Horizontal interpolation
note:
1. Can be performed on pixels or bytes
2. This instruction is an instruction having one operand, and the operand C may be a register to be set.
A. 10.2 Vertical interpolation and remainder fusion
note:
1. The settings for vertical interpolation and rest fusion are the same.
2. Executable for both pixels and bytes.
3. This instruction is an instruction having two operands, and the operand C may be a register set.
A. 11 Control instructions
note:
1. The control instruction consists of two types of operations, namely a flow control instruction and an internal access instruction.
A. 11.1 Flow control
note:
1. Opcode is 0xB
2. The flow control command currently consists of various jump commands and various standby commands.
3. There is no explicit placement within the coprocessor, and this instruction is not an “active” instruction. That is, submodules in the coprocessor do not actually do anything like other instructions.
4). Operand C may be a register to be set.
A. 11.2 Internal access (read)
note:
1. Opcode is 0xA
2. A read instruction transfers data out of the coprocessor.
3. RO is actually the only module that does everything in the coprocessor.
A. 11.3 Internal access (write)
note:
1. Opcode is 0xA
2. A write instruction transfers data into the coprocessor.
3. Since this instruction is not an “active” instruction, modules other than the IC actually do nothing.
A. 12 Reserved instructions
note:
1. Opcodes 0x0 and 0xF are reserved.
2. Reserved instructions give maskable errors.
3. These reserved instructions are to be used as other instructions when the coprocessor is revised in the future.
Appendix B: Registers
1.1 Registers and tables
This section describes the coprocessor registers. These registers can be changed in three ways.
1. Specific coprocessor instructions are for reading and writing registers. By using these instruction groups, the register is read from or written to the memory associated with the local memory interface using the start of the PIC bus cycle of the initiator or the transaction of the general-purpose interface.
2. The contents of many registers change due to side effects of instruction execution. The main mechanism by which the coprocessor sets itself for instruction execution is realized by setting various registers to reflect the current state. After completion of instruction execution, each register reflects the state of the coprocessor. Many typical processes are completely specified and configured by certain instructions. Some registers need to be set just before instruction execution.
"Reserved" register bit meaning
The meaning of “reserved” for any register or its components is as follows.
・ You can write to the reserved place, but the data is rejected.
・ You can read from the reserved place, but the data is undefined.
All unspecified registers and register fields are “reserved”.
1.1.1 Register classification
Registers in the coprocessor are classified based on the behavior described in this section. These descriptions are
External: Outside module (access from). External access using the CBus interface. That is, the target mode PCI by the instruction controller or the external CBus interface is used. Note, registers cannot be set from the PCI bus via the biset mode.
・ Inside: Inside the module (access from)
Status register
The status register is read-only externally and can be read and written internally.
Config 1 register
The config 1 register is readable / writable from the outside and is read-only from the inside. The Config 1 register does not support Type C CBus operations (ie, does not support bit set mode) and is used as a register to hold byte (or larger) configuration information such as address values.
Config 2 register
The config 2 register can also be read and written from the outside, and is read-only from the inside. The configuration 2 register supports type C CBus operation (ie, bit set mode) and is used as a register for holding configuration information that needs to be set in bit units.
Control 1 register
Control 1 register can be read and written from outside and inside. The Control 1 register does not support Type C CBus operations (ie, does not support bit set mode) and is used as a register to hold bytes such as address values (or larger control information).
Control 2 register
Control 2 register can be read and written from outside and inside. The control 2 register supports type C CBus operations (ie, bit set mode) and is used as a register for holding control information that needs to be set in bit units.
Interrupt register
The bit in the interrupt register can be set to 1 from the inside and can be reset to 0 by writing 1 from the outside. Module interrupt / error registers are also of this type. The module interrupt / error register consists of three fields.
[7: 0] means any error condition (status) generated by the module
[23: 8] means any exception condition generated by the module
[31:24] Means any interrupt state generated by the module 1.1.2 Register Map
Table 1.1 shows the coprocessor registers. The number is not an address but a register number.
Table 1.1 Coprocessor registers
1.1.3 Register definition
Function module register
Instruction controller register
I. ic_cfg
The ic_cfg register is divided into three parts. The least significant byte contains global configuration information. The third least significant byte contains stream A configuration information, and the most significant byte contains stream B configuration information. The reset value of this register is 0x00000000.
m. is_stat
This register is divided into four sections. The least significant byte holds the internal state of the IC. The second byte from the least significant holds the decoded result of the current instruction and the current and prefetched instruction streams. The second byte from the most significant holds all status information regarding the A stream. The most significant byte holds information about the B stream. The reset value of this register is 0x00000000.
n. ic_err int
This register includes an active high flag that indicates whether an interrupt or error has occurred within the IC. Each bit is cleared by writing 1.
o. ic_err_int_en
This register contains various error and interrupt permission masks, and the reset value is 0x00000000.
p. ic_ipa
This register holds the most significant 30 bits of the virtual address used for stream A instruction fetch. The two least significant bits are assumed to be 0 as the instruction should be aligned. The reset value of this register is 0x00000000.
q. ic_tda
This register holds the “to do” value for stream A. This is a 32-bit (wrapping) sequence number until a proper instruction exists. The reset value of this register is 0x00000000.
r. ic_fna
This register holds the “end” value for stream A. This indicates the last completed instruction with a 32-bit (wrapping) sequence number. The reset value of this register is 0x00000000.
s. ic_inta
This register holds the “interrupt” number for stream A. This is a 32-bit (wrapping) sequence number where to interrupt when the mechanism is valid and prepared. The reset value of this register is 0x00000000.
t. ic_loa
This register holds the 32-bit (wrapping) sequence number of the last duplicate instruction executed in stream A. The reset value of this register is 0x00000000.
u. ic_ipb
This register holds the most significant 30 bits of the virtual address used for stream B instruction fetch. The two least significant bits are assumed to be 0 as the instruction should be aligned. The reset value of this register is 0x00000000.
v. ic_tdp
This register holds the “to do” value of stream B. This is a 32-bit (wrapping) number until a proper instruction exists. The reset value of this register is 0x00000000.
w. ic_fnb
This register holds the “end” value for stream B. This indicates the last completed instruction with a 32-bit (wrapping) sequence number. The reset value of this register is 0x00000000.
x. ic_intb
This register holds the “interrupt” number for stream B. This is a 32-bit (wrapping) sequence number where to interrupt when the mechanism is valid and prepared. The reset value of this register is 0x00000000.
y. ic_lob
This register holds the 32-bit (wrapping) sequence number of the last duplicate instruction executed in stream B. The reset value of this register is 0x00000000.
z. ic_sema
This register is an alias using a side effect of the ic_stat register, and reading of this register is a side effect of the request of the stream A register semaphore.
aa. ic_semb
This register is an alias using the side effect of the ic_stat register, and reading this register is a side effect of the request for the stream B register semaphore.
Input interface register
ab. iis_cfg
ac. iis_stat
ad. iis_err_int
ae. iis_err_int_en
af. iis_ic_addr
ag. iis_dcc_addr
ah. iis_po_addr
ai. iis_burst
aj. iis_base_addr
ak. iis_test
External interface controller register
al. eic_cfg
am. eic_stat
an. eic_err_int
The error and interrupt bits in the eic_err_int register can be set only by EIC and can be reset only by software. Normal error and interrupt bits are reset by writing a 1 to the bit. The error bit, which is a copy of the PCI configuration register bit, must be cleared by writing to the PCI configuration register. That is, copying with eic_err_int has no effect.
ao. eic_err_int_en
ap. eic_test
aq. eic_pob
ar. eic_high_addr
as. eic_wtlb_v
at. eic_wtlb_p
au. eic_mmu_v
Note: The value of this register can be changed at any time if the MMU is not invalid due to a page fault error or an MMU to PCI bus error.
av. eic_mmu_p
Note: The value of this register can be changed at any time if the MMU is not invalid due to a page fault error or an MMU to PCI bus error.
aw. eic_ip_addr
Note: The value of this register can be changed at any time if the IBD is not invalid due to an error from the Ibus to the PCI bus.
ax. eic_rp_addr
Note: The value of this register can be changed at any time if the RBR is not invalid due to an error from the RBus to the PCI bus.
ay. eic_ig_addr Note: The value of this register can be changed at any time if the GBC is not invalid due to a universal bus error.
az. eic_rg_addr
Note: The value of this register can be changed at any time if the GBC is not invalid due to a universal bus error.
PCI bus configuration space alias
The PCI bus configuration space consisting of 16 words is aliased to a register indicated by an address from 0xc0 to 0xcf.
Local memory controller register
ba. lmi_cfg
This register contains a number of configuration bits and control bits that are used to determine the processing mode and parameters of the LMC. Bits that specifically refer to SDRAM processing have no effect when the sdram_1 pin is high. This register has a reset value 0x20000100 which is a refresh interval of 3.2 microseconds when the frequency of clkin is 80 MHz. All special modes and functions are disabled when power is turned on, and all access rights are set equal to zero. Refresh is valid at reset, but other modules are invalid (E = 0). Refresh is not affected by the E bit.
bb. lmi_stat
The status register consists of module active and undecided bits as well as information inside the machine. The state machine is driven with twice the clock of the CBus interface, so two fields are required to hold the state information for each of the two latest 80 MHz clock cycles.
bc. lmi_err_int
The error and interrupt status registers hold interrupt, exception, and error status information. The register can be read and written, read returns status information, and writing a 1 to a specific bit resets that bit. Writing a zero has no effect on that bit.
This register must have a reset value of 0x00000000, which indicates that no interrupts or errors have occurred. The reserved bit is always 0 and can never change state.
bd. lmi_err_int_en register
The error / exception / interrupt valid register is used to select whether the error / exception interrupt signal is valid or invalid. Registers can be read and written. This register is used to enable bit by bit based on errors, exceptions and interrupts in the lmi_err_int register. There is a one-to-one correspondence between the bits in this register and the bits in the lmi_err_int register. If a particular bit in the lmi_err_int_en register goes high, the corresponding bit in the lmi_err_int register becomes valid, and if it is high, an LMC module error, exception or interrupt signal, c_err, c_exp, or c_int can be generated. If a particular bit in the lmi_err_int_en register is cleared, the corresponding bit in the lmi_err_int register becomes invalid and c_err, c_exp, or c_int cannot be generated. Since there is no exception in LMC, the exp_mask bit in this register has no effect and is all reserved. The reset value of this register is 0x00000000, which disables all error and interrupt sources. Unused bits are always 0 and cannot be set high.
be. lmi_dcfg
This configuration register holds design parameters that determine the size and configuration when a DRAM chip is used. This register holds a reset value 0x0007ff80 that maximizes all timing limit values.
bf. lmi_mode register
This configuration register holds information written to the SDRAM mode register as part of the initialization process. This register is always readable and writable and may be written to the SDRAM by setting the initialization bit. This register has a reset value of 0x0037. This useful default value is required immediately after power-up precharge or immediately after level 1 reset. This sets the read delay to 3 clocks and sets the burst length to a full page using sequential wrap. After any reset, if the sdram_1 pin is low, the initialization bit is set to initially program the SDRAM mode register. After writing the mode register, this bit is automatically cleared to zero.
Peripheral interface register
bg. pic_cfg register
bh. pic_stat
bi. pic_err_int
The error and interrupt bits in the pic_err_int register are set only by PIC and reset only by software. Each bit is reset by writing 1
bj. pic_err_int_en
bk. pic_abus_cfg
bl. pic_abus_addr
bm. pic_cent_cfg
The pic_cent_cfg register contains read / write signals and read-only status signals that control all interface aspects when the Centronics mode is enabled.
bn. pic_cent_dir
bo. pic_reverse_cfg
bp. pic_timer0
bq. pic_timer1
Data cache controller register
br. dcc_cfg1
bs. dcc_cfg2
bt. dcc_stat
bu. dcc_err_int
bv. dcc_err_int_en
bw. dcc_lv0
bx. dcc_lv1
by. dcc_lv2
bz. dcc_lv3
ca. dcc_addr
cb. dcc_raddrb
cc. dcc_raddrc
cd. dcc_test
Operand Organizer Register There are two similar operand organizers in the Operand Organizer register: Operand Organizer B and Operand Organizer C. The registers for these two operand organizers are described here.
ce. oon_cfg (oob_cfg = 0x70, ooc_cfg = 0x80)
cf. oon_stat (oob_cfg = 0x71, ooc_cfg = 0x81)
cg. oon_err_int (obb_err_int = 0x72, err_int = 0x82)
ch. oon_err_int_en (oob_err_int_en = 0x73, err_int_en = 0x83)
ci. oon_dmr (oob_dmr = 0x74, ooc_dmr = 0x84)
cj. oon_subst (oob_subst = 0x75, ooc_subst = 0x85)
ck. oon_cdp (oob_cdp = 0x76, ooc_cdp = 0x86)
cl. oon_len (oob_len = 0x77, ooc_len = 0x8
cm. oon_said (oob_said = 0x78, ooc_said = 0x88)
cn. oon_tile (oob_tile = 0x79, ooc_tile = 0x89)
Pixel organizer register
co. po_cfg
cp. po_stat
cq. po_err_int
cr. po_err_int_en
cs. po_dmr
ct. po_subst
cu. po_cdp
cv. po_len
cw. po_said
cx. po_idr
cy. po_muv_valid
cz. po_muv
Main data path register
da. mdp_cfg All bits are reset to zero.
db. mdp_stat
All bits are reset to zero.
dc. mdp_err_int
All bits are reset to zero.
dd. mdp_err_int_en
All bits are reset to zero.
de. mdp_test All bits are reset to zero.
df mdp_op1 All bits are reset to zero.
dg mdp_op2 All bits are reset to zero.
dh mdp_port All bits are reset to zero.
di mdp_bi All bits are reset to zero. The mdp_bi register is used for various things in various modes.
dj mdp_bm All bits are reset to zero. The mdp_bm register is used for different ones in different modes.
dk mdp_len All bits are reset to 0
JPEG encoder register dl jc_cfg
dm jc_stat
dn jc_err_int
do jc_err_int_en
dp jc_rsi
dq jc_decode
dr jc_res
ds jc_table_sel
Results organizer register
dt ro_cfg
du ro_stat
dv ro_err_int
dw ro_err_int_en
dx ro_dmr
dy ro_subst
dz ro_cdp
ea ro_len
eb ro_sa
ec ro_idr
ed ro_vbase
ee ro_cut
ef ro_lmt
PCI Configuration Space Alias The PCI configuration space is a 256-byte PCI-defined block of registers that allows the host to configure and read the status of PCI devices. It is accessed using the PCI configuration cycle. The registers are also mirrored in the read-only area of the coprocessor's internal memory and can therefore be read using the normal PCI memory cycles. The format of the configuration space implemented in the EIC is shown in Table 1.141.1.
Table 1.141.1 Spatial layout of coprocessor PCI configuration
The reserved bits in the reserved register and the implemented register return 0 for reading and are not affected by writing. Configuration space addresses in the range 0x40-0xff are also reserved. Vendor-specific configuration registers are not defined.
eg Vendor ID
This register is read-only. The vendor ID of CISRA is 0x11AC.
eh Device ID
This register is read-only. The device ID of the coprocessor is 0x0001. The device ID field is divided into two 8-bit fields: the most significant 8 bits are numbers indicating device characteristics (0x0 is a coprocessor), and the least significant 8 bits are the version number of the device (0x1). Indicates the coprocessor version).
ei command register
Table 1.142 shows the definition of the command register field. All unreserved bits in this register can be read / written. After reset, this register is set to 0x0000.
ej Status register Table 1.143 shows the definition of the status register field. Reading this register is normal. Some bits in this register are read-only. The other bits are set to 1 only by the coprocessor and reset to 0 only by the host (except for the test mode). The host resets by writing a 1 to that bit; writing a 0 makes no sense. After reset, this register is set to 0x0280.
ek revision ID This is a read-only register. The initial revision ID of the coprocessor is 0x01. el class code This is a read-only register. This register is set to 0xFF0000 because the coprocessor is not suitable for the PCIISIG defined class code.
em cache line size
This is a read / write register that determines the cache line size of the system in units of 32 bit words. This is determined when the coprocessor uses a memory read line or a memory multiple read command. The coprocessor supports values from 0 to 255 in this register. A 0 in this register disables the memory read line and memory multiple read formats. This register is set to 0x00 at reset.
en Delay timer
This register is a readable / writable register that specifies the maximum number of clocks used by the CPU for all PCI processing. The coprocessor supports values from 0 to 255 in this register. This register is set to 0x00 at reset.
eo header type
This read-only register is set to 0x00. This means that the coprocessor uses a configuration space of type 0 layout.
ep base address
This readable / writable register is used to place the coprocessor's internal registers, internal memory, local memory, and general purpose interface in the host's memory map. The various resources of the coprocessor occupy 64 MB (not all are used), so only the first 6 bits of this register can be written. All remaining bits are hard wired to 0. The lower 4 bits of this register are read-only control bits, which are also wired to 0. This means that the register refers to the memory space, meaning that the coprocessor is mapped anywhere in the host 32-bit space and cannot be prefetched when the coprocessor resource is the target.
eq Subsystem vendor ID
This read-only register allows the host to identify the vendor of the PCI board installed in the system (for the component vendor installed in the PCI interface on the board). The contents of this register are loaded using the EIC configuration serial port at reset.
er subsystem ID
This read-only register allows the host to identify the PCI board installed in the system. The contents of this register are loaded using the EIC configuration serial port at reset. This mechanism allows external encoding and reading from the host of information required for board function or configuration.
es interrupt line
This read / write register is used to allow the system software to record interrupt line routing information and can be accessed by the interrupt service software. It has no effect on the processing in the coprocessor. This register is set to 0x00 at reset.
et interrupt pin
This read-only register is wired to 0x01 in hardware. This indicates that the coprocessor uses the PCI inta_1 interrupt pin.
eu Min_Gnt
This read-only register indicates to the host the burst period length in 1/4 microsecond units required by the coprocessor. The optimal value for this register has not yet been determined.
ev Max_Lat
This read-only register indicates to the host the PCI bus gain control maximum delay required by the coprocessor in 1/4 microsecond units. The optimal value for this register has not yet been determined.
1.1.4 Internal memory map
This section details the objects that occur in the pre-module data area in the coprocessor's internal memory map.
1.1.5 Memory word field
a eic_ptp

Diagram showing the operation of a raster image coprocessor in a host computer environment A more detailed view of the raster image coprocessor of FIG. Diagram showing memory map of raster image coprocessor Diagram showing the relationship between CPU, instruction queue, instruction operand, result in shared memory, and coprocessor Diagram showing the relationship between the instruction generator, memory manager, queue manager, and coprocessor Diagram showing the operation of the graphics coprocessor that reads instructions from the pending instruction queue and places them in the end instruction queue Diagram showing the implementation of a fixed-length cyclic buffer in the instruction queue and explaining the need to wait until the buffer overflows Diagram showing instruction execution stream used in coprocessor Instruction execution flowchart, Diagram showing standard instruction word format used in coprocessors Diagram showing the instruction word field of a standard instruction Diagram showing data word field of standard instruction The figure which shows the command control part of FIG. 2 typically The figure which showed the execution control part of FIG. 13 in detail State transition diagram of command controller The figure which shows the instruction decoding part of FIG. FIG. 16 shows the instruction sequencer of FIG. 16 in more detail. State transition diagram of the ID sequencer of FIG. The figure which showed the prefetch buffer control part of FIG. 13 in detail , Diagram showing the standard format for register storage and inter-module relationships used in the coprocessor The figure which shows the format of the control bus processing which is used in the coprocessor Diagram showing the data flow within a part of a coprocessor Diagram showing various data reformat examples used in coprocessors Diagram showing various data reformat examples used in coprocessors Diagram showing various data reformat examples used in coprocessors Diagram showing various data reformat examples used in coprocessors Diagram showing various data reformat examples used in coprocessors Diagram showing various data reformat examples used in coprocessors Diagram showing various data reformat examples used in coprocessors Diagram showing format conversion performed in coprocessor Diagram showing format conversion performed in coprocessor The figure which shows the input data conversion process performed in a coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various data transformations performed in the coprocessor Diagram showing various internal output data conversions performed in the coprocessor Diagram showing various data conversion examples executed in coprocessor Diagram showing various data conversion examples executed in coprocessor Diagram showing various data conversion examples executed in coprocessor Diagram showing various data conversion examples executed in coprocessor Diagram showing various data conversion examples executed in coprocessor Diagram showing various fields used in internal registers that determine which data conversion should be used Block diagram of a graphics subsystem using data normalization Circuit diagram of data normalizer The figure which shows the pixel process performed in a compositing process Diagram showing instruction word format for composition processing Diagram showing data word format for compositing process Diagram showing instruction word format for tile processing Diagram showing operation of tile command for image The figure which shows the utilization process of the color section / intra-section position table for remapping a color value The figure which shows the storage format of the area / intra-section position table in the MUV buffer of a coprocessor The figure which shows the color conversion process using the interpolation performed in a coprocessor The figure which shows the improvement process of the color conversion process in the edge performed in a coprocessor The figure which shows the color space conversion process for 1 output color performed in a coprocessor Diagram showing memory storage in coprocessor cache when using single color output color space conversion Diagram showing the technique used in multiple color space conversion The figure which shows the address remapping process for the cache used in a multiple color space conversion process The figure which shows the instruction word format in a color space conversion instruction Diagram showing multiple color conversion method The figure explaining the production | generation of MCU in the JPEG conversion process performed with a coprocessor The figure explaining the production | generation of MCU in the JPEG conversion process performed with a coprocessor The figure which shows the structure of the JPEG encoding part of the coprocessor 68 shows the quantization unit in FIG. 68 in more detail. The figure which shows the Huffman encoding part of FIG. 68 in detail The figure which shows a Huffman encoding part and a decoding part The figure which shows a Huffman encoding part and a decoding part A diagram for explaining deletion / restriction processing of JPEG data used in the coprocessor A diagram for explaining deletion / restriction processing of JPEG data used in the coprocessor A diagram for explaining deletion / restriction processing of JPEG data used in the coprocessor The figure which shows the command word format of the JPEG command Block diagram of a general discrete cosine transform device (conventional example) The figure which shows the arithmetic data path of the DCT apparatus of a prior art example Block diagram of DCT device used in coprocessor A block diagram showing the arithmetic circuit of FIG. 79 in more detail. The figure which shows the arithmetic data path of the DCT device of FIG. The figure which shows the typical Huffman coding data in which the bit field (one which is not byte-aligned and what is not byte-aligned) is interleaved like a JPEG format , FIG. 84 is a diagram showing in more detail the overall structure of the JPEG data Huffman decoding unit in FIG. The figure which shows the whole structure of the Huffman decoding part of JPEG data The figure which shows the data processing in the stripper block which deletes the bit field which is not byte-aligned and encoded from input data, and also shows the example of the tag code corresponding to the data output from a stripper , Diagram showing data pre-shifter configuration and data flow , The figure which shows the control logic of the decoding part of FIG. , Diagram showing marker pre-shifter configuration and data flow Block diagram of a combinational circuit for decoding a Huffman code value in JPEG encoding; Block diagram of padding area concept and padding bit decoding unit The figure which shows the example of the data format output from a decoding part and used in a coprocessor Diagram showing the technique used in image conversion instructions The figure which shows the command word format in the image conversion command Diagram showing the format of the image conversion kernel used by the coprocessor Diagram showing the format of the image conversion kernel used by the coprocessor The figure which shows the utilization process of the index table for the image conversion used with a coprocessor Diagram showing data field format for instructions used in conversion and convolution, Explanatory drawing of bp field of instruction word Diagram showing the convolution process used in the coprocessor Instruction word format diagram of convolution instruction used in coprocessor Instruction word format diagram of matrix multiplication used in coprocessor, Diagram showing hierarchical image manipulation processing used in the coprocessor Diagram showing hierarchical image manipulation processing used in the coprocessor Diagram showing hierarchical image manipulation processing used in the coprocessor Diagram showing hierarchical image manipulation processing used in the coprocessor Diagram showing instruction word codes in hierarchical image instructions The figure which shows the instruction word code of the flow control instruction which is used with the coprocessor Diagram showing the pixel organizer in more detail The figure which shows the operand fetch section in the pixel organizer in more detail Diagram showing various storage formats used in coprocessors Diagram showing various storage formats used in coprocessors Diagram showing various storage formats used in coprocessors Diagram showing various storage formats used in coprocessors Diagram showing various storage formats used in coprocessors The figure which shows the MUV address production | generation part in the pixel organizer of a coprocessor in detail. Block diagram of a multi-value (MUV) buffer used in a coprocessor 116 shows the structure of the encoder in FIG. 116 shows the structure of the decoder in FIG. The figure which shows the structure of the address generation part of FIG. 116 which produces | generates a read address in JPEG mode (pixel decomposition | disassembly). The figure which shows the structure of the address generation part of FIG. 116 which produces | generates a read address in JPEG mode (pixel restoration). 116 is a diagram showing a configuration of a memory module including the storage device of FIG. The figure which shows the structure of the circuit which multiplexes the read address to the memory module Diagram showing how lookup table entries are stored in a buffer operating in single lookup table mode Diagram showing how lookup table entries are stored in a buffer operating in multiple lookup table mode Diagram showing how pixels are stored in a buffer operating in JPEG mode (pixel decomposition) Diagram showing how a single color is stored from a buffer operating in JPEG mode (pixel restoration) Diagram showing the structure of the coprocessor results organizer in more detail Diagram showing the structure of the coprocessor operand organizer in more detail Block diagram of computer architecture for main data path used in coprocessor Block diagram of the input interface for receiving, storing and rearranging input data objects for further processing Block diagram of an image data processor for performing arithmetic operations on input data objects A block diagram of a color channel processor for performing arithmetic operations on one channel of an input data object. Block diagram of multi-function block in color channel processor Block diagram for compositing operation Diagram showing inverse scanline transformation A block diagram of the steps necessary to calculate the value at a specified pixel Block diagram of image conversion engine Diagram showing two formats for kernel description Diagram showing the definition and interpretation of the bp field Block diagram of multiplication / addition unit that performs matrix multiplication Diagram showing control, address and data flow in cache and cache controller in coprocessor Diagram showing cache memory configuration Diagram showing the address format for the cache controller in the coprocessor , Block diagram of multi-function block in color channel processor 144 shows the coprocessor input interface switch of the cache and cache controller of FIG. The figure which shows the 4 port dynamic local memory control part of the coprocessor which shows the main address and the data path 146 is a state mechanism diagram of the control unit of FIG. The figure which shows the pseudo code which listed the function in the arbitration department of Figure 146 in detail 146 is a diagram showing the structure and terminology of requester priority bits used in FIG. Diagram showing the external interface controller in the coprocessor in more detail The figure which shows the mapping process to the physical address used by the coprocessor or the mapping process from the physical address The figure which shows the mapping process to the physical address used by the coprocessor or the mapping process from the physical address The figure which shows the mapping process to the physical address used by the coprocessor or the mapping process from the physical address The figure which shows the mapping process to the physical address used by the coprocessor or the mapping process from the physical address , The figure which shows the IBus receiving part in FIG. 150 in detail , The figure which shows the RBus receiving part in FIG. 2 in detail , The figure which shows the memory management part in FIG. 150 in detail The figure which shows the peripheral interface control part in FIG. 2 in detail

Claims (11)

A device for decoding a plurality of data blocks encoded with a plurality of variable length codes interleaved with a variable length uncoded bit field and having a plurality of fixed length uncoded fields,
Removing the plurality of fixed length uncoded fields, interleaving the variable length uncoded bit field and the variable length uncoded bit field, and the plurality of variable length codes in the plurality of data blocks A pre-processing unit that outputs a plurality of position signals indicating the positions of the fixed-length uncoded fields of
Decoding data of variable-length encoded data input during the fixed-length non-encoded field is output from a decoding device during the position signal corresponding to the fixed-length non-encoded field. And a means for sending the position signal to an external device in synchronization with the data to be decoded. A first processing unit having a first barrel shifter set and a first register, and processing the plurality of variable length codes interleaved with the variable length uncoded bit field;
A second processing unit which has a second barrel shifter set and a second register, and which processes a plurality of position signals indicating the positions of the plurality of fixed-length uncoded fields in a plurality of data blocks, The decoding apparatus according to claim 1, wherein the first and second processing units are the same, and outputs of the first and second barrel shifter sets and the first and second processing units receive the same control signal. The output of the second processing unit that processes a position signal indicating the position of the fixed-length non-encoded field is used to determine the size of an unencoded variable-length field that is removed from the data stored in the data register at the time of decoding. The decoding device according to claim 2, wherein The preprocessing unit removes a plurality of fixed-length uncoded fields, and converts the plurality of variable-length codes interleaved with the variable-length uncoded bit field and the variable-length uncoded bit field into a plurality of A tag indicating a plurality of fixed-length codes composed of fixed-length bit fields and one of the fixed-length bit fields being passed or removed in the preprocessing field or passed in the preprocessing field The decoding apparatus according to claim 1, wherein the tag is output so as to exist before or after a marker indicating a fixed-length uncoded field. The decoding apparatus according to claim 1, wherein the data block is Huffman encoded. A method of decoding a plurality of data blocks encoded with a plurality of variable length codes interleaved with a variable length uncoded bit field and having a plurality of fixed length uncoded fields,
Removing the plurality of fixed length uncoded fields, interleaving the variable length uncoded bit field and the variable length uncoded bit field, and the plurality of variable length codes in the plurality of data blocks A preprocessing step of outputting a plurality of position signals indicating the positions of the fixed-length uncoded fields
Decoding data of variable-length encoded data input during the fixed-length non-encoded field is output from a decoding device during the position signal corresponding to the fixed-length non-encoded field. And a step of sending the position signal to an external device in synchronization with the data to be decoded. Processing the plurality of variable length codes interleaved with the variable length non-encoded bit field using a first processing unit having a first barrel shifter set and a first register;
The method further includes the step of processing a plurality of position signals indicating positions of the plurality of fixed-length uncoded fields in the plurality of data blocks using a second processing unit having a second barrel shifter set and a second register. ,
7. The decoding method according to claim 6, wherein the first and second processing units are the same, and outputs of the first and second barrel shifter sets and the first and second processing units receive the same control signal. In accordance with the output of the second processing unit that processes the position signal indicating the position of the fixed-length non-encoded field, the size of the non-encoded variable-length field to be removed from the data stored in the data register at the time of decoding is set. The decoding method according to claim 7, further comprising a step of determining. In the pre-processing unit step, a plurality of fixed-length uncoded fields are removed, and the plurality of variable-length codes interleaved with the variable-length uncoded bit field and the variable-length uncoded bit field are As a plurality of fixed-length codes consisting of a fixed-length bit field, and indicating that one fixed-length bit field is passed or removed in the pre-processing field or passed in the pre-processing field 7. The decoding method according to claim 6, wherein the decoding method has a tag, and the tag is output so as to exist before or after a marker indicating a fixed-length uncoded field. The decoding method according to claim 6, wherein the data block is Huffman encoded. Storage medium for storing the method described as computer executable program code to any one of claims 6-1 0.