== Petite présentation ==

Quelques mots concernant ma personne, je suis électronicien de formation mais j'ai assez rapidement délaissé le fer à souder pour me consacrer plus à la programmation système et aux (micro)processeurs qui sont ma vrai passion.

J'ai débuté ma carrière professionnelle 1993 avec le 80C51 pour arriver maintenant en 2008 aux processeurs ARM (type iMX27) et softcore (NIOS II d'Altera).

En 1998, j'ai fait mes premières armes avec le protocole TCP/IP, j'ai participé à la conception d'un système complet (RTOS + TCP/IP + Services) sur un 68EN360. A l'époque les accès internet n'étaient pas très connus, on communiquait encore beaucoup par téléphone/FAX ou pour les plus à la pointe via CompuServe. C'était les balbutiements de la fameuse ''Bulle Internet''.

Après cela, les technos ceux sont enchainées, en vrac: MP3, Linux, ActiveX, .NET, Windows CE, XP Embedded, VHDL, System on Chip, et d'autres encore.

Début 2000, j'ai fait la découverte de Linux, tout d'abord avec la distribution '''Suze''' et très rapidement '''Debian''', que j'utilise chez moi sur un PC qui me sert de serveur et, en 2004, je me suis mis à '''Ubuntu''', que j'utilise sur mon PC portable en dual boot avec Windows, parce que certains outils ne fonctionnent que sous Windows et qu'au boulot de toute façon j'utilise Windows.

Fin 2006, découvert l'association Armadeus sur Linux-Fr, et après quelques échanges de mails pour ''sentir'' un peu l'association, je me suis lancé dans l'aventure et j'ai commandé ma carte APF9328 :-)

== Mes centres d'intérêts ==

Il y a beaucoup de choses qui m'intéressent et que j'aimerai pouvoir essayer avec la carte APF9328.

Mon centre d'intérêt le plus fort en ce moment, c'est le VHDL. C'est l'association d'un FPGA avec un microprocesseur sur la même carte qui m'a fait craquer pour la carte APF9328. Dans mon travail, j'ai souvent affaire aux FPGA, dans mon cas de chez Aletra et non Xilinx. J'ai accumulé pas mal d'expérience avec ces périphériques et l'envie de les utiliser ''pour moi'' est donc venue tout naturellement.

A coté de cela, cette carte me donne la possibilité de me mettre à la programmation Linux, que je ne connait finalement seulement qu'en tant qu'utilisateur. De plus je n'ai jamais utilisé Linux ailleurs que sur PC, l'utilisation dans le monde de l'embarqué est également une découverte pour moi.

== Mes projets en cours ==

=== Orchestra ===
La première chose qui m'est apparue en mettant en oeuvre la carte APF9328, c'est le manque d'outils permettant la mise en oeuvre ''simple'' d'un design dans le FPGA. La simplicité est toujours quelque chose de relatif. Et pour moi, qui suis habitué aux outils Altera, la mise en oeuvre d'un '''System on Chip''' sur les FPGA Altera a toujours été quelque chose de très simple, et ceci en particulier grâce à l'outil '''SoPC Builder'''.

C'est ce manque d'outil qui m'a donner l'envie de créer mon propre outil de conception de System on Chip. Après en avoir discuter avec Nicolas Colombain (aka salocin) et la rédactions de quelques spécifications sur le wiki, je me suis lancé dans l'aventure.

Et voilà le point de départ d'Orchestra :)

Le projet est encore à ces balbutiement mais j'espère bien pouvoir obtenir une première version utilisable pour début 2009. Actuellement le projet est hébergé sous '''berlios''' [http://osocgen.berlios.de].

2008-02-12T08:03:55Z

FabriceM: /* Convention de codage */

2007-01-14T20:51:01Z

FabriceM: /* Vue d'ensemble du système Orchestra */

2006-12-22T21:35:17Z

FabriceM: /* La composition du système Wishbone */

= Spécifications de conception du FPGA =

== Evolutions ==

2006/12/21: MAJ en fonction des remarques de tout le monde.

== But ==

Cette page a été créée pour permettre à tous les membres de l'association de discuter de l'architecture qui va être mise en place pour le FPGA présent sur la carte APF9328.

Cette espace doit être vu comme un espace d'échange d'idées. Tout le monde est convié à y participer. Il est préférable d'avoir quelques connaissances en électronique et sur les langages HDL (VHDL ou Verilog), mais ce n'est pas une obligation.

Bonne lecture et merci pour votre participation.

== Les grandes lignes ==

Le FPGA de la carte APF9328 est là pour offrir le maximum de souplesse au projet '''Armadeus''' et permettre d'implanter des fonctionnalités coté '''matériel''' qui seraient trop pénalisantes ou impossibles à implanter coté '''logiciel'''. Bien entendu, pour que cela soit exploitable, il faut également disposer d'un lien entre le FPGA et le processeur i.MX.

Pour réaliser cela, il faut mettre en place un bus de communication entre le FPGA et l'i.MX. Ce bus de communication va permettre le pilotage des fonctionnalités qui seront implantées dans le FPGA. Bref, il faut recréer à l'intérieur du FPGA un bus tel qu'il existe entre l'i.MX et les différents composants de la carte (RAM, Flash, USB, Ethernet, etc.).

Pour gagner en temps de développement et pour pouvoir récupérer des fonctionnalités ou IP (Intellectual Property) déjà existantes, le bus Wishbone a été retenu. Ce bus, dont les spécification ont été placées dans le domaine public, a été conçu spécifiquement pour ce genre de configuration et sur le site '''[http://www.opencores.com www.opencores.com]''' plusieurs IP compatibles avec les spécifications Wishbone sont disponibles.

== Le bus Wishbone ==

La spécification Wishbone décrit un certain nombre de composants de base:
* Des interfaces '''maitres''', ces interfaces sont implantés dans des composants qui seront alors capable d'initier les transferts sur le bus Wishbone
* Des interfaces '''esclaves''', ces interfaces sont implantés dans des composants capables de répondre à des demandes de transferts
* Un composant '''syscon''', ce composant va générer le signal d'horloge qui sera utilisé par tous les composants/interfaces du bus ainsi que le signal de RESET synchrone.
* Un macro composant '''intercon''', ce composant va gérer la connexion de toutes les interfaces maitres et esclaves qui composent le bus interne. Il prend en charge :
** Le décodage/transcodage d'adresse (génération des signaux A0 à A3 selon le mode d'adressage 8/16/32/64 bits)
** le routage du bus de données entre les différentes interfaces maitres et esclaves (conversion big endian/little endian, etc)
** le routage/génération des signaux de contrôle du bus (Read, Write, Chip Select, Output Enable, ACK, etc.)
* Un composant '''arbitre''', ce composant va permettre de partager l'accès au bus ou à un composant de type esclave qui est partagé par plusieurs composants de type maitre.

