Speicherzugriff beim Nexys4-DDR Board

[Burkhard K. (buks)]

Hat jemand hier im Forum ein Nexys4-DDR Board in Betrieb? Ich hätte ein 
paar Fragen bzw. Beobachtungen zur Nutzung des DDR2 Speichers; dabei 
handelts es sich um ein MT47H64M16 mit 64 Meg x 16 Konfiguration und 
einer eingestellten Burstlänge von 8. Ich benutze ISE 14.7.

1. Simulation:
   Der per MIG erzeugte DDR2 Core lässt sich mit ISim nicht simulieren, 
der Simulator stoppt mit einem Fehler "Signal phy_dout index is out of 
bound." Tatsächlich findet sich in der MIG-Doku der Hinweis, dass nur 
ModelSim unterstützt wird. Eine ModelSim Lizenz kommt für mein 
Hobbyprojekt nicht in Frage - kann ich evtl. einen anderen (freien) 
Simulator einsetzen?

2. Erstellen einer Netzliste:
   Es muss wohl möglich sein, aus den per MIG generierten Sourcen eine 
Netlist-Datei einmalig zu erstellen und in das Projekt einzubinden. Kann 
jemand das Vorgehen dazu kurz skizzieren?

(BTW: Die von Digilent in 
https://reference.digilentinc.com/_media/nexys4-ddr:ram2ddr_refcomp.zip 
bereitgestellte Datei hat einen Bug).

3. Timing:
   Digilent gibt die Cycle-Time 
