clock forwarding, Spartan6

[Daniel M. (daniel__m)]

hi,

es geht um die Ausgabe eines Taktes mittels ODDR. Nachdem ich mein 
Design etwas umgestellt habe (Anzahl der Taktnetze konnten reduziert 
werden), funktioniert diese nicht mehr, obwohl an dem Bereich keine 
Änderungen statt fanden. Die Beschreibung ist gemäß "Language Templates" 
und die Synthese läuft durch (siehe Bild). Jedoch bricht der Mapper ab 
mit der Meldung

[Place 1136] This design contains a global buffer instance, <soc_i0/clock_generator_0/clock_generator_0/PLL0_CLKOUT2_BUFG_INST>, driving the net, <fpp_clk_int>, that is driving the following (first 30) non-clock load pins.
< PIN: fpp_clk_int_inverter.A6; >
This is not a recommended design practice in Spartan-6 due to limitations in the global routing that may cause excessive delay, skew or unroutable situations.  It is recommended to only use a BUFG resource to drive clock loads. If you wish to override this recommendation, you may use the CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote this message to a WARNING and allow your design to continue.
< PIN "soc_i0/clock_generator_0/clock_generator_0/PLL0_CLKOUT2_BUFG_INST.O" CLOCK_DEDICATED_ROUTE = FALSE; >

    oddr_clk                  <= fpp_clk_int;
    oddr_clk_n                <= not(fpp_clk_int);
    --
    u_fpp_clk_int_fddrcpe : ODDR2
        port map(
            d0 => '0',
            d1 => '1',
            c0 => oddr_clk,
            c1 => oddr_clk_n,
            ce => '1',
            s  => '0',
            r  => '0',
            q  => clk_out
            );

Den Inverter kann ich mit planAhead nicht finden. Dieser sollte (und 
bisher ging das auch) in das ODDR gezogen werden (interner Inverter, wie 
das Bild es zeigt).

Ich habe das Design in ISE importiert und dort sehe ich den Inverter.

Ich habe noch 2 weitere solcher Taskausgänge mit anderen Frequenzen. 
Diese sind identisch beschrieben und die Schematics sehen identisch aus 
(ISE sowie planAhead), werden aber nicht bemängelt.

weiß jemand Rat?

grüße

[Duke Scarring (Gast)]

Und Du bist sicher, das Dein "fpp_clk_int" aus einem BUFG kommt?
Die Xilinx-Software ist da lt. Fehlermeldung anderer Meinung.

Duke

[Daniel M. (daniel__m)]

hi,

bin ich.

Ich habe es im Clock-Module (im MicroBlaze) angegeben, in der Schematic 
wird er gezeigt, im FPGA Editor habe ich ihn auch gesehen und die erste 
Zeile der Fehlermeldung führt ihn auch auf. Er beschwert sich, dass ich 
mit einem Takt auf ein Signaleingang will.

Ich habe mal das Constraint hinzugefügt und dann im FPGA Editor gesehen, 
dass der Taktinverter bei diesem clock forwarding tatsächlich über eine 
LUT gemacht wird. Die Anderen nutzen den Inverter im OLOGIC, so wie es 
sein soll.

grüße

[Duke Scarring (Gast)]

Ich beschreib das bei mir so:

    phy_gtxclk_out_i0 : oddr2
        port map (
            Q  => PHY_GTXCLK,
            C0 => clk_125,            C1 => not( clk_125),
            CE => '1',
            D0 => '0',                D1 => '1',
            R  => '0',                S  => '0'
        );

Vielleicht hilft es auch bei Dir, das 'not' in die port map zu setzen.
Es könnte aber auch ein Problem bei den Syntheseeinstellungen sein. Ist 
'Add IO Buffer' aktiviert?

Duke

[Daniel M. (daniel__m)]

hi,

werde ich mal prüfen, jedoch habe ich an den Settings seit langem nichts 
mehr geändert.

Deine Beschreibung verursacht eine Warnung, daher gehe ich über ein 
extra Signal. Ansonsten ist sie identisch zu meiner.

hmmm

[Fisch (Gast)]

Hallo,

bist du dir denn sicher, dass der ODDR2 einen integrierten 
Clock-Inverter besitzt? Wenn ich mir das Primitive(Spartan6?) so 
angucke, sehe ich nichts davon. Und dann ist die Fehlermeldung mehr als 
gerechtfertigt. Kann es sein, dass bei den Fehlerfreien Taktausgängen 
automatisch der invertierte Taktausgang der DCM verwendet wird? Kannst 
du mal den kompletten Clock-Tree aufzeichnen? Dein Bild ist nur bedingt 
aussagekräftig, weil da das Technology-Mapping noch nicht stattgefunden 
hat.

Gruß,
Fisch

[Christian R. (supachris)]

Ob man das beim Spartan 6 mit dem IOB Inverter machen kann, müsste man 
erst mal im User Guide nachlesen. Der Spartan 3 hatte den. Was aber sein 
kann ist, dass die globalen Clock Leitungen in dem Chip Segment schon 
voll sind. Der Spartan 6 hat eine extrem eingeschränkte Clock-Struktur. 
Schau dir mal den Clocking User Guide an, da sind die Übersichtspläne 
drin, dann kannst du schauen, ob die Global Clock Leitungen überhaupt 
ausreichen.

[Daniel M. (daniel__m)]

hi,

gemäß dem FPGA Editor hat jeder OLOGIC interne clock-inverter (2x), 
diese kann ich im Editiermodus auch umstellen.