Les spécifications du bus Wishbone permettent de créer différents types de bus:
* '''Point to Point''': C'est le type de bus le plus simple possibl, un composant avec une interface type maitre connecté à un composant avec une interface de type esclave.
* '''Data Flow''': C'est un bus en cascade, à un bout on trouve un composant avec une interface de type maître et à l'autre bout un composant avec une interface de type esclave. Entre les deux composant se trouve une chaine d'un ou plusieurs composants avec une interface de type maitre et de type esclave.
* '''Shared''': C'est un bus sur lequel plusieurs composants sont connectés dessus. Tous les composants se partagent ce bus. Si plusieurs ''maitres'' sont connectés sur ce bus, un seul pourra initier un transfert à un instant donné.
* '''CrossBar''': C'est également un bus de type partagé, par contre dans se cas, on dispose de plusieurs bus. Chaque maitre utilise sont propre bus pour communiquer avec ces esclaves. On peut donc avoir plusieurs transferts en simultané. Le seul cas de blocage/arbitrage est le transfert de plusieurs maitre avec le même esclave.

Il existe également un certain nombre de mécanismes dans la spécification Wishbone pour permettre d'optimiser les temps de transferts sur le bus. Ces optimisations sont de plusieurs nature:
* utilisation de signaux '''ACK''', '''ERR''' et '''RTY''' pour signaler la fin de transfert
* les '''Registered Feedback Bus Cycles''', qui permettent de gagner un cycle d'horloge pour des transferts consécutifs
* les transferts en mode '''Burst'''

== Le lien i.MX <=> FPGA ==

La communication entre l'i.MX et le FPGA passe par les signaux suivants (à vérifier):
* des signaux de contrôle: <strike>RW_n</strike>, OE_n, EB_n[3..2] et CS1_n
* le bus de données sur 16 bits (D[15..0])
* le bus d'adresses sur 12 bits (A[12..1])

Ces signaux sont alors utilisés pour créer une interface Wishbone maitre qui va permettre de communiquer efficacement avec les autres IPs contenus dans le FPGA qui implémenterons une interface wishbone de type esclave.

