1 / 9

Cheddar architecture Description language : current status

November 2012 J. Legrand, P. Dissaux, L. Lemarchand, S. Rubini, V. Gaudel, A. Plantec, F. Singhoff. Cheddar architecture Description language : current status. Requirements.

frisco
Télécharger la présentation

Cheddar architecture Description language : current status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. November 2012 J. Legrand, P. Dissaux, L. Lemarchand, S. Rubini, V. Gaudel, A. Plantec, F. Singhoff Cheddar architecture Description language : current status

  2. Requirements Current Cheddar ADL is quite simple : must be extend to be applied on new domains : FPGA, Multiprocessor architectures with caches/cores and shared memory, N-level of hierarchical scheduling Should be as close as possible with real-time scheduling and queueing system theorys (Classic models, synchronization/dependencies, scheduler parameters) Must stay simple and easy/quick to use/understand Maintain existing features. Allow transformation to AADL/Marte/others supported ADLs Provide isolation : spatial and temporal Both hardware/software modelingand software deployment: required fo real-time systems analysis, user/designer understanding

  3. Cheddar ADL concepts Basic entities: Components: reusable unit. A component has a type, an unique name and attributes. Part of a system to analyze. Bindings: relationships between components. Model a resource allocation between n providers and m consumers. Types of entity: Hardware components: resources provided by the execution environment. Processor, cache, core, memory unit, network. Software components: model the design of the software. Task, resource, buffer, dependency, message. Bindings: enforce either temporal or spatial isolation.

  4. Semantic of components Software components : Address space: model a logical unit of memory. May be associated to an address protection mechanism Task: model a flow of control. Run any type of program (including any operating system function such as a scheduler). Statically defined in an address space. Resource : any data structure, shared by tasks or not, synchronized or not. May model asynchronous communication between tasks of the same address space. Statically defined in an address space. Buffer : model queued data exchanges between tasks of the same address space. Statically defined in an address space. Message : model queued data exchanges between tasks located in different address spaces.

  5. Semantic of components Hardware component: Core: model an entity providing a resource to sequentially run flow of controls. Deployment unit for a software component. Cache: model memory caches related to one of several cores. Data/instruction cache. Processors: composed of a set of cores and caches. Deployment unit for a software component. Memory: model an entity providing a physical memory unit. Deployment unit for a software component. Network: any communication link between any hardware components. Monocore processor : schedule tasks independently Multicore processor : schedule tasks globally with a set of cores Expliquer le concept de multi et mono cœur, ces concepts sont liés à la facon dont l'ordonnancement est réalisé

  6. Semantic of bindings A binding is a relationship between two set of entities : source entities (resource consumer entities) and sink entities (resource entities). Static binding : a static binding contains a tabledefines how the resources are statically allocated by the resource consumers. Example : may model an off-line scheduling of task or a statically defined set of addresses for each software component inside an address space. Dynamic binding: a dynamic binding contains an algorithm. The algorithm defines how the resources are dynamically allocated by the resource consumers. Example : an algorithm may be an on-line scheduler of tasks or a malloc algorithm for a set of software components inside an address space.

  7. Semantic of bindings Static & Dynamic bindings: ENTITY Generic_Binding SUBTYPE OF ( Generic_Object ); source_entity : Generic_Objects_Set; sink_entity : Generic_Objects_Set; DERIVE SELF\Generic_Object.object_type : Objects_Type := Binding_Type; END_ENTITY; ENTITY Static_Binding SUBTYPE OF ( Generic_Binding ); allocation : STRING; END_ENTITY; ENTITY Dynamic_Binding SUBTYPE OF ( Generic_Binding ); allocation : Scheduling_Parameters; END_ENTITY;

  8. Examples Examples of cardinality and allowed bindings: Consumers => Providers Il faut rédiger les règles ci-dessous avec les entités du méta modèle cheddar afin de bien définir la sémantique de connection autorisée ! Flot de contrôle/ordonnancement  : 1..N generic_task => 1..M processors, XMLV4 1..N generic_task => 1..1 processors, XMLV3 1..N generic_task => 1..M cores, XMLV3 1..N generic_task => 1..M scheduling_task_type, XMLV4, tache à droite = virtual processor AADL Architectural/déploiement : 1..N generic_task => 1..1 address space 1..N buffers => 1..1 address space 1..N resources => 1..1 address space 1..N address space => 1..M memory 1..N processors => 1..M network …

  9. Status Bindings: Bindings are part of the current Cheddar ADL meta model. XML Printers/Parsers are Ok Next steps : Simulation engine must be coupled with bindings. Planned for next meeting. Relationships with ARINC 653 configuration tables.

More Related