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
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
