REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA

RECHERCHE SCIENTIFIQUE

Université Larbi Ben M’hidi d’Oum El Bouaghi

Faculté des sciences exactes et des sciences de la nature et de la vie
Département de mathématiques et Informatique

MÉMOIRE
Pour l’obtention du diplôme de Master en Informatique
OPTION : SYSTÈMES DISTRIBUÉS

Génération automatique de Diagrammes

SysML à partir du code VHDL

Présenté par : Fartas Okba

Encadré par : Dr. Boutekkouk Fateh

2013/2014
 Dédicaces
La louange est à Allah Le Clément et Le Miséricordieux et

que la prière et le salut de mon Seigneur soient sur son

Prophète et son Serviteur Mohammed ( ).

A mes très chers parents, faible témoignage de ma

reconnaissance pour leurs inestimables efforts consentis

dans l’unique souci de ma réussite et de mon bien être ;

A mon oncle, sa femme et tous ses enfants ;

A mes frères, ma sœur, et tous les membres de la famille

FARTAS ;

A tous mes amis et à toutes personnes ayant contribué de

près ou de loin à la réalisation de ce mémoire ;

f.okba

II
 Remerciements
Au terme de ce modeste travail, je tiens à exprimer ma

gratitude et présenter mes vifs remerciements à tous ceux

qui ont participé de près ou de loin à sa réalisation.

Je rends un hommage particulier :

AU mon encadreur Dr.BoutekkoukFatehpour son

dévouement total durant la réalisation de ce travail, et

surtout pour ses précieux conseils qu’il ma prodigué.

Je tiens également à exprimer toute ma grande gratitude

aux membres de jury D’avoir accepté de juger ce travail.

Je tiens à remercier tous mes collègues et amisboubeker,

HossemeEt mes amis les plus chersDjamel, Mahdi, Nacer,

ET MA MERE pour tout ce qu’elle a fait et ce qu’elle fait

encore pour moi.

3
 Résumé

Ces dernières années, le standard SysML a attirébeaucoup d’attentions auprès des

concepteurs du matériel. A l’instar d’UML, SysML a été déjà utilisé pour générer de
manière automatique un code de description matériel (HDL) écrit en System, Verilog
et VHDL. Contrairement à la plupart des travaux existants, nous proposons dans ce
mémoire une nouvelle approche de rétro ingénierie pour générer les diagrammes
SysML de définition du bloc et de bloc interne à partir du code VHDL. La génération
du code s’effectue en faisant référence à un ensemble de règles de correspondance
entre les concepts SysML et VHDL.
L’apport de notre travail est de faciliter la maintenance et la compréhension des
programmes VHDL auprès les concepteurs matériel et même logiciel et cela c’est
grâce aux modèles graphiques offerts par SysML.
Mots-clés : VHDL, SysML, rétro ingénierie, diagrammes de définition du bloc,
diagrammes de blocs internes.

Abstract
In the last years, the standard SysML is attracting more attention from hardware designers. As
UML, SysMLhas been used to automatically generate an HDL code written in SystemC,
Verilog and VHDL. Contrarily to most existing works, we propose in this dissertation, a new
reverse engineering approach to generate SysML definition bloc and internal bloc diagrams
from VHDL code. Code generation is done on the basis of a set of well defined corresponding
rules between SysML and VHDL concepts. The benefit of our work is to enable both
hardware and software designers to maintain and comprehend VHDL programs.
Key-words: VHDL, SysML, reverse engineering, bloc definition diagram, internal bloc
diagram

4
 Sommaire

Contenu
Résumé .................................................................................................................................................... 4
Sommaire ................................................................................................................................................. 5
Liste de figure .......................................................................................................................................... 8
Chapitre 01 : .......................................................................................................................................... 12
1.1 Introduction : ............................................................................................................................... 13
1.2 Définition de la rétro-ingénierie : ................................................................................................ 13
1.3 Le But de la rétro-ingénierie : ...................................................................................................... 13
1.4 Processus de rétro-ingénierie : .................................................................................................... 14
1.4.1 rétro-ingénierie d’un système : ............................................................................................ 14
1.4.2 Une démarche générale pour la rétro-ingénierie : ............................................................... 14
1.5 Conclusion :.................................................................................................................................. 17
Chapitre 02 : .......................................................................................................................................... 18
2.1 Introduction : ............................................................................................................................... 19
2.2 SysML : ......................................................................................................................................... 19
2.3 Les diagrammes de SysML : ......................................................................................................... 19
2.3.1 Diagramme de définition de bloc : ....................................................................................... 21
2.3.1.1 Bloc et propriété : .......................................................................................................... 21
2.3.1.2ValueType : ..................................................................................................................... 23
2.3.1.3 Composition : ................................................................................................................. 24
2.3.1.4 Agrégation :.................................................................................................................... 24
2.3.1.5 Association : ................................................................................................................... 25
2.3.1.6 Généralisation (héritage) : ............................................................................................. 25
2.3.1.7 Opération : ..................................................................................................................... 26
2.3.1.8 Exemple de Diagramme de définition de bloc :............................................................. 27
2.3.2 Diagramme de blocs internes : ............................................................................................. 27
2.3.2.1 Parties et connecteurs : ................................................................................................. 27
2.3.2.2 Connecteurs : ................................................................................................................. 28
2.3.2.3 Les Ports : ....................................................................................................................... 29
2.3.2.4 Exemple de diagramme de bloc interne : ...................................................................... 31
2.4 Conclusion :.................................................................................................................................. 31
Chapitre 03 : .......................................................................................................................................... 32

5
 3.1 Introduction : ............................................................................................................................... 33
3.2 Le langage VHDL : ........................................................................................................................ 33
3.2.1 Définition et historique : ....................................................................................................... 33
3.2.2 Pourquoi un langage de description ? .................................................................................. 33
3.3 Structure d’une description VHDL : ............................................................................................. 34
3.3.1 Les entités de conception et la configuration : .................................................................... 34
3.3.1.1 La déclaration d’entité : ................................................................................................. 35
3.3.1.2 Les architectures : .......................................................................................................... 36
3.3.1.3 Déclaration d’un composant ‘COMPONENT’ :............................................................... 37
3.3.1.4Déclaration de’ Blocs’ : ................................................................................................... 38
3.3.1.5 Les signaux : ................................................................................................................... 38
3.3.1.6 Les processus : ............................................................................................................... 39
3.3.1.7 Les variables : ................................................................................................................. 40
3.3.1.8 Les constantes :.............................................................................................................. 40
3.3.1.9 Les fichiers : ................................................................................................................... 40
3.3.2 Les sous-programmes : ......................................................................................................... 40
3.3.2.1 les procédures :.............................................................................................................. 40
3.3.2.2 Les fonctions : ................................................................................................................ 41
3.3.3 Les éléments d’archivage :.................................................................................................... 41
3.3.3.1 Les librairies : ................................................................................................................. 41
3.3.3.2 Les paquetages : ............................................................................................................ 41
3.4 Conclusion :.................................................................................................................................. 42
Chapitre 04 : .......................................................................................................................................... 43
4.1 Introduction : ............................................................................................................................... 44
4.2 Approche de rétro ingénierie pour la génération de diagrammes SysML à partir du code VHDL
........................................................................................................................................................... 44
4.3 Passage de code VHDl vers SYSML : ............................................................................................ 45
4.4 Implémentation : ......................................................................................................................... 45
4.4.1 Java éclipse ........................................................................................................................... 45
4.4.1.1Installation : .................................................................................................................... 46
4.4.2 Génération automatique de Diagrammes SysML à partir du code VHDL ............................ 46
4.4.2.1 Génération automatique de Diagrammes de définition de bloc et Diagramme de bloc
interne à partir du code VHDL : ............................................................................................... 47
4.4 Conclusion :.................................................................................................................................. 51
Conclusion générale............................................................................................................................... 52

6
Bibliographie .......................................................................................................................................... 54

7
 Liste de figure
Figure 1.1 : Une démarche pour la rétro-ingénierie………………………………......................15
Figur2.1 :UML2 et SysML……………………………….…………………………………………19

Figure 2.2 : les 9 types diagramme de SysML................................................................................ 21

Figure 2-3 le bloc radio-réveil…………………………………………………………….……….23

