Hallo Zusammen, ich möchte eine einfache Aufgabe codieren und würde gerne, soweit es möglich ist, einen zweiten Code von jmd. anders dazu nehmen und auch als Überprüfung gerne testen. Die Aufgabe ist nicht schwer. Ich selbst bin noch Anfänger... Siehe das Problem im Dateianhang. Vll hat ja jemd die Muse mir zu helfen und einen fertige Code zu schicken. Vielen Dank und Grüße Martin
Angehängte Dateien:
-
VHDL.PNG
53 KB
Martin schrieb: > Die Aufgabe ist nicht schwer Da wirst Du wohl vorlegen müssen - hier ist keiner scharf drauf, deine Hausaufgaben zu erledigen ;)
Hi es geht um eigenes Kennenlernen, keine Aufgabe der VHDL... und würde es gerne als 2te Meinung haben... Die Entity habe ich selbst aber in der Architecture bekomme ich noch einige Fehlermeldungen...da hänge ich...
Wie lange sind die Eingänge vom Geldprüfer aktiv? Wurden die bereits aufbereitet und eine Entprellung samt Flankenerkennung darauf angewendet, sodass pro Geldstück nur 1 einziger Impuls mit der Dauer 1 einzigen Takzyklus ankommt? Nein? Dann wäre das der erste Schritt... Dann Brain 1.0: was ist der Höchstbetrag, vor ein Kaffee ausgespuckt wird? Welche Überbezahlung ist demnach möglich? Was ist die simpelste Darstellung des höchsten Geldbetrags (Stichwort GGT)? Heraus kommt dann, dass ein Kaffe 3 "Geldeinheiten" kostet und der Einzahlbetrag maximal 6 "Geldeinheiten" und damit der nötige "Geldzähler" 3 Bit breit ist. Mit diesen "kleinen" Integerzahlen lässt sich dann sehr einfach "rechnen". Wenn nach Ausgabe des Kaffees und Abzug der dafür nötigen 3 "Geldeinheiten" noch was übrig ist, dann ist es ein 50 Cent Stück, wenn das LSB Bit 0 gesetzt ist, und 1 Euro, wenn das Bit(1) des "Geldzählers" gesetzt ist. Alles in Allem: nette kleine Aufgabe, bei der man schon lange vor dem Schreiben der ersten VHDL-Codezeile viel falsch machen kann... ;-)
:
Bearbeitet durch Moderator
Hinzu kommt, dass man dasselbe Geldstück ja öfter einwerfen könnte … … es bräuchte also zähler pro Geldstück-Art. Aber wahrscheinlich ist es nur ganz simpel "gemeint". Jede Kombination aus einzelnen Geldstücke (eines pro Art) und die Reaktion der Ausgänge. Nur ein paar Gatter ...
Angehängte Dateien:
-
Kaffeeautomat_V0a.PNG
4,6 KB
Ich habs zwischendurch mal mit einem Summenzähler gemacht... ;-) Aber jetzt muss erst mal jemand die simulierten 6 Kaffee trinken und was von Martin kommen, damit man ihm helfen kann.
:
Bearbeitet durch Moderator
@Lothar, Jeder kann es mit 2 bits per FF lösen !, aber mit normalle FFs... ahem... Beitrag "Hommage an Lothar Miller" :-D
Ich würde einfach die ganze statemachine malen und implementieren. Sind grob im Kopf geschätzt s 5 10 15 k0 25 k10 30 k15 20 k5 also ca. 11 Zustände mit maximal 3 übergangen pro Zustand.
Angehängte Dateien:
-
kaffee_wave_noclk.png
2,5 KB
Lothar optimiert den Reset weg, dann optimier ich noch den Takt weg. Aus Spaß mal eine Variante ohne Takt, glitch free und synthetisierbar. Nicht das es irgentwie sinnvoll wäre, war aber interessant :)
Angehängte Dateien:
-
Kaffeeautomat_V1a.PNG
7,4 KB
FPGA zum Spass schrieb im Beitrag #5878936: > Lothar optimiert den Reset weg, dann optimier ich noch den Takt weg. Dann also mit Latches? Da ist es schon wichtig, dass keine Glitches auftreten können. Lass mal sehen, wie die Zeit für die Ausgabepulse von Kaffee und Rückgeld gemacht ist. Bin gespannt... ;-) Wie sieht es da mit der gegen EMV-Störungen nötige Konditionierung der Eingänge aus (wie z.B. EMV-Spikes im Anhang ab Cursor, wo der 1 Euro-Eingang Störungen abbekommt)? > synthetisierbar Damit ist das Spiel aber noch nicht gewonnen, denn man kann sogar ganz problemlos eine kombinatorische Schleife synthetisieren. Manche machen das, ohne es zu wissen. nfet schrieb: > die ganze statemachine Bestand bei mir aus dem Geldzähler und einem Flag, das anzeigt, ob das Geld schon reicht. Inzwischen hab ich das aber mal überarbeitet, damit es "lehrbuchmäßiger" aussieht. Der Zustandsautomat kennt jetzt 3 Zustände: kassieren, kaffee, rueckgeld. Das ist jetzt leicht wart- und erweiterbar (z.B. wenn noch ein 5€-Geldscheinprüfer mit ins Spiel kommt, oder der Kaffeepreis angepasst werden muss).
Lothar M. schrieb: > FPGA zum Spass schrieb im Beitrag #5878936: >> Lothar optimiert den Reset weg, dann optimier ich noch den Takt weg. > Dann also mit Latches? Da ist es schon wichtig, dass keine Glitches > auftreten können. Lass mal sehen, wie die Zeit für die Ausgabepulse von > Kaffee und Rückgeld gemacht ist. Bin gespannt... ;-) - Ein Schieberegist.. pardon Latch. - Gelöscht werden alle Ausgänge(Kaffee, Rückgeld) ab Schiebe-Füllstand x (Verzögerung x*ps) - Sind alle Bits in der Schiebekette gesetzt, dann wird ein Lösch Latch gesetzt, das erst zurückgenommen wird wenn wieder alle Bits 0 sind. Ok, die Simulation ist an der Stelle mit "after x ps" getrickst, hatte keine Lust auf Post P&R Simulation. Ist aber die einzige Stelle mit künstlicher Verzögerung. Und ja, wenn die Verzögerung zwischen x Schiebstellen kleiner ist als das Löschen der Ausgänge dauert, dann geht es schief. Mut zur Lücke :) Vielleicht gibts ja dafür bessere Lösungen ohne Takt (dazu zähle ich auch kombinatorische Schleifen um sich einen Takt zu erschleichen) > Wie sieht es da mit der gegen EMV-Störungen nötige Konditionierung der > Eingänge aus (wie z.B. EMV-Spikes im Anhang ab Cursor, wo der 1 > Euro-Eingang Störungen abbekommt)? Schlecht. War auch nur just for fun um zu sehen ob es überhaupt geht. Wenn man auf bestimmte Dinge verzichtet bekommt man manchmal erst den Blick dafür was man überhaupt so tut und ist nicht im festen Arbeitsschema gefangen. Dafür taugt dann eine Hausaufgabe ganz gut.
FPGA zum Spass schrieb im Beitrag #5879301: > dann wird ein Lösch Latch gesetzt, das erst zurückgenommen wird wenn > wieder alle Bits 0 sind. Aber das ist m.E. eigentlich nur eine lange Schreibweise für "Obacht, Glitch!" > Ok, die Simulation ist an der Stelle mit "after x ps" getrickst Dachte ich mir, das sieht allzu schön aus. Und so kann man sich auch einen Takt "simulieren"... ;-)
Angehängte Dateien:
-
delay.png
7,8 KB
Lothar M. schrieb: > Aber das ist m.E. eigentlich nur eine lange Schreibweise für "Obacht, > Glitch!" Du hast mich verunsichert, habe es jetzt extra nochmal geprüft. Randbedingung: die Signallaufzeit ist jetzt bei jeder(!) Zuweisung zufällig zwischen 50 und 50000ps. Mehr muss man denke ich nicht abdecken. Hat ein paar Millionen Fälle durchlaufen, alle unproblemtisch. Im Bild ein Beispieldurchlauf, im Anhang der Code für die Schiebestrecke.
Vielleicht verstehe ich etwas falsch, aber m.E. kann man im Modelsim keine Glitches simulieren. Der Simulator arbeitet mit einer gewählten Zeitauflösung. Und falls doch mehrere Ereignisse zum 'gleichen Zeitpunkt' stattfinden, gibt es noch die Delta-Cycles. Was ich damit sagen will: es gibt immer ein genau definiertes Vorher und ein Nachher. In der Realität gibt es aber u.a. 1. Laufzeitunterschiede zu den verschiedenen Signalsenken (Spannungs- und Temperaturabhängig) 2. Glitches, wenn sich z.B. beide Eingänge eines XOR-Gatters (fast) gleichzeitig ändern 3. Setup- und Holdzeiten, die Einzuhalten sind, um Datenintegrität zu gewährleisten Alles Dinge, die in der Simulation nicht berücksichtigt werden. Duke
In der Praxis werden diese Abfragen schiefgehen, weil du den Vergleicher nicht glutenfrei bekommst: if (latchchain > 256) then... Denn hinter diesem Vergleicher bzw. dem 8-fach AND bzw. NOR verstecken sich ja wieder nur zusammengeschaltete LUTs, die per se nicht als glitchfrei angesehen werden dürfen (spätestens dann nicht mehr, wenn sich mehr als 1 Eingang "gleichzeitig" ändert).
:
Bearbeitet durch Moderator
Ok, was wenn ich den Vergleicher mit einzelnen And/Or aufbaue und diese jeweils mit randomisierten Delays verdrahte. Dann sollte ich mich doch drauf verlassen können, nicht?
FPGA zum Spass schrieb im Beitrag #5879960: > Ok, was wenn ich den Vergleicher mit einzelnen And/Or aufbaue Ja, das geht ja wiederum nur in der Theorie, weil sie im realen Leben sprich im FPGA ja wieder zu LUTs zusammengefasst oder mit LUTs realisiert werden. Du müsstest dann also eine Zielarchitektur haben, wo du ein einzelnes AND auch als solche Komponente instantiieren kannst.
Ok, zurück zum Start: Statt: if Latchchain > 256 machen wir if Latchchain(8) = '1' D.h. man muss nur ein Bit prüfen -> unproblemematisch. Abgesehen davon wäre ja selbst ein kurzer Glitch auf der Resultleitung nicht so schlimm, prellt halt die Kaffeeausgabe kurz :)
Angehängte Dateien:
-
Programmierung.jpg
130 KB
Hallo Zusammen ich habe den ersten Teil im Anhang... danach hänge ich aber und versuche es immer wieder neu... Grüße
Angehängte Dateien:
Martin schrieb: > ich habe den ersten Teil im Anhang... Bitte VHDL-Sourcecode als VHDL-Dateie anhängen (oder kurze Schnipsel mit den [vhdl] Tags umrahmen). Und Screenshots als PNG. > ich habe den ersten Teil im Anhang... Warum hast du da integer als Ports? Und warum heißen die Münzprüfereingänge a, b und c, wenn du einfach richtig lesbare Zeichenkombinationen vergeben könntest. > danach hänge ich aber Ganz offenbar "hängt" es da nicht nur am VHDL-Code, sondern weit vorher daran, dass du noch keine Vorstellung hast, WAS du da eigentlich mit VHDL beschreiben willst. Es kamen hier schon einige Vorschläge, wie die Aufgabe gelöst werden könnte. Zeichne deine Gedanken zu deiner Hardware mal als Blockdiagramm mit Steuersignalen auf ein Blatt Papier. Oder denk dir einen Zustandsautomaten aus, der die möglichen Einwurf- und Ausgabekombinationen einzeln durchläuft und beschreibe den. Das wird zwar etwas umfänglich, ist aber ganz einfach lehrbuchmäßig realisierbar, denn es kann nur 4 "Endzustände" geben. > danach hänge ich aber Wenn du selber diese Aufgabe zum Lernen realisieren willst, dann musst du da schon ein wenig mehr ranklotzen. Es bringt nichts, wenn ich einfach meine Lösung(en) hier poste, denn dann hättest du ja nur was zum Angucken, aber selber nichts gelernt... BTW: die Sache mit der blinkenden LED und dem Lauflicht usw. hast du schon selber schon mal inklusive Simulation und Implementierung realisiert? Oder ist dieser Kafee-Automat dein erster VHDL-Kontakt? FPGA zum Spass schrieb im Beitrag #5880119: > if Latchchain > 256 machen wir > if Latchchain(8) = '1' > D.h. man muss nur ein Bit prüfen -> unproblemematisch. Der Gedanke kam mir auch sofort, aber dadurch entschärft sich lediglich die Ermittlung der "Obergrenze". Es bleibt aber noch der zweite "Vergleicher auf 0" für den Clear, der in beiden Fällen über mehrere hintereinander geschaltete LUTs/Multiplexer realisiert ist. Ich würde nicht garantieren, dass das ohne störende Glitches abgeht und nicht zwischendurch mal "zufällig" ein paar der Latches auf zufällige Werte gesetzt werden. Man müsste das Design tatsächlich mal real implementieren und auf Hardware loslassen...
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
Kaffeeautomat_FSM.PNG
6,9 KB
nfet schrieb: > Ich würde einfach die ganze statemachine malen und implementieren. Auch das ist recht einfach. Allerdings muss man hier z.B. die eigentlich unnötige Überzahlung von z.B. 50C-50C-1E oder 50C-2E oder sogar 50C-50C-2E auch berücksichtigen (siehe Screenshot). Trotzdem kommt man übersichtlich mit 7 Zuständen aus, wobei die Ausgabe mit 4 Zuständen "A..." eigentlich unnötig ausufernd beschrieben ist:
1 | type zustaende is (warte, C50, E1, AK, AKC50, AKE1, AKE1C50); |
Das lässt sich dann leicht (allerdings auf Kosten der Leserlichkeit) wieder auf die "unterbezahlten" 3 Zustände verkürzen:
1 | type zustaende is (warte, C50, E1); |
Auch wenn ich mich wiederhole: das ist eine nette Aufgabe und Fingerübung (gerade für die Frühstückspause), wobei und weil trotz der überschaubaren Anzahl von Signalen für ein einfaches Ergebnis schon vor der ersten VHDL-Zeile Gehirnschmalz eingesetzt werden muss... ;-)
:
Bearbeitet durch Moderator
Eine Kaffeeautomatensteuerung im FPGA. Wo bleibt die Münzenentprellung und Erkennung von Falschgeld?
Hier mal ein paar Lösungsansätze und die passende Testbench, nachdem vom Martin offenbar nichts mehr kommt... ;-)
Lothar M. schrieb: > Aber jetzt muss erst mal jemand die simulierten 6 Kaffee trinken Danke Lothar dass du den unerschöpflichen (simulierten) Kaffeenachschub mit uns allen teilst!
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.