Mehrere BRAMs parallel

Ich hab da noch nichts constraint, aber es sieht ja auch sonst gut aus, 
vielleicht ist mein Problem auch einfach eines das man nicht wegbekommt, 
ich versuche das mal näher zu erklären mit "Bildchen":

Ich gebe da ein Rechteck drauf, digital auf das höchste Bit. Das wird 
derzeit mit 250kHz abgespeichert und dann angezeigt. Ich betrachte jetzt 
die niedrigste Zoomstufe, also man sieht einen kleinen Bereich 
vergrößert. Bei jedem horizontalen Durchlauf am Monitor (Pixeltakt = 
75MHz) werden 1024 Spalten durchgegangen, also ein 10Bit Wert. Davon 
werden die oberen 6Bits als Adresse verwendet und liegen am BRAM an, und 
die unteren 4Bits entscheiden von welchem der 16 BRAMs die gelesenen 
Daten verwendet werden.

Das Bild am Monitor besteht also aus 64 vertikalen Streifen von denen 
jeder aus 16 vertikalen Linien besteht. Die 0. Linie kommt aus dem 
BRAM0, ... ich denke es wird klar.

So jetzt zu den Bildchen:

Eigentlich sollte das Rechteck ja so aussehen

1

     |¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|              

2

     |                 |      

3

_____|                 |_________

tut es aber nicht, es sieht so aus (nicht maßstabsgetreu)

1

     |¯|  |¯¯¯¯¯¯¯¯¯| |¯¯|              

2

     | |  |         | |  |     

3

_____| |__|         |_|  |_________

und das wandert dann auch noch weiter und sieht manchmal auch ok aus:

1

     |¯¯| |¯¯¯¯¯¯¯¯¯|  |¯|              

2

     |  | |         |  | |     

3

_____|  |_|         |__| |_________

1

     |¯¯¯||¯¯¯¯¯¯¯¯¯|   ||              

2

     |   ||         |   ||     

3

_____|   ||         |___||_________

1

     |¯¯¯¯|¯¯¯¯¯¯¯¯¯|    |              

2

     |    |         |    |     

3

_____|    |         |____|_________

1

     |¯¯¯¯¯¯¯¯¯¯¯¯¯¯|                   

2

     |              |          

3

_____|              |______________

Also ich vermutete, dass da die Reihenfolge der 16 Werte nicht korrekt 
ist, aber manchmal sieht es eben ok aus und ein Vertauschen bringt 
leider keinen Erfolg. Kann das sein, dass das normal ist wenn ich ein 
Rechteck in einzelne Werte zerlege? Das Komische ist nur, dass das 
Problem nicht auftrat als ich nur einen langen RAM verwendet habe und 
immer nur einen wert gelesen habe.
Oder schreibe ich das in genau der umgekehrten Reihenfolge wie ich lese?

Noch zwei Fotos:

Einmal mit vollem Zoom, also da wird wirklich je horizontalem Pixel ein 
anderer Wert aus einem anderen BRAM gelesen.
Und einmal um 1 rausgezoomt, also da ist jede Spalte der Mittelwert aus 
zwei Werten.

Man kann gut erkennen, dass es manchmal ok aussieht, aber eben nicht 
immer.

Und der Rechteck ist das 6. Bit eines 8-Bit-Binärzählers, also die 
Periodendauern sind nicht immer gleich lang, aber lang im Vergleich zu 
den zeitlich kurzen Fehlern.

Solche Geschichten kann man eigentlich sehr einfach simulieren.

Wie hast Du deine BRAMs parallel?
Wo ist deine TB?
Dein Code?

Standardanfängerfehler ist, die Adresse des Multiplexers, mit dem man 
postselektiert, nicht 1-2 Takte zu verzögern, damit er zur 
RAM-Adressierung und deren Delays passt. Dann liest man bein 
Grenzübergang falsch und erhält "sporadisch" falsche Daten

So, da bin ich wieder.

Die BRAMs habe ich wie oben beschrieben parallel, also ich nutze von 
jedem BRAM nur die Hälfte, also 1024x8Bits.
Ich nutze 16BRAMs habe also eine 14-Bit lange Adresse, davon sind die 
höheren 10 Bits die Adresse die an den BRAMs anliegt und die unteren 4 
Bits, also die die sich am häufigsten ändern wenn der 14-Bit Zähler 
hochzählt entscheiden in welchen BRAM die Daten gehen.