Figure 2-4 le bloc radio-réveil aves qqn propriétés typées...........................................................23

Figure 2-5 deuxième bdd du bloc voiture……………………………………………………...….24

Figure 2-6 La représentation graphique de la relation d’agrégation………………..….…...…25

Figure 2-7La représentation graphique de la relation d’association…………………...…....….25

Figure 2-8La représentation graphique de la relation de généralisions...............................… 26

Figure 2.9 : exemple de diagrammede définition de bloc……………………………….....……27

Figure 2.10 : Exemple d’ibd du bloc voiture.………………………………………..…...…...…28

Figure 2.11 exemple d’ibd.….............................................................................................................29

Figure 2.12 : exemple de ports...........................................................................................................29

Figure 2.13 représentation d’item flow…...……………………………………….......……..........30

Figure 2.14 exemple d’ibd…………….………………………………………………..………...…31

Figure 3.1 : la structure logique de VHDL………………………………………………………34

Figure 4.1 : Notre approche proposée……………………………………………………………44

Figure 4.2 : la fenêtre de java éclipse……………………………………………….......................46

Figure 4.3 : Interface de projet…………..…………………………………………………………47

Figure 4.4 affichage de code VHDL dans l’interface……………...........................................49

Figure 4.5 génération de diagramme de définition de bloc à partir l’exemple VHDL…..…..50

Figure 4.6 génération de diagramme de bloc interne à partir l’exemple VHDL……..…...…51

8
Introduction générale

9
Avec l’évolution de la technologie, le développement des systèmes des différentes disciplines
(aéronautique, automobile...) devient de plus en plus complexe. Ces derniers requièrent
plusieurs approches soit pour la conception ou soit pour le développement ce qui nécessite
une collaboration entre les développeurs et les concepteurs. En raison de l’émergence
continue de la complexité de ces systèmes, il est nécessaire de mettre en place un
environnement qui nous permet de modéliser les systèmes en éliminant les détails de bas
niveau et en se focalisant sur l’aspect général, structurel ou comportemental.
Dans le cycle de vie de développement des applications logicielles, l’étape de maintenance est
l’étape la plus critique, et elle consomme environ 90% de l’ensemble des ressources utilisées.
La tâche principale de la maintenance est de comprendre l’application en analysant sa
structure et l’organisation de ses composants afin de fixer lesproblèmes et/ou d’ajouter des
nouvelles caractéristiques [1]. Utiliser directement le code source pour comprendre une
application est une tâche difficile pour trois raisons principales :
1) les applications sont de plus en plus complexes et leur code source est dispersé sur
desmilliers voir des millions de lignes de code.
2) les anciennes applications(legacy code), sont souvent codées dans des langages
deprogrammations obsolètes peu connus actuellement par les mainteneurs.
3) la maintenance est souvent réalisée par des individus qui n’ont pas été impliqués dans le
codage del’application [2]. Ainsi, les mainteneurs ont besoin de disposer d’une représentation
abstraitepermettant de gérer la complexité des applications. D’autre part, il est important que
cette représentation soit décrite dans un langage standard connu par un très grand nombre de
mainteneurs.
De l’autre côté, SysML est un nouvel langage standardisé par l’OMG extension d’UML pour
modéliser les systèmes au sens large que c soit logiciel, matériel, mécanique, etc.
A l’instar d’UML, la rétro-ingénierie des modèles SysML a attiré beaucoup d’attentions ces
dernières années. Bien que les travaux de recherche autour de cet axe ont atteint un niveau de
maturité élevé surtout au niveau de la communauté logiciel, nous pouvons constater qu’il y ait
une insuffisance au sein des travaux de recherche visant à générer des diagrammes SysML à
partir du code de langages de description matériel (HDL pour Hardware Description
Langages) tels que VHDL, Verilog, SystemC, etc.
Dans ce travail, nous nous sommes intéressés à la rétro ingénierie de diagrammesSysML de
définition du bloc et de bloc interne à partir du code VHDL.
Le reste de ce mémoire est organisé comme suit :

10
Dans le premier chapitre nous présenterons quelques concepts de base sur la rétro-ingénierie,
et sa démarche générale. Le deuxième chapitre est consacré auSysML et en particulier les
diagrammes définition de bloc et les diagrammes de bloc interne.
Le troisième chapitre met la lumière sur le standard VHDL. Nous commencerons le chapitre
par l’étude des concepts de base de VHDL et ensuite nous présenterons la Structure d’une
description VHDL.
Dans le dernier chapitre nous détaillerons notre approche de génération de diagrammes
définition de bloc et les diagrammes de bloc interne à partir du code VHDL en établissant un
ensemble des règles de correspondance entre les concepts SysML et les concepts VHDL
ensuite nous allons présenter notre outil avec un exemple explicatif.
Le présent mémoire se termine par une conclusion générale qui résume ce que nous avons
réalisé dans notre contribution ainsi que les perspectives envisageables.

11
Chapitre 01 :

Rétro ingénierie

12
1.1 Introduction :
La rétro-ingénierie en informatique est un sous-domaine de la rétro-ingénierie
appliquée aux systèmes, logiciels ou appareils informatiques. Elle a pour but d'analyser un
système pour en créer une représentation à un plus haut niveau d'abstraction. Les objectifs de
la rétro-ingénierie sont multiples [3], certains pouvant être autorisés voire nécessaires, et
d'autres plus malveillants sont combattus de différentes méthodes.
1.2 Définition de la rétro-ingénierie :
La rétro-ingénierie informatique regroupe l'ensemble des techniques et des outils liés à
la compréhension d'un système logiciel et/ou matériel existant, sans le bénéfice des
spécifications originales. Réalisée généralement en deux phases, elle consiste en
l'identification des composants du système et de leurs relations, puis leurs représentations à un
niveau d'abstraction plus élevé et plus compréhensible par les humains (spécifications,
documentations, plans, schémas). La rétro-ingénierie est un défi technique pour plusieurs
raisons :
• l'intention du programmeur n'est pas claire ;
• le problème initial peut ne pas être résolu correctement ;
• le code a été altéré pour répondre à des besoins de maintenance ;
• le logiciel est un portage d'un environnement différent ;
• la plateforme matérielle a changé ou évolué ;
• la sémantique du langage a changée.
1.3 Le But de la rétro-ingénierie :
La rétro-ingénierie a deux objectifs principaux : la re-documentation et la récupération du
modèle de conception. La re-documentation a pour but de produire une vue alternative d'un
modèle, au même niveau d'abstraction. La récupération du modèle de conception vise à
recréer les modèles d'abstraction à partir du code source, de la documentation existante, de la
connaissance des experts ainsi que toutes autres sources d'informations. Le but de la rétro-
ingénierie d'un logiciel est d'en améliorer sa compréhension globale, autant pour sa
maintenance que pour son développement futur. Son analyse sera menée selon les axes
suivants :
• faire face à la complexité :création de méthodes et outils, combinés aux
environnements CASE, afin de fournir un moyen d'extraire des informations
pertinentes[3] ;

13
 • générer des vues alternatives : les représentations graphiques sont considérées comme
des aides à la compréhension ;
• récupérer l'information perdue : l'évolution d'un système de taille conséquente
entraîne la perte d'information, les modifications ne sont généralement pas
documentées ;
• détecter les effets de bord : la conception initiale ou les modifications successives
peuvent entraîner des effets de bords involontaires ;
• créer des abstractions : la discipline nécessite des méthodes et outils afin de créer des
abstractions à un niveau plus haut [4] ;
• faciliter la ré-utilisation : la rétro-ingénierie peut aider à trouver des logiciels
potentiellement réutilisables.

1.4 Processus de rétro-ingénierie :

1.4.1 rétro-ingénierie d’un système :
C’est un processus complexe qui permet par l’étude d’un systèmeexistant de décrire
son fonctionnement et sa structure à travers un modèle.
Il s’agit alors de pouvoir par exemple :
• Comprendre le fonctionnement externe et interne du système ;
• Connaître les relations du système avec son environnement ;
• Connaître la mission et la finalité du système ;
• Identifier les solutions retenues ;
• Evaluer son bon fonctionnement ;
• Le modifier ;
• Le maintenir ;