Etant donné les erratas du composant i.MX concernant le signal DTACK, il n'est pas possible d'implanter une interface Wishbone maitre ''classique''. Ceci entraine les limitations suivantes:
* Pas possible d'utiliser le signal '''ACK''' Wishbone pour terminer le transfert entre FPGA et i.MX.
* Pas possible de mettre en place des optimisations du temps de transfert.

Pour contrer ce problème, il faudra s'assurer que toutes les interfaces esclaves qui seront connectées à l'interface maitre du composant Wishbone i.MX répondent dans un temps fixe donné.<br />
Comme le bus Wishbone est un bus entièrement synchrone, le temps minimal d'un transfert est de 2 cycles de l'horloge Wishbone. Il faut ajouter à cela, un cycle pour la synchronisation des signaux du bus i.MX. Cela nous fait donc un minimum de 3 cycles Wishbone pour un transfert entre le FPGA et l'i.MX.

Etant donné les performances des FPGA actuels, on peut tabler sur une fréquence de fonctionnement d'au moins 100MHz pour le bus Wishbone. Cela nous donne donc un taux de transfert approximatif de 66 Moctets/sec (100MHz * 16bits / 3).

== La composition du système Wishbone ==

[[Image:FPGA_Armadeus.png]]

Le système Wishbone qui sera implanté dans le FPGA se compose des éléments suivants:
* '''i.MX Wrapper''': L'interface i.MX vers le bus Wishbone
* '''Syscon''': Ce composant va gérer les signaux '''CLK''' (généré par une PLL ou directement issu de l'i.MX) et '''RESET''' (synchrone).
* '''Intercon''': Ce composant devra être généré automatiquement par une moulinette, il va faire le lien entre tous les composants faisant parti du '''Système Wishbone'''.
* '''Gestionnaire d'interruption''': Ce composant est un '''esclave wishbone''' et va centraliser toutes les demandes d'interruption et les remonter vers l'i.MX.
* '''Esclaves whisbone''': Ceci représentent tous les autres composants avec une interface wishbone esclave qui sont accessibles via le wrapper i.MX.

Sur le diagramme, il manque un certain nombre de choses:
* Les signaux ''non wishbone'' en entrée ou en sortie sur les '''esclaves wishbone'''
* Le macro composant '''système wishbone'''. Ce macro composant est celui qui sera ensuite instancié dans le design du FPGA. Sur ce composant ne seront visibles que les signaux ''externes'' au système:
** Les signaux issus de l'i.MX
** <strike>Le signal RESET (en entrée) qui sera synchronisé sur l'horloge système</strike> Le signal RESET synchrone du bus Wishbone sera directement généré par le composant syscon à l'aide d'une simple machine d'état.
** Le signal CLK (en entrée) qui sera l'horloge utilisée pour la génération des signaux Wishbone
** Le signal IRQ (en sortie) qui sera utilisé pour remonter les demandes d'interruption vers l'i.MX
** Les signaux d'entrée et de sortie spécifiques aux autres composants connectés sur le bus Wishbone

L'intérêt de créer le composant '''Système Wishbone''', est que cela simplifie la vision dans l'outil conception du FPGA. Il ne suffit plus alors qu'à relier les signaux sur les broches correspondantes du FPGA.

=== i.MX Wrapper ===

Ce composant est le point d'accès au bus Wishbone pour l'i.MX et sera le seul à disposer d'une interface Wishbone maitre.

Les fonctions de ce composants sont:
* synchronisation des signaux issus de l'i.MX. Ceci est primordial pour assurer la stabilité de tout le système Wishbone. De plus, le bus de sortie étant asynchrone (l'horloge de génération des signaux n'est pas véhiculée), la resynchronisation des signaux par rapport à l'horloge du bus s'impose.
* gestion du bus de données en 3 états.
* conversion des signaux de contrôle du bus i.MX en signaux Wishbone.

=== Syscom ===

C'est le composant le plus simple du système <strike>, il ne fait que synchroniser le signal RESET en entrée avec le signal d'horloge du système</strike>.

Il va être en charge de la génération du signal RESET synchrone pour le bus Wishbone.

Le signal d'horloge en entrée du composant '''syscon''' sera celui utilisé pour le fonctionnement du bus Wishbone. La fréquence du signal d'horloge devra être assez élevée pour permettre le traitement des signaux issus de l'i.MX. Cela va dépendre de la configuration du chip select utilisé (CS5).

La source du signal d'horloge reste encore à définir, les choix possibles sont:
* directement issu de l'i.MX
* utilisation d'un DCM du Spartan 3

Le choix définitif dépendra principalement des essais ''grandeur nature'' lors de la génération des premiers systèmes whisbone durant la phase de mise en place des composants de base.

=== Intercon ===

Ce composant a la particularité qu'il sera créé automatiquement par un outil (script ou programme). '''Intercom''' a comme fonctionnalités:
* Le décodage d'adresse pour la sélection des différents esclaves du système
* Le routage des bus d'adresses et de données vers les différents esclaves
* La génération des signaux de contrôle pour les différents esclaves.

Etant donné les limitations induites par les erratas de l'i.MX, le composant '''intercom''' remplira les fonctionnalités suivantes:
* le bus de données est figé sur 16 bits
* les cycles de lecture et d'écriture sont de longueur fixe (à priori 3 cycles d'horloge '''à valider''' lors des essais du système de base)
* une interruption est générée en cas de dépassement du temps de cycle d'écriture ou de lecture
* le bus sera de type '''shared''' avec un seul maitre (le Wrapper i.MX).

=== Les composants esclaves ===

<span style="color:#FF0000;">
<big>Suite aux divers discussions issues de ce chapitre. L'organisation et la présences des fichiers dans les répertoires ''doc''' et '''HAL''' n'est pas encore établie. Ce chapitre sera encore à retravailler.</big>
</span>

