Développement d’interfaces de communication numérique avec LabVIEW FPGA

Un besoin commun dans le développement de systèmes de test dans l’automobile, l’aéronautique et une série d’autres industries est de développer ou de mettre en œuvre une interface de communication numérique entre le système de test et d’autres dispositifs. Ces périphériques comprennent d’autres systèmes de test ou ordinateurs, des instruments, des DUT, des composants système de bas niveau tels que des ECU et plus encore.

Idéalement, lors du développement d’un nouveau système de test, vous aurez une interface prête à l’emploi pour votre protocole de communication numérique qui inclut un driver facile à utiliser pour votre outil de développement d’applications. Cependant, dans de nombreux cas, ce n'est pas la réalité. Vous devrez peut-être développer une carte ou une autre interface pour communiquer avec votre périphérique externe. Cela peut se faire en développant votre propre matériel personnalisé allant à l’extrême, comme la conception de votre propre ASIC, ou au moins en soudant une nouvelle carte basée sur des composants prêts à l’emploi. Cependant, avec le matériel d'E/S reconfigurable et le LabVIEW FPGA Module vous pouvez concevoir votre matériel personnalisé en utilisant uniquement LabVIEW et ses outils de programmation graphique. Votre conception matérielle personnalisée est chargée sur le FPGA du matériel d’E/S reconfigurable pour créer votre carte d’interface personnalisée spécifique à vos besoins.

Nous allons décrire comment vous pouvez utiliser le LabVIEW FPGA Module pour implémenter un large éventail de protocoles de communication sur votre propre carte d'interface personnalisée. Ces techniques s’appliquent à la fois aux cartes d’E/S reconfigurables PCI et PXI enfichables (série R) et à la plate-forme CompactRIO fournissant un boîtier robuste prêt pour l’industrie.

Il existe un large éventail de protocoles de communication utilisés dans les systèmes de test, allant des interfaces extrêmement courantes telles que RS-232 et GPIB aux protocoles personnalisés implémentés par des fournisseurs individuels et des développeurs d’applications. Les interfaces courantes, mais moins connues, comprennent SPI (Serial Peripheral Interface) et I²C (Inter-Integrated Circuit) utilisées pour les communications au sein et entre les dispositifs et systèmes électroniques. Bien que courants dans les applications, ces protocoles ne sont pas toujours supportés par les interfaces de communication disponibles dans un large éventail de plates-formes et d'environnements logiciels. Pour de tels besoins LabVIEW FPGA et la plate-forme d'E/S reconfigurables sont un outil idéal pour fournir une solution rentable.

Les protocoles de communication numérique peuvent être regroupés par domaine d'application ou secteur d'activité, ainsi que selon la nature et les spécifications techniques du protocole lui-même. Nous aborderons les détails techniques et la nature des différents protocoles en détail dans les sections suivantes et montrerons comment LabVIEW est utilisé pour les implémenter. En ce qui concerne l'application et l'industrie, voici un ensemble de base de catégories et d'exemples de protocoles qui incluent des interfaces de communication qui ont été résolues avec LabVIEW FPGA

Communication composant/CI

• Conception électronique : SPI, I²C, JTAG, PS/2, ...

Communication avec le système

•   Aérospatiale : MIL-STD-1553, ARINC-429, ...
•   Automobile : CAN, MOST, KWP, 1939, ...

Télécommunications

• Communications par satellite et aérospatiale : PCM/Télémétrie

Électronique grand public

•   Audio numérique : S/PDIF, I²S

Personnalisé

• Implémentations spécifiques au périphérique

Les protocoles de communication numérique peuvent être classés en fonction de leur définition technique et de leurs exigences. Cette façon indépendante de l’application de considérer un protocole aide à se concentrer sur les détails qui sont importants dans la sélection de l’implémentation optimale à l’aide des outils de développement à portée de main. Le reste de ce document se concentrera sur ces critères de classification et sur la manière dont différents groupes de protocoles sont mis en œuvre sur le FPGA.

