Embedded systems are by nature diverse and ubiquitous. High-performance applications such as controlling production lines and rail systems, enabling high resolution medical imaging, or facilitating in-vehicle entertainment systems exemplify how indispensable computing systems span all aspects of modern life and business.
Understandably, the design process is becoming increasingly complex. Connected embedded systems must often support specific interfaces required by end-use applications, handle extreme temperature ranges, and deliver low power consumption with high performance in remote, rugged deployments.
It’s up to system developers to navigate the complicated world of technical and strategic options impacting design in order to choose the optimal small form factor that both enables and improves structure and function. Asking the right questions will help developers evaluate design requirements and priorities, ultimately guiding the process to the ideal form factor for the application.
Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.
The following material examines various aspects of the complex question-and-answer process, illustrating how developers must reflect on differences between PC/104 single-board-computer (SBC) and computer-on-module (COM) options and their architectures. There’s no single path to creating the ideal small-form-factor design—only a logical balance of considerations that address performance and price while distinguishing innovative, competitive designs.
Evaluating Technical Choices
Technical and strategic issues may have equal weight in determining a design path; each affects the other and must be considered in tandem. Technical factors (e.g., CPU performance and interface set), as well as strategic considerations of development time, recurring and non-recurring engineering costs, and upgrade options, help the developer balance essential choices. The field narrows only slightly by assuming the baseline requirements of your project or request for proposal (RFP) have guided you toward a small-form-factor option. From there, the criteria could vary in importance depending on the end-use application; careful evaluation and key questions will validate the recommended form factor for the job.
Which form factor best suits the intended application?
COMs and SBCs may offer similar capabilities, but each takes a very different design path to enable performance. Long-term impact of this decision is significant, binding the solution to the chosen form factor and its associated product lifecycle. If the system is limited by legacy concerns, upgrades, or connecting to existing systems, options may be less flexible than if the system is a new, blank slate.
PC/104 SBCs enable modules to stack together like building blocks—a highly modular solution that avoids use of a backplane. Boards are commonly suited for designs using up to 25 W, a high thermal design point (TDP) for higher power systems. As standards-based components, developers have access to boards that are consistently interchangeable from vendor to vendor, adding flexibility and value to the purchase process. No baseboard is needed; the system simply requires its power supply and cable set. I/O connectors can be placed at all four corners of the board, both top and bottom.
Although the interface set isn’t specified, CPU/chipset interfaces are typically routed to IDC headers, standard PC connectors, or special high-density connectors. For designers, this is a matter of evaluating time, cost, and expertise. Questions arise such as “Is time-to-market delayed by accommodating the development of a baseboard?” “Is there a high degree of confidence in the technical know-how required to perfect a baseboard quickly and cost-effectively?” “Can the application readily afford a two-board design?” If these are roadblocks to using a baseboard, then PC/104 becomes an effective solution.
In contrast, COMs address a greater spectrum of power options, scaling from 38 W in COM Express, and under 12 W in Qseven and SMARC (Smart Mobility ARChitecture) standards. Not every feature or interface must be supported by each standard module. Instead, a baseboard is necessary to bring in customized performance and I/O required by the specific application. Upgradability is cost-effective and efficient, as the module can be replaced to upgrade performance, yet it’s still possible to capitalize on the same customized baseboard.
Certain applications will see real value in a two-board solution, because the custom-made carrier board offers a perfect fit of performance and interfaces in a very small footprint. Customization can endure for multiple product generations, while performance steadily improves with new, interchangeable modules from a wide array of vendors.
Are you tied to an existing footprint? COMs also offer a range of footprints and performance options that increase the scope of where they can be deployed.
Overall, an SBC provides the structure of a standalone computer. The system is ready; just add power and connect the I/O of your choice. COMs rely on their baseboard and connector(s) to draw all I/O lanes through to the system, without the possibility of more flexible I/O implemented directly to the module. The baseboard requires additional development resources, but enables flexibility in terms of where the interfaces are placed.
Perhaps most importantly, it’s not a simple thing to switch from a module concept to an SBC. With major differences in how they are implemented, choosing one platform over the other commits a design for the long term. Developers must ask which elements enable not only the strongest starting point for their system, but also the preferred development path in terms of baseboards. Do you want to shift design resources to the baseboard, or can you work with the defined structure of a backplane system?
Is your design characterized by low or ultra-low power consumption?
CPU performance is directly related to power consumption. In general, smaller form factors warrant lower power consumption and, therefore, lower performance. When designs are limited to passive cooling due to physical space or other design restrictions, performance tradeoffs must be considered in the form of a lower-performance CPU.
If the design can handle active cooling, which is crucial for managing the additional heat generated by a higher-performance processor, a greater number of options exist in terms of platform, layout, CPU, and more. For example, COM Express remains scalable with a range of different module footprints to accommodate the numerous options for choice of CPU. COM Express Basic and Compact sizes represent the larger footprints within this form factor, which also scales down to a mini footprint, comparable in size to the SMARC short form factor.
Designs typically require a straightforward look at power-management versus performance-requirement evaluations, yet some fine-grained options open new doors for ultra-low-power, higher-performance systems. In the area of low power in small, light, and reliable designs, x86 platforms have historically been challenged by ARM processors. Yet evolution continues, and today developers have access to a credible option for low-power x86 designs in a very small footprint. New system-on-chip processors offer higher than previous generation performance in an x86 chip that draws less than 10 W.
Developers ultimately must determine if it’s preferable that systems sacrifice performance rather than power. The key here is for designs to be right-sized in key elements of power and performance. For example, if the application requires high CPU performance in a small footprint, COM Express modules in Basic and Compact sizes may provide the ideal form factor. When lower CPU performance is acceptable, developers have more options and should consider architecture and interface set to help drive their form-factor decision.
Is there an overriding argument for one architecture vs another?
Both x86 and ARM have well-developed roles in the embedded marketplace—each ideally suited for a particular set of applications, and each essentially defined by the differences in how they communicate with I/Os. ARM’s three-step communication keeps processes streamlined, but reduces power and gets the job done, while x86’s 10-step process is more detailed, but also requires more time, power, and memory to complete (Fig. 1).
The communication process in x86 relies on the CISC (Complex Instruction Set Computing) architecture. CISC is a mature technology, with core architecture choices that include instructions to work directly with I/O, as well as memory. ARM’s communication protocol is known as RISC (Reduced Instruction Set Computing), and it doesn’t include the instructions to work directly with I/O. RISC processes operate only on registers with a few instructions for loading and saving data to and from memory.
ARM’s simpler, native 32-bit architecture leads to a small area for silicon and significant power-savings features, optimized for handheld devices such as smartphones and tablets. If a comparable application requires an x86 interface set, developers would find the ideal fit in a COM Express Mini-sized module, providing low power and all of the commonly required interfaces. When ARM interfaces are required—or perhaps a mix of both (e.g., direct camera support or I²S)—then SMARC modules become the clear choice. Both COM Express and SMARC are optimal for mobile solutions because of the option for battery-powered usage.
Designing for Strategic Impact
Are you planning DIY software support, or do you need the help of an established ecosystem?
Software support is a strategic element to the design process. Major systems include Windows or Linux, prompting designers to evaluate I/O requirements, ecosystem constraints, and overall ease of development. In general, Windows, VxWorks, and QNX are better suited for x86 architectures, and Linux is the better choice for ARM.
Windows offers mature support of the x86 architecture with comprehensive driver support for all cards. This enables relatively pain-free development when working with SBCs such as PC/104 and COMs in the COM Express and Qseven platforms. The ecosystem is highly accessible, and if new drivers aren’t available, developers can readily use standard drivers as a means of implementing new cards. Familiar x86 environments are well-supported by development tools that help implement, debug, and fine-tune software.
In regards to drivers, Linux is very similar to Windows, although driver support is more limited and can result in design challenges and extended development timelines. When drivers are unavailable, it’s more challenging to improve older versions to accommodate new cards. This is partly due to the open-source nature of Linux, with new published drivers requiring consortium review and approval.
In contrast, Android plays a different role and is specifically suited for smaller, smart devices such as smartphones and tablets. Based on Linux and specifically written for ARM architectures, Android today offers limited support of x86 I/Os.
The ARM environment is more complex and differentiated, with a singular focus on SoC products often optimized for a particular application. Building standard I/O definitions has not been a primary focus. As a result, the ARM marketplace includes a number of proprietary form factors and connector definitions. Designs may be locked to a single vendor that may not support more than a single generation of silicon. Although anticipation lurks for expanded x86 support in the future, today it results in higher development costs and extended software-design efforts.
However, the SMARC standard does enable some improved crossover between x86 and ARM processors. Originally designed to standardize the use of ARM processors, SMARC now also supports low-power x86 processors. Designers now have more choice and access to backwards-compatible, low-energy products, as well as the familiarity of working with the x86 ecosystem.
What factors form the basis for system cost?
The expectation of cost is often oversimplified. In reality, actual costs are based on a complex variety of factors. For example, general wisdom may assume that costs depend simply on module size, with a smaller module being more affordable than a larger module. In a real-world design scenario, however, a short module may be more expensive than a full-sized module. Technical specifications, single versus quad-core processor model, and realized I/O interfaces are some of the elements that will determine overall cost of the module itself.
Design expertise and resources add to the cost, too. Consider a SMARC module using low-power x86 processors in both short and full-sized models. The short module clearly has less space, but the design may require the same features that are present on the full-sized module. The design can be engineered effectively, but will require more printed-circuit-board layers to implement the I/O. This is a costly and painstaking engineering process; development time increases accordingly, along with the cost of production.
When realizing a similar system on the various small-form-factor platforms, engineering costs are generally highest with PC/104, less with COM Express, and still less with SMARC or Qseven – all of which potentially playing a role in the strategic evaluation that kicks off your platform choice. Engineering costs generally line out this way because of PC/104’s fully-formed, ready-to-go design, contrasted to the scalable design options found within COM Express. In turn, SMARC and Qseven have fewer components and are typically lower function than COM Express, further streamlining overall engineering requirements.
In general, customers tend to think that small form factors should cost less than larger computing platforms. In reality, that’s only true of small form factors with lower performance, i.e., those without high-performance I/Os. However, more often than not, today’s small systems must incorporate sophisticated I/O, and deliver the features and performance of a larger system in a smaller space. The resulting design is more challenging and, therefore, more costly, and that will have a greater impact on the overall platform choice.
What is the smartest application of time and design resources?
Development time depends on various factors, with each platform bringing its own unique challenges and advantages. Software must be adapted for any platform, and it will take a different path depending on whether or not a baseboard is required.
SBCs offer ready hardware—for example, PC/104 systems can be completed with the comparatively simple addition of power and a cable set, along with designer-selected I/Os. Once software is adapted, these systems are generally up and running quickly. COMs integrate a standard off-the-shelf module, but require time and expertise to develop the accompanying baseboard. Depending on their pin-out (e.g., Type 2, Type 6, or Type 10), modules in the COM Express standard may rely on a multi-pin connector to connect to the baseboard while SMARC and Qseven standards may rely on an edge connector, yet this provides the ability to customize it to the long-term needs of the application.
Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.
Architecture, layout, upgradability—what key factor defines your greatest risk?
Mitigating risk isn’t necessarily a freestanding issue, and likely influences every choice made in the design process. For example, from the designer’s perspective, no differences exist between x86 and ARM architectures at the board-layout level. Both incorporate standard I/Os, high-speed lanes, memory interfaces, and more.
Yet in the initial design phase, as well as troubleshooting that follows, the process is easier when working with the x86 architecture. The ARM platform is more complicated to analyze and troubleshoot, issues that may guide the developer to an alternative architecture. For example, COMs remain upgradable with a module switch; PC/104 requires a new board and may also incorporate different I/O connectors placed at different locations on the board.
Achieving Balance in a Competitive Design
Developers face a spectrum of technical and strategic choices in determining the ideal small-form-factor platform for a particular application. Even while there is no right or wrong path, evaluating options from both perspectives enables a smart look at tradeoffs, performance, and long-term upgradability (Fig 2).
Small form factors, in general, play one of the greatest roles in connected embedded arenas, bringing intelligent systems to new deployments and further advancing performance to match that of larger systems. SBCs enable specific performance ideals for volume production designs, while COMs are a path for cost-effective, customized performance that can last for multiple product generations. Keeping the system right-sized for the chosen application is ideal as a basic strategy, and fortunately there’s usually more than one workable option. Both x86 and ARM ecosystems continue to evolve, and narrowing design choices will never be a static process.
Jeff Munch, CTO of ADLINK Technology, heads all R&D operations in North America and Asia. He has over 20 years of experience in hardware design, software development, and engineering resource management. Before joining the company, he spent five years at Motorola Computer Group as director of engineering. Munch is also Chair of several PICMG Subcommittees.