Reference platform

The Altera Nios II is a flexible platform that allows different configurations with different performance. When considering Erika Enterprise performance measurements, we only considered a reference platform derived from the standard Altera reference design.

Moreover, also Erika Enterprise is highly configurable, providing different compiling options that impact of the system performance. These options are in fact a series of #ifdef in the kernel source code that inevitably changes the code footprint and the memory usage.

Having said that, the hardware used to take these measurements is the same used for the Erika Enterprise and RT-Druid tutorial, and runs on a Stratix 1S40 Altera evaluation board. The design have been generated by Altera Quartus II 5.0, Altera Nios II IDE 5.0, Evidence RT-Druid withErika Enterprise 1.2. The design is composed by two Nios II/s running at 50MHz with Instruction cache of 4Kb, and a few standard Altera peripherals. Code and data resides on external SRAM. Timings were measured using an Altera Performance Counter. Software projects used to perform the measurements are available in the full version of the products.

The hardware design on which the measurements have been performed is neither the fastest, nor the slowest design that can be done with Nios II, but is somehow an "average" design.

Erika Enterprise code footprint

The following table presents the memory usage of a typical subset of Erika Enterprise primitives, with:

• BCC1 conformance class.

• Monostack Kernel.
  
• Standard Status.
• Support for Autostart of task and alarms.
• Support for Nested Interrupts.
• Support for StartupHook and ShutdownHook.
  
• Startup Barrier (only multiprocessor).
• Interprocessor interrupt (only multiprocessor).
• Support for remote task activations (only multiprocessor).
• Support for global resources (only multiprocessor).

Comments:

• Multiple CPU numbers are referred to the Master CPU.
  
• The difference in footprint for the GetResource and ReleaseResource, and the big size of the Interprocessor IRQ handling are due to inline expansion of spin-lock handling code.
• The difference in the StartOS primitive is due to the implementation of the startup barrier in multiprocessor systems.

Erika Enterprise data footprint

The following table reports the memory usage of typical Erika Enterprise application. The comments below clarifies the parameters used for the Applications considered

Comments:

• Single CPU numbers considers a BCC1 configuration containing 3 tasks, 1 resources, 1 Application mode, 0 Counters, 0 Alarms, and Autostart features.
• Multiple CPU mumbers considers the memory usage on the Master CPU of a 2 CPU BCC1 configuration containing 4 tasks (3 of them on the Master CPU),  1 local resource, 1 global resource, 1 Application mode, 0 Counters, 0 Alarms, and Autostart features.
• Memory usage varies with the numbers of CPUs, tasks, resources, that are instantiated inside the OIL file.
  

ERIKA Enterprise execution times

The following timing figures are an example of performance measurements that can be obtained from a typical deployment of Erika Enterprise. This is NOT the best performance you can get ot of an Erika Enterprise deployment, because performance highly depends on:

• the topology of the multiprocessor system;
• the memory layout;
• the Avalon bus traffic;
• the compiler options.
  

In particular, in the case we considered, both CPU code and data were allocated on SRAM, meaning also that Multiple CPU may collide accessing the same memory bank. Tightly coupled memories were not used in the example.

Comments:

• Single CPU example has been made using the same hardware configuration of the Double CPU data, and creating, compiling and debugging a single processor system.
• The BCC1 conformance class (with O(n) ready queue queuing algorithms) has been used.
  
• The difference between a local and a remote task activation is mainly due to the internal use of the Altera Avalon Mutex. This overhead will be reduced in the next versions ofErika Enterprise.
• The small differences in the TerminateTask timings are most probably due to instruction cache misses (the code executed is the same).