Settop box architectures..................
October 27, 1997, Issue: 977
Section: Embedded Systems
Set-top box requires a specialized RTOS
By Ken Morse, Chief Technical Officer, PowerTV Inc., Cupertino, Calif.
The move toward digital technologies providing video/audio compression and
high-speed data delivery has created a new class of set-top boxes, from
those used in satellite systems such as DSS to the ones in cable systems like
Pegasus, the Time Warner Cable commercial deployment of digital cable
services. These new set-tops provide capabilities that rival, and in some areas
surpass, those of $2,000 personal computers. The complexity of this new
generation, and the need to support an open applications and services
platform, has driven a new set of requirements for embedded operating
systems.
Set-top boxes are very cost-sensitive devices, and this restricts the amount of
memory. Typical configurations provide 1 Mbyte of ROM for the OS; 1
Mbyte of flash for the resident application, system patches and additional
system software; 1 Mbyte of RAM for downloaded applications; and 2
Mbytes of RAM for MPEG decompression and graphics. Such constraints
force the developers of system software and applications to devise novel
architectures to enable compelling services.
Silicon integration plays a large role in making the boxes cost-effective, but
this integration can also require the CPU to handle a large set of general
housekeeping activities that can potentially affect performance.
In almost every important aspect, the set-top box can correctly be called a
network computer. It is connected to a high-speed broadband network
capable of delivering data at up to 38 Mbits/second. For two-way
installations, a return path equivalent to a fractional T1 is provided. High-end
multimedia capabilities are standard, including MPEG-2 video, Dolby AC-3
Surround Sound, high-quality graphics, video manipulation and compositing,
and locally generated PCM (pulse-code-modulated) audio.
Security is also a major concern in systems that support the delivery of
studio-quality digital film masters. With this in mind, set-tops implement a
comprehensive encryption and authentication system to avoid signal theft. The
security system also enables additional services through the use of smart cards
to extend the box's capabilities.
Set-tops are consumer devices and, as such, must function reliably. There is
no reset switch, and a non-working unit means a loss of revenue for the
operator. Reliability must be addressed in terms of the set-top's internal
operation as well as its operation when the delivery network becomes
impaired. In such a complicated network environment, there are many
potential failure cases to deal with while minimizing the impact on the end
user.
Another set-top requirement is the ability in a memory-constrained device to
support multiple applications executing at the same time. Typically, these
include the resident application, a downloaded application and perhaps a
background task, such as a Simple Network Management Protocol agent.
This affects design of the operating system, which must be able to support
multiple applications and handle resource management for single-access
resources, such as the tuner, network interface or display.
This environment presents many challenges for an OS developer. For
example, the low memory requires very careful management of resources to
avoid fragmentation and performance degradation. Supporting multiple
interfaces and housekeeping tasks requires optimized low-latency thread and
interrupt management. Perhaps the biggest challenge is providing all the
required functionality, in a small code space, that the OS needs to support
features beyond those of a typical real-time operating system (RTOS)
Evaluating RTOSes for this environment generally exposes the weaknesses of
traditional RTOSes in several areas. First, the set-top needs a complete
software solution, not simply the kernel, hardware-abstraction layer, device
drivers and TCP/IP stack that most RTOS vendors provide.
The operating system must also support additional protocols for connecting to
the network, such as Davic (Digital Audio-Visual Council) and DSM-CC
(Digital Storage Media, Command and Control). These specify how a set-top
signs on to the network, establishes sessions and receives data over
mechanisms such as data carousels. A comprehensive 2-D imaging model,
including support for bit-blit (rectangular-pixel) operations, is required, too,
along with support for high-quality anti-aliased text and graphics rendering.
Several RTOS vendors provide the capability to dynamically link applications
at run-time and patch the operating system (when it resides in ROM) using
RAM or flash-based tables. However, this functionality needs to be extended
to incorporate the ability to decrypt the applications and patches sent over the
network and to digitally authenticate them upon receipt. However, most
RTOS solutions do not provide a multiple-application framework and
resource-sharing environment, which is critical for set-top solutions running in
a constrained memory space.
With respect to providing an optimized low-latency real-time system, many
existing RTOSes are adequate. But they typically incorporate predefined
kernel objects that encompass a high level of functionality and perhaps do not
give the application programmer or system-software developer the ability to
optimize their implementation for performance.
The introduction of multiple IP interfaces on the set-top requires modifications
to standard TCP/IP stack implementations to support path associations with
Davic signaling connections. In addition, the TCP/IP stack must be optimized
to operate effectively in a constrained memory environment.
In providing a solution for the set-top market, PowerTV has developed an
in-house compact operating system that incorporates all the necessary
functionality to support set-top operation and enable compelling applications
in a small footprint.
The decision was made early on to develop our own kernel, as opposed to
leveraging an existing RTOS design. This was a result of several key needs.
First, it was important to be able to work with the platforms as they were
presented to us by customers (most set-top platforms utilize exotic
processors with a lot of silicon integration, not typically supported by existing
kernel providers). Second, we felt it was important to provide interfaces that
enable system- and application-software developers to access the
lowest-granularity objects required to build a system that operates efficiently
in the given memory constraints. Also important was the capability to modify
and optimize the memory-management implementation for these devices.
At the heart of the kernel is a unified events system that enables low-latency
delivery of data to single or multiple destinations. Applications and drivers
merely register interest in the type of events they are interested in, and the
generated events are then directed to the registered receivers. This model is
enhanced by enabling applications to register interest with a mask-compare
system. That allows applications to listen for all key events, for example,
whether they come from an IR remote, keyboard, front panel or external
device. Giving application developers access to the lowest-level kernel object
means they can build their own optimized kernel objects on top.
Copyright (c) 1997 CMP Media Inc.
You can reach this article directly:
techweb.com |
