Xilinx MIG Userinterface Doku

[René D. (Firma: www.dossmatik.de) (dose)]

Ich habe jetzt den externen Speicher am Laufen.
Leider habe ich bisher keine Dokumentation für die Signale am 
Userinterface gefunden.
Das Beispieldesign rödelt ein paar Schreib- und Lesezykluse durch. Doch 
jetzt will ich den Zugriff erweitern und ich habe keine Beschreibung, zu 
den ganzen Signalen die ich bewackeln muss, gefunden.

Wie lange muss das Command gehalten werden? Wie wird ein Burst 
aktiviert?  usw..

Da ist noch was offen und würde gerne ein paar Taktdiagramme und 
Erläuterungen studieren.

[G.A. (Gast)]

wie aus der anleitung für den ip core hervorgeht, gibt es für jeden 
bidirektionalen port des MIG-Core jeweils 3 fifos. 1 schreibfifo, 1 
lesefifo, 1 commandfifo!

ablauf schreiben:

1.datenwörter an schreibfifoeingang anlegen und jeweils wr_enable so 
lange high wie du wörter schreiben willst. ps es gibt die möglichkeit 
bytes eine datenworts zu maskieren, d.h. die werden dann nicht 
geschrieben. dafür gibt es zusätzlich den eingang wr_mask.

2.burstlänge (0 = 1 datenwort, usw..), startadresse und cmd_instruction 
(1 = lesen, 0 schreiben... achtung nachrpüfen bin mir nicht mehr sicher) 
an die entsprechenden einänge des commandfifos anlegen.

3. cmd_en ein takt hoch.

4. ca 22 takte später (irgendwie sowas) sind die daten im ram

ablauf lesen.

1. burstlänge, startadresse für auslesevorgang an commandfifoeingänge 
anlegen.

2. cmd_en 1 takt hoch.

3. warten bis das empty vom lesefifo von high auf low geht.

4. rd_en vom lesefifo entsprechend der anzahl der burstlänge so viele 
taktzyklen auf high und datenwörter am datenausgang vom lesefifo 
ablesen.

das ganze auch etwas komplizierter im xilinx ug388 nachlesen.

[René D. (Firma: www.dossmatik.de) (dose)]

So habe ich es auch verstanden.
Ich habe ein Simulation, leider nicht mehr am laufen.

Da sah es aus, als könnte auch zuerst das Commando geschrieben werden 
und dann die Daten.

[G.A. (Gast)]

beim schreiben müssen erst daten im schreibfifo sein. sonst schreibst du 
nur schrott bzw den defaultwert ins ram. zum lesen ist es logischerweise 
anders herum. erst commandos, dann daten auslesen (dann sind übrigens 
immer so ca 30 taktzyklen dazwischen bevor die ersten daten im lesefifo 
erscheinen, egal ob du nen 63 burst-read machst oder nen single-read). 
bei mir funktioniert der ramcore seit monaten so.

[Hans-Georg L. (h-g-l)]

Der MIG kann eine Beispielanwendung generieren.
Die musst du dann nur noch finden, die ist gut versteckt ;)

Der Beispielcode wird default in Verilog generiert, man kann aber auch 
VHDL einstellen. Da war ein BUG und man musste bei jeder Änderung mit 
dem MIG VHDL neu auswählen. Auch wenn die Einstellung VHDL angezeigt 
hat.
Keine Ahnung ob das bei der aktuellen Version behoben ist.

[René D. (Firma: www.dossmatik.de) (dose)]

Ich hatte das Thema noch umgesetzt und habe es wieder aufgegriffen.
Da es einfach nicht richtig erklärt wird.

Also mein gegenwärtiger Wissenstand ist:

Am MIG gibt es drei Datenströme.

Read, Write, Command.

Verstehe ich das Richtig?
Wenn ich was in den Write Datenstrom  mit Enable reinschreibe wird noch 
nichts auf den externen RAM geschrieben.

Erst wenn ich mit Command ein Schreiben nachschiebe?!!!

Das ist ja oberdoof, dann muss ich doch  noch eine Statemaschine vor den 
MIG-RAM Controller setzen. Ich dachte das ist ein Controller der das von 
selbst gebacken bekommt.

[Christian R. (supachris)]

Hm, nee zumindest beim 7er MIG für DDR2/DDR3 muss das Kommando nur 
anliegen. Da gibts auch nur Lesen oder Schreiben. Dann Enable und die 
Adressen und Daten reinschreiben wenn frei, oder halt lesen wenn valid. 
Jedenfalls beim Nicht-Axi Interface. Ich habs selber noch nicht 
gebraucht, aber für ein neues Projekt musste ich mir die Doku schon mal 
reinziehen (UG586 war es glaube ich).

