mikrocontroller.net

Forum: FPGA, VHDL & Co. Hilfe für Code - VHDL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Markus F. (mfro)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Martin schrieb:
> Die Aufgabe ist nicht schwer

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

Autor: Martin (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Duke Scarring (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dann zeig doch erstmal Deine Entity.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Thomas W. (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ale (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Lothar,

Jeder kann es mit 2 bits per FF lösen !, aber mit normalle FFs...

ahem... Beitrag "Hommage an Lothar Miller" :-D

Autor: nfet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stelle heute Abend meine ENTITY rein... Danke für das Feedback bisher...

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"...  ;-)

Autor: FPGA zum Spass (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen ich habe den ersten Teil im Anhang... danach hänge ich 
aber und versuche es immer wieder neu...

Grüße

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
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:
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
Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Kaffeeautomatensteuerung im FPGA. Wo bleibt die Münzenentprellung 
und Erkennung von Falschgeld?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Christophz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.