DACRAM Zusatzplatine

Das Forum für die Hardware der FPGA-Basisplatine
magicroomy
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 205
Registriert: 01.12.2007, 09:23

DACRAM Zusatzplatine

Beitrag von magicroomy » 26.02.2009, 09:59

Hi zusammen,
hat schon jemand die DACRAM zusammengebaut?
(Das Löten des DUAL DAC war nicht wirklich lustig. )
Ich glaube es geschafft zu haben und würde das Ding gerne Testen.
Funktion der D/As, des RAM und des Frequenzzählers.
Leider ist die Doku im c't Artikel diesbezüglich etwas karg.

Da ich einen neuen PC habe, hab ich noch kein Labview (Wenn mir jemand sagen kann wo man die Windowsversion herbekommt wäre ich froh. CD ist irgendwie verschütt gegangen). Kann also noch nicht mit Labview arbeiten.
Kalibriert wird ja aber scheinbar eh nix.

Mein Stand bisher ist:

Test des Frequenzzählers:
ct-frequz.zip auspacken und main.bit auf die SD Karte. Dann sollte man mit Subchannel 20 einen Wert proportional zur Frequenz abfragen können. Hier könnte man mit dem guten alten DDS mal ein paar Eingangssignale erzeugen, die auch mal nicht 5V oder 3,3V sind um die Pegelwandlung zu testen.
Wenn der abgefragte Wert sich proportional zur DDS Frequenz ändert ists gut.
Laut Artikel kann man wohl einen DAC (DDS) Ausgang auf ein Eingang des Frequenzzählers legen. Wenn ich aber weder die Funktion des Zählers noch des DAC verifiziert habe wäre mir das nicht geheuer.

Test der DACs:
Da wirds schwieriger. Im AMDDS ISE Projekt gibt es eine Bit-Datei und eine INI um eine Wellenform auf die DACs zu zaubern. Wenn ich das tue kommt auch eine am Ausgang des TxDAC und einem Kanal des DualDAC raus. Der zweite Ausgang des DualDac zeigt keine Wellenform. Nach einem ersten Studium der Schaltpläne würde ich sagen das ist ok so, weil der Select Eingang des Dual Dac vom AMDDS nicht beschaltet wird. Hat hier evtl. schon jemand ein .BIT gestrickt mit dem man die DACs mal gezielt und einfach testen kann? Z.B. ein Sägezahn auf alle DACs oder so?

Test des RAM:
Gehe ich recht in der Annahme das die QVGA Beispiele das RAM implizit mittesten? Hab die neueste Firmware drauf, LCD Monitor angeschlossen. Nach anfänglichen Problemen mit der Bildfrequenz hat sich der Monitor aber doch noch dazu bewegen lassen ein Bild anzuzeigen. Ich habe aber Pixelfehler in manchen Bildbereichen. Sind das Pegelprobleme oder haben ein paar Adressleitungen einen Kurzschluß? Letzteres würde ich fast ausschließen weil die Pixelfehler nur in manchen Bildbereichen sind. Sieht auch irgendwie nicht systematisch aus.

Würde mich freuen wenn auch andere mal ihre Erfahrungen posten.

Sobald ich den ISE Webpack installiert hab werde ich mich mal an ein simples Test.bit für die DACs machen. Ein Ram Tester wäre auch gut.

Gruß
Magic Roomy

ingo
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 26
Registriert: 26.02.2009, 10:19

DACRAM-Platine

Beitrag von ingo » 26.02.2009, 10:23

Hi!

ich hab die DACRAM auch bereits fertig, konnte aber noch nicht ausführlich testen. Hab bis jetzt einfach das asteroids-demo laufen lassen, das geht ganz gut! Zumindest ist dann klar, dass RAM und die DualDACs laufen. (die beiden 2- und 3bit-DACs sind ja kaum erwähnenswert ;))
TxDAC und Frequenzzähler hab ich noch nicht probiert.


Gruss, Ingo

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 894
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 » 26.02.2009, 11:20

Wenn Asteroids funktioniert, dann sollte das RAM in Ordnung sein. Dto Packman, weil da Code des emulierten Prozessors aus dem RAM ausgeführt wird.

