Ich bekomme per LVDS ein 60Mhz clock. bekomme aber beim syntetisiren volgende fehler meldung ------------------------------------------------------------------------ ERROR:Place:1018 - A clock IOB / clock component pair have been found that are not placed at an optimal clock IOB / clock site pair. The clock component <n3e> is placed at site <BUFGMUX_X2Y11>. The IO component <DCLK> is placed at site <N6>. This will not allow the use of the fast path between the IO and the Clock buffer. 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 "DCLK" CLOCK_DEDICATED_ROUTE = FALSE; > ------------------------------------------------------------------------ im Canstrain file habe ich alderdings einen CLK dekleriert (sihe anhang) kann das damit zu tun haben das der von mir ausgewehlte pinn ein LHCLK pin (LEFT HALF CLOCK) ist? Oder mach ich da was kommplet falsch?
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.
Christian R. schrieb: > Wenn man nachher > > erst damit anfängt geht man ziemlich sicher baden und/oder muss viele > > Krücken um den kleinen Fehler herumbasteln. Wie war! und wie oft kommt es vor, dass an fertigen Platinen die FPGAs nachgefrickelt werden müssen.
Ich danke euch für aure Hilfe Leider verwend ich als Entwicklungs umgebung Altium dort wird das UCF file jedes mal neu erstellt Das mit der sample tacktung würd ich interessiren wird das in einen der constreint files eingestellt? auf jeden dank viel danck für Euren rad! Ps.: ich hab mitlerweile die Deutschmatura (ABI)
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.
Habe gerade ein ähnliches Problem / eine gleichlautende Meldung. Wie gehe ich damit nun um: Habe ich bezüglich des Problems eine Disfunktion der Schaltung zu befürchten oder kann ich davon ausgehen, dass mein Design i.O. ist, sofern er die Timings schafft und hätte durch die suboptimale Verdrahtung nur ein Taktreserveproblem. ??
Jürgen S. schrieb: > Die DCM entkoppelt das. Du kannst die DCM auf SOURCE_SYNCHRONOUS stellen. Dann sollte sie als zero-delay-buffer arbeiten. Stephan H. schrieb: > Leider verwend ich als Entwicklungs umgebung Altium > dort wird das UCF file jedes mal neu erstellt M.E. konnte man früher dem Altium-Designer noch zusätzliche Constraints (in einer eigenen Syntax) mitgeben. Mich würde wundern, wenn das heute nicht mehr geht. Duke
Ich Danke vielmals um für alle radschläge Ich kann euch leider nicht sagen ob es geholfen hätte mein nanoboard fährt leider nicht mehr hoch Dennoch herzlichen Danke
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.
Die Dioden die anzeigen das er Strom hat leuchten. Die Dioden die anzeigt das er ready ist nicht. Und nach ca 24-36 stunden Fährt er wieder hoch ^^ Dann hab ich wieder einen versuch Ich werd mal das bord mit einen aus der Schule vertausen Altium benutzt das XILINX ISE. hat aber eigene Constraint diese wandelt es zu ein UCF file um. mit dem clk bin ich schon draufgekommen FPGA_NOCLOCK=TRUE wird dann zu NET "DCLK" CLOCK_DEDICATED_ROUTE = FALSE; übersetzt. Wie ich den Tackt beschleunige muss ich noch rausfinden. Ich nehme an "Bandwidth = High" wird ins UCF file eingetragen?
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.
Hat er nicht sowas wie eine Sample tackt? Ich Mus ja dann Daten mit 60mhz verarbeiten. Ich weis nur nicht ob er das so ohne definierten Clock einfach schafft. Prinzipiell ist mir sogar egal wenn hi und da ein Fehler ist Ist nehmlich nur EMPG.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.