👐🏾 ⭕️ 📐 Générer une horloge en FPGA sur des primitives ◽️ 🌍 💪

En lisant les fiches techniques sur les FPGA, vous pouvez trouver des signes sur leurs fréquences de fonctionnement ... Mais

non, l'histoire commence en 2015, lorsque je me suis familiarisé avec les FPGA. Dans mes premiers travaux simples, j'ai formé l'horloge dont j'avais besoin à partir du compteur et alimenté toute la logique de celui-ci (naturellement, à condition que j'aie besoin de l'horloge plus lente qu'elle n'était alimentée au FPGA, par exemple UART et SPI). Naturellement, ils m'ont poursuivi pour cela, mais j'avais une simple excuse «mais ça marche!», Et tout a vraiment fonctionné. Depuis, la pensée s'est glissée dans ma tête: "D'où puis-je obtenir le signal de synchronisation?"

Il n'y a pas beaucoup d'options pour que les sources prennent un lambeau. Soit prendre à partir d'un certain ClockWizard basé sur PLL ou MMCM, ou le former à partir d'un compteur, ou immédiatement à partir de la jambe, pour ainsi dire, à une seule extrémité. Et si nous prenions le signal d'horloge généré par la primitive FPGA?

Dans le cadre de cet article, j'ai décidé de considérer trois options: un multiplexeur (MUXF7), une table de vérité (LUT1) et court-circuiter les jambes du FPGA à elles-mêmes.

Dans le cas d'un multiplexeur, la sortie est envoyée au signal de commande et les signaux d'entrée sont tirés vers 0 et 1.

Dans le cas de LUT, nous court-circuitons la sortie sur l'entrée et définissons la table de vérité inverseuse. Lors de la fourniture de "1", sortie zéro et lors de la fourniture de "0", sortie un.

Dans le cas du GPIO, tout y est simple, le signal de sortie est affecté à l'inverse du signal d'entrée:

attribuer s2 = ~ s1;

Le but de l'expérience: générer une fréquence de trois manières et la mesurer.

Nous mesurerons la fréquence aux dépens des compteurs. Il y aura 4 compteurs: trois pour chaque option et un compteur de base, par rapport auquel tout sera compté. Et nous regarderons ces compteurs via ChipScope.

Et voici le code complet du module:

module gen_clk(
    input clk_base,
    input s1, //gpio
    output s2 //gpio
    );

//  - 
assign s2 = ~s1;
wire clk_gpio = s1;
reg [31:0] cnt_gpio = 0;
 (* MARK_DEBUG="true" *) reg [31:0] cnt_gpio_buf = 0;
