Group items tagged

Verification of algorithm-intensive systems is a long, costly process. Studies show that the majority of flaws in embedded systems are introduced at the specification stage, but are not detected until late in the development process. These flaws are the dominant cause of project delays and a major contributor to engineering costs. For algorithm-intensive systems —including systems with communications, audio, video, imaging, and navigation functions— these delays and costs are exploding as system complexity increases. It doesn't have to be this way. Many designers of algorithm-intensive systems already have the tools they need to get verification under control. Engineers can use these same tools to build system models that help them find and correct problems earlier in the development process. This can not only reduce verification time, but also improves the performance of their designs. In this article, we'll explain three practical approaches to early verification that make this possible. First, let's examine why the current algorithm verification process is inefficient and error-prone. In a typical workflow, designs start with algorithm developers, who pass the design to hardware and software teams using specification documents.

A product can be of low quality for several reasons, such as it was shoddily manufactured, its components were improperly designed, its architecture was poorly conceived, and the product's requirements were poorly understood. Quality must be designed in. You can't test out enough bugs to deliver a high-quality product. The quality assurance (QA) process is vital for the delivery of a satisfactory system. In this last part in this series, we will concentrate on portions of the methodology particularly aimed at improving the quality of the resulting system. The software testing techniques described earlier in this series constitute one component of quality assurance, but the pursuit of quality extends throughout the design flow. For example, settling on the proper requirements and specification cannot be overlooked as an important determinant of quality. If the system is too difficult to design, it will probably be difficult to keep it working properly.

RoweBots Research, Inc., a supplier of tiny embedded POSIX RTOS products, today announced the launch and release of UnisonTM Version 5 and the open-source version of Unison Version 4. These two ultra-tiny embedded-Linux and POSIX compatible RTOSs open Renesas Technology Corp.’s SH-2A Microcontroller (MCU) family to Linux and POSIX compatible development for the first time.

Xilinx Inc. today introduced the architecture for a new Extensible Processing Platform they claim will deliver unrivaled levels of system performance, flexibility and integration to developers of a wide variety of embedded systems. The ARM Cortex-A9 MPCore processor-based platform enables system architects and embedded software developers to apply a combination of serial and parallel processing to address the challenges they face in designing today's embedded systems, which must meet ever-growing demands to perform highly complex functions. The Xilinx Extensible Processing Platform offers embedded systems designers a processor-centric design and development approach for achieving the compute and processing horsepower required to drive tasks involving high-speed access to real-time inputs, high-performance processing and complex digital signal processing - or any combination thereof - needed to meet their application-specific requirements, including lower cost and power.

The main goal of this article is to focus on the difficulties encountered by SoC integrators when selecting an embedded microcontroller (MCU). Indeed, the selection is based on MCU performances, but the comparison can be difficult and compromised when considering all the parameters influencing these performances.In this article, we will detail how to assess rigorously power consumption, area, speed, code density and processing power for an embedded MCU. For each performance, we will describe how the parameters have to be selected to enable a fair comparison between processor cores.

In many instances, the way embedded software is structured and how it interacts with the hardware in a system can have a profound effect on the transient immunity performance of a system. It can be impractical and costly to completely eliminate transients at the hardware level, so the system and software designers should plan for the occasional erroneous signal or power glitch that could cause the software to perform erratically. Erratic actions on the part of the software can be classified into two different categories:

While the topic of timing has already been raised in previous parts in this series, the discussion here will be expanded to include the execution and response time of the software functions. When discussing timing in embedded software, there are typically two types of timing requirements, rate of execution and response time. Rate of execution deals with the event-to-event timing within a software function. It can be the timing between changes in an output, time between samples of an input, or some combination of both.

TTE Systems' RapidiTTy IDE provides a self-contained environment for developers who wish to create "time-triggered" microcontroller software in order to improve overall system reliability. RapidiTTy (Figure 1, below) is intended to address deeply-embedded applications including control and monitoring operations in medical, defence, automotive and industrial sectors, as well as in white and brown goods.

In then the past few years we have seen multiprocessing systems become more mainstream, in fact most modern personal computer CPUs now feature symmetric multiprocessing systems (SMP), where multiple instantiations of the same processor share the processing burden of the applications running on the PC. While SMPs are quite common today, we typically have not seen a shift towards multiprocessing in embedded computing. However, a new type of embedded design technique gives engineers the freedom to intelligently distribute processing functions across a digital subsystem. This article will look at an example of the distributed processing technique using Cypress Semiconductor's PSoC 3 and PSoC 5 architectures, which consist of a main CPU (in this case an 8051 or ARM Cortex M3), a DMA engine, and array of Universal Digital Blocks (UDB).

Related to the strong demands for virtualization technology, network I/O virtualization has recently become a hot topic and is one of the key topics being discussed at the upcoming Multicore Expo @ ESC. In fact, analyst firm IDC, in a recent white paper titled "Optimizing I/O Virtualization: Preparing the Data Center for Next-Generation Applications", stated that "If I/O is not sufficient, then it could limit all the gains brought about by the virtualization process."

