How to choose an RTOS for your FPGA and ASIC designs

1. Purchase an off-the-shelf RTOS
2. Write your own RTOS
3. Use a software synthesis tool to automatically generate an RTOS.

If you purchase one, what is available and what are the tradeoffs? If you write your own, which issues will you need to take into account? If you synthesize one, what tools are available and how do they work?

What is a system-on-a-chip?
The definition of a system on a chip (SoC) varies somewhat, depending on the use. One definition is a chip that is so large – contains so many logic gates – that it takes the place of an entire system that would have taken an entire PCB full of chips only a few years ago. For the purposes of this article, however, we will use the definition that a programmable SoC – which may be implemented as a custom ASIC or using an off-the-shelf FPGA – must include a microprocessor.

What is an RTOS?
A good place to start is to define a real-time operating system. The book Real-Time Concepts for Embedded Systems, by Qing Li with Caroline Yao, defines an RTOS as: "a program that schedules execution in a timely manner, manages system resources, and provides a consistent foundation for developing application code."

The key differentiator between any old operating system and a real-time operating system is the term "timely." Of course, this vague adjective leaves lots of wiggle room. Rather than "timely," it might be better to say "within specified time constraints." An RTOS has specific time constraints that a desktop PC does not. For example, when you click on an icon, it may take seconds (or, unfortunately even minutes) to start the execution of a program while a disk cleanup operation or a virus scan is occurring in the background. By comparison, when you step on your brake pedal in your car, you can't have the operating system finish a disk scan before the brakes are activated. In this case the brakes must activate within a specific time, so the OS in your car must be a real-time OS.

The example of the braking system in a car is more precisely what is called a hard RTOS. This means that the time between pressing the brake pedal and the time that the brakes are engaged must have an absolute worst-case time, or latency. A hard RTOS has time constraints that must be met under any and all conditions for certain tasks. By comparison, a soft RTOS can usually respond within a certain time, though under some conditions there may be further, unpredictable delay. For example, a vending machine company may have surveys showing that customers want their candy bars within 2 seconds of pressing the button, but if one out of every thousand customers has to wait 10 seconds, there will be no catastrophic results (other than a swift kick to the machine).

The book goes on to say that: "in some applications, an RTOS comprises only a kernel, which is the core supervisory software that provides minimal logic, scheduling, and resource management algorithms. . . On the other hand, an RTOS can be a combination of various modules, including the kernel, a file system, networking protocol stacks, and other components required for a particular application. . ."

This definition illustrates one of the problems in defining an RTOS. Some people refer to the kernel, the basic task scheduler, as the RTOS while others refer to the kernel plus hardware drivers plus services as the RTOS. Those who followed the Microsoft anti-trust legal proceedings will remember that this same question came up there. When Microsoft added a file editor and a calculator and – specifically – a Web browser, did these constitute applications on top of the operating system, as the government insisted, or did they constitute additional functionality for the OS as Microsoft insisted? The answer is not simple and many reasonable people continue to disagree. For our purposes, we will refer to the RTOS as simply the task manager or kernel. The drivers and applications, though very important, will be considered to be separate.

Do You Need An RTOS?
If your SoC will be running more than one task then it needs an RTOS. If your SoC will run only one task, then most likely you would not need an SoC but could simply create a hardware state machine in Verilog or VHDL to implement the single task.

While it is theoretically possible to create the RTOS in hardware, the effort is difficult, there are few if any tools to support it, and it is very difficult to make changes during development and particularly to systems in the field. These are all the reasons why software is useful and why systems are migrating to processor-based SoCs.

One argument that you must be careful to avoid is the one that says the processor in your SoC is doing only one thing so there is no need for an RTOS. This argument is often heard when describing multiprocessor SoCs – those with multiple small processors, each handling a single piece of hardware or a single small task. The CEO of a company that produces configurable processors – someone who should have known better – made this argument at a recent talk. If your SoC contains multiple processors, each handling one task, the processors by definition are actually handling more than one task. Each processor is handling the task to which it is assigned plus the task of communicating with the other processors. All SoCs need some kind of RTOS. The question is which RTOS and whether to build, buy, or use a third, more recent, option – synthesize.

Purchasing an RTOS
Many commercial companies offer RTOSes that have been designed and debugged for you. These are often called "off-the-shelf" RTOSes. There are generally two kinds of off-the-shelf RTOS – ones where you purchase object code that has been compiled for the processor you will be using, and ones where you receive the source code and compile the code to your processor. These are described in further detail below.

Object Code: A traditional off-the-shelf RTOS consists of code that has been written, compiled, debugged, and tested by a company that then sells the object code. The main reason for selling object code is that this protects the intellectual property of the company because the object code is extremely difficult to reverse engineer. It also means that the customer relies on the vendor to do a good job and to support the code when there are problems.

The traditional method of charging for these kinds of RTOSes is with an upfront fee and a royalty. In other words, the vendor receives a certain amount of money to hand over the code to the customer and support it during system development; the vendor subsequently receives a little money for each system that the customer ships containing the RTOS. With the availability of embedded Linux, which is open source, the object code model is becoming less popular.

Open Source: Especially since the introduction of Linux, and later the introduction of real-time versions of Linux intended for embedded systems, users are often no longer willing to pay royalties and want their software for free. Of course there is no such thing as a free lunch. Companies do not stay in business by giving away free goods. Open source RTOSes may be free to download, but there is usually a steep learning curve.