JPH10303308A - Integrated circuit having cores and shells and hierarchical firmware therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten a design time and a verification time. SOLUTION: A first core 14A is coupled with a first shell 12A, which in turn is coupled with a bus. The first shell 12A provides an interface to the bus under control of a third firmware routine. The third firmware routine is designed to call a first firmware routine when a first input value is given to the bus, thereby producing a first defined result. The same explanation holds true even for a second core and shell. With such a firmware structure, the cores, shells and corresponding firmware routines can be re-used in another integrated circuit design.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to the field of integrated circuits, and more particularly, to the design of integrated circuits using pre-designed cores.

[0002]

[0003] Integrated circuits are often included in computer systems to extend the hardware functionality of these systems. Prior to the inclusion of a particular integrated circuit, the function embodied by the particular integrated circuit
Typically, a central processing unit (C) of a computer system
PU)). (i) the functionality is often performed by a computer system; and (ii) the functionality is typically performed in hardware if the functionality can be performed more efficiently by implementing the functionality in hardware. Will be fulfilled.

[0003] In most cases, the functions to be handled by the integrated circuit can achieve the desired performance without requiring a complete translation into hardware. Alternatively, hardware that accelerates certain basic operations within the function may be used. Software is written to perform the function using the newly added hardware. Because the software is useful only with newly added hardware, the software is typically implemented with integrated circuits (eg, implemented in read-only memory or ROM), and therefore Software is always available for use with the integrated circuit. Software that is always available for use with specific hardware is referred to as firmware. The firmware and the newly added hardware work together to perform the desired function.

[0004] In the past, integrated circuits have often been limited by the number of transistors that can be used therein.
Accordingly, the amount of functionality contained in a particular integrated circuit has been somewhat limited. Thus, it was relatively efficient to design each new integrated circuit independently, without reference to any previous work.

[0005] More recently, the number of transistors that can be included in a given integrated circuit has increased dramatically. Integrated circuits have thereby become more complex, integrating larger amounts of functionality as the number of available transistors has increased. As integrated circuits have increased in complexity, so has the amount of time required to develop and fully test new integrated circuits. At the same time, the speed of change in the semiconductor industry requires shorter time to market products.

[0006]

SUMMARY OF THE INVENTION The problems outlined above are largely solved by a hierarchical integrated circuit and a corresponding hierarchical firmware structure. Hierarchical integrated circuits are designed (p
Perform various subfunctions of the integrated circuit using redesigned and preverified cores. Since the core is designed and verified, the time required to design and verify the desired integrated circuit may be advantageously reduced. Custom logic that can be used to complete the desired function of an integrated circuit
Is designed, and the custom logic can interface to the core according to the interface used by the core. Moreover, shells can be developed that interface the core to other parts of the integrated circuit. The shell may provide a higher level interface than the lower level interface used by the core. In addition, the shell provides buffering (b
uffering).

[0007] The hierarchical firmware structure corresponding to the hierarchical integrated circuit provides a firmware routine corresponding to each level of the hierarchy in the integrated circuit. In this way, if the core is reused in a later designed integrated circuit, the corresponding core firmware routine is also immediately available for reuse. Similarly, if the shell and the core contained therein are reused in a subsequently designed integrated circuit, the corresponding shell and core firmware routines will also:
Ready to use for re-use. Advantageously,
Hardware implementation
The portability of the firmware from to the hardware implementation can be increased.

[0008] Generally speaking, the present invention comprises a first and a second.
An integrated circuit having a first core and first and second shells is contemplated. The first core operates under control of a first firmware routine based on a first input value to the first core to calculate a first predefined result.
lt). Similarly, the second core is configured to operate under a second firmware routine based on a second input value to the second core to produce a second defined result. The first core is coupled to a first shell, where the first shell also
Coupled to a bus. The first shell is configured to provide an interface to the bus under control of a third firmware routine. In addition, the third firmware routine is configured to invoke the first firmware routine when a first input value is provided over the bus, thereby producing a first defined result. The second core is similarly coupled to a second shell, and the second shell is further coupled to a bus. The second shell is configured to provide an interface to the bus under control of a fourth firmware routine. Further, the fourth firmware routine is configured to invoke the second firmware routine when a second input value is provided over the bus, thereby producing a second defined result.

The present invention further contemplates a method for operating an integrated circuit. A first shell in the integrated circuit comprises a first shell.
Is controlled by using a firmware routine. The first core in the first shell is controlled using a second firmware routine.

[0010] The present invention still further contemplates an integrated circuit having a plurality of shells and a plurality of cores coupled to each other. Each of the plurality of cores is one of the plurality of shells.
Included in one. The firmware structure used with the integrated circuit is modularized into shell firmware routines and core firmware routines. Each of the plurality of shell firmware routines corresponds to a different one of the plurality of shells. Similarly, each of the multiple core firmware routines
It corresponds to a different one of the plurality of cores.

[0011] Other objects and advantages of the present invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the figures and will herein be described in detail. However, the figures and detailed description thereto are not intended to limit the invention to the particular form disclosed, but, on the contrary, fall within the spirit and scope of the invention as claimed. It is to be understood that all variations, equivalents and alternatives are intended to be included.

[0013]

