Hilfe für Code - VHDL

Martin schrieb:
> Die Aufgabe ist nicht schwer

Da wirst Du wohl vorlegen müssen - hier ist keiner scharf drauf, deine 
Hausaufgaben zu erledigen ;)

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...   ;-)

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 ...

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.

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).

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"...  ;-)

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).

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.

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...

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...  ;-)

Hier mal ein paar Lösungsansätze und die passende Testbench, nachdem vom 
Martin offenbar nichts mehr kommt...   ;-)