Advertisement

Blog

Step Up to C for Embedded R&D

We are all eager to lower the cost of embedded system design while increasing quality and decreasing time-to-market. However, as embedded systems become more complex and sophisticated, the traditional design process is taking up too much time. It is simply not agile enough to achieve the results as rapidly as we need.

Since the 1990s, efforts to improve the R&D of embedded systems using hardware/software co-design have yielded limited co-development processes. The R&D has tended to center on specific types of hardware design, and still with separate departmental teams involved; hardware and software. As a result, prototypes still require an integration phase, along with the risks that this process incurs, and multiple coding languages are used, resulting in a constant need for recoding.

The starting point for a more agile approach to development is to work at a higher level of abstraction, in this case, ESL, or electronic system level.

By taking advantage of the SystemC library definitions and TLM-2.0 interface standards — both part of standard IEEE 1666 — we can use a single language: C/C++. This allows us to create a fully-modeled, functional software representation of a hardware/software SoC design based on a mix of processors, software, communication links (AXI interconnects), memories, and other IP cores. Thus, the various tasks of the requested embedded application can be implemented in the SoC as either hardware or software, according to quality-of-results (QoR) requirements based on performance, power consumption, and hardware resource utilization, following a true hardware/software co-design approach.

Under this approach, the hardware/software co-design process is conducted from the very start of a SoC embedded system project. The application is first broken down into multiple tasks; otherwise, a single large task will end up as a single software or hardware implementation without the benefit of optimization. Before introducing details of any target architecture platform, the tasks need to comprise an algorithm that is a functional specification of the application, which must be validated through behavioral simulation.

Once the algorithm is deemed sound, the functional specification is then mapped to an initial design configuration, for a chosen architecture platform of processors (including RTOS) and interconnects. Some tasks will be targeted for software implementation while others will be targeted for hardware. A design exploration process ensues, where successive design configurations are analyzed based on QoR constraints. Real co-design takes place while exploring different design configurations and adjusting the hardware/software partitioning.

This process can be facilitated by an automation technology, which retargets the same C/C++ models from hardware to software, or vice-versa, without recoding for the other medium, resulting in a rapid and agile process.

With the efficiency of using the same models to create hardware and software implementation of an SoC embedded system, and the speed of simulating ESL models for performance analysis of each candidate, it is possible to converge rapidly on a design that fulfills QoR goals. If not, one must examine the ability of the chosen architecture platform and decide which changes to make — for example, choose another processor from within the same instruction set architecture or change the platforms outright.

Even then, the rapidity of using this agile approach results in a loop of mere hours, if not days, rather than weeks using RTL-based approaches.

When a viable configuration is found, the next step after implementation is realization. At this phase, we seek to drive downstream implementation tools such as the Xilinx Vivado tool suite or Altera's Quartus II. The new Xilinx All Programmable Abstractions initiative highlights a number of tools that can be driven this way, such as HLS (high level synthesis) for silicon realization after design creation, using true hardware/software co-design as I have described above.

In summary, using the suggested method, the hardware and software design is highly unified compared to designs made using current methodologies. In this paradigm, embedded system design becomes so rapid that there is no need for an explicit prototyping phase — instead, you can start working on your product implementation on day one, and proceed with incremental refinement. This is a process where there is no longer need for multiple design languages, design teams, and models, where the recoding of functions for hardware or software is a thing of the past.

The approach is practical and the entire process has been realized by the author's company using the Xilinx Zynq “All Programmable SoC” platform.

— Guy Bois is a professor at École Polytechnique de Montréal and Director of the GRM2 Laboratory, where the SPACE program (SystemC Partitioning of Architectures for Co-design of Embedded Systems) was originally conceived. Guy's expertise in leading his research lab has extended to guiding the launch of SpaceStudio from Space Codesign Systems Inc.

Editor's note: This article originally appeared on EETimes.

1 comment on “Step Up to C for Embedded R&D

  1. t.alex
    November 3, 2013

    This is definitely a very interesting approach wherein we can develop and try out various solutions since day 1. I have the following questions hopefully the author can clarify more:

    – This approach can only work on FPGA ?  Will it consume a lot of power? And what kinda applications are most suitable using this approach?

    – How about the skillsets of developers. Must all the developers know about hardware design as well as software design or we can hire hardware and software guys separately.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.