PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : An die VHDL Spezis: Seltsames Problem


Senior Sanchez
2010-07-01, 15:08:06
Hallo miteinander!

Mit VHDL kenne ich mich mittlerweile schon etwas aus, aber jetzt stehe ich vor einem gewaltigen Problem. Es geht um folgende Praktikumsaufgabe, bei der auch mein Betreuer noch keine Lösung gefunden hat.

Der folgende Codeausschnitt stellt den so genannten Geld-Decoder einer Autowaschanlage dar. Der Nutzer kann über Tastendrücke verschiedene Geldbeträge (50 ct, 1 € und 2 €) einwerfen, die direkt in die entsprechende Waschzeit umgerechnet werden. Maximal kann der Nutzer 9 € einwerfen, bzw. 90 mal 10 ct. (Daher der Check auf 90, da keine einstelligen Cent-Beträge möglich sind und ich deshalb die Beträge durch 10 dividiere )
Versucht er dagegen mehr Geld einzuwerfen, soll das Display flackern, was über die Shake-Leitung signalisiert wird.


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity Geld_decoder is
Port ( CLK : in STD_LOGIC;
Reset : in STD_LOGIC;
Fuenfzig : in STD_LOGIC;
Eins : in STD_LOGIC;
Zwei : in STD_LOGIC;
Einer : out STD_LOGIC_VECTOR (3 downto 0);
Zehner: out STD_LOGIC_VECTOR (3 downto 0);
Hunderter : out STD_LOGIC_VECTOR (3 downto 0);
Shake : out STD_LOGIC);
end Geld_decoder;

architecture Behavioral of Geld_decoder is

begin
geld_decode:process(clk)
variable temp_einer: natural := 0;
variable temp_zehner: natural;
variable temp_hundert: natural;
variable money_sum : natural;
variable shaking : STD_LOGIC;
begin
if clk'event and clk = '1' then
if Reset = '1' then
temp_einer := 0;
temp_zehner := 0;
temp_hundert := 0;
money_sum := 0;
end if;

shaking := '0';

if Fuenfzig = '1' then
if money_sum + 5 > 90 then
shaking := '1';
else
money_sum := money_sum + 5;
-- addiere 30 Sekunden drauf
temp_zehner := temp_zehner + 3;
-- wenn groesser als 1 Minute, dann erhoehe die Minute und berechne den Sekundenrest
if temp_zehner >= 6 then
temp_hundert := temp_hundert + 1;
temp_zehner := temp_zehner - 6;
end if;
end if;
end if;

if Eins = '1' then
if money_sum + 10 > 90 then
shaking := '1';
else
money_sum := money_sum + 10;
-- addiere eine Minute drauf
temp_hundert := temp_hundert + 1;
end if;
end if;

if Zwei = '1' then
if money_sum + 20 > 90 then
shaking := '1';
else
money_sum := money_sum + 20;
-- addiere zwei Minuten drauf
temp_hundert := temp_hundert + 2;
end if;
end if;

shake <= shaking;
einer <= conv_std_logic_vector(temp_einer, 4);
zehner <= conv_std_logic_vector(temp_zehner, 4);
hunderter <= conv_std_logic_vector(temp_hundert, 4);
end if;
end process;

end Behavioral;


Das Problem ist nun, dass beim Systemstart, selbst ohne Tastendrücke (!), ein Flackern ausgelöst wird, also eine logische 1 auf dem Shake-Port liegt. Klapprige Tasten kann man ausschließen, da ich diese entprelle und durch meine Tests schon herausgefunden habe, dass es daran nicht liegt. Genauso wenig sind Hardwareprobleme Schuld. Das Problem tritt auch bei anderen FPGAs derselben Reihe auf. Wenn ich zudem mindestens eine dieser Überprüfungen auf Tastendrücke herausnehme, so tritt das Problem _nicht_ auf!

