Description du format

Le format ip-xact contient sept types de mod`eles. Les r`egles de construction syntaxiques de chacun sont sp´ecifi´ees en xsd (xml Schematic Description). Plutˆot que les sch´emas xsd du

standard, nous avons pr´ef´er´e retenir une m´eta-mod´elisation plus proche d’uml. Les diagrammes pr´esent´es sont extraits de la th`ese d’Aamir Mehmood Khan?. Au pr´ealable nous ´enum´erons les sept types de description et leur rˆole :

– bus definition description pour les types d’un bus ;

– abstraction definition description pour la repr´esentation plus d´etaill´ee d’un bus ; – component description pour la structure d’un composant ;

– design description pour les syst`emes et sous-syst`emes ;

– abstractor description pour des adaptations entre diff´erentes interfaces ; – generator chain description pour la partie g´en´eration de l’assemblage ;

– design configuration description pour des informations compl´ementaires la generator chain ou la design description.

Dans cette section, nous nous concentrons sur les concepts essentiels `a la construction d’un mod`ele de design. La figure 2.7 donne un aper¸cu global des paquetages ip-xact n´ecessaires ainsi que leurs inter-d´ependances. Chacun de ces paquetages correspond `a un concept diff´erent d’ip- xact. Le paquetage Component contient les ´el´ements qui d´ecrivent la structure d’un composant (ou “IP”). Il est ´etroitement li´e aux informations contenues dans les paquetages BusDefinition etAbstractionDefinition. Le paquetageBusDefinitiondonne les informations de base concernant un bus de communication utilis´e par le syst`eme, alors que l’AbstractionDefinitiondonne des informa- tions relatives au niveau d’abstraction de communication utilis´e (i.e.,tlm, rtl). Le paquetage Abstractor contient les ´el´ements n´ecessaires `a la cr´eation/s´election de passerelles de communi- cations entre diff´erents composants ip-xact d´ecrits `a diff´erents niveaux d’abstraction. Il d´ecrit en particulier comment un port transactionnel regroupe un ensemble de ports de base (rtl) repr´esentant les signalisations n´ecessaires `a la transaction. Enfin, le paquetage Design contient les divers ´el´ements de mod`ele permettant de manipuler, r´ef´erencer et instancier les composants utilis´es pour l’´elaboration d’un syst`eme.

Des propri´et´es fonctionnelles et extra-fonctionnelles peuvent ˆetre int´egr´ees dans une d´efi- nition de composant ou d’un design en utilisant ce qu’on appelle des vendor extensions. Le format et le type d’information contenu dans une vendor extension propri´etaire ne font pas partie de la norme. Ces informations ne peuvent donc pas ˆetre partag´ees entre diff´erents outils et fournisseurs sans l’impl´ementation du m´ecanisme de reconnaissance et d’interpr´etation sp´e- cifique. Cela empˆeche l’int´egration des IPs d´evelopp´ees `a la main ou au travers des diff´erents outils disponibles. Une autre limitation, mise en ´evidence dans la th`ese de S´ebastien Revol?, est l’absence de m´ecanisme permettant de g´erer facilement les structures r´ep´etitives comme pour des tableaux de registres ou d’instances d’un composant. Ces limitations et d’autres qui seront r´ev´el´ees dans la description d´etaill´ee d’ip-xact nous incitent `a penser que les formalismes de d´efinition plus g´en´eriques tels que ceux qu’on trouve en uml pourraient ˆetre utiles.

Figure 2.7 – Aper¸cu du m´eta-mod`_{ele ip-xact}

Composant En ip-xact, un processeur, un p´eriph´erique, un ´el´ement de stockage, un bus, tous sont des composants. En g´en´eral, les composants peuvent ˆetre statiques ou configurables. Les composants statiques ne peuvent pas ˆetre modifi´es mais seulement instanci´es. En revanche les composants configurables peuvent n´ecessiter un param´etrage lors de leur instanciation. Contrai- rement `a d’autres mod`eles de composants, ip-xact ne permet pas d’int´egrer directement un com- posant dans un autre. Pour mod´eliser une hi´erachie il faut passer par un design (voir page 22). La figure 2.8 montre une vue simplifi´ee du m´eta-mod`ele Component. Un composant peut poss´eder de nombreuses propri´et´es dont des interfaces, des descriptions d’espace m´emoire et indirectement des ports physiques. Il contient ´egalement des r´ef´erences aux descritions de son comportement. La seule propri´et´e obligatoire est son identificateur unique (identifiantvlnvpour Vendor, Library, Name, Version) qui permet de le r´ef´erencer.

Les interfaces Les ports qui participent `a un mˆeme protocole de communication sont regroup´es sous le concept de Bus Interface. Les attributs d’une interface de bus sont sp´ecifi´es dans deux m´eta-classes distinctes mais compl´ementaires : BusDefinition et BusAbstraction. Le concept de Bus Interface introduit une vision abstraite des communications avec l’introduction des ports logiques.

La d´efinition de bus L’´el´ement busDefinition d´ecrit les attributs de haut niveau des inter- faces connect´ees `a un bus ou r´eseau. Il d´efinit les informations structurelles associ´ees `a un type de bus, ind´ependant du niveau d’abstraction, comme le nombre maximum de maˆıtres et

