Upgradeable highly integrated embedded CPU system

[0002] The present invention relates generally to embedded central processing unit (CPU) systems and more particularly to a such a system which is upgradeable.

[0003] Embedded central processing unit (CPU) systems are utilized in a variety of applications. For example, a set top box controller is utilized with a television or the like to provide certain functionality and performance to that television. Typically, a set top box includes a set top box controller which utilizes an embedded processor for providing initialization and control and application code execution. Choosing the correct level of processor performance for a set top box controller is a difficult task due to the varying needs of users and applications. It is important that as much of the logic should be integrated to reduce the product cost to the smallest quantity of chips, and the smallest silicon dies for those chips. However, by putting limits on the core performance available on a set top box, limits are placed on the number of applications which can run on the set top box.

[0004] Accordingly, what is desired is a wide range of processor performance solutions from a low end microprocessor using only minimal set up and control to a high end microprocessor implementing a highly interactive set top box. For example, the highly interactive set top box might include web browsing, Java processing, two dimensional (2D) and three dimensional (3D) graphics. Accordingly, while it is desirable to have a single chip implementation at lowest system cost, given the various customer needs, it is also desirable to have a set top box in which the CPU performance is such that it can be adjusted for those various user's needs. In addition, some customers have invested much software development in different processors' architectures.

[0005] Accordingly, it would be desirable to allow those different processor architectures to function with an integrated embedded CPU system, such as a set top box, to ensure a solution is available for customers with alternative CPU architectures. This secondary CPU or CPU alternative should have direct access to key on-chip resources of the embedded CPU system.

[0006] In a preferred embodiment this type of system would be implemented utilizing a multiprocessor architecture to allow for such upgrades.

[0007] To enable such a multiprocessor system to perform efficiently, the following requirements must be met:

[0008] (1) Low latency notification path between multiple processors

[0009] (2) Common memory space for all of the processors

[0010] (3) Minimize external memory fetches for instruction execution

[0011] (4) Direct access to key resources in the embedded processor by a stand alone CPU.

[0012] What is needed, therefore, is an embedded CPU system such as a set top box controller which includes a processor core that can be used in a complementary fashion with higher performing external stand alone processors with minimal glue logic. The stand-alone processor must also have a low latency direct access path to key resources in the embedded CPU system. The product should be cost effective, easy to implement, and adaptable to existing technologies. The present invention addresses such a need.

[0013] A system and method in accordance with the present invention provides for an embedded CPU system which is upgradeable through the use of an external CPU which can be utilized therewith. In a first aspect, the embedded CPU system includes a CPU and a plurality of devices which are accessible by the CPU, via a device control register bus. The embedded CPU system includes logic coupled to the device control register bus for allowing access to the devices within the embedded CPU system by an external CPU.

[0014] In a second aspect, a highly integrated set top box (HISTB) comprises an embedded CPU (EMCPU) subsystem; an MPEG subsystem; a memory subsystem; and a peripheral subsystem. The HISTB includes at least one bus for allowing communication between the EMCPU subsystem, the MPEG subsystem, the memory subsystem and the peripheral subsystem. A device control register (DCR) bus is provided for coupling the EMCPU subsystem, the MPEG subsystem, the memory subsystem. The HISTB also includes logic within the HISTB that allows an external CPU to access the MPEG subsystem and its control register space.

[0015] In a preferred embodiment the present invention provides a highly integrated set top box controller with a processor performance that services the low-end with the added advantage of additional performance with the EMCPU operating as an I/O assist processor to the EXCPU. When the EXCPU operates as the primary processor these two processors serve as a high end set top box controller. A system and method in accordance with the present invention can also preserve much of the software programming model when migrating from a low end processor set top box controller to a higher end solution. A system and method in accordance with the present invention also offers a choice of preserving much of the existing software investment by allowing different processor architectures to function as the EXCPU.

[0016] FIG. 1 is a block diagram of a multiprocessor configuration in accordance with the present invention.

[0017] FIG. 2 is a detailed block diagram of a highly integrated set top box (HISTB) in accordance with the present invention.

[0018] FIG. 3 is a block diagram illustrating the cooperation of the external CPU and an embedded CPU of the HISTB in accordance with the present invention.

[0019] FIG. 4 is a flow chart of the operation of the external CPU and the embedded CPU when obtaining common access to the HISTB register space.

