Informations communes à plusieurs types de blocs

2.3.3.1 Interface maître et esclave

Chaque bloc doit préciser ses interfaces de communications, entrantes ou sortantes.

À l’exception des blocs initiaux, un bloc possède au moins une interface entrante (esclave) utilisée pour la réception du flux de données issues du bloc précédent et généralement une interface sortante (maître), hormis pour les terminaux, pour la propagation des résultats du traitement du bloc.

La balise bloc_interfaces contient la liste de toutes les interfaces du bloc. Chaque balise interfaces doit fournir les informations suivantes :

– dir : les arguments in ou out donnent la direction de l’interface.

– type : video ou complex (interface contenant un bus pour la partie réelle, un pour la partie imaginaire), pour préciser le type de l’interface et donc, par extension, le jeu de signaux/bus de celle-ci.

Par exemple pour un filtre en niveau de gris recevant un pixel et produisant un résultat du même type : <?xml v e r s i o n ="1.0" e n c o d i n g="u t f −8"?> <i m p l e m e n t a t i o n _ b l o c name="t h r e s h o l d _ i m p l 1 " > . . . <b l o c _ i n t e r f a c e s > < i n t e r f a c e s d i r =" i n " ty p e="v i d e o"> < i n t e r f a c e name=" i f _ i n " /> </ i n t e r f a c e s >

< i n t e r f a c e s d i r ="out " t yp e="v i d e o"> < i n t e r f a c e name="i f _ o u t " /> </ i n t e r f a c e s >

</ b l o c _ i n t e r f a c e s > . . .

</implementation_bloc >

Certains traitements ou algorithmes ne sont, par nature, pas typé et par extension ne fournissent pas d’attribut type pour leurs interfaces d’entrée et de sortie. La décimation, par exemple, peut être aussi bien appliquée sur un flux de réels issus d’un convertisseur analogique-numérique que sur un flux de complexes. Dans le cas où le bloc de haut-niveau ne fournit pas cette information, ce sont les implémentations qui doivent le faire. Ce mécanisme permet de présenter à l’utilisateur, non pas un ensemble de versions du même algorithme, mais un seul bloc. La sélection de l’implémentation présentant l’interface adéquate vis-à-vis du bloc précédent incombe à CoGen.

D’autres attributs optionnels peuvent également apparaître dans ce nœud :

– chan : permet, dans le cas d’un flux vidéo couleur, de guider CoGen pour la connexion automatique des interfaces. Cet attribut peut prendre les valeurs RED, GREEN ou BLUE. Exemple pour un filtre couleur recevant et sortant un pixel :

<b l o c _ i n t e r f a c e s > < i n t e r f a c e s d i r =" i n " ty p e="v i d e o"> < i n t e r f a c e name="i f _ r _ i n " chan="RED" /> < i n t e r f a c e name="if_g_in " chan="GREEN" /> < i n t e r f a c e name="if_b_in " chan="BLUE" /> </ i n t e r f a c e s >

< i n t e r f a c e s d i r ="out " t yp e="v i d e o">

<i n t e r f a c e _ n a m e="if_r_out " chan="RED" /> <i n t e r f a c e _ n a m e="if_g_out " chan="GREEEN" /> <i n t e r f a c e _ n a m e="if_b_out " chan="BLUE" /> </ i n t e r f a c e s >

</ b l o c _ i n t e r f a c e s >

Dans le cas où une balise interfaces contient plusieurs balises interface mais que celles-ci ne contiennent pas d’attributs chan, elles sont considérées comme recevant des données consécutives. Voici un exemple pour un bloc initial (pas d’entrée) de type vidéo fournissant deux pixels consécutifs :

< i n i t i a l _ b l o c name="c a m e r a l i n k"> . . . <b l o c _ i n t e r f a c e s > < i n t e r f a c e s d i r =" i n " ty p e="v i d e o"> < i n t e r f a c e name=" i f 1 _ i n " /> < i n t e r f a c e name=" i f 2 _ i n " /> </ i n t e r f a c e s > </ b l o c _ i n t e r f a c e s > . . . </ i n i t i a l _ b l o c >

Si, pour un même bloc, plusieurs balises interfaces sont définies avec la même direction (attributs dir identiques) les données sont considérées comme étant parallèles.

Par exemple, pour un filtre en niveaux de gris recevant deux pixels issus de deux traitements parallèles : <?xml v e r s i o n ="1.0" e n c o d i n g="u t f −8"?> <i m p l e m e n t a t i o n _ b l o c name="canny_impl1"> . . . <b l o c _ i n t e r f a c e s > < i n t e r f a c e s d i r =" i n " ty p e="v i d e o"> < i n t e r f a c e name=" i f 1 _ i n " /> </ i n t e r f a c e s > < i n t e r f a c e s d i r =" i n " ty p e="v i d e o"> < i n t e r f a c e name=" i f 2 _ i n " /> </ i n t e r f a c e s >

< i n t e r f a c e s d i r ="out " t yp e="v i d e o"> < i n t e r f a c e name="i f _ o u t " /> </ i n t e r f a c e s >

