B.2. Présentation des éléments de description d’un composant

Pour réaliser la modélisation d’un composant en vue d’en réaliser la vérification par la

méthode présentée ici, il est nécessaire de décrire les trois types d’éléments (ressources,

entrées /sorties et configuration) qui sont utilisés.

III.B.2.a. La définition des ressources d’un composant ou la

description des registres

Le premier type de paramètres qui est utilisé pour caractériser un composant est celui

décrivant les ressources du composant. La définition des ressources correspond à la définition

des registres du composant.

Cette spécification des ressources du composant réalise la définition pour chaque

registre :

• Du nom et de l’adresse ;

• Des champs et du type d’accès (lecture / écriture).

Un tel format a déjà été développé au sein de l’équipe TV. Une représentation de ce

format de description est donnée sous la forme d’une pseudo grammaire sur la Figure 26. A

partir de cette description, un outil a été développé et permet la génération de programme de

test de bas niveau permettant de vérifier tous les types d’accès aux registres. Ce formalisme

peut être intégré directement dans le cadre de notre modélisation, ainsi que la génération de ce

type de test.

Figure 26 : Présentation de la définition des registres sous la forme d’une grammaire et

exemple de description

AXIOME → REGISTER_DEF

REGISTER_DEF → Register"nom_registre " SIZE_DEF

SIZE_DEF → Size" taille " OFFSET_DEF

OFFSET_DEF → Offset" offset " BITFIELD_DEF

BITFIELD_DEF → BitfieldBITFIELD_TYPE

BITFIELD_TYPE → {" nom_champ " | - }:"bit_index" :"bit_index"

{BITFIELD_DEF * | INITVAL_DEF}

INITVAL_DEF → Initialvalue" valeur_reset " ACCESS_DEF

ACCESS_DEF → AccesstypeACCESS_TYPE

ACCESS_TYPE → { RO| RW} REGISTER_DEF *

HDPP

Exemple de définition des ressources Register CTRL Size 32 Offset 0x000 Bitfield VED:1:1 Bitfield HED:2:2 … Initialvalue 0x00000001 Accesstype RW Register PRG_VSYNC_OFF Size 32 Offset 0x004 …

AXIOME → REGISTER_DEF

REGISTER_DEF → Register"nom_registre " SIZE_DEF

SIZE_DEF → Size" taille " OFFSET_DEF

OFFSET_DEF → Offset" offset " BITFIELD_DEF

BITFIELD_DEF → BitfieldBITFIELD_TYPE

BITFIELD_TYPE → {" nom_champ " | - }:"bit_index" :"bit_index"

{BITFIELD_DEF * | INITVAL_DEF}

INITVAL_DEF → Initialvalue" valeur_reset " ACCESS_DEF

ACCESS_DEF → AccesstypeACCESS_TYPE

ACCESS_TYPE → { RO| RW} REGISTER_DEF *

HDPP

Exemple de définition des ressources Register CTRL Size 32 Offset 0x000 Bitfield VED:1:1 Bitfield HED:2:2 … Initialvalue 0x00000001 Accesstype RW Register PRG_VSYNC_OFF Size 32 Offset 0x004 …

III.B.2.b. Présentation des paramètres de modélisation d’un

composant et leurs relations avec la modélisation des services.

En plus de la définition des registres d’un composant, il est nécessaire d’en modéliser

les principales caractéristiques. Cette modélisation est réalisée par l’intermédiaire de

paramètres qui abstraient le fonctionnement. Ces paramètres peuvent être divisés en deux

ensembles :

• Les paramètres spécifiques au système ;

• Les paramètres spécifiques au composant.

Les paramètres relatifs au système permettent de définir si le composant possède une

zone mémoire qui lui est allouée. Ces paramètres sont nécessaires pour vérifier la cohérence

du plan mémoire spécifié pour le système. Ils sont génériques pour tous les composants. Il

existe deux paramètres de ce type, le premier est noté « memory_map ». Il permet ainsi de

spécifier l’espace mémoire accessible au composant. Un second paramètre est attaché à cette

description, il est noté « memory_map_service ». Il permet de spécifier le ou les services qui

mettent en œuvre les accès mémoires.

Les paramètres relatifs aux composants sont de deux types :

• Les paramètres d’entrés/sorties réalisent l’abstraction du type de données que

manipule le composant ;

• Les paramètres de configuration définissent le mode de fonctionnement du

composant.

Comme cela a été évoqué lors de la description des services, les services et les

paramètres sont liés. Les paramètres spécifiés pour un composant sont ainsi hérités par les

services. Au moment de la spécification des paramètres du composant, il n’est pas nécessaire

de définir les valeurs respectives de chaque paramètre. Aussi, certaines valeurs de ces

paramètres sont différentes voire non définies d’un service à l’autre. La seule contrainte de

modélisation fixée ici est que tous les paramètres du composant soient définis pour les feuilles

de l’arbre de service.

Ces deux types de paramètres permettent pour un service donné de définir le mode de

fonctionnement du composant. Les paramètres de configuration sont ensuite utilisés dans les

programmes de test de haut niveau. Ils constituent un ensemble des paramètres, utilisé lors de

l’appel des fonctions de l’API de vérification. Ils permettent au travers de l’API la

configuration, la gestion et le contrôle du composant pendant le test.

Si l’on considère maintenant le composant HDPP utilisé pour l’illustration du concept

de services, la Figure 27 présente un exemple de la modélisation de celui-ci par les paramètres

et leurs relations avec la modélisation des services offerts. On notera que ce composant ne

dispose pas d’un accès mémoire, d’où l’absence de paramètres spécifiques au système.

Figure 27 : Exemple de modélisation pour le composant HDPP des paramètres

d’abstraction des entrées/sorties et de la configuration

Comme cela apparaît sur la Figure 27, les paramètres « IT_* » spécifient quelles

interruptions du composant sont activées lors du test. Les autres paramètres constituent la

définition du flux vidéo d’entrée et sont utilisés pour définir la configuration du composant.

III.B.3. Présentation de la structure du modèle d’un système