[0020] FIG. 5 provides details of how the data, address and control signals from both the External Memory Bus and the DCR Bus (within the HISTB chip) connect in and around the DCRX.

[0021] FIG. 6 illustrates a complete cycle in the changes of state in the arbitration for the External Memory Bus.

[0022] FIG. 7 illustrates a special case that can occur in the arbitration sequence.

[0023] FIG. 8 illustrates a timing diagram showing the synchronization of signals between the External Memory Bus and the DCR bus during an EXCPU write to a HISTB DCR via the DCRX.

[0024] FIG. 9 illustrates a timing diagram showing the synchronization of signals between the External Memory Bus and the DCR bus during an EXCPU 14 read from a HISTB 12 DCR via the DCRX.

[0025] FIG. 10 is a flow chart illustrating the notification path from the embedded CPU to the external CPU.

[0026] FIG. 11 is a flow chart of the notification path from the external CPU to the embedded CPU.

[0027] The present invention relates to an improvement in embedded CPU systems. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.

[0028] A system and method in accordance with the present invention provides for an embedded CPU system which is upgradeable through the use of an external CPU which can be utilized therewith. The embedded CPU system includes a CPU and a plurality of devices which are accessible by the CPU, via a device control register bus. The embedded CPU system includes logic coupled to the device control register bus for allowing access to the devices within the embedded CPU system by an external CPU.

[0029] To further describe the scope and novelty of the present invention, the present invention will be hereinafter described within the context of a set top box controller. However, one of ordinary skill in the art readily recognizes that the present invention is applicable to any type of embedded processor system wherein there is a need to upgrade the system.

[0030] In accordance with the present invention, a highly integrated set top box (HISTB) controller is provided that includes a low-end Embedded CPU core (EMCPU), for example, a Power PC RISC processor, and the following subsystems: CPU Subsystem, an MPEG Subsystem, a Memory Subsystem and a Peripheral Subsystem.

[0031] In addition, the system can be upgraded using the HISTB controller in conjunction with a higher performance external CPU (EXCPU) such as a Pentium based or K6 processor. Accordingly, high and low performance set top box systems can be provided while utilizing the same core architecture.

[0032] FIG. 1 is a simple block diagram of the multiprocessor configuration 10 in accordance with the present invention. As is seen, there is a highly integrated set top box (HISTB) 12 controller which is in communication with an external CPU (EXCPU) 14 via a bus 16. As is also seen, memory, DRAM and Flash memories 20 and 22 are also accessible by either the HISTB controller 12 or the EXCPU 14. In addition, a SDRAM memory 24 is utilized by the embedded CPU (EMCPU) 26 of the HISTB controller 12.

[0033] As has been indicated, the HISTB controller 12 is a tightly coupled integrated system. FIG. 2 is a detailed block diagram of the HISTB controller 12. As is seen, the HISTB controller 12 includes a CPU subsystem 102 which includes the EMCPU 26 which, in a preferred embodiment, is a low end microprocessor core such as a 401 PowerPC RISC processor. The EMCPU 26 in a preferred embodiment includes a data cache 105 and an instruction cache 109. The CPU subsystem 102 also includes an on-chip memory (OCM) 104 which is in communication with the EMCPU 26. The CPU subsystem 102 also includes an interrupt controller 107 which is in communication with EMCPU 26.

[0034] The HISTB controller 12 also includes an MPEG subsystem 108. The MPEG system 108 includes an MPEG 2 transport demultiplexer 110, an MPEG2 video decoder 112, and an MPEG2 audio decoder 114. As is seen, the MPEG2 video decoder 112 and MPEG2 audio decoder 114 are coupled to the MPEG transport demultiplexer 110 and the processor local bus (PLB)-2 bus 148. As is seen, the MPEG subsystem 108 communicates with audio D/A converter 161, a NIM/descrambler 163, 2D/3D graphics device 165 and a digital encoder decoder (DENC) 167.

[0035] The HISTB controller 12 also includes a memory subsystem 115. The memory subsystem 115 includes a SDRAM memory interface controller 120, a SRAM/DRAM memory interface controller 128, a crossbar switch 124, and a DMA controller 126. As is seen, the crossbar switch 124 is coupled to DRAM/SRAM interface 128 and the SDRAM interface 120.