Also das ist dann so zeitlich, dass immer abwechselnd in alle BRAMs 
geschrieben wird weil nur so kann ich am Ende das Auslesen in einem Takt 
(dem Pixeltakt) so gestalten, dass ich bei der minimalen Zoomstufe 16 
Werte je Takt erhalte und diese addieren kann.

Eine Testbench habe ich nicht, den Code wird es geben wenn der ADC dran 
hängt und das alles schön funktioniert.

Und es funktioniert jetzt auch schon sehr fein, der Fehler war, dass ich 
die Daten zu schnell gelesen habe, also immer bei einem Punkt hatte ich 
dann noch die Daten von der alten Leseadresse. Behoben habe ich das 
indem ich in jedem Takt lese, weil ich brauche auch alle Daten, aber 
dann immer von den bis zu 16 Bits in Reihe das letzte aus dem vorherigen 
und die unteren 15 aus dem aktuellen Takt verwende.

Und wieder ein paar Bildchen:
Ich generiere mir meinen Sägezahn mit einem 8-Bit-Zähler der mit 50Mhz 
zählt, und mit derzeit 50Mhz schreibe ich auch, also das ist die 
Samplefrequenz.
Einmal reiche ich die Anschlüsse des Zählers auf Pins raus und mit 
Drähten wieder auf 8 Eingangspins, aber das sieht nicht schön aus, liegt 
aber an der externen Verbindung. Dann reiche ich auch die Daten vom 
Zähler intern weiter an den Eingang. Und für den Rechteck verwende ich 
extern des höchste Bit des Zählers.

Mal sehn wann der 200MHz ADC in der Post oder bei Zoll liegt.

Doch, das mache ich.

Ich habe intern einen 8-Bit-Zähler der mit 50MHz hoch und wieder runter 
zählt.

Und dann habe ich den Eingang, der nimmt einfach in jedem Takt (gleicher 
50MHz Takt) die 8 Bits und schreibt die in den BRAM.

So jetzt gebe ich das 8-Bit-Bitmuster des Zählers intern direkt an den 
Eingang und auch extern auf 8 Ausgangspins. Diese verbinde ich dann mit 
8 Eingangspins mit Litzen.
Und ich kann mit einem Schalter umschalten ob jetzt der interne Eingang 
genommen wird, oder die 8 Eingangspins. ich kann mir nur vorstellen, 
dass das Herausreichen der Leitungen und dann wieder das Hineinführen zu 
den Fehlern in der Darstellung führt.

Ist aber auch nicht wichtig, wenn die Platine mit dem ADC da ist, dann 
ist da ein eigener Taktgeber drauf für den Sampletakt und den Takt werde 
ich dann natürlich auch verwenden um im FPGA die Bitmuster in den BRAM 
zu schreiben.

