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.
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).
