Le design FPGA se fait sur une carte reliée à un PC grâce à une interface PCIe GEN3. Ce protocole série offre un débit de 8Gb/s par ligne, sachant que les cartes peuvent implé-menter jusqu’à 16 lignes séries en parallèle. La solution finale qui sera offerte aux clients permettra de réaliser leurs systèmes en disposant déjà de toute l’infrastructure de commu-nication.

Le projet est décomposé en différentes étapes:

Développement du switch central

Le switch offre 4 à 8 ports sur lesquels viennent se placer des agents. Il permet un débit pouvant atteindre jusqu’à 4GB/s par port, via une interface à 128 bits, et grâce à une horloge interne de 250MHz. Sa structure interne contient de la logique de contrôle et une grande quantité d’éléments mémoire de type FIFOs permettant de faire transiter les paquets de données de manière optimale entre les agents. Son architecture doit évidemment être la plus optimale possible en termes d’occupation de ressources, afin de laisser un maximum de place à l’application utilisateur. Il y a donc une balance à trouver entre les ressources nécessaires et les performances délivrées par le switch. L’utilisateur pourra exploiter un optimiseur développé dans le cadre de ce projet pour trouver le meilleur com-promis pour son application.

Schéma de principe du Switch DNoC

Réalisation d'un agent PCI GEN3 et d'un agent mémoire

Le switch central offre des ports sur lesquels viennent se connecter des agents, qui peuvent être multiples: contrôleur mémoire, bridge vers un autre bus (VME par exemple), lo-gique utilisateur, bridge PCIe, … Dans le cadre du projet, un agent PCIe GEN3 sera développé pour connecter le système sur un PC standard. Cet agent est critique et nécessaire car le système sera connecté sur PCIe pour chacune de ses applications. La norme PCIe GEN3 correspond à un débit de 8Gb/s par ligne avec la possibilité d’avoir plusieurs lignes en parallèle. Elle offre également des mécanismes qui n’étaient pas présents dans la ver-sion précédente de la norme (GEN2). Un des points intéressant concerne les opérations atomiques. En effet, il est maintenant possible d’exploiter des opérations, non plus de lecture ou écriture simples, mais de type « fetch and add », « unconditional swap », et « swap and compare ». Ceci nécessite de développer une fonctionnalité spécifique qui va influencer la réalisation des agents. L’agent mémoire doit notamment supporter les opérations atomiques, ce qui sera mis en place durant le projet.

Monitoring de l'état interne du Switch

Le switch sera exploité par des applications nécessitant une qualité de service irréprochable. Dès lors des statistiques sur l’état du switch doivent pouvoir être extraites. Un nouveau mécanisme permettant d’observer le remplissage des FIFOs internes et de calculer le débit/latence du switch est développé dans le cadre du projet. Il doit permettre à une application logicielle d’être avertie des problèmes pouvant survenir (FIFO plein, par exemple) et de pouvoir extraire des statistiques pertinentes sur le fonctionnement du système. Le type de statistiques et la manière de les extraire sans mettre à mal la qualité de service offerte par le système fait partie de la phase d’exploration du projet.

Optimisation des ressources internes du Switch

Le switch est composé d’un grand nombre de FIFOs permettant un transfert des paquets d’un agent à un autre. Plus les FIFOs sont grands moins le risque de remplissage et donc de perte de QoS existe. Toutefois il n’est pas tolérable de consommer trop de ressources matérielles car celles-ci sont nécessaires pour l’application spécifique qui sera développée par chaque client. Un compromis doit donc être trouvé, avec dans le cas idéal une taille de FIFO la plus petite possible offrant une qualité de service optimale.

Un optimiseur de taille des FIFOs est donc nécessaire pour trouver la solution optimale, en fonction des contraintes et des besoins de chaque application. Etant donné que le switch central est développé dans le cadre de ce projet, un banc de test est réalisé afin d’en vali-der le bon fonctionnement. Celui-ci exploite le langage SystemVerilog et une partie de la méthodologie UVM. Afin de ne pas obliger les utilisateurs à disposer d’un simulateur sup-portant l’entier du langage SystemVerilog, le banc de test n’utilise pas de randomisation contrainte ni de fonctions de couverture. Il offre toutefois une très bonne flexibilité de par la méthodologie UVM et la réalisation de nouveaux scénarios de tests est aisée.

Il serait possible d’exploiter ce banc de test pour lancer des simulations avec des architectures internes (tailles des FIFOs) différentes. Ceci pourrait être une base pour l’optimiseur, toutefois le temps de simulation est relativement long et peu appréciable. Dès lors un simulateur purement logiciel, émulant le fonctionnement du switch, est développé. Il permet d’implémenter des agents ayant des comportements différents, et de définir des politiques de fonctionnement.

L’optimiseur exploite ensuite le simulateur logiciel pour déterminer la taille optimale pour chaque FIFO du switch. Cette optimisation est effectuée en exploitant les comportements attendus des différents agents de l’application spécifique qui peuvent être définis facilement à partir du framework développé. Un algorithme génétique a été développé car l'espace de recherche est important, de part le grand nombre de FIFOs présents et de par la balance à donner aux FIFOs placés en Block RAM ou LUT. Le client pourra dès lors se retrouver avec le switch le plus petit possible garantissant la qualité de service nécessaire.

Visualisation de l'états des FIFOs internes

Lors d’une simulation des fichiers de logs sont générés et une interface graphique permet d’afficher et d’observer l’état de remplissage des FIFOs. Ceci permettra de facilement mettre à jour des problèmes potentiels. Cette interface graphique pourra ensuite être exploitée pour visualiser le comportement du switch après intégration, notamment pour confronter les résultats des simulations avec le fonctionnement sur cible.