Scrambling Takt erzeugen

[Hagen R. (hagen)]

Hi Experten,

ich habe hier ein EMV Problem und möchte meine Datenströme scramblen und 
dazu auch noch gleich die Datentakte ebenfalls im Spektrum spreizen. 
Dazu muß ich aus einer festen Taktbasis heraus arbeiten. Ich habe leider 
keine konkreten Ergebnisse bei meiner Suche gefunden und frage deshalb 
hier nach.

Meine ersten Ergebnisse habe ich mit LFSRs erzielt. Dazu habe ich ein 
LFSR (x^28+x^25+1) als Scramler betrieben. Mit zB. 60MHz lass ich das 
LFSR laufen. Aus den 60MHz erzeuge ich 30MHz und dieser "takt" dient als 
Input für den LFSR Scrambler. Während der steigenden und fallenden 
Flanke des 60Mhz Taktes lese ich 2 Taps dieses LFSRs aus und 
xor'verküpfe beide Signale um anschließend meinen Spreizspektrumtakt zu 
bekommen. Durchschnittlich läuft dieser Takt also mit 30MHz. Wählt man 
bei dem LFSR die richtigen zwei Taps aus so entsteht ein taktteiler im 
Verhältnis 4:1. Durch die Abfrage der Taps bei steigender und fallender 
Flanke habe ich also effektiv aus den 60Mhz einen 30Mhz 
Spreizspektrumtakt gewonnen.

Soweit so gut. Ich muß aber synchron zum 30Mhz Takt und dem 
Spreizspektrumtakt noch Daten verarbeiten, eg. über diese Taktgrenze 
synchron verarbeiten. Nun läuft aber der Spreizspektrumtakt in Relation 
zum 30Mhz Takt leicht davon. Er ist ca. maximal -8 bis +8 Takte daneben.

Im Bild sieht man den Takt C2 (30MHz), in Data0(7) den 
"Spreizspektrumtakt" erzeugt aus dem Scrambling-LFSR. StatX zeigt die 
Taktzyklen von C2 und Stat0-7 die sich ergebende Differenz an taktzyklen 
der Datentakte, zB. Stat0 -> Data0(7) zu C2.

Ich suche nun eine Lösung die besser ist.

Gruß Hagen

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hagen Re schrieb:
> läuft aber der Spreizspektrumtakt in Relation zum 30Mhz Takt leicht davon.
Läuft davon? Oder Jittert?

[Hagen R. (hagen)]

Hi Lothar,

er jittert. Ich kann aber bisher nicht mathematisch beweisen das er 
langfristig jittert oder langsam weglaufen wird. Dazu muß ich entweder 
meinen Aufbau mathematisch beweisen und durchrechnen oder ich gehe 
BruteForce vor und teste durch Simulation die komplette Periode des 
LFSRs durch. Bei 2^28-1 geht das ja noch.

Ich habe bisher folgende "Fakten":
- taktet man ein Scrambling-LFSR, sprich nimmt einen Takt als Input für 
diesen LFSR-Typ, dann ist die Anzahl der Flankenwechsel durchschnittlich 
exakt 25% zu den Flankenwechseln des Taktes
- ergo ergibt sich ein langfristiger maximaler Vor-/Nachlauf dieses 
Taktes zum Ausgangstakt von +-4 Takten.
- da ich mit doppeltem Takt das LFSR betreibe und zusätzlicvh noch auf 
fallende/steigende Flanke arbeite erzeuge ich also aus zb. 64MHz einen 
32MHz Spreizclock.
- mit bestimmten Taps und bestimmten Seed für dieses LFSR habe ich einen 
Nach/Vorlauf des Taktes von +-1 Basistakt
- möchte ich nun Daten auf diese Weise senden dann benötige ich also 
einen minimal 3-stufigen FIFO an dieser Taktgrenze

Ich möchte also folgendes erreichen:
- Spreiztakt aus 64MHz mit 32MHz Frequenz erzeugen
- ich muß möglichst billig (wenig Resourcen) 8 solcher Takte erzeugen 
die natürlich weitest möglich strickt orthogonal zueinander sind, ich 
möchte später vom einfachen LFSR Scrambler zu Gold-Codes wechseln um 
diese Orthogonalität zu gewährleisten ohne zu viele verschiedene 
Polynome nutzen zu müssen
- dieser Spreiztakt sollte höchstens +-2 Takte a 32MHz jittern
- er sollte aber nicht auf Pulsweitenmodulation basieren sondern 
wirklich spreizen. Oben im Bild sieht man das bei Data0(7). Die minimale 
ON/OFF-Zeit dieses Taktes beträgt immer noch 15.6ns (64MHz) aber 
durchschnittlich betrachtet ergibt sich ein 32MHz Takt. Ich möchte also 
maximale Spreizung innerhalb meiner gewählten Grenzen

Vielleicht gibt es da was viel Besseres und ich weiß nur nichts davon, 
deshalb frage ich hier.

Gruß Hagen

[Hagen R. (hagen)]

@Lothar:

im Bild oben:
- StatX Anzahl Taktwechsel C2
- Stat0 bis Stat7 ist der Jitter in den Spreiztakten Data0(7) bis 
Data7(7)
- dieser Jitter ist gerechnet in C2 Taktzyklen Versatz zu Spreizclock
- Data0(7) ist ein solcher Spreizclock

Gruß Hagen

[René D. (Firma: www.dossmatik.de) (dose)]

Hagen Re schrieb:
> @Lothar:
>
> im Bild oben:
> - StatX Anzahl Taktwechsel C2
> - Stat0 bis Stat7 ist der Jitter in den Spreiztakten Data0(7) bis
> Data7(7)
> - dieser Jitter ist gerechnet in C2 Taktzyklen Versatz zu Spreizclock
> - Data0(7) ist ein solcher Spreizclock
>
> Gruß Hagen