Referring now to FIG. 1, a block diagram of a hierarchical integrated circuit 10 is shown. As shown in FIG. 1, the hierarchical integrated circuit contains a plurality of shells 12A-12B. Each shell contains one or more cores, for example, shell 12A contains core 14A and shell 12B contains cores 14B and 14C. Shell 12A is coupled to shell 12B. Moreover, both shells 12A and 12B are configured to communicate with blocks outside of integrated circuit 10. It is noted that any number of shells 12 may be included in various embodiments of integrated circuit 10 and any number of cores 14 may be incorporated into shell 12. Further, a given shell is configured to communicate directly with the outer blocks to the integrated circuit 10,
Or may not be configured.

In general, the core includes defined and verified blocks of logic that perform sub-functions of the desired function of integrated circuit 10. The core can be used with other cores or custom logic to perform the functions for which the integrated circuit 10 is designed. Since the core is defined and verified, the designer of the integrated circuit 10 need not be concerned with the details of implementing the sub-functions implemented by the core. Instead, the designer includes the core in the integrated circuit design and designs additional sub-functions where the core is not available. The time that an integrated circuit is brought to market can be reduced by the amount of time previously required to design the functionality within the core and verify that the core functions as desired.

[0015] The core may be provided in a number of ways. The core is a synthesizable register-transfer level (regis
It can be provided as a ter-transfer level (RTL) description, which can be synthesized together with RTL descriptions of shell logic and other logic blocks in the integrated circuit 10. If the core is provided this way, the designer of the integrated circuit will need to
It has the flexibility to place the core related circuit design along with other logic blocks and related circuit designs ("lay out" the core) to optimize the g aspect). Alternatively, the core is a pre-laid out circuit that can be included in the final integrated circuit design
Can be provided as Although the designer of the integrated circuit is less flexible in this case, the task of placing the circuit design corresponding to the core has been completed previously (ie, the starting design of the integrated circuit where the core is incorporated). Will be completed prior to Integrated circuit designers can focus their time on the additional circuit designs involved in the design.

Each core 14 selected to be included in the integrated circuit 10 generally provides an input value on which the core 14 operates and is useful for providing an output value generated by the core 14. Has a low level interface. To combine the various cores 14 together (as well as into any custom logic blocks (not shown) that may be included in the design), a "shell" couples each core (or if directly together) If several cores designed like are chosen for the design, they are designed for a group of cores). As used herein, a shell includes a circuit design used to interface between a designed core and the rest of the integrated circuit 10. The shell may further include a buffer for storing input and output data for the cores contained therein. In addition, the shell may include an interface circuit design for interfacing to a custom bus included in integrated circuit 10. Custom bus integrated circuit 10
Optimized for communication between components, typically
Not the same as the interface to the core. Additional circuit designs can be included to communicate with devices external to integrated circuit 10.

Since the integrated circuit 10 is hierarchical in structure, the accompanying firmware is designed to have a similar hierarchical structure. `` Modularizing code into independent routines for software (modularizin
g) ”creates a hierarchy. Routines corresponding to the more abstract levels of hierarchy may "call" the lower hierarchy routines if the higher level routine decides that a lower hierarchy operation is desired in hardware. call) "(ie, transfer control). As used herein, a "routine" is a set of instructions arranged to perform a desired function. Instructions are arranged in a particular sequence and are consciously separated from other sequences (routines) by the programmer. Typically, a routine has a formally specified set of zero or more input arguments to operate on, and zero or more output return values (return).
value). In this way, firmware that interacts with each level of the design is easily identifiable for change and / or portability. If the core, or shell and some of the cores contained therein, are to be used for another integrated circuit design, the corresponding firmware can be identified and reused.

[0018] In contrast, firmware written for a typical integrated circuit or group of integrated circuits generally has one part where the functional parts and the parts that interact with the hardware are mixed. It is a routine. Redesigning the corresponding hardware parts requires that the new firmware be written essentially from scratch. Thus, the modular firmware structure of the present invention allows for easier portability and variations. The core can be reused in another integrated circuit design, and the corresponding core firmware routine can also be reused. Similarly, a shell and a corresponding core, along with a corresponding shell firmware routine and a core firmware routine, can be reused in another integrated circuit design.

Referring to FIG. 2, a diagram of the firmware hierarchy 20 corresponding to the integrated circuit 10 is shown. hierarchy
The highest level at 20 is application programming int
erface) (API) layer 22. The API layer 22 defines a set of high-level routines that can be used by an application programmer (ie, a programmer writing a program for use in a computer system including the integrated circuit 10).
API routines provide a standard interface for use by application programmers, regardless of the specific hardware included in a particular computer system. The implementation of the routine and the underlying hardware can vary, and the application program will still work correctly if recompiled for a new implementation. In general, the API layer routines check for errors in the arguments provided to the routine and then call the appropriate lower level routine.

The system firmware level 24 is next in the hierarchy and generally corresponds to the functionality of the integrated circuit 10 as a whole. Among other tasks, system firmware level 24 includes task scheduling between the shell firmware routine and the core firmware routine, as well as error handling when any routine detects an error. handling) can be provided. Shell firmware layer 26 includes shell firmware routines corresponding to each shell 12 in integrated circuit 10. Similarly, core firmware layer 28 includes a core firmware routine corresponding to each core 14 in integrated circuit 10. The shell firmware routine can call a core firmware routine for a core included in the corresponding shell.

