Programmieren des LTC2287 Dual 10-Bit ADCs

[Beruk (manitou)]

Hallo an alle!

ich hoffe von ganzem Herzen, dass ich hier Hilfe finde. Denn was ich 
bisher auf Ihrer Seite gelesen habe, zeigt, dass Sie viel Erfahrung mit 
FPGAs haben. Mein Problem ist wie folgt:
Ich muss in der Programmiersprache VHDL einen ADC mit zwei Eingängen und 
einem Clock programmieren. Der Ausgang des ADCs besteht aus 20 Ausgängen 
und einem Multiplexer. Bedenkt man, dass ich nicht sehr erfahren bin. 
Ich hätte gerne Ihre Hilfe, um zu verstehen, wie dieser ADC funktioniert 
und wie ich ihn am besten programmieren kann. Ich habe nämlich vor, eine 
FSM zu verwenden, um den ADC zu steuern und die FIFO BRAM-Konfiguration 
zu verwenden.

Beste Grüße

[Gustl B. (gustl_b)]

Beruk schrieb:
> Ich muss in der Programmiersprache VHDL einen ADC mit zwei Eingängen und
> einem Clock programmieren.

Den ADC gibt es schon, du musst nur die Daten entgegennehmen. Und das 
ist recht einfach weil das ein paralleler Ausgang ist. Du kannst also 
wie im Datenblatt Seite 14 die Daten mit einer Taktflanke übernehmen. 
Wenn du die Daten auf einen Bus multiplext, dann brauchst du ein IDDR um 
die Daten mit beiden Flanken zu erfassen.

Beruk schrieb:
> Ich habe nämlich vor, eine FSM zu verwenden, um den ADC zu steuern

Kann man machen, aber viel gibt es da nicht zu steuern. Spannung 
anlegen, Takt erzeugen, einmal die Pins so beschalten wie man es haben 
will und dann so lassen.

Beruk schrieb:
> die FIFO BRAM-Konfiguration zu verwenden.

Das ist dann im FPGA. Das macht auch Sinn. Wir wissen nicht wo die Daten 
hin sollen oder was damit passiert. FSM und FIFO können also sinnvoll 
sein oder auch nicht.

Was hast du denn schon geschrieben? So einen FPGA kann man auch 
wunderbar simulieren und so ganz ohne Hardware sein VHDL schreiben.

[Beruk (manitou)]

Hallo Gusti_b,
ich danke dir für deine sehr schöne Rückmeldung, also geschrieben habe 
ich noch nicht, denn ich bin bis jetzt immer am Denken wie das ganze 
funktionieren wird. Die Daten aus dem ADC werden im einem BRAM im FPGA 
erstmal gelagert. Deswegen hatte oben von FSM und FIFO BRAM gesprochen.

[Rick D. (rickdangerus)]

Beruk schrieb:
> Die Daten aus dem ADC werden im einem BRAM im FPGA
> erstmal gelagert.
Dein ADC kann die Daten mit bis zu 40 MS/s liefern. Bei zwei Kanälen und 
10 Bit pro Kanal kommen in einer Sekunde 80 Millionen Bit zusammen.
Wieviele Bit hat dein BRAM?

Ich habe öfters mal einen ADC am FPGA. Um die vernünftig zu simulieren, 
schreibe ich mir in VHDL ein Modell des ADCs. Erst danach kommt das FPGA 
Design.
Auch hier macht es dir der ADC mit seinem Parallel-Interface relativ 
einfach.

[Gustl B. (gustl_b)]

Rick D. schrieb:
> Wieviele Bit hat dein BRAM?

Ist doch egal, das ist sein Konzept. FIFOs sind nur dazu da etwas zu 
entzerren. Die Daten müssen eben im zeitlichen Mittel schnell genug auf 
der anderen Seite aus dem FIFO gelesen werden.

[J. S. (engineer)]

Gustl B. schrieb:
> Ist doch egal, das ist sein Konzept. FIFOs sind nur dazu da etwas zu
> entzerren.

