Guten Tag. Ich soll eine RGB diode mittels FPGA ansteuern. Die Diode selber befindet sich auf einer Platine, auf der mehrere Widerstände sind.Das ganze ist mit einem GPIO Kabel verbunden. Ich habe für jede Farbe 6 Ausgänge... Hab schonmal rumprobiert und geguckt warum es 6 Stück sind... damit kann ich die jeweilige LED so weit dimmen bis sie aus ist. Bin leider recht unerfahren auf diesem Gebiet. Weiß aber, dass ich das ganze mit einem moore Automaten realisieren kann. Ich hab sowas schonmal mit c++ und einem Mikrokontroller realisiert. Nur leider weiß ich jetzt nicht ganz wieviele Eingänge und Ausgänge ich brauche. Kann jemand aus Erfahrung mir sagen was ich alles in der Entity benötige? Mein Ansatz wäre ja, dass ich einen Eingang habe (clock von 50mhz des fpga). Dann jeweils pro Farbe 6 Ausgänge in Form eines Array. Weiter weiß ich bis jetzt noch nicht... hoffe ihr könnt mir einen Denkschupser verpassen.. Vielen Dank schonmal
Thomas K. schrieb: > für jede Farbe 6 Ausgänge Schaltplan? > Mein Ansatz wäre ja, dass ich einen Eingang habe (clock von 50mhz des > fpga). Dann jeweils pro Farbe 6 Ausgänge in Form eines Array. Weiter > weiß ich bis jetzt noch nicht... Das reicht. Jetzt kannst du schon ein freilaufendes Disco-Lauflicht bauen. Und wenn man von aussen eingreifen soll, dann brauchst noch irgendeinen Eingriff. Einen Taster, oder eine RS232 Schnittstelle, oder eine DMX Schnittstelle...
Ich nehme mal an, deine Diode hat je eine Kathode+Anode pro Farbkanal. Einfach rausfinden per Durchklingeln mit 2-3V DC kurz am Pin. FPGA-seitig müsstest du 'nen Taktteiler bauen. Also einen Zähler mit n Bit, der bei deinem Grundtakt alle soundsoviel Mikrosekunden mit dem MSB überläuft (bei Überlauf auf 0 rücksetzen). Damit hast du erstmal ein Timing. Damit 'ne PWM draus wird, müsstest du noch ein Tastverhältnis definieren können. Du schleifst also noch einen Vektor rein mit der Breite deines Zählers, der Werte zwischen 0 und 2^Zählerbreite enthalten kann. Beim Erreichen des Zählerstands togglest du einfach deinen Ausgangspin. Das instanziierst du 3 mal, also einmal pro Kanal und das müsste es sein.
Gibt aber noch andere Ansätze, schau dir mal das Datenblatt der AVRs an, dort werden die Timer sehr gut und ausführlich dokumentiert.
Also einen Schaltplan habe ich nicht vor mir. Ich habe das User Manual zur Hand und habe daraus die Ausgänge rausgelesen sowie den clock. Unser Prof hat uns nahe gelegt uns an diesem Zustandsautomaten zu halten. Den kann ich natürlich so nicht übernehmen. Aber das mit den Zuständen kommt mir natürlich sehr bekannt vor. Den Code der uns empfohlen wurde ist als Datei angehängt. Und nein, das ist eine einzige Diode, die 3 Farben hat...insgesamt sind dort 4 Beinchen angebracht..einmal minus und dann die anderen drei Farben halt. Das soll nicht als PWM Signal realisiert werden.
Hmm, na gut, brauchst also keine PWM, sollst nur Farben togglen. Dein Codebeispiel taugt für die Simulation, ist aber nicht wirklich synthetisierbar (wait-Anweisungen). Anstelle der Wait-Anweisung müsstest du halt z.B. eben so einen Zähler bauen, der jede Sekunde überläuft. Beim Überlauf wechselst läufst du dann deine Statemachine ab. Also: Zähler von 27 Bit Breite bauen und wenn das MSB '1' wird, Statemachine durchlaufen und Zähler wieder zurücksetzen. Kannst also einiges weiterverwenden von deinem Codebeispiel. Nicht vergessen, deine Constraints (UCF) richtig zu setzen, damit du mit den richtigen Pegeln arbeitetest. Das kannst du aber schon rausfinden, bevor du 'nen Zähler implementierst, indem du einfach die jeweiligen Ausgänge auf '1' in deiner Verhaltensbeschreibung legst.
Thomas K. schrieb: > Unser Prof hat uns nahe gelegt uns an diesem Zustandsautomaten zu > halten. Meinen Glückwunsch! Das ist eine Beschreibung aus dem letzten Jahrtausend. Und sowas heute an der Hochschule. Mannmannmann... Sieh dir mal mein Lauflicht an: http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html Mit diesem Tabellenansatz könnte man in kurzer Zeit was brauchbares und zeitgemäßes machen.
:
Bearbeitet durch Moderator
Gut alles klar. Aber wie genau funktioniert dieser Zähler und warum muss der eine Größe von 27 Bit haben? Könnte ich nicht einfach anhand des Clocks bei fallender oder steigender Flanke meine Zustände durchlaufen? Als ich das mit dem Mikrokontroller realisiert habe, habe ich 3 Eingänge und 3 Ausgänge benutzt und für die die Zustände - enum -. Durch mein Delay konnte ich dann immer eine Zeit deklarieren für die Verzögerung. Mir ist schon klar, dass ein FPGA anders arbeitet. Aber ist die Umsezung so anders als beim Mikrocontroller? Ich habe zur Zeit so meine Schwierigkeiten beim Umdenken. Aber danke für die schneller Antworten. =)
Thomas K. schrieb: > Aber ist die Umsezung so anders als beim Mikrocontroller? Ja. Sehr grundlegend sogar. Ein Mikrocontroller wird programmiert. Die in einem FPGA implementierte Hardware wird mit VHDL beschrieben. Thomas K. schrieb: > Könnte ich nicht einfach anhand des Clocks bei fallender oder steigender > Flanke meine Zustände durchlaufen? Wie sähe denn deiner Meinung nach dieses "durchlaufen" mit LUTs und Flipflops aus? Nur diese beiden Komponenten hast du nämlich zur freien Verfügung. Damit muss deine Beschreibung umsetzbar sein. Ließ mal "VHDL Synthese" von Reichardt&Schwarz...
Ja das ist eine gute Frage. Ich hab halt selber bis jetzt nur mit c++ programmiert und die Umstellung fällt mir nicht leicht. Der Code den ich vorhin mit angefügt hatte ist sogar aus dem Buch ;)! Hab das hier vor meiner Nase liegen. Ich danke für die hilfreichen Antworten...mal sehen was sich so machen lässt!
Thomas K. schrieb: > Gut alles klar. > > Aber wie genau funktioniert dieser Zähler und warum muss der eine Größe > von 27 Bit haben? Na überleg doch mal wie viele Zyklen du brauchst, um bei 50Mhz eine Sekunde zu erreichen. Die 27 ist über den Daumen gepeilt der Logarithmus Dualis zur 50e6. Soll heißen, läuft das MSB über, isses knapp ne Sekunde. Setz dich früh damit auseinander, wie du korrekte Timings erhalten kannst und Zähler implementierst. Du musst dafür schon ein einfaches Addierwerk implementieren und taktsynchron sein. Wenn du das hast, hast du die halbe Miete. Auf Lothars Seite findest du sehr gute Anregungen, wie das richtig gemacht wird -> unbedingt anschauen. > Könnte ich nicht einfach anhand des Clocks bei > fallender oder steigender Flanke meine Zustände durchlaufen? Überleg doch mal, was das bewirkt, wenn du in jedem Takt deinen Zustand wechselst. Welche Farbe denkst du denn, kommt dabei raus, wenn du mit der Trägheit des menschlichen Sehsystems auf die Diode guckst?
Naja mit jedem Takt wechsel ich natürlich meinen Zustand und mische entweder eine Farbe rein oder auch raus.
Thomas K. schrieb: > Naja mit jedem Takt wechsel ich natürlich meinen Zustand und > mische > entweder eine Farbe rein oder auch raus. Wenn du einen externen Takt von 1Hz hast, mag das so funktionieren. Nimmst du aber die 50Mhz vom Board, wird das nüscht. Dann musst du die eben runterteilen, bis du eine Frequenz erhältst, die halbwegs sinnvoll erscheint. Nix anderes macht ein Zähler, der bei jeder steigenden Flanke inkrementiert wird - jede Bitstelle wechselt also ihren Zustand mit der jeweils halben Original-Taktfrequenz. Das LSB ist also 50Mhz, das Bit 1 25Mhz, Bit 2 12.5Mhz usw. usf. Möchtest du also keine weiß leuchtende RGB-LED, sondern ein etwas schmalbandigeres Spektrum haben - so lange warten, bis dein Auge die Farbe wahrnehmen kann.
Btw: wenn du in deinem Mikrocontroller 'ne Sleep-Routine (und keinen Interrupt) genommen hast, kann die auch so implementiert sein, dass sie den von dir angegebenen Zeitraum einfach No-Ops ausführt und damit den Befehlszähler vom uC belastet. Vielleicht hilft dir das, ein wenig den Zugang zu finden.
Thomas K. schrieb: > Der Code den ich vorhin mit angefügt hatte ist sogar aus dem Buch ;)! Ja, das wurde offenbar auch schon im letzten Jahrtausend geschrieben... Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete" > Hab das hier vor meiner Nase liegen. Schau rein und versuche nachzuvollziehen, was die Jungs da meinen. Thomas K. schrieb: > Ich habe zur Zeit so meine Schwierigkeiten beim Umdenken. Du darfst nicht in "Microcontroller" denken, und das Gedachte dann hinterher nach "FPGA" übersetzen. Sondern du musst dir mal überlegen, was das D in VHDL bedeutet: Description = Beschreibung. Du musst also etwas mit dieser Sprache "beschreiben". Und etwas "beschreiben" kannst du nur, wenn du ein Bild oder wenigstens eine grobe Skizze davon hast. Zuerst muss also eine Vorstellung da sein, welche Hardware benötigt wird, danach wird diese Ideee mit VHDL "beschrieben". BTW1: kein Mensch beschreibt einen Automaten mit 3 Prozessen. Ich verwende in den allermeisten Fällen sogar nur 1 Prozess: http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html Und dann auch keine Sensitivliste mehr: http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html BTW2: ein "after" in einer VHDL-Beschreibung für die Synthese ist sinnlos und verwirrend BTW3: ich wiederhole an dieser Stelle mal gleich das Postulat für Anfänger: Ein Design hat genau 1 Takt, der immer auf die selbe Flanke reagiert (ein Takt ist alles, was ein _edge() oder 'event beinhaltet).
...und den kombinatorisch runtergeteilten Takt (Zähler) nicht direkt als Taktquelle verwenden, sondern als Clock Enable. Ist zwar implizit in Lothars Aussage schon enthalten: Lothar M. schrieb: > Ein Design hat genau 1 Takt, der immer auf die selbe Flanke reagiert > (ein Takt ist alles, was ein _edge() oder 'event beinhaltet).
Sorry Leute aber ich komm absolut nicht weiter mit dem Zähler. Ich hab ja meinen clock mit 50Mhz laufen und soll nun einen neuen clock erstellen, nachdem meine Zustände pro Sekunde fortlaufen sollen. Ich check einfach nicht wie ich den Zähler einbinden muss. Muss ich einen extra process dafür schreiben, der parallel läuft ? Oder wird der zähler sequentiell ausgeführt, nachdem ein Zustand gesetzt wurde... kann es doch ja eigentlich nicht, weil der Zustand sich nach dem neuen clock richten muss ?!
Thomas K. schrieb: > Sorry Leute aber ich komm absolut nicht weiter mit dem Zähler. Ich > hab > ja meinen clock mit 50Mhz laufen und soll nun einen neuen clock > erstellen, nachdem meine Zustände pro Sekunde fortlaufen sollen. Ich > check einfach nicht wie ich den Zähler einbinden muss. Muss ich einen > extra process dafür schreiben, der parallel läuft ? Oder wird der zähler > sequentiell ausgeführt, nachdem ein Zustand gesetzt wurde... kann es > doch ja eigentlich nicht, weil der Zustand sich nach dem neuen clock > richten muss ?! Dein Zähler soll dir ja erstmal einen runtergeteilten Takt geben. Wie die beiden anderen schon geschrieben haben, reagierst du immer auf den Systemtakt. Egal was kommt. Ist dein Zähler abgelaufen, setzt du ein Flag, dass er abgelaufen ist. Auf ein Systemtaktereignis und dieses 'Enable' hin kann deine Statemachine ihren Zustand wechseln. Fang doch mal an, dir einen Prozess zu schreiben, wo du einen Zähler inkrementierst. Synthetisiere und simuliere das mal und guck auch mal, was für Logikelemente verwendet werden.
Thomas K. schrieb: > Sorry Leute aber ich komm absolut nicht weiter mit dem Zähler. Dann zeig doch mal, wie weit du schon gekommen bist. Hast du den Link mit dem Lauflicht schon mal angesehen? Wenn du das nicht verstehst, dann einfach Joch ein Schritt zurück zur blinkenden LED: http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html Und ein wichtiger Tipp: vergiss mal für ein paar Stunden deine Farb-LED, das ist zur Zeit zu hoch für dich. Fang mit dem Blinklicht an. Mach es selbst (nach). Nur dann kapierst du es irgendwann.
:
Bearbeitet durch Moderator
Hey Lothar. Leider habe ich noch nichts brauchbares hinbekommen. Lese zur Zeit die Lektüre und versuche eure Anregungen umzusetzen und vorallem auch zu verstehen. Vorallem will ich das mit den Zähler verstehen wie das im FPGA umgesetzt wird. Dein Link mit der blinkenden Led ist echt gut. Ich wusste z.B. nicht das alles was mit Zeiten zutun hat, mit Zählern realisiert werden kann. Beim Mikrocontroller hatte ich einfach ein Delay und schwups wars erledigt. Danke für die hilfreichen Tipps ! Super Forum =)
Thomas K. schrieb: > Ich wusste z.B. nicht das alles was mit Zeiten zutun hat, mit Zählern > realisiert werden kann. Sobald die Zeiten im ns-Bereich sind, musst du das "kann" durch ein "muss" ersetzen. > Beim Mikrocontroller hatte ich einfach ein Delay Schon der Programmzähler, der die Befehle abarbeitet ist (wie der Name nahelegt) ein Zähler. Und das delay() ist im uC ja keine Schnur, die ein Gewicht abfädelt und einen Kontakt schließt, sondern eine Unterroutine, in der schon wieder Zählvariablen heruntergezählt werden... Und jetzt kommt der lustigste Trick an der ganzen Sache: wenn dein Prof will, dass da eine FSM beteiligt ist, dann sag ihm, dass jeder Zähler in sich und ganz logisch auch ein Zustandsautomat ist. Und du somit das Problem mit einem Automaten gelöst hast. > Beim Mikrocontroller ... schwups wars erledigt. Es lohnt sich, hinter die Kulissen und ins Datenblatt zu schauen. Das dauert zwar länger als "schwupps", bringt aber ein "Gefühl", ob etwas effizient umgesetzt werden kann... > Dein Link mit der blinkenden Led ist echt gut. Der Blinker ist das erste, was ich auf jeder Hardwareplattform mache (Multivibrator mit Transistoren, Blinklicht mit CMOS-Gattern, Blitzlicht mit einem uC, ...). Denn dann habe ich für eine einfache Aufgabe einen Vergleich, wie aufwändig die mit der jeweiligen Hardware im Vergleich zu anderen umgesetzt werden muss/kann.
:
Bearbeitet durch Moderator
Halli Hallo. Ich habe mal wieder ein kleine Frage und diesmal zu meinem Code. Ich hatte das eigentlich schon soweit fast fertig, aber musste noch einige Änderungen vornehmen, weil ich nicht einen eigenständigen Prozess für den clock geschrieben habe, sondern nach jeder Zustandsberechnung mein delay eingebaut hatte. Wie schon erwähnt würde ich wissen was bei mir nun noch falsch ist. Mir ist noch nicht ganz klar ob die beiden Prozesse parallel zueinander ablaufen, oder ob zuerst der Prozess für den clk sequentiell abläuft und dann erst die Folgezustandsberechnung sequentiell abläuft. Und was gehört dann alles in die Sensitivitätsliste für den Prozess der Folgezustandsberechnung? Mfg W.A.
Du hast einen process geschrieben, der einfach ein Signal hochzählt. Um damit ein "delay" zu realisieren, wird normal ein Signal getoggelt (oder bei einem Zähler der die clock um vielfache von 2 herunterteilt das MSB des counters genommen). Mit diesem Signal wird dann der Startschuss für das Flipflop am anderen process gegeben. Der process läuft parallel zu deinem anderen code ab.
Thomas K. schrieb: > ie schon erwähnt würde ich wissen was bei mir nun noch falsch ist. Du hast für das Signal r eine kombinatorische Schleife gemacht. Die Simulation passt nicht zur Hardware, weil die Sensitivliste falsch ist: r fehlt. http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife Thomas K. schrieb: > Und was gehört dann alles in die Sensitivitätsliste für den Prozess der > Folgezustandsberechnung? Alles, was für den Simulator eine Neuberechnung des Prozesses nötig macht. Nur der Simulator verwendet die Sensitivliste. Thomas K. schrieb: > oder ob zuerst der Prozess für den clk sequentiell abläuft und dann erst > die Folgezustandsberechnung sequentiell abläuft. Prozesse "laufen" nicht ab!! Sie werden nebeneinander in Hardware abgebildet und sind immer "aktiv". Mein schlimmer Verdacht: Deine Vorstellungen von der Hardwarebeschreibung (VHDL ist keine Programmiersprache!) sind noch grundlegend falsch... BTW: VHDL Code bitte als *.vhd Datei anhängen. Dann gibts Syntaxhighlighting gratis.
:
Bearbeitet durch Moderator
guck dir doch mal das hier an und versuch dir danach eine Digitale Schaltung zu zeichnen, die dein Problem löst: https://www.fbi.h-da.de/fileadmin/personal/e.komar/public_html/DGT-Skript-Teil2.PDF
Moin Moin. Ich schon wieder. Also, ich habe nun das Programm soweit fertig und laut meinem Prof. ist es soweit korrekt. Mir fehlt zur Zeit der Richtungsumkehr wenn mein Taster gedrückt wird. Meinen Code habe ich angehängt, habe jedoch nicht den kompletten Code angefügt, sondern einiges gelöscht, da ich sonst ja eine Lösung sozusagen veröffentliche. Meine Frage wäre demnach also wie ich das mit den Taster realisieren kann. Ich habe ja meine 8 Zustände an sich mit dem Zustand INIT, der dafür gedacht ist, dass alle Ausgänge zunächst auf 0 gesetzt werden und anschließend der Folgezustand ermittelt wird... Das läuft auch alles.. Nun habe ich mir gedacht, dass ich mir 8 weitere Zustände erschaffe, die einfach rückwärts laufen... also statt RGB dann RBG verlaufen... Ich hatte zuvor in meinem Prozess für die Zustandsaktualisierung geschrieben, dass auch abgefragt wird ob der Taster 0 oder 1 ist... und dann soll er halt bei einer '1' in den Zustand INIT1 springen und bei '0' in den Zustand INIT...Ist der Ansatz überhaupt richtig den ich habe, oder hat jemand einen Tipp wie ich es leicht realisieren kann? Vielen Dank W.A.
Waldemar A. schrieb: > laut meinem Prof. ist es soweit korrekt. Sehr bedenklich... Dieses "Programm" wäre in der freien Wirtschaft ein Kündigungsgrund! So wird in einem FPGA kein "Systemtakt" erzeugt! Niemals! Und darüber hinaus dieser seltsam doppelt getaktete Zustandsautomat, wo mit dem "Systemtakt" der Folgezustand und mit den CLK der aktuelle Zustand übernommen wird. Das sieht man sonst nirgends... :-o Ich hatte doch mein Lauflicht verlinkt, und dort wird mit Clock-Enable gearbeitet. So funktioniert 'synchrones Design'. Was hast du daran nicht verstanden?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und darüber hinaus dieser seltsam doppelt getaktete Zustandsautomat, wo > mit dem "Systemtakt" der Folgezustand und mit den CLK der aktuelle > Zustand übernommen wird. ja. > So wird in einem FPGA kein "Systemtakt" erzeugt! Niemals! Warum nicht? Liefert die Synthese nicht das Gewünschte?
Lars R. schrieb: > Liefert die Synthese nicht das Gewünschte? Doch, die Synthese liefert ein Flipflop, das mit dem Systemtakt vor sich hintoggelt. Aber dieser Systemtakt wird dann nicht über ein Taktnetz verdrahtet, sondern über normales Routing mit erhöhtem Jitter und umterschiedlichem Delay...
Lothar, nun hab ich es extra bei mir durchlaufen lassen: Synthesis Clock Summary (gekürzt) **************** Start Requested Clock Clock Clock Frequency Type Group ---------------------------------------------------- R2R_FPGA|Sy...100.0 MHz inferred Inferred_clkgroup_1 R2R_FPGA|clk 100.0 MHz inferred Inferred_clkgroup_0 ==================================================== Resource Usage: Type Used Total Percentage [...] Chip Globals 2 16 12.50 [...]
@ Lothar. In deinem Beispiel arbeitest du doch mit einem Reset, der beim betätigen in den ersten Zustand wieder gelangt. Ich weiß nicht was ich damit anfangen soll. Gehe ich nach deinem Schema, so komme ich immer wieder zu dem Problem, dass ich immer wieder nur in die eine Richtung gehen kann. Sprich wenn der Taster nicht gedrückt ist, passiert nicht... halte ich es aber gedrückt, so gehts in die andere Richtung, solange die Taste gedrückt wird.
Hallo.. Ich bin echt am verzweifeln mit diesen Taster. Hab nun erstmal probiert ob ich beim drücken oder nicht drücken in die verschiedenen anfangszustände springen kann.. Das klappt. Der code sieht so aus. process (clk,button) begin if clk = '1' and clk'event then if button = '1' then ZUSTAND <= ZINIT1; else ZUSTAND <=ZINIT; end if; end if; end process; Das Ding ist nun. Ich kriege es nicht hin den Folgezustand zu ermitteln wenn die Taste gedrückt oder nicht gedrückt ist. Kann ich das noch in dem Prozess irgendwie realisieren?
Waldemar A. schrieb: > Sprich wenn der Taster nicht gedrückt ist, passiert nicht... halte ich > es aber gedrückt, so gehts in die andere Richtung, solange die Taste > gedrückt wird. Es läuft also schon vor und zurück? Toll. Dann nimm den Taster, synchronisiere ihn ein, setze eine Flankenerkennung drauf an und toggle pro Flanke (nein, nicht mit rising_edge() oder 'event) ein Flag, das du in deiner Beschreibung statt des Tasters zum vor- und rückwärts laufen nimmst.
Ne, es läuft wenn dann nur in eine Richtung. Das mit der anderen Funktioniert noch nicht. Weshalb ist es wichtig, dass der Taster synchron ist?
Waldemar A. schrieb: > Weshalb ist es wichtig, dass der Taster synchron ist? Weil ganz einfach jedes externe Signal einsynchronisiert werden muss. http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
:
Bearbeitet durch Moderator
Hmmm... process(clk) begin if clk = '1' and clk'event then if (delay<=1500000) then delay<=delay+1; else delay <= 0; SystemTakt <= not SystemTakt; key <= button; << Taktsynchron? end if; end if; end process; Mal ne Frage.Ich habe ja hier mein Prozess und erzeuge ein weiteren Takt der langsamer ist.. Mein button ist mein externes Eingangssignal. Ist es nun synchron zum Takt und kann abgefragt werden?..das ist mir noch nicht ganz klar wie ich das machen soll mit der synchro. Hab die ganze Nacht dran gesessen und es kam nichts sinnvolles raus :/ Den obigen Link habe ich mir natürlich durchgeguckt. Ich denke mein Problem ist einfach nur das ich nicht den richtigen Weg finde um zwischen den Anfangszuständen zu springen und anschließend daraus die Folgezustände ermitteln kann..
Waldemar A. schrieb: > Ich habe ja hier mein Prozess und erzeuge ein weiteren Takt der > langsamer ist.. Ja, genau so mit den "not systemtakt" geht das nicht. Es gibt in einem Anfängerdesign genau 1 Takt. Der Rest wird mit Clock-Enables gemacht. Ich komme mir hier vor wie eine Kuh: ich kaue alles wieder und wieder... Sieh dir MEIN Blinklicht (als hello world) an. Dort wird ein Clock-Enable verwendet. Sieh dir MEIN Lauflicht an. Dort wird ein Clock-Enable verwendet. Versuche die Strukturen zu erkennen, und wie das Ganze umgesetzt wird. Diese Aufgabe ist wirklich simpel, du musst nur mal überlegen, wie du das Lauflicht samt Richtungsumkehr mit Hardwarebausteinen aufbauen würdest. Und das dann mit der Hardwarebeschreibungssprache VHDL beschreiben. Waldemar A. schrieb: > Mein button ist mein externes Eingangssignal. Ist es nun synchron zum > Takt und kann abgefragt werden? Dein button dort ist natürlich nicht synchron. Der key ist allerdings synchron zum Takt clk. Der könnte dann schon verwendet werden. Sicherer ist allerdings, zwei Synchronisierungsflipflops hinter einander zu schalten. Ich habe mir diese FSM angesehen und als unglaublich aufwändig und unnötig kompliziert eingestuft. Warum verwendest du nicht die Tabellenversion des Lauflichts, dazu einen Zähler, dessen Laufrichtung umgeschaltet werden kann?
:
Bearbeitet durch Moderator
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.