Hallo,
ich habe im Rahmen einer Übungsaufgabe das Modell eines Binärzählers
geschrieben, dessen Bitbreite mittels eines Generic-Konstrukts variabel
sein soll.
Als Erweiterung dieser Aufgabe soll beim höchsten Zählzustand ein Bit
gesetzt werden.
Da die Bitbreite den Ausgangsvektor unbekannt ist
1
count_out:outstd_logic_vector(n-1downto0)
hab ich mir geholfen, indem ich ein lokales Signal mit gleicher
Bitbreite wie count_out deklariere, das komplett mit '1' fülle
1
architectureBehavioralofn_bit_counteris
2
signalcount_max:std_logic_vector(n-1downto0);
3
4
begin
5
count_max<=(count_max'range=>'1');
und mit count_out vergleiche.
Wahrscheinlich kann man das eleganter lösen, nur wie?
Und wo wir grad dabei sind, habe ich grad noch eine Frage zu dieser
Zeile
count_max <= (count_max'range => '1');
Ich weiß zwar was sie diese Anweisung bewirkt aber was da genau passiert
ist mir nicht klar.
'range ermittelt die Bitbreite des Vektors, aber was soll dann der "=>"
Operator?
Im Zusammenhang mit Signalzuweisungen in einer Port Map oder innerhalb
von case-Anweisungen ist mir das ja klar, aber hier?
Wäre nett wenn das jemand helfen könnte :)
Zeig doch mal ein wenig mehr vom Quellcode.
Natürlich brauchst du für den Endwert kein eigenes lokales Signal.
Du könntest z.B. eine Konstante verwenden:
constant count_max: std_logic_vector (n-1 downto 0) := (others=>'1');
Aber warum lässt du deinen Binärzahler nicht einfach überlaufen?
>count_max <= (count_max'range => '1');>Ich weiß zwar was sie diese Anweisung bewirkt aber was da genau passiert>ist mir nicht klar.>'range ermittelt die Bitbreite des Vektors, aber was soll dann der "=>">Operator?
Die Syntax hier ist ganz einfach:
signal <= (Bitnummer/Range => Wert1, Bitnummer/Range => Wert2 ...);
Bitnummer/Range kann dabei für ein einzelnes Bit (z.B. 0, 1, 2...)
stehen, dem dann Wert zugewiesen wird, oder gleich für eine ganze Reihe
von Bits (z.B. (2 downto 0)), denen dann jeweils der Wert zugewiesen
wird.
Dein count_max'range wird einfach automatisch durch die richtige Range
ersetzt, in deinem Fall (n-1 downto 0).
>doch, einfach wie oben schon angesprochen ersetzen durch:>> constant count_max : std_logic_vector (n-1 downto 0) := (others=>'1');
Nein, das meinte ich nicht. Es ging mir darum eine Methode zu finden mit
der sich herausfinden läßt, ob der Vektor count_out seinen Maximalwert
angenommen hat. Dies ist hier, zumindest mit meinen bisherigen
Kenntnissen, problematisch, da ich die Größe des Vektor nicht kenne.
Deshalb habe ich mir damit geholfen einen Hilfsvekttor count_max zu
definieren, alle BITS auf 1 zu setzen und mt count_out zu vergleichen.
Mir kommt diese Methode, obwohl sie funktioniert, recht aufwändig vor.
Daher meine Frage: geht das auch einfacher?
> Wahrscheinlich kann man das eleganter lösen, nur wie?
1) Mit std_logic_vector rechnet man nicht. Nimm die numeric_std.
2) Lass den Zähler überlaufen.
Die Aufgabenstellung verlangt
"...dass ein Überlauf bei höchstem Zählzustand angezeigt wird"
wobei das aus meiner Sicht unglücklich formuliert ist. Meines Wissens
erfolgt der Überlauf nicht beim höchsten Zählstand sondern einen Takt
später.
Wenn ich es so mache wie in deinem Beispiel, also den Ausgang auf 0
teste, habe ich aber bereits gleich zu Beginn (vorausgesetzt ich fange
bei null an zu zählen) das Überlaufbit auf 1, und das kann ja auch nicht
gewollt sein, oder?
Ich habs jetzt mal so umgesetzt wie in der Aufgabenstellung gefordert
und setzte das Überlaufbit beim höchsten Zählzustand:
Oh, das ging aber schnell, danke
>enable ist unnötig. Der Prozess ist nur von reset und clk abhängig.
Hast Recht, aber schaden tut's auch nicht, oder?
>Es ist nicht gut, mit Vektoren zu rechnen.
ok, aber warum?
Chris schrieb:
> Nachtrag: du hast die overflow Abfrage aus dem Prozess rausgenommen. Ist> sie da besser aufgehoben?
Durch die Concurrent-Zuweisung entfällt der 1 Takt Latency, der dir
Probleme gemacht hat.
>> Es ist nicht gut, mit Vektoren zu rechnen.> ok, aber warum?
Du mußt immmer mit angeben, welche der Libs (STD_LOGIC_UNSIGNED oder
STD_LOGIC_SIGNED) du verwendet hast. Bei der Verwendung der Datentypen
SIGNED und UNSIGNED gibt es keine Doppeldeutigkeiten. Das hatten wir
schon mal im Beitrag "Re: Problem mit FSM"
EDIT:
>> Hast Recht, aber schaden tut's auch nicht, oder?
JA und NEIN.
Es braucht in der Simulation (und nur für die Simulation ist die
Sensitivliste überhaupt interessant) mehr Rechenzeit, denn der Prozess
wird auch neu berechnet, wenn sich enable ändert. Das wäre aber unnötig.