[aadl]: [aadl-modeling]: Modeling of ARINC653 multicore systems

[Jérôme Hugues]

Hi,


Le 2 avr. 2015 à 16:22, Julien Delange <jdelange at sei.cmu.edu> a écrit :

> Good point about the containment and this point was also discussed during the last meeting. One suggested workaround during the meeting would be to add a rule to limit the level of nesting in the hierarchy: a processor component can only have one level of processor sub-components. This would then limit potential semantics inconsistencies (what means to have three level of processors containment?) while keeping the changes minimal. On the other, having new types would then need to adapt the standard and the associated annex (such as the ARINC653 annex). I am skeptical about the return on investment of such a change.

It seems part of the debate is how much details we want, and what are the analysis objectives.
- as a rebuttal, 3 levels can be used if you want to model processor, core, and then hyper threading, and a fourth one if we add  inside multiples ALU for out-of-order execution. Of course, the question is to know whether this belongs to an architectural AADL model or not.
- system seems a good option to model the pure hardware part (cores, interconnect fabric, etc), using the Implemented_As, but it creates issue in terms of binding elements.as we discussed in the past. (Oleg: how could you bind one subcomponents to subcomponents of the system referred to in the Implemented_As property?)

There is IMHO one big area of clarification for the processor category: they represent both the physical components and the configuration of the OS (e.g. scheduler), we need to clarify the separation of concerns between OS configuration (the core id I use in RT-POSIX or other RTOS for instance, priority ranges, scheduler, etc) and the CPU configuration (e.g. the configuration of the interconnect fabric of a P4080 so that a core has a specific path to access memory). 

As far as I could conceptualize it, a core in a multi-core system is a parallel unit of computation (as seen from software, and at coarse grain), an ARINC partition a serial one (time partitioning). Both refers to some notion of scheduler configuration. Of course, one needs to avoid clashes between patterns, but this seems difficult to avoid.

I’d like we separate the two, and then bind one logical core (should it be a partition, a process or a RTOS) to physical ones. It is a requirement I have for some projects here so as to define a virtual deployment on logical cores, and then map it to various CPU configurations. I do not think it is easily addressable in the "processor in processors" mapping as I miss one level  of indirection/configuration provided by some RTOS: mapping logical core (as seen from API) to physical ones (see http://blogs.windriver.com/vxworks/2011/02/vxworks-pushing-the-limits-on-system-flexibility.html for some food for thoughts)

To make a long mail shorter: I think we should discuss patterns, but also use cases for analysis so as to converge on a design, requirements for OS configuration as needed for code generation are different from those for scheduling analysis, and modular modeling. We need also to clarify how far we go in detailed modeling. 

Regards,

—
Jerome HUGUES
Enseignant-Chercheur/Associate Professor 
Ingénierie des Systèmes Embarqués/Embedded Systems Engineering

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l’Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr 
Tel (+33) 5 61 33 91 84 - Fax (+33) 5 61 33 83 30
Plan d'accès/Access map

-------------- next part --------------
HTML attachment scrubbed and removed