Difference between revisions of "Kalray MPPA"

From ERIKA WIKI
Jump to: navigation, search
(Created page with "= Synopsys = Kalray-1 (K1) is the name of the Instruction Set Architecture (ISA) of Kalray MPPA processors. The Kalray-1 core implements a 32-bit 5-issue Very Long Instructio...")
 
 
(4 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
Kalray-1 (K1) is the name of the Instruction Set Architecture (ISA) of Kalray
 
Kalray-1 (K1) is the name of the Instruction Set Architecture (ISA) of Kalray
 
MPPA processors.
 
MPPA processors.
The Kalray-1 core implements a 32-bit 5-issue Very Long InstructionWord (VLIW)
+
The Kalray-1 core implements a 32-bit 5-issue Very Long Instruction Word (VLIW)
architecturewith a 7-stage instruction pipeline.
+
architecture with a 7-stage instruction pipeline.
 
MPPA processors are manycore processors.
 
MPPA processors are manycore processors.
 +
 
The Kalray MPPA®-256 processor (Multi-Purpose Processing Array) integrates 256
 
The Kalray MPPA®-256 processor (Multi-Purpose Processing Array) integrates 256
 
processing engine (PE) cores and 32 resource management (RM) cores on a single
 
processing engine (PE) cores and 32 resource management (RM) cores on a single
 
chip.
 
chip.
These cores are distributed across 16 compute clusters and 4 I/O subsystems.
+
These cores are distributed across 16 computing clusters and 4 I/O subsystems.
I/O subsystem contains 4 RM cores each.
+
The I/O subsystem contains 4 RM cores each.
Compute clusters contains 1 RM and 16 PE each.
+
The computing clusters contain 1 RM and 16 PE each.
ERIKA v3 has been ported only on computing clusters.
+
 
In the second generation of the chip, code name: Bostan, the one officially
+
ERIKA Enterprise v3 has been ported only on the computing clusters.
supported by ERIKA v3, the cluster's RM core is not avaiable to users, but
+
The chip officially supported by ERIKA v3 is the second generation of the chip (called '''Bostan''').
it's managed by the Kalray SDK by the '''mOS''' layer (hypervisor),
+
In this chip version, the cluster's RM core is not available to users, but
 +
it's directly managed by the Kalray SDK through the '''mOS''' layer (hypervisor),
 
leaving a "virtual cluster" of 16 PE cores for users.
 
leaving a "virtual cluster" of 16 PE cores for users.
The need of a complete rewrite of ERIKA is born during the Euopean project
+
 
[http://www.p-socrates.eu P-Socartes] where ERIKA were supposed to be the
+
The Kalray port of ERIKA is part of the European project
 +
[http://www.p-socrates.eu P-SOCRATES], where ERIKA was supposed to be the
 
back-end of a lightweight OpenMP runtime.
 
back-end of a lightweight OpenMP runtime.
You can find project's results provided as open source project called
+
 
 +
You can find project's results provided as an open source project called
 
[http://www.upscale-sdk.com Upscale SDK]
 
[http://www.upscale-sdk.com Upscale SDK]
A parallel framework like OpenMP has some requiriments that do not fit well
+
 
with an AMP OS like an Autosar OS, so, even tough still present and supported,
+
A parallel framework like OpenMP has some requirements that do not fit well
the library that provide services, called jobs, for the runtime OpenMP,
+
with an AMP OS like an Autosar OS.
 +
So, we created a library in ERIKA to provide services for the runtime OpenMP,
 +
and we call them jobs.
 +
Even though it is present and supported, it
 
is not perfectly integrated with the current status of ERIKA.
 
is not perfectly integrated with the current status of ERIKA.
Actually ERIKA's still lack of complete multicore Autosar OS support for this
+
 
platform (the first release of ERIKA v3 is a singlecore OSEK/VDX OS, ready to
+
Currently, ERIKA is still lacking a complete multicore AUTOSAR OS support for this
be extended with multicore features), when the multicore support will be
+
platform (the first release of ERIKA v3 is a single-core OSEK/VDX OS, ready to
completed we will try harmonize the jobs library.
+
be extended with multicore features). When the multicore support will be
 +
completed, we will try to harmonize the jobs library.
  
 
= Configuration and Programming =
 
= Configuration and Programming =
  
 
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]].
 
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]].
ERIKA's support for Kalray lay on top of Kalray Access Core SDK, and inherit
+
ERIKA's support for Kalray lay on top of Kalray Access Core SDK, and inherits
 
the environment configuration.
 
the environment configuration.
  
Line 48: Line 56:
  
 
== Interrupt Handling ==
 
== Interrupt Handling ==
ERIKA let you install an handler for any IRQ source (physical and virtual)
+
 
has provided by Kalray-K1 mOS, using the same name that SDK uses.
+
ERIKA lets you install a handler for any IRQ source (physical and virtual)
 +
provided by Kalray-K1 mOS, using the same name that SDK uses.
  
 
   ISR TimerISR {
 
   ISR TimerISR {
Line 81: Line 90:
 
The scheduling model is: full preemptive on PE0 (Master-Core), limited
 
The scheduling model is: full preemptive on PE0 (Master-Core), limited
 
preemption on PE[1:15] (this is what was needed for the upscale-sdk, and what
 
preemption on PE[1:15] (this is what was needed for the upscale-sdk, and what
we has been able to achive due some issues in the '''mOS''' layer of the
+
we have been able to achieve due some issues in the '''mOS''' layer of the
 
AccessCore version we worked with).
 
AccessCore version we worked with).
  
To access this feature you need to switch-on the dynamic beaviour (TASK
+
To access this feature you need to switch-on the dynamic behavior (TASK
 
creation at runtime from an object pool) of ERIKA ('''USEDYNAMICAPI = TRUE''') and  
 
creation at runtime from an object pool) of ERIKA ('''USEDYNAMICAPI = TRUE''') and  
 
the API extension ('''USEEXTENSIONAPI = TRUE'''), and configure all the 16 Cores
 
the API extension ('''USEEXTENSIONAPI = TRUE'''), and configure all the 16 Cores
Line 93: Line 102:
 
('''MAX_NUM_JOB''').
 
('''MAX_NUM_JOB''').
  
Inside '''USEEXTENSIONAPI''' is possible to configure the '''SCHEDULER''' beaviour:
+
Inside '''USEEXTENSIONAPI''' is possible to configure the '''SCHEDULER''' behaviour:
* '''PARTITIONED''' is the normal Autosar OS scheduler with TASK fully pinned to one core and each core handling it's own TASKs ready queue.
+
* '''PARTITIONED''' is the normal Autosar OS scheduler with TASK fully pinned to one core and each core handling its own TASKs ready queue.
 
* '''GLOBAL''' is a global work conserving priority based ready queue common to all cores, where a preempted TASK can migrate to a core previously in idle.
 
* '''GLOBAL''' is a global work conserving priority based ready queue common to all cores, where a preempted TASK can migrate to a core previously in idle.
  
Line 101: Line 110:
 
and priority multiqueue (O(1) with 31 priority), are supported).
 
and priority multiqueue (O(1) with 31 priority), are supported).
  
Follow a configuration example:
+
A configuration example follows:
  
 
     CPU_DATA = KALRAY_K1 {
 
     CPU_DATA = KALRAY_K1 {
Line 118: Line 127:
 
     };
 
     };
 
      
 
      
     USERESSCHEDULER = FALSE; /* ResScheduler support has to be explicitly shutdown in a multicore configuartion */
+
     USERESSCHEDULER = FALSE; /* ResScheduler support has to be explicitly shutdown in a multicore configuration */
 
      
 
      
 
     USEDYNAMICAPI = TRUE {
 
     USEDYNAMICAPI = TRUE {
Line 146: Line 155:
  
 
[[Category:Architectures]]
 
[[Category:Architectures]]
 +
[[Category:Tutorial]]

Latest revision as of 16:48, 11 June 2018

Synopsys

Kalray-1 (K1) is the name of the Instruction Set Architecture (ISA) of Kalray MPPA processors. The Kalray-1 core implements a 32-bit 5-issue Very Long Instruction Word (VLIW) architecture with a 7-stage instruction pipeline. MPPA processors are manycore processors.

The Kalray MPPA®-256 processor (Multi-Purpose Processing Array) integrates 256 processing engine (PE) cores and 32 resource management (RM) cores on a single chip. These cores are distributed across 16 computing clusters and 4 I/O subsystems. The I/O subsystem contains 4 RM cores each. The computing clusters contain 1 RM and 16 PE each.

ERIKA Enterprise v3 has been ported only on the computing clusters. The chip officially supported by ERIKA v3 is the second generation of the chip (called Bostan). In this chip version, the cluster's RM core is not available to users, but it's directly managed by the Kalray SDK through the mOS layer (hypervisor), leaving a "virtual cluster" of 16 PE cores for users.

The Kalray port of ERIKA is part of the European project P-SOCRATES, where ERIKA was supposed to be the back-end of a lightweight OpenMP runtime.

You can find project's results provided as an open source project called Upscale SDK

A parallel framework like OpenMP has some requirements that do not fit well with an AMP OS like an Autosar OS. So, we created a library in ERIKA to provide services for the runtime OpenMP, and we call them jobs. Even though it is present and supported, it is not perfectly integrated with the current status of ERIKA.

Currently, ERIKA is still lacking a complete multicore AUTOSAR OS support for this platform (the first release of ERIKA v3 is a single-core OSEK/VDX OS, ready to be extended with multicore features). When the multicore support will be completed, we will try to harmonize the jobs library.

Configuration and Programming

ERIKA Enterprise is configured through RT-Druid and an OIL file. ERIKA's support for Kalray lay on top of Kalray Access Core SDK, and inherits the environment configuration.

CPU

CPU_DATA must be set to KALRAY_K1.

Example of a CPU_DATA section:

 CPU_DATA = KALRAY_K1 {
   ...
 };

Interrupt Handling

ERIKA lets you install a handler for any IRQ source (physical and virtual) provided by Kalray-K1 mOS, using the same name that SDK uses.

 ISR TimerISR {
   CATEGORY = 2;
   SOURCE   = "BSP_IT_TIMER_0";
   ...
 };

OSEK/VDX Extensions

This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the Kalray K1.

System Timer

System Timer can be configurated to use one od the two cluster's timers (BSP_IT_TIMER_0 or BSP_IT_TIMER_1).

 COUNTER SystemTimer {
   MINCYCLE = 1;
   MAXALLOWEDVALUE = 2147483647;
   TICKSPERBASE = 1;
   TYPE = HARDWARE {
     DEVICE = "BSP_IT_TIMER_0";
     SYSTEM_TIMER = TRUE;
   };
   SECONDSPERTICK = 0.001;
 };

Jobs library

Even though not yet harmonized, the jobs library is already available. The scheduling model is: full preemptive on PE0 (Master-Core), limited preemption on PE[1:15] (this is what was needed for the upscale-sdk, and what we have been able to achieve due some issues in the mOS layer of the AccessCore version we worked with).

To access this feature you need to switch-on the dynamic behavior (TASK creation at runtime from an object pool) of ERIKA (USEDYNAMICAPI = TRUE) and the API extension (USEEXTENSIONAPI = TRUE), and configure all the 16 Cores for the cluster.

Inside USEDYNAMICAPI field in addition to the normal ERIKA's dynamic support, for Kalray-K1 is possible to configure the dimension of the jobs pool (MAX_NUM_JOB).

Inside USEEXTENSIONAPI is possible to configure the SCHEDULER behaviour:

  • PARTITIONED is the normal Autosar OS scheduler with TASK fully pinned to one core and each core handling its own TASKs ready queue.
  • GLOBAL is a global work conserving priority based ready queue common to all cores, where a preempted TASK can migrate to a core previously in idle.

N.B. Be aware that the conformance classes that support jobs library are ECC1 or BCC1 with MULTI_STACK enabled (both ready queue algorithms: priority queue (O(n) with 127 priority) and priority multiqueue (O(1) with 31 priority), are supported).

A configuration example follows:

   CPU_DATA = KALRAY_K1 {
     ID = 0;
     MULTI_STACK = TRUE;
   };
   
   CPU_DATA = KALRAY_K1 {
     ID = 1;
   };
   
   ....
   
   CPU_DATA = KALRAY_K1 {
     ID = 15;
   };
   
   USERESSCHEDULER = FALSE; /* ResScheduler support has to be explicitly shutdown in a multicore configuration */
   
   USEDYNAMICAPI = TRUE {
     TASK_ARRAY_SIZE     = 128;    /* 16 * 8 */
     SN_ARRAY_SIZE       = 128;    /* 16 * 8 */
     STACKS_MEMORY_SIZE  = 131072; /* 8192 * 16 */
     MAX_NUM_JOB         = 2;
   };
   
   USEEXTENSIONAPI = TRUE {
     /* SCHEDULER = PARTITIONED; Uncomment this and comment the following, to switch back to the normal multicore partitioned scheduler */
     SCHEDULER = GLOBAL;
   };
   
   KERNEL_TYPE = OSEK {
     CLASS = ECC1;
     /* RQ = MQ; Uncomment this to use the priority multi-queue */
   };
 };
 
 /* Workaround: FAKE TASK, just to have a place where declare APP_SRC */
 TASK Fake_Task {
   CPU_ID   = 0;
   APP_SRC  = "test.c";
   PRIORITY = 1; /* Always Needed */
 };