ESL Explained

Publish Date: Dec 28, 2015 | 13 Ratings | 3.23 out of 5 | Print | 1 Customer Review | Submit your review

Table of Contents

  1. Design and Simulation
  2. Behavioral Synthesis
  3. Test and Verification
  4. The Necessity of ESL
  5. Challenges with ESL
  6. The Bigger Picture

ESL is another acronym flooding inboxes these days. What does this term mean and how does it apply to engineers and scientists? Generally, electronic system level (ESL) design and verification provides tools and methodologies you can use to describe and analyze chips on a high level of abstraction.

The original definition targeted the high-end chip designers or applications and developers in the “head” of the long tail as introduced by Chris Anderson, editor-in-chief of Wired magazine, in a 2004 Wired article.

Figure 1. The long tail is a way to describe specialty or niche applications in many industries.

However, many engineers and scientists work in the long tail, developing specialty machines, new devices, and lower-volume deployments. The long tail applications rarely have the sales volumes to justify large up-front investments in time or the resources to develop a “full” chip. This may be because these are new applications in the initial conception and research stages, or because they are new variations on an existing concept. Fortunately, significant advancements in programmable hardware logic density, area, power, and speed have enabled a larger set of these applications and the development of the hardware necessary to satisfy the ever-growing requirements of embedded systems. Furthermore, vendors such as National Instruments are now offering value-added, off-the-shelf prototyping solutions based on the programmable hardware appropriate for iterating quickly on early ideas, allowing more exploration and simulation of the different components. National Instruments LabVIEW embedded software including NI LabVIEW Real-Time and LabVIEW FPGA, combined with National Instruments CompactRIO embedded measurement and control hardware, is an example of a platform that involves peripherals beyond chip design including I/O, driver software, application software, and prototyping. This combination can be applied to a new definition of ESL to better address the needs of a “long tail” system designer.

The ESL categories originally defined by former chief EDA analyst at Gartner Dataquest, Gary Smith, include:

• Design and simulation
• Behavioral synthesis
• Test and verification

1. Design and Simulation

Design and simulation encompass several steps of the design process, including algorithm design as well as system simulation and analysis. Looking at algorithm design, you can already identify some of the challenges with the original definition of 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 and working on nontraditional application designs. However, the majority of design engineers have deliverables with deadlines that need to generate solutions and products. That means to give you something you can actually use, you have to combine algorithm design with prototypes and I/O. This is called algorithm engineering.

Algorithm Design and Prototype Implementation = 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 more accurate end results in a shorter design cycle.

Figure 2. Algorithm engineering combines algorithm design with real I/O to dramatically speed your design process.

System simulation and analysis is another stage addressed in the ESL process. Oftentimes 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 system design. To truly benefit from simulations, which include the simulation of linear, nonlinear, discrete, and dynamic system and circuit simulations, you need to be able to quickly implement your dynamic systems with real-time I/O.

Back to Top

2. Behavioral Synthesis

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 derive the greatest benefit from the use of a higher level of abstraction and automation.

To be more useful for designers of long tail applications, behavioral synthesis could be described as behavioral prototyping. A popular option for rapid prototyping involves the use of 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 you can test and modify 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. LabVIEW FPGA provides this ability. You can easily import existing HDL code into the LabVIEW FPGA graphical block diagram to combine graphical programming with low-level code.

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 costs.

Back to Top

3. Test and Verification

For high-end applications, test and verification usually include the tools offered in the electronic design automation (EDA) market. However, for lower-end designs, the test and verification step is traditionally used later in the development process on the manufacturing line and other areas. Automated test bench technology should be used earlier in the design cycle for validation, verification, and iterative design. For example, you can use PC-based data acquisition devices to easily connect algorithms to real-world I/O signals for validation. For algorithm-in-the-loop and DSP verification, you can boot PC platforms into a real-time operating system with minimal additional effort.

Matthew Viele from Woodward Governor explained how his company realized the benefits of combining simulation, I/O, and test/verification.