Das macht aber nur Sinn, wenn man die Daten dann blockweise verarbeiten 
möchte, wie z.B. bei manchen AXI-Video-Cores. Und sie machen Sinn, wenn 
man die Datenrate hochpuschen möchte, z.B. indem man 2 Datenworte 
gleichzeitíg verarbeitet und das BRAM mit 2:1 betreibt -> 80 MHz. Hier 
geht es sogar mit 2 BRAMs, weil 2 Kanäle. Allerdings ...

Rick D. schrieb:
> Wieviele Bit hat dein BRAM?
ist das Dingens rasch voll. Und zum parallelen Verarbeiten braucht man 
nue 2x2 Registerworte.

Die Frage ist: Wieviel DACs kommen dran?

[Gustl B. (gustl_b)]

J. S. schrieb:
> blockweise verarbeiten möchte

Muss nicht sein.
Kann auch eine krasse Reduktion der Datenrate bedeuten wenn einen nur 
seltene Ereignisse interessieren oder man wie bei einem Oszi nur um 
einen Trigger herum speichern will. Da nimmt man zwei FIFOs, schaufelt 
vom ersten in den zweiten und dazwischen hängt man die Triggerlogik.

[Beruk (manitou)]

Hallo @gustl_b,

ich danke Dir für die Rückmeldung. Ich habe mittlerweile einen Kode 
geschrieben. Aber ich weiß nicht ob der okay ist.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity adc_interface is port
(
    CLK              : in std_logic;
    reset            : in std_logic;
    enable_in        : in std_logic;
    Real_in_from_ADC : in std_logic_vector(9 downto 0);--receiver side i/p
    imag_in_from_ADC : in std_logic_vector(9 downto 0); --receiver side i/p

    Dout1            : out std_logic_vector(9 downto 0);--receiver side 0/p
    Dout2            : out std_logic_vector(9 downto 0);--receiver side o/p

    CLK_out          : out std_logic ;
-- ADC_CLK2 : out std_logic;
    enable_out       : out std_logic
);
end entity;

architecture behavioral of adc_interface is

begin

process(CLK,reset)
    begin
        if  reset = '1' then
            enable_out  <= '0';
            Dout1       <= (others=>'0');
            Dout2       <=  (others=>'0');

        elsif rising_edge (CLK) then

            Dout1       <= Real_in_from_ADC ;
            Dout2       <= imag_in_from_ADC;
            enable_out  <= enable_in;

        end if;

end process;

CLK_out <= CLK ;
-- ADC_CLK2<=CLK_SAMP;

end behavioral;

[Mod: bitte die vhdl-Tags das nächste Mal selber einfügen]

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Beruk schrieb:
> Ich habe mittlerweile einen Kode geschrieben.
Der Code ist supersimpel und beschreibt eigentlich nur 21 Fipflops. Das 
wird der RTL-Schaltplan deutlich darstellen.

> Aber ich weiß nicht ob der okay ist.
Der Code ist ok. Wenn "es" damit nicht funktioniert, dann liegt das 
Problem woanders.

Beruk schrieb:
> Ich hätte gerne Ihre Hilfe, um zu verstehen, wie dieser ADC
> funktioniert und wie ich ihn am besten programmieren kann.
Wie der ADC funktioniert, ist im Datenblatt beschreiben. Und das 
Interface zum ADC ist ganz einfach, wenn kein Multiplexer verwendet 
wird: mit jeder steigender Taktflanke wird der 6 Takte zuvor gesampelte 
Analogwert in digitaler Form ausgegeben.

Und weil das bis hinunter zu 1 MHz Taktfrequenz zuverlässig 
funktioniert, kannst du ja einfach mal die ersten Tests mit solch 
niedrigen Taktfrequenzen machen. Und dich erst später mit hohen 
Taktfrequenzen, Signallaufzeiten und Timing Constraints beschäftigen.