(https://reference.digilentinc.com/nexys4-ddr:sram) mit 210 (tRC) bzw. 
260 (tWR) ns an. Tatsächlich gemessen habe ich für den Lesezyklus ca. 
350 ns, mit gelegentlichen Ausreissern (> 400 ns) nach oben (vom Anlegen 
des CEN Signals bis zur Assertion von RD_DATA_VALID des MIG UIs - bei 
Verwendung des RAM2DDRxadc Moduls von Digilent). Die Zeit für einen 
Schreibzyklus kann ich mit meinem Mitteln leider nicht messen; sie 
scheint aber unter der fürs Lesen zu liegen.

   Hat evtl. jemand die Zeit für einen Schreibzyklus gemessen oder per 
Simulation ermittelt?

   Meine Anwendung erzeugt 2x16 bit (Audio-)Daten mit 1 MSps/s die per 
FFT analysiert und später auf 200 kSps/s reduziert ausgegeben werden. 
Bei den oben dargestellten Zugriffszeiten muss ich die aus dem RAM 
gelesenen Daten (Burstlänge 8) in einem FiFo zwischenspeichern. 
Hinsichtlich des Timings ist der Ersatz von SRAM durch DDR2 ein eher 
enttäuschender Rückschritt.

   Nur so nebenbei: Digilent umgeht in seinem Referenzdesign für das 
Board mögliche Timingprobleme durch eine fest eingestellte Wartezeit von 
1200 ns (sic!) vor Ausgabe des ACK-Signals.

Gruß,
Burkhard

[Duke Scarring (Gast)]

Ich habe auch ein Nexys4, aber die Variante mit dem PSRAM.
Bis zum externen Speicher bin ich aber noch nicht vorgedrungen...

Burkhard K. schrieb:
> 1. Simulation:
>    Der per MIG erzeugte DDR2 Core lässt sich mit ISim nicht simulieren,
> der Simulator stoppt mit einem Fehler "Signal phy_dout index is out of
> bound."
Erzeugt der MIG 'normale' Netzlisten zum Simulieren oder irgendwas 
verschüsseltes/proprietäres?

> Tatsächlich findet sich in der MIG-Doku der Hinweis, dass nur
> ModelSim unterstützt wird. Eine ModelSim Lizenz kommt für mein
> Hobbyprojekt nicht in Frage - kann ich evtl. einen anderen (freien)
> Simulator einsetzen?
Du kannst GHDL probieren. Ich weiß nicht, ob es bei Altera noch 
ModelSim-AE gibt. Aber der Fehler sieht nach einem kaputten Design bzw. 
kaputtem Modell aus. Da sollte ein anderer Simulator die gleiche 
Fehlermeldung bringen.

Duke

[Burkhard K. (buks)]

Duke Scarring schrieb:

> Erzeugt der MIG 'normale' Netzlisten zum Simulieren oder irgendwas
> verschüsseltes/proprietäres?
Eine *.ngc Datei kann ich nicht finden, dafür aber ein Verzeichns 
"user_design" mit Verilog Sourcen, die bei der Synthese gelesen werden. 
Siehe auch meine zweite Frage zur Erzeugung einer Netlist-Datei.

>
Aber der Fehler sieht nach einem kaputten Design bzw.
> kaputtem Modell aus. Da sollte ein anderer Simulator die gleiche
> Fehlermeldung bringen.
Zu dieser Vermutung würden die ca. 2300 Warnungen passen, mit denen mich 
Synthese und Implementation überschütten.

Burkhard

[Matze (Gast)]

Hallo Burkhard,

Habe auch ein Nexys4 Board und möchte den DDR2-Ram ansteuern.
Wenn ich es richtig lese hast du es geschafft den Ram anzusteuern, 
zumindest als SRAM.
Dabei soll Vivado 15.4 genutzt werden.

Wie hast du dass geschafft?

Ich habe nun verschiedene Varianten versucht:

1. Mit MIG7 das DDR-Interface so wie hier:
https://reference.digilentinc.com/nexys4-ddr:sram
vorgesehen einzustellen und den Ram als DDR-Ram zu nutzen.

2. Ein Demoprojekt welches DDR-Ram nutzt als Basys für mein eigenes 
Projekt zu nutzen.

3. Die auf der Seite vorgesehene refferenz Komponente nutzen, sie 
richtig verbinden:
z.b. mit PLL für clk_200MHz_i und einem Ablauf bei dem ich versuche den 
RAM so wie es mit sinvoll erscheint anzusprechen:

    RD_DATA: process(CLK100MHZ)
    variable counter : integer;
    variable counter_langsam : integer;
    begin
        if rising_edge(CLK100MHZ) then
            counter := counter + 1;
            if counter = 200000000 then
                counter :=0;
                counter_langsam := counter_langsam + 1;
                if counter_langsam = 11 then
                    counter_langsam :=0;
                end if;
            end if;
            if counter_langsam = 0 then
                LED <= "0000000000000001";
                schreibdaten <= x"0FA5";
                cen <='0';
                read_en <= '0';
                write_en <= '0';
                ub <= '0';
                lb <= '0';
            elsif counter_langsam = 1 then
                LED <= "0000000000000010";
                schreibdaten <= x"0FA5";
                cen <='0';
                read_en <= '0';
                write_en <= '1';
                ub <= '1';
                lb <= '1';
            elsif counter_langsam = 2 then
                LED <= "0000000000000100";
                schreibdaten <= x"0FA5";
                cen <='1';
                read_en <= '0';
                write_en <= '1';
                ub <= '1';
                lb <= '1';
            elsif counter_langsam = 3 then
                LED <= "0000000000001000";
                schreibdaten <= x"0000";
                cen <='0';
                read_en <= '0';
                write_en <= '1';
                ub <= '1';
                lb <= '1';
            elsif counter_langsam = 4 then
                LED <= "0000000000010000";
                schreibdaten <= x"0000";
                cen <='0';
                read_en <= '0';
                write_en <= '0';
                ub <= '0';
                lb <= '0';
            elsif counter_langsam = 5 then
                LED <= "0000000000100000";
                schreibdaten <= x"0000";
                cen <='0';
                read_en <= '1';
                write_en <= '0';
                ub <= '1';
                lb <= '1';
            elsif counter_langsam = 6 then
                LED <= "0000000001000000";
                schreibdaten <= x"0000";
                cen <='1';
                read_en <= '1';
                write_en <= '0';
                ub <= '1';
                lb <= '1';
            elsif counter_langsam = 7 then
                LED <= "0000000010000000";
                schreibdaten <= x"0000";
                cen <='1';
                read_en <= '1';
                write_en <= '0';
                ub <= '1';
                lb <= '1';
                LED <= lesedaten;
            elsif counter_langsam = 8 then   
                LED <= "0000000100000000";
                schreibdaten <= x"0000";
                cen <='0';
                read_en <= '1';
                write_en <= '0';
                ub <= '1';
                lb <= '1';
            elsif counter_langsam > 9 then   
                LED <= "0000001000000000";
                schreibdaten <= x"0000";
                cen <='0';
                read_en <= '0';
                write_en <= '0';
                ub <= '0';
                lb <= '0';
            else 
                LED <= x"0000";
                cen <='0';
                read_en <= '0';
                write_en <= '0';
                ub <= '0';
                lb <= '0';
            end if;
        end if;
    end process;

Doch im grunde spielt es keine Rolle welchen weg ich wähle, es treten 
immer an die 1000 Info's, von denen nicht wenige auf Fehler innerhalb 
des MIG-Erzeugten Verilogs hindeuten.

Dies führt zu etwa 500 Warnungen, verschiedenster Art, die aber 
sicherlich aufzeigen, dass es so nicht gehen kann.

Es entstehen zwischen 100 und 200 Warnungen, z.b. der Form:

[Netlist 29-160] Cannot set property 'IN_TERM', because the property does not exist for objects of type 'pin'. ["d:...ram2ddr/ram2ddr.srcs/sources_1/ip/ddr/ddr/user_design/constraints/ddr.xdc":34]

Sowas sollte doch nicht vorkommen, wozu bekommt man vordefinierte 
UCF-Files für das Pining?

Letztendlich gibt es beim Bitstream generieren Fehler, diese sind von je 
mach Fall verscienener Art, besonders was den Clk_eingang der 200MHz 
angeht.

[J. S. (engineer)]

Burkhard K. schrieb:
> Hat jemand hier im Forum ein Nexys4-DDR Board in Betrieb?
Auf dem Atlys

>    Der per MIG erzeugte DDR2 Core lässt sich mit ISim nicht simulieren,
das ist keine so wirklich neue Information
ISIM wird von Xilinx aus irgendeinem mir nicht verständlichen Grund 
nicht vollständig gepflegt. Im Bereich SERDES und GBT habe ich weitere 
Beispiele, wo man mit ISIM nicht weiterkommt und nur ModelSIM das kann.


>    Es muss wohl möglich sein, aus den per MIG generierten Sourcen eine
> Netlist-Datei einmalig zu erstellen und in das Projekt einzubinden. Kann
> jemand das Vorgehen dazu kurz skizzieren?
Du musst das user design entsprechend anpassen. Meistens muss man einen 
internen Takt benutzen, der aus einer eigenen PLL kommt, oder sich an 
die des DDR-CTRL dranhängen.


> Meine Anwendung erzeugt 2x16 bit (Audio-)Daten mit 1 MSps/s die per
> FFT analysiert und später auf 200 kSps/s reduziert ausgegeben werden.
Warum wird die so hoch gesampelt? Wenn man eine Steigerung der Auflösung 
möchte, muss man in der Regel auch die Bitbreite anpassen. 24 Bit wären 
bei Audio ohnehin Pflicht.

> Bei den oben dargestellten Zugriffszeiten muss ich die aus dem RAM
> gelesenen Daten (Burstlänge 8) in einem FiFo zwischenspeichern.
> Hinsichtlich des Timings ist der Ersatz von SRAM durch DDR2 ein eher
> enttäuschender Rückschritt.

Eigentlich würde man bei FFTs eher die Blockrams nehmen. Wenn Du später 
runtersampelst, müssen bei 200kHz x Stereoaudio aber ein SRAM 100mal 
reichen (?)

Ungeachtet dessen, willst Du sicher den DDR-CRTRL ins Laufen bekommen.
Hast Du die Möglichkeit, einen physischen Test zu machen? Einfach mal 
statisch reinschreiben und rausschreiben, ohne großartige 
Zugriffskontrolle?

[Josef G. (bome)]

Ich habe zwar kein Nexys4, aber vielleicht ist
in diesem Zusammenhang folgendes interessant:

Bei der Realisierung meines 8bit-Computers auf dem Spartan-3A-Starterkit
hatte ich das Problem, das DDR2-RAM (MT47H32M16) als Ersatz für ein SRAM
verwenden zu müssen. Der Zeitablauf besteht aus einer Folge von Halb-
zyklen tA und tB, welche jeweils 320 ns dauern. Der Speicherzugriff
durch die CPU erfolgt während tA, der Refresh während tB.

Ich habe das Problem ohne Verwendung des MIG so gelöst: Bei
der Initialisierung des RAMs habe ich eingestellt Burstlänge 4. Bei
den Speicherzugriffen verwende ich Auto-Precharge. Die 4 Datenworte
eines Bursts werden als ein einziges Datenwort behandelt: Beim
Schreiben erhalten alle 4 Worte denselben Wert. Das Lesen erfolgt
irgendwo im Inneren des Bursts. Man braucht keine DDR-Flipflops,
und das Timing beim Lesen vereinfacht sich drastisch. Ich habe
nicht einmal Timing-Constraints gebraucht. Ein theoretisch
denkbares Glitch-Problem beim Lesen ist nie aufgetreten.

Siehe Datei ps3a.vhd auf der Seite Downloads meiner Website:
http://www.bomerenzprojekt.de

[Burkhard K. (buks)]

Hallo Matze,

den DDR2 habe ich inzwischen eigenem Controller in Benutzung (mit 
ISE14.7). Die Anzahl der Warnungen ist Legion (> 1700). Simulieren ist 
nicht (s.oben). PAR schmeisst zwei Timing-Violations aus den Tiefen des 
PHY-Layers, die ich aber als unkritisch einstufe (Temperatur-Kontrolle).

Mein Controller-Design habe ich aus Digilentics Referenzkomponente 
https://reference.digilentinc.com/_media/nexys4-ddr:ram2ddr_refcomp.zip 
(ram2ddrxadc.vhd) abgeleitet. Die Referenz-Komponente basiert auf dem 
MIG-UserInterface.

Gestört hat mich an Digilents ram2ddrxadc.vhd insbeondere das sehr 
langsame Timing und die fest eingestellte Wartezeit (1200 ns bis zum 
RAM-ACK). Um ein für meine Anwendung brauchbares Timing zu realisieren, 
habe ich einge Anpassungen vorgenommen:

  * den vorgeschalteten SRAM Controller eingedampft
  * die Steuer-Eingänge (ram_cen, ram_rnw) nach ram2ddrxadc.vhd 
übernommen und dort registriert
  * die Steuersignale "rd_data_valid" bzw. "mem_rdy" für die Erzeugung 
der ACK-Signale ausgewertet
  * eine fixe Datenbreite von 32 Bit eingestellt, wodurch sich das 
Setzen der WDF-Maske erheblich vereinfacht
  * und schliesslich das MIG Interface auf 2:1 Mode umgestellt so dass 
sich die Zugriffszeiten für einzelne Schreib- ( < 100 ns) Lesezugriffe 
(ca. 200 ns) erheblich verkürzen
  * einen Arbiter mit fixer Priorität (Schreiben) integriert

Das MIG-UserInterface läuft mit 75 MHz (4:1 Mode) bzw. 150 MHz (2:1) bei 
eingestellter 3333 ps DDR2-Clock. Daher müssen die Kontroll-Signale im 
User-Design einsynchronisiert werden - bei 150 MHz zusätzlich noch 
gestreckt werden.

Da ich nicht simulieren kann (s.o.) musste ich die relevanten 
Steuersignale auf einen Pmod-Port legen und per USB-Logicanalyzer 
anschauen (Mein Hobby-Bastel Analog-Discovery kann 10 ns Auflösung 
gerade noch so). Zum Testen und Verifizieren habe ich die Daten über die 
16 Schiebeschalter eingegeben, die Address-Eingabe per an einen Pmod 
angeschlossen Drehgeber realisiert, die 27bit Adresse auf der 
7-Segmentanzeige ausgegeben.

@Jürgen - ich analysiere Ultraschalldaten bis ca. 200 kHz - 5faches 
Oversampling scheint mir dafür angemessen. Für die (hörbare) Ausgabe der 
heruntergemischten bzw. Frequenz-transponierten Signale verwende ich 
"normale" Audio-Samplingraten. HiFi spielt in diesem Zusammenhang keine 
Rolle, 16bit Datenbreite reicht aus.

Gruß,
Burkhard

[Matze (Gast)]

Burkhard K. schrieb:
> Hi Matze, das mem_rdy Signal des UserInterfaces ist tatsichlich 99% der
> Zeit auf '1', bewegt sich aber doch auf '0' - nämlich bei zwei
> Gelegenheiten:
>
>   * sobald das Write Kommando akzeptiert wurde, also als Reaktion auf
> das Setzen von "mem_wdf_wren" UND "mem_wdf_end"

Stimmt, das konnte ich nun auch nachvollziehen.

Burkhard K. schrieb:
> Wenn Dein "debug"-Signal in einer anderen
> Clk-Domäne weiterverarbeitet wird, muss es noch einsynchronisiert
> werden, die mem_ui_clk läuft mit einem Viertel  bzw. der Hälfte (2:1
> Mode) der DDR2 Clk.

Würde es von einem anderen CLK getaktet müsste es einsyncronisiert 
werden.
Werde von daher erstmal den ui_clk als Systemtackt nutzen.
Der ui_clk läuft etwa mit 150MHZ.

Burkhard K. schrieb:
> Tatsächlich gibt es gleich mehrere mögliche Reihenfolgen, in denen
> Daten, WDF Maske und Schreibkommando präsentiert werden können, bitte am
> besten selbst im MIG User Guide, Abschnitt "User Interface" nachlesen -
> und zwar in der neuesten Version (Zynq-7000 AP SoC and 7 Series Devices
> Memory Interface Solutions v2.4)! In älteren Versionen des Dokuments ist
> die Abfolge unvollständig dargestellt, was mich einige Zeit gekostet
> hat.

Danke, dies ist der entscheidende Tipp, ich hatte ein unvollständiges 
Datenblatt und wusste so nicht genau in welcher Reihenfolge die Signale 
gesetzt werden müssen.

Habe schreiben/lesen nun deutlich verkürzen können.

Hiermit kann man den RAM lesen + schreiben

        if (rising_edge(ui_clk)) then
            if state = 0 then           --Idle
                addr <= address;
                cmd <= CMD_WRITE;
                en <= '0';
                wdf_mask <= "00000000";
                wdf_wren <= '0';
                wdf_data <= data_in;
                wdf_end <= '0';
                debug <=x"0"; 
                write_ok <= '0';
                read_ok <= '0';
                if wdf_rdy = '1' and rdy = '1' then -- MIG bereit
                    DDR2_rdy <= '1';--Controller bereit
                    if write_en = '1' and read_en = '0' then
                        state := 1; 
                    elsif write_en = '0' and read_en = '1' then
                        state := 2;
                    else 
                        state := 0;
                    end if;
               else
                    DDR2_rdy <= '0';                     --Controller ! bereit
               end if;
            elsif state = 1 then        --Schreiben
                addr <= address;
                cmd <= CMD_WRITE;
                en <= '1';
                wdf_mask <= "00000000";
                wdf_wren <= '1';
                wdf_data <= data_in;
                wdf_end <= '1';
                debug <=x"1"; 
                write_ok <= '1';
                read_ok <= '0';
                DDR2_rdy <= '0'; 
                state := 0;
            elsif state = 2 then        --Lesen
                addr <= address;
                cmd <= CMD_READ;
                en <= '1';
                wdf_mask <= "11111111";
                wdf_wren <= '0';
                wdf_data <= data_in;
                wdf_end <= '0';
                debug <=x"2"; 
                write_ok <= '0';
                DDR2_rdy <= '0'; 
                if rd_data_valid = '1' then
                    data_out <= rd_data;
                    read_ok <= '1';
                    state := 0;
                else 
                    read_ok <= '0';
                end if;
                
            else
                state := 0;
            end if;
        end if;
    end process;

Angesteuert wird das ganze Testhalber so:

            if state = "0000" then
                data_in <= address(26 downto 0) & x"000000000" & '0';
                if DDR2_rdy = '1' then
                    write_en <= '1';
                    read_en <= '0';
                    state <= "0001";
                end if;
                JC(1 downto 0) <= "01";-- Gelb, Blau, Lila
                JC(2)           <= '0';
            elsif state = "0001" then
                if write_ok = '1' then
                    write_en <= '0';
                    read_en <= '0';
                    state <= "0010";
                end if;   
                JC(1 downto 0) <= "10";
                JC(2)           <= '0';
            elsif state = "0010" then
                if DDR2_rdy = '1' then
                    data_in <= address(26 downto 0) & x"000000000" & '0';
                    write_en <= '0';
                    read_en <= '1';
                    state <= "0011";
                end if;
                JC(1 downto 0) <= "11";
                JC(2)           <= '0';
            elsif state = "0011" then
                 if read_ok = '1' then
                    write_en <= '0';
                    read_en <= '0';
                    LED(15 downto 0) <= data_out(63 downto 48);
                    disp_data(15 downto 0) <= data_out(47 downto 32);
                    address <= address + '1';
                    data_in <= address(26 downto 0) & x"000000000" & '0';
                    state <= "0000";
                end if;
                JC(1 downto 0) <= "00";
                JC(2)           <= '1';
            end if;

Problem ist der Lesezyklus, wie du es schreibst dauert er bei mir gut 
400ns, da die Gültigkeit der daten ewig auf sich warten lässt.

Jedenfalls liegen die Signale

 JC(1 downto 0) <= "00";
 JC(2)           <= '1';

des so lange an.

Somit müsste es hierran liegen:

if rd_data_valid = '1' then

Aber es kann doch nicht sein, dass der DDR-Controller so extrem langsam 
liest. Was bringen 128MByte DDR2 wenn man nur mit Einstelliger MB/s- 
Datenrate davon lesen kann?

Schreiben scheint um ein vielfaches schneller zu gehen.

Somit hast du völlig Recht:
Burkhard K. schrieb:
> 3. Timing:
>    Digilent gibt die Cycle-Time
> (https://reference.digilentinc.com/nexys4-ddr:sram) mit 210 (tRC) bzw.
> 260 (tWR) ns an. Tatsächlich gemessen habe ich für den Lesezyklus ca.
> 350 ns, mit gelegentlichen Ausreissern (> 400 ns) nach oben (vom Anlegen
> des CEN Signals bis zur Assertion von RD_DATA_VALID des MIG UIs - bei
> Verwendung des RAM2DDRxadc Moduls von Digilent). Die Zeit für einen
> Schreibzyklus kann ich mit meinem Mitteln leider nicht messen; sie
> scheint aber unter der fürs Lesen zu liegen.

Hast du schon versucht den DDR-Controller MIG7 IP-Block von Hand 
anzulegen.
Dass werd ich nun mal versuchen.

[Josef G. (bome)]

Duke Scarring schrieb:
> Ich habe auch ein Nexys4, aber die Variante mit dem PSRAM.

Ist zwar OT, aber ich häng mich mal hier mit einer Frage dran:

Mir ist aufgefallen, dass Digilent innerhalb kurzer Zeit die Boards
Nexys2/Nexys3/Nexys4 mit PSRAM vom Markt genommen hat, obwohl die
FPGAs darauf verschiedenen Generationen angehören. Offenbar lag's
nicht an veralteten FPGAs (Spartan-3E beim Nexys2), sondern an
den PSRAMs. Weiss jemand, was es damit auf sich hat? Werden
diese RAMs nicht mehr hergestellt?

[Josef G. (bome)]

Korrektur:

Das Nexys3 und Nexys4 mit PSRAM gibt es noch, aber "Limited Time".

[Michael W. (Gast)]

Hat sich das mit dem Speicherproblem geklärt?

[Burkhard K. (buks)]

M. W. schrieb:
> Hat sich das mit dem Speicherproblem geklärt?

Ich selbst habe den DDR2-Speicher im 2:1 Modus - nach einigen "Gotchas" 
(MIG-7 - die Doku ist extrem dünn und in älteren Versionen 
unvollständig) - im Einsatz; Matze soweit ich lese ebenso. Das Digilent 
"Referenz-Design" ist ein schlechter Witz. Was genau willst Du wissen?

MIG: Was immer noch nervt, ist die Nichtsimulierbarkeit mit ISIM und die 
in die Tausenden gehenden Warnungen aus diesem IP-Block. Implementieren 
mit MIG im Design dauert ewig (gefühlt +10 Minuten). Leider habe ich es 
bisher nicht hinbekommen, das MIG User Interface für den Speicher 
vorsynthesiert in eine .ngc Datei zu packen (ISE). Noch genialer wäre 
es, wenn sich der ganze MIG Kram vorimplementiert (PAR) auf den FPGA 
klatschen liesse und ich mein restliches Design anschliessend darum 
bauen könnte. Für einen Tip in diese Richtung wäre ich dankbar.

Gruß,
Burkhard

[Christian R. (supachris)]

Das Nexsys 4 ist doch ein Artix Board, wieso nutzt ihr dann ISE? In 
Vivado kann man den Mig simulieren, geht zwar langsamer als Modelsim 
aber immerhin. Doku ist beschissen aber anhand des Example Designs 
kriegt man das hin. Den 2:1 Modus sollte man meiner Meinung nach nur 
nutzen, wenn man auf Schmerzen steht. Im 4:1 ist das wenigstens halbwegs 
sinnvoll, da kann man einfach beim Schreiben den Fall 1 nehmen, und 
Daten, Adresse, app_en wdf_end und wren gleichzeitig setzen.
Klar, beim Sdram hat man immer Latenz, wenn man nur einen Burst liest, 
ist das langsam, aber wenn es einmal los ging kommen die Daten 
hintereinander.

[Burkhard K. (buks)]

Christian R. schrieb:
> Den 2:1 Modus sollte man meiner Meinung nach nur
> nutzen, wenn man auf Schmerzen steht.

Danke für die Blumen - Du hast im Thread meine Requirements gelesen? Was 
nützt mir der vermeintlich einfachere Transfer, wenn das Timing nicht zu 
gebrauchen ist?
2:1 Mode: Eine zusätzliche UI_Clock Periode und 4 Zeilen Code mehr - das 
piekst nur ganz sanft - sobald man mal weiss wie's geht.

   MEM_WR_CTL: process(cState, ram_wrm_int)
   begin
      -- first transmission - upper address part transferred during BL8
      -- these part must be masked completely to prevent unintended
      -- overwrite at app_addr(7 downto 4)
      if cState = stSendData then
         mem_wdf_wren  <= '1';
         mem_wdf_end   <= '0';
         mem_wdf_mask   <= "11111111";
 
      -- second transmission - lower address part transferred during BL8
      -- contains 32bit payload
      -- mask non-payload data at app_addr(3 downto 2)
      elsif cState = stSendData2 then
         mem_wdf_wren  <= '1';
         mem_wdf_end   <= '1';
         mem_wdf_mask   <= "1111" & "0000";
      else
         mem_wdf_wren  <= '0';
         mem_wdf_end    <= '0';
         mem_wdf_mask   <= "11111111";
      end if;
   end process MEM_WR_CTL;

Für ISE hab ich meine Gründe - z.B. hätte mein Design von dem ganzen 
AXI-Geraffel nur den Overhead - aber keinen Vorteil (ausser dass ich 
eine Handvoll IP-Blöcke grafisch in das Design klicken könnte).

Gruß, Burkhard

[Christian R. (supachris)]

Man kann Vivado und dort auch den MIG komplett ohne Axi benutzen. Ivh 
mag Axi auch nicht und benutze es nicht. Aber ISE und Artix war wirklich 
nur eine Krücke. Das mit dem Timing verstehe ich nicht ganz, DDR Sdram 
braucht halt prinzipiell eine gewisse Latenz, dafürgibts Buffer. Jeder 
B8L einzeln mag dann mit 2:1 besser gehen, richtig.

[Burkhard K. (buks)]

Christian R. schrieb:
> Man kann Vivado und dort auch den MIG komplett ohne Axi benutzen.

Den MIG schon - aber divsere andere IPs (FIR-Compiler, CIC-Compiler, 
CORDIC, DDS-Compiler, XADC-Wizard etc.) gibt es - anders als in ISE - in 
Vivado offensichtlich nur noch mit AXI-Interface. Sollten sich in ISE 
vorhandene, ältere Versionen dieser IPs nach Vivado importieren, wäre 
das ein Grund mir Vivado noch mal anzuschauen.

Beim Timing gibt es nicht viel zu verstehen, wenn ich in einer 
Mikrosekunde je einen Schreib- und einen (oder sogar zwei) 
Lesezugriff(e) unterbringen muss, dann ist der 4:1 Modus mit der 
schlecht definierten Lesezeit von 400 ns und darüber zu dicht am Limit.

[Christian R. (supachris)]

OK, manche Cores gibts nur noch mit Axi, stimmt, aber Axi Streaming ist 
auch nur ein simples FIFO Interface. Ich hab mit ISE und dem Artix ganz 
schlechte Erfahrungen gemacht, dauert alles lange, Simulation klappt 
nicht, da bin ich dann auch auf Vivado umgestiegen. Hat auch Macken, 
aber für die 7er einfach besser als ISE.

Klar, wenn du nicht puffern kannst, ist der 2:1 besser. Ich finde den 
halt bissl seltsam, passt nicht so recht zu meinem Interface und 
außerdem braucht der bei DDR400 den 3er Speedgrade. Timing ist schon bei 
4:1 irre, aber bei 2:1 mit DDR400 aufm Artix schon echt schwierig.
Daher umgehe ich den wo es geht. ;)