penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/wppesynthesis.pdf · table des matieres`...

135
Prototypage Handel-C d’architectures parallèles programmables sur la plateforme multimédia Celoxica RC203E Université de Bretagne Occidentale Département Informatique 20, avenue Le Gorgeu C.S. 93837 BP 809 29238 BREST Cedex 3 AUTEURS : K.Berraho & A.Floc’h Juillet 2006

Upload: others

Post on 24-Jul-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Prototypage Handel-C d’architectures parallèles programmables sur la plateforme multimédia Celoxica RC203E

Université de Bretagne OccidentaleDépartement Informatique

20, avenue Le Gorgeu C.S. 93837 BP 809 29238 BREST Cedex 3

AUTEURS : K.Berraho & A.Floc’h

Juillet 2006

Page 2: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Remerciements

Ce travail d’etude et de recherche s’est deroule au sein du laboratoire Architectures

et Systemes de l’UBO.

Nous tenons a remercier l’ensemble de l’equipe qui nous a accueilli et tout parti-

culierement Erwan Fabiani pour sa disponibilite et ses conseils.

Page 3: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Table des matieres

1 Contexte et objectifs du projet 2

1.1 Recherches sur les possibilites de prototypage d’architectures paralleles

sur base d’un circuit logique reconfigurable . . . . . . . . . . . . . . 2

1.2 Developpement sur la plateforme Celoxica RC203 . . . . . . . . . . 3

1.2.1 Presentation et caracteristiques de la carte . . . . . . . . . . . 3

1.2.2 Le FPGA Virtex-II XC2V3000. . . . . . . . . . . . . . . . . 4

1.2.3 Handel-C : Un langage adapte au developpement d’architec-

tures materielles. . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.4 Acces au materiel : couche d’abstraction PAL et librairie PSL 7

1.2.5 Environnement de developpement DK4 de Celoxica . . . . . 8

1.2.6 Generation des fichiers binaires de configurations : ISE de Xilinx 8

2 Interfacage et alimentation en donnees d’architectures. 10

2.1 Les technologies utilisees. . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Exploitation du code type assembleur . . . . . . . . . . . . . 10

2.1.2 Lecture des donnees et du programme en memoire interne. . 10

2.1.3 Lecture du code sur la SmartMedia puis transfert vers la memoire

statique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.4 Lecture du code via le port parallele puis transfert vers la memoire

interne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.5 Lecture du code via le port parallele, stockage et acces en RAM. 14

2.1.6 Programme dans en memoire interne, donnees en RAM. . . . 14

2.2 Comparaison des taux d’utilisation. . . . . . . . . . . . . . . . . . . 15

ii

Page 4: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

TABLE DES MATIERES

2.2.1 Conditions de mesures. . . . . . . . . . . . . . . . . . . . . . 15

2.2.2 Resultats observes. . . . . . . . . . . . . . . . . . . . . . . . 15

3 Etude des performances 18

3.1 Methodologie theorique et remarques sur l’optimisation du temps de

cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Analyse du code . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.2 Documentation PSL : performances d’acces aux ressources ex-

ternes au FPGA . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.3 Optimisation du temps de cycle . . . . . . . . . . . . . . . . 20

3.2 Mesure du nombre de cycles . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Mesure de la frequence de fonctionnement du FPGA . . . . . . . . . 21

4 Processeur programmable 23

4.1 Processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Architecture du processeur . . . . . . . . . . . . . . . . . . . 23

4.1.2 Jeu d’instructions . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.3 Fonctionnement du processeur . . . . . . . . . . . . . . . . . 25

4.1.4 Couts des instructions . . . . . . . . . . . . . . . . . . . . . 25

4.1.5 Exemple de programme : suite de Fibonacci . . . . . . . . . . 26

4.2 Architecture s’appuyant sur la micro-programmation . . . . . . . . . 26

4.2.1 Architecture du processeur et format logique des instructions . 27

4.2.2 Le microcontroleur . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Micro-instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1 Types de micro-instructions . . . . . . . . . . . . . . . . . . 31

4.3.2 Exploitation des micro-operations . . . . . . . . . . . . . . . 32

4.3.3 Traitement d’une micro-instruction . . . . . . . . . . . . . . 35

4.4 Jeu d’instruction du processeur microprogramme . . . . . . . . . . . 37

4.5 Specialisation des processeurs . . . . . . . . . . . . . . . . . . . . . 38

5 Reseaux de processeurs a topologies fixes 39

iii

Page 5: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

TABLE DES MATIERES

5.1 Matrice carree de processeurs . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Reseau de processeurs . . . . . . . . . . . . . . . . . . . . . 39

5.1.2 Extension du jeu d’instructions : dialogues inter-processeurs . 39

5.1.3 Exemple d’un reseau de 4 processeurs . . . . . . . . . . . . . 40

5.1.4 Extension du nombre de processeurs : mesure des taux d’occu-

pation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Architecture Data-Flow . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 Description de l’architecture . . . . . . . . . . . . . . . . . . 42

5.2.2 Modification du jeu d’instructions . . . . . . . . . . . . . . . 43

5.2.3 Application d’un modele data-flow : Dilatation d’une image . 43

6 Reseaux de processeurs a topologies reconfigurables 49

6.1 Communications par commutation de canaux : crossbars . . . . . . . 49

6.1.1 Description de l’architecture du crossbar . . . . . . . . . . . 49

6.1.2 Description du fonctionnement . . . . . . . . . . . . . . . . . 50

6.1.3 Evolution de la taille des canaux : mesure du taux d’occupa-

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.4 Reseau de processeurs . . . . . . . . . . . . . . . . . . . . . 52

6.2 Communications par circuits virtuels . . . . . . . . . . . . . . . . . . 54

6.2.1 Architecture iWarp . . . . . . . . . . . . . . . . . . . . . . . 54

6.2.2 Communications par circuits virtuels . . . . . . . . . . . . . 55

6.2.3 Occupation de la surface et performances . . . . . . . . . . . 58

6.3 Reconfiguration du reseau : processeur de Boot . . . . . . . . . . . . 58

6.3.1 L’architecture du processeur de boot . . . . . . . . . . . . . . 59

6.3.2 Jeu d’instructions . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3.3 Fonctionnement du processeur de boot . . . . . . . . . . . . 61

6.3.4 Exemple de programme pour le processeur de boot . . . . . . 64

A Mesure de cycles et de frequences : Handel-C 66

B Mesure de cycles et de frequences : programme C 68

iv

Page 6: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

TABLE DES MATIERES

C Commandes FTU2 72

C.1 Adressage logique. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

C.2 Exportation du contenu de la carte. . . . . . . . . . . . . . . . . . . . 72

C.2.1 Acces selon un adressage physique. . . . . . . . . . . . . . . 72

C.2.2 Acces selon un adressage logique. . . . . . . . . . . . . . . . 73

C.3 Ecriture sur la carte. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.3.1 Ecriture de donnees : -d. . . . . . . . . . . . . . . . . . . . . 73

C.3.2 Ecriture d’un fichier BIT : -b. . . . . . . . . . . . . . . . . . 73

C.3.3 Configuration de la carte. . . . . . . . . . . . . . . . . . . . . 73

D Code Handel-C du processeur 74

E Code Handel-C du processeur utilisant les micro instructions 78

F Matrice de quatre processeurs : calcul fibonacci 95

G Data-flow : Dilatation d’une image, transmission par colonnes 99

H Communication par circuits virtuels : code Handel-C 110

I Microcode du microcontroleur 126

v

Page 7: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Table des figures

1.1 Architecture de la plateforme RC203E. . . . . . . . . . . . . . . . . . 3

1.2 Structure d’un bloc logique configurable (CLB). . . . . . . . . . . . . 4

1.3 Architecture des Virtex-II. . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Caracteristiques du XC2V3000. . . . . . . . . . . . . . . . . . . . . 5

1.5 Abstraction PAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Compilation d’un fichier type assembleur. . . . . . . . . . . . . . . . 11

2.2 Calcul du 9e terme de la suite de Fibonacci . . . . . . . . . . . . . . 11

2.3 Code Handel-C : Initialisation de la SmartMedia. . . . . . . . . . . . 13

2.4 Code Handel-C : lecture et ecriture sur port parallele. . . . . . . . . . 14

2.5 Macros Handel-C de lecture et d’ecriture en RAM0. . . . . . . . . . . 14

2.6 Taux d’utilisation logique (sans tenir compte du cout de routage). . . . 15

2.7 Utilisation des slices. . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.8 Utilisation totale des LUT’s. . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Couts fixes et variables d’acces aux ressources externes de la carte RC203 19

3.2 Mesure du nombre de cycles . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Mesure de la frequence . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Architecture du processeur. . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Codage d’une micro-instruction horizontale. . . . . . . . . . . . . . . 27

4.3 Format d’une instruction principale . . . . . . . . . . . . . . . . . . . 27

4.4 Architecture du processeur microprogramme . . . . . . . . . . . . . 28

vi

Page 8: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

TABLE DES FIGURES

4.5 Architecture du microcontroleur . . . . . . . . . . . . . . . . . . . . 30

4.6 Mecanisme de controle des microinstructions . . . . . . . . . . . . . 31

4.7 Format logique d’une micro-instruction . . . . . . . . . . . . . . . . 32

4.8 Micro-operations de transferts . . . . . . . . . . . . . . . . . . . . . 33

4.9 Transferts possibles dans l’architecture . . . . . . . . . . . . . . . . . 33

4.10 Micro-operations de calculs . . . . . . . . . . . . . . . . . . . . . . . 33

4.11 Micro-operations de conditions . . . . . . . . . . . . . . . . . . . . . 34

4.12 Cout des micro-operations . . . . . . . . . . . . . . . . . . . . . . . 34

4.13 Cout fixe du microcontroleur et de l’interpretation d’une micro-instruction

36

5.1 Architecture d’une matrice de 4 processeurs. . . . . . . . . . . . . . . 40

5.2 Canaux de communications inter-processeurs. . . . . . . . . . . . . . 41

5.3 Evolution des taux d’utilisation en fonction du nombre de processeurs. 42

5.4 Architecture data-flow. . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5 Grille de pixels a dilater. . . . . . . . . . . . . . . . . . . . . . . . . 44

5.6 Grille de pixels dilatee. . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.7 Dilatation par colonnes. . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.8 Dilatation par colonnes. . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1 Architecture du crossbar. . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2 evolution du taux d’occupation d’un crossbar en fonction de la taille de

ses canaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.3 exemple d’un crossbar 16 e/s pour un reseau de 4 processeur. . . . . . 52

6.4 exemple de crossbars dedies pour un reseau de 4 processeur. . . . . . 53

6.5 taux d’utilisation du FPGA en fonction des differentes methodes testees. 53

6.6 Matrice de cellules iWarp . . . . . . . . . . . . . . . . . . . . . . . . 54

6.7 Traitement des donnees par l’agent de communication . . . . . . . . . 56

6.8 Format logique d’un circuit virtuel . . . . . . . . . . . . . . . . . . . 56

6.9 Architecture du processeur de boot. . . . . . . . . . . . . . . . . . . 59

6.10 Communication du processeur de boot avec les processeurs du reseau. 60

vii

Page 9: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

TABLE DES FIGURES

6.11 Codage de l’instruction BOOT. . . . . . . . . . . . . . . . . . . . . . 60

6.12 Cout des instructions du processeur de Boot. . . . . . . . . . . . . . . 61

viii

Page 10: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Introduction

Le TER effectue en fin de Master 1 Informatique Logiciel doit nous permettre de

decouvrir et d’apprehender le fonctionnement de la recherche dans le domaine que

nous avons etudie.

Nous avons ete accueilli au sein du laboratoire Architectures et Systemes de l’UBO

pour une duree de 4 semaines.

L’objectif du projet etait de programmer sur une plateforme multimedia RC203 des

architectures paralleles programmables (de type reseau regulier ou matrice d’operateurs

par exemple), de les alimenter en donnees et de les tester a travers differentes applica-

tions.

1

Page 11: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Chapitre 1

Contexte et objectifs du projet

En liaison avec les activites du laboratoire LESTER, le developpement d’architec-

tures paralleles a partir de langages adaptes necessite des recherches sur les diverses

possibilites de modelisations. Avant d’explorer les differentes facons d’alimenter en

donnees une architecture dans le chapitre 2, cette partie s’interessera a la plateforme

RC203 ainsi qu’aux facilites de developpement : environnement et interfacage haut

niveau.

1.1 Recherches sur les possibilites de prototypage d’ar-

chitectures paralleles sur base d’un circuit logique

reconfigurable

A la constante evolution des applications vers des systemes miniaturises a hautes

performances, les systemes reconfigurables apportent une reelle reponse s’appuyant

sur le developpement d’architectures paralleles adaptees. Notre objectif etait d’explo-

rer differentes possibilites d’implementation d’architectures et d’etudier les moyens de

les alimenter en donnees. La plateforme materielle utilisee est une carte multimedia

Celoxica RC203e integrant un FPGA Xilinx Virtex II.

Ces travaux ont pour objectifs de faciliter une eventuelle modelisation objet apres

avoir degage les capacites materielles (occupation spatiale) liees a la modelisation

Handel-C d’architectures paralleles.

2

Page 12: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

1.2 Developpement sur la plateforme Celoxica RC203

1.2.1 Presentation et caracteristiques de la carte

La plateforme de developpement RC203 permet le developpement d’applications a

hauts degres de parallelisme. Elle s’articule autour d’un FPGA Xilinx Virtex II XVC2V-

3000-4FG672. Elle offre de nombreuses possibilites multimedia de part ses multiples

interfaces d’entrees et de sorties :

– Ecran tactile.

– Entree/sortie S-video.

– Chipset audio compatible AC97 : 2 Entrees/1 sortie.

– Module bluetooth.

– Port serie RS232.

– Port Parallele.

– Port Ethernet 10/100.

– Ports PS2 .

– Socket SmartMedia.

– Afficheur sept segments.

La carte dispose de deux bancs de RAM de 2 Mo chacun. Le port parallele et la socket

SmartMedia sont relies au FPGA. Un CPLD (Complex Programmable Logic Device)

configure le FPGA lors de la transmission d’un fichier bit (cf paragraphe) via le port

parallele. Il s’occupe egalement de la gestion de la SmartMedia(Lecture/Ecriture d’une

configuration). Au demarrage de la carte, le FPGA obtient sa configuration a partir de

la SmartMedia.

FIG. 1.1 – Architecture de la plateforme RC203E.

3

Page 13: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

1.2.2 Le FPGA Virtex-II XC2V3000.

La figure 1.3 represente une partie du FPGA. Il est principalement compose d’une

matrice de CLBs (Configurable Logic Blocks). Chaque bloc configurable (cf. figure

FIG. 1.2 – Structure d’un bloc logique configurable (CLB).

1.2) est compose de 4 elements identiques appeles slices et de deux buffers. Les slices

sont identiques et contiennent :

– Deux generateurs de fonctions (compose de LUTs a quatre entrees).

– Deux elements de memorisation (bascules D).

– Des portes logiques.

– Des multiplexeurs.

– Une chaıne de cascade horizontale (portes OR).

Les multiplexeurs permettent a chaque slice d’implementer des fonctions possedant

jusqu’a 8 entrees. Les quatre slices sont repartis en deux colonnes, chacune est traversee

par une chaine logique independante l’une de l’autre (CIN1/COUT1, CIN2/COUT2)

et par une chaıne commune de decalage.

Chaque bloc est connecte a une matrice de commutation pour acceder aux res-

sources de routage general.

Les IOBs (Input Output Blocks) sont programmables et peuvent prendre le com-

portement d’entree, de sortie ou encore bidirectionnel. Deux ou quatre IOB’s sont

connectes a une matrice de commutation pour acceder aux ressources de routage.

Les blocs memoires sont de 18kb assignables de 16k * 1bit a 512*36bits. Chaque

memoire possede deux ports synchrones et independants l’un de l’autre. A chaque bloc

memoire est associe un multiplieur 18*18 optimise pour des operations sur le bloc

memoire. Chaque multiplieur et bloc memoire est relie a quatre matrices de commuta-

tion pour acceder aux ressources de routage.

Les blocs DCM (Digital Clock Multiplexer) et le multiplexeur d’horloge global

fournissent des fonctionnalites d’horloges evoluees. Au total il y a 12 DCM sur l’en-

semble du FPGA.

4

Page 14: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

FIG. 1.3 – Architecture des Virtex-II.

La figure 1.4 indique les caracteristiques precises du Virtex-II XC2V3000, la taille

reelle de la matrice de CLB est de 64*56 soit 3584 elements.

FIG. 1.4 – Caracteristiques du XC2V3000.

1.2.3 Handel-C : Un langage adapte au developpement d’architec-tures materielles.

Handel-C est un langage reprenant en grande partie la syntaxe C. Il presente pour-

tant des particularites remarquables l’adaptant au developpement d’architectures mater-

ielles :

– Typage fort des variables : taille fixee au bit pres et donc minimisation des res-

sources occupees.

– Prise en compte du parallelisme.

– Existence de canaux de communications dont l’utilisation est la meme que pour

les langages derives des principes CSP1 (comme Occam).

– Notions de ram et de rom exploitant les memoires du FPGA.

1Communicating Sequential Processes

5

Page 15: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

– L’affectation d’une variable dure un cycle d’horloge.

Structure d’un programme : Des instructions permettent de differencier les compor-

tements paralleles des comportements sequentiels. A chaque programme correspondent

un ou plusieurs main(). Il faut associer une horloge a chaque main(). Ainsi on utilisera

plusieurs main() dans le cas ou le programme doit s’effectuer selon plusieurs horloges.

Declarations globales.

Definition de l’horloge

void main(void){

Declarations locales.

Corps du programme.

}

Gestion du parallelisme : Handel-C permet de produire du code bas niveau ayant

un comportement parallele reel. Chaque instruction se trouvant dans un bloc parallele

sera effectuee sans determin-isme. La declaration d’un bloc parallele se fait comme

suit :

par{

bloc d’instructions s’effectuant en parallele.

}

A l’inverse les instructions sequentielles se declarent :

seq{

bloc d’instructions sequentielles.

}

Fonctions et macros : Handel-C offre divers mecanismes de fonctions et de ma-

cros :

– Fonctions : analogue C.

– Tableaux de fonctions : permet d’executer une meme fonction en parallele.

– Fonctions internes : fonctions non-partagees, le code logique est genere a chaque

execution.

– Macros procedures : A chaque appel le composant materiel est genere. Les res-

sources materielles ne sont pas partagees, les macros peuvent donc s’executer en

parallele. Une macro peut prendre un ou plusieurs parametres. Les expressions

s’executent en un cycle d’horloge.

– Macros expressions : Il existe deux types de macro expressions, partagees (sha-

red) ou non. Une macro partagee n’est generee qu’une seule fois. Les expressions

peuvent etre recursives. L’operateur select laisse au compilateur le choix d’une

expression plutot qu’une autre en fonction de la largeur par exemple.

Dans l’exemple ci-dessous on code une multiplication de x par y de facon recursive

puis, afin d’eviter de generer le code a chaque appel, on utilise une expression partagee

(rapprochement d’un mecanisme client/serveur). Si la largeur de x est egale a 0 alors

6

Page 16: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

multiply(x,y) = 0. Sinon on calcule la somme de la multiplication du decalage a droite

de x et du decalage a gauche de y avec y si le LSB de x est egal a 1 et 0 sinon.

Exemple :

1 macro e xp r m u l t i p l y ( x , y ) = s e l e c t ( wid th ( x ) == 0 , 0 ,

m u l t i p l y ( x \\ 1 , y <<1) + ( x [ 0 ] == 1 ? y : 0 ) ) ;

3 s h a r e d ex p r mul t ( x , y ) = m u l t i p l y ( x , y ) ;

Un exemple d’architecture systolique a deux processeurs developpee en Handel-C

est fourni en annexe ??. Ce programme utilise la console dont le fonctionnement est

detaille dans le deuxieme chapitre.

Communication par canaux : Handel-C est un langage de programmation permet-

tant de gerer le parallelisme. Pour cela il s’appuie de meme que le langage Occam

sur la notion de canaux de communication. Chaque canal fonctionne en half-duplex et

possede une entree et une sortie.

L’acces au canaux se fait selon les primitives suivantes :

– canal ? Valeur : lecture du canal dans valeur.

– Canal ! Valeur : ecriture de la valeur dans le canal.

Un canal peut posseder une pile FIFO , on parle alors de communication sans synchro-

nisation. Si le canal ne dispose pas de FIFO, il y a une synchronisation par semaphores

de rendez-vous : un processus B ne pourra obtenir de valeur que lorsque le processus

A lui aura fourni via un canal C1. Un canal avec une fifo de taille 8 se declare comme

suit :

1 chan u n s i g n e d 32 c a n a l w i th { f i f o l e n g t h = 8}

Il est donc possible de developper des architectures asynchrones en Handel-c.

1.2.4 Acces au materiel : couche d’abstraction PAL et librairiePSL

La PAL2 est une couche d’abstraction fournissant l’API d’acces aux composants

materiels de la plateforme. Elle est disponible depuis la sortie de l’environnement DK3

(cf.1.2.5 page 8). L’interet de cette couche est d’ecrire un code identique alors que les

cartes sont differentes, l’application Handel-C peut alors etre portee sans difficulte sur

autre support que l’original. Avant d’utiliser les primitives PAL, il faut declarer l’usage

de la bibliotheque generale regroupant toutes les cartes supportees :

1 # i n c l u d e ” p a l m a s t e r . hch ”

Comme le fait apparaıtre la figure 1.5, la couche PAL etablit le lien avec la librairie

PSL3. Cette librairie fournit un ensemble de pilotes specifiques a la plateforme. Ceux-

ci permettent d’obtenir un niveau d’abstraction facilitant l’utilisation du materiel. Ty-

piquement une fonction PSL commencera dans notre cas par RC200.

2Platform Abstraction Layer3Platform Support Library

7

Page 17: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

FIG. 1.5 – Abstraction PAL.

1.2.5 Environnement de developpement DK4 de Celoxica

La suite DK design constitue l’environnement de developpement Handel-C. C’est

un outil de design ESL4, c’est a dire qu’il fait abstraction du bas niveau au profit du

developpement d’architectures et d’algorithmes. L’environnement dispose d’un mo-

dule de simulation.

DK4 offre des algorithmes d’optimisation adaptes a une implementation specifique.

L’environnement optimise egalement les algorithmes, ecrits dans une syntaxe proche

du langage C, de facon transparente au programmeur.

Le DK fait la correspondance entre la couche PAL et les librairies PSL. DK conver-

tit le code Handel-C en elements logique standards dans un fichier EDIF servant d’entree

au logiciel fourni par le constructeur du FPGA.

1.2.6 Generation des fichiers binaires de configurations : ISE deXilinx

L’ISE5 est un outil de design evolue produisant un fichier de configuration binaire

adapte a une carte specifique. Differents formats de plus ou moins haut niveau sont

acceptes en entree :

– HDL (VHDL, Verilog HDL, ABEL)

– EDIF

– NGC/NGO

– Fichiers de design schematiques.

– Machines a etats.

4Electronic System Level5Integrated Software Environment

8

Page 18: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 1. CONTEXTE ET OBJECTIFS DU PROJET

A partir des outils d’implementation integres, le placement et le routage est ef-

fectue et ecrit dans le fichier binaire .BIT. L’ISE fournit differents outils de conception

(floorplanner) et d’analyse (XPower,etc.)

9

Page 19: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Chapitre 2

Interfacage et alimentation endonnees d’architectures.

Avant de s’interesser aux architectures mises en oeuvres, ce chapitre presente les

differents moyens d’alimentation en donnees. Il presente les choix de codage d’un pro-

gramme et comment l’utiliser a travers une architecture. La consommation en surface

de la carte en fonction des differentes methodes conclura cette partie.

2.1 Les technologies utilisees.

2.1.1 Exploitation du code type assembleur

Dans les architectures developpees, un programme est constitue d’une suite d’ins-

tructions identifiees par un entier. Afin de simplifier l’interpretation par les processeurs,

un fichier de code contient deux zones : - Donnees : chaque ligne indique une valeur

d’entree du programme. - Programme : chaque ligne correspond a une instruction. Les

deux zones sont identifiees par les delimiteurs DATE et CODE.

La figure 2.1.1 code un programme et les donnees qui lui sont relatives. Un decodeur

(cf. figure 2.1) a ete cree pour exploiter le code initial dont la syntaxe est proche de

l’assembleur. Il produit un fichier plus facilement exploitable par l’architecture. Les

delimiteurs DATA et CODE sont traduits par le caractere « % » et chaque instruction

est remplacee par un entier interpretable par le processeur (l’operateur et l’operande

etant detectes par des operations binaires).

2.1.2 Lecture des donnees et du programme en memoire interne.

On dispose d’une architecture programmable. Le circuit configure est statique mais

capable d’interpreter une suite d’instructions. La complexite logique de l’architecture

est beaucoup plus elevee que si le comportement du programme etait directement

10

Page 20: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

FIG. 2.1 – Compilation d’un fichier type assembleur.

DATA

9

CODE

LOADI, 0

STORE, 0

LOADI, 1

STORE, 1

STORE, 3

INPUT, 0 //Chargement de la valeur d’entree, ici 9.

STORE, 2

LOAD, 1

ADD, 0

STORE, 0

ADD, 1

STORE, 1

LOAD, 2

SUB, 3

JUMPNZ, 6

LOAD, 1

OUTPUT, 0 //Sortie du resultat

HALT, 0

FIG. 2.2 – Calcul du 9e terme de la suite de Fibonacci

11

Page 21: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

implemente sur le FPGA. Elle permet a l’inverse, de reporter les difficultes de codage

du comportement sur le programme et non sur le FPGA.

L’interpretation du programme suppose l’existence d’un processeur. Le mode d’acces

le plus simple au programme et aux donnees, est de les stocker dans un registre lu

par le(s) processeur(s). L’utilisation de memoire au contenu fixe statiquemetn lors de

la configration limite evidemment les applications reelles de l’architecture. A chaque

modification du programme ou des donnees, il est alors necessaire de reconfigurer le

FPGA.

La lecture dans un registre statique a le merite de reduire la complexite du pro-

gramme Handel-C et donc le temps de generation du fichier EDIF (etape intermediaire

au placements et routages automatiques effectues par les outils de Xilinx). Suivant l’ar-

chitecture et surtout l’utilisation de la console, celui-ci est en effet eleve (meme si en

general le temps de placement et de routage dans l’ISE est plus important). Nous avons

utilise ce fonctionnement pour faciliter le developpement du processeur (cf. ??) et de

la matrice de processeurs (cf. ??).

2.1.3 Lecture du code sur la SmartMedia puis transfert vers lamemoire statique.

La plateforme RC203 dispose de plusieurs interfaces d’entrees/sorties (cf. ??). Il

est interessant de se rapprocher d’une architecture plus ouverte que la precedente a

travers l’exploitation de ces interfaces. Ainsi il est possible de recuperer un fichier,

contenant les donnees et le programme a executer, sur la carte SmartMedia.

– Utilisation de l’outil RC200CmdFTU fourni par Celoxica.

– Creation d’un programme exploitant les primitives C d’acces au port parallele.

Pour acceder a la carte SmartMedia, il est preferable d’utiliser l’adressage logique

a l’adressage physique. En effet l’adressage logique ignore les blocs reserves et ceux

defectueux, le bloc 0 sera donc toujours un bloc valide. Les differentes commandes

FTU2 sont decrites dans l’annexe C.

Des fonctions de haut niveau en Handel-C sont necessaires a l’initialisation de la

carte :

– RC200SmartMediaRun()

– RC200CPLDEnable()

– RC200SmartMediaInit()

Avant de pouvoir acceder a la carte SmartMedia, le programme doit donc contenir

le code de la figure 2.3. Les deux modes d’adressages (physique et logique) sont

differencies par deux macros :

– RC200SmartMediaSetLogicalAddress(WriteNotRead, Address)

Positionne l’adresse de lecture ou d’ecriture a l’adresse logique fournie en pa-

rametre. Le mode est defini par WriteNotRead (Si WriteNotRead = 1 alors ecriture

si WriteNotRead= 0 alors lecture).

– RC200SmartMediaSetAddress(WriteNotRead, Address)

Meme comportement pour une adresse physique.

12

Page 22: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

1 p a r {RC200SmartMediaRun ( ) ;

3 RC200CPLDRun ( ) ;

seq {5 RC200CPLDEnable ( ) ;

RC200Smar tMediaIn i t ( ) ;

7 }}

FIG. 2.3 – Code Handel-C : Initialisation de la SmartMedia.

Selon le type d’adresse positionnee, une macro d’ecriture ou de lecture peut ensuite

etre executee :

– RC200SmartMediaRead(DataPtr, LastData)

DataPtr est un unsigned 8 indiquant le registre ou stocker les donnees lues. Last-

Data indique la fin de la lecture quand il est egal a 1.

– RC200SmartMediaWrite(DataPtr, LastData)

Meme fonctionnement que pour la lecture. Attention cependant, une ecriture ef-

face au moins un bloc entier soit 512 pages de 512 octets et ce meme si un seul

octet est ecrit.

Une fois la lecture ou l’ecriture terminee l’operation doit etre validee par la macro

RC200SmartMediaOperationEnd(ResultPtr) . ResultPtr est un pointeur sur un registre

valant 1 en cas d’erreur et 0 sinon.

La lecture de la carte est lancee avant d’initialiser l’architecture. Une macro ecrit

dans un registre les valeurs de la SmartMedia en distinguant les donnees des instruc-

tions. En effet en terme de performance, il n’est pas interessant d’acceder directement

a la carte en raison du temps de reponse eleve. Le comportement est alors le meme que

dans le paragraphe 2.1.2. La lecture des donnees et du programme sur la SmartMedia a

ete realisee a titre experimental pour une matrice de quatre processeurs. Comme il sera

montre dans le paragraphe 2.2.2, ce mode d’acces est le plus gourmand en LUTs et en

bascules.

2.1.4 Lecture du code via le port parallele puis transfert vers lamemoire interne.

Il est possible d’exploiter le port parallele directement dans le circuit logique. Ce-

loxica propose en effet des primitives d’acces de haut niveau en Handel-C permettant

de lire des octets directement a partir du port. La lecture/ecriture Handel-C sur le port

parallele repose sur le schema de fonctionnement de la figure 2.4.

De meme que pour la lecture sur la SmartMedia, une macro distinguant les donnees

des instructions s’execute avant l’initialisation de l’architecture. Cette methode a ete

testee pour la matrice de quatre processeurs (cf. ??).

13

Page 23: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

macro e xp r P a r a l l e l P o r t = P a l R C 2 0 0 P a r a l l e l P o r t ;

2 vo id main ( vo id )

{4 u n s i g n e d c h a r c ;

p a r {6 P a l D a t a P o r t R u n ( P a r a l l e l P o r t , C lockRa te ) ;

Seq {8 P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ; /∗ L e c t u r e ∗ /

10 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , c ) ; /∗ E c r i t u r e ∗ /

}12 }

}

FIG. 2.4 – Code Handel-C : lecture et ecriture sur port parallele.

1 RC200PL1RAM0SetReadAddress ( Addr ) ;

RC200PL1RAM0Read(&tmp ) ;

3 RC200PL1RAM0SetWriteAddress ( Addr ) ;

RC200PL1RAM0Write ( tmp ) ;

FIG. 2.5 – Macros Handel-C de lecture et d’ecriture en RAM0.

2.1.5 Lecture du code via le port parallele, stockage et acces enRAM.

L’usage de la RAM a la place de la memoire interne permet d’envisager des archi-

tectures plus dynamiques (cette ressource etant externe au FPGA). Il est alors possible

de modifier le programme au cours de son execution dans l’architecture. Le fonction-

nement est sensiblement le meme que pour le cas precedent : le code est transfere via

le port parallele. Cependant au lieu de stocker les donnees et le programme dans un

registre, on utilise les primitives Handel-C d’acces a la RAM.

La carte dispose de deux memoires : RAM0 et RAM1. Avant de pouvoir utiliser

l’une d’elles, elle doit etre initialisee par la macro RC200PL1RAMxRun(ClockRate).

Ou x designe l’identifiant de la RAM. La lecture/ecriture se fait apres avoir positionne

l’adresse d’acces respective (cf fig 2.5) . Dans le cas d’une lecture, la reference a une

variable indique la destination de la lecture. Dans le cas d’une ecriture la valeur a ecrire

est fournie en parametre.

Ce mode d’acces a l’avantage de se rapprocher d’un fonctionnement plus applique.

Il a ete teste pour la matrice de quatre processeurs (cf. ??).

2.1.6 Programme dans en memoire interne, donnees en RAM.

Le ou les programmes sont fixes en statique alors que les donnees sont lues en

RAM. Le programme est directement execute, la phase d’initialisation de l’architecture

est donc plus courte. Pour changer le comportement il est alors necessaire de reconfi-

14

Page 24: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

gurer le FPGA. Cependant dans le cas d’une architecture selon le modele data-flow (cf.

??) ce type d’acces est a privilegier.

2.2 Comparaison des taux d’utilisation.

2.2.1 Conditions de mesures.

Afin de comparer les differences en termes de taux d’occupation du FPGA, nous

nous sommes interesse a une matrice de quatre processeurs (cf. ??). Chaque processeur

possede le meme programme et calcule un element de la suite de Fibonacci. Pour

chaque technique d’acces du 2.1, le taux d’utilisation total de LUTs et de bascules est

releve. Ces resultats sont obtenus a partir du rapport genere par l’environnement de

placement et de routage ISE1 .

2.2.2 Resultats observes.

Le graphique 2.6 indique le pourcentage de bascules D et de LUTs utilisees en

fonction des differents modes d’acces. Il y apparaıt clairement que l’utilisation de la

SmartMedia occupe plus de surface que les autres methodes.

Le FPGA constitue son comportement a partir d’un certain nombre de slices. La

figure 2.7 indique les differents taux d’utilisation des slices2. La lecture du code dans

la RAM ne s’eloigne pas trop de l’exploitation interne avec un taux de 16% contre

11%. De meme l’utilisation des LUTs se rapproche du codage interne (cf. fig2.8) avec

un taux de 13% contre 11% des LUTs.

FIG. 2.6 – Taux d’utilisation logique (sans tenir compte du cout de routage).

1Integrated Software Environment2cf. paragraphe 1.2.2

15

Page 25: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

FIG. 2.7 – Utilisation des slices.

FIG. 2.8 – Utilisation totale des LUT’s.

16

Page 26: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 2. INTERFACAGE ET ALIMENTATION EN DONNEES

D’ARCHITECTURES.

L’exploitation d’une ressource externe au FPGA permet de gagner une place no-

table. Sur tous les graphiques, le stockage en RAM(en violet) apporte un gain de qua-

siment 5% par rapport au stockage dans un registre (en orange).

17

Page 27: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Chapitre 3

Etude des performances

Ce chapitre expose les differentes methodes utilisees pour mesurer les performances

d’une architecture. Il est possible de determiner le nombre de cycles theorique en analy-

sant le code et a partir des documentations. Les performances pratiques sont mesurees

et confrontees aux resultats theoriques.

3.1 Methodologie theorique et remarques sur l’optimi-

sation du temps de cycle

3.1.1 Analyse du code

Une particularite Handel-C est de connaıtre exactement le nombre de cycles necessaires

aux differentes operations. Une affectation prends un cycle, les operations de calcul ont

un cout nul de meme que les conditions. Ainsi l’expression :

x = ( a + b ) <− c

Ne prendra q’un seul cycle. La complexite d’une expression se traduit par la mise en

oeuvre de fonctions logiques complexes sur le FPGA et donc plus exigeantes en termes

de surface.

Exemple : Multiplexeur d’affichage

1 w h i l e ( 1 ){p r i a l t {

3 c a s e p r i n t [ 0 ] ? v a l :

from = 0 ;

5 b r e a k ;

c a s e p r i n t [ 1 ] ? v a l :

7 from = 1 ;

b r e a k ;

9 c a s e p r i n t [ 2 ] ? v a l :

from = 2 ;

18

Page 28: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 3. ETUDE DES PERFORMANCES

11 b r e a k ;

c a s e p r i n t [ 3 ] ? v a l :

13 from = 1 0 ;

b r e a k ;

15 }}

Les operateurs « while » et « prialt » sont des operateurs de conditions et ne necessitent

aucun cycle. A chaque « case » il y a une lecture sur un canal qui prend un cycle. Il y

a ensuite une affectation qui necessite egalement un cycle, puis un « break » de cout

nul. Le cout total de ce multiplexeur d’entrees est donc de deux cycles.

3.1.2 Documentation PSL : performances d’acces aux ressourcesexternes au FPGA

La couche d’abstraction PAL s’adapte au type de carte utilisee alors que la couche

PSL est specifique. La documentation de cette couche fournit les informations sur les

latences liees aux acces aux differentes ressources mis a part pour la console et le port

parallele. En effet la console est en soi une abstraction PAL et le cout d’affichage varie

en fonction des caracteres affiches. Le cout d’acces au port parallele varie en fonction

de l’hote [?].

ACCES RAM PSL

Cout fixe : 0 cycle

– RC200PL1RAM0Run(ClockRate) = 0 ;

Cout variable (n acces) : n*2 cycles

– RC200PL1RAM0SetReadAddress = 1 cycle.

– RC200PL1RAM0Read(&dataRam) = 1 cycle.

ACCES PORT PARALLELE PSL

Cout fixe : 4 cycles

– RC200SendProtocolEnable() : 1 cycle.

– RC200SendProtocolDisable() : 1 cycle.

– RC200CPLDEnable : 2 cycles si le CPLD est disponible.

Cout variable (n acces) :

– RC200SendProtocolEnable() : depend de l’hote.

– RC200SendProtocolDisable() : depend de l’hote.

ACCES SMART MEDIA PSL

Cout fixe : 240 cycles RC200SmartMediaInit() : 240 cycles.

Cout variable (n acces) : minimum 330*n en lecture et 560*n en ecriture.

– RC200SmartMediaSetLogicalAddress : 170 cycles ou plus.

– RC200SmartMediaSetAddress : 170 cycles ou plus.

– RC200SmartMediaRead : 160 cycles ou plus.

– RC200SmartMediaWrite : 390 cycles ou plus.

FIG. 3.1 – Couts fixes et variables d’acces aux ressources externes de la carte RC203

19

Page 29: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 3. ETUDE DES PERFORMANCES

La figure 3.1 resume les latences liees aux differentes ressources. Il y apparaıt clai-

rement que l’utilisation de la smartMedia induit une latence tres importante.

3.1.3 Optimisation du temps de cycle

Attention cependant, le calcul d’expressions complexes peut gagner a etre decompose

[?]. Le nombre de cycles necessaires est plus eleve mais chaque cycle est plus court et

augmente la vitesse d’horloge globale possible du circuit.

Exemple :

( 1 ) X = a + b + c + d + e + f + g + h

Peut s’exprimer ainsi :

1 p a r {T1 = a + b ;

3 T2 = c + d ;

T3 = e + f ;

5 T4 = g + h ;

}7 p a r {

t 1 = t 1 + t 2 ;

9 t 3 = t 3 + t 4 ;

}11 x = t 1 + t 3 ;

A fonctionnalites egales, le nombre de cycles necessaires ici est de 3 contre 1 pour

l’expression (1). La frequence de fonctionnement d’un circuit correspond a l’inverse

de la periode du chemin le plus long sur le circuit. Des cycles plus courts permettent

de reduire cette periode et donc d’augmenter la frequence du circuit. Dans le cas de

frequences limites, la deuxieme methode de calcul peut avoir un impact global et eviter

de freiner la frequence de fonctionnement.

Remarque : Dans les architectures implementees, la frequence de fonctionnement

est fixee a 25,175 MHz pour permettre l’affichage sur la console. Il est donc peu pro-

bable de ralentir la frequence de fonctionnement en dessous de la frequence fixee.

Cependant dans l’optique d’une utilisation a frequence optimale, il faut surveiller la

periode du chemin logique maximal(dans le rapport Xilinx) et optimiser le code en

consequence.

3.2 Mesure du nombre de cycles

Pour determiner les couts inconnus et valider la methodologie theorique, une procedure

de mesure permet de connaıtre le nombre de cycles ecoules entre deux etapes. Elle

consiste a lancer un compteur en parallele avec le programme a executer. Le compteur

est incremente a chaque cycle jusqu’a ce qu’une variable partagee passe a 0 une fois le

programme acheve (cf. figure 3.3).

20

Page 30: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 3. ETUDE DES PERFORMANCES

1 vo id main ( vo id )

{3 . . .

u n s i g n e d i n t 1 c o n d i t i o n ;

5 c o n d i t i o n = 1 ;

p a r {7 seq {

/∗ e x e c u t i o n du programme ∗ /

9 p r o c e s s o r ( canaux [ 0 ] , canaux [ 1 ] , canaux [ 2 ] , canaux [ 3 ] ,

i n p u t [ 0 ] , o u t p u t [ 0 ] , i n i t [ 0 ] , p r i n t [ 0 ] , program0 , 0 ) ;

11 c o n d i t i o n =0;

}13 seq {

/∗ compte l e nombre de c y c l e s j u s q u ’ a que c o n d i t i o n =0 ∗ /

15 compteur ( i , c o n d i t i o n ) ;

/∗ a f f i c h a g e du compteur de c y c l e s ∗ /

17 p r i n t [ 3 ] ! ( i −1)<−32;

p r i n t [ 3 ] ! ( i >>32)<−32;

19 }}

21 }s t a t i c macro p ro c compteur ( i , c o n d i t i o n ){

23 w h i l e ( c o n d i t i o n ) i ++;

}

FIG. 3.2 – Mesure du nombre de cycles

Cette procedure permet de determiner le cout d’acces a la console en fonction des

caracteres affiches :

CONSOLE

Cout fixe : 2 cycles

– PalConsoleEnable() : 2 cycles.

Cout variable :

– PalConsolePutUInt() : 31 + (chiffre1+1) + (chiffre2+1) + ... + (chiffren+1)

– PalConsolePutChar() : 2

– PalConsolePutString() : 5*nbchar

3.3 Mesure de la frequence de fonctionnement du FPGA

Il est interessant de verifier que la frequence de fonctionnement reelle est en adequation

avec la configuration de l’horloge decrite en Handel-C. Pour cela un programme C sert

de compteur temps reel. Ce programme va comptabiliser le nombre de ticks entre le

moment ou l’architecture est operationnelle et l’instant ou le programme situe sur l’ar-

chitecture est acheve.

Le nombre de cycles N est affiche sur la console de la carte. A partir du nombre

de ticks et de la frequence du processeur hote, la periode T est affichee en micro-

21

Page 31: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 3. ETUDE DES PERFORMANCES

/ / A r c h i t e c t u r e o p e r a t i o n e l l e

2 RC200SendBlock (& c t l , &block , 0x01 , &p r o g r e s s ) ;

/ / T ick de d e p a r t

4 QueryPe r fo rmanceCoun te r (& bt ime ) ;

/ / A t t e n t e de f i n du programme de l ’ a r c h i t e c t u r e

6 w h i l e ( ! RC200GetBlock(& c t l , b lock1 , 0x01 , &p r o g r e s s )

&& ( b l o c k 1 [ 0 ] != 8) )

8 QueryPe r fo rmanceCoun te r (& e t i m e ) ;

/ / Nombre de t i c k s d ’ e x e c u t i o n

10 e t i m e . QuadPar t −= bt ime . QuadPar t ;

/ / A f f i c h a g e du temps en m i c r o s e c

12 t p r i n t f ( T ( ” Temps de t r a i t e m e n t . . . %I 64 dus . . . \ n ” ) ,

(1000000 ∗ e t i m e . QuadPar t ) / f r e q . QuadPar t ) ;

FIG. 3.3 – Mesure de la frequence

secondes sur la machine hote. Le rapport entre le nombre de cycles et la periode donne

la frequence :

F = N/T

Les frequences obtenues apres plusieurs essais correspondent quasiment a celle

definie pour l’horloge. L’imprecision provient des delais de propagation du port pa-

rallele variants selon l’hote. Par exemple :

N = 7000216cycles, T = 278058µs

F = 25, 176105Mhz

Remarque : le programme necessite un nombre important de cycles pour avoir un

resultat fiable et exploitable. Plus le nombre de cycles est important plus l’imprecision

devient negligeable.

22

Page 32: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Chapitre 4

Processeur programmable

4.1 Processeur

Nous avons developpe une architecture programmable qui modelise un processeur

qui permet d’executer un programme de type assembleur. Cette architecture est basee

sur l’exemple fourni avec le logiciel DK Design de Celoxica ref Celoxica/DK/Examples/Handel-

C/Example5.

4.1.1 Architecture du processeur

Le processeur est compose d’une unite de commande,d’une RAM, d’un accumula-

teur et d’une UC (cf. figure 4.1).

L’UAL (Unite Arithmetique Logique) permet d’effectuer des operations addition

ou soustraction sur deux operandes l’une etant situee dans l’accumulateur, l’autre sur

la RAM ou dans les LSBs du registre d’instruction IR. L’unite de commande est com-

posee d’un compteur d’instruction PC (Program Counter), d’un registre IR (Instruction

Register) et d’un sequenceur.

Le compteur d’instruction PC code sur 5 bits pointe vers la prochaine instruction a

executer. Chaque instruction traitee est stockee dans le registre IR de 9 bits. Les 4 bits

de poids faibles sont reserves a l’operateur et les 5 bits de poids forts a l’operande. Le

sequenceur interprete l’instruction presente dans le registre IR.L’accumulateur est un

registre de 32 bits stockant temporairement l’etat d’une variable. Il peut egalement lire

et ecrire une valeur dans la RAM de 32*32bits. Deux canaux input et ouput interfacent

le processeur.

23

Page 33: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

FIG. 4.1 – Architecture du processeur.

4.1.2 Jeu d’instructions

Les instructions qui permettent d’utiliser le processeur sont codees selon le format

suivant : OPERATEUR,Operande

Les operateurs disponibles sont :

– LOAD Chargement dans l’accumulateur d’une valeur de la RAM a l’adresse

indiquee par l’operande.

– LOADI Chargement dans l’accumulateur de la valeur indiquee par l’operande.

– STORE Enregistre la valeur de l’accumulateur dans la RAM a l’adresse indiquee

par l’operande.

– ADD Ajoute la valeur presente dans la RAM a l’adresse indiquee par l’operande

a la valeur presente dans l’accumulateur.

– SUB Soustrait la valeur presente dans la RAM a l’adresse indiquee par l’operande

a la valeur presente dans l’accumulateur.

– JUMP Saut inconditionnel vers une autre instruction (position dans la ROM).

– JUMPNZ Saut si la valeur de l’accumulateur est differente de zero.

– INPUT Lit et affEx : 9e element =¿ 181 cycles ecte dans l’accumulateur la valeur

presente dans le canal input.

– OUTPUT Envoie la valeur de l’accumulateur dans le canal output.

– ADDI Ajoute la valeur de l’operande a la valeur presente dans l’accumulateur.

– SUBI Soustrait la valeur de l’operande a celle presente dans l’accumulateur.

– HALT Fin du programme.

– MUL Multiplication de l’accumulateur avec l’operande.

24

Page 34: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

4.1.3 Fonctionnement du processeur

Le decodage de chaque instruction presente dans le registre d’instruction IR se fait

a l’aide de deux macro expressions.

1 macro e xp r opcode = ( i r <− OPCW) ;

La macro opcode permet de recuperer les 4 bits de poids faibles qui codent l’operateur.

1 macro e xp r ope rand = ( i r \\ OPCW) ;

La macro operand permet de recuperer les 5 bits de poids forts qui codent l’operande.

Le sequenceur qui interprete l’instruction est modelise par un switch / case. Il lit le

code de l’operateur present dans le registre IR puis il traite le cas adapte.

1 s w i t c h ( opcode )

{3 c a s e HALT : b r e a k ;

c a s e LOAD : x = d a t a [ ope rand <− RAM AW] ; b r e a k ;

5 c a s e LOADI : x = 0 @ operand ; b r e a k ;

c a s e STORE : d a t a [ ope rand <− RAM AW] = x ; b r e a k ;

7 c a s e ADD : x += d a t a [ ope rand <− RAM AW] ; b r e a k ;

c a s e SUB : x −= d a t a [ ope rand <− RAM AW] ; b r e a k ;

9 c a s e JUMP : pc = ope rand <− ROM AW; b r e a k ;

c a s e JUMPNZ : i f ( x != 0) pc = ope rand <− ROM AW;

11 b r e a k ;

c a s e INPUT : i n p u t ? x ; b r e a k ;

13 c a s e OUTPUT : o u t p u t ! x ; b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ;

15 }

L’accumulateur est represente par la variable x. La RAM correspond a la variable data.

L’acces a un element de la memoire se fait de la meme facon que pour un tableau.

4.1.4 Couts des instructions

Le cout fixe d’une instruction correspond a sa lecture dans la memoire de pro-

gramme et a l’incrementation du compteur en parallele. La valeur correspondante est

de un cycle auquel s’ajoute la latence specifique a chaque comportement :

– HALT : 1 cycle.

– LOAD : 1 cycles.

– LOADI : 1 cycles.

– STORE : 1 cycles.

– ADD : 1 cycles.

– SUB : 1 cycles.

– ADDI 1 cycles.

– SUBI : 1 cycles.

– JUMP : 1 cycles.

– JUMPNZ : 1 cycles

25

Page 35: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

– JUMPR : 1 cycles

– INPUT : 1 cycles

– OUTPUT : 1 cycles

– MUL : 4 + LargeurOperande cycles

4.1.5 Exemple de programme : suite de Fibonacci

Cette partie presente un exemple de programme validant le fonctionnement du pro-

cesseur.

Definition :

La suite f est definie par : f1=f2=1.

de plus pour tout n ≥1 on a : fn+2 = fn+1 + fn

Calcul du 9e element de la suite de Fibonacci. Nombre de cycles theorique : 6*2 +

9*2n. Ex : 9e element =>174 cycles

LOADI, 0

STORE, 0

LOADI, 1

STORE, 1

STORE, 3

LOADI, 9

STORE, 2

LOAD, 1

ADD, 0

STORE, 0

ADD, 1

STORE, 1

LOAD, 2

SUB, 3

JUMPNZ, 6

LOAD, 1

HALT, 0

4.2 Architecture s’appuyant sur la micro-programmation

Une machine basee sur les micro-instructions s’appuie sur des instructions de semantiques

fortes referencant differentes instructions simples. Un mecanisme de controle permet

de passer d’un niveau d’interpretation plus eleve a celui des micro-instructions. L’en-

semble des micro-instructions liees a une instruction complete est appele micropro-

gramme ou microcode. Les interets sont multiples :

– Reduction de la taille d’un programme.

– Specification des processeurs.

26

Page 36: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

– Adaptabilite d’un programme. Il suffit de modifier le microcode pour fonctionner

avec une architecture materielle differente.

– Facilite d’extension du jeu d’instruction.

FIG. 4.2 – Codage d’une micro-instruction horizontale.

La micro-programmation peut etre horizontale ou verticale. Dans le cas d’un micro-

programmation horizontale (cf. figure 4.2), chaque bit de l’instruction correspond a

une operation a effectuer. Une partie de la micro-instruction est reservee a l’adresse

de la prochaine a effectuer. Cette adresse sera utilisee en fonction d’un bit de branche-

ment conditionnel. Le principal avantage d’une telle instruction est l’acces simultane

a plusieurs ressources. Cependant la taille d’une micro-instruction horizontale est pro-

portionnelle a la complexite de l’architecture et la complexite d’implementation est

elevee.Dans le cas d’un acces a une seule ressource, on parle de micro-programmation

verticale.

Une unite de controle est chargee de trouver les micro-instructions d’une instruc-

tion dans une memoire specifique. Une micro-instruction peut contenir l’adresse d’une

eventuelle autre micro-instruction a executer conditionnellement constituant alors des

sous-microcodes.

4.2.1 Architecture du processeur et format logique des instructions

La complexite de l’architecture etant reporte sur le micro-controleur, celle du pro-

cesseur est simple. Le processeur se contente de lire l’instruction dans son programme

a l’adresse correspondant au compteur d’instruction PC. Cette instruction est stockee

dans le registre 32bits IR. Une instruction est construite selon le format de la figure 4.3.

FIG. 4.3 – Format d’une instruction principale

L’operateur est code sur 8bits et les operandes sur 12bits. Chaque instruction est

transmise au micro-controleur qui modifie en consequence l’etat de l’accumulateur, de

la RAM interne au processeur et de la RAM externe.

27

Page 37: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

Une fois que micro-controleur a acheve le traitement d’une instruction, le compteur

de programme est incremente et la prochaine instruction est chargee.

FIG. 4.4 – Architecture du processeur microprogramme

Dans l’optique d’optimiser l’acces a la RAM du processeur, deux ports independants

sont utilises. Pour cela il faut declarer une memoire multiports en Handel-C. Chaque

port permet d’acceder a la RAM en lecture seule, ecriture seule ou lecture/ecriture. Il a

ete choisi d’avoir deux ports lecture/ecriture pour permettre d’obtenir ou d’ecrire deux

valeurs en un seul cycle.

Structure de la memoire multi-port :

1 mpram Ram1 {ram <u n s i g n e d DW> p1 [1 << RAM AW] ;

3 ram <u n s i g n e d DW> p2 [1 << RAM AW] ;

} ;

Declaration de la RAM du processeur :

mpram Ram1 d a t a wi th { b l o c k = ”BlockRAM” } ;

L’option block = ”BlockRAM” precise que la memoire a utiliser se situe sur les

blocs RAM interne au FPGA. L’acces a un element de la memoire necessite alors de

preciser le port. Dans l’exemple suivant, une valeur est ecrite dans la RAM et une autre

est lue en un seul cycle.

1 p a r {d a t a . p1 [ p o s i t i o n E c r i t u r e ] = r e g i s t r e 1 ;

3 r e g i s t r e 2 = d a t a . p2 [ p o s i t i o n L e c t u r e ] ;

}

La communication de l’instruction courante au micro-controleur passe par un canal.

Ainsi le processeur sera bloque tant que le micro-controleur n’aura pas demande a lire

une autre instruction.

seq {

28

Page 38: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

2 / / i n i t i a l i s a t i o n

p a r {4 pc = 0 ; end = 0 ;

m i c r o C o n t r o l e u r ( canaux , microMem , da ta , pc , acc , end ) ;

6 }/ / Boucle du p r o c e s s e u r

8 do{/ / Recherche de l ’ i n s t r u c t i o n a e x e c u t e r

10 i r = program [ pc ] <−(OPCW + 2∗OPRW) ;

/ / t r a n s m i s s i o n de l ’ i n s t r u c t i o n au micro−c o n t r o l e u r

12 m i c r o C o n t r o l e u r I n ! I r ;

w h i l e ( ! newIns t rOk ) d e l a y ;

14 } w h i l e ( ! end ) ;

}

C’est le micro-controleur qui incremente le compteur d’instruction du processeur. Tant

que le micro-controleur n’a pas acheve le traitement d’une instruction, le processeur

reste bloque. Ce fonctionnement est necessaire dans le cas d’instruction de saut. En

effet quand le micro-controleur recoit l’instruction, il consomme le canal et debloque

le processeur. Celui-ci lit alors une instruction incoherente.

Pour contourner le probleme, une variable (newInstrOk) est mise a 0 par le proces-

seur. Une fois le canal consomme, le processeur reste bloque tant que la variable vaut

O. Il sera libere par le micro-controleur au chargement d’une nouvelle instruction :

newInstrOK = 1.

4.2.2 Le microcontroleur

Le micro-controleur (figure 4.5) est constitue de :

– Une memoire de controle (CM1) contenant les micro-instructions : 255 * 34bits.

– Une RAM multiports(LM2) contenant les registres propre au micro-controleur :

16*32bits.

– Un registre MIC3 indiquant la prochaine micro-instruction a executer : 16bits.

– Un registre MIR4 contenant la micro-instruction en cours d’execution : 34bits.

– Une UAL connectee aux registres locaux et sortant sur l’accumulateur.

– opP1 :registre contenant l’operande1 principale ( celle de la macro-instruction).

– opP2 : registre contenant l’operande2 principale.

– opL1 : registre contenant l’operande1 de l’operation locale.

– opL2 : registre contenant l’operande2 de l’operation locale.

Le jeu de micro-instructions fournit les primitives de chargement et de sauvegarde

dans la memoire locale LM mais egalement celles permettant d’acceder a la memoire

principale du processeur. L’accumulateur du processeur est lie a la memoire principale

et au micro-controleur. Les operandes principales sont recues a chaque nouvelle ins-

truction. De meme que la RAM du processeur, la memoire locale possede deux ports

d’acces independants.

1Control Memory2Local Memory3Micro Instruction Counter4Micro Instruction Register

29

Page 39: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

FIG. 4.5 – Architecture du microcontroleur

1

/∗3 ∗ A r c h i t e c t u r e du micro−c o n t r o l e u r

∗ /

5 u n s i g n e d i n t MIC AW mic ; /∗ compteur de micro i n s t r u c t i o n s ∗ /

u n s i g n e d i n t MIR AW mir ; /∗ r e g i s t r e de micro i n s t r u c t i o n s ∗ /

7 u n s i g n e d i n t DW opL1 ; /∗ op e r ande1 l o c a l e ∗ /

u n s i g n e d i n t DW opL2 ; /∗ op e r ande2 l o c a l e ∗ /

9 u n s i g n e d i n t OPRW opP1 ; /∗ op e r ande1 p r i n c i p a l e ∗ /

u n s i g n e d i n t OPRW opP2 ; /∗ op e r ande2 p r i n c i p a l e ∗ /

11 mpram Ram2 {ram <u n s i g n e d DW> p1 [1 << MICRO LOCALMEM AW ] ;

13 ram <u n s i g n e d DW> p2 [1 << MICRO LOCALMEM AW ] ;

} ;

15 mpram Ram2 d a t a wi th { b l o c k = ”BlockRAM” } ; /∗RAM du m i c r o c o n t r o l e u r ∗ /

La reception d’un instruction se fait par canal.

1 / / R e c e p t i o n d ’ une i n s t r u c t i o n

p a r {3 i n p u t ? i n s t r u c t i o n ;

end = 0 ;

5 }

Les operandes et l’operateur sont recuperes via des macros expressions, les operandes

sont affectees aux registres en parallele. Un seul cycle est donc necessaire a l’initiali-

sation des registres a partir de l’instruction.

/∗2 ∗ Macros d ’ e x t r a c t i o n de l ’ o p e r a t e u r e t des l ’ o p e r a n d e de l ’ i n s t r u c t i o n

30

Page 40: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

∗ /

4 macro e xp r opcode = ( i n s t r u c t i o n \\ (OPRW+OPRW) ) ;

macro e xp r ope rand2 = ( i n s t r u c t i o n <− OPRW) ;

6 macro e xp r ope rand1 = ( i n s t r u c t i o n >> OPRW)<−OPRW;

/ / Decodage de l a micro− i n s t r u c t i o n

8 macro e xp r t y p e = mir \\ (MICROI AW − 1)<−1;

macro e xp r a c t i o n = ( mir \\ (MICROI AW − 3))<−2;

10 macro e xp r cond = ( mir \\ (MICROI AW − 4))<−1;

macro e xp r m i c r o I n s t r = mir<−(MICROI AW − 4 ) ;

L’operateur est place dans le mic (etape 1 de la figure 4.6). La micro-instruction se

situant a la ligne indiquee par le mic est ensuite lue dans le mir (etape 2) avant d’etre

interpretee (etape 3). Les premieres lignes de la memoire de controle constituent un

index des premieres micro-instructions de chaque operateur.

FIG. 4.6 – Mecanisme de controle des microinstructions

4.3 Micro-instructions

4.3.1 Types de micro-instructions

On distingue deux types de micro-instructions :

Type 1 : le MSB est a 1. Les bits de 0 jusqu’au nombre de points de controles

designent chacun un point de controle (cf. 2.1). Tous les points de controles dont

le bit est a 1 sont active dans le microcycle.

Type 2 : le MSB est a 0. Precise la facon dont la MIC va etre modifiee. Les quatre

MSB ont un role particulier.

Suivant les valeurs de ABC le traitement du MIC sera different. A, B sont princi-

palement utilises dans les micro-instructions de type 2 :

– 00 : chargement d’une nouvelle instruction. IRk vers MIC, lecture des operandes.

31

Page 41: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

FIG. 4.7 – Format logique d’une micro-instruction

– 01 : incrementation de la MIC.

– 10 : saut conditionnel, si C est a 1 ou que l’accumulateur > 0 alors MIRn vers

MIC.

– 11 : saut inconditionnel MIRn vers MIC.

Les instructions de type 1 ont toujours le meme comportement, application des points

de controles puis incrementation du MIC. Il existe cependant des cas particuliers pour

les instructions de type 1 :

– saut dans le programme principal : utilisation du bit C pour differencier les sauts

conditionnels des inconditionnels.

– transmission ou reception sur un canal specifique : utilisation de A,B et C pour

identifier le canal a utiliser.

4.3.2 Exploitation des micro-operations

Une micro-instruction specifie un ensemble de micro-operations. Chacune corres-

pond a une operation dans la memoire locale LM, la memoire principale MM ou les

registres d’operandes. Elles peuvent etre de trois types : micro-operations de transfert,

micro-operations de fonctions, ou micro-operations de controle.

Une micro-operation de transfert amene simplement le contenu d’une source vers

une destination (operation d’affectation). Une micro-operation de fonction active une

unite operationnelle dont les arguments dependent d’une liste de ressources. Une fois

l’operation effectuee, le resultat est stocke dans un element destination. Une micro-

operation de controle selectionne une action parmi d’autres en fonction d’une condition

definie sur les ressources de la machine.

Les micro-operations de transfert du tableau 4.8 definissent les affectations entre

les registres et l’accumulateur du processeur. Elles expriment egalement le lien entre

les E/S de l’architecture et l’accumulateur (cf. figure4.9)

Les micro-operations de calcul (tab 4.10) permettent d’effectuer des operations

arith-metiques et logiques et de stocker le resultat dans l’accumulateur.

Les micro-operations de condition (tab 4.11) permettent d’effectuer un saut condi-

tionnel. Dans le cas d’un saut global le compteur d’instruction du processeur est mo-

difie si l’accumulateur est strictement superieur a 0.

Une micro-instruction est composee de l’ensemble de ces points de controles aux-

quels s’ajoutent les quatre bits de controle. Elle est donc codee sur 34bits. Le tableau

4.12 precise le cout de chaque micro-operation.

32

Page 42: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

N˚ Micro-operation N˚ Micro-operation

1 Acc = opP1 12 OpL2 = LM(opL2)

2 Acc = opP2 13 OpL2 = opP2

3 Acc = opL1 14 OpL1 = opP1

4 Acc = opL1 15 Canal[opL1] ! acc

5 opL1 = acc 16 Canal[opL1] ? acc

6 opL2 = acc 17 OpL1 = MM(opL1)

7 MM(opL1) = acc 18 OpL2 = MM(opL2)

8 MM(opL2) = acc 19 RamExt@opL1= acc

9 LM(opL1) = acc 20 Acc = RamExt@opL1

10 LM(opL2)= acc 21 OpL1 = opP2

11 OpL1 = LM(opL1) 22 OpL2 = opP1

FIG. 4.8 – Micro-operations de transferts

FIG. 4.9 – Transferts possibles dans l’architecture

N˚ Micro-operation

1 Acc = LM(opL1) + LM(opL2)

2 Acc = LM(opL1) * LM(opL2)

3 Acc = LM(opL1) - LM(opL2)

4 Acc = LM(opL1) <<LM (opL2)

5 Acc = LM(opL1) >>LM(opL2)

FIG. 4.10 – Micro-operations de calculs

33

Page 43: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

N˚ Micro-operation N˚ Micro-operation

1 opL1 > opL2 => acc = 1 sinon acc = 0 2 acc > 0 => pc = opL1

FIG. 4.11 – Micro-operations de conditions

Points de controles cycles

0 Acc = opP1 11 Acc = opP2 12 Acc = opL1 13 Acc = opL2 14 opL1 = acc 15 opL2 = acc 16 MM(opL1) = acc 17 MM(opL2) = acc 18 LM(opL1) = acc 19 LM(opL2)= acc 1

10 OpL1 = LM(opL1) 111 OpL2 = LM(opL2) 112 OpL2 = opP2 113 OpL1 = opP1 114 Canal[opL1] ! acc 115 Canal[opL1] ? acc 116 OpL1 = MM(opL1) 117 OpL2 = MM(opL2) 118 RamExt@opL1= acc 219 Acc = RamExt@opL1 320 Acc = opL1 + opL2 121 Acc = opL1 * opL2 3622 Acc = opL1 - opL2 123 Acc = opL1 << opL2 124 Acc = opL1 >> opL2 125 acc > 0 => pc = opL1 1 ou 026 opL1=opP2 127 opL2=opP1 128 opL1 > opL2 => acc = 1sinon acc = 0 129 TODIR 5

FIG. 4.12 – Cout des micro-operations

34

Page 44: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

4.3.3 Traitement d’une micro-instruction

Le micro-controleur est une boucle se terminant lorsque l’operateur HALT est lu.

A chaque etape, le MIR lit le contenu de la memoire de controle a l’adresse specifiee

par le MIC. Le comportement differe selon le type de micro-instruction (cf. p31).

w h i l e ( ! end ){2 / / L e c t u r e de l a micro− i n s t r u c t i o n s e l o n l a mic

mir = microMem [ mic<−MICROM AW] ;

4 / / Comportement de l a micro− i n s t r u c t i o n

i f ( t y p e == 1){6 / / A p p l i c a t i o n des p o i n t s de c o n t r o l e

p a r ( i =0 ; i < MICROI AW − 4 ; i = i +1){8 i f ( ( m i c r o I n s t r >>i )<−1){

s w i t c h ( i ){10 c a s e 0 :

acc = 0@opP1 ;

12 b r e a k ;

c a s e 1 :

14 acc = 0@opP2 ;

b r e a k ;

16 c a s e 2 :

acc = opL1 ;

18 b r e a k ;

/ / . . .

20

d e f a u l t : w h i l e ( 1 ) d e l a y ;

22 }}

24

}26 mic = mic + 1 ;

}28 e l s e i f ( t y p e == 0){ / / M o d i f i c a t i o n de l a mic

s w i t c h ( a c t i o n ){30 c a s e 0 : / / N o u v e l l e i n s t r u c t i o n : i f e t c h

pc = pc +1;

32 p a r {newInstrOK = 1 ; / / L i b e r a t i o n p r o c e s s e u r

34 i n p u t ? i n s t r u c t i o n ;

}36 p a r {

opP1 = operand1 ;

38 opP2 = operand2 ;

opL1 = 0 ;

40 opL2 = 0 ;

seq {42 i f ( opcode != HALT) mic = 0@opcode ;

e l s e {44 p a r {

end = 1 ; / / f i n pgr

46 acc = 0 ;

}48 }

35

Page 45: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

}50 }

b r e a k ;

52 c a s e 1 : / / I n c r e m e n t a t i o n de l a mic

mic = mic + 1 ; b r e a k ;

54 c a s e 2 : / / Sa u t c o n d i t i o n n e l

i f ( ( cond )&&( acc >0)){56 mic = ( m i c r o I n s t r )<−MIC AW;

}58 b r e a k ;

c a s e 3 : / / Sa u t i n c o n d i t i o n n e l

60 mic = ( m i c r o I n s t r )<−MIC AW; b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ;

62 }}

64 }newInstrOK = 1 ; / / L i b e r a t i o n du p r o c e s s e u r

66 }

Le cout fixe d’interpretation d’une micro-instruction depend de son type (cf. tab

4.13)

Cout fixe d’une micro-instruction

mir = microMem[mic] ; 1

et mic = mic + 1 ; 1

Type 1 2mir = microMem[mic] ; 1

et cas0 3

ou cas1 1

ou cas2 1 ou 0

ou cas3 1

Type 2 1< cycles < 4

Cout fixe du micro-controleur 3

FIG. 4.13 – Cout fixe du microcontroleur et de l’interpretation d’une micro-instruction

36

Page 46: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

4.4 Jeu d’instruction du processeur microprogramme

Operateur op1 op2 Commentaires nbCyclesRegistres

LDL R1 load local R1 13

LDC val load constant 7

STL R1 sauvegarde acc dans R1 10

UAL

ADD R1 R2 acc = R1 + R2 13

ADC val acc=acc + val 10

ADCR val R1 acc=R1+val 19

SUB R1 R2 acc = R1-R2 13

SUBC val acc=acc-val 10

SUBCR val R1 acc=R1-val 19

MUL R1 R2 acc=R1*R2 42

MULC val acc=acc*val 39

MULCR val R1 acc=R1*val 48

LSL val acc = acc << val 10

LSLR R1 acc = acc << R1 19

LSLCR R1 val acc = R1 << val 19

LSRR R1 acc = acc >> R1 19

LSRCR R1 val acc = R1 >> val 19

LSR val acc = acc >> val 10

Saut

JUMPR R1 pc =R1 10

JUMP val pc = val 13

JUMPNZ val acc > 0 => pc = val 10

Condition

GT R1 R2 R1 > R2 => acc = 0 13

GTC val acc > val => acc = 0 10

EQC val R1 R1 == val => acc = 0 10

EQ R1 R2 R1 == val => acc = 0 13

E/S

INPUT val input[val] ? Acc 10

OUTPUT val output[val] ! Acc 10

WRITERAM R1 ram@R1 = acc 11

READRAM R1 acc = ram@R1 12

Divers

GET val R1 Input[val] + store R1 13

COPY R1 R2 R1 vers R2 28

TONORTH north ! acc et south ? acc 9

TOWEST 9

TOSOUTH 9

TOWEST 9

Le microcode correspondant est fourni en annexe I. D’autre part un fichier excel5

facilite la creation de microcode.

5Le fichier JeuMicroInstr.xls se situe dans le repertoire microprogrammation du CD lie a ce rapport

37

Page 47: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 4. PROCESSEUR PROGRAMMABLE

4.5 Specialisation des processeurs

La surface d’un processeur micro programme occupe 17% de la surface disponible,

ce qui set une surface relativement elevee par rapport aux resultats precedents. Cette

mesure a ete effectuee avec l’affichage sur la console du contenu de l’accumulateur

a chaque fin d’instruction. Cette sortie est utile pour verifier le bon fonctionnement

du processeur mais egalement pour eviter que l’optimisation de DK 4 simplifie trop

l’architecture. En effet si les resultats ne sont pas consommes, l’environnement d’opti-

misation juge la majeure partie de l’architecture inutile et simplifie en consequence.

Apres plusieurs tentatives de specialisation du microcontroleur, il s’est avere que la

suppression des points de controles relatifs aux operations sur la RAM externe divisait

par trois la surface occupee. Dans une architecture les processeurs necessitant un acces

a la RAM externe sont generalement peu nombreux, un microcontroleur specifique a

ceux-ci a ete cree.

Dans une optique d’architecture reconfigurable, il serait interessant de determiner

le choix d’un microcontroleur en fonction d’une variable de comportement. Cette solu-

tion n’est malheureusement pas realisable. DK4 interprete toutes les possibilites d’une

condition et ce meme si la variable conditionnelle est passee en parametre d’appel du

processeur ou du microcontroleur. La seule maniere de specialiser les processeurs est

de creer deux macros de comportement quasi similaires mis a part l’appel du micro-

controleur.

Il y a donc deux macros processeurs :

1. processorRamExt()=> appel de microControleurRamExt.

2. processor()=> appel de microControleur.

Une solution beaucoup plus flexible passerait par la modelisation objet et la generation

de code Handel-C apres avoir selectionne les differents points de controles.

38

Page 48: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Chapitre 5

Reseaux de processeurs atopologies fixes

5.1 Matrice carree de processeurs

En reprenant le processeur presente precedemment, nous avons modelise une archi-

tecture de type matrice carree de processeurs. La matrice de processeur a un fonction-

nement SPMD (Single Program Multiple Data). Chaque processeur execute le meme

programme en parallele, mais pas forcement la meme instruction. De plus nous avons

etendu le jeu d’instruction pour permettre la communication inter-processeur.

5.1.1 Reseau de processeurs

Dans notre architecture chaque processeur possede quatre canaux de communica-

tion bidirectionnels de 32 bits. Un processeur est identifie par son abscisse X et son

ordonnee Y. Les processeurs des extremites sont connectes entre eux (figure 5.1).

Exemple :

Le processeur (0,0) est connecte selon les canaux suivant :

– NORTH (0,1).

– EAST (1,0).

– SOUTH (0,1).

– WEST (1,0).

5.1.2 Extension du jeu d’instructions : dialogues inter-processeurs

Pour permettre la communication entre les processeurs nous avons ajoute quatre

nouvelles instructions :

39

Page 49: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

FIG. 5.1 – Architecture d’une matrice de 4 processeurs.

– TONORTH Envoie la valeur de l’accumulateur au processeur situe au nord.

– TOEAST Envoie la valeur de l’accumulateur au processeur situe a l’est.

– TOSOUTH Envoie la valeur de l’accumulateur au processeur situe au sud.

– TOWEST Envoie la valeur de l’accumulateur au processeur situe a l’ouest.

Ces nouvelles instructions introduisent une synchronisation car l’envoi d’une va-

leur par un canal implique forcement la reception d’une valeur par le canal qui lui est

oppose.

Le comportement pour une communication est le suivant :

c a s e TONORTH:

2 y =0;

p a r {4 n o r t h ! x ;

s o u t h ? y ;

6 }x = y ;

8 b r e a k ;

Chaque processeur execute le meme programme :

1. il envoie la valeur de l’accumulateur par le canal Nord

2. il recoit la valeur de son voisin du canal Sud

3. il la stocke dans une variable temporaire

4. l’accumulateur prend la valeur de la variable temporaire.

5.1.3 Exemple d’un reseau de 4 processeurs

Nous avons mis en place un reseau de 4 processeurs pour valider les communica-

tions inter-processeurs (cf. annexe ??).

L’initialisation des processeurs est faite selon les canaux de la figure 5.2 :

40

Page 50: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

FIG. 5.2 – Canaux de communications inter-processeurs.

p r o c e s s o r ( canaux [ 0 ] , canaux [ 1 ] , canaux [ 2 ] , canaux [ 3 ] ,

2 i n p u t [ 0 ] [ 0 ] , o u t p u t [ 0 ] [ 0 ] , 0 , 0 ) ;

p r o c e s s o r ( canaux [ 4 ] , canaux [ 3 ] , canaux [ 5 ] , canaux [ 1 ] ,

4 i n p u t [ 1 ] [ 0 ] , o u t p u t [ 0 ] [ 0 ] , 1 , 0 ) ;

p r o c e s s o r ( canaux [ 2 ] , canaux [ 6 ] , canaux [ 0 ] , canaux [ 7 ] ,

6 i n p u t [ 0 ] [ 1 ] , o u t p u t [ 0 ] [ 0 ] , 0 , 1 ) ;

p r o c e s s o r ( canaux [ 5 ] , canaux [ 7 ] , canaux [ 4 ] , canaux [ 6 ] ,

8 i n p u t [ 1 ] [ 1 ] , o u t p u t [ 0 ] [ 0 ] , 1 , 1 ) ;

En ce qui concerne la transmission du programme et des donnees d’entrees nous

avons applique tous les differents types d’acces presentes au chapitre precedent.

A la fin du programme, chaque processeur retourne, vers l’interface, le contenu de

son accumulateur par le bais de son canal output. Le resultat est ensuite affiche sur la

console :

seq ( i =0 ; i<NBPROCL; i ++){2 seq ( j =0 ; j<NBPROCL; j ++){

/ / s o r t i e des r e s u l t a t s

4 o u t p u t [ i ] [ j ] ? d a t a s O u t [ i@0+j@0∗NBPROCL ] ;

/∗ a f f i c h a g e des r e s u l t a t s s u r l a c o n s o l e ∗ /

6 p r i n t ! d a t a s O u t [0@( i + j ∗NBPROCL ) ] ;

}8 }

5.1.4 Extension du nombre de processeurs : mesure des taux d’oc-cupation

Nous avons mesure le taux d’occupation du FPGA en fonction du nombre de pro-

cesseurs (4, 9, 16, 25 et 36). Ces mesures ont ete realisees avec le programme assem-

bleur defini en memoire interne du FPGA. La figure 5.3 resume l’evolution obtenue.

41

Page 51: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

Le comportement est quasiment lineaire (y=3x) avec un maximum atteint pour 36 pro-

cesseurs.

FIG. 5.3 – Evolution des taux d’utilisation en fonction du nombre de processeurs.

Les taux d’utilisation du FPGA pour les autres types d’acces au programme ont ete

mesures uniquement dans le cas d’une matrice carree a 4 processeurs cf. graphes 2.6,

2.7 et 2.8.

5.2 Architecture Data-Flow

Une architecture de type data-flow a ete. Elle est composee de trois processeurs

fonctionnant en parallele. Chacun de ces processeurs a un role different :

– Le premier processeur lit les donnees en memoire puis les transmet au second.

– Le second effectue les operations et transmet le resultat au dernier processeur.

– Le troisieme et dernier processeur recupere les resultats et les stocke en memoire.

5.2.1 Description de l’architecture

Le traitement est effectue par une chaıne comprenant un processeur charge d’obte-

nir les donnees a partir de la RAM (ZBT SRAM0), un processeur effectuant les calculs

et un processeur ecrivant le resultat dans une autre RAM (ZBT SRAM1).

L’acces aux donnees qui entrent et sortent de la chaıne de traitement se fait par le

port parallele de la machine hote.

42

Page 52: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

FIG. 5.4 – Architecture data-flow.

5.2.2 Modification du jeu d’instructions

Pour que le fonctionnement de cette architecture soit possible, nous avons ajoute

deux instructions :

READRAM Lit une valeur de la RAM0 a l’adresse indiquee par l’operande.

READRAM: RC200PL1RAM0SetReadAdress ( operand<− 2 0 ) ;

2 RC200PL1RAM0Read(&dataRam ) ;

x = dataRam<−DW;

4 b r e a k ;

WRITERAM Ecrit une valeur dans la RAM1 a l’adresse indiquee par l’operande.

WRITERAM: dataRam = 0@x;

2 RC200PL1RAM1SetWriteAdress ( operand <−20);

RC200PL1RAM1Write(&dataRam ) ;

4 b r e a k ;

Remarque : Dans cet exemple, chaque processeur possede un role different. Une

specialisation du jeu d’instructions pour chaque processeur a donc ete effectuee (sup-

pression des instructions inutiles) en fonction de son role dans le reseau. Ceci a permis

un gain de 28 pour-cent en terme de surface sur le FPGA par rapport a la mise en place

de 3 processeurs possedant le meme jeu d’instruction.

5.2.3 Application d’un modele data-flow : Dilatation d’une image

Nous avons applique l’architecture data-flow a la dilatation d’une image binaire.

L’image est divisee en pixels codes sur 1 bit.

L’algorithme de dilatation traite l’image pixel par pixel. Pour chaque pixel, il verifie

si lui ou l’un des pixels qui l’entoure possede la valeur 1. Si cela est le cas le pixel traite

prend la valeur 1. Sinon il reste a la valeur 0.

43

Page 53: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

Exemple d’une dilatation sur une image de 6x6 pixels. Il est necessaire d’elargir

l’image d’un pixel sur les peripheries afin de prendre en compte les effets de bord. (cf

figure 5.5 et 5.6)

FIG. 5.5 – Grille de pixels a dilater.

FIG. 5.6 – Grille de pixels dilatee.

Nous avons commence par la mise en place d’un algorithme de dilation simple.

Pour chaque pixel a traiter, le programme lisait ce pixel et ceux qui l’entourait et cela

pour chaque pixel de l’image.

Programme de l’algorithme en assembleur :

INIT , 0 /∗ L e c t u r e du nombre de p i x e l s a t r a i t e r ∗ /

2 STORE , 9 /∗ −> r e g : 9 ∗ /

LOADI , 0 /∗ Compteur de p i x e l a 0 ∗ /

4 STORE , 10 /∗ −> r e g : 10 ∗ /

INPUT , 0 /∗ L e c t u r e des 9 p i x e l s ∗ /

6 STORE , 0

INPUT , 0

8 STORE , 1

INPUT , 0

10 STORE , 2

INPUT , 0

12 STORE , 3

INPUT , 0

14 STORE , 4

INPUT , 0

16 STORE , 5

INPUT , 0

18 STORE , 6

INPUT , 0

44

Page 54: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

20 STORE , 7

INPUT , 0

22 STORE , 8 /∗ Fin l e c t u r e ∗ /

/∗ Si p i x e l d i f f e r e n t 0 , r e s =1 e t s o r t i e s i n o n t e s t e p i x e l s u i v a n t

∗ /

24 JUMPNZ, 38

LOAD, 7

26 JUMPNZ, 38

LOAD, 6

28 JUMPNZ, 38

LOAD, 5

30 JUMPNZ, 38

LOAD, 4

32 JUMPNZ, 38

LOAD, 3

34 JUMPNZ, 38

LOAD, 2

36 JUMPNZ, 38

LOAD, 1

38 JUMPNZ, 38

LOAD, 0

40 OUTPUT, 0 /∗ s o r t i e r e s u l t a t ∗ /

LOAD, 1 /∗ I n c r e m e n t a t i o n du compteur de p i x ∗ /

42 ADDI , 1

STORE , 1

44 LOAD, 0

SUB, 1 /∗ C a l c u l du nombre de p i x e l s a t r a i t e r ∗ /

46 JUMPNZ, 4 /∗ Si i l n ’ y a p l u s de p i x e l s : FIN . ∗ /

HALT, 0 /∗ E x i t ∗ /

Remarque : Cet algorithme n’est pas specialement efficace. En effet il n’integre pas

le fait que certains pixels deja lu servent au traitement du pixel voisin.

Nous avons donc developpe un algorithme plus efficace. Cet algorithme lit l’image

par colonne de 3 pixels puis il conserve les 2 colonnes necessaires pour au traitement

du pixel suivant.

Exemple : si on veut dilater le pixel 1, on doit lire la colonne centree sur le pixel

0 puis celle centree sur le pixel 1 et enfin celle centree sur le pixel 2. Et si on souhaite

appliquer l’algorithme de dilatation au pixel 2, il nous suffit de lire la colonne centree

sur le pixel 3 (cf figure 5.7).

Programme de l’algorithme en assembleur :

1 INPUT , 0 /∗ Read nombre p i x e l s s u r une l i g n e ∗ /

STORE , 9 /∗ S t o r e ad d r 9 ∗ /

3 STORE , 11 /∗ Compteur de p i x e l p e u t e t r e e n l e v e e ∗ /

INPUT , 0 /∗ Read nombre l i g n e s a t r a i t e r ∗ /

5 STORE , 10 /∗ S t o r e ad d r 10 ∗ /

STORE , 12 /∗ Compteur de l i g n e ∗ /

7 LOAD, 9 /∗ Compteur de p i x e l = nombre p i x e l s s u r une l i g n e

∗ /

STORE , 11

9 INPUT , 0 /∗ S t o c k a g e des 9 p i x e l s dans l a RAM∗ /

45

Page 55: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

FIG. 5.7 – Dilatation par colonnes.

STORE , 0

11 INPUT , 0

STORE , 1

13 INPUT , 0

STORE , 2

15 INPUT , 0

STORE , 3

17 INPUT , 0

STORE , 4

19 INPUT , 0

STORE , 5

21 INPUT , 0

STORE , 6

23 INPUT , 0

STORE , 7

25 INPUT , 0

STORE , 8 /∗ Fin s t o c k a g e ∗ /

27 JUMP, 45 /∗ A l l e r au t r a i t e m e n t ∗ /

LOAD, 3 /∗ Si on e s t s u r l a meme l i g n e −> Deca lage ∗ /

29 STORE , 0

LOAD, 4

31 STORE , 1

LOAD, 5

33 STORE , 2

LOAD, 6

35 STORE , 3

LOAD, 7

46

Page 56: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

37 STORE , 4

LOAD, 8

39 STORE , 5 /∗ Fin d e c a l a g e ∗ /

INPUT , 0 /∗ L e c t u r e des t r o i s p i x e l s manquant ∗ /

41 STORE , 6

INPUT , 0

43 STORE , 7

INPUT , 0

45 STORE , 8 /∗ Fin L e c t u r e ∗ /

/∗ Debut du t r a i t e m e n t −> s i un p i x e l =1 a l o r s on e n v o i e l a v a l e u r 1

∗ /

47 LOAD, 8

JUMPNZ, 62

49 LOAD, 7

JUMPNZ, 62

51 LOAD, 6

JUMPNZ, 62

53 LOAD, 5

JUMPNZ, 62

55 LOAD, 4

JUMPNZ, 62

57 LOAD, 3

JUMPNZ, 62

59 LOAD, 2

JUMPNZ, 62

61 LOAD, 1

JUMPNZ, 62

63 LOAD, 0

OUTPUT, 0 /∗ Fin du t r a i t e m e n t e t e n v o i de l a v a l e u r o b t e n u e ∗ /

65 LOAD, 11 /∗ Compteur de p i x e l −1 ∗ /

SUBI , 1

67 STORE , 11

JUMPNZ, 27 /∗ A l l e r p i x e l s u i v a n t ∗ /

69 LOAD, 12 /∗ Compteur de l i g n e −1 ∗ /

SUBI , 1

71 STORE , 12

JUMPNZ, 6 /∗ Debut de l i g n e ∗ /

73 HALT, 0 ) /∗ E x i t ∗ /

La transmission des pixels de la machine hote via le port parallele se fait par octet.

Le FPGA s’occupe de grouper les pixels par paquets de 32 puis de les stocker dans le

banc RAM (cf figure 5.8).

47

Page 57: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 5. RESEAUX DE PROCESSEURS A TOPOLOGIES FIXES

FIG. 5.8 – Dilatation par colonnes.

48

Page 58: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Chapitre 6

Reseaux de processeurs atopologies reconfigurables

Ce chapitre traite des differents moyens mis en oeuvre pour obtenir un reseau de

communication reconfigurable. La solution la plus simple et la plus couteuse consiste

a implementer un crossbar disposant d’autant d’entrees/sorties que de canaux de com-

munications. Ce mecanisme s’avere tres couteux et un autre systeme de crossbar a ete

etudie. Autre possibilite, un reseau de communications inspire de l’architecture iWarp

permet aux processeurs de dialoguer sur la base de circuits virtuels. L’objectif etant

d’obtenir un reseau de communication reconfigurable, la derniere partie de ce chapitre

propose le prototype d’un processeur de boot charge de configurer le reseau et les pro-

cesseurs.

6.1 Communications par commutation de canaux : cross-

bars

Le crossbar est un commutateur qui par sa connexion a plusieurs processeurs per-

met de modifier la topologie du reseau.

6.1.1 Description de l’architecture du crossbar

Le crossbar est constitue de canaux bidirectionnels (canaux de gauche et de droite)

par lesquels vont circuler les donnees inter-processeurs. Les valeurs presentes en entree

des canaux sont redirigees vers les canaux determines par la table de switch. La table

de switch est configuree par le canal de configuration. qui est aussi utilise pour de-

mander la reconfiguration du crossbar. Cette demande de fait par le message DEMAN-

DERECONF. Si la demande est acceptee, le crossbar se met en attente d’une nouvelle

configuration.

49

Page 59: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

FIG. 6.1 – Architecture du crossbar.

6.1.2 Description du fonctionnement

Le remplissage de la table de switch s’effectue en commencant par l’affection des

canaux de gauche puis des canaux de droite :

1 /∗ c o n f i g u r a t i o n ∗ /

p a r {3 r e c o n f =0;

seq ( i =0 ; i <2; i = i +1) {5 seq ( j =0 ; j<CROSSBARSIZE ; j = j +1){

c a n a l C o n f ? t a b l e R o u t a g e [ i ] [ j ] ;

7 p r i n t ! t a b l e R o u t a g e [ i ] [ j ] ;

}9 }

}

Pour chaque canal de gauche, on parcourt la table de routage pour connaıtre le canal

de droite auquel il est relie :

u n s i g n e d i n t CodeCROSSBAR tmp ;

2 u n s i g n e d i n t CodeCROSSBAR tmp2 ;

tmp = t a b l e R o u t a g e [ 0 ] [ k]<−CodeCROSSBAR ;

4 tmp2 = t a b l e R o u t a g e [ 1 ] [ k]<−CodeCROSSBAR ;

Des que la table est correctement configuree, le crossbar scrute l’arrivee d’une va-

leur sur l’une de ses entrees :

Si une valeur arrive sur le canal de configuration, le crossbar se met en attente d’une

nouvelle configuration.

Si une valeur arrive sur un canal G ou un canal D, le crossbar emet la valeur recue

par le canal de sortie determine par la table de switch :

2 p r i a l t {

50

Page 60: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

c a s e c a n a l C o n f ? r e c o n f :

4 b r e a k ;

6 c a s e canauxG [ tmp ] ? va l eu rG [ k ] :

va l eu rD [ k ] = va leu rG [ k ] ;

8 canauxD [ tmp2 ] ! va l eu rD [ k ] ;

b r e a k ;

10

c a s e canauxD [ tmp2 ] ? va l eu rD [ k ] :

12 va leu rG [ k ] = va leu rD [ k ] ;

canauxG [ tmp ] ! va l eu rG [ k ] ;

14 b r e a k ;

}

6.1.3 Evolution de la taille des canaux : mesure du taux d’occupa-tion

Des mesures ont ete effectuees pour mesurer l’impact de la taille des canaux sur le

taux d’utilisation du FPGA. Ces evaluations ont ete realises pour un crossbar 16 e/s.

FIG. 6.2 – evolution du taux d’occupation d’un crossbar en fonction de la taille de ses

canaux.

Le graphique fait clairement apparaıtre une evolution exponentielle du taux d’utili-

sation du FPGA en fonction de la taille des canaux. (cf figure 6.2)

51

Page 61: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

6.1.4 Reseau de processeurs

La communication entre 4 processeurs avec un ou plusieurs crossbars a ete mise en

oeuvre pour mesurer l’impact sur le taux d’utilisation du FPGA

Reseau de processeurs relies a un crossbar :

La premiere mise en oeuvre realisee est la connexion de 4 processeurs identiques a

un crossbar 16 e/s (Cf figure 6.3).

FIG. 6.3 – exemple d’un crossbar 16 e/s pour un reseau de 4 processeur.

Reseau de processeurs avec crossbars dedies :

Dans un deuxieme temps, chaque processeur est relie a un crossbar specifique et

identique. Les canaux de gauche de chaque crossbar sont affectes a leur processeur. Les

canaux de droite sont relies entre les crossbars pour permettre de configurer le reseau

avec toutes les topologies possibles(Cf figure 6.4).

Mesure et comparaison des differentes methodes :

La mesure de reference a ete le taux d’utilisation du FPGA pour une matrice carree

de 4 processeurs dont la topologie est fixe et avec le programme assembleur code dans

la RAM interne. Nous avons effectues les mesures pour les deux configurations decrites

precedemment, les programmes assembleur etant egalement implementes dans la RAM

interne du FPGA (Cf figure 6.5).

Ce graphique montre la forte augmentation en terme de taux d’occupation qu’im-

plique l’insertion d’un ou de plusieurs crossbars pour un reseau de 4 processeurs.

Nous remarquons que la methode avec les crossbars dedies est moins couteuse mais

consomme tout de meme 40 pour-cent des slices et 38 pour-cent des LUTs disponibles

sur le FPGA.

52

Page 62: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

FIG. 6.4 – exemple de crossbars dedies pour un reseau de 4 processeur.

FIG. 6.5 – taux d’utilisation du FPGA en fonction des differentes methodes testees.

53

Page 63: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

En conclusion, l’utilisation d’un ou de plusieurs crossbars n’est pas suffisamment

interessante pour etre retenue. Une autre approche doit donc etre testee pour permettre

au reseau de processeurs d’avoir une topologie variable.

6.2 Communications par circuits virtuels

6.2.1 Architecture iWarp

L’architecture parallele i-warp a ete developpee conjointement par l’universite Car-

negie Mellon et Intel Corporation. Les communications entres les cellules sont ef-

fectuees par memoire ou par transmission systolique [?]. La communication systolique

etant particulierement adaptee aux acces grains fins, c’est ce type de communication

qui a ete etudie.

L’architecture i-warp est basee sur un ensemble de cellules elles memes constituees

d’un composant i-warp et d’une memoire locale. Chaque cellule communique avec les

autres via un agent de communication integre au composant i-warp. Le composant se

structure autour d’un agent de calcul executant le programme et d’un agent de gestionmemoire, tous deux connectes a l’agent de communication [?]. La figure 6.6 illustre

l’architecture i-warp.

FIG. 6.6 – Matrice de cellules iWarp

L’agent de communication fournit quatre entrees et quatre sorties physiques : Xleft

(in et out), Xright, Yup, Ydown. Ces liens sont unidirectionnels et parametrables, il est

par exemple possible d’affecter une cellule differente sur l’entree Xleft de celle liee

a la sortie Xleft. Chaque agent de communication possede 20 queues de 8*32bits. A

54

Page 64: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

chaque queue correspond une source specifique. Il est possible qu’il existe des queues

dont la source est la cellule locale, on parle alors de communication programme vers

programme. A la reception sur une entree, la valeur est placee dans la file dont la source

correspondante a ete fixee statiquement a l’initialisation de l’agent.

La gestion des files repose sur deux etapes :

1. Allocation statique des sources : a chaque queue est affectee une source.

2. Assignement dynamique des destinations : pendant l’execution une destination

est associee a une file au temps d’execution.

La transmission d’une donnee s’appuie sur la notion de « pathway ». Le pathway

est une connexion unidirectionnelle construite a partir des canaux de communications.

Un chemin est etabli a la demande par un algorithme de routage, il peut etre sauve-

garde dans un pool de reservation local. Une fois qu’un chemin est etabli les donnees

sont transmises rapidement. Un chemin est constuit a partir d’un header qui indique le

comportement a adopter a chaque cellule traversee (on parle de routage a signalisation

de direction) :

– Transmission de la donnee vers la direction par defaut de l’agent de communi-

cation local.

– Virage vers un autre canal.

Un marqueur de fin de chemin indique que la donnee est arrivee a destination.

6.2.2 Communications par circuits virtuels

Le reseau de communication developpe s’appuie sur la notion de « pathway » de

l’architecture iWarp. Un circuit virtuel est un chemin unidirectionnel unique transferant

des donnees d’un processeur source vers un processeur destination. Ce circuit s’appuie

sur un ou plusieurs circuits reels. C’est-a-dire q’une donnee est encapsulee dans une

trame contenant un identifiant de circuit virtuel et est transmise d’agent de communi-

cation en agent de communication jusqu’a atteindre le processeur cible.

Il existe deux types de communications a distinguer :

– Transmission d’une donnee vers un autre processeur.

– Reception d’une trame sur un des canaux d’entrees.

La figure 6.7 schematise le comportement de l’agent de communication et du pro-

cesseur. Pour transmettre une donnee vers autre processeur, celle-ci est encapsulee dans

une trame indiquant la destination sur les 4 MSBs. La trame est transmise a l’agent de

communication via un canal de 36 bits. En fonction d’une table locale de correspon-

dance, l’agent de communication dirige la donnee vers le canal de sortie approprie

apres l’avoir encapsule avec l’identifiant du circuit virtuel (paquet de 36 bits).

Lors de la reception d’une trame, l’agent de communication commence par verifier

dans la table correspondant au canal d’entree, si le CV ne s’arrete pas ici. Si c’est le cas,

il recupere les 32LSBs de la trame et les transmet au processeur via le canal d’entree

du processeur. Dans le cas contraire, il faut retransmettre la trame sur le bon canal et le

bon CV. Ceux-ci sont indiques dans la table des CVs du canal d’entree.

55

Page 65: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

FIG. 6.7 – Traitement des donnees par l’agent de communication

Les canaux de transmissions de l’agent de communication disposent d’une fifo de

taille 8. Les fifos sont declarees directement sur les canaux en Handel-C :

1 chan u n s i g n e d 36 O1 wi t h { f i f o l e n g t h = FIFOL} ,

O2 wi th { f i f o l e n g t h = FIFOL} ,

3 O3 wi th { f i f o l e n g t h = FIFOL} ,

O4 wi th { f i f o l e n g t h = FIFOL } ;

5 chan u n s i g n e d 36 I1 wi t h { f i f o l e n g t h = FIFOL} ,

I 2 wi th { f i f o l e n g t h = FIFOL} ,

7 I3 wi th { f i f o l e n g t h = FIFOL} ,

I 4 wi th { f i f o l e n g t h = FIFOL } ;

A chaque canal correspond une table des CV. L’identifiant d’un circuit virtuel indice

une entree de la table et la valeur associee est construite selon le format de la figure 6.8.

Le comportement est sensiblement identique (cf. figure 6.7) pour la correspondance

destination/CV.

FIG. 6.8 – Format logique d’un circuit virtuel

56

Page 66: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

L’agent de communication est construit autour d’une boucle d’emission et d’une

boucle de reception s’executant en parallele :

p a r {2 / / Boucle d ’ e m i s s i o n

w h i l e ( 1 ){4 o u t P r o c ? t rameOut ; / / r e c e p t i o n de l a t r ame du p r o c e s s e u r

r o u t e = t a b l e R [ d e s t O u t ] ; / / r e c h e r c h e de l a bonne r o u t e

6 s w i t c h ( r o u t e c h a n O u t ){c a s e 0 :

8 t r ameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

O1 ! t rameOut ;

10 b r e a k ;

c a s e 2 :

12 t r ameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

O2 ! t rameOut ;

14 b r e a k ;

c a s e 3 :

16 t r ameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

O3 ! t rameOut ;

18 b r e a k ;

c a s e 4 :

20 t r ameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

O4 ! t rameOut ;

22 b r e a k ;

d e f a u l t :

24 d e l a y ; / / D e s t i n a t i o n in c o n n u e : p e r t e du message

} ;

26 }/ / Boucle de r e c e p t i o n & t r a n s m i s s i o n

28 w h i l e ( 1 ){p r i a l t {

30 c a s e I1 ? t r a m e I n :

cv = tableCV1 [ c v d l c i I n ] ; / / R e c u p e r a t i o n du DLCI dans l a t a b l e 1

32 i f ( c v h e r e ){i n P r o c ! t r ameIn <−DW; / / t r a n s m i s s i o n au p r o c e s s e u r

34 }e l s e {

36 s w i t c h ( cv chanOut ){ / / s e l e c t i o n du c a n a l de s o r t i e

c a s e 1 :

38 t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

O1 ! t r a m e I n ;

40 b r e a k ;

c a s e 2 :

42 t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

O2 ! t r a m e I n ;

44 b r e a k ;

c a s e 3 :

46 t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

O3 ! t r a m e I n ;

48 b r e a k ;

c a s e 4 :

50 t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

O4 ! t r a m e I n ;

52 b r e a k ;

57

Page 67: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

d e f a u l t :

54 d e l a y ; / / D e s t i n a t i o n in c o n n u e : p e r t e du message

} ;

56 }b r e a k ;

58 / / e t c . . . pour l e s a u t r e s canaux d ’ e n t r e e s

Le decodage d’une trame s’appuie sur les macros suivantes(NB : dlci designe

l’identifiant d’un circuit virtuel) :

/ / Macro de d ecodage de t r ame v e n a n t du p r o c e s s e u r

2 macro ex p r d e s t O u t = ( t rameOut \\DW)<−COM DEST AW;

/ / Macros de d ecodage de l a t a b l e de r o u t a g e

4 macro ex p r r o u t e c h a n O u t = r o u t e <−COM CHAN AW;

macro ex p r r o u t e d l c i O u t = ( r o u t e \\COM CHAN AW)<−COM DLCI AW ;

6 / / Macros de d ecodage de l a t a b l e des C i r c u i t s V i r t u e l s

macro ex p r c v d l c i I n = ( t r a m e I n \\ DW)<−COM DLCI AW ; / / d l c i de l a t r ame e n t r a n t e

8 macro ex p r cv chanOut = cv <−COM CHAN AW;

macro ex p r c v d l c i O u t = ( cv \\ COM CHAN AW )<−COM DLCI AW ;

10 macro ex p r c v h e r e = ( cv \\ (COM CHAN AW+COM DLCI AW))<−COM HERE AW;

6.2.3 Occupation de la surface et performances

La surface occupee pour un processeur micro programme et son agent de communi-

cation occupe 17% des slices. Cependant cette mesure est faite en affichant le contenu

de l’accumulateur a chaque fin d’instruction afin d’empecher DK4 de trop simplifier

l’architecture. Pour avoir une valeur plus representative, un reseau de quatre proces-

seurs a ete implemente. Les resultats sont les suivants : 15% des bascules, 49% des

slices, 41% des LUTs. Le nombre de slices occupe pour l’architecture d’un processeur

et de son agent de communication doit donc etre proche de 11% du total disponible.

L’analyse du code fournit les latences de transmissions suivantes :

– Emission d’une donnee : 4 cycles.

– Reception d’une donnee : 3 cycles.

– Parcourt d’un circuit virtuel : 4 * nombre de cellules traversees.

6.3 Reconfiguration du reseau : processeur de Boot

Le processeur de boot a ete utilise pour configurer les processeurs du reseau.

Par le biais d’un programme assembleur, il permet d’affecter un programme assem-

bleur et les donnees correspondantes a chaque processeur et d’activer les processeurs

souhaites.

Il pourrait permettre egalement la modification de la communication entre les differents

processeurs en configurant le crossbar ou le circuit virtuel, mais cette fonctionnalite n’a

pas ete mise en oeuvre.

58

Page 68: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

6.3.1 L’architecture du processeur de boot

L’architecture du processeur de boot est la suivante :

FIG. 6.9 – Architecture du processeur de boot.

Le processeur est compose d’une unite de commande, d’une RAM, d’un accu-

mulateur, de plusieurs memoires de programme et d’une memoire de controle pour

permettre de stocker les donnees necessaires au fonctionnement des programmes.

L’UAL (Unite Arithmetique Logique) permet d’effectuer des operations addition

ou soustraction en deux operandes : l’un etant situe dans la RAM, l’autre defini par le

registre IR (operande 1). L’unite de commande est composee d’un compteur d’instruc-

tion PC (Program Counter), d’un registre IR (Instruction Register) et d’un sequenceur.

Le compteur d’instruction PC, code sur 32 bits, pointe vers la prochaine instruction

a executer. Chaque instruction traitee est stockee dans le registre IR de 32 bits. Les

8 bits de poids forts sont reserves a l’operateur. Les 24 bits restant sont reserves au

codage des deux operandes (les bits de 0 a 11 pour l’operande 2 et de 12 a 23 pour

L’operande 1). L’accumulateur est un registre de 32 bits qui stocke temporairement

l’etat d’une variable. Le processeur peut egalement lire et ecrire une valeur dans la

RAM. La RAM est modelisee par un tableau de taille 32. Chacune de ses valeurs est

codee sur 32 bits.

La quantite de «memoire de programme» (stockage des programmes) varie en

fonction du nombre de programmes que l’on affecte aux processeurs. Le programme

du processeur de boot est egalement stocke dans la «memoire de programme».

Le canal de sortie permet l’envoi de message vers les processeurs du reseau.

La propagation du message se fait par un canal qui circule sur tout le reseau de la

facon suivante :

59

Page 69: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

FIG. 6.10 – Communication du processeur de boot avec les processeurs du reseau.

6.3.2 Jeu d’instructions

LDL, LDC, STL, ADCR, SUBCR, JUMP, JUMPNZ et HALT sont des instructions

qui ne sont pas specifiques au processeur de boot. Leur comportement a ete decrit lors

de la presentation du jeu d’instructions dans le chapitre microprogrammation.

Les instructions suivantes sont specifiques au processeur de boot :

BOOT active les processeurs souhaites. Pour activer un processeur, il faut posi-

tionner a 1 le bit correspondant a son numero dans la configuration (cf. figure 6.10).

Exemple :

FIG. 6.11 – Codage de l’instruction BOOT.

Active les processeurs 0 et 2, les processeurs 1 et 3 ne sont pas actives

STOP arrete les processeurs souhaites selon le meme procede que l’instruction

BOOT.

60

Page 70: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

instruction cout en cycle

LDL 2

LDC 2

STL 2

ADCR 3

SUBCR 3

JUMP 2

JUMPNZ 2

HALT 1

BOOT 3

PROGRAM 3

DAT 4

DATAI 3

LOADD 2

READ variable

FIG. 6.12 – Cout des instructions du processeur de Boot.

PROGRAM affecte un programme a un processeur. L’operande 2 permet de specifier

le programme qui est affecte au processeur defini par l’operande 1 (numero du proces-

seur).

READ lit un programme via le port parallele. L’operande 1 specifie l’adresse de la

memoire de programme dans laquelle va etre stocke le programme lu.

LOADD charge dans l’accumulateur une valeur de la memoire de controle pointee

par l’adresse specifiee par l’operande 1.

DAT envoie par le canal de sortie la donnee contenue dans l’accumulateur vers le

processeur defini par l’operande 1 (numero du processeur).

DATAI envoie par le canal de sortie la valeur de l’operande 2 vers le processeur

defini par l’operande 1 (numero du processeur).

Chaque instruction a un cout determine sauf l’instruction READ dont le cout est

fonction de la taille du programme lu et de la vitesse de transmission via le port pa-

rallele :

6.3.3 Fonctionnement du processeur de boot

Bootstrap :

Avant de commencer a configurer les processeurs du reseau, il faut affecter une

valeur a la variable bootstrap. Cette valeur permet de specifier l’emplacement des pro-

grammes assembleur.

Deux possibilites sont offertes :

61

Page 71: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

– Soit les programmes sont prealablement ecrits dans la RAM interne (memoire

de programme) du FPGA (Bootstrap =1).

– Soit les programmes du processeur de boot et des processeurs sont lus via le port

parallele (Bootstrap =2) puis stocke dans la memoire de programme.

Remarque : La lecture des programmes necessaires au fonctionnement des pro-

cesseurs n’est pas automatique. Elle se fait par l’intermediaire de l’instruction READ

ecrite dans le programme du processeur de boot.

Code permettant le lancement du processeur de boot :

p a r

2 {RunConsole ( p r i n t ) ; / / Lancement du m u l t i p l e x e u r d ’ a f f i c h a g e

4 i f (BOOTSTRAP ==2)

P a l D a t a P o r t R u n ( P a r a l l e l P o r t , C lockRate ) ;

6 seq {i f (BOOTSTRAP ==2){

8 P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

/ / l e c t u r e du programme de boo t

10 R e a d P a r a l l e l ( p r i n t [ 3 ] , d a t a s I n , programB ) ;

12 }p r o c e s s o r B o o t ( i n i t [ 0 ] , p r i n t [ 0 ] , programB , BOOTSTRAP, d a t a ) ;

14 / / Lancement des p r o c e s s e u r s

16 }

Code du processeur de boot :

s t a t i c macro p ro c p r o c e s s o r B o o t ( o u t p u t , program , b o o t s t r a p , d a t a )

2 {/ / . . . i n i t i a l i s a t i o n . . .

4

/ / Decodage de l ’ i n s t r u c t i o n e t e x e c u t i o n

6 s w i t c h ( opcode )

{8 c a s e HALT : b r e a k ;

c a s e BOOT : x= i r ;

10 o u t p u t ! x ;

b r e a k ;

12 c a s e STOP : x= i r ;

o u t p u t ! x ;

14 b r e a k ;

c a s e PROGRAM : x= i r ;

16 o u t p u t ! x ;

b r e a k ;

18 c a s e DATAI : x= i r ;

o u t p u t ! x ;

20 b r e a k ;

c a s e DAT : tmp =x ;

22 x = 0@opcode + 0 @operand1+ 0@( tmp<−OPRW) ;

o u t p u t ! x ;

24 b r e a k ;

62

Page 72: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

c a s e READ :

26 i f ( b o o t s t r a p ==2){P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

28 s w i t c h ( ope rand1 ){c a s e 0 : R e a d P a r a l l e l ( p r i n t , d a t a s I n , program0 ) ; b r e a k ;

30 c a s e 1 : R e a d P a r a l l e l ( p r i n t , d a t a s I n , program1 ) ; b r e a k ;

c a s e 2 : R e a d P a r a l l e l ( p r i n t , d a t a s I n , program2 ) ; b r e a k ;

32 d e f a u l t : w h i l e ( 1 ) d e l a y ;

}34 }

b r e a k ;

36 c a s e LOADD : x = 0@data [ ope rand1 <− RAM DAT ] ;

b r e a k ;

38 / / . . . e t c . . .

}40 } w h i l e ( opcode != HALT ) ;

}

Le fonctionnement des processeurs a ete modifie pour permettre leur configuration

par le processeur de boot. Chaque processeur se met en attente d’une configuration

avant de derouler le programme.

Les modifications apportees aux processeurs :

1 /∗∗ Macros d ’ e x t r a c t i o n du b i t c o r r e s p o n d a n t au p r o c e s s e u r

3 ∗ /

macro ex p r num = ( ( ( i r >> (X <− 6 ) ) <−1) == 1 ) ;

5

s t o p =0;

7 do{boo t =0 ;

9 do{

11 i n p u t R o o t ? i r ;

i f (X != (NBPROC−1))

13 o u t p u t R o o t ! i r ;

15 s w i t c h ( opcode ){

17 c a s e BOOT: i f ( num )

boo t = 1 ;

19 b r e a k ;

c a s e PROGRAM: i f ( ope rand2 == X){21 s w i t c h ( ope rand1 ){

23 c a s e 0 : program = &( program0 ) ;

b r e a k ;

25 c a s e 1 : program = &( program1 ) ;

b r e a k ;

27 c a s e 2 : program = &( program2 ) ;

b r e a k ;

29 d e f a u l t : w h i l e ( 1 ) d e l a y ;

}

63

Page 73: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

CHAPITRE 6. RESEAUX DE PROCESSEURS A TOPOLOGIES

RECONFIGURABLES

31 }b r e a k ;

33 c a s e STOP : i f ( num )

s t o p =1;

35 b r e a k ;

c a s e DAT: i f ( ope rand2 == X)

37 dataR = 0@operand1 ;

b r e a k ;

39 c a s e DATAI : i f ( ope rand2 == X)

dataR = 0@operand1 ;

41 b r e a k ;

43 } w h i l e ( ( opcode !=BOOT) && ( opcode !=STOP ) ) ;

i f ( bo o t == 1){45 /∗ d e r o u l e m e n t du programme ∗ /

/∗ code du s e q u e n c e u r ∗ /

47 }} w h i l e ( s t o p == 0 ) ;

49 }

6.3.4 Exemple de programme pour le processeur de boot

Ce programme assembleur attribue le programme 0 au processeur 0, le programme

2 au processeur 1 puis il active ces deux processeurs. Des que les deux processeurs ont

execute leur programme, ils s’arretent a la lecture de l’instruction STOP 0,3.

1 DATA

CODE

3 PROGRAM 0 ,1

PROGRAM 2 ,2

5 BOOT 0 ,3

STOP 0 ,3

7 HALT

64

Page 74: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Conclusion

Apres un apprentissage du langage Handel-C, plusieurs architectures ont ete imple-

mentees sur la carte RC203. L’objectif du TER n’etait pas de developper des applica-

tions specifiques mais de degager les bases d’une modelisation de differentes architec-

tures paralleles. C’est pourquoi les programmes utilises a titre d’exemple sont simples.

Cependant nous avons valide differentes techniques d’implementations qui permettront

a l’avenir de faciliter le developpement d’architectures (notamment matrice de proces-

seurs et modele data-flow).

Nous avons rencontre certaines difficultes dont la principale reste le typage fort du

langage. Il n’etait pas rare de perdre plusieurs heures sur des problemes de taille de

variable. Il serait d’ailleurs interessant d’envisager une couche superieure capable de

gerer au mieux le typage.

Une perspective de suite de ce projet serait une modelisation objet de nos resultats :

design assiste de matrices de processeurs par exemple. Nous n’avons pas eu le temps

de mettre en place nos reflexions sur les micro-instructions qui seraient d’ailleurs par-

ticulierement adaptees a une modelisation objet.

65

Page 75: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe A

Mesure de cycles et defrequences : Handel-C

1 /∗∗ Main program

3 ∗ /

vo id main ( vo id )

5 {u n s i g n e d 20 Addr ;

7 u n s i g n e d i n t 32 d a t a s I n [ 4 ] ;

/ / ram u n s i g n e d i n t program1 [ 2 5 5 ] ;

9 ram u n s i g n e d i n t program0 [ 2 5 5 ] ;

/ / ram u n s i g n e d i n t program2 [ 2 5 5 ] ;

11 chan u n s i g n e d 32 canaux [ 8 ] ;

chan u n s i g n e d 32 i n i t [ 4 ] ;

13 chan u n s i g n e d 32 i n p u t [ 4 ] ;

chan u n s i g n e d 32 o u t p u t [ 4 ] ;

15 / / Canaux d ’ a f f i c h a g e

chan u n s i g n e d DW p r i n t [ 4 ] ;

17 u n s i g n e d i n t 1 c o n d i t i o n ;

u n s i g n e d i n t 64 i ;

19 u n s i g n e d i n t 1 c o n d i t i o n 1 ;

u n s i g n e d i n t 32 j ;

21 u n s i g n e d i n t 8 c ;

c o n d i t i o n =1;

23 i =0 ;

c o n d i t i o n 1 =1;

25 j =0 ;

p a r {27 P a l D a t a P o r t R u n ( P a r a l l e l P o r t , C lockRa te ) ;

RunConsole ( p r i n t ) ; / / Lancement du m u l t i p l e x e u r d ’ a f f i c h a g e

29 RC200PL1RAM0Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM0

RC200PL1RAM1Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM1

31 seq {P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

33 R e a d P a r a l l e l ( p r i n t [ 3 ] , d a t a s I n , program0 ) ;

66

Page 76: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE A. MESURE DE CYCLES ET DE FREQUENCES : HANDEL-C

p a r

35 {seq {

37 p r o c e s s o r ( canaux [ 0 ] , canaux [ 1 ] , canaux [ 2 ] ,

canaux [ 3 ] , i n p u t [ 0 ] , o u t p u t [ 0 ] , i n i t [ 0 ] ,

39 p r i n t [ 0 ] , program0 , 0 ) ;

/ / n o t i f i c a t i o n du pgr C

41 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , 8 ) ;

c o n d i t i o n =0; / / F in du pgr

43 }seq {

45 / / l a n c e m e n t du compteur de c y c l e s

compteur ( i , c o n d i t i o n ) ;

47 p r i n t [ 3 ] ! ( i −1)<−32; / / a f f i c h a g e nbCyc les

}49 }

}51 }

}53

55 s t a t i c macro p ro c compteur ( i , c o n d i t i o n ){w h i l e ( c o n d i t i o n )

57 i ++;

}

67

Page 77: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe B

Mesure de cycles et defrequences : programme C

2 # i n c l u d e < s t d l i b . h>

# i n c l u d e <windows . h>

4 # i n c l u d e <s t d i o . h>

# i n c l u d e < t c h a r . h>

6 # i n c l u d e ” r c 2 0 0 s p . h ”

8 /∗∗ Pa th t o b i t f i l e from Debug / R e l e a s e o u t p u t d i r

10 ∗ /

# d e f i n e CONFIGFILE ”RC200 / t e s t . b i t ”

12 # d e f i n e SIZET 4

14 i n t main ( ) {

16 i n t s t o p = 0 ;

RC200 CONTROL c t l ;

18 i n t r v a l , p r o g r e s s = 0 ;

LARGE INTEGER btime , e t ime , f r e q ;

20 DWORD s t i m e ;

RC200 BITFILE PROPS p r o p s ;

22 i n t B o a r d N o t P r e s e n t ;

FILE ∗ f s o r t i e ;

24 UCHAR b l o c k 1 [ 1 ] ;

UCHAR b l o c k 2 [ 1 ] ;

26 UCHAR b l o c k ;

28

i n t i , j ;

30 l on g s i z e T r a n s m i t ;

FILE ∗ F i l e ;

32

/∗

68

Page 78: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE B. MESURE DE CYCLES ET DE FREQUENCES : PROGRAMME C

34 ∗ T e x t u a l v e r s i o n of messages r e t u r n e d by RC200Tes tPor t ( )

∗ /

36 s t a t i c TCHAR ∗RC200TestPortMsg [ 5 ] =

{38 T ( ”No p a r a l l e l p o r t a t t h i s a d d r e s s ” ) ,

T ( ” P a r a l l e l p o r t found i s n o t c a p a b l e o f b i d i r e c t i o n a l d a t a t r a n s f e r ” ) ,

40 T ( ” Byte mode ( SPP / b i d i r e c t i o n a l ) p a r a l l e l p o r t found ” ) ,

T ( ” Enhanced P a r a l l e l P o r t ( EPP ) found ” ) ,

42 T ( ” Extended c a p a b i l i t i e s (ECP) p a r a l l e l p o r t found and i n i t i a l i s e d ” )

} ;

44

/∗46 ∗ T e x t u a l v e r s i o n of messages r e t u r n e d by R C 2 0 0 I n i t i a l i s e S e n d ( )

∗ /

48 s t a t i c TCHAR ∗R C 2 0 0 I n i t i a l i s e S e n d M s g [ 3 ] =

{50 T ( ” Board I n i t i a l i s e d S u c c e s s f u l l y ” ) ,

T ( ” Could n o t i n i t i a l i s e p r o t o c o l on RC200” ) ,

52 T ( ” There i s e i t h e r no RC200 a t t a c h e d or i t i s i n c o r r e c t l y c o n f i g u r e d ” )

} ;

54

/∗56 ∗ T e x t u a l v e r s i o n of messages r e t u r n e d by a l l o t h e r l i b r a r y f u n c t i o n s

∗ /

58 s t a t i c TCHAR ∗RC200TransferMsg [ 5 ] =

{60 T ( ” Data t r a n s f e r r e d s u c c e s s f u l l y ” ) ,

T ( ” There were e r r o r s e n c o u n t e r e d t r a n s f e r r i n g d a t a ” ) ,

62 T ( ” There i s e i t h e r no RC200 a t t a c h e d or i t i s i n c o r r e c t l y c o n f i g u r e d ” ) ,

T ( ” There was an e r r o r w h i l s t a t t e m p t i n g t o open f i l e ” ) ,

64 T ( ” There was i n s u f f i c i e n t memory t o c o m p l e t e t h e o p e r a t i o n ” )

} ;

66

68 QueryPe r fo rmanceFrequency (& f r e q ) ;

70 c t l . p o r t = 0 x378 ;

c t l . t e s t e c p = TRUE;

72 c t l . t e s t e p p = TRUE;

74 /∗∗ T e s t p a r a l l e l p o r t

76 ∗ /

r v a l = RC200Tes tPor t (& c t l ) ;

78 t p r i n t f ( T ( ”\n\ ’ RC200Tes tPor t \ ’ r e t u r n e d %d : \”%s \”\n\n ” ) , r v a l ,

RC200TestPortMsg [ r v a l ] ) ;

80

t p r i n t f ( T ( ” p o r t = 0x%03X ECP = %s EPP = %s \n\n ” ) ,

82 c t l . p o r t , c t l . e c r ? ” yes ” : ” no ” , c t l . emu? ” e m u l a t e d ” : ” ha rdware ” ) ;

84 /∗∗ T e s t i f boa rd i s p r e s e n t

86 ∗ /

B o a r d N o t P r e s e n t = RC200TestBoard (& c t l ) ;

69

Page 79: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE B. MESURE DE CYCLES ET DE FREQUENCES : PROGRAMME C

88 t p r i n t f ( T ( ” RC200TestBoard r e t u r n e d : %d\n ” ) , B o a r d N o t P r e s e n t ) ;

90 i f ( B o a r d N o t P r e s e n t )

{92 t p r i n t f ( T ( ”RC200 board n o t d e t e c t e d , check power and p a r a l l e l c a b l e s \n ” ) ) ;

t p r i n t f ( T ( ” E x i t i n g . . . \ n ” ) ) ;

94 r e t u r n 1 ;

}96

/∗98 ∗ C l e a r t h e RC200 FPGA

∗ /

100 RC200ClearFPGA (& c t l ) ;

102 t p r i n t f ( T ( ”\ n T e s t i n g RC200 FPGA . . . \ n\n ” ) ) ;

104 /∗∗ Check t h e b i t f i l e header , and c o n f i g u r e RC200 i f i t i s OK

106 ∗ /

i f ( R C 2 0 0 G e t B i t f i l e H e a d e r ( CONFIGFILE , &p r o p s ) == RC200 OKAY)

108 {t p r i n t f ( T ( ” f i l e : %s\n ”

110 ” g e n e r a t e d : %d/%d/%d %02d:%02d:%02d\n ”

” f o r p a r t : %s\n\n ” ) ,

112 CONFIGFILE ,

p r o p s . t imes t amp . wDay ,

114 p r o p s . t imes t amp . wMonth ,

p r o p s . t imes t amp . wYear ,

116 p r o p s . t imes t amp . wHour ,

p r o p s . t imes t amp . wMinute ,

118 p r o p s . t imes t amp . wSecond ,

p r o p s . p a r t n o ) ;

120

t p r i n t f ( T ( ” C o n f i g u r i n g RC200 . . . ” ) ) ;

122 r v a l = RC200ConfigureFPGA (& c t l , CONFIGFILE , &props , &p r o g r e s s ) ;

124 t p r i n t f ( T ( ”\n\ ’ RC200ConfigureFPGA \ ’ r e t u r n e d %d : \”%s \”\n\n ” ) ,

r v a l , RC200TransferMsg [ r v a l ] ) ;

126 }e l s e

128 {t p r i n t f ( T ( ” Could n o t f i n d c o n f i g u r a t i o n f i l e ’%s ’ .\ n ” ) , CONFIGFILE ) ;

130 t p r i n t f ( T ( ” E x i t i n g . . . . \ n ” ) ) ;

r e t u r n 1 ;

132 }

134 /∗∗ I n i t i a l i s e t h e Send P r o t o c o l − t h i s s y n c h r o n i s e s t h e h o s t PC

136 ∗ wi t h t h e RC200 c l i e n t .

∗ /

138 r v a l = R C 2 0 0 I n i t i a l i s e S e n d (& c t l ) ;

t p r i n t f ( T ( ” \ ’ R C 2 0 0 I n i t i a l i s e S e n d \ ’ r e t u r n e d %d : \”%s \”\n\n ” ) ,

140 r v a l , R C 2 0 0 I n i t i a l i s e S e n d M s g [ r v a l ] ) ;

70

Page 80: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE B. MESURE DE CYCLES ET DE FREQUENCES : PROGRAMME C

142

144 s t o p = 1 ;

t p r i n t f ( T ( ” T e s t i n g p e r f o r m a n c e ( t h i s s h o u l d t a k e a b o u t 10 s e c o n d s ) . . . \n ” ) ) ;

146

i = 0 ;

148

150 /∗∗ Envoie du code pour l e p r o c e s s e u r

152 ∗∗ /

154

F i l e = fopen ( ” pgr2 . r c203 ” , ” rb ” ) ;

156 i f ( F i l e ==NULL) e x i t ( 1 ) ;

158 / / o b t a i n f i l e s i z e .

f s e e k ( F i l e , 0 , SEEK END ) ;

160 n b o c t e t s = f t e l l ( F i l e ) ;

162 r ewind ( F i l e ) ;

s i z e T r a n s m i t = 0 ;

164

166 do{f r e a d (& block , 1 , 1 , F i l e ) ;

168 RC200SendBlock (& c t l , &block , 0x01 , &p r o g r e s s ) ;

/ / p r i n t f (”%d\n ” , b l o c k ) ;

170

s i z e T r a n s m i t ++;

172 }w h i l e ( s i z e T r a n s m i t < n b o c t e t s ) ;

f c l o s e ( F i l e ) ;

174 b l o c k =255;

RC200SendBlock (& c t l , &block , 0x01 , &p r o g r e s s ) ;

176 QueryPe r fo rmanceCoun te r (& bt ime ) ; / / T ick de d e p a r t

178 w h i l e ( ! RC200GetBlock(& c t l , b lock1 , 0x01 , &p r o g r e s s ) && ( b lo ck 1 [ 0 ] != 8) )

180

QueryPe r fo rmanceCoun te r (& e t i m e ) ; / / T ick de f i n

182 e t i m e . QuadPar t −= bt ime . QuadPar t ; / / Nombre de t i c k s d ’ e x e c u t i o n

/ / A f f i c h a g e du temps en m i c r o s e c

184 t p r i n t f ( T ( ”Temps de t r a i t e m e n t . . . %I 64 dus . . . \ n ” ) ,

(1000000 ∗ e t i m e . QuadPar t ) / f r e q . QuadPar t ) ;

186

188

g e t c h ( ) ;

190

192

}

71

Page 81: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe C

Commandes FTU2

Les commandes d’acces a la carte RC203 sont de la forme :

RC200CmdFTU <action> [<switch> [parametre] ...] [<fichier>]

C.1 Adressage logique.

Pour acceder a la carte SmartMedia, il est preferable d’utiliser l’adressage logique

a l’adressage physique. En effet l’adressage logique ignore les blocs reserves et ceux

defectueux, le bloc 0 sera donc toujours un bloc valide.

La carte doit etre formatee au prealable selon les specifications Celoxica :

RC200CmdFTU -f

C.2 Exportation du contenu de la carte.

Il est possible de lire le contenu de la carte et d’exporter le contenu dans un fichier.

Deux types d’acces sont possibles : physique et logique.

RC200CmdFTU -r <adresse> -n <taille> <fichier de sortie>

C.2.1 Acces selon un adressage physique.

L’acces a l’adresse physique se fait en specifiant l’option -p au champ indiquant

l’adresse a partir de laquelle le contenu de la carte doit etre copie. Exemple :

RC200CmdFTU -r -p 0x32 -n 0xEA60 donneesPhy.fic

72

Page 82: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE C. COMMANDES FTU2

La taille des donnees a copier, de meme que l’adresse, est en notation hexadecimale

ou decimale.

C.2.2 Acces selon un adressage logique.

La seule difference avec l’adressage physique se situe au niveau de la specification

de l’option de l’adresse. Celle-ci est alors « -l ».

Exemple :

RC200CmdFTU -r -l 0x00 -n 0xEA60 donneesLog.fic

La carte SmartMedia doit evidemment etre formatee au prealable.

C.3 Ecriture sur la carte.

C.3.1 Ecriture de donnees : -d.

L’ecriture de donnees necessite de preciser l’adresse physique ou logique a partir

de laquelle ecrire le contenu d’un fichier passe en parametre. Exemple :

RC200CmdFTU -d -l 0x00 datas

C.3.2 Ecriture d’un fichier BIT : -b.

Comportement identique a l’envoi de donnee mis a part le changement de l’option

« -d » en « -b ». Exemple :

RC200CmdFTU -b -l 0x00 pgr.bit

C.3.3 Configuration de la carte.

L’option « -c » permet la configuration du RC203 avec un fichier BIT fourni en

parametre. Exemple :

RC200CmdFTU -c -l 0x00 config.bit

73

Page 83: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe D

Code Handel-C du processeur

2 # d e f i n e PAL TARGET CLOCK RATE 25175000

# i n c l u d e ” p a l m a s t e r . hch ”

4

6 s t a t i c macro ex p r ClockRa te = PAL ACTUAL CLOCK RATE ;

8

/∗10 ∗ P a r a m e t e r i s a t i o n

∗ /

12 # d e f i n e DW 32 /∗ Data wid th ∗ /

# d e f i n e RAM AW 4 /∗ Width o f RAM a d d r e s s bus ( d a t a ) ∗ /

14 # d e f i n e ROM AW 5 /∗ Width o f ROM a d d r e s s bus ( code ) ∗ /

# d e f i n e OPCW 4 /∗ Op−code wid th ∗ /

16 # d e f i n e OPRW 5 /∗ Operand wid th ∗ /

18 /∗∗ The opcodes

20 ∗ /

# d e f i n e HALT 0

22 # d e f i n e LOAD 1

# d e f i n e LOADI 2

24 # d e f i n e STORE 3

# d e f i n e ADD 4

26 # d e f i n e SUB 5

# d e f i n e JUMP 6

28 # d e f i n e JUMPNZ 7

# d e f i n e INPUT 8

30 # d e f i n e OUTPUT 9

32 /∗∗ The a s s e m b l e r macro

34 ∗ /

# d e f i n e asm ( opc , opr ) ( opc + ( opr << OPCW) )

36

74

Page 84: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE D. CODE HANDEL-C DU PROCESSEUR

/∗38 ∗ ROM program d a t a

∗ /

40 rom u n s i g n e d i n t program [ ] =

{42 asm (LOADI , 0 ) , /∗ 0 ∗ / /∗ Get a z e r o ∗ /

asm (STORE , 0 ) , /∗ 1 ∗ / /∗ S t o r e t h i s ∗ /

44 asm (LOADI , 1 ) , /∗ 0 ∗ / /∗ Get a one ∗ /

asm (STORE , 1 ) , /∗ 1 ∗ / /∗ S t o r e t h i s ∗ /

46 asm (STORE , 3 ) , /∗ 2 ∗ / /∗ . . . ∗ /

asm ( INPUT , 0 ) , /∗ 3 ∗ / /∗ Read v a l u e from i n p u t ∗ /

48 asm (STORE , 2 ) , /∗ 4 ∗ / /∗ S t o r e t h i s ∗ /

asm (LOAD, 1 ) , /∗ 5 ∗ / /∗ Loop e n t r y p o i n t ∗ /

50 asm (ADD, 0 ) , /∗ 6 ∗ / /∗ Make a f i b number ∗ /

asm (STORE , 0 ) , /∗ 7 ∗ / /∗ S t o r e i t ∗ /

52 asm (ADD, 1 ) , /∗ 8 ∗ / /∗ Make a f i b number ∗ /

asm (STORE , 1 ) , /∗ 9 ∗ / /∗ S t o r e i t ∗ /

54 asm (LOAD, 2 ) , /∗ a ∗ / /∗ Decrement c o u n t e r ∗ /

asm (SUB, 3 ) , /∗ b ∗ / /∗ . . . ∗ /

56 asm (JUMPNZ, 6 ) , /∗ c ∗ / /∗ Repea t i f n o t z e r o ∗ /

asm (LOAD, 1 ) , /∗ d ∗ / /∗ Load t h e f i n a l answer ∗ /

58 asm (OUTPUT, 0 ) , /∗ e ∗ / /∗ Outpu t i t ∗ /

asm (HALT, 0 ) /∗ f ∗ / /∗ E x i t ∗ /

60 } ;

62 /∗∗ P r o t o t y p e s

64 ∗ /

s t a t i c macro p ro c p r o c e s s o r ( i n p u t , o u t p u t ) ;

66

/∗68 ∗ Main program

∗ /

70 vo id main ( vo id )

{72

/∗74 ∗ P r o c e s s o r i n p u t and o u t p u t c h a n n e l s

∗ /

76 chan u n s i g n e d canaux [2∗NBPROC ] ;

u n s i g n e d v a l u e ;

78

/∗80 ∗ Run t h e p r o c e s s o r : r e q u e s t t h e (1+2∗5)=11 t h F i b o n n a c i

∗ number . Th i s i s r e t u r n e d and s t o r e d i n ” v a l u e ” , and

82 ∗ s h o u l d be 8 9 .

∗ /

84 p a r

{86 p r o c e s s o r ( canaux [ 0 ] , canaux [ 1 ] ) ;

canaux [ 0 ] ! 5 ;

88 {canaux [ 1 ] ? v a l u e ;

90 }

75

Page 85: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE D. CODE HANDEL-C DU PROCESSEUR

}92

}94

96 /∗∗ The p r o c e s s o r

98 ∗ /

s t a t i c macro p ro c p r o c e s s o r ( i n p u t , o u t p u t )

100 {/∗

102 ∗ RAM f o r p r o c e s s o r

∗ /

104 ram u n s i g n e d i n t DW d a t a [1 << RAM AW] ;

106 /∗∗ P r o c e s s o r r e g i s t e r s

108 ∗ /

u n s i g n e d i n t ROM AW pc ; /∗ Program c o u n t e r ∗ /

110 u n s i g n e d i n t (OPCW + OPRW) i r ; /∗ I n s t r u c t i o n r e g i s t e r ∗ /

u n s i g n e d i n t DW x ; /∗ Accumula to r ∗ /

112

/∗114 ∗ Macros t o e x t r a c t opcode and ope rand f i e l d s

∗ /

116 macro ex p r opcode = ( i r <− OPCW) ;

macro ex p r ope rand = ( i r \\ OPCW) ;

118

pc = 0 ;

120

/∗122 ∗ P r o c e s s o r lo op

∗ /

124 do

{126 /∗

∗ F e t c h

128 ∗ /

p a r

130 {i r = program [ pc ] ;

132 pc ++;

}134

/∗136 ∗ Decode and e x e c u t e

∗ /

138 s w i t c h ( opcode )

{140 c a s e HALT : b r e a k ;

c a s e LOAD : x = d a t a [ ope rand <− RAM AW] ; b r e a k ;

142 c a s e LOADI : x = 0 @ operand ; b r e a k ;

c a s e STORE : d a t a [ ope rand <− RAM AW] = x ; b r e a k ;

144 c a s e ADD : x += d a t a [ ope rand <− RAM AW] ; b r e a k ;

76

Page 86: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE D. CODE HANDEL-C DU PROCESSEUR

c a s e SUB : x −= d a t a [ ope rand <− RAM AW] ; b r e a k ;

146 c a s e JUMP : pc = ope rand <− ROM AW; b r e a k ;

c a s e JUMPNZ : i f ( x != 0) pc = ope rand <− ROM AW; b r e a k ;

148 c a s e INPUT : i n p u t ? x ; b r e a k ;

c a s e OUTPUT : o u t p u t ! x ; b r e a k ;

150 d e f a u l t : w h i l e ( 1 ) d e l a y ; /∗ unknown opcode ∗ /

}152 } w h i l e ( opcode != HALT ) ;

}

77

Page 87: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe E

Code Handel-C du processeurutilisant les micro instructions

1 # d e f i n e PAL TARGET CLOCK RATE 25175000

# i n c l u d e ” p a l m a s t e r . hch ”

3 # i n c l u d e ” p a l c o n s o l e . hch ”

5 /∗∗ P a r a m e t e r i s a t i o n

7 ∗ /

# d e f i n e DW 32 /∗ Data wid th ∗ /

9 # d e f i n e RAM AW 8 /∗ Width o f RAM a d d r e s s bus ( d a t a ) ∗ /

# d e f i n e ROM AW 8 /∗ Width o f ROM a d d r e s s bus ( code ) ∗ /

11 # d e f i n e OPCW 8 /∗ Op−code wid th ∗ /

# d e f i n e OPRW 12 /∗ Operand wid th ∗ /

13 # d e f i n e NBPROCL 2 /∗ nombre de p r o c e s s e u r p a r l i g n e ∗ /

15 # d e f i n e MICROI AW 34 /∗ l a r g e u r des m i c r o i n s t r u c t i o n s ∗ /

# d e f i n e MICROM AW 9 /∗ t a i l l e de l ’ a d r e s s a g e micro−memoire ∗ /

17 # d e f i n e MICROOP AW 5 /∗ l a r g e u r du micro o p e r a t e u r ( l i e au nb de p t de c o n t r o l e s ) ∗ /

# d e f i n e MIC AW 16 /∗ l a r g e u r de l a mic ∗ /

19 # d e f i n e MIR AW 34 /∗ l a r g e u r de l a mir ∗ /

# d e f i n e MICRO LOCALMEM AW 4 /∗ l a r g e u r du nombre de

21 r e g i s t r e s de l a ram du micro−c o n t r o l e u r ∗ /

23

/∗25 ∗ The opcodes

∗ /

27 # d e f i n e HALT 99

29 /∗∗ The a s s e m b l e r macro

31 ∗ /

# d e f i n e asm ( opc , opr ) ( opc + ( opr << OPCW) )

33

78

Page 88: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

35 /∗∗ P r o t o t y p e s

37 ∗ /

s t a t i c macro p ro c R e a d P a r a l l e l ( p r i n t , program ) ;

39 s t a t i c macro p ro c p r o c e s s o r ( canaux , p r i n t , program , microMem , X ) ;

s t a t i c macro p ro c processo rRamExt ( canaux , p r i n t , program , microMem , X ) ;

41 s t a t i c macro p ro c d a t a s ( i n p u t , d a t a s I n , p r i n t ) ;

s t a t i c macro p ro c RunConsole ( p r i n t I n ) ;

43 s t a t i c macro p ro c RAM1ToParal lel ( Addr , p r i n t ) ;

s t a t i c macro p ro c Paral lelToRAM0 ( Addr , p r i n t ) ;

45 s t a t i c macro p ro c compteur ( i , c o n d i t i o n ) ;

s t a t i c macro p ro c m i c r o C o n t r o l e u r ( canaux , microMem , da ta , pc , acc , end , s e m T r a i t e m e n t ) ;

47 s t a t i c macro p ro c mic roCon t ro l eu rRamExt ( canaux , microMem , da t a , pc , acc , end , s e m T r a i t e m e n t ) ;

macro e xp r P a r a l l e l P o r t = P a l R C 2 0 0 P a r a l l e l P o r t ;

49

/ / Hor loge

51 s t a t i c macro ex p r ClockRa te = PAL ACTUAL CLOCK RATE ;

53 /∗∗ Main program

55 ∗ /

vo id main ( vo id )

57 {/ / Canaux d ’ e n t r e e s e t de s o r t i e s des p r o c e s s e u r s

59 chan u n s i g n e d 32 canauxP0 [ 5 ] ;

/∗ chan u n s i g n e d 32 canauxP1 [ 5 ] ;

61 chan u n s i g n e d 32 canauxP2 [ 5 ] ;

chan u n s i g n e d 32 canauxP3 [ 5 ] ; ∗ /

63

/ / Canaux d ’ a f f i c h a g e

65 chan u n s i g n e d DW p r i n t [ 4 ] ;

67 u n s i g n e d 20 Addr ;

ram u n s i g n e d i n t program0 [ 2 5 5 ] ;

69

s t a t i c ram u n s i g n e d i n t MICROI AW microMem [ ] ={71 6442450979 ,

8590458880 ,

73 0 ,

. . . e t c . . .

75 0 ,

10737418240 ,

77 0 ,

11811160064

79 } ;

Addr = 0 ;

81 p a r

{83

RunConsole ( p r i n t ) ; / / Lancement du m u l t i p l e x e u r d ’ a f f i c h a g e

85 P a l D a t a P o r t R u n ( P a r a l l e l P o r t , C lockRa te ) ;

RC200PL1RAM0Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM0

87 RC200PL1RAM1Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM1

79

Page 89: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

seq {89 P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

R e a d P a r a l l e l ( p r i n t [ 3 ] , program0 ) ;

91 p a r {p r o c e s s o r ( canauxP0 , p r i n t [ 0 ] , program0 , microMem , 0 ) ;

93 /∗ p r o c e s s o r ( canauxP1 , p r i n t [ 1 ] , program0 , microMem , 1 ) ;

p r o c e s s o r ( canauxP2 , p r i n t [ 2 ] , program0 , microMem , 2 ) ;

95 p r o c e s s o r ( canauxP3 , p r i n t [ 3 ] , program0 , microMem , 3 ) ; ∗ /

}97 }

}99

}101

s t a t i c macro p ro c compteur ( i , c o n d i t i o n ){103 w h i l e ( c o n d i t i o n ) i ++;

}105

/∗107 ∗ P r o c e s s e u r s a n s a c c e s a l a RAM e x t e r n e

∗ /

109 s t a t i c macro p ro c p r o c e s s o r ( canaux , p r i n t , program , microMem , X)

{111

/ / u n s i g n e d i n t 1 s i g T r a i t e m e n t ;

113 / / chan u n s i g n e d i n t 1 n e w I n s t r ;

u n s i g n e d i n t 1 newInstrOK ;

115 /∗∗ R e g i s t r e s du p r o c e s s e u r

117 ∗ /

u n s i g n e d i n t ROM AW pc ; /∗ Compteur de programme

∗ /

119 u n s i g n e d i n t (OPCW + 2∗OPRW) i r ; /∗ R e g i s t r e d ’ i n s t r u c t i o n

∗ /

u n s i g n e d i n t DW acc ; /∗ Accumula teu r ∗ /

121 u n s i g n e d i n t 1 end ;

123 /∗∗ RAM du p r o c e s s e u r

125 ∗ /

mpram Ram1 {127 ram <u n s i g n e d DW> p1 [1 << RAM AW] ;

ram <u n s i g n e d DW> p2 [1 << RAM AW] ;

129 } ;

mpram Ram1 d a t a wi t h { b l o c k = ”BlockRAM” } ;

131

w h i l e ( 1 ){133 / / i n i t i a l i s a t i o n

p a r {135 pc = 0 ;

acc = 0 ;

137 end = 0 ;

newInstrOK = 0 ;

139 / / s i g T r a i t e m e n t = 0 ;

80

Page 90: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

}141 p a r {

m i c r o C o n t r o l e u r ( canaux , microMem , da ta , pc , acc , end , newInstrOK ) ;

143 / / Boucle du p r o c e s s e u r

do

145 {/ / Recherche de l ’ i n s t r u c t i o n a e x e c u t e r

147 i r = program [ pc ] <−(OPCW + 2∗OPRW) ;

/ / t r a n s m i s s i o n de l ’ i n s t r u c t i o n au micro−c o n t r o l e u r

149 canaux [ 0 ] ! i r ;

/ / n e w I n s t r ? newInstrOK ;

151 w h i l e ( ! newInstrOK ) d e l a y ;

newInstrOK = 0 ;

153 p r i n t ! acc ;

155 } w h i l e ( ! end ) ;

}157 }

}159 /∗

∗ P r o c e s s e u r avec a c c e s a l a RAM e x t e r n e

161 ∗ /

s t a t i c macro p ro c processo rRamExt ( canaux , p r i n t , program , microMem , X)

163 {

165 / / u n s i g n e d i n t 1 s i g T r a i t e m e n t ;

chan i n t 1 n e w I n s t r ;

167 /∗∗ R e g i s t r e s du p r o c e s s e u r

169 ∗ /

u n s i g n e d i n t ROM AW pc ; /∗ Compteur de programme

∗ /

171 u n s i g n e d i n t (OPCW + 2∗OPRW) i r ; /∗ R e g i s t r e d ’ i n s t r u c t i o n

∗ /

u n s i g n e d i n t DW acc ; /∗ Accumula teu r ∗ /

173 u n s i g n e d i n t 1 end ;

175 /∗∗ RAM du p r o c e s s e u r

177 ∗ /

mpram Ram1 {179 ram <u n s i g n e d DW> p1 [1 << RAM AW] ;

ram <u n s i g n e d DW> p2 [1 << RAM AW] ;

181 } ;

mpram Ram1 d a t a wi t h { b l o c k = ”BlockRAM” } ;

183

w h i l e ( 1 ){185 / / i n i t i a l i s a t i o n

p a r {187 pc = 0 ;

acc = 0 ;

189 end = 0 ;

s i g T r a i t e m e n t = 0 ;

191 }

81

Page 91: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

p a r {193 microCon t ro l eu rRamExt ( canaux , microMem , da ta , pc , acc , end , n e w I n s t r ) ;

/ / Boucle du p r o c e s s e u r

195 do

{197 / / Recherche de l ’ i n s t r u c t i o n a e x e c u t e r

i r = program [ pc ] <−(OPCW + 2∗OPRW) ;

199 / / t r a n s m i s s i o n de l ’ i n s t r u c t i o n au micro−c o n t r o l e u r

canaux [ 0 ] ! i r ;

201 w h i l e ( ! s i g T r a i t e m e n t ) d e l a y ;

s i g T r a i t e m e n t = 0 ;

203 p r i n t ! acc ;

205 } w h i l e ( ! end ) ;

}207 }

}209

211 s t a t i c macro p ro c mic roCon t ro l eu rRamExt ( canaux ,

microMem ,

213 mainMemory ,

pc ,

215 acc ,

end ,

217 s i g T r a i t e m e n t ){/∗

219 ∗ A r c h i t e c t u r e du micro−c o n t r o l e u r

∗ /

221 u n s i g n e d i n t MIC AW mic ; /∗ compteur de micro i n s t r u c t i o n s ∗ /

u n s i g n e d i n t MIR AW mir ; /∗ r e g i s t r e de micro i n s t r u c t i o n s ∗ /

223 u n s i g n e d i n t DW opL1 ; /∗ op e r ande1 l o c a l e ∗ /

u n s i g n e d i n t DW opL2 ; /∗ op e r ande2 l o c a l e ∗ /

225 u n s i g n e d i n t OPRW opP1 ; /∗ op e r ande1 p r i n c i p a l e ∗ /

u n s i g n e d i n t OPRW opP2 ; /∗ op e r ande2 p r i n c i p a l e ∗ /

227 mpram Ram2 {ram <u n s i g n e d DW> p1 [1 << MICRO LOCALMEM AW ] ;

229 ram <u n s i g n e d DW> p2 [1 << MICRO LOCALMEM AW ] ;

} ;

231 mpram Ram2 d a t a wi t h { b l o c k = ”BlockRAM” } ; /∗ Memoire ram du micro−c o n t r o l e u r ∗ /

233 /∗∗ V a r i a b l e s de f o n c t i o n n e m e n t

235 ∗ /

u n s i g n e d 36 dataRam ;

237 u n s i g n e d i n t MICROOP AW microOp ; /∗ Micro−o p e r a t e u r ∗ /

u n s i g n e d i n t (OPCW + 2∗OPRW) i n s t r u c t i o n ; /∗ Macro i n s t r u c t i o n

∗ /

239 u n s i g n e d i n t DW t Res [DW] , sou rce , m u l t i p l i e u r , y ;

/ / u n s i g n e d i n t MICRO LOCALMEM AW d a t a a d d r p 1 , d a t a a d d r p 2 ;

241 / / u n s i g n e d i n t RAM AW mmaddrp1 , mmaddrp2 ;

u n s i g n e d i n t 3 c a n a l D e s t , c a n a l S o u r c e ;

243 /∗∗ Macros d ’ e x t r a c t i o n de l ’ o p e r a t e u r e t des l ’ op e r a n d e de l ’ i n s t r u c t i o n

82

Page 92: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

245 ∗ /

macro ex p r opcode = ( i n s t r u c t i o n \\ (OPRW+OPRW) ) ;

247 macro ex p r ope rand2 = ( i n s t r u c t i o n <− OPRW) ;

macro ex p r ope rand1 = ( i n s t r u c t i o n >> OPRW)<−OPRW;

249

/ / Decodage de l a micro− i n s t r u c t i o n

251 macro ex p r t y p e = mir \\ (MICROI AW − 1)<−1;

macro ex p r a c t i o n = ( mir \\ (MICROI AW − 3))<−2;

253 macro ex p r cond = ( mir \\ (MICROI AW − 4))<−1;

macro ex p r m i c r o I n s t r = mir<−(MICROI AW − 4 ) ;

255

macro ex p r i n p u t = canaux [ 0 ] ;

257 / / R e c e p t i o n d ’ une i n s t r u c t i o n

p a r {259 canaux [ 0 ] ? i n s t r u c t i o n ;

end = 0 ;

261 }

263 p a r {opP1 = operand1 ;

265 opP2 = operand2 ;

opL1 = 0 ;

267 opL2 = 0 ;

/ / Chargement de l ’ o p e r a t e u r en MIC

269 mic = 0@opcode ;

}271 w h i l e ( ! end ){

/ / L e c t u r e de l a micro− i n s t r u c t i o n s e l o n l a mic

273 mir = microMem [ mic<−MICROM AW] ;

/ / Comportement de l a micro− i n s t r u c t i o n

275 i f ( t y p e == 1){/ / A p p l i c a t i o n des p o i n t s de c o n t r o l e

277 p a r ( i =0 ; i < MICROI AW − 4 ; i = i +1){/ / s eq {

279 i f ( ( m i c r o I n s t r >>i )<−1){s w i t c h ( i ){

281 c a s e 0 :

acc = 0@opP1 ;

283 b r e a k ;

c a s e 1 :

285 acc = 0@opP2 ;

b r e a k ;

287 c a s e 2 :

acc = opL1 ;

289 b r e a k ;

c a s e 3 :

291 acc = opL2 ;

b r e a k ;

293 c a s e 4 :

opL1 = acc ;

295 b r e a k ;

c a s e 5 :

297 opL2 = acc ;

b r e a k ;

83

Page 93: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

299 c a s e 6 :

mainMemory . p1 [ opL1<−RAM AW] = acc ;

301 b r e a k ;

c a s e 7 :

303 mainMemory . p2 [ opL2<−RAM AW] = acc ;

b r e a k ;

305 c a s e 8 :

d a t a . p1 [ opL1<−MICRO LOCALMEM AW] = acc ;

307 b r e a k ;

c a s e 9 :

309 d a t a . p2 [ opL2<−MICRO LOCALMEM AW] = acc ;

b r e a k ;

311 c a s e 1 0 :

opL1 = d a t a . p1 [ opL1<−MICRO LOCALMEM AW ] ;

313 b r e a k ;

c a s e 1 1 :

315 opL2 = d a t a . p2 [ opL2<−MICRO LOCALMEM AW ] ;

b r e a k ;

317 c a s e 1 2 :

opL2 = 0@opP2 ;

319 b r e a k ;

c a s e 1 3 :

321 opL1 = 0@opP1 ;

b r e a k ;

323 c a s e 1 4 :

canaux [ opL1<−3] ! acc ;

325 b r e a k ;

c a s e 1 5 :

327 canaux [ opL1<−3] ? acc ;

b r e a k ;

329 c a s e 1 6 :

opL1 = mainMemory . p1 [ opL1<−RAM AW] ;

331 b r e a k ;

c a s e 1 7 :

333 opL2 = mainMemory . p2 [ opL2<−RAM AW] ;

b r e a k ;

335 c a s e 1 8 :

p a r {337 / / Formatage de l ’ acc en 36 b i t s

dataRam = 0@acc ;

339 / / P o s i t i o n n e m e n t de l ’ a d r e s s e d ’ e c r i t u r e

RC200PL1RAM1SetWriteAddress ( opL1 <−20);

341 }/ / E c r i t u r e dans l a ram dataRam = opL1 ;

343 RC200PL1RAM1Write ( dataRam ) ;

b r e a k ;

345 c a s e 1 9 :

/ / L e c t u r e de l a ram a l ’ a d r e s s e de l ’ acc

347 RC200PL1RAM0SetReadAddress ( opL1 <−20);

RC200PL1RAM0Read(&dataRam ) ;

349 acc = dataRam<−DW;

b r e a k ;

351 c a s e 2 0 :

acc = opL1 + opL2 ;

84

Page 94: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

353 b r e a k ;

c a s e 2 1 :

355 p a r {acc = 0 ;

357 s o u r c e = opL1 ;

m u l t i p l i e u r = opL2 ;

359 }p a r ( i =0 ; i < DW; i ++){

361 seq {u n s i g n e d i n t 1 b i t ;

363 b i t = ( m u l t i p l i e u r >> i )<−1;

i f ( b i t == 1) tR es [0@i ] = 0@( s o u r c e << i ) ;

365 e l s e tRes [0@i ] = 0 ;

}367 }

seq ( i =0 ; i<DW; i ++){369 acc = acc + tRes [ i ] ;

}371 b r e a k ;

c a s e 2 2 :

373 acc = opL1 − opL2 ;

b r e a k ;

375 c a s e 2 3 :

acc = 0@( opL1<< opL2<−6);

377 b r e a k ;

c a s e 2 4 :

379 acc = 0@( opL1 >> opL2<−6);

b r e a k ;

381 c a s e 2 5 :

i f ( ( cond = = 1 ) | | ( acc > 0 ) ){383 pc = opL1<−ROM AW;

}385 b r e a k ;

c a s e 2 6 :

387 opL1 = 0@opP2 ;

b r e a k ;

389 c a s e 2 7 :

opL2 = 0@opP1 ;

391 b r e a k ;

c a s e 2 8 :

393 i f ( opL1 > opL2 ) acc =1;

e l s e acc = 0 ;

395 b r e a k ;

c a s e 2 9 :

397 p a r {y =0;

399 seq {c a n a l D e s t = ( i n s t r u c t i o n >> 29)<−3;

401 s w i t c h ( c a n a l D e s t ){c a s e 0 :

403 c a n a l S o u r c e = 2 ;

b r e a k ;

405 c a s e 1 :

c a n a l S o u r c e = 3 ;

85

Page 95: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

407 b r e a k ;

c a s e 2 :

409 c a n a l S o u r c e = 0 ;

b r e a k ;

411 c a s e 3 :

c a n a l S o u r c e = 1 ;

413 b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ;

415 }}

417 }p a r {

419 canaux [ c a n a l D e s t ] ! acc ;

canaux [ c a n a l S o u r c e ] ? y ;

421 }acc = y ;

423 b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ; /∗ unknown opcode ∗ /

425 }}

427 / / }}

429 mic = mic + 1 ;

}431 e l s e i f ( t y p e == 0){ / / M o d i f i c a t i o n de l a mic

s w i t c h ( a c t i o n ){433 c a s e 0 : / / No u v e l l e i n s t r u c t i o n : i f e t c h

pc = pc +1;

435 p a r {s i g T r a i t e m e n t = 1 ;

437 i n p u t ? i n s t r u c t i o n ;

}439 p a r {

opP1 = operand1 ;

441 opP2 = operand2 ;

opL1 = 0 ;

443 opL2 = 0 ;

seq {445 i f ( opcode != HALT) mic = 0@opcode ;

e l s e {447 p a r {

end = 1 ; / / f i n du programme

449 acc = 0 ;

}451 }

}453 }

b r e a k ;

455 c a s e 1 : / / I n c r e m e n t a t i o n de l a mic

mic = mic + 1 ; b r e a k ;

457 c a s e 2 : / / Sau t c o n d i t i o n n e l

i f ( ( cond )&&( acc >0)){459 mic = ( m i c r o I n s t r )<−MIC AW;

}

86

Page 96: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

461 b r e a k ;

c a s e 3 : / / Sau t i n c o n d i t i o n n e l

463 mic = ( m i c r o I n s t r )<−MIC AW; b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ;

465 }}

467

}469 s i g T r a i t e m e n t = 1 ;

}471

s t a t i c macro p ro c m i c r o C o n t r o l e u r ( canaux ,

473 microMem ,

mainMemory ,

475 pc ,

acc ,

477 end ,

newInstrOK ){479 /∗

∗ A r c h i t e c t u r e du micro−c o n t r o l e u r

481 ∗ /

u n s i g n e d i n t MIC AW mic ; /∗ compteur de micro i n s t r u c t i o n s ∗ /

483 u n s i g n e d i n t MIR AW mir ; /∗ r e g i s t r e de micro i n s t r u c t i o n s ∗ /

u n s i g n e d i n t DW opL1 ; /∗ op e r ande1 l o c a l e ∗ /

485 u n s i g n e d i n t DW opL2 ; /∗ op e r ande2 l o c a l e ∗ /

u n s i g n e d i n t OPRW opP1 ; /∗ op e r ande1 p r i n c i p a l e ∗ /

487 u n s i g n e d i n t OPRW opP2 ; /∗ op e r ande2 p r i n c i p a l e ∗ /

mpram Ram2 {489 ram <u n s i g n e d DW> p1 [1 << MICRO LOCALMEM AW ] ;

ram <u n s i g n e d DW> p2 [1 << MICRO LOCALMEM AW ] ;

491 } ;

mpram Ram2 d a t a wi t h { b l o c k = ”BlockRAM” } ; /∗ Memoire ram du micro−c o n t r o l e u r ∗ /

493

/∗495 ∗ V a r i a b l e s de f o n c t i o n n e m e n t

∗ /

497 u n s i g n e d 36 dataRam ;

u n s i g n e d i n t MICROOP AW microOp ; /∗ Micro−o p e r a t e u r ∗ /

499 u n s i g n e d i n t (OPCW + 2∗OPRW) i n s t r u c t i o n ; /∗ Macro i n s t r u c t i o n

∗ /

u n s i g n e d i n t DW t Res [DW] , sou rce , m u l t i p l i e u r , y ;

501 u n s i g n e d i n t 3 c a n a l D e s t , c a n a l S o u r c e ;

/∗503 ∗ Macros d ’ e x t r a c t i o n de l ’ o p e r a t e u r e t des l ’ op e r a n d e de l ’ i n s t r u c t i o n

∗ /

505 macro ex p r opcode = ( i n s t r u c t i o n \\ (OPRW+OPRW) ) ;

macro ex p r ope rand2 = ( i n s t r u c t i o n <− OPRW) ;

507 macro ex p r ope rand1 = ( i n s t r u c t i o n >> OPRW)<−OPRW;

509 / / Decodage de l a micro− i n s t r u c t i o n

macro ex p r t y p e = mir \\ (MICROI AW − 1)<−1;

511 macro ex p r a c t i o n = ( mir \\ (MICROI AW − 3))<−2;

macro ex p r cond = ( mir \\ (MICROI AW − 4))<−1;

513 macro ex p r m i c r o I n s t r = mir<−(MICROI AW − 4 ) ;

87

Page 97: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

515 macro ex p r i n p u t = canaux [ 0 ] ;

/ / R e c e p t i o n d ’ une i n s t r u c t i o n

517 p a r {canaux [ 0 ] ? i n s t r u c t i o n ;

519 end = 0 ;

}521

p a r {523 opP1 = operand1 ;

opP2 = operand2 ;

525 opL1 = 0 ;

opL2 = 0 ;

527 / / Chargement de l ’ o p e r a t e u r en MIC

mic = 0@opcode ;

529 }w h i l e ( ! end ){

531 / / L e c t u r e de l a micro− i n s t r u c t i o n s e l o n l a mic

mir = microMem [ mic<−MICROM AW] ;

533 / / Comportement de l a micro− i n s t r u c t i o n

i f ( t y p e == 1){535 / / A p p l i c a t i o n des p o i n t s de c o n t r o l e

p a r ( i =0 ; i < MICROI AW − 4 ; i = i +1){537 i f ( ( m i c r o I n s t r >>i )<−1){

s w i t c h ( i ){539 c a s e 0 :

acc = 0@opP1 ;

541 b r e a k ;

c a s e 1 :

543 acc = 0@opP2 ;

b r e a k ;

545 c a s e 2 :

acc = opL1 ;

547 b r e a k ;

c a s e 3 :

549 acc = opL2 ;

b r e a k ;

551 c a s e 4 :

opL1 = acc ;

553 b r e a k ;

c a s e 5 :

555 opL2 = acc ;

b r e a k ;

557 c a s e 6 :

mainMemory . p1 [ opL1<−RAM AW] = acc ;

559 b r e a k ;

c a s e 7 :

561 mainMemory . p2 [ opL2<−RAM AW] = acc ;

b r e a k ;

563 c a s e 8 :

d a t a . p1 [ opL1<−MICRO LOCALMEM AW] = acc ;

565 b r e a k ;

c a s e 9 :

567 d a t a . p2 [ opL2<−MICRO LOCALMEM AW] = acc ;

88

Page 98: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

b r e a k ;

569 c a s e 1 0 :

opL1 = d a t a . p1 [ opL1<−MICRO LOCALMEM AW ] ;

571 b r e a k ;

c a s e 1 1 :

573 opL2 = d a t a . p2 [ opL2<−MICRO LOCALMEM AW ] ;

b r e a k ;

575 c a s e 1 2 :

opL2 = 0@opP2 ;

577 b r e a k ;

c a s e 1 3 :

579 opL1 = 0@opP1 ;

b r e a k ;

581 c a s e 1 4 :

canaux [ opL1<−3] ! acc ;

583 b r e a k ;

c a s e 1 5 :

585 canaux [ opL1<−3] ? acc ;

b r e a k ;

587 c a s e 1 6 :

opL1 = mainMemory . p1 [ opL1<−RAM AW] ;

589 b r e a k ;

c a s e 1 7 :

591 opL2 = mainMemory . p2 [ opL2<−RAM AW] ;

b r e a k ;

593 c a s e 2 0 :

acc = opL1 + opL2 ;

595 b r e a k ;

c a s e 2 1 :

597 p a r {acc = 0 ;

599 s o u r c e = opL1 ;

m u l t i p l i e u r = opL2 ;

601 }p a r ( i =0 ; i < DW; i ++){

603 seq {u n s i g n e d i n t 1 b i t ;

605 b i t = ( m u l t i p l i e u r >> i )<−1;

i f ( b i t == 1) tR es [0@i ] = 0@( s o u r c e << i ) ;

607 e l s e tRes [0@i ] = 0 ;

}609 }

seq ( i =0 ; i<DW; i ++){611 acc = acc + tRes [ i ] ;

}613 b r e a k ;

c a s e 2 2 :

615 acc = opL1 − opL2 ;

b r e a k ;

617 c a s e 2 3 :

acc = 0@( opL1<< opL2<−6);

619 b r e a k ;

c a s e 2 4 :

621 acc = 0@( opL1 >> opL2<−6);

89

Page 99: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

b r e a k ;

623 c a s e 2 5 :

i f ( ( cond = = 1 ) | | ( acc > 0 ) ){625 pc = opL1<−ROM AW − 1 ;

}627 b r e a k ;

c a s e 2 6 :

629 opL1 = 0@opP2 ;

b r e a k ;

631 c a s e 2 7 :

opL2 = 0@opP1 ;

633 b r e a k ;

c a s e 2 8 :

635 i f ( opL1 > opL2 ) acc =1;

e l s e acc = 0 ;

637 b r e a k ;

c a s e 2 9 :

639 c a n a l D e s t = ( ( i n s t r u c t i o n >> 29)<−3)+1;

canaux [ c a n a l D e s t ] ! acc ;

641 b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ; /∗ unknown opcode ∗ /

643 }}

645 / / }}

647 mic = mic + 1 ;

}649 e l s e i f ( t y p e == 0){ / / M o d i f i c a t i o n de l a mic

s w i t c h ( a c t i o n ){651 c a s e 0 : / / No u v e l l e i n s t r u c t i o n : i f e t c h

pc = pc +1;

653 p a r {newInstrOK = 1 ; / / n e w I n s t r ! 1 ; / / s i g T r a i t e m e n t = 1 ;

655 i n p u t ? i n s t r u c t i o n ;

}657 p a r {

opP1 = operand1 ;

659 opP2 = operand2 ;

opL1 = 0 ;

661 opL2 = 0 ;

seq {663 i f ( opcode != HALT) mic = 0@opcode ;

e l s e {665 p a r {

end = 1 ; / / f i n du programme

667 acc = 0 ;

}669 }

}671 }

b r e a k ;

673 c a s e 1 : / / I n c r e m e n t a t i o n de l a mic

mic = mic + 1 ; b r e a k ;

675 c a s e 2 : / / Sau t c o n d i t i o n n e l

90

Page 100: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

i f ( ( cond )&&( acc >0)){677 mic = ( m i c r o I n s t r )<−MIC AW;

}679 b r e a k ;

c a s e 3 : / / Sau t i n c o n d i t i o n n e l

681 mic = ( m i c r o I n s t r )<−MIC AW; b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ;

683 }}

685

}687 newInstrOK = 1 ; / / n e w I n s t r ! 1 ; / / s i g T r a i t e m e n t = 1 ;

}689

/∗691 ∗ M u l t i p l e x e u r d ’ a f f i c h a g e

∗693 ∗ /

s t a t i c macro p ro c RunConsole ( p r i n t )

695 {s t a t i c u n s i g n e d 32 X;

697 u n s i g n e d i n t 32 from ;

u n s i g n e d i n t 32 v a l ;

699 u n s i g n e d i n t 32 cmpt ;

s t a t i c ram u n s i g n e d c h a r S t r i n g [ 2 5 6 ] =

701 ” Proc : ” ;

s t a t i c ram u n s i g n e d c h a r S t r i n g 2 [ 2 5 6 ] =

703 ” V a l e u r : ” ;

P a l C o n s o l e ∗C o n s o l e P t r ;

705 P a l V i d e o O u t R e q u i r e ( 1 ) ;

cmpt = 0 ;

707 p a r

{709 w h i l e ( 1 ){

P a l C o n s o l e E n a b l e ( C o n s o l e P t r ) ;

711 p r i a l t

{713 c a s e p r i n t [ 0 ] ? v a l :

from = 0 ;

715 b r e a k ;

c a s e p r i n t [ 1 ] ? v a l :

717 from = 1 ;

cmpt ++;

719 b r e a k ;

c a s e p r i n t [ 2 ] ? v a l :

721 from = 2 ;

b r e a k ;

723 c a s e p r i n t [ 3 ] ? v a l : / / c a n a l de debuggage ne v e n a n t pas d ’ un p r o c e s s e u r

from = 1 0 ;

725 b r e a k ;

}727 P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g ) ;

P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , from ) ;

729 X = 0@val ;

91

Page 101: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g 2 ) ;

731 P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , X ) ;

P a l C o n s o l e P u t C h a r ( C o n s o l e P t r , ’\n ’ ) ;

733 }

735 PalConso leRun (& C o n s o l e P t r , PAL CONSOLE FONT NORMAL,

PalVideoOutOpt imalCT ( ClockRa te ) , C lockRate ) ;

737 }

739 }s t a t i c macro p ro c RAM1ToParal lel ( Addr , p r i n t )

741 {u n s i g n e d 20 j ;

743 u n s i g n e d 36 d a t ;

j =0 ;

745 w h i l e ( j < Addr ){RC200PL1RAM1SetReadAddress ( j ) ;

747 RC200PL1RAM1Read(& d a t ) ;

749 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , ( da t >>24)<−8);

P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , ( da t >>16)<−8);

751 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , ( da t >>8)<−8);

P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , da t <−8);

753 j ++;

}755

}757 s t a t i c macro p ro c Paral lelToRAM0 ( Addr , p r i n t )

{759

u n s i g n e d 32 c ;

761 u n s i g n e d 20 z ;

u n s i g n e d 8 i ;

763 u n s i g n e d 8 n b O c t e t s ;

u n s i g n e d 32 tmp ;

765 u n s i g n e d 8 f r o m P o r t ;

i =0 ;

767

seq

769 {

771 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &n b O c t e t s ) ; / / Nombre d ’ o c t e t s a l i r e : max 255

do

773 {P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

775 c = 0 @fromPort ;

tmp = ( c << 2 4 ) ;

777 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

c = 0 @fromPort ;

779 tmp += ( c << 1 6 ) ; / / L e c t u r e dans une v a r i a b l e de 32 b i t s

P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

781 c = 0 @fromPort ;

tmp += ( c << 8 ) ; / / . . .

783 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

92

Page 102: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

c = 0 @fromPort ;

785 tmp += 0@c; / / . . .

RC200PL1RAM0SetWriteAddress ( Addr ) ;

787 RC200PL1RAM0Write (0@tmp ) ;

p a r {Addr ++;

789 i +=4;

tmp =0;

791 }} w h i l e ( i < n b O c t e t s ) ;

793

}795

}797

s t a t i c macro p ro c R e a d P a r a l l e l ( p r i n t , program )

799 {

801 u n s i g n e d i d I n s t r ;

u n s i g n e d 8 c ;

803 u n s i g n e d i n t 32 tmp ;

u n s i g n e d i n t 32 tmp2 ;

805 u n s i g n e d i n t 6 deca ;

u n s i g n e d i n t 32 zone ; / / t y p e de zone : donn ees ou prog

807 u n s i g n e d i n t 32 code ;

u n s i g n e d i n t 32 recu , i ;

809 p a r {zone = 0 ;

811 i d I n s t r = 0 ;

deca =24;

813 r e c u = 0 ;

tmp = 0 ;

815 }seq

817 {/ / R e c e p t i o n du nombre d ’ o c t e t s de code

819 seq ( i = 0 ; i <4; i ++){P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ;

821 tmp2 =0;

tmp2 = 0@c;

823 tmp += tmp2 << deca ;

deca = deca − 8 ;

825 }p a r {

827 code = tmp ;

deca = 2 4 ;

829 }p a r {

831 tmp = 0 ;

r e c u = 0 ;

833 }/ / R e c e p t i o n du programme

835 w h i l e ( r e c u < code )

{837 seq ( i = 0 ; i <4; i ++){

93

Page 103: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE E. CODE HANDEL-C DU PROCESSEUR UTILISANT LES MICRO

INSTRUCTIONS

P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ;

839 tmp2 =0;

tmp2 = 0@c;

841 tmp += tmp2 << deca ;

p a r {843 deca −= 8 ;

r e c u = r e c u + 1 ;

845 }}

847 program [ i d I n s t r ] = tmp ;

p a r {849 i d I n s t r ++;

tmp =0;

851 deca = 2 4 ;

}853 }

855 }

857 }

94

Page 104: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe F

Matrice de quatre processeurs :calcul fibonacci

1

# d e f i n e PAL TARGET CLOCK RATE 25175000

3 # i n c l u d e ” p a l m a s t e r . hch ”

# i n c l u d e ” p a l c o n s o l e . hch ”

5

# d e f i n e NBPROCL 2 /∗ nombre de p r o c e s s e u r p a r l i g n e ∗ /

7

9

/∗11 ∗ P a r a m e t e r i s a t i o n

∗ /

13 # d e f i n e DW 32 /∗ Data wid th ∗ /

# d e f i n e RAM AW 4 /∗ Width o f RAM a d d r e s s bus ( d a t a ) ∗ /

15 # d e f i n e ROM AW 5 /∗ Width o f ROM a d d r e s s bus ( code ) ∗ /

# d e f i n e OPCW 5 /∗ Op−code wid th ∗ /

17 # d e f i n e OPRW 5 /∗ Operand wid th ∗ /

19 /∗∗ The opcodes

21 ∗ /

# d e f i n e HALT 0

23 # d e f i n e LOAD 1

# d e f i n e LOADI 2

25 # d e f i n e STORE 3

# d e f i n e ADD 4

27 # d e f i n e SUB 5

# d e f i n e JUMP 6

29 # d e f i n e JUMPNZ 7

# d e f i n e INPUT 8

31 # d e f i n e OUTPUT 9

# d e f i n e TONORTH 10

33 # d e f i n e TOSOUTH 11

95

Page 105: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE F. MATRICE DE QUATRE PROCESSEURS : CALCUL FIBONACCI

# d e f i n e TOEAST 12

35 # d e f i n e TOWEST 13

# d e f i n e FROMNORTH 14

37 # d e f i n e FROMSOUTH 15

# d e f i n e FROMEAST 16

39 # d e f i n e FROMWEST 17

41 /∗∗ The a s s e m b l e r macro

43 ∗ /

# d e f i n e asm ( opc , opr ) ( opc + ( opr << OPCW) )

45 s t a t i c macro p ro c RunConsole ( C o n s o l e P t r , r e s ) ;

s t a t i c macro ex p r ClockRa te = PAL ACTUAL CLOCK RATE ;

47 s t a t i c macro p ro c d a t a s ( ) ;

s t a t i c macro p ro c p r o c e s s o r ( n o r t h , e a s t , sou th , west , i n p u t , o u t p u t , X, Y ) ;

49 /∗∗ ROM program d a t a

51 ∗ /

rom u n s i g n e d i n t program [ ] =

53 {asm (LOADI , 0 ) , /∗ 0 ∗ / /∗ Get a z e r o ∗ /

55 asm (STORE , 0 ) , /∗ 1 ∗ / /∗ S t o r e t h i s ∗ /

asm (LOADI , 1 ) , /∗ 0 ∗ / /∗ Get a one ∗ /

57 asm (STORE , 1 ) , /∗ 1 ∗ / /∗ S t o r e t h i s ∗ /

asm (STORE , 3 ) , /∗ 2 ∗ / /∗ . . . ∗ /

59 asm ( INPUT , 0 ) , /∗ 3 ∗ / /∗ Read v a l u e from i n p u t ∗ /

asm (STORE , 2 ) , /∗ 4 ∗ / /∗ S t o r e t h i s ∗ /

61 asm (LOAD, 1 ) , /∗ 5 ∗ / /∗ Loop e n t r y p o i n t ∗ /

asm (ADD, 0 ) , /∗ 6 ∗ / /∗ Make a f i b number ∗ /

63 asm (STORE , 0 ) , /∗ 7 ∗ / /∗ S t o r e i t ∗ /

asm (ADD, 1 ) , /∗ 8 ∗ / /∗ Make a f i b number ∗ /

65 asm (STORE , 1 ) , /∗ 9 ∗ / /∗ S t o r e i t ∗ /

asm (LOAD, 2 ) , /∗ a ∗ / /∗ Decrement c o u n t e r ∗ /

67 asm (SUB, 3 ) , /∗ b ∗ / /∗ . . . ∗ /

asm (JUMPNZ, 6 ) , /∗ c ∗ / /∗ Repea t i f n o t z e r o ∗ /

69 asm (LOAD, 1 ) , /∗ d ∗ / /∗ Load t h e f i n a l answer ∗ /

asm (TONORTH, 0 ) ,

71 asm (TOWEST, 0 ) ,

asm (OUTPUT, 0 ) , /∗ e ∗ / /∗ Outpu t i t ∗ /

73 asm (HALT, 0 ) /∗ f ∗ / /∗ E x i t ∗ /

} ;

75

/∗77 ∗ P r o t o t y p e s

∗ /

79

81

/∗83 ∗ Main program

∗ /

85 vo id main ( vo id )

{87

96

Page 106: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE F. MATRICE DE QUATRE PROCESSEURS : CALCUL FIBONACCI

chan u n s i g n e d 32 i n p u t [NBPROCL ] [ NBPROCL ] ;

89 chan u n s i g n e d 32 o u t p u t [NBPROCL ] [ NBPROCL ] ;

chan u n s i g n e d 32 canaux [NBPROCL∗NBPROCL∗ 2 ] ;

91 u n s i g n e d i n t 32 d a t a s I n [NBPROCL∗NBPROCL ] ;

ram u n s i g n e d 32 d a t a s O u t [NBPROCL∗NBPROCL ] ;

93 u n s i g n e d i n t v a l u e ;

u n s i g n e d 8 nb ;

95

97 P a l C o n s o l e ∗C o n s o l e P t r ;

P a l V i d e o O u t R e q u i r e ( 1 ) ;

99

/ / E n t r e e s du r e s e a u

101 d a t a s I n [ 0 ] = 5 ;

d a t a s I n [ 1 ] = 5 ;

103 d a t a s I n [ 2 ] = 5 ;

d a t a s I n [ 3 ] = 9 ;

105

p a r

107 {d a t a s ( ) ;

109 p r o c e s s o r ( canaux [ 0 ] , canaux [ 1 ] , canaux [ 2 ] , canaux [ 3 ]

, i n p u t [ 0 ] [ 0 ] , o u t p u t [ 0 ] [ 0 ] , 0 , 0 ) ;

111 p r o c e s s o r ( canaux [ 4 ] , canaux [ 3 ] , canaux [ 5 ] , canaux [ 1 ]

, i n p u t [ 1 ] [ 0 ] , o u t p u t [ 0 ] [ 0 ] , 1 , 0 ) ;

113 p r o c e s s o r ( canaux [ 2 ] , canaux [ 6 ] , canaux [ 0 ] , canaux [ 7 ]

, i n p u t [ 0 ] [ 1 ] , o u t p u t [ 0 ] [ 0 ] , 0 , 1 ) ;

115 p r o c e s s o r ( canaux [ 5 ] , canaux [ 7 ] , canaux [ 4 ] , canaux [ 6 ]

, i n p u t [ 1 ] [ 1 ] , o u t p u t [ 0 ] [ 0 ] , 1 , 1 ) ;

117 seq

{119 P a l C o n s o l e E n a b l e ( C o n s o l e P t r ) ;

seq ( i =0 ; i<NBPROCL; i ++){121 seq ( j =0 ; j<NBPROCL; j ++){

/ / s o r t i e des r e s u l t a t s

123 o u t p u t [ i ] [ j ] ? d a t a s O u t [ i@0+j@0∗NBPROCL ] ;

p r i n t ! d a t a s O u t [0@( i + j ∗NBPROCL ) ] ; /∗ a f f i c h a g e ∗ /

125 }}

127

}129 RunConsole ( p r i n t ) ; / / Lancement du m u l t i p l e x e u r d ’ a f f i c h a g e

131 }

133

135 /∗∗ M u l t i p l e x e u r d ’ a f f i c h a g e

137 ∗∗ /

139 s t a t i c macro p ro c RunConsole ( p r i n t )

{141 s t a t i c u n s i g n e d 32 X;

97

Page 107: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE F. MATRICE DE QUATRE PROCESSEURS : CALCUL FIBONACCI

u n s i g n e d i n t 32 from ;

143 u n s i g n e d i n t 32 v a l ;

145 s t a t i c ram u n s i g n e d c h a r S t r i n g [ 2 5 6 ] =

” Proc : ” ;

147 s t a t i c ram u n s i g n e d c h a r S t r i n g 2 [ 2 5 6 ] =

” V a l e u r : ” ;

149 P a l C o n s o l e ∗C o n s o l e P t r ;

P a l V i d e o O u t R e q u i r e ( 1 ) ;

151

p a r

153 {w h i l e ( 1 ){

155 P a l C o n s o l e E n a b l e ( C o n s o l e P t r ) ;

p r i a l t

157 {c a s e p r i n t [ 0 ] ? v a l :

159 from = 0 ;

b r e a k ;

161 c a s e p r i n t [ 1 ] ? v a l :

from = 1 ;

163 b r e a k ;

c a s e p r i n t [ 2 ] ? v a l :

165 from = 2 ;

b r e a k ;

167 c a s e p r i n t [ 3 ] ? v a l : / / c a n a l de debuggage ne v e n a n t pas d ’ un p r o c e s s e u r

from = 1 0 ;

169 b r e a k ;

}171 P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g ) ;

P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , from ) ;

173 X = 0@val ;

P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g 2 ) ;

175 P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , X ) ;

P a l C o n s o l e P u t C h a r ( C o n s o l e P t r , ’\n ’ ) ;

177 }

179 PalConso leRun (& C o n s o l e P t r , PAL CONSOLE FONT NORMAL,

PalVideoOutOpt imalCT ( ClockRa te ) , C lockRate ) ;

181 }

98

Page 108: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe G

Data-flow : Dilatation d’uneimage, transmission parcolonnes

1

3 # d e f i n e PAL TARGET CLOCK RATE 25175000

# i n c l u d e ” p a l m a s t e r . hch ”

5 # i n c l u d e ” p a l c o n s o l e . hch ”

7 /∗∗ P a r a m e t e r i s a t i o n

9 ∗ /

# d e f i n e DW 32 /∗ Data wid th ∗ /

11 # d e f i n e RAM AW 4 /∗ Width o f RAM a d d r e s s bus ( d a t a ) ∗ /

# d e f i n e ROM AW 8 /∗ Width o f ROM a d d r e s s bus ( code ) ∗ /

13 # d e f i n e OPCW 5 /∗ Op−code wid th ∗ /

# d e f i n e OPRW 8 /∗ Operand wid th ∗ /

15 # d e f i n e NBPROCL 2 /∗ nombre de p r o c e s s e u r p a r l i g n e ∗ /

# d e f i n e SIZEIMG 6 /∗17

19

21 /∗∗ The opcodes

23 ∗ /

# d e f i n e HALT 0

25 # d e f i n e LOAD 1

# d e f i n e LOADI 2

27 # d e f i n e STORE 3

# d e f i n e ADD 4

29 # d e f i n e SUB 5

# d e f i n e JUMP 6

31 # d e f i n e JUMPNZ 7

99

Page 109: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

# d e f i n e INPUT 8

33 # d e f i n e OUTPUT 9

# d e f i n e ADDI 10

35 # d e f i n e SUBI 11

# d e f i n e WRITERAM 12

37 # d e f i n e READRAMI 13

# d e f i n e INIT 14

39

/∗41 ∗ The a s s e m b l e r macro

∗ /

43 # d e f i n e asm ( opc , opr ) ( opc + ( opr << OPCW) )

45

/ / macro de m u l t i p l i c a t i o n

47 macro e xp r m u l t i p l y ( x , y ) = s e l e c t ( wid th ( x ) == 0 , 0 ,

m u l t i p l y ( x \\ 1 , y <<1) + ( x [ 0 ] == 1 ? y : 0 ) ) ;

49 s h a r e d ex p r mul t ( x , y ) = m u l t i p l y ( x , y ) ;

51 /∗∗ ROM program d a t a

53 ∗ /

55 s t a t i c rom u n s i g n e d i n t program0 [ ] =

{57 asm ( INIT , 0 ) , /∗ Read nombre p i x e l s s u r une l i g n e ∗ /

asm (STORE , 9 ) , /∗ S t o r e add r 9 ∗ /

59 asm ( INIT , 0 ) , /∗ Read nombre l i g n e s a t r a i t e r ∗ /

asm (STORE , 1 0 ) , /∗ S t o r e add r 10 ∗ /

61 asm (LOADI , 0 ) ,

asm (STORE , 1 2 ) , /∗ Compteur de l i g n e ∗ /

63 asm (STORE , 1 6 ) ,

asm (LOAD, 9 ) ,

65 asm (ADDI , 2 ) ,

asm (STORE , 1 3 ) , /∗ m u l t p l i c a t e u r ∗ /

67 asm (LOADI , 0 ) ,

asm (STORE , 1 1 ) , /∗ Compteur de p i x e l ∗ /

69 asm (LOAD, 1 6 ) , /∗ 8∗ numl igne ∗ /

asm (ADD, 1 1 ) , /∗ 8∗ numl igne + numpixe l ∗ /

71 asm (STORE , 1 5 ) ,

asm (READRAMI, 0 ) ,

73 asm (OUTPUT, 0 ) ,

asm (LOAD, 1 5 ) ,

75 asm (ADD, 1 3 ) ,

asm (STORE , 1 5 ) ,

77 asm (READRAMI, 0 ) ,

asm (OUTPUT, 0 ) ,

79 asm (LOAD, 1 5 ) ,

asm (ADD, 1 3 ) ,

81 asm (READRAMI, 0 ) ,

asm (OUTPUT, 0 ) ,

83 asm (LOAD, 1 6 ) , /∗ 2 e c o l o n n e ∗ /

asm (ADD, 1 1 ) , /∗ 8∗ numl igne + numpixe l ∗ /

85 asm (ADDI , 1 ) ,

100

Page 110: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

asm (STORE , 1 5 ) ,

87 asm (READRAMI, 0 ) ,

asm (OUTPUT, 0 ) ,

89 asm (LOAD, 1 5 ) ,

asm (ADD, 1 3 ) ,

91 asm (STORE , 1 5 ) ,

asm (READRAMI, 0 ) ,

93 asm (OUTPUT, 0 ) ,

asm (LOAD, 1 5 ) ,

95 asm (ADD, 1 3 ) ,

asm (READRAMI, 0 ) ,

97 asm (OUTPUT, 0 ) ,

asm (LOAD, 1 6 ) , /∗ 8∗ numl igne ∗ /

99 asm (ADD, 1 1 ) , /∗ 8∗ numl igne + numpixe l ∗ /

asm (ADDI , 2 ) ,

101 asm (STORE , 1 5 ) ,

asm (READRAMI, 0 ) , /∗ jump l e c t u r e 3 e c o l o n n e ∗ /

103 asm (OUTPUT, 0 ) ,

asm (LOAD, 1 5 ) ,

105 asm (ADD, 1 3 ) ,

asm (STORE , 1 5 ) ,

107 asm (READRAMI, 0 ) ,

asm (OUTPUT, 0 ) ,

109 asm (LOAD, 1 5 ) ,

asm (ADD, 1 3 ) ,

111 asm (READRAMI, 0 ) ,

asm (OUTPUT, 0 ) ,

113 asm (LOAD, 1 1 ) ,

asm (ADDI , 1 ) ,

115 asm (STORE , 1 1 ) ,

asm (LOAD, 9 ) ,

117 asm (SUB, 1 1 ) ,

asm (JUMPNZ, 7 2 ) , /∗ p i x e l meme l i g n e ∗ /

119 asm (LOAD, 1 6 ) ,

asm (ADD, 1 3 ) ,

121 asm (STORE , 1 6 ) ,

asm (LOAD, 1 2 ) ,

123 asm (ADDI , 1 ) ,

asm (STORE , 1 2 ) ,

125 asm (LOAD, 1 0 ) ,

asm (SUB, 1 2 ) ,

127 asm (JUMPNZ, 1 1 ) , /∗ n o u v e l l e l i g n e ∗ /

asm (JUMP, 7 7 ) , /∗ f i n programme ∗ /

129 asm (LOAD, 1 6 ) , /∗ une c o l o n n e a l i r e ∗ /

asm (ADD, 1 1 ) , /∗ 8∗ numl igne + numpixe l ∗ /

131 asm (ADDI , 2 ) ,

asm (STORE , 1 5 ) ,

133 asm (JUMP, 4 5 ) , /∗ l e c t u r e 3 e c o l o n n e ∗ /

asm (HALT, 0 ) /∗ E x i t ∗ /

135 } ;

137 s t a t i c rom u n s i g n e d i n t program1 [ ] =

{139 asm ( INIT , 0 ) , /∗ Read nombre p i x e l s s u r une l i g n e ∗ /

101

Page 111: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

asm (STORE , 9 ) , /∗ S t o r e add r 9 ∗ /

141 asm (STORE , 1 1 ) , /∗ Compteur de p i x e l ∗ /

asm ( INIT , 0 ) , /∗ Read nombre l i g n e s a t r a i t e r ∗ /

143 asm (STORE , 1 0 ) , /∗ S t o r e add r 10 ∗ /

asm (STORE , 1 2 ) , /∗ Compteur de l i g n e ∗ /

145 asm (LOAD, 9 ) , /∗ Compteur de p i x e l = nombre p i x e l s s u r une l i g n e

∗ /

asm (STORE , 1 1 ) ,

147 asm ( INPUT , 0 ) , /∗ St o c k a g e des 9 p i x e l s dans l a RAM∗ /

asm (STORE , 0 ) ,

149 asm ( INPUT , 0 ) ,

asm (STORE , 1 ) ,

151 asm ( INPUT , 0 ) ,

asm (STORE , 2 ) ,

153 asm ( INPUT , 0 ) ,

asm (STORE , 3 ) ,

155 asm ( INPUT , 0 ) ,

asm (STORE , 4 ) ,

157 asm ( INPUT , 0 ) ,

asm (STORE , 5 ) ,

159 asm ( INPUT , 0 ) ,

asm (STORE , 6 ) ,

161 asm ( INPUT , 0 ) ,

asm (STORE , 7 ) ,

163 asm ( INPUT , 0 ) ,

asm (STORE , 8 ) , /∗ Fin s t o c k a g e ∗ /

165 asm (JUMP, 4 5 ) , /∗ A l l e r au t r a i t e m e n t ∗ /

asm (LOAD, 3 ) , /∗ Si on e s t s u r l a meme l i g n e −> Deca lage ∗ /

167 asm (STORE , 0 ) ,

asm (LOAD, 4 ) ,

169 asm (STORE , 1 ) ,

asm (LOAD, 5 ) ,

171 asm (STORE , 2 ) ,

asm (LOAD, 6 ) ,

173 asm (STORE , 3 ) ,

asm (LOAD, 7 ) ,

175 asm (STORE , 4 ) ,

asm (LOAD, 8 ) ,

177 asm (STORE , 5 ) , /∗ Fin d e c a l a g e ∗ /

asm ( INPUT , 0 ) , /∗ L e c t u r e des t r o i s p i x e l s manquant ∗ /

179 asm (STORE , 6 ) ,

asm ( INPUT , 0 ) ,

181 asm (STORE , 7 ) ,

asm ( INPUT , 0 ) ,

183 asm (STORE , 8 ) , /∗ Fin L e c t u r e ∗ /

asm (LOAD, 8 ) , /∗ Debut du t r a i t e m e n t

185 −> s i un p i x e l =1 a l o r s on e n v o i e l a v a l e u r 1 ∗ /

asm (JUMPNZ, 6 2 ) ,

187 asm (LOAD, 7 ) ,

asm (JUMPNZ, 6 2 ) ,

189 asm (LOAD, 6 ) ,

asm (JUMPNZ, 6 2 ) ,

191 asm (LOAD, 5 ) ,

asm (JUMPNZ, 6 2 ) ,

102

Page 112: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

193 asm (LOAD, 4 ) ,

asm (JUMPNZ, 6 2 ) ,

195 asm (LOAD, 3 ) ,

asm (JUMPNZ, 6 2 ) ,

197 asm (LOAD, 2 ) ,

asm (JUMPNZ, 6 2 ) ,

199 asm (LOAD, 1 ) ,

asm (JUMPNZ, 6 2 ) ,

201 asm (LOAD, 0 ) ,

asm (OUTPUT, 0 ) , /∗ Fin du t r a i t e m e n t e t e n v o i de l a v a l e u r o b t e n u e

∗ /

203 asm (LOAD, 1 1 ) , /∗ Compteur de p i x e l −1 ∗ /

asm ( SUBI , 1 ) ,

205 asm (STORE , 1 1 ) ,

asm (JUMPNZ, 2 7 ) , /∗ A l l e r p i x e l s u i v a n t ∗ /

207 asm (LOAD, 1 2 ) , /∗ Compteur de l i g n e −1 ∗ /

asm ( SUBI , 1 ) ,

209 asm (STORE , 1 2 ) ,

asm (JUMPNZ, 6 ) , /∗ Debut de l i g n e ∗ /

211 asm (HALT, 0 ) /∗ E x i t ∗ /

} ;

213

s t a t i c rom u n s i g n e d i n t program2 [ ] =

215 {asm ( INIT , 0 ) , /∗ L e c t u r e du nombre de p i x e l s a t r a i t e r

∗ /

217 asm (STORE , 0 ) , /∗ −> r e g : 0 ∗ /

asm (LOADI , 0 ) , /∗ Compteur de p i x e l a 0 ∗ /

219 asm (STORE , 1 ) , /∗ −> r e g : 1 ∗ /

asm ( INPUT , 0 ) , /∗ R e c e p t i o n du p i x e l ∗ /

221 asm (WRITERAM, 1 ) , /∗ E c r i t u r e dans l a RAM en f o n c t i o n du compteur

∗ /

asm (LOAD, 1 ) , /∗ I n c r e m e n t a t i o n du compteur de p i x ∗ /

223 asm (ADDI , 1 ) ,

asm (STORE , 1 ) ,

225 asm (LOAD, 0 ) ,

asm (SUB, 1 ) , /∗ C a l c u l du nombre de p i x e l s a t r a i t e r ∗ /

227 asm (JUMPNZ, 4 ) , /∗ Si i l n ’ y a p l u s de p i x e l s : FIN . ∗ /

asm (HALT, 0 ) , /∗ FIN ∗ /

229 } ;

231

/∗233 ∗ P r o t o t y p e s

∗ /

235 s t a t i c macro p ro c p r o c e s s o r ( i n p u t , o u t p u t , i n i t , p r i n t , program , X ) ;

s t a t i c macro p ro c d a t a s ( i n p u t , d a t a s I n , p r i n t ) ;

237 s t a t i c macro p ro c RunConsole ( p r i n t I n ) ;

s t a t i c macro p ro c R e a d P a r a l l e l ( Addr ) ;

239 s t a t i c macro p ro c W r i t e P a r a l l e l ( Addr , p r i n t ) ;

macro e xp r P a r a l l e l P o r t = P a l R C 2 0 0 P a r a l l e l P o r t ;

241

/ / Hor loge

243 s t a t i c macro ex p r ClockRa te = PAL ACTUAL CLOCK RATE ;

103

Page 113: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

245 /∗∗ Main program

247 ∗ /

vo id main ( vo id )

249 {/ / Canaux d ’ e n t r e e s e t de s o r t i e s des p r o c e s s e u r s

251 chan u n s i g n e d 32 canaux [ 4 ] ;

chan u n s i g n e d 32 i n i t [ 3 ] ;

253 / / Canaux d ’ a f f i c h a g e

chan u n s i g n e d DW p r i n t [ 4 ] ;

255 u n s i g n e d 20 Addr ;

Addr = 0 ;

257

259 p a r

{261

RunConsole ( p r i n t ) ; / / Lancement du m u l t i p l e x e u r d ’ a f f i c h a g e

263 P a l D a t a P o r t R u n ( P a r a l l e l P o r t , C lockRa te ) ;

RC200PL1RAM0Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM0

265 RC200PL1RAM1Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM1

seq {267

P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

269

R e a d P a r a l l e l ( Addr ) ; / / L e c t u r e a p a r t i r du p o r t p a r a l l e l e v e r s l a ram

271 p a r {seq {

273 i n i t [ 0 ] ! 6 ;

i n i t [ 0 ] ! 6 ;

275 }seq {

277 i n i t [ 1 ] ! 6 ;

i n i t [ 1 ] ! 6 ;

279 }i n i t [ 2 ] ! 3 6 ;

281 / / Lancement des p r o c e s s e u r s

p r o c e s s o r ( canaux [ 0 ] , canaux [ 1 ] , i n i t [ 0 ] , p r i n t [ 0 ] , program0 , 0 ) ;

283 p r o c e s s o r ( canaux [ 1 ] , canaux [ 2 ] , i n i t [ 1 ] , p r i n t [ 1 ] , program1 , 1 ) ;

p r o c e s s o r ( canaux [ 2 ] , canaux [ 3 ] , i n i t [ 2 ] , p r i n t [ 2 ] , program2 , 2 ) ;

285 }

287 W r i t e P a r a l l e l ( Addr , p r i n t [ 3 ] ) ; / / L e c t u r e de l a ram v e r s l e p o r t p a r a l l e l e

}289 }

291 }

293

/∗295 ∗ The p r o c e s s o r

∗ /

297 s t a t i c macro p ro c p r o c e s s o r ( i n p u t , o u t p u t , i n i t , p r i n t , program , X)

104

Page 114: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

{299 /∗

∗ RAM f o r p r o c e s s o r

301 ∗ /

ram u n s i g n e d i n t DW d a t a [1 << RAM AW] ;

303

/∗305 ∗ P r o c e s s o r r e g i s t e r s

∗ /

307 u n s i g n e d i n t ROM AW pc ; /∗ Compteur de programme

∗ /

u n s i g n e d i n t (OPCW + OPRW) i r ; /∗ R e g i s t r e d ’ i n s t r u c t i o n

∗ /

309 u n s i g n e d i n t DW x ; /∗ Accumula teu r ∗ /

u n s i g n e d i n t DW y ;

311 u n s i g n e d i n t DW cmpt ;

u n s i g n e d 36 dataRam ;

313 /∗∗ Macros d ’ e x t r a c t i o n de l ’ op e r a n d e e t de l ’ o p e r a t e u r

315 ∗ /

macro ex p r opcode = ( i r <− OPCW) ;

317 macro ex p r ope rand = ( i r \\ OPCW) ;

cmpt =0;

319 pc = 0 ;

/ / Boucle du p r o c e s s e u r

321 do

{323 / / Recherche de l ’ i n s t r u c t i o n a e x e c u t e r e t i n c r e m e n t a t i o n du compteur

p a r

325 {i r = program [ pc ] ;

327 pc ++;

}329

/ / Decodage de l ’ i n s t r u c t i o n e t e x e c u t i o n

331 s w i t c h ( opcode )

{333 c a s e HALT : p r i n t ! x ; b r e a k ;

/ / Chargement d ’ une v a l e u r du r e g i s t r e dans l ’ a c c u m u l a t e u r .

335 c a s e LOAD : x = d a t a [ ope rand <− RAM AW] ; b r e a k ;

/ / On ne g a r d e que l e s RAM AW p l u s f a i b l e b i t s pour l ’ o p e r a n d e .

337 c a s e LOADI : x = 0 @ operand ; b r e a k ; / Chargement d ’ un e n t i e r dans l ’ a c c u m u l a t e u

c a s e STORE : d a t a [ ope rand <− RAM AW] = x ; b r e a k ; / / E n r e g i s t r e m e n t de l ’ acc

339 c a s e ADD : x += d a t a [ ope rand <− RAM AW] ; b r e a k ;

/ / A d d i t i o n de l ’ acc avec une v a l e u r du r e g i s t r e

c a s e SUB : x −= d a t a [ ope rand <− RAM AW] ; b r e a k ;

/ / S o u s t r a c t i o n . . .

341 c a s e ADDI : x += 0@operand ; b r e a k ; / / A jou t d ’ un e n t i e r dans l ’ acc

c a s e SUBI : x −= 0@operand ; b r e a k ; / / S o u s t r a c t i o n

343 c a s e JUMP : pc = ope rand <− ROM AW; b r e a k ;

c a s e JUMPNZ : i f ( x != 0) pc = ope rand <− ROM AW; b r e a k ;

345 c a s e READRAMI:

RC200PL1RAM0SetReadAddress ( x<− 2 0 ) ; / / L e c t u r e de l a ram a l ’ a d r e s s e de l ’ acc

347 RC200PL1RAM0Read(&dataRam ) ;

105

Page 115: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

x = dataRam<−DW;

349 b r e a k ;

c a s e WRITERAM:

351 dataRam = 0@x; / / Formatage de l ’ acc en 36 b i t s

/ / P o s i t i o n n e m e n t de l ’ a d r e s s e d ’ e c r i t u r e

353 RC200PL1RAM1SetWriteAddress ( ( d a t a [ ope rand <− RAM AW]) <−20);

355 RC200PL1RAM1Write ( dataRam ) ; / / E c r i t u r e dans l a ram

p r i n t ! x ;

357 b r e a k ;

c a s e INIT : i n i t ? x ; b r e a k ; / / i n i t i a l i s a t i o n du p r o c e s s e u r

359 c a s e INPUT : i n p u t ? x ; b r e a k ; / / Chargement de l ’ e n t r e e dans l ’ acc

c a s e OUTPUT : o u t p u t ! x ; b r e a k ; / / T r a n s m i s s i o n de l ’ acc v e r s l a s o r t i

361 d e f a u l t : w h i l e ( 1 ) d e l a y ; /∗ unknown opcode ∗ /

}363 } w h i l e ( opcode != HALT ) ;

}365

/∗367 ∗ M u l t i p l e x e u r d ’ a f f i c h a g e

∗369 ∗ /

s t a t i c macro p ro c RunConsole ( p r i n t )

371 {s t a t i c u n s i g n e d 32 X;

373 u n s i g n e d i n t 32 from ;

u n s i g n e d i n t 32 v a l ;

375 u n s i g n e d i n t 32 cmpt ;

s t a t i c ram u n s i g n e d c h a r S t r i n g [ 2 5 6 ] =

377 ” Proc : ” ;

s t a t i c ram u n s i g n e d c h a r S t r i n g 2 [ 2 5 6 ] =

379 ” V a l e u r : ” ;

P a l C o n s o l e ∗C o n s o l e P t r ;

381 P a l V i d e o O u t R e q u i r e ( 1 ) ;

cmpt = 0 ;

383 p a r

{385 w h i l e ( 1 ){

P a l C o n s o l e E n a b l e ( C o n s o l e P t r ) ;

387 p r i a l t

{389 c a s e p r i n t [ 0 ] ? v a l :

from = 0 ;

391 b r e a k ;

c a s e p r i n t [ 1 ] ? v a l :

393 from = 1 ;

b r e a k ;

395 c a s e p r i n t [ 2 ] ? v a l :

from = 2 ;

397 b r e a k ;

c a s e p r i n t [ 3 ] ? v a l : / / c a n a l de debuggage ne v e n a n t pas d ’ un p r o c e s s e u r

399 from = 1 0 ;

b r e a k ;

401 }

106

Page 116: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g ) ;

403 P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , from ) ;

X = 0@val ;

405 P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g 2 ) ;

P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , X ) ;

407 P a l C o n s o l e P u t C h a r ( C o n s o l e P t r , ’\n ’ ) ;

}409

PalConso leRun (& C o n s o l e P t r , PAL CONSOLE FONT NORMAL,

411 PalVideoOutOpt imalCT ( ClockRa te ) , C lockRate ) ;

}413

}415 s t a t i c macro p ro c W r i t e P a r a l l e l ( Addr , p r i n t )

{417 u n s i g n e d 20 j ;

u n s i g n e d 36 d a t ;

419 ram u n s i g n e d 32 b u f f e r [ 1 ] ;

j =0 ;

421 w h i l e ( j < Addr ){RC200PL1RAM1SetReadAddress ( j ) ;

423 RC200PL1RAM1Read(& d a t ) ;

b u f f e r [ 0 ] = 0 ;

425 b u f f e r [ 0 ] = ( d a t << 7)<−32;

j ++;

427 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

429 b u f f e r [ 0 ] = b u f f e r [ 0 ] +( d a t << 6)<−32;

j ++;

431 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

433 b u f f e r [ 0 ] = b u f f e r [ 0 ] +( d a t << 5)<−32;

j ++;

435 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

437 b u f f e r [ 0 ] = b u f f e r [ 0 ] +( d a t << 4)<−32;

j ++;

439 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

441 b u f f e r [ 0 ] = b u f f e r [ 0 ] +( d a t << 3)<−32;

j ++;

443 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

445 b u f f e r [ 0 ] = b u f f e r [ 0 ] +( d a t << 2)<−32;

j ++;

447 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

449 b u f f e r [ 0 ] = b u f f e r [ 0 ] +( d a t << 1)<−32;

j ++;

451 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

453 b u f f e r [ 0 ] = b u f f e r [ 0 ] + da t <−32;

j ++;

455 /∗ P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , b u f f e r [ 0 ] ) ;

107

Page 117: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

P a l C o n s o l e P u t C h a r ( C o n s o l e P t r , ’ ’ ) ; ∗ /

457 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , b u f f e r [0] <−8);

459 }

461 }s t a t i c macro p ro c R e a d P a r a l l e l ( Addr )

463 {

465 u n s i g n e d 8 c ;

u n s i g n e d 20 z ;

467 u n s i g n e d 1 p i x ;

ram u n s i g n e d 32 b u f f e r [ 1 ] ;

469 p i x =0;

seq

471 {

473 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ;

w h i l e ( c != 255)

475 {p i x = ( c\\7)<−1;

477 RC200PL1RAM0SetWriteAddress ( Addr ) ;

RC200PL1RAM0Write (0 @pix ) ;

479 Addr ++;

481 p i x = ( c\\6)<−1;

RC200PL1RAM0SetWriteAddress ( Addr ) ;

483 RC200PL1RAM0Write (0 @pix ) ;

Addr ++;

485

p i x = ( c\\5)<−1;

487 RC200PL1RAM0SetWriteAddress ( Addr ) ;

RC200PL1RAM0Write (0 @pix ) ;

489 Addr ++;

491 p i x = ( c\\4)<−1;

RC200PL1RAM0SetWriteAddress ( Addr ) ;

493 RC200PL1RAM0Write (0 @pix ) ;

Addr ++;

495

p i x = ( c\\3)<−1;

497 RC200PL1RAM0SetWriteAddress ( Addr ) ;

RC200PL1RAM0Write (0 @pix ) ;

499 Addr ++;

501 p i x = ( c\\2)<−1;

RC200PL1RAM0SetWriteAddress ( Addr ) ;

503 RC200PL1RAM0Write (0 @pix ) ;

Addr ++;

505

p i x = ( c\\1)<−1;

507 RC200PL1RAM0SetWriteAddress ( Addr ) ;

RC200PL1RAM0Write (0 @pix ) ;

509 Addr ++;

108

Page 118: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE G. DATA-FLOW : DILATATION D’UNE IMAGE, TRANSMISSION

PAR COLONNES

511 p i x = c <−1;

RC200PL1RAM0SetWriteAddress ( Addr ) ;

513 RC200PL1RAM0Write (0 @pix ) ;

Addr ++;

515

517 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ;

}519

}521

}

109

Page 119: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe H

Communication par circuitsvirtuels : code Handel-C

1 # d e f i n e PAL TARGET CLOCK RATE 25175000

# i n c l u d e ” p a l m a s t e r . hch ”

3 # i n c l u d e ” p a l c o n s o l e . hch ”

5 /∗∗ P a r a m e t r i s a t i o n

7 ∗ /

# d e f i n e DW 32 /∗ Data wid th ∗ /

9 # d e f i n e RAM AW 8 /∗ Width o f RAM a d d r e s s bus ( d a t a ) ∗ /

# d e f i n e ROM AW 8 /∗ Width o f ROM a d d r e s s bus ( code ) ∗ /

11 # d e f i n e OPCW 8 /∗ Op−code wid th ∗ /

# d e f i n e OPRW 12 /∗ Operand wid th ∗ /

13 # d e f i n e NBPROC 4 /∗ nombre de p r o c e s s e u r s ∗ /

15 # d e f i n e MICROI AW 34 /∗ l a r g e u r des m i c r o i n s t r u c t i o n s ∗ /

# d e f i n e MICROM AW 9 /∗ t a i l l e de l ’ a d r e s s a g e micro−memoire ∗ /

17 # d e f i n e MICROOP AW 5 /∗ l a r g e u r du micro o p e r a t e u r ∗ /

# d e f i n e MIC AW 16 /∗ l a r g e u r de l a mic ∗ /

19 # d e f i n e MIR AW 34 /∗ l a r g e u r de l a mir ∗ /

# d e f i n e MICRO LOCALMEM AW 4 /∗ l a r g e u r du nombre de r e g i s t r e s

21 de l a ram du micro−c o n t r o l l e u r ∗ /

23 # d e f i n e FIFOL 8 /∗ t a i l l e des f i f o s des canaux e n t r e comAgent ∗ /

# d e f i n e COM HERE AW 1 /∗ l a r g e u r du champ HERE d ’ un c i r c u i t v i r t u e l ∗ /

25 # d e f i n e COM DLCI AW 4 /∗ l a r g e u r d ’ un DLCI dans un c i r c u i t v i r t u e l ∗ /

# d e f i n e COM CHAN AW 3 /∗ l a r g e u r de l ’ i d e n t i f i a n t d ’ un c a n a l d ’ un c i r c u i t v i r t u e l ∗ /

27 # d e f i n e COM DEST AW 6 /∗ champ DEST d ’ une r o u t e ∗ /

29 /∗∗ The opcodes

31 ∗ /

# d e f i n e HALT 99

33

110

Page 120: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

/∗35 ∗ The a s s e m b l e r macro

∗ /

37 # d e f i n e asm ( opc , opr ) ( opc + ( opr << OPCW) )

39

/∗41 ∗ P r o t o t y p e s

∗ /

43 s t a t i c macro p ro c R e a d P a r a l l e l ( p r i n t , program ) ;

s t a t i c macro p ro c d a t a s ( i n p u t , d a t a s I n , p r i n t ) ;

45 s t a t i c macro p ro c RunConsole ( p r i n t I n ) ;

s t a t i c macro p ro c RAM1ToParal lel ( Addr , p r i n t ) ;

47 s t a t i c macro p ro c Paral lelToRAM0 ( Addr , p r i n t ) ;

s t a t i c macro p ro c compteur ( i , c o n d i t i o n ) ;

49 macro e xp r P a r a l l e l P o r t = P a l R C 2 0 0 P a r a l l e l P o r t ;

51 /∗∗ P r o t o t y p e s de l ’ a r c h i t e c t u r e : p r o c e s s e u r , micro−c o n t r o l e u r e t a g e n t de communica t ion

53 ∗ /

s t a t i c macro p ro c p r o c e s s o r ( p roc In , procOut , p r i n t , program , microMem , X ) ;

55 s t a t i c macro p ro c m i c r o C o n t r o l e u r ( m i c r o C o n t r o l e u r I n , p roc In , procOut ,

microMem , da ta , pc , acc , end , s e m T r a i t e m e n t ) ;

57 s t a t i c macro p ro c comAgent ( I1 , I2 , I3 , I4 , O1 , O2 , O3 , O4 , inP roc , ou tP roc ,

t ab l eR , tableCV1 , tableCV2 , tableCV3 , tableCV4 ) ;

59

61 / / Hor loge

s t a t i c macro ex p r ClockRa te = PAL ACTUAL CLOCK RATE ;

63

/∗65 ∗ Main program

∗ /

67 vo id main ( vo id )

{69 / / Canaux d ’ e n t r e e s e t de s o r t i e s des p r o c e s s e u r s

chan u n s i g n e d DW p r o c I n [NBPROC ] ;

71 chan u n s i g n e d 38 procOut [NBPROC ] ;

chan u n s i g n e d 38 O1 [NBPROC] wi th { f i f o l e n g t h = FIFOL} ,

73 O2 [NBPROC] wi th { f i f o l e n g t h = FIFOL} ,

O3 [NBPROC] wi th { f i f o l e n g t h = FIFOL} ,

75 O4 [NBPROC] wi th { f i f o l e n g t h = FIFOL } ;

chan u n s i g n e d 38 I1 [NBPROC] wi th { f i f o l e n g t h = FIFOL} ,

77 I2 [NBPROC] wi th { f i f o l e n g t h = FIFOL} ,

I 3 [NBPROC] wi th { f i f o l e n g t h = FIFOL} ,

79 I4 [NBPROC] wi th { f i f o l e n g t h = FIFOL } ;

81 / / Canaux d ’ a f f i c h a g e

chan u n s i g n e d DW p r i n t [ 4 ] ;

83

u n s i g n e d 20 Addr ;

85 ram u n s i g n e d i n t program0 [ 2 5 5 ] ;

87 s t a t i c ram u n s i g n e d i n t MICROI AW microMem [ ] ={

111

Page 121: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

} ;

89

/∗ T a b l e s CV P1 ∗ /

91 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV10 [ ] ={} ;

93 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV20 [ ] ={} ;

95 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV30 [ ] ={} ;

97 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV40 [ ] ={} ;

99

/∗ T a b l e s CV P2 ∗ /

101 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV11 [ ] ={} ;

103 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV21 [ ] ={} ;

105 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV31 [ ] ={} ;

107 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV41 [ ] ={} ;

109

/∗ T a b l e s CV P3 ∗ /

111 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV12 [ ] ={} ;

113 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV22 [ ] ={} ;

115 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV32 [ ] ={} ;

117 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV42 [ ] ={} ;

119

/∗ T a b l e s CV P4 ∗ /

121 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV13 [ ] ={} ;

123 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV23 [ ] ={} ;

125 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV33 [ ] ={} ;

112

Page 122: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

127 s t a t i c ram u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW)

tableCV43 [ ] ={} ;

129 /∗ T a b l e s R∗ /

s t a t i c ram u n s i g n e d i n t (COM CHAN AW+COM DLCI AW+ COM DEST AW) t a b l e R 0 [ ] ={131 } ;

s t a t i c ram u n s i g n e d i n t (COM CHAN AW+COM DLCI AW+ COM DEST AW) t a b l e R 1 [ ] ={133 } ;

s t a t i c ram u n s i g n e d i n t (COM CHAN AW+COM DLCI AW+ COM DEST AW) t a b l e R 2 [ ] ={135 } ;

s t a t i c ram u n s i g n e d i n t (COM CHAN AW+COM DLCI AW+ COM DEST AW) t a b l e R 3 [ ] ={137 } ;

139 Addr = 0 ;

p a r

141 {

143 RunConsole ( p r i n t ) ; / / Lancement du m u l t i p l e x e u r d ’ a f f i c h a g e

P a l D a t a P o r t R u n ( P a r a l l e l P o r t , C lockRa te ) ;

145 RC200PL1RAM0Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM0

RC200PL1RAM1Run ( ClockRa te ) ; / / A c t i v a t i o n de l a RAM1

147 seq {P a l D a t a P o r t E n a b l e ( P a r a l l e l P o r t ) ;

149 R e a d P a r a l l e l ( p r i n t [ 3 ] , program0 ) ;

p a r {151 p r o c e s s o r ( p r o c I n [ 0 ] , p rocOut [ 0 ] , p r i n t [ 0 ] , program0 , microMem , 0 ) ;

comAgent ( I1 [ 0 ] , I2 [ 0 ] , O1 [ 2 ] , I4 [ 0 ] , O1 [ 0 ] , O2 [ 0 ] , O3 [ 0 ] , O4 [ 0 ] ,

153 p r o c I n [ 0 ] , p rocOut [ 0 ] , t ab l eR0 , tableCV10 , tableCV20 ,

tableCV30 , tableCV40 ) ;

155 p r o c e s s o r ( p r o c I n [ 1 ] , p rocOut [ 1 ] , p r i n t [ 1 ] , program0 , microMem , 1 ) ;

comAgent ( I1 [ 1 ] , I2 [ 1 ] , O1 [ 0 ] , I4 [ 1 ] , O1 [ 1 ] , O2 [ 1 ] , I1 [ 0 ] , O4 [ 1 ] ,

157 p r o c I n [ 1 ] , p rocOut [ 1 ] , t ab l eR1 , tableCV11 , tableCV21 ,

tableCV31 , tableCV41 ) ;

159 p r o c e s s o r ( p r o c I n [ 2 ] , p rocOut [ 2 ] , p r i n t [ 2 ] , program0 , microMem , 2 ) ;

comAgent ( I1 [ 2 ] , I2 [ 2 ] , O1 [ 1 ] , I4 [ 2 ] , O1 [ 2 ] , O2 [ 2 ] , I1 [ 1 ] , O4 [ 2 ] ,

161 p r o c I n [ 2 ] , p rocOut [ 2 ] , t ab l eR2 , tableCV12 , tableCV22 ,

tableCV32 , tableCV42 ) ;

163 p r o c e s s o r ( p r o c I n [ 3 ] , p rocOut [ 3 ] , p r i n t [ 3 ] , program0 , microMem , 3 ) ;

comAgent ( I1 [ 3 ] , I2 [ 3 ] , O1 [ 2 ] , I4 [ 3 ] , O1 [ 3 ] , O2 [ 3 ] , I1 [ 2 ] , O4 [ 3 ] ,

165 p r o c I n [ 3 ] , p rocOut [ 3 ] , t ab l eR3 , tableCV13 , tableCV23 ,

tableCV33 , tableCV43 ) ;

167

}169 }

}171

}173

s t a t i c macro p ro c compteur ( i , c o n d i t i o n ){175 w h i l e ( c o n d i t i o n ) i ++;

}177

/∗179 ∗ P r o c e s s e u r s a n s a c c e s a l a RAM e x t e r n e

113

Page 123: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

∗ /

181 s t a t i c macro p ro c p r o c e s s o r ( p roc In , procOut , p r i n t , program , microMem , X)

{183

/ / u n s i g n e d i n t 1 s i g T r a i t e m e n t ;

185 / / chan u n s i g n e d i n t 1 n e w I n s t r ;

u n s i g n e d i n t 1 newInstrOK ;

187 /∗∗ R e g i s t r e s du p r o c e s s e u r

189 ∗ /

u n s i g n e d i n t ROM AW pc ; /∗ Compteur de programme

∗ /

191 u n s i g n e d i n t (OPCW + 2∗OPRW) i r ; /∗ R e g i s t r e d ’ i n s t r u c t i o n

∗ /

u n s i g n e d i n t DW acc ; /∗ Accumula teu r

∗ /

193 u n s i g n e d i n t 1 end ;

chan u n s i g n e d i n t DW m i c r o C o n t r o l e u r I n ;

195

/∗197 ∗ RAM du p r o c e s s e u r

∗ /

199 mpram Ram1 {ram <u n s i g n e d DW> p1 [1 << RAM AW] ;

201 ram <u n s i g n e d DW> p2 [1 << RAM AW] ;

} ;

203 mpram Ram1 d a t a wi t h { b l o c k = ”BlockRAM” } ;

205 w h i l e ( 1 ){/ / i n i t i a l i s a t i o n

207 p a r {pc = 0 ;

209 acc = 0 ;

end = 0 ;

211 newInstrOK = 0 ;

/ / s i g T r a i t e m e n t = 0 ;

213 }p a r {

215 m i c r o C o n t r o l e u r ( m i c r o C o n t r o l e u r I n , p roc In , procOut ,

microMem , da t a , pc , acc , end , newInstrOK ) ;

217 / / Boucle du p r o c e s s e u r

do

219 {/ / Recherche de l ’ i n s t r u c t i o n a e x e c u t e r

221 i r = program [ pc ] <−(OPCW + 2∗OPRW) ;

/ / t r a n s m i s s i o n de l ’ i n s t r u c t i o n au micro−c o n t r o l e u r

223 m i c r o C o n t r o l e u r I n ! i r ;

/ / n e w I n s t r ? newInstrOK ;

225 w h i l e ( ! newInstrOK ) d e l a y ;

newInstrOK = 0 ;

227 p r i n t ! acc ;

229 } w h i l e ( ! end ) ;

}

114

Page 124: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

231 }}

233

s t a t i c macro p ro c m i c r o C o n t r o l e u r ( m i c r o C o n t r o l e u r I n ,

235 proc In ,

procOut ,

237 microMem ,

mainMemory ,

239 pc ,

acc ,

241 end ,

newInstrOK ){243 /∗

∗ A r c h i t e c t u r e du micro−c o n t r o l e u r

245 ∗ /

u n s i g n e d i n t MIC AW mic ; /∗ compteur de micro i n s t r u c t i o n s ∗ /

247 u n s i g n e d i n t MIR AW mir ; /∗ r e g i s t r e de micro i n s t r u c t i o n s ∗ /

u n s i g n e d i n t DW opL1 ; /∗ op e r ande1 l o c a l e ∗ /

249 u n s i g n e d i n t DW opL2 ; /∗ op e r ande2 l o c a l e ∗ /

u n s i g n e d i n t OPRW opP1 ; /∗ op e r ande1 p r i n c i p a l e ∗ /

251 u n s i g n e d i n t OPRW opP2 ; /∗ op e r ande2 p r i n c i p a l e ∗ /

u n s i g n e d i n t 38 t rameOut ;

253 u n s i g n e d i n t 38 t r a m e I n ;

mpram Ram2 {255 ram <u n s i g n e d DW> p1 [1 << MICRO LOCALMEM AW ] ;

ram <u n s i g n e d DW> p2 [1 << MICRO LOCALMEM AW ] ;

257 } ;

mpram Ram2 d a t a wi t h { b l o c k = ”BlockRAM” } ;

259 /∗ Memoire ram du micro−c o n t r o l e u r ∗ /

261 /∗∗ V a r i a b l e s de f o n c t i o n n e m e n t

263 ∗ /

u n s i g n e d 36 dataRam ;

265 u n s i g n e d i n t MICROOP AW microOp ; /∗ Micro−o p e r a t e u r ∗ /

u n s i g n e d i n t (OPCW + 2∗OPRW) i n s t r u c t i o n ; /∗ Macro i n s t r u c t i o n

∗ /

267 u n s i g n e d i n t DW t Res [DW] , sou rce , m u l t i p l i e u r , y ;

u n s i g n e d i n t 3 c a n a l D e s t , c a n a l S o u r c e ;

269 /∗∗ Macros d ’ e x t r a c t i o n de l ’ o p e r a t e u r e t des l ’ op e r a n d e de l ’ i n s t r u c t i o n

271 ∗ /

macro ex p r opcode = ( i n s t r u c t i o n \\ (OPRW+OPRW) ) ;

273 macro ex p r ope rand2 = ( i n s t r u c t i o n <− OPRW) ;

macro ex p r ope rand1 = ( i n s t r u c t i o n >> OPRW)<−OPRW;

275

/ / Decodage de l a micro− i n s t r u c t i o n

277 macro ex p r t y p e = mir \\ (MICROI AW − 1)<−1;

macro ex p r a c t i o n = ( mir \\ (MICROI AW − 3))<−2;

279 macro ex p r cond = ( mir \\ (MICROI AW − 4))<−1;

macro ex p r m i c r o I n s t r = mir<−(MICROI AW − 4 ) ;

281

/ / R e c e p t i o n d ’ une i n s t r u c t i o n

283 p a r {

115

Page 125: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

m i c r o C o n t r o l e u r I n ? i n s t r u c t i o n ;

285 end = 0 ;

}287

p a r {289 opP1 = operand1 ;

opP2 = operand2 ;

291 opL1 = 0 ;

opL2 = 0 ;

293 / / Chargement de l ’ o p e r a t e u r en MIC

mic = 0@opcode ;

295 }w h i l e ( ! end ){

297 / / L e c t u r e de l a micro− i n s t r u c t i o n s e l o n l a mic

mir = microMem [ mic<−MICROM AW] ;

299 / / Comportement de l a micro− i n s t r u c t i o n

i f ( t y p e == 1){301 / / A p p l i c a t i o n des p o i n t s de c o n t r o l e

p a r ( i =0 ; i < MICROI AW − 4 ; i = i +1){303 / / seq {

i f ( ( m i c r o I n s t r >>i )<−1){305 s w i t c h ( i ){

c a s e 0 :

307 acc = 0@opP1 ;

b r e a k ;

309 c a s e 1 :

acc = 0@opP2 ;

311 b r e a k ;

c a s e 2 :

313 acc = opL1 ;

b r e a k ;

315 c a s e 3 :

acc = opL2 ;

317 b r e a k ;

c a s e 4 :

319 opL1 = acc ;

b r e a k ;

321 c a s e 5 :

opL2 = acc ;

323 b r e a k ;

c a s e 6 :

325 mainMemory . p1 [ opL1<−RAM AW] = acc ;

b r e a k ;

327 c a s e 7 :

mainMemory . p2 [ opL2<−RAM AW] = acc ;

329 b r e a k ;

c a s e 8 :

331 d a t a . p1 [ opL1<−MICRO LOCALMEM AW] = acc ;

b r e a k ;

333 c a s e 9 :

d a t a . p2 [ opL2<−MICRO LOCALMEM AW] = acc ;

335 b r e a k ;

c a s e 1 0 :

337 opL1 = d a t a . p1 [ opL1<−MICRO LOCALMEM AW ] ;

116

Page 126: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

b r e a k ;

339 c a s e 1 1 :

opL2 = d a t a . p2 [ opL2<−MICRO LOCALMEM AW ] ;

341 b r e a k ;

c a s e 1 2 :

343 opL2 = 0@opP2 ;

b r e a k ;

345 c a s e 1 3 :

opL1 = 0@opP1 ;

347 b r e a k ;

c a s e 1 4 :

349 t r ameOut = 0@acc + (0@opL1)<<DW;

procOut ! t rameOut ;

351 b r e a k ;

c a s e 1 5 :

353 p r o c I n ? acc ;

b r e a k ;

355 c a s e 1 6 :

opL1 = mainMemory . p1 [ opL1<−RAM AW] ;

357 b r e a k ;

c a s e 1 7 :

359 opL2 = mainMemory . p2 [ opL2<−RAM AW] ;

b r e a k ;

361 c a s e 2 0 :

acc = opL1 + opL2 ;

363 b r e a k ;

c a s e 2 1 :

365 p a r {acc = 0 ;

367 s o u r c e = opL1 ;

m u l t i p l i e u r = opL2 ;

369 }p a r ( i =0 ; i < DW; i ++){

371 seq {u n s i g n e d i n t 1 b i t ;

373 b i t = ( m u l t i p l i e u r >> i )<−1;

i f ( b i t == 1) tRes [0@i ] = 0@( s o u r c e << i ) ;

375 e l s e tRes [0@i ] = 0 ;

}377 }

seq ( i =0 ; i<DW; i ++){379 acc = acc + tRe s [ i ] ;

}381 b r e a k ;

c a s e 2 2 :

383 acc = opL1 − opL2 ;

b r e a k ;

385 c a s e 2 3 :

acc = 0@( opL1<< opL2<−6);

387 b r e a k ;

c a s e 2 4 :

389 acc = 0@( opL1 >> opL2<−6);

b r e a k ;

391 c a s e 2 5 :

117

Page 127: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

i f ( ( cond = = 1 ) | | ( acc > 0 ) ){393 pc = opL1<−ROM AW − 1 ;

}395 b r e a k ;

c a s e 2 6 :

397 opL1 = 0@opP2 ;

b r e a k ;

399 c a s e 2 7 :

opL2 = 0@opP1 ;

401 b r e a k ;

c a s e 2 8 :

403 i f ( opL1 > opL2 ) acc =1;

e l s e acc = 0 ;

405 b r e a k ;

d e f a u l t : w h i l e ( 1 ) d e l a y ; /∗ unknown opcode ∗ /

407 }}

409 / / }}

411 mic = mic + 1 ;

}413 e l s e i f ( t y p e == 0){ / / M o d i f i c a t i o n de l a mic

s w i t c h ( a c t i o n ){415 c a s e 0 : / / No u v e l l e i n s t r u c t i o n : i f e t c h

pc = pc +1;

417 p a r {newInstrOK = 1 ;

419 m i c r o C o n t r o l e u r I n ? i n s t r u c t i o n ;

}421 p a r {

opP1 = operand1 ;

423 opP2 = operand2 ;

opL1 = 0 ;

425 opL2 = 0 ;

seq {427 i f ( opcode != HALT) mic = 0@opcode ;

e l s e {429 p a r {

end = 1 ; / / f i n du programme

431 acc = 0 ;

}433 }

}435 }

b r e a k ;

437 c a s e 1 : / / I n c r e m e n t a t i o n de l a mic

mic = mic + 1 ; b r e a k ;

439 c a s e 2 : / / Sa u t c o n d i t i o n n e l

i f ( ( cond )&&( acc >0)){441 mic = ( m i c r o I n s t r )<−MIC AW;

}443 b r e a k ;

c a s e 3 : / / Sa u t i n c o n d i t i o n n e l

445 mic = ( m i c r o I n s t r )<−MIC AW; b r e a k ;

118

Page 128: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

d e f a u l t : w h i l e ( 1 ) d e l a y ;

447 }}

449

}451 newInstrOK = 1 ; / / n e w I n s t r ! 1 ; / / s i g T r a i t e m e n t = 1 ;

}453

/∗455 ∗ Agent de communica t ion

∗457 ∗ /

s t a t i c macro p ro c comAgent ( I1 , I2 , I3 , I4 , O1 , O2 , O3 , O4 ,

459 i nP roc , ou tP roc , t ab l eR , tableCV1 ,

tableCV2 , tableCV3 , tableCV4 ){461

u n s i g n e d i n t 32 donneeIn , donneeOut ;

463 u n s i g n e d i n t 32 d l c i I n , d l c i O u t ;

u n s i g n e d i n t 38 trameOut , t r a m e I n ;

465 u n s i g n e d i n t (COM CHAN AW + COM DLCI AW+ COM HERE AW) cv ; / / c i r c u i t v i r t u e l de r e c h e r c h

u n s i g n e d i n t (COM CHAN AW+COM DLCI AW+ COM DEST AW) r o u t e ; / / r o u t e de r e c h e r c h e

467 u n s i g n e d i n t (COM CHAN AW+COM DLCI AW) idCV ; / / i d e n t i f i a n t du CV dans l a t a b l e

469

/ / Macro de d ecodage de t r ame v e n a n t du p r o c e s s e u r

471 macro ex p r d e s t O u t = ( t rameOut \\DW)<−COM DEST AW;

/ / Macros de d ecodage de l a t a b l e de r o u t a g e

473 macro ex p r r o u t e c h a n O u t = r o u t e <−COM CHAN AW;

macro ex p r r o u t e d l c i O u t = ( r o u t e \\COM CHAN AW)<−COM DLCI AW ;

475 / / Macros de d ecodage de l a t a b l e des C i r c u i t s V i r t u e l s

macro ex p r c v d l c i I n = ( t r a m e I n \\ DW)<−COM DLCI AW ; / / d l c i de l a t r ame e n t r a n t e

477 macro ex p r cv chanOut = cv <−COM CHAN AW;

macro ex p r c v d l c i O u t = ( cv \\ COM CHAN AW )<−COM DLCI AW ;

479 macro ex p r c v h e r e = ( cv \\ (COM CHAN AW+COM DLCI AW))<−COM HERE AW;

481 p a r {/ / Emiss ion

483 w h i l e ( 1 ){o u t P r o c ? t rameOut ;

485 r o u t e = t a b l e R [ d e s t O u t ] ; / / r e c h e r c h e de l a bonne r o u t e

s w i t c h ( r o u t e c h a n O u t ){487 c a s e 0 :

t rameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

489 O1 ! t rameOut ;

b r e a k ;

491 c a s e 2 :

t rameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

493 O2 ! t rameOut ;

b r e a k ;

495 c a s e 3 :

t rameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

497 O3 ! t rameOut ;

b r e a k ;

499 c a s e 4 :

119

Page 129: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

t r ameOut = 0@( trameOut<−DW) + ( ( 0 @ r o u t e d l c i O u t )<<DW) ;

501 O4 ! t rameOut ;

b r e a k ;

503 d e f a u l t :

d e l a y ; / / D e s t i n a t i o n in c o n n u e : p e r t e du message

505 } ;

}507 / / R e c e p t i o n & t r a n s m i s s i o n

w h i l e ( 1 ){509 p r i a l t {

c a s e I1 ? t r a m e I n :

511 cv = tableCV1 [ c v d l c i I n ] ; / / R e c u p e r a t i o n du DLCI dans l a t a b l e 1

i f ( c v h e r e ){513 i n P r o c ! t r ameIn <−DW; / / t r a n s m i s s i o n au p r o c e s s e u r

}515 e l s e {

s w i t c h ( cv chanOut ){ / / s e l e c t i o n du c a n a l de s o r t i e

517 c a s e 1 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

519 O1 ! t r a m e I n ;

b r e a k ;

521 c a s e 2 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

523 O2 ! t r a m e I n ;

b r e a k ;

525 c a s e 3 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

527 O3 ! t r a m e I n ;

b r e a k ;

529 c a s e 4 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

531 O4 ! t r a m e I n ;

b r e a k ;

533 d e f a u l t :

d e l a y ; / / D e s t i n a t i o n i n c o n n u e : p e r t e du message

535 } ;

}537 b r e a k ;

c a s e I2 ? t r a m e I n :

539 cv = tableCV2 [ c v d l c i I n ] ; / / R e c u p e r a t i o n du DLCI dans l a t a b l e 2

i f ( c v h e r e ){541 i n P r o c ! t r ameIn <−DW; / / t r a n s m i s s i o n au p r o c e s s e u r

}543 e l s e {

s w i t c h ( cv chanOut ){ / / s e l e c t i o n du c a n a l de s o r t i e

545 c a s e 1 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

547 O1 ! t r a m e I n ;

b r e a k ;

549 c a s e 2 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

551 O2 ! t r a m e I n ;

b r e a k ;

553 c a s e 3 :

120

Page 130: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

555 O3 ! t r a m e I n ;

b r e a k ;

557 c a s e 4 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

559 O4 ! t r a m e I n ;

b r e a k ;

561 d e f a u l t :

d e l a y ; / / D e s t i n a t i o n i n c o n n u e : p e r t e du message

563 } ;

}565 b r e a k ;

c a s e I3 ? t r a m e I n :

567 cv = tableCV3 [ c v d l c i I n ] ; / / R e c u p e r a t i o n du DLCI dans l a t a b l e 3

i f ( c v h e r e ){569 i n P r o c ! t r ameIn <−DW; / / t r a n s m i s s i o n au p r o c e s s e u r

}571 e l s e {

s w i t c h ( cv chanOut ){ / / s e l e c t i o n du c a n a l de s o r t i e

573 c a s e 1 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

575 O1 ! t r a m e I n ;

b r e a k ;

577 c a s e 2 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

579 O2 ! t r a m e I n ;

b r e a k ;

581 c a s e 3 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

583 O3 ! t r a m e I n ;

b r e a k ;

585 c a s e 4 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

587 O4 ! t r a m e I n ;

b r e a k ;

589 d e f a u l t :

d e l a y ; / / D e s t i n a t i o n i n c o n n u e : p e r t e du message

591 } ;

}593 b r e a k ;

c a s e I4 ? t r a m e I n :

595 cv = tableCV4 [ c v d l c i I n ] ; / / R e c u p e r a t i o n du DLCI dans l a t a b l e 4

i f ( c v h e r e ){597 i n P r o c ! t r ameIn <−DW; / / t r a n s m i s s i o n au p r o c e s s e u r

}599 e l s e {

s w i t c h ( cv chanOut ){ / / s e l e c t i o n du c a n a l de s o r t i e

601 c a s e 1 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

603 O1 ! t r a m e I n ;

b r e a k ;

605 c a s e 2 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

607 O2 ! t r a m e I n ;

121

Page 131: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

b r e a k ;

609 c a s e 3 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

611 O3 ! t r a m e I n ;

b r e a k ;

613 c a s e 4 :

t r a m e I n = 0@( t rameIn <−DW) + ( ( 0 @cv dlc iOut)<<DW) ;

615 O4 ! t r a m e I n ;

b r e a k ;

617 d e f a u l t :

d e l a y ; / / D e s t i n a t i o n i n c o n n u e : p e r t e du message

619 } ;

}621 b r e a k ;

}623 }

}625 }

627

629 /∗∗ M u l t i p l e x e u r d ’ a f f i c h a g e

631 ∗∗ /

633 s t a t i c macro p ro c RunConsole ( p r i n t )

{635 s t a t i c u n s i g n e d 32 X;

u n s i g n e d i n t 32 from ;

637 u n s i g n e d i n t 32 v a l ;

u n s i g n e d i n t 32 cmpt ;

639 s t a t i c ram u n s i g n e d c h a r S t r i n g [ 2 5 6 ] =

” Proc : ” ;

641 s t a t i c ram u n s i g n e d c h a r S t r i n g 2 [ 2 5 6 ] =

” V a l e u r : ” ;

643 P a l C o n s o l e ∗C o n s o l e P t r ;

P a l V i d e o O u t R e q u i r e ( 1 ) ;

645 cmpt = 0 ;

p a r

647 {w h i l e ( 1 ){

649 P a l C o n s o l e E n a b l e ( C o n s o l e P t r ) ;

p r i a l t

651 {c a s e p r i n t [ 0 ] ? v a l :

653 from = 0 ;

b r e a k ;

655 c a s e p r i n t [ 1 ] ? v a l :

from = 1 ;

657 cmpt ++;

b r e a k ;

659 c a s e p r i n t [ 2 ] ? v a l :

from = 2 ;

661 b r e a k ;

122

Page 132: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

c a s e p r i n t [ 3 ] ? v a l : / / c a n a l de debuggage ne v e n a n t pas d ’ un p r o c e s s e u r

663 from = 1 0 ;

b r e a k ;

665 }P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g ) ;

667 P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , from ) ;

X = 0@val ;

669 P a l C o n s o l e P u t S t r i n g ( C o n s o l e P t r , S t r i n g 2 ) ;

P a l C o n s o l e P u t U I n t ( C o n s o l e P t r , X ) ;

671 P a l C o n s o l e P u t C h a r ( C o n s o l e P t r , ’\n ’ ) ;

}673

PalConsoleRun (& C o n s o l e P t r , PAL CONSOLE FONT NORMAL,

675 PalVideoOutOpt imalCT ( ClockRa te ) , C lockRa te ) ;

}677

}679 s t a t i c macro p ro c RAM1ToParal lel ( Addr , p r i n t )

{681 u n s i g n e d 20 j ;

u n s i g n e d 36 d a t ;

683 j =0 ;

w h i l e ( j < Addr ){685 RC200PL1RAM1SetReadAddress ( j ) ;

RC200PL1RAM1Read(& d a t ) ;

687

P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , ( da t >>24)<−8);

689 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , ( da t >>16)<−8);

P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , ( da t >>8)<−8);

691 P a l D a t a P o r t W r i t e ( P a r a l l e l P o r t , da t <−8);

j ++;

693 }

695 }s t a t i c macro p ro c Paral lelToRAM0 ( Addr , p r i n t )

697 {

699 u n s i g n e d 32 c ;

u n s i g n e d 20 z ;

701 u n s i g n e d 8 i ;

u n s i g n e d 8 n b O c t e t s ;

703 u n s i g n e d 32 tmp ;

u n s i g n e d 8 f r o m P o r t ;

705 i =0 ;

707 seq

{709

P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &n b O c t e t s ) ; / / Nombre d ’ o c t e t s a l i r e : max 25

711 do

{713 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

c = 0 @fromPort ;

715 tmp = ( c << 2 4 ) ;

123

Page 133: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

717 c = 0 @fromPort ;

tmp += ( c << 1 6 ) ; / / L e c t u r e dans une v a r i a b l e de 32 b i t s

719 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

c = 0 @fromPort ;

721 tmp += ( c << 8 ) ; / / . . .

P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &f r o m P o r t ) ;

723 c = 0 @fromPort ;

tmp += 0@c; / / . . .

725 RC200PL1RAM0SetWriteAddress ( Addr ) ;

RC200PL1RAM0Write (0@tmp ) ;

727 p a r {Addr ++;

i +=4;

729 tmp =0;

}731 } w h i l e ( i < n b O c t e t s ) ;

733 }

735 }

737 s t a t i c macro p ro c R e a d P a r a l l e l ( p r i n t , program )

{739

u n s i g n e d i d I n s t r ;

741 u n s i g n e d 8 c ;

u n s i g n e d i n t 32 tmp ;

743 u n s i g n e d i n t 32 tmp2 ;

u n s i g n e d i n t 6 deca ;

745 u n s i g n e d i n t 32 zone ; / / t y p e de zone : donn ees ou prog

u n s i g n e d i n t 32 code ;

747 u n s i g n e d i n t 32 recu , i ;

p a r {749 zone = 0 ;

i d I n s t r = 0 ;

751 deca =24;

r e c u = 0 ;

753 tmp = 0 ;

}755 seq

{757 / / R e c e p t i o n du nombre d ’ o c t e t s de code

seq ( i = 0 ; i <4; i ++){759 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ;

tmp2 =0;

761 tmp2 = 0@c;

tmp += tmp2 << deca ;

763 deca = deca − 8 ;

}765 p a r {

code = tmp ;

767 deca = 2 4 ;

}769 p a r {

124

Page 134: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

ANNEXE H. COMMUNICATION PAR CIRCUITS VIRTUELS : CODE

HANDEL-C

tmp = 0 ;

771 r e c u = 0 ;

}773 / / R e c e p t i o n du programme

w h i l e ( r e c u < code )

775 {seq ( i = 0 ; i <4; i ++){

777 P a l D a t a P o r t R e a d ( P a r a l l e l P o r t , &c ) ;

tmp2 =0;

779 tmp2 = 0@c;

tmp += tmp2 << deca ;

781 p a r {deca −= 8 ;

783 r e c u = r e c u + 1 ;

}785 }

program [ i d I n s t r ] = tmp ;

787 p a r {i d I n s t r ++;

789 tmp =0;

deca = 2 4 ;

791 }}

793

}795

}

125

Page 135: penarvir.univ-brest.frpenarvir.univ-brest.fr/reports/2006/WPPESynthesis.pdf · Table des matieres` 1 Contexte et objectifs du projet 2 1.1 Recherchessurlespossibilitesdeprototypaged’architecturesparall´

Annexe I

Microcode du microcontroleur

126