mikrocontroller.net

Forum: FPGA, VHDL & Co. Problem mit DCM-Position


Autor: Anguel S. (anguel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ich nutze einen Spartan-3A XC3S200A-4FT256 und ISE 12.1 (Webpack).
Bisher hatte ich folgende DCM-Konfiguration, die ohne Probleme lief:
Clock Eingangs-Pin (R9) -> IBUFG -> [DCM1 -> DCM2]

DCM1 und DCM2 sind kaskadiert und wurden als solche mit CoreGen erzeugt. 
Den IBUFG habe ich darauf aus dem mit CoreGen generierten Modul 
herausgenommen und ins Top-Modul gebracht. DCM1 erzeugt einen CLKFX und 
einen CLK2X. Der CLK2X dient einmal als interner Feedback für DCM1 und 
geht auch zu DCM2. DCM2 erzeugt daraus einen CLK0 (der auch als interner 
Feedback für DCM2 dient) und einen CLK90. Alle Output-Clocks der beiden 
DCMs verwenden BUFGs.

Nun wollte ich einen dritten DCM_NEU erzeugen, der unabhängig von DCM1 
und DCM2 einen eigenen CLKFX erzeugt. Als interner Feedback dient CLK0 
des DCM_NEU. Auch hier verwenden alle Ausgangs-Clocks des DCM BUFGs. In 
Coregen habe ich bei DCM_NEU als CLKIN Source INTERNAL gewählt, damit 
ich den oben erwähnten bereits vorhandenen IBUFG nutzen kann. Der CLKIN 
Eingang von DCM_NEU habe ich mit diesem IBUFG verbunden, so dass ich nun 
zusätzlich zur oberen Konfiguration:
IBUFG (derselbe von oben) -> DCM_NEU
habe.

Der Place & Route Prozess meldet aber nun folgenden Fehler (in der 
Fehlermeldung "the_clk8mhz_dcm" DCM_NEU):
ERROR:Place:1012 - A clock IOB / DCM component pair have been found that 
are not placed at an optimal clock IOB / DCM
site pair.  The clock component <the_clk8mhz_dcm/DCM_SP_INST> is placed 
at site <DCM_X0Y1>.  The clock IO/DCM site
can be paired if they are placed/locked in the same quadrant.  The IO 
component <sys_clk_in> is placed at site
<PAD151>.  This will not allow the use of the fast path between the IO 
and the Clock buffer. If this sub optimal
condition is acceptable for this design, you may use the 
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote
this message to a WARNING and allow your design to continue. However, 
the use of this override is highly discouraged
as it may lead to very poor timing results. It is recommended that this 
error condition be corrected in the design. A
list of all the COMP.PINs used in this clock placement rule is listed 
below. These examples can be used directly in
the .ucf file to override this clock rule.
< NET "sys_clk_in" CLOCK_DEDICATED_ROUTE = FALSE; >
< PIN "the_clk8mhz_dcm/DCM_SP_INST.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE; 
>

Das Eigenartige ist, dass die Xilinx Answer Datenbank nun auf folgende 
Bugs verweist:
http://www.xilinx.com/support/answers/31462.htm -> 10.1 Spartan-3A PAR - 
ERROR:Place:1012 - A clock IOB / DCM component pair have been found that 
are not placed at an optimal clock IOB / DCM site pair
und
http://www.xilinx.com/support/answers/34571.htm -> AR #34571 - ISE 
Design Suite 11.5 Update - Known Issues for Early Access 11.5 DVD 
Release
Im zweiten AR ist dann ein weiterer Link zu Xilinx Answer 34613: 11.5 
EDK - "ERROR:Place:1012 - A clock IOB / DCM component pair have been 
found that are not place at an optimal clock IOB / DCM site pair"
Dieser AR 34613 ist aber nicht vorhanden: "We apologize, but the page 
you have requested was not found on our site."

Die Frage ist nun, ob die oben genannte Fehlermeldung ein Bug ist. Oder 
ist es einfach so, dass mein Clock-Signal von Clock Pin (R9) über den 
IBUFG nur zu DCM1, aber nicht gleichzeitig auch zu DCM_NEU gelangen 
kann? Es gibt ja laut UG331 bevorzugte Clock-Eingangs-Pins für die 
einzelnen DCMs. Kann es sein, dass tatsächlich nur die eine DCM in dem 
einen Quadranten von Clock Pin R9 versorgt werden kann?
Habe auch versucht, die DCM manuell näher am Clock Pin zu platzieren 
(INST "the_clk8mhz_dcm/DCM_SP_INST" LOC=DCM_X0Y0;) - siehe angehängten 
Screenshot vom PlanAhead.

Rechts unten ist DCM1, links oben ist DCM2 (beide cyan).
Links unten (X0Y0) ist dann der manuell platzierte DCM_NEU (orange).
Vom Clock-Eingangs-Pin R9 aus gehen die beiden grünen Striche zu DCM1 
und DCM_NEU.

Das manuelle Platzieren hat leider nichts gebracht. Der P&R-Fehler kommt 
erneut :( Kann der Fehler evtl. auch was damit zu tun haben, dass keine 
freien Global Clock Routing Ressourcen mehr vorhanden sind?

Danke für jede Hilfe!

Grüße,
Anguel

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anguel S. schrieb:

> Oder ist es einfach so, dass mein Clock-Signal von Clock Pin (R9) über den
> IBUFG nur zu DCM1, aber nicht gleichzeitig auch zu DCM_NEU gelangen
> kann?

Genau so ist es. Wird ein DCM mit einem CLK betrieben, der nicht einer 
der direkt zugeordneten GCLK oder LCLK Eingänge ist, dann gibts diese 
Warnung.
Das gleiche Problem hatten wir auch mal, 2 CLK auf 2 DCM, deren je 4 
Ausgänge alle benutzt waren. Leider lagen die 2 CLK Eingänge nicht auf 
unterschiedlichen Seiten des Chips, somit kam 1. die o.g. Warnung und 2. 
konnten auch nicht alle 8 DCM Ausgänge einen BUFG am Ausgang bekommen. 
Da muss man auch noch aufpassen. Immer 2 DCM teilen sich die 4 BUFGMUX 
am Ausgang. Leider hat der Spartan 3 nur 8 globale interne Clock Lines. 
(Seite 83 im UG331).

beheben kannst du den Fehler durch ein passendes "CLOCK_DEDICATED_ROUTE 
= FALSE" Constraint im UCF.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Christian!

Also bleibt mir anscheinend nix anderes übrig, als CLOCK_DEDICATED_ROUTE 
= FALSE zu setzen. Habe dazu nicht wirklich gute Dokumentation gefunden 
:( Muss man beide von P&R vorgeschlagenen Constraints setzen oder reicht 
nur die eine dieser beiden:
NET "sys_clk_in" CLOCK_DEDICATED_ROUTE = FALSE;
PIN "the_clk8mhz_dcm/DCM_SP_INST.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE;

Die Warnungen von P&R bzgl. dieses Workarounds hören sich nicht gerade 
beruhigend an. Wirkt sich das Umbiegen auf ungeeignetere Ressourcen 
durch CLOCK_DEDICATED_ROUTE = FALSE eigentlich nur auf meine DCM_NEU 
aus, oder wird auch meine bisher gut laufende und wichtigere DCM1 davon 
benachteiligt, wenn ich die von P&R vorgeschlagenen Constraints setze?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Constraint du setzen musst, steht doch eigentlich an der 
Fehlermeldung direkt mit dran.(zumindest im Transcript Fnster 
unten....mal hochscrollen) Wenn du keine abartig hohen Frequenzen hast, 
klingt das schlimmer, als es ist. Ich hatte bei 100MHz und diesem 
"Fehler" bisher keine Schwierigkeiten.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Welche Constraint du setzen musst, steht doch eigentlich an der
> Fehlermeldung direkt mit dran.(zumindest im Transcript Fnster
> unten....mal hochscrollen)

In der Fehlermeldung sind aber 2 Constraints gelistet:
NET "sys_clk_in" CLOCK_DEDICATED_ROUTE = FALSE;
PIN "the_clk8mhz_dcm/DCM_SP_INST.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE;

Habe das getestet und anscheinend lösen beide einzeln das Problem, aber 
gemeinsam kann man die auch setzen.

Nochmal zu CLOCK_DEDICATED_ROUTE: Im FPGA-Editor sehe ich keinen 
Unterschied, wenn ich CLOCK_DEDICATED_ROUTE = FALSE setze. Wie kann man 
sehen, ob diese dedizierte Route verwendet wird oder nicht?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen Unterschied wirst du se nicht sehen, denn ohne Constraint ist das 
ja ein Error und der Router bricht ab. Da dürfte die CLK Leitung 
überhaupt nicht fertig geroutet sein.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Einen Unterschied wirst du se nicht sehen, denn ohne Constraint ist das
> ja ein Error und der Router bricht ab. Da dürfte die CLK Leitung
> überhaupt nicht fertig geroutet sein.

Ich meinte natürlich Unterschied zwischen:
a) ohne DCM_NEU und
b) mit DCM_NEU und Constraint

Habe beide Designs angeschaut und verglichen, aber keinen Unterschied 
gesehen in Bezug auf das Routing zu DCM1 und überhaupt.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bedanke mich auch für diesen Thread.
Steige gerade mit meinen Basteleien von ISE9.1 auf 12.1 um.
Das Constraint hat geholfen.

Bei 9.1 ging es ohne ein entsprechendes Constraint, hat aber eben ne 
Warnung ausgespuckt. Also bei allen Projekten schön das Constraint 
setzen, zumal ich eh nicht über 100MHz komme (denke ich jedenfalls nicht 
:-)).

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.