Ich kann's auf der DACRAM-Platte leider noch ausprobieren, mein Bausatz ist noch in der Post. Aber ich hatte mir vorab ein 256 k RAM auf eine Lochrasterplatte gefädelt, und da gab's von der Hardware her keine Bildstörungen.

@Volker: überprüfe doch mal, ob Du wirklich ein aktuelles QVGA.bit verwendest, es gab da mal welche mit nicht optimalen Syncsignalen.

Wie sehen denn die Bildstörungen aus, flackern da Pixel? Dann ist evtl. eine Adress- oder Datenleitung nicht sauber verlötet und die Lötstelle koppelt mehr kapazitiv als galvanisch. :?

HSiebrecht
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 116
Registriert: 30.11.2007, 23:50
Wohnort: Westfalen

Beitrag von HSiebrecht » 26.02.2009, 18:35

Hallo zusammen,

heute erst die Bestellung bei Segor aufgegeben.

@ Volker
Test des RAM:
Gehe ich recht in der Annahme das die QVGA Beispiele das RAM implizit mittesten?


Testen würde ich nicht direkt sagen, identifizieren trifft es wohl eher. Cm hatte das irgendwo geschrieben, es wird ein Pattern ins SRAM geschrieben und dann wird versucht diese Daten wieder richtig auszulesen.

Hab die neueste Firmware drauf, LCD Monitor angeschlossen. Nach anfänglichen Problemen mit der Bildfrequenz hat sich der Monitor aber doch noch dazu bewegen lassen ein Bild anzuzeigen. Ich habe aber Pixelfehler in manchen Bildbereichen. Sind das Pegelprobleme oder haben ein paar Adressleitungen einen Kurzschluß? Letzteres würde ich fast ausschließen weil die Pixelfehler nur in manchen Bildbereichen sind. Sieht auch irgendwie nicht systematisch aus.
Wie psclab38 ja schon schrieb, mit einem aktuellem QVGA.bit probiert ?

Ansonsten fällt mir noch folgender Thread ein :

http://thoralt.ehecht.com//phpbb/viewtopic.php?t=239

Da schrieb cm :

"PS: Für manche Monitore ist der RGB-Ausgangspegel an der VGA-Buchse etwas zu hoch. Wenn die Farbdarstellung zu flau ist, drei SMD-Widerstände 100 Ohm an der VGA-Buchse von Pin 1, 2 und 3 nach Masse (nächste Pin-Reihe) löten. "


Unterstelle mal Du hast den Segor Teilesatz oder ?
Frage wegen dem SRAM ( 3,3V Typ ), obwohl für meine FPGA-RAM Karte ( Fädeltechnik ) hatte ich meinem alten Eurocom I die 32KB SRAM (5V) geklaut und es funktioniert auch mit einem 62256 / 5V.
Viele Grüße

Helmut

Die meisten Desaster in der IT Welt haben eine gemeinsame Ursache: Wir machen mal eben.

Merlin
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 13
Registriert: 09.09.2008, 08:04

Beitrag von Merlin » 26.02.2009, 20:33

Hallo FPGA-User !

Ich habe Probleme mit der DACRAM-Karte von Segor.
Der QVGA-Ausgang funktioniert nicht richtig (siehe Bilder im Anhang)

Status:
- DACRAM-Karte voll bestückt
- QVGA bzw. main.bit neu heruntergeladen
- Zwei Monitore mit gleichem Ergebnis
- Frequenzzähler funktioniert
- DACs müssen noch richtig getestet werden
- Leitungen und Lötstellen überprüft

Wer kann mir weiterhelfen !

Viele Grüße

Merlin
Dateianhänge
FPGA-VGA1.JPG
FPGA-VGA1.JPG (27.02 KiB) 5811 mal betrachtet
FPGA-VGA2.JPG
FPGA-VGA2.JPG (22.42 KiB) 5810 mal betrachtet

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 894
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 » 26.02.2009, 21:18

Hi Merlin,

tja, so wie die Bilder aussehen, tauchen Daten teilweise nicht nur an einer Stelle auf, sondern an mehreren. Da ist wohl die Adressierung nicht ganz sauber.