[0036] Finally, the HISTB controller 12 includes a peripheral subsystem 130. The peripheral subsystem 130 in a preferred embodiment includes general purpose timers 132, a 1284 peripheral device 134, a smart card interface 136, I²C interface 138, a universal asychronous receiver transmitter (UART) 140, a 403 serial port unit (SPU) 142 and a general purpose I/O (GPIO) 144 all coupled to an on chip peripheral (OPB) bus 151.

[0037] The CPU, memory and MPEG subsystems 102, 115 and 108 communicate with each other via PLB buses 146 and 148. The OPB bus 151 allows for communication between the peripheral subsystem 130 and the subsystems 102, and 115 via an OPB bridge 150. A device control register (DCR) bus 152 is provided between devices in the MPEG subsystem 100, CPU subsystem 102 and the memory subsystem 115. In a preferred embodiment, the DCR bus 152 is implemented as a ring in a daisy chained fashion. The DCR bus 152 allows for access to registers within each of the devices to allow for control of each device. In addition the system includes a DCR extension (DCRX) logic 160 which is coupled to SRAM-DRAM interface 128. The function of the DCRX logic 160 will be described in more detail hereinbelow.

[0038] Through the use of the HISTB controller 12, a more tightly coupled set top box controller is provided which is upgradable by coupling an EXCPU thereto as illustrated in FIG. 1. A HISTB controller 12 includes the following features which allow for an efficient, highly integrated upgradable set top box controller. These features are listed below.

[0039] 1. Common Access to HISTB Register Space for EXCPU and EMCPU

[0040] 2. Common Memory Space for Both EMCPU and EXCPU

[0041] 3. Low Latency Notification Path from EXCPU to EMCPU

[0042] 4. Low Latency Notification Path from EMCPU to EXCPU

[0043] 5. On-Chip Memory (OCM) Reducing Memory Accesses Within Common Memory Space

[0044] 6. Staged Power On Reset Mechanism

[0045] 7. Unique CPU Intercommunication Protocol Each of these features will be described in more detail hereinbelow.

[0046] 1. Common Access to HISTB Register Space for EXCPU and EMCPU

[0047] FIG. 3 is a block diagram illustrating the cooperation of the EXCPU 14 and the EMCPU 26 of the HISTB controller 12 for common access to the DCR registers via the DCRX logic 160. FIG. 3 is a simplified version of the block diagram of FIG. 2. This figure illustrates the key devices related to the above-identified feature. As has been before mentioned, DCR registers are within the devices coupled to the DCR bus 152 provided which allows either the EXCPU 24 or the EMCPU 26 to control the devices in the HISTB controller 12. As is also seen control signals are passed through the DCRX logic 160 to allow for either the EMCPU 26 or the EXCPU 14 to control the devices.

[0048] A key element of the present invention is common access to the register space within the HISTB controller 12 by the EMCPU 26 and the EXCPU 14. As has been before mentioned, the DCR bus 152 is coupled to devices in the CPU subsystem 102, MPEG subsystem 108 and the memory subsystem 115 in the HISTB controller 12. Within each of those devices there are DCR registers which allow for control of these devices register by the EMCPU 26 reading and writing to and from these device control registers. In addition, as is seen, there is a DCRX logic that allows for either the EXCPU 14 or the EMCPU 26 to control the operation of the devices within the HISTB controller 12. Control and ownership of the external memory interface is provided through a plurality of arbitration control signals between the shared arbitration logic (not shown) of the external CPU 14 and the SRAM/DRAM memory interface controller 128. The arbitration details will be described in detail later.

[0049] The common access to the DCRX logic 160 control register 159 allows the EXCPU processor 14 to gain access to the entire control register space attached to the DCR bus, and specifically to the MPEG subsystem 108 (FIG. 2). Due to the amount of MPEG driver code exceeding the on-chip storage available, the EXCPU 14 should execute the MPEG subsystem 108 driver code directly from common shared memory. An alternative to this solution would be for the EXCPU 14 executing the MPEG driver code to post requests for writing/reading the on-chip register space via an interrupt to the EMCPU 26. However, the latency associated with servicing the interrupts could cause on-screen display artifacts and slow the response time for a channel change. The code that controls the MPEG subsystem 108 requires minimum change, whether running on the EMCPU 26 or the EXCPU 14. Existing customers invest many man-years in the software to control an MPEG subsystem 108 in a set-top box and large architectural changes are difficult to market to the existing customer base. With a system in accordance with the present invention, the only software difference between EMCPU 26 execution and EXCPU 14 execution is that load, store instructions are used by the EXCPU 14 and move to DCR (MTDCR)/move from DCR (MFDCR) instructions are used for the EMCPU 26 for access to the DCR register spare. The advantages of the EXCPU 14 controlling the MPEG subsystem 108 of the multiprocessor configuration are listed below:

[0050] (1) Reduced latency to MPEG control register access

[0051] (2) Reduces EMCPU code store keeping it in on-chip memory.

[0052] FIG. 4 is a flow chart of the operation of the EXCPU 14 and the EMCPU 26 when obtaining common access to the DCRX logic 160. First, the EXCPU 14 gains control of DCRX logic 160 or memory interface through arbitration, via step 302. Next, the HISTB controller 12 reverses direction of SRAM interface signals to provide a SRAM-like interface, via step 304. Thereafter, the EXCPU 14 reads/writes to address space where HISTB DCR registers are mapped, via step 306. Next, the DCRX logic 160 accesses the DCR register via the internal DCR bus 152 (bypassing EMCPU 26) and completes a memory operation, via step 308. At completion of the memory operation, the HISTB controller 12 rearbitrates for control of interface, via step 310. Finally, EXCPU 14 tri-states the memory interface and HISTB controller 12 regains control in order to access memory, via step 312.

[0053] The more typical implementation of the DCR 152 bus is a single master (EMCPU) and DCR slaves connected in a daisy chained ring. The arbitration circuitry at the beginning of the bus 152 enables either the EMCPU 26 or the EXCPU 14 to be the master.

[0054] While the EMCPU 26 normally receives an ACKknowledge signaling the end of a data transfer, the EXCPU 14 receives the device READY signal from the HISTB controller 12. This is referred to as device paced access. This implementation allows either processor to gain control of the DCR bus 152 at any time. If sharing the DCR bus 152 is required for the system implementation, communication between the EXCPU 14 and EMCPU 26 is required to insure completion of data transfers prior to switching DCR bus 152 master ownership.

[0055] The arbitration sequence for passing control of the DCR logic 160 is described hereinbelow. Assuming the HISTB controller 12 currently has control of the DCR ring 152 and the EXCPU 14 does not currently have any pending memory operations, the states of the arbitration signals shown in FIG. 3 are as follows:

[0056] When the EXCPU 14 needs to gain control of the bus it asserts Bus Req. All other signals remain unchanged.

[0057] When the HISTB controller 12 completes its current operation the HISTB internal arbiter will deassert the HoldReq to the EXCPU 14 indicating that it is no longer being held off the bus.

[0058] The EXCPU 14 responds by deasserting the HoldAck and the BusReq signal.

[0059] When the HISTB controller 12 needs to regain control of the bus it asserts the HoldReq to the EXCPU 14 and indicates the priority of the request via the HoldPri signal.

[0060] The HoldPri is only needed until the EXCPU 14 Acknowledges the HoldReq by asserting HoldAck. The HISTB controller 12 regains control of the memory interface bus.

[0061] FIG. 5 provides details of how the data, address and control signals from an External Memory interface 176 and the DCR bus 152 (within the HISTB chip) are coupled to the DCRX logic 160.

[0062] The arbitration control logic 172 acts independently from the DCRX control logic 173 but the DCRX control logic 173 does use arbitration information in determining the states of the bus control signals. All the External Memory Bus signals and buses are bidirectional so the HISTB 12 may act as both a source and a destination of memory operations, however, only the SRAM/DRAM memory controller 128 drives the Address Out and Address Enable signals and this only occurs during an External Memory operation (the DCRX logic 160 is not involved). In a preferred embodiment, ten bits of the Address In bus are used directly as the 10 bit DCR Address when the DCRX logic 160 is handling a DCR operation.

[0063] The External Memory Bus Data In (32 bits) is driven onto the DCR Data Bus by the CPU 14 when the DCRX logic 160 is performing a DCR Write (also known as Move-To-DCR, i.e., MTDCR). The data returned from the DCR data bus is directed out onto the External Memory Bus Data Out when the DCRX logic 160 is performing a DCR Read (also known as Move-From-DCR, i.e., MFDCR).

