United States Patent [19]
`Lam
`
`US005960464A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,960,464
`Sep. 28, 1999
`
`[54] MEMORY SHARING ARCHITECTURE FOR
`A DECODING IN A COMPUTER SYSTEM
`
`[75] Inventor: Christopher S. Lam, San Jose, Calif.
`
`[73] Assignee: STMicroelectronics, Inc., Carrollton,
`TeX.
`
`Doquilo, J., “Symmetric Multiprocessing Servers: Scaling
`the Performance Wall,” Infoworla', Mar. 27, 1995, pp.
`82—85, 88—92.
`
`Video Electronics Standards Association, “VESA Uni?ed
`Memory Architecture Hardware Speci?cations Proposal,”
`Version: 1.0p, Oct. 31, 1995, 1995, pp. 1—38.
`
`[21] Appl. No.: 08/701,890
`[22]
`Filed:
`Aug. 23, 1996
`
`[51] Int. Cl.6 .................................................... .. G06F 12/10
`[52] US. Cl. ............................................................ .. 711/206
`[58] Field of Search ................................... .. 711/202, 203,
`711/206, 207; 395/846; 710/22
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,263,142 11/1993 Watkins et a1. ....................... .. 395/842
`5,301,287
`4/1994 Herrellet al.
`711/202
`5,459,519 10/1995 Scalise et al. ........................ .. 348/431
`
`FOREIGN PATENT DOCUMENTS
`
`0 673 171 A2 9/1995 European Pat. Off. .
`
`OTHER PUBLICATIONS
`
`Bheda, H. and P. Srinivasan, “A High—Performance Cross—
`Platform MPEG Decoder,” Digital Video Compression on
`Personal Computers: Algorithms and Technologies, vol.
`2187, Feb. 7—8, 1994, pp. 241,248.
`Bursky, D., “Highly Integrated Controller Eases MPEG—1
`Adoption,” Electronic Design, vol. 43, No. 17, Aug. 21,
`1995, pp. 141—142.
`Galbi, D. et al., “An MPEG—1 Audio/Video Decoder With
`Run—Length Compressed Antialiased Video Overlays,”
`1995 IEEE International Solid—State Circuits Conference,
`pp. 286—287, 381.
`Maturi, G., “Single Chip MPEG Audio Decoder,” IEEE
`Transactions on Consumer Electronics, vol. 38, No. 3, Aug.
`1992, pp. 348—356.
`Butler, B. and T. Mace, “The Great Leap Forward,” PC
`Magazine, Oct. 11, 1994, pp. 241—244, 246, 248, 250,
`253—254, 256, 260—261, 264, 266—268, 273—275, 278.
`
`(List continued on neXt page.)
`
`Primary Examiner—Eddie P. Chan
`Assistant Examiner—Kevin L Ellis
`Attorney, Agent, or Firm—David V. Carlson; Theodore E.
`Galanthay; Lisa K. Jorgenson
`
`[57]
`
`ABSTRACT
`
`A method and apparatus employing a memory management
`system that can be used With applications requiring a large
`contiguous block of memory, such as video decompression
`techniques (e.g., MPEG 2 decoding). The system operates
`With a computer and the computer’s operating system to
`request and employ approximately 500 4-kilobyte pages in
`tWo or more noncontiguous blocks of the main memory to
`construct a contiguous 2-megabyte block of memory. The
`system can employ, on a single chip, a direct memory access
`engine, a microcontroller, a small block of optional memory,
`and a video decoder circuit. The microcontroller retains the
`blocks of multiple pages of the main memory, and the page
`descriptors of these blocks, so as to lock doWn these blocks
`of memory and prohibit the operating system or other
`applications from using them. The microcontroller requests
`the page descriptors for each of the blocks, and programs a
`lookup table or memory mapping system in the on-chip
`memory to form a contiguous block of memory. As a result,
`the video decoder circuit can perform operations on a
`2-megabyte contiguous block of memory, Where the micro
`controller employs the lookup table to translate each
`2-megabyte contiguous address requested by the video
`decoder circuit to its appropriate page in the main memory.
`As soon as the video decoding operations are complete, the
`microcontroller releases the blocks of multiple pages of
`memory back for use by the computer.
`
`40 Claims, 3 Drawing Sheets
`
`[/54
`
`USER
`INTERFACE
`
`WINDOWS 95
`
`I52
`
`I58
`
`152
`
`I56
`
`DVD DRIVER
`
`DVD INFORMATION
`FILE MANAGER
`
`AUDIO DRIVER
`
`7/5
`
`VIDEO OBJECTS MANAGER \
`/59
`
`VIDEO DRIVER
`
`150/ @ I70
`
`Apple Inc. v. Parthenon
`Ex. 1001 / Page 1 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 1
`
`

`
`5,960,464
`Page 2
`
`OTHER PUBLICATIONS
`
`Video Electronics Standards Association, “VESA Uni?ed
`Mernory
`Architecture VESA BIOS
`Extensions
`(VUMA—SBE) Proposal,” Version: 1.0p, Nov. 1, 1995, pp.
`1—26.
`
`Giorgis, T., “SMP Network Operating Systems,” Computer
`Dealer News, Aug. 8, 1996, pp. 42, 43.
`King, A., Inside Windows 95, Microsoft Press, Redrnond,
`Washington, 1994, pp. 85—90.
`“MPEG Video Overview,” SGS—Thomson Microelectronics
`Technical Note, Apr. 1992, pp. 1—4.
`
`Ex. 1001 / Page 2 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 2
`
`

`
`U.S. Patent
`
`Sep.28, 1999
`
`Sheet 1 of3
`
`5,960,464
`
`/02
`
`I08
`
`706
`
`
`
`MNN
`MEMORY
`
`
`
`
`
`G2
`
`
`MPEDECODER
`
`\\/O0
`
`‘
`Q30
`
`—:
`
`I I I
`
`I L
`
`\
`
`'
`:
`I
`
`I I I
`
`:
`
`{ I
`
`Fig. 1
`
`/24
`
`/20
`
`
`
`
`MEMORY
`WCR0
`(OPHONAL)
`_C_O_N_T_|ROLLER
`
`
`MMU'
`
`
`
`
`
`vIDEO
`DECOD|NG
`CIRCUIT
`
`
`
`
`DECODING
`CIRCUIT
`
`
`
`/29
`
`I
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 3
`
`Ex. 1001 /Page 3 of11
`
`Ex. 1001 / Page 3 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 3
`
`

`
`U.S. Patent
`
`Sep.28, 1999
`
`Sheet 2 0f 3
`
`5,960,464
`
`r154
`
`USER
`INTERFACE
`
`I52 /
`
`WINDOWS 95
`
`I
`
`158
`
`v
`
`[762
`
`DVD DRIVER
`
`DVD INFORMATION
`FILE MANAGER
`
`‘
`' AUDIO DRIVER
`
`I73
`
`VIDEO OBJECTS MANAGER-v59
`
`150 /
`
`II
`SOUND
`
`II
`VIDEO DR|VER_
`
`I
`DISPLAY
`
`I70
`
`Fig. 3
`
`Ex. 1001 / Page 4 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 4
`
`

`
`U.S. Patent
`
`Sep.28, 1999
`
`Sheet 3 of3
`
`5,960,464
`
`START THE
`WINDOWS APPLICATION
`
`I
`
`f204
`
`LOCK DOWN
`ZMBIT OF MEMORY
`
`I
`
`PROGRAM THE
`DESCRIPTORS IN
`THE MPEG CHIP
`
`RELEASE THE
`MEMORY
`
`Hg. 4
`
`Ex. 1001 / Page 5 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 5
`
`

`
`1
`MEMORY SHARING ARCHITECTURE FOR
`A DECODING IN A COMPUTER SYSTEM
`
`5,960,464
`
`2
`Current computers, such as personal computers, employ
`graphics or video accelerator cards that permit the computer
`to rapidly display static images. Personal computers are
`typically unable to decompress and display video images
`because the decompression or decoding routines typically
`require substantial processor overhead. For example, the
`MPEG 2 standard decodes 720 pixels per line and 576 lines
`per frame for a single image, and approximately 30 frames
`per second. As is knoWn, each frame is divided into a series
`of 16 pixel by 16 pixel macroblocks, so that for each second,
`the processor must decode 48,600 macroblocks per second.
`Consequently, the time interval betWeen decoding each
`macroblock is approximately 2.0576 microseconds. If a
`CPU in the PC is running at 100 megahertZ, then only 2,057
`clock cycles are available betWeen decoding of each mac
`roblock. This is an inadequate number of clock cycles to
`decode a given macroblock given the complexity of the
`decoding function under the MPEG 2 standard.
`As a result, chip sets have been developed that employ a
`dedicated microcontroller, a MPEG 2 decompression chip,
`and a large amount (e.g., 2 megabytes) of memory, such as
`DRAM. Such chip sets can be expensive, particularly since
`they require 2 megabytes of DRAM. Thus, it Would be
`desirable to employ the main memory of the computer,
`Which typically has over 8 megabytes of DRAM.
`Some applications exist that share the main memory. For
`example, the symmetrical multiprocessor environment
`(SMP) by Intel employs tWo or more identical processors
`that each access the same block of main memory. HoWever,
`each of the microprocessors employs a memory manage
`ment unit (MMU) that has an identical memory mapping
`table. Neither microprocessor can permanently allocate a
`portion of the main memory. Instead, as soon as one of the
`microprocessors no longer employs a portion of the memory,
`and the address of that memory is removed from its memory
`map, then the other microprocessor is free to use that portion
`of memory. Additionally, the SMP environment requires a
`speci?c operating system.
`Another knoWn method of sharing main memory is
`employed With graphics accelerators in personal computers.
`Previously, graphics or video accelerator cards included
`on-board memory chips. HoWever, under the Video Elec
`tronics Standards Association (VESA), a VESA uni?ed
`memory architecture (VUMA) standard has been developed.
`Under this standard, video accelerators can share main
`memory With the computer to thereby eliminate the need for
`on-board memory for the graphics accelerator. During boot
`up of the computer system employing the video accelerator,
`the video accelerator Will cause the basic input/output
`instructions (BIOS) of the computer to reserve a large
`portion of contiguous memory in the main memory, and
`prohibit the operating system or other applications from
`accessing or employing that memory.
`HoWever, typical operating systems such as WindoWs
`95®, manufactured by Microsoft Corporation, do not permit
`large blocks of memory to be permanently allocated for a
`given application or operation after booting up the computer.
`Instead, WindoWs 95 dynamically allocates memory to an
`application based on the need of that application. As soon as
`the application no longer uses the memory, WindoWs 95
`allocates that memory to another application. Moreover,
`MPEG 2 decoding requires 2 megabytes of contiguous
`memory. WindoWs 95 allocates small blocks of memory
`(typically “pages” of 4 kilobytes each) that are scattered
`throughout the main memory.
`SUMMARY OF THE INVENTION
`One solution the inventor has developed Would be to
`initialiZe the computer during the boot-up process to reserve
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application relates to the following US. Patent
`Applications: “VIDEO AND/OR AUDIO DECOMPRES
`SION AND/OR COMPRESSION DEVICE THAT
`SHARESAMEMORY INTERFACE” (US. Pat. No. 5,812,
`789 issued on Sep. 22, 1998) and “VIDEO AND/OR
`AUDIO DECOMPRESSION AND/OR COMPRESSION
`DEVICE THAT SHARES A MEMORY” (US. application
`Ser. No. 08/702,910)[, and “MPEG DECODER TO BE
`USED IN A MICROCOMPUTER” (Attorney’s Docket No.
`95-GR2-041), all] ?led concurrently hereWith.
`
`10
`
`15
`
`TECHNICAL FIELD
`
`The present invention relates to the ?eld of electronic
`systems requiring blocks of memory, and is more speci?
`cally directed to systems employing decompression devices,
`such as audio and/or video decompression.
`
`20
`
`BACKGROUND OF THE INVENTION
`
`25
`
`In the past, moving images Were transmitted via analog
`signals, such as television signals. To improve signal to
`noise ratio and improve security, While also potentially
`providing additional signals over a given channel, moving
`images are digitiZed and transferred digitally. The siZe of a
`digital representation of moving images (i.e., video) is
`dependent on the resolution of the image. If a display device,
`such as a CRT, has a resolution of 1024x768 picture ele
`ments (pels or pixels), Where each pixel can have an 8-bit
`color value, one image requires approximately % of a
`megabyte of memory. At a minimum, 30 images must be
`displayed per second, thereby requiring over 22 megabytes
`of memory per second. A typical 90-minute movie Would
`thus require nearly 120 gigabytes of memory.
`As a result of such need for memory to store a typical
`movie, digitiZed video is compressed using various digital
`compression techniques. One such technique for compress
`ing video is the Digicypher II system by General Instru
`ments. Such a system alloWs for compressed video and
`audio images to be transmitted over high bandWidth chan
`nels such as satellite transmission. Other knoWn techniques
`for encoding/decoding video images include the Motion
`Picture Expert Group (MPEG) techniques MPEG 1 and
`MPEG 2. Current encoding/decoding standards for video
`telephony include the H.261 and H.263 standards.
`Many of the compression/decompression standards
`employ the knoWn discrete cosine transfer algorithm (DCT).
`The MPEG 1, MPEG 2, H.261 and H.263 standards are
`decompression protocols that describe hoW an encoded bit
`stream is to be decoded. As a result, the video can be
`encoded in any manner, as long as the resulting bit stream
`complies With the particular standard.
`Once encoded, the images can be decoded and displayed
`on an electronic system dedicated to displaying video and
`audio, such as a television or digital video disk (DVD)
`player, or on electronic systems Where displaying images are
`just one of the features of the system, such as a computer. A
`given electronic system must include an appropriate decoder
`to alloW it to display digital sequences of images com
`pressed under one of the above standards, assuming the
`original video Was compressed using an encoder under that
`standard.
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`Ex. 1001 / Page 6 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 6
`
`

`
`5,960,464
`
`3
`a 2 megabyte portion of contiguous memory, as is performed
`With video accelerators under the VUMA standard. Such an
`allocation of memory, hoWever, is aWkWard, and therefore
`undesirable by users. Additionally, such a solution Would
`prohibit “on-the-?y” display of video information on the
`computer. Instead, the computer must be rebooted Whenever
`the computer Wishes to use the 2 megabyte portion for other
`applications.
`The present invention solves problems inherent in the
`prior art and in the inventor’s above solution, and provides
`additional advantages, by employing a memory manage
`ment system that operates With the computer and its oper
`ating system (e.g., WindoWs 95) to request and employ
`approximately 500 4-kilobyte pages of the main memory,
`some of Which are in noncontiguous blocks of pages, to
`construct a single contiguous 2-megabyte block of memory.
`The system retains the multiple pages of memory, and their
`page descriptors, so as to lock doWn these portions of
`memory and prohibit the operating system or other appli
`cations from using them. The memory management system
`can be employed on a single chip having a direct memory
`access (DMA) engine, a microcontroller, a small block of
`memory (optional), and a video decoder circuit (e.g., an
`MPEG 2 decoder circuit).
`The microcontroller, performing a WindoWs 95 memory
`allocation application, requests the page descriptors for each
`block of 4-kilobyte pages. Each of the page descriptors is
`then stored in the form of a lookup table in the on-chip
`memory to form a contiguous block of memory. As a result,
`the video decoder circuit can perform operations on What
`appears to be a 2-megabyte continuous block of main
`memory, Where the microcontroller employs the lookup
`table to translate one of the 2-megabyte contiguous
`addresses to its appropriate page in the main memory. As
`soon as the video decoding operations are complete, the
`microcontroller releases the multiple pages of memory back
`to the computer.
`Broadly stated, the present invention embodies a control
`circuit for use in a computer system. The computer system
`is controlled by an operating system and has a main memory.
`An electronic device is coupled to the processor and the
`main memory and is con?gured to request continuous use of
`several portions of the main memory from the operating
`system. The memory portions can have noncontiguous
`addresses. The control circuit is also con?gured to translate
`the noncontiguous addresses to contiguous addresses of a
`block of memory, Wherein the control circuit permits access
`to the portions of the main memory as the block of memory
`based on the contiguous addresses.
`Broadly stated, the present invention also embodies a
`memory management method for use With the computer
`system. The memory management method includes the steps
`of: (a) requesting continuous use of several portions of the
`main memory from the operating system, the portions of the
`main memory having noncontiguous addresses; (b) receiv
`ing requests for access to a block of memory, the block of
`memory having contiguous addresses; and (c) translating the
`contiguous addresses to the noncontiguous addresses.
`Overall, the present invention is applicable to any appli
`cation requiring a large block of contiguous memory, not
`necessarily video decoding. Other features and associated
`advantages of the present invention Will become apparent
`from studying the folloWing detailed description, together
`With the accompanying draWings.
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a computer system having an
`MPEG 2 decoder under the present invention.
`
`4
`FIG. 2 is a block diagram of the MPEG 2 decoder of FIG.
`1.
`FIG. 3 is a block diagram of softWare elements employed
`by the computer system of FIG. 1.
`FIG. 4 is a ?oWchart of a routine performed by the MPEG
`2 decoder of FIG. 1.
`
`DETAILED DESCRIPTION OF THE
`PRESENTLY PREFERRED EMBODIMENT
`Referring to FIG. 1, a computer system 100 under the
`present invention includes a computer 102, such as a con
`ventional personal computer (PC). The computer 102
`includes a central processing unit (CPU) 104, Which can be
`an X86 based microprocessor. The CPU 104 communicates
`With a large block of main memory 106 through a memory
`controller 108. As Will be understood beloW, the main
`memory 106 should include at least approximately 4 mega
`bytes of memory (typically random access memory
`A visual display device, such as a CRT 110, displays
`output produced by the computer 102. A digital video disk
`(DVD) compact disk-read only memory (CD-ROM) player
`112, coupled to the computer 102, plays back video images
`to the computer from a DVD CD-ROM disk 113, Which can
`be displayed on the CRT 110. The DVD CD-ROM disk 113
`is a super-density disk that can hold up to 18 gigabytes of
`audio, video and other types of data (eg., menus in various
`languages, sub-pictures, graphics, etc.). Speci?cally, the
`DVD CD-ROM player 112 retrieves video images that have
`been compressed under knoWn video compression tech
`niques such as the MPEG 2 technique.
`An MPEG 2 decoder 114, coupled to the computer 102,
`decodes the compressed video images from the DVD
`CD-ROM player 112 to reconstruct the original, uncom
`pressed video images so that they can be displayed on the
`CRT 110. The DVD CD-ROM player 112 can also provide
`compressed audio sequences Which the MPEG 2 decoder
`114 decodes using knoWn audio decompression techniques
`(e.g., Dolby AC-3). The computer system 100 of FIG. 1 can
`also contain other peripherals and elements, not shoWn, such
`as a hard disk drive, tape drive, input devices such as a
`keyboard or mouse, etc.
`Referring to FIG. 2, the MPEG 2 decoder 114 is shoWn in
`greater detail. A microcontroller 120 having a memory
`management unit 122 (MMU) operates under a routine
`described beloW to decode audio and video from the DVD
`CD-ROM player 112. A direct memory access (DMA)
`engine 124 coupled betWeen the microcontroller 120 and the
`computer 102 alloWs the microcontroller to directly access
`the main memory 106, Without employing the CPU 104. The
`DMA engine 124 can form part of a video module interface
`(VMI). The DMA engine 124 and VMIinterfaces are
`conventional, and are not described in detail herein for
`purposes of brevity and so as not to obscure the detailed
`description of the present invention.
`A video decoding circuit 126, coupled to the microcon
`troller 120, decodes or decompresses the video images
`stored on the DVD CD-ROM disk 113 in the DVD
`CD-ROM player 112. Preferably, the video decoding circuit
`126 employs conventional MPEG 2 decoding techniques.
`Alternatively, or in addition, the video decoding circuit 126
`can decode video images compressed under the MPEG 1,
`JPEG, H.261, or other knoWn video compression tech
`niques. In general, the MPEG compression standard is
`described in SGS-Thomson Microelectronics, Technical
`Note, MPEG Video OvervieW, April 1992.
`An audio decoding circuit 128 similarly decodes audio
`compressed on the DVD CD-ROM disk 113 in the DVD
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`Ex. 1001 / Page 7 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 7
`
`

`
`5,960,464
`
`5
`CD-ROM player 112. The audio decoding circuit 128 pref
`erably employs known audio decoding techniques, such as
`the Dolby AC-3technique. The video decoding circuit 126
`and audio decoding circuit 128 are of conventional
`construction, and are not described in detail herein for
`purposes of brevity and so as not to obscure the detailed
`description of the present invention.
`An optional memory 129, coupled to the microcontroller
`120, provides storage for a lookup table or memory map, as
`described beloW. The microcontroller 120, DMA engine
`124, video decoding circuit 126, audio decoding circuit 128,
`and memory 129 can be monolithically integrated as a single
`chip 130 for use With or in the computer system 100.
`Referring to FIG. 3, the computer 102 preferably operates
`under the conventional WindoWs 95 operating system 152.
`A user interface 154, forming a high-level part of the
`WindoWs 95 operating system 152, provides an interface to
`a user of the computer system 100. The WindoWs 95
`operating system 152 provides services for the user interface
`154 and “hooks” for all drivers to permit operation there
`With. Execution process of drivers and other application
`programs start from the user interface 154. Upon request by
`such programs, a ?rst menu appears to the user on the CRT
`110, alloWing the user to select menu items to initiate
`sequences of events performed by the application, such as
`initiating vieWing of a movie stored on the DVD D-ROM
`disk 113.
`A DVD driver 156 employs the hooks of the operating,
`system 152 and routes data from the DVD CD-ROM disk
`113 to a DVD information ?le manager 158 and video
`objects manager 159. In general, there are tWo basic levels
`of data structures on the DVD CD-ROM disk 113, a volume
`information ?le Which keeps track of the physical locations
`of loWer level data structures, and video objects Which
`contain data packets for all types of data. Physical locations
`of data on the DVD CD-ROM disk 113 are provided in terms
`of sectors, each being 2048 bytes long. The DVD driver 156
`essentially performs the task of reading data from the DVD
`CD-ROM disk 113. The DVD information ?le manager 158
`provides the DVD driver 156 With a physical disk location
`and a length of data. The DVD driver 156, in turn, transfers
`the requested data from the DVD CD-ROM disk 113 to a
`knoWn location in the main memory 106, as described
`beloW.
`The DVD information ?le manager 158 reads the volume
`information ?le from the DVD CD-ROM disk 113 to
`determine the physical locations of video titles, menu titles
`for each language, title attributes, etc. that are stored on the
`disk. In general, the DVD information ?le manager 158
`controls the playback of video from the DVD CD-ROM disk
`113 by requesting data therefrom through the DVD driver
`156, and sending the data to the video objects manager 159
`for display on the CRT 110. Once a user makes a selection
`through the user interface 154, the DVD information ?le
`manager 158 looks up the location of the appropriate video
`information from the volume information ?le. The DVD
`information ?le manager 158 continuously reads the video
`objects from the DVD CD-ROM disk 113 and sends the
`objects to the video objects manager 159. The data transfer
`rate changes according to the bit rate needed for the display
`of the particular video images. In other Words, the DVD
`information ?le manager 158 is an upper level traf?c con
`troller that recogniZes the type of data that is read from the
`DVD CD-ROM disk 113. Based on the type of data, the
`DVD information ?le manager 158 either processes user
`input from the user interface 154, or plays or pauses video
`and audio from the DVD CD-ROM disk 113.
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`The video objects manager 159 is a loWer level traf?c
`controller responsible for the parsing of different packets of
`video, and time synchroniZation for video and audio “lip
`synching.” Each video object contains video, audio, sub
`picture data, and other data as appropriate. The video and
`audio packets contain MPEG 2 elementary video stream and
`system information, i.e., presentation time stamps, scram
`bling control, clock data, etc., as is knoWn in the MPEG 2
`standard. The video objects manager 159 parses the packets
`and provides appropriate synchroniZation. The video objects
`manager 159 routes the video packets to a video driver 160,
`and routes the audio packets to an audio driver 162. In sum,
`the video objects manager 159 is a system coordinator. As
`long as the video objects manager 159 obtains data from the
`DVD driver 156, it routes the data to the appropriate video
`and audio drivers 160 and 162.
`The video driver 160 decodes the video under the MPEG
`2 technique. LikeWise the audio driver 162 decodes the
`audio packets under the Dolby AC-3technique, or other
`techniques. The video driver 160 and audio driver 162 can
`be implemented as a combination of both hardWare and
`softWare elements. The video driver 160 outputs video to the
`CRT 110, While the audio driver 162 outputs sound to a
`speaker (not shoWn).
`In operation, the DVD information ?le manager 158
`retrieves menu data from the DVD CD-ROM disk 113,
`through the DVD driver 156, to display a menu through the
`user interface 154 on the CRT 110. Auser inputs a request,
`Which is received by the DVD information ?le manager 158
`that in response thereto, allocates a location and number of
`sectors on the DVD CD-ROM disk 113 and requests the
`appropriate information from the DVD driver 156. The
`DVD driver 156 then reads the appropriate information from
`the DVD CD-ROM disk 113 and transfers the video objects
`data, and/or other data, to the DVD information ?le manager
`158.
`The video objects manager 159 parses the video objects
`into video, audio, sub-picture and other data packets. The
`video objects manager 159 transfers the video and audio
`packets to the video and audio drivers 160 and 162,
`respectively, under synchronism according to time stamps.
`The video driver 160 then employs knoWn MPEG 2 decod
`ing techniques to decode the video and display it on the CRT
`110. Similarly, the audio driver 162 employs knoWn Dolby
`AC-3techniques to decode the audio packets and play them
`back over the speaker. The decoding of audio and video
`continues until a break occurs, or the user interrupts the
`process by a user command to the user interface 154.
`Importantly, the MPEG 2 decoding technique, performed
`at least in part by the video driver 160, requires 2 megabytes
`of memory because of temporal compression employed by
`the technique to compress information and eliminate redun
`dancy therein. The MPEG 2 encoding technique refers to
`previous and future pictures to encode a current picture. As
`a result, the MPEG 2 decoding technique must refer to
`previous and future pictures to decode a current picture.
`Thus, the MPEG 2 technique must store at least tWo images
`(past and future) to generate a current image. While prior
`MPEG 2 decoding circuits employed dedicated memory, the
`present invention shares the main memory 108 With the
`computer 102.
`Referring to FIG. 4, a memory sharing routine 200
`performed by the microcontroller 120 (FIG. 2) operates With
`the WindoWs 95 operating system 152 (FIG. 3) to request a
`2-megabyte portion of the main memory 106. The routine
`200 can form part of the DVD information ?le manager 158
`
`Ex. 1001 / Page 8 of 11
`
`Petitioners HTC Corp. & HTC America, Inc. - Ex. 1001, p. 8
`
`

`
`5,960,464
`
`7
`(FIG. 3). In step 202, the microcontroller 120 initiates the
`routine 200 as a Windows 95 -based application. Therefore,
`the microcontroller 120 interacts With the WindoWs 95
`operating system 152 as a neW executable application. In
`step 104, the microcontroller 120 requests from the Win
`doWs 95 operating system 152, 2 megabytes of the main
`memory 106. As is knoWn, X86 microprocessors deal With
`physical memory in pages, each page being 4 kilobytes in
`siZe. Under step 204, the microcontroller 120 makes a loW
`level ring Zero function call to the WindoWs 95 operating
`system 152 to request 2 megabytes (500 total pages) of the
`main memory 106, some of Which Will be in the form of
`noncontiguous pages. The ring, Zero function call under the
`WindoWs 95 operating system 152 provides contiguous
`blocks of memory based on such a call or request.
`Therefore, the microcontroller 120 preferably initially
`requests a 2-megabyte block of the main memory 106 under
`a ?rst iteration of the ring Zero function call. If such a large
`block of memory is unavailable and the WindoWs 95 oper
`ating system 152 provides such an indication to the micro
`controller 120, the microcontroller performs at least tWo
`more ring Zero function calls to request, for example, tWo
`1-megabyte block of contiguous memory. The process
`repeats under step 204, Where if tWo 1-megabyte blocks are
`unavailable, the microcontroller 120 requests four 500
`kilobyte contiguous blocks of the main memory 106 under
`four ring Zero function calls to the WindoWs 95 operating
`system 152. The blocks, of course, can be of varying siZe.
`In step 204, microcontroller 120 also requests, and
`receives from the WindoWs 95 operating system 152, point
`ers or page descriptors that correspond to memory locations
`for the blocks of memory, Where the blocks have a total of
`500 pages of physical memory in the main memory 106.
`Importantly, the routine 200 indicates to the WindoWs 95
`operating system 152 that the routine is actively using the
`500 pages of memory. As a result, the routine 200 locks
`doWn and prohibits the WindoWs 95 operating system 152
`from using or allocating any of these pages to other appli
`cations.
`In step 206, the microcontroller 120 programs a lookup
`table based on the page descriptors of the blocks of the 500
`pages of memory. As noted above, the MPEG 2 decoding
`technique requires 2 megabytes of contiguous memory.
`Since the WindoWs 95 operating system 152 has provided
`500 pages of memory, most of Which Will not be contiguous,
`the microcontroller 120 programs or creates a lookup table
`to translate or map the 500 pages to a contiguous string of
`memory locations beginning at a set address and increasing
`contiguously therefrom to an address 2 megabytes later (the
`“2 megabyte contiguous addresses”).
`As is knoWn, page descriptors typically include an offset
`address and a page siZe that correspond to a starting address
`of a block of contiguous pages, and the number of pages in
`the block. Therefore, the lookup table need not store 2
`megabytes Worth of addresses to map each byte of the
`contiguous block to a byte in the main memory 106. Instead,
`in a Worst case scenario, only 500 of such addresses are
`required, each corresponding to one of the 500 pages.
`HoWever, if the WindoWs 95 operating system 152 provides
`tWo 1 megabyte blocks of the main memory 106 (the tWo
`blocks being contiguous Within themselves), then the lookup
`table need only provide the equivalent of tWo addresses for
`each of the 1 megabyte blocks. Moreover, if 64-bit or double
`Word addresses are employed by the computer system 100,
`then only the more signi?cant bits or bytes must be trans
`lated or mapped under step 206. The least signi?cant bits or
`bytes correspond to contiguous addresses Within one or
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`8
`more pages, as is knoWn in the art. As a result, a much
`smaller amount of memory is required for the lookup table
`than addresses for each 2-megabyte contiguous addresses.
`To further limit the amount of memory needed to perform
`the routine 200, the routine can be con?gured to limit the
`smallest contiguous memory block siZe, and thereby limit
`the siZe of the lookup table created in step 206. For example,
`if the WindoWs 95 operating system provided the smallest
`blocks of memory as only blocks of tWo pages each (250
`blocks of the main memory 106), the routine 200 can
`provide an indication to the user over the CRT 110, through
`the user interface 154, that one or more applications must be
`closed on the computer system 100 in order to free up larger
`blocks of the main memory.
`The lookup table can be programmed into the memory
`129 (FIG. 2). Alternatively, the memory 129 can be omitted,
`and instead, the memory management unit 122 can be
`programmed to rapidly perform such memory mapping of
`the noncontiguous page descriptors to the contiguous string
`of 2-megabyte addresses. Under such an alternative, the
`memory management unit 122 algorithmically maps a con
`tiguous address to a n