Schnell Daten in DDR2/DDR3 RAM

Stefan Huebnerschrieb: "

Könnte sowas nicht direkt auf einem Mainboard laufen? Also ADC auf einen RAM-Riegel setzen, in's Mainboard einklicken und in ASM die Daten in einen anderen echten Riegel kopieren. Könnte mir vorstellen, das man sowas unter embedded Linux oder DOS machen könnte.

Dirk

DDR (1, 2 oder 3) ist dynamisches RAM mit einer nicht so besonders einfachen Ansteuereung. Ohne Zusatzlogic wird ein ADC damit nichts anfangen koennen. Ebenso wird der in aktuellen CPUs verbaute DRAM-Controller mit einem ADC nicht viel anfangen koennen.

Gerrit

Das Protokoll von DDR-SDRAMs bildet man nicht mal eben nach, das geht dann in Richtung großes schnelles FPGA - und wenn ich das zur Verfügung hätte, bräuchte ich das Mainboard ja nicht mehr :) An einen PC hatte ich auch schon gedacht, PCIe schafft pro Lane 2 bzw 4 GBit/s (Version 1 vs 2) und das ist etwas einfacher zu implementieren als ein DDR2-Controller. Aber das schnelle FPGA werde ich dennoch brauchen. Real kommt man unter besten Bedingungen auf einer PCIe-x1 Lane auf >200MByte/s, die wollen dann auch erstmal weggeschrieben werden. Es läuft alles darauf hinaus, dass man einen Stream von bis zu 10 GS/s, also 60GBit/s, erstmal puffern muss, wenn man PC-Hardware zur finalen Speicherung einsetzen will - womit wir wieder beim dicken FPGA wären ;)

Ein entsprechend potentes DSO oder eben eine DAQ-Karte wären ja im Prinzip die fertige Lösung, und gerade im Falle des DSO auch mit hervorragendem Zusatznutzen versehen, aber eben zu teuer.

Stefan Huebner schrieb:

Äh, nicht wirklich. PCIe ist deutlich komplexer zu implementieren als DDR2, zudem du für DDR2/3 schon deutlich mehr von den Herstellern vorimplementiert bekommst. Dazu kommt das sich dort Bandbreite und Antwortzeiten deutlich besser abschätzen lassen als beim PCIe, bei dem sich jeder Chipsatz noch mal anders verhalten kann.

Das FPGA muß eigentlich nicht mal sonderlich dick sein, DDR2/3 Controller sind nicht besonders groß und neben dem Controller ist in deinem Aufgabenfall ja kaum zusätzliche Logik nötig. Das eigentliche Problem ist das du für diese Datenmengen sehr breite Busse brauchst um auf machbare Busfrequenzen runter zu kommen. Wenn du das mit einem einzelnen FPGA machen willst, dann landest du ganz schnell bei sehr großen FPGAs, einfach weil alle anderen nicht in Bauformen mit so vielen IOs verfügbar sind. Ein parallele Lösung mit mehreren kleinen FPGAs dürfte da wirklich am einfachsten zu handhaben sein.

Evt. mieten? Was du vorhast ist weder auf der analogen Seite noch auf der digitalen Seite trivial, da entstehen ganz schnell Entwicklungskosten in einer Höhe die das DSO nicht mehr so teuer erscheinen lassen. Für ein Einzelstück dürfte sich so eine Entwicklung vermutlich wirtschaftlich nicht rechnen.

Grüße, Jan

Stefan Huebnerschrieb: "

Vermutlich denkst du zu kompliziert.

Sehe ich nicht so.

Warum willst du einen Controller implementieren?

