www.mikrocontroller.net

Forum: FPGA, VHDL & Co. DAC108S085 + FPGA


Important announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Sandy (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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?

Autor: Sandy (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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...

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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.

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Hab im Datenblatt nachgesehen. Die 6,25MHz sollte er ohne Probleme 
schaffen.

Autor: franke (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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ß

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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...

Autor: franke (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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.

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
H E L P ! ! !

Autor: franke (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
versuch doch mal den baustein in den powerdown(high-z) zu schicken,
das sollte sich messen lassen, dann weisst du ob dein interface geht...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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.)?

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: bko (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
nur mal ebenso geraten:
Reihenfolge der seriellen Daten  vertauscht?
Muss D(15) oder D(0) zuerst zum DAC ?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Bit 15 muss die Nummer 1 sein...

Autor: Sandy (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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...

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Sparxx (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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".

Autor: Sandy (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Sparxx (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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.

Autor: franke (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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ß

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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. ;)

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Oszilloskop
Wie sieht es damit aus?

Duke

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Die Oszi Bilder sind weiter oben in den Beiträgen.

Wenn Du was spezielles sehen willst kann ich´s gerne online stellen.

Bussi
Sandy

Autor: Jean Neo Leander (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Hör doch mal bitte mit dem "Bussi" auf. Du bist doch ein Kerl ;-)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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...

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Sandy (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Hi!

Nach einer Woche Urlaub habe ich endlich das Oszi Bild.

Bussi
Sandy

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Aja,

D2 ist sync
D1 ist clk
D0 sind die Daten

Sorry

Autor: Duke Scarring (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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!

Autor: Wat (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Is klar

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite Flattr this
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
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"...

Autor: Sandy (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
@Lothar: Danke für den Tipp. Ich glaube den Fehler mache ich nur ein mal 
;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net