Picking the right MPSoC-based video architecture: Part 3

Multimedia SoCs frequently house multiple processor cores that share the task of running the operating system and controlling the critical and noncritical on-chip functional-unit resources.

In this context, an efficient bus architecture and arbitration (for reducing contention) play important roles in maximizing system performance. Besides, for many applications, the performance of multiprocessor systems relies heavily on an efficient communication between the processors and a balanced load distribution (of computing tasks) among them.

With multiple CPUs and a plethora of functional units, on-chip communication poses a critical design problem that is often solved using multilevel hierarchical busses connected via local bridges, the bridges primarily serving as protocol converters between different bus systems and/or connectors between busses with different speeds (e.g., high-speed processor bus and low-speed peripheral bus).

CoreConnect, for example, has three levels of hierarchy: processor local bus (PLB), on-chip peripheral bus (OPB), and device control register (DCR). PLB provides a high-performance and low-latency processor bus with separate read and write transactions, whereas OPB provides low speed with separate read and write data busses to reduce bottlenecks caused by slow I/O devices; the daisy-chained DCR offers a relatively low-speed datapath for communicating status and configuration information.

The advanced microcontroller bus architecture (AMBA) from ARM has two levels of hierarchy: the advanced high performance bus (AHB), similar to PLB, and the advanced peripheral bus (APB), similar to OPB. CoreConnect and AMBA are both pipelined busses with bridges to increase the communication efficiency between the high- and low-speed busses (for data transfer between them).

CoreFrame from Palmchip Company, on the other hand, is a nonpipelined bus that also has two independent bus types: Mbus for memory transfer and Palmbus for I/O devices. The PNX-8500 SoC from Philips is no exception; it also features, as shown in Figure 14-8, an on-chip hierarchical bus structure supported by local bridges.

Even though the bus structures across various SoCs (mentioned above) resemble one another at a coarse level of comparison, they do differ in their characteristics and implementation details (e.g., function, width, delay, throughput, pipelining, utilization, number of segments, number of busses, number and type of bridges, number of bus agents, and so on); an in-depth analysis of the target application, the desired timing, and the on-chip communication pattern determine the exact implementation.

To this end, the next few sections offer insights into the analysis that guided the final bus implementation in the PNX-8500 SoC.

PNX-8500 Structure
In PNX-8500, the multimedia processing and the control processing functions are split between two CPUs—the TriMedia CPU (TM32) and the MIPS RISC CPU (MIPS32). Thus, each CPU is responsible for the peripherals that belong to its task domain. This leads to the concept of separate processor busses, whereby each CPU controls all the devices on its local bus.

Not all the peripheral devices, however, can be owned by one CPU in all user cases (applications), and so provisions have been made so that every peripheral is still accessible from both the CPUs, but with a preference. If a peripheral is indeed shared at run time, the CPUs must negotiate its availability through the use of Semaphores.

Combining both CPUs in one system (from an SoC point of view) lowers the overall cost of computing by sharing system resources such as main memory, disk, and network interfaces.

All the on-chip functional units (peripherals) are programmable via CPU writes to their control registers. These control registers being memory-mapped, programmable reads from and/or writes to the registers are commonly referred to as memory mapped input output (MMIO) or programmable input output (PIO) transactions. Even though each peripheral can be addressed by both of the CPUs, it is "usually" read or written by the CPU to whose local bus it is connected.