Ehrlich gesagt, bin ich da mit meinem Latein am Ende. Ich programmiere nicht erst seit gestern, habe den Code zig Mal gesehen und durchdacht, aber so etwas ist mir noch nie passiert. Wo ist da das Problem? Ich vermute mittlerweile, dass die VHDL-Synthese irgendwie schief geht.

Achja, noch zur Umgebung: Wir nutzen Xilinx Spartan 3 FPGAs und programmieren mit dem Xilinx ISE WebPack 10.1 SP 3.

Hat da irgendjemand eine Idee was da falsch ist?

Coda
2010-07-01, 15:50:31
Helfen kann ich dir auch nicht wirklich, aber meine Idee wäre das ganze in einen Simulator zu packen und dann zu schauen ob es auch auftritt. GHDL kommt mir da in den Sinn.

Senior Sanchez
2010-07-01, 15:53:33
Helfen kann ich dir auch nicht wirklich, aber meine Idee wäre das ganze in einen Simulator zu packen und dann zu schauen ob es auch auftritt. GHDL kommt mir da in den Sinn.

Den internen Simulator haben wir probiert, aber dort funktioniert es anscheinend fehlerfrei. Trotzdem danke für den Tipp.

Funky Bob
2010-07-01, 21:10:53
Sicher das die Knöpfe die ihr drückt logisch 1 sind, wenn sie gedrückt sind?
Nicht das sie logisch 1 sind wenn man sie nicht drückt und er somit sofort alles voll macht...

Edit:
Shacked er denn wenn du reset drückst? Spätestens dann dürfte es ja nicht mehr gehen.

Edit2: Was ich gerade sehe:
Du setzt in dem PRozess das Shaking auf 0 und später auf 1.
Es ist aber nicht später! Das passiert in Hardware gleichzeitig, in der Simu gewinnt immer der letztere, obs in Hardware noch so ist kann dir keiner sagen.

Edit3:
Und noch was:
Schau dir mal beim Zusammenbauen für den FPGA an, ob dir die ISE Signale/Variablen wegoptimiert. Passiert oft.
Habt ihr die Pins auch richtig geroutet auf dem Board? Nicht angeschlossene Pins werden mit irgendwas verknüpft...
Und als Tipp:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--Kann sowohl mit signed als auch unsigned rechnen...
USE ieee.numeric_std.ALL;

Das soltle im Kopf stehen, nicht das unsigned etc. Nur die Numeric_std kommt mit signed als auch unsigned klar. Hat noch nen paar mehr Gründe, bei Interesse Google fragen.

Gast
2010-07-01, 21:15:34
Du benutzt Variablen, ohne sie zu initialisieren und setzt nach BEGIN kein
Wert => FFs/Latches werden erzeugt, bloss welcher Startwert???
Ordne den Variablen bei ihrer Definition Startwerte zu.

Besser ist, du verwendest überhaupt keine Variablen, sondern Signale. Das
macht eigentlich niemand, weils gefährlich ist.

Nebenbei: Du führst die Variablen durch Signalzuweisung nach Aussen.
Wie sehen die Werte zu Beginn aus?

Gruss Jörg


P.S. was macht "-- addiere 30 Sekunden drauf" etc. ?

Gast
2010-07-01, 22:28:31
Wie der andere Gast schon schrieb, dein Signals solltest du mit := '0' initialisieren, weil ein std_logic sonst automatisch mit 'U' initialisiert wird.

Variables von denen du sofort eine Reaktion erwartest würde ich dagegen nicht als signals ausführen, so hast du es aber sowieso gemacht.

Achja und wenn man nicht von zwei processes auf ein signal schreiben will/muss sollte man statt std_logic, std_ulogic verwenden. Die beiden sind gleich ausser das std_logic ein resolved type ist, d.h man kann von mehreren processes drauf schreiben und eine sogenannte resolve function schaut dann was wirklich hinten rauskommt.

