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.
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.
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.
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.
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.
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.
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).
:
Bearbeitet durch User
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.
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?
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
Oder Reset ist aktiviert. Bei den "normalen" IP COre FIFOs ist beim Reset auch EMPTY = '1' und FULL = '1' jedenfalls in der Default-Einstellung.
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.
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,
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.
1 | -- the local declaration of input port signals doesn't work. The mig_p1_xxx through mig_p5_xxx always ends up
|
2 | -- high Z even though there are signals on p1_cmd_xxx through p5_cmd_xxxx.
|
3 | -- The only solutions that I have is to have MIG tool remove the entire internal codes that doesn't belongs to the Configuration..
|
4 | --
|
5 | |
6 | -- Inputs from Application CMD Port
|
7 | |
8 | p0_cmd_ena : if (C_PORT_ENABLE(0) = '1') generate |
9 | |
10 | mig_p0_arb_en <= p0_arb_en; |
11 | mig_p0_cmd_clk <= p0_cmd_clk; |
12 | mig_p0_cmd_en <= p0_cmd_en; |
13 | mig_p0_cmd_ra <= p0_cmd_ra; |
14 | mig_p0_cmd_ba <= p0_cmd_ba; |
15 | mig_p0_cmd_ca <= p0_cmd_ca; |
16 | mig_p0_cmd_instr <= p0_cmd_instr; |
17 | mig_p0_cmd_bl <= ((p0_cmd_instr(2) or p0_cmd_bl(5)) & p0_cmd_bl(4 downto 0)); |
18 | p0_cmd_empty <= mig_p0_cmd_empty; |
19 | p0_cmd_full <= mig_p0_cmd_full; |
20 | end generate; |
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.