Du willst ja nur Daten von einer Bank (mit ADC) lesen und diese Daten erstmal in eine andere Bank kopieren (später dann auf Festplatte). Dazu wirst du natürlich die Steuersignale richtig verdrahten müssen. Die Adressleitungen brauchst du nicht. Erstmal wird man ein altes Speichermodul nehmen und die RAMs ablöten. Das EEPROM kann man drauf lassen, bzw. mit passenden Werten programmieren. Jegliche Speichertest auf dieses Modul müssen natürlich unterbleiben. Evtl. muss man den Speichercontroller auch per Software konfigurieren (CAS Latency möglichst 0).

Ein FPGA wird man schon brauchen, da man nicht 1GB kontinuierlich bei gleichen Takt lesen kann. Der Controller kann nur in Bursts (8 Bursts) lesen und will dazwischen neu addressieren. Dabei kann man auch gleich die 6bit in z.B. 60bit Breite umsetzen, also bis zu 10 Werte zwischenpuffern, sonst wird das mit den 10 GS/s nichts.

Alles in allem sicher kein Projekt, das man mal an einem verregneten Wochenende erschlägt, aber durchaus interessant. Mainboard und Speicheriegel sind ja Massenware und billig. Dafür muss man halt seine Zeit reinstecken.

Dirk

Zunächst dachte ich, dass Du dafür zu einfach denkst, aber Deine schon konkreteren Angaben im weiteren Text lassen erahnen, dass Du schon was mit DDR2 gemacht hast (mehr als kaufen und einstecken :) )

Ok, überzeugt - ich habe nach zwei Negativmeldungen dieser Art noch mal in die PCIe Specs geguckt und gar nicht erst weitergelesen. Da muss ich ja im Prinzip massiv puffern, wenn ich keine Werte verlieren möchte, und die Implementierung ist auch nicht wirklich trivial.

Wenn der Controller da mitspielt...

Das ist klar. Mein Probe-ADC kam in ersten Versuchen auch "nur" auf

800MS/s. Insofern hätte ich eh schon 10-faches Interleaving bei 8GS/s.

Massenware und billig - das ist eben der Punkt. DAQ-Karten im GS/s-Bereich sind eben keine Massenware, wenn man sowas bräuchte, um sich digital fernverblöden zu lassen, würden die Teile zweieurofuffzich kosten. Das einzige mir bekannte Massenprodukt, in dem ein ADC mit 4 und mehr GS/s und meistens auch 6 bit sitzt, der an einer anständig programmierbaren Signalverarbeitungslogik (naja, DSP mag ich sowas Proprietäres nicht nennen) hängt und eine fast ausreichend schnelle Schnittstelle hat, sind die Controller für Festplatten. Aber die wechseln alle zwei Wochen ihre Spezifikatin und sind nicht wirklich brauchbar dokumentiert.

Stefan Huebner schrieb: " [...]

PCI halte ich für sowas völlig ungeeignet. Die Vorlaufzeiten um sowas zu entwickeln sind viel zu lang. Dazu kommt noch das ganze Power Managment usw. Man muss dem Buscontroller viel zu viel "beantworten" bevor es richtig los geht.

Für einen Festplattencontroller bekommt man keine richtige Dokumentation. Vermutlich läuft auch zu vieles automatisch ab, auf das man keinen Einfluss hat und was einem die Sample-Zeiten versaut.

DAQ-Karten die kontinuierlich 1GB bei 10GS/s sampeln hab ich jetzt noch nicht gesehen.

Allen gemein ist aber, dass die Daten letztendlich im RAM eines PCs landen und je länger diese Kette ist, um so schwieriger ist der Datenstrom zu kontrollieren. Schneller als der RAM Bus können die nicht sein, es sei denn, dass sie selbst 1GB zwischenbuffern.

Dann doch lieber gleich von RAM zu RAM. Zum Warmwerden reichen sicher die Einstellungen, die man im BIOS machen kann.

Als schwieriger sehe ich eher das elektrische Interface. Bei 1GHz hast du sicher aber auch nichts anderes erwartet, Tektronix hat da was schönes im Programm.

So ist das halt, wenn man sich im Grenzbereich bewegt. Ich hoffe nur du hast die dazu passenden Messmöglichkeiten.