[0064] Referring now to the bidirectional I/Os 171, the direction of the Chip Select (CS) from the bidirectional I/Os 171 is determined by a DCRX register bit in DCR control logic 173 at system initialization. This bit is set to allow or disallow DCRX operations to occur. Reprogramming this bit during system operations could result in both processors driving the CS. One of the external processor's Chip Select (CS) signals must be dedicated to accessing the DCR registers on the HISTB 12 so it is not necessary for the DCRX logic 160 to decode any of the bits of the address bus. The importance of this dedicated pin will be described in detail later in the specification. The CS signal will indicate when a memory operation, initiated by the external processor, is targeted for the DCR registers. It will be up to the individual DCR slaves to decode the 10 bits of the Address bus which are passed on as the DCR address.

[0065] The directions of the R/W, OE and Ready lines are all controlled by the DCRX control logic 173 since they must reverse direction only for External Memory bus operations addressing the DCR registers. For those operations these three signals are used to synchronize the interface just as if the HISTB 12 were an SRAM.

[0066] As is seen ADDR EN, ADDR OUT, ADDR IN, CS OUT, R/W OUT, OE OUT, READY IN signals from memory controller 128 have dots connected thereto. BID IR I/Os 171 have similarly the same signals with dots connected thereto. These dots represent connections therebetween without necessarily being connected to or driven by the DCRX logic 160.

[0067] Similarly, DCRX DATA IN, DCRX ADDR and DCRX ACK signals provided from DCRX control logic 173 have on page connectors dots connected thereto. Multiplexer 187 has the DCRX ADDR signal input thereto connected to a dot. Multiplexer 189 has the DCRX DATA IN input thereto connected to a dot. Multiplexer 191 has the DCRX ACK input thereto connected to a dot. These dots represent internal connections within the DCRX logic 160. The select lines of the multiplexers 181, 183, 185, 187, 189 and 191 are controlled by the DCRX Control Logic 173. These multiplexers 181-191 allow both the External Memory Bus 176 and the DCR bus 152 to be taken over by the DCRX logic 160 or the Memory Controller 128 and EMCPU 26 to assume control of those buses and perform as they would if the DCRX logic 160 was not in the system.

[0068] FIG. 6 illustrates a complete cycle in the changes of state in the arbitration for the External Memory Bus. Referring to FIGS. 3 and 6 together the cycle begins with the EMCPU 26 using the bus without a bus request from the EXCPU 14 (state A): When the EXCPU 14 needs access to the Ext Mem bus it raises the EX_BUSREQ and the arbiter immediately responds by raising the HOLDREQ signal to the EMCPU 26 (state B). Some time later, when the EMCPU 26 completes its bus operation, it will relinquish control of the bus by responding to the HOLDREQ by raising HOLDACK and will stop driving the bidirectional data bus, address bus, and control signals. The arbiter will immediately respond by dropping the HOLDREQ to the EXCPU 14 (state D). When the EXCPU 14 is assuming control of the bus it will drop HOLDACK and BUSREQ (state E). States G through J are identical to states B through E except that the roles of the EMCPU 26 and EXCPU 14 are reversed. Note that these states do not necessarily indicate individual cycles of the system clocks and that the EMCPU 26 and the EXCPU 14 are not necessarily even running at the same frequency.

[0069] FIG. 7 illustrates a special case that can occur in the arbitration sequence. When a processor (i.e., EMCPU 26) is giving up control of the bus (raising HOLDACK) it may already have the need to regain control of the bus for another pending operation so it will simultaneously raise BUSREQ with HOLDACK. In this case there are internal controls within the arbiter to make sure that the HOLDREQ to the other processor (ie., EXCPU 14) is held low until that other processor indicates that it is taking control of the bus (dropping HOLDACK) so a deadlock situation does not occur. This is different from the operation of HOLDREQ indicated in states B and G of FIG. 6.

[0070] FIG. 8 illustrates a timing diagram showing the synchronization of signals between the External Memory Bus and the DCR bus during an EXCPU 14 write to a DCR register via the DCRX logic 160.

[0071] FIG. 9 illustrates a timing diagram showing the synchronization of signals between the External Memory Bus and the DCR bus 152 during an EXCPU 14 read from a DCR register via the DCRX 160.