1.4.2 Une démarche générale pour la rétro-ingénierie :

C’est une démarche non linéaire mais itérative et les étapes sont définies comme suit :

14
 Figure
igure 1.1 : Une démarche pour la rétro-ingénierie.

Décrire le contexte :
Décrire le contexte pour la phase de vie où le système est exploité (utilisation).Le
contexte permet d’expliciter l’environnement dans lequel évolue le système, il identifie les
éléments en interaction avec le système : les acteurs humains et d’autres
autres éléments (autres
systèmes de l’environnement)
nement) [5].

Définir la mission :
La mission principale du système est l’ensemble des services rendus par le système, si
on connait l’origine
ne du système on précise la finalité recherchée et le problème auquel
répond le système étudié.

Définir les cas d’utilisation :
Dans le contexte défini, pour chaque phase de vie, on définit les services rendus par le
système. En général, la mission princip
principale
ale du système se retrouve souvent dans le cas
d’utilisation principal de la phase exploitation.

15
 L’architecture physique d’un système représente sa structurematérielle : composition et
organisation.
Deux catégories d’éléments possibles :
• Les composants : entités élémentaires, que le modélisateurconsidère comme une entité
non décomposable ;
• Les sous-systèmes : éléments décomposables, pouvant êtrecomposés d’autres sous-
systèmes et/ou de composants.
Cette activité est formée de trois sous-activités permettant :
• de définir l’organisation des éléments en décrivant les flux échangés.
• de définir la structure hiérarchique : vision hiérarchisée des composants regroupés au
sein d’entités fonctionnelles (sous-systèmes).
• de définir l’architecture logique.

Décrire la structure interne :
Utiliser pour Représenter l’architecture interne du système étudié et Représenter les
flux échangés par les éléments [5].

Décrire la structure hiérarchique :
Utiliser pour Représenter la structure d’un système, composé d’éléments de manière
hiérarchique. (Chaque élément peut être décomposé jusqu’à obtenir uniquement des
composants).

Décrire les interactions du système :
Décrire les interactions du système avec son environ.

Décrire les états du système :
Identifier les états du système et identifier les conditions de passage entre les états
suivant les scénarios opérationnels (modes de marche,…)

Décrire les échanges avec les sous-systèmes :
Décrire les interactions entre les différents sous-systèmes entre eux et avec
l’environnement.

Décrire les états des sous-systèmes :
Activité réalisée en parallèle de l’étude des interactions entre sous-systèmes. Utiliser
pour Décrire des états des sous-systèmes/composantsvus comme un système indépendant.
(États et des conditions d’évolution associées).

Décrire l’architecture logique :

16
 Les activités précédentes ont permis la mise en évidence des opérations et signaux
reçus du système et de ses éléments, ainsi que l’architecture du système. Utiliser pour
allouer les opérations et signaux reçus aux différents éléments de l’architecture.

Définir les exigences système :
Utiliser pour Définir les exigences satisfaites par le système.

Associer les exigences système :
Etape qui consiste à montrer comment les exigences sont satisfaites par les opérations,
systèmes, sous-systèmes et autres composants (Allocation et vérification).
Pour chaque activité de rétro ingénierie, on peut indiquer les sources d'information : plaquette
commerciale produit, documents techniques à disposition, photos, le système que l’on peut
démonterpour l’analyse etc. [5].

1.5 Conclusion :
L’activité de la rétro-ingénierie est très importante car elle permet de comprendre
unsystème existant en produisant des artefacts d’un niveau d’abstraction supérieur au
code.Dans ce chapitre nous avons présenté les apports de la rétro-ingénierie et nous avons
étudiéses étapes principales.

17
Chapitre 02 :

SysML
(System ModelingLanguage)

18
2.1 Introduction :
SysML est le nouveau langage de modélisation spécifié par l’OMG, a fini par se
mettre d’accord la fin des années 90 sur un formalisme de modélisation unifiée : UML, Il
s’agit d’un langage de modélisation graphique dont la séma
sémantique semi-formelle
formelle est définie
dans OMG. Les concepteurs de SysML ont travaillé d’une part, à limiter ou adapter les
concepts trop proches de l’ingénierie logicielle, et d’autre part à simplifier la notation UML
originale en réduisant notamment le nombre de types de diagramme disponible, afin d’en
simplifier l’utilisation.

2.2 SysML :
SysML
L est défini comme un langage de modélisation pour l’ingénierie système
capable d’offrir un support pour la modélisation de multiples processus et méthodes.
Néanmoins, comme explicité chaque méthodologie peut imposer des contraintes
additionnelles sur la manière
anière dont un élément de construction ou un type de diagramme donné
peut être utilisé.
L’OMG veut promouvoir SysML comme un nouveau langage différent d’UML, tout en
profitant de sa filiation directe [6].

Figur2.1 :UML2 et SysML

Les concepteurs de SysML ont travaillé d’une part, à limiter ou adapter les concepts
trop proches de l’ingénierie logicielle, et d’autre part à simplifier la notation UML originale
en réduisant notamment le nombre de types de diagramme disponible.

2.3 Les diagrammes de SysML :

Le SysML est compos
composé de diagrammes qui permettent d’aborder
aborder plus facilement les
systèmes techniques, que ce soit en phase de conception ou en phase dd’analyse
analyse d’un
d existant.
Il peut également décrire
crire le cheminement de la mati
matière, de l’énergie
nergie et de l’information,
l’

19
sesdiagrammes offrant la possibilité de représenter à la fois les composantes les flux de toute
nature.Les diagrammes SysML, le plus souvent, sont liés entre eux (interconnectés) et ont leur
descriptionpropre. Ils peuvent remplacer la plupart des autres outils de description auparavant
utilisés (Grafcet, Fast,SADT, etc.)[7] .
Il existe neuf types de diagrammes, chacun d’eux étant dédié à la représentation des
concepts particuliers d’un système .ces types de diagramme sont répartis par l’OMG en trois
grand groupes :
 Quatre Aspects comportementaux :
1-Diagramme des cas d’utilisation (Uc) : Identique en UML et en SysML, il modélise les
fonctionnalités que le système doit fournir. Le cas d’utilisation est une unité fonctionnelle
utilisée pour la description et la recette du système.
2-Diagramme de séquence (Sd) : Identique en UML et en SysML le diagramme de séquence
modélise la chronologie des interactions entre les éléments du système ou entre le système et
l’extérieur.
3-Diagramme d’activité : Même utilisation en UML et en SysML. Le diagramme d’activité
modélise les flux d’informations et les flux d’activité du système.
4-Diagramme Etats transitions (Stm) : Identique en UML et en SysML, il représente les
différents états que peut prendre un élément ou une opération ainsi que ses réactions aux
évènements extérieurs.
 diagramme transverse :
5-Diagramme d’exigences : montre les exigences du système et leurs relations.
 quatre Aspects structurels :
6-Diagramme de Bloc (Bdd) : Le diagramme de Bloc en SysML est semblable au diagramme
de Classe en UML. Il donne une représentation statique des entités du système, de leurs
propriétés, et de leurs opérations.
7-Diagramme interne de bloc (Ibd) : Le diagramme interne de bloc permet de décrire les
blocs et les relations entre les blocs internes d’un système.
8-Diagramme de Package (Pkg) : Le diagramme de Package montre l’organisation générale
du modèle en UML comme en SysML. En SysML il sert en plus à donner différents point de
vue du système.[7]
9-Diagramme paramétrique (Par) : Nouveau dans SysML ce diagramme modélise les
paramètres physiques du système. Il exprime les contraintes physiques entre les blocs avec
des équations et des paramètres qui permettent de simuler le fonctionnement du système.

20
 La structure du système est re
représentée
présentée par les diagrammes de blocs. Le diagramme de
définition de blocs décrit la hiérarchie du système et les classifications système/composant. Le
diagramme de bloc interne décrit la structure interne du système en termes de partie, ports et
connecteurs.
rs. Le diagramme de package est utilisé pour organiser le modèle.

Figure2.2 : les 9 types diagramme de SysML

SysML inclut également une relation d’allocation pour représenter différent types
d’allocation, comme celles de fonction a des composant, de composants logique a composant
physique, ainsi software a hardware.

