hallo zusammen, kurz zu meiner Ausgangslage / Problem: ich habe ein Displaypanel vorliegen welches mit 18 Bit digital RGB angesteuert wird. Displaydaten: Panel Model LB070WQ5-TD01 Panel Typ Si TFT-LCD Panel Größe 7.0 inch Auflösung 480 x 240, WQVGA Aspect Ratio 17:9 (W:H) Interface Digital parallel RGB Interface Model FH12K-40S-0.5SH Display Farbraum 262K (6-bit) Nun möchte ich mit Hilfe eines FPGAs das vom Grafikcontroller ausgesendete untypische Format (480 x 240) dahingehend abändern, um auch in Europa existierende Displays ansteuern zu können :). Das Problem ist hierbei, das ich nicht auf den eigentlichen Grafikcontroller zugreifen kann, um das Format direkt zu ändern, sondern nur die Signale abgreifen kann. Weiterhin ist zu bedenken, dass der Grafikcontroller kontinuierlich Videodaten ausgibt, d.h. ich greife auf keinen Speicher zurück . Weiterhin sind laut Angaben folgende Frequenzen für Sync und clk gegeben: ______________________________________________________ Display Signal Min Typ. Max Unit 7‘‘ WQVGA VSync 37.75 57.39 79.44 Hz HSync 12.46 14.86 19.86 kHz Pixel Clock 7.80 8.80 11.40 MHz ______________________________________________________ Zu meinen Überlegungen: Ich lese die parallel vorliegenden Daten mit einem FPGA ein (Programmierung in VHDL - hier schon etwas Erfahrung gesammelt)und formatiere diese auf ein gängiges Format ( HVGA(480x320), VGA(640x480), WVGA(800x640), etc...). Theoretisch müsste ich ja die Frequenzen von CLK HSync, VSync, De, dementsprechend anpassen (Zähler). Die zusätzlich erzeugten Pixel müssen dann iwie in Abhängigkeit der einzulesenden interpoliert werden (noch kein Plan wie). Weiterhin benötige ich ja ein gewisses Speichervolumen (SDRAM), um vorab sagen wir ein komplettes Bild (18 Bit *480*240 = 254 kByte (min)) einzulesen. bräuchte einen kleinen Schups in die richtige Richtung, da ich auf diesem Gebiet noch keine all zu großen Erfahrungen gesammelt habe. - Hat jmd damit schon Erfahrung gesammelt? - geeigneter FPGA + Board + Software? - realisierbar ? wenn ja in welchem Zeitrahmen +- ? - nicht bedachte Problemfelder ? MFG
Schaue Dir die Video Suite von ALTERA an. Da ist alles drin. Kostet aber eine "Kleinigkeit". Oder Du schreibst einen Scaler selber -- habe ich auch mal gemacht. Ist aber nicht ohne (vor allem wenn man qualitativ hohe Qualität erreichen möchte). In Deinem Fall wäre so ein Scaler viel einfacher aufgebaut, weil Du nur Y Koordinate skalieren musst. Also ich vermute mal, man könnte komplett ohne externen Speicher (Framebuffer) hinkommen, wenn man nur ein Paar Zeilen zwischenspeichert und daraus die neuen Interpoliert. Allerdings, falls Du noch zw. PAL/NTSC konvertieren müsstest, dann bräuchtest Du schon einen Framebuffer. Kest
Arg, falsch gelesen, Du möchstest ja auch andere Auflösungen unterstützen (also nicht nur Y-verschieden)! Okay, wird etwas komplizierter, aber theoretisch geht es immer noch ohne Framebuffer (allerdings mit genügend Zeilem im Onchip-Ram) Kest
Tronix schrieb: > - Hat jmd damit schon Erfahrung gesammelt? Ja. > - geeigneter FPGA + Board + Software? Jeder halbwegs aktuelle FPGA kann das. Die Aufgabe an sich ist nicht allzu aufwendig: ein paar Zähler und die RAM-Umschaltung. Mit Nachdenken und Timinganalyse ist am meisten zu holen. > - realisierbar ? Ja. > - wenn ja in welchem Zeitrahmen +- ? Ohne VHDL-Kenntnisse und FPGA-Erfahrung bis zur Serienreife? 1 Jahr. Mindestens. > - nicht bedachte Problemfelder ? Evtl. brauchst du doppelt so viel Speicher, weil Double Buffering nötig werden könnte...
Hallo, das hört sich auf den ersten Blick schon mal ganz gut an. Danke! Kann mir Jmd. ein geeignetes FPGA+Board nennen? Sollte nicht zu teuer sein, d.h. ich brauche kein Superboard das noch 1000 Dinge mehr erledigen kann. Brauche halt eines gewisse Perepherie für meine I/Os. Würds auch selbst zusammen basteln, aber dafür fehlen mir die Mittel. Diese Frage hat nichts damit zu tun, das ich zu faul zum suchen bin, die Auswahl ist einfach zu groß :) und mir fehlt einfach dei regelmäßige Praxis Erfahrung.
Ramon F. schrieb: > Kann mir Jmd. ein geeignetes FPGA+Board nennen? Ein Spartan 3 mit externem SRAM wäre ok. Ich würde dir mal das vorschlagen: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_114_119&products_id=569
Ein Board zu empfehlen ist nicht einfach. Vielleicht reicht ja schon ein DE0 oder DE1 von TErasic. Da sind 2 Erweiterungsstecker drauf, da könntest Du Dein Display und die DAten vom Grafikcontroller anschließen. Aber ein bisschen rechnen solltest Du schon vorher -- also ob SDRAM Bandbreite ausmacht, ob man mit internen Speicherblöcken hinkommt und so weiter und so fort Kest
> Ein Spartan 3 mit externem SRAM wäre ok. Ich würde dir mal das > vorschlagen: > http://shop.trenz-electronic.de/catalog/product_in... thx, auch nach weiterer Suche bin ich zu dem Entschluss gekommen, das dieses Board vollkommen meinen Anforderungen entspricht. Jetz hab ich nur noch eine Frage was die Software angeht. ISE WEBpack ist ja laut Angaben kostenlos - d.h. downloaden und Lizenz für ein Jahr beantragen. soweit gut. Aber gilt das nur für die private Nutzung oder ist das auch für Unternehmen zulässig? Hab jetz Berichte gelesen, die einen sagen ja, die anderen nein. Was stimmt den jetz? MfG
Ramon F. schrieb: > ISE WEBpack ist ja laut Angaben kostenlos ... > Aber gilt das nur für die private Nutzung oder ist das auch für > Unternehmen zulässig? Du kannst das Webpack auch im Geschäft verwenden. Merke: Xilinx will FPGAs verkaufen, nicht vorrangig die Toolchain.
Angehängte Dateien:
-
VGA_Timing.png
77 KB
hi, so komm eig recht gut zurecht, jetz hab ich aber noch eine kleine Verständnisfrage zu den Timing Signalen. Hab mir jetz einen code geschreiben der mir erst einmal meine VGA 640x480 / 60Hz Timing Signale (Vsnc, Hsync, De) erzeugt. Nun meine Frage. (Bild dazu im Anhang) Gestartet wird ja mit der steigenden Flanke des Vsync Signals!. Läuft das Hsync Signal immer mit, d.h. auch während der vertikalen blanking Phase (TVp + TVs) oder startet dies erst zu Beginn von TVd (Valid Date), also mit begin der aktiven Pixelzeilen? THX
Versuche erst einmal das Bild in der neuen Auflösung zu zentrieren. Das richtige Timing ist das Hauptproblem. Skalieren und zwischenspeichern kannst du in einem 2. Schritt machen.
ahhh ok aber das enable Signal nur während der aktiven Phase, also dementsprechend nur 480 mal pro Bild ?
Einmal pro Zeile, würde ich mal behaupten, oder? Zum generellen Timing VGA gibt es ja dies hier: Projekt VGA Core in VHDL Kannst Du eine Ganzzahl-Interpolation machen und schwarze Ränder einführen? - dann ist die Interpolation mit einem einfachen Ganzzahlzoom (Duplikation der Werte) + Kantenschärfung mit Diamantfilter möglich. Wenn Du mit float interpolieren musst, weil Du "krumme" Werte hast, brauchst Du ein CIC-Filter, bei hohen Ansprüchen noch ein FIR-Filter dahinter, welches eine Kompensation / Anhebung im Bereich der Nyquist-Frequenz besitzt. Ich hätte da einen Core anzubieten, der das gesamte skalierbar- und parametrierbar leistet, und auch mit nicht zusammenpassenden Taktdomainen klar kommt, wenn also die Horizontalfrequenzen der beiden Videotakte (In, Out) kein einfaches Verhältnis haben, oder die Frameraten nicht passen. Kostet aber nicht nur eine "Kleinigkeit". :-)
Gehört zwar eigentlich nicht hierhin, aber bei diesen ganzen Video-Geschichten half mir ein BF561-Evalboard massiv zum Testen. Der BF561 ist ein Dualcore-DSP mit zwei Videoports, auf dem Video-Erweiterungsboard kann man auch digital-Video einspeisen bzw. ausgeben (LVDS-Treiber). Damit liess sich zumindest mal NTSC auf VGA/PAL konvertieren. Wenn dann die Assembler-Geschichte steht, muss man sich seine Algorithmen noch in die Hardware giessen (von den DSP-Tricks kann man sehr gut auch für's FPGA lernen), und die Wahrscheinlichkeit ist gross, dass man das Konzept nich mehr kippen muss. Schlussendlich muss man dann allerdings auch die Rechnung machen, was entwicklungs versus Material-technisch billiger kommt. Grüsse, - Strubi
hey danke für eure Kommis, hat mir bis jetzt echt weitergeholfen. hab mich jetzt für das Spartan 3 Board entschieden und auch schon die ersten Module soweit erstellt, simuliert und synthetisiert. läuft!!!! nun bin ich dabei die einzelnen Datenbits einzulesen und zwischen zuspeichern. Da sowohl mein Eingangs- als auch das Ausgangsformat mit einer Widerholfrequenz von 60 Hz arbeiten, reicht es ja ein Frame zwischen zuspeichern (640x480 x 18 Bit = 253,125 KByte Farbinfos). Mein Board besitzt ein asynchronen 1 MByte ( 2 x 0.5 MByte) großen SRAM. also 2 mal 256Kx16 SRAM (10ns) IDEE: Ich arbeite mit beiden, auf dem einen schreibe ich die Daten, auf dem anderen lese ich alle 1/60 Sekunde aus ( und umgekehrt). soweit gut! Jetz fällt mir aber auf, das ich pro Taktzyklus 18 Bit Input habe aber nur 16 Bit Input für den Speicher habe. Da der SRAM asynchron ist, also unabhängig eines Takts arbeitet und 10ns Zeit pro Transfer einer Zeile benötigt, kann ich doch innerhalb eines Zyklus meines Eingangstaktes (8,8 MHz =^ 114ns), also innerhalb eines Prozessdurchlaufes, den Adressbus ändern und somit die zwei fehlenden Bits in die nächste Zeile schreiben oder ????????
Ramon F. schrieb: > Jetz fällt mir aber auf, das ich pro Taktzyklus 18 Bit Input habe aber > nur 16 Bit Input für den Speicher habe. Wie sieht's mit einer Reduktion auf 5:6:5 aus? Würde Dir vielleicht 'ne Menge Kopfweh ersparen...
ok das Thema mit der Reduktion war schon mal ganz gut. Aber kann ich während eines Taktzyklus den Chip einfach so wechseln. D.h. Sequentielle Abarbeitung innerhalb des Prozesses? Eig. steht soweit alles Aber jetz das große Problem: Ich habe nicht bedacht, dass ich natürlich nicht parallel auf dem SRAM lesen und schreiben kann. Mit anderen Worten die Steuersignale WE und OE der beiden SRAMs hängen jeweils an einem FPGA Pin (Was soll denn das ?) Somit kann ich nicht auf dem einen Lesen und dem anderen schreiben. Oder überseh ich hier evtl. was. Ein Denkanstoss wär echt hilfreich. Thx
Tja wenn die Datenbusse der beiden SRAMS zu einem 32Bit Datenbus zusammengefügt sind dann kann man das so machen. Du müßtest also noch zwei extra pins vom FPGA nehmen und von beiden SRAMs die OEs und WE trennen und zu den extra FPGA PINs führen. ABER ich glaube wenn die OEs und WEs zusammen sind dann ist der Adressbus der beiden SRAMS auch parallel geschaltet.
ja das hab ich wohl zu Begin nicht bedacht. Ok das mit dem Speicher kann ich jetz nicht ändern, also muss ich mich selbst verarschen. D.h. ich versuchs erst einmal mit 30 Frames/sec. hinzubekommen, indem ich eines schreibe, dann lese usw. Jetz fällt mir aber noch etwas auf bei dem ich mir nicht so ganz sicher bin. Meine Eingansdaten will/muss ich mit 8,8 MHz auf den SRAM schreiben. Auslesen muss ich aber mit 25Mhz. (Das Timing ist hier nicht das Problem aufGrund unterschiedlicher Ausflösung) Ich brauch also 2 Prozesse (8,8Mhz externer Takt und 25MHz von 50 MHz Systemtakt runtergeteilt). Theoretisch muss ich nun aber abwechselnd (alle 16,6 ms) den Ausgang "Adress (17 downto 0)" mit dem jeweiligen Takt hochzählen. Und genau hier liegt das Problem. Kann ich einen Ausgang mit mehreren Prozessen überhaupt beschreiben bzw. gibts da irgendein Trick.????????????????????????????????????????????????? MfG
Hallo Hallo, da bin ich mal wieder mit einem weiteren kleinen Stolperstein. Die Programmierung ist soweit abgeschlossen. nun will ich das ganze natürlich auch testen. also noch mal kurz refresh: OUTPUT FPGA: - 18 BIT RGB - VSync - HSync - DE Alles soweit auf 640x480 @ 60Hz abgestimmt. Testen will ich das mit meinem Monitor über DVI (TMDS). Nur leider hab ich das dumme Gefühl, das mir niemand einen simplen TTL - DVI Adapter verkaufen möchte. Irgendwie sind diese Dinger nicht aufzutreiben ?????? TTL to LVDS dagegen gibts wie Sand am Meer. Ich habe zum Bsp. einen passenden DVI TX IC von TexIns gefunden (TFP410), der ohne HDCP läuft (brauch ich nicht). http://www.ti.com/lit/ds/symlink/tfp410-ep.pdf Weiterhin brauch ich auch keinen DDC. Kann ich denn einfach so weg lassen? Geb ja ein vordefiniertes stand. Format aus, was der Monitor defenitiv kennt. (Laut Datenblatt funkt das auch so, indem ich I^2C deaktiviere). Entsprechende Layoutplatine gibts auch fürn Euro. Problem is hierbei das Löten des Chips (0,5mm Abstand), no way!! Also zu meinem Gesamtproblem: Wie bekomm ich meine Daten am schnellsten auf meinen Monitor. Kennt jmd. evtl. ein passendes Modul? (Bitte bedenkt das das hier mein Hobby ist, bevor ich mir anhören darf wie unpraktisch das doch ist ohne DDC etc.. Erst wenn das mal läuft gehts weiter :) ) Danke
Ramon F. schrieb: > TTL to LVDS dagegen gibts wie Sand am Meer. Was nun? TTL zu LVDS (das kann jades aktuelle FPGA) oder TTL zu DVI? Ramon F. schrieb: > Kann ich denn einfach so weg > lassen? Ja. Damit kannst Du nur die Kennung und die Eckdaten vom Monitor auslesen. Nett, aber nicht zwingend notwendig. Duke
Ne ne suche einen TTL to DVI Adapter (ohne HDCP, ohne DDC, ganz simple) ums am Monitor zu testen !! der TPF410 von TexIns kann das ja, nur bevor ich jetz 50 - 60 Euro pro Material (Chip + Platine) und Bestückung bezahle gibts da doch bestimmt einfachere und billigere Lösungen oder ?? MfG
Ramon F. schrieb: > der TPF410 von TexIns kann das ja, nur bevor ich jetz 50 - 60 Euro pro > Material (Chip + Platine) und Bestückung bezahle gibts da doch bestimmt > einfachere und billigere Lösungen oder ?? Ich denke viel günstiger wirst Du nicht kommen. Du kannst Dir auch mal den Schaltplan vom Xilinx SP605 anschauen (xtp067.pdf). Dort wird ein Chrontel CH7301C verwendet. Duke
hey vielen dank Duke aber ich würde doch gern auf eine fertige Lsg zurückgreifen und evtl ein paar EUR mehr ausgeben, da ich mich nicht so gut damit auskenne, zumal ich das ganze erst einmal nur simple testen möche, bevor ich das ganze komplett alles hardwaretechnisch umsetzen werde. die Boards die ich gefuunden habe können halt noch 1000 sachen mehr! gibts denn kein kleines TTL to DVI/Tx Extension Board ????????? MfG
Dieses Board (mehr als 2 Lagen zu kaufen bei mouser.com) verwendet den TFP410. Vielleicht kannst du den LVDS entfernen und die Signale direkt einspiesen oder du verwendest einen TTL-LVDS umsetzer oder dein FPGA erzeugt LVDS direkt. http://www.congatec.com/de/produkte/zubehoer/dView/conga-ldvi.html
Angehängte Dateien:
-
LED-Backlight.png
38 KB
Hallo zusammen, Ich habe mich nun auf LVDS festgelegt. Und nun prompt kommt das nächste Problem wobei ich euere Hilfe/Erfahrung gebrauchen könnte. Ich möchte dem DC DC Wandler LT1932 gerne zur Ansteuerung meines LED-Backlights verwenden ! Ich besitze folgendes Display : NEC NL6448BC20-21D , 6,5'' Daten zum Backlight siehe Abbildung!!!! Also laut Angaben brauch ich ja 60mA (10mA pro String). Da dieser nur max. 40mA kann, möchte ich 2 davon verwenden, jeweils mit 30mA (einer jeweils für 3 Strings) so jetz brauch ich ja 26,82V LED Voltage. Ich verstehe nicht so ganz wie ich meine Ausgangsspannung (Pin 1,SW) regeln kann. Den Strom regel ich ja über den Widerstand R_set = 750Ohm (Pin 4) (entspricht dann 30mA) aber wie regel ich nun die Ausgangsspannung? Das Ganze möchte ich mit Hilfe meines FPFGA-Boards realisieren, d.h. ich habe für Vin 3,3 bzw. 5V zur verfügung Könnt Ihr mir da evtl weiterhelfen? MFG
Bei solchen Fragen (habe ich nicht durchgelesen) würde ich im Elektronik-Forum posten und nicht hier bei FPGA. Da sind auf jeden Fall "kompetentere" Leute unterwegs. Grüße Kest
Ramon F. schrieb: > aber wie regel ich nun die > Ausgangsspannung? Na die stellt der Regler soweit er kann passend ein... Du kannst ja nicht Spannung UND Strom gleichzeitig vorgeben...
Hallo zusammen, soweit läuft alles dementsprechend. Nun möchte ich ein bestimmtes Startbild darstellen. Kennt von euch jmd ein passendes Programm (freeware), welches mir ein Bild in einer Art Pixel matrix ausgibt (Farbtiefe wählbar wär ganz nett). Selbst umrechnen würde etwas dauern :) MfG
Schau dir mal Gimp an. Der kann ein paar lustige export Formate wie z. B. C Code & Header Datei. Nützlich für ähnliche Tests und Basteleien mit uCs. Weiss grad nicht auswendig was für dich grad passend wäre, aber ein Blick in die Gimp export Formate ist es sicher wert.
hi Zu der DVI Adapter Geschichte möchte ich nur noch etwas Senf dazugeben: einige Fpgas können auch direkt mit Tmds umgehen also kann man DVI und HDMI ein und Ausgänge ohne externe Signalwandler handhaben, wenn man entsprechend beschaltete und konfigurierte ios verwendet. LVDS ist andererseits die bevorzugte Schnittstelle wen es darum geht größere panels anzb Laptop anzusteuern (siehe auch Display Port)
Hallo zusammen, also ich wende mich ein letzes mal an euch da ich es seit geschlagenen 2 wochen nicht hinbekomme das System einwandfrei zu laufen zu bekommen. Noch mal kurz die zusammenfassung: Ich habe ein Spartan 3 Board von Digilent. Am Eingang habe ich Videoaten im Format WQVGA (480x240) vorliegen. CLK: 8,8Mhz, 18 Bit RGB + DE Ausgabe erfolgt über das VGA_Format (640x480@60Hz) an ein RGB Display. Mein in VHDL erstelltes Timing-Modul funktioniert soweit auch einwandfrei! Da ich die Daten vorerst nicht scalen möchte habe ich diese (480x240)mittig in (640x480) platziert und den äußeren Rand schwarz gelassen. Nun habe ich ein VHDL_Modul geschrieben (siehe Data_Converter.vhd), welches mir die Daten eines Einzelbildes einliest und jeden Pixel in einer SRAM Adresse ablegt. (Datenreduzierung um 2 Bit da die Adresse nur platz für 16 Bit besitzt) Darauffolgend möchte ich das Bild dauerhaft ausgeben bzw. jede sec. einmal aktualisieren. Nun zu meinem problem: Getestet habe ich das ganze indem ich mir eine Art "Picturesimulator" in VHDL geschrieben habe (inkl. DE und Takt), der dauerhaft Daten sendet. Mit diesem Simulator funktioniert mein Data_Converter Modul einwandfrei. Die Datensätze werden genau wie vorgegeben auf dem Display angezeigt. Wenn ich mein FPGA mit den externen Daten (Clk, De, RGB) speise, kommt teils teils nur schwachsinn bei rum. Problem ist, er erkennt die daten, ordent sie aber falsch auf dem Display an. z.B. sind mal die ersten 4 Zeilen und zeile 89-120 richtig, dafür ist der rest total verschoben. etc etc. schwer zu erklären. Ich bin zu dem entschluss gekommen (nach 1000den von tests) das es eig nur an der VHDL programmierung liegen kann. Er erkennt den Bildanfang, den Clk sowie De und auch die RGB Daten sind korrekt, nur halt falsch angeordnet. Teilweise liest/ schreibt er den Speicher erst gar nicht kommplett mit 240x480 = 115200 Adressen voll sondern zeigt wiederholt einige Daten im unteren Bildaufbau wieder an. Habe 2 Versionen im Anhang. Video_converter.vhd ist mein ursprüngliches Modul. In Video_converter2.vhd habe ich versucht mein Lese/Schreibprozess zu vereinigen, was zur Folge hatte das noch weniger zusammenhängende Daten sichtbar waren. Weiss leider echt nicht mehr weiter! ich weiss es ist jetz evtl etwas aufwändiger sich damit zu befassen. Also wenn jmd. von euch zeit und lust hat wäre ich euch sehr dankbar. Ich bin leider endgültig mit meinem Latein am Ende MfG
Hast Du mal einen Screenshot? Irgenwie klingt Deine Fehlerbeschreibung nach einem Synchronisationsproblem. Wieviele Taktdomänen hast Du? Duke
@Ramon F. (tronixx): Ich sage gleich: ich habe keine Lösung für Dein Problem. Dein Code ist nicht "sauber". Zunächst mal die Formatierung -- es ist schwer was zu lesen. Daraus ist die Funktionalität nicht ersichtlich, zumindest mir nicht. Wieso die Grütze rauskommt kann gut daran liegen, dass die Clock-Trennung unsauber ist. Woher weißt Du, dass clk_8_8MHz und clk_50MHz synchron sind? In der clk_8_8MHz-Domäne generierst Du "zustand_Data_in", den Du dann in der clk_50MHz-Domäne abfragst... Mhh... Da läuft Einiges schief und ich würde Dir raten alles "from scratch" zu machen, mit sinnvollen Signal-Bezeichnungen, FIFOs für Daten (zur Domain-trennung) und und und. Klar, es ist ein Schock erstmal, wenn man alles simuliert hat und es funktioniert und dann lädt man alles runter und es "funzt" nicht mehr ;-) Aber so ist es halt... Grüße Kest
Hallo Kest ich weiss ich bin noch sehr am anfang der FPGA Welt. Aber eins musst du mir erklären? > In der clk_8_8MHz-Domäne generierst Du "zustand_Data_in", den Du dann in > der clk_50MHz-Domäne abfragst Wo genau liegt hier das Problem? Was ist an sowas unsauber? MfG
irgendwie muss ich doch eine Beziehung zwischen den beiden Takten herstellen
> Wo genau liegt hier das Problem? Was ist an sowas unsauber?
Kannst du in einem solchen Fall GARANTIEREN, daß die Setup und Hold
timings eingehalten werden ?
> Wo genau liegt hier das Problem? Was ist an sowas unsauber? Da wirds doch schön erklärt, dies gilt auch für den Übergang von Signalen zwischen zwei freilaufenden Takten: (runterscrollen bis "Laufzeitunterschiede im Routing" dann lesen) http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren oder hier: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Als Lösung fällt mir so spontan ein: Entweder ein Synchronisierungs Flipflop verwenden oder die einkommenden Daten in ein asyncrones Fifo schreiben (mit dem Xilinx Core-generator erzeuen)
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.