Embedded software development tools make for more flexible silicon

Semiconductor companies are integrating more software content with their processor offerings, marking a stark contrast with days past, when companies left software development and tools as an exercise for designers to perform on their own. The earliest efforts to integrate software with a hardware offering were development tools, such as assemblers and compilers, to ease programming a target processor. The software that semiconductor companies and their development-tool partners provide to support embedded-software development has continued to expand over the past few decades. But the focus of these efforts has been on easing and speeding the use and development with a target processor or family of similar processors (see sidebar “Software productivity”). An emerging trend in how semiconductor companies and their partners are integrating software and hardware is going beyond just making development faster and easier; it is making hardware more flexible and enabling designers to explore more options before binding and optimizing their design to a processing target.

A challenge for software development for the embedded-processor market is how to productively work with the myriad processor architectures that are available to designers (reference 1 and reference 2). One reason there are so many processing options is that it is a critical consideration for embedded designs to find a good balance of delivered functions, features, and power consumption that you can implement with minimum resources to enable lower costs. There are dozens of semiconductor companies that provide processors to embedded-system designers, and a handful of distinct processing approaches focus on how best to solve problems (Reference 3). Examples include microprocessors, microcontrollers, DSPs (digital-signal processors), programmable-logic fabrics, and DSCs (digital-signal controllers). Each of these processing options choose architectural trade-offs that emphasize optimized capabilities for the type of tasks they best address, often at the expense of other architectural constraints that play a negligible role in quickly and efficiently performing those tasks.

Further increasing the complexity of embedded-software development is the use of multiple processing options within a single system, such as a DSP, a microprocessor, and accelerated logic. Although most users focus their attention on the CPU inside a desktop computer, a handful of embedded processors inside that computer handles the peripherals, such as the disk drive, the network connection, and the video display. Automobiles rely on dozens of processors. Even consumer appliances, such as washing machines, microwave ovens, and refrigerators, can use several microcontrollers to control motors and the user interface and to monitor the overall system. These multiple processing units provide just enough performance at lower power consumption and lower cost.

The range of code-incompatible specialized processing options available forces software-development teams to bind their design to target processor architectures as one of the first actions they must make. This decision significantly impacts the project’s overall cost, design difficulty, and risk at a time when the team has the least information about what resources the project will ultimately require.

A growing and key realization by the semiconductor companies is that the supplied software, runtime blocks, and development tools are no longer just adjuncts to make it easier to market and sell their silicon but are essential components of their entire system offering. In fact, the total resources a semiconductor company will invest in software to go with its silicon offerings represent a large and significant portion of the development budget. The days of processor companies saying they are not in the software business are at an end. The focus of semiconductor companies is moving to systems houses that have partitioned some of the system as hardware and software; they leave the remaining software capacity for designers to add their differentiation.

Semiconductor companies are creating and maintaining more software with their silicon products because software is a cheaper, safer, and more flexible way for these companies to continue the integration story of the past decade. Processor devices have been integrating more of the system into a single chip, including peripherals, memory, and memory controllers. However, it is not always practical to integrate everything as hardware. For example, the CRC (cyclic redundancy check) is an expensive function to perform in software but relatively simple to implement in hardware—yet only a handful of processor offerings, such as from Microchip, actually include an integrated CRC register. Including the CRC register in every processor does not make sense because many applications do not need it, but cases in which the primary application of the processor would use it enough justify its inclusion in the chip.

An emerging consequence of processor vendors’ changing perspective toward integrated software is that it holds tremendous benefit for the vendors and designers if they can support flexibility among their processor offerings. Most processor companies offer multiple processor architectures so that they can better target more than a single application. Providing useful integrated software for all of those products is a difficult proposition, especially if there is no way to support software flexibility among all of those architectures. In fact, although some companies support flexibility within a subset of their processor offerings, providing a consolidated, comprehensive, integrated software suite across all of the company’s architectures is still a goal for the future. This approach differs from a single integrated software-development environment that can support development across a semiconductor vendor’s entire line of processors.

Adding to the complexity is the trend in variations of processor architectures. According to Clyde Stubbs, chief executive officer of Hi-Tech Software, the number of processor architectures has actually been proliferating, contrary to industry expectations. In a sense, this proliferation of instruction-set architectures is a testament to the success of modern compilers, because they have done an acceptable job of abstracting a target processor’s instruction set. Although some of the variations are from architectural features, such as specialized execution engines, memory architectures tolerant of memory-access latencies are large drivers for architectural differences. This architectural variability is not capricious; it is the result of real differentiation, as architectural design teams make trade-offs for processors that target specific application categories.

