hallo zusammen! Mir fällt kein besserer Betreff ein. Es geht um folgendes: ich experimentiere mit einem TFT mit 24 bit rgb Interface. Das funktioniert auch wie gewünscht. Derzeit wird ein Testbild ausgegeben welches anhand von Pixelzählern und hsync/vsync Timings generiert wird. Was ich nun möchte ist es mit den Schaltern meines eval Boards verschiedene Farbquellen auszuwählen. d.h. ich kann ein festes Testbild jetzt schon generieren. Dann möchte ich sicher einen Framebuffer anzeigen, einen Textgenerator, einen Framebuffer im externen RAM, double buffered Framebuffer, ein Signal vom A/D Wandler, klassisches Pong..... Jetzt soll das Alte aber nicht weggeworfen werden sondern das Design soll wachsen. Wenn ich mit 8 Schaltern aus maximal 8 entities auswählen möchte, die irgendwie Pixelwerte ausspucken bin ich mir unsicher wie ich das am besten mache. Ich bin bei FPGA ein Neuling, bezüglich Digitalschaltungen habe ich grundkenntnisse, daher bitte ich um Hilfe. Mir würde einfallen: - Das TFT Interface bekommt die Pixeldaten aus einem Multiplexer der dann im Extremfall ein 8x1 mux ist. Nur bei 24 bit Farbtiefe stelle ich mir einen Mux als Monster vor. Jedenfalls wenn ich mir das als 74er Platine vorstelle. - Alle Entities die Pixeldaten ausspucken bekommen ein enable Signal welches ich aus den Schaltern erzeuge. Könnte ich dann auch theoretisch 2 entities gleichzeitig aktivieren? Intern währen die Komponenten ja an Signale angeschlossen. Dürfen dann mehrere quellen gleichzeitig ihre Daten auf das Signal schreiben? - Die Entities als eine Art Bus schalten? Aber so weit ich es verstanden habe geht es innerhalb des FPGA nicht tri-state Buffer zu machen um die Quellen zu trennen - ??? Ja wie gehe ich mein Problem an? Ich werde an dem Projekt sicher noch lange spielen. Einmal zum lernen, einmal wegen Zeitmangel. Darum soll es zum einen möglichst nicht zu unsinnig angegangen werden und außerdem weiß ja jeder dass man sich einmal falsch eingeprägtes sehr schwer abschütteln kann.... Ich danke euch!
Multiplexer ist das einfachste und erfüllt deine Anforderung. Nicht in Gattergräbern denken. Auf dem FPGA sind das 3 bis 6 LUTs, die da draufgehen. Von 50.000 die dir z.B. zur Verfügung stehen... Die anderen Lösungen erzeugen nicht weniger Logik.
Christian F schrieb: > Wenn ich mit 8 Schaltern aus maximal 8 entities auswählen möchte Mein Tipp: lass das. Das ist kindische Spielerei: das behalten, was man schon hat, und noch mehr dazubekommen. Du kämpfst so immer mit alten, unerfahrenen Beschreibungen herum und traust dich nicht, mal was komplett Neues und Anderes auszuprobieren. BTW: zur Auswahl von 8 Quellen auf 1 Ziel braucht man nur 3 Schalter. Du musst dir das Hardware-Denken noch antrainieren... Christian F schrieb: > Darum soll es zum einen möglichst nicht zu unsinnig angegangen werden Mach für jedes Design ein neues Projekt und kopiere das, was von einem Alten Design brauchbar ist, ins neue hinein. Nur so wirst du dich und deinen Beschreibungsstil weiterentwickeln. Ich habe z.B. gut 1000 kleine und große Designs abgelegt und kann da immer wieder mal schauen, ob sich irgendwas mit der Toolchain getan hat.
:
Bearbeitet durch Moderator
Für mich wäre es im obigen Fall jetzt angenehmer je Verhalten ein bit vorzusehen. Wenn ich meine Phantasie spielen lasse und als Pixelquelle verschiedene simple Videospiele ala Pong annehme dann ist das doch schöner. Aber,ja, ihr habt grundsätzlich sicher Recht damit lieber zeitig einen cut zu wagen, als alles krampfhaft mit zu schleppen. Bei dem Projekt ist das Gerüst aber ja quasi erst mal die TFT Ansteuerung - ohne dass mir einer da Fehler zeigt, wüsste ich auch nicht was ich beim Neustart anders machen würde.... hm. Nun aber grundsätzlich wäre, allgemein gesehen, der richtige Weg die einzelnen Daten zu multiplexen?
Schaue Dir bitte nochmal Deine Liste an: > ... ein festes Testbild jetzt schon generieren. Dann möchte ich > sicher einen Framebuffer anzeigen, einen Textgenerator, einen > Framebuffer im externen RAM, double buffered Framebuffer, > ein Signal vom A/D Wandler, klassisches Pong..... und nimm einmal an, Dein Problem sei nicht eines der Signalumschaltung sondern des "Systemdesigns". Die Liste ist von diesem Standpunkt aus sehr heterogen - sie nennt Elemente die in einer Reihe von denkbaren Gesamtsystemen sehr unterschiedliche Stellungen einnehmen. - Ein "Framebuffer" und ein "Framebuffer mit externem RAM" sind strukturell eine Teileinheit eines Systems in dem Bilder angezeigt aber nicht notwendigerweise "erzeugt" werden. Ausserdem ist die Bezeichnung "Framebuffer" generischer als "Framebuffer mit externem RAM". Analoges gilt für die Beziehung zwischen "Framebuffer" und "double buffered Framebuffer". - Hingegen sind "Framebuffer mit externem RAM" und "double buffered Framebuffer" sozusagen "orthogonale" Begriffe. Sie beziehen sich nicht unmittelbar aufeinander. Es mag beides in Kombination vorliegen oder auch nicht. - Ein "Textgenerator" ist weder mit den verschiedenen "Framebuffer"-Varianten vergleichbar noch mit einem "A/D-Wandler" noch mit "Pong". Er wandelt lediglich einen ASCII-Code in eine Menge von Pixeln um. Insofern wäre er, je nach Systemdesign (da ist er, der Begriff) eine Teilstruktur eines Pong-Spiels (für die Spielstand-Anzeige) oder eines "A/D-Wandler" (für die Messwert-Anzeige). Vielmehr ist der "Textgenerator" vergleichbar mit den ungenannten Teilstrukturen, die aus A/D-Wandlungsergebnissen eine Grafik erzeugen oder aus X-Y-Position der Bälle und Schläger das Bild dieser Elemente im Spielkontext. Möglicherweise ist Dir nun schon klar, worauf ich hinaus will. Ein "Umschalter" oder Multiplexer ist zwar eine für den Anfänger naheliegende abstrakte Möglichkeit, dass Problem in einem ersten Schritt zu beschreiben. Aber es passt im Detail dann doch nicht wirklich so, dass man ein ökonomisches Design daraus machen kann. Würde man so nämlich fortschreiten, hättest Du ein Pong-Spiel, einen A/D-Wandler, eine Textanzeige usw. die in sich komplett sind und bei denen am Ende über einen Multiplexer nur noch das Videosignal ausgewählt wird. Nun stammt der Vorschlag eines "Multiplexers" nicht von Dir; Du wirst Dich demnach mit Recht missverstanden fühlen können. Es geht mir aber nicht so sehr darum, dass lediglich der Multiplexer ein unpassendes Detail ist, sondern darum, Dich dazu zu bringen, Dir das Gesamtsystem vorzustellen. Ich könnte Dir da jetzt mal eine Skizze machen, möchte das jedoch (vorerst) nicht tun. Vielleicht magst Du das ja mal versuchen. Es wird zwar nicht 100%ig hinhauen, aber "aus Fehlern lernt man" - "am meisten" könnte man hinzufügen. Ein Ansatzpunkt sollten die oben erwähnten Bemerkungen zu den Unterschieden zwischen den genannten Einheiten in Bezug auf Ihre Funktion sein. Ich hoffe das Dir das hilft, wenn es auch keine simple Antwort ist.
Hm. Doch also ich hatte ursprünglich schon an einen Multiplexer gedacht der rgb Werte aus völlig unterschiedlichen Quellen durchschaltet. An der länge deines Posts sehe ich, dass du dir einige Gedanken gemacht hast mir etwas zu sagen. Was das ist, ist mir noch nicht so ganz klar... Ich werde also noch mal zu Gemüte führen und auf eine Erleuchtung hoffen. Als dann vielen Dank!
Die These das das (mein) Problem im Systemdesign liegt ist naheliegend und vermutlich DAS Kernproblem. Es fällt ja auch nichts vom Himmel. Ich habe das nicht wirklich gelernt aber die Herausforderung angenommen. Ich muss feststellen, dass ich das 'erweitern' des Designs ganz charmant finde, weil ich dann etwas angehen kann, was ich glaube zu verstehen bzw zum entsprechenden Zeitpunkt in den Griff zu bekommen. :-( Aber so eine richtige Alternative fällt mir auch nicht ein. Der Vorschlag zu Beginn ein entsprechend komplexes Design komplett zu erschlagn ist wohl sinnvoll, aber ich sehe leider dazu noch keinen Hebel... Beispiel: Ich könnte mir vorstellen, dass als nächster Schritt einen Framebuffer auf dem Display anzuzeigen derzeit im Bereich des Machbaren ist. Wenn auch wundersame Weise Daten im Speicher stehen, und ich bei dem Cellular Ram vom Nexys Board den SRAM Modus benutzen kann. Wenn ich aber auch Daten reinschreibe bin ich bei allem Überlegen immer wieder früher oder später am Ende. Egal wo die Daten herkommen, von einem Controller über spi oder von einem Modul was Linien malen kann...irgendwann kollidiert die Schreibadresse ja mit der Leseadresse. Das kann ich ja abfangen und das Schreiben in dem Fall einfach einen Zyklus verzögern....aber diese Kollision könnte ja öfter passieren, so würde das reinschreiben ja immer weiter nach hinten durchrutschen... Ich hoffe ihr versteht was ich meine. Deshalb war meine Vorstellung dieses derzeit(vermeindlich) unlösbare Problem, nämlich etwas konkret umzusetzen, etwas double buffered zu machen. Das ist natürlich Vermeidungstaktik und wird früher oder später wieder vor den Poller laufen. Über Ideen oder Vorschläge wie ich meine Blockade überwinden kann wäre ich dankbar. Ich hab es nicht gelernt. Gilt auch für Blockschaltbilder zeichnen - anscheinend echt schwer wenn man das nicht Schritt für Schrit gelernt hat.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.