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.
:
Bearbeitet durch User
https://de.wikipedia.org/wiki/DCO Doping Control Officer ? https://de.wikipedia.org/wiki/Digitally_Controlled_Oscillator = DDS + DAU dümmster anzunehmender User? Digital-Analog-Umsetzer (DAU) Verzögerungsleitung? Ein DDS ist normalerweise ein Addierer, dessen Ergebnis der nächste Eingangswert wird.
Christoph db1uq K. schrieb: > https://de.wikipedia.org/wiki/DCO > Doping Control Officer ? > https://de.wikipedia.org/wiki/Digitally_Controlled_Oscillator > = DDS + DAU > dümmster anzunehmender User? > Digital-Analog-Umsetzer (DAU) > > Verzögerungsleitung? Ein DDS ist normalerweise ein Addierer, dessen > Ergebnis der nächste Eingangswert wird. Hallo, ich habe mit DCO Digitally Controlled Oscillator gemeint: https://de.wikipedia.org/wiki/Digitally_Controlled_Oscillator
Moin, Halil E. schrieb: > 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? Gruss WK
in Wikipedia verlinkt: https://www.latticesemi.com/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/NumericallyControlledOscillator.aspx 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.
Angehängte Dateien:
> 1.) Axo, dieee Verzoegerungsleitung. Das zentrale Bauteil jedes DCO... > 2.) Vielleicht mehr Bilder und weniger Prosa? > > Gruss > WK > 1.) Axo, dieee Verzoegerungsleitung. Das zentrale Bauteil jedes DCO... 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
Moin, 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. Gruss WK
Halil E. schrieb: > 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.
Halil E. schrieb: > 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.
:
Bearbeitet durch User
https://de.wikipedia.org/wiki/Phasenraum Das klingt immer sehr wissenschaftlich und gelehrt. 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.
Christoph db1uq K. schrieb: > Ich verstehe auch nicht, wie man so ein unpräzises Verfahren wie die > Laufzeit eines Gatters als Zeitreferenz verwenden kann Ich glaube es reicht, wenn es kurzzeitstabil ist. Dann kann man es differentiell gegen eine Referenz messen und kriegt Zeitauflösungen im ps-Bereich.
:
Bearbeitet durch User
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. Gerhard DK4XP
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.
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.