Hallo zusammen, nur so eine fixe Idee - wäre es sinnvoll (möglich ist es wahrscheinlich) einen FPGA als Oszillator zu verwenden ? Heißt dass ich einfach an 32PINs einen gewünschten Takt in Hertz vorgebe und der FPGA exakt diesen Takt auf Hertz-genau erzeugt. Wenn ich mich recht erinnere haben FPGAs einen externen Quarzoszillator und mehrere PLLs mit dem quasi jeder gewünschte Takt erzeugt werden kann. Wie genau könnte so etwas sein und bis wieviel MHz wäre realistisch? Mfg, Thomas
Die Frage ist immer, wofür du den Takt verwenden willst? Von Exakt will ich hier nicht mehr reden, siehe Wiki zum Thema "Jitter"! Wenn man etwas relativ genau haben will, dann nimmt man einen externen Clock-Baustein (diverse PLL ICs z. B. Si5338 von SiLab). Diese sind für sowas sehr viel besser geeignet, und trotz der ca. 7€ auch billiger als der FPGA! Wenn man etwas wirklich genau haben willst, dann ist das hier ein guter Ansatz: http://www.microsemi.com/products/timing-synchronization-systems/embedded-timing-solutions/components/sa-45s-chip-scale-atomic-clock Was genau und exakt ist, ist immer relativ!
Thomas schrieb: > Heißt dass ich einfach an 32PINs einen gewünschten Takt in Hertz vorgebe > und der FPGA exakt diesen Takt auf Hertz-genau erzeugt. Und was willst du damit erreichen? Bis hierhin hört es sich an, als ob ein simpler Treiber genau das wäre, was du willst...
Im FPGA gibt es tatsächlich solche Blöcke wie du beschreibst. Die Teilerwerte bzw. VervielfacherWerte stehen in Registern, die mit einprogrammiert werden. Es laufen in einem FPGA nicht alle Gatter mit der gleichen Frequenz. Die internen Frequenzen werden normalerweise von einem einzigen angelegten Takt erzeugt. Den erzeugten Takt kann man auch auf ein Pin geben und so extern verfügbar machen.
Hallo zusammen, ich wollte nur mal hören wie sinnvoll das von der Theorie her überhaupt ist. Dieses Kanonen-Spatzen Dingens trifft natürlich zu. Hab übrigens gesehen dass es da hier schon einen VHDL-Code dazu gibt: http://www.mikrocontroller.net/articles/Clockgenerator_in_VHDL Mfg, Thomas
Was Du tun willst, ist nicht, den FPGA als Oszillator zu nehmen, sondern als Taktteiler. Ein Oszillator wäre z.B. als Ringpuffer zu realisieren, sodass er von sich aus schwingt. Taktteiler wiederum macht dann Sinn, wenn du den Takt nach aussen gibts und für andere Chips verwendest. Intern musst Du noch ein wenig anders bauen. So, wie du es beschrieben hast geht das, ja, aber wenn es nur um das Erzeugen der Frequenz als solchen geht, macht das keiner, wie schon erklärt wurde. Einen FPGA setzt man in solchen Fällen nur ein, wenn es sonst noch irgendwelche exotischen Timing-Geschichten braucht, die sich analog nicht machen lassen und auch als Chip nicht exisitieren, wie das hier: Beitrag "Re: Digtale Baugruppen hochgenau synchronisieren"
Ich suche nach einer Möglichkeit, mehrere Analogkanäle z.B. über DA-Wandler mit Sinustönen oder auch anderen Wellenformen anzusteuern. Geplant sind mindestens 36 Kanäle. Nun bin ich auf die Idee gekommen, das voll digital mit 1 Bit Wandlern zu machen. Wie würde das im FPGA idealerweise aussehen? Die Frequenzen müssen programmierbar sein.
Hobbyorganist schrieb: > Ich suche nach einer Möglichkeit Such doch bitte in einem neuen Thread mit etwas konkreterer Angabe, was du wie machen willst und wie der 1 Bit Wandler aussieht...
Die Frage ist eigentlich 2-geteilt: 1) Wie baue ich die benötigte Gruppe digitaler Oszillatoren mit individuellen Frequenzen und welche FPGA-Grösse brauche ich dafür? Ich meine das passt noch zum Thema. 2) Wie steuere ich mit einem Baustein mehrere Kanäle an, um mir die vielen DACs zu sparen.
Hobbyorganist schrieb: > Ich meine das passt noch zum Thema. Seis drum... > 1) Wie baue ich die benötigte Gruppe digitaler Oszillatoren mit > individuellen Frequenzen und welche FPGA-Grösse brauche ich dafür? Sieh dir mal den Beitrag "FPGA Größe ausreichend für komplexen FM Synthesizer" an. > 2) Wie steuere ich mit einem Baustein mehrere Kanäle an, um mir die > vielen DACs zu sparen. Welche vielen ADCs? Wenn du im FPGA eine Summe deiner Ausgangssignale bildest, dann brauchst du genau 1 ADC, der mit dieser Summe angesteuert wird.
> Wenn ich mich recht erinnere haben FPGAs einen externen Quarzoszillator > und mehrere PLLs mit dem quasi jeder gewünschte Takt erzeugt werden > kann. 1. Die PLL haben meist recht begrenzte Bereiche für m- und n-Teiler. Jeder beliebige Takt lässt sich damit auch unter Verwendung weiterer externer Teiler mitnichten erzeugen. 2. Die Faktoren für N und M werden mit der Konfiguration eingestellt und können während des Betriebes nicht mehr verändert werden.
@ Hobbyorganist: Da hast du den Salat: eine Antwort auf die erste, aber nicht auf deine an den Thread angehängte Frage. So nahm das Drama seinen Lauf... Ich würde an deiner Stelle schnellstmöglich einen neuen Thread aufmachen und die Aufgabe incl. Frequenzbereiche und Pipapo (wer steuert das FPGA an, was ist das eigentliche Ziel...) angeben.
Bürovorsteher schrieb: > 2. Die Faktoren für N und M werden mit der Konfiguration eingestellt und > können während des Betriebes nicht mehr verändert werden. Stimmt nicht ganz. Es gibt - zumindest beim Spartan 6 - einen "Dynamic Reconfiguration Port". Da kann man auch zur Laufzeit Parameter verstellen. Hobbyorganist schrieb: > Geplant sind mindestens 36 Kanäle. Da hört es dann bei Xilinx mit der Zahl der PLL's auf... Duke
Ich denke, es geht wieder mal um Dein AVR Orgelprojekt: Beitrag "AVR Orgel Eigenbau" Eigentlich müsste man mit einer PLL auskommen, von der aus man einen Mastertakt erzeugt und davon per Teiler die benötigten Frequenzen gewinnt. Sieh Dir mal an, wie ich das bei meiner PLD Orgel mache. Die laufen mit 15, 25 und in der letzten Version mit 50 MHz. Die Teiler sind im Bereich von >1000 digit, also auf 0,1 % in der Frequenz genau. Das ist schon recht gut. Wenn es genauer sein soll, dann eben klassisch DDS und Filtern. Auf diese Weise braucht man nur 12 Teiler und ab dann geht es mit Faktor 2 herunter. Um daraus Sinusse zu machen, muss natürlich etwa gefiltert werden, Das kann man aber entsprechend multiplexen. Die andere Frage, ob man nur mit einem DAC auskommt, hängt davon ab, ob die entstehenden Sinusse gemischt werden dürfen. Es wäre aber kein Problem je einzelne auf einem Pin auszugeben. Habe ich anfänglich auch so gemacht. Die entstehende PDM muss dann noch mit einem Doppel-T-Filter gefiltert werden.
Wie wäre es mit einer Menge N an DDS Oszillatoren. 1 Stück mit 250 MHz, 2 mit 125 etc.....
Mischen und einmal ausgeben geht nicht, ich brauche die Kanäle einzeln. Die Idee, einen FPGA zu nehmen liegt wie vermutet darin, sich die Ausgänge und die DACs zu ersparen und lieber PWM zu nehmen. Im Automobilbereich machen sie es ja teilweise genauso. Ist im Vergleich zu Hifi sicher eine Billiglösung aber sie funktioniert offenbar ausreichend gut. Eine PLL und viele Teiler klingt schon gut, aber ich brauche die Freqenzen ganz genau, also sie müssen zu tunen sein. Thomas S. schrieb: > Wie wäre es mit einer Menge N an DDS Oszillatoren. 1 Stück mit 250 MHz, > 2 mit 125 etc..... Das habe ich jetzt nicht verstanden. Wie ist das gemeint, 1x 250, 2x 125?
@ Hobbyorganist (Gast) >Eine PLL und viele Teiler klingt schon gut, aber ich brauche die >Freqenzen ganz genau, also sie müssen zu tunen sein. Ja und? Mit ein paar Steuerregistern im FPGA ist das problemlos möglich.
Das ist eine klassiche Aufgabe für einen DDS Generator. In ein FPGA passen locker die 30+ DDS-Generatoren hinein. Jeder dieser Generatoren besteht aus aus einem 32bit Akkumulator und einem Frequenz-Register. Zusätzlich brauchst du noch intern eine Sinustabelle. Die obersten n-Bits der Akkumulatoren steuern die Sinustabelle an. Die Werte aus der Sinustabelle werden dann seriell zu den externen D/A Wandlern geschickt.
:
Bearbeitet durch User
Wenn es Töne mit Rechteck Signalen und fester Stimmung sein sollen ... Brauchst du 12 Oszillatoren welche die Töne/Halbtöne der höchsten Oktave erzeugen. Alle anderen Oktave kannst du durch Teilung mit 2 erzeugen. Die Abweichungen eines Quarzoszillator reichen da bei weitem aus, da hörst du keinen Unterschied und brauchst keine Feinabstimmung.
Helmut S. schrieb: > Das ist eine klassiche Aufgabe für einen DDS Generator. > In ein FPGA passen locker die 30+ DDS-Generatoren hinein. Jeder dieser > Generatoren besteht aus aus einem 32bit Akkumulator und einem > Frequenz-Register. Zusätzlich brauchst du noch intern eine Sinustabelle. > Die obersten n-Bits der Akkumulatoren steuern die Sinustabelle an. Die > Werte aus der Sinustabelle werden dann seriell zu den externen D/A > Wandlern geschickt. Nö, ist es nicht. Reiner Sinus ist musikalisch nicht das gelbe vom Ei und die Auflösung von DDS bis in die µHz macht für den Zweck auch keinen Sinn. Auch die Hammond-Sinus Orgeln benutzen keinen reinen Sinus sondern mehrere Sinusoszillatoren pro Ton und Filter.
:
Bearbeitet durch User
Ok, es stellen sich also zwei Wege: 12 Präzise Oszillatoren mit 3 Teilern oder 12 DDSen Jeweils danach die Teiler mit Faktor 2 für die 3 Oktaven. Frage: Wie baue ich die Oszillatoren und wie stimme ich sie?
Hobbyorganist schrieb: > Frage: Wie baue ich die Oszillatoren und wie stimme ich sie? Du musst den Oszillator nicht selber bauen! Kauf dir einen fertigen Oszillator mit einer geeigneten Frequenz. Für ein paar Cent fuffzig z.B. so einen 50MHz-Quarzoszillator. Dahinter dann die allseits bekannte DDS und fertig ist ein Ton: http://www.lothar-miller.de/s9y/categories/31-DDFS Allerdings kannst du einen solchen Sinus dann nicht soooo einfach mit einem Flipflop "herunterteilen". > 12 Präzise Oszillatoren Keine Orgel ist "präzise". Im Gegenteil: Verstimungen von Pfeifen gegeneinander und in den Oktaven beleben den Klang und machen "Volumen" und "Fülle". > Ok, es stellen sich also zwei Wege Und wohin sollen die führen? Andersrum: was willst du denn überhaupt? Was willst du überhaupt machen? Eine Orgel mit Manual? Oder ein Midi-Device, das die Noten von einem Masterkeyboard bekommt? Auf welchem Konzept willst du denn aufbauen?
:
Bearbeitet durch Moderator
Du kannst die Top Oktave auch von einem einzigen Quarz Oszillator ableiten dann musst du überhaupt nicht stimmen. Da gab es früher fertige 12V PMOS-IC dafür z.b. MK50240. Der benutzte 2,00024 Mhz dividiert durch 451, 426, 402, 379, 358, 338, 319, 301, 284, 268, 253, 239 Das ergibt die Töne von C8 mit brauchbarer Genauigkeit. Bis 2Mhz runter kommt aber keine FPGA-PLL dafür bekommst durch die höhere Frequenz und den entsprechenden Teilerfaktoren auch eine viel bessere Genauigkeit deiner Frequenzen. Ausrechnen darfst du dir das selbst ;)
Lothar Miller schrieb: > Andersrum: was willst du denn überhaupt? Was willst du überhaupt machen? Dies hier ist des Hobbyorganisten Traum: Beitrag "AVR Orgel Eigenbau" Hobbyorganist schrieb: > Ok, es stellen sich also zwei Wege: > 12 Präzise Oszillatoren mit 3 Teilern oder 12 DDSen Wenn es hochpräzise Töne sein müssen, brauchst Du 12 externe Quarzoszillatoren oder Du stimmst Deine Orgel rein, dann kann man das mit einem Oszillator machen. So ähnlich wie im Beitrag über mir- Ich habe dafür mal ein Setup gefunden, das auf 440,03 Hz passt und mit einem 50MHz Quarz arbeitet. Die anderen darauf basierenden Töne sind auf C-Dur abgestimmt und passen ebenfalls mit dieser Genauigkeit. Dann hast Du 12 Töne mit minimalem Jitter. Tunen kannst du sie aber nur mit Tricks, indem du die Quarze analog hinziehst. Für Deinen Fall sind DDS-Einheiten sicher das Richtige. Du kannst dann entweder soweit mit der Frequenz runtergehen, dass Du ein hörbares Rechteck mit der Zielfrequenz hast, die Du weiter um Faktor 2 teilst oder Du bleibst mit dem Ausgangsvektor der DDS um einen Binärfaktor weiter oben, z.B. Faktor 256 und verwandlest in einen Sinus und filterst ihn. Hier wäre eine "Schaltung": http://home.arcor.de/jusuihe/pldsynthesizer.html Generell: Bei DDS muss man ein wenig aufpassen, weil sie digitalen Phasenjitter erzeugen. http://www.96khz.org/oldpages/limitsofdds.htm Um von dem Sinus mit wenigen Bits nach oben zu kommen, kann man den eh noch erwas filtern, was zugleich den Jitter dämpft. Im vorliegenden Fall sollte das aber kein Problem sein, da die "Orgelpfeife" als Filter dahinter sitzt. Ich meine, Du könntest Deine Pfeife / Röhre sogar auch mit einem Rechteck anregen. Kannst Du ja mal probieren. Einen Punkt muss ich aber noch hinterfragen: Warum sollen die Anregungstöne denn überhaupt getuned werden? Wäre es nicht sinnvoller, diese exakt anzuwenden und die Pfeiffen anzupassen? Wie auch immer bist Du mit DDS flexibler. Hans-Georg Lehnard schrieb: > Auch die Hammond-Sinus Orgeln benutzen keinen reinen Sinus sondern > mehrere Sinusoszillatoren pro Ton und Filter. Beziehst Du Dich dabei auf die echten Hammond-Orgeln oder die Nachbauten? Zumindest für den HOAX ist es ja so gelöst, dass DDS-Einheiten arbeiten und deren digitale Unzulänglichkeiten als Effekt hingenommen werden, wenn ich den Autor im Musikerboard richtig verstanden habe. Was reale Hammonds angeht, sind da etliche magnetische Sättigungseffekte im Spiel. Ausserm modulieren die Töne extrem sodass dort praktisch keine konstanten Frequenzen auftreten. Aus musikalischer Sicht übrigens ein sehr wirksames Mittel, um die Artefakte von DDS-Musik zu reduzieren.
Hans-Georg Lehnard schrieb: > Der benutzte 2,00024 Mhz dividiert durch > > 451, 426, 402, 379, 358, 338, 319, 301, 284, 268, 253, 239 > > Das ergibt die Töne von C8 mit brauchbarer Genauigkeit. > > Bis 2Mhz runter kommt aber keine FPGA-PLL Wieso nicht? Das geht ausgangsseitig immer und unter Weglassen der DLL-Funktion sogar eingangsseitig bei vielen FPGAs. > dafür bekommst durch die > höhere Frequenz und den entsprechenden Teilerfaktoren auch eine viel > bessere Genauigkeit deiner Frequenzen. Naja, wenn die Teilerfaktoren einigermassen stimmen muss die Eingangsfrequenz aber schon sehr viel höher sein, damit man durch die Änderung eines digits genauer wird, also z.B. Faktor 10 und dann 2391 statt 2390 und selbst dann stimmt der Teiler nur im Bereich 1/5000. Da brauche ich auch kein Audio-Quarz mit 2,00000xxx Genauigkeit. Da ist dann auch eine DDS vergleichbar. Die Fehler, die die DDS durch den Jitter bringt, haben mitunter auch ihre positiven Effekte, wenn nämlich trotz aller Bemühungen die Abstimmung der Frequenz des Resonators mit dem Errreger nicht 100% klappt. Da ist ein bischen phase dithering / vibrato nötig.
:
Bearbeitet durch User
Jürgen Schuhmacher schrieb: > Da brauche ich auch kein Audio-Quarz mit 2,00000xxx Genauigkeit. Zumal eine Kirchenorgel sich mit jedem Grad Temperaturunterschied um gute 3 Cent verstimmt, und so im Winter leicht einen viertel Ton tiefer klingen können...
Das kommt noch hinzu, ja, und die Pfeiffen verstimmen sich leider nicht gleichmässig. Die Obertöne passen dann nicht mehr in derselben Weise zu den Grundtönen und daher ist das eigentlich nicht zu tolerieren. Daher werden Orgelkonzerte auch meistens im Herbst durchgeführt wenn die Kirche noch nicht zu kalt ist, aber dennoch kühl genug, um genug Regelreserve fürs Heizen zu haben, anders herum die Heizung es auch packen kann. Problematisch sind laute Kirchenheizungen, die sich schlecht steuern lassen, wenn man Tonaufnahmen machen will. Da muss man taktisch geschickt vorheizen, die Orgel warm machen, dann etwas kühlen lassen um einen nnstrumentenweiten Temperaturausgleich zu haben, dann die Heitung kurz einschalten, damit es unten wieder warm ist und die Luft gleichmässig Schall dämpft und dann, wenn sich die Luft beruhigt hat, schnell ein Stückchen aufnehmen. Ab dann befindet man sich im Heiz-Kühl-Regel-Ton-aus-an-Loop-Betrieb. Heiland, was habe ich da schon Schlachten geschlagen. Weil ich das aber beherrsche, sind meine Orgelaufnahmen auch vom Feinsten :D Das Thema Instrumententemperaturmanagement ist im Übrigen ein sehr Interessantes: Kaum ein Tonmeister interessiert sich da so wirklich dafür, dabei sind viele Instrumente extrem temperaturabhängig und damit auch der Gesamtklang.
:
Bearbeitet durch User
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >Zumal eine Kirchenorgel sich mit jedem Grad Temperaturunterschied um >gute 3 Cent verstimmt, und so im Winter leicht einen viertel Ton tiefer >klingen können... <Barriton> Zieht euch WAAAAAARM an!!!! </Barriton>
Ich habe mich auch schon gefragt was dabei rauskommen würde wenn man sowas wie das Folgende bauen würde: signal CLK, TRIGGER:bit; process (TRIGGER) begin ... beliebige ... Berechnungen die nicht ... wegoptimiert werden dürfen. ... Anzahl variieren um ... die Taktlänge zu verändern. CLK <= not CLK; end process process (CLK) begin TRIGGER <= not TRIGGER; end process So oder so ähnlich ließe sich doch eine maximal kurzer (und bestimmt maximal ungenauer) CLK Takt einstellen. Sollte man nicht verwenden, ist aber ein interessantes Experiment;)
Daniel R. schrieb: > So oder so ähnlich ließe sich doch eine maximal kurzer (und bestimmt > maximal ungenauer) CLK Takt einstellen. Das ist eine kombinatorische Schleife: http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html Und die Simulation ist wieder falsch, weil die Sensitivlisten falsch sind. Einen schnellen Oszillator kannst du als Ringoszillator aufbauen: http://www.lothar-miller.de/s9y/archives/90-Ringoszillator.html Aber ich würde dir raten: probiers einfach aus. Das FPGA geht nicht kaputt davon... Nochmal mein Tipp: Denke in Hardware und beschreib es mit VHDL.
:
Bearbeitet durch Moderator
Daniel R. schrieb: > process (TRIGGER) > begin > ... beliebige > ... Berechnungen die nicht > CLK <= not CLK; > end process Nein, die Überlegung ist falsch. "not CLK" wird immer und zu jeder Zeit (hier nach dem Trigger) ausgeführt, egal wieviel da noch drin steht. Nur in einer Software kannst Du so die Ausführung verzögern. Real geht das nur, wenn echte, verzögernde Hardware verwendet wird. LUTs, die sich gegenseitig ein Signal weiterreichen, wären ein solcher Konstrukt. Mit einem Inverter am Ende, der zurückkoppelt kann man damit einen variabel langen Schwingkreis aufbauen und die Frequenz beeinflussen. Man kann z.B. die Länge durch Variation der Anzahl der Kettenspeicher ändern und damit z.B. eine zufällige Länge erzeugen, wie bei meinem Rauschgenerator oder auch die Länge indirekt dynamisch regeln und damit eine Art PLL bauen, wie bei meinem Frequenzumsetzer. 1. http://www.96khz.org/oldpages/digitalnoisegenerator.htm 2. Digitaler Rauschgenerator im FPGA 3. http://www.96khz.org/oldpages/frequencyshifter2.htm Das togglen selber, als simples VHDL realisiert, als Taktgenerator mit unvorhersehbarer Frequenz funktioniert dabei durchaus, wenn man den Konstrukt ein bischen auf die FPGA-Technologie anpasst. Im Spartan 3E klappt das bereits mit einem Zähler bis 3. Sieh Dir mal den Farbmultiplexer in meinem VGA Core an, der die künstlichen Zwischenfarben oberhalb des Horizontaktes mischt: Das ist als ein sich selbst hochzählender Zähler ohne eigenen Takt formuliert; benutzt wird das bit 1. Durch das Rauschen des Taktes funktioniert die statistische Überlagerung der Farben, weil mitten im Horizontaltakt die RGB-Werte geändert werden. Bei einem getakteten toogle klappt es z.B. nicht! Da das Ganze aber syntheseabhängig mal gut und mal weniger gut aussieht, gehe ich davon aus, dass sich der Mischer-"takt" manchmal doch irgendwie indirekt auf den internen Takt synched, - wahrscheinlich auf das Doppelte. Dann fällt die Geschichte aus. Projekt VGA Core in VHDL
Lothar Miller schrieb: > Aber ich würde dir raten: probiers einfach aus. Das FPGA geht nicht > kaputt davon... Vorsicht :-) Ich hatte mal so einen selbstschwingenden OSC in einem Design drin, um ChipScope nutzen zu können, ohne einen externen Takt zu haben. Der kam nämlich nur sporadisch und auch gepulst. Der OSC lief dann auf gerechneten 1GHz, denn der FPGA lief mit genau einem Drittel des OSC-Taktes (nach dem BUFG) und hatte noch weit über 300 MHz Abtastfrequenz, was sich anhand des abgetasteten Eingangstaktes abzählen liess. Das Ding wurde so heiss, dass ich einen Kühlkörper aufsetzen musste. Man darf also an den Schwingzwerg im Inneren nicht zuviel dranhängen. Und die Verzögerung muss auch lang genug sein, damit es ausreichend schwingt und in die Sättigung geht. Nur dann kann man einen digitalen Takt daraus ableiten.
Jürgen Schuhmacher schrieb: > Nein, die Überlegung ist falsch. "not CLK" wird immer und zu jeder Zeit > (hier nach dem Trigger) ausgeführt Die Bemerkung in der Klammer kannst du streichen. Der Synthesizer wird eine Info ausgeben, dass er die Sensitivliste stillschweigend um das fehlende Signal CLK erweitert hat und deshalb die Simulation nicht mehr zur Realität passt. Letztlich bedeutet das für die umgesetzte Hardware: "not CLK" wird immer und zu jeder Zeit ausgeführt Daniel R. schrieb:
1 | process (TRIGGER,CLK) -- ich habe die Liste mal korrigiert! |
2 | begin
|
3 | ... beliebige ... Berechnungen die nicht |
4 | ... wegoptimiert werden dürfen. |
5 | ... Anzahl variieren um |
6 | ... die Taktlänge zu verändern. |
7 | CLK <= not CLK; |
8 | end process |
Die "Zeit", die die "Prozessausführung" im gepunkteten Bereich "braucht", ist komplett irrelevant, weil nämlich die in dem Prozess beschriebene Hardware gleichzeitig und parallel auf dem FPGA implementiert wird. Du könntest diesen Prozess ohne die klitzekleinste Änderung des Syntheseergebnisses auch so schreiben:
1 | process (TRIGGER) |
2 | begin
|
3 | ... beliebige ... Berechnungen die nicht |
4 | ... wegoptimiert werden dürfen. |
5 | ... Anzahl variieren um |
6 | ... die Taktlänge zu verändern. |
7 | end process |
8 | |
9 | process (CLK) |
10 | begin
|
11 | CLK <= not CLK; |
12 | end process |
Oder gleich so:
1 | process (TRIGGER) |
2 | begin
|
3 | ... beliebige ... Berechnungen die nicht |
4 | ... wegoptimiert werden dürfen. |
5 | ... Anzahl variieren um |
6 | ... die Taktlänge zu verändern. |
7 | end process |
8 | |
9 | CLK <= not CLK; -- nebenläufig |
Und dann sieht man klar, dass das ein "einstufiger Ringoszillator" sein könnte, in Realität aber eine LUT geben wird, deren Ausgang auf Vcc/2 hin&her zappelt. Ich hatte es schon erwähnt: in Hardware denken und die mit VHDL beschreiben. Dann hat die Beschreibungssprache ihren Namen verdient. Du denkst noch immer in C und Prozessor...
:
Bearbeitet durch Moderator
Jürgen Schuhmacher schrieb: > Hans-Georg Lehnard schrieb: >> Der benutzte 2,00024 Mhz dividiert durch >> Bis 2Mhz runter kommt aber keine FPGA-PLL > Wieso nicht? Das geht ausgangsseitig immer und unter Weglassen der > DLL-Funktion sogar eingangsseitig bei vielen FPGAs. > Ich habe mich vielleicht undeutlich ausgedrückt und den Begriff PLL auf den VCO reduziert. Teilen kann man ja immer.
Lothar Miller schrieb: > ch hatte es schon erwähnt: in Hardware denken und die mit VHDL > beschreiben. Dann hat die Beschreibungssprache ihren Namen verdient. Du > denkst noch immer in C und Prozessor... ein ganz schickes Spielzeug, um sich das "in Hardware denken" anzuüben: http://tiweb.hsu-hh.de/LogiFlash/index.html auch Laufzeitverzögerungen lassen sich dort hervorragend beobachten, jedoch ist es ein wenig "frickelig" zu bedienen und deshalb vorallem für großere Verschaltungen unkomfortabel
Ich komme zurück auf die Fragestellung nach der Verwendbarkeit des FPGAs als Oszillator. Soweit mir geläufig gelten die PLLs in FPGAs nicht unbedingt, als das Maß der Dinge, daher muss also so oder so ein Spezialquarz angeschlossen werden und das FPGA kann nur als Taktteiler genutzt werden sowie zur Erzeugun der PWM-Signale. Das habe ich mir genauer angesehen, setze das Thema aber in meinem Faden fort: Beitrag "Re: Orgel Eigenbau - Ansteuerung der Pfeifenröhren"
Lothar Miller schrieb: > Oder gleich so: process (TRIGGER) > begin > ... beliebige > ... Berechnungen die nicht > ... wegoptimiert werden dürfen. > ... Anzahl variieren um > ... die Taktlänge zu verändern. > end process > > CLK <= not CLK; -- nebenläufig > Ich hatte es schon erwähnt: in Hardware denken und die mit VHDL > beschreiben. Dann hat die Beschreibungssprache ihren Namen verdient. Du > denkst noch immer in C und Prozessor... Ich bin immer sehr dankbar für ausführliche Antworten;) Eine Frage und einen Vorschlag hätte ich aber noch: Ich wusste bereits, dass es in einem Prozess wie process (SIG,...) begin ... OUT <= SIG; end process nur allzu logisch ist, dass hier die letzte Zeile aus der Prozesslogik entfernt und zu einer nebenläufigen Signalzuweisung umgewandelt wird. Denn bei einer solchen taktasynchronen Zuweisung, die immer dann stattfindet wenn sich das/die Eingangssignal/e ändern kommt es auf das selbe hinaus -> OUT wird immer dann mit einem neuen Wert beschrieben wenn sich bei den zugewiesenen Signalen etwas ändert. Etwas anderes ist es doch aber wenn man mit Variablen rechnet. process (TRIGGER, CLK) variable vCLK:bit; begin vCLK := CLK; ... einige Anweisungen ... zur Verzögerung CLK <= vCLK; end process Sofern die Variable vCLK in ein paar Berechnungen mit einbezogen wird, dürfte sie denke ich nicht herausoptimiert werden oder?
@ Hobbyorganist (Gast) >Ich komme zurück auf die Fragestellung nach der Verwendbarkeit des FPGAs >als Oszillator. Soweit mir geläufig gelten die PLLs in FPGAs nicht >unbedingt, als das Maß der Dinge, daher muss also so oder so ein >Spezialquarz angeschlossen werden und das FPGA kann nur als Taktteiler >genutzt werden sowie zur Erzeugun der PWM-Signale. Mann o Mann, du macht hier einen Aufriss wegen so ein bisschen Rumgeorgel! Deine PWMs kann jedes FPGA ohne hyperpräzisien Quarzosziollator locker erzeugen. Und sooooo genau wie das hier bisweilen diskutiert wird, muss es nie und nimmer sein! Alles nur akademischer Unsinn!
Daniel R. schrieb:1 | process (TRIGGER, CLK) |
2 | variable vCLK:bit; |
3 | begin
|
4 | vCLK := CLK; |
5 | ... einige Anweisungen <--- Diese Annahme ist GRUNDLEGEND falsch! |
6 | ... zur Verzögerung |
7 | CLK <= vCLK; |
8 | end process |
> Sofern die Variable vCLK in ein paar Berechnungen mit einbezogen wird, > dürfte sie denke ich nicht herausoptimiert werden oder? Denn die Anweisungen in einem Prozess haben in der Hardware keine "Ausführungsreihenfolge". Sie sind lediglich so in der Hardware implementiert, dass nach Durchlauf sämtlicher kombinatorischer Pfade die letzte Zuweisung an ein Signal "gewinnt". Wie lange das dauert, steht auf einen ganz anderen Blatt. Siehe dazu den kurzen Prozess im Beitrag "Re: Clock-Signallaufzeit" Dein Beispiel oben ist übrigens nur ein kleines Stück Draht. vCLK wird natürlich wegoptimiert, weil man die Reihenfolge von Zuweisungen in einem Prozess beliebig vertauchen kann, solange keine Abhängigkeiten bestehen. Das hier:
1 | process (a,b,c,d,e) |
2 | variable v:bit; |
3 | begin
|
4 | v := a; |
5 | w <= a or b and c or d or e; |
6 | x <= v and c or d xor e; |
7 | y <= v or a and b or c; |
8 | z <= v; |
9 | end process |
Ergibt exakt die selbe Hardware wie das hier:
1 | process (a,b,c,d,e) |
2 | variable v:bit; |
3 | begin
|
4 | v := a; |
5 | z <= v; |
6 | y <= v or a and b or c; |
7 | x <= v and c or d xor e; |
8 | w <= a or b and c or d or e; |
9 | end process |
Na gut, manchmal stolpert der Synthesizer und rafft es nich so richtig. Dann passiert sowas wie dort unten: http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html
Ich wäre da trotzdem vorsichtig mit den Variablen, weil man sich beim VHDL ja irgendwie angewöhnt hat, dass die Reihenfolge der Anweisungen nicht von Interesse ist, was ja nicht wenige dazu nutzen, viele verschachtelte Konstrukte in einen Prozess zu schreiben. Das Ergebnis ist dann eher so, wie beim objektorientierten PRogrammieren: Jedes "Objekt" ist konkurrent existent. Bringt man da nun wieder Variablen rein, steigt die Komplexität und wie man gerade an diesem thread hier erkennt, lassen sich damit für die Simulation herrliche Sachen machen, die in der späteren Realität nicht mehr funktionieren, weil diese Zeitdimension eben unter den Tisch gefallen ist.
Hans-Georg L. schrieb: > Der benutzte 2,00024 Mhz dividiert durch > 451, 426, 402, 379, 358, 338, 319, 301, 284, 268, 253, 239 Könntest Du mal bitte erklären, wie man dabei auf die musikorientierten Frequenzen kommen soll?
Hobbmusiker schrieb: > Könntest Du mal bitte erklären, wie man dabei auf die musikorientierten > Frequenzen kommen soll? Das entspricht eher eine Orchesterstimmung von 442 Hz würde Ich sagen und sie wäre sogar noch genauer, wenn es ein 2.000 MHz Quarz wäre.
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.