[0072] One of the important features of this implementation is that the number of pins required can be significantly reduced to control the memory interface. For example, if the DCR bus is 32 bits wide the EMCPU 26 requires 32 pins for data in, the MTDCR/MFDCR require 2 bits or 2 pins, the DCR address requires 10 bits or 10 pins, the DCR data out requires another 32 bits or 32 pins, and the DCR acknowledge requires 1 bit or 1 pin. Accordingly, there is a total of 77 bits for the internal memory interface at the input of the EMCPU. This translates into a total of 77 internal pins for the device control register bus. Providing external control of the DCR bus 152 to the EXCPU 14 without sharing I/Os of the memory interface would require a significant number of dedicated chip I/O. The present invention demonstrates the pin savings of the shared memory and register interface.

[0073] At the output of the bidirectional I/Os 171, only 64 bits or pins are required to provide access to both the SRAM/DRAM memory by the EMCPU and allow the EXCPU to access the DCR bus. For example, if the data bus is the same, 32 bits wide, the address is 24 bits wide, the chip select is 5 bits wide, the read write is 1 bit wide, and the output enable is 1 bit wide and the ready is 1 bit wide, a total of 64 pins are needed to allow an external DCR master to control the DCR bus. The number of additional pins required is reduced by dedicating one chip select (CS) for providing access to the DCRX control logic and registers. Accordingly, the CPU 14 can have access to the DCR bus 152 via the memory arbitration and asserting the chip select (CS) pin along with the appropriate SRAM interface signals. Accordingly, by providing a dedicated chip select signal for accessing the DCR registers it is not necessary for the DCRX logic 160 to decode any of the bits of address bus.

[0074] 2. Common Memory Space for Both EMCPU and EXCPU

[0075] Shared memory for both SRAM and DRAM 121 is provided in a glueless fashion between the two processors. This provides a common memory space for both the EXCPU 14 and the EMCPU 26 to pass data back and forth very efficiently. Only a command header and memory pointers need to be passed between the two processors via a memory mailbox (dedicated contiguous section of memory) unique to each processor at agreed upon memory locations in the common memory space. The SRAM/DRAM interface controller 128 in the HISTB controller 12 and the EXCPU 14 both tri-state the memory bus when the bus is requested and allow the requesting device access to the common memory. This arbitration insures that a memory collision is avoided. In a preferred embodiment, pull up resistors on the memory control lines (active low) to insure the transition from HISTB controller 12 driving inactive->tri-state->EXCPU 14 driving inactive and vice versa does not cause a glitch. When DRAM 121 is shared, the memory bus owner (that is both the EXCPU 14 and the HISTB controller 12) should in a preferred embodiment refresh the DRAM 121 to ensure the integrity of the memory contents.

[0076] 3. Low Latency Notification Path from EMCPU to EXCPU

[0077] The low latency notification path from the EMCPU 26 to the EXCPU 14 is needed to insure that real-time critical tasks are dispatched from the EMCPU 26 to the EXCPU 14 as they arise. Significant delays for processing these tasks can cause significant problems. This requirement was met by utilizing the GPIO 144 output as an interrupt input to the EXCPU 14.

[0078] FIG. 10 illustrates a flow chart for execution of the low latency notification path between EMCPU 26 and the EXCPU 14. First, the EMCPU 26 writes to memory mapped register bit in GPIO via step 402, via the execution of a “Store” instruction to the GPIO 144 register. This is accomplished via PLB and OPB Bus data transfer setting the general purpose output. Next the GPIO 144 (FIG. 3) register bit drives HISTB output via step 404. This output is connected to EXCPU 14 external interrupt input. Finally, the EXCPU 14 receives interrupt input, branches to interrupt service routine handling the necessary system task, via step 406.

[0079] 4. Low Latency Notification Path from EXCPU to EMCPU

[0080] The low latency notification path from the EXCPU 14 to the EMCPU 26 is needed to insure that real-time critical tasks are dispatched from the external CPU to the embedded CPU as they arise. Significant delays for processing these tasks can cause significant problems. This requirement was met by providing interrupt generation capability by the EXCPU 14 writing to a bit of a DCRX 160 register space on the HISTB controller 12 that creates an interrupt to the EMCPU 26.

