hey leutz...... bräuchte mal ein wenig know how von euch, ich wäre euch dafür sehr dankbar. Die serielle datenübertragung erfordert auf der Empfängerseite die Rückgewinnung des Taktsignals aus den eingehenden Daten. (bevorzugendes Prinzip wäre die PLL) Welche Realisierungsprinzipien digitaler PLL's auf FPGA Bausteinen der Spartan3 Familie gibt es. Bräuchte man dafür eventuell spezielle Phasenvergleicher? Sollte man entweder ein Oszi benutzen, dass mit konstanter Spannung osziliert oder ein Oszi welcher mit konst. Frequenz osziliert? auch bei dem clock skew bin ich noch nicht dahinter gestiegen, ist es ein fester wert oder ändert er sich? wenn er sich ändert, woran liegt das?
was genau soll gemacht werden? ich habe es nicht richtig verstanden...
eine Phasenregelschleife soll mittels FPGA realisiert werden... zumindest wird es, so wie ich es gelesen habe so realisiert: PLL besteht extern aus einem VCO und einem Schleifenfilter. Intern hingegen ist ein Phasendetektor auf dem FPGA in Programmierbarer Logik (analoger Multiplizierer) vorhanden.
Moin... Spartan3 haben tatsächlich interne PLL, aber nicht als prog. Logik, sondern als feste Funktionsblöcke. Eine synthesefähige PLL in VHDL(-ams) ist mir noch nicht untergekommen, möchte ich auch mal stark anzweifeln das es soetwas gibt. Weder VCO noch analoge Multiplizierer lassen sich beschreiben! Oszillatoren sind eigentlich immer Frequenz- und Spannungsstabil (im Rahmen des technisch möglichen). Welche anderen kenst du? Skew ist die Verzögerung von Signalen die "eigentlich gleichzeitig" ankommen sollen. Der Clock Skew ist die messbare Verzögerung des Takts zwischen dem ersten FF das erreicht wird und dem letzten. Ist abhängig von der gewählten Technologie, der Komplexität des Designs, dem P&R Erfolg und wohl auch der Betriebstemperatur. Post P&R Simulation schafft Klarheit. -- SJ
Es gibt von Xilinx Application Notes zur asynchronen Takt- und Datenrückgewinnung, schau dich mal dort um. Eine externe PLL benötigst du nur, wenn das zurückgewonnene Taktsignal von Jitter befreit werden muss.
Was für eine Frequenz haben Deine Signale denn ? Bei niedrigeren Frequenzen kann man so eine Taktrückgewinnung auch in Logik machen. Gruss Axel
Hallo Axel Es soll für verschiedene Frequenzen untersucht werden @HolgerB Hast du eventuell den link zu diesem Xilinx Application Note, hab irgendwie das richtige noch nicht gefunden...wäre Dir sehr dankbar
Um welche serielle Datenübetragung handelt es sich denn? Asynchron (RS-232 o.ä.)? Da macht eine Taktrückgewinnung (für beliebige Frequenzen) wenig Sinn bzw. ist je nach Beschaffenheit der empfangenen Daten sogar unmöglich. Für RS-232 ist es einfacher und zuverlässiger, von einer festen Baudrate auszugehen, und die Phase (d.h. die Abtastzeitpunkte) für jedes empfangene Byte an Hand des Startbitflanke zu synchronisieren. Ähnliches gilt für CAN-Bus, nur dass dort die Nachrichten deutlich länger als 1 Byte sind, so dass die Abtastzeitpunkte mehrfach innerhalb der Nachricht synchronisiert werden müssen. Deswegen gibt's dort das Bit-Stuffing, um genügend Flanken bereitzustellen. Bei vielen anderen seriellen Übertragungsverfahren (SPI, I2C) wird der Takt sowieso mitgeliefert, so dass sich das Problem gar nicht stellt. yalu
"Es soll für verschiedene Frequenzen untersucht werden" Also etwas konkreter sollte es schon sein. Wenn Du z. B. eine interne Frequenz hast, die wesentlich höher als die externe ist, kannst Du das problemlos digital lösen. Andernfalls musst Du tricksen. Ich bin aber nicht sicher, ob die FPGA tools Dich einen Ringoszillator aufbauen lassen. Gruss Axel
Andreas, ohne die Appnotes jetzt nochmals im Detail angesehen zu haben sehen xapp224 und xapp250 recht brauchbar aus.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.