Technique proposée pour le calcul des propriétés non fonctionnelles

Le principe considéré ici consiste en une abstraction des propriétés non fonctionnelles via un accroissement du niveau de granularité au sein de modèles de niveau transactionnel. Il s‟apparente au principe d‟abstraction fait entre le niveau „cycle accurate‟, qui donne une description précise des opérations de transport effectuées à chaque cycle d‟horloge, et le niveau „Approximately-timed‟ où des durées sont associées aux opérations de transport des données. Ce principe d‟abstraction est ici appliqué sur les propriétés non fonctionnelles en vue de l‟évaluation des performances du système. En utilisant des langages comme SystemC, il est avéré que le temps de simulation d‟un modèle dépend du nombre de changements de contexte effectués pendant son exécution [97]. Un changement de contexte intervient dès lors qu‟une transaction entre deux modules SystemC est effectuée. Il s‟agit donc de limiter au maximum le nombre de transactions initiées pour pouvoir réduire les temps de simulation de nos modèles. La figure 3.4 permet d‟illustrer la méthode que nous proposons d‟utiliser.

Figure 3.4 – Principe de la méthode de calcul des propriétés non fonctionnelles.

La figure 3.4 présente deux activités désignées A1 et A2. A1 est une activité émettrice et

A2 est une activité réceptrice. Sur la partie haute de la figure, l‟activité A2 est en attente de

quatre transactions M pour pouvoir passer de l‟état S0 à l‟état S1. Δt1, Δt2 et Δt3 sont ici

représentatifs des délais qui sont induits par le nœud de communication utilisé pour transférer les données. En définissant M à un niveau de granularité plus élevé, il est possible de remplacer ces quatre transactions par une seule transaction. De manière à conserver un comportement temporel équivalent pour l‟activité A2, un état S0‟ est rajouté. Le temps de

transfert associé à la réception des données est alors calculé lors de la réception de la transaction M. Ce calcul nécessite que les délais Δt1, Δt2 et Δt3 soient ajoutés dans le contenu

de la transaction M. L‟instant de réception est alors utilisé comme instant de référence et les délais Δt1, Δt2 et Δt3 lui sont ajoutés pour calculer l‟instant de fin de réception. L‟état S0‟ est

alors introduit afin de prendre en compte le temps de transfert estimé des données.

A1 A2 s0 s1 M /k:=k+1; k=4 /k:=1; M 4 transactions A1 A2 s0 s0' M M 1 transaction

Approche de modélisation au niveau transactionnel Approche de modélisation basée sur les états

s1 /Tnext:=ComputeAfterM(); t = Tnext MCA2 = mcs0; CCA2 = ccs1; MCA2 = mcs0; CCA2 = ccs1; Δt1 Δt2 Δt3 MCA2 = mcs0';

Chapitre 3 Contributions pour la prise en compte des propriétés non fonctionnelles au sein de modèles de niveau transactionnel

40

Une expérimentation a été faite pour justifier du gain en termes de temps de simulation pouvant être obtenu en réduisant le nombre de transactions initiées lors de l‟exécution d‟un modèle. La figure 3.5 présente le diagramme d‟activités du modèle proposé pour réaliser cette expérimentation.

Figure 3.5 – Modèle pour l‟évaluation du gain de temps de simulation en fonction du facteur de réduction du nombre de changements de contexte.

Chaque activité décrite ici représente un module SystemC. L‟activité AProd est définie de

manière à assurer la production d‟une transaction MIn toutes les 100 ns. Le comportement

décrit pour les activités A1 à AN permet ensuite d‟assurer la retransmission des transactions

reçues en entrée sur la sortie. Aucun traitement n‟est ici considéré entre la réception et la production d‟une transaction. L‟activité ACons vient elle consommer les transactions MOut en

sortie.

L‟outil CoFluent Studio a été utilisé dans le cadre de cette expérimentation pour capturer et simuler ce modèle. Il offre en effet la possibilité de capturer graphiquement des modèles de niveau transactionnel. Il génère ensuite automatiquement une description en SystemC du modèle qui peut alors être simulée pour analyser son comportement et les performances obtenues. Pour cette expérimentation, nous avons fixé un temps simulé de 11 ms. L‟activité AProd génére alors 110000 transactions MIn durant la simulation du modèle. Nous avons

