Use OCP interface technology in SIPs for video coding

Digital video capture and playback has rapidly become a standard feature in many portable consumer and communications devices, including digital still cameras, portable media players, and, of course, mobile handsets. Compared to consumer video equipment, like camcorders, DVD players, and set-top boxes, the design of mobile devices places stricter requirements on size, power consumption, and manufacturing cost. To meet these requirements, system makers use ICs specifically developed for this environment.

Typical components that enable digital video in mobile devices are general-purpose application ICs for handsets and smart devices, coprocessors that implement video functionality in conjunction with camera and LCD control functions, and stand-alone video-coding chips. As 3G technology becomes mainstream, video circuitry will be integrated onto digital radio baseband ICs.

The most common video format in mobile devices is MPEG-4 (H.283), which is gradually being replaced by the MPEG-4 AVC (H.264) standard. The VC-1 video standard (originally implemented by Microsoft as the Windows Media Video format) is also making inroads into mobile devices. Proprietary video formats, such as Real Video, are also found in some mobile devices.

Video coding by itself is an area that requires special skills, and the plethora of formats that must be supported is a challenge for semiconductor component makers. That’s why most component vendors buy video coding technology from specialized silicon intellectual property (SIP) providers.

SIP requirements for mobile video
SIP vendors develop silicon solutions, such as hardware video codecs, that enable their customers to bring their chips to market faster. While the SIP vendor can develop video coding functions in-house, developing the interface between the customers’ logic and the SIP blocks usually requires attention from both parties. And because video coding is a very data-intensive application in which the performance depends on the ability to move large amounts of data over the IC and system buses, solving these integration issues can take time.

Most general-purpose application ICs use industry-standard, on-chip buses, such as the AMBA bus specified by ARM, but some vendors employ proprietary buses. In the coprocessor and camera-chip market, proprietary bus solutions are quite common. Supporting the array of interface standards is an additional cost to SIP vendors. Alternatively, proprietary buses make SIP procurement difficult for IC vendors that have made large investments in their in-house solutions. OCP technology can solve the problems for both parties. Therefore, demand for OCP support in SIP products has risen recently.

Video-based SIP characteristics
A video codec is a complex hardware and software solution. One particular multi-format encoder’s hardware implements the computationally intensive video coding tools, such as motion estimation, discrete cosine transform, and deblock filtering (see the figure). By employing custom parallel architectures, these functions can be executed on a low clock frequency, thus reducing the power consumption. The software parts of a video codec carry out control tasks, stream parsing, and less computationally intensive coding tasks.

The architecture of a multi-format video encoder is shown.

The video codec hardware implements two types of bus interfaces. Communication with the host CPU core occurs through a register-based slave interface, which is a fairly low-bandwidth interface. The video encoder hardware must also access image data stored in external (off-chip) memory by functioning as a bus master. This, in turn, is a high-bandwidth interface.

Challenges for next-gen mobile video coding solutions
The advances in semiconductor, display, and image-sensor technologies make it possible to implement higher-quality video features in mobile devices. As screen resolutions rise to VGA (640 by 480 pixels) and above, consumers will also want to capture and view video content at that resolution. For a video SIP provider, this creates a new challenge in that customers’ performance requirements will vary greatly. For mass-market handsets, CIF resolution (352 by 288 pixels) is enough, while high-end devices may require VGA or even D1 resolution (720 by 576 pixels).

Among the design issues faced by a video SIP provider is the increasing amount of transferred data caused by higher resolution video coding. Next-generation handset applications, including mobile television, will result in even more traffic on the system bus than current camcorder applications as the presence of the other active modules connected to the bus increases latency to the SDRAM for the video codec IP. The implication of this will be to reduce the maximum resolution and frame rate the codec can process at the given clock frequency.

Latency is different in the traditional AMBA approach than it is in an OCP system. AHB allows only one bus master to connect to the SDRAM at a time, while other masters must request the bus and wait for their turn. The OCP system behaves differently—it allows each master to access the bus, and the latency is perceived as the time between the issued command and the response from the bus. While this may seem a trivial difference, it’s far from it.

OCP separates address cycles from data cycles, which means that the master needn’t wait for a response to each command before issuing the next. This makes the pipelining of bus commands possible, which is the best weapon available in the fight against latency.

As an example, consider a case where the latency between the issued command to the SDRAM and the received data is 100 clock cycles. If the master performs a read burst to the SDRAM, then a write burst, followed by another read burst, the AHB system’s delay caused by latency would be 300 clock cycles. In OCP, this can be reduced to 100 by pipelining the three accesses. Also, if the master is aware of this 100 clock-cycle latency, it can start the pipelined command 100 clock cycles in advance, and thus completely compensate the effect of the system latency.

The video codec itself can be made scalable so that one solution can support all video resolutions. However, the customers’ SoC bus solutions must be developed so that a balance is found between performance and cost. In lower-end chips, 32-bit buses can be used, while higher-end parts may opt for a 64-bit bus to avoid bus congestion problems.

When choosing the bus interface for its latest multi-format video codec products, two options were considered at Hantro. The first option was to implement two interfaces, one for 32-bit AMBA-based systems, and another for 64-bit systems based on ARM’s AXI bus standard. However, this approach was considered risky, as it wasn’t clear how fast the AXI standard would be adopted by the industry.

The second option, which was chosen, was to base the interface design on OCP, which supports both 32- and 64-bit buses. This architecture makes possible to support all customer-requirements with just one interface. Customer demand for an OCP interface is on the rise, and OCP compliance is now regarded as mandatory.

OCP opens the door for SIP products
OCP technology makes it possible for a SIP provider to adapt smoothly to customers’ SoC bus roadmaps, without allocating resources to develop bus interfaces for emerging standards well before customer demand picks up. OCP technology also lets SIP providers serve customers that aren’t directly in their target industry segment. For instance, most ICs for handsets and other smart devices have a fairly similar bus architecture (such as AMBA), which makes it easy to develop video-coding SIP products for them. Outside this segment, there are ICs, like image sensors, that could potentially use the same video-codec solutions as handsets. However, they often employ different (and proprietary) bus and memory architectures. To serve such customers, SIP providers would have to delve deeply into the customer’s design, which usually isn’t possible for resource and time-to-market reasons.

About the author
Aki Kuusela, a project manager at Hantro Products, holds an MSEE from the University of Oulu. He can be reached at .