Pour qu'une IP puisse être facilement inclue dans le système, il faut une certaine organisation. Sinon, à moyen ou à long terme cette IP est morte parce qu'elle sera difficilement exploitable et encore plus difficilement maintenable.

Ce sont des notions qui ne sont pas simples à prendre en considération lors du développement d'un nouveau projet, mais lorsque l'on doit se replonger dans un travail fait par quelqu'un d'autre ou un projet qu'on a laissé en sommeil pendant quelque temps, on est content d'avoir quelque chose à quoi se raccrocher.

Pour développer efficacement, il faut assurer une organisation logique, figée et compréhensible, et le plus simple dans ce genre de cas est de se baser sur la notion de répertoire. Voici les répertoires qui doivent être utilisés par une IP:
* '''doc''': Ce répertoire va contenir toute la documentation nécessaire à l'exploitation de l'IP. On y trouvera une notice ('''readme.txt'''), un fichier de suivi de modification ('''ChangeLog.txt'''), un fichier contenant les évolutions futures prévues ('''todo.txt''') ainsi que tout autre fichier estimé utile par le(s) créateur(s) de l'IP.
* '''hdl''': Ce répertoire va contenir tous les fichiers VHDL (ou Verilog) qui auront été développés spécifiquement pour cette IP.
* '''inc''': Ce répertoire va contenir un fichier d'en-tête ANSI C contenant l'adresse de tous les registres interne de l'IP pour permettre de créer simplement un programme en langage C permettant de contrôler l'IP. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''
* '''HAL''': Ce répertoire va contenir un drivers ou un exemple de logiciel de base permettant l'utilisation de l'IP par un microprocesseur/contrôleur. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''

=== Gestionnaire d'interruption ===

Ce composant esclave est le premier qui sera créé spécifiquement pour le système. Il sera capable de:
* prendre en compte jusqu'à 16 sources d'interruptions différentes
* réaliser l'acquittement de chaque interruption individuellement
* masquer/autoriser chaque interruption individuellement

Le composant disposera des registres suivants:
* '''isr_mask''': registre d'autorisation des interruptions. Chaque bit correspond à une interruption (bit0 => IRQ0, bit1 => IRQ1, etc.). Ce registre sera accessible en lecture et en écriture.
* '''isr_pend''': ce registre est à double emploi
** '''en lecture''': Les interruptions en attente de traitement
** '''en écriture''': Acquittement des interruptions. Chaque bit à 1 va acquitter l'interruption correspondante.

== Le script / programme d'assemblage des IP ==

Nous allons maintenant parler du coeur du système, du moins de la partie la plus visible de l'iceberg ;-)

La première des priorités, sera de trouver un nom pour cet outil qui reste un peu dans l'esprit du projet. Voici quelques propositions, à vous de compléter ou de voter pour un nom ou plusieurs noms:
* Concerto
* Orchestra

=== Principe et fonctionnement ===

Afin de de rendre tout ce système utilisable par le plus grand nombre, il faut être capable de proposer des outils qui vont simplifier la vie de l'utilisateur final ainsi que de l'intégrateur.