[hunz (Gast)]

René D. schrieb:
> Verstehe ich das Richtig?
> Wenn ich was in den Write Datenstrom  mit Enable reinschreibe wird noch
> nichts auf den externen RAM geschrieben.
>
> Erst wenn ich mit Command ein Schreiben nachschiebe?!!!
>
> Das ist ja oberdoof, dann muss ich doch  noch eine Statemaschine vor den
> MIG-RAM Controller setzen. Ich dachte das ist ein Controller der das von
> selbst gebacken bekommt.

Das ist schon so und das macht auch durchaus Sinn.
Der Controller schiebt die Daten ja mit bis zu 800MHz xDatenbreite raus, 
mit der Geschwindigkeit müsste man ohne FIFO dann auch die Daten für 
einen Burst anlegen damit es keinen underrun gibt. Und der Controller 
muss dazwischen auch mal andere Dinge tun, z.B. sich um refresh kümmern, 
er kann also nicht immer sofort tun was der Userport gerade will.
Daher gibt es die Datenfifo und read/write Kommando.
Man kann das Kommando aber angelegt lassen und cmd_en einfach kurz 
pulsen wenn man genug Worte für den Burst in der Fifo hat.

[René D. (Firma: www.dossmatik.de) (dose)]

Ich habe meinen eigen Teil zusammengefügt.
Leider Läuft die Sache nicht so richtig.
Nach weiter Untersuchung habe ich jetzt das Problem gefunden.

Das Signal CMD_full ist immer high.

Zugleich ist das Signal CMD_empty auch high.


full und empty zugleich!?

Hat jemand eine Idee?

[Duke Scarring (Gast)]

René D. schrieb:
> full und empty zugleich!?
Da habe ich nur eine philosophische Antwort: Die Größe des Command-FIFO 
muss '0' sein, um diese Bedingung erfüllen zu können. :-/

Vielleicht ist auch was mit dem Timing nicht in Ordnung?

Duke

[Christian R. (supachris)]

Oder Reset ist aktiviert. Bei den "normalen" IP COre FIFOs ist beim 
Reset auch EMPTY = '1' und FULL = '1' jedenfalls in der 
Default-Einstellung.

[René D. (Firma: www.dossmatik.de) (dose)]

Christian R. schrieb:
> Oder Reset ist aktiviert. Bei den "normalen" IP COre FIFOs ist beim

Den Reset habe ich auch schon in Verdacht. Den MIG habe ich mir schon 
mal genauer angeschaut. Er benutzt hier Componenten, die in keiner Doku 
bei Xilinx auftauschen.

[Fpgakuechle K. (Gast)]

René D. schrieb:

> Den Reset habe ich auch schon in Verdacht. Den MIG habe ich mir schon
> mal genauer angeschaut. Er benutzt hier Componenten, die in keiner Doku
> bei Xilinx auftauschen.

Welche undokumentierten Komponenten meinst Du?
Welcher FPGA-Typ/Familie?

MfG,

[René D. (Firma: www.dossmatik.de) (dose)]

Fpga Kuechle schrieb:

> Welche undokumentierten Komponenten meinst Du?
> Welcher FPGA-Typ/Familie?
> Spartan 6

Es gibt für jeden Port eine Komponente "px_cmd_ena". Per generate wird 
diese aktiviert.

Jetzt mein Problem, da geht gar kein Reset mit ran?!
Da kommen die Signale cmd_empty und cmd_full raus.
Das ist gerade meine Black box.

    -- the local declaration of input port signals doesn't work.  The mig_p1_xxx through mig_p5_xxx always ends up
    -- high Z even though there are signals on p1_cmd_xxx through p5_cmd_xxxx.
    -- The only solutions that I have is to have MIG tool remove the entire internal codes that doesn't belongs to the Configuration..
    --

    -- Inputs from Application CMD Port

    p0_cmd_ena : if (C_PORT_ENABLE(0) = '1') generate

      mig_p0_arb_en    <= p0_arb_en;
      mig_p0_cmd_clk   <= p0_cmd_clk;
      mig_p0_cmd_en    <= p0_cmd_en;
      mig_p0_cmd_ra    <= p0_cmd_ra;
      mig_p0_cmd_ba    <= p0_cmd_ba;
      mig_p0_cmd_ca    <= p0_cmd_ca;
      mig_p0_cmd_instr <= p0_cmd_instr;
      mig_p0_cmd_bl    <= ((p0_cmd_instr(2) or p0_cmd_bl(5)) & p0_cmd_bl(4 downto 0));
      p0_cmd_empty     <= mig_p0_cmd_empty;
      p0_cmd_full      <= mig_p0_cmd_full;
    end generate;