![]() ![]() |
||||
|
||||
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 physical system
implementation are collectively called bindings.
Naming Rules
TheAllowed_Processor_Bindingproperty values evaluate to a processor, or a system that
contains a processor in its component containment hierarchy.
TheAllowed_Memory_Bindingproperty values 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.
The first identifier of the property value for each element
of a property value list must exist in the
local namespace of the containing component implementation or in one of its containing
component implementations. The first containing component with a match must be an execution
platform system, i.e., must be a processor component or a system component containing a
processor or memory in its containment sub-hierarchy. Subsequent identifiers must exist in the
local namespace of the component implementation associated with the component identified by
the preceding identifier. The final identifier identifies the system, processor, or memory component
that represents a legal candidate for processor or memory binding.
Legality Rules
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). In the case of dynamic process loading, the actual binding may change at
runtime. In the case of tightly coupled multi-processor configurations, 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. Multiple software components may be bound to a single
memory component. A software component may be bound to multiple memory components. A
thread must be bound to a single processor. Multiple threads can be bound to a single processor.
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.
A shared data component must be bound to memory accessible
by all processors to which the
processes sharing the data component are bound.
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_Classproperty associated with
the process. Furthermore, all those processors must be able to access the memory to which the
process is bound.
The complete set of software components making up the
kernel address space of a processor
must be bound to memory that is accessible by that processor.
Each thread must be bound to a processor satisfying the
Allowed_Processor_Binding_Classand Allowed_Processor_Bindingproperty
values
of the thread. TheAllowed_Processor_Bindingproperty 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.
Each process must be bound to a memory satisfying the
Allowed_Memory_Binding_Classand Allowed_Memory_Bindingproperty values
of the
process. The Allowed_Memory_Bindingproperty 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.
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 insure 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.
The memory requirements of ports and data components
are specified as property values of their
data types. Those property associations can have binding-specific values.
Semantics
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 with in the
system iimplementation.
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
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 physical 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 physical system construction, and may require thread to processor bindings to be
fixed at mode changes. Other choices are possible and permitted.
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
systemsmp
endsmp;
system implementation smp.s1
-- a multi-processor system
subcomponents
p1: processor cpu.u1;
p2: processor cpu.u1;
p3: processor cpu.u1;
endsmp.s1;
processp1
endp1;
process implementation p1.i1
subcomponents
ta: thread t1.i1;
tb: thread t1.i1;
endp1.i1;
threadt1
endt1;
threadimplementation t1.i1
endt1.i1;
processorcpu
endcpu;
processorimplementation cpu.u1
endcpu.u1;
systemS
endS;
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;
endS.I;
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. |
||||