Multicore specification

[Etienne13]

As far as I understood the discussions of the standardization committee, multi-core processors are supposed to be modeled using a system component in which processor subcomponents model execution cores.

To precise that the system is a multi-core processor, I would suggest to add a dedicated property as follows:

Is_Processor : aadlboolean applies to (system);

[jjhugues]

Must clarify the conditions to "detect" that a system is a processor. Could be that defining Scheduling_Protocol is enough. We must document this pattern

Anoter consideration could be to have "Is_Hardware_System" to capture the intent that the system is a MPSoC, a device, a multi-core, etc

What is a processor? If it is a processor, you can bind threads to it, otherwise it is a device (a black box).

Could backport v3 pattern of processors as subcomponents of processors

• Etienne, Pierre and Dominique to propose a write-up that defines the intent of the Is_Processor property

[Etienne13]

Notes from the discussion of the committee (for the record):

1 - specify the semantics; e.g. represents a single execution board, potentially multi-core, along with its memory and devices. The intent is to differentiate systems that are "single" processors from those which are distributed platforms or integration systems (with both HW and SW).
2 - define potential legality rules: can we have threads as subcomponents of a system with an 'Is_Process => true' property association.
3 - could it be derived from the fact that a process is bound to the system? Would this imply some of the semantic definitions and legality rules as mentioned above?

[jjhugues]

Following-up on saeaadl/arinc653#4

Steve proposed the following properties

    -- The following are new properties taken from the ARINC 653 standard.
    -- The apparent intention of the ARINC 653 standard is to permit an RTOS
    -- to do virtual mapping between the cores a partition thinks it has and
    -- actual physical hardware cores.  The expected simple use is that a Processor_Core_ID
    -- would apply to an AADL processor (A653 physical core) and Num_Assigned_Cores
    -- would apply to an AADL virtual processor (A653 partition).  However, adding the
    -- other options gives tool vendors some freedom to deal with virtual cores.
    Processor_Core_ID : aadlinteger 0 .. Max_AADLinteger applies to (virtual processor, processor);
    Num_Assigned_Cores : aadlinteger 0 .. Max_AADLinteger applies to (virtual processor, processor);

How do they match with the discussions here?

[Etienne13]

Can we have an example that would use these properties? I have difficulties to figure if they actually capture a mapping information and/or whether they would help to fix the issue under discussion.

[Etienne13]

A few notes from a discussion we had with Pierre and Frank:

== Summary ==

Rationale: the objective is to unify the way AADL 2 users represent hardware components made up of more hardware [software] components. In particular, in the context of multi-core processors. This unification will enable inter-operability among tools that have already used a similar solution (i.e. define a system as a HW component using the property). It will also avoid ambiguous ad-hoc inference rules to decide if a system component represents a hardware component or not (e.g. inferences from bindings, protocoles, etc.).

In order to avoid the impression that this property is intended to replace a category (system) by another (processor) we propose to rename it as "Is_Hardware_System" (or Is_SystemOnChip). The default value is false obviously.

The property is intended to be restrictive, without requiring additional legality/consistency rules. Indeed, the property introduces semantic restrictions (i.e. a system with the property being "true" is intended to represent a hardware system) but does not introduce structural restrictions (i.e. the hardware system may contain software components, assuming they represent the behavior of the hardware itself). Consequently, the introduction of the property should not introduce additional legality/consistency rules.

One can see this property as the symmetric of "implemented as": implemented as helps to refine the internals of a hardware component as a system. In the case of the "is_hardware_system" property, the objective is to explicit the fact that a system actually represents a hardware component. In other words, a hardware component "implemented as" should reference a system that "is hardware". Note: we might want to be specific in this case with a "is_processor" to represent a system that models the implementation of a processor, "is_device" to represent a system that models the implementation of a device ... But this would contradict the objective not to use properties to change categories, and this my become too specific (leading to the introduction of restrictions that might not be worth considering at this stage).

[yoogx]

Can we have an example that would use these properties? I have difficulties to figure if they actually capture a mapping information and/or whether they would help to fix the issue under discussion.

