DDR3 RAM Datenleitung beliebig anschliessen

Auswendig weiss ich es nicht, aber es gibt bei den Addressen eine 
Beschränkung, weil die mehrfunktional benutzt werden. Bei den Daten 
sollte es egal sein, weil die ja nicht deterministisch sind. Hast halt 
dann physikalisch Datensalat in den RAMs, der aber nicht relevant ist.

Falk B. schrieb:
> a, das tust du. Bei DDR3 sind je 4 oder 8 Bit als sog. Lanes an ein
> Taktsignal angebunden.
Das ist aber ein rein physikalisches Problem, oder?

Die Bits werden nur ja nur "falsch" einsortiert und beim Auslesen wieder 
sortiert.

?

Der Hocko schrieb:
> Das ist aber ein rein physikalisches Problem, oder?

Das ist ein Timing-Problem: das DRAM schickt beim Lesen zusammen mit den 
Daten das DQS-Signal, das vom Speichercontroller zum Eintakten der Daten 
genommen wird.

Wenn du das DQS-Signal von DRAM zum Eintakten der Daten von DRAM 
verwendest, dann taktest du die Daten im falschen Zeitpunkt ein. Je 
nachdem, mit welcher Frequenz die Daten übertragen werden (und wie 
identisch die DLLs in beiden DRAMs laufen) sind damit Lesefehler 
vorprogrammiert.

oh man:

Achim S. schrieb:
> Wenn du das DQS-Signal von DRAM zum Eintakten der Daten von DRAM
> verwendest,

sollte heißen:

Wenn du das DQS-Signal von ersten DRAM zum Eintakten der Daten vom 
zweiten DRAM verwendest...

Stimmt - kurze Denkblockade meinerseits - der Controller kann es ja 
nicht kompensieren. Ich hatte hier wohl meine Lösung im Kopf (Pin-swap 
am FPGA).

Ich sehe gerade noch was:

Die "CPU-REF", die manuell mit Spannungsteiler hergestellt werden, sind 
hoffentlich nicht die benötigten 0.75-Ref, oder?

Oder doch?

Macht man das neuerdings wieder mit RR, statt mit einem Regler?

>BananaPi

Sieht ziemlich "Banane" aus ... :-)

Holger K. schrieb:
> Ich habe das folgende RAM: K4B4G1646D
> Anbei das Datenblatt.
> Wo sehe ich nun, wie viele Lanes ich habe und wie breit eine solche ist?

Alle Bits, die zu einem DQS-Signal gehören, gehören zu einer Lane. Dein 
DRAM hat 16 IOs und zwei (jeweils differentielle) DQS-Signale (DQSU und 
DQSL). DQSL gehört zu den "L"ower bits - also DQ0..7
DSQU gehört zu den "U"pper bits - also DQ8..15
Innerhalb der Bytes kannst du die IOs also tatsächlich vertauschen, über 
die Bytegrenzen weg aber nicht.

Neben dem Timing Problem (Zuordnung zum richtigen DQS) gäbe es dann 
nämlich sogar noch ein funktionales Problem: dein DRAM hat auch zwei 
Data-Mask Signale (DMU und DML), mit denen das Schreiben für die eine 
oder andere Hälfte der IOs geblockt werden kann. Wenn dein System auch 
mal byteweise auf den Speicher schreiben mag (also die Schreibzugriffe 
nicht immer mit voller Breite durchführt), dann muss die Zuordnung der 
DM zu den DQ stimmen, sonst werden die falschen Bits geschrieben. Also 
auch deswegen: kein Tausch der DQs über die Grenzen der Bytelanes.

Achim S. schrieb:
> Innerhalb der Bytes kannst du die IOs also tatsächlich vertauschen, über
> die Bytegrenzen weg aber nicht.

Fast volle Zustimmung. Bei manchen DDR3-Controller gibt es da aber 
Einschränkungen. Beim i.MX6 muss das erste Bit eines Bytes (also 0 und 
8) "richtig" angeschlossen werden, die anderen dürfen munter vertauscht 
werden.

Hier der Auszug aus dem Manual:
The rules are as follows:
• Hardware write leveling – lowest order bit within byte lane must 
remain on lowest order bit of lane by JEDEC compliance (see the “Write 
Leveling” section in JESD79-3E)
  — D0, D8, D16, D24, D32, D40, D48, and D56 are fixed
  — Other data lines free to swap within byte lane
• JEDEC DDR3 memory restrictions are:
  – No restrictions for complete byte lane swapping
  – DQS and DQM must follow lanes

Ob die Allwinners auch so ein tolles Manual haben, weiß ich allerdings 
nicht.

Auch interessant! Was macht denn das erste Bit so besonders? Das mit den 
der lane-Zuordnung ist eigentlich vollkommen klar und kann nicht nur 
timing-Fehler machen, sondern wird Fehler machen. Aber das 
Bit-Null-Thema ist mir jetzt vollkommen unklar.

?

stimmt, DQ0 ist besonders, das hatte ich schon wieder verdrängt ;-)

https://www.micron.com/products/datasheets/%7BE39E9941-4D9E-426A-9ACA-D65A25A01794%7D?page=8