always@(posedge clk_gpio)
begin 
    if(cnt_gpio[2:0]==3'd0) cnt_gpio_buf<=cnt_gpio; 
    cnt_gpio <= cnt_gpio + 1'b1;
end

//  
wire clk_mux;
MUXF7 MUXF7_inst
(
    .O(clk_mux),
    .I0(1'b1),
    .I1(1'b0),
    .S(clk_mux)
);
reg [31:0] cnt_mux = 0;
 (* MARK_DEBUG="true" *) reg [31:0] cnt_mux_buf = 0;
always@(posedge clk_mux)
begin 
    if(cnt_mux[2:0]==3'd0) cnt_mux_buf<=cnt_mux; 
    cnt_mux <= cnt_mux + 1'b1;
end
//   
wire clk_lut;
LUT1#(
    .INIT(2'b01)
)
LUT1_inst(
    .O(clk_lut),
    .I0(clk_lut)
);
reg [31:0] cnt_lut = 0;
 (* MARK_DEBUG="true" *) reg [31:0] cnt_lut_buf = 0;
always@(posedge clk_lut)
begin 
    if(cnt_lut[2:0]==3'd0) cnt_lut_buf<=cnt_lut; 
    cnt_lut <= cnt_lut + 1'b1;
end
//         
 (* MARK_DEBUG="true" *) reg [31:0] cnt_base = 'd0;        
always@(posedge clk_base)
begin
    cnt_base <= cnt_base + 1'b1;
end    
   
endmodule

Voici un schéma du projet. Les primitives sont encerclées et les flèches indiquent le signal qui sera entré dans le ChipScope pour l'analyse de fréquence:

Partie pratique J'ai

trois planches à ma disposition:

Kit d'évaluation KC705
Kit d'évaluation ML507
Carte chinoise Spartan-6 XC6SLX16

Regarder vers l'avant
Pour l'avenir, je dirai que le dernier conseil n'a pas eu un résultat normal.

Et donc maintenant les résultats réels

Kintex-7:

Depuis que le projet a commencé à être fait pour lui, le projet n'a pas été écrit entièrement en une seule fois, mais par étapes. Tout d'abord, j'ai connecté une LUT, ajouté des signaux au débogage et commencé à regarder.

Le compteur de base est cadencé à 200 MHz, il n'est donc pas difficile de calculer la fréquence des horloges générées sur le butin, combien de fois le compteur delta du compteur de butin est le delta du compteur de base en même temps, autant de fois sa fréquence. Dans ce cas: la fréquence générée par le butin est de 381,55 MHz.

Maintenant, nous allons ajouter un multiplexeur au projet, et par analogie avec un butin, nous allons calculer la fréquence pour celui-ci, et pour le butin (après tout, quelque chose doit changer).

La première chose qui attire un coup d'œil est à quel point le comptoir claque. Cela affecte la fréquence énorme du multiplexeur, mais en général, il est clair que le compteur augmente, ce qui signifie qu'il peut également être pris et compté. Finalement:

Fréquence du multiplexeur: 5953,89 MHz
Fréquence de butin (modifiée): 379,98 MHz

Eh bien, à la fin, ajoutons une boucle fermée d'une paire GPIO au projet. La carte KC705 possède des connecteurs SMA J13 et J14. Ici, je les ai fermés avec un conducteur d'environ 10 cm de long.

Fréquence GPIO: 90,59 MHz
Fréquence du multiplexeur: 12994,13 MHz
Fréquence du butin: 380,18 MHz

Remplaçons, par souci d'expérience, le conducteur par un plus long, j'ai un fil deux fois plus long. En conséquence, la fréquence est tombée à 85,29 MHz.

A ce stade de l'expérience, on peut constater que la fréquence de fonctionnement des primitives dans les FPGA n'est pas la même. Dans le cas où il n'y avait qu'un seul butin, le synthétiseur a choisi le butin le plus rapide et a construit un circuit autour de celui-ci, puis lorsque le multiplexeur a été ajouté, le synthétiseur a essayé de trouver cette super position où le butin et le multiplexeur fonctionnent le plus rapidement possible, et ce sont d'autres éléments et fréquences qui sont déjà plus lents. Lorsque des broches externes ont été ajoutées, tout le projet sur un cristal a été fondamentalement déplacé sur ces jambes et le projet a commencé à être synthétisé sur des éléments proches, pour une raison quelconque, à cet endroit, les fréquences du butin et du multiplexeur ont sensiblement augmenté, mais n'oubliez pas que dans le contexte de tout cela, au projet un ChipScope d'une profondeur de 1024 et un bus de données de 64 à 128 est connecté (il change de projet en projet). Passons maintenant au tableau suivant.

Virtex-5:

Je ne suis pas allé jusqu'au bout avec le tableau précédent, j'ai immédiatement ajouté les 3 options pour générer une cape et j'ai regardé dans ChipScope ce qui s'était passé.

La figure montre deux étiquettes X et O. Outre leurs valeurs dans les colonnes, le format des nombres est décimal non signé. Il est à noter que le compteur de base compte désormais à 100 MHz. Et donc le résultat:

Fréquence GPIO: 96,34 MHz
Fréquence du multiplexeur: 614,41 MHz
Fréquence de butin: 5761,1 MHz

On peut voir que sur cette carte, le butin s'est avéré plus rapide que le multiplexeur, et que la fréquence des broches s'est avérée plus élevée que sur la première carte, peut-être parce que j'ai connecté les deux broches non pas avec un conducteur de 10 cm, mais avec un cavalier, en conséquence, la ligne de communication est devenue plus courte et la fréquence était plus élevée.

Et maintenant la dernière option avec une planche chinoise.

Spartan-6:

Il y a deux compteurs de base dans ChipScope, en fait c'est le même compteur qui ne voulait tout simplement pas reconfigurer ChipScope. Dans ce projet, le compteur de base est cadencé à 50 MHz.

Dans le cas de cette planche, tout s'est avéré beaucoup plus compliqué. Premièrement, le projet ne souhaitait en aucune manière être synthétisé sous la forme synthétisée dans les versions précédentes. Deuxièmement, à la fin, j'ai dû jeter la LUT, j'ai essayé de la remplacer par une cinq voies, mais cela n'a pas fonctionné non plus. En général, voici les résultats:

Fréquence GPIO: 51,77 MHz
Fréquence du multiplexeur: 3490504 MHz
Fréquence du butin: échec de la collecte

Les résultats obtenus par cette carte se sont révélés peu satisfaisants, non seulement parce que le butin ne pouvait pas être utilisé comme un morceau, mais aussi à cause de la fréquence incroyablement énorme du multiplexeur. En ce qui concerne le lambeau généré sur les pattes, un conducteur d'environ 25-30 cm a été utilisé, fermé par un fil à l'extrémité, des capacités et inductances parasites s'y sont probablement formées, ce qui a eu leur effet sur la génération du lambeau.

Conclusion

En général, nous avons réussi à générer des signaux d'horloge sur diverses primitives, et nous avons également réussi à voir (en utilisant le Kintex-7 comme exemple) que les primitives ont une latence différente en fonction de leur emplacement. En mon nom personnel, je tiens à ajouter que je ne considère pas l'expérience réalisée comme tout à fait correcte, par exemple, la largeur de bits des compteurs n'a pas été calculée, le transfert de signal de différents domaines d'horloge n'a pas été pris en compte (bien que j'ai fait rester le signal dans le tampon pendant plusieurs horloges), le ChipScope lui-même devrait idéalement être supprimé et un autre moyen devrait être trouvé analyser la fréquence générée.

Les problèmes rencontrés:

Vivado ISE , . :

set_property ALLOW_COMBINATORIAL_LOOPS TRUE [get_nets -of_objects [get_cells gen_clk_inst/LUT1_inst]]
NET «s1» CLOCK_DEDICATED_ROUTE = FALSE;

Générer une horloge en FPGA sur des primitives

Et donc maintenant les résultats réels

More articles: