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. 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!
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! –