Introduction
Stop at any booth at the Embedded Systems Conference and you'll see a demo of the latest and greatest tool for accelerating the time to market for your latest project. Just like Moore's Law has accurately predicted the growth of complexity of integrated circuits over the last 30 years or so, numerous studies have demonstrated exponential growth in embedded code size and complexity over the same period of time. Through each new project cycle, embedded systems designers are being faced with shrinking project schedules, increasing expectations of productivity improvements, pressure from offshore developers and the certain guarantee that the next project will be more complex than the previous one.

What's a poor developer to do? One solution that has been touted for several years are graphical design tools such as Statemate from Telelogic and ObjecTime from IBM. These are graphical design languages that generate embedded code from graphical software structures that generally follow the design rules of the Unified Modeling Language, or UML. However, general adoption of these tools, even though they hold the promise of freeing the designer from the low-level tasks of creating software, has been slow. While it is not the focus of this article to examine the reasons for the slow adoption of the next generation of software synthesis tools, it is instructive to consider one possible explanation.

Just as compiled high-level languages gradually took over from assembly language as the method of choice for software generation, we might expect that the introduction of another level of abstraction between the application code and the real-time execution of the code might be met with some degree of initial skepticism. In fact, at a paper presented at the 2000 San Jose Embedded Systems Conference – 'The Twenty-Five Most Common Mistakes with Real-Time Software Development' – Dave Stewart asserted that the number one mistake of embedded systems designers is their lack of understanding of the execution time parameters of the software that they are designing.

From this perspective, it is easy to guess that a software synthesis tool that abstracts the designer even further form the software that they are creating would have to deal with the designer's real need to generate efficient and high-quality code while still maintaining some level of understanding of the code created by the tool.

Even more than a software synthesis tool, a tool that synthesizes an operating system seems even more heretical. Commercial operating systems have built their reputations on the premise that creating and porting a real-time operating system to a new target platform is not for the faint of heart. They point out the engineer-years of effort that went into fine-tuning the RTOS to wring the last bit of performance out of the kernel tasks such as task switching and interrupt response. Thus, to propose that there is a tool capable of synthesizing a real-time operating system would obviously be met with a hefty dose of skepticism.

To investigate the use of software synthesis technology, Hill and Berger set out to use a software synthesis tool to generate an embedded real-time operating system (RTOS). Bob Zeidman of Zeidman Technologies and the creator of SynthOS agreed to take part in the project as both the supplier of the tool and advisor to the authors. We then worked together with the intention of creating a basic system, documenting our experiences for other designers who want to use software synthesis to get an embedded OS system up and running. Performance measurements were also taken to see how well the synthesized system worked.

Picking the ColdFire 5206eLITE board
The target system we chose for this project was Freescale's ColdFire 5206eLITE, which uses the MCF5206e processor. This board is readily available to use because it is the target system used in Professor Berger's embedded systems courses at the University of Washington Bothell campus.

With the addition of a PC and terminal emulation software, this board serves as a complete microcomputer. The board has a seven-segment LED display and two programmable timers. It also has expandable I/O capabilities and numerous other configurable options to suit our application. A block diagram of the MCF5205e is presented in Fig 1.

1. MCF5206e block diagram (courtesy of Freescale Corporation).
(Click this image to view a larger, more detailed version)

What is software synthesis?
The concept of software synthesis is similar that of hardware synthesis. With hardware synthesis you write a description in a high level language such as Verilog or VHDL and the hardware synthesis tool creates a low level description that is still in Verilog or VHDL. Similarly with software synthesis you write code in C using high-level primitives that look like function calls but really represent complex operating system concepts like thread creation and destruction, message passing mechanisms, and mutexes and semaphores, but much, much simpler. The output code, after synthesis, is still in C, but the synthesis tool handles all of the low-level implementation details.

For example, when you need to write a task that will be executed by the operating system, there's no need to worry about setting semaphores, mutexes, or priority flags. There's no need to consider deadlock conditions, infinite loops, or un-serviced tasks. When you need to have one task communicate with another task, you use one of several simple synthesis primitives. The synthesizer then takes your input code and synthesizes all of the appropriate low-level code according to the general system parameters that you give it. It also creates an operating system kernel with a scheduling algorithm customized to your needs. The synthesized code can be compiled and debugged using all of your existing C tools.