Dirk

PCI ging ja noch. Bei PCIe ist die Geschwindigkeit des Busses ein Problemultiplikator, das habe ich ja inzwischen eingesehen ;)

Eben. Ich hab zwar mal was von Marvell bekommen, aber dafür bekommt man den Chip nicht, ausser, man lötet ihn aus. Keine Basis. Ich hatte die DSP-Funktionen bewusst umschrieben, weil zB. die Servoerkennung und Datenrückgewinnung weitgehend fest verdrahtet sind.

Ich hatte mir Modelle mit 7GS/s und 0,5GS Speichertiefe und das Picoscope mit 5GS/s und 1GS angschaut und einfach mal über die Zeit seitem interpoliert, dass inzwischen 10GS/s möglich sein müssten.

Verlockend scheint das auf jeden Fall erst einmal. Allerdings muss ich dazu ja dem Controller einerseits sagen, dass da RAM ist, damit ich davon lesen kann, andererseits aber darf er den ADC nicht mitten in den RAM-Bereich einblenden (also kein Multichannel-Betrieb usw).

Nö, nicht wirklich. In meiner Diplomarbeit habe ich mit einem jitterarmen 440MHz-Takt für eine DDS gekämpft, so ein paar Fallstricke kenne ich, aber sicher nicht alle.

Dazu werde ich mir dann bei Bedarf jeweils Zugang verschaffen (16 GS/s R&S zB)

Stefan Huebnerschrieb: " [...]

Erkennen sollte das der Controller am EEPROM des Moduls.

Gibt Mainboards für 6 RAM-Module, da sollte sich was finden lassen.

Na dann ist ja alles nur halb so wild. ;-)

Dirk

Ich denke das wäre eine recht aufwendige Entwicklung. Du müsstest die von dir bereits erwähnten Probleme lösen, dann ein Layout entwickeln, was die hohen Übertragungsraten kann und das DDR2/3-Interface für die RAM-Seite simulieren. Einen großen FIFO und irgendein Synchronisierungskonzept (da das Auslesen nicht mit der Samplegeschwindigkeit synchron sein wird) braucht man auch.

Da du ja nur 1 GB Daten samplen willst, ist es da nicht einfacher, ein FPGA-Entwicklungsboard zu nehmen, was diese 1 GB bereits on-board hat, z.B. per SO-DIMM? Viele Boards scheinen allerdings nicht soviel Speicher zu unterstützen. Hier gibt es aber eins, was das kann:

Für den Preis kannst du so ein System, um schnell Daten in ein RAM zu speichern, nicht selber für eine Einzelanfertigung entwickeln, aber ist bestimmt immer noch Faktor 10 preiswerter, als eine fertige DAQ-Lösung mit dieser Geschwindigkeit. Anbindung an einen PC könnte dann per Ethernet gehen, oder du schreibst direkt eine NIOS-Anwendung und gibts auf dem DVI-Anschluss was aus.

Musst du dann nur noch irgendwie deine 60 GBit/s da rein kriegen. Das Terasic-Board unterstützt 300 MHZ DDR2 RAMs, sodaß du maximal 38,4 GBit/s damit hinbekomen würdest, aber bestimmt nicht unter NIOS. Blöd auch, daß man wohl nicht die freie Web-Edition von Quartus dafür verwenden kann und die mit solchen Eval-Kits verkauften Versionen sind meist nur für ein Jahr gültig, da müsste man dann mal nachfragen.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Stefan Huebner schrieb:

Hallo,

denke daran das Du die Daten nicht nur in die dynamischen RAMs hineinschieben musst, Du musst auch für den Refresh sorgen damit dann auch später das auslesen sinnvoll ist.

Eine Logik die 10 * 6 Bit in 64 Bit verpackt würde die Datenrate schon auf 0,5 bis 1 GS/s senken.

Bye