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
1
[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.
2
< PIN: fpp_clk_int_inverter.A6; >
3
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.
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
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
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
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
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
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.
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
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.
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
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
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
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.
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.
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
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.
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.
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.
clock_forwarding.png
(4,6 KB)