Senior Sanchez
2010-07-02, 01:15:42
Danke für die vielen Hinweise!

Sicher das die Knöpfe die ihr drückt logisch 1 sind, wenn sie gedrückt sind?
Nicht das sie logisch 1 sind wenn man sie nicht drückt und er somit sofort alles voll macht...

Ja, das ist sicher.


Edit:
Shacked er denn wenn du reset drückst? Spätestens dann dürfte es ja nicht mehr gehen.

Nope, mit dem Reset hat es nichts zu tun.


Edit2: Was ich gerade sehe:
Du setzt in dem PRozess das Shaking auf 0 und später auf 1.
Es ist aber nicht später! Das passiert in Hardware gleichzeitig, in der Simu gewinnt immer der letztere, obs in Hardware noch so ist kann dir keiner sagen.

Naja, es ist ja eine Variable und die bekommt eigentlich schon sofort den Wert zugewiesen.

@Gäste
Auch euch Danke für die Hinweise.

Mit der Initialisierung habt ihr natürlich Recht. Das da oben ist eine etwas alte Version, bei der aktuellen haben wir das aber schon gefixed und es hatte keine Auswirkungen. Beim Xilinx FPGA werden die wohl immer mit 0 initialisiert.

Ich habe schon begonnen, von Variablen auf Signale umzusteigen, da ich es vorhin schon von anderer Seite gehört habe. Ich werde Variablen jetzt nur noch verwenden, wenn ich es als wirklich nötig erachte.

Was ist eigentlich an den Variablen so schlimm? Jemand anderes erklärte es mir, dass der Aufwand zum Verarbeiten von Variablen wesentlich höher sei, wobei die Komplexität doch jetzt nicht so drastisch sein kann, oder?

Das -- addiere 30 Sekunden ist einfach nur ein Quelltextkommentar. :)

Funky Bob
2010-07-02, 08:38:59
Danke für die vielen Hinweise!

Nope, mit dem Reset hat es nichts zu tun.



Naja, da du die Summe auf 0 setzt, muss shacking in Folge dessen auch immer 0 bleiben, solange du reset drückst, ist das nicht der Fall hast du noch ganz andere Probleme...


Naja, es ist ja eine Variable und die bekommt eigentlich schon sofort den Wert zugewiesen.


Wusste ich nicht, danke, nutze Variablen nie.
Aber da deren Handling wesentlich komplexer ist, frage ich mich warum du sie überhaupt benutzt? Das Problem hier bekommt man auch so noch schnell erschlagen...
Da du einen Automaten bauen möchtest, würde ich evtl. auch das Prinzip eines endlichen Automaten umsetzen. => Zustände einführen

Senior Sanchez
2010-07-02, 09:36:28
Naja, da du die Summe auf 0 setzt, muss shacking in Folge dessen auch immer 0 bleiben, solange du reset drückst, ist das nicht der Fall hast du noch ganz andere Probleme...

Also ich drücke reset nicht, dass wollte ich sagen. Ein Reset löst das shaking also nicht aus.


Wusste ich nicht, danke, nutze Variablen nie.
Aber da deren Handling wesentlich komplexer ist, frage ich mich warum du sie überhaupt benutzt? Das Problem hier bekommt man auch so noch schnell erschlagen...
Da du einen Automaten bauen möchtest, würde ich evtl. auch das Prinzip eines endlichen Automaten umsetzen. => Zustände einführen

Hmm, ich denke die Nutzung von Variablen rührt daher, weil ich es von anderen Programmiersprachen so gewohnt bin. Ich weiß, VHDL ist keine Programmiersprache, aber man gewöhnt sich halt so bestimmte Sachen an und macht sie immer wieder.

Das mit dem endlichen Automaten habe ich mir auch schon überlegt. Vielleicht mach ich das noch.