2.3.1 Diagramme de définition de bloc :

C’est un diagramme statique. Il montre les briques statiques : blocs, composition,
associations, agrégation, association, et généralisation.
Il est utilisé pour décrire l’architecture
architecture mat
matérielle du système.
me. Un bloc est une entité
entit bien
délimitéee qui encapsule principalement des attributs (variables dd’état),
tat), des opérations
op
(procédures
dures comportementales), des contraintes, des ports ((échange
change de flux avec l’extérieur)
l
et des parts (sous-blocs
blocs internes).
internes).[8]
Un bloc peut modéliser
liser tout le syst
système, un élément matériel ou logiciel.

2.3.1.1 Bloc et propriété :

Le bloc SysML constitue la base de la modélisation de la structure d’un système.
Le bloc permet de décrire également les flots qui circulent à travers un système.

21
Les blocs sont décomposables et peuvent posséder un comportement, on peut s’en servir pour
représenter des entités physiques logique et aussi conceptuelles.
Elles peuvent être deux propriétés principales[6] :
-les valeurs : décrivent des caractéristiques quantifiables en termes types de valeur (domaine
de valeur, dimension et unité optionnelles).
-les parties : décrivent la hiérarchie de décomposition du bloc en termes d’autre blocs.
Par exemple, si l’on considère le bloc Voiture, on peut définir des valeurs :
• Numéro d’immatriculation ;
• Kilométrage ;
• Vitesse courante ;
• etc.
La valeur vitesse courant sera typée part un types de valeur Vitesse, lui même
Définie par un type de base réel, une dimension Distance/temps et une unité km/h.
Pour ce même bloc, on pourra définir des parties telles que :
• un moteur ;
• quatre roues ;
• quatre portes ;
• un coffre ;
• etc.
Chaque bloc définit un ensemble d’instances partageant les propriétés du bloc, mais possédant
chacun une identité unique.
Le diagramme de définition de bloc est utilisé pour représenter les blocs, leurs propriétés,
leurs relations.
Dans in bdd, un bloc est représenté graphiquement par un rectangle découpé en
compartiments. Le nom du bloc apparait tout en haut, et constitue l’unique compartiment
obligatoire. Tous les autres compartiments ont des labels indiquant ce qu’ils contiennent :
valeurs, parties, etc.
Dans l’exemple suivant , nous avons modélisé le radio-réveil en tant que systéme a l’étude,
avec une valeur : couleur, et deux parties : radio et réveil.

22
 Figure 2-3 : le bloc radio-réveil
Nous pouvons préciser le type des parties et des valeurs :
• la partie radio est de type Radio(un nouveau bloc a créer) ;
• la partie réveil est de type éveil (un nouveau bloc a créer) ;
• la valeur couleur est de type Couleur(une énumération a créer).

Figure 2-4 : le bloc radio

radio-réveil aves qqn propriétés typées.
typées

2.3.1.2ValueType :
les valeur sont utilsées pour modéliser les caractéristique quantitatives des blocs. Il est
très important de bien définir les types de ces valeurs en termes de types de valeur
réutilisables.
SysML permet d’associer a chaque type de valeur une dimension et une unité optionnelles.on
peut également spécifier une valeur initiale (nom vvaleur=
aleur= valeur initiale) , ainsi qu’une
multiplicité[6].
Les types valeur sont basés sur les types de base proposés par SysML, a savoir :
• les types primitifs : integer, string,boolean,real,etc ;
• les énumération qui définissent un ensemble de valeurs nommées .
• les types stucturés,permettant de définir plusieurs champs,chacun étant a son tour une
valeur.

23
2.3.1.3 Composition :
La relation de composition entre blocs, dans laquelle un bloc représente le tout et les
autres ses parties, peut également être représentée graphiquement .le coté du tout est indiqué
par un losange plein. La multiplicité de ce même coté ne peut être 1 ou 00...1,
...1, car une instance
de partie ne peut exister que dans instances de tout au maximum a un moment a un moment
donné, dans notre exemple, nous allons préciser qu’une roue peut ne pas appartenir à une
voiture a un moment donné (multiplicité 0...1 du côté vo
voiture).Du
iture).Du côté des parties, on peut in
indiquer un nom de rôle et multiplicité (la valeur par défaut étant toujours 1)[6].
1)

Le diagramme qui suit est donc une représentation graphique alternative du précédent.

Figure 22-5 : deuxième bdd du bloc voiture.

2.3.1.4 Agrégation :
La relation d’agrégation est beaucoup moins forte que la relation de composition .en
particulier, il n’y a pas de contrainte de multiplicité du cote du tout, et donc pas nécessité
d’une structure stricte d’arbre. Mais il y a d’autres ccas
as ou l’agrégation est utile : pour
représenter le fait que la contenance n’est pas vraiment structurelle et obligatoire, mais plus
conjoncturelle [9].

24
 Figure 2-6 : La représentation graphique de la relation d’agrégation.
d’agrégation

2.3.1.5 Association :
L’association est une relation n’’impliquant pas de contenance, comme la composition
ou l’agrégation, mais une relation d’égale àégale.

Figure2-7 : La représentation graphique de la relation d’association.

d’association

2.3.1.6 Généralisation (héritage

(héritage) :
Toutes les définitions qui apparaissent dans un bdd peuventêtreorganisées dans une
hiérarchie de classification. Le but est souvent de factoriser des propriétés communes
(valeurs, partie, etc.), aplusieurs
plusieurs dans un bloc généralisé .les bloc spécialisés « héritent » des
propriétés du bloc généralisé et peuvent comporter des propriétés spécifique supplémentaire
.la généralisation en SysML se représente graphiquem
graphiquement
ent par une flèche triangulaire pointant
sur le bloc généralisé[6].

25
 Figure 2-8 : La représentation graphique de la relation de généralisions .

2.3.1.7 Opération :
Tous bloc possède également des propriétés comportementales, les principales étant
appelés opérations .une opération représente soit :
• une requête synchrone (l’émetteur est bl
bloqué
oqué en attente d’une réponse), avec ses
éventuels paramètres(ou arguments) en entrée, sortie, ou les deux ;
• une requête asynchrone, aussi appelée réception (l’émetteur n’est bloqué en attente
d’une réponse).Chaque réception est associée à un signal qui dé
définit
finit un message avec
ses éventuels paramètres. Des réceptions définies dans des blocs définition peuvent
répondre eu même types de signal.
Les opérations sont montrées dans un compartiment supplémentaire aves leur signature (nom,
paramètres et type de retour) :
Nom_opération (liste de paramètres) : types_retour
La liste de paramètres est une liste d’éléments séparés par des virgules, chaque élément étant
noté :
Directionnom_paramétre : type_paramétre
La direction pouvant prendre une des valeurs suivant : in,out, inout.
Les réceptions sont souvent montrées dans un compartiment à part. Les signaux peuvent à
leur tour être définis comme des blocs avec un mot
mot-clé« signal ».

26
2.3.1.8 Exemple de Diagramme de définition de bloc :

Figure 2.9 : exemple de diagrammede définition de bloc..

2.3.2Diagramme de blocs internes :

C’est un diagramme statique. Il est utilisé pour décrire l’architecture matérielle du
système. Il montre l’organisation interne d’un élément statique complexe. Il représente les
instances des
es parts d’un bloc (objets). L’IBD est cadré à l’intérieur des frontières du bloc
concerné. Les circulations de flux (MEI) entre les parts s’effectuent grâce aux connecteurs qui
relient leurs ports.
L’IBD d’un bloc est défini à partir du BDD correspondant. Un flux entre ou sort d’une part
via un port. [9]
L’élément de base d’IBD est part, qui décrit une collection des blocs. Un IBD identifie les
parts et leur structure interne, en montrant comment elles sont reliées entre elles.

2.3.2.1 Parties et connecteu

connecteurs :
On peut représenter la connexion entre les éléments d’un bloc au moyen d’un
diagramme de bloc interne. Ce diagramme montre les éventuelles multiplicités des parties.
La relation de composition du bdd se traduit de la façon suivant dans l’ibd :

27
 • le cadre de l’ibd représente le bloc englobant .il fournit le contexte pour tous les
éléments du diagramme.
• chaque extrémité d’une relation de composition, ou élément du compartiment parts,
apparaît comme un bloc à l’intérieur du cadre. Le nom du bloc est identique
ide à ce qui
apparaitrait dans le compartiment parts, soit : nom_partie : nom_bloc [multiplicité]
La multiplicité peut également être représentée dans le coin supérieur droit du rectangle. S’il
n’y a pas d’indication de multiplicité, elle est supposée vvaloir
aloir exactement 1.

Figure 2.
2.10 : Exemple d’ibd du bloc voiture.
Les associations simples et agrégation sont représentées de façon similaire aux compositions,
sauf que le rectangle du bloc est en pointillé.
Il est important de noter qu’on peut représente
représenterr plusieurs niveaux de décompositions ou de
référence sur un même ibd. [6]
6]