Um das Timing sauber einzutrainieren kann man das Mode-Register so 
programmieren, dass über DQ0 eine Toggle-Sequenz läuft, die anderen DQs 
halten währenddessen still....

Ein weiterer Stolperstein ist das length-matching.
Alle CA Signale müssen gleich lang sein und möglichst identische 
Impedanzen aufweisen. Das selbe gilt für die Daten lanes. Diese müssen 
in sich die gleiche Länge haben.
Zu einer Daten-lane gehören 8 Datenbits, DQM und das DQS Pärchen.

Die 5 Gruppen können unterschiedlich lang sein, das wird durch das 
leveling ausgeglichen.

D0, D8, D16, D24 sollten 1:1 aufgelegt werden, das ist normalerweise der 
"Feedback" Kanal für das write leveling, sofern der Controller write 
leveling überhaupt hardwareseitig unterstützt. Das tun nämlich nicht 
alle.

Die Generierung der Referenzspannung kann man über Regler oder RR 
machen, mit RR habe ich gute Erfahrung. Allerdings erscheint mir dein 
Spannungsteiler etwas hochohmig.

Der ZQ Widerstand ist normalerweise 50Ohm, 1k habe ich noch nie 
gesehen...

ich schrieb:
> Der ZQ Widerstand ist normalerweise 50Ohm, 1k habe ich noch nie
> gesehen...

50 Ohm habe ich da aber auch noch nie gesehen. Ich kenne da 240 Ohm...

Korrektur: ZQ Widerstand=240Ohm

Deine Clockterminierung ist auch etwas seltsam. Hast du 2x 1k längs und 
100p am Eingang des Taktsignals? Das wird so nicht funktionieren. Zeig 
doch mal die Anbindung an den Prozessor.

Bei unterminierten Systemen, wie deinem, habe ich gute Erfahrung mit 
100R zwischen dem CLK-Paar.

mit 1:1 meine ich:

D0 Controller an D0 RAM1
D8 Controller an D8 RAM1
D16 Controller an D0 RAM2
D24 Controller an D8 RAM2

Ja, Vcc/2 ist ein Referenzwert der intern benötigt wird. Wenn der Teiler 
allerdings zu hochohmig ist, ist das störanfälliger. Schau dir mal an 
welche Genauigkeit an der Referenz benötigt wird.

Die Bit0 Geschichte ist noch falsch.

Die Clockterminierung würde ich anders machen. Was erhoffst du dir von 
den 22Ohm und den 10p? Ein DDR Controller hat bereits eine definierte 
Ausgangsimpedanz, das macht dir nur Ärger.
In dem Referenzschaltplan haben die 0 Ohm bestückt und den Kondensator 
nicht. Dann kann man das auch weg lassen, der Sprung deiner Impedanz 
durch die Pads der Bauteile kann zum Problem führen.
Mach einfach einen 100 Ohm Widerstand zwischen das CLK Paar.

Welche Frequenz willst du verwenden?
Wie soll die Topologie aussehen?
http://www.icd.com.au/articles/DDR3-4_Topology_PCBD_Apr2016.pdf

Rufus Τ. F. schrieb:
> Holger K. schrieb:
>> Dabei stellt sich mir die Frage, ob ich denn nun die Datenleitungen
>> beliebig auf den zwei Chips schieben kann,
>
> Sollte gehen. Nur bei den Adressleitungen darfst Du das auf keinen Fall,
> denn über die werden nicht nur die Speicheradressen, sondern auch
> weitere Steuerinformationen (für verschiedene Mode-Register)
> transportiert.

Ich würde das so pauschal nicht sagen.

Da gibt es etwas, das ZQ-Kalibrierung heißt. Bei einigen Prozessoren 
erfordert das, dass man bestimmte Datenleitungen an bestimmte Ports des 
Speichercontrollers und des RAMs anschließen muss.

Ich kann nur zum genauen (!) prüfen des Datenblattes raten.

Holger K. schrieb:
> Danke für die Antwort.
> Anbei das Datenblatt des A20
>
> Leider ist der DDRC Teil sehr spärlich.

Das ist kein Datenblatt, sondern ein Sparwitz. Möglicherweisee hast du 
aber auch nur das falsche erwischt. Da sollte es zumindest ein 
"Reference Manual" geben. Das vom i.MX6 hat zum Beisiel 5800 Seiten, so 
um den Dreh müsste das hier auch aussehen.
Mit DEM Ding wird da kein funktionisfähiges Board herauskommen :-(

Wenn du bezüglich des SOC keine Wahl hast, wirst du dich an bestehenden 
(funktionsfähigen) Designs orientieren müssen. Die einfachste Lösung 
ist, die DDR3-Schaltung des Referenzdesigns 1:1 zu übernehmen. Inklusive 
Layout, das ist nicht ganz unkritisch. Vorsichtig ausgedrückt.
Falls es keines gibt, nimm wenigstens eine funktionsfähige Schaltung, 
welche frei verfügbar ist.
Nichts ist schlimmer, als ein SOC der nicht hochfährt. DDR3 mit dem Oszi 
debuggen ist fast unmöglich - man kommt an die Leitungen schon gar nicht 
ran.

Es gibt übrigens von Freescale ordentliche Prozessoren mit richtiger 
Dokumentation. Möglicherweise wäre das was?