Real-Time Systems


Introduction

Only the most basic embedded systems can manage without a multi-tasking or real-time kernel. The effort to develop any of these is huge, even the small “tick based” kernels that run a fixed list of periodic tasks to completion.

Commercially available RTOS should be considered if staff are temporary or are averse to creating documentation. If the source code is going to be made available, whether publically or to customers, consider the chances of being sued for patent infringement unless you are prepared to base all work on prior art, and that you can show a paper trail with dates. A recent case where prior art was ignored and juries without patent knowledge decided on over a billion dollars of damages, or API suites were brought to court by people who could afford good counsel, even your best might not be good enough.

The academic research into RTOS scheduling in the 1990s should be good enough to base significant work on, and this overcomes the 20 year patent gap. We started to write a framework and documentation that ran into hundreds of pages, but this is unlikely to be published. Our favourite books on real-time research are by Jane W.S. Liu, (2000), Real-Time Systems, published by Prentice Hall, ISBN 0-13-099651-3, and Giorgio C. Buttazzo, (2004), Hard Real-Time Computing Systems — Predictable Scheduling Algorithms and Applications, 2nd edition, published by Springer, ISBN 0-387-23137-4. For visualisation and trying to get past WindRiver patents, see the book by authors Jeffrey J.P. Tsai, Yaodong Bi, Steve J.H. Yang and Ross A.W. Smith, titled Distributed Real-Time Systems. Monitoring, Visualization, Debugging and Analysis, published by Wiley-Interscience, 1996, ISBN 0-471-16007-5. The Wind River patent is Logic Analyzer for Software, US Patent No 5,872,909, filed 7th June, 1995, and about to expire.

Our work

We spent many years working on commercial real-time systems, but somehow they fell short—no acceptance tests on dynamic task admission, usually nothing on the schedule feasibility, little in the way of measurement for verification. About five years were spent researching some of these aspects (part-time and self-funded). The documentation will be posted as a lot of effort was put into the LaTeX version. It will be an interesting exercise to see what is involved in extracting the diagrams, but we’ll keep you updated on these pages.

We have written code to find the hyper-period and frame size of a task set, generate function calls for initialisation and instrumentation, but never managed to close the loop of schedule verification due to lack of non-intrusive instrumentation. We fail to see how critical real-time systems can be signed off without this validation. Code coverage is a requirement for highly critical systems, but what about time verification? Surely that is more important? We proposed a system to test this, but we simply ran out of time and money. The PhD work started to rely on hardware that was always on a PowerPoint slide to still be novel, but after a few years it was doubtful that we would reach our targets before other researchers. The interest since moved to scheduling for power consumption, but there still are no systems that close the loop from specification through to verification that we are aware of. Five years part-time managed to create some interesting tools, but not enough time to document them for distribution, and little interest outside military work.

Future Plans

Real-time requires instrumentation, as you cannot halt a running target for JTAG debug. The claims of being able to read variables without intrusion is a myth. The debug probes often loose control and wonder into the weeds without being able to halt or single-step the target. The solution — brutal as it sounds — is to exit the toolchain, reset the target with a power cycle, and sometimes even resetting the host workstation. And we are not even gathering trace information!

Realistically, instrumentation will have to be purely software based with footprints left in some portion of memory, or hardware assisted via a FPGA. If you get to this level of detail, expect much work. We are not sure what Xilinx intends doing with ARMv8, as UltraScale MPSoC Architecture, accessed 25th Sep, 2014, is scant on details. Meanwhile, Altera Announces Quad-Core 64-bit ARM Cortex-A53 for Stratix 10 SoCs, (Altera.com, 29th Oct, 2013). If the tools ship with a special DS-5 version of ARMv8 compilers and trace readers, it might be worth learning the latest version of Quartus (or whatever is required when the chips ship).

The RISC-V Instruction Set Architecture from Berkeley has a reasonable chance of gaining traction in FPGA implementations and possibly off-the-shelf silicon. Devices in the past faded rather quickly (Beyond Semiconductor and OpenRISC have not announced any 64-bit plans). MIPS looks deserted, although many instructions sets have many similarities to this core (ARMv8 is surprisingly MIPS-like besides the stack pointer wired to zero rather than a dedicated register).

If we ever get the energy and time to have another shot at instrumenting hardware, it makes sense to choose something that has a long-term future. If you look at our FPGA hardware pages, you will follow our trails through FPGA-land looking for a core with source-code that could be instrumented. There is an implementation for some Zynq boards, where the ARM device boots the RISC-V cores in the Xilinx FPGA, so hopefully they will continue this to the Altera A53 devices when shipped.