Altera PLL-Reconfig Core

[Mampf F. (mampf)]

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

[Donni D. (Gast)]

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.

[C. A. Rotwang (Gast)]

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.

[Mampf F. (mampf)]

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!

[C. A. Rotwang (Gast)]

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.

[Mampf F. (mampf)]

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