Difference between revisions of "FpgaArchitecture"

From ArmadeusWiki
Jump to: navigation, search
m (Le bus Wishbone)
m (Le lien i.MX <=> FPGA)
Line 52: Line 52:
 
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.
 
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''. En effet, la spécification Wishbone prévoit que le transfert sur le bus se termine soit par:
+
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:
* le signal '''ACK''' pour informer de la fin réussi du transfert
+
* Pas possible d'utiliser le signal '''ACK''' Wishbone pour terminer le transfert entre FPGA et i.MAX.
* les signaux '''ERR''' et '''RTY''' pour informer de la fin anormale du transfert.
+
* Pas possible de mettre en place des optimisations du temps de transfert.
  
Dans notre cas, l'interface wishbone pour l'i.MX va terminer automatiquement le transfert dans un temps donné. Ce temps doit être au moins de 2 cycles d'horloge du bus Wishbone. C'est le temps minimal nécessaire pour le transfert sur un bus synchrone tel que le bus Wishbone.
 
  
En cas de non terminaison de la communication dans le temps imparti, une interruption sera générée par l'interface i.MX (ou l'intercon ?!?) pour informe l'i.MX que la dernière lecture ou écriture à échouée. On pourra ainsi gérer l'erreur au niveau du processeur (reset du FPGA, nouvelle tentative de transfert, etc.)
+
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 bus Wishbone ==
 +
 
 +
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).

Revision as of 22:28, 12 December 2006

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 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é.
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 bus Wishbone

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).