Gast (Jörg)
2010-07-02, 11:07:08
Ich hatte gestern Abend keine Lust mehr, deinen Code vollständig
durchzuspielen (Deshalb auch meine Frage nach "-- 30 Minuten..",
gemeint waren von mir die nachfogenden Zeilen).

Soweit ich es verstanden habe, implementierst Du ein BCD-Zähler
für die Minutenanzeige, deshalb auch "zehner := zehner + 3" etc..
In der Simulation müsste es auch funktionieren. Es bleibt aber das
Hauptproblem, dass die Variablen bei ihrer Definition keine Startwerte
zugeordnet bekommen haben. Ordne ihnen einfach eine "0" zu. Dann
müsste dein Beispiel eigentlich funktionieren.
Falls nicht, was passiert nach einen RESET, sind die Tasten vollständig
entprellt??

Zu Automatenansatz: Du hast als IN-Signale die Münzeinwürfe,
die im aktuellen Schritt sofort verarbeitet werden: Warum also
endliche Automaten, es gibt eigentlich nur einen Zustand.

Zu Variablen: Variablen verursachen keinen höheren Aufwand, sie
haben einfach eine andere Semantik. Das kann sie tückisch machen,
und deshalb werden sie von den meisten VHDL-Entwicklern gemieden.

Gruss Jörg

Gast (Jörg)
2010-07-02, 11:10:02
Edit: Variablen haben bei der Simulation (bei den meisten Tools) den
Nachteil nicht anzeigbar zu sein. Du hast also weniger Kontrolle über
deinen Code.

Senior Sanchez
2010-07-02, 11:25:42
Ich hatte gestern Abend keine Lust mehr, deinen Code vollständig
durchzuspielen (Deshalb auch meine Frage nach "-- 30 Minuten..",
gemeint waren von mir die nachfogenden Zeilen).

Achso, okay.


Soweit ich es verstanden habe, implementierst Du ein BCD-Zähler
für die Minutenanzeige, deshalb auch "zehner := zehner + 3" etc..
In der Simulation müsste es auch funktionieren. Es bleibt aber das
Hauptproblem, dass die Variablen bei ihrer Definition keine Startwerte
zugeordnet bekommen haben. Ordne ihnen einfach eine "0" zu. Dann
müsste dein Beispiel eigentlich funktionieren.

Richtig. Aber selbst wenn ich die Variablen initialisiere tritt das Problem auf.
Wie gesagt, meine Aufgabe funktioniert eigentlich perfekt, sie macht alles was sie soll. Das einzige Problem ist einfach nur, dass am Anfang shake auf 1 gesetzt wird und ich weiß absolut nicht warum. Kann da was bei der Synthese schief laufen?


Falls nicht, was passiert nach einen RESET, sind die Tasten vollständig
entprellt??

Ein Reset wird zu dem Zeitpunkt nicht ausgelöst. Das erfolgt erst später und ich habe diesen Eingang auch schon mal auf Masse gelegt, aber das Problem besteht weiterhin. Reset hat also darauf absolut keinen Einfluss.

Die Tasten sind vollständig entprellt und die Entprellkomponente (die gleichzeitig das asynchrone Signal "einsynchronisiert") funktioniert einwandfrei. Das habe ich an anderer Stelle getestet und es geht wirklich ohne Probleme.


Zu Automatenansatz: Du hast als IN-Signale die Münzeinwürfe,
die im aktuellen Schritt sofort verarbeitet werden: Warum also
endliche Automaten, es gibt eigentlich nur einen Zustand.

Ja, das stimmt. Ich war gedanklich bei einer anderen Komponente in meiner Schaltung wo ein Automat direkt Sinn macht.


Zu Variablen: Variablen verursachen keinen höheren Aufwand, sie
haben einfach eine andere Semantik. Das kann sie tückisch machen,
und deshalb werden sie von den meisten VHDL-Entwicklern gemieden.

Gruss Jörg