Figure 2.8 – M´eta-mod`ele de composants IP-Xact

d’esclaves admis sur le bus. Une variable bool´eenne directConnection obligatoire pr´ecise quelles connexions sont autoris´ees. Une valeur vraie sp´ecifie que ces interfaces peuvent ˆetre connec- t´ees directement d’un maˆıtre `a un esclave alors qu’une valeur fausse indique que la connexion ne peut se faire que vers un miroir de l’interface consid´er´ee. Le dernier bool´een obligatoire est la variableisAddressable qui sp´ecifie, si elle est `a vrai, que le bus poss`ede des informations d’adressage m´emoire. ip-xact fournit ´egalement un m´ecanisme visant `a ´etendre ces d´efinitions de bus. L’extension d’une d´efinition de bus permet la d´efinition des r`egles de compatibilit´e avec les bus existants. Par exemple, la d´efinition d’un bus AHB (Advanced High-performance Bus) peut ´etendre la d´efinition de sa version simplifi´ee l’AHBlite. Une faiblesse notoire de ce type d’extension est de ne pas s’appuyer sur la g´en´eralisation/sp´ecialisation que l’on rencontre dans les mod`eles de classes. La notion d’h´eritage n’est pas support´ee en ip-xact.

La d´efinition d’abstraction L’AbstractionDefinitiond´ecrit les aspects de bas niveau d’un bus. Une AbstractionDefinition donne des attributs plus pr´ecis pour une d´efinition de bus donn´e. Il peut y avoir plusieurs d´efinitions d’abstraction pour la d´efinition d’un mˆeme bus, par exemple une pour la version rtl et une autre pour la version tlm. UneAbstractionDefinitiondoit contenir deux ´el´ements obligatoires, son busType et ses ports. L’attribut busType donne la r´ef´erence au

BusDefinition pour lequel cette AbstractionDefinition est d´efinie. Comme pour busDefinition, une AbstractionDefinition peut ´etendre une autre AbstractionDefinition modulo certaines contraintes. L’AbstractionDefinitionpeut ´etendre ou modifier la d´efinition de ports logiques (`a ne pas confondre avec les ports physiques que poss`ede un composant), en ajouter de nouveaux, ou en rendre certains ill´egaux.

Le design Un design IP-XACT est un assemblage d’objets composant. Il repr´esente un syst`eme ou un sous-syst`eme d´efinissant l’ensemble des instances de composants et leurs interconnexions, (figure 2.9). Les interconnexions peuvent ˆetre entre interfaces ou entre ports de composants. Les instances de composants r´ef´erencent leur description g´en´erique. Comme ces ´el´ements du design sont des sous-syst`emes potentiellement param´etr´es, ils peuvent ˆetre configur´es pour r´epondre aux besoins sp´ecifiques du design. Ces valeurs de configuration sont sp´ecifi´ees `a l’aide d’´el´ements configurableElementValues(r´ef´erenc´es par les instances de composants). Le concepteur peut alors connecter les composants en utilisant diff´erents types d’´el´ements de connexion. Les diff´erents types de connexions possibles sont l’Interconnection,MonitorInterconnection,AdHocInterconnectionet HierConnection. L’Interconnection est une simple connexion point `a point entre Bus Interfaces de deux composantes compatibles. Elle est par cons´equent la plus utilis´ee pour la connexion de composants dans un design pourvu d’un bus de communication. Cependant, sa nature point `a point lui interdit tout broadcast d’informations `a des cibles multiples. LeMonitorInterconnection est un type sp´ecial d’interconnexion qui sp´ecifie la connexion entre une interface et une liste d’in- terfaces de supervision/monitorage. L’AdHocConnection relie deux ports directement, les ports de type wire mais aussi les ports transactionnels, sans l’aide d’une interface de bus. Il peut aussi connecter des ports (internes) d’instance de composants contenus dans un composant aux ports (externes) de ce dernier dans le cas d’un composant hi´erarchique. Enfin, les connexions hi´erarchiques (HierConnection) connectent des composants provenant de diff´erents niveaux hi´e- rarchiques au travers d’une interface de bus.

Les Abstracteurs L’Abstractorest l’´el´ement ip-xact de plus haut niveau qui soit inclus dans le format. Il est utilis´e pour adapter les communications entre deux types d’interfaces de bus ayant un niveau d’abstraction diff´erent et partageant les mˆemes types de bus. Des designs contenant des composants d´ecrits `a diff´erents niveaux doivent contenir ce type d’´el´ements. Un abstracteur contient deux interfaces, qui doivent ˆetre la d´efinition du bus et les d´efinitions d’abstraction des diff´erents niveaux. Contrairement `a un composant, un abstracteur n’est pas r´ef´erenc´e `a partir d’un design, mais plutˆot r´ef´erenc´e par une configuration d’un design. L’´el´ement de mod`ele abstracteur ressemble beaucoup `a une interface de bus.

SPIRIT::Design + InterfaceRef: String [1] HierConnection + activeInterface 1 + ident: VersionedIdentifier [1] Design + instanceName: String [1] ComponentInstance Connection + ident: VersionedIdentifier [1] SPIRIT::Component::Component + componentInstances * + referenceId: String [1] + value: String [0..1] ConfigurableElementType + configurableElementValues * 1 + componentRef + busRef: String [1] + componentRef: String [1] Interface + name: String [1] + tiedValue: UnlimitedNatural [0..1] AdHocConnection + name: String [1] Interconnection + activeInterface 2 + name: String [1]

MonitorInterconnection + activeInterface 1 1..* + monitorInterface

+ componentRef: String [1] + portRef: String [1] InternalPort + portRef: String [1] ExternalPort + internalPortRef 1..* + externalPortRef *

Figure 2.9 – M´eta-mod`ele de design IP-Xact