Error in Xilinx EDK -> CLOCK_DEDICATED_ROUTE = FALSE

[VHDLUser (Gast)]

Guten Tag.
Ich habe ein Problem mit einem VHDL-Code auf dem Virtex 6. Wie kann ich 
folgende Fehlermeldung beheben (nicht umwandeln in eine Warnung!)?

Als Lösung wird mir http://www.xilinx.com/support/answers/34346.htm 
angeboten. Jedoch verstehe ich nicht, was damit genau gemeint ist (bzw. 
wie ich es in EDK umsetze).

Ursprünglich war das Signal (im ucf-File) "rx_clk_in_p_2" mit Pin AF20. 
(AF20 -> IO_L11P_SRCC_22) verbunden. Jetzt musste ich es auf Pin K26 
routen (K26 -> IO_L9P_MRCC_16).

Was ist der Unterschied zwischen SRCC und MRCC? Kann der genannte Fehler 
damit zu tun haben?

Vielleicht hat ja wer Erfahrung mit dem Fehler (habe hier im Forum 
ältere Beiträge gelesen) und kann mir helfen diesen Schritt für Schritt 
zu beheben. Danke. Nun die Fehlermeldung aus EDK heraus:

ERROR:Place:1153 - A clock IOB / BUFGCTRL clock component pair have been 
found that are not placed at an optimal clock
   IOB / BUFGCTRL site pair. The clock IOB component <rx_clk_in_p_2> is 
placed at site <K26>. The corresponding BUFGCTRL
   component <axi_ic/axi_ic_1/i_dev_if/i_clk_gbuf> is placed at site 
<BUFGCTRL_X0Y26>. The clock IO can use
   the fast path between the IOB and the Clock Buffer if a) the IOB is 
placed on a Global Clock Capable IOB site that
   has the fastest dedicated path to all BUFGCTRL sites, or b) the IOB 
is placed on a Local Clock Capable IOB site that
   has dedicated fast path to BUFGCTRL sites in its half of the device 
(TOP or BOTTOM). You may want to analyze why this
   problem exists and correct it. 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 "rx_clk_in_p_2" CLOCK_DEDICATED_ROUTE = FALSE; >

ERROR:Pack:1654 - The timing-driven placement phase encountered an 
error.
ERROR:Xflow - Program map returned error code 2. Aborting flow 
execution...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

VHDLUser schrieb:
> rx_clk_in_p_2
Was ist das für ein "Takt"?
Wie viele "Takte" hast du in deinem Design?

Zum drüber Nachdenken:
Warum schreibe ich hier "Takt" immer in Hochkommas?

[VHDLUser (Gast)]

Danke. Der "Takt" beträgt 250 MHz. 6 "Taktsignale" habe ich im Design:

CLK_IN_P      -> 200 MHz (J9),
CLK_IN_N      -> 200 MHz (H9),

rx_clk_in_p_1  -> 250 MHz (AF20),
rx_clk_in_n_1  -> 250 MHz (AF21),

rx_clk_in_p_2 -> 250 MHz  (K26),
rx_clk_in_n_2 -> 250 MHz  (K27),

Der Fehler tritt nur lediglich für "rx_clk_in_p_2" auf.

... aus dem ucf-File:

NET "CLK_P" TNM_NET = "CLK_P";
TIMESPEC "TS_CLK_P" = PERIOD "CLK_P" 200 MHz;
NET "CLK_N" TNM_NET = "CLK_N";
TIMESPEC "TS_CLK_N" = PERIOD "CLK_N" 200 MHz;

NET "rx_clk_in_p_1" TNM_NET = "rx_clk_in_p_1";
TIMESPEC "TS_rx_clk_in_p_1" = PERIOD "rx_clk_in_p_1" 250 MHz;
NET "rx_clk_in_n_1" TNM_NET = "rx_clk_in_n_1";
TIMESPEC "TS_rx_clk_in_n_1" = PERIOD "rx_clk_in_n_1" 250 MHz;

OFFSET = IN BEFORE "rx_clk_in_p_1" RISING;
OFFSET = IN BEFORE "rx_clk_in_p_1" FALLING;

OFFSET = OUT AFTER "rx_clk_in_p_1" REFERENCE_PIN "tx_clk_out_p_1" 
RISING;
OFFSET = OUT AFTER "rx_clk_in_p_1" REFERENCE_PIN "tx_clk_out_p_1" 
FALLING;


NET "rx_clk_in_p_2" TNM_NET = "rx_clk_in_p_2";
TIMESPEC "TS_rx_clk_in_p_12" = PERIOD "rx_clk_in_p_2" 250 MHz;
NET "rx_clk_in_n_2" TNM_NET = "rx_clk_in_n_2";
TIMESPEC "TS_rx_clk_in_n_2" = PERIOD "rx_clk_in_n_2" 250 MHz;

OFFSET = IN BEFORE "rx_clk_in_p_2" RISING;
OFFSET = IN BEFORE "rx_clk_in_p_2" FALLING;

OFFSET = OUT AFTER "rx_clk_in_p_2" REFERENCE_PIN "tx_clk_out_p_2" 
RISING;
OFFSET = OUT AFTER "rx_clk_in_p_2" REFERENCE_PIN "tx_clk_out_p_2" 
FALLING;

[Valko Z. (hydravliska)]

Xilinx ug362, Seite 63, Appendix A
SRCC - Single Region clock capable
MRCC - Multi Region clock capable

[VHDLUser (Gast)]

Danke. Also für die hier verwendeten "Takte" müsste es laut 
http://forums.xilinx.com/t5/7-Series-FPGAs/SRCC-vs-MRCC/td-p/305119 egal 
sein. D.h. hier kann der Fehler nicht liegen.

[VHDLUser (Gast)]

Das Design beinhaltet einen IP-Core von Analog Devices. Da wird in den 
Core Einstellungen eine "PCore_IODELAY_GROUP" festgelegt. Ursprünglich 
stand da "adc_if_delay_group_1".  Mit diesem Core sind die Signale 
"rx_clk_in_p_1" und "rx_clk_in_n_1" verbunden. Ich habe einen weiteren 
Core hinzugefügt. Diesem habe ich die selben Eigenschaften zugewiesen. 
Ich habe lediglich die PCore_DELAY_GROUP "adc_if_delay_group_2" genannt, 
damit diese nicht beide den selben Namen tragen ( ansonsten gibt es 
einen Fehler). Mit dem hinzugefügten Core sind die Signale 
"rx_clk_in_n_2" und "rx_clk_in_p_2" verbunden.

Vielleicht ist das ein möglicher Grund für die eingangs erwähnte 
Fehlermeldung.

[VHDLUser (Gast)]

Habe bereits vor einem Monate wegen dem Fehler nachgefragt. Konnte den 
alten Beitrag nur nicht mehr finden (-> 
Beitrag "Problem mit der Vergabe einer PCORE_IODELAY_GROUP"). Entschuldigung. Hoffe, mir 
wird trotzdem weitergeholfen.

[VHDLUser (Gast)]

Okay. Das wird nicht der Grund sein. Hat wer Vorschläge, wie ich ans 
Ziel komme?

[René D. (Firma: www.dossmatik.de) (dose)]

Du kannst in deinem UCF File die Zeile einfügen.

 NET "rx_clk_in_p_2" CLOCK_DEDICATED_ROUTE = FALSE;

So kannst du schauen ob es durchläuft. Manchmal tauchen dann noch 
weitere Fehler auf, den du nachgehen musst und dann kannst du die Zeile 
wieder herausnehmen.

[Valko Z. (hydravliska)]

So wie es ausschaut hast du nicht die optimale Pins für die Takten 
ausgewählt. Du kannst im Xilinx FPGA Editor nachschauen durch welche 
Komponente dein Signal geroutet wird. Die Xilinx Meldung sagt schon 
welche Komponente problematisch sind.

[Valko Z. (hydravliska)]

http://forums.xilinx.com/t5/Virtex-Family-FPGAs/Questions-about-the-Virtex-6-Clock-Pins/td-p/195646

[VHDLUser (Gast)]

1)
Danke René D.. Habe ich bereits gemacht. Dann läuft das Design durch. 
Jedoch ist der ADC (an den der clock geht) nicht funktionsfähig.

2)Dir auch danke Valko Zapalko. Wo muss ich da genau nachschauen? Mit 
welchen Programm?

[VHDLUser (Gast)]

Also folgendes habe ich nun lokalisiert:

1. Test:

rx_clk_in_p_1 -> AF20 -> IO_L11P_SRCC_22
rx_clk_in_n_1 -> AF21 -> IO_L11N_SRCC_22
rx_clk_in_p_2 -> K26  -> IO_L9P_MRCC_16
rx_clk_in_n_2 -> K27  -> IO_L9N_MRCC_16

=> oben genannte Fehlermeldung bezieht sich auf NET "rx_clk_in_p_2"

2. Test:

rx_clk_in_p_2 -> AF20 -> IO_L11P_SRCC_22
rx_clk_in_n_2 -> AF21 -> IO_L11N_SRCC_22
rx_clk_in_p_1 -> K26  -> IO_L9P_MRCC_16
rx_clk_in_n_1 -> K27  -> IO_L9N_MRCC_16

=> oben genannte Fehlermeldung bezieht sich auf NET "rx_clk_in_p_1"

Demnach sind die IO_L9P_MRCC_16 nicht geeignet? Ich habe das Problem, 
dass ich eine vom Hersteller verwendete Pin-Belegung nutze. Ich kann 
diese nicht umrouten (momentan).

Also muss ich das Problem irgendwie über die Software/das Design lösen. 
Seht ihr da Möglichkeiten, außer jetzt den Fehler zu ignorieren? In 
Zukunft benötige ich noch 4 weitere rx_clk_in_p/n Signale. Seht ihr da 
noch weitere Probleme (falls ich mein jetziges irgendwie mit eurer Hilfe 
gelöst bekomme)?

