Guten Abend, hat zufällig jemand einen kleinen funktionierenden Schnippsel Source-Code, um den PLL-Reconfig Core zu nutzen? Ich hab PDFs zu dem Core gefunden, aber es fehlt so das wichtige darin ... Beispielsweise, wie man die optimalen Settings für die einzelnen Register für eine bestimmte Frequenz ermittelt. In einem Forum hatte ich gesehen, hatte jemand eine dreifach-geschachtelte Brute-Force-Schleife gepostet, mit der man alle Settings ausprobiert und dann abbricht, sobald die Formel die richtige Taktfrequenz errechnet hat. Soll man das so machen? Viele Grüße, Mampf
Ich würde eine PLL mit den gewünschten Parametern erstellen und ein MIF generieren lassen. Das für alle gewünschten Einstellungen und alles in einem großen MIF zusammenfassen. Beim PLL Recomfig Core dann MIF Streaming aktivieren und die Einstellungen aus einem ROM lesen.
Mampf F. schrieb: > Ich hab PDFs zu dem Core gefunden, aber es fehlt so das wichtige darin > ... Beispielsweise, wie man die optimalen Settings für die einzelnen > Register für eine bestimmte Frequenz ermittelt. Ich seh nicht ganz das Problem, respektive eine Definition von "optimal". Also Verhältnis zwischen fin und fout bestimmen, dann beginnend mit dem kleinsten PLL-Teiler Nenner passenden Zähler bestimmen -> fertig?! Bei xilinx gabs irgendwo einen Hinweis ob besser kleiner oder grosser Zähler, das bestimmte wohl die Zeit bis zum Lock -> wenn das wichtig ist. Ansonsten würd ich eher auf Parameter setzen die zu geringen internen Frequenzen führen, als kleine Zähler. Oder in Hinblick auf EMV auf einen Wert mit grössten "spektralen Budget" also wo kein anderer Oszillator Harmonische hat. Am besten man bereitet für die EMV eh mehrerer Parametersätze respektive FPGA's vor und schaut mit einer Messung, ob das üerhaupt einen nennenswerten Einfluß hat Bei mehreren erzeugtenfout hat man (bei Altera) zuweilen das problem das wegen gemeinsamer resourcen es einschränkungen bezüglich der möglichen Kombinationen v. Ausgangsfrequenz hat. Das kann man umgehen wenn man nicht alle F-outs mit einer PLL erzeugt, sondern alle PLL auf den Chip benutzt. Was nun optimaler ist - eher viel oder wenig PLL's kann ich so nicht sagen, Ich tendiere eher zu mehr also Extra-PLLs für kritische Schnittstellen wie DDR-mem, weil es da etliche Signal gibt die man auf die richtige Phase schieben muß. Vielleicht hilft es, alle Anforderungen an das Taktsystem schriftlich fixieren, dazu eine Auflistung der Einstelloptionen, das Optimum ausdrücklich formulieren und daraus ein paar Kombinies abzuleiten, die man mal durch die Synthese laufen lässt und schaut was rauskommt. Dabei klärt sich dann schnell, was man mit dem Taktsystem uberhaupt will (weniger Energieverbrauch, fein granulares Phase-Shift) als zum "Optimum erklärt" und wie gut es sich erreichen lässt.
C. A. Rotwang schrieb: > Vielleicht hilft es, alle Anforderungen an das Taktsystem schriftlich > fixieren, dazu eine Auflistung der Einstelloptionen, das Optimum > ausdrücklich formulieren und daraus ein paar Kombinies abzuleiten, die > man mal durch die Synthese laufen lässt und schaut was rauskommt. Dabei > klärt sich dann schnell, was man mit dem Taktsystem uberhaupt will > (weniger Energieverbrauch, fein granulares Phase-Shift) als zum "Optimum > erklärt" und wie gut es sich erreichen lässt. Vermutlich ist meine Anwendung trivial ... Sorry dafür :-) Ich hab einen Rechen-Core, der mit einer eigenen PLL läuft und ich würde, falls möglich, die Taktfrequenz für den Core einfach nur in 1MHz Schritten verringern oder erhöhen wollen. Das ist nur bisserl Fine-Tuning, da der Core übertaktet ist und ich so gerne die Varianz der FPGAs kompensieren wollen würde. Beispielsweise erzeugen manche bei 50MHz mehr als das Synthese-Tool angibt (das sind 25% mehr) mehr (erstaunlich, dass das überhaupt geht) bei 10000 Rechnungen 10 Fehler. Es gibt aber FPGAs, die erzeugen 500 Fehler, obwohl ansonsten alles gleich ist. Die würde ich dann gerne etwas per Software nach-tunen. Daher würde ich auch kein ROM oder mif-Streaming benutzen wollen. Aber was du geschrieben hast ist sehr interessant ... Das PLL-Konfig-Tool gibt eher hohe Werte für n und für die anderen beiden Parameter eher niedrigere Werte. Das kann man zur Bestimmung der Parameter gut nutzen. Vielen Dank!
:
Bearbeitet durch User
Mampf F. schrieb: > Ich hab einen Rechen-Core, der mit einer eigenen PLL läuft und ich > würde, falls möglich, die Taktfrequenz für den Core einfach nur in 1MHz > Schritten verringern oder erhöhen wollen. > > Das ist nur bisserl Fine-Tuning, da der Core übertaktet ist und ich so > gerne die Varianz der FPGAs kompensieren wollen würde. So wie das "Turbo Boost" von intel ? Also je nach Core-temperatur rauf- un t runter takten? https://de.wikipedia.org/wiki/Intel_Turbo_Boost Klingt interessant. Wobei 1MHz IMHO viel zu granular sind, intel schaltet wohl gleich um 200MHz rauf und runter. Der Takt geht wohl quadratisch in die Leistungsaufnahme ein, da bringt etwas weniger kaum etwas. Und dann dauert es noch bis sich das Die abkühlt. Statt die PLL nachzujustieren, könnte man auch 5 verschiedenen Takte (jeweils im Abstand von 10%) an den Ausgängen erzeugen und per Clockmultiplexer umschalten - das spart dann auch die Wartezeit bis die PLL wieder eingerastet ist. >Beispielsweise erzeugen manche bei 50MHz mehr als das Synthese-Tool >angibt (das sind 25% mehr) mehr (erstaunlich, dass das überhaupt geht) Schau dir mal an, wie F_Max bestimmt wird, da werden Worst-Case szenarion (Multi Corner Cases - http://billauer.co.il/blog/2018/05/intel-fpga-timing-closure-path-report/) durchgerechnet, also Temperatur am oberen Anschlag und Corespannung am unteren. Man kann die STA auch so starten, das nur auf Best case szenarien gerechnet wird. Wenn man diese Szenarien mit der richtigen Kühlung und der richtigen Stromversorgung gewährleistet, passen auch die übertakteten Werte. Und manchmal werden Dies mit einem schnelleren speedgrad als FPGA's mit langsamen Speedgrad verkauft. Der Speedgrad wird grösstenteils durch Selektion erreicht, weniger durch Produktionstricks.
C. A. Rotwang schrieb: > Und manchmal werden Dies mit einem schnelleren speedgrad als FPGA's mit > langsamen Speedgrad verkauft. Der Speedgrad wird grösstenteils durch > Selektion erreicht, weniger durch Produktionstricks. Hmm ja, aber da gibt es dann immer noch Varianz in der Produktion. Sie haben ja nur ein paar Bins. Es geht weniger darum, Energie zu sparen oder bei Überhitzung runterzutakten. Die FPGAs sind aktiv gut gekühlt und bleiben handwarm. Aber es gibt halt bessere und schlechtere FPGAs und die schlechteren würde ich dann gerne so weit runtertakten, bis sie aufhören sooo viele Fehler zu produzieren :)
Bitte 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.