Pour cela, il faudra créer un outil soit sous forme de script(s), soit sous forme de programme(s) qui va permettre de réaliser les tâches suivantes:
* Edition d'un '''système wishbone''', c'est-à-dire
** Ajout/suppression de composants '''''Armadeus Ready''''' (c'est comme HD Ready mais en mieux ;-) ).
** Spécification de la valeur des paramètres '''GENERIC''' de chaque composant s'il y en a.
** Configuration des adresses de base de chaque composant placé sur le bus Wishbone. La plage d'adresses étant donné par la taille du bus d'adresses du composant.
** Affectation du bit d'interruption pour chaque composant ayant besoin de générer une interruption.
** Affectation des signaux non wishbone d'entrée et de sortie des composants aux broches du FPGA si cela est possible
* Génération d'un fichier '''''mapping''''' contenant:
** Un ''Time Stamp'' pour connaitre la date de création/génération du système
** Le fréquence de base du bus Wishbone
** L'adresse de base de chaque composant
** Le niveau d'interruption affecté à chaque composant
* Génération du macro composant '''syscon''' qui va faire le lien (routage) entre les différents composants sus le bus Wishbone.
* Génération du composant '''system''' qui va regrouper toutes les connexions internes au système que l'on est en train de créer dans un seul fichier HDL (VHDL ou Verilog). C'est ce fichier qui sera alors instancier dans '''''Xilinx ISE''''' avec éventuellement d'autres IP qui n'ont pas de lien direct avec l'i.MX
* Génération d'un fichier script '''tcl''' pour la création du projet de base pour '''''Xilinx ISE'''''. Ceci va éviter les erreurs de connexions sur les broches du FPGA, au moins pour la partie relative à l'i.MX. Ce script sera directement exécutable par l'outil fourni par Xilinx.
* Génération d'un fichier '''Makefile''' pour la création des --?? DLL ?? (<- tu veux dire drivers Linux ?)-- '''''host drivers''''' d'accès au système via programme.

=== Gestionnaire d'interruption ===

'''Ce chapitre est donné à titre informatif/propositon et ne tiens pas lieu de spécification.'''

Afin de simplifier la vie des programmeurs systèmes, il faut pouvoir offrir un mécanisme simple de mise en place et de gestion des demandes d'interruption du FPGA.

Pour cela, je propose la solution suivante:
* Mise en place d'un gestionnaire d'interruption générique pour le FPGA. Ce gestionnaire d'interruption sera capable de lire le registre d'interruption (lecture de '''isr_pend''') et de déterminer les interruptions à traiter (via '''isr_mask'''). Il va en suite aiguiller l'exécution de la routine d'interruption vers les routines adéquates pour chaque bit d'interruption valide. L'interruption traitée sera alors acquitée (écriture vers '''isr_pend''').
* Création d'une routine '''''d'enregistrement de vecteur d'interruption'''''. Cette routine va permettre d'ajouter une routine de traitement d'interruption pour un bit d'interruption donné. Pour cela il faudra lui fournir les informations suivantes (via une structure ?!?):
** Le numéro du bit d'interruption (0 à 31)
** La routine de traitement d'interruption pour ce driver
** Un paramètre additionnel à fournir à la routine de traitement d'interruption (pointeur de type '''''void *''''')
** Le nom du drivers (optionnel, permet d'identifier/visualiser les drivers installer éventuellement)
* Création d'une routine de validation d'une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour masquer une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour désinstaller une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine ou méthode pour visualiser tous les drivers Wishbone installés:
** Leur numéro
** Leur nom
** Leur état (validé/masqué)
** Le nombre de fois qu'ils ont été appelé
** etc.

FpgaArchitecture

2006-12-22T20:22:40Z

FabriceM: /* Le lien i.MX <=> FPGA */

FpgaArchitecture

2006-12-22T20:14:05Z

FabriceM: /* Le bus Wishbone */

2006-12-17T13:51:54Z

FabriceM: /* Le script / programme d'assemblage des IP */

= Spécifications de conception du FPGA =

== But ==

Cette page a été créée pour permettre à tous les membres de l'association de discuter de l'architecture qui va être mise en place pour le FPGA présent sur la carte APF9328.

Cette espace doit être vu comme un espace d'échange d'idées. Tout le monde est convié à y participer. Il est préférable d'avoir quelques connaissances en électronique et sur les langages HDL (VHDL ou Verilog), mais ce n'est pas une obligation.

Bonne lecture et merci pour votre participation.

== Les grandes lignes ==

Le FPGA de la carte APF9328 est là pour offrir le maximum de souplesse au projet '''Armadeus''' et permettre d'implanter des fonctionnalités coté '''matériel''' qui seraient trop pénalisantes ou impossibles à implanter coté '''logiciel'''. Bien entendu, pour que cela soit exploitable, il faut également disposer d'un lien entre le FPGA et le processeur i.MX.

Pour réaliser cela, il faut mettre en place un bus de communication entre le FPGA et l'i.MX. Ce bus de communication va permettre le pilotage des fonctionnalités qui seront implantées dans le FPGA. Bref, il faut recréer à l'intérieur du FPGA un bus tel qu'il existe entre l'i.MX et les différents composants de la carte (RAM, Flash, USB, Ethernet, etc.).

Pour gagner en temps de développement et pour pouvoir récupérer des fonctionnalités ou IP (Intellectual Property) déjà existantes, le bus Wishbone a été retenu. Ce bus, dont les spécification ont été placées dans le domaine public, a été conçu spécifiquement pour ce genre de configuration et sur le site '''[http://www.opencores.com www.opencores.com]''' plusieurs IP compatibles avec les spécifications Wishbone sont disponibles.

== Le bus Wishbone ==

La spécification Wishbone décrit un certain nombre de composants de base:
* Des interfaces '''maitres''', ces interfaces sont implantés dans des composants qui seront alors capable d'initier les transferts sur le bus Wishbone
* Des interfaces '''esclaves''', ces interfaces sont implantés dans des composants capables de répondre à des demandes de transferts
* Un composant '''syscon''', ce composant va générer le signal d'horloge qui sera utilisé par tous les composants/interfaces du bus ainsi que le signal de RESET synchrone.
* Un macro composant '''intercon''', ce composant va gérer la connexion de toutes les interfaces maitres et esclaves qui composent le bus interne. Il prend en charge :
** Le décodage/transcodage d'adresse (génération des signaux A0 à A3 selon le mode d'adressage 8/16/32/64 bits)
** le routage du bus de données entre les différentes interfaces maitres et esclaves (conversion big endian/little endian, etc)
** le routage/génération des signaux de contrôle du bus (Read, Write, Chip Select, Output Enable, ACK, etc.)
* Un composant '''arbitre''', ce composant va permettre de partager l'accès au bus ou à un composant de type esclave qui est partagé par plusieurs composants de type maitre.

