Hallo, ich habe ein kleines Problem mit meinem Programm. Ich soll einen
Zähler entwerfen, der zwischen zwei 4-Bit Zahlen (Input) hoch und runter
zählt. Die Zahlen werden anschließend in einer 7 Segment Anzeige
ausgegeben, was auch ganz gut funktioniert. Ich habe nun das Problem,
dass mein Zähler bis zum Minimum runter zählt und anschließend immer +1
und dann wieder Minimum. Also zB. ist das Minimum 3 und der Zähler
startet bei 6, dann bekomme ich diese Zahlenfolge: 6,5,4,3,4,3,4,...
Kann mir jemand sagen warum dies so ist, bzw was ich ändern kann?
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
6
7
Formatierung (mehr Informationen...)
8
:
9
:
10
[vhdl]VHDL-Code[/vhdl]
Mirko schrieb:> Also zB. ist das Minimum 3 und der Zähler startet bei 6, dann bekomme> ich diese Zahlenfolge: 6,5,4,3,4,3,4,...
Wie stellst du das fest? Mit einer Simulation?
Mirko schrieb:
1
ifcount=Athen
2
help<=false;
3
elsifcount=Bthen
4
help<=true;
5
endif;
Das ist ein Latch, das von Kombinatorik angesteuert wird. Das geht
unbedingt schief! Stichwort zur weiteren Recherche: "Glitch"
Du bist da heute schon der Zweite, der sowas asynchrones probiert:
Beitrag "Re: Stoppuhr Normal/Addition/Split, Funktion abhängig von "Taktrate""
Der Merksatz dazu ist: Latches verwenden nur die, die es können und die,
die es nicht können. Erstere bewusst und Zweitere aus Zufall... ;-)
Mach da einen Takt mit rein und aus dem "help" ein Flipflop statt eines
Latches.
Hi, vielen erstmal Dank fürs bearbeiten, das mit dem Dateianhang merk
ich mir fürs nächste mal.
Lothar M. schrieb:> Wie stellst du das fest? Mit einer Simulation?
Ich kann die Zahlenfolge an meinem Demoboard ablesen,bekomme den Code so
wie er ist auch aufgespielt.
Diesen Prozess hier kannst du genauso gut oder besser duch die
entsprechenden Concurrent-Anweisungen ersetzen:
1
-- ClockMode: process (MLEFT, MRIGHT) is
2
-- begin
3
ModeLeft<=MLEFT;
4
ModeRight<=MRIGHT;
5
-- end process ClockMode;
Zum Code selber:
Insgesamt sind die Signalnamen extrem ungünstig und völlig nichtssagend:
was ist denn "A" und "B"? Und was ist "dir"? Sollten die drei nicht
besser /durchgängig/(!!) z.B. minimum, maximum und dirUP heißen? Oder du
definierst einen neuen Typ für "dir", sodass du z.B. so abfragen kannst:
if dir = UP then ...
Und auch die Kommentare sind nutzlos: nicht mal am Kommentar kann man
ablesen, ob jetzt hoch oder runter gezähl werden soll. Man muss den
entsprechenden Code lesen und verstehen, um zu erahnen, was da gewollt
ist.
Du solltest die komplette Takterzeugung aus dem Zählermodul heraushalten
und dort nur den 1 gültigen Takt einspeisen.
Und zum Takt: wird wer immer noch auf diese krude Art&Weise händisch mit
Zählern und toggelnden Flipflops erzeugt? Auf eine Art also, von der ich
schon im Beitrag "Lauflicht mit vorgegbenen Clkgen" schrieb, dass man
das so nicht macht, weil es nicht zuverlässig funktioniert?
Zur Takterzeugung in FPGAs nimmt man deren Taktmanager und arbeitet mit
Clock-Enables.
Generell: wenn man das verbastelte Design mal soweit verbiegt, dass man
den eigentlichen Zähler und seine Umschaltung (was man ja eigentlich
überprüfen will) simuliert, dann sieht man (im Screenshot die untern 5
Signale), dass der "im Prinzip" schon funktioniert, nur nicht ganz
rechtzeitig umschaltet (abwärts wird auf 2 gezählt trotz Untergrenze 3,
und aufwärts bis 7 trotz Obergrenze 6). Der dort beobachtete Effekt
nennt sich "Latency".