Hallo! Hab mittlerweile ein großes Problem und hoffe mir kann geholfen werden. Ich habe das DevBoard mit dem Cyclone II als FPGA. Dieser ist mit einem DSP und diversen Peripherieplatinen (LWL In/Out, Sigma-Delta AD Wandler und Userplatine mit LED und Tastern). Soviel dazu. Mein Problem nun ist folgendes: Auf dem DevBoard ist ein 25MHz Quarz vorhanden, der den FPGA und den Cypress USB Adapter betreibt. Letzterer wird zur Kommunikation mit LabView verwendet. Also möchte ich einen Systemclock in Quartus mit 25MHz angeben. Dieses habe ich auf eine PLL gelgt, als Input-Pin. Da die Sigma-Delta-ADWandler mit max. 20MHz laufen, kommt es zu Timing Problemen. Somit geh ich mit den 25MHz auf einen altpll Block und gebe 12, 20 und 100 MHz raus. Da nun ein Problem entsteht, das viele andere Blöcke mit 25 MHz laufen und ich den Systemclock nicht verwenden kann, wollte ich den 100MHz Takt mit Hilfe von TFF-Blöcken 2-mal teilen (auf 25). Es wird aber alles nicht besser, eher schlimmer. Mit Hilfe des Timing-Advisers habe ich recht viel im Programm verfuscht...Schande über mich. Frage 1: Wie erzeuge ich einen Globalclock und welcher wäre das? Frage 2: Kann ich Clock's manuell löschen/festlegen? Quartus erkennt oft einfache normale Inputs als Clock. Frage 3: Auto Clock - ja, nein? Frage 4: Welcher Timing Analyser-Classic oder der "neue"? Was ich brauche: 1) Einen Clock den ich mit altpll auf 3 auspalte 2) Einen synchronen 25MHz Clock (zum erzeugten 100MHz Clock) um alle Blöcke zu betreiben 3) Evtl. allgemeine Hinweise/Links zu altpll, (Global-)Clock und Clocksynchronisation. Hoffe ich habe euch nicht ganz verwirrt, aber mir gehts mittlerweile von Tag zu Tag schlimmer ;) Danke im Voraus! Gruß, KaBi PS: Bin über jede Antwort dankbar!
KaBi schrieb: > Quartus erkennt oft einfache normale Inputs als Clock. Das liegt an deiner VHDL-(oder Verilog-)Beschreibung, nicht am Quartus. > 1) Einen Clock den ich mit altpll auf 3 auspalte Wozu brauchst du 3 Takte? > Frage 1: Wie erzeuge ich einen Globalclock und welcher wäre das? Sieh nach, an welchem Pin der Quarzoszillator angeschlossen ist. > Somit geh ich mit den 25MHz auf einen altpll Block und gebe 12, 20 und > 100 MHz raus. Da nun ein Problem entsteht, das viele andere Blöcke mit > 25 MHz laufen und ich den Systemclock nicht verwenden kann, wollte ich > den 100MHz Takt mit Hilfe von TFF-Blöcken 2-mal teilen (auf 25). Es wird > aber alles nicht besser, eher schlimmer. Ja, diese Takt-Verknoterei hört sich nicht gut an. Am einfachsten ist ein Design mit genau 1 Takt unter Kontrolle zu haben. Wenn die Takte aber in keiner (sinnvollen) Beziehung zu einander stehen (100MHz -- 12MHz) dann zerhagelt es dich garantiert(!!!) an den Übergängen zwischen diesen Taktdomänen.
@Lothar Miller Danke schonmal ;) Ich bekomme timing und/oder synchronisationsprobleme mit Labwiev wenn ich den Systemclock (25MHz Oszilator) vor dem altpll nehme. Also versuche ich die Sigma-Delta Blöcke mit 100 MHz zu betreiben (beste Labview Anzeigeergebnisse) und sie mit 25 Output-Clock auszugeben, da sonst HIER Timingprobleme mit dem Cypress-USB Block kommt (dieser arbeitet ja NUR mit 25 MHz). Desweiteren arbeiten die Sigma-Delta IC's mit einem vom FPGA geliferten Clock, der max. 20 MHz sein darf (daher erst das ganze gemausche....).Also brauche ich schonmal 100 MHz, 20 MHz und den 12 MHz hatte ich für einen Incrementalgeber, der da die besten Ergebnisse zeigte. Leider habe ich das ganze Prjekt nur übernommen und nicht selbst entworfen, sonst wäre das alles einfacher (Probleme ändern...). Nur wird langsam die Zeit knapp, da die Bachelorarbeit auch gern mal abgegeben werden möchte :D Aber gibt es die Möglichkeit den 100MHz Takt in einen 25MHz Takt zu zerlegen? Die TFF-Teile machen keinen "guten" Eindruck.... Beste Grüße, KaBi
KaBi schrieb: > Aber gibt es die Möglichkeit den 100MHz Takt in einen 25MHz Takt zu > zerlegen? Sowas macht man gern mit einem Clock Enable. Siehe Taktung FPGA/CPLD: Clock Enable
KaBi schrieb: > und den 12 MHz hatte ich für einen Incrementalgeber, der da die besten > Ergebnisse zeigte. Ist da eventuell 12.5 Mhz auch ok? Dann kann man das auch per Clock Enable von den 100 MHz ableiten und wärem beim Einclockdesign angekommen.
KaBi schrieb: > Frage 4: Welcher Timing Analyser-Classic oder der "neue"? Hi, nimm mal den Timequest. Dauert wirklich eine Weile sich einzuarbeiten. Lohnt sich aber.
So, bin jetzt wieder im Labor und versuch das mal mit dem Clock Enable und auch den 12,5 MHz. Zum Timequest. Da muss ich doch über den Wizzard die sdc-File erzeugen, richtig? Welche Clocks kommen da rein? Nur der System-Clock oder auch die erzeugten?
Warum kannst du die 25MHz nicht mehr verwenden? Du kannst sie doch auf die PLL und auf den Rest der Schaltung legen. Im Notfall gibt es Taktverstärker aus dem IP-Cores. Zur Frage 1: Normalerweise erkennt Quartus die Global Clock automatisch. Außer du hast natürlich die entpsprechende Einstellung bereits verstellt Frage 2 versteh ich leider so nicht. Kannst du sie etwas umformulieren? Mein Tipp bei Tming Problemen: Assignments->Settings->Fitter Settings Ganz oben unter Timing Driven compilation zwei Haken und im Flipmenu auf All-Paths stellen Untenhalb dann auf Standart Fit einstellen. Dann die besondere Fleißarbeit: More Settings (ganz unten) durcharbeiten
@ Stefan Der systemclock vor dem altpll ist der, der auf dem Board ist. Durch altpll entstehen laufzeiten, die meine Ausgangssignale nicht synchron zum systemclock machen. Sicher gibt es die möglichkeit eine compensation einzustellen, brachte aber bisher nicht den gewünschten erfolg. Außer ihr könnt mir jetzt sagen welche compensation ich nehmen kann ;) und warum ich dann einen channel aussuchen kann. Mit den Clocks ist das so: Im Timing Advisor kann ich mir eine Liste mit Global Clocks anzeigen. Die geht komischerweise auch nur manchmal. Dort sind aber auch Inputs vorhanden, die keine seien sollen (Bsp: AD1=erster Eingang vom Sigma-Delta Wandler). Dachte ich kann die Manuell so festlegen, das diese Signale nicht mehr als (evtl.) Clocks angesehen werden. Danke mal wieder! Gruß, KaBi
Das hört sich für mich so an, als wenn Du bisher ein durchaus komplexes FPGA-Design ohne Timing-Constraints zum Laufen bringen möchtest. Das dürfte Dein Problem sein. In einfach gelagerten Fällen kann so ein Constraining sehr kurz sein, wenn man beispielsweise nur einen Clock im System hat und alle halbwegs schnellen IOs in Ausgangs-/Eingangsregister festgenagelt hat. Darüber hinaus wird es schnell aufwändig, bei Mehrtaktsystemen will jeder Taktübergang überprüft und constraint werden und bei anspruchsvollen IOs kann das länglich werden. Im Grunde ist es so: Hast Du ein korrektes Constraining und die Timing Analyze sagt "OK", dann wird das Design auch funktionieren - zumindest vom Timing her. Nur der Weg zu einem vollständigen Constraining kann lang sein. Welche Signale Quartus auf globale (Takt-)Pfade routet, ist zwar interessant zu wissen, das beeinflussen zu wollen wird Dir aber nicht helfen. Das ist die falsche Baustelle, Deine Baustelle sind die Timing Vorgaben. Bei Altera können übrigens auch normale, schnelle Signale als globale (Clock-)Signale geroutet werden. Im Gegensatz zu Xilinx bringt das keine Nachteile mit sich, deshalb macht Quartus das ab und zu.
Ohne dein Design gesehen zu habe, würde ich das Problem ganz anders angehen: -Hardwarepipelining -Zwei Ausgangsregister in Reihe geschaltet auf Systemtakt -Im Cyclone 2 Handbuch auch unbedingt mal den Teil I/O genau durchlesen Ich habe hier zwar den größten und schnellsten Cyclone 2, aber von den Taktraten die Altera verspricht, bin ich noch weit entfernt. Ich denke, dass die nur von Profis mit vielen Jahren Erfahrung erreicht werden können
Hier mal 2 Screenshots, wenns dem Verständis beiträgt. Gruß, KaBi
Der Taktteiler gefällt mir überhaupt nicht, da darüber der Takt den du dort generierst auf Datenleitungen im Chip verteilt wird. Der FPGA hat aber spezielle Taktleitungen, die man unbedingt nutzen sollte. Selbst der kleinste Cyclone 2 hat doch 2 PLLs.
Stefan R. schrieb: > Der Taktteiler gefällt mir überhaupt nicht, da darüber der Takt den du > dort generierst auf Datenleitungen im Chip verteilt wird. Der FPGA hat > aber spezielle Taktleitungen, die man unbedingt nutzen sollte. Jein... Quartus kann automatisch auch "normale" Signale über globale (Takt-)Leitungen verteilen. Das macht er auch immer dann, wenn er sieht, dass es ein High-Fanout Signal ist. Das ist unabhängig von der Signalquelle. Zum Beispiel ein globales Resetsignal, was FPGA-intern erzeugt wird, wirst Du unter Umständen auf einer globalen (Takt-)Leitung wiederfinden. Quartus erkennt: High-Fanout, also promote ich das über eine globale Signalleitung. Umgekehrt kann auch ein lokales Taktsignal über normale Routingresourcen verteilt werden, wenn es eben nur lokal benötigt wird. Der Jitter mag dann etwas größer sein, aber: Solange das Design anständig constrained ist und die Analyse OK sagt, ist das kein Problem. Korrekt ist natürlich, dass ein Taktsignal auf normalen Routingresourcen einen Jitter und Skew hat und so das Syntheseergebnis schlechter ausfallen wird, als wenn in der gleichen Situation das globale Netz verwendet wird. Das Problem an dem Taktteiler ist eher, dass das geteilte Signal jetzt einen Phasenversatz gegenüber dem ursprünglichen Takt hat. Die Flanken haben also keinen festen Bezug mehr zueinander. Das macht den Übergang von einer Taktebene zu einer anderen unnötig schwierig. Nutze ich eine PLL zur Erzeugung beider Takte, dann kann ich mich darauf verlassen, dass die Flanken zueinander entsprechend synchron sind und die Timing-Analyse diese Übergänge abprüfen kann. Im anderen Fall müsste man die Übergänge als asynchron betrachten, mit allen Folgen. Xilinx ist übrigens eine andere Welt, da muss man sich in der Tat selber darum kümmern, wie welche Taktsignale verteilt werden.
So, ich glaube ich habe eine Lösung gefunden. Diese hatte ich schonmal, eigentlich logisch, aber damals hatte die nicht gut funktioniert. Jetzt gehts ;) Den Sys-Clock habe ich an alle Blöcke gehangen. Am altpll kommt jetzt nur noch 12, 100 und 20 MHz raus. Das Problem mit dem Taktteiler war/ist, dass der nur gerade Takte brechen kann, bei ungraden kommt es zu Phasenverschiebung. Die letzten Timingfehler konnte ich mit der internen Phasenverschiebung im altpll beseitigen. Die Sigma-Delta Wandler werden nun auch wieder mit 20 MHz betrieben und geben halt nur das 25MHz Signal aus. Wegen der zusätzlichen PLL-Idee: Hatte ich auch, nur kam es dort zwischen den beiden altpll Blöcken wiederum zu verzögerungen, deswegen hatte ich das verworfen. Somit scheint doch eine Lösung für mein Problem gefunden zu sein und möchte mich nochmals für die schnellen und hilfreichen Antworten bedanken :) Gruß, KaBi
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.