How to choose an RTOS for your FPGA and ASIC designs
May 09, 2007 -- pldesignline.com
Introduction
This article examines different options for putting a real-time operating system (RTOS) on a system on a chip (SoC). There are basically three options:
- Purchase an off-the-shelf RTOS
- Write your own RTOS
- 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.
E-mail This Article | Printer-Friendly Page |
Related Articles
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)