Wirklich? Bei mikrocontroller.net (dort habe ich auch nachgefragt) wurde mir gesagt, dass es sehr aufwändig ist für den Synthesizer. Das ist mir irgendwie auch klar, denn obwohl ein Prozess ja sequentiell ausgeführt wird, kann vieles ja parallelisiert werden da Änderungen an den Signalen erst am Ende des Prozesses aktiv werden. Bei Variablen geht das aber nicht, die müssen sofort aktualisiert werden und somit wird das ganze sequentieller.

Den Nachteil mit der Simulation habe ich auch schon gehört und da werde ich mal schauen. Jedenfalls, das Simulationsverhalten war einwandfrei. Da wurde kein Shake beim Start ausgegeben.

Gast (Jörg)
2010-07-02, 12:00:42
Ich habe dein Beispielcode nochmal überflogen und mir ist eigentlich kein
Fehler aufgefallen. Versuchs mal mit einer blöden Idee wie z.B. die
Munzeinwursignale komplett auf GND zu legen. Dann müsste ja SHAKE
auf "0" liegen (d.h. kein Flackern???).
Oder kommentiere einfach mal alle SHAKE-Tests aus und beobachte an
deinem Testboard, ob alle Anzeigen korrekt funktionieren (inkl.
Tasteneingabe), d.h. korrekt hochzählen bzw. die Waschdauer anzeigen.

Wenn's dann noch immer nicht klappt, solltest du vieleicht mal die
übergeordneten Komponenten untersuchen. Wie hast du z.B. die Tasten
entprellt etc.?

Zu Variablen,Aufwand: Mit Variablen lassen sich genau die selben Sachen
implementieren wie mit Signalen, ihre Semantik innerhalb eines Prozesses
ist nur anders. Wenn ein höherer Rechenaufwand vorliegt, dann weil mit
der Variable eine Menge "gemacht" wird. Das ist aber auch bei Signalen so.
In der Simulation kann's ein wenig anders aussehen, bei etwa gleicher
Schaltungkomplexität ist da aber auch kein Unterschied (hängt aber auch
vom Simulator ab!!). Das zugrunde liegende Prinzip heisst Delta-Zyklus.

Gruss Jörg

