SystemC : une extension de C++

SystemC [94, 95] est une extension du langage C++ proposée par OSCI (Open SystemC Initia-tive) qui regroupe un nombre important d’industriels dans le domaine de la conception de produits microélectroniques pour modéliser des systèmes matériels. Depuis sa version 2.1 publiée en 2005, SystemC intègre un modèle de composant qui est intéressant pour la modélisation des systèmes. Dans la suite de cette section, nous présentons le modèle de composant de SystemC et nous pré-sentons son environnement d’exécution sous-jacent.

Les modules constituent les éléments d’encapsulation de comportements et de données en Sys-temC. Les modules peuvent interagir avec d’autres modules se trouvant dans leur environnement par le biais de leurs ports. Les ports permettent des échanges de données en entrée ou en sortie et sont définis par un type d’interface et par une cardinalité. En d’autres termes, un port encapsule un nombre défini d’interfaces de même type. Une interface définit le type des données qui peuvent être échangées ainsi que le sens de l’échange. Les ports des modules ont besoin d’être connectés

pour établir leurs interactions. SystemC propose une classe de base qui définit certaines opérations par défaut pour la mise en place de différents types de connecteurs afin de permettre l’échange de différents types de données entre les modules, éventuellement avec des protocoles d’interactions sophistiqués. Un ensemble de connecteurs pré-définis est aussi proposé. Cet ensemble comprend les signaux pour échanger des valeurs avec une synchronisation événementielle, des tampons avec des sémantiques de remplissage et de vidage différentes pour des échanges de données asynchrones, et des mutex et des sémaphores pour la synchronisation. Enfin, SystemC permet l’utilisation des objets, qui ne font pas partie des éléments architecturaux, mais qui sont fournis pour aider la programmation de contrôles dynamiques. Les modules SystemC peuvent êtres actifs et/ou réac-tifs. Deux modèles d’exécution sont proposés pour les modules actifs : sc-thread associe un flot d’exécution classique à une opération implémentée dans un module alors que sc-cthread (clocked thread) associe un flot d’exécution synchrone, contrôlé par une base de temps gérée via une horloge présente dans le système. Les opérations d’un module peuvent aussi être réactives (sc-method), ce qui permet de les exécuter en réaction à l’occurrence d’un événement. Dans ce cas, une liste de ports d’entrée qui peuvent déclencher une réaction est spécifiée pour chaque opération réactive. Il est important de noter que les actions et les réactions sont associées aux opérations et non pas aux modules, ce qui permet aux modules d’encapsuler à la fois des opérations actives et réactives.

Les modules SystemC sont définis pour la modélisation des composants matériels. Par consé-quent, ils sont instanciés une fois pour toute avant la simulation du système, et ne peuvent êtres détruits ou reconfigurés au cours de la simulation. Le cycle de vie d’un programme SystemC com-mence par une phase d’élaboration où tous les modules sont instanciés et interconnectés et continue par la simulation du système jusqu’à ce qu’un des modules fasse appel à la procédure de terminaison. En revanche, les objets qui ne font pas partie des éléments de modélisation architecturale, peuvent être instanciés et détruits dynamiquement. Alors que la première version de SystemC supportait uniquement un modèle de composition plat, certaines constructions ont été rajoutées à partir de la version 2 pour permettre la composition hiérarchique. Les modules peuvent donc contenir d’autres instances de module, et configurer leurs connections. Pour ce faire, ils doivent décrire cette partie de gestion de configuration dans une procédure pré-définie qui sera appelée pendant la procédure d’élaboration du système global. Le partage de module n’est pas permis ; une configuration de sys-tème en SystemC est forcément représentée sous forme d’arbre. Enfin, un support d’introspection est défini par SystemC pour découvrir, au cours de l’exécution, la configuration du système en prenant en compte les objets qui sont instanciés dynamiquement.

SystemC fournit deux éléments pour étendre le langage C++ afin d’y intégrer les concepts présentés ci-dessus. Premièrement, une librairie est fournie pour la définition des classes modèles et des procédures qui sont destinées à être utilisées par les programmeurs. Cette libraire comprend, entre autres, un fichier en-tête principal qui fournit les définitions des nombreuses macros qui doivent être utilisées pour définir et manipuler des modules, des ports, des interfaces, etc. Le deuxième élément consiste en une librairie runtime qui est destinée à être liée avec les programmes SystemC. Cette librairie fournit le point d’entrée des programmes SystemC et assure leur élaboration et leur simulation. Cette dernière fournit aussi un certain nombre d’outils qui permettent d’observer et de contrôler la simulation au cours de son exécution.

SystemC est largement utilisé pour la modélisation dans le domaine de la conception de systèmes électroniques en raison de ses atouts en ce qui concerne les outils de pro-grammation, de débogage et d’analyse. L’absence de générateur RTL depuis des modèles SystemC empêche cependant son déploiement dans un processus complet de conception de circuits.

2.3.7 Autres approches

Dans les sections précédentes, nous avons présenté les modèles pour l’adaptation logicielle propo-sant des apports différents en termes d’architecture. Cette section présente les spécificités d’autres

modèles méritant d’être soulignées.

