Why has code generation been so slow to be considered a de-facto methodto program embedded systems? Many do not realize that every time weboard a plane with loved ones, the code inside the aircraft's flightcontrol computer is not always hand written, but is often rather codedesigned through automated code generation techniques.
While most embedded applications are not mission critical, it begsthe question, “Why not use code generation techniques with everydayembedded application design?” You hear many dampening reasons; some saythe resulting generated code is not readable, some say it is notreliable. Others build a barrier by stating the code is too fat andslow for the cost optimized solution they are solving.
This paper applies a classical step-wise analysis to review issuesfacing auto-code generation by analyzing the pressures for change,defining how a vision for change will help generate momentum, openingthe capacity for change, and finally securing actions to actuallychange the ways we code embedded systems.
It is getting easier to find pressure points to push industry changesin the way embedded software is designed. Does the answer fall towardautomated C code generation, or to the idea that industry needs a newhigher level language? Some say industry just moved from Assembly to C.
Research groups explain that a major percentage of designs finishlate, with most delays due to software. There are some mixed emotionsto solving this problem, with some recommending outsourcing tolower-cost locations of the world.
Such short term tactics will help the corporate profitability, butwill not solve the challenges hampering proliferation of electroniccircuitry and software into our everyday life.
It is hard to find a product that does not have a chip and softwarewithin. Technology evolution and price allows 8-bit micro's to be usedin our bread toasters. The web's network effect on our life and theintertwined nature of electrical and mechanical control, which is oftencalled mechatronics, is squeezing 16-bit designs in favor of 32-bitprocessors.
A customer observation to the software engineering skill set inindustry seems to indicate a large base of existing software engineerswho call themselves embedded programmers are in reality microcontrollersoftware savvy, not microprocessor savvy.
Today's “typical” embedded system is not just an interrupt orloop-driven based application that is focused upon memory and CPUcycles. Typical systems today must be network aware, deterministicapplications, often including real-time input/output signalmanipulation, highly complex algorithms, and low power executionrequirements.
As one can guess, the software design in solving such devicerequirements is a step function in complexity.
Pressures to help drive change are often born within the academiccommunity, as it is there that some of the smartest minds can stretchour imaginations. Often, the academic community does not live with theadded financial pressure to deliver product revenue each quarter.
A leading example is the work from the Robert S. PepperDistinguished Professor and Chair of EECS, US Berkeley, Dr. Edward A.Lee. Working on a project called Ptolemy, Dr. Lee faces the challengeby asking if a new language is necessary for multi-coremicroprocessors, and if truly real-time computing is becomingunachievable?
In Dr. Lee's findings, he notes that real-time and concurrency areintegrally intertwined, however the application of threads limit thisgrowth while at the same time dominates concurrent softwaredevelopment. In another presentation he states that the problem is thattiming is not repeatable, except at course granularity, and non-trivialsoftware written with threads is incomprehensible to humans.
A final perspective on the mounting pressures for the way softwaredesign must change relates back to the term Mechatronics.In the past,and still today, many design teams try to tie the electrical,mechanical and software aspects of product design together throughintegrated rounds of prototyping. Given time-to-market pressures anddesign time costs, many have realized this method as a luxury of thepast.
Mechatronics requires use of a concept called algorithm engineering.Algorithm engineering incorporates real-world data and situations, suchas real-world I/O signals from simple devices like pressure, to complexdynamic signals such as sound or RF, with system architectures early inthe process to ensure a more accurate result and shorter design cycle.
It is very challenging to use today's programming methods withcross-functional design because the teams can not communicate with acommon understanding to the programming language details.
The Clearly Defined Vision forChange
With the multitude of pressures design engineers face, how does onechange? The only way change will transpire is with a clearly definedvision. Visionary leaders with visionary ideas are required to point usforward together. Visionary leaders help the human nature, as we arecreatures of habit and association.
Reviewing Dr. Lee's work one can find much visionary material. Theauthor's under standing of Dr. Lee's message points toward the need ofa new S-curve software language adoption which can abstract complexity.As an analogy, C abstracted much of the complexities using assembly.
Another inspiration pointed to the need for coordination languagesthat complement rather that replace existing languages, enabling asmoother transition path. So what is the answer? Some say it's not anew mouse trap, but a better mouse trap.
In terms we often hear today, it may be called model-based design(MBD) or model-driven design (MDD). It may also be what you hear calleddomain specific languages (DSL). You will find each valid options withmerit and pitfalls.
Model Based Languages
Using model-based design (MBD) or model-driven development (MDD) toachieve coordination though automated code generation is not a newfield of study. One type of MDD is UML. UML stands for unified modelinglanguage. Its first use in the production setting was for executablespecification. Many think of UML for object oriented modeling andautomated code generation based upon C++.
Designers can also apply UML under a functional-based abstraction,the reason being most real-time embedded applications arefunctional-based. Software engineers are very comfortable withtraditional concepts of files, functions and variables, as compared toclasses, operations and attributes. A challenge for UML is that UMLdiagrams are not understood by many.
By itself, UML is a breakthrough because it enables better crossdepartment communication and elimination of errors. The model code canserve as a focal point from which documentation and direct codegeneration can be generated.
However, UML uses direct programming concepts, for example returnvalues and classes, as modeling constructs. Having a block represent afunctional-based model or class, then represented in textual codebrings the level of abstraction and code to the same level. As aconsequence, engineers often wish to simply write the code directly.
Languages that connect the language to the domain problem at handoften are referred to as Domain Specific Languages (DSLs). Industryoften lumps different types of DSLs into the category called ModelBased Design.
DSL's define a shared vocabulary along with the rules of whatinformation and elements must be communicated. The MATRIXx xMathenvironment is a mathematically-based modeling DSL many use in school.
With this DSL, the model elements represent the domain world not thecoding world. The scripting language follows the domain abstractionsemantics, allowing the user to work in their world of thinking. Aclose alignment of the language and problem needing solved offersbenefits including productivity, hiding complexity, and quality.
Another example of a DSL that can be used for auto code generationis MATRIXx AutoCode. MATRIXx AutoCode offers both simulation andmodeling capabilities and is an example DSL most often used by those incontrol engineering tasks who model in terms of continuous-time.
The goal is to allow one to mathematically model the systembehavior, design the base algorithm software while modeling thensimulate the model. Once the model of the algorithm is created,traditional C code can be generated and loaded into traditional C IDEdevelopment tools.
Solving the Time and ConcurrencyChallenge
The Ptolemy Project at Berkley pointed to a way of helping abstract thechallenges threads bring to concurrent programming, which many DSL'shave not solved. Dr. Lee indicates that imperative languages are fineif the problems with threads can be fixed.
One way is at the component level. By component architecture hemeans moving from object-oriented to actor oriented program flow. Dr.Lee's explanation said that sequential control is what flows through anobject in object oriented code, that is, things happen to objects. Incontrast, actor oriented languages flow evolving data through anobject, meaning actors make things happen.
An example of an actor oriented language is LabVIEW. The mainuserprogramming model of computation in this approach is structureddata-flow. Other supported models of computation include statediagrams, control diagrams and MathScript. MathScript addsmath-oriented, textual programming to LabVIEW.
The actor-oriented structured data-flow provides an interactiveenvironment for dynamic systems modeling, controller design, andoff-line simulation. Figure 1 below showsan example of using this structured data-flow approach with MathScripttext code and control design, all within the dataflow language.
|Figure1. Simulation Loop using Control Design and MathScript|
Where C requires explicit ordering of each call or assignment, anddemands variable reuse be written into the algorithm, the actor-basedapproach only requires the user specify the dataflow paths with aVirtual Instrument (VI) in LabVIEW terms, between the functional units.
A procedure is represented by an icon with wired inputs/outputs- anode. This function is then analyzed at compile time to determine howall nodes can be ordered and parallelized for execution on the specifictarget, processor or FPGA, thus taking the component of time andconcurrency into consideration.
Shifting to a data-flow mindset from C requires a small shift inthinking regarding algorithms, tasks and inter-task communication.Straight C calculation is replaced by dataflow across numericprimitives in containers such as a While Loop or Case Structure, withsub-VIs taking on the role of user defined procedures in C.
Task creation and timing are accomplished through Timed Loops andwait primitives rather than direct RTOS calls, for example to createprocesses, go to sleep, or configure interrupts.
Finally inter-task communication in C works by making RTOS calls forshared memory, semaphore, or message-based pipes. These samecapabilities are available in LabVIEW through FIFO and shared variableprimitive sets.
Actor oriented languages allow for a high level of abstraction sothe end code can be deployed to multiple targets. Figure 2 below shows the LabVIEWFPGA block diagram for a simple PWM generator. The fact that the U8data type is used makes this a 8-bit timer to define on/off state. Withaccess to the FPGA one can write their own PWM implementation andconfigure their own PWM “chip” on part of the FPGA.
|Figure2. LabVIEW FPGA PWM Generation|
Figure 3 below shows thesame data-flow language used for a real-time, multi-core processordesign. In this example, the code can be configured to auto-loadbalance on multiple processors or assigned to a specific resource. Thedesigner has the capability to specifically choose which core a giventask should run. For example, a time-critical task can be dedicated toits own core.
The value of higher level languages in addressing such advancedparallel execution system complexity is that multi-core and real-timecan be represented simply by placing two independent loop structures ona diagram. Each loop operates independently, while also having timingand CPU designation controlled by configuring the left part of theloop.
|Figure3. Using multi-core processors and LabVIEW Timed Loop execution|
This same structured data-flow code can be simultaneously translatedinto traditional C-code if the designer wishes, but the nature of thelanguage is to provide a higher level perspective, including theability to easily add existing C-code or IP.
A key aspect of LabVIEW is that the language encompasses thealgorithm creation, as with other DSL tools, while at the same timesolving the low-level kernel, interrupt and execution complexities.From an embedded engineering perspective, the graphical language alsosolves the memory, threads, semaphores, and I/O issues that thetraditional C coders must tackle.
Obviously, with high-level tools, deeply embedded engineers willraise concerns about footprint or performance, but those are the kindof problems that get solved naturally over time, as the industry isalready seeing with the almost daily innovations in silicon.
Open Capacity for Change
Once a vision is understood, how does the industry open the capacityfor change? This is accomplished by expanding the installed base ofusers that are capable of programming real-time embedded systems. Thisis exactly what happened during the transition from assemble to the Clanguage for embedded design.
The existing coders dug their feet into the ground and cried thatthe sky was falling, mostly because we engineers are creatures of habitand often resist change. The C language delivered a whole new set ofusers capable of designing embedded code.
The good news is that the use of higher-level autocode generationtools will dramatically increase the overall accessibility of embeddeddesign to many engineers, scientists, and domain experts. Some vendorssuch as National Instruments are calling this new market GraphicalSystem Design (GSD).
Graphical System Design provides highly productive system-levelverification tools that are open to existing languages and technologiesas well as an efficient path to implementation for various targets,including heterogeneous real-time and FPGA platforms.
This article is focused upon the lack of adoption surroundingauto-code generation, but it's more complex than one dimension. Systemlevel complexities born from the evolution of today's processor such asmulti-core and system-on-chip require one to look at the entire designflow challenge.
If industry can transition to higher-level tools, an ecosystem ofsuppliers become empowered to create off-the-shelf prototyping hardwarewith configurable, extensible processors, allowing designs to achievetime-to-market goals. In particular, integrated platforms will emergeand prove to be more flexible and application-adaptable substitutes forcustom hardware, while achieving acceptable performance and power.
In the end, Graphical System Design will be able to add algorithmdevelopers, scientists, system engineers, and other domain experts tothe embedded pool, creating 10X more people capable of deliveringproduction ready solutions.
Now comes the hard part, defining the actions to bring auto-codegeneration to a reality. Doing something new and outside the comfortzone is not easy.
So what is a manager to do? Take time to test a project with higherlevel tools and document a valid review. Traditional embedded engineersneed to open their eyes or face the consequence that they will be adieing breed down the road.
Finally, we could just let it get worse; letting projects growlonger, blame outsourcing, blame silicon and tool suppliers. Engineerscan be skeptics. The end challenge may boil down to the simple factthat we are creatures of habit.
Case in point about the author– the traffic in Austin, Texas isvery congested due to growth. Each day, it can take 50 minutes or moreto make a simple19-mile journey to the National Instruments' campus.One morning, due to a traffic accident, an alternative route lead to ashorter daily commute.
The story's moral, like most people it is easy to go on autopilotand often start down the same old road without thinking about a newshorter path. The embedded design industry can not wait for a wreck inthe road.
In conclusion, the pressures on embedded design engineers is great,and it will not go way in a competitive winner takes all industry.Silicon technologies continue to advance at Moore's Law, but it seemsnew software design methods are lagging behind.
The advancement and pressure to attempt change can be great which iswhy industry needs a clear vision and capacity for change. In the end,change will not happen unless action is made. This action for softwaredesign methods means defining an active project to use high-levels ofsoftware abstraction with higher-level software tools.
As industry moves forward, a whole new set of tools based uponGraphical System Design will emerge to help efficiency, reduce time tomarket and bring embedded technologies to our everyday lives.
Greg Crouch is Embedded SystemsBusiness Director at National Instruments.
1) Edward A. Lee, “Is TrulyReal-Time Computing Cecoming Unachievable”, UC Berleley, Berkeley, CA,Real-Time and Embedded Technology and Application Sympsoium (RTAS),April 3 2007
2) Edward A. Lee, “Are newlanguages necessary for milticore?”, UC Berleley, Berkeley, CA, PanelStatement for Panel International Symposium on Code Generation andOptimization (CGO), March 11 2007
3) The Ptolemy Project at http://ptolemy.org
I agree that autocode has a ways to go in acceptance and use for embedded applications. However, since embedded autocode tools (non-embedded autocode tools existed before this) started to become “popular” in the mid 1990s, significant progress has been made. I see even more progress being made in the next few years as I am personally helping two of my clients transition from using model-based tools and autocode in a research only application to production applications with hundreds of developers. This autocode should be on the road and in the air in the near future. While autocode is a great technology, don't forget the rest of the process, such things as modeling style (not all styles produce efficient code), automatic test generation, formal methods, requirements traceability, and other tools to make a complete software development process.
self-proclaimed pioneer in using model-based tools for embedded software development
Software Beret Inc
The author states: “The good news is that the use of higher-level autocode generation tools will dramatically increase the overall accessibility of embedded design to many engineers, scientists, and domain experts.” I imagine that many embedded software developers don't necessarily consider this “good news” as their livelihoods depend on their abilities to turn someone's ideas into code. Many will cite the fear of inefficient or bloated machine generated code, while the real fear is one of becoming obsolete. While I think the proliferation of auto-code generation tools is inevitable, the average coder will move forward with great reluctance.
I would like to share my experience with auto code generation technology.
In last 5 years, I have worked with two automotive suppliers in area of model-based design and auto code generation.
First, organization moved from less than 10% autocoded modules to 70% autocoded modules in a complex ECU within 2 years time. The success is attributed to well-defined process and visionary leadership/managers.
Second, organization is still struggling to include auto code generation technology even after five years of effort. The failure is attributed to lack of vision of managers driving the technology introduction, lack of trained/skilled engineers. In this organization, people will try to fine-tune autocode to match their decade end coding standard, which in general needs to be updated.