Gast (Jörg)
2010-07-02, 12:04:47
Edit: Vieleicht noch ein kleiner Hinweis: Die Simulationsergebnisse und
der Ablauf in der Hardware sind idR immer identisch, Probleme gibt's
eigenlich immer bei der Ansteuerung von Aussen, denn deren physikalischen
Einflüssen (wie z.B. Prellen bei Taste9 werden in der Simulation oft nicht
mitangegeben.

Gruss Jörg

Senior Sanchez
2010-07-02, 12:09:59
Ich habe dein Beispielcode nochmal überflogen und mir ist eigentlich kein
Fehler aufgefallen. Versuchs mal mit einer blöden Idee wie z.B. die
Munzeinwursignale komplett auf GND zu legen. Dann müsste ja SHAKE
auf "0" liegen (d.h. kein Flackern???).
Oder kommentiere einfach mal alle SHAKE-Tests aus und beobachte an
deinem Testboard, ob alle Anzeigen korrekt funktionieren (inkl.
Tasteneingabe), d.h. korrekt hochzählen bzw. die Waschdauer anzeigen.

Die Münzeinwurfsignale habe ich mal auf GND gezogen, dann tritt der Fehler nicht auf. An der Entprellung der Tasten liegt es aber auch nicht, denn selbst wenn ich die Taster direkt anbinde (ohne Entprellung) und die NICHT drücke, tritt der Fehler auf.

Deshalb habe ich mal an einer anderen Komponente (da wo dann vom Geld-Decoder die Shake-Leitung hingeht) mal direkt einen Taster angeschlossen. Resultat war, das da nichts flackert. An den Tastern liegt es also auch nicht so wirklich.

Ohne Shake funktioniert das ganze System auch einwandfrei. Mit Shake im Betrieb auch, nur der Startup macht eben Probleme. Ansonsten läuft alles rund und problemlos.


Wenn's dann noch immer nicht klappt, solltest du vieleicht mal die
übergeordneten Komponenten untersuchen. Wie hast du z.B. die Tasten
entprellt etc.?

Also ich habe mir das zig Mal angeschaut und die Entprellung der Tasten ist okay. Mein Praktikumsbetreuer, der sich mit sowas schon wesentlich länger als ich beschäftigt, sitzt seit gestern drüber und hat bisher auch keinen Fehler in meiner Schaltung gefunden. Er kann sich das Verhalten auch nicht erklären.


Zu Variablen,Aufwand: Mit Variablen lassen sich genau die selben Sachen
implementieren wie mit Signalen, ihre Semantik innerhalb eines Prozesses
ist nur anders. Wenn ein höherer Rechenaufwand vorliegt, dann weil mit
der Variable eine Menge "gemacht" wird. Das ist aber auch bei Signalen so.
In der Simulation kann's ein wenig anders aussehen, bei etwa gleicher
Schaltungkomplexität ist da aber auch kein Unterschied (hängt aber auch
vom Simulator ab!!). Das zugrunde liegende Prinzip heisst Delta-Zyklus.

Gruss Jörg

Also machts im Grunde keinen Unterschied, ob man Signale oder Variablen nutzt? Dann verstehe ich aber nicht, was an Variablen jetzt so schlimm sein soll, denn ich finde das Prinzip hinter ihnen eigentlich recht eingängig.

Senior Sanchez
2010-07-02, 17:57:59
Kleines Update. Mein Betreuer hat mir geschrieben.

"Ich habe den Geld_decoder simulieren könne und es kommt tatsächlich nach der Freigabe von GSR ein 1-Impuls bei Shake raus. Ursache ist, daß das Shake-Flipflop mit '1' initialisiert wird. Im Moment ist mir noch rätselhaft, warum. Bug oder ????"

und weitere Nachricht von ihm:

"Ja und es ist noch rätselhafter, weil bei der RTL-Schematic INIT=0 steht und bei der Technologie Schematic INIT=1!?

Liegt wahrscheinlich daran, weil es das Modul Nr. 13 ist... ;-)"

Interessant oder?

Senior Sanchez
2010-07-05, 01:03:50
Mal eine kleine Frage am Rande:

Angenommen ich habe einen STD_LOGIC_VECTOR der Länge 3 und möchte diesen einem Signal des Typs STD_LOGIC_VECTOR der Länge 4 zuweisen. Das most significant bit (bei mir in der Regel immer das erste von links nach rechts gesehen) soll dabei auf 0 gesetzt werden.

Wie mach ich das?

Gast (jörg)
2010-07-05, 10:29:51
Ich nehme mal an, du hast deine Vektoren so definiert:

signal src: std_logic_vector(2 downto 0); -- 3 bits
signal dst: std_logic_vector(3 downto 0); -- 4 bits

(immer "MSB downto LSB", macht jeder so..),

dann erfolgt die Zuweisung so:

dst <= src & '0'; -- &: concatenation operator

ein shift wäre dann z.B.:

src <= src(2 downto 0) & src(3); -- hm,welche richtung???

Gruss Jörg


P.S.1.: dein Variablen-Problem (das eine Tool sagt '1', das andere '0') ist
typisch für die Praxis, alle Herstellertools haben kleinere Macken. Dass
das Problem noch nicht entdeckt wurde, liegt and der seltenen
Verwendung von Variablen.

