Den echten DDR-Bus identifizieren

Am FPGA ist ein echter DDR-Speicherbaustein angeschlossen. Ich hoffe, dass die Hardware-Ingenieure dafür die gleiche Pin-Belegung verwendet haben, wie sie Xilinx im MIG (Memory-Interface-Generator) vorgeschlagen wird. Ich habe meine Zeichnung entsprechend ergänzt.

• 

Pins zum RAM (Bild: Christer Weinigel)

Der Speicherbaustein sitzt über dem FPGA auf der Platine, so dass die Pin-Belegung auch hier sinnvoll ist. SSTL kommt erneut als Verbindungsstandard zum Einsatz, der VREF-Pin wird also auch hier mit 0,9 Volt Spannung versorgt.

So weit, so gut, allerdings gibt es hier auch ein Problem.

Wie zu sehen ist, habe ich neun Pins der Bank 3 als unbenutzt markiert. Diese wurden bei meinem Test ständig beschaltet und sind wahrscheinlich Teil des SoC-Busses. Das sollte üblicherweise kein Problem bereiten. Zum Beispiel fungiert der Pin B1 als M3BA2, er dient damit zur Adressierung des Speicherbausteins durch den FPGA-Speichercontroller. Da DDR2-Speicher nur aus zwei Bänken besteht, sind lediglich M3BA0- und M3BA1-Pins erforderlich und M3BA2 verbleibt ungenutzt - die Namen der Pins entstammen der Xilinx-Dokumentation. Beim Pin F4 sollte es sich um den Pin M3CKE (Clock Enable) handeln, der zum entsprechenden Pin des DDR2-Speicherbausteins führt. Es ist aber auch möglich, dass dieser Pin beim Speicherbaustein fest verdrahtet wurde und das Signal nicht durch den FPGA geschaltet wird.

Das große Problem an dieser Stelle ist die Aussage der Xilinix-Dokumentation, dass einer der Pins M4, M5, N4 oder B3 für die RZQ-Kalibrierung benutzt und nicht beschaltet werden sollte. So können Umwelteinflüsse auf die Datenleitungen erkannt und ausgefiltert werden. Das entsprechende Zitat aus der Dokumentation: "The RZQ pin is required and cannot be removed from the design". Aber alle Pins sind mit dem SoC-Bus verbunden. Ich habe nicht genug Erfahrung mit dem MIG-Werkzeug, um eine solche Verschaltung zum Laufen zu bekommen und dabei die Empfehlung von Xilinix zu ignorieren.

Ansonsten sollte es recht einfach sein, mit Hilfe von MIG den Speichercontroller auf dem FPGA zu konfigurieren.

Es fehlt nur noch der ADC-Bus

Es bleibt nun noch ein großer Bus übrig: Er verbindet den FPGA mit dem Analog-Digital-Konverter (ADC). Wenn ich das Oszilloskop normal starte, dann per OpenOCD den SoC neu starte und Linux boote, läuft der ADC normal weiter und dessen Pins liefern weiterhin Signale. Das ist praktisch zur Analyse.

Die ADC-Signale sind symmetrische (differenziale) Signale, und als ich die Frequenzen der Signale an den Pins analysiere, wird deutlich, dass die Frequenzen stets paarweise auftreten und es insgesamt 32 Stück davon gibt. Das entspricht genau meinen Erwartungen. Denn der ADC lieferte 32 symmetrische Signale (zwei Kanäle mit je 2 x 8 Bits).

• 

Pins zum ADC (Bild: Christer Weinigel)

Der ADC befindet sich auf der Platine unterhalb des FPGA, das Layout ergibt auch hier Sinn.

Diesmal ist alles recht einfach.

Die Signalwechsel des symmetrischen Signals an den Pins E7 und E8 liegt selbst dann an, wenn der ADC ausgeschaltet war. Wahrscheinlich handelt es sich um den Takt, mit dem der ADC über die Pins DCLK+/DCLK- betrieben wurde. Ich starte das Oszilloskop erneut, ändere die horizontale Auflösung der Signaldarstellung und starte erneut Linux. Darüber spiele ich wieder mein FPGA-Image ein und die Frequenz (Häufigkeit) der Signalwechsel an den Pins hat sich geändert. Ich bin mir sicher, es handelt sich um den Sampling-Takt, mit dem der ADC die gemessenen Signale an den angeschlossenen Tastköpfen erfasst.

Als ich später an einigen Pins des ADC herumstochere, führt das ebenfalls zu Schaltvorgängen an den Pins F13 und F14. Ich bin mir nicht sicher, was sie tun. Es könnte sich um die Pins des ADC handeln, die einen Überlauf und einen Kalibrierungsvorgang signalisieren.

Ich weiß nicht direkt, welche symmetrischen Signale am FPGA zu den Datenausgabe-Pins am ADC passen, aber das sollte nicht zu schwer herauszufinden sein. Wenn es mir gelingt, das Analog-Frontend zum Laufen zu bringen und eine Signalquelle anzuschließen, könnte ich den Gain-Wert (Verstärkung) so weit verändern, dass nur das niederwertigste Bit in der Datenausgabe auf dem zugehörigen FPGA-Pin auftaucht. Erhöhe ich dann den Gain-Wert, sollten schrittweise auch die höherwertigen Bits in der Datenausgabe auftauchen. So kann ich herausfinden, welches Pin-Paar welchem Bit entspricht, statt per Brute-Force alles durchzuprobieren. Doch das ist am Ende gar nicht notwendig, wie sich zeigen wird.