Les propositions de Sun Microsystems dans le domaine des composants logiciels commencent avec les Java Beans [96] qui sont destinés à la mise en place des interfaces graphiques. Les compo-sants Java Beans sont en effet un modèle de programmation spécifique contenant des métadonnées sur les événements auxquels ils répondent, et sont destinés à être assemblés. Les Java Beans consti-tuent un pas en avant par rapport au langage Java en définissant un patron de conception pour y retrouver des composants logiciels. En effet, les Java Beans proposent de mettre en place des objets Java avec des interfaces bien définies, et de documenter les paquetages créés avec des informations contenues sous forme de Bean Infos. J. Sasitorn [97] apporte dans sa thèse deux contributions originales à l’approche composant. D’abord, il propose une analyse des techniques logicielles pour réaliser une plate-forme de composants pour les langages typés orientés objet supportant la géné-ricité. Ensuite, il propose sa plate-forme CGEN qui permet l’héritage entre composants, l’analyse statique des types entre composants (la réflexion enlevait cette possibilité).

La plate-forme AESOP [98] est un système créé à l’université de Carnegie Mellon pour dévelop-per des environnements de conception orientée-style (appelés Fables). Il offre un dépot étendu de composants, de connecteurs et de configurations (pattern de conception). Ils peuvent être utilisés pendant la construction de support pour des styles architecturaux. AESOP offre également un éditeur graphique qui peut être spécialisé afin de visualiser différents styles d’architecture. Il permet la vérification de type et l’analyse statique utilisant une description CSP. Il y a aussi une option de génération simple de code reflétant les connecteurs architecturaux. Cependant, pour chaque type de connecteur, un programme C++ implémentant le code du connecteur doit être fait. Il n’y a pas de solution par contre pour avoir des connecteurs modulaires ou les rendre configurables.

La plate-forme Classages [99] est une proposition académique de langage qui s’insère dans le cadre de la programmation basée sur des interactions (IOP). L’implémentation actuelle du modèle Classages fournit un support complet pour le langage. Mais le downcasting nécessaire à l’implé-mentation des connecteurs et des pluggers et la duplication du code en raison de la mise à plat de l’héritage pour les opérations de mixage compliquent la mise en œuvre. Classages est un nouveau langage qui est conçu pour fournir une isolation forte des composants logiciels en maîtrisant leurs interactions dynamiques et statiques. Le modèle d’interaction dynamique proposé par Classages est proche de celui d’ArchJava. Il est basé sur des ports qui implémentent des communications bidirectionnelles. Le modèle d’interaction statique est plutôt original ; il utilise la composition de composants à grain fin (mixage de méthodes) pour remplacer plus clairement l’héritage classique. Parmi les contributions de ce modèle, nous tenons aussi à citer la distinction entre les interac-tions d’un composant avec ses éléments internes (domaine de possession) et externes (domaine de collaboration).

D’une part, Senthil [100] apporte deux contributions originales à l’approche composant. D’abord, il montre qu’il peut obtenir de meilleures performances et une moindre complexité du code en s’ap-puyant sur la notion d’interface d’adaptation. Cela réduit le couplage entre les composants en abstrayant les données échangées au niveau des ports de communication. D’autre part, Zdun [101] apporte deux contributions originales à l’approche composant. Il propose de modéliser des pat-terns [98] d’architecture en utilisant neuf constructions élémentaires décrivant les interactions et la structure des entités de l’architecture. Ensuite, il démontre l’existence de ces constructions élé-mentaires à partir de l’analyse des patterns d’architecture les plus utilisées (incluant les design patterns). Aussi, Fissi [102] apporte une contribution originale à l’approche composant. Il propose l’ajout d’une unité de déploiement gérant le cycle de vie des composants. La découverte et la sé-lection de service se fait par l’utilisateur et est ensuite mémorisée et réutilisée automatiquement (cache d’assemblage). Enfin, on peut citer également les travaux de Chefrour [103] qui portent sur un modèle de composant adaptatif dans ACEEL : l’adaptation est centrée sur le composant logiciel.

2.3.8 Synthèse et conclusion

Sasitorn [97] propose une analyse des techniques logicielles pour réaliser une plate-forme de compo-sants pour les langages orientés objet supportant la généricité en la plate-forme CGEN. Il permet

l’héritage entre composants, l’analyse statique de types entre composants. Bruhn propose l’inspec-tion structurelle et l’observal’inspec-tion des interacl’inspec-tions entre les composants par l’utilisal’inspec-tion de callbacks. Il ne se base pas sur les modifications de l’implémentation des plates-formes d’exécution ni des containers et permet l’insertion de code (pour l’observation et la reconfiguration) de manière trans-parente pour le développeur. S. Robert et al.intègre la notion de connecteur dans CCM et capitalise l’expertise sur la gestion des interactions. Cela permet l’indépendance d’un composant par rapport à CORBA. Senthil [100] pour améliorer les performances et diminuer la complexité utilise la no-tion d’interface d’adaptano-tion. Il s’agit d’abstraire les données échangées au niveau des ports de communication. Zdun [101] propose de modéliser des patterns d’architecture [98] en utilisant des constructions élémentaires décrivant les interactions et la structure des entités de l’architecture. Fissi [102] propose plutôt l’ajout d’une unité de déploiement gérant le cycle de vie des composants. La découverte et la sélection de services se font par une demande à l’utilisateur et sont mémorisées. SOFA 2.0 propose la reconfiguration dynamique d’architecture hiérarchique en s’appuyant sur un modèle du contrôleur de composants. Fractal propose un modèle de composant hiérarchique avec partage de composants entre plusieurs composants composites. Les composants sont aussi dotés d’un ensemble de capacités réflexives paramétrables (contrôleurs et intercepteurs). Enfin, la modé-lisation de connecteur se fait par l’intermédiaire de bindings composites qui sont des composants jouant le rôle de connecteurs.

Nous avons vu la première notion fondamentale constituant les systèmes adaptatifs. Nous voyons dans la section suivante la seconde notion plus liée à la distribution logicielle : celle de service.