2.3.2.2 Connecteurs :
Le connecteur est un concept structurel utilisé pour relier deux parties et leur fournir
l’opportunité d’interagir, bien que le connecteur ne dise rien sur la nature de cette interaction.
Les connecteurs permettent également de relier plus finement les parties à travers des ports
(comme décrit au paragraphe suivant).
L’extrémité d’un connecteur peut posséder une multiplicité qui décrit le nombre d’instances
qui peuvent être connectées par des liens décrits par le connecteur.
Un connecteur peut être type par une association .il peut ainsi posséder une flèche
unidirectionnelle, si l’association qui le type la posséder .son nom complet est de la forme :
Nom_connecteur ; nom_association.

28
 Figure 2.11 : exemple d’ibd.

2.3.2.3 Les Ports :

1-Types de ports :
Le diagramme de bloc interne permet également de décrire la logique de connexion, de
services et de flot entre bloc grâce eu concept de « port » .les ports définissent
définiss les points
d’interaction offerts et requis entre les blocs. Les ports peuvent être de deux natures [6] :
• flux : ce type de port autorise la circulation de flux physiques entre les blocs.
• Standard : ce type de port autorise la description de services logique entre les blocs, au
moyen d’interfaces regroupant des opérations.
La distinction entre ces deux types de ports est souvent d’ordre méthodologique.
Les flow porte sont bien adaptés pour représenter des flux continus d’entités physiques.

Figure 2.12 : exemple de ports.

a) Flow Port :
Les ports de type « flux » sont soit atomiques (un seul flux), soit composites
(agrégation) de flux de natures différentes). La direction étant simplement indiquée par

29
une flèche à l’intérieur du carré représentant le por
port. Pour leur part ; les ports standards
sont simplement représentés par des carrés.

Les flow ports peuvent être typés par un bloc, un value type ou un signal représentant
le type d’élément pouvant circuler en entrée ou en sortie du port.

On peut également associer une multiplicité à un port. Donc la notion complète d’un
flow port est de la forme : nom_port : nom_item [multiplicité].

b) Item Flow :

Les éléments de flot (item flow) permettent de décrire ce qui circule réellement sur les
connecteurs, alors que les flow ports définissent ce qui peut circuler.la distinction n’est
pas toujours utile, mais peut se révéler néanmoins très pratique dans certains
certa cas. Les
items flow peuvent être représentés précisément grâce à la solution SysML d’item flow
(flèche noire nommée sur le connecteur), comme indiqué sur le diagramme suivant [6].

Figure 2.13 représentation d’item flow

c) Port standard :

Plutôt que de relier directement les interfaces aux blocs par des relations de réalisation
ou utilisation, on peut préciser à quel port standard est rattachée chaque interface .un
même port posséder plusieurs interfaces requises ou fournies .plusieurs ports peuvent
reliés
és aux mêmes interfaces
interfaces. [8]

30
2.3.2.4 Exemple de diagramme de bloc interne :

Figure 2.14 exemple d’ibd

2.4 Conclusion :
Dans ce chapitre, nous avons présenté le langage de modélisation standard SysML qui
est une extension d’UML pour modéliser les systèmes au sens large que se soient logiciel,
matériel, mécanique, etc…SysML apporte plusieurs améliorations surtout en ce qui concerne
c
la modélisation des blocs internes, des flux des données et des paramètres utilisés dans
différents contextes.

31
Chapitre 03 :

VHDL
(VHSIC Hardware Description Langage.)

32
3.1 Introduction :
Les sociétés de développement et les ingénieurs ont voulu s’affranchir des contraintes
technologiques des circuits. Ils ont donc créé des langages dits de haut niveau à savoir VHDL
et VERILOG. Ces Deux langages font abstraction des contraintes technologies des circuits
PLDs. Ils permettent au code écrit d’être portable, c’est à dire qu’une description écrite pour
un circuit peut être facilement utilisée pour un autre circuit. Dans ce chapitre, nous nous
sommes intéressés seulement à VHDL et aux fonctionnalités de base de celui-ci lors de
simulation ou de synthèse [10].

3.2 Le langage VHDL :

3.2.1 Définition et historique :
L’AbbreviationVHDL signifieVHSICHardware Description Language
(VHSIC:VeryHighSpeedIntegratedCircuit).
Le langage VHDL est utilisé pour décrire des systèmes logiques synchrones ou
asynchrones.
Développé dans les années 80 aux États-Unis, le langage de description VHDL est
ensuite devenu une norme IEEE numéro 1076 en 1987. Révisée en 1993 pour supprimer
quelques ambiguïtés et améliorer la portabilité du langage, cette norme est vite devenue un
standard en matière d'outils de description de fonctions logiques. A ce jour, on utilise le
langage VHDL pour [11] :
• concevoir des ASIC (Application SpecificIntegratedcircuit),
• programmer des composants programmables du type PLD(Programmable
LogicDevice), CPLD(Complex Programmable LogicDevice) et FPGA (Field
Programmable GateArray),
• concevoir des modèles de simulations numériques ou des bancs de tests.

3.2.2 Pourquoi un langage de description ?

L'électronicien a toujours utilisé des outils de description pour représenter des
structures logiques ou analogiques. Le schéma structurel que l'on utilise depuis si longtemps
et si souvent n'est en fait qu'un outil de description graphique. Aujourd'hui, l'électronique
numérique est de plus en plus présente et tend bien souvent à remplacer les structures
analogiques utilisées jusqu'à présent. Ainsi, l'ampleur des fonctions numériques à réaliser
nous impose l'utilisation d'un autre outil de description. Il est en effet plus aisé de décrire un
compteur ou un additionneur 64 bits en utilisant l'outil de description VHDL plutôt qu'un
schéma.

33
 Le deuxième point fort du VHDL est d'être “un langage de description de haut
niveau”. D'autres types de langage de description, comme l'ABEL par exemple, ne possèdent
pas cette appellation. En fait, un langage est dit de haut niveau lorsqu'il fait le plus possible
abstraction de l'objet auquel ou pour lequel il est écrit. Dans le cas du langage VHDL, il n'est
jamais fait référence au composant ou à la structure pour lesquels on l'utilise. Ainsi, il apparaît
deux notions très importantes [12]:

Portabilité des descriptions VHDL, c'est-à-dire, possibilité de cibler une
descriptionVHDL dans le composant ou la structure que l'on souhaite en utilisant
l'outil que l'on veut (en supposant, bien sûr, que la description en question puisse
s'intégrer dans le composant choisi et que l'outil utilisé possède une entrée VHDL) ;

Conception de haut niveau, c'est-à-dire qui ne suit plus la démarche descendante
habituelle (du cahier des charges jusqu'à la réalisation et le calcul des structures
finales) mais qui se “limite” à une description comportementale directement issue des
spécifications techniques du produit que l'on souhaite obtenir.

3.3 Structure d’une description VHDL :

3.3.1 Les entités de conception et la configuration :
Les entités de conception sont les briques d’une construction VHDL. Elles peuvent
représenter un système complet, un sous-système, une carte, un circuit intégré, une porte
logique. Elles présentent des ports d’entrée et de sortie bien définis et exécutent une fonction
bien définie. Une configuration peut être utilisée pour décrire comment ces entités sont
connectées entre elles pour former un système complet. Une entité de conception est définie
par une déclaration d’entité associée au corps d’une architecture.
En VHDL, une structure logique est décrite à l'aide d'une entité et d'une architecture de la
façon suivant [11] :