Turning now to FIG. 3, a block diagram of one embodiment of the integrated circuit 30 is shown. FIG.
Is an MPEG decoding (decod
ing). However,
Other embodiments may be configured to perform any desired functions.

Before further discussion of the features of integrated circuit 30 in order to facilitate an understanding of integrated circuit 30, MPEG
Provide a brief discussion of the standard. The MPEG (Moving Pictures Experts Group) compression standard is a set of techniques for compression and decompression of full motion video images using inter-frame and intra-frame compression techniques. This is the method. Intra-frame compression is a method of converting a still image or data in a single frame into spatial redundancy (spatial redundancy) in a frame.
(redundancy). The interframe compression method uses multiple frames or motion video (m
otion video) with temporal redundancy between frames (temporal redu
ndancy). MPEG
Compression uses both motion compensation and the discrete cosine transform (DCT) method, among others, and can result in compression ratios above 200: 1.

The two dominant MPEG standards are MPEG-
1 and MPEG-2. The MPEG-1 standard generally covers block-based motion compensation prediction.
It relates to inter-field data reduction using (motion compensation prediction) (MCP). The MCP generally uses a time differential pulse code modulation (d
Ifferential pulse code modulation (DPCM) is used. The MPEG-2 standard is similar to the MPEG-1 standard, but extends to cover a wider range of applications, including interlaced digital video such as high definition television (HDTV). ) including.

The inter-frame compression method such as MPEG is based on the following facts. That is, in most video sequences, the background is relatively stable,
The activity takes place in the foreground. The background can move, but most of the consecutive frames in the video sequence are redundant. MPEG compression uses this inherent redundancy to encode or compress frames in a sequence.

An MPEG stream contains three types of images. These are the inner frames (I) (i
ntra (I) frame), Predicted (P)
frame) and bidirectional interpolation frame (B) (Bi-directio
nal Interpolated (B) frame). The I or inner frame contains video data for all frames of the video and is typically placed every 10-15 frames. Inner frames provide an entry point into the file for random access and are generally only gently compressed. The predicted frame is encoded with respect to the past frame, ie, the previous inner or predicted frame. Thus, a P frame only contains the changes associated with the previous I or P frame. In general, predicted frames receive a fairly high amount of compression and are used as references for future predicted frames. Thus, both I and P are used as references for subsequent frames. Bi-direct image
ional pictures) contain the greatest amount of compression and require both past and future references to be encoded. Bidirectional frames are not used as references for other frames.

In general, for the frames following the reference frame, ie the P and B frames following the reference I or P frame, only a small part of these frames differs from the corresponding part of the respective reference frame. Thus, for these frames, only the differences are captured, compressed and stored. The difference between these frames is typically the result of motion vector estimation logic, as discussed below.
logic).

When an MPEG encoder receives a video file or bitstream, it generally first creates an I-frame. MPEG encoders use intraframe lossless compression technology.
The I frame can be compressed using a compression technique. After the I frames are created, the MPEG encoder divides each frame into a 16 × 16 pixel square grid called a macroblock. Each frame is divided into macroblocks to perform motion estimation / compensation. Thus, for each target image or frame, i.e., the frame to be encoded, the encoder determines the exact or exact position between the macroblock of the target image and a block in the next image called a search frame. Find an exact match. For the target P frame,
The encoder searches in the previous I or P frame. For a target B frame, the encoder searches in a previous or subsequent I or P frame. If a match is found, the encoder transmits a vector movement code or motion vector. The vector movement code or motion vector only contains information about the differences between the search frame and the respective target image. Blocks in the target image that do not have changes associated with the blocks in the reference image or I-frame are ignored. in this way,
The amount of data actually stored for these frames is significantly reduced.

After the motion vectors have been generated, the encoder then encodes the changes using spatial redundancy. Thus, after finding a change at the position of the macroblock, M
The PEG algorithm further calculates and encodes the differences between corresponding macroblocks. The encoding of the difference is accomplished through a mathematical process called the Discrete Cosine Transform (DCT). This process divides the macroblock into four sub-blocks, looking for changes in color and brightness. Human perception is more sensitive to changes in brightness than changes in color. Thus, the MPEG algorithm reduces color space rather than brightness,
Focus more effort.

Thus, MPEG compression is based on two types of redundancy in a video sequence, these being spatial in which redundancy is in individual frames and temporal in which is redundancy between consecutive frames. is there. Spatial compression is achieved by considering the frequency characteristics of the image frames. Each frame is divided into non-overlapping blocks, and each block is transformed via a discrete cosine transform (DCT). After the transformed block is transformed into a "DCT domain",
Each entry in the transformed block is quantized with respect to a set of quantization tables. The quantization step for each entry can vary, taking into account the sensitivity of the human visual system (HVS) to frequency. Since HVS is more sensitive to low frequencies, most of the high frequency entries are quantized to zero. At this stage where the entries are quantized, information is lost and errors are introduced into the reconstructed image. Run length encoding is used to convey the quantized value. To further facilitate compression, the blocks are scanned in a zig-zag arrangement that scans the lower frequency entries first, and the non-zero quantized values are entropy encoded with a zero run length.

