XILINX Numerically Controlled Oscillator

[olpo (Gast)]

Hallo,

ich suche für mein Xilinx-Projekt einen vorgefertigten Core, werde aber 
nicht fündig.
Ich glaube die Dinger heißen Numeric Controlled Oscillator oder 
Digitally Controlled Oscillator.

Also, es soll eine Clock sein, die zur Kontrolle einen Zähler hat. Und 
ab und zu bekommt sie von außen einen Zahlenwert übergeben, anhand 
dessen sich die Clock synchronisiert.

So ganz genau weiß ich auch nicht, wie das funktionieren soll. Es geht 
um die PCRs im MPEG-TS.

Danke

[olpo (Gast)]

Keiner?

Also, die PCR ist nur ein Zahlenwert, der von einer 27MHz clock 
generiert wird. Ich habe auf meiner Seite selbst eine 27MHz clk laufen 
und zähle selber einen Wert (counter) hoch.
Zum synchronisieren der beiden Clocks, muss ich regelmäßig rechnen: 
delta = counter - PCR.
Nur, was mache ich jetzt mit dem Delta-Wert? Wie synchronisiere ich 
damit meine Clock?
Coregen und EDK bieten zwar eine Menge Sachen (edk: clk-generator; 
coregen: DCM & PLL), aber richtig verstehen tu ich die einzelnen Cores 
nicht.

[Duke Scarring (Gast)]

olpo schrieb:
> Nur, was mache ich jetzt mit dem Delta-Wert? Wie synchronisiere ich
> damit meine Clock?
Du baust Dir keinen Takt sondern clock_enables.
Die läßt Du dann je nach Delta mal häufiger oder mal weniger häufig 
kommen. So das Dein Delta zu null wird.

> Coregen und EDK bieten zwar eine Menge Sachen (edk: clk-generator;
> coregen: DCM & PLL), aber richtig verstehen tu ich die einzelnen Cores
> nicht.
Weil die nicht primär für Videosachen und MPEG gemacht wurden.
Prinzipiell decken die Cores nur recht allgemeine Sachen ab.
Du kannst die Cores nur dann sinnvoll nutzen, wenn
1. Du weißt was Du willst und
2. Du weißt was die können und
3. 1. und 2. haargenau zusammenpassen.

Für kleine Modifikationen hilft Dir evtl. noch ein Wrapper, sonst bleibt 
nur selber schreiben, oder jemanden damit zu beauftragen.

Duke

[BiBi (Gast)]

Die Funktion ist als Teil in dem DDS-Compiler integriert.

[Georg A. (georga)]

> So das Dein Delta zu null wird.

Was impliziert, dass es sich hier nicht nur um einen reinen 
Phasenakkumulator, sondern um eine Regelschleife handelt. D.h. die 
Differenz aus dem PCR und dem eigenen Zähler muss irgendwie in das 
Increment des Zählers zurückgeführt werden. Für das "Irgendwie" gibt es 
je nach Anwendung beliebig komplizierte Methoden (aka Regelungstechnik, 
Stichwort PID-Regler). Meistens reicht es aber aus, die Differenz mit 
einem Faktor <<1 zu Multiplizieren und dann auf das Inkrement zu 
addieren. Wenn es genauer sein soll, kann man die Differenzen noch mit 
einem Faktor akkumulieren und den Wert aufs Inkrement geben.

Der Rest ist eigentlich ganz einfach. Der Phasenakku besteht aus n+m 
Bits und ist wirklich nur ein langweiliger Akkumulator ohne Tricks, also 
a=a+i.
n ist Anzahl der Bits, die du für deinen Vergleich der Timestamps 
brauchst, MPEG war AFAIR 27bit oder so. m ist der Anteil "hinterm" 
Komma, der es erlaubt, mit Bruchteilen der eigentlichen Zählerauflösung 
zu rechnen. Also nur getarnte Fixkommarechnung... Wieviele Bits da man 
braucht, hängt davon ab, wie genau man tracken will.

Insgesamt kommt dann folgender Pseudo-Algorithmus raus:

i(n+m-1 downto m)=1;
i(m-1 downto 0)=0;

Jeden 90kHz-Takt {
  a=a+i;
  mein_aktueller_pcr=a(n+m-1 downto m);
  if (neuer externer_pcr vorhanden) {
    diff=mein_aktueller_pcr-externer_pcr;
    i=i+diff*faktor;
  }
}

Bitbreiten und Vorzeichen bitte nach Bedarf reparieren ;)

Das Problem an dieser simplen Methode ist nur, dass der Faktor von der 
Häufigkeit der externen Referenzen abhängt. Ändert sich das zu stark, 
kann es sein, dass die Regelung nie hinterherkommt oder ins Schwingen 
gerät.

Allerdings stolpern da auch "Grosse" drüber, habe schon genügend 
Settop-Boxen gesehen, deren Ton unter ungünstigen Bedingungen anfängt, 
zu jaulen. Fängt sich dann auch nur manchmal wieder :)

[Hannes (Gast)]

Liegt oft auch an der ungünstigen Vorkompression des Materials.