Lefthalf Clock

Klar hängt das mit dem LHCLK zusammen. Die Logik, die du damit betreiben 
willst, ist offenbar nicht (komplett) im Einzugsbereich des Taktnetzes. 
Du musst dann den Takt an einen GCLK Eingang anschließen. Ansonsten 
gibts nur die Lösung mit dem CLOCK_DEDICATED_ROUTE, aber was das für 
Folgen hat, steht ja oben. Bei 60MHz sollte man das nicht mehr machen.

Ralf schrieb im Beitrag #3107444:
> Wenn du so programmierst wie du deutsch schreibst wundert mich
> gar nichts.

Wenn Du ihn schon erziehen willst, musst Du aber selber auch korrekt 
schreiben: "DU" als Anrede groß, in den Satz müssen 2 Kommata und "gar 
nichts" auseinander. 5 Fehler pro Satz macht leider eine 6! :-)

Christian R. schrieb:
> Bei 60MHz sollte man das nicht mehr machen
Was wäre denn Deiner Erfahrung nach die Grenze? Wenn er timingmäßig zu 
routen packt, müsste es doch gehen, wobei halt die Frage ist ob er es 
packt.

Bei geringen Frequenzen wie 60MHz kann man den Takt wie ein Signal 
behandeln und sampeln.

Jürgen S. schrieb:
> Was wäre denn Deiner Erfahrung nach die Grenze? Wenn er timingmäßig zu
> routen packt, müsste es doch gehen, wobei halt die Frage ist ob er es
> packt.

Naja, ich hatte sowas am Spartan 3e mal mit 80MHz gemacht. Das ging zwar 
hat aber trotz korrektem Routing und getroffener Constraints immer mal 
Timing-Fehler erzeugt (Glitched im Mess-Signal).

> Bei geringen Frequenzen wie 60MHz kann man den Takt wie ein Signal
> behandeln und sampeln.

Dann muss man das aber auch so machen und nicht als Takt behandeln. Man 
braucht dann halt noch einen viel höheren Sample-Takt.

Besser ist es aber beim Platinen-Design auf solche Dinge zu achten. 
Idealerweise macht man Platine und FPGA Design gleichzeitig um zum 
Zeitpunkt der Übergabe an den Platinenhersteller sicher zu sein, dass 
zumindest alle Clock und sonstigen Spezialpins passen. Wenn man nachher 
erst damit anfängt geht man ziemlich sicher baden und/oder muss viele 
Krücken um den kleinen Fehler herumbasteln.

Vielleicht kannst du von dem LHCLK Pin auf einen DCM gehen und von da 
über einen BUFG auf das globale Takt-Netzwerk. Das könnte dann klappen.

Christian R. schrieb:
> von dem LHCLK Pin auf einen DCM gehen
Ist aber auch nur eine Notlösung, weil der eigentliche Sinn des Taktes 
ja sicher ist, dass er vorgibt, wann die Daten passen, d.h. er "jitter" 
mit seinen Daten mit. Die DCM entkoppelt das.

Das sollte bei 60MHz aber weit weniger ins Gewicht fallen als den Clock 
über ein normales Routing-Netzwerk zu schicken und zu hoffen, dass er 
gleichzeitig an allen betreffenden Flipflops ankommt.

Duke Scarring schrieb:
> Jürgen S. schrieb:
>> Die DCM entkoppelt das.
> Du kannst die DCM auf SOURCE_SYNCHRONOUS stellen. Dann sollte sie als
> zero-delay-buffer arbeiten.
"source_synchronous" bedeutet ja nur, dass die Phase an der 
Eingangsphase orientiert wird, die glättende Wirkung der PLL als solcher 
bleibt ja bestehen, wodurch die Taktoffsetreserve insgesamt sinkt - 
jedenfalls, wenn es sich um eine richtige PLL handelt. Die Frage ist, 
wie stark es sich auswirkt. In jedem Fall sollte man das Regelverhalten 
auf "Fast" stellen - bei (Xilinx ist das "Bandwidth = High", bei Altium 
weiss ich es nicht) damit der Takt schneller folgt.


Stephan H. schrieb:
> alle ra*d*schläge
:-)

> mein nanoboard fährt leider nicht mehr hoch
elektrisch nicht oder funktionell nicht?
will sagen: FPGA defekt / board defekt, oder vielleicht nur das flash 
überschrieben?

>Altium
Was genau macht Altium im Entwicklungsprozess? Es muss ja 
Informations-Quellen und Randbedingungen geben, aus denen er das UCF 
erzeugt.

Ich würde das UCF einmal kopieren, umbennenen und in Xilinx als anders 
benanntes UCF eintragen. AM Besten die toolchain gleich ganz auftrennen, 
das macht IMHO nur Probleme.

Stephan H. schrieb:
> Wie ich den Tackt beschleunige muss ich noch rausfinden.
> Ich nehme an "Bandwidth = High" wird ins UCF file eingetragen?

Was willst du da beschleunigen? Wenn es kein Takt -Netz ist, dann ist 
es keins, sondern ein normales Logik-Netz.