See ARINC653_Multicore_Examples.zip in saeaadl/arinc653#4

Processor_Core_Id is required (AFAICT) to capture the id of the core used, e.g. for setting task affinity in code generation. I have something similar in Ocarina for POSIX. It is a property you would specify for each core.

Num_Assigned_Cores is more like an implementation permission (again, my words here, not Steve's): you just specify you want to use Num_Assigned_Cores (out of the Nmax cores you modelled). E.g. a partition may use 2 cores out of the 8, the RTOS decides which ones at runtime.

Here, I want to make sure we have an evaluation of required properties to capture multicore.

[Etienne13]

Thanks for the clarification. I understand now the usage of these properties (define threads affinity). To come back to issue#51, the proposed properties in the ARINC653 related issue are mapping properties from which we could infer (among other patterns) that a system models a multicore. However, I still believe it would make tools life easier not to have to infer this.

For example: if I have 3 processors in a system, two for which the core identifier is given. Does this mean I have a multi-core and use only 2 cores in my model? Or does this mean I have a dual core next to a single core processor... I don't think tool vendors want to deal with all the types of property combinations from which "system as a multicore" can be inferred.

What do you think?

[yoogx]

I agree there is no clear solution yet on how to solve this. As an exercise; we could capture a MPSoC like this one: https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html

This is the reason why I have never been confortable with the system-as-a-processor pattern.

[stevevestal]

I agree tool vendors do not want to have to try and infer multi-core from a host of potential variations on how to model things.

We currently use Scheduling_Protocol => (ARINC653) applied to an AADL system having processor subcomponents as a primary indicator that a multi-core rather than uni-processor module is modeled. Are others using that same property association for purposes other than modeling a system-of-processors multi-core? We don't use major frame and/or module schedule properties as user-declared indicators because those may not yet be present for schedule generation tools.

It was our own impression that the December ARINC 653 standard was worded to leave the door open to future standardization of ways to deal with virtual cores and module schedules in which windows of different partitions can run concurrently on different subsets of cores. It was worded so RTOS vendors who support that would not be in violation of the standard. But our impression was, it has not standardized those things yet.

A use case that we consider is, how independently can you specify an ARINC 653 workload from the specification of a hosting ARINC 653 module? How easy is it to re-bind a collection of ARINC 653 partitions and their connections and flows onto different uni-processor and multi-core ARINC 653 module configurations? What properties are part of the workload specification, part of the module specification, and part of the binding/hosting specification that gets changed when re-hosting?

So far, we've tried to avoid committing to specifics about how virtual versus physical cores would be handled. If a workload is bound to a uni-processor module, we let the AADL binding of the AADL processor to its partition virtual processor inherit down to the threads. If that workload is later bound to a multi-core, AADL bindings of individual threads to specific AADL processors are added to specify core affinity. We assumed the ARINC 653 core ID and number of assigned cores properties would be used to help address these issues (i.e., reserved for future use), again based on our interpretation of the future intent of the ARINC 653 standard.

One can speculate about using another layer of AADL virtual processors to model virtual cores that can then be mapped to hardware cores for ARINC 653 modules that support that. That mapping might be static (specified in the model) or might be dynamic (model specifies constraints). Will there be a need to specify something about bindings/affinities for hyper-threaded cores (hardware-implemented virtual cores)?

[jjhugues]

Decisions taken

• Document Is_Hardware in v2 core, minimal design intent to be captured, no need to go deeper into details.
• Processor_Core_Id probably belongs to deployment or code generation, first propose a wording, then discuss where to put this property definition
• Num_Assigned_Cores could be dropped at this stage
• No need to discuss enumerators for scheduling and concurrency control policies

[jjhugues]

Document updates

• 6.1 (22) mentions system as an alternative to processor category to capture processors
  XXXX must do device, do it for categories that have implemented_as
• 7.1 (4) has been introduced to document the Is_Hardware property
• A.7 (Modeling properties) defines
  Is_Hardware : aadlboolean applies to (system);
  The Is_Hardware property specifies that the system is to be interpreted as a hardware system, e.g. multi-core processor, device, MPSoC, etc.