Hallo, ich möchte in den kommenden Tagen ein kleines 1-Kanal-DSO basteln und habe mir dazu auch schon das Flashy http://www.knjn.com/ShopFlashy.html bestellt. Derzeit generiere ich mir einen digitalen Rechteck/Sägezahn den ich einfach auf 8 Eingänge gebe und mir dann angucke. Das eigentliche Problem ist aber die Speicherverwaltung. Ich gebe das Bild mit 75MHz Pixeltakt am VGA (xga) Bildschirm aus, also immer 1024 Werte in der Horizontalen. Ich will aber mehr Werte speichern und die dann zusammenfassen. Die erste Herangehensweise war einen fetten RAM im FPGA zu erstellen mit 32768 * std_logic_vector(7 downto 0), da die Daten der Reihe nach reinzuschreiben und auszulesen. In verschiedenen Zoomstufen dann eben nur jeden 1., 2., ... , 32. Wert zu lesen und anzuzeigen. Das funktioniert auch wunderprächtig, hat aber Nachteile, weil ja dann Werte nicht beachtet werden. Besser wäre es immer alle Werte zu lesen, und dann Mittelwerte für die einzelnen Pixel zu bilden wenn sonst nicht alles auf den Monitor passt. Ich habe einen XC3S1200E mit 28 BRAMs von denen ich 16 nutze. Also parallel lesen und schreiben: 16*1024*8Bit BRAM (wenn ich die vollen 2k je BRAM verwenden wollte müsste ich doppelt so schnell lesen). Beim Schreiben mache ich die Aufteilung über die WEs der BRAMs, also ich habe einen Zähler von 0 ... 16383, die vorderen 10Bits sind die Schreibadresse, die letzten 4Bits sagen in in welchen der 16 BRAMs der Wert geht. Beim Lesen mache ich das ähnlich, also je nach Zoomstufe lesen ich aus allen gleichzeitig über die vollen 1024 Werte und addiere dann die 16 Werte je Spalte und teile das durch 16, bis hin dass ich nur die vorderen 64 werte jedes BRAMs lese, aber dann nacheinander in der Reihenfolge wie sie geschrieben wurden. Also eigentlich funktioniert das auch, aber es sieht nicht immer gut aus, manchmal sieht es so aus, also würden manche Werte zu einem falschen Zeitpunkt ankommen. Meine Frage ist eigentlich: Hat Jemand das schonmal gemacht und irgendwelche Tips? Also vielleicht ein eleganteres Verfahren zur Speichereinteilung? Oder gerne auch eine schöne Triggerfunktion? Ich triggere derzeit indem ich über zwei Bereiche den Mittelwert bilde und gucke welcher der beiden größer ist und wenn sich das ändert, dann starte ich den Zähler. Funktioniert bei Rechteck/Sägezahn auch schon sehr gut.
Gustl Buheitel schrieb: > > Also eigentlich funktioniert das auch, aber es sieht nicht immer gut > aus, manchmal sieht es so aus, also würden manche Werte zu einem > falschen Zeitpunkt ankommen. > Timing constraints erfüllt? 16 Werte in einem Takt addieren ist anspruchsvoll, auch nicht zu vergessen die Multiplexer die wegen der verschiedenen Zoomstufen gebraucht werden. Bei höheren Frequenzen wird man da pipelinen müssen.
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?
Angehängte Dateien:
-
voller_zoom.jpg
1 MB -
eins_rausgezoomt.jpg
900 KB
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
Angehängte Dateien:
-
externer_sa_gezahn_1k.jpg
29 KB -
interner_sa_gezahn_1k.jpg
29 KB -
interner_sa_gezahn_16k.jpg
67 KB -
externer_rechteck_1k.jpg
16 KB -
externer_rechteck_16k.jpg
37 KB
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.
Gustl Buheitel schrieb: > aber das sieht nicht schön aus, > liegt an der externen Verbindung. nee, liegt an der Schaltung. Bild zeigt eindeutig ein Synchproblem: Du gibst die Daten nicht snyhcorn zum Takt raus.
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!
Hört sich komisch an mit den 90 Grad. Entweder edge aligned oder center aligned mit 180 grad und diese entweder über dc oder falling edge
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!
Mal in eine andere Richtung vermutet: Digital ist evtl. alles ok, aber der ADC wird durch den FPGA über die Versorgung gestört?
Angehängte Dateien:
-
Zoom.jpg
170 KB -
Ohne_Zoom.jpg
160 KB
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.
Gustl Buheitel schrieb: > 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. Wie kurz sind diese Drähte? Wie ist Masse geführt? Wie ist die Clock von den Daten abgeschirmt? Wie sind die Signale terminert?
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.
Gustl Buheitel schrieb: > 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? Das macht schon deutlich unter 100 MHz schlapp Füge da mal massiv GND Verbindungen hinzu, so für 3-4 Datenleitungen eine, und wickle sie um kleine Bündel von Datenleitungen. 3-4 Windungen wirken bereits Wunder. Für die Clockleitung ditto, da aber eine dedizierte Masseleitung, und 4-5 Windungen. Eventuell mit einen Serienwiderstand an der Quelle abschliessen. Die Masseleitungen ausserdem so nah wie möglich an den davon "abgeschirmten" Leitungen auf die Boardmasse. Auf keinen Fall etwas auf der anderen Seite des Boards nur weil da vielleicht so ein schön dicker GND Testpin ist. > 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. Das ist aber eine Onboardverbindung mit ordentlichen Massebezug.
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!
Gustl Buheitel schrieb: > Hm, das klingt nach Lötaction Du kannst ja auch mal ein Bild von Deinem Aufbau hier einstellen... Duke
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.
Wenn du den ADC von extern eine CLK gibst musst du bei den Geschwindigkeiten auf der CLK vom ADC triggern und nicht auf deiner FPGA CLK, d.h. das der FPGA synchron zur ADC CLK laufen muss oder du baust dir noch eine Daten-Synchronisierung mit ein. An deiner Stelle würde ich mal bei 1MHz oder etwas mehr anfangen und dann bei deinem Drahtverhau max. bis 50MHz gehen.
Alter was hast du mit dem Board gemacht? Puh... gegrillt wird draußen mit freunden und bier. Gruß jonas
Jonas Biensack schrieb: > Alter was hast du mit dem Board gemacht? Puh... gegrillt wird draußen > mit freunden und bier. Brat, Brat, Fett, Fett.
@ 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.
Angehängte Dateien:
-
SAMPLE.JPG
61 KB
SOOO viel umwickelt ist auch nicht gut. Da ist jetzt ein nicht zuvernachlässige Induktivität auf der Masseleitung. Ich meinte das umwickelen eher im Sinne von twistet Pair. Die 3-5 mal bezogen sich auf dein ürsprünglichen 10 cm. Ausserdem ist das die einzige Masseverbindung? Wenn ja, eine 2. hinzufügen für die Daten, die auf dem Boards neben den Datenleitungen angeschlossen bzw gelötet ist. Die für die Clock sollte ungefähr die gleiche Länge wie die Clockleitung haben. Das angehängte Bild zeigt einen Testaufbau von mir, die Kabel sind 10 cm, erreicht wird >120 MHz. Allerdings nicht so viele Datenleitungen parallel.
Gustl Buheitel schrieb: > 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. Dann lege ein festes Signal an und schau was passiert, wenn dort Müll erscheint ist etwas anderes faul. > 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. Weniger Müll. Um bei der Geschwindigkeit die Daten zu lesen brauchst du den CLK-Output vom ADC, der braucht etwas zum Wandeln, ansonsten gibt es Müll, wie von dir schon bestätigt. Ordentliche ADC-Bausteine bieten diese Möglichkeit.
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 ...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.