This type of variability impairs the usability of third-party IP (intellectual-property) blocks and portability of efficient code, especially for real-time-sensitive code. Programming languages, such as C and C+ +, do not include constructions to accommodate these architecturally important differences. As a result, compilers must use proprietary-language extensions if they are to be able to effectively employ these differentiating resources. So, although processor architectures have become more compiler-friendly at the instruction level, they have become less compiler-friendly on the differentiating features of modern architectures. A processor’s instruction set is less a differentiator; its memory architecture and how it can perform relevant operations in parallel or with less power are larger factors. Unfortunately, these tasks are not compilers’ strong suits.

Even using the same instruction set between processor offerings is insufficient to allow easy flexibility among processors. One of the ways ARM licensees differentiate their ARM7 devices is with proprietary interrupt, bus, peripheral, and memory-access structures. Although this approach enables the processor to handle a type of workload, it complicates porting code between two devices using the same CPU. ARM’s Coretex architectures are partial moves to help with these types of software-porting challenges, such as by specifying a consistent approach for handling interrupts.

Enabling designers the flexibility to explore more processor architectures and delay binding to a given device requires action by the semiconductor companies and their software-tool partners. Many companies use common peripheral blocks among their processor offerings and support a consistent interface to each type of peripheral. To aid designers with configuring and using peripherals, many companies now offer device managers, configuration wizards, processor experts, or visual-device-initializer tools that allow designers to work at a higher level of abstraction and avoid the learning curve of how to explicitly place a peripheral into a specific state. This approach enables designers more flexibility to move among devices that these tools support; it does not, however, eliminate the need for designers to understand the consequences between the processing performance and power consumption of specialized blocks, such as hardware accelerators or smart peripherals, versus generalized blocks.

Differentiating approaches to supporting flexibility in silicon choices include Microchip’s common-code base, which allows designers to migrate between 16- and 32-bit PIC devices and offers common APIs (application-programming interfaces) to abstract architectural differences and present virtual peripherals. It also gives peripheral blocks a defined, consistent look, feel, and behavior and provides the ability to remap I/O pins with a peripheral pin-select capability.

Renesas announced the RX family of processors to unify the peripheral IP between legacy 16- and 32-bit processors from Mitsubishi and Hitachi as an extension of those architectures. The EXREAL (Excellent Reliability Efficiency Agility Link) Platform is a “mother,” or superset, platform targeting the development of specialized processor platforms using common software-evaluation, -development, -optimization, and -validation techniques to enable more architectural exploration.

Freescale’s Flexis platform attempts to provide more flexibility among price, performance, and power trade-offs by providing a software-development environment that spans 8- and 32-bit architectures and supports movement both up and down among those architectures (Figure 1). According to Jeff Bock, global product-marketing manager for consumer- and industrial-microcontroller operation at Freescale, 50% of Flexis designers know upfront which architecture they are going to target, 25% target both architectures, and 25% explore both architectures and delay their choice until they have application code and can compare the differences between both architectures.

Texas Instruments’ DaVinci development approach (Figure 2), an evolutionary step beyond the earlier OMAP (Open Multimedia Applications Platform) approach, takes the most extreme stance on silicon implementation. DaVinci devices may include any combination of microprocessor, microcontroller, DSP, FPGA, or even hardware accelerators. A consequence of this approach is that, although designers may use multiple heterogeneous cores, the software-development model attempts to abstract the implementation through APIs so that, as new silicon offerings become available, designers can migrate more easily to better silicon targets without a major porting effort. Greg Mar, DSP-strategic-marketing manager at Texas Instruments, points out that, despite efforts to preserve a designer’s software investment, the need to support different “touch points,” or levels of interaction, even from the same customer, creates significant challenges.

Touch points are significant concerns to any embedded-processor supplier because, although some designers want to work at the application layer, which is ideal for APIs and preserving software investments, others want to touch the system at lower levels, such as at the hardware-abstraction layer all the way down to the silicon with assembly programming. This situation creates a major challenge because each developer wants to see different information as he develops his system.

A key element of modern processor systems and their surrounding ecosystems is that they enable designers to perform more exploration than they ever could before. Many processors offer evaluation or demonstration boards. A key goal of modern low-cost evaluation kits is to enable designers to quickly explore a family of processors and determine whether it is a good candidate for their project. The attention to detail in modern evaluation kits focuses on getting the designer up and running in minutes by integrating the hardware with vertically targeted software. These systems also save designers time by immediately confirming that the system is indeed operating correctly when the designer first connects it to his workstation and helping to avoid opportunity-destroying troubleshooting in kits that do not work properly out of the box. They allow designers to explore more processing options and give semiconductor companies more access to the designers.

Getting a working implementation of a processor into a designer’s hands also means suppliers can offer differentiating software to expand, optimize, and better target the platform to a designer’s project by making common, optimized software libraries that support the range of processor options that the kit represents. It is increasingly in the interest of designers to use the integrated software, so that they can incorporate the lessons they learned into future versions from the processor provider. It is also in the processor vendor’s interest to maintain this integrated software in more than an as-is condition, because it is an integral part of its system offering that happens to include hardware and software partitioning before the designer even considers the part.