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

[Pierre Dissaux]

Hello Julien,

So, points 1 to 4 are more or less the same: 
you argue that a system has too weak semantics to well represent a computing resource.

On the other side, does recursive containment of processors inside processors always represents realistic hardware components ?

Another option would be to introduce a new category to differentiate the two layers of the multicore:
- processor group containing processors
- processor containing cores (like in the Cheddar ADL)

But in the meantime, it is nice to have a solution that already works, using systems.

Pierre


From: Julien Delange 
Sent: Thursday, April 02, 2015 3:09 PM
To: AADL Modeling ; sae-aadl-users at lists.sei.cmu.edu 
Subject: Re: [aadl-modeling]: Modeling of ARINC653 multicore systems

Hi Pierre,

 

1.       The text should be “does not capture the hardware nature of the main processor” (not the core). When using a system to represent the processor, the semantics of the system is not supposed to capture a hardware component but rather a “box”. Using a processor for both the core and the main cpu would show that these are hardware component.

2.       I am not mentioning any particular tool. I am assuming that now, analysis tool consider a processor as a processor component, not a CPU. From a semantics point of view, it would make sense to keep the processor component to model the physical processor. I am just advocating against using the system to model everything: this would then remove the type system system of AADL – using a system for many modeling pattern is (from my perspective) a bad idea.
Also, the proposed changes could be for AADL v2.2 or AADLv3. The main motivation was to capture multicore for ARINC653 systems. The ARINC653 part related to multicore is not yet standardized, so, there are time from our end. But I would prefer to initiative the changes so that our core language is ready when we need to make additions to the ARINC653 annex.

3.       I do not say this is an issue but I think that using a system for modeling a processor is probably not the best solution from a semantics point of view, especially when we have a processor component type. 
If we keep using the system for everything, one can wonder why do we have component types and just use system type for everything. We might then have a poor semantics with a box for everything.

4.       I think this point has been discussed/addressed in the previous comments.

 

Julien.

 

 

From: aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu [mailto:aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Pierre Dissaux
Sent: Thursday, April 02, 2015 3:24 AM
To: AADL Modeling; sae-aadl-users at lists.sei.cmu.edu
Subject: Re: [aadl-modeling]: Modeling of ARINC653 multicore systems

 

Hi Julien,

 

I didn’t follow the discussions on that topic during the last meeting, but I well remember that the second option in your paper (System with Processors) was approved by the committee at the Winter 2014 meeting in Toulouse.

 

So, we do have a solution today to model multicore systems with or without virtual processors.

I will just comment the “Cons” you have identified for this current solution (§2.2 in your paper):

 

1. Do not capture the hardware nature of a core and potential interactions with buses. This might be critical

when analyzing the timing and shared resources of a core.

 

The core is represented by a processor. Why do you say it does not capture its hardware nature ?

 

2. Backwards compatibility of analysis tools (some analysis tools will not consider a system as a processor)

 

Which tool are you mentionning ?

We have no problem with that in AADL Inspector (Cheddar, Marzhin, ARINC 653 checker).

The changes we had to make one year ago to support systems as computing resources were very light.

 

Changing the components composition rules in the standard would have a much stronger impacts on both modelling and verification tools.

 

3. Compatibility of properties: properties using the processor as the OS needs to be updated. In that case, OSrelated

properties must also apply to system components then.

 

This has already been done for the Scheduling_Protocol

It is not a big issue to update a few property definitions if required

 

4. Lack of semantics: use the system as a container whereas a processor is a physical entity

 

This is a matter of point of view

A system can already have a Scheduling_Protocol, contain processors and virtual processors: it can actually be seen as a computing resource.

It also has all the required flexibility to incorporate complex architectures with buses and devices if necessary.

 

Moreover, the discussion we have today about processors could be extended to buses or devices. In all the cases, the system allows for a white box representation of complex hardware components.

 

Best regards

 

Pierre

 

From: Julien Delange 

Sent: Wednesday, April 01, 2015 8:39 PM

To: AADL Modeling ; sae-aadl-users at lists.sei.cmu.edu 

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

 

My apologies, please find the attachment.

 

Julien.

 

 

From: aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu [mailto:aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Julien Delange
Sent: Wednesday, April 01, 2015 2:18 PM
To: sae-aadl-users at lists.sei.cmu.edu; AADL Modeling (aadl-modeling at lists.sei.cmu.edu)
Subject: [aadl-modeling]: Modeling of ARINC653 multicore systems

 

Dear all,

 

As discussed during the last meeting, please find a white paper that explains the modeling of multicore systems for ARINC653 architectures and motivates having processor subcomponents in process components types.

 

Julien.

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