Datum:
Angehängte Dateien:Liebe Kollegen! Ich versuche seit Tagen einen DAC108S085 zu programmieren. Wenn wenigstens ein Ausgang etwas anzeigt wäre ich schon zufrieden. Ich sende an jeden Kanal die selben digitalen Werte "0011111100". Die Signale vom FPGA liegen auch am Chip an (CLK, SYNC, DATA). Ich habs mit dem Oszi kontrolliert. Könnt Ihr mir einen Tip geben bevor ich ganz verzweifel!? Datenblatt http://www.ti.com/lit/ds/symlink/dac108s085.pdf
p_DAC088S085 : process (reset, clk) begin if reset = '1' then s_counter1 <= (others => '0'); s_counter2 <= (others => '1'); s_state <= Idle; elsif clk = '1' and clk'event then if enable = '1' then case s_state is ------------------------------------------------------------ when Idle => data_o <= '0'; sync_o <= '1'; case s_counter1 is when "0000" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i0; s_data(1 downto 0) <= "00"; when "0001" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i1; s_data(1 downto 0) <= "00"; when "0010" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i2; s_data(1 downto 0) <= "00"; when "0011" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i3; s_data(1 downto 0) <= "00"; when "0100" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i4; s_data(1 downto 0) <= "00"; when "0101" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i5; s_data(1 downto 0) <= "00"; when "0110" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i6; s_data(1 downto 0) <= "00"; when "0111" => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i7; s_data(1 downto 0) <= "00"; when "1000" => -- update DATA s_data(15) <= '1'; s_data(14 downto 12) <= "001"; s_data(11 downto 2) <= "0000111111"; s_data(1 downto 0) <= "11"; when others => s_data(15) <= '0'; s_data(14 downto 12) <= s_counter1 (2 downto 0); s_data(11 downto 2) <= data_i7; s_data(1 downto 0) <= "00"; end case; s_state <= sync; ------------------------------------------------------------ when sync => sync_o <= '1'; s_state <= wrt; ------------------------------------------------------------ when wrt => sync_o <= '0'; if s_counter2 = "0000" then s_state <= Idle; if s_counter1 = "1000" then s_counter1 <= "0000"; else s_counter1 <= unsigned(s_counter1) + 1; end if; s_counter2 <= "1111"; else s_counter2 <= unsigned(s_counter2) - 1; end if; data_o <= s_data(conv_integer(s_counter2)); end case; end if; end if; end process; |
Die CLK zum Chip wird in einer eigenen Entity erzeugt und ist 100MHz/8 (habs mit 16 und 32 auch schon versucht). Enable wird in dem selben Chip erzeugt wie CLK und ist 100MHz/16. B I T T E helft mir!! Bussi Sandy
Datum:
Sandy schrieb: > Die Signale vom FPGA liegen auch am Chip an (CLK, SYNC, DATA). > Ich habs mit dem Oszi kontrolliert. Ja und? Kommt da das an, was der DAC will? Sandy schrieb: > Könnt Ihr mir einen Tip geben bevor ich ganz verzweifel!? In deiner Simulation ändern sich die Zustände von sync_o und dac_o mit der fallenden Flanke von clk_o. Das ist aber laut Datenblatt genau die Flanke, an der die Daten unbedingt stabil sein müssen! Sandy schrieb: > Die CLK zum Chip wird in einer eigenen Entity erzeugt und ist 100MHz/8 > (habs mit 16 und 32 auch schon versucht). Hoffentlich mit einem Taktmanager... > Enable wird in dem selben Chip erzeugt wie CLK und ist 100MHz/16. Warum glitcht das Ding so?
Datum:
Angehängte Dateien:Das mit der falling edge stimmt. Ist aber leider nicht die Lösung. Wenn ich 100MHz/4 nehme (so war es eigentlich vorgesehen) funktioniert es auch nicht und das falling edge Problem tritt nicht auf.
Datum:
Was passiert, wenn du den DAC mal z.B. nur mit 1 MHz ansteuerst? Mann muß auf die Dinger ja nicht gleich mit Vollgas losbolzen...
Datum:
Das langsamste was ich getestet habe waren 6,25MHz. Er hat mich einfach ignoriert. 1MHz kann ich erst morgen wieder probieren. Komme gerade nicht in´s Labor.
Datum:
Hab im Datenblatt nachgesehen. Die 6,25MHz sollte er ohne Probleme schaffen.
Datum:
Hi Ich glaube ich seh dein Problem. Nach Power-Up der DAC ist in WRM Mode (write register mode), d.h. die Daten erscheinen nicht am Ausgang, du musst erst in den WTM (write trough mode) wechseln, dann erscheinen auch die Daten am ausgang. Gruß
Datum:
franke schrieb: > du musst erst in den WTM (write trough mode) wechseln, > dann erscheinen auch die Daten am ausgang. Das passiert eigentlich schon beim
when "1000" => -- update DATA
s_data(15) <= '1';
s_data(14 downto 12) <= "001";
s_data(11 downto 2) <= "0000111111";
s_data(1 downto 0) <= "11";
|
Damit sind die Bits 15..12 = "1001" und der WTM sollte aktiviert sein...
Datum:
ups, übersehen, trotzdem , den zugriff würde ich mal an den anfang setzten, nicht ans ende. Ich würde den text des datenblattes etwas anderes interpretieren.
Datum:
Die Entity schreibt die ganze Zeit an den DAC. Wenn sich die Daten am Eingang ändern will ich das so schnell wie möglich am DAC sehen. Dadurch wird der WTM auch immer wieder geschrieben (das dabei die dersten Daten nach dem Start UP ignoriert werden ist egal). Das war mein erster Fehler. Ich habe überlesen, dass ich das Ding auch updaten muss ;) Bussi Sandy
Datum:
versuch doch mal den baustein in den powerdown(high-z) zu schicken, das sollte sich messen lassen, dann weisst du ob dein interface geht...
Datum:
Sandy schrieb: > H E L P ! ! ! Was ist jetzt mit dem Oszi? Zeig mal einen Screenshot davon. Die Hardware ist sicher in Ordnung (Referenzspannungen und Co.)?
Datum:
Ich hab keine Screenshots vom Oszi. Ich hab inzwischen einen 2. Baustein getestet. Ignoriert mich leider auch. An den IC´s liegts also nicht. Referenzspannung und dgl. sind in Ordnung. Das mit dem Power Down kann ich machen aber wenn das Interface gehen würde könnte ich das Ding ja programmieren. Ich habe heute noch ein paar Codes getestet (schneller, langsamer, clk_DAC... anders generiert, ...). Leider funktioniert keiner. Ich hab mir am Oszi auch die Limits für Low bzw. High angeschaut. Da besteht auch keine Gefahr. Ich bin mit allem im grünen Bereich. Die Signale kommen auch beim IC an, das habe ich heute kontrolliert. Ich habe keine Idee mehr was ich noch probieren könnte. Danke für Eure Hilfe! Bussi Sandy
Datum:
Sandy schrieb: > Ich habe keine Idee mehr was ich noch probieren könnte. Uns einen Screeshoot (Simulation und Oszilloskop) zukommen zu lassen, ist gar keine schlechte Idee. Duke
Datum:
nur mal ebenso geraten: Reihenfolge der seriellen Daten vertauscht? Muss D(15) oder D(0) zuerst zum DAC ?
Datum:
Bit 15 muss die Nummer 1 sein...
Datum:
Angehängte Dateien:Bit 15 ist die Nummer 1, deshalb hab ich den Counter 2 umgedreht. Anbei die neue Simulation. Ich hab die CLK_DAC... so eingestellt, dass sich die Daten immer mit der steigenden Flanke ändern. Dann kann nichts passieren wenn die Flanke fällt. Geht leider auch nicht, ich habs gestern an der Hardware getestet. Ich werde versuchen heute in´s Labor zu kommen und ein paar Bilder zu machen. Bussi Sandy
Datum:
Angehängte Dateien:Sandy schrieb: > Geht leider auch nicht, ich habs gestern an der Hardware getestet. Der Sync passt nicht! Bei mindestens einer fallenden Flanke muss der Sync '1' sein, denn sonst kann der Baustein gar nicht erkennen, dass ein Sync da war...
Datum:
Angehängte Dateien:Sandy schrieb: > Geht leider auch nicht, ich habs gestern an der Hardware getestet. Hast Du mal mit dem Datenblatt verglichen? Dein SYNC ist zu kurz. Der muß auch während einer fallenden Flanke aktiv sein. Duke
Datum:
Ihr habt recht, das hab ich übersehen. SUPER, DANKE!!!! Ich werd´s heute gleich ausprobieren und sage Euch dann bescheid ob es funktioniert hat. Wenn das geht mach ich heute eine Flasche Sekt auf!! Bussi Sandy
Datum:
Sorry,wenn ich mich kurz dazwischenquetsche :) habe da eine Frage: Anhang des Timing diagramms liegt das Signal SYNC in der Mitte der steigenden Flanke. Wie wird es in VHDL umgesetzt? Wird das im constraints File eangegeben? Wollte die Gelegenheit nutzen und keinen neuen Thread aufmachen. Danke für ihr Verstädnis.
Datum:
Sparxx schrieb: > Anhang des Timing diagramms liegt das Signal SYNC in > der Mitte der steigenden Flanke. Wie wird es in VHDL umgesetzt? Gar nicht! Das Bildchen aus dem Datenblatt allein ist bestenfalls die halbe Wahrheit! Im Datenblatt sind nämlich auch Zeiten angegeben, und die besagen z.B. dass nach der fallenden Flanke das Sync-Signal nicht mehr stabil sein muss, sondern sich ändern darf. Und dann wählt man sein Timing so, dass man sicher im sicheren Bereich ist. > Wird das im constraints File eangegeben? Nein. Das geht nicht. Dort kann man nicht einfach so "Verzögerungszeiten" angeben. Die Werte im Constraints File sind Maximalwerte. Drunter darf die Toolchain idR. gerne bleiben. Ich sage also nicht: "ich will genau 10ns Laufzeit", sondern "das Signal darf maximal 10ns Laufzeit ahben".
Datum:
Angehängte Dateien:Ich hab auf die schnelle die CLK verändert. Jetzt hinkt sie ein bischen aber SYNC bekommt die fallende Flanke. Hab mich auch schnell in´s Labor gedrängt aber der IC ignoriert mich weiter. Ich werde noch das Design so ändern, dass ich eine ordentliche CLK habe, vielleicht liegt es daran. @Sparxx: Ich setze die clk momentan in der State Machine. Ist nicht sehr schön aber es funktioniert (nicht schimpfen ich weis, dass man das nicht so machen sollte). Dementsprechend kann ich SYNC setzten wenn ich mit CLK auf '1' gehe. Bussi Sandy
Datum:
Lothar Miller schrieb: > Und dann wählt man sein Timing so damit meinst du die Angaben im Constraints File, richtig? >Sandy Danke euch,dass ihr mir diese Unklarheit erklärt habt.
Datum:
hi nochmal du schreibst, dass die statemachine immer läuft. lass sie doch nur einmal im kreis laufen, mit WTM natürlich, oder nutze den broadcast. im datenblatt steht was von settling-time im bereich von 5 us... vielleicht machst du die interne statemachine kirre und die fängt laufend von vorne an... ist aber auch nur geraten. gruß
Datum:
im datenblatt steht was von settling-time im bereich von 5 us... vielleicht machst du die interne statemachine kirre und die fängt laufend von vorne an... stimmt, das kann sein. Ich werds mal ändern und sehen was passiert. Im fertigen Design soll das Ding aber den DAC immer auf dem laufenden halten. Bussi Sandy P.S.: Dein "ielleicht machst du die interne statemachine kirre" hat mich sehr erheitert. ;)
Datum:
Ich konnte jetzt endlich das neue Design ausprobieren. Ich programmiere den DAC jetzt nur ein mal. Zuerst alle Werte und dann den Update Befehl. Wieder nichts. Auch beim 2. Board nicht. Langsam gehen mir die Ideen aus. Bussi Sandy
Datum:
Die Oszi Bilder sind weiter oben in den Beiträgen. Wenn Du was spezielles sehen willst kann ich´s gerne online stellen. Bussi Sandy
Datum:
Hör doch mal bitte mit dem "Bussi" auf. Du bist doch ein Kerl ;-)
Datum:
Sandy schrieb: > Die Oszi Bilder sind weiter oben in den Beiträgen. Das sind nur Bilder von Simulations-Waveforms. Oszi ist aber das Ding mit den Tastköpfen, mit dem man auf der Hardware an IC-Pins misst...
Datum:
Und ich hab mich schon gewundert warum der Fernseher so einen kleinen Bildschirm hat. Oszi Bilder hab ich nicht. Zumindest keine auf denen man die Signale sieht. Ich mache welche wenn ich das nächste mal im Labor bin. Bussi Sandy
Datum:
Angehängte Dateien:Hi! Nach einer Woche Urlaub habe ich endlich das Oszi Bild. Bussi Sandy
Datum:
Aja, D2 ist sync D1 ist clk D0 sind die Daten Sorry
Datum:
Sieht doch gar nicht so schlecht aus (bis auf die zusätzliche steigende Flake während /SYNC). Du hast 16 Pins an dem Chip. Was misst Du an V_ref1 und V_ref2? Was misst Du an den Ausgängen (V_outA...V_outH)? Was liegt als Betriebsspannung an? Sind die Masse von FPGA und DAC miteinander verbunden? Welche Codes schickst Du denn jetzt an den DAC? Ist da auch auch x"9000" (WTM aktivieren) dabei? Oder ein x"A0FF" (update selected channels)? Duke
Datum:
Ich hab des Rätesels Lösung! Es war eine kalte Lötstelle. So was dummes! DANKE für Eure Hilfe und vorallem Zeit!!!!!!!!!!!!!!!!! Bussi Sandy!
Datum:
Sandy schrieb: > Es war eine kalte Lötstelle. So was dummes! Da kann man lange simulieren... Drum für die Zukunft: immer am anzusteuernden Baustein messen, nicht am FPGA oder "irgendwo zwischendrin"...
Datum:
@Lothar: Danke für den Tipp. Ich glaube den Fehler mache ich nur ein mal ;)








