Ich habe mit gerade mit dem MIG einen DDR2-Controller generiert um damit
das Verständniss für die Arbeit eines solchen Controllers zu erlangen.
Ich habe schon ein Problem in dem Top File (ist im Anhang). Von dem Core
aus gehen ja etliche Anschlüße ab, die fast alle aus dem FPGA raus und
zum RAM hin laufen. Wo sind den die Ports, an denen ich meine Daten(32
Bit)/Adressen(12Bit) anlegen kann? Ich seh die Ports zwar im TOP File,
aber die "gehen ja raus an den RAM Baustein", da kann man als Nutzer ja
nix anlegen. Und warum wird der Adressbus im Core als OUT erzeugt und
nicht als INOUT die der Datenbus?
Gibt es eigentlich irgendwo Literatur zu dem Thema? Buchempfehlungen?
Desweiteren hätte ich noch eine Frage an die Leute, die sich schon
länger mit FPGAs beschäftigen. Wie stuft ihr eigentlich den Aufwand/die
Komplexität für einen solchen Controller ein? Wenn ich mir vorstelle,
dass ich sowas vielleicht mal ohne einen Generator erstellen muss, dann
wird mir da schon ein bisschen Bange bei.
Auch wenn sich das oben nicht so anhört, aber die Grundlagen in
VHDL/FPGA sind mir geläufig. Nur finde ich den Sprung von meinen
einfachen Designs (VGA-Controller, I2C, PWM-De/Coder) zu so einem
Projekt schon ziemlich enorm.
Danke im Vorraus für die hoffentlich zahlreichen Antworten :)
Hi Gast(Gast)
1) Du hast nicht die aktuelle Version von MIG - aktuell is 2.2 (das
würde dann nämlich auch so im Header stehen
2) Dein toplevel ist das "Test-Design", mit dem man untersuchen kann, ob
das PCB funktioniert: es werden ständig dummy-daten zum Speicher
geschrieben und wieder gelesen - bei einem Fehler beklagt sich ne LED
3) je nach aktueller Version vom MIG steht die IP in einem anderen
Verzeichnis: bei MIG2.2 steht "Dein" Test-Design unter
"example_design\rtl" und die "nackte" IP unter "user_design\rtl"
4) Literatur zum MIG wird mitgeliefert - siehe unter "docs"
5) das "Problem" bei Xilinx Spartan3 (und den Derivaten) ist, daß ihnen
aus Kostengründen ein Feature fehlt, um das PRoblem gescheit zu lösen.
Virtex4/5 -Design sind WESENTLICH einfacher / auch LatticeXP ist
"leichter", da sie einen zusätzlichen IO-Sync-Block anbieten.
Bei Spartan3 muß macn tricksen, um "sicher" das Einlesen der Daten unter
allen Bedingungen (P,V,T) zu garantieren. Daher beinhaltet die Xilinx-IP
einen Kalibrierungs-Block, der je nach Umstände (P,V,T) dafür sorgt, daß
dies Lese-Daten im "richtigen" Moment eingelesen werden (adaptive
Verzögerung über LUTs !!! hatten wir nicht grad einen Beitrag über da
Thema !?!)
Dies ist NICHT trivial - die Arbeit wird jedoch vom MIG gelöst: es gibt
im Plazierungsvorgaben im Chip vor - abhängig vom Typ,Package,Bank die
der Anwender verwenden will
6) Lies Dir den ug086.pdf genau durch, beschalte die User-Signal wie
beschrieben, dann wird alles gut !!!!
Wir haben diesen Controller in 3 Projekten mit Stückzahlen von je ca
100k-250k jährlich seid einiger Zeit ohne Probleme "am Laufen" (na gut
es ist der Controller für den DDR1 - aber Projekte mit DDR2 sind in
Vorbereitung: zumindest ein TestBoard läuft bei mir auf dem Tisch)
Gruß
Jochen
@Joko,
nur eine dumme Frage: Kann man das Einlesen bzw. die notwendigen
Verzögerungen nicht auch per Delay-Elemente in den IOBs lösen?
Gruss und Danke
Jörg
Nachtrag:
im Virtex4/5-Baustein wird das genau so gemacht - jedoch regelt da der
Baustein 'von selbst' die Verzögerung nach : man muß den IOBs nur einen
zusätzlichen Arbeits-Takt geben.
Bei Spartan3 muß man die Regelung 'von Hand' machen - das geht aber
nicht mit den im IOB angebotenen Features :-(
daher macht es Xilinx (ich wiederhole: die IP-Spezialisten von Xilinx
sagen, daß es nicht im IOB geht !!!) in den CLBs IM Chip
Gruß
Jochen
@Joko,
kannst du uns/mir vieleicht einen kleinen Hinweis geben, wie
das zeitgenaue Delay mit LUTs funktioniert? (Möchte selber mal
als Hobby ein kleines Interface schreiben)
Gruss und Danke
Jörg
@Jörg
offizieller Weg:
1) ISE installieren (möglichst 10.1 mit SP2 und IP-Update #2)
2) CoreGen öffnen
3) mit MIG (irgend-) ein DDR-Interface bauen
4) ins directory "doc" gehen
5) 768c.pdf lesen
Gruß
Jochen
P.S.
xapp768c.pdf war mal 'confidential' und man brauchte 'Beziehungen'
- jetzt darf es anscheinend jeder lesen (recht so)
Ich habe eine Frage, was ist eigentlich der Grund, warum diese Adaptive
Verzögerung für die Datenkanäle (DQS und der andere Kanal, habe das .pdf
gerade nicht hier) überhaupt benötigt wird. Sorry falls diese Frage
trivial ist, aber ich bin Informatiker im 2. Sem und wir haben in
Etechnik erst ein paar einfache Grundlagen kennen gelernt.
Wünsch einen schönen Abend
Mathias G.
Beim Lesen/Schreiben vom/zum Speicher - so ist es in der JEDEC-Spec
definiert - haben die Datenleitungen (DQ) eine definierte Phasenlage zu
den zugehöhrigen Strobeleitungen (DQS).
Beim Schreiben ZUM Speicher hat der Contoller dafür zu sorgen, daß die
Flanken der DQS-Leitungen in der "mittig" zu den Daten liegen - der
Speicher also mit stiegender/fallender DQS-Leitung die Datenleitungen
"abfragen" kann.
Beim Lesen VOM Speicher treibt der Speicherbaustein DQ und DQS jedoch
GLEICHZEITIG! Das heißt, daß der Controller selbst dafür sorgen muß, daß
er die Daten "mittig" abfragt. Er muß also (selbst) dafür sorgen, daß er
das ankommende DQS-Signal um eine viertel Periode verzögert - denn nur
dann kann er sicher sein, daß er die Datensignal auch im richtigen
Moment einliest.
1. Ansatz: Dies macht man 'normalerweise' mit einer PLL/DCM.
"Unglücklicherweise" ist das DQS-Signal jedoch nicht periodisch - d.h.
PLL/DCM funktionieren nicht
2. Ansatz: wir verwenden die in den IOBs vorhandenen Delayalemente, um
das DQS-Signal zu verzögern. Leider sind die einstellbaren Stufen so
grob und ungenau, daß man nicht bei in jedem Betriebsfall (PVT =
Process/Voltage/Temperatur = Chip-Herstellung/Betriebsspannung/aktuelle
Temperatur) sicher sein kann, das Auge zu treffen :-(
3. Ansatz: wir basteln uns unsere eigene Verzögerungskette und
kalibrieren sie ständig (beim Schreiben) - is aber nur was für die
"harten Jungs".
Wir verlassen uns darauf, daß die wissen, was sie tun, und übernehmen
ihre Ergebnisse...
Gruß
Jochen