simulé notre modèle une première fois en considérant une seule activité entre AProd et ACons.

Nous avons alors observé le temps nécessaire à la simulation du modèle. Une activité intermédiaire entre AProd et ACons a ensuite été successivement ajoutée et nous avons mesuré

les temps de simulation requis. Le but était d‟évaluer l‟influence du nombre de changements de contexte sur le temps de simulation du modèle. La figure 3.6 montre les résultats concernant les gains en temps de simulation observés.

Figure 3.6 – Gain de temps de simulation en fonction du facteur de réduction du nombre de changements de contexte.

AProd A1 ACons

Nombre d’activités modélisées : 1 à N

s0 MIn t = TProd s0 s1 MIn M2 A2 _s 0 s1 M2 M3 AN _s 0 s1 MN MOut MIn _M2 MOut s0 MOut 1 1 1 2,37 3,33 4,39 5,58 1,93 6,41 7,37 8,39 9,55 10,57 Facteur de réduction du temps de simulation 2 4 6 8 10 12 2 4 6 8 10 12 Facteur de réduction du nombre de changements de contexte

Chapitre 3 Contributions pour la prise en compte des propriétés non fonctionnelles au sein de modèles de niveau transactionnel

41 L‟axe des abscisses représente le rapport de commutations économisées entre un modèle avec N activités et un modèle avec une activité entre AProd et ACons. Pour une activité, deux

changements de contexte sont effectués pour une transaction initiée par AProd. Pour un

modèle avec N activités, N+1 changements de contexte sont nécessaires. Le facteur de réduction du nombre de changement de contexte se calcul alors avec l‟expression (N+1)/2, avec N le nombre d‟activités considérées entre AProd et ACons. L‟évaluation a porté

successivement sur la prise en compte de 3, 4, 6, 8, 10, 12, 14, 16, 18 et 20 activités entre AProd et ACons. L‟axe des ordonnées représente lui le facteur de réduction de temps de

simulation en fonction du facteur de réduction du nombre de changements de contexte. Nous vérifions ainsi à travers cette expérimentation que le facteur de réduction du temps de simulation est quasiment proportionnel au facteur de réduction du nombre de changements de contexte au sein d‟un modèle. Cette observation confirme l‟intérêt de diminuer le nombre de transactions nécessaires à l‟évolution du comportement d‟un modèle lors de son exécution afin de limiter le temps de simulation requis. Il s‟agira par la suite d‟évaluer l‟influence des algorithmes pouvant être ajoutés au sein des modules SystemC sur le temps de simulation.

Sur la partie haute de la figure 3.4, la propriété non fonctionnelle MCA2 considérée

évolue dès lors qu‟une transaction M est reçue en entrée. Cette propriété permet en effet d‟observer l‟évolution du coût mémoire induit par le stockage des informations contenues dans M. Une méthode spécifique est alors requise pour pouvoir observer l‟évolution de cette propriété non fonctionnelle avec le niveau de granularité des transactions considéré sur la partie basse de la figure 3.4. Nous présentons dans la partie suivante la proposition d‟un modèle générique permettant de décrire à la fois le comportement d‟une activité et l‟évolution des propriétés non fonctionnelles associées. Ce modèle générique est défini de manière à bien séparer la description qui est faite de l‟évolution temporelle de l‟activité liée aux instants de consommation et de production des transactions, et l‟évolution temporelle des propriétés observées. Nous qualifions cette approche de modélisation de state based en ce sens qu‟elle exprime les caractéristiques de l‟architecture à partir d‟états significatifs. Elle se différencie d‟une approche event based qui elle exhibe l‟ensemble des transactions nécessaires à l‟évolution du système. Dans la partie suivante, nous proposons donc de modéliser une activité en se basant sur cette approche orientée state based de manière à pouvoir représenter d‟une part la partie consommation et production de transactions et d‟autre part l‟évolution des propriétés non fonctionnelles analysées.