</ b l o c _ i n t e r f a c e s > . . .

</implementation_bloc >

Le fait qu’un bloc dispose de plusieurs interfaces entrantes ayant la même direction pour rece- voir plusieurs données en parallèle est une caractéristique de l’algorithme. Le Laplacien DOG de Marr-Hildreth (1980), qui est un filtre de détection de contours, prend en entrée le résultat de deux lissages gaussiens de tailles différentes appliqués sur la même image et réalise la différence. Il est ainsi logique que cette information soit portée par le fichier de description du bloc de traitement. Par contre, le fait qu’un bloc reçoive ou produise des données consécutives en parallèle est un cas particulier. Généralement ce type de situation se rencontre pour un bloc initial lié à un périphérique d’acquisition qui présente cette caractéristique (telle que la caméra présentée en section 4.2 et le convertisseur analogique-numérique décrit en section 5.1) et pour des implémentations liées aux mêmes périphériques ou permettant de pouvoir traiter un flux important à une fréquence d’horloge faible. C’est pourquoi, dans le cas des algorithmes, seules les implémentations peuvent spécifier des interfaces pour des données consécutives en parallèle.

Une balise interfaces dispose également d’un attribut target exclusivement utilisé pour les blocs d’implémentation. Cet attribut permet à CoGen de faire le lien entre chaque interface de l’implémentation et celles du bloc de haut-niveau.

2.3.3.2 Informations relatives aux caractéristiques temporelles d’un bloc

Les blocs initiaux, terminaux et les implémentations doivent fournir une balise timings. Elle contient des éléments de type timing qui spécifient

– dir : in ou out

– freq : notée en MHz pour l’acceptance ou la fréquence de production de données (exclusive- ment utilisé pour les blocs initiaux et terminaux) ;

– pattern : qui donne la représentation sous la forme d’un motif de l’acceptance ou de la sortance du bloc. Dans le cas des blocs initiaux, cette information est définie par rapport à la fréquence propre du périphérique.

Des attributs optionnels sont également disponibles :

– latency : uniquement disponible pour les balises timing en mode out. Il représente le nombre de cycles d’horloge entre l’arrivée d’une donnée et la sortie de la donnée correspondante. Cette information n’est pas disponible pour les blocs initiaux ;

– delay : est utilisé pour les blocs tels que les convolutions qui présentent un retard, qui n’est pas lié au temps du traitement, entre l’arrivée d’une donnée et la production du résultat correspondant (problématique présentée dans les sections 1.6.1 et 2.2.2)

La balise timings contient au plus un élément dont la direction est in et un élément dont la direction est out :

<t i m i n g s >

<t i m i n g d i r ="" p a t t e r n ="" [ f r e q =""] /> </t i m i n g s >

Une implémentation doit avoir une balise timing par direction, chacune d’elle est décrite par un motif. Un bloc initial ne posséde qu’une seule balise au format out, et un bloc terminal, une seule au format in.

La balise timings, ainsi que la sous-balise timing et l’ensemble des attributs ne sont pas modifiables par l’utilisateur.

Exemple pour une caméra ayant un débit de pixels de 80 MHz et 8 cycles de temps de pause à la fin de chaque ligne :

<?xml v e r s i o n ="1.0" e n c o d i n g="u t f −8"?> < i n i t i a l _ b l o c name="c a m e r a l i n k " >

. . . <t i m i n g s >

<t i m i n g d i r ="out " f r e q ="80" p a t t e r n ="[1(IMG_WIDTH) 0 ( 8 ) ] ( IMG_HEIGHT) " /> </t i m i n g s >

</ i n i t i a l _ b l o c >

Exemple pour un composant acceptant toujours des informations, ne produisant qu’une donnée sur deux et dont la latence est de 1 cycle d’horloge :

<?xml v e r s i o n ="1.0" e n c o d i n g="u t f −8"?> <i m p l e m e n t a t i o n _ b l o c name=" t h r e s h o l d " > . . . <t i m i n g s > <t i m i n g d i r ="i n " p a t t e r n ="1∗" /> <t i m i n g d i r ="out " l a t e n c y ="1" p a t t e r n = " [ 0 1 ] (IMG_WIGTH∗IMG_HEIGHT) " /> </t i m i n g s > . . . </implementation_bloc >

2.3.3.3 Utilisation des ressources

Les blocs initiaux, terminaux et les implémentations doivent fournir le type et le volume de ressources matérielles qu’ils utilisent.

Les balises resource incluses dans la balise resources possèdent deux attributs : – type : pour le type de ressource utilisé ;

– amount : pour le nombre de ressources du type type concerné. Exemple pour le bloc cameralink :

<?xml v e r s i o n ="1.0" e n c o d i n g="u t f −8"?> < i n i t i a l _ b l o c name="c a m e r a l i n k " > . . . <r e s o u r c e s > <r e s o u r c e t y pe=" s e r d e s " amount="8" /> <r e s o u r c e t y pe="PLL_ADV" amount="1" /> </ r e s o u r c e s > . . . </ i n i t i a l _ b l o c >