Programmieren des LTC2287 Dual 10-Bit ADCs

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.

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.

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.

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.

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?

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.

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.

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.STD_LOGIC_ARITH.ALL;

4

use IEEE.STD_LOGIC_UNSIGNED.ALL;

5

6

entity adc_interface is port

7

(

8

    CLK              : in std_logic;

9

    reset            : in std_logic;

10

    enable_in        : in std_logic;

11

    Real_in_from_ADC : in std_logic_vector(9 downto 0);--receiver side i/p

12

    imag_in_from_ADC : in std_logic_vector(9 downto 0); --receiver side i/p

13

14

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

15

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

16

17

    CLK_out          : out std_logic ;

18

-- ADC_CLK2 : out std_logic;

19

    enable_out       : out std_logic

20

);

21

end entity;

22

23

architecture behavioral of adc_interface is

24

25

begin

26

27

process(CLK,reset)

28

    begin

29

        if  reset = '1' then

30

            enable_out  <= '0';

31

            Dout1       <= (others=>'0');

32

            Dout2       <=  (others=>'0');

33

34

        elsif rising_edge (CLK) then

35

36

            Dout1       <= Real_in_from_ADC ;

37

            Dout2       <= imag_in_from_ADC;

38

            enable_out  <= enable_in;

39

40

        end if;

41

42

end process;

43

44

CLK_out <= CLK ;

45

-- ADC_CLK2<=CLK_SAMP;

46

47

end behavioral;

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

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.

Hallo zusammen, ich hätte gerne Ihre Hilfe bezüglich der xdc-Datei für die Handhabung des ADCs mit einem Eingang. Zu Testzwecken teste ich zunächst nur einen Eingang, dann werde ich beide testen. Beim Ausführen von Generate Bitstream erhalte ich die folgende Fehlermeldung.

Error: [DRC UCIO-1] Unconstrained Logical Port: 12 out of 22 logical

ports have no user assigned specific location constraint (LOC). This may

cause I/O contention or incompatibility with the board power or

connectivity affecting performance, signal integrity or in extreme cases

cause damage to the device or the components to which it is connected.

To correct this violation, specify all pin locations. This design will

fail to generate a bitstream unless all logical ports have a user

specified site LOC constraint defined. To allow bitstream creation with

unspecified pin locations (not recommended), use this command:

set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When

using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add

this command to a .tcl file and add that file as a pre-hook for

write_bitstream step for the implementation run. Problem ports:

Dout[9:0], CLK, and CLK_out.

Ist das dein ganzes Projekt? Wenn ja: Es fehlen die ganzen Constraints für die Ports wie sie in der Fehlermeldung stehen:

Beruk schrieb:

Problem ports: Dout[9:0], CLK, and CLK_out.