Hallo, ich habe vor einigen Jahren mal basierend auf Lothar Miller's DDFS http://lothar-miller.de/s9y/archives/37-DDFS-mit-BROM.html eine DDFS mit 32Bit Breite erstellt. Jetzt versuche ich das Modul erneut zu verwenden. Es kommt leider aber kein Signal raus..... zum Verständnis --> CLK ist mein Eingangstakt FREQ_INC ist ein Wert, mit dem ich die lut durchlaufe, also der Abstand zwischen zwei benachbarten, auszugebenden Werten BCK keine Ahnung warum das da ist? DIN_CNT DIN_CNT_MAX beides keine Ahnung PHASE_INC damit kann das Signal in der Phase verschoben werden DOUT generiertes Ausgangssignal warum frag ich bloß DIN_CNT und BCK ab?
Daniel F. schrieb: > Es kommt leider aber kein Signal raus..... In der Simulation? Oder bei der Implementierung? Simuliere mal und schau, was an Dout ankommt und was überhaupt so mit der DDS passiert. Daniel F. schrieb: > DIN_CNT > DIN_CNT_MAX beides keine Ahnung Ich auch nicht. Dein Phasenakkumulator zählt nur weiter, wenn BCK=1 ist und Din_cnt=Din_cnt_max -1 . Beides sind Eingänge, d.h. für jede andere Kombination deiner Eingangswerte bleibt der Phasenakku stehen. Vielleicht wolltest du dir damit so was wie einen "Vorteiler" bauen. Glaube eher nicht, dass das sinnvoll ist. Aber in jedem Fall musst du die passenden Signale an diese Eingänge legen, wenn deine DDS was tun soll.
Beitrag #5147764 wurde von einem Moderator gelöscht.
E. M. schrieb im Beitrag #5147764:
> Vielleicht ist das Mindesthaltbarkeitsdatum des Codes überschritten?
Wo steht das üblicherweise?
Daniel F. schrieb: > warum frag ich bloß DIN_CNT und BCK ab? Das steht üblicherweise in den Kommentaren im Code. Aber wenn du die sowieso nicht brauchst, dann lösch die Zeilen doch raus. So wie ich das sehe, wirken alle diese Signale eine Art Enable, die die Signalerzeugung von anhalten können...
Lothar M. schrieb: > Das steht üblicherweise in den Kommentaren im Code. Aber wenn du die > sowieso nicht brauchst, dann lösch die Zeilen doch raus. > > So wie ich das sehe, wirken alle diese Signale eine Art Enable, die die > Signalerzeugung von anhalten können... Stimmt ich hab das jetzt mal rausgelöscht.... BCK sollte wohl mal "Bit Clock" heißen.... bräuchte ich das dann nicht auch weiterhin? also z.B. mit CLK arbeiten und BCK als Clock Enable
Daniel F. schrieb: > bräuchte ich das dann nicht auch weiterhin? > > also z.B. mit CLK arbeiten > und BCK als Clock Enable Wenn du ein Clock Enable brauchst (weil du die DDS zwischendurch anhalten oder "einfrieren" willst), dann kannst du das so machen. Wenn du es nicht brauchst (bzw. nicht mehr weißt, wozu des früher mal zu brauchen glaubtest), dann kannst du es weglassen.
Daniel F. schrieb: > also z.B. mit CLK arbeiten > und BCK als Clock Enable Ist der Bitclock auch wirklich ein Puls oder ein 50:50 Takt? Dann wäre das ein schlechtes enable.
Hallo, Vielen Dank noch einmal an alle, die mir hier bisher geholfen haben. Nun stehe ich vor einem weiteren, (hoffentlich) kleinen Problem! ich wollte die Sinustabelle neu berechnen oder besser gesagt : die "Viertel-Sinustabelle". Im Vergleich zur ursprünglichen Tabelle aus "DDS.vhd" erhalte ich andere Werte und mit diesen Werten erhalte ich ganz eklige "Peaks" im erzeugten Signal.... vermutlich irgendwie ein Überlauf.... Ich nutze zur Erzeugung der Sinuswerte ein Script, das ich in "Octave" ausführe (siehe Anhang). Ich kann mir nicht so recht erklären, wie die ursprünglich generiert worden sind, die auch supi funktionieren... da hab ich wohl schlecht dokumentiert. aber was könnte das Problem sein? Ich wäre für Tipps sehr dankbar. Viele Grüße Daniel
Frickelfritze schrieb: > Daniel F. schrieb: >> aber was könnte das Problem sein? > > Others vergessen? Nö leider nicht :( --> others => x"00000000"
Daniel F. schrieb: > aber was könnte das Problem sein? das 0x8000 nicht die signed representation von 1 ist?
Bitwurschtler schrieb: > das 0x8000 nicht die signed representation von 1 ist? Hmmh ich kann leider partout nichts finden, was dann die richtige Representation sein könnte? etwa 0xFFFFFFFF?
Daniel F. schrieb: > Hmmh ich kann leider partout nichts finden, was dann die richtige > Representation sein könnte? > etwa 0xFFFFFFFF? ok ich merke gerad, dass das mit der Ausgabe im fprintf als hex also %x nicht das ist, was ich will....... negative Werte können so nicht dargestellt werden blabla...... oh man das ist doch alles viel zu lange her ;)
Ich habe mal vor ein paar Jahren in < http://opencores.org/project,sincos > eine Sinustabelle veröffentlicht, die komplett parametrisierbar ist und vom VHDL-Compiler zur Compilationszeit ausgerechnet wird. Man braucht nichts als die Bordmittel von ISE oder Modelsim. Es wird geprüft, ob die Ergebnisse bitgenau sind, es wird nur ein Quadrant gespeichert und ohne Mehraufwand an Speicher gibt's auch den Cosinus dazu, was ganz praktisch ist wenn man reale ADC-Werte komplex weiterverarbeiten will. (Mischer in einem SDR) Pipelineregister werden auch strategisch günstig eingebaut für hohe Taktfrequenzen. Es sind in den 7 Jahren noch keine Beschwerden gekommen, was ich mal als gutes Zeichen nehme. Das Testbett ist ein DDS. Ob 32 Bit Y-Auflösung bei 10 Bit X-Auflösung sinnvoll sind ist eine andere Sache. Gruß, Gerhard
Das ist wie die ewige V0.99 bei einigen Programmen :-) Das wird noch fast jeden Tag runtergeladen und die einzigen Nachfragen waren, wie man den Modelsim auf ps-Zeitauflösung einstellt, das aber öfter. Von der un/signed-lib gibt's erweiterte Versionen, hab' aber nicht den Antrieb, das nochmal zu testen und hochzuladen. Es gibt neue VHDL-features die das tangieren, die habe ich aber selber noch nicht benutzt. Mein Interessengebiet ist zur Zeit eher Mikrowellensachen, so mit rauscharmen Oszillatoren, S-Parametern, ps-scopes und TDR.. Gruß, Gerhard
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.