Hallo. Ich habe folgendes Projekt. Gekauftes FPGA-Board (Trenz electronic) mit Spartan6 und 2 * DDR3-RAM. An diesem Board ist ein Controller (SH2A von Renesas) per SDRAM-Schnittstelle angeschlossen. Ich kann nun vom Controller aus (über den Spartan 6, habe hier ein SDRAM-Interface programmiert) ins DDR3-RAM schreiben (geht über den internen Memory-Core den der Spartan 6 schon fest eingebaut hat) und auch daraus lesen. Funktioniert eigentlich ganz gut. Ab und zu erhalte ich jedoch falsche RAM-Inhalte. Beim nächsten lesen stimen diese dann wieder. Es sind immer wieder die "gleichen falschen" Werte. Kann es damit zusammenhängen, dass das DDR3-RAM in diesem Moment gerade einen Refresh durchführt, während ich lesen möchte? Der Refresh ist auf Auto eingestellt. Wenn das so wäre, wie kann ich dies umgehen?. Ein Ansatz hätte ich. Mein Controller gibt ja über die SDRAM-Schnittstelle auf Refresh-Zyklen aus. Diese könnte ich dann in dem Moment auf die beiden DDR3-RAM's geben. Somit wäre das ganze synchron. Den Auto-Refresh vom DDR3 RAM ändere ich dann auf manuell. Wäre das ein Ansatz? noeppkes ...
Christian Armbruster schrieb: > Kann es damit zusammenhängen, dass > das DDR3-RAM in diesem Moment gerade einen Refresh durchführt, während > ich lesen möchte? Nein, das kann es nicht sein. Ich würde nochmal überprüfen ob alle Initialsierungswerte für den DDR3 und Pineinstellungen für den FPGA stimmen. Z.B. Mit dem Referenzdesign vergleichen.
Klingt eher nach einem Kommunikationsproblem der CPU mit dem Memorycontroller.
Oder dein Takt ist immer noch zu schnell und durch unzureichende Constraint-Abdeckung wird er durch die statische Timing-Analyse nicht angemeckert....wie schnell läuft denn das Design jetzt?
Georg A. schrieb: > Klingt eher nach einem Kommunikationsproblem der CPU mit dem > Memorycontroller. Hallo Georg. Nein. Habe ich mit dem Oszi gemessen. Die Signale sind sauber, und werden auch richtig ausgewertet. nieppkes ...
Christian R. schrieb: > Oder dein Takt ist immer noch zu schnell und durch unzureichende > Constraint-Abdeckung wird er durch die statische Timing-Analyse nicht > angemeckert....wie schnell läuft denn das Design jetzt? Hallo Christian R. Schön wieder von dir zu hören. Der Takt beläuft sich jetzt auf 250 Mhz. Habe jetzt insgesamt 3 Takte. 2 Stk. für den Menory-Controller und einer für meine Logik (alle 250 Mhz). Diese werden mit einer PLL erzeugt. Ich habe man die DDR3_Read_Daten auf Pin's ausgegeben. Dabei ist mir aufgefallen, dass wenn ich einen Read an den DDR3-Controller gebe, die Read-Daten dann ganze kurz High sind, dann auf Low (was richtig ist) fallen. Das High ist etwa 190 nsec. lang. Durch min/max-Messung mit dem Scope kommt es aber ab und zu mal vor, dass das High der Datenleitung(en) 390 nsec. lang wird. Dann werde ich vermutlich auch ein High Controllerseitig einlesen. Das SDRAM-Interface habe ich schon auf das Maximun-Delay gesetzt. (etwas um die 400 nsec.). Ich denke dass dies das Problem ist. Warum ist mir aber noch nicht klar. noeppkes ...
Hallo zusammen. Bin nun mal einen Schritt weitergekommen. Takt für den DDR3-Core auf 312,5 Mhz eingestellt. Der Core verdoppelt diesen noch einmal auf 625 Mhz. Logiktakt auf 125 Mhz. reduziert. Das ergibt keine Timing Errors mehr. Nun sieht es so aus, dass mein Signal pX_rd_empty für 200 nsec. auf high geht. Ich vermute mal, dass dies die Lesezeit vom DDR3-Core ist. Mein an den FPGA angeschlossener Controller erwartet die Daten in etwa in 200nsec. Später --> Lesefehler. Genau so sieht es auch aus. Ab und zu benötigt der DDR3-Core mehr als 200 nsec. Das pX_rd_empty signal ist dann länger high. Bis zu 380 nsec im Worst-Case Fall. Warum entstehen so unterschiedliche Zeiten? Ich denke immernoch an den Auto-Refresh vom DDR3. Kann dies die Lesezeiten so drastisch beeinflussen? Oder hat jemand noch eine andere Idee?. Die 2. Frage die sich mir stellt: Warum benötigt der DDR3-Core "so lange" zum lesen bzw. zum bereitstellen der Daten. 200 nsec und mehr sind ganz schön ordentlich bei 625 Mhz Takt. Rechnet man 200 nsec. auf die Takte um, so sind das 125 Takte. Sollte das nicht schneller gehen? noeppkes ...
Christian Armbruster schrieb: > Die 2. Frage die sich mir stellt: Warum benötigt der DDR3-Core "so > lange" zum lesen bzw. zum bereitstellen der Daten. 200 nsec und mehr > sind ganz schön ordentlich bei 625 Mhz Takt. Rechnet man 200 nsec. auf > die Takte um, so sind das 125 Takte. Sollte das nicht schneller gehen? Das ist nicht der Core, sondern der DDR Ram selbst. Besorg dir Datenblätter und schau mal das Timing an. Man kann keine feste Zugriffszeit erwarten, da spielen noch Dinge wie Precharge, Refresh etc rein.
Christian Armbruster schrieb: > Kann dies die Lesezeiten so drastisch beeinflussen? Ja. > Oder hat jemand noch eine andere Idee?. Bank switching könnte auch noch eine Rolle spielen. Wenn Du deterministische Zugriffszeiten brauchts, mußt Du z.B. einen QDR-SRAM nehmen. Bei DRAM puffert man die Zugriffe über einen FIFO... Duke
Hallo Lattice User. Jetztz bin ich aber leicht verwirrt. Du hast ein paar Posts weiter oben geschrieben: >>Christian Armbruster schrieb: >> Kann es damit zusammenhängen, dass >> das DDR3-RAM in diesem Moment gerade einen Refresh durchführt, während >> ich lesen möchte? > Nein, das kann es nicht sein. und jetzt: Lattice User schrieb: > Christian Armbruster schrieb: > Das ist nicht der Core, sondern der DDR Ram selbst. Besorg dir > Datenblätter und schau mal das Timing an. Man kann keine feste > Zugriffszeit erwarten, da spielen noch Dinge wie Precharge, Refresh etc > rein. Also spielt der Refresh doch eine Rolle. Ich habe von der Controllerseite her auch einen Refresh. Wenn ich diesen nun auf meinen DDR3-Core gebe, dann wären die beiden Synchron und der Refresh würde schon mal keine Rolle mehr spielen. Generell Takte ich den Core mit 312.5 Mhz an (Der Core verdoppelt, wie oben beschrieben, den Takt noch einmal.) Den Command Path, Write Path, Read path takte ich mit 125 Mhz. Ist das dann zu langsam? Hat aber ja eigentlich nichts mit dem Core zu tun oder? Das sind doch nur die Takteingänge für die FiFo's. noeppkes ...
Christian Armbruster schrieb: > Jetztz bin ich aber leicht verwirrt. > Du hast ein paar Posts weiter oben geschrieben: Weiter oben ging es um Lesefehler, von festen Zugriffszeiten bin ich da nicht ausgegangen, ich habe wie alle anderen angenommen dass dir bekannt ist dass ein DDR ein im Grunde asynchrones Interface hat. Missverständnisse kommen halt vor.
Christian Armbruster schrieb: > Also spielt der Refresh doch eine Rolle. > Ich habe von der Controllerseite her auch einen Refresh. Wenn ich diesen > nun auf meinen DDR3-Core gebe, dann wären die beiden Synchron und der > Refresh würde schon mal keine Rolle mehr spielen. Die anderen Dinge wie Precharge,Bankswitching aber immer noch. > > Generell Takte ich den Core mit 312.5 Mhz an (Der Core verdoppelt, wie > oben beschrieben, den Takt noch einmal.) > Den Command Path, Write Path, Read path takte ich mit 125 Mhz. Ist das > dann zu langsam? Hat aber ja eigentlich nichts mit dem Core zu tun oder? > Das sind doch nur die Takteingänge für die FiFo's. Beim DDR ist Commandpath und Datenpath getrennt und asynchron zueinander. Deswegen braucht der Core ja auch Fifos um mit Pipelining auf Geschwindigkeit zu kommen. Beim Lesen heisst das aber dass deine Logik wartem muss bis die Daten gültig sind.
Christian Armbruster schrieb: > Nun sieht es so aus, dass mein Signal pX_rd_empty für 200 nsec. auf high > geht. Durch wen? Wie hast Du diese Zeit gemessen? > Ich vermute mal, dass dies die Lesezeit vom DDR3-Core ist. Welche Lesezeit genau? > Mein an > den FPGA angeschlossener Controller erwartet die Daten in > etwa in 200nsec. Später --> Lesefehler. Das Lese-Timing des MIG-Controller ist nicht deterministisch. Wenn Dein SDRM-Controllerinterface ein festes Timing vorsieht, musst Du dir überlegen wie Du das verheiratest. > Das pX_rd_empty signal ist dann länger high. Wenn das pX_rd_empty länger high ist, hast Du länger zum Auslesen des Read-FIFOs gebraucht. Das liegt dann an Dir, nicht am DDR3-Controller. Geht da was durcheinander? > Warum entstehen so unterschiedliche Zeiten? UG388 "Read Latency" ist passende Lektüre. > Die 2. Frage die sich mir stellt: Warum benötigt der DDR3-Core "so > lange" zum lesen bzw. zum bereitstellen der Daten. 200 nsec und mehr > sind ganz schön ordentlich bei 625 Mhz Takt. Rechnet man 200 nsec. auf > die Takte um, so sind das 125 Takte. Sollte das nicht schneller gehen? Je nachdem was Du alles machst. Immer ein 8er Burst lesen, dann Synchronisierung zwischen zwei Clockdamains, das dauert. Wenn man nur Einzelzugriffe macht, dann ist das halt nicht effektiv. Sieh Dir mal eine Simulation des Cores an und spiel ein wenig mit den Kommandos rum. Da kann man dann sehen, wie schnell der ganze Kram läuft und laufen kann. 64 Bytes lesen dauert nicht viel länger als ein einzelnes.
> Nein. Habe ich mit dem Oszi gemessen. Die Signale sind sauber, und > werden auch richtig ausgewertet. vs. > Mein an den FPGA angeschlossener Controller erwartet die Daten > in etwa in 200nsec. Ist genau das, was ich gemeint habe ;) Kommunikationsprobleme können auch auf Protokollebene sein...
Hallo zusammen. > Das Lese-Timing des MIG-Controller ist nicht deterministisch. Wenn Dein > SDRM-Controllerinterface ein festes Timing vorsieht, musst Du dir > überlegen wie Du das verheiratest. Tja. Mein Controller steht schon auf Maximum Wait State. Ich habe somit ca 200 nsec. Zeit auf die Daten zu warten. Wenn die bis dahin nicht da sind, wie soll ich dann die beiden "verheiraten"? > Wenn das pX_rd_empty länger high ist, hast Du länger zum Auslesen des > Read-FIFOs gebraucht. Das liegt dann an Dir, nicht am DDR3-Controller. > Geht da was durcheinander? O.K. Meine obige Frage ist noch nicht richtig beantwortet worde. Ich weiss wohl dass es unterschiedliche Zugriffszeiten wegen Precharge, Refresh usw. gibt. Aber Leute: 200 nsec. sind doch in der Welt der digitalen Logik (und ich spreche hier von einem Spartan 6 mit DD3-Ram, 625 Mhz getaktet) unendlich lange. Bringt es nun was wenn ich den Takt für den Command-Path Write-Path Read-Path erhöhe ?. Letztendlich lese ich doch nur (beim Read) die FiFo aus. Das dürfte doch nicht lange dauern oder? > Je nachdem was Du alles machst. Immer ein 8er Burst lesen, dann > Synchronisierung zwischen zwei Clockdamains, das dauert. Wenn man nur > Einzelzugriffe macht, dann ist das halt nicht effektiv. Wie soll ich denn das sonst handeln? Ich habe keinen Einfluss darauf wie mein angeschlossener Controller die Daten aus den DDR3-Ram abholt. Wie oben geschrieben. Maximum Wait-States programmiert. ca. 200 nsec. Das sollte doch mit meiner Hardware locker möglich sein. Ich rufe überigens die Daten einzeln ab (Kein burst von 8 oder höher). Und im Moment zum testen immer die gleiche Adresse. noeppkes ...
> Aber Leute: 200 nsec. sind doch in der Welt der digitalen Logik DRAMs haben sich in der Zugriffszeit in den letzten 20 Jahren nicht wesentlich verändert. Die Zykluszeit hat sich wohl so in etwa gedrittelt, heute ist sie ~50-80ns. Zusätzlich kommen die Pipelinedelays des Memorycontrollers dazu (Zugriff auslösen, Synchronisation der DDR-Pfade, etc.). Das musst du halt so hinnehmen. > Ich habe keinen Einfluss darauf wie mein angeschlossener > Controller die Daten aus den DDR3-Ram abholt. Tja, dann wirds schwer. Evtl. ginge es noch, wenn du den Memorycontroller selber schreibst, da könnte man evtl. ein paar Takte sparen... Aber prinzipiell ist das System fu**ed up, wenn es kein echtes ACK gibt. > Ich rufe überigens die Daten einzeln ab (Kein burst von 8 oder höher). Ob ein Wort oder 8, macht zeitlich kaum was aus.
Christian Armbruster schrieb: > Wie soll ich denn das sonst handeln? */Schulterzuck/* Das ist ja scheinbar das interessante an Deiner Aufgabe ;-). Ich habe hier beim Lesen einzelner Worte auch Zugriffszeiten, die Deinen ähneln (gemessen von cmd_en bis cmd_en ca. 280 ns), allerdings auch bei einem Design, bei dem ich mir keine Mühe geben musste, es möglichst schnell zu bekommen. Da lässt sich also evtl. noch ein wenig was rausholen, aber auch eher im Handling der Kommandos und Lesen der FIFOs. Ich sag ja: guck Dir die Simulation an, spiel mit den Kommandos und deren Timing ein wenig rum und guck Dir an, wie lange ein DDR3-Zugriff wirklich dauert und wie schnell Du wirklich beim Umsetzen Deines SDRAM-Interfaces auf das MIG-User-Interface bist. Schlimmstenfalls ist der MIG+MCB halt nicht geeignet für deine Aufgabe...
>Wie soll ich denn das sonst handeln? Ich habe keinen Einfluss darauf wie >mein angeschlossener Controller die Daten aus den DDR3-Ram abholt. Na das halte ich doch für groben Unfug. Du musst doch an irgendeiner Stelle einen Schreib- oder Lesetransfer absetzen (mit Angabe der Burstlänge und der Speicheradresse) und bekommt daraufhin doch ein Schreib-oder Lese-Strobe. Harry
Ich habe mir gerade nochmal ein DDR3 Datasheet von Micron angeschaut. 200 ns sollten machbar sein. Ein 1066er kann man laut Datasheet mit 7-7-7 betreiben, das sind dann ca 40 nsec Zugriffszeit. (bis zum Anfang des Bursts) Wieviel der Memorycontroller zusätzlich braucht kann allerdings nicht benatworten. Auch nicht wieviel bei der Synchronisation von deinem Controllertakt auf den Takt des Memorycontrollers verloren geht. Überprüf als erstes mal die Timingparamter für den DDR3, wenn man die Memoryclock reduziert, kann man auch die Zahl der Takte für den Zugriffzyklus heruntersetzen ( z.b. auf 5-5-5 ). Abgleichen mit dem Datasheet des DDR3 Bausteins!
Noch ein paar Anmerkungen: Ich ziehe die Aussage dass der DDR3 im Prinzip asynchron ist zurück, Für die ein Einhaltung der Zeiten zwischen verschiedenen Zugriffen, (Refresh,Prechare,Read,Write) ist der Memorycontroller zuständig. Einen eigenen schüttelt man deshalb nicht so schnell aus dem Ärmel :-) Die Anwenderseite des Memorycontrollers kann aber trotzdem asynchron sein, insbesondere wenn man mehr als einen Port verwendet! In deinem Fall musst du sicherstellen dass der Controllerport die höchste Priorität hat. Round robin geht nicht!
Hallo Lattice User. Hatte leider nicht mehr bemerkt, dass du noch einmal geschrieben hast. Hatte das ganze schon aufgegeben, aber nachdem du von 40 nsec. schreibst, wird es wieder interessant. (Ich hatte eben auch Zugriffszeiten von über 200 nsec. (im WorstCaseFall, wie Rudolph schreibt) gemessen. Bei 200 nsec. ist Schluss bei meinem Controller. Mehr WaitStates gehen nimmer.) Ich habe überigens 2 Ports am MemoryController. Und: Mit Round robin. Ist das wirklich viel langsamer als "irgend etwas anderes das ich noch nicht kenne"? Wenn ja, was soll ich sonst nehmen? Lässt sich glaube ich im MIG einstellen. Benötige aber unbedingt 2 Port's. Der 2. Port ist vom Display und kann dann auch im BURST-Mode betrieben werden. Controllerseitig geht BURST nicht. Der schreibt ja so wie er will. Na ja. Ich wollte jetzt parallel zum DDR3-Ram (welches ja am FPGA hängt) ein SDRAM direkt auf die Controllerplatine setzetn, die genau ein Abbild des DDR3-Ram's enthält. Schreiben würde ich dann in beide, lesen nur aus dem SDRAM von den Controllerplatine. Das geht eh schneller. Somit wäre mein Problem gelöst. Ist halt etwas teuerer, da ich eben noch das zusätzliche SDRAM benötige, sehe jedoch im Moment keine andere Möglichkeit mehr. Falls ich es doch noch hinbekommen sollte, kann ich ja das SDRAM wieder knicken bzw unbestückt lassen. noeppkes ...
Der WorstCaseFall entsteht dann wenn bei einem Controllerugriff zuerst alle anderen Ports durch den Memorycontroller bedient wird. Bei RoundRobin kann und tut das vorkommen. Dem kann man vorbeugen indem der zugriffskritische Port Priorität hat. Bei nur 2 Ports ist der Gewinn zwar nicht gross aber trotzdem. Worstcase bei RoundRobin könnte so aus sehen Ausgangsstatus: Memorycontroller führt gerade einen Refresh durch 1. Controller meldet Request an. 2. Display meldet Request an. 3. Refresh ist beendet. 4. Memorycontroller führt den Displayrequest aus 5. Memorycontroller führt den Controllerrequest aus Wenn der Controllerport Priorität hat wird der Controllerrequest in diesem Scenario immer vorgezogen. Worstcase wäre dann in etwas so: Memorycontroller ist idle. 1. Display meldet Request an. 2. Memorycontroller startet dessen Verarbeitung. 3. Controller meldet Request an. 4. Displayrequest ist beendet 5. Memorycontroller fügt einen Referesh ein (vielleicht kann man das verhindern wenn ein normaler Request ansteht) 6. Memorycontroller führt den Controllerrequest aus.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.