Les spécifications du bus Wishbone permettent de créer différents types de bus:
* '''Point to Point'''': Un composant avec une interface type maitre connecté à un composant avec une interface de type esclave.
* '''Data Flow''': C'est un bus en cascade, à un bout on trouve un composant avec une interface de type maître et à l'autre bout un composant avec une interface de type esclave. Entre les deux composant se trouve une chaine d'un ou plusieurs composants avec une interface de type maitre et de type esclave.
* '''Shared''': C'est un bus sur lequel plusieurs composants sont connectés dessus. Tous les composants se partagent ce bus. Si plusieurs ''maitres'' sont connectés sur ce bus, un seul pourra initier un transfert à un instant donné.
* '''CrossBar''': C'est également un bus de type partagé, par contre dans se cas, on dispose de plusieurs bus. Chaque maitre utilise sont propre bus pour communiquer avec ces esclaves. On peut donc avoir plusieurs transferts en simultané. Le seul cas de blocage/arbitrage est le transfert de plusieurs maitre avec le même esclave.

Il existe également un certain nombre de mécanismes dans la spécification Wishbone pour permettre d'optimiser les temps de transferts sur le bus. Ces optimisations sont de plusieurs nature:
* utilisation de signaux '''ACK''', '''ERR''' et '''RTY''' pour signaler la fin de transfert
* les '''Registered Feedback Bus Cycles''', qui permettent de gagner un cycle d'horloge pour des transferts consécutifs
* les transferts en mode '''Burts'''

== Le lien i.MX <=> FPGA ==

La communication entre l'i.MX et le FPGA passe par les signaux suivants (à vérifier):
* des signaux de contrôle: RW_n, OE_n, EB_n[3..2] et CS1_n
* le bus de données sur 16 bits (D[15..0])
* le bus d'adresses sur 12 bits (A[12..1])

Ces signaux sont alors utilisés pour créer une interface Wishbone maitre qui va permettre de communiquer efficacement avec les autres IPs contenus dans le FPGA qui implémenterons une interface wishbone de type esclave.

