Real-time operating systems implemented in Xilinx FPGAs enhance performance, improve predictability, simplify design, and lower system costs.

Designers once used field programmable gate arrays (FPGAs) as the glue logic to interconnect discrete components on a printed circuit board (PCB). As we start a new era, though, we can now build complete systems in one FPGA chip.

To take advantage of the possibilities offered by Xilinx Platform FPGAs, we must consider the kind of operating system best suited for these one-chip systems, as well as other systems that contain more than one central processing unit (CPU) or one digital signal processor (DSP).

The RealFast company in Sweden has many years of experience in FPGA design, in operating systems, and in real-time systems development. We recently developed the Sierra 16 real-time operating system (RTOS), implemented in an FPGA, to enhance performance and predictability and to reduce system complexity. This article describes the Sierra 16 RTOS, explains what it can do, and explores the possibilities of putting operating system functions into hardware.

Sierra 16 RTOS

Why implement an operating system in hardware? Is it not better to have the operating system in software as we are used to? Well, who would have imagined in the mid-1980s that mathematical operations would be performed by hardware in the CPU instead of software? A closer look at operating systems shows that many of the low-level primitives are similarly independent of the operating system. These primitives can be performed by either hardware or software.

Some example low-level primitives are:

• Task handling – create and schedule tasks
• Synchronization – semaphores, message passing
• Time handling – delay, timeout handling
• Interrupts.

What is the point of doing these operations in a hardware FPGA system instead of in software? Even in the new platform FPGAs, memory is limited if you do not add external memory. In small, cheap products, you probably want to squeeze your application into the available memory in the FPGA. If you use a traditional operating system, the operating system eats substantial memory, leaving less space for the application.

On the other hand, platform FPGAs contain logic that is just waiting to be used. By moving the operating system to logic, you save a lot of space in memory, and at the same time, you increase performance and achieve a fully predictable system. The Sierra 16 RTOS has the same functionalities found in other traditional software real-time operating systems. As shown in Figure 1, the Sierra 16 RTOS has the following configuration:

• Handles as many as 16 tasks at eight priority levels
• Supports 16 semaphores
• Handles timing – delay, timers
• Supports eight external interrupts.

In the coming months, RealFast will complement the Sierra series with other configurations to suit both small and large systems.

Interrupt Handling
Interrupt handling is critical in most systems and is particularly critical in realtime systems. Interrupts introduce unpredictable behavior because of the difficulty in predicting when they will arrive. The Sierra 16 RTOS has an intelligent interrupt handler that makes it possible to achieve fully predictable system behavior, even though it is not possible to know exactly when the interrupts will arrive.

We treat the interrupt service routines (ISR) like any ordinary task with a certain priority in the system. As shown in Figure 2, when not taking care of any service, ISRs are in a wait state. When the interrupt arrives, the ISR is transferred to the ready state in the Sierra 16 RTOS scheduler. ISR tasks execute by priority. To switch between different tasks, the Sierra 16 RTOS interrupts the CPU with a task-switch interrupt. This is the only interrupt that interrupts the CPU. All mecha-nisms are handled by the Sierra 16 RTOS – from the physical pin, to scheduling, to interrupting the CPU so it can switch from present task code to the ISR code and start executing it.

Nonintrusive Monitoring and Debugging

Run-time observability in embedded system architectures is a requirement for testing, debugging, and validating design assumptions made about the behavior of the system and its environment. The classic approach to run-time observability is to apply monitoring – the process of detecting, collecting, and interpreting run-time information regarding the system’s execution behavior.

When monitoring real-time systems, an important aspect is to minimize – or better yet, completely avoid – the intrusiveness of the monitor on the system’s timing and execution properties. Failure to handle monitor intrusiveness may lead to probe effects that cause nondeterministic behavior in programs with race conditions and poor synchronization.

When we use a hardware RTOS (HW-RTOS) like the Sierra 16 RTOS, we avoid the intrusiveness problem. Because the Sierra 16 RTOS comprises a number of hardware components that know at each moment exactly what is going on in the system, this information can be extracted without any software probes normally used for extracting information. One intellectual property (IP) component available for the Sierra 16 RTOS is the Multiprocess Application Monitor (MAMon). As shown in Figure 3, this monitor is implemented in hardware and listens nonintrusively to the different parts inside the Sierra 16 RTOS.

Multiprocessor Solutions Made Easy

Loosely coupled systems and tightly coupled systems contain more than one CPU. In a loosely coupled system, all CPUs have their own memory for such things as program codes and data, and the CPUs communicate through a shared memory. In a tightly coupled system, often called Symmetrical Multiprocessor System (SMP), all CPUs share the same memory and execute code and data from this memory.

The problem with these kinds of systems, in particular SMP systems, is the difficulty in making efficient operating systems that use the efficiency of multiple CPUs. It takes complex algorithms to handle and synchronize multiple CPUs. Pure software solutions for operating systems with multiprocessor support become inefficient and do not give the desired performance boost compared to single CPU systems.

An RTOS implemented in hardware can, on the other hand, perform many parallel operations. This capability provides a completely new approach to solving the problem with multiprocessor systems. All algorithms that are complex and time-consuming in software are moved to hard-ware. All synchronization of tasks, such as semaphores, is handled by the HW-RTOS. The Sierra 16 RTOS supports single CPU systems, but RealFast will soon release another HW-RTOS series that provides support for systems with two or more CPUs or DSPs.

MicroBlaze CPU + Sierra 16 HW-RTOS

A powerful but very inexpensive RTOS solution is to combine a Xilinx MicroBlaze™ software CPU with a RealFast Sierra 16 HW-RTOS. With a small 150K-gate Spartan™-II FPGA and (maybe) some external memory, you can create a complete and advanced realtime system at a very low cost.

In bigger Spartan-II and Virtex™-II FPGAs, it is even possible to exclude external memory, as the internal block RAMs will be big enough for both driver and application in many cases. The software driver for the Sierra 16 has a minimal footprint, only a couple of kilobytes. This driver, together with the HW kernel, makes a very fast and predictable RTOS kernel. With a system running at 50 MHz, most of the system-calls are finished within 2 microseconds.

Conclusion

The new Xilinx Platform FPGAs offer new design approaches and new possibilities. Because logic has grown, we need to start solving problems in a parallel manner, rather than in the sequential manner that we are used to.

An operating system implemented in hardware is a step towards parallel processing, and we believe that these kinds of cost-effective solutions will meet the increasing demands of applications in the future. To learn more about the RealFast Sierra 16 HW-RTOS, visit www.realfast.se/.

Printable PDF version of this article.  (02/15/03) 240 KB