nein, die Geschichte beginnt im Jahr 2015, als ich FPGAs kennenlernte. In meinen ersten einfachen Arbeiten formte ich die Uhr, die ich brauchte, vom ZĂ€hler und speiste die gesamte Logik daraus (vorausgesetzt, ich brauchte die Uhr langsamer als sie dem FPGA zugefĂŒhrt wurde, zum Beispiel UART und SPI). NatĂŒrlich haben sie mich dafĂŒr gejagt, aber ich hatte eine einfache Ausrede "aber es funktioniert!", Und alles hat wirklich funktioniert. Seitdem schlich sich der Gedanke in meinen Kopf: "Woher bekomme ich das Zeitsignal?"
Es gibt nicht viele Möglichkeiten fĂŒr Quellen, einen Fetzen zu nehmen. Entweder von einem bestimmten ClockWizard, der auf PLL oder MMCM basiert, oder von einem ZĂ€hler oder sozusagen direkt vom Bein, Single-Ended. Was ist, wenn wir das vom FPGA-Grundelement erzeugte Taktsignal nehmen?
Als Teil dieses Artikels habe ich beschlossen, drei Optionen in Betracht zu ziehen: einen Multiplexer (MUXF7), eine Wahrheitstabelle (LUT1) und einen Kurzschluss der FPGA-Beine fĂŒr sich.
Bei einem Multiplexer wird der Ausgang dem Steuersignal zugefĂŒhrt und die Eingangssignale auf 0 und 1 gezogen.
Im Fall von LUT schlieĂen wir den Ausgang mit dem Eingang kurz und setzen die invertierende Wahrheitstabelle. Wenn Sie "1" angeben, geben Sie Null an und geben Sie bei "0" Eins aus.
Bei GPIO ist dort alles einfach, dem Ausgangssignal wird die Umkehrung des Eingangssignals zugewiesen:
| zuweisen s2 = ~ s1; |
Der Zweck des Experiments: eine Frequenz auf drei Arten zu erzeugen und zu messen.
Wir werden die Frequenz auf Kosten der ZĂ€hler messen. Es gibt 4 ZĂ€hler: drei fĂŒr jede Option und einen BasiszĂ€hler, relativ zu dem alles gezĂ€hlt wird. Und wir werden diese ZĂ€hler ĂŒber ChipScope beobachten.
Und hier ist der gesamte Modulcode:
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
Hier ist eine schematische Darstellung des Projekts. Die Grundelemente sind eingekreist, und die Pfeile geben das Signal an, das zur Frequenzanalyse in das ChipScope eingegeben wird:
Praktischer Teil Ich
habe drei Boards zur VerfĂŒgung:
- KC705 Evaluierungskit
- ML507 Evaluierungskit
- Chinesisches Spartan-6 XC6SLX16 Board
Vorausschauen, , .
Und so nun die tatsÀchlichen Ergebnisse
Kintex-7:
Seit Beginn des Projekts wurde das Projekt nicht vollstĂ€ndig auf einmal geschrieben, sondern schrittweise. Zuerst habe ich eine LUT angeschlossen, dem Debugging Signale hinzugefĂŒgt und angefangen zu schauen.
Der BasiszÀhler wird mit 200 MHz getaktet, so dass es nicht schwierig ist, die Frequenz der auf der Beute erzeugten Takte zu berechnen, wie oft der Delta-ZÀhler des BeutezÀhlers gleichzeitig das Delta des BasiszÀhlers ist, so oft seine Frequenz. In diesem Fall: Die von der Beute erzeugte Frequenz betrÀgt 381,55 MHz.
Jetzt werden wir dem Projekt einen Multiplexer hinzufĂŒgen und in Analogie zu einer Beute die HĂ€ufigkeit dafĂŒr und fĂŒr die Beute berechnen (schlieĂlich muss sich etwas Ă€ndern).
Das erste, was einen Blick auf sich zieht, ist, wie stark der ZĂ€hler klappert. Dies wird durch die groĂe Frequenz des Multiplexers beeinflusst, aber im Allgemeinen ist klar, dass der ZĂ€hler zunimmt, was bedeutet, dass er auch genommen und gezĂ€hlt werden kann. Zusammenfassend:
- Multiplexerfrequenz: 5953,89 MHz
- Beutefrequenz (geÀndert): 379,98 MHz
Nun, am Ende fĂŒgen wir dem Projekt eine geschlossene Schleife von einem GPIO-Paar hinzu. Die KC705-Karte verfĂŒgt ĂŒber die SMA-AnschlĂŒsse J13 und J14. Hier habe ich sie mit einem ca. 10 cm langen Leiter verschlossen. Als Ergebnis:
- GPIO-Frequenz: 90,59 MHz
- Multiplexerfrequenz: 12994,13 MHz
- Beutefrequenz: 380,18 MHz
Ersetzen wir aus VersuchsgrĂŒnden den Leiter durch einen lĂ€ngeren, ich habe einen doppelt so langen Draht. Infolgedessen fiel die Frequenz auf 85,29 MHz.
In dieser Phase des Experiments kann festgestellt werden, dass die Betriebsfrequenz von Grundelementen in FPGAs nicht gleich ist. In dem Fall, in dem es nur eine Beute gab, wĂ€hlte der Synthesizer die schnellste Beute und baute eine Schaltung um sie herum. Als der Multiplexer hinzugefĂŒgt wurde, versuchte der Synthesizer, diese Superposition zu finden, in der sowohl die Beute als auch der Multiplexer so schnell wie möglich arbeiten, und dies sind andere Elemente und Frequenzen, die bereits langsamer sind. Als externe Stifte hinzugefĂŒgt wurden, wurde das gesamte Projekt auf einem Kristall im Wesentlichen auf diese Beine verlagert und das Projekt begann auf nahegelegenen Elementen zu synthetisieren. Aus irgendeinem Grund nahmen an dieser Stelle die Frequenzen der Beute und des Multiplexers merklich zu, aber vergessen Sie dies nicht vor dem Hintergrund all dessen fĂŒr das Projekt Ein ChipScope mit einer Tiefe von 1024 und einem Datenbus von 64 bis 128 ist angeschlossen (es Ă€ndert sich von Projekt zu Projekt). Fahren wir nun mit dem nĂ€chsten Board fort.
Virtex-5:
Ich bin nicht den ganzen Weg gegangen, den ich mit dem vorherigen Board gegangen bin, ich habe sofort alle 3 Optionen zum Generieren eines Umhangs hinzugefĂŒgt und in ChipScope nachgesehen, was passiert ist.
Die Abbildung zeigt zwei Beschriftungen X und O. Neben ihren Werten in den Spalten ist das Format der Zahlen vorzeichenlos dezimal. Es ist erwÀhnenswert, dass der BasiszÀhler jetzt bei 100 MHz zÀhlt. Und so das Ergebnis:
- GPIO-Frequenz: 96,34 MHz
- Multiplexerfrequenz: 614,41 MHz
- Beutefrequenz: 5761,1 MHz
Es ist zu sehen, dass auf dieser Platine die Beute schneller als der Multiplexer und die Frequenz der Pins höher war als auf der ersten Platine. Vielleicht liegt dies daran, dass ich die beiden Pins nicht mit einem 10-cm-Leiter, sondern mit einem Jumper verbunden habe, wodurch die Kommunikationsleitung kĂŒrzer und die Frequenz höher wurde.
Und jetzt die letzte Option mit einem chinesischen Board.
Spartan-6:
Es gibt zwei grundlegende ZÀhler in ChipScope. TatsÀchlich ist es derselbe ZÀhler, der ChipScope einfach nicht neu konfigurieren wollte. In diesem Projekt wird der BasiszÀhler mit 50 MHz getaktet.
Bei diesem Board stellte sich heraus, dass alles viel komplizierter war. Erstens wollte das Projekt in keiner Weise in der Form synthetisiert werden, die in den vorherigen Versionen synthetisiert wurde. Zweitens musste ich am Ende die LUT wegwerfen und versuchte, sie durch eine FĂŒnf-Wege-LUT zu ersetzen, aber es funktionierte auch nicht. Im Allgemeinen sind hier die Ergebnisse:
- GPIO-Frequenz: 51,77 MHz
- Multiplexerfrequenz: 3 490 504 MHz
- Beutefrequenz: konnte nicht gesammelt werden
Die Ergebnisse bei der Leistung dieses Boards erwiesen sich als ĂŒberhaupt nicht zufriedenstellend, und zwar nicht nur, weil die Beute nicht als Block verwendet werden konnte, sondern auch wegen der unglaublich groĂen Frequenz des Multiplexers. FĂŒr den an den Beinen erzeugten Schredder wurde ein Leiter von etwa 25 bis 30 cm verwendet, an dessen Ende mit einem Draht verschlossen wahrscheinlich parasitĂ€re KapazitĂ€ten und InduktivitĂ€ten gebildet wurden, die sich auf die Erzeugung des Schredders auswirkten.
Fazit
Im Allgemeinen ist es uns gelungen, Taktsignale auf verschiedenen Grundelementen zu erzeugen, und wir haben auch (am Beispiel des Kintex-7) festgestellt, dass Grundelemente je nach Standort unterschiedliche Latenzzeiten haben. In meinem eigenen Namen möchte ich hinzufĂŒgen, dass ich das durchgefĂŒhrte Experiment nicht als vollstĂ€ndig korrekt betrachte. Beispielsweise wurde die Bitbreite der ZĂ€hler nicht berechnet, die SignalĂŒbertragung von verschiedenen TaktdomĂ€nen wurde nicht berĂŒcksichtigt (obwohl ich das Signal im Puffer fĂŒr mehrere Taktzyklen beibehalten habe), das ChipScope selbst sollte idealerweise entfernt werden und ein anderer Weg sollte gefunden werden Analysieren Sie die erzeugte Frequenz.
Probleme aufgetreten:
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;