Spartan 6, BUFGMUX

[T. F. (sar)]

Hallo,

In einem Design habe ich zwei Eingänge für ein Taktsignal. CLKIN1 wird 
analog aufbereitet (Verstärker, Pegeanpassung) und der zweite Eingang, 
CLKIN2, ist nur mittel Schmitt-Trigger angebunden. Beide Eingänge gehen 
auf GCLK Pins am Spartan 6 (GCLK20 und GCLK22).

Ich wollte jetzt mittels BUFGMUX einen der beiden Auswähöen und einer 
DCM zuführen. Während der Map-Phase bekomme ich allerdings folgenden 
Fehler angezeigt:

 A clock IOB / BUFGMUX clock component pair have been found
   that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
   IOB component <CLKIN2> is placed at site <P14>. The corresponding BUFG
   component <XLXI_87/BUFGMUX_inst1> is placed at site <BUFGMUX_X3Y14>. There is
   only a select set of IOBs that can use the fast path to the Clocker buffer,
   and they are not being used. 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 "TTL_IN" CLOCK_DEDICATED_ROUTE = FALSE; >

Nachdem ich mir die Struktur des Taktnetzes in UG382 angesehen habe, 
scheint es jetzt so zu sein, dass ich nicht zwsichen den beiden Takten 
auswählen kann. Das wurde beim Design nicht beachtet.

Gibt es trotzdem eine Möglichkeit einer sauberen Umschaltung zwischen 
den beiden Clocks?

Danke

[Klakx (Gast)]

T. F. schrieb:
> 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.

steht in der Message mit drin. Setz das CLOCK_DEDICATED_ROUTE constraint 
und der Takt wird über die Standard-Routing Ressourcen dort rangeroutet, 
anstatt sauber über das dedizierte Taktnetzwerk.

Der Nachteil ist nur, dass du mehr Skew auf den Takt bekommst und etwas 
mehr Jitter. In der Regel nur kritisch, wenn man schnelle Daten dazu 
synchron noch einsampeln möchte.

[T. F. (sar)]

ja das habe ich gelesen und würde ich gerne vermeiden.
Es scheint zu gehen wenn ich beide Eingänge zuerst auf eine DCM führe 
und dann per BUFGMUX auswähle. Braucht allerdings 2 DCMs.

[SeriousSam (Gast)]

Eine andere Möglichkeit könnten 2 weitere (I)BUFG vor einem/dem BUFGMUX 
sein, wenn die nicht sonst schon verwendet werden.

[Valko Z. (hydravliska)]

Hi

schaue dir UG382 an. Vor mir habe ich die Version 1.9 offen.

Tabellen 1-1 und 1-2 sowie Figure 1-3 und 1-4 erläutern wie die 
Taktnetzwerk aufgebaut ist.

Was dir vielleicht hilft ist ein BUFIO2. Die BUFGMUX Eingänge sind 
dediziert aber über ein BUFIO2 könntest du indirekt auch andere Quelle 
für dein MUX anschliessen.


Gruss

[Jürgen S. (engineer)]

Das ist ein typisches Spartan 6 Problem und hängt mit den begrenzten 
Resourcen zusammen. Leider ist zumindest ISE auch gerne mal in Stimmung, 
eigentlich routbare Designs nicht hinzubekommen. Da hilft nur manuelles 
Platzieren, also ein LOC-contraint auf die buffer selbst.

Zum Multiplexen der Takte mit BUFGMUX ist zu sagen, dass da eben nicht 
jeder mit jedem geht. Unter Umständen hilft es, über IBUF zunächst auf 
einen BUFG zu gehen und dann in den MUX, vor allem, wenn an den Takten 
noch was dran hängt. Ich habe da regelmäßig Probleme mit einem 
Reset-Generator, der selber anläuft: In einem design braucht er diesen 
BUFG in einem anderen will er genau das nicht akzeptieren, je nachdem 
was dranhängt. Gleiche Platine, minimale Änderung des Taktroutings.

Wenn es gar nicht geht, müssen beide Takte isoliert auf eine PLL und 
dann auf den MUX.