La plupart des interfaces de communication numérique appartiennent à l'une des deux catégories très générales, série et parallèle, selon le nombre de signaux de données entre un expéditeur et un destinataire. Si les données sont transférées sur une seule ligne de données, il s'agit d'une liaison de données série car tous les bits de données sont transmis séquentiellement ou en série. Une liaison de données parallèle a plusieurs lignes de données et souvent un multiple de huit lignes de données. Les données sont transférées en parallèle, généralement un octet ou un mot à la fois. Traditionnellement, les liaisons de communication série (RS-232) et parallèles (GPIB) ont été utilisées avec des liaisons de communication parallèles offrant des vitesses de transfert de données plus élevées à la même fréquence d'horloge. À mesure que les débits possibles sur une seule ligne de données augmentent dans la gamme Megabit et Gigabit, les liaisons série sont devenues beaucoup plus courantes et dominantes sur le marché, car elles fournissent une solution plus rentable réduisant le coût des composants d’interface (par exemple, les drivers de ligne) ainsi que le coût du câblage. Dans les interfaces de communication série et parallèle, des lignes de signaux supplémentaires peuvent être utilisées pour l'horloge et le déclenchement ainsi que pour la communication de contrôle et de commande.

Une deuxième classification de base de l'interface de communication physique concerne les niveaux de tension et la référence à la masse utilisés pour les lignes de signaux numériques. Les bits de données et autres informations sont transférés par les différents niveaux de tension des lignes de signaux, mais il peut y avoir des différences significatives dans les niveaux de tension utilisés entre différents types d’interfaces. Dans un signal numérique asymétrique, le niveau de tension d'une ligne de signal est mesuré par rapport à une référence de masse commune. Un signal numérique différentiel se compose de deux signaux non référencés et le niveau de tension entre les deux lignes de signaux représente la valeur du signal. Les signaux différentiels sont plus immunisés contre le bruit capté par les lignes de signaux et peuvent normalement être utilisés pour transférer des signaux sur de plus longues distances. Les niveaux de tension spécifiques utilisés dans la communication numérique sont référencés par des normes telles que TTL, CMOS et LVDS et ne sont pas abordés dans l’implémentation du protocole sur le FPGA. Les entrées et sorties numériques du matériel d'E/S reconfigurable utilisent des niveaux de tension compatibles TTL/CMOS. Si d'autres niveaux sont requis, un traducteur/convertisseur de signaux doit être inséré entre le matériel d'interface et la liaison de communication.

Signaux et bit-banging

Alors que nous analysons un protocole et réfléchissons à son implémentation dans LabVIEW FPGA nous devons identifier les différentes lignes de signaux utilisées par le protocole et le but de chaque signal. Le nombre de lignes de signaux utilisées par le protocole déterminera combien de ressources matérielles nous devons configurer dans le projet LabVIEW et combien de lignes numériques nous utiliserons dans le diagramme LabVIEW. Le diagramme de cadencement suivant (figure 1), montrant le protocole SPI (Serial Peripheral Interface), illustre l’utilisation de trois lignes de signaux que nous devons gérer dans l’implémentation de ce protocole.

^{Figure 1 : Diagramme de cadencement simple du protocole SPI avec une ligne de données}

En commençant l'implémentation, nous nous rendons compte que pour convertir le diagramme de cadencement en code LabVIEW FPGA correspondant, nous nous préoccupons de deux choses - activer et désactiver les lignes numériques et attendre la durée appropriée entre la définition de l'état des différentes lignes numériques. Dans les applications où nous lisons un protocole numérique, nous nous préoccupons de lire l’état des lignes numériques et de noter le laps de temps entre les transitions sur chaque ligne de signal. Typiquement, la sortie d’un protocole numérique est plus facile à implémenter et nous allons donc aborder ce cas en premier.

Cadencement

L'un des critères suivants que nous utilisons pour classifier un protocole est la source d'horloge utilisée par le protocole. Les deux catégories principales sont les protocoles synchrones et asynchrones. Les protocoles synchrones incluent un signal de cadencement spécifique dans le protocole, tandis que les protocoles asynchrones sont cadencés en utilisant un débit défini.