Entrée STRUCTURE
LOGIQUE
Sorties

Figure 3.1 : la structure logique de VHDL

34
3.3.1.1 La déclaration d’entité :
Une déclaration d’entité définie les ports d’interface entre une entité de conception et
son environnement. Une déclaration d’entité peut être partagée par plusieurs entités de
conception, chaque entité de conception possédant une architecture différente. Une
déclaration d’entité peut être vue comme une classe d’entité de conception, chacune
présentant les mêmes interfaces.
-Les paramètres génériques sont des constantes dont les valeurs peuvent être spécifiées par
l’environnement, sinon une valeur par défaut doit leur être affectée.
-Le champ mode des ports peut prendre les noms in, out, inout. Une valeur par défaut peut
être affectée aux ports en mode in, cette valeur est prise en compte à la simulation et à la
synthèse pour initialiser la valeur des signaux. Les modes des ports couramment utilisés sont :
in, port d’entrée, out, port de sortie, inout, port d’entrée/sortie.
-La partie déclarative des paramètres et ports déclare des objets qui sont communs à toutes les
entités de conception dont les interfaces sont définies par la déclaration d’entité.
-La partie instructions déclare des appels de procédures concurrentes ou des process. Ces
déclarations sont utilisées pour contrôler les conditions d’opération de l’entité de conception.
Les process ou procédures doivent être passifs, c'est-à-dire ne pas contenir d’affectation de
signaux.[13]
entitynomEntitéis
[generic (
nomParamètre : type := valeurParDéfaut;
…
nomParamètre : type := valeurParDéfaut);]
[Port (
nomPort : mode type := valeurParDéfaut;
…
nomPort : mode type := valeurParDéfaut);]
[déclarations sous-programmes, types, constantes…]
[begin instructions process ou procédures passifs]
end [entity] [nomEntité];

Exemple code :
EntitybasculeD is
Generic (
tSetUp: time := 5 ns ;
tHold : time := 4 ns ;
tCkToQ : time := 2 ns
);
Port (
d: in std_logic:= ‘1’ ;
h : in std_logic:= ‘1’ ;

35
q : out std_logic
);
Constant :pulseWidth : time := 10 ns ;
Begin
checkSetUpTime (tSetUp, d, h) ;
checkHoldTime (tHold, d, h) ;
checkPulseWidth (pulseWidth, h) ;
EndentitybasculeD;
3.3.1.2 Les architectures :
Le corps d’une architecture définit le corps d’une entité de conception. Il spécifie les
relations entre les entrées et les sorties d’une entité de conception. Cette spécification peut
être exprimée sous forme comportementale, structurelle, flot de données, les trois formes
peuvent coexister à l’intérieur d’un même corps d’architecture.
La partie déclarative déclare des objets qui seront visibles et utilisables par l’entité de
conception[14].
Toutes les instructions qui décrivent le corps de l’architecture sont des instructions
concurrentes qui s’exécutent de façon asynchrone les unes par rapport aux autres.
architecturenomArchitecture of nomEntitéis
[déclarations sous-programmes, types, constantes, signaux, composants…]
begin
instructionsconcurrentes
end [architecture] [nomArchitecture];

Exemplecode :
architecturertlofbasculeDis
begin
pBascD :process (h)
begin
if (h'eventand h = '1') then
q <= d;
endif;
endprocesspBascD;
endarchitecturertl;

36
3.3.1.3 Déclaration d’un composant ‘COMPONENT’ :
La déclaration d’un composant déclare les interfaces à une entité de conception
virtuelle. Une configuration de composant peut être utilisée pour associer l’instance d’un
composant avec une unité de conception présente en librairie.
C’est une description de type hiérarchique par liste de connexions tout à fait comparable à la
Réalisation d’un circuit imprimé comprenant des supports, des circuits et des équipotentielles.
Une description est structurelle si elle comporte un ou plusieurs composants (mot
clé :COMPONENT). Ceux-ci jouent le rôle de support pour le câblage. Ils doivent donc avoir
le même aspect extérieur que les modèles qu’ils vont supporter. Il est, bien sûre, possible
deconcevoir des structures imbriquées donc à plusieurs niveaux de hiérarchie.
Pour de telles descriptions, la marche à suivre est la suivante [13] :

Déclarer autant de composants que nécessaire : COMPONENT.

Déclarer les listes de signaux internes nécessaires pour le câblage : SIGNAL.

Déclarer quel modèle (couple entité-architecture) doit être utilisé sur
chaqueComposant.

Instancier chaque composant en indiquant sa liste de connexions : PORT MAP.

Exemple code :
ARCHITECTURE structure1 OF compteur4 IS
-- déclaration des signaux nécessaires aux câblages
SIGNAL d, s, sb: BIT_VECTOR (3 DOWNTO 0);
SIGNAL ra1 : BIT ;
-- déclarat1ion des composants nécessaires
COMPONENTbascule
PORT (h, d, raz, ra1 : IN BIT;
s, sb: OUT BIT);
END COMPONENT;
COMPONENTcalcul
PORT (s, sb: IN BIT_VECTOR ( 3 DOWNTO 0);
compter: IN BIT;
d: OUT BIT_VECTOR ( 3 DOWNTO 0);
Plein: OUT BIT);
END COMPONENT;
-- configurations locales (si pas de CONFIGURATION séparée)

37
-- FOR ALL: bascule USE ENTITY WORK.bascule_d (rtl);
-- FOR ALL: calcul USE ENTITY WORK.equations (par_10);

3.3.1.4Déclaration de’ Blocs’ :

Le bloc (BLOCK) est élément de base de la structuration de la description. Il permet
de définir une hiérarchie. Mais il n’est pas exportable et reste interne à une architecture.
L’entité apparaît ainsi comme un bloc exportable. Plusieurs blocs peuvent êtreImbriqués.
Dans un bloc, on ne trouve que des instructions concurrentes. Il est possible d’y définir des
frontières (PORT), d’y mettre en commun des conditions logiques (GUARD), dele concevoir
comme paramétrable (GENERIC) [13].

Exemple code :
ENTITY es IS
PORT(e IN bit ; -- une entrée
s : OUT bit); -- une sortie
END es;
ARCHITECTUREdeux_blocs OF es IS
SIGNAL i : bit; -- signal intermediaries
BEGIN
B1 :BLOCK PORT (e1 : IN bit; s1 ; OUT bit);
PORT MAP ( e1 => e, s1 => i);
BEGIN
s1 <= e1; -- notations locales
END BLOCK B1;
B2:BLOCK PORT (e2 : IN bit; s2 ; OUT bit);
PORT MAP ( e2 => i, s2 => s);
BEGIN
s2 <= e2; -- notations locales
END BLOCK B2;
END deux_blocs;

3.3.1.5 Les signaux :

a)Signal avec un seul pilote :

Le signal est un objet de première importance car c’est lui qui permet de connecter entre eux
les circuits implantés sous forme de processus.[11]

38
Un signal est caractérisé par :
-Un type déclaré
-Un état en référence à ce type
-Un ou plusieurs pilotes (driver) qui lui sont associé.
Le pilote du signal contient une liste de couples état-heure celle-ci étant comptée relativement
àl’heure actuelle du simulateur.
Au moment de son exécution, l’instruction VHDL suivante
s <= ‘0’, ‘1’ AFTER 10 ns,’0’ AFTER 25 ns;
Placera dans la pilote de s
heure Etat
0 ‘0’
10 ‘1’
25 ‘0’
Le pilote est en fait une mémoire associée au signal.

b) Évènements :
On appelle événement tout changement d’état d’un signal. (Alors qu’une transaction est une
opération effectuée sur le signal mais qui peut ne pas se traduire par un événement).Tant
qu’un événement potentiel se trouve dans le pilote mais n’est pas affecté au signal, il est dit
non mur.

