Ich arbeite an einem DCO. Die Verzögerungsleitung implementiere ich mit LUT-Zellen auf einem FPGA. Ich verwende LUT1-Elemente als Inverter und überspringe pro Schritt zwei Inverter. Danach nutze ich vier weitere LUTs als Buffer und gehe pro Schritt um einen Buffer weiter, um eine feinere Verzögerungsauflösung zu erreichen.
Wenn sich jedoch das Steuersignal ändert, bekomme ich Glitches am Ausgang. Wie kann ich diese Glitches kompensieren oder vermeiden? Bei kleinen Perioden treten keine Probleme auf, aber im mittleren Periodenbereich schon, und die Signalform wird verzerrt.
Die Verzögerungsleitung implementiere ich mit
LUT-Zellen auf einem FPGA. Ich verwende LUT1-Elemente als Inverter und
überspringe pro Schritt zwei Inverter. Danach nutze ich vier weitere
LUTs als Buffer und gehe pro Schritt um einen Buffer weiter, um eine
feinere Verzögerungsauflösung zu erreichen.
1.) Axo, dieee Verzoegerungsleitung. Das zentrale Bauteil jedes DCO...
2.) Vielleicht mehr Bilder und weniger Prosa?
Da ist ein DCO im FPGA von Lattice beschrieben. Wie gesagt vor allem ein Addierer, der hier Phase accumulator heißt. Und da der im Prinzip eine Treppenspannung liefert, muss dahinter noch eine Sinustabelle (LUT = look-up table) folgen. Die hat aber nichts mit FPGA-lookup-tables zu tun.
Ja, ich möchte LUT1 als Inverter verwenden und sie miteinander verbinden, sodass eine Oszillation entsteht. Mit einem MUX kann ich verschiedene Knoten auswählen, wodurch sich die Periodendauer ändert.
Aber beim Umschalten der Knotenpunkte treten Verzerrungen auf. Wie kann ich diese beseitigen? Ich habe auch ein Bild hinzugefügt
Au weia. Na, hoffentlich hast du gute Gruende, dir so ein Minenfelddesign ans Bein zu binden.
Vielleicht rippelt es sich zurecht, wenn du als Ausgang des Desasteroszillators nicht das 1. Delayelement nimmst, sondern das letzte.
Ich arbeite an einem DCO. Die Verzögerungsleitung implementiere ich mit
LUT-Zellen auf einem FPGA.
Das kann in einem ASIC OK sein so zu bauen, wo du die volle Kontrolle über die Platzierung der Inverter und der Leitungen hast.
Kann man prinzipiell auch in einem FPGA machen ist aber wirklich mühsam. Stelle dich darauf ein, alle eine LUT1 Elemente mit passenden Constraints an bestimmte Stellen im FPGA zu plazieren und stelle dich darauf ein, dass trotzdem nach jeder Designänderung deine Verzögerungsleitungen andere Verzögerungen haben.
Simulieren geht auch nur als post-layout Simulation, bringe als Geduld mit für die Simulation.
Und sowohl im FPGA wie im ASIC ist das ganze Temperatur und Versorgungsspannungsabhängig.
Ja, ich möchte LUT1 als Inverter verwenden und sie miteinander
verbinden, sodass eine Oszillation entsteht. Mit einem MUX kann ich
verschiedene Knoten auswählen, wodurch sich die Periodendauer ändert.
Aber beim Umschalten der Knotenpunkte treten Verzerrungen auf. Wie kann
ich diese beseitigen? Ich habe auch ein Bild hinzugefügt
Solche "Umschalt Glitches" sind bei dieser Toplogie völlig normal, ja inherent im Design. Insbesondere wenn Du die Kette länger machst, sind nämlich in den Delay-Zellen, die eigentlich die tiefe Frequenzen bewirken sollen noch die Historie von den hohen Frequenzen enthalten was dann erstmal rückkoppelt. Wenn du Pech hast bleibt der DCO beim Umschalten sogar einfach auf der alten Frequenz stehen. (Nämlich wenn Du die Kettenlänge exakt verdoppelst).
Der Ansatz taugt nicht für einen kontinuierlich im Betrieb veränderbaren DCO. Im FPGA (und woanders auch) macht man das normalerweise per Addierer
Irgendwie kam der Zweck der Verzoegerungsleitung nicht duch. Bei einem FPGA geht es um ein synchrones Design. Da sollte man ohne solche Laufzeit Optimierungen durchkommen.
Ja, das carry bestimmt die hoechst moegliche Frequenz. Ein DDS addiert phasen inkremente. Mit phasenraeumen bis 48 bit. Fuer hoehere Geschwindigkeiten des Taktes verwendet man einfach schnellere FPGA.
Was soll's denn werden ? Wie schnell ?
Resp welche Frequenzen.
Ich verstehe auch nicht, wie man so ein unpräzises Verfahren wie die Laufzeit eines Gatters als Zeitreferenz verwenden kann, wo es doch wesentlich genaueres gibt.
Was ist "das Steuersignal"? - Das zu transportierende Datum oder der händische MUX zum Umschalten der Delays?
Ich nehme an, Letzteres.
Lösung: der Umschalter muss auf das Signal und das kritische Delay hin synchronisiert werden. Eine mögliche Lösung dafür habe ich 2009 erarbeitet und steckt gut verpackt in einem Patent der Siemens AG und hier drinnen:
http://96khz.org/oldpages/frequencyshifter.htm
Wenn du das nicht machst, kommst du um zufällige Ausgangszustände nicht herum, wenngleich die noch keine glitches produzieren müssen. Die in meinem Rauschgenerator verwendete Technik ist die gleiche, dort schalten die MUX gezielt unkontrolliert um und damit völlig nichtdeterministisch. Es ergeben sich aber lediglich veränderliche Frequenzen / Perioden der jeweiligen Schaltdauer und keine glitches.
Digitaler Rauschgenerator im FPGA
Ein erster Schritt wäre, die Delay-Zellen parallel aufzubauen, statt seriell und damit jeweils stabile Signale umzuschalten, da nur ein MUX in der Kette beteiligt ist.
Mir erschließt sich daber die Notwendigkeit insgesamt nicht, das so zu lösen. Da geht mit einer halb analogen Lösung unter Nutzung eines Komparators erheblich einfacher:
http://96khz.org/htm/resampler4496.htm
Solche Gattergeschchten sind sicher nicht als reproduzierbar zu betrachten. Also eine neue Serie Chips, eine neue Software, und die Zeiten werden anders sein.
Ja. Das ist nicht reproduzierbar. Ich habe schon jemanden
glorreich untergehen gesehen, zu Zeiten, als das XC3020 das
obergeilste war. Der hat seine Schaltung echt direkt in den
Chipeditor XACT eingehackt, also transmission gate für t.g.,
CLB-Gleichungen und location locks. Wir sind ja soooviel
schneller als wenn man das von Orcad aus übersetzt!
Auf der Systems stand dann ein grosses Reservoir an Kältespray-
Dosen als Bückware im Stand und vor jeder Vorführung musste
eine halbe Dose dran glauben. Ich hab' versehentlich gesagt,
dass Kältespray eigentlich nur Treibgas ist. Das gab richtig
Krawall weil wir damals gerade am Ozonloch gestorben sind.
Bei der nächsten Chiplieferung oder gar dem nächsten feature
size shrink geht dann natürlich garnix mehr.
Es ist auch ein verbreitetes Vorurteil, dass die seriellen
Bits aus einem Schieberegister-Generator unabhängig
voneinander sind. In Wirklichkeit sind sie für die meisten
Bitpositionen einfach nur das alte Bit vom Nachbarn, um 1
weitergeschoben. Die paar XORs ändern da recht wenig.
Man muss sich nur mal so ein typisches Polynom ansehen.
Die ganzen SRegisterinhalte als integer genommen sind meist
ganz ok zufällig, aber für math. starke Zufälligkeit braucht
man mehrere verschieden lange Register mit XORs, für zufällige
Einzelbits sowieso.
Für GPS-artige Anwendungen gibt es Gold-Codes die ganz
ordentlich sind. Nicht nach dem edlen Metall benannt sondern
nach dem Mann der sie gefunden hat.
Fuer solche Experimente lohnt es sich allenfalls, die Lernkurve von yosys/nextpnr zu bewaeltigen und auf eine relativ gut durchleuchtete Architektur wie ECP5 umzusteigen. Da hat man wenigstens einigermassen automatisierte Kontrolle ueber die Tools (und kann mit amaranth oder cyhdl den Kram prozedural erzeugen/plazieren). Allerdings kann man auch ein FPGA damit zum hochfrequenten Sender alias Kochplatte treiben, also, Vorsicht geboten.
Wirtschaftlichkeit ist bei sowas nur bedingt gegeben, damals beim Spartan6 hat irgend eine Umstellung im Packaging das muehsame Finetuning der Delay-Lines wieder versaut. Ich gehe allerdings mal davon aus, dass das hier um Forschung geht, du also etwas Zeit und Spass an der Freud mitbringst.
Ja, ich möchte LUT1 als Inverter verwenden und sie miteinander
verbinden, sodass eine Oszillation entsteht. Mit einem MUX kann ich
verschiedene Knoten auswählen, wodurch sich die Periodendauer ändert.
Aber beim Umschalten der Knotenpunkte treten Verzerrungen auf. Wie kann
ich diese beseitigen? Ich habe auch ein Bild hinzugefügt
Viele Grüße
Das gleiche Problem hat man eigentlich immer. Auch bei einer LC-Oszillator basierten PLL, wo man die Cs zu und wegschaltet. Abhängig der Oszillatorphase schiebt der Schaltvorgang das Signal, sodass ein Phasenfehler entsteht, der von der Phase abhängt.
Gibt mehrere Möglichkeiten (manchmal werden auch alle angewendet):
Schalten der Mux Elemente an die Phase des Oszillators angleichen
Kalibrieren des Phasenfehlers beim zu / abschalten (bei Inverterkette nicht effektiv)
Das OTW (Oscillator Tuning Word) deutlich überabtasten und Delta Sigma modulieren, sodass sich dieses Phasenrauschen aus dem eigentlichen Nutzband schiebt.
Wenn du den DCO für digitale Dinge verwenden willst, bleibt dir eigentlich nur Option 1: Du musst das Schalten der Elemente so timen, dass der Oszillator nicht gestört wird. Das ist im Asic natürlich deutlich einfacher als im FPGA, da du weder besonders gut an die Punkte herankommst, noch kannst du die eingeltichen MUX Elemente beeinflussen und sicherstellen, dass die in ihrer Implementierung selbst Glitch-frei sind.
Generell ist "ALL-DIGITAL FREQUENCY SYNTHESIZER IN DEEP-SUBMICRON CMOS" von Robert Bogdan ein sehr empfehlenswertes Buch, wenn es um das Design von Oszillatoren / PLLs geht.
Der Ansatz taugt nicht für einen kontinuierlich im Betrieb veränderbaren
DCO. Im FPGA (und woanders auch) macht man das normalerweise per
Addierer
Jein. Fast jede General Purpose PLL in uCs etc. funktioniert genau so. Ist also kein generelles Problem. Das Problem ist eben die begrenzte Ansteuerbarkeit im FPGA.
Dumme Frage, welche Frequenz soll da erzeugt werden? Und warum nicht das oberste Bit eines schnell getakteten Addierers nehmen, der das Steuersignal mit dem Takt aufaddiert?