As discussed above, temporal compression means that most of the objects remain the same between successive image frames, and the difference between objects or blocks in subsequent frames is the motion (object motion). , Camera movement or both) as a result of their position in the frame. The key to this relative encoding is motion estimation. In general, motion evaluation is an essential processing requirement in most video compression algorithms. As mentioned above, motion estimation is the task of identifying temporal redundancy between frames of a video sequence.

When the MPEG decoder receives the encoded stream, the MPEG decoder reverses the above operation. In this way, the MPEG decoder reverse scans to remove the zigzag arrangement and dequantizes the data
(de-quantize) and inverse DCT for transforming data from the frequency domain back to the pixel domain. The MPEG decoder also performs motion compensation using the transmitted motion vectors to recreate or reconstruct temporally compressed frames. As frames are received that are used as references for other frames (eg, I or P frames), these frames are decoded and stored in memory. When a temporally compressed or encoded frame (eg, a P or B frame) is received, the previous decoded I
Alternatively, motion compensation is performed on the frame using the P reference frame. The temporally compressed or encoded frame (referred to as the target frame) includes a motion vector that references a block in a previous decoded I or P frame stored in memory. MPE
The G decoder tests each motion vector, determines the respective reference block in the reference frame, and calls the reference block indicated by the motion vector from memory to reconstruct the temporally compressed frame. .

Referring to FIG. 3, the integrated circuit 30 in this embodiment is coupled to an external memory 32. As shown, the external memory 32 is a synchronous dynamic random access memory (Synchronous Dynamic Random Access Memory).
ory) (SDRAM), but note that other memories can be used. The integrated circuit 30 also includes an audio digital-to-analog converter (audio DAC) 34 and an NTSC (National Television Standards Committ).
ee) / PA1 encoder 36. The audio DAC 34 converts the digitized audio values decoded by the A-shell 54 into analog signals for transmission to a speaker (not shown) which converts the analog signals to audible sound. Similarly, NTSC / PA1 encoder 36 converts the image decoded by V-shell 52 into a signal that can be displayed on a video screen (not shown).

As shown, integrated circuit 30 includes a CPU bus controller 38 for coupling to an external CPU. Any CPU can be used, for example, the processor M
IPS family or Intel Pentium
Pentium). In one particular embodiment, C
The PU can be integrated into the integrated circuit 30 with MPEG functions. CPU bus controller 38 couples to CPU bus 40. Timer 42 and the stream and host interface subsystem
bsystem) 44 is coupled to CPU bus 40. Stream and host interface subsystem 44 is adapted to receive an MPEG stream from an external device (not shown). Further, the stream and host interface subsystem 44 includes a PTS table 46, a control unit (CTL unit) 48, and a stream buffer 50. The operation of the components of the stream and host interface subsystem 44
This is described in more detail below. Video shell block (video
A shell block 52 is also coupled to the CPU bus 40. As shown in FIG. 4 below, V-shell block 52 includes a video processing core (V core) and a macroblock processing core (MB core), as well as reconstruction buffer logic and reference buffer logic. An audio shell block (A shell) 54 is also coupled to the CPU bus 40. As shown in FIG. 5 below, the audio shell block 54 includes a CPU bus interface, a memory bus interface, and an input / output interface.
Includes audio processing core (A core).

V-shell block 52 couples to memory controller subsystem 58 through memory bus 56. The memory controller subsystem 58 also couples to the CPU bus controller 38. Memory controller subsystem 58 includes memory controller logic that interfaces to external memory 32. A shell block 54 also couples to memory bus 56 as shown.
Display controller 60 is coupled to memory bus 56 and provides output to NTSC / PAl encoder 36. A
The shell block 54 provides an output to the audio output controller 62, which in turn provides an output to the audio DAC 34. Generally, display controller 60 includes the circuit design used to interface to NTSC / PAl encoder 36.
Similarly, audio output controller 62 includes the circuit design used to interface to audio DAC 34.

As described above, the stream and host interface subsystem 44 includes a PTS table 46,
It includes a control unit 48 and a stream buffer 50. A stream buffer 50 is provided to temporally store the outbound audio / video stream (or PE stream) until the stream can be processed. The stream includes a set of packets, each packet having a header and corresponding data. The header defines the packet as video or audio and gives further information about the video or audio data provided with it according to the compression standard used to provide compression of the data. The control unit 48 controls the allocation and deallocation of space in the stream buffer under the control of the corresponding firmware.

Of particular interest is the presentation time stamp of the header of each packet.
p) The (PTS) field. The PTS indicates the time at which the data contained in the packet is to be displayed (video) or played (audio). The time stamp is
It is measured from a specific base time (usually at the beginning of the sequence of images or sounds to which the packet belongs). For each packet detected in the input stream, control unit 48 makes an entry in PTS table 46. The PTS, type (audio or video) and the offset of the beginning of the heading within the word are stored in the PTS table 46. The PTS table is used to determine which packets should be decoded next by A-shell 54 and V-shell 52.