P.S.2.: Ich habe mir mittlerweile mal den Thread auf mikrocontroller.net
angeschaut. Du hast dein Problem ausreichend gut beschrieben (als
Projekt zum Erlernen von VHDL deutlich zu erkennen) und trotzdem kamen
Tipps wie DCM, CONSTRAINTS und PIPELINING: DCM brauchtst du ganz
bestimmt nicht und CONSTRAINTS (für I/O) brauchst du bei einem
Beispielprojekt auch nicht, Eingabetasten und einfache Anzeige (selbst
VGA) sind nicht so kritisch. Da du einen Spartan3 (inkl. 50MHz Quarz)
verwendest und deine Logik recht einfach gehalten hast, wirst du eigentich
ohne Probleme immer zwischen 50 und 100 MHz landen, also kein Pipelining.
Also daran scheitert dein Projekt sicher nicht. Naja, Profis eben, schiessen
immer mit Spatzen auf Tauben oÄ ...

Senior Sanchez
2010-07-05, 11:41:36
Ich nehme mal an, du hast deine Vektoren so definiert:

signal src: std_logic_vector(2 downto 0); -- 3 bits
signal dst: std_logic_vector(3 downto 0); -- 4 bits

(immer "MSB downto LSB", macht jeder so..),

dann erfolgt die Zuweisung so:

dst <= src & '0'; -- &: concatenation operator

ein shift wäre dann z.B.:

src <= src(2 downto 0) & src(3); -- hm,welche richtung???

Gruss Jörg


Ist das wirklich so?
Setzt du da nicht das LSB auf 0 anstatt das MSB?
Müsste es nicht eher dst <= '0' & src sein? Ich möchte ja das MSB auf 0 gesetzt haben, da ich den vektor (oder eben die dargestellte Zahl) nur in einen größeren Vektor packen möchte und nicht ihren Wert verändern will.


P.S.1.: dein Variablen-Problem (das eine Tool sagt '1', das andere '0') ist
typisch für die Praxis, alle Herstellertools haben kleinere Macken. Dass
das Problem noch nicht entdeckt wurde, liegt and der seltenen
Verwendung von Variablen.


Das kann sehr gut sein, aber es ist erstaunlich, dass das noch nicht aufgedeckt wurde. Vielleicht ist das Problem ja in neueren Versionen von ISE behoben. Es hat sich aber wohl endgültig herauskristalisiert, dass es wirklich ein Bug ist.

Ich habe jedenfalls angefangen alle Komponenten (auch den Geld_decoder) auf Signals umzustellen. Damit scheints weniger Probleme zu geben und zugleich meinen Stil zu verbessern. (Also IEEE.numeric_std.all verwenden, range-Beschränkungen meiner Variablen, nur kombinatorische oder getaktete Prozesse verwenden usw.)
Wirklich testen kann ich das aber erst wieder, wenn ich morgen in der Uni bin.


P.S.2.: Ich habe mir mittlerweile mal den Thread auf mikrocontroller.net
angeschaut. Du hast dein Problem ausreichend gut beschrieben (als
Projekt zum Erlernen von VHDL deutlich zu erkennen) und trotzdem kamen
Tipps wie DCM, CONSTRAINTS und PIPELINING: DCM brauchtst du ganz
bestimmt nicht und CONSTRAINTS (für I/O) brauchst du bei einem
Beispielprojekt auch nicht, Eingabetasten und einfache Anzeige (selbst
VGA) sind nicht so kritisch. Da du einen Spartan3 (inkl. 50MHz Quarz)
verwendest und deine Logik recht einfach gehalten hast, wirst du eigentich
ohne Probleme immer zwischen 50 und 100 MHz landen, also kein Pipelining.
Also daran scheitert dein Projekt sicher nicht. Naja, Profis eben, schiessen
immer mit Spatzen auf Tauben oÄ ...

Ja, mir kams da auch so vor, als dass viel mehr über meinen Stil gemeckert wird, als mit dem eigentlichen Problem weiterzuhelfen.

Den DCM benutze ich schon, da unser FPGA mit 50 MHz taktet, wir ihn aber erst mal auf 10 MHz runtertakten sollten mit einer DCM-Komponente. Insofern war das eh vorgegeben und die angesprochenen Sachen bezüglich locked werden automatisch eingehalten, da ein Flag an der Komponente gesetzt wurde, dass erst wenn die Signale "gelocked" sind, der Takt anfangen soll.