3.3.1.6Les processus :
Les processus constituent les éléments calculatoires de base du simulateur. Au
niveaudescriptif, ils peuvent être explicites (PROCESS) ou implicites (instructions
concurrentes).
Du point de vue de l’exécution, on peut affirmer que « tout est processus ».
Un processus vit toujours depuis le chargement du code exécutable dans le simulateur. Il
nepeut prendre fin qu’avec la simulation mais peut par contre être endormi pour une durée
plusou moins longue. L’instruction WAIT, obligatoire au moins une fois, synchronise le
processus. Elle possède trois formes pouvant être combinées :[14]
WAIT ON événement ; WAIT FOR durée ; WAIT UNTIL condition ; WAIT ;
Le processus s’exécute au moins une fois jusqu’à rencontrer le WAIT, puis la condition de
réveil une fois validée, l’exécution continue de façon séquentielle et cyclique (après la fin,
ledébut). Donc à retenir :
« Tout est processus »

39
« Un processus est synchronisé par WAIT »
« Un processus est cyclique »
Première exemple : génération d’horloge :
SIGNAL h : bit;
BEGIN
Horloge :PROCESS
BEGIN
h <= ‘0’, ‘1’ AFTER 75 ns;
WAIT FOR 100 ns;
END PROCESS;
3.3.1.7 Les variables :
Les variables ne peuvent apparaitre que dans le domaine de programmation séquentiel.
Elles sont affectées par l’instruction ":=", l’affectation est immédiate.
Différence entre signal et variable :
-s <= 1 + 2 ; -x := 1 + 2 ;
-C’est le pilote du signal qui est -Une variable estaffectée immédiatement.
immédiatement affecté. -x prend la valeur 3.
-3 est mémorisé dans le pilote de s. -une variable n’est pasvisible au dehors du
-Le signal est affecté plus tard ( processus.
Processus endormi par WAIT).

3.3.1.8 Les constantes :

Sont assimilés à des constantes tous les objets dont la valeur peut être résolue durant la
phased’élaboration de la description VHDL. Les constantes sont déclarées par le mot clé
constant, lesparamètres génériques déclarés dans l’en-tête des entités doivent aussi être des
constantes.

3.3.1.9 Les fichiers :

Les fichiers sont des objets spéciaux utilisés exclusivement dans des descriptions non
synthétisables.

3.3.2 Les sous-programmes :

3.3.2.1 les procédures :

Tout comme l‘instruction d’affectation d’un signal, une procédure appelée au même
niveau que l’instruction "process" est dite concurrente alors qu’une procédure appelée à
l’intérieur du corps d’un process est dite séquentielle.[13]

40
 Déclaration
