mikrocontroller.net

Forum: FPGA, VHDL & Co. problem mit externen Takt


Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn mein Taktsignal nicht zu einer Clock Domain geroutet werden 
kann, macht mein IBUFG dann einen Sinn, oder wird dieses wegoptimiert?

Danke

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Iulius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok dann nochmal vielen dank

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.