[0081] FIG. 11 is a flow chart of the notification path from the EXCPU 14 to the EMCPU 26. First, the EXCPU 14 gains access to the DCRX logic 160 and writes to the control register 159 via the shared SRAM/DRAM interface controller 128, via step 502. Next, the write to the logic control register 159 causes the assertion of the interrupt signal to the interrupt controller 107, via step 504. Next the interrupt controller 107 then asserts the interrupt input to EMCPU 26, via step 506. Finally, the EMCPU 26 receives the interrupt input, branches to the interrupt service routine handling the necessary system task, via step 508.

[0082] An alternative approach that does not require the EXCPU 14 to gain access, through arbitration, of the common memory space is to use a general purpose output of the EXCPU 14 that drives the HISTB controller's 12 external interrupt input directly.

[0083] 5. On-Chip Memory (OCM) 104 Reducing Memory Fetches for Instruction Execution

[0084] Both OCM 104 instruction cache 105 and data cache 109 provide a significant quantity of instruction and data storage on-chip. Having both the EXCPU 14 and EMCPU 26 fetch data and instructions from a common memory simultaneously is feasible in this system; however, it is anticipated that the inefficiencies of the memory bus arbitration will reduce the performance of the total system. To reduce system costs there is no glue logic required to add the EXCPU 14 external processor. With the addition of some bus transceivers and added system cost it is feasible to isolate the HISTB controller's 12 memory from the EXCPU 14 memory.

[0085] This allows for simultaneous instruction or data fetch from each CPUs isolated memory without collision and reduces the amount of shared/common memory arbitration. If the desired amount of instruction store for the EMCPU 26 exceeds the amount of on-chip instruction storage, the external buffering provides a gateway, enabled only when inter-CPU communication is required.

[0086] Optimum performance in the “glueless” multiprocessor architecture is achieved when the majority of program storage for the embedded processor is executed from the OCM 14 and avoids instruction fetch from shared/common memory. For the HISTB controller 12, the EMCPU 26 and the DMA controller 126 handle all the data management for the peripheral subsystem components to/from the shared/common memory. The EMCPU 26 insures that data transfer to and from the shared memory DRAM 121 is efficient with a maximum amount of burst type traffic and minimum to no instruction memory fetch.

[0087] 6. Staged Power-On Reset Mechanism

[0088] Another issue to be resolved in multiprocessor configuration is the system initialization. If both EXCPU 14 and EMCPU 26 receive a common reset, they would both attempt to fetch shared/common memory at the same time. By holding the HISTB controller 12 (and therefore the EMCPU 26) in reset until the EXCPU 14 was out of reset and initialized, then releasing the reset which had been holding the HISTB's I/O in tri-state, proper memory arbitration is implemented. Each processor 14 and 26 reads the same boot code but executes different branches of the code depending upon the result of the processor identification test. This allows the same ROM (or FLASH) memory to hold a single common boot routine that can service both processors. Control of the HISTB controller 12 reset is done via on-card logic implementing a general purpose I/O function controlled by the EXCPU 14.

[0089] 7. CPU Inter-Communication Software

[0090] The EMCPU 26 in a multiprocessor configuration services all the peripheral subsystem communications. The EMCPU 26 is responsible for all data communications to/from memory and the peripheral subsystem. In effect, the EMCPU 26 becomes an I/O processor for the EXCPU 14. Because the peripheral subsystem can tolerate more system latency than the MPEG subsystem, this is an effective division of labor between the two processors.

[0091] A system and method in accordance with the present invention provides for an embedded CPU system which is upgradeable through the use of an external CPU which can be utilized therewith. The embedded CPU system includes a CPU and a plurality of devices which are accessible by the CPU, via a device control register bus. The embedded CPU system includes logic coupled to the device control register bus for allowing access to the devices within the embedded CPU system by an external CPU.

[0092] In a preferred embodiment the present invention provides a highly integrated set top box controller with a processor performance that services the low-end with the added advantage of additional performance with the EMCPU operating as an I/O assist processor to the EXCPU. When the EXCPU operates as the primary processor these two processors serve as a high end set top box controller. A system and method in accordance with the present invention can also preserve much of the software programming model when migrating from a low end processor set top box controller to a higher end solution. A system and method in accordance with the present invention also offers a choice of preserving much of the existing software investment by allowing different processor architectures to function as the EXCPU.

[0093] Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.