mikrocontroller.net

Forum: FPGA, VHDL & Co. Clock-Probleme mit Quartus 10 Web und Cyclone II


Autor: KaBi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: KaBi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KaBi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, werd ich morgen direkt ausprobieren ;)

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grace Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: KaBi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KaBi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Florian V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KaBi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal 2 Screenshots, wenns dem Verständis beiträgt.

Gruß,

KaBi

Autor: Stefan R. (stefripp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: KaBi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.