[Valko Z. (hydravliska)]

Wohin gehen deine Signale? Zum PLL oder taktest du direkt Logik damit? 
Oder beider? Ist ein BUFG dazwischen oder IBUFDS oder...? So wie ich das 
verstehe ist der Unterschied zwischen SRCC, MRCC und GC in der Art und 
Weise wie die verwendet werden.

FPGA Editor ist ein Tool was du vom Xilinx ISE starten kannst. Du musst 
die "Implement Design" Menu aufklappen und dann "Place & Route". Drin 
findest du View/Edit Routed Design (FPGA Editor). Ein Tool wird 
gestartet und da kannst du deine Pins raussuchen und die Signale 
verfolgen.


Gruss

[VHDLUser (Gast)]

Ich habe das Design in EDK erstellt. Bekomm es irgendwie nicht mit dem 
FPGA Editor auf.

[Valko Z. (hydravliska)]

Dann musst du den FPGA Editor Standalone starten. START Menu und dann in 
den Xilinx Tools nachschauen. Dann File-> Open und alle relevante 
Dateien in deinen Syntheseordner raussuchen.

[VHDLUser (Gast)]

Danke. Ich habe dir mal das Ergebnis angehängt.

(1) Ich habe nun "NET "rx_clk_in_p_1" CLOCK_DEDICATED_ROUTE = FALSE;" 
eingefügt, damit geroutet wird.

Auszug aus dem ucf-File:

NET rx_clk_in_p    LOC = AF20  |  IOSTANDARD = LVDS_25  | DIFF_TERM = 
TRUE;
NET rx_clk_in_n    LOC = AF21  |  IOSTANDARD = LVDS_25  | DIFF_TERM = 
TRUE;

NET rx_clk_in_p_1  LOC = K26   |  IOSTANDARD = LVDS_25  | DIFF_TERM = 
TRUE;
NET rx_clk_in_n_1  LOC = K27   |  IOSTANDARD = LVDS_25  | DIFF_TERM = 
TRUE;

NET "rx_clk_in_p_1" CLOCK_DEDICATED_ROUTE = FALSE;

Auszug aus dem FPGA-Editor ist angehängt.

Kannst du mich eventuell durch das Debugging leiten? (Vorschläge machen)

Nachtrag:

Ich weiß nicht, was dazwischen ist (BUFG dazwischen oder IBUFDS). Ich 
muss schnell mit EDK ein Refrenzdesign erweitern. In dem Fall um die 
AD-Wandler. Ich habe in EDK lediglich die relevanten "Blöcke" dupliziert 
und entsprechend verbunden. Funktioniert auch soweit. Bis auf den ADC 
(wegen dem Taktproblem).

[VHDLUser (Gast)]

Anbei nocheinmal die Signalverläufe vom Signal rx_clk_in_p/n (links) und 
rx_clk_in_p_1/n_1 (rechts).

[René D. (Firma: www.dossmatik.de) (dose)]

VHDLUser schrieb:
> 1)
> Danke René D.. Habe ich bereits gemacht. Dann läuft das Design durch.
> Jedoch ist der ADC (an den der clock geht) nicht funktionsfähig.

Ah der Port ist ein Taktausgang zu ADC.
Dann schau dir mal mit einem gutem Oszi den Takt an.
Ich kenne nicht dein ADC.
Die ADCs  wollen meist ein Tastverhältnis von 50:50. Pegel usw.

[VHDLUser (Gast)]

Es ist ein SDR AD 93 61. Und das Signal geht denke ich in den ADC. Komme 
an das Signal nicht heran von außen. (FMC-Stecker)

[Duke Scarring (Gast)]

VHDLUser schrieb:
> Und das Signal geht denke ich in den ADC.
Vielleicht klärst Du erstmal in wo bei diesem Signal Quelle und Senke 
sitzen? Im .ucf-File schreibst Du rx_clk_in (_p,_n). Das suggeriert ein 
differentielles (Takt-)Signal, welches in den FPGA geht...
Jetzt geht es auf einmal in den ADC...

Duke

[VHDLUser (Gast)]

Sorry. Es geht in einen IP-Core. Da heißt das Signal nur adc. Mein 
Fehler.

[VHDLUser (Gast)]

Ich kann das Design leider nicht hochladen, da die Datei sehr groß ist.

[VHDL User (Gast)]

Habe habe die Pins K26 bzw. K27 gegen die Pins AH23 bzw. AH24 (im 
.ucf-File) ausgetauscht. Bei den Pins AH23 bzw. AH24 handelt es sich nun 
auch um SRCC.

Der bit stream wird erfolgreich erzeugt.

=> es lag wohl an der Umgebung MRCC der Pins K26 bzw. K27.

Nun kann ich die Pins in "wirklichkeit" nicht umlegen, da sie fest im 
FMC-Stecker verdrahtet sind.

Hat wer einen Vorschlag, wie ich die MRCC Umgebung trotzdem nutzen kann 
(-> oder Umwandeln in eine SRCC-Umgebung)?