The memory 32 includes, among other things, a channel buffer
The channel buffer is used to store packets of the combined audio / video stream. Multiple independent audio and video data strea
m) can proceed simultaneously (e.g., multiple windows on a computer screen can simultaneously display different whole motion video sequences). Each independent audio or video data stream is a different channel and is assigned to a different channel buffer. Several channel buffers are shown in FIG. 3 (eg, channel buffers 64A, 64B and 64 in memory 32).
C). The control unit 48 DMAs the packet to the appropriate channel buffer 64 when so instructed by the CPU (running the firmware corresponding to the stream and host interface subsystem 44).
It is configured to perform a transfer. Subsequently, V-shell 52 or A-shell 54 decodes the packet into a format usable for display or playback.

In addition to storing the channel buffer 64, the memory 32 can store firmware corresponding to the integrated circuit 30 for execution. This firmware may be stored permanently in a disk drive in the computer system corresponding to integrated circuit 30, or may be stored in ROM (not shown). As the capabilities of the computer system containing integrated circuit 30 increase, this firmware can be downloaded to memory 32.

Turning now to FIG. 4, a block diagram illustrating the video shell (V-shell) logic 52 is shown. As shown, the Vshell logic 52 has a CPU
It includes a CPU bus interface unit 80 for coupling to the bus 40 (FIG. 3). The CPU bus interface unit 80 is coupled to a macroblock processing core (MB core) 82 and to a video processing core (V core) 84.

The V shell block 52 also includes a memory bus 56
3 includes a memory interface unit 86 for coupling to FIG. The memory interface unit 86 couples through a memory bus to the memory controller subsystem 58, which in turn couples to the external memory 32. A pre-fetch buffer 88 couples to the memory interface unit 86, which in turn couples to provide data to the macroblock processing core. The prefetch buffer 88 is used to store data retrieved from the external memory 32 before being provided to the MB core 82.

As shown, the MB core 82 includes a correction motion vector block (concealment motion vector block).
k) Bind to 90. MB core 82 also couples to reference buffer logic 92, as shown,
The macro block data is given to 92. The MB core 82 performs MPEG decoding of a macroblock in a frame.

Reference buffer logic 92 also couples to receive reference frame data from memory interface unit 86. Reference buffer logic 92 is used to store one or more reference macroblocks used in motion compensation or frame reconstruction.

The V core block 84 is a processing pipeline (process) for performing MPEG video decoding.
ing pipeline). V-core block 84 includes one or more inverse DCT blocks to perform inverse quantization logic and inverse discrete cosine transform. V-core block 84 also includes motion compensation logic for performing motion compensation.

Reference buffer logic 92 also includes a V core block.
84 and the reference frame macroblock data
Give to core block 84. V-core block 84 is coupled to reconstruction buffer logic 94, as shown. In performing the motion compensation logic, the V-core block 84 accesses the reference blocks stored in the reference buffer logic 92 and uses these blocks to reconstruct a temporally compressed frame, Is then stored in the reconstruction buffer logic 94. Reconstruction buffer logic 94 also couples to a memory interface unit 86 for providing reconstructed blocks or frame outs to memory bus 56, whereby the reconstructed frames are displayed for display on a video screen. It may be provided to the display controller 60.

Next, referring to FIG.
A block diagram of one embodiment of is shown. As with the V shell block 52, the A shell block 54 includes a CPU bus interface unit 100 for interfacing with the CPU bus 40.
CPU bus interface unit 100 has input RAM 10
2. Coupling to the audio core (A core) 104 and the audio data buffer 106. A core 104 is further coupled to an input RAM 102 and an output RAM 108. Output RAM 108 provides output to audio output controller 62 and is coupled to memory interface unit 110.
Memory interface unit 110 is used to interface with memory bus 56 and is coupled to audio data buffer 106.

Generally, the compressed audio data is stored in input RAM 102, decoded by A-core 104, and the result is stored in output RAM 108. A core 104 and accompanying core firmware are Dolby A
It supports both C3 audio decoding and MPEG audio decoding. Audio output controller 62 reads data from output RAM 108 to play the results on the speakers. In addition, the contents of the output RAM 108 are stored in the memory interface unit.
It can be stored in memory 12 via 110.

The audio data buffer 106, like the prefetch buffer 88 shown in FIG. 4, is provided for storing data before placing the data in the input RAM 102. The data recently stored in the input RAM 102 is decoded, and the corresponding decoded output is output RAM.
When stored in 108, data is transferred from audio data buffer 106 to input RAM 102. In other words, the audio data buffer 106 is
Helps prevent 102 overruns and underruns.

Turning now to FIG. 6, an exemplary heading structure 120 for the combined audio / video stream.
Is shown. The heading begins with a 24-byte start code prefix 122 that identifies the start of the packet, and a stream ID that identifies the particular stream to which the data corresponding to heading 120 belongs.
Followed by 124. Included is a packet length field 126 where a number of bytes (headings and data) in the packet are encoded. Finally, an optional header field 128 is included, which is shown in an exploded form. Optional heading field 128 is a set of additional optional fields 130
(Shown in exploded form) and optional field 130 includes yet another set of optional fields 132 (also shown in exploded form). A first flag field 134 indicates which of the optional fields 130 are included, and a second flag field 136 indicates an optional field 132.
Indicates which of In optional field 130,
There is a PTS field 138. PTS field 138
Contains the presentation time stamp for the data following the heading 120. Stream and host interface subsystem 44 uses presentation time stamps to synchronize audio and video streams.

