NI PXI-7811R TIming entrées sorties

[NITHREE]

Bonjour,

Je développe un outils d'émulation de composant SPI slave avec une carte PXI-7811r.

La vitesse du bus SPI est de 20Mhz (et 40Mhz par la suite).

Je doit donc positionner ma donnée le plus rapidement possible. 

Mon problème:

 Au scope, je m'aperçoit que, entre le front montant de ma clock spi et le front de ma donnée j'ai 50ns de "latence". Peux importe la vitesse de mon FPGA je ne peux pas réduire ce temps.

Y-a-t-il quelque chose au niveau hardware qui m'empêcherai d'aller plus vite ?

Cordialement,

NITHREE

[Mathieu_R.]

Bonjour,

Quelques éléments de réponse.

Par défaut, les cartes FPGA NI son cadencées à 40MHz, soit 25ns minimum entre deux changement d'état d'une sortie numérique - ou deux consultation de l'état d'une entrée numérique. Si je cherche à générer un signal d'horloge en faisant bagotter une ligne numérique à chaque tick d'horloge du FPGA, j'aurais une fréquence de sortie de 20MHz (25ns à l'état haut, 25ns à l'état bas, période de 50ns soit... 20MHz). Et je ne parle là que de génération, pour laquelle l'horloge FPGA est de notre côté : si je vous comprends bien, dans votre cas la clock SPI est une entrée pour le FPGA... Donc premièrement, quelle est la Top Level Clock ? (Selecting a Top-Level Clock for an FPGA Target)

Ensuite, en fonction de comment est traité le changement d'état côté FPGA en vue de faire changer l'état de la sortie data, on peut retrouver les 50ns en question. Cela va dépendre de l'implémentation (SCTL ou non, pipelining éventuel des traitements, que sais-je). Est-ce que vous utilisez une librairie de référence pour le SPI ? (SPI and I2C Driver API par exemple)

Enfin, il peut y avoir (je ne sais plus dans quelle mesure) du code rajouté par LabVIEW concernant l'arbitration, i.e. la gestion d'un accès concurrent vers une ressource matérielle : Cf. Understanding Arbitration Options (FPGA Module). Pour faire court, et si vous n'avez "qu'un point du diagramme" qui accède à votre entrée/sortie, testez avec l'option Never Arbitrate, pour voir si cela arrange les choses.

Cordialement,

[NITHREE]

Bonjour,

Merci de votre retour. Effectivement, dans la documentation de la carte, il est indiqué un "Minimum Pulse Width" qui est de 25ns (40MHz) en entrée et 12.5ns en sortie (80MHz). La carte FPGA NI est cadencé à 40MHz mais il est possible de créer des horloges jusqu'à 210MHz.

Mon entrée est une horloge de 20MHz, le temps de traitement est de ~10ns et il y a 12.5ns de stabilité en sortie. Nous sommes donc à ~42.5ns. Une horloge de 20MHz donne une période de 50ns. Dans mon cas, le master lit sur un front descendant, je n'ai donc que 25ns pour positionner ma donnée (dans le fichier zip, je n'ai qu'une horloge de 10MHz au maximum, limitation hardware). Avec anticipation ( positionnement du premier bit sur front montant du CS de la demande précédente), nous arrivons à suivre la cadence mais cela demande de savoir en avance la donnée n+1. Dans le futur il faut que je puisse répondre à un SPI de 40MHz. Pour du 10MHZ j'arrive à répondre, mais pour du 20MHz et du 40MHz, cela est impossible.

Après échange avec des personnes de chez NI (SAV de notre contrat d'entreprise), nous avons confirmé mon explication ci-dessus. Nous sommes donc partis sur un nouveau hardware composé d'une carte PXIe-7871R, un front end NI 6583 ainsi que des cordons pigtail.

J'espère que cette réponse aidera certain d'entre vous.

Voici un zip avec mon montage et la description de mon fichier zip en PJ:

Liste du matériel utilisé et des versions logiciels :

• Partie Slave
  • Châssis PXI 1042Q
  • PC intégré PXI-8840
  • Carte FPGA NI-7811R
  • Cordon SH68
  • Boite éclateur SCB-68
  • Windows 7
  • LabVIEW 2014
• Partie Master
  • NI USB-8452
  • PC Dell SDS-1HM9
  • Windows 10
  • LabVIEW 2018

Structure du fichier zip :

• Il est composé de 4 essais :
  • VI_SPI_REPLY_TEST : Conception d’un VI qui joue le rôle de SPI Slave simplement
    • FALLING_EDGE : essai par type de détection du front de l’horloge.
      • VI.png : copie d’écran du code LabVIEW
      • VI_face_avant.png : interface utilisateur du code LabVIEW
      • xMHz : essai à différentes vitesses de bus SPI
        • Config_Master_1MHz.png : copie d’écran du paramétrage du master sur le bus SPI
        • Trace_Scope_Global.png : copie d’écran de l’oscilloscope de la trame global
        • Trace_Scope_Zoom_Front.png : copie d’écran de l’oscilloscope du zoom sur le temps entre la détection du front et la positionnement de la donnée.
      • RISING_EDGE : Même structure que pour FALLING_EDGE
        • xMHz
      • VI_SPI_REPLY_TEST_ANTICIPATION : Même essai que pour VI_SPI_REPLY_TEST , sauf qu’ici, nous anticipons le premier bit
        • FALLING_EDGE 
          • xMHz
        • RISING_EDGE
          • xMHz
        • VI_SPI_VHDL : Conception d’un VI appelant un code VHDL
          • spi_slave_test.vhd : code VHDL utilisé
          • Trace_Scope_Global.png : copie d’écran de l’oscilloscope de la trame global
          • Trace_Scope_Zoom_Front.png : copie d’écran de l’oscilloscope du zoom sur le temps entre la détection du front et la positionnement de la donnée.
          • VI.png : copie d’écran du code LabVIEW
        • VI_TEST_REACTION : test du temps de réaction avec un VI simple
          • Lecture_x00MHz.png : copie d’écran de l’oscilloscope
          • VI_x00MHz.png : copie d’écran du code LabVIEW
        • Montage.jpg : Photo du banc d’essai

Cordialement,

NITHREE