How platform-based design cuts digital still camera design time and costs

by Frederick Tarverdians, ARC International

Platform-based design is becoming the method of choice for designing systems-on-chip (SoCs) for embedded systems, such as digital still cameras (DSCs). It offers major advantages over the traditional approach based on separate, multiple-sourced pieces of intellectual property.

Also called a system approach, platform-based design is especially helpful to designers developing complex portable and consumer systems with design cycles of six months or less. The platform consists of application-specific extensions and peripherals; application-independent hardware and software, including processor and memory blocks; and the interfaces, software stacks, and development tools needed to pull them all together.

Digital still cameras are complex systems that pose multiple design challenges. They are composed of several subsystems that require interdisciplinary expertise, and which must be integrated and tuned to each other for excellent performance. Platform-based design significantly reduces DSC development time and cost, as well as overall design risk, by limiting the number of hardware and software suppliers required. Since system-level SoC design incorporates multiple types of standardized peripheral IP and software stacks, there is no need to train engineers in specialized protocols. This can result in large savings in design time, and thus cost.

Platform-based design is specifically aimed at the middle of the OEM DSC market, usually called the “amateur/consumer” market segment, with DSCs of 2 to 5 Mpixels. The entire time-to-market window for this segment can be as short as six months. The high end of the market is likely to use entirely custom designs, and cost is less of an issue, so more time can be spent on design. At the low end of the market, the “point and shoot” segment, are DSCs of 1 to 2 Mpixels with a very limited set of features and few image enhancement options. These designs are usually based on a simple microcontroller, such as an 8051, along with a hardwired JPEG engine.

For the middle range, designers want a platform which is mostly standardized, but which can be customized for product differentiation as well as to keep pace with changing standards and feature sets. Here, a general DSC architecture can be used, with, for example, an ARC processor core as the supervisory processor, and functioning as the image-processing engine. With such a design platform, less time must be spent on hardware design, so software design can start on practically the same day. Since the IP components of a DSC are designed and developed with the platform's tools, pre-integrated, and pre-verified, users can save development time and cost. Developers do not need to integrate hardware and software with a third-party tool, nor use multiple tools that were not designed to work together.

Integrating system-level IP into an OEM's design can also be done faster when the platform's processor core is equipped with interfaces for standardized internal buses, such as the Basic Virtual Component Interface (BVCI) and Advanced Microcontroller Bus Architecture (AMBA) interfaces. This connectivity lets designers plug in a wide variety of discrete IP to the core design platform. BVCI is an open industry standard bus that provides on-chip interconnectivity between IP cores on a SoC. The AMBA interface provides a similar function for SoCs based on a variety of processors, thus widening an OEM's design possibilities.

Many designers of SoCs used in portable embedded systems also want connectivity to external devices, such as that provided by Universal Serial Bus (USB) or TCP/IP interfaces. USB on-the-go (OTG) functionality is increasingly being added to power-sensitive portable systems, such as DSCs. This reflects the shift away from using the PC as the central point for data exchange. OTG is a supplement to the USB 2.0 specification which features limited host capability for portable devices, power conservation capabilities, and the ability to transfer data between OTG-enabled devices without the need to involve a PC. Connectivity for DSCs is thus becoming far more than merely plugging them into a PC. Instead, digital still cameras today are being designed to connect directly to printer and storage systems. Other external device interfaces for DSCs may include 1394, or FireWire, for high-speed peripherals; direct Ethernet connections that can transform the DSC into an internet appliance; and flash card interfaces for removable storage, such as SmartMedia and CompactFlash.

Aside from the supervisory processor, the main subsystems in a digital still camera are the user interface (including video and GUI overlay), motor control, the camera lens subsystem, the image acquisition subsystem, image processing, the JPEG engine, the memory controller, the audio controller, the storage media controller, and the communication controller, including interfaces to internal and external buses.

A complex design with multiple subsystems such as a DSC requires a set of development and debugging tools, as well as a supervisory program or operating system to create and schedule different DSC functional tasks.Multitasking software can often be developed much more easily with a real-time operating system. However, the RTOS must be efficient in terms of its memory footprint. A modular, embedded RTOS can be scaled to match the particular DSC design's subsystem requirements and achieve an optimum memory footprint.

Other software, such as drivers and communication protocol stacks, are also required which make it possible to transfer data to external devices connected to the DSC, and to manage that data. For example, storing and managing images on flash cards requires a flash file system. Transferring data over USB or Ethernet ports requires USB or TCP/IP protocol stacks. As components of a platform, these stacks have also been designed to be scalable, allowing developers to choose the specific feature set they need for a particular DSC design and keep memory usage to a minimum. The drivers and protocol stacks available from ARC, for example, have been designed and tested to work well when integrated with its MQX RTOS.

Extensive testing and verification of the whole system, including hardware and software components, is required for a design of this complexity. A software debugging tool can help developers test all the software, including the operating system, using either the Instruction Set Simulator (ISS) or an FPGA development platform. However, to run hardware and software co-simulation on the entire design, the software debugger must be interfaced to the HDL design database. This generally results in very long simulation times, and is thus rarely used during code development. Simulation tools that act as a bridge between the hardware and software simulation environments can supply an alternative approach by connecting the processor ISS model to the rest of the HDL design and running a hardware/software cosimulation. This approach can potentially result in huge time savings for the entire project schedule. Being able to test and debug the software and hardware in such an environment can easily shed months from a development schedule.

The traditional alternative to platform-based design usually involves piecing together an assortment of non-integrated IP components. For example, a simple RISC or x86 controller might be used for the DSC's supervisory processor, and one or more specialized, OEMdesigned, custom DSPs for the image-processing engine. A major detraction of this approach is the frequent lack of documentation for the processor, and of standard software or tools that may be used with it. For example, every time a new audio codec comes out for frequently changing standards, or a new feature is added, hardware and software must be integrated with the processor. But third-party plug-ins aren't available for a custom processor, so developers must create their own application software from scratch.

Testing and verification are also a problem with the piecemeal approach. Developers must create non-portable, inflexible, HDL-based testbenches which require many tedious changes whenever the system is modified and which force users to re-create test benches and tests to verify IP in the final system. In addition, they must also write many tests and extensively test each block separately with a unique configuration. Moreover, this approach allows only limited system testing, consisting of basic interactions between blocks in the base system: processor IP,memory IP, a set of peripheral IP, and a common system bus.

In platform-based design, the integrated hardware/ software platform forms a complete development environment for system-level functional verification of DSC hardware IP, as well as for simulating software IP. Users can test complex interactions between blocks, analyze hardware and software performance, and develop and test application code using the same simulation platform.When all this software is provided by a single source and has been designed to work together in an embedded system, a DSC's subsystems can be fine-tuned more precisely and easily, since their interoperability is assured, thus reducing the software integration effort.Users can then add their own differentiating features in the shortest amount of time, with the greatest confidence and the least amount of risk.