Hallo, ich würde gerne externe Daten in einen FPGA einlesen. Bei den Daten handelt es sich um 16 Bit breiten parallelen Datenbus und ein dazugehörigem Taktsignal. Ich wollte nun die Daten in ein FIFO mit Independent Clock, mit dem externen Takt einlesen und auf der anderen Seite diese Daten mit dem Board Takt wider auslesen. Ich bekomme jedoch die Fehlermeldung: "A clock IOB clock component is not placed at an optimal clock IOB site. The clock IOB component <ext_CLK> is placed at site <IOB_X0Y150>. The clock IO site can use the fast path between the IO and the Clock buffer/GCLK if the IOB is placed in the master Clock IOB Site." Daraufhin hab ich meinen externen Takt auf ein IBUFG gelegt und dessen Ausgang auf das FIFO_WR_CLK Pin. Dies hat allerdings NICHTS an der Fehlermeldung geändert. Kann mir jemand sagen, was ich noch falsch mache? In meinem UCF File hab ich zu dem Taktsignal folgendes stehen: NET ext_CLK TNM_NET = ext_CLK_pin; TIMESPEC TS_ext_CLK_pin = PERIOD ext_CLK_pin 100 ns HIGH 50%; NET ext_CLK LOC = H32 | IOSTANDARD = LVCMOS33; Ich benutzt das ML505 Board und alle meine signale gelangen über J6 in den FPGA. Danke für Hilfe Mit freundlichen Grüßen matzunami
Diese Meldung ist nur eine Warnung und kein Fehler. Bestimmte Eingänge des FPGAs sind speziell dafür vorgesehen für Taktsignale benut zu werden. Diese ermöglichen dann eine möglichst schnelle Verteilung im ganzen FPGA ohne größere Latenzen. Solange in deinem Fall die Setup und Holdzeiten für die Dateneingänge eingehalten werden können spricht nichts dagegen, für diesen kleinen Teil der Logik, nämlich die eine Seite des Fifos plus die nötigen Synchronisierungsregister, den Takt an einem nicht-dedizierten Eingang in den FPGA zu geben und die möglicherweise etwas längere Zeit bis dieser an den FF ankommt zu tolerieren.
Ok... Xilinx meint nur das ich das Problem im UCF File zu einer Warnung machen kann, dies aber nicht ratsam währe. Aber wenn das so funktioniert. Seh ich das dann richtig, dass mein Ausgewählter Pin "H32", nicht einer der bestimmten Pins ist, der für Taktsignale vorgesehen ist? Wo finde ich im Datenplatt die dafür vorgesehen Pins? Und zuletzt noch: Du schreibst "plus die nötigen Synchronisierungsregister" Sind diese auch nötig wenn ich die Daten direkt in das FIFO einlese? Wenn ja warum? Meine Daten kommen doch nicht vor dem FIFO mit dem Board Takt in Berührung? Vielen Dank für deine schnelle Antwort.
Und wenn mein Taktsignal nicht zu einer Clock Domain geroutet werden kann, macht mein IBUFG dann einen Sinn, oder wird dieses wegoptimiert? Danke
Das heißt nur, dass der Clock-Eingang nicht der optmale ist. Die Eingänge gehen in bestimte Regionen des Chips, und wenn dein FIFO in einer anderen region sitzt kommt diese Meldung (die übrigens erst seit ISE 10.1 ein Fehler ist, vorher wars immer Warnung). Solange das Timing passt, kannst du das ignorieren. Wenn du viel BlockRam zu großen FIFOs zusammenschaltest, lässt sich das gar nicht vermeiden. In der Praxis ist es eh schwierig, den gesamten FPGA optimal aus einem CLK zu versorgen. Du kannst auch an den CLK Eingang einen DCM schalten, dessen Ausgänge gehen direkt auf die schnellen CLK Leitungen im Fabric, und können größere Teile des FPGA versorgen als die IBUFG. Wieso, weiß ich auch nicht. Aber wahscheinlich kommt dann als nächstes die Meldung, dass IBUFG und DCM nicht die optimalen Pärchen sind. Naja, wie gesagt, im Auge behalten, aber als Warnung einstellen. Einfach das DEDICATE_ROUTE auf False setzen. Zu den Sync-FF: Mach die mal lieber rein. Die 2 Takte Latenz hast du sicher...
> Und zuletzt noch: Du schreibst > "plus die nötigen Synchronisierungsregister" > > Sind diese auch nötig wenn ich die Daten direkt in das FIFO einlese? > Wenn ja warum? Meine Daten kommen doch nicht vor dem FIFO mit dem Board > Takt in Berührung? Deine Daten nicht, aber dein write-pointer fuer den Fifo! Wenn du wirklich sauber wissen willst, ob Daten im Fifo sind oder ob noch ein Plaetzchen fuer neue Daten frei ist, dann musst du den sauber in deine FPGA Clock-Domain einsynchronisieren.
Clock Pins besitzen intern entsprechende, dedizierte clockleitungen. Das beudetet fest verlegte Verbindungen zu allen(?) FF, was global einen eindeutigen takt ermöglicht und kein Routing notwendig macht. Ganz zu schweigen vom Fanout einer Clockleitung im Gegensatz zu einer normalen. Wenn du einen typischen i/o-pin benutzen willst wie einen clock pin, dann wirst du bei massivem Einsatz global nicht mit dem gleichen Taktzeitpunkt arbeiten können. Falls das mittlerweile anders aussieht, schlagt mich, aber so hab ichs an der Uni gelernt. Ehrlich gesagt kann ichs mir auch nicht anders vorstellen. Jede normale Leitung muss nunmal über die Verbindungspunkte geroutet werden und kann deshalb per se schon nicht zum gleichen Zeitpunkt an jedem Folge-FF schalten. (unterschiedliche Wege, Anzahl Verbindungspunkte) Für dieses kleine Problem hier sollte das aber noch nicht relevant sein.
Ok dann mal schon vielen dank für die Antworten. Dann hab ich nur noch eine frage. Wenn ich die Eingäne über FF laufen lassen soll, müssen diese ja von dem externen Takt getaktet werden. Somit muss ich den Takt doch für das FIFO noch einmal negieren, um die Daten wieder in der Mitte des Datenauges einzulesen. Wenn der Takt eh schon nicht optimal ist ist es dann noch ratsam ihn auch noch negiert zu benutzen?
Nein, du musst um Gottes willen keinen Takt negieren. Alles mit einem Takt. Da sich dann die Daten hinter dem FF garantier erst nach der steigenden Flanke ändern kannst du die mit der steigenden Flanke in den FIFO übernehmen. Die FF sind dringend anzuraten, denn die sitzen dann direkt als IOB-FF hinter dem Pin und übernehmen die Daten und Steuersignale somit ohne Routing-Laufzeiten. Die FIFO Blöcke sind erst über Routing zu erreichen und sitzen von außen aus gesehen, hinter den IOB-FlipFlops. @ Iulius: Ganz so einfach ist es leider nicht (mehr). Es gibt da noch die regional Clocks oder Site Clocks usw. Bei unseren Virtex 4 Designs meckert der auch rum, dass es nicht der optimale GCLK Eingang ist, wenn ich einen der globalen CLK Eingänge direkt als CLK verwende. Benutze ich einen DCM, passiert das nicht. In den Datenblättern ist außerdem angegeben, dass die sequenzielle Logik schneller läuft, wenn man als CLK versorgung einen Ausgang des DCM benutzt (speziell beim Spartan 3 ist das ein ganzes Stück).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.