The remaining fields shown in FIG. 6 are values defined by either the MPEG compression standard or the Dolby AC3 compression standard, as is well known in the art. The next heading 120 is the data for the packet. MPEG if the data is a video packet
Video headings are included in the data. Similarly, if the data is an audio packet, the data includes an MPEG audio header or a Dolby AC3 audio header.

Referring now to FIGS. 7-13, one of the integrated circuits 30
A shell firmware routine, according to one embodiment,
A flowchart is provided that provides an exemplary flow for a core firmware routine and corresponding hardware. 7 to 10 show a shell firmware routine, and FIGS. 11 to 13 show a core firmware routine. For this embodiment, the system firmware routine corresponding to the integrated circuit is a real-time operating system (rea).
l time operating system). An exemplary real-time operating system is Intel Corpora
IASPOX operating system available from). The API layer corresponding to the integrated circuit 30 releases the stream, plays the stream, pauses the stream,
Includes routines for getting the state of the stream, moving forward or backward a number of frames, stopping the stream, and resuming the stream. Each routine takes a stream identifier argument. Open ro
utine) also has the audio type (AC3 or MPE)
Take a type designator indicating G). The status routine stores the pointer in the status structure (s
tatus structure). The step routine will advance many frames.

FIG. 7 is a flowchart of the operation of the stream and host interface subsystem 44.
The steps performed by the hardware are shown below.

Initially, the stream and host interface subsystem 44 is programmed to detect the start code of heading 120 (step 150). Once programmed, the control unit 48 begins checking the stream received by the stream buffer 50 for the start code of the combined audio / video stream header 120 (step 152). The combined audio / video stream is also called a PE stream (PES). When a start code is detected, the stream and host interface subsystem 44
Updates the status register to indicate that a packet has been detected. The core firmware polls the status register until an indication that a start code has been detected is observed (steps 154 and 156).

Upon detecting the start code, the start code is compared with the start code described in the PTS table 46 (steps 158 and 160). If the start code is not found in the PTS table,
Heading 120 is parsed to locate the TS (step 162). Next, start code and PT
S is stored in the start code table (step 164)
). Steps 166 and 168 are when the start code is PTS
Executed regardless of whether it is found in table 46. In step 166, the firmware programs the stream and host interface 44 to perform a DMA of the received stream to a channel buffer selected by the firmware to store the received stream. In step 168, D
An MA operation is performed. In an embodiment of the present invention,
Steps 152-168 are hardware steps, the other steps are coded in corresponding shell firmware routines.

Referring now to FIG. 8, there is shown a flowchart of the operation of the V shell 52. The steps performed by the hardware are described below.

According to an entry in the PTS table, a packet in one of the video channel buffers is selected for decoding. For example, the video packet with the earliest (ie, numerically smallest) PTS can be selected. MB core 82
Is programmed using the memory address of the packet in memory 32 to be decoded (step 180).
Next, the MB core 82 starts the DMA transfer of the packet from the memory 32 to the prefetch buffer 88 (step 182).
). Once enough data has been read into the prefetch buffer, processing of the packet begins (steps 184 and 186).
). According to one embodiment, the sufficient data is 75
Defined as a prefetch buffer that is% full. It is noted, however, that the definition of sufficient data may vary significantly depending on various factors, including the service time of the DMA controller. Generally, the prefetch buffer 88 has a V
Provided to prevent overruns and underruns of data for core 84. The size of prefetch buffer 88 and the level deemed sufficient may be determined through analysis and simulation.

When enough data has been received in the prefetch buffer, a call is made to the core firmware routine corresponding to Vcore 84 (step 188).
). The core firmware routine decodes the video header portion of the packet (as defined by the MPEG compression standard). Upon decoding the video header, if the quantization matrix is included in the header, then the quantization matrix is stored in V-core 84 (step 190). Specific images (extracted from video headings)
The additional information used to decompress is encoded into the V-core 84 (step 192).
). If a P or B frame is to be decoded,
Reference buffer logic 92 is programmed to detect the image referenced in the P or B frame (step 194). Thereby, when decoded, these frames are stored in a reference buffer.

The reconstruction buffer is programmed to receive the reconstructed image provided by the operation of MB core 82 and V core 84 (step 196). Next, MB core 82 is programmed to start decoding the macroblock in prefetch buffer 88, and the macroblock for the image indicated by the decoded packet is processed by MB core 82 and V core 84. (Steps 198 and 200). MB core 82 may be configured for slicing or processing a sequence of macroblocks at a time. MB core 82 decodes either slices or columns of the macroblock, provides information to V core 84 where the pixels are reconstructed via inverse DCT, and a quantization matrix provided by MB core 82. Applied to the value. Once the processing of the slice or column is complete, the next column or slice of the macroblock is then provided to the MB core 82 (step 202), or once the image is complete, for the next image in the packet to be decoded. Returning to step 180 is performed. In an embodiment of the present invention, steps 182 and 200 are performed in hardware, and the remaining steps are performed in corresponding shell firmware routines.

Referring now to FIG. 9, there is shown a flowchart of the operation of the display controller 60. The steps performed by the hardware are described below. The control registers include the format in which the frames are stored in memory, the number of macroblocks per column and per column of the video display, and
2: 0 to 4: 2: 2 chroma (chroma) / luma (l
uma) Included in display controller 60 to indicate the proposed conversion scheme to the display controller. The control register is programmed in step 210. Two sets of registers are available for storing macroblocks for display. In this way, the display controller 60 can display the contents of one set of registers, while the other set of registers are programmed using subsequent macroblocks. When the display controller 60 has completed displaying the macroblocks stored in a set of registers, the set is indicated to be free for updating with subsequent data. The corresponding firmware switches using a set of registers for the display. Accordingly, the corresponding firmware checks the status of the set of registers to be programmed (steps 212 and 214 for the first set and steps 220 and 222 for the second set, respectively). If the set of registers to be programmed is available, the registers are programmed with the macroblock data to be displayed (steps 216 and 224, respectively). Next, the macroblock data is displayed (steps 218 and
226). In an embodiment of the present invention, steps 218 and 226 are performed in hardware, and the remaining steps are performed in corresponding shell firmware routines.

Referring now to FIG. 10, there is shown a flowchart of the operation of the A shell 54. The steps performed by the hardware are described below.

The next audio packet to be decoded, according to the entry in the PTS table 46,
It is selected from the audio channel buffer in the memory 32.
The packets are read and decoded according to the Dolby AC3 standard or the MPEG standard, via the core firmware corresponding to the A core 104 (whichever standard is used to encode the audio packets) (step 230). . The decoded data is stored in the input RAM 102 (step 232). A control register defining the location and type of the decoded data is programmed (step 234), and a control register indicating that decoding should begin is similarly programmed.

Many types of audio streams are:
It has a higher density of sound in some frequency ranges (or sub-bands) of the audio spectrum than in others. Therefore, the coefficients for performing an inverse DCT or pulse coded modularization (PCM) transform are:
It may differ for different subbands to reproduce the original sound most accurately. Accordingly, the subbands are combined (or reconstructed) separately (step 236). Finally, the reconstructed sound is played (step 238). Once the reconstructed sound has finished playing on the speaker, the next audio packet may be processed (steps 240 and
242). In an embodiment of the present invention, steps 236 and 238 are performed by A shell 54, and the remaining steps are performed in corresponding shell firmware routines.

Turning now to FIG. 11, a flowchart of a core firmware routine for the V-core 84 is shown. The core firmware for Vcore 84 is MPE
Includes a video header parser for the G video stream. The MPEG video heading may include a sequence heading that defines a sequence of subsequent images. The sequence is
Multiple groups of images can be included, each with a group of image (GOP) headings. Finally, each image has a corresponding image header.

In step 250, the sequence header is decoded. MPEG2 sequence headers can include sequence extensions and user-defined extensions. These fields are detected and similarly decoded (steps 252 and 254). Next, the video core firmware routine determines whether a GOP header is detected (step 256). If a GOP header is detected, the GOP header and user data extension (MPEG2) are decoded (steps 258 and 260). The image header is decoded (step 262).
), And the image coding and user extensions are decoded (MPEG2, steps 264 and 266)
). Finally, the image data itself is located
Then, it is given to the MB core 82 / V core 84 (step 268). At the end of the sequence, the video core firmware routine is now complete, and step 25
Return to 0 to decode next sequence. If the sequence is not over, the video core firmware routine returns to step 256 for further decoding (step 270).

FIGS. 12 and 13 depict a core firmware routine that is used with the A-core 104. As described above, A-core 104 provides sub-band synthesis and audio playback functions. The core firmware routine uses Dolby AC3 decoding (FIG. 12) and MP
Give EG decoding (FIG. 13). As those skilled in the art will recognize, steps 280-296 are performed by decoding AC
Steps in 3 audios. Input parameters
298 to 312 are decoded from the header of the audio packet to be decoded. Similarly, step 330 in FIG.
340 includes decoding audio according to the MPEG compression standard (e.g., adaptive pulse code modulation).

In accordance with the above disclosure, there is shown a hierarchical integrated circuit that advantageously utilizes a predesigned core and shell to expedite its development process. A corresponding hierarchical firmware structure is shown that advantageously identifies firmware routines for each level of hardware. By identifying the firmware corresponding to each piece of hardware, firmware reuse is facilitated.

Once the above disclosure has been completely and correctly recognized,
Many variations and modifications will be apparent to those skilled in the art.
It is intended that the appended claims be construed to include all such variations and modifications.

[Brief description of the drawings]

FIG. 1 is a block diagram of a hierarchical integrated circuit.

FIG. 2 is a diagram depicting a hierarchical firmware structure used with the integrated circuit depicted in FIG. 1;

FIG. 3 is a block diagram of one embodiment of an integrated circuit.

FIG. 4 is a view showing one of the V-shell blocks shown in FIG. 3;
4 is a block diagram of one embodiment.

FIG. 5 is a view showing one of A shell blocks shown in FIG. 3;
4 is a block diagram of one embodiment.

FIG. 6 is a diagram depicting a heading structure for a combined audio / video stream.

FIG. 7 is a flowchart depicting firmware operations corresponding to the stream and host interface subsystem shown in FIG. 3;

FIG. 8 is a flowchart illustrating an operation of firmware corresponding to the V-shell block shown in FIG. 3;

FIG. 9 is a flowchart illustrating an operation of firmware corresponding to the display controller shown in FIG. 3;

FIG. 10 is a flowchart illustrating an operation of firmware corresponding to the A-shell block shown in FIG. 3;

FIG. 11 is a flowchart illustrating an operation of firmware corresponding to the V-core block illustrated in FIG. 4;

FIG. 12 is a flowchart depicting firmware operations corresponding to the A core block shown in FIG. 5 when Dolby AC3 audio compression is used.

FIG. 13 is a flowchart depicting firmware computations corresponding to the A core block shown in FIG. 5 when MPEG audio compression is used.

 ──────────────────────────────────────────────────続 き Continuation of front page (72) Inventor Srinivasa R. Maladie United States, California 95135, San Jose, Silverland Drive 3101

Claims (20)

[Claims] A first firmware configured to operate under a first firmware routine based on a first input value to a first core to produce a first defined result.
A second core, based on a second input value to the second core, under the control of a second firmware routine.
A second core configured to produce the defined result of the first core, wherein the first shell is coupled to the first core, wherein the first shell is coupled to a bus; The first shell is configured to provide an interface to the bus under control of a third firmware routine, and wherein the third firmware routine comprises:
A first shell configured to invoke the first firmware routine when the first input value is provided over the bus, thereby producing the first predefined result; and the second shell. A second shell, wherein the second shell is coupled to the bus, and the second shell is connected to the bus under control of a fourth firmware routine. The fourth firmware routine is configured to provide an interface, and wherein the fourth firmware routine is configured to invoke the second firmware routine when the second input value is provided over the bus, whereby the second firmware routine is configured. An integrated circuit including a second shell, wherein the defined result of the second shell occurs. 2. The first shell includes a first set of buffers, wherein the first set of buffers stores the first input value prior to an operation thereon by the first core. 2. The integrated circuit of claim 1, wherein the first set of buffers is further used to store the first defined result. 3. The second shell includes a second set of buffers, wherein the second set of buffers stores the second input value prior to an operation thereon by the second core. 2. The integrated circuit of claim 1, wherein the second set of buffers is further used to store the second defined result. 4. The integrated circuit according to claim 1, wherein said integrated circuit includes an MPEG decoder. 5. The integrated circuit of claim 4, wherein said first shell comprises a video shell, and wherein said first input value comprises an MPEG video stream. 6. The integrated circuit according to claim 5, wherein said first core includes a video core configured to convert said MPEG video stream for display on a video screen. 7. The first shell is coupled to a display controller configured to display an image generated from the MPEG video stream on the video screen, and the first shell is connected to the display controller. 7. The integrated circuit according to claim 6, wherein the integrated circuit is configured to transfer the image. 8. The MPE further comprising the first shell.
7. The integrated circuit of claim 6, including a third core configured to decode macroblocks in the G video stream. 9. The integrated circuit according to claim 4, wherein said second shell comprises an audio shell and said second input value comprises an MPEG audio stream. 10. The integrated circuit of claim 9, wherein said MPEG audio stream is compressed using a Dolby AC3 compression standard. 11. The integrated circuit of claim 9, wherein said MPEG audio stream is compressed using an adaptive pulse code modulation compression standard. 12. The integrated circuit according to claim 9, wherein said second core comprises an audio core configured to convert said MPEG audio stream for playback on a speaker. 13. The audio output controller, wherein the second shell is coupled to an audio output controller configured to transmit sound generated from the MPEG audio stream to the speaker, and wherein the second shell includes the audio output controller. 13. The integrated circuit according to claim 12, wherein said integrated circuit is configured to transfer said sound. 14. Controlling a first shell in the integrated circuit using a first firmware routine; and controlling a first core in the first shell using a second firmware routine. An operation method of an integrated circuit including: 15. The method of claim 14, wherein controlling the first core is initiated by controlling the first shell. 16. The method of claim 1, wherein the first firmware routine calls the second firmware routine.
5. The method according to 5. 17. The method according to claim 17, wherein the first firmware routine and the second firmware routine are executed using a third firmware routine.
17. The method of claim 16, comprising scheduling a firmware routine of. 18. A method for controlling a second shell in the integrated circuit using a fourth firmware routine, and controlling a second core in the second shell using a fifth firmware routine. 15. The method of claim 14, comprising controlling. 19. An integrated circuit comprising a plurality of shells coupled to each other; and a plurality of cores, each of the plurality of cores being included in one of the plurality of shells. The firmware structure used with the integrated circuit is modularized into a plurality of shell firmware routines and a plurality of core firmware routines, each of the plurality of shell firmware routines corresponding to a different one of the plurality of shells, and An integrated circuit wherein each of said plurality of core firmware routines corresponds to a different one of said plurality of cores. 20. The integrated circuit of claim 19, wherein said firmware structure further comprises a system firmware routine used to schedule said plurality of core firmware routines and said plurality of shell firmware routines.