Un exemple typique de protocole synchrone est le protocole SPI illustré dans le diagramme de cadencement ci-dessus. Le protocole inclut un signal d'horloge dédié permettant à n'importe quel récepteur d'utiliser la ligne d'horloge comme base de temps pour lire ou écrire la ligne de données. Le protocole asynchrone le plus connu est probablement le bus série (RS-232) utilisé sur de nombreux PC. Lorsque nous utilisons le bus série, nous spécifions le débit en bauds (bits par seconde) du périphérique avec lequel nous communiquons. Le débit en bauds est utilisé par l'émetteur et le destinataire pour mettre à jour ou lire le signal de données au même débit. Comme la source de temps ne sera pas exactement la même aux deux extrémités de la communication, la longueur des paquets de données de communication asynchrone est limitée pour éviter un désalignement des bits. La communication asynchrone doit se resynchroniser fréquemment pour permettre de légères différences de temps. En revanche, les protocoles de communication synchrones peuvent communiquer en continu car ils sont synchronisés sur chaque bit de données.

Lorsque nous implémentons un signal d’horloge dans le cadre d’un protocole synchrone, l’horloge FPGA est utilisée pour déterminer la base de temps du protocole et mettre à jour le signal d’horloge en conséquence.

^{Figure 2 : Diagramme LabVIEW FPGA générant un signal d'horloge} de 10 us (100 kHz)

Pour un protocole asynchrone, un signal d'horloge distinct n'est pas généré, mais l'horloge FPGA et le débit en bauds défini sont utilisés pour déterminer quand mettre à jour ou lire les signaux de données. 

^{Figure 3 : Diagramme LabVIEW FPGA mettant à jour la ligne de données à 4800 bauds
(8333 cycles d'horloge FPGA = 208,3 us = 1/4800 Hz)}

Encodage/Décodage - Modulation de code d'impulsion

En fonction de la fréquence spécifiée par le signal d'horloge ou la spécification de cadencement, les données sont encodées sur le signal de données ou lues à partir du signal de données, puis décodées.  L'encodage des données peut se faire dans différents formats. La méthode la plus courante consiste à représenter la valeur d'un bit de données par un ou plusieurs états du signal de données. Cette classe générale de méthodes d'encodage est appelée modulation de code d'impulsion (PCM).

Le sous-ensemble des méthodes PCM dans lesquelles le bit de données est représenté par un seul état du signal de données est appelé Non-retour à zéro (NRZ). Par exemple, un signal de données haut représente un bit '1', alors qu'un signal de données bas représente un bit '0'. Cette méthode est appelée NRZ-L car le niveau du signal de données représente le bit de données. Dans certains protocoles, comme RS-232, cette logique est inversée où l'état haut représente '0' et l'état bas représente '1'. Ceci est appelé NRZ-I (inverse). Les autres sous-types NRZ sont NRZ-M (marque) et NRZ-S (espace) où la valeur du bit de données '1' est représentée par un changement du signal de données (NRZ-M) ou un '0' est représenté par un changement du signal de données (NRZ-S).

^{Figure 4 : Méthodes d'encodage} NRZ (non-retour à zéro)

La modulation par code d'impulsion comprend un autre ensemble de schémas d'encodage qui combinent le signal d'horloge et le signal de données en une ligne de données ; chaque bit est représenté par plusieurs états du signal de données. Ceux-ci sont appelés encodage biphase et le schéma d'encodage commun de Manchester est un type d'encodage biphase.

D'autres schémas d'encodage plus avancés incluent différentes formes d'encodage de largeur d'impulsion. Le schéma de modulation de largeur d'impulsion (PWM) couramment utilisé convertit directement une valeur analogique en largeur d'impulsion variable d'un train d'impulsions à fréquence constante. D'autres formes d'encodage de largeur d'impulsion utilisent deux largeurs d'impulsion différentes pour représenter un bit '0' et '1' dans une séquence de bits traditionnelle.

Maintenant que nous avons une nomenclature de base pour décrire les protocoles communs, nous pouvons voir comment implémenter des protocoles dans LabVIEW FPGA. Pour implémenter un protocole dans LabVIEW FPGA, nous commençons généralement par parcourir le diagramme de cadencement et convertir les changements d'état des différentes lignes de signaux et le cadencement entre ces changements dans les fonctions et structures LabVIEW correspondantes. Chaque changement d'état d'une ligne numérique est implémenté à l'aide du nœud d'E/S FPGA et le cadencement est implémenté à l'aide des fonctions de cadencement LabVIEW FPGA (Timer de boucle et Attendre). Les étapes du diagramme de cadencement qui sont répétées plusieurs fois sont implémentées en utilisant la boucle For ou While. Pour des protocoles plus étendus, des groupes de fonctions et de structures peuvent être encapsulés dans un sous-VI pour permettre la réutilisation du code et le rendre plus modulaire et gérable.

Sortie SPI

Comme premier exemple, nous implémentons le diagramme de cadencement SPI illustré ci-dessus dans la figure 1 ci-dessus. La communication utilisant le protocole SPI consiste en des paquets de données envoyés entre deux périphériques. Dans la communication SPI, il existe un périphérique maître qui contrôle le signal ChipSelect et le signal d'horloge. Il peut y avoir un ou plusieurs périphériques esclaves avec une ligne de signal ChipSelect dédiée du maître à chaque esclave et une ligne de données commune pour tous les périphériques. Si l'application inclut une communication dans les deux sens entre maître et esclave(s), deux lignes de données sont généralement utilisées ; elles sont étiquetées Maître en sortie esclave en entrée (MOSI) et Maître en entrée esclave en sortie (MISO). Dans notre exemple, nous ne nous concentrerons que sur une seule ligne de données.

^{Figure 5 : Diagramme de câblage pour la communication SPI entre deux périphériques}

Les transferts de paquets sont toujours initiés par le périphérique maître en activant la ligne ChipSelect du périphérique esclave adressé. Généralement, la ligne ChipSelect est active à l'état bas de sorte qu'elle reste dans un état haut lorsque le système est inactif et est tirée à l'état bas par le maître pour démarrer une transmission. Après l'activation du signal ChipSelect, le maître mettra à jour la ligne de données puis fera basculer la ligne d'horloge pour transférer chaque bit de données à l'esclave. Le contenu du paquet de données est spécifique à l'application et laissé à la définition du développeur et du concepteur du périphérique.

Dans le diagramme LabVIEW FPGA correspondant (voir figure 6 ci-dessous), chaque transfert de données est initialisé en définissant la commande booléenne 'Écrire'. Ceci provoque l'exécution de la condition Vrai. Initialement, la ligne ChipSelect (SPI CS*) est activée en abaissant la sortie numérique à un niveau bas. En même temps, la valeur de données 'Data Out' est convertie dans la séquence de bits correspondante (tableau de booléens). La fonction d'attente d'une microseconde (1 us) permet au périphérique esclave d'être prêt pour les bits de données suivants. Ensuite, une séquence de mise à jour de la ligne de données et de basculement de la ligne d'horloge est répétée 16 fois dans la boucle For. Chaque bit du tableau de booléens est renvoyé à la ligne de données (SPI DOUT), puis la ligne d'horloge (SPI SCLK) est définie d'abord haut puis bas. La fonction Timer de boucle permet à la boucle de s'exécuter à des intervalles de 2 us, tandis que la fonction Attendre contrôle la longueur de la phase haute du signal d'horloge à 1 us, générant un signal d'horloge de rapport cyclique de 500 kHz à 50 %. Une fois les 16 bits générés, la fonction Chip Select et les lignes de données retournent à leur état d'inactivité et la fonction Attendre 5 fois le temps d'inactivité minimum est insérée. À ce stade, le FPGA est prêt pour la prochaine commande Écrire.

^{Figure 6 : Diagramme LabVIEW FPGA d ' une implémentation} de sortie SPI simple

En fonction des spécifications des périphériques SPI utilisés et de l'application, n'importe lequel des paramètres de communication (par exemple le nombre de bits de données à transférer, la fréquence du signal d'horloge, etc. peut être ajusté sur le diagramme ou peut être contrôlé dynamiquement à l'aide d'une commande sur la face-avant du VI LabVIEW FPGA.

Si nécessaire, la direction de chacune des lignes numériques utilisées dans l'application peut être définie par programmation en utilisant le nœud de méthode Définir la sortie activer les E/S FPGA (voir figure 7).

^{Figure 7 : Initialisation des lignes numériques} LabVIEW FPGA

Entrée SPI

L’implémentation de la partie entrée d’un protocole peut présenter quelques défis uniques car le code doit être plus flexible dans la détection et le traitement du protocole. Au lieu de mettre à jour les lignes de sortie numérique et d'insérer les délais appropriés, le code surveille l'état de différentes lignes numériques et, si nécessaire, mesure le temps entre des transitions spécifiques sur les lignes de signaux.

L'exemple suivant montre une implémentation d'entrée SPI de base, correspondant à l'exemple de sortie SPI précédent. Dans l'état Inactif, le FPGA surveille la ligne ChipSelect et détecte tout front descendant. En réponse à un front descendant, il commence à surveiller la ligne d'horloge. Pour chacun des 16 fronts montants du signal d'horloge, le FPGA lit le signal de données et stocke la valeur du bit dans un tableau de booléens préalloué. À la fin du paquet de données, après 16 cycles d'horloge, le tableau de booléens est converti en valeur de données entières et mis à disposition sur la face-avant du VI.

^{Figure 8 : Diagramme LabVIEW FPGA d ' une implémentation d} ' entrée SPI simple

En raison de la nature du protocole SPI, cet exemple n'a pas besoin d'effectuer de mesures de temps car tout cadencement est directement contrôlé par les fronts du protocole.

Dans cette section, nous abordons un certain nombre de sujets supplémentaires à prendre en compte lors du développement d'un protocole de communication numérique utilisant LabVIEW FPGA.

Lignes de signaux à collecteur ouvert/à drain ouvert

Dans les exemples SPI précédents, chaque ligne de signal n'est pilotée que par un seul périphérique. Cependant, dans de nombreux protocoles, les lignes de signaux peuvent être pilotées ou contrôlées par plusieurs périphériques selon l'état du bus ou de la communication. Cela permet à plus d'un périphérique d'initialiser la transmission sur le bus ou d'utiliser la même ligne de données pour envoyer et recevoir des données. Généralement, ceci est réalisé en utilisant un circuit collecteur ouvert/drain ouvert. Dans cette configuration, un périphérique peut seulement piloter ou tirer une ligne de signal vers le bas, mais laissera la ligne de signal flotter lorsqu'il veut définir la ligne vers le haut ou ne pas piloter la ligne. En plus de chaque périphérique connecté à une ligne de signal, la ligne de signal a également une résistance de pull-up à une tension définie pour établir la tension haute de la ligne si aucun des périphériques connectés ne conduit le signal bas. En utilisant cette configuration, n'importe quel périphérique peut réduire la ligne sans créer de conflit de tension entre différents périphériques. Ces signaux sont généralement définis comme étant actifs-bas, ce qui signifie que la ligne est dans un état haut lorsque le bus est inactif et qu'un périphérique active le signal en tirant la ligne vers le bas. Les signaux actifs-bas sont souvent indiqués par une barre en travers du nom du signal ou un astérisque après le nom du signal, comme dans le cas du signal ChipSelect* (SPI CS*) utilisé dans les exemples précédents.

Pour implémenter un signal à collecteur ouvert dans LabVIEW FPGA, nous utilisons la capacité de contrôler la direction de la ligne numérique pour basculer entre la conduite d’une ligne à l’état bas et son flottement. Dans LabVIEW FPGA, le nœud de méthode d'E/S est utilisé pour activer ou désactiver une ligne de sortie numérique. Lorsqu'une ligne est désactivée, le FPGA ne pilote pas la ligne numérique et lui permet de flotter haut. Pour abaisser la ligne quand elle est activée, nous définissons Données en sortie à Faux. Données en sortie est un registre logiciel qui conserve sa valeur, que la ligne soit configurée pour piloter ou faire flotter la ligne.

Les figures suivantes montrent un exemple de configuration de collecteur ouvert dans LabVIEW FPGA pour le protocole I²C (Inter-Integrated Circuit). I²C est utilisé dans des applications similaires à SPI pour communiquer avec différents types de circuits intégrés tels que les EEPROM, CAN, CNA, etc. Le bus I²C n'a que deux lignes de signaux, horloge et données, et chacune est une ligne à collecteur ouvert. Pour sélectionner le destinataire approprié pour une communication, l'expéditeur commence par transmettre une adresse de périphérique unique qui spécifie le périphérique récepteur.

Pour initialiser le VI de communication à collecteur ouvert, les deux lignes de signaux (SCL et SDA) sont désactivées pour mettre le bus à l'état inactif. Les Données en sortie pour chaque signal sont définies à Faux. À partir de là, l'état de chaque ligne est contrôlé à l'aide de la méthode Définir l'activation de la sortie pour activer la ligne et la mettre à l'état bas ou pour la désactiver et la laisser flotter à l'état haut.

^{Figure 9 : Configurer deux lignes numériques pour la communication à collecteur ouvert}

Pour initier une transmission sur le bus I²C, l'émetteur transmet une condition de démarrage en basculant la ligne de données (SDA) puis en basculant la ligne d'horloge (SCL).

^{Figure 10 : Implémenter la condition de démarrage I2C sur le bus}

Pour transmettre un bit de données sur le bus I²C (voir figure 11), l'expéditeur met à jour la ligne de données (1 ^ère trame), puis fait basculer la ligne d'horloge vers l'état haut (2 ^ème trame) et vers l'état bas (4 ^ème trame).

Dans le protocole I²C après le transfert de chaque octet de données (8 bits), un cycle d'horloge supplémentaire est inséré dans la communication pour permettre au périphérique récepteur d'accuser réception de l'octet précédent. Pour cela, le récepteur tire la ligne de données vers le bas pendant le 9 ^ème cycle d'horloge. Du côté de l'expéditeur dans notre exemple, cela est implémenté en envoyant un bit de données haut et en vérifiant l'état réel de la ligne de données (3^ème étape) pendant le cycle d'horloge. Même si l'expéditeur laisse la ligne de données flotter à l'état haut, la valeur réelle des données devrait être basse car le récepteur tire la ligne de données à l'état bas pour accuser réception du dernier octet de données.

^{Figure 11 : Transmettre un bit de données sur le bus I2C}

Modèle de référence OSI

Le modèle de référence OSI (Open Systems Interconnection) est une représentation des différentes couches logiques d'un protocole de communication, y compris l'application qui utilise le protocole de communication. Il est utilisé pour mieux définir et comprendre les différents aspects d'un protocole et d'un réseau.

^{Figure 12 :  Modèle de référence OSI}

La couche 1 est la couche physique traitant des détails électriques et mécaniques fournissant la capacité d'envoyer des données sur un support. De simples paquets asynchrones fonctionnent à ce niveau.

La couche 2 fournit une définition de base des données au niveau des bits et des octets ainsi qu’une modulation au-delà de la NRZ et de la synchronisation.

Les deux couches suivantes traitent de l’adressage, de la définition des paquets de données, de la détection des erreurs, etc.

Comme nous pouvons le voir dans nos exemples, le FPGA fonctionne au niveau de la couche physique L1 et s’interface directement avec chacune des lignes d’entrée et de sortie numériques au niveau électrique. Cela signifie que nous, développeurs d’un protocole de communication numérique dans LabVIEW FPGA, sommes responsables de toutes les couches du modèle de référence en ce qui concerne le protocole et l’application. Pour de nombreux protocoles plus simples, cela ne nécessitera qu’un peu plus de programmation que ce que nous avons fait jusqu’à présent, ajouter une interface au-dessus de la couche de protocole pour permettre à l’application d’interagir avec le FPGA et d’utiliser le protocole. Cependant, pour les protocoles plus avancés, nous pouvons avoir besoin de beaucoup plus de programmation pour fournir ces couches de protocole intermédiaires, telles que la détection et la gestion des erreurs au niveau du bus, la construction et l'analyse de paquets, la gestion de différents types de paquets, etc.

Cadencement et résolution

Comme nous l’avons vu, le cadencement joue un rôle très important dans l’élaboration d’une implémentation de protocole. Les données et les lignes d'horloge doivent être mises à jour à intervalles précis. Lors du décodage d'un protocole, il est important de mesurer avec précision ces mêmes intervalles. Il est important de garder à l'esprit le comportement temporel du FPGA lorsque nous élaborons des protocoles de communication pour nous assurer que notre implémentation répondra aux exigences et aux spécifications du protocole.

Le FPGA fonctionne sur une fréquence d'horloge de base et toutes les fonctions de cadencement sont basées sur la même fréquence d'horloge. Pour LabVIEW FPGA, la fréquence d'horloge FPGA par défaut est de 40 MHz, de sorte que chaque cycle d'horloge et unité de temps est de 25 nanosecondes (ns). Dans LabVIEW FPGA, nous pouvons spécifier des intervalles de temps pour les fonctions de cadencement en millisecondes, microsecondes et tops. Chaque top correspond à un cycle d'horloge ou 25 ns. Cela signifie que la plus haute résolution dont nous disposons pour spécifier un délai ou un temps d’itération de boucle est de 25 ns. Bien que cela semble très précis, lorsque nous prenons l’inverse et déterminons les fréquences possibles que nous pouvons générer, nous voyons l’effet que cela a à des vitesses plus élevées.

Pour générer une fréquence de mise à jour de 1 MHz pour une ligne numérique, nous pouvons utiliser une fonction Timer de boucle définie pour 40 tops.

1 MHz => 1 μs = 1000 ns
1000 ns / 25 ns par top = 40 tops

Et si nous voulons une fréquence de mise à jour de 1,25 MHz ?

1,25 MHz =>0,8 us = 800 ns
800 ns / 25 ns par top = 32 tops

Pour 1,25 MHz, nous utilisons un délai de 32 tops. Et si nous voulons une fréquence de mise à jour de 1,1 MHz ?

1.1 MHz => 0,9091 us = 909,1 ns
909,1 ns / 25 ns par top = 36,36 tops

Comme nous ne pouvons pas choisir de cycles d’horloge partiels spécifiques, nous devrions choisir 36 cycles d’horloge, ce qui représente un retard de 900 ns et correspond à une fréquence de 1,111 MHz. La fréquence inférieure suivante que nous pourrions utiliser est 37 tops ou 1,081 MHz. Nous voyons donc qu’en utilisant l’horloge FPGA 40 MHz, nous pouvons mettre à jour les lignes numériques à 1,081 MHz ou 1,11 MHz, mais pas entre les deux.

En utilisant les propriétés FPGA et les ressources d'horloge dans le projet LabVIEW nous avons la possibilité de changer la fréquence d'horloge de base FPGA à 80 ou 120 MHz. Cela fera fonctionner le FPGA à une fréquence plus élevée et améliorera la résolution de cadencement des fonctions de cadencement. Cependant, la fréquence d'horloge plus élevée réduira également la complexité qui peut être utilisée dans le diagramme du VI FPGA et compilée avec succès pour le FPGA.

Lors de la planification de l'implémentation d'un protocole cadencé, vous devez déterminer si la résolution de cadencement du FPGA est adéquate pour les besoins du protocole et de l'application. Ceci est particulièrement important pour le cadencement nécessaire pour générer un protocole comme les calculs précédents l'ont montré. Pour lire et décoder des protocoles, il est souvent suffisant de pouvoir lire les lignes de signaux à une fréquence plus élevée que la fréquence de mise à jour la plus élevée du protocole. Nous devrions pouvoir échantillonner les signaux au moins deux fois plus vite que la fréquence de mise à jour pour être sûrs.

Si nous devons effectuer des mesures de temps sur un signal en entrée pour décoder les données contenues dans le protocole, nous devons faire des calculs supplémentaires pour déterminer la résolution de cadencement requise pour décoder avec précision le protocole.

machines à états

Les machines à états peuvent être une technique utile pour implémenter l'encodage ou le décodage d'un protocole de communication numérique. Dans LabVIEW, les machines à états peuvent être facilement implémentées en utilisant la boucle While et une structure Condition pour représenter chacun des différents états. 

La machine à états aide au développement de protocoles de communication car elle décompose naturellement le diagramme de cadencement en étapes distinctes et nous pouvons convertir chacune en un état distinct dans le diagramme LabVIEW FPGA. Cela isole chaque étape du programme et réduit la complexité de la programmation dans une partie de l’implémentation. De plus, il simplifie les opérations génériques telles que la gestion des erreurs et des exceptions en nous permettant de passer de n’importe où dans l’exécution du protocole à des états de gestion d’erreur spéciaux. Parfois, les spécifications du protocole sont écrites en termes de machine à états, que vous pouvez ensuite traduire directement en diagramme d'états LabVIEW.

Pour le diagramme de cadencement SPI de la figure 1, les étapes suivantes sont un moyen possible de le décomposer en machine à états.

• Définir puceSélectionner bas
• Définir des données (0)
• Définir l'horloge à haut
• Définir l'horloge à bas
• Définir des données (1)
• Définir l'horloge à haut
• Définir l'horloge à bas
• (répéter Données et Horloge pour les bits 2-15)
• Définir SélectionPuce haut

Nous remarquons qu’il existe cinq étapes uniques, bien que certaines d’entre elles soient répétées pour chaque bit de données. Initialement, nous implémentions ces étapes répétitives dans une boucle For. Dans la machine à états, nous créons un état unique pour chacune de ces cinq étapes, puis nous les parcourons. Pour les trois étapes répétées qui mettent à jour la ligne de données et font basculer la ligne d’horloge, nous configurons la machine à états pour répéter cette séquence 16 fois avant de passer à la dernière étape. Dans la machine à états LabVIEW ceci est implémenté en utilisant un compteur dans un registre à décalage de la boucle While.

Utilisation de la boucle cadencée à un cycle

Un autre avantage de l'architecture machine à états est qu'elle nous permet d'implémenter une implémentation de protocole à l'intérieur d'une boucle cadencée à un cycle (SCTL) LabVIEW FPGA. SCTL fournit une exécution plus rapide du diagramme LV FPGA, permettant à chaque cycle de la boucle de s'exécuter en un cycle d'horloge. Cela nous permet de mettre à jour une ligne de signal à la fréquence de l’horloge de base FPGA. La SCTL optimise également la génération de code pour que le code sur le FPGA soit plus efficace et utilise moins de biens immobiliers FPGA. Cependant, il existe plusieurs restrictions au code implémenté dans une SCTL. Par exemple, nous ne pouvons accéder à chacune des lignes de signaux qu'une fois par itération SCTL. Par conséquent, nous devons définir les états de notre machine à états de sorte que nous ne lisons ou mettons à jour chaque ligne de signal qu’une fois par état.

Les diagrammes suivants (figure 13) montrent l'implémentation du protocole de sortie SPI en utilisant une machine à états à l'intérieur d'une SCTL. L'état Inactif attend que la commande Écrire démarre la sortie du paquet de données suivant. Il convertit aussi la valeur des données en tableau de booléens pour l'opération de sortie. L'étape suivante Définir CS active la ligne SélectionPuce. Ensuite, nous commençons à renvoyer les bits de données. Dans Réinitialiser l'horloge, nous mettons à jour la ligne de données avec la valeur du bit suivant et réinitialisons le signal d'horloge. Dans Set Clock, nous définissons le signal d’horloge qui déclenche le récepteur pour lire le signal de données. Dans cette paire d'états, nous incrémentons un compteur dans un registre à décalage, qui sélectionne la valeur de données appropriée dans le tableau de booléens à envoyer à la ligne de données. Après avoir renvoyé le 16ème bit, nous passons à l’état Reset CS qui réinitialise toutes les lignes de signaux à l’état inactif du bus. De là, nous retournons à l'état Inactif et attendons la commande Écrire suivante.

^{Figure 13 : Implémentation de la sortie SPI dans une boucle} cadencée à un cycle

L'encodage ou modulation biphase est un type d'encodage de données très courant utilisé dans de nombreux protocoles différents. Il combine le signal de données et le signal d’horloge en une seule ligne de signal, réduisant les besoins de câblage et améliorant considérablement l’intégrité des données sur de plus longues distances de câblage.