6.4      Buses

(1)   A bus component represents an execution platform component that can exchange control and data between memories, processors, and devices. This execution platform component represents a communication channel, typically hardware together with communication protocols. Supported communication protocols can be explicitly modeled through virtual buses (see Section 6.5).

(2)   Processors, devices, and memories can communicate by accessing a shared bus.  Such a shared bus can be located in the same system implementation as the execution platform components sharing it or higher in the system hierarchy.  Memory, processor, and device types, as well as the system type of systems they are contained in, can declare a need for access to a bus through a requires bus reference. 

(3)   Buses can be connected directly to other buses by one bus requiring access to another bus.  Buses connected in such a way can have different bus classifier references.

(4)   Connections between software components that are bound to different processors transmit their information across buses whose protocol supports the respective connection category.

Legality Rules

Category

Type

Implementation

bus

Features

·         requires bus access

·         feature group

·         feature

Flow specifications: no

Modes: yes

Properties: yes

Subcomponents:

·         virtual bus

·         abstract

Subprogram calls: no

Connections: no

Flows: no

Modes: yes

Properties: yes

 

(L1)      A bus type can have requires bus access declarations, a modes subclause, and property associations.

(L2)      A bus type must not contain any flow specifications.

(L3)      A bus implementation can contain virtual bus and abstract subcomponent declarations. 

(L4)      A bus implementation can contain a modes subclause and property associations. 

(L5)      A bus implementation must not contain flows subclause, or subprogram calls subclause.

Standard Properties

-- Properties specifying bus transmission properties
Allowed_Connection_Type: list of enumeration 
                        (Sampled_Data_Connection, Immediate_Data_Connection,
                         Delayed_Data_Connection, Port_Connection,
                         Data_Access_Connection,
                         Subprogram_Access_Connection)
 
Allowed_Physical_Access_Class: list of classifier ( device, processor, memory, bus )
Allowed_Physical_Access: list of reference ( device, processor, memory, bus )
Allowed_Message_Size: Size_Range
Transmission_Type: enumeration ( push, pull )
Transmission_Time: record (
    Fixed: Time_Range;
    PerByte: Time_Range; )
Prototype_Substitution_Rule: inherit enumeration (Classifier_Match, Type_Extension, Signature_Match)
-- Hardware description properties
Hardware_Description_Source_Text: inherit list of aadlstring
Hardware_Source_Language: Supported_Hardware_Source_Languages 
 
Access_Right : Access_Rights => read_write  
-- Protocol support
Provided_Virtual_Bus_Class : inherit list of classifier (virtual bus)
Provided_Connection_Quality_Of_Service : inherit list of Supported_Connection_QoS
-- mode related properties
Resumption_Policy: enumeration ( restart, resume )
-- Virtual machine layering
Implemented_As: classifier ( system implementation )
 

Semantics

(5)   A bus support physical communication between processors, memories, and devices.  This allows a processor to support execution of source text in the form of code and data loaded as binary images into memory components.  A bus allows a processor to access device hardware when executing device software. A bus may also support different port and subprogram connections between thread components bound to different processors.  The Allowed_Connection_Type property indicates which forms of access a particular bus supports.  The bus may constrain the size of messages communicated through data or event data connections.

(6)   A bus component provides access between processors, memories, and devices.  It is a shared component, for which access is required by each of the respective components.  A device is accessible from a processor if the two share a bus component.  A memory is accessible from a processor if the two share a bus component.

(7)   Buses can be directly connected to other buses.  This is represented by one bus declaration specifying access to another bus in its requires subclause.

(8)   Physical access to a bus can be restricted to certain types of devices, memory, buses, and processors.  This is achieved with the property Allowed_Physical_Access.

(9)   Bus components can have different property values under different operational modes.

(10)  A bus component can include protocols in its abstraction.  Protocols provided by a bus can be specified with the Provided_Virtual_Bus_Class property.  They are matched against protocol requirements of connections and virtual buses as specified by their Required_Virtual_Bus_Class property.  If desired instances of protocols supported by a bus can be explicitly modeled as virtual bus subcomponents.  In that case the connection or virtual bus requiring a specific protocol can be bound to the specific virtual bus instance. 

(11)  Virtual buses (protocols) may be implemented in the bus hardware or in software.  The virtual bus software executes on processors connected to the bus, whose bound threads communicate over connections that require the protocol. 

(12)  The bus is intended to be an abstraction of a physical bus or network.  If it is desirable, the internals of the bus can be modeled by AADL as a system in its own right, i.e., an application system and an execution platform.  This system implementation description can be associated with the bus component declaration by the Implemented_As property (see Section 14).

Processing Requirements and Permissions

(13)  A method of implementation shall define how the final size of a transmission is determined for a specific connection.  Implementation choices and restrictions such as packetization and header and trailer information are not defined in this standard.

(14)  A method of implementation shall define the methods used for bus arbitration and scheduling.  If desired this can be modeled by a notation of your choice and associated with a bus via property.  Alternatively, it can be modeled through an AADL system model and associated with the bus through an Implemented_As property.

Examples

package Hardware

public

bus VME

end VME;

 

memory Memory_Card

features

   Card_Connector : requires bus access VME;

end Memory_Card;

 

processor PowerPC

features

   Card_Connector : requires bus access VME;

end PowerPC;

 

processor implementation PowerPC.Linux

end PowerPC.Linux;

 

system Dual_Processor end Dual_Processor;

 

system implementation Dual_Processor.PowerPC

subcomponents

   System_Bus: bus VME;

   Left: processor PowerPC.Linux;

   Right: processor PowerPC.Linux;

   Shared_Memory: memory Memory_Card;

 

connections

   LCConn: bus access System_Bus <-> Left.Card_Connector;

   RCConn: bus access System_Bus <-> Right.Card_Connector;

   SMConn: bus access System_Bus <-> Shared_Memory.Card_Connector;

end Dual_Processor.PowerPC;

end Hardware;