So ich habe nochmal nachgedacht ... weil ich wuerde gerne mehrere Punkte 
speichern, also einen FPGA mit schnellem RAM verwenden.
Der Monitor ist aber eben XGA 1024x768. Das ist auch voll ok weil so 
passen die Werte fuer den Bildschirm sch[n in ein BRAM.
Jetzt munn man natuerlich auch nicht immer das Bild in Echtzeit aus 
allen Messpunkten bauen sondern kann das auch nur ab und zu machen.
Der Plan ist also regelmaessig alle Werte zu lesen und daraus dann die 
1024 Werte zu errechnen die angezeigt werden. Das wuerde zeitlich gut 
zwischen zwei Bildern passen, also im Video Blank.
Wenn ich dann wirklich externes RAM verwende wird es zeitlich vielleicht 
etwas eng, aber noch ist es nur BRAM. Geschrieben werden die Daten dann 
also waehrend des Bildes.
Ich habe das noch nicht umgesetzt, werde es aber die kommenden Tage mal 
ausprobieren.
Mein Ziel ist dann mit noch Bedienelementen ein DSO zu haben mit dem man 
schoen zoomen und durch die Zeit scrollen kann.

So, der ADC ist endlich da, es ist ein Flashy
http://www.knjn.com/Flashy.html
mit dem adc08200. (Datenblatt: 
http://www.ti.com/lit/ds/snas136m/snas136m.pdf)

Auf dem Board ist schon ein Taktgeber drauf, dieser Takt wird genauso 
wie die 8 Datenpins herausgereicht, kann aber, wenn man den Taktgeber 
überbrückt auch als Eingang verwendet werden.

So, jetzt schreibt der Hersteller im Democode:

reg [7:0] data_flash_reg;
always @(posedge clk_flash) data_flash_reg <= data_flash;

Das habe ich auch gemacht, in VHDL, also funktional den Takt genommen, 
an das FPGA gelegt (auf einen GCLK-Pin) und bei der steigenden 
Taktflanke werden die 8 Datenbits in ein Register geschrieben.

Das Bild ist aber total verrauscht, also es sieht sehr danach aus als 
würden nur manchmal die korrekten Daten im Register landen.

Dann habe ich mal im FPGA einen Takt erzeugt 75MHz und die an den ADC 
angelegt. Natürlich habe ich dann nicht bei der Steigenden Flanke 
gelesen, sondern mir den Takt im FPGA noch um 90° verschoben und den zum 
Takten des Leseprozesses verwendet.
Das sah schon sehr gut aus.

Im Datenblatt des ADC stehen auch Output Delays und Output Hold Zeiten 
drinnen, jeweils wenige Nanosekunden.
Wie kann ich denn den Takt nur um wenige Nanosekunden verzögern? Brauche 
ich dazu einen DCM oder gibt es da andere Tricks?

Vielen Dank!

Egal welche Taktflanke ich verwende, das sieht nicht gut aus. Kann 
natürlich auch daran liegen, dass ich das ADC board extern über ein paar 
kurze Drähe an das FPGA board angebunden habe. Also ich meine vielleicht 
sind da 133MHz zu schnell.

So, ich beobachte das Gleiche wie weiter oben schon beim externen 
Sägezahn. Jetzt habe ich einen Sinus (15kHz) angelegt und gucke die 
obere Hälfte an. Einmal komplett, und einmal die steigende Flanke in 1:1 
Auflösung.
Man sieht schön, dass es Stellen gibt an denen ein höherwertiges Bit oft 
falsch ist.

Der ADC, also dessen 8 Datenausgänge sind aber schön parallel mit 
ziemlich genau der gleichen Kabellänge an den FPGA angebunden.

Was kann ich da machen? Anscheinend passt der Takt ja, weil sonst wäre 
das wohl komplett falsch. Sieht so aus als wären die Datenbits nicht 
gleichzeitig am Ausgang.

Vielen Dank!

Und noch mehr Bilder, jetzt bei 75 statt 133MHz.
Ich reiche also die internen 75MHz heraus an den ADC und nutze nicht den 
darauf verlöteten Taktgeber.

Das Problem bleibt aber bestehen, wenn auch deutlich schwächer. Man 
erkennt immer auf gleicher Höhe deutliche Störungen in der Darstellung.

Auch wenn es schon "ok" aussieht, würde ich doch gerne einen höheren 
Takt nutzen und ein richtig sauberes Bild erhalten.

Vielen Dank!

Wie meinst du das mit dem Stören? Der ADC bekommt ja nur den Takt vom 
FPGA. Und auch anders herum, also wenn ich den Takt auf dem ADC Board 
nutze, gibt es die gleichen Fehler.

Und noch mehr Bilder:
Das ist jetzt normales Audio das ich da angelegt habe, und ich habe 
lange belichtet, einmal mit und einmal ohne Zoom. Auf dem Bild Zoom 
erkennt man schön, dass die Fehler immer auf derselben Höhe auftreten.
Das sind ja 8 Bits, und ich vermute, dass also die beiden höchstwertigen 
Bits manchmal nicht passen.
Bei dem Bild Ohne Zoom erkennt man wie es 1:1 aussieht. Das Signal 
zittert also sehr schnell um den Wert des hohen Bits hin und her. Die 
weiße Fläche ist ja wenn es dauernd, also in jedem Takt von hoch nach 
niedrig und wieder zurück wackelt.

Warum das so ist kann ich mir nicht erklären.
Ich reiche jetzt 50MHz aus dem FPGA an den ADC und nutze die fallende 
Flanke um die Daten zu übernehmen.

Zwischen den Boards sind das so 10cm.
Masse ist auch so ein Draht, das sind dünne Kupferdrähte die jeweils 
isoliert sind.
Abgeschirmt ist nichts, wie könnte ich das denn machen wenn alles nur 
Pfostenstecker und so Buchsenleisten sind?
Terminiert habe ich auch nichts, weil der ADC-Board Hersteller das Board 
auch direkt mit einem getrennt zu erwerbenden FPGA-Board verbunden hat 
über einen Steckverbinder, also direkt an die FPGA IOs. Ich habe als IOs 
die PMOD von Digilent genutzt, also eigentlich auch direkt an den FPGA 
aber noch mit ESD Schutz.
Den Draht mit dem Takt habe ich in die Buchse für einen zusätzlichen 
Taktgeber auf dem Board gestekt.

Ja ist nicht optimal, vermutlich sollte ich mir ein FPGA Board kaufen, 
bei dem ich das direkt an die FPGA IOs löten kann.

Du hast ein eindeutiges Timingproblem in Deinem Design. Entweder tastest 
Du intern noch was ab, addierst die BRAM-Ausgänge nicht korret oder Du 
gibt die Daten nicht passend zum Takt raus.

Welche Relation braucht der DAC?
Hast Du IO-Zellen drin?
Stimmt die Taktpolarität?

Solange Du das nicht beschreibst und den Code zeigst, wird das ein 
Fischen im Trüben bleiben, fürchte ich.

Ich habe keinen DAC sondern einen ADC mit Ausgängen. Mein Problem ist 
entweder diese Ausgänge zum richtigen Zeitpunkt in ein Register zu 
schreiben (und danach in den BRAM) oder, dass die Datenbits nicht 
gleichzeitig richtig am FPGA anliegen, ich also zu keinem Zeitpunkt die 
richtigen Daten in ein Register speichern kann.

Im Code ist eigentlich doch nur das Abspeichern in ein Register und 
vielleicht noch der DCM interessant.

Hm, das klingt nach Lötaction^^ Ich schlachte jetzt hier ein 
teildefektes FPGA Board und löte das direkt dran, mal sehn ob das was 
bringt.
Jedenfalls vielen Dank!

So hier mal Fotos.

Der rote ist die Clock und mit Masse umwickelt. Der ist etwas länger 
weil ich auch einen GCLK Pin wollte.

Ich habe aber mittlerweile eine andere Vermutung, und zwar sahen schon 
oben der Sägezahn extern schlecht aus, also der hatte auf der Hälfte, 
bei 1/4, bei 3/4 ... Fehler.
Es sieht für mich also so aus, als würde ein höherwertiges Bit kippen, 
wenn viele der niedrigeren Bits auf '1' sind. Unter Anderem deshalb habe 
ich jetzt den ESD-Schutz auf dem Board weggelötet damit die einzelnen 
Pins ganz sicher nichtmehr untereinander verbunden sind.

Alter was hast du mit dem Board gemacht? Puh... gegrillt wird draußen 
mit freunden und bier.

Gruß jonas

@  Merkbefreit:
1. Habe ich das auch schon so oben beschrieben
2. Geht der ADC erst ab 20MHz.

Also das ADC Board hat einen 133MHz Taktgeber drauf, den Takt führe ich 
in das FPGA und schreibe mit diesem Takt die Daten ins BRAM. Aber da 
entsteht nur Müll bei. Aber wenn ich den Taktgeber auf dem ADC Board 
lahm lege und den ADC vom FPGA aus Takte, z.B. mit 50MHz, und dann auch 
mit synchronem Takt die Daten abspeichere sieht es einigermaßen gut aus.

@ Jonas Biensack:
Ja schon klar aber es ist heute nicht soo warm draussen. Und leider ist 
auch mein Lötkolben eher zum grillen als zum Löten geeignet.

Das mit den festen Signalen ist eine sehr gute Idee, danke!

Einen Clockout hbe ich nicht, aber ich kann ja die andere Taktflanke 
nehmen oder den Takt um 90° verschieben.

was auch bei ~100MHz noch ganz gut als 'drahtverhau' funktioniert:
besorg' dir flachbandleitungen - nicht die normalen flachbandkabel, 
sondern die FFC variante, eben flexleitungen, wie hier unten zu sehen:
http://www.esskabel.de/upload/images/produktbilder/FFC-FDC-Flex_Jumper.jpg
conrad hat sie auf jeden fall (papier- sowie kunststoff-variante).
die lassen sich auch in der breite auf beliebige leiterzahl kürzen, 
mittel schere, in der länge allerdings nicht.
um das ganze für schnellere signale tauglich zu machen brauchst du dann 
noch selbstklebende metallfolien, kupfer oder kupfer verzinnt.
dieses ist dann beidseitig auf die ffc-leitungenaufzubringen, wenn die 
kupferfolie breit genug ist kannst du auch eine tasche falten und das 
kabel hinein legen, so sind die beiden seiten nicht nur über den 
leitenden kleber verbunden.

Sind diese PMOD Anschlüsse nicht mit Widerständen usw. gegen zu viel 
Spannung geschützt? Das müsstest du dann alles mal rausbauen, denn das 
verschleift die Signalflanken ja extrem...

Ja irgendwo habe ich einen Fehler drinnen.

Jetzt nehme ich den 133MHz Takt vom ADC und führe den in das FPGA. An 
den Dateneingang lege ich an nur einen Pin einen FPGA Ausgang an. Und 
zwar den eines Zählers der mit einer niedrigeren Frequenz zählt.

Man sollte jetzt also ein Rechteck bekommen - und das bekomme ich auch, 
aber mit genau den gleichen Fehlern wie im ersten Bild das in in diesem 
Thread gepostet habe.

Die Widerstände der PMODs habe ich schon rausgelötet, also daran sollte 
es nicht liegen.

Und es sieht auch so aus als käme das Signal gut durch, wenn ich mit der 
externen 133MHz Clock den langsameren Rechteck abtaste und anzeigen 
lasse bekomme ich wirklich den Rechteck (mit Fehlern) aber die Flanken 
sind immer im gleichen Abstand, also zwischen zwei Flanken kommt immer 
die gleiche Anzahl an Sampletakten. Die 133MHz kommen also wirklich 
richtig an.

Ich bekomme diese Fehler aber nur, wenn ich den Externen Takt nutze.
Auch wenn ich die Daten, also den Rechteck intern mache und nur den 
externen Takt verwende gibt es Fehler.

Ich könnte ja verstehen, dass es direkt an der Flanke des langsamen 
Rechtecks nicht klar ist welcher Wert gespeichert wird, weil der 
Sampletakt nicht synchron zum Rechtecktakt ist, aber mitten im Rechteck?

Verwende ich einen internen Sampletakt passt alles.

Dann stimmt wohl was am Takt selber nicht. Ist der mit einem 33 Ohm 
Widerstand wenigstens serien-terminiert?

Ne da ist kein Widerstand drinnen.
Also:
Ich habe diesen Takt und mit dem will ich die Daten in ein BRAM 
schreiben, also zähle ich die Schreibadresse hoch und lege die Daten an 
den BRAM Eingang an.

Mit dem internen Takt geht das super, aber mit dem externen nicht. Ich 
lege als Daten nur auf einen Pin einen langsameren Takt (deutlich 
langsamer) der dann als Rechteck zu sehen ist. Da die Rechtecke gleich 
groß sind (breit) sind auch die gleich Zahl an Taktperioden des externen 
Takts richtig angekommen weil die Schreibadresse jeweils um die gleiche 
Zahl weitergezählt wurde.

Und dann gibt es aber stellen an denen nur ganz kurz, also ein Wert 
falsch ist, also satt hoher Pegel beim Rechteck ein niedriger oder so. 
Das kann ich mir nicht erklären wenn ja doch die richtige Zahl an Takten 
ankommt und das Rechteck mit internem Takt gut aussieht.

Kann man einen externen Takt irgendwie "korrigieren"? Also vielleicht 
passt der "Duty cycle" nicht, also zwar zum Adresse zählen aber nicht 
für den BRAM.

So, Fehler hoffentlich gefunden. Ich brauche natürlich ein Dualport BRAM 
...