Clarify AADL ARINC 653 guidance for multi-cores

[stevevestal]

I posted a discussion on this topic to the OSATE google group, link below. From the standards committee perspective, the request is to clarify use of the AADL ARINC 653 Annex with multi-cores. There is also a request to discuss relaxing the "applies to" clause a bit for four ARINC 653 module properties so they can apply to a "system" of "processor" cores, and not only to "processor" components.

https://groups.google.com/forum/#!topic/osate/MO32_No8hw4

[stevevestal]

On further reflection, I am going to request that the committee discuss relaxing the restrictions on the Module_Schedule, Module_Major_Frame, Module_Identifier, and Module_Version properties so that they can be applied to an AADL system as well as an AADL processor. I think it is important to explicitly distinguish a multi-core from a set of multiple uni-processor ARINC 653 modules. I think making this distinction explicit in the model may affect a number of semantic assumptions, e.g., on connection timing, partition schedule synchronization.

[stevevestal]

FYI, a new version of the ARINC 653 standards was released December 2019.

[stevevestal]

After some exchanges with Jerome, I drew up a simple AADL package that shows various alternatives for modeling ARINC 653 multi-core processors. I am attaching this for review and comment. What are people using now? What do they favor? What are other alternatives?

[jjhugues]

From Steve's email, extend the definition of properties to cover system, for consistency with the "system as processor pattern"

[stevevestal]

Earlier attempt at attaching examples apparently failed. Trying again. This has examples and discussions of various approaches to doing this, with a specific recommendation for minor extensions to the current ARINC 653 property set for AADL 2.2 to meet near-term needs.
ARINC653_Multicore_Examples.zip

[jjhugues]

Following these discussions, the following properties have been extended in ARINC653 property sets

    Module_Major_Frame : Time applies to ( system, processor, virtual processor );
    Module_Schedule : list of ARINC653::Schedule_Window applies to ( system, processor, virtual processor );
    Module_Version : aadlstring applies to (system, processor);
    Module_Identifier : aadlstring applies to (system, processor);

These extensions are not part of OSATE yet, they will be merged at some point in the future

[jjhugues]

Note that a side effect of this "minor" property extension is that the whole module pattern has to be rewritten: a module is now either a system or a processor

[stevevestal]

Assigned to do what?

[jjhugues]

Monitor this issue .. only for tracking purposes

[Etienne13]

After discussions on this issue and its relation with aadlv2.2#51, I am wondering if properties Processor_Core_Id and Num_Assigned_Cores are necessary to define threads affinity: we can consider Processor_Core_Id to be the index of the core in the collection of processors in the system (which mainly requires to define the order of processor subcomponents) ; and the number of assigned cores can be computed from the processor binding.

[yoogx]

Processor_Core_Id should not be deduced from the model; for instance some processors like the P4080 can configure cores to access memory differently. Unless this is also part of AADL, this will not work. Same for I/Os on some MPSoC like the UltraScale.

The number of cores can be computed, but the fact that a partition/thread can be affected to k out of n cores without specifying which ones in early design phases cannot.

But do these belong to the core AADL? or to ARINC653? I would opt for the core here

[Etienne13]

Not sure to follow you on the first point: what is the difference between saying "core i is the i-th in the list of processor subcomponents" and "core i has value i in Processor_Core_Id"? ... Note: ordering elements (features, subcomponents) in AADL components is a more general issue, which we also have when dealing with subprogram parameters and their image/order in legacy source code...

I agree with your second and third point.

[jjhugues]

What is the notion of order you use? lexicographic? order in declaration?
Do we have guarantees the instantiation process keeps this order?
How do you define order in the case of component extension? do you prepend or append?
Unless we solve this, this solution seems fragile

I agree the property could be seen as overprescriptive, but is is also more precise.

[Etienne13]

I was thinking about the order of declaration, and asking whether it is better to standardize such an order (including cases of extensions and instanciation) or to add properties to do a very similar cognitive effort for a designer (map declarations to indexes).

Unless we solve this, this solution seems fragile

Exactly. As it is needed for cores in a multi-core and parameters in subprograms, that might be worth defining the order.

Otherwise, I am also ok with the property.

[Etienne13]

I was re-reading the definition of properties proposed by Steve, and looked at the examples.

	Processor_Core_ID : aadlinteger 0 .. Max_AADLinteger applies to (virtual processor, processor);
	Num_Assigned_Cores : aadlinteger 0 .. Max_AADLinteger applies to (virtual processor, processor);

I would prefer not to allow Processor_Core_ID for virtual processors since virtual processors are not (AFAIK) meant to represent cores in a multi-core processor. For a similar reason, I would not allow Num_Assigned_Cores for processors. But I would allow it for a process or thread.

Except for these minor remarks, I think we can add these properties to one of the property sets of the core since they are not specific to ARINC.

[yoogx]

I understand your point for Processor_Core_ID. This will go in the general issue of multicore we must address in the core (e.g. backporting what we have from v3?) but also saeaadl/aadlv2.2#51

About Num_Assigned_Cores: I understand the rationale to have it for process or thread in addition to virtual processor, which is to specify how much cores could be used; and let the OS or an optimisation tool do the allocation (online, offline, etc). Is that correct?

The reason I am asking is that I need to attach some semantics to these properties, in addition to the AADL definition itself

[stevevestal]

As I recall, we used both due to uncertainty about the somewhat permissive ARINC 653 standard. It seemed fairly clear to us they wanted to permit virtual as well as physical cores. A partition can specify its needs and affinities in terms of virtual cores, and the underlying RTOS or module integrator can decide how those virtual cores are allocated to physical cores. So we included both in that earlier submission due to uncertainty in how this might be modeled in the future.

[Etienne13]

@yoogx about Num_Assigned_Cores: I think the semantics is to express a requirement, i.e. the thread/process/virtual processor requires N cores when scheduled. I would even say "exclusive access to N cores" when scheduled (at least for ARINC).

@stevevestal given your comment, I would define (if necessary) another property for virtual cores. My reaction was partly due to one of the examples you provided in which a virtual processor seemed to be used to model a processor core. I think we should avoid this and therefore we should not reuse the same property.

[jjhugues]

• Add an example in the annex document with a multicore system

[stevevestal]

Confirming the following extensions of the "applies to" clauses are what was requested. A tool implementation has verified these are sufficient for very basic modeling of multi-cores, with proper use and interpretation to distinguish a uni-processor modeled as a processor from a multi-core modeled as a system of processor subcomponents. I assume the annex will have a description of modeling multi-cores versus uni-processors.

Module_Major_Frame : Time applies to ( system, processor, virtual processor );
Module_Schedule : list of ARINC653::Schedule_Window applies to ( system, processor, virtual processor );
Module_Version : aadlstring applies to (system, processor);
Module_Identifier : aadlstring applies to (system, processor);