Kontrolliere doch nochmal die Adress-( und Daten-)Leitungen des SRAM. Vielleicht gibt's da noch einen versteckten Fehler, evtl. Kurzschluß von zwei Adressleitungen. Übrigens kann das Problem theoretisch auch auf der FPGA-Hauptplatine liegen, die Anschlüsse sind ja bislang gar nicht verwendet worden.

Das SRAM ist ja bestimmt aus dem Bausatz, sollte also mit 3V laufen. Das SRAM hat mit den DACs überhaupt keine Verbindung, sollte also von den anderen Schaltungsteilen nicht beeinflußt werden.

Das SRAM steckt richtig im Sockel und der Jumper ist richtig gesetzt?

Viele Grüße
Paul

HSiebrecht
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 116
Registriert: 30.11.2007, 23:50
Wohnort: Westfalen

Beitrag von HSiebrecht » 26.02.2009, 22:08

Hallo zusammen,

@psclab38
Das SRAM ist ja bestimmt aus dem Bausatz, sollte also mit 3V laufen. Das SRAM hat mit den DACs überhaupt keine Verbindung, sollte also von den anderen Schaltungsteilen nicht beeinflußt werden.
Dem ist nicht so, SRAM A0 - A13 ist gleich D13 - D0 von U2 AD9752.
SRAM A0 - A11 ist gleich D11 - D0 von U5 AD5447.

@Merlin
siehe oben, so wie es aussieht sind die Datenleitungen D0 - D7 des SRAM OK, sonst hättest Du mehr "Müll". Tippe hier auf ein Problem bei den höheren Adressleitungen. Kontrolliere mal alles um U2 und U5 auf eventuelle Lötbrücken.
Viele Grüße

Helmut

Die meisten Desaster in der IT Welt haben eine gemeinsame Ursache: Wir machen mal eben.

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 894
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 » 26.02.2009, 22:16

@Helmut
Dem ist nicht so, SRAM A0 - A13 ist gleich D13 - D0 von U2 AD9752.
SRAM A0 - A11 ist gleich D11 - D0 von U5 AD5447.
Hmmm, ja, da hast Du recht. Ich hätte doch in den Schaltplan schauen sollen :oops:
Aber ich tippe auch auf ein Problem bei den höheren Adressleitungen. Das Bild sieht danach aus.

HSiebrecht
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 116
Registriert: 30.11.2007, 23:50
Wohnort: Westfalen

Beitrag von HSiebrecht » 26.02.2009, 22:28

Hallo psclab38,
Hmmm, ja, da hast Du recht. Ich hätte doch in den Schaltplan schauen sollen
Ja, aber da sieht man es nicht auf Anhieb. Einfacher ist cm's FPGA Pinbelegung, siehe :

http://www.heise.de/ct/projekte/machmit ... umentation
Viele Grüße

Helmut

Die meisten Desaster in der IT Welt haben eine gemeinsame Ursache: Wir machen mal eben.

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 894
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 » 26.02.2009, 22:38

Ja, aber da sieht man es nicht auf Anhieb.
Das liegt an den "Luftbrücken" in den Stromläufen von cm. :wink: Die haben mich schon mehrfach in die Irre geführt.

magicroomy
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 205
Registriert: 01.12.2007, 09:23

Bei mir sehr ähnlich

Beitrag von magicroomy » 26.02.2009, 23:29

Hi,
bei mir ist das Bild des QVGA sehr ähnlich. Ich habe hier zwei FPGA Basisplatinen. Eine hat ein Problem die andere nicht => Bei mir liegt es ziemlich sicher an der Basisplatine. Hab die VG Leisten nochmal nachgelötet. Hat nichts geholfen.
Kann man an die Pins einfach mal ein Ohmmeter ranhängen um zu sehen ob es Brücken hat, oder schießt man sich damit den FPGA?
Und vor allem bringt so eine Messung was? Wenn es ein übersprechen bei höheren Frequenzen ist, ist bei einfacher Messung evtl. kein Problem zu erkennen? Also was tun?

Gruß
Volker


Mist, Sollte eigentlich als Post zum RAMDAC sein... Evtl. kann Thoralt es umbiegen?

HSiebrecht
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 116
Registriert: 30.11.2007, 23:50
Wohnort: Westfalen

