While the definitions of ESL may vary, the end result should be the same, namely letting system developers analyze their designs at a higher level of abstraction.
A recent Google search on “electronic system level” yielded more than 86,900 results (and growing daily), quickly demonstrating how much information is available on this topic. But despite the abundance of buzz, it's not always easy to find a clearcut explanation of what this design method encompasses and how it applies to embedded systems design. From the broadest perspective, electronic system level (ESL) design consists of tools and methods that enable designers to describe and analyze ICs at a high level of abstraction.
This original definition was targeted at high-end chip designers. If you look at a concept introduced by Wired 's Editor in Chief Chris Anderson called “the long tail,” these high-end applications fit into the “head” as more high-volume and vertical applications.1 This concept is visualized in Figure 1.
While many designers live in the head, where deployments are made in high volumes, the rest of the embedded systems engineering world lives by a different set of rules–often developing applications in the long tail. Long-tail applications rarely have the sales volumes needed to justify large up-front investments in time or resources to develop a full, custom IC. This may be because these applications are either new (just being conceived or researched by domain experts) or new variations of existing concepts.
Fortunately, significant advancements in programmable hardware, specifically in logic density, area, power, and speed, have enabled a larger set of these long-tail applications to develop the hardware needed to satisfy the ever-growing requirements of embedded systems. Furthermore, tool vendors now offer value-added, off-the-shelf prototyping tools based on the programmable hardware that are appropriate for quickly iterating on early ideas, allowing more exploration and simulation of the different components. These prototyping tools involve peripherals beyond chip design, including I/O, driver and application software, and prototype hardware. Yet such prototyping hardware alone doesn't enable long-tail development. To really take advantage of such prototyping hardware for these complex applications, developers need an updated set of development tools.
Let's revisit some of these tools along with the categories that were originally defined for ESL:2
- Design and simulation.
- Behavioral synthesis.
- Test and verification.
Design and simulation
This category encompasses several steps of the design process, including algorithm design, system simulation, and analysis. Thinking about algorithm design, we can already identify some of the challenges associated with ESL in practice. Algorithm “design” is a very theoretical approach to solving a problem. A small number of researchers in the world today have the luxury of theorizing about tough problems in a lab and working on nontraditional application designs. The majority of design engineers, however, have deliverables with deadlines that need to be met. Hence, to give design engineers something they can actually use, you must combine algorithm design from early stages with prototypes and I/O. Let's call this algorithm engineering.
Algorithm engineering is a design process that incorporates real-world data and situations such as I/O signals and system architectures early in the process to ensure a more accurate result in a shorter design cycle. As shown in Figure 2, algorithm engineering can be broken into a few steps for clarification:
- Goal: establish high-level desired attributes/customer expectations.
- Idea: come up with architecture/target algorithm.
- Design: tailor algorithm/architecture to fit requirements.
- Prototype: build preliminary system to enable validation.
- Deploy: deploy design to target hardware.
Doug Jones, professor at the University of Illinois at Urbana-Champaign, used algorithm engineering to help solve a complex signal-processing challenge that involved designing a frequency domain minimum variance (FDMV) beam-forming algorithm to suppress background noise to improve hearing-aid performance. By tightly integrating real signals into the early algorithm designs, he could more quickly iterate and refine the application.
System simulation and analysis is another stage addressed early in the ESL design process. Often, these steps are presented by software-only vendors as software-only functions in the design process. Many vendors claim that you can design the entire system in software through simulations and analysis and save money on building or buying prototyping hardware. This approach can prove to be detrimental to the final system design as demonstrated in devastating examples that include the NASA Columbia space shuttle crash, the Chinook helicopter disaster, Airbus, and recent Toyota safety issues.3, 4, 5, 6 To truly benefit from simulations, which include the simulation of linear, nonlinear, discrete, and dynamic system and circuit simulations, you must be able to quickly implement your dynamic systems with real-time I/O and ideally COTS hardware.
Behavioral synthesis is often described as an enabling technology for implementing a practical methodology for high-level design, usually of an eventual register transfer level (RTL) implementation. As a definition for chip design, behavioral synthesis can be selectively applied to portions of a design that will derive the greatest benefit from using a higher level of abstraction and automation.
To be more specific and useful for designers of long-tail applications, behavioral synthesis can be generally described as behavioral prototyping. A popular (and growing) option for rapid prototyping involves using field-programmable gate array (FPGA)-based, off-the-shelf prototyping platforms. Advanced rapid prototyping systems powered by FPGAs provide the ability to create highly configurable working proof-of-concept implementations that can be tested and evolved in the field, even for mobile applications that demand a rugged battery-powered form factor. Combining FPGA platforms with high-level graphical tools that are open to text-based RTL code in C or HDL tools yields a productive and appropriate toolset for creating effective behavioral prototypes.
Behavioral prototypes are useful when you want to easily build real-world implementations of any control or plant model for rapid control prototyping, hardware-in-the-loop (HIL) testing, or final deployment. Through this process, you can improve control design by adding real-world I/O to early designs and reuse testing software and hardware from the design and verification stages when developing system and manufacturing tests, saving time and development cost.
Test and verification
For high-end applications, test and verification usually includes the tools offered by EDA vendors. However, for the long tail, test and verification is traditionally used later in the development process on the manufacturing line and other areas. Automated test-bench technology and mindsets should be used earlier in the design cycle for validation, verification, and iterative design. For example, using PC-based data-acquisition devices, algorithms can easily be connected to real-world I/O signals for validation. For algorithm-in-the-loop and DSP verification, PC platforms can also be booted into a real-time operating system with minimal additional effort.
Who uses ESL?
There seems to be clear agreement on the importance of ESL design and verification, especially in the actual use of ESL concepts. EDA analyst Gary Smith predicts that the market for ESL is moving from semicconductor design to embedded FPGA/microprocessor design.7 In a recent ESL usage study, Celoxica saw the following results:8
- 52% of hardware designers (including several nontraditional hardware designers, such as system engineers and algorithm developers) agree that they will increase their ESL usage.
- 50% of algorithm developers and system engineers will be using ESL.
Increasingly, embedded system design is turning to the use of high-level tools and off-the-shelf prototypes with configurable, extensible processors in an effort to achieve time-to-market goals and provide flexibility and programmability for reuse of complex platforms. In particular, integrated platforms are proving to be more flexible and application-adaptable substitutes for custom hardware in many designs, while achieving acceptable performance and power. As result of this shift to an increasingly processor- and multiprocessor-centric design style, the need for architecting and designing embedded platforms at higher abstraction levels than traditional methods allow grows more urgent.
Overall, engineers are asking for higher-level tools and integrated hardware platforms to effectively deal with their challenges. Graphical system design provides highly productive system-level verification tools that are open to existing languages and technologies as well as an efficient path to implementation for a various targets, including heterogeneous real-time and FPGA platforms. Built-in graphical abstractions free the designer from the constricting modeling syntax required by strict ESL tools, allowing complex design concepts to be represented and implemented with a high degree of efficiency. For example, a system-level designer can easily represent a 16-bit counter in an FPGA with a simple block diagram. A Labview FPGA block diagram is implemented in hardware, which gives you direct control over the reconfigurable I/O device. You can analyze and manipulate I/O signals in ways that aren't possible with fixed I/O hardware. Figure 3 shows the LabView FPGA block diagram for a simple rising-edge counter. The fact that the U16 data type is used makes this a 16-bit counter. On a typical data-acquisition board, the counter logic is implemented in a fixed ASIC. With access to the FPGA, however, you write your own counter implementation and configure your own counter “chip” on part of the FPGA.
In a similar fashion, you can include your existing IP into graphical system-design applications. For example, Xilinx' System Generator for DSP is a software package that can be used in conjunction with a tool like Labview to achieve fast digital signal processing on reconfigurable I/O (RIO) hardware devices that contain Xilinx Virtex-II FPGAs. Figure 4 shows combining multiple computing models as a helpful abstraction technique for effective ESL implementations.
These examples of using a graphical system design language show the power of ESL design combined with graphical system design. In addition to an easy-to-use and highly productive language for design, it also gives designers a complete set of advanced graphical tools for data analysis, visualization, algorithm development, and implementation through already-integrated hardware platforms.
The good news is that the use of graphical system design will dramatically increase the overall accessibility of embedded design to many engineers, scientists, and domain experts. As the Celoxica study also pointed out, if you add algorithm developers, scientists, system engineers, and other domain experts, 10X more people will be using ESL and graphical system design, well beyond the current $4 billion annual market.
Challenges with ESL
As we've seen, ESL is just a part of the larger picture. To recap, we've seen that ESL needs to incorporate the concept of algorithm engineering early in the design process to ensure more system accuracy and shorter design cycles. A similar gap is found in the simulation step. For critical applications, I/O supplementing is vital to proper and reliable system behavior, and simulation-only designs can be dangerous when unpredictable “real-world” effects are omitted.
In prototyping, ESL is defined as basically anything working in an abstraction level above RTL. Is that enough? Don't we need more than “just above RTL?” Today's complex systems need access to the latest technologies and platforms such as heterogeneous processor and FPGA systems and a deep set of ready-to-use IP.
Another fundamental challenge with ESL is the ability to address more complex issues, including describing parallelism. Many ESL definitions center around sequential C-based languages. In a recent Design Automation Conference panel discussion, the moderator and panelists addressed this specific issue, asking “Aren't there always going to be problems using C-based languages to describe parallelism?”9 When developing software that takes advantage of the computing power of multicore processors that represent complex, concurrent applications, you need development tools that inherently provide parallelism. Because of their sequential nature, text-based programming languages, such as C and C++, require you to call functions to programmatically spawn and manage threads. It's also often difficult to visualize how various code sections run in parallel because of the sequential, line-by-line syntax of text-based languages.
In contrast, graphical programming environments can easily represent parallel processes because data flow is inherently parallel. It's easier to visualize parallel code execution in a graphical environment, in which two parallel execution paths of graphical code reside side by side.
The bigger picture
ESL needs to be combined with graphical system design to address long-tail challenges. Graphical system design is a complementary but encompassing approach that includes embedded and electronic system design, implementation, and verification tools. ESL and graphical system design are really part of the same movement–higher abstraction and more design automation looking to solve the real engineering challenges that designers are facing today–addressing design flaws that are introduced at the specification stage to ensure they're detected well before validation for on-time product delivery.
We need to make sure we aren't focused on theoretical-only topics, but instead we need to use integrated hardware platforms and intuitive software tools to implement, iterate, and improve even the most complex designs. This is done through high-level graphical system design software and commercial off-the-shelf rapid prototyping hardware that improve every stage of development, from the earliest stages of design and simulation, to prototyping the system with real-world I/O signals and hardware, to deploying the embedded software on a chosen processor target. The graphic system design approach shortens the design cycle by providing domain-specific engineering libraries, embedded software development tools, and dynamic simulation capabilities directly with integrated hardware platforms for rapid prototyping, system deployment, and verification.
Shelley Gretlein is the Labview real-time and embedded team manager for National Instruments. Gretlein joined National Instruments in 2000 and holds a BS in computer science and management systems from the University of Missouri-Rolla. She can be reached at .
1. Anderson, Chris. “The Long Tail,” Wired Magazine , October 2004. www.wired.com/wired/archive/12.10/tail.html. Chris Anderson has also written a book and maintains a blog on the subject: www.thelongtail.com/about.html.
2. Gary Smith, former chief EDA analyst of Gartner Dataquest, defined these categories. See “Tool vendors dispute report of downturn in ESL” by Richard Goering, EE Times , posted December 20, 2004. www.eetimes.com/showArticle.jhtml?articleID=55800416
3. CAIB report, Volume 1, August 2003, p.52. Available at http://i.a.cnn.net/cnn/SPECIALS/2003/shuttle/CAIB.report.pdf or at http://caib.nasa.gov/
4. Rogerson, Simon. “The Chinook Helicopter Disaster,” originally published as ETHIcol in the IMIS Journal . Volume 12 No 2 (April 2002). www.ccsr.cse.dmu.ac.uk/resources/general/ethicol/Ecv12no2.html
5. Matlack, Carol. “Airbus: First, Blame the Software,” Businessweek Online, posted October 5, 2006. http://yahoo.businessweek.com/globalbiz/content/oct2006/gb20061005_846432.htm>
Duvall, Mel and Doug Bartholomew. “PLM: Boeing's Dream, Airbus' Nightmare” Baseline magazine, posted online February 5, 2007. www.baselinemag.com/article2/0,1540,2089789,00.asp
“In addition to the problem encountered with wiring on the A380, Airbus also suffered another setback in February 2006, when a wing on the giant 550-seat aircraft snapped during a stress test. Software modules integrated with CAD systems are meant to simulate stress and catch possible failure points before components go into production. But Airbus said that during the last step of testing in February, where the wingtip is bent more than 24 feet away from its normal position, a rupture occurred between two engines. It did not provide further information on why the rupture could not be prevented through stress simulations; however, Airbus said the rupture would not result in major delays and could be corrected with “refinements” to the design.”
6. Shirouzu, Norihiko. “Toyota May Delay New Models To Address Rising Quality Issues,” The Wall Street Journal , August 25, 2006; and “Toyota Ties Quality Issues To Rushed Work,” The Wall Street Journal , December 13, 2006. “http://online.wsj.com/public/us
7. Goering, Richard. “Analyst Gary Smith: top 10 EDA topics for 2007,” EE Times , posted December 28, 2006. www.eetimes.com/showArticle.jhtml?articleID=196702472
8. Article on Celoxica study appears on SOCcentral.com. “Survey Shows 'Hidden' Market for ESL and FPGAs,” August 31, 2005. www.soccentral.com/results.asp?CategoryID=199&EntryID=15866