Allerdings haben die Leute mir dort aber auch ein wenig geholfen, einige Sachen einfach sauberer zu machen. Andererseits muss ich aber sagen, dass mir das 3dcenter-Forum, insbesondere du Herr Gast (Jörg) ;), wesentlich mehr geholfen habt, was ich bei dieser speziellen Thematik nicht erwartet hätte. Vielen Dank auf jeden Fall für die Hilfe!

PS: Ich muss sagen, dass auch wenn ich anfangs und manchmal mich jetzt noch mit VHDL schwer tue, machts mir irrsinnig Spaß daran rumzubasteln.

Gast
2010-07-05, 12:05:25
Stupido, muss natürlich "dst <= '0' & src" sein!!

Wenn du gute Einführungen in VHDL (praktische für die Synthese) suchst,
schau mal nach

1. Circuit Design With VHDL (Volnei Pedroni): Autor Arbeitet am MIT, was
man an der Qualität der Beispiele (nicht hohes Niveau sondern einfach
und anschaulich) sofort merkt. Ca. 100 von 400 Seiten reichen schon.

2. RTL Hardware Design Using VHDL (Pong Chu) hat ein Kapitel (ca. 20-30
Seiten, in dem die genauen Zeitabläufe von Registern/Logik beschrieben
werden. Hat mir als Hobby-Programmierer sehr geholfen.

3. VHDL-Synthese (Reichard/Schwarz): Habe ich selbst nicht gelesen,
wird aber oft empfohlen.

Alle 3 Bücher müssten eigentlich in jeder UNI-Bib rumliegen, schau einfach
mal rein, insbesondere Kapitel zu 1-Prozess/2-Prozess Ansatz (da gibt's in
den meissten Foren Religionskriege!!) und zu endlichen Automaten.

Gruss Jörg

Senior Sanchez
2010-07-11, 14:02:33
Vielen Dank, Jörg, für die Empfehlungen.

Ich hab mein Programm jetzt soweit umgeschrieben, dass es keine Variablen mehr benutzt. Der Fehler ist auch nicht mehr aufgetreten und alles funktioniert reibungslos. :)

Gast
2010-07-12, 01:59:43
Hallo,

das Problem ist zwar schon gelöst, aber noch ein kleiner Tipp: VHDL ist eine Sprache mit der man vieles beschreiben kann aber es nicht tun sollte (zumindest, wenns synthetisierbar bleiben soll).

Also für synthetisierbare digitale Sachen: Es gibt nur 2 Dinge: Flip-Flops und Logik. Denke in diesen Strukturen, sonst wird das nichts mit der Hardware ;) Und Variablen sind meistens böse, weil fehlerträchtig _und_ langsam. Die Kollegen vom Mikrocontroller.net mögen ein bischen übers Ziel hinausgeschossen sein, aber im Prinzip haben sie Recht!

Senior Sanchez
2010-07-12, 11:22:04
Hallo,

das Problem ist zwar schon gelöst, aber noch ein kleiner Tipp: VHDL ist eine Sprache mit der man vieles beschreiben kann aber es nicht tun sollte (zumindest, wenns synthetisierbar bleiben soll).

Also für synthetisierbare digitale Sachen: Es gibt nur 2 Dinge: Flip-Flops und Logik. Denke in diesen Strukturen, sonst wird das nichts mit der Hardware ;) Und Variablen sind meistens böse, weil fehlerträchtig _und_ langsam. Die Kollegen vom Mikrocontroller.net mögen ein bischen übers Ziel hinausgeschossen sein, aber im Prinzip haben sie Recht!

Japp und japp.
Ich habe darauf geachtet, dass es synthetisierbar ist und auch die Variablen durch Signale ersetzt.