“By simulating the outputs of an engine in response to inputs from the controller, we accomplish HIL testing of the controller without an engine present. It also helps us simulate conditions that may be difficult to achieve with a real engine in a test cell, such as running at the limits of expected use. In addition to simulating normal operating conditions, the test system simulates fault conditions by shorting and opening signal paths.”

He also noted that “the increased control of I/O timing and synchronization combined with rapid onboard decision making for output generation is vital to simulating an engine in real time. We can now build and modify a test system that best meets all of our electronic control unit (ECU) testing needs.”

Back to Top

4. The Necessity of ESL

With all of that said, it seems that everyone agrees on the importance of ESL design and verification as more and more designers (hardware and system designers alike) increase their usage of ESL concepts for future applications.
Overall, engineers are asking for higher-level tools and integrated hardware platforms to effectively deal with challenges. Graphical system design is a complementary approach to ESL. It 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 variety of targets, including heterogeneous real-time and FPGA platforms. Built-in graphical abstractions liberate the designer from the constricting modeling syntax required by strict ESL vendors, 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 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 are not possible with fixed I/O hardware. Figure 3 shows the block diagram for a simple rising-edge counter. The fact that the U16 datatype is used makes this a 16-bit counter. On a typical data acquisition (DAQ) board, the counter logic is implemented in a fixed ASIC chip. With access to the FPGA, however, you write your own counter implementation and configure your own counter “chip” on part of the FPGA.

Figure 3. Implement a simple rising-edge counter with LabVIEW FPGA and gain direct control over your hardware logic.

In a similar fashion, you can easily include your existing IP in graphical system design applications. For example, Xilinx SystemGenerator for DSP is a software package you can use with a tool such as LabVIEW to achieve ultrafast digital signal processing (DSP) on NI reconfigurable I/O hardware devices that contain Xilinx Virtex-II FPGAs.

 These examples using the LabVIEW graphical system design language show the power of ESL design combined with graphical system design. In addition to this easy-to-use and highly productive graphical system design language, designers have a complete set of advanced graphical tools for data analysis, visualization, algorithm development, and implementation through previously integrated hardware platforms.

The increased use of graphical system design will dramatically expand the overall accessibility of embedded design to many more engineers and scientists.

Back to Top

5. Challenges with ESL

As previously discussed, ESL is really just a part of the larger picture. Remember that in design, ESL needs to incorporate the concept of algorithm engineering and design validation earlier in the design process to ensure more system accuracy and shorter 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 very 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? Do engineers not need more than “just above RTL”? Today’s complex systems need access to the latest technologies and platforms such as heterogeneous processors 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 definitions of ESL center on C-based languages. When developing software that takes full advantage of the computing power of multicore processors or needs to represent complex, concurrent applications, you need a development tool that inherently provides parallelism. In contrast to text-based programming languages such as C and C++, graphical programming environments such as LabVIEW can easily represent parallel processes because data flow is inherently parallel. It is considerably easier to visualize the parallel execution of code in a graphical environment where two parallel execution paths of graphical code reside side by side.

Back to Top

6. The Bigger Picture

The concept of ESL needs to be combined with “long tail challenges.” Graphical system design is a complementary but encompassing approach that includes embedded and electronic system design, as well as 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 introduced at the specification stage to ensure they are detected before validation for on-time product delivery. Engineers not only need to focus on theoretical topics but also use integrated hardware platforms and intuitive software tools to implement, iterate, and improve even the most complex designs. This is done by using high-level graphical system design software and commercial off-the-shelf rapid prototyping hardware, which improve every stage of development. The approaches shorten the design cycle by providing domain-specific engineering libraries, embedded software development tools, and dynamic simulation capabilities with integrated hardware platforms for rapid prototyping, system deployment, and verification. Finally, using ESL techniques for “long tail” applications through graphical system design approaches can lead to product transition from the ‘tail’ to the “head.” For example, once your product is proven, you can either retarget or migrate the already high-quality design to an even more rigorous flow.

Back to Top

Customer Reviews
1 Review | Submit your review

Wrong edge counter diagram  - May 7, 2007

I believe that code will count both rising and falling edges - not just rising. - Brad

Bookmark & Share


Rate this document

Answered Your Question?
Yes No