ProcedurenomProcedure ([classeObjet] nomParametre : [sens] type ;

Définition
ProcedurenomProcedure ([classeObjet] nomParametre : [sens] type ;
…
[classeObjet] nomParametre : [sens] type) is
Begin
ListeInstructionsSéquentielles
End procedure [nomProcedure] ;

3.3.2.2 Les fonctions :

Déclaration
functionnomFonction (nomParametre : type ;
…
nomParametre : type)
return type ;
Définition
functionnomFonction (nomParametre : type ;
…
nomParametre : type) is
Begin
ListeInstructionsSéquentielles
Endfunction[nomFonction] ;

3.3.3 Les éléments d’archivage :

3.3.3.1 Les librairies :

Une librairie est une bibliothèque ou sont stockées des entités de conception
précompilées. Elles sont déclarées en en-tête d’une description VHDL par l’instruction
library et l’instruction usepermet de sélectionner quels objets pourront être utilisés dans la
suite de la description. [12] Lesdescriptions sont compilées dans la librairie par défaut de
travail work à moins qu’une autrelibrairie soit couramment activée dans l’outil de
compilation. La déclaration des librairies std, worket la sélection des paquetages et corps de
librairies std.standard.all, work.all n’est pas nécessaire.

3.3.3.2 Les paquetages :

Spécification et corps de paquetage :

Les spécifications de paquetages définissent les prototypes de procédure et fonctions,
déclarent des constantes, des composants, des types. Le corps du paquetage décrit le corps des
fonctions etprocédures.[13]
PackagenomPaquetageis

41
listeInstructionsDéclarations
endpackagenomPaquetage ;
Package bodynomPaquetageis
listeInstructionsDéclarationsInternes
corpsProcedures
corpsFonctions
End [package body] [nomPaquetage] ;
Les paquetages normalisés
-Les paquetages développés et normalisés par l’IEEE sont les suivants :
• standard, textio (Librairiestd)
• math_complex, math_real,,numeric_bit, numeric_std, std_logic_1164 (librairieieee)
-Les paquetages développés par la société SYNOPSYS et utilisés dans beaucoup
d’environnementVHDL sont les suivants :
• std_logic_arith, std_logic_misc, std_logic_signed, std_logic_textio, std_logic_unsigned

3.4 Conclusion :
Le langage VHDL est un standard IEEE pour décrire les circuits électroniques à
plusieurs niveaux d’abstraction. Elle offre les constructeurs nécessaires pour spécifier la
concurrence, la synchronisation, le temps et même des mécanismes logiciels tels que l’appel
aux procédures, les instructions séquentielles et de contrôle. VHDL est utilisé d’une part pour
la simulation fonctionnelle et temporelles grâce à son simulateur à événements discret intégré
et de l’autre part, pour la synthèse des circuits à partir des descriptions comportementales qui
ressemblent bien les algorithmes du côté logiciel. Bien que VHDL soit le premier standard
préféré par la communauté matérielle, elle souffre de plusieurs lacunes telles que le manque
de l’aspect graphisme ce qui rend la maintenance des programmes fastidieuse.

42
Chapitre 04 :

CONCEPTION
ET IMPLMENTATION

43
4.1 Introduction :
Dans ce chapitre, nous présentons, notre conception etoutil pour la génération
automatique de diagrammes SysML à partir du code VHDL. En premier lieu, nous décrivons
notre approche tout en définissant les règles de passage de code VHDl vers SysMl, après nous
présentons brièvement le langage java, adopté à la mise en œuvre de cette génération. Ensuite
nous présentons quelques résultats sur un exemple.
4.2 Approche de rétro ingénierie pour la génération de diagrammes
SysML à partir du code VHDL
L’approche proposée est illustrée en figure 4.1.

Code VHDL Simulation

Parsing
(Analyse lexicale)

Règles de
correspondance
Structuration des SysML-VHDL
éléments
syntaxiques

XML

Génération de
diagrammes SysML

Figure 4.1 : Notre approche proposée.

44
 Le processus de génération passe par plusieurs étapes, la première étape consiste à
simuler le code VHDL afin de détecter et corriger les erreurs éventuelles. A ce stade on peut
par exemple utiliser le simulateur VHDL ModelSim. La deuxième étape est l’analyse lexicale
du code VHDL de départ. Le code VHDL est généralement reparti sur plusieurs fichiers ayant
l’extension ‘vhd’. Dans cette étape, on essaye de reconnaitre et d’extraire tous les éléments
syntaxiques du code VHDL comme les entités, les architectures, les processus, les ports, les
paquetages, les composants, etc. La troisième étape sert à agencer les éléments trouvés
précédemment en structures hiérarchiques (en XML par exemple) pour faciliter la génération
de diagrammesSysML. La dernière étape revient à générer les diagrammes SysMLen faisant
référence aux règles de correspondance SysML-VHDL.
4.3Passage de code VHDl vers SYSML :
La génération automatique de diagrammes SysML à partir du code VHDL, nous
oblige de définir un ensemble de règles de correspondance entre les concepts VHDL et
SysML. Ces règles dont présentées dans le tableau 4.1. Notons que ces règles concernent
uniquement les diagrammes SysML de définition de bloc et de bloc interne.

Concept VHDL Concept SysML

Entity Bloc
Use Héritage
Component Agrégation
Port Flow port
Bloc Composition
PRECESS Stéréotype « Process »
Signal Stéréotype « signal »
Variable Variable
Component / bloc instance Instance de classe
Procédure/fonction Méthode de classe
Port map Lien entre deux Flow ports
Nombre des instances Cardinalité
Table 4.1 : Règles de passage VHDL-SysML

4.4 Implémentation :
Nous avons implémenté notre outil avec le langage java éclipse.

4.4.1 Java éclipse

Eclipse est un IDE, IntegratedDevelopmentEnvironment (EDI environnement de
développement intégré en français), c'est-à-dire un logiciel qui simplifie la programmation en

45
proposant un certain nombre de raccourcis et d'aide à la programmation. Il est développé
dévelop par
IBM, est gratuit et disponible pour la plupart des systèmes d'exploitation. [15]
Au fur et à mesure qu’on programme
programme, éclipse compile
ile automatiquement le code qu’on écrit,
en soulignant en rouge ou jaune les problème qu'il décèle. Il souligne en rouge les parties du
programme qui ne compilent pas, et en jaune les parties qui compilent mais peuvent
éventuellement poser des problème
problèmes (on dit qu'éclipse lève un avertissement, ou warning en
anglais).

Figure 4.2 : la fenêtre de java éclipse.

4.4.1.1Installation :
Le logiciel
giciel est déjà installé sur la machine
machine. Il suffit de taper éclipse dans un terminal pour le
lancer. (éclipse est disponible sur le site http://www.eclipse.org pour linux, BSD, Windows ou
MacOS. La page http://www.eclipse.org/downloads choisit automatiquement la bonne
version).

4.4.2 Génération automatique de Diagrammes SysML à partir du code VHDL

Voici l’interface de projet de Génération automatique de Diagrammes SysML à partir du code
VHDL :

46
 Figure 4.3 : Interface de projet.

L’interfacecontient deux menu

menus File et Trans :

File contient Open VHDl File : pour importer un fichier VHDL ou plusieurs fichier.
fichier

Transcontient Bloc définition diagramme etinternal Bloc diagramme.

Si on importe un fichier ajouté dans le File List et déterminer leur architecture et liste de bloc
et liste de package dans Architect List et Block List et Package List.

4.4.2.1
.2.1 Génération automatique de Diagrammes de définition de bloc et Diagramme
de bloc interne à partir du code VHDL :

Exemple :
Les fichiers VHDL utilisés dans l’exemple est totalmedian, utils, pixel2pgm, pgm2pixel
median, gaussien(.vhd) etle
le fichier principal qui contient la classe main est totalmedian et
défini comme suit :

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITYtotalmedian IS
ENDtotalmedian;

USEwork.utils.ALL;

ARCHITECTURE structure OF totalmedian IS

BLOCKS camera
GENERIC (
image : string := "lena.pgm";

47
periode : time := 100 ns); -- frequenceechantillonnage
PORT (
init : OUT std_ulogic;
pixel : OUT natural RANGE 0 TO 255;
dispo : OUT std_ulogic;
acquit : IN std_logic);
END COMPONENT;

COMPONENT dut
PORT (h : IN std_ulogic;
init : IN std_ulogic;
pixel : IN natural RANGE 0 TO 255;
pix_calcul : OUT natural RANGE 0 TO 255;
ready_in : IN std_ulogic;
ack_in : OUT std_ulogic;
ready_out : OUT std_ulogic;
ack_out : IN std_ulogic);
END COMPONENT;

COMPONENT moniteur
GENERIC (
image : string := "lena_fil.pgm";
periode : time := 100 ns; -- frequenceechantillonnage
nx : natural := 512; -- points par ligne
ny : natural := 512); -- nbre de lignes
PORT (
init : IN std_ulogic;
pixel : IN natural RANGE 0 TO 255;
dispo : IN std_ulogic;
acquit : OUT std_ulogic);
END COMPONENT;

SIGNAL h, init, ready_in, ack_in, ready_out, ack_out :std_ulogic;

SIGNAL pixel, sortie : integer; -- contraintedifferree

FOR C1 : camera
USE ENTITY work.pgm2pixel(pour_cci);

FOR d1 :dut
USE ENTITY work.filtre(median);

FOR M1 :moniteur

USE ENTITY work.pixel2pgm(ecriture);

TYPE tableau IS ARRAY (positive RANGE<>) OF natural RANGE 0 TO

16*255;

BEGIN --par_constantes

C1 : camera GENERIC MAP (

image => "/net/ens/nouel/pub/filtrage/lenabruit.pgm")
PORT MAP (
init =>init,

48
pixel => pixel,
dispo =>ready_in,
acquit =>ack_IN );

d1: dut

PORT MAP (h, init, pixel, sortie, ready_in,ack_in,ready_out,

ack_out);

M1 :moniteur
GENERIC MAP (
image => "median.pgm")
PORT MAP (
init =>init,
pixel => sortie,
dispo =>ready_out,
acquit =>ack_out);

pour_circ : horloge(h, 50 ns , 50 ns);

END structure;

Après l’importation Vhdl on peut afficher le code dans l’interface comme suite :

Figure 4.4 affichage de code VHDL dans l’interface

49
Le résultat de génération est :

Figure 4.5 génération de diagramme de définition de bloc à partir de l’exemple VHDL.

Le résultat de génération de diagramme de bloc interne à partir code VHDL est présenté en
figure 4.6.

50
 Figure 4.6 génération de diagramme de bloc interne à partir du l’exemple VHDL.

4.4 Conclusion :
Dans ce chapitre, nous avons donné un aperçu sur notre approche de rétro ingénierie
pour la génération automatique de ddiagrammes SysML de définition de bloc et de bloc interne
à partir du code VHDL. Nous avons également validé notre approche sur un exemple concret.

51
Conclusion générale

52
Dans ce travail, nous avons proposé une approche de rétro ingénierie pour la génération
automatique de diagrammes SysML de définition du bloc et de bloc interne à partir du code
VHDL.
SysML est un nouvel langage standardisé par l’OMG extension d’UML pour modéliser les
systèmes au sens large que ce soit logiciel, matériel, mécanique, etc. il intègre un ensemble de
concepts intéressants pour modéliser le matériel.
VHDL est un standard pour la conception des circuits numériques et analogiques (VHDL-
AMS est une extension de VHDL pour programmer les circuits analogiques).
A l’instar d’UML, SysML a attiré beaucoup d’attentions ces dernières années surtout pour les
concepteurs du matériel. SysML a été déjà utilisé pour générer de manière automatique un
code de description matériel (HDL) écrit en SystemC, Verilog et VHDL-AMS.
A l’inverse de ces travaux, notre contribution sert à générer de diagrammes SysML à partir du
code VHDL existant. L’apport de notre travail est de faciliter la maintenance et la
compréhension des programmes VHDL auprès les concepteurs matériel et même logiciel et
cela c’est grâce aux modèles graphiques offerts par SysML.
Notre approche de génération de diagrammes définition de bloc et les diagrammes de bloc
interne à partir du code VHDL se fait en s’appuyant sur un ensemble des règles de
correspondance entre les concepts SysML et les concepts VHDL.
Comme perspectives, nous envisageons de :
1. Etendre notre approche pour générer d’autres diagrammes SysML comme les
diagrammes d’activités.
2. Appliquer la technologie de transformation de modèles pour la génération automatique
de diagrammes SysML à partir du code VHDL.

53
 Bibliographie
[1]:Identification of Behavioral and Creational Design Patterns through Dynamic Analysis.
Proceedings of the third International Workshop on Program Comprehension through
Dynamic Analysis (PCODA), October 2007.
[2]:http://theses.univbatna.dz/index.php?option=com=doc_download&gid=1506&Itemid=4,
September 2010.
[3]:http ://en.wikipedia.org/wiki/Systems engineering
[4]:Chikofsky and J. I. Cross. Reverse engineering and design recovery: taxonomy.
IEEE Software, Jan 1990.
[5] :PROCESSUS De RETRO INGÉNIERIE avec SysMLavecSysML Travaux issus du
groupe de travail Education Nationale/AFIS.mars 2014.
[6] : Pascal Roques, EyrollesSysML par l’exemple Un langage de modélisation pour systèmes
complexes, 2009.
[7] : Finance. Modélisation SysML .décembre 2010.
[8]:OMG Systems Modeling Language (OMG SysML™), V1.0 September 2007.
[9]:http ://www.sysml.org/.
[10]:The VHDL Golden Reference Guide DOULOS. Version 1.1, December 1995
[11]: VHDL Du langage au circuit, du circuit au langage par J.Weber et M.Meaudre- Masson.
[12] :http://lslwww.epfl.ch/pages/teaching/cours_sl/sl_info/19.VHDL.pdf.
[13] : Hervé Le Provost Initiation au langage VHDL Université de Marne-La-Vallée juin
2008
[14] : www.vhdl.org.
[15] :http ://www.eclipse.org/m2m/.

54