Wenn ich deswegen über eine DCM/PLL gehen müsste, dann müsste ich ja ein 
komplettes Taktnetzwerk (+ Buffer) dafür "opfern", was Resourcen- und 
Energieverschwendung wäre.

Im Bild ist der Normalfall dargestellt. Beide Takteingänge bekommen den 
gleichen Takt und einer wird intern invertiert.

grüße

[Klaus F. (kfalser)]

Daniel M. schrieb:
> hi,
>
> gemäß dem FPGA Editor hat jeder OLOGIC interne clock-inverter (2x),
> diese kann ich im Editiermodus auch umstellen.
>
> Wenn ich deswegen über eine DCM/PLL gehen müsste, dann müsste ich ja ein
> komplettes Taktnetzwerk (+ Buffer) dafür "opfern", was Resourcen- und
> Energieverschwendung wäre.
>
> Im Bild ist der Normalfall dargestellt. Beide Takteingänge bekommen den
> gleichen Takt und einer wird intern invertiert.
>
> grüße

Das Problem kommt von der Laufzeit im Inverter, sodass das invertierte 
CLK Signal verzögert ist.
Dadurch takten die DDR FF nicht mehr genau zu den Flanken des 
Eingangstakts und die Zeitpunkte liegen nicht mehr genau an 50%.

Nur mit DLL und gleichen Signalstrecken für Takt und invertiertem Takt 
erreicht man eine 50% Taktung.

[Duke Scarring (Gast)]

Klaus Falser schrieb:
> Dadurch takten die DDR FF nicht mehr genau zu den Flanken des
> Eingangstakts und die Zeitpunkte liegen nicht mehr genau an 50%.
Es kommt halt darauf an, wie gut das Signal sein muß.
Für meine Belange hat der lokale Inverter bisher immer gereicht.

Duke

[Daniel M. (daniel__m)]

hi,

Klaus Falser schrieb:
> Nur mit DLL und gleichen Signalstrecken für Takt und invertiertem Takt
> erreicht man eine 50% Taktung.

die 50% duty-cycle sind auch ohne DCM akkurat, da der nicht-invertierte 
Takt auch durch solch einen Block läuft. Der Inverter wird nicht 
umgangen, sondern ist neutral gestellt. Die Laufzeit ist identisch. Die 
Aussage von Xilinx hatte ich mir mal bestätigt, indem ich diverse Pfade 
durch sie STA analysieren lassen habe.

grüße

[Daniel M. (daniel__m)]

Hi,

Nachtrag: der Spartan kann es grundsätzlich (kein Routing- oder 
Resourcenproblem). Ich habe die Taktinvertierung in der Beschreibung mal 
weggelassen und sie dann per FPGA Editor aktiviert -> Hardware läuft.

Jetzt muss ich "nur" noch schauen, warum der mapper das nicht (mehr) 
selber kann, d.h., was ihn durcheinander bringt.

grüße

[Gustav (Gast)]

Kam hierbei noch was raus?

[Weltbester FPGA-Pongo (Gast)]

Der Spartan 6 kann das, hat aber keinen Clock-Inverter. Man bekommt also 
keine 50:50. Ist aber meist egal. Entscheidend ist, dass der PLL-Ausgang 
direkt auf den "n"-geht.

[J. S. (engineer)]

Weltbester FPGA-Pongo schrieb im Beitrag #4497983:
> Entscheidend ist, dass der PLL-Ausgang
> direkt auf den "n"-geht.
Wenn man das über einen BUFG tut, ergibt das aber durchaus ein sehr 
exaktes 50:50.

[daniel__m (Gast)]

Gustav schrieb:
> Kam hierbei noch was raus?

ähm, ja.

Da ich mehrere Clockforwardings benötige, habe ich mehrere ODDR2. Diese 
hängen seit dem Taktumbau am gleichen Taktnetz. Danach erschienen die 
Probleme. Ursache schien der einzige Set/Resets eines ODDR2. Als ich den 
Reset über die Dateneingänge nachbildete und ich den Reset entfernte, 
war alles wieder ok.

Solange die das eine ODDR2 an einem eigenem Taktnetz hing, ging es auch 
mit Reset.

grüße

[Christian R. (supachris)]

Ja, die S und R Eingänge können einem ordentlich das Timing versauen, 
hatte ich auch schon. Das CE ist auch sehr langsam...

[J. S. (engineer)]

Sprechen wir von realen Timing-Problemen oder von der Schwierigekeit, 
das Timing einzuhalten? Aus welcher Domain kommen die Set/Resets?

[Christian R. (supachris)]

Bei mir hat er das Timing nicht einhalten können, hatte das erst am 
Artix letztens. Clock Forwarding 125MHz und S/R aus der gleichen 
Taktdomäne hat nicht geklappt. Musste dann über die Dateneingänge gehen.

[daniel__m (Gast)]

Es ging damals nicht darum, dass das Timing nicht eingehalten wurde, 
sondern dass der Mapper den/die ODDR2 nicht plazieren wollte/konnte. 
Siehe ersten Post.

[J. S. (engineer)]

Ich verwende die Set/Resets an der Stelle eigentlich kaum, bei reinem 
Taktausgang gibt es eh nur die Option "Abschalten" oder "nicht" und dann 
kann man in der Tat den Dateneingang rausnehmen. Irgendwoher kommt ja 
die Information, wenn der Takt laufen soll. Wenn es aus einer anderen 
domain kommt, ist der CE sicher das Beste.