Problem mit der Vergabe einer PCORE_IODELAY_GROUP

[User (Gast)]

Hi! Ich habe ein funktionsfähiges Projekt in EDK Xilinx vorliegen. Nun 
möchte ich einen Teil des Programmes erweitern. Ich habe somit einen 
Core dupliziert. In den Settings des originalen Cores steht etwas von 
PCORE_IODELAY_GROUP "adc_if_delay_group". Nun meine Frage hierzu: Ist 
der Name der Gruppe , also "adc_if_delay_group" irgendeine frei gewählte 
Bezeichnung für die Gruppe, oder handelt es sich um einen in Xilinx 
allgemein definierten Namen?

Verwende ich in beiden Cores (original und dupliziert) den selben Namen 
"adc_if_delay_group" kommt es zu einem Fehler:

.
ERROR:MapLib:1002 - IDELAYCTRL processing failed. IDELAYCTRL symbol
   "axi_device_0/axi_device_0/i_dev_if/i_delay_ctrl" (output
   signal=axi_device_0/axi_device_0/delay_locked_s) and IDELAYCTRL 
symbol
   "axi_device_1/axi_device_1/i_dev_if/i_delay_ctrl" (output
   signal=axi_device_1/axi_device_1/delay_locked_s) have the same 
IODELAY_GROUP
   constraint but do not share the same Reset signal.

Kann ich zum Beheben nun einfach die Gruppe des duplizierten Cores 
"adc_if_delay_group_2" nennen?

[User (Gast)]

Hier der Anhang.

[Duke Scarring (Gast)]

User schrieb:
> Ist der Name der Gruppe , also "adc_if_delay_group" irgendeine frei gewählte
> Bezeichnung für die Gruppe, oder handelt es sich um einen in Xilinx
> allgemein definierten Namen?
Ich würde sagen, es ist eine von Xilinx frei gewählte Bezeichnung ;-)

> Verwende ich in beiden Cores (original und dupliziert) den selben Namen
> "adc_if_delay_group" kommt es zu einem Fehler:
Dann würde ich für die Kopie einen anderen Namen wählen.
Die Constraints müssen dann natürlich auch dupliziert und angepasst 
werden.

Die verwendeten Signalnamen kann man mit dem FPGA-Editor ermitteln.

Duke

[User (Gast)]

Danke. Ich habe den Namen für den zweiten Core in "adc_if_delay_group_2" 
geändert.

Du schreibst "Die Constraints müssen dann natürlich auch dupliziert und 
angepasst werden.". Klar. Das macht EDK doch automatisch, richtig?!.

Möchte ich mir nun ein BitStream erzeugen bekomme ich folgenden Fehler:

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_device_1/axi_device_1/i_dev_if/i_clk_gbuf> is placed 
at site <BUFGCTRL_X0Y18>. 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...


Ich denke mal nicht, dass dieser Fehler etwas mit der zuvor behobenen 
DelayGroup zu tun hat, richtig?

Im ucf-File stand im funktionsfähigen Fall:

...
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 tx_clk_out_p LOC = J30   |  IOSTANDARD = LVDS_25  | SLEW = FAST;
NET tx_clk_out_n LOC = K29   |  IOSTANDARD = LVDS_25  | SLEW = FAST;

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" TNM_NET = "rx_clk_in_p";
TIMESPEC "TS_rx_clk_in_p" = PERIOD "rx_clk_in_p" 250 MHz;
NET "rx_clk_in_n" TNM_NET = "rx_clk_in_n";
TIMESPEC "TS_rx_clk_in_n" = PERIOD "rx_clk_in_n" 250 MHz;

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

OFFSET = OUT AFTER "rx_clk_in_p" REFERENCE_PIN "tx_clk_out_p" RISING;
OFFSET = OUT AFTER "rx_clk_in_p" REFERENCE_PIN "tx_clk_out_p" FALLING;

Da ich das Programm um einen duplizierten Core erweitert habe, habe ich 
hinzugefügt:

NET rx_clk_in_p_2 LOC = AF20 |  IOSTANDARD = LVDS_25  | DIFF_TERM = 
TRUE;
NET rx_clk_in_n LOC_2 = AF21 |  IOSTANDARD = LVDS_25  | DIFF_TERM = 
TRUE;
NET tx_clk_out_p_2 LOC = J30 |  IOSTANDARD = LVDS_25  | SLEW = FAST;
NET tx_clk_out_n_2 LOC = K29 |  IOSTANDARD = LVDS_25  | SLEW = FAST;

NET "rx_clk_in_p_2" TNM_NET = "rx_clk_in_p_2";
TIMESPEC "TS_rx_clk_in_p_2" = 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;

In der Fehlerbeschreibung steht ja nun als Abhilfe etwas von "NET 
"rx_clk_in_p_2" CLOCK_DEDICATED_ROUTE = FALSE;". Ich denke aber nicht, 
dass das eine Lösung darstellt. (Es wird ja nur der Fehler in eine 
Warnung umgewandelt. Was ich persönlich nun nicht gerade für 
erstrebenswert halte).

Kannst du mir mit den wenigen Infos eventuell weiterhelfen, wo der 
Fehler liegen könnte bzw, was mit dem Fehler gemeint ist um diesen auf 
die Spur zu kommen? Danke dir.

[User (Gast)]

Ich habe das ganze einmal mit dem Beitrag 
(Beitrag "Problem mit DCM-Position") verglichen. Ist ja genau 
mein Problem (denke ich). Ich habe nun im UCF-File:

NET "rx_clk_in_p_2" CLOCK_DEDICATED_ROUTE = FALSE;

hinzugefügt.

Bringt nichts. Erhalte die selbe Fehlermeldung wie zuvor.

[Duke Scarring (Gast)]

User schrieb:
> Du schreibst "Die Constraints müssen dann natürlich auch dupliziert und
> angepasst werden.". Klar. Das macht EDK doch automatisch, richtig?!.
Das weiß ich nicht, dazu kenne ich EDK zu wenig.

User schrieb:
> Ich denke mal nicht, dass dieser Fehler etwas mit der zuvor behobenen
> DelayGroup zu tun hat, richtig?
Möglicherweise schon, aber eher indirekt.

Hast Du einen Überblick, wieviele Takte in Deinem Design verwendet 
werden?
Speziell die IDELCTRL benötigen doch irgendwie 200 MHz Takt, wenn ich 
mich nicht irre.

Der Router hat eher ein Problem die Clock-Ressourcen optimal zu 
plazieren und zu routen. Aber hier wird es eklig.
Wieviele BUGs hat Dein FPGA?
Wieviele BUFG und BUFGMUX verwendet Dein Design?
Wieviele DCM/PLL werden benutzt?
Wenn man das alles im Blick hat, kann man mit placemnt constraints den 
Tools auf die Sprünge helfen. Aber so richtig Spaß macht das nicht.

User schrieb:
> NET "rx_clk_in_p_2" CLOCK_DEDICATED_ROUTE = FALSE;
>
> hinzugefügt.
>
> Bringt nichts. Erhalte die selbe Fehlermeldung wie zuvor.
Sicher? Schau nochmal genau nach. Aus dem Fehler sollte eine Warnung 
werden. Aber wenn es danach zu einem Fehler kommt, sollte der eigentlich 
anders lauten.

Duke