PC-compatible industrial computers are increasing in computing power at a rapid rate due to the availability of multi-core microprocessor chips, and Microsoft Windows has become the de-facto software platform for implementing human-machine interfaces (HMIs). PCs are also becoming more reliable. With these trends, the practice of building robotic systems as complex multi-architecture, multi-platform systems is being challenged. It is now becoming possible to integrate all the functions of machine control and HMI into a single platform, without sacrificing performance and reliability of processing. Through new developments in software, we are seeing industrial systems evolving to better integrate Windows with real-time functionality such as machine vision and motion control. Software support to simplify motion control algorithm implementation already exists for the Intel processor architecture.

Intel has announced that is developing a system-on-chip for embedded applications based around its Atom processor core. However, it appears the SoC will be of a fixed design with a PCI Express bus interface to which system-level customers can attach their own or third-party chips. Similarly it appears that Intel will manufacture the system-chip internally rather than allowing a foundry to make the chip, or add its customers' IP to the design. Doug Davis, corporate vice president and general manager of Intel's embedded and communications group, disclosed details of the "Tunnel Creek" SoC during his keynote speech on Wednesday (April 14) at the Intel Developer Forum, in Beijing China.

The embedded world is constantly changing. You might not have noticed, but if you take a minute to recall what a microcontroller system was like 10 years ago and compare it to today's latest microcontroller systems, you will find that PCB design, component packages, level of integration, clock speed, and memory size have all going through several generations of change. One of the hottest topics in this area is when will the last of remaining 8-bit microcontroller users start to move away from legacy architectures and move to modern 32-bit processor architectures like the ARM Cortex-M based microcontroller family. Over the last few years there has been a strong momentum of embedded developers starting the migration to 32-bit microcontrollers and, in this multi-part article, we will take a look at some of the factors accelerating this migration.

Multisim 11 is the latest version of its circuit simulation software, with specialized editions for both hands-on learning and professional circuit design. The easy-to-use Multisim software delivers a graphical approach that abstracts the complexities of traditional circuit simulation, helping educators, students and engineers employ advanced circuit analysis technology. The academic edition of Multisim 11 incorporates specialized teaching features and is complemented by circuits textbooks and courseware. This integrated system helps educators engage students and reinforce circuit theory with an interactive, hands-on approach to investigating circuit behavior. Multisim 11 Professional helps engineers optimize circuit designs, minimize errors and reduce prototype iterations. When combined with the new NI Ultiboard 11 layout and routing software, Multisim provides engineers a cost-effective, end-to-end prototyping platform. Its integration with NI LabVIEW measurement software also helps engineers define custom analyses to improve design validation…

When considering the resolution required for an A/D converter (ADC) integrated in a microcontroller (MCU), embedded systems designers must balance cost and performance. Higher ADC resolution implies higher-cost MCUs, but in some cases you can use other features in the MCU to enhance the ADC performance via software. That approach lets you achieve higher resolution using an inexpensive integrated ADC. Here's how to use of oversampling to achieve extra bits of resolution for an ADC integrated in an MCU.

NXP BV (Eindhoven, The Netherlands) has said it will demonstrate a microcontroller based on the ARM Cortex-M4 at the Embedded Systems Conference in San Jose, California. NXP was one of the first companies to license the Cortex-M4 processor core and a chip has been implemented using a low-leakage 90-nm process technology. This enables performance in excess of 150-MHz clock frequency, NXP said. NXP has added proprietary power-down techniques to reduce power consumption. The ESC Silicon Valley demo will show that a 7-channel audio graphic equalizer application processing 32-bit precision audio data requires only 12 MHz of CPU bandwidth using the Cortex-M4 DSP extensions, and 60 MIPs without. The core includes DSP extensions not usually found inside a microcontroller and NXP's implementation are aimed at a broad set of applications including motor control, digital power control and embedded audio.

The consumer handheld market is growing by leaps and bounds. With more processing power and increased support for more applications, portable products are cross-pollinating with traditional computing systems even as the product life cycle has decreased considerably in this market segment. As a result, especially in this era of economic slowdown, it is imperative that new products meet the time-to-market window to gain maximum acceptance. A decrease in product life cycles requires a reduced development cycle and an increased emphasis on reusability and reprogrammability. The emerging handheld market is also seeing interesting trends in which each individual device in a family has lower volumes but there is more customization across the series of devices, effectively upping the total unit volumes. The key challenge then becomes how to develop a system that is widely reusable and also customizable. These requirements have led designers increasingly to turn to the FPGA for handheld-product development. The FPGA has become more powerful and feature-rich, while gate counts, area and frequency have increased. FPGA development and turnaround cycles are considerably shorter than those of custom ASICs, and the added advantage of reprogrammability can make the FPGA a more compelling solution for handheld embedded systems.

Field programmable gate arrays (FPGAs) present an efficient and inexpensive alternative when it comes to implementing complete embedded systems along with important peripheral functions. The reconfigurable logic circuitry of an FPGA offers tremendous flexibility. A lesser known feature is that the outputs of a digital FPGA also permit various analogue applications.