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.
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.
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.
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?
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.
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.
@ 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:> 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...Berechnungendienicht
4
...wegoptimiertwerdendürfen.
5
...Anzahlvariierenum
6
...dieTaktlängezuverändern.
7
CLK<=notCLK;
8
endprocess
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...Berechnungendienicht
4
...wegoptimiertwerdendürfen.
5
...Anzahlvariierenum
6
...dieTaktlängezuverändern.
7
endprocess
8
9
process(CLK)
10
begin
11
CLK<=notCLK;
12
endprocess
Oder gleich so:
1
process(TRIGGER)
2
begin
3
...beliebige...Berechnungendienicht
4
...wegoptimiertwerdendürfen.
5
...Anzahlvariierenum
6
...dieTaktlängezuverändern.
7
endprocess
8
9
CLK<=notCLK;-- 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...
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!
...einigeAnweisungen<--- Diese Annahme ist GRUNDLEGEND falsch!
6
...zurVerzögerung
7
CLK<=vCLK;
8
endprocess
> 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:
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 abschalten