Choix du modèle d’architecture reconfigurable
2. Estimation des temps et des ressources à destination du partitionnement
Le modèle général d’architecture étant établi, il est nécessaire de déterminer les modèles d’estimation des temps de fonctionnement de l’architecture et des ressources matérielles requises de l’UCR pour exécuter les tâches de l’application. Ces valeurs sont utilisées par le partitionnement.
CPU UCR
M ém oire & Registres de
Contrôle
Routage Ports E/SUCR Contrôle des reconfiguration Contexte actif A ppel logiciel G estion des contextes Configuration H W Routage E/S Code objet SW routing
Contexte Contexterouting routing
Contexte D M A
IC U R E
Partie 2. Méthodologie de partitionnement logiciel/matériel 85
On distingue les temps de reconfiguration, de communication, d’exécution et les nombres de CL et de CD de l’UCR suivant la performance visée.
2. 1. Estimation des temps de reconfiguration de l’UCR
Il est important de tenir compte des temps de reconfiguration de l’UCR dans la phase de partitionnement puisque ces temps peuvent être très importants selon les composants ciblés.
Les constructeurs donnent généralement le temps de reconfiguration total du composant reconfigurable et parfois un temps de reconfiguration par cellule logique dans le cas d’une architecture reconfigurable partiellement. Si ce temps de reconfiguration par CL n’est pas disponible, il peut être estimé de plusieures manières dont celle utilisée dans notre approche. Nous partons de l’hypothèse que le temps de reconfiguration de l’UCR dépend linéairement du nombre Nk de cellules logiques CL utilisées pour réaliser le contexte k sur l’UCR. Soit TF le temps que prend une reconfiguration totale, et Smax(CL) la taille maximale de l’UCR en terme de Cellules Logiques, alors le temps de reconfiguration par CL peut être estimé à :
On évalue le temps de reconfiguration du contexte k par :
B itstre a m (b in a ire )
R ésu lta t d e la syn th èse d u cod e S yste m C o u V H D L d u con te xte . C on fig u ra tio n e n u n e fois (loa d _ c on te xt()).
R o u ta ge x m a p (b in a ire )
C onfig ura tio n du cro ssb a r xm a p p ou r le contexte .
D e sc rip teu rs d e c o n te x te (c o d e o b je t)
P a rtie visib le p ou r le log icie l.
P ossib le im p lé m e nta tion log icie lle d e s fonctions. C O N T E XT E
FIGURE 2.16. Anatomie d’un contexte
Treconf CL⁄
TF
Smax CL( )
---
= (EQ 2.1)
86 Partie 2. Méthodologie de partitionnement logiciel/matériel Choix du modèle d’architecture reconfigurable et de son schéma d’exécution
2. 2. Estimation des temps de communication
Le modèle de communication que nous avons établi essaye de tenir compte de la spécificité de l’architecture ciblée sans que sa prise en compte n’entraîne un accroissement trop important de la complexité de la méthode de partitionnement.
Dans notre modèle de communication, les transferts de données entre les deux unités s'effectuent au travers de la mémoire double-ports située dans l'interface ICURE connectée au processeur par son bus de données (busCPU-
ICURE) et au reconfigurable par un bus spécifique (busICURE-UCR). Ces trans-
ferts sont de type asynchrone, c’est à dire que les données sont d’abord écri- tes dans la mémoire d’ICURE puis lues depuis cette mémoire (ce qui nécessite une ressource mémoire assez importante).
On fait aussi l'hypothèse que les communications sur le busCPU-ICURE sont bloquantes pour les traitements sur le CPU, c’est à dire qu’il n’y a pas de recouvrement entre traitement et communication sur le CPU. Par contre, cel- les sur le busICURE-UCR ne le sont pas pour les traitements sur l’UCR, c’est à dire que les traitements effectués sur une partie d’un contexte peuvent se faire en parallèle avec la communication effectuée par une autre partie du con- texte. Détaillons maintenant le modèle de communication considéré.
Les caractéristiques prises en compte dans notre modèle sont les suivantes : - débit et largeur des bus de données.
- temps d’accès à la mémoire de l’interface ICURE.
Le modèle de communication choisi permet d’avoir un temps de transfert dépendant linéairement du nombre de données à échanger [40]. Des modèles de communication plus riches peuvent être trouvé dans [152].
Soit ρi le nombre d'octets communiqués sur l'arc ei d'un GFD et λl le nombre d'octets par paquet supporté par le bus l. Soient αl le temps de communica- tion d'un paquet sur le bus l et Ωl le temps d'accès par paquet sur ce bus. Le temps d’accès mémoire (en lecture ou écriture) est représenté par ΩMem et la largeur du banc mémoire par λMem. Le temps global pour communiquer les données représentées par l'arc ei d'une unité vers une mémoire (ou vis versa) est donné par :
Tcom( )ei ρi λl --- (αl+Ωl) ρi λMem --- ⋅ΩMem + ⋅ = (EQ 2.3)
Partie 2. Méthodologie de partitionnement logiciel/matériel 87
Dans le cas d'une tâche τj exécutée par le processeur (respectivement l’UCR) dont au moins un de ses prédécesseurs τi est exécuté par l’UCR (resp. le pro- cesseur), et puisque notre choix a été porté sur un type de communication asynchrone, les données produites par τi à destination de τj doivent être copiées de la mémoire d'ICURE (resp. du processeur) dans la mémoire du processeur (resp. d'ICURE).
Les temps de transfert associés à cette communication sont évalués à l'aide de l’équation (2.4) et l'arc ei entre ces deux tâches est libellé par :
On convient que le temps de communication entre deux tâches affectées au CPU est nul. Dans le cas où deux tâches dépendantes sont exécutées par l’UCR et appartiennent à un même contexte (i.e. il n'y a pas de reconfigura- tion) aucun temps de communication n'est comptabilisé. En effet, ces temps sont du même ordre de grandeur que ceux relatifs aux transferts de données entre les entités logiques du circuit, synthétisées à partir de la description comportementale de la procédure.
Si les deux tâches τi et τj sont exécutées par le reconfigurable mais situées dans deux contextes différents, des temps de communication entre le reconfi- gurable et la mémoire d'ICURE sont considérés. En effet, les données calcu- lées par la tâche productrice τi sur le reconfigurable doivent être sauvegardées dans la mémoire d'ICURE avant que la reconfiguration du con- texte contenant la tâche consommatrice τj ne soit activée (ici, on considère le cas pire parce qu'il existe des architectures, notamment la famille Virtex de Xilinx, qui permettent de stocker les données intermédiaires dans des cellules dédiées de type block RAM tout en reconfigurant une autre partie du FPGA). Ensuite, les données sont transférées de la mémoire d'ICURE vers la tâche τj lorsque la reconfiguration est terminée.
Dans un premier temps, et étant donné que les contextes ne sont pas encore construits, nous libellons l'arc e'i entre les deux tâches affectées à l’UCR τi et
τj avec un temps de communication relatif au cas pire, c’est à dire égal à la somme d'un temps de transit sur le busICURE-UCR, d'un temps d'accès en écri-
Tcom( )ei ρi
λCPU–ICURE
--- (αCPU–IC URE+ΩCPU–ICURE)
ρi λIC URE–U C R --- (αIC URE–U CR+ΩIC URE–U C R) 2 ρi λMem --- ΩMem ⋅ ⋅ + ⋅ + ⋅ = (EQ 2.4)
88 Partie 2. Méthodologie de partitionnement logiciel/matériel Choix du modèle d’architecture reconfigurable et de son schéma d’exécution
ture à la mémoire d'ICURE, d'un temps d'accès en lecture et d'un temps de transit sur le busICURE-UCR que l'on simplifie par :