NIOS Debugger an DDR2 interface - Problem wegen burst?

[Matthias (Gast)]

Hallo,

wir haben hier folgendes Problem: Ein NIOS2-System mit DDR2 als 
Arbeitsspeicher soll gebaut werden. Der DDR2 hat Wortbreite 16 Bit, der 
generierte DDR2 Controller aus dem SOPC_Builder System hat intern ein 32 
Bit breites Interface. Vorerfahrung besteht mit einem System wo der 
Arbeitsspeicher in einem SSRAM war. Bei den ersten Gehversuchen hat sich 
gezeigt, dass ein Speichertest NIOS <-> DDR2, lt SignalTap erfolgt der 
Zugriff anscheinend durch die Caches durch burst-weise. Der Speichertest 
ist in C mit Pointern implementiert. Wenn jetzt der Debugger benutzt 
werden soll, dann zeigt sich, dass jeweils 32 Bit korrekt sind (in 
Wahrheit nur 16 bit, die anderen sind auf 0 wie sie sein sollen) und 
dann 32 Bit auf 0 gehen. Dabei werden auch davorliegende Addressen 
überschrieben, bspweise sieht man zuerst

0 --> 0x00000001
2 --> 0x00000000

dann wird der Wert 0x02 auf Wortaddresse 2 geschrieben und es steht

0 --> 0x00000000
2 --> 0x00000002

im Speicher. Das schaut für mich aus wie wenn im zweiten Fall der Burst 
die Address-Sequenz 2-3-0-1 durchläuft und damit das vorige Wort wieder 
überschrieben wird.

Unsere Theorie dazu ist, dass der Debugger mittels Makros am Cache 
vorbei in den Speicher schreibt und dadurch keinen gültigen Burst 
erzeugt.


Weiß jemand, wie man das beheben kann? Eine Möglichkeit wäre ein 
zusätzlicher transparenter Cache außerhalb des NIOS im FPGA an dem auch 
der Debugger nicht vorbeikommt. Nur finden wir auf die Schnelle keinen 
Avalon Interface Cache.

Insgesamt bin ich ein wenig verwundert, dass es ein derartiges Problem 
gibt, wenn man ein wenig durchs Netz schaut kriegt man den Eindruck es 
gibt auch andere Menschen, die NIOS-Systeme mit DDR2 haben und dieses 
debuggen können. Ist es ein PEBKAC?

lg
Matthias

[Duke Scarring (Gast)]

Der Debugger hat ja auch nur das interne 32-Bit-Interface.
Laut Deiner Theorie würde das bedeuten: Burst geht, Einzelzugriff nicht.
Damit wäre der DDR2-Controller fehlerhaft.

Matthias schrieb:
> Unsere Theorie dazu ist, dass der Debugger mittels Makros am Cache
> vorbei in den Speicher schreibt und dadurch keinen gültigen Burst
> erzeugt.
Meine Theorie dazu wäre, das der Debugger richtige Speicherzugriffe 
macht, aber der Cache davon nix mitbekommt und den Speicher bei der 
nächsten Gelegenheit mit "alten" Werten überschreibt.

Funktioniert denn das debuggen, wenn de Cache deaktiviert ist?

Duke

[Matthias (Gast)]

Oje, oje, ich hab im ersten Post bei aller Länge die wichtigste Info 
nicht gegeben: Die DM~ Pins der DDR2 sind bei dem Board fix auf GND 
gelegt. Ohne diese Info macht das was ich schreibe natürlich nicht viel 
Sinn, tut mir leid.

So, ich hab das in den letzten zwei Tagen im Simulator nachstellen 
können und denke, damit die Theorie bestätigt zu haben: Zugriffe mittels 
Pointern laufen über den Cache. Man sieht, wie immer ganze 32 Bytes 
gelesen oder geschrieben werden, dh 4 Zugriffe hintereinander mit 
jeweils einem Cycle Pause am Interface zwischen NIOS Kern und DDR2 IFC. 
Der Wert an Port "avl_size" ist 4.

Anders die Zugriffe mittels des Makro: Es findet nur ein Zugriff statt, 
die avl_size ist 1, die internen (aber nicht nach außen verbundenen) DM 
Pins schalten wie um die nicht verwendeten Wörter auszumaskieren, der 
Speicher bekommt davon natürlich nichts mit und überschreibt die anderen 
32 Bit in der Burst Sequenz mit 0.

Wie geschrieben, ein zweiter Cache vor der DDR2 Komponente würde das 
Problem lösen, allein wir haben bisher keine gefunden. Hat da jemand 
vllt einen Pointer für uns (oder was bei sich im Cache)?

lg
Matthias