IN der Datenübertragung wird gerne der Manchestercode verwendet. Da kann 
der Takt im Empfängern zurückgewonnen werden. Die Daten müssen durch 
einen Fifo gehoben werden um die unterschiedlichen Frequenzen wieder 
einzusynchronisieren.

Schau dir mal eine LAN Phy an.

Jedem Datenpaket wird im Datenpaket eine Bitmuster als Preamble zur 
Synchronisation mitgesendet.

Theory in der Praxis mit einem gutem Aufbau:
http://www.holmea.demon.co.uk/Ethernet/EthernetRx.htm

[Hagen R. (hagen)]

Hi Rene,

danke für deinen Hinweis ich habe aber Manchestercodierung verworfen. 
Erstens geht es mir um die Erzeugung eines, deterministisch in Grenzen 
arbeitenden, Spreizspektrum-Taktes. Zweitens sind meine Daten schon 
ge-scrambled und das führt zu dem von mir gewünschten Rauschen. Drittens 
benötige ich keine Taktrückgewinnung da ich den Takt gespreizt mit 
übertragen muß. Das liegt einfach darin begründet das die nachfolgende 
Kette an Empfängern keine PLL oder ähnliches zur Taktrückgewinnung 
haben. Davon abgesehen soll der Spreiztakt der Daten auch später für 
weitere gespreizte PWM-Takte a 16MHz zur Verfügung stehen. Die 
Eigenschaften der gespreizten Datentakte korreliert also später mit den 
PWM Takten.

zZ. probiere ich einen Automaten der den Jitter der Taktzyklen zum 32Mhz 
Takt berechnet und abhängig davon den Spreizspektrumtakt teil-zufällig 
erzeugt. So stelle ich sicher, das diese Takte in engen Grenzen jittern 
zum Referenztakt, so das ich einen deterministischen FIFO Buffer für die 
Daten darauf aufsetzen kann.

Gruß Hagen

[Hagen R. (hagen)]

mit einem Automaten der die annähernde Synchronität zum Referenztakt 
aufrechterhält konnte ich soweit mein Problem lösen.

- clk der Basistakt
- clk2 = clk /2 der Referenztakt
- sclk sind 8 Spreiztakte
- err0 bis err7 ist der Zyklenfehler der sclk() Spreiztakte in Relation 
zum Referenztakt clk2, wie man sieht ist das System maximal +-2 takte im 
Verzug oder zu schnell
- ones und zeros sind die in sclk() kummulierten 1/0-Bits
- pulse ist die Differenz aus ones und zero und stellt damit die 
Gleichspannungsfreiheit der sclk() Takte dar.

Besonders pulse ist interessant da es in einem Bereich von ca. +-170 
schwankt und das mit einer Periode von ca. 200us. Die takte sind also 
langfristig gleichspannungsfrei, kurzfristig aber intermoduliert.

Ich denke noch darüber nach diese Gleichspannungsfreiheit ebenfalls in 
den Automaten einzubauen.

Gruß Hagen

[tsmiiii (Gast)]

Nur mal dumm gefragt:

der Empfänger bekommt also als einzige "Clock" die, wie auch immer 
geartet gescrambled-te?
Mit der soll er dann ohne zu Hilfenahme eines Referenztaktes und einer 
PLL wieder eine schöne saubere synchronisierte Clock bauen und die Daten 
recovern und dann schön synchron weitergeben mit einer 50:50 load clock?

Ich stell lieber ersteinmal paar dumme Fragen, bevor ich versuche das 
Problem anzugehen...

Ach ganz am Rande zur Gleichspannungsfreiheit von LFSR:
Ein LFSR liefert keinen gleichspannungsfreien Ausgang. Der 
Gleichspannungsanteil ist 1/2^(Länge der Periode des LFSR)

(Liegt einfach daran, dass ein LFSR den Zustand (others => '0') (wenn es 
mit XOR aufgebaut ist, bei XNOR (others => '1') nie annehmen darf.

[HR (Gast)]

>der Empfänger bekommt also als einzige "Clock" die, wie auch immer
>geartet gescrambled-te?

Korrekt.

>Mit der soll er dann ohne zu Hilfenahme eines Referenztaktes und einer
>PLL wieder eine schöne saubere synchronisierte Clock bauen und die Daten
>recovern und dann schön synchron weitergeben mit einer 50:50 load clock?

Garnicht, er arbeitet komplett mit diesem Takt. Die Daten sind auf 
Senderseite synchron zur steigenden/fallenden Flanke dieses Spreizclocks 
raus getaktet.

Ich habe das Problem übrigens schon gelösst, es geht alles wie es soll.

>Ach ganz am Rande zur Gleichspannungsfreiheit von LFSR:
>Ein LFSR liefert keinen gleichspannungsfreien Ausgang.

Korrekt.

>Der Gleichspannungsanteil ist 1/2^(Länge der Periode des LFSR)

Nicht ganz, ich benutze primitive Polynome für die LFSR mit maximaler 
Periode. Dann hat man eine 1 oder 0 mehr Datenstrom als 0'en oder 1'en. 
Eine 7 Bit MLS hat 127 Zustände und davon sind 64 Einsen und 63 Nullen. 
Also fast gleichspannungsfrei, ich invertiere die komplette sequenz 
periodisch für 127 Takte, also 127 Bit haben 63 Nullen + 64 Einsen, dann 
invertierte MLS hat 127 Bit davon 64 Nullen + 63 Einsen, ergibt 127 
Nullen + 127 Einsen, perfekte Gleichspannungsfreiheit ist sicher 
gestellt.


Gruß Hagen