Table 3 shows some example code generated by the synthesis process. The left half of the table has the original code used as input and the right half presents the result of the synthesis operation. As can be seen, a single primitive is synthesized into many lines of code related to the management of the RTOS, all of it thankfully without needing the user's assistance or expert knowledge.

Table 3. Original code (left) and synthesized code (right).

Synthesize tasks
Once the tasks were tested and proved to be working independently, Matt began the infamous part of the project, known and feared by experienced embedded systems designers everywhere: integrating the operating system. With SynthOS this consisted of the following:

• Inserting the primitives.
• Creating the .SOP (SynthOS options) file.
• Synthesizing code.
• Testing the final system.

Insertion of the primitives was a straightforward process of changing the non-OS function calls to SynthOS-compatible calls, i.e., 'convert();' to 'SynthOS_call(convert());' (as shown in Table 3). The creation of the .SOP file was very simple and Fig 3 shows a sample .SOP file. Once those steps were completed, synthesis was completed with a simple command such as, 'SynthOS filename.SOP'.

3. Sample .SOP file.

Testing and debugging the RTOS
Integration testing!!! Often death is more pleasant. But in this case things turned out to go fairly smoothly since we had done such extensive modular testing throughout the entire process.

Performance measurements
When comparing the performance of this SynthOS RTOS to the performance of another RTOS, it is very important to remember that the numbers were likely collected from different systems. Because each system can be completely different, the numbers can not accurately determine if one RTOS performs better than the other.

Another important consideration is that the SynthOS scheduling algorithm is dependant on the number of tasks. These performance tests were done with three to five (depending on the test) tasks to keep it simple and provide some baselines for comparison.

We performed a test to measure task switch time. The time was measured using an HP Logic Analyzer to monitor the signals coming off the board by 'instrumenting' the code to place markers in areas that we wanted to do performance measurements. The logic analyzer was set to monitor certain locations in the unused memory space of the processor. Single-instruction 'writes to memory' were added to the code wherever we wanted to measure a time interval. For example, the logic analyzer would record the memory write instruction that signaled the entry point to a task switch operation and then record the next write that would signal the exiting of the task switch. Since both memory writes were time stamped by the logic analyzer, we could determine the elapsed time for the operation to an accuracy of +/– 2.5 nanoseconds.

However, it should also be pointed out that this method does place a slight perturbation in the system so the actual performance would be two instruction times better than the observed time duration.

In order to measure the task switch time, we used an Init task and two Loop tasks. The Init task initialized communication with the Logic Analyzer. Each Loop task sent a signal to the Logic Analyzer and then made a SynthOS_sleep() call to allow the RTOS to perform a task switch.

For reference, the MCF5206e features, on average, 50 MIPS performance at 54 MHz. The test was performed with the on-chip I-cache enabled and we measured an average task switch time of 15 microseconds. While commercial, hand-crafted RTOS measurements would probably yield better numbers, these results are quite adequate for many real-time embedded applications.

Conclusion
The most compelling result that came out of this project was that a software developer without prior embedded or OS design experience can implement an embedded RTOS and have it function to a high level of usability. Software synthesis is similar to having a standard library of functions that you can include and have the functions always available; software synthesis allows this convenience on a larger scale. For example, SynthOS creates an entire RTOS, using the user-provided code like library calls. The generated code treats the user code as a black box. Now with software synthesis, instead of writing code to use library calls, we instead write the 'library calls' themselves and let the synthesis tools create the underlying low level code.

Overall we found that software synthesis tools perform much of the redundant work of repeatedly creating similar code. This reduces errors and testing because the tools have already been established as working. Furthermore, developers can move on to creating new features for the RTOS, rather than re-creating a similar RTOS for every occasion.

Software synthesis can reduce the reliance on out-sourcing. There are situations where Company A out-sources the creation of an RTOS to a third-party Company B. Company A can instead use software synthesis tools to accomplish about the same thing. The difference is that using the synthesis tools, the RTOS is in a familiar, easy to debug, and easy to modify language, rather than object code from a third-party.

Of course, there are some downsides to software synthesis tools including overhead, compatibility concerns, and availability of support. The main downside is the same for almost any software tool: overhead from learning how to use the tool. Depending on the complexity of the tool, there can be a huge learning curve before the tool is useable. If the tool is only going to be used once, time spent learning the tool is going to be very wasteful. However, if it will be used frequently, that same tool might save a lot of time and money and allow the developers to work on different and more interesting features.

Library support is another critical issue. Off-the-shelf RTOSes, like embedded Linux, come with a large number of drivers and applications that run on the RTOS that users can simply compile into the system. SynthOS does not have such a library of code, though Zeidman Technologies is working on a tool to automatically convert existing drivers and applications for synthesis.

Another concern when using software synthesis tools is compatibility. The tool should have an input and output language that is compatible with existing software and hardware. Finally, another thing to consider is the availability of support for the tool. There should at least be an informative user's manual for the tool, and ideally someone to contact for troubleshooting.

Overall we found software synthesis to be an interesting and very useful technology. We believe that its use will grow, particularly in the embedded world, and may eventually become a mainstream method of software development.

Arnold Berger is a Senior Lecturer in the CSS Department of the University of Washington Bothell. He can be reached at ABerger@bothell.washington.edu.

Mathew Hill is a recent graduate of the University of Washington Bothell. He can be reached at mjmthere@hotmail.com.

Bob Zeidman is the president of Zeidman Technologies. He can be reached at bob@zeidman.biz.