HOW TO SIMPLIFY YOUR NEXT

EMBEDDED DESIGN

STEPHEN OLSEN, TECHNICAL MARKETING ENGINEER, MENTOR GRAPHICS

W H I T E P A P E R

E M B E D D E D S O F T W A R E

w w w.m e n t o r.c o m
How to Simplify your Next Embedded Design

INTRODUCTION
With today’s SoCs increasing in complexity, it’s no wonder the software needed to run on these devices is
taking longer to create, adapt, and optimize for a given application on a given piece of hardware. No question
practices and methodologies behind system design needs to change.

Each SoC is designed for a specific set of applications that is in its core target market. The same is true
of operating systems. The combination of choices can be daunting. The system integrator typically handles
the task of creating the hardware/software platform for the application team and therefore, must select
the correct hardware and software combination to ensure that the application will perform adequately and
meet the design goals as specified.

Often this approach is insufficient for a complete application. As a result, the system integrator must then add
in different sets of middleware provided by the OS vendor, or different third-party providers in order to meet
the platform design goals. If no third-party solution exists, or the current approach is cost prohibitive,
the system integrator must specify what functionality needs to be present for the application to perform its
duties and how to achieve the design goals.

As the depth of application complexity and feature set increase, there needs to be a better way to work with
these systems. From the myriad of protocols in which to choose what is optimal for the system? How will the
end-user interact with the finished product? Are there accelerators present that must be interfaced from the
application or middleware?

This problem is no longer trivial for the system integrator to solve.

MYRIAD APPLICATIONS, SIMILAR MIDDLEWARE

As an example, let’s look at the difference between a personal multimedia player (PMP) and a medical EKG
monitor. Both have displays, audio interfaces, and are battery operated. The EKG is specifically designed to
accurately reproduce the waveform on the screen and alert the staff if something is wrong with an audible alarm.
Incorrect reporting could lead to the wrong diagnosis. The PMP is designed to reproduce a waveform played
through an audio channel where if played wrong, degrades the quality of the device’s primary function – but it
won’t cause any harm with its screen being used to display album covers in order to choose what song to arrange
on a playlist. Both have the ability to record waveform data to internal flash, host a USB disk, or be tethered as
a USB peripheral and communicate with a host to upload and download data. On the surface, these two
applications seem very similar.

This leads to the first assessment that the same hardware may or may not meet the needs of the device.
Functionality is a primary concern when selecting a piece of hardware. This same concern persists with
selecting the software. But how do you put it all together?

If the hardware is adequately defined to the operating system in a way that allows trade-offs to be made, the
system integrator has the flexibility to create an optimal configuration versus selecting an operating solution that
doesn’t sufficiently support the selected hardware resulting in a suboptimal configuration. This includes routing of
interrupts, DMA channels, and advanced processing cores such as DSPs.

So, indeed the operating system needs to be configured to match the hardware selection and be adapted
to optimize the functionality necessary for a given application. If 3rd party software is to be used, it must be
integrated to fill in the gaps, or if a development program specified for in-house development is initiated, it must
bring the complete application to bear. This involves a buy versus build assessment for the given functionality.

w w w. m e nto r. co m
2
How to Simplify your Next Embedded Design

CONFIGURING THE SOC AND BSP

Typically system integrators start with the hardware description provided by the SoC manufacturer usually in
the form of a data sheet or programmer’s guide. These documents provide the highest level of detail about the
available devices, etc., but they do not address the necessary low-level information to actually enable your design.
The integrator is left with the complex task of understanding the hardware, its pinouts and how to enable
each device. The job of designing an application increases in complexity as well, as peripherals may share common
pins leaving the integrator to decide which device has priority. Enabling the device optimally often leads the
system integrator to an operating system vendor who can provide a board support package and documentation to
successfully enable the specifics of the chosen hardware. Depending on the application, it is likely that some tuning
will have to be done.

The BSP provided will include the common functions that may be necessary for the OS to operate such as a timer
and console and some basic interfaces. While this is a good starting point, it’s not the entire configuration
necessary to bring the platform to its full capabilities.

The answer lies in a configurable build system that allows the BSP and OS to be designed to exploit the hardware’s
capabilities. This accomplishes two goals: 1) The ability to try different combinations to create the platform on
which to build your application; and 2) The ability to work at a level above the manual – which can sometimes
be confusing.

DEVICE DRIVERS
Each device on an SoC has a set of registers that need to be set in order to perform the necessary operations.
A device driver is required to interact with these registers and select the appropriate settings. But how far the
device driver goes in the system is dependent upon the layering involved in a BSP. For instance, the setting up of
the baud rate for a standard serial UART is dependent on the clock source, and frequency. Many times the clock
source is shared between devices on SoC. Therefore, the clock does not belong to a specific serial port even
though the serial port is dependent on the clock. Modern SoC peripherals have an added complexity in
power management. Being able to gate the clock or reduce the clock frequency will save power by changing the
clock at runtime which has an added complexity of having to adjust the serial port registers in order to maintain
the correct baud rate.

