Changes between Initial Version and Version 1 of Component/FHT


Ignore:
Timestamp:
Mar 2, 2009, 5:30:30 PM (15 years ago)
Author:
ivan.miro-panades@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Component/FHT

    v1 v1  
     1[wiki:Component SocLib Components General Index]
     2
     3= FHT =
     4
     5'''Ce fichier en haute qualité:''' [https://www.soclib.fr/trac/dev/attachment/wiki/Component/FHT/soclib_fht_specifications_v1.0.pdf soclib_fht_specifications_v1.0.pdf]
     6
     7== 1) Fonctionnalités du bloc ==
     8Le module FHT calcule la transformé de Hartley rapide (Fast Hartley Transform) sur une série de données d'entrée complexes (I et Q). Ces données arrivent à la FHT à travers deux FIFOs d'entrée, chacune avec les valeurs complexes (I et Q).
     9
     10== 2) Architecture du bloc ==
     11L'architecture du bloc FHT est composée de deux modules, le cœur et le wrapper. Le cœur effectue tous les traitements FHT. Le wrapper sert à fournir une interface compatible SoClib CABA avec le module MWMR_controller, disponible dans la librairie SoClib.
     12
     13[[Image(aaa.JPG, align=top,nolink)]]
     14
     15=== 2.1) Interface du bloc FHT ===
     16L'interface proposé est compatible avec le module MWMR_controller sans ajouter des modifications ni adaptations.
     17
     18Le module FHT dispose des interfaces suivantes:
     19
     20 * Deux FIFOs d'entrée de données.
     21 * Une FIFO de sortie de données.
     22 * Une FIFO d'entrée de configuration.
     23 * Six registres de configuration (seulement en écriture).
     24 * Cinq registres de status (seulement en lecture).
     25
     26
     27Les deux FIFO de données et celle de configuration sont du même type. Vis-à-vis du MWMR_controller, on peut considérer que le bloc FHT dispose de trois FIFO d'entrée et une de sortie.
     28
     29=== 2.2) Architecture de l'unité FHT ===
     30Ci dessous l'architecture de l'unité FHT, elle est composé par:
     31
     32 * User mux: multiplexeur d'entrée de donnés à partir de deux FIFOs
     33 * FHT Core: cœur du calcul FHT
     34 * FIFO out: FIFO de sortie des donnés calculées
     35
     36[[Image(aaa.JPG, align=top,nolink)]]
     37
     38Le format de donnés d'entrée complexe a ce format : la partie I (réelle) est sur les 16 bits poids forts et la partie Q (imaginaire) sur les 16 bits poids faibles.
     39
     40[[Image(aaa.JPG, align=top,nolink)]]
     41
     42==== 2.2.1) User mux ====
     43Le User Multiplexor construit les symboles d’entrées pour la FHT (8, 16 ou 32 complexes) à partir de 2 flots d’entrée. L’origine de chaque complexe est définie par un jeu de 2 masques de 32 bits. Pour chaque bit (i) du jeux des masques, on détermine si la donnée provient de la FIFO 0, FIFO 1 ou elle est nulle.
     44
     45[[Image(aaa.JPG, align=top,nolink)]]
     46
     47==== 2.2.2) FHT ====
     48Cette Unité peut exécuter des FHTs sur 8, 16 ou 32 points. La FHT travaille sur des formats internes de scalaires de 20 bits alors qu’en entrée et en sortie, la taille est de 16 bits. Une saturation éventuelle est détectée en sortie sur chacun des parties  I et Q.   Pour la FHT en Rx, le résultat doit être divisé par le nombre de points (puissance de 2) au moyen d’un décalage droit programmable. Cet operateur se retrouve dans toutes les unités FHT (même unité pour le Tx et le Rx)
     49
     50
     51
     52==== 2.2.3) Détection de saturation ====
     53Toutes les détections de saturation sont comptées dans un seul compteur de 16 bits, I et Q  des 2 opérations confondues. Ce compteur est mis à 0 au Reset. Une option de configuration permet de reseter aussi le compteur au démarrage d’une nouvelle configuration.
     54
     55Lorsque le compteur passe de 0 à une valeur non nulle (première détection d’une saturation). Le compteur continue ensuite à accumuler les saturations. Si le compteur arrive à la valeur maximum (64K) , il reste bloqué à cette valeur.
     56
     57Le compteur est remis à 0 lorsque le CPU vient dumper le registre.
     58
     59
     60
     61=== 2.3) Anoc_copro_wrapper ===
     62Les interfaces de communication entre les coprocesseurs développés au CEA-Leti ne sont pas directement compatibles avec les interfaces CABA proposés par SoClib. Pour permettre de faire une conversion de protocole en gardant une fonctionnalité équivalente, un wrapper à été développé.
     63
     64L'interface fournie par le module MWMR controller a certaines limitations. Par exemple, le contenu des registres configuration ne peut pas être modifié par le coprocesseur. En outre, si le coprocesseur fait une copie locale de ce registre, il ne peut pas savoir quand le contenu de ces registres été mise à jour.
     65
     66Pour résoudre ce problème, nous avons conçu un wrapper qui détecte le changement du contenu des registres de configuration pour détecter un changement dans ces derniers.
     67
     68Pour écrire dans un registre de configuration et s'assurer que la valeur à été correctement écrite, on doit faire deux écritures avec des valeurs différentes. Une première avec une valeur quelconque et puis une deuxième avec la bonne valeur. De ce fait, le wrapper détecte un changement de la valeur et met à jour la valeur du registre interne.
     69
     70
     71==== 2.3.1) Registres de configuration ====
     72Les registres ici détaillés correspondent aux registres de configuration accessible à travers du bloc MWMR.
     73
     74Le wrapper développé a été conçu pour pouvoir supporter plusieurs coprocesseurs avec plusieurs cœurs de calcul. Par contre, le bloc FHT contient uniquement un cœur de calcul, donc tous les registres pour les cœurs 1 à 3 ne sont pas utilisés.
     75
     76[[Image(aaa.JPG, align=top,nolink)]]
     77
     78==== 2.3.2) Registres de status ====
     79Ces registres sont accessibles uniquement en lecture.
     80
     81
     82[[Image(aaa.JPG, align=top,nolink)]]
     83
     84== 3) Configuration du cœur ==
     85
     86[[Image(aaa.JPG, align=top,nolink)]]
     87
     88format du registre fht_conf
     89
     90[[Image(aaa.JPG, align=top,nolink)]]
     91
     92cfg_fht_sz code la taille effective de la FHT sur 2 bits :
     93
     94[[Image(aaa.JPG, align=top,nolink)]]
     95
     96== 4) Envoi de la configuration du cœur à travers de MWMR ==
     97Les configurations du cœur ne sont pas visibles directement dans le memory map du système. On ne peut pas faire une lecture/écriture à une adresse pour obtenir la valeur à configurer/lire. Pour configurer ces registres, il faut passer par un mécanisme d'indirection mise en place par l'association MWMR + wrapper du FHT. Ce mécanisme permet uniquement de faire des écritures de configuration, on ne peut pas faire de lecture.
     98
     99Pour charger les configurations au cœur FHT on utilise une FIFO (FIFO d'entrée de configuration) et un registre de configuration (Adresse de configuration: registre @5) de MWMR. La procédure est la suivante:
     100
     101 * On écrit dans le registre @5 l'adresse de début à configurer.
     102 * On écrit dans la FIFO les données de configuration de maniére séquentielle.
     103Par exemple, si on veut configurer les adresses 10 à 25, on écrit 10 dans le registre @5 et puis on écrit les 15 valeurs de configuration dans la FIFO.
     104
     105Avant d'envoyer des données au cœur, on doit s'assurer que tous les paramètres de configuration on été reçus. On doit utiliser la fonction 'mwmr_wait_fifo_empty' pour s'en assurer.
     106
     107== 5) Chargement des données dans le cœur ==
     108Le module FHT travaille avec des paquets de données, par exemple pour une FHT de 32 symboles, le paquet de données sont les 32 valeurs nécessaires pour réaliser la FHT.
     109
     110Pour que le module FHT puisse travailler avec un nouveau paquet de données il faut:
     111
     112 1. Ecrire dans le registre SlotID (registre @1) du cœur le numéro de configuration à exécuter.
     113 2. Reseter à 0 le registre Excute (registre @0).
     114 3. Ecrire 1 au registre Execute pour démarrer une nouvelle exécution au module.
     115 4. Charger les données du module à travers les FIFOs.
     116 5. Attendre la fin du chargement avant de charger des nouvelles données. Pour cella, faire du polling sur le registre de EOC (End of Compute, registre status @0) et attendre la valeur 1.
     117 6. On peut lire la valeur de Status du cœur 0 (registre status @1) pour savoir si tout est bien passé. La valeur 0 signifie que tout s'est bien passé.
     118
     119
     120On peut charger un nouveau paquet de données dès que le registre de EOC du paquet précédent vaut 1. Autrement on pourrait écraser l'exécution courante.
     121
     122== 6) Démonstrateur du bloc FHT ==
     123Le démonstrateur du bloc FHT est constitué de :
     124
     125 * Un processeur MIPS
     126 * Trois bancs mémoire
     127   * Mémoire du programme
     128   * Mémoire données
     129   * Mémoire des objets logiciels MWMR (non caché)
     130 * Une mémoire de locks
     131 * Un TTY
     132 * Un MWMR connecté au module FHT
     133
     134[[Image(aaa.JPG, align=top,nolink)]]
     135
     136Tout le code nécessaire pour faire fonctionner le bloc FHT est embarqué dans le MIPS. Nous avons crée une API (api_fht.h) pour permettre une programmation simple de ce bloc. De même, nous avons crée une API (api_mwmr.h et api_mwmr.cpp) pour le MWMR qui intègre toutes les fonctionnalités requises par la API du FHT.
     137
     138
     139
     140=== 6.1) Organisation des répertoires ===
     141Le répertoire racine du démonstrateur est:
     142
     143''soclib/platform/topcells/caba-vgmn-fht-mipsel''
     144
     145Le répertoire du module FHT est:
     146
     147''soclib/module/streaming_component/fht''
     148
     149Ce répertoire contient deux sous-répertoires:
     150 * soft: contient le logiciel embarqué et les apis de fht et mwmr
     151 * appli/trace: contient des informations internes du module fht. Indispensable pour pouvoir utiliser le module.
     152
     153
     154=== 6.2) Objets logiciels pour le FHT ===
     155Les objets logiciels utilisés par le MWMR sont trois:
     156
     157 * FIFO logicielle
     158 * Etat de la FIFO logicielle
     159 * Locks
     160Nous avons séparé les objets FIFO logiciel et son état dans une mémoire (RAM MWMR) pour pouvoir définir cette mémoire comme non cachée. Autrement, il ne serait pas possible d'utiliser le MWMR correctement.
     161
     162
     163
     164Pour pouvoir utiliser le bloc FHT il faut configurer tous les objets logiciels pour le MWMR. Ces objets sont:
     165
     166 * FIFO logicielle
     167 * Etat de la FIFO logicielle
     168 * Lock de la FIFO logicielle
     169On doit configurer tous ces objets pour chacune des FIFOs utilisés: 2 FIFOs d'entrée, une FIFO de sortie et une FIFO de configuration.
     170
     171
     172
     173