Présentation
Une fois j'avais besoin d'implémenter un petit bloc de CAM (mémoire associative). Après avoir lu comment Xilinx fait cela sur BRAM (blocs de mémoire statiques) ou sur SRL16 (registres à décalage 16 bits), j'ai été un peu attristé, car leurs implémentations prenaient beaucoup de place. J'ai décidé d'essayer de le faire moi-même. La première option était la mise en œuvre sur le front. Pour l'avenir, cela m'est presque venu tout de suite et, eh bien, la fréquence cible pour la conception n'était que de 125 MHz.
L'architecture
Pour commencer, considérez l'énoncé du problème. Nous avons donc besoin d'un petit CAM avec une largeur de mot de 8 à 64 bits et une profondeur de 16 à 1024 mots. J'avais besoin d'une recherche binaire dans CAM, mais plus tard, il s'est avéré que la fabrication de TCAM (mémoire associative ternaire) est assez bon marché en termes de ressources et affecte légèrement le timing. La limite de fréquence inférieure est de 125 MHz sur la famille Kintex7 . Commençons! Notre CAM sera composé de ces lignes, chacune correspondant à une adresse et stockant un mot:
Figure 1. La structure d'une ligne de CAM
Sur la figure 1, D est un déclencheur D régulier pour stocker des données; le nombre de ces déclencheurs sur la ligne correspond à la largeur du mot de données d'entrée dans CAM. VALID - D-trigger, qui stocke «1» si les données de la ligne sont pertinentes. CMP est un comparateur qui compare la valeur du bit de bus de clé de recherche correspondant si VALID = '1'. écriture de données - écriture de bus de données , connectée au niveau du bit au D correspondant (largeur de mot N - CAM), drapeau we - write, effacement - réinitialisation VALID (invalidation de la ligne de données). ET - ET logique à partir de N sorties des comparateurs, indicateur de correspondance se transformant en «1» si la recherche dans cette ligne réussit.
Donc, nous avons une ligne dans laquelle nous pouvons rechercher. Maintenant, combinez-les:
Figure 2. Structure CAM
Sur la figure 2, CAM_line est la ligne CAM elle-même de la figure 1, MUX est le multiplexeur d'adresse d'entrée, MATCH REGISTER est un registre qui stocke les valeurs d'indicateur de correspondance , ENCODER est un décodeur qui convertit le bus de correspondance en l'adresse de correspondance la plus basse trouvée. FSM est une machine à états finis de contrôle, qui est prev. match supprime de MATCH REGISTER le bit correspondant à l'adresse envoyée afin que ENCODER passe à la prochaine adresse trouvée. L'interface de notre CAM sera la suivante:
Tableau 1. Interface CAM
Ci-dessous, sur la figure 3, un chronogramme du fonctionnement de cette interface, qui montre d'abord l'enregistrement de trois mots dans CAM, puis une recherche, un effacement et une recherche réussis:
Figure 3. Diagramme temporel de l'interface avec le module CAM
Donc, nous avons une description de la FAO, passons à la synthèse.
La synthèse
Nous synthétiserons dans Xilinx ISE pour comparer les résultats avec ceux obtenus dans XAPP1151 .
Figure 4. Dépendance de la fréquence après XST (synthétiseur intégré à ISE) à la profondeur CAM pour la largeur du bus de données 8 bits
Figure 5. Fréquence après XST par rapport à la profondeur CAM pour la largeur du bus de données 32 bits
Figure 6. Fréquence après XST par rapport à la profondeur CAM pour une largeur de bus de données 64 bits
Sur la figure 6, il n'y a pas de données pour Virtex5 , car la CAM de cette taille ne correspondait pas au BRAM existant. On note également que pour une largeur de 64 bits et une profondeur de 1024, notre résultat était légèrement pire que celui de l'implémentation sur SRL16. Passons maintenant à la synthèse Vivado pour le XC7K325T . Les résultats sont les suivants:
Figure 7. Dépendance en fréquence après PnR (placement des blocs sur la puce et traçage du signal) sur la profondeur CAM pour une largeur de bus de données 32 bits
Figure 8. Utilisation des ressources pour différentes profondeurs CAM pour une largeur de données de 32 bits en%
Il est important de noter que les résultats sur Vivado ont été obtenus après PnR, ce qui signifie que la conception n'a aucun problème avec le traçage.
TCAM
Comme mentionné ci-dessus, obtenir avec cette approche de CAM TCAM n'était pas un problème particulier. Il suffit d'ajouter un bus de masquage pour les bits de données et de le répartir bit à bit dans les comparateurs, afin que lors de la comparaison des données avec la clé, ils prennent en compte sa valeur. Un tel changement n'a pas entraîné de baisse de fréquence ni d'augmentation sérieuse des ressources consommées, nous avons donc obtenu gratuitement TCAM.
Conclusions
Nous avons donc pu terminer la tâche. La conception qui en résulte permet à la 7e famille FPGA Xilinx de recevoir une CAM suffisamment grande avec une fréquence supérieure à la cible 125 MHz. Le résultat de la comparaison avec XAPP1151 s'est avéré être inattendu pour moi, j'ai supposé que l'implémentation sur BRAM, bien qu'elle soit très coûteuse en termes de ressources, dépassera l'implémentation frontale en fréquence. Cependant, ne célébrez pas la victoire si tôt, ce document décrit le noyau IP Xilinx CAM, qui permet, par exemple, d'obtenir une CAM avec une profondeur de 32K cellules et une fréquence de 155 MHz, basée sur BRAM. Ce résultat peut probablement être atteint dans la version proposée dans l'article, soit en ajoutant les étapes du pipeline, soit en collectant de gros CAM à partir de petits, mais je ne peux pas immédiatement prédire s'il s'intégrera dans la puce. À l'avenir, j'essaierai de mettre en œuvre quelque chose de similaire sur BRAM, mais pour l'instant, merci de votre attention.