Beitrag von HSiebrecht » 27.02.2009, 00:52

Hallo Volker,

wenn Du wie bei Merlin einiges richtig lesen kannst, sind die Datenleitungen D0 - D7 des SRAM OK.

Also zu den Adressleitungen, am besten mit dem Osci messen.
A0 hat die höchste Frequenz ( Low / High - Wechsel ). A1 = 1/2 A0, A2 = 1/2 A1 .... Keine 2 Adressleitungen dürfen die selbe "Frequenz" aufweisen = Kurzschluss dieser beiden Adressleitungen.
Wenn eine Adressleitung auf permanent High oder Low ist, fällt es dann ja auch sofort auf.

Aus Deinen geschilderten Problemen gehe ich davon aus, dass Du vorher keine FPGA-RAM Karte aufgebaut hattest ?

Auch aus einem vorherigen Post, Segor Teilesatz oder ?
Wegen SRAM Typ

Good Luck bei der Fehlersuche
Viele Grüße

Helmut

Die meisten Desaster in der IT Welt haben eine gemeinsame Ursache: Wir machen mal eben.

magicroomy
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 205
Registriert: 01.12.2007, 09:23

Säuberung

Beitrag von magicroomy » 27.02.2009, 09:54

Hi Helmut,
ich hab jetzt meine FPGA-Basisplatine in meiner Firma mal säubern lassen. Mal schaun obs hilft, sonst muß ich tatsächlich auf Jagd gehen mit Oszi und Logic Analyser.

Mein DACRAM ist von Segor mit dem 512kB Erweiterungskäfer. Der Effekt ist bei beiden Rams (32kB-512kB) auf der "defekten" FPGA-Basisplatine zu bemerken.
Auf der anderen FPGA läuft es wunderbar.

Für den Test der DACs habe ich mir übrigens mittlerweile ein Test.bit geschrieben, welches einfach auf allen 3 DACs einen Sägezahn erzeugt. Das sieht auf beiden Basisplatinen schon ganz gut aus. Muß mir mal die dafür verwendeten Leitungen anschauen. Die verursachen das Problem dann vermutlich nicht.

Gruß
Volker

HSiebrecht
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 116
Registriert: 30.11.2007, 23:50
Wohnort: Westfalen

Re: DACRAM Zusatzplatine

Beitrag von HSiebrecht » 27.02.2009, 17:04

Hallo Volker,

habe ja meine DACRAM Karte leider noch nicht, hatte die Hoffnung sie kommt heute. :roll:

Zu Deinem Phänomen, wenn Du ein Problem auf den unteren Datenleitungen der DAC's = höhere Adressleitungen des SRAM hast, könnte ich mir vorstellen dass der Sägezahn wie einer aussieht, nur halt ggf. mit einigen Einbrüchen oder Zacken. Beim SRAM gibt es aber Adressierungsprobleme.

Habe noch mal ins Layout / Pinbelegung geschaut.

Da der Fehler mit 32K und 512K auftritt kannst Du erst einmal A18 - A15 aussen vor lassen. QVGA.bit benutzt meines Wissens eh nur 32K.

Wenn obiges ( Sägezahn ) alles richtig ist, ist SRAM A14 = FP124 = b19 ein ganz heisser Kandidat, der geht an keinen der DAC's. Eventuell ist der FPGA Pin FP124 ( oder ein anderer ) nicht richtig gelötet bzw. Lötbrücke mit einem anderen Pin.

P.S. Man(n) muss das Rad ja nicht zweimal erfinden, würdest Du dein Test.bit zur Verfügung stellen ?
Viele Grüße

Helmut

Die meisten Desaster in der IT Welt haben eine gemeinsame Ursache: Wir machen mal eben.

magicroomy
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 205
Registriert: 01.12.2007, 09:23

Re: DACRAM Zusatzplatine

Beitrag von magicroomy » 27.02.2009, 19:12

Hi zusammen,
nur eine kurze Meldung...
Kaum entfernt man das verbrutzelte Colofonium von der FPGA Basisplatine, schon klappts auch mit QVGA.
Hab also keine Bildfehler mehr.

Test.BIT stelle ich am Wochenende rein.

Gruß
Volker

Antworten