MIDDLEWARE AND DEVICE MANAGEMENT

As the system developer moves up from the devices, the next layer is the operating system and the middleware;
there is still configuration data that needs to be supplied. Take a look at a USB stack and its ability to host a USB
disk-on-key. The USB mass storage class driver needs to be enabled with the SCSI subclass, and then it needs to
be mounted to the file system. Once the drive is recognized, it can be made available to the application. Manual
configuration can turn on and off certain aspects of the USB stack, but adding automation to automatically
configure the stack without manually modifying source code lowers the probability of errors.

Devices must be associated either with their protocol stacks or presented to the developer in a standard API.
Without a device manager, the APIs for a particular class of device may be custom for each device, which makes
controlling them difficult. What’s needed is a device manager that abstracts the device from the middleware and
application, so no matter what devices are available they can be discovered and mounted. This includes power
management as well, where each device may implement a different type of power management and the power
controlling software commands the device into certain predefined modes.

w w w. m e nto r. co m
3
How to Simplify your Next Embedded Design

An ideal system would describe the hardware and software to the build system, allowing the system integrator to
make choices as to what protocols are needed to support the system and what devices are available. If any 3rd
party content is to be integrated, the build system should be extendable to configure that IP as well, and allow it
to either bind under existing protocol stacks or be presented to the application with additional APIs.

For example, let’s say a particular system is designed to support a FAT filesystem across a USB peripheral interface.
Access to this FAT filesystem must be present, both from a host computer, as well as by the peripheral itself.
Looking back at the PMP application, the ability to upload and download files to a host is imperative, but when the
device is not hooked to a host computer, the system must also work in standalone mode to process those same
files in either saving or playing multimedia files or playlists.

Likewise, a USB host controller may be used to host a disk-on-key to either store or retrieve multimedia files.
Additionally, the USB host controller might be used to interface USB speakers or a microphone for greater
functionality.

A device manager abstracts away the specifics in the hardware and provides a common interface for middleware,
applications and power management. This makes it easy to change from one device to another.

This scenario depicts the many forms of an end product and the need for flexible hardware/software to address
the spectrum of the market, from the low end to the high end. It’s important to capture all the necessary requirements,
and heavily weigh the configurability in both the hardware and software selected for the solution.

HIGHER LEVELS OF INTEGRATION

An embedded system involves much more than devices and OS services; it must also contain the most common
protocols in use today for transport of information like TCP and UDP. It must also have the ability to transmit data
encrypted for security, and even higher levels like that of remotely accessing a file system.

The need for integration extends all the way up to the application. The middleware present needs to be configured
to match the desired functionality. But with multiple sources of middleware, the system integrator is faced with the
task of integrating a great variety of components. The solution of course, is to use pre-integrated 3rd party com-
ponents. A key piece of this solution is the ability to configure for a particular application, regardless of using
tightly-integrated operating system parts or 3rd party add-on parts.

SO HOW DO YOU GET THE MOST OUT OF YOUR SYSTEM?

Let’s look back on our two examples: The PMP player and the EKG monitor. Specifically, how they present a user interface.
While the applications are very different, there are common threads between them. For example, the ability to store and
retrieve data that is related to a particular item is common between both applications. For the PMP player that may be
the playlist, or the album. For the EKG, it could be to browse patient data records. While they are very different
applications, they need to access data in a common format which simplifies what the system integrator needs to
do by first taking the common elements between them and then customizing them for their product.

Another example is the audio interface. Whether it is used over USB, or directly connected to a built-in speaker makes no
difference to the application. It can configure the proper interface to use or present the developer with a list of devices.

THE INTEGRATED PLATFORM

Today, system developers expect more from an operating system and the should expect more. Being able to
select and create a user experience that is similar to what they want and then customize it to fit is the
ideal development platform. To be able to take advantage of whatever devices are present from an app-
lication perspective without having the details built into the application allows them to quickly migrate to
a supported platform in both hardware and software to achieve the quickest re-design possible and get

w w w. m e nto r. co m
4
How to Simplify your Next Embedded Design

future products out faster. Taking advantage of a complete platform that includes the necessary hardware
components in the SoC, to the configurable por tions of the device drivers, middleware IP, and sample
applications results in a faster time to market.

CONCLUSION
As systems become more capable, SoCs are designed to have more options. The ability to completely describe the
hardware and software, configure both for a particular application, and then apply trade-offs is critically important
to maximizing the utility provided in the SoC.

The ReadyStart platform from Mentor Graphics.

The Mentor Embedded™ ReadyStart™ platform for the Nucleus® RTOS is an example of such a solution. It
provides complete BSP packages along with metadata that describes the hardware and the software
solutions, including some 3rd party software that integrates seamlessly on top. This gives developers the
freedom to maximize the potential of the platform – starting with compelling user interface demonstrations for
medical, industrial, automotive, and consumer devices, to providing all the necessary protocols along with the
configurability to give developers and architects alike a formidable tool for embedded design.

For the latest product information, call us or visit: w w w.m e n t o r.c o m

©2010 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and
may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 09-10 TECH9290-w