Simpler software design tools
Across industries, embedded systems are becoming more complex, and, unfortunately, traditional software tools are matching the growth in complexity. During the design process, system developers face a variety of challenges: programming the different types of processing technologies that must work together in a complex system, balancing feature requests with time to market, balancing validation testing with robustness, and ensuring that the team headcount has the appropriate levels of expertise for the project. What system developers need are fewer, more productive tools that will help them spend more time on engineering algorithms and less time on integration of hardware and software.
System design software environments
System design software environments are used to design and test a wide range of control and measurement systems. They offer unprecedented integration with existing software, intellectual property (IP), and hardware while capitalizing on the latest computing technologies. System design software environments have the tools to solve today’s system design problems—and the capacity for future innovation. These software tools integrate with specific hardware architectures and modular platforms to maximize productivity and software reuse from early prototype to final deployment. The validated hardware and software integration eliminates the need to develop specialized drivers and middleware for all forms of I/O and peripherals, allowing embedded designers to quickly begin developing a specific application.
System design software environments need to provide the following critical functionality and capabilities:
1. Support a wide range of processing elements such as microprocessors, FPGAs, and GPUs
2. Provide a complete set of models of computation. System design software cannot limit embedded designers to one language or software model of computation. System designers need be able to use the appropriate language for each aspect of their application from one environment, whether graphical programming, textual math, C/C++/C#, and HDL (see Figure 1).
3. Simulation capabilities
4. Tools for user interface development
5. Manage system deployment and maintenance.
One of the historical challenges of using one system design environment to design, prototype, and deploy an embedded system is the common use of field-programmable gate arrays (FPGAs) alongside microprocessors (MPUs) in the same design. While this architecture has proved ideal for many advanced control and monitoring systems, historically the FPGA and MPU required different languages and specialized skills to program. System design software can allow system development for both processing elements within one environment.
Why architects build models
The entire design process is a tug-of-war between making it fast and making it right. These sides seem farthest apart in the early stages where multiple ideas exist. Starting from nothing takes time, and the first step can be the most important as it determines the direction of the entire design. This is why architects create building models of their architectural drawings. A building model can provide a complete view of the final design at a relatively low cost to allow all stakeholders to provide input to the creative process and allow the architects to see their concept realized and make any needed modifications. Going straight from sketch to ground breaking is too risky for major architectural projects. Creating a building model is an efficient tool that strikes a balance between time and functionality. The embedded control systems equivalent of the architectural model is a functional prototype.
A functional prototype has connectivity to hardware I/O (input-output) points, sensors, and runs the current iteration of the designed algorithm. With a functioning prototype, engineers can perform more realistic tests to catch more problems earlier, which will ultimately shorten the design cycle. The aerospace and automotive industries have more than one example where software simulation did not catch critical design flaws. This is just one reason why functional prototyping of control systems is so important, though finding algorithm issues must still be balanced with time to market.
The design process of the traditional programmer is one that probably dates back to a high school computer science class: flow chart to pseudocode. From the architecture example, this is closer to a sketch than a model. The low-level nature of C requires a lot of housekeeping before the true algorithm development can begin, and this level of optimization comes at the cost of time since effort must be spent managing memory, spawning threads, and communicating with I/O elements.
The abstraction provided by system-level design tools helps engineers develop concepts for new ideas in three ways. The first is that developers spend more time on the algorithm construction and less time setting up a software framework that may ultimately get scrapped. The second is that system design software often includes prebuilt IP for industry standard functions so programmers can focus on solving the new problem and not ones the market already covers. Both of these benefits reduce time to market. System-level design software also allows designers to choose a final deployment target different from the prototyping platform with minimal software changes.
A wall to productivity
For the above reasons, many embedded system designers choose to use an abstract, system-level design tool for prototyping and then throw the result “over the wall” so the entire project can be rebuilt in C for final deployment. Imagine the time saved if an engineer could clean up and deploy prototyped code. Some designs may require this switch, but changing programming tools comes at the cost of time, and not just the time needed to program the algorithm in a new language. One of the benefits of C is that it can target a wide array of hardware, but this requires a significant amount of effort to tailor the code to the designed hardware. Furthermore, many designs today incorporate processing and logic devices, such as FPGAs, complex programmable logic device (CPLDs), and digital signal processors (DSPs), that require additional software compilers and assembly packages.
System design software often is available with a platform of hardware components to facilitate faster development while providing some flexibility for design optimization. System-level design software is available that supports a large collection of Intel, Freescale, ARM, TI, and ADI technologies with specific embedded control hardware. Software/hardware platform combinations remove the need for low-level management of direct memory access (DMA) transfers, VHDL [VHSIC (very high speed integrated circuit) hardware description language] programming, and memory handling. These are the constructs that take time to implement but are rarely part of the “new IP” to the market. Control developers that leverage the same system-level design tools for both prototyping and deployment can remove the wall to productivity and drastically reduce time to market.
How to future-proof
Compiling a list of features to add in the 2.0 version starts before 1.0 is even out the door. A good embedded system developer will plan for system upgrades and design-in the ability to add or change the code more easily in the future. The most common method for future-proofing code is software abstraction. Low-level code spread throughout a codebase is difficult to change, which is why developers construct modules of code that perform higher level functions. System-level design tools are inherently abstract and thus conducive to future upgrades when used properly.
Not all changes made to a design are planned features. Over the life of a design, individual components and technologies are subject to lifecycle planning and, based on the technology, component changes can trigger the need for software upgrades. System design software from one supplier will manage all of the software components. Without this management, traditional designers must track compatibility of compilers, assemblers, and other low-level software tools, which further increases the risk of a forced redesign due to an end-of-life (EOL) issue.
It’s all about ROI
Return on investment (ROI) is one of the most important calculations for a project. Using the traditional C programming language and in-house hardware for embedded system development may drive down the cost when measured in megabytes of random-access memory (RAM), CPU load, or hardware components needed, but the design team will pay for this optimization with overall development cost and time to market. In addition to time, the size of the group increases as different specialists are needed for VHDL programming, DSP assembly language, real-time operating system (OS) integration, and control algorithms. Figure 2 shows the difference in complexity between system design software and a low-level, target-specific programming tool.
Time-to-market benefit calculations include more than simple revenue and profit over time. Earlier project completion can mean the difference between being first in the market and capturing a larger share; or being second to market with possibly a better product, but too late to be seen as the leader and therefore relegated to “me too” status. By simplifying complexity and placing design focus on the new IP rather than the optimization of common programming constructs, system design software helps engineers be first to market and have the best product.
– James Smith is director of embedded systems, and Brett Burger is senior product manager of embedded systems, National Instruments. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, firstname.lastname@example.org.
NI provides more about system design software at www.ni.com/embeddedsystems.
- Simplify complexity and place design focus on new intellectual property.
- Allow system design software to optimize common programming constructs.
- Better software tools for embedded systems help engineers be first to market and have the best product.
Speed and quality instead of speed or quality: Would you rather be first in the market and capture a larger share or second to market with possibly a better product, but too late to be seen as the leader