2017-10-18 12 views
0

J'essaie de réaliser un module de comptage. Ma configuration de base: FPGA (Digtyent's Arty avec Xilinx Artix-35T) avec deux câbles BNC connectés aux ports IO connectés à un générateur de signaux et via USB/UART au PC pour la lecture. Mon générateur de signal produit, disons, 1 Hz de signal TTL. Je veux maintenant compter le nombre d'événements dans le canal 1, dans le canal 2 et les coïncidences des canaux 1 et 2. Alors que le principe de base fonctionne, je vois les canaux 1 et 2 séparés, même s'ils ont la même entrée (via le connecteur BNC-T). En outre, il arrive que l'un des canaux de sortie saute - dans les deux sens, voir la figure. counting Le canal violet ("Canal 1") a une pente différente de celle du vert ("Canal 2"). Aussi les coïncidences font ici deux petits sauts avec perte.Le comptage des différents canaux diverge et saute

Mon code de comptage séquentiel ressemble

reg [15:0] coinciInt [(numCoincidences -1):0]; // internally store events 
always @(posedge clk or posedge reset) // every time the clock rises... 
begin 
    signalDelay <= signal;    // delayed signal for not counting the same event twice 

    if(reset)        // reset 
    begin 
     for(i=0;i<numCoincidences;i=i+1) 
      coinciInt[i] <= 16'b0; 
    end 
    else         // No reset 
    begin 
     for(i=1;i<numCoincidences;i=i+1) // loop through all coincidence possibilities: 
     begin 
      if(((signal & i) == i) && ((signalDelay & i) != i)) // only if signal give coincidence, but did not give before, it's a coincidence 
      begin       // "(signal & i) == i" means that "signal" is checked if bitmask of "i" is contained: 
              // ((0011 & 0010) == 0010) is true, since 0011 & 0010 = 0010 == 0010 
       coinciInt[i] <= coinciInt[i] + 1'b1; // the i-th coincidence triggered, store it 
      end 
     end 
    end 
end // end of always 

assign coinci = coinciInt; // the output variable is called coinci, so assign to this one 

S'il vous plaît noter que tous les événements sont dans le Coinci de registre - coïncidences ainsi que des « événements uniques ». Idéalement, coinci [1] devrait stocker les événements du canal 1, coinci [2] ceux du canal 2 et coinci [3] coïncidences entre 1 et 2, puisque les canaux sont étiquetés par 1,2,4,8, ..., 2^n et les coïncidences par la somme respective. coinci [0] est utilisé pour une certaine somme de contrôle, mais c'est hors sujet maintenant.

Y a-t-il des idées pour les nombres manquants? Pour les différentes pentes?

Merci beaucoup

Modifier 1

Magnuson a souligné @ Brian la question de la stabilité méta. L'utilisation d'entrées multi-buffered a résolu le problème des canaux divergents. Cela fonctionne bien. Bien que je ne comprenne pas entièrement la raison de cela, je n'ai pas non plus vu de sauts dans le canal de coïncidence jusqu'à présent. Vous me sauvez probablement beaucoup de temps, merci!

+0

Heureux que ça a marché pour vous. Désolé pour la réponse courte. https://en.wikipedia.org/wiki/Flip-flop_(electronics)#Timing_considerations a un peu plus d'infos. Fondamentalement, sans le synchroniseur, vous êtes assuré de violer occasionnellement les exigences d'installation/attente des premiers FF que vos entrées en éventail. Lorsque cela se produit, l'état (0/1) auquel le flop est attribué n'est pas déterministe. Le synchroniseur "contient" ce comportement et ne le laisse pas contaminer votre logique de compteur. Une autre phrase google'able serait «passage de domaine d'horloge». Bonne chance! –

Répondre

1

Je suspecterais un problème de méta-stabilité. Vos impulsions entrantes sur ch1/ch2 ne sont probablement pas synchronisées avec l'horloge système que vous utilisez. See here. Pour cette raison, il est probable que vous attrapiez parfois les mises à jour de comptage «mid-stride» pour ainsi dire, ce qui entraînera un comportement inattendu. Pour résoudre ce problème, vous pouvez faire flop deux fois les entrées (appelées synchroniseurs à deux rangs) avant de les introduire dans le reste de votre logique. Habituellement, la synchronisation multi-bits nécessite un traitement un peu plus prudent, mais dans votre cas, chaque bit peut être traité indépendamment.