Etant donné les erratas du composant i.MX concernant le signal DTACK, il n'est pas possible d'implanter une interface Wishbone maitre ''classique''. Ceci entraine les limitations suivantes:
* Pas possible d'utiliser le signal '''ACK''' Wishbone pour terminer le transfert entre FPGA et i.MAX.
* Pas possible de mettre en place des optimisations du temps de transfert.

Pour contrer ce problème, il faudra s'assurer que toutes les interfaces esclaves qui seront connectées à l'interface maitre du composant Wishbone i.MX répondent dans un temps fixe donné.<br />
Comme le bus Wishbone est un bus entièrement synchrone, le temps minimal d'un transfert est de 2 cycles de l'horloge Wishbone. Il faut ajouter à cela, un cycle pour la synchronisation des signaux du bus i.MX. Cela nous fait donc un minimum de 3 cycles Wishbone pour un transfert entre le FPGA et l'i.MX.

Etant donné les performances des FPGA actuels, on peut tabler sur une fréquence de fonctionnement d'au moins 100MHz pour le bus Wishbone. Cela nous donne donc un taux de transfert approximatif de 66M octets/sec (100MHz * 16bits / 3).

== La composition du système Wishbone ==

[[Image:FPGA_Armadeus.png]]

Le système Wishbone qui sera implanté dans le FPGA se compose des éléments suivants:
* '''i.MX Wrapper''': L'interface i.MX vers le bus Wishbone
* '''Syscon''': Ce composant va gérer les signaux '''CLK''' (généré par une PLL) et '''RESET''' (synchrone).
* '''Intercon''': Ce composant devra être généré automatiquement par une moulinette, il va faire le lien entre tous les composants faisant parti du '''Système Wishbone'''.
* '''Gestionnaire d'interruption''': Ce composant est un '''esclave wishbone''' et va centraliser toutes les demandes d'interruption et le remontées vers l'i.MX.
* '''Esclaves whisbone''': Ceci représentent tous les autres composants avec une interface wishbone esclave qui sont accessibles via le wrapper i.MX.

Sur le diagramme, il manque un certain nombre de choses:
* Les signaux ''non wishbone'' en entrée ou en sortie sur les '''esclaves wishbone'''
* Le macro composant '''système wishbone'''. Ce macro composant est celui qui sera ensuite instancié dans le design du FPGA. Sur ce composant ne seront visibles que les signaux ''externes'' au système:
** Les signaux issus de l'i.MX
** Le signal RESET (en entrée) qui sera synchronisé sur l'horloge système
** Le signal CLK (en entrée) qui sera l'horloge utilisée pour la génération des signaux Wishbone
** Le signal IRQ (en sortie) qui sera utilisé pour remonter les demandes d'interruption vers l'i.MX
** Les signaux d'entrée et de sortie spécifiques au autres composants connectés sur le bus Wishbone

L'intérêt de créer le composant '''Système Wishbone''', est que cela simplifie la vision dans l'outil conception du FPGA. Il ne suffit plus alors qu'à relier les signaux sur les broches correspondantes du FPGA.

=== i.MX Wrapper ===

Ce composant est le point d'accès au bus Wishbone pour l'i.MX.

=== Syscom ===

C'est le composant le plus simple du système, il ne fait que synchroniser le signal RESET en entrée avec le signal d'horloge du système.

=== Intercon ===

Ce composant a la particularité qu'il sera créé automatiquement par un outils (script ou programme). '''Intercom''' a comme fonctionnalité:
* Le décodage d'adresse pour la sélection des différents esclaves du système
* Le routage des bus d'adresses et de données vers les différents esclaves
* La génération des signaux de contrôle pour les différents esclaves.

Etant donné les limitations induites par les erratas de l'i.MX, le composant '''intercom''' remplira les fonctionnalités suivantes:
* le bus de données est figé sur 16 bits
* les cycles de lecture et d'écriture sont de longueur fixe (à priori 3 cycles d'horloge '''à valider''')
* une interruption est générée en cas de dépassement du temps de cycle d'écriture ou de lecture

=== Les composants esclaves ===

Pour qu'une IP puisse être facilement incluse dans le système, il faut une certaine organisation. Sinon, à moyen ou à long terme cette IP est morte parce qu'elle sera difficilement exploitable et encore plus difficilement maintenable.
Ceux sont des notions pas simple à prendre en considération lors du développement d'un nouveau projet, mais lorsque l'on doit se replonger dans un travail fait par quelqu'un d'autre ou un projet qu'on a laissé en sommeil pendant quelque temps, on est content d'avoir quelque chose à quoi se raccrocher.
Pour développer efficacement, il faut assurer une organisation logique, figée et compréhensible, et le plus simple dans ce genre de cas est de se baser sur la notion de répertoire. Voici les répertoires qui doivent être utilisés par une IP:
* '''doc''': Ce répertoire va contenir toute la documentation nécessaire à l'exploitation de l'IP. On y trouvera une notice ('''readme.txt'''), un fichier de suivit de modification ('''ChangeLog.txt'''), un fichier contenant les évolutions futures prévues ('''todo.txt''') ainsi que tout autre fichier estimé utile par le(s) créateur(s) de l'IP.
* '''hdl''': Ce répertoire va contenir tous les fichiers VHDL (ou Verilog) qui auront été développés spécifiquement pour cette IP.
* '''inc''': Ce répertoire va contenir un fichier d'en-tête ANSI C contenant l'adresse de tous les registres interne de l'IP pour permettre de créer simplement un programme en langage C permettant de contrôler l'IP. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''
* '''HAL''': Ce répertoire va contenir un drivers ou un exemple de logiciel de base permettant l'utilisation de l'IP par un microprocesseur/contrôleur. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''

=== Gestionnaire d'interruption ===

Ce composant esclave est le premier qui sera créé spécifiquement pour le système. Il sera capable de:
* prendre en compte jusqu'à 16 sources d'interruptions différents
* réaliser l'acquittement chaque interruption individuellement
* masquer/autoriser chaque interruption individuellement

Le composant dispose des registres suivants:
* '''isr_mask''': registre d'autorisation des interruptions. Chaque bit correspond à une interruption (bit0 => IRQ0, bit1 => IRQ1, etc.). Ce registre sera accessible en lecture et en écriture.
* '''isr_pend''': ce registre est à double emploi
** '''en lecture''': Les interruptions en attente de traitement
** '''en écriture''': Acquittement des interruptions. Chaque bit à 1 va acquitter l'interruption correspondante.

== Le script / programme d'assemblage des IP ==

Nous allons maintenant parler du coeur du système, du moins de la partie la plus visible de l'iceberg ;-)

=== Principe et fonctionnement ===
Afin de de rendre tout ce système utilisable par le plus grand nombre, il faut être capable de proposer des outils qui vont simplifier la vie de l'utilisateur final ainsi que de l'intégrateur.

Pour cela, il faudra créer un outil soit sous forme de script(s), soit sous forme de programme(s) qui va permettre de réaliser les tâches suivantes:
* Edition d'un '''système wishbone''', c'est-à-dire
** Ajout/suppression de composants '''''Armadeus Ready''''' (c'est comme HD Ready mais en mieux ;-) ).
** Configuration des adresses de base de chaque composant placé sur le bus Wishbone. La plage d'adresses étant donné par la taille du bus d'adresses du composant.
** Affection du bit d'interruption pour chaque composant ayant besoin de générer une interruption.
** Affection des signaux non wishbone d'entrée et de sortie des composants aux broches du FPGA si cela est possible
* Génération d'un fichier '''''mapping''''' contenant:
** Un ''Time Stamp'' pour connaitre la date de création/génération du système
** Le fréquence de base du bus Wishbone
** L'adresse de base de chaque composant
** Le niveau d'interruption affecté à chaque composant
* Génération du macro composant '''syscon''' qui va faire le lien (routage) entre les différents composants sus le bus Wishbone.
* Génération du composant '''system''' qui va regrouper toutes les connexions internes au système que l'on est en train de créer dans un seul fichier HDL (VHDL ou Verilog). C'est ce fichier qui sera alors instancier dans '''''Xilinx ISE''''' avec éventuellement d'autres IP qui n'ont pas de lien directe avec l'i.MX
* Génération d'un fichier script '''tcl''' pour la création du projet de base pour '''''Xilinx ISE'''''. Ceci va éviter les erreurs de connexions sur les broches du FPGA, au moins pour la partie relative à l'i.MX.
* Génération d'un fichier '''Makefile''' pour la création des DLL d'accès au système via programme.

=== Gestionnaire d'interruption ===

Afin de simplifier la vie des programmateurs systèmes, il faut pouvoir offrir un mécanisme simple de mise en place et de gestion des demandes d'interruption du FPGA.

Pour cela, je propose la solution suivante:
* Mise en place d'un gestionnaire d'interruption générique pour le FPGA. Ce gestionnaire d'interruption sera capable de lire le registre d'interruption (lecture de '''isr_pend''') et de déterminer les interruptions à traiter (via '''isr_mask'''). Il va en suite aiguiller l'exécution de la routine d'interruption vers les routines adéquates pour chaque bit d'interruption valide. L'interruption traitée sera alors acquitée (écriture vers '''isr_pend''').
* Création d'une routine '''''d'enregistrement de vecteur d'interruption'''''. Cette routine va permettre d'ajouter une routine de traitement d'interruption pour un bit d'interruption donné. Pour cela il faudra lui fournir les informations suivantes (via une structure ?!?):
** Un numéro du bit d'interruption (0 à 31)
** Une routine de traitement d'interruption pour ce driver
** Un paramètre additionnel à fournir à la routine de traitement d'interruption (pointeur de type '''''void *''''')
** Le nom du drivers (optionnel, permet d'identifier/visualiser les drivers installer éventuellement)
* Création d'une routine de validation d'une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour masquer une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour désinstaller une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine ou méthode pour visualiser tous les drivers Wishbone installés:
** Leur numéro
** Leur nom
** Leur état (validé/masqué)
** Le nombre de fois qu'ils ont été appelé
** etc.