[Oberon] Linux versus Oberon System

[skulski at pas.rochester.edu]

> I understand that for your very special application the FPGA is the way
>to go. From what I see at your webpage you have done some impressive
>hardware. What I still not understand is: what is the essential benefit
>of the Oberon System/Compiler in your case. You have ucLinux (I
>believe) running and 600 MHz CPU or so; compared to that the RISC5 is a
>small toy running at 25 MHz, I think.
>
> These numbers are very deceptive when you are wanting real-time
> performance. You don't  tune a watch for precision by speeding it up.
> Modern OS's are "soft real-time", at best whereas Oberon FPGA promises
> "hard real-time" performance...Precision Swiss timing.

A few observations. The chip which we are using is a fairly typical one,
so the remarks will be almost universally true. 600 MHz refers to the
dual-core CPU and the L1 memories on chip. These memories is integrated
into the cores. There is also an on-chip L2 memory which is shared between
the two cores. It runs at half the speed. Linux, being a large piece of
software, needs more memory than is present on chip. The SDRAM, which is
off chip, runs at 133 MHz*32 bits. So it is noticeably slower. Newer chips
would use DDR kind of memory that can provide bandwidth similar to SDRAM
with fewer pins. (Faster clock, but narrower interface, so you end up with
a wash.) In general, on-chip memory is fast but limited, while off-chip
memory is big but slower. Linux will not fit into the former, so the
performance of a Linux system is limited by the latter.

Concerning timing, inside the kernel Linux uses a very elaborate
arrangement of software timers that execute various parts of the kernel.
Servicing the timers will eat CPU cycles. Here the kernel is trading the
CPU performance for the concurrency. This is inside the kernel. Outside
the kernel (in the "user space") the processes are executed by the
scheduler, which periodically allocates time slices to each process. The
period is typically 1 ms. I suspect that one can try a finer granularity
(100 us perhaps?) but the scheduling overhead will increase relative to
useful work. I would be grossly surprised if one could decrease the
scheduling period below 100 usec. Perhaps on a multi-GHz core this could
be done, but such cores are not good candidates for embedded systems where
power is paramount. The short summary is that timing-wise the GHz CPU
becomes a kilohertz one, if you operate it in user space, what is the
easiest. If you need a faster response, then you need to dive into the
kernel, which may not be easy.

In short, Linux is sweet and easy if one is happy with great tools running
in user space. Which seems to be its original goal. As soon as you are
trying to service some real time with Linux, it can easily become an
endless source of interesting problems to solve.

Wojtek