13.2    System Binding

(1)   This section defines how binary images produced by compiling source units are assigned to and loaded onto processor and memory resources, taking into account requirements for component sharing and the interconnect topology between processors, memories and devices.  The decisions and methods required to combine the components of a system to produce a actual system implementation are collectively called bindings.

Naming Rules

(N1)     The Allowed_Processor_Binding property values must evaluate to a processor, virtual processor, or a system that contains a processor in its component containment hierarchy. 

(N2)     The Allowed_Memory_Binding property values must evaluate to a memory, a processor that contains memory or a system that contains a memory or a processor containing memory in its component containment hierarchy. 

Legality Rules

(L1)      The memory requirements of ports and data components are specified as property values of their data types or by properties on the port feature or data subcomponent.  Those property associations can have binding-specific values. 

Consistency Rules

(C1)Every mode-specific configuration of a system instance must have a binding of every process component to a (set of) memory component(s), and a binding of every thread component to a (set of) processor(s). 

(C2)In the case of dynamic process loading, the actual binding may change at runtime.  In the case of tightly coupled multi-processor configurations, such as dual core processors, the actual thread binding may change between members of an actual binding set of processors as these processors service a common set of thread ready queues. 

(C3)Multiple software components may be bound to a single memory component.

(C4)A software component may be bound to multiple memory components. 

(C5)A thread must be bound to a one or more processors. If it is bound to multiple processors, the processors share a ready queue, i.e., the thread executes on one processor at a time. 

(C6)Multiple threads can be bound to a single processor.

(C7)All software components for a process must be bound to memory components that are all accessible from every processor to which any thread contained in the process is bound.  That is, every thread is able to access every memory component into which the process containing that thread is loaded.

(C8)A shared data component must be bound to memory accessible by all processors to which the threads sharing the data component are bound.

(C9)For all threads in a process, all processors to which those threads are bound must have identical component types and component implementations.  That is, all threads that are contained in a given process must all be executing on the same kind of processor, as indicated by the processor classifier reference value of the Allowed_Processor_Binding_Class property associated with the process.  Furthermore, all those processors must be able to access the memory to which the process is bound.

(C10)   The complete set of software components making up the functionality of the processor must be bound to memory that is accessible by that processor.

(C11)   Each thread must be bound to a processor satisfying the Allowed_Processor_Binding_Class and Allowed_Processor_Binding property values of the thread. 

(C12)   The Allowed_Processor_Binding property may specify a single processor, thus specifying the exact processor binding.  It may also specify a list of processor components or system components containing processor components, indicating that the thread is bindable to any of those processor components.

(C13)   Each process must be bound to a memory satisfying the Allowed_Memory_Binding_Class and Allowed_Memory_Binding property values of the process.  The Allowed_Memory_Binding property may specify a single memory component, thus specifying the exact memory binding. It may also specify a list of memory components or system components containing memory components, indicating that the process is bindable to any of those memory components.

(C14)   The memory requirements of the binary images and the runtime memory requirements of threads and processes bound to a memory component must not exceed that memory’s capacity. The execution time requirements of all threads bound to a processor must not exceed the schedulable cycles required to ensure that all thread timing requirements are met.  These two constraints may be checked statically or dynamically.  Runtime detection of such a memory capacity or timing requirements violation results in an error that the application system can choose to recover from.

Semantics

(2)   A complete system instance is instantiated and bound by identifying the actual binding of all threads to processors, all binary images reflected in processes and other components to memory, and all connections to buses if they span multiple processors.  The actual binding can be recorded for each component in the containment hierarchy by property associations declared within the system implementation. 

(3)   The actual binding must be determined within specified binding constraints. Binding constraints of application components to execution platform components are expressed by the allowed binding and allowed binding class properties for memory, processor, and bus.  In the case of an allowed binding property, the execution platform component is identified by a sequence of ‘.’ (dot) separated subcomponent names. This sequence starts with the subcomponent contained in the component implementation for which the property association is declared. Or the sequence begins with the subcomponent contained in the component implementation of the subcomponent or system implementation for which the property association is declared. This means that the property association representing the binding constraint or the actual binding may have to be declared as a component instance property association of a component that represents a common root of the components to be bound.

Processing Requirements and Permissions

(4)   A method of building systems is permitted to require bindings of selected kinds to be fixed at development time, or to be fixed at the time of actual system construction.  A method of building systems is permitted to allow bindings of selected kinds to change dynamically at runtime.  For example, a method of building systems may require process to memory binding and loading to be fixed during actual system construction, and may require thread to processor bindings to be fixed at mode changes.  Other choices are possible and permitted.

(5)   A method of building systems must check and enforce the semantics and legality rules defined in this standard.  Property associations may impose constraints on allowed bindings.  The access semantics impose a number of constraints on allowed bindings for processes and threads to execution platform systems, and ultimately to processors and memories.  In general, the semantic constraints depend on the particular software and hardware architecture interconnect topologies.  In particular, for most hardware and operating system configurations all threads contained in a process must execute on the same processor.  Such additional restrictions must be taken into account by the method of building systems.  A method of building systems is otherwise permitted to make any partitioning and binding choices that are consistent with the semantics and legality rules of this standard.

NOTES:

If multiple processes share a component, then the physical memory to which the shared component is bound will appear in the virtual address space of all those processes.  This physical memory is not necessarily addressed using either the same virtual address in different processes or the same physical address from different processors.  An access property association may be used to specify different addresses used to access the same component from different processors.

The AADL supports binding-specific property values.  This allows different property values to be specified for a component property whose values are sensitive to binding decisions. 

Examples

package Deployment

system smp

end smp;

 

system implementation smp.s1

-- a multi-processor system

subcomponents

   p1: processor cpu.u1;

   p2: processor cpu.u1;

   p3: processor cpu.u1;

end smp.s1;

 

process p1

end p1;

 

process implementation p1.i1

subcomponents

   ta: thread t1.i1;

   tb: thread t1.i1;

end p1.i1;

 

thread t1

end t1;

 

thread implementation t1.i1

end t1.i1;

 

processor cpu

end cpu;

 

processor implementation cpu.u1

end cpu.u1;

 

system S

end S;

 

system implementation S.I

-- a system combining application components

-- with execution platform components

subcomponents

   p_a: process p1.i1;

   p_b: process p1.i1;

   up1: processor cpu.u1;

   up2: processor cpu.u1;

   ss1: system smp.s1;

properties

    Allowed_Processor_Binding => ( reference (up1), reference (up2) )

                                     applies to p_a.ta;

    Allowed_Processor_Binding => ( reference (up1), reference (up2) )

                                     applies to p_a.tb;


   -- ta is restricted to a subset of processors that tb can be bound to;

   -- since ta and tb are part of the same process they must be bound to the

   -- same processor in most hardware configurations

   Allowed_Processor_Binding => reference (ss1.p3 ) applies to p_b.ta;

   Allowed_Processor_Binding => reference (ss1 ) applies to p_b.tb;

end S.I;

end Deployment;

NOTES:

Binding properties are declared in the system implementation that contains in its containment hierarchy both the components to be bound and the execution platform components that are the target of the binding.  Binding properties can also be declared separately for each instance of such a system implementation, either as part of the system instantiation or as part of a subcomponent declaration.