Hallo,
ich habe ein Problem mit meinem VHDL-Code. Der Code ist dazu da, um ein
Sieben-Segment von 0 bis 9 hochzuzählen (Code siehe unten). Der Compiler
meckert ständig bei der Zeile:
var_Seg := var_seg + 1;
Dort kommt die Fehlermeldung: + can not have such operands in this
context.
Ich habe keinen Rat. Variablen sind gleich den Signalen und auch auf
Null gesetzt.
Vielleicht kann einer von Euch mir helfen oder mir nur einen kleinen Rat
geben.
Dankeschön
Kodi
VHDL-CODE:
Kodi schrieb:> Hallo,>> ich habe ein Problem mit meinem VHDL-Code. Der Code ist dazu da, um ein> Sieben-Segment von 0 bis 9 hochzuzählen (Code siehe unten). Der Compiler> meckert ständig bei der Zeile:> var_Seg := var_seg + 1;>> Dort kommt die Fehlermeldung: + can not have such operands in this> context.
Das heist die typen passen nicht.
var_seg ist std_logic_veector und 1 ist integer. deklarier var_temp als
Unsigned und convertiere wo nötig auf std_logic_vector und es passt.
Bsp
http://www.mikrocontroller.net/svnbrowser/pibla/00_hw/src/pibla.vhd?revision=2&view=markup
nx_address (Zeilen 36/170)
MFG,
Hallo,
danke für die Antwort.
Denke habe es jetzt richtig gemacht. Laut Simulation kommt auf jeden
Fall schonmal das richtige Ergebnis heraus.
Deine Antwort hat mich auf dem richtigen Weg gebracht, aber musste echt
noch bisschen überlegen.
Zur Kontrolle nochmal der Kode
... und wenn du jetzt noch eine Erklaerung liefern kannst, warum du die
VARIABLE var_seg und var_cnt eigentlich brauchst und das nicht mit einem
SIGNAL sig_cnt machst, tja, dann kannst du noch ein virtuelles
Ueberraschungsei gewinnen...
Ich benutze in Prozessen immer Variablen. Diese nehmen so unmittelbar
den Zustand ein und nicht erst wenn der Prozess beendet wird. Außerdem
gelten die so nur für diesem Prozess. Mit Signalen verknüpfe ich die
Prozesse und Strukturen miteinander.
Sehe ich etwas falsch oder warum so eine Anmerkung? Das Ei kannst du
gerne behalten.
Kodi schrieb:> Ich benutze in Prozessen immer Variablen. Diese nehmen so unmittelbar> den Zustand ein und nicht erst wenn der Prozess beendet wird.
Ich sehe das eher so: du hast vorher Software gemacht. Und möchtest den
Coding-Style beibehalten. Man kann auch in C mit "Goto" programmieren.
Warum tut man das nicht?
> Außerdem gelten die so nur für diesem Prozess. Mit Signalen verknüpfe> ich die Prozesse und Strukturen miteinander.> Sehe ich etwas falsch
Ja.
> warum so eine Anmerkung?
Lies mal den Thread ganz genau durch:
Beitrag "Variable vs Signal"
Danke, habe es mir durchgelesen. Ist auch sehr Informativ. Verstehe nur
eins nicht, dieser negative "Ton". Muss ich erst meine
Programmiergeschichte zuschreiben? Ihr habt die Erfahrung, die ich nicht
habe und vielleicht auch nie haben werde, aber deshalb schreibt man hier
doch und wenn jemanden was anderes auffällt, dann kann man doch mal Nett
darauf hinweisen.
Naja, unterm Strich sage ich danke, aber werde euch auch nicht weiter
"belästigen".
Kodi schrieb:> Danke, habe es mir durchgelesen. Ist auch sehr Informativ. Verstehe nur> eins nicht, dieser negative "Ton". Muss ich erst meine> Programmiergeschichte zuschreiben? Ihr habt die Erfahrung, die ich nicht> habe und vielleicht auch nie haben werde, aber deshalb schreibt man hier> doch und wenn jemanden was anderes auffällt, dann kann man doch mal Nett> darauf hinweisen.>> Naja, unterm Strich sage ich danke, aber werde euch auch nicht weiter> "belästigen".
Sorry wenn ich dir auf den Schlips getreten bin, aber: Weisst du, was
eine Variable in einem getakteten Prozess eigentlich ist? Wenn ja, dann
gilt immer noch das Angebot mit dem virtuellen Ueberraschungsei, dann
hast du HDL (egal ob VHDL oder Verilog) verstanden.
Falls nein, du bist dann nicht der erste, der hier mit Variablen um sich
schmeisst und eigentlich gar nicht weiss, was das in dem konkreten Fall
bedeutet.
Und es hat nix mit Variablen wie man sie vom Programmieren her kennt zu
tun...
Kodi schrieb:> Naja, unterm Strich sage ich danke,
Wenn wenigstens die Gesamtbilanz positiv war...
> aber werde euch auch nicht weiter "belästigen".
Eine Frage hätte ich noch: stimmt das mit meiner Annahme, dass du bisher
vorrangig Software programmiert hast?
Denn gerade wenn jemand von C herkommt, dann gefällt ihm das "sofortige
Übernehmen" des neuen Wertes (genauso wie derjenige dann Prozesse als
Funktionsersatz sieht).
Mir gefällt aber wesentlich besser, dass Signale ihren Wert erst am Ende
des Prozesses ändern. Das erleichtert das Design von synchronen
Schaltungen/Zustandsautomaten mit dem Ein-Prozess Modell ganz ungemein,
weil die Signal dort ihren Wert auch erst beim nächsten Takt ändern...
Soweit ich es überblicke ist hier die Verwendung von Variable korrekt
und damit nicht zu beanstanden.
Habs extra nochmal in lehrbuch nachgeschlagen (ISBN 0-9651934-3-8) dort
werden auch Zähler auf diese Weise (mit variable) synthetisierbar
beschrieben.
Ferner wird in dem Buch empfohlen, wo möglich variable statt signal zu
verwenden da dies die Geschwindigkeit der Simu verbessert (weniger
simulation overhead). Auch stehen bei dieser Variante Deklaration und
verwendung nah beeinander, man hat also gleich im Blick welchen typ etc.
die Variable hat. Signaldeklarationen dagegen stehen z(|m)eilenweit weg,
da verliert man eher den Überblick. Auch "kapselt" hier eine variable
das in einen process ein was nicht nür den Überblick verbessert sondern
auch verhindert, das an einer anderer Stelle versehentlich das falsche
Signal benutzt wird.
Also wenn es das synthesetool versteht (XST tut es und xilinx gestattet
die Verwendung von variables in process
http://www.cis.upenn.edu/~milom/cse372-Spring06/xilinx/xst.pdf S. 470)
und man kontrolliert sein design auf ungewollte latches (synthese report
lesen) dann sind variables genau richtig.
MfG,
----------------------------------
aber werde euch auch nicht weiter "belästigen".
---------------------------------
Die Hunde beissen hier nicht, sind zwar ein bisschen unwirsch und
kurzatmig.
Mich scheissen die auch ab und zu an....damit kann ich leben als
Pensionär.
Man kann auch davon lernen, das man Fragende nicht so behandelt wie hier
manchmal, sondern immer gelassen bleibt, weil es ein Hobby ist.
Es stärkt den eigenen Charakter weil man dann der Bessere ist.
Gruss
peter schrieb:> Muss er hier auf "0" setzen wenn das Range bis 49999999 läuft?
Ja. Zumindest der Xilinx-Synthesizer baut nicht automatisch einen
begrenzten Zähler, nur weil man den integer-Range begrenzt.
Im Klartext: In der Simulation wird ein Fehler ausgegeben, wenn man aus
dem range rauskommt, aber die Synthese wird im FPGA trotzdem 26 Bit zum
Speichern reservieren.
Duke
Hm..bei meinem QuartusII Version 13 funktioniert es, es fängt dann bei
"0" wieder an. So stelle ich mir auch das Range vor, nicht nur für eine
schnellere Verarbeitung ,sondern auch als Entlatsung.
Gruss
Fpga Kuechle schrieb:> Soweit ich es überblicke ist hier die Verwendung von Variable> korrekt> und damit nicht zu beanstanden.
Im Prinzip ja, aber :-)
> Habs extra nochmal in lehrbuch nachgeschlagen (ISBN 0-9651934-3-8)
Doone Publications 1999
Ist auch nicht mehr das Jüngste. Ich habe schon einige VHDL-Bücher
gelesen (dieses noch nicht) und festgestellt, das Perfekte gibt es
nicht. Leider.
> Ferner wird in dem Buch empfohlen, wo möglich variable statt signal zu> verwenden da dies die Geschwindigkeit der Simu verbessert (weniger> simulation overhead).
Simulationsgewschwindigkeit ist in den allermeisten Design nicht
relevant und sollte für VHDL-Anfänger kein Grund sein, Variablen zu
verwenden. (Wenn das Argument bei heutigen Simulatoren überhaupt noch
stimmt.)
> Auch stehen bei dieser Variante Deklaration und> verwendung nah beeinander, man hat also gleich im Blick welchen typ etc.> die Variable hat. Signaldeklarationen dagegen stehen z(|m)eilenweit weg,> da verliert man eher den Überblick.
Da muß ich Dir leider recht geben. Aber wenn der Editor mehrere Panels/
Fenster öffnen kann, ist es bei heutigen Displaygrößen kein Problem sich
beides auf den Schirm zu zaubern.
Außerdem müßte man mit Deinem Argument bei C/C++ die Variablen auch eine
Zeile über der ersten Verwendung deklarieren.
> und man kontrolliert sein design auf ungewollte latches (synthese report> lesen)
Das fällt gerade bei Xilinx nicht ganz leicht, da dort sehr viele (oft
irrelevante) Warnungen auftauchen.
> dann sind variables genau richtig.
Ich kann Variablen erst empfehlen, wenn der geneigte Anfänger genau
den Unterschied zu Signalen verstanden hat.
Und damit meine ich nicht den Unterschied zwischen <= und :=
:-)
Duke
Duke Scarring schrieb:> Fpga Kuechle schrieb:>> Habs extra nochmal in lehrbuch nachgeschlagen (ISBN 0-9651934-3-8)> Doone Publications 1999> Ist auch nicht mehr das Jüngste.
Erscheinungsjahr ist nun wirklich nicht ein Qualitätskriterium für
Lehrbücher.
>> Auch stehen bei dieser Variante Deklaration und>> verwendung nah beeinander, man hat also gleich im Blick welchen typ etc.>> die Variable hat. Signaldeklarationen dagegen stehen z(|m)eilenweit weg,>> da verliert man eher den Überblick.> Da muß ich Dir leider recht geben. Aber wenn der Editor mehrere Panels/> Fenster öffnen kann, ist es bei heutigen Displaygrößen kein Problem sich> beides auf den Schirm zu zaubern.
Dann muss man den Überblick waren, welche Panels gerade offen sind und
welchen codebereich zeigen. Und irgendwann ist vor lauter Monitoren kein
Platz für die Tastatur mehr ;-). Und bei Code-reviews oder Durchsicht im
stillen Kämmerlein wird gern mit ausgedruckten listings gearbeitet. Oder
das pad/ebok-reader/smartphone hat keine multifenster-Editor oder ist
umständlich damit zu bedienen
> Außerdem müßte man mit Deinem Argument bei C/C++ die Variablen auch eine> Zeile über der ersten Verwendung deklarieren.
Hm in C bin ich nicht wirklich zu hause, aber man kann doch in C
tatsächlich variablen deklarieren wo man sie gerade braucht, hauptsache
vor einem Block .
http://stackoverflow.com/questions/1287863/c-for-loop-int-initial-declaration
1
main()
2
{
3
for(inti=0;i<=300;i+=20)
4
{
5
printf("F=%d C=%d\n",i,(i-32)/9);
6
}
7
}
man werfe einfache ein {} paar in den code und kann dort die variablen
deklarieren die man braucht.
Ich seh es so wo man die Möglichkeit der übersichtlichen Form
(Deklaration und Verwendung nah beieinander) hat sollte man diese und
nicht den workaround (multi-fenster editor) nutzen. Das ist auch besser
für Dritte
die nicht mit dem Editor arbeiten wollen/können den sich der
Code-ersteller gerade wünscht.
MfG
dann waere ich ja auch froh. 'Lokale' Typdeklarationen waeren toll, das
gibt es aber in VHDL nicht. Variablen sind dagegen etwas ganz anderes!
Je nach Kontext koennen das 'Signale die in ein FF muenden' sein oder
auch 'fliegende Logiksignale'. Und das stoert mich an Variablen. Und bei
entsprechender Verwendung macht es den Code in einem sequentiellen
Prozess schlicht und einfach unlesbar und nahezu unwartbar!
------------------------------------
.....dann kann man doch mal Nett darauf hinweisen....
------------------------------------
Da kannst du hier lange warten.
Sind einige Bauernlümmel hier runter...schlechte Ehe...von der Frau
ausgeschlossen(kein Geschlechtsverkehr)... Alkohol...... usw. das formt
einen Menschen und macht ihn schlecht.
Ich habe noch nie so viele missmutige im Leben stehende Menschen erlebt
wie in diesem speziellen FPGA_Forum.
Gruss
peter schrieb:> ------------------------------------> .....dann kann man doch mal Nett darauf hinweisen....> ------------------------------------>> Da kannst du hier lange warten.> Sind einige Bauernlümmel hier runter...schlechte Ehe...von der Frau> ausgeschlossen(kein Geschlechtsverkehr)... Alkohol...... usw. das formt> einen Menschen und macht ihn schlecht.>> Ich habe noch nie so viele missmutige im Leben stehende Menschen erlebt> wie in diesem speziellen FPGA_Forum.>> Gruss
Komisch, dass du hier in den letzten paar Wochen aber gefueht eine
Million Threads aufgemacht hast...
Und, komischerweise, du auf keine Antwort jemals mit etwas
'substantiellem' geantwortet hast und trotzdem die 'Bauernluemmel' dir
immer noch irgendwie helfen wollen...
berndl schrieb:> peter schrieb:>> Da kannst du hier lange warten.>> Sind einige Bauernlümmel hier runter...schlechte Ehe...von der Frau>> ausgeschlossen(kein Geschlechtsverkehr)... Alkohol...... usw. das formt>> einen Menschen und macht ihn schlecht.>>>> Ich habe noch nie so viele missmutige im Leben stehende Menschen erlebt>> wie in diesem speziellen FPGA_Forum.> Komisch, dass du hier in den letzten paar Wochen aber gefueht eine> Million Threads aufgemacht hast...>> Und, komischerweise, du auf keine Antwort jemals mit etwas> 'substantiellem' geantwortet hast und trotzdem die 'Bauernluemmel' dir> immer noch irgendwie helfen wollen...
Achtung Verwechslungsgefahr: viele Anfragen gestellt hat ein
angemeldeter Peter, von Bauernlümmel schwadroniert hier ein "Peter
(Gast)".
MfG
berndl schrieb:> Variablen sind dagegen etwas ganz anderes!> Je nach Kontext koennen das 'Signale die in ein FF muenden' sein oder> auch 'fliegende Logiksignale'.> Und das stoert mich an Variablen.
Man weiß jetzt nicht genaus was für dich 'fliegende Logiksignale' sind,
aber signals werden ebenfalls je nach context (bspw. senseliste
process) in FF münden, zu latches oder kombinatorischen Ausgängen.
Die Vermeidung von variables erspart Dir das Wissen um den richtigen
Gebrauch derselben. Es führt aber nicht zwangsläufig zu fehlerfreien und
effizienten VHDL-Code.
> Und bei> entsprechender Verwendung macht es den Code in einem sequentiellen> Prozess schlicht und einfach unlesbar und nahezu unwartbar!
Nee unlesbar oder unwartbar ist was anderes als nicht synthetisierbarer
Code oder ungewollte Latches.
> also koennte ich sowas schreiben:>
1
>process(clk)
2
>signalhugo,sepp:std_logic;
3
>begin
4
>...
5
>endprocess;
6
>
> dann waere ich ja auch froh. 'Lokale' Typdeklarationen waeren toll, das> gibt es aber in VHDL nicht.
Pack um den process einen block dann kannst du quasi lokale Signale
deklarieren
Fpga Kuechle schrieb:> Achtung Verwechslungsgefahr: viele Anfragen gestellt hat ein> angemeldeter Peter, von Bauernlümmel schwadroniert hier ein "Peter> (Gast)".
Aus dem Nähkästchen: es ist (leider oder zum Glück) der selbe Peter.
Und er bessert sich. Nur das Zitieren von Beiträgen klappt noch nicht so
richtig...
Fpga Kuechle schrieb:> Erscheinungsjahr ist nun wirklich nicht ein Qualitätskriterium für> Lehrbücher.
Leider doch. Die älteren Werke beziehen sich oft nur auf den
simulationsfähigen Teil von VHDL.
Wenn doch explizit der synhtetisierbare Teil erwähnt wird, dann
bestenfalls das, was die Tools zu diesem Zeitpunkt konnten. Und das ist
leider nicht so berauschend viel gewesen. Oft wird dann noch nichtmal
ein rising_edge verwendet. Oder es erfolgt der großflächige Einsatz der
ollen std_logic_arith zum Rechnen :-(
Gefühlt 1/4 der Beiträge hier im Forum, wären nicht nötig, wenn es
gescheite VHDL Bücher gäbe.
Duke
> dann waere ich ja auch froh.
Ja, ich fände es auch schön, wenn ich das gleich so schreiben könnte.
Das mit dem Block geht natürlich, aber ich fände es übersichtlicher und
kompakter wenn ich es direkt im Prozess definieren könnte.
Duke Scarring schrieb:> Fpga Kuechle schrieb:>> Erscheinungsjahr ist nun wirklich nicht ein Qualitätskriterium für>> Lehrbücher.> Leider doch.
?? Das meinst Du wirklich ernst? Dieses "Ich kenn dieses Lehruch zwar
nicht, aber ich ziehe es anhand seines Erscheinungsjahr in Zweifel"?
Meinst Du nicht man sollte wenigstens einen Blick hinein werfen bevor
man versucht seine inhaltlichen Stärken und Schwächen abzuschätzen? Hier
mal 'ne Beispielseite:
http://www.mikrocontroller.net/attachment/199654/20131109_HDL_Design_Muxk.jpg
MfG,
Fpga Kuechle schrieb:> Meinst Du nicht man sollte wenigstens einen Blick hinein werfen bevor> man versucht seine inhaltlichen Stärken und Schwächen abzuschätzen?
Ok. Kritik angenommen.
Ersteinmal die positiven Aspekte:
+ dieses Buch verwendet durchgängig ieee.numeric_std
+ enthält viele (relativ) praktische Beispiele, die gleich zum
Ausprobieren locken
+ ist für Umsteiger geeignet, weil Verilog und VHDL parallel behandelt
werden
+ hat eine gute Erklärung warum man rising_edge verwenden sollte (S.
172)
+ enthält einen schönen Überblick, über Generatoren für Testsignal (Kap.
11)
Jetzt die Punkte, die mir negativ aufgefallen sind:
- Behauptung, daß eine Variable nicht zu einem FF synthetisiert werden
kann (S. 229 im Beispiel)
- Empfehlung zur Mischung von kominatorischer und sequentieller Logik in
einem Prozess (S. 78 und S. 274)
- Verwendung von internen Tristate-Bussen (Kap. 10, Kap. 12 Beispiel 1)
- Multiplikation und Division werden nicht zur Synthese empfohlen (S.
63)
- Empfehlung Signale durch Variablen zu ersetzten um schneller zu
simulieren (S. 78)
- umfangreiche Erklärung zu Latches (S. 164), teilweise mit mehrphasigen
Enable-Signalen trotz Hinweis, das eine Timing-Analyse nicht möglich ist
- Einsatz von asynchronen Zählern (Beispiele 7.14 und 7.15)
- Verwendung von Taktteiler, statt clk_enable (Beispiel 7.13)
- numeric_std wird of eingebunden, obwohl die Funktionalität gar nicht
gebraucht wird (Kap. 3)
- nicht zeitgemäßer Hinweis, das 'initial' nicht synthetisiert werden
kann (Bild 3.4 und Anhang B)
Und noch drei 'optische' Mängel:
- genrell sind alle if-Ausdrücke geklammert, obwohl das bei VHDLnicht
nötig ist
- im FSM-Kapitel (Kap. 8) wird viel zu oft ein else-Zweig verwendet,
obwohl man auch schön vor dem case einen Default zuweisen kann
- gelegentlich werden Namen für States verwendet, die nicht in ein
Lehrbuch gehören: ST1, ST2, ST3, ST4, ST5, ...
Insgesamt gesehen ist das Buch nicht schlecht, aber auch nicht wirklich
gut.
Viele Dinge sind unzeitgemäß (initial-Zuweisung, Multiplikation), bzw.
haben nur noch informativen Charakten (Kapitel 9, Interna zu Addierern
und Multiplizierern).
Positiv ist wirklich hervorzuheben, daß hier durchgängig
ieee.numeric_std verwendet wird. Auch der Einsatz von rising_edge
gefällt mir. Der Autor verwendet auch gelegentlich das 'wait until
...'-Konstrukt, auch wenn ich seine Begrüdung zu dessen Nachteilen nicht
teilen kann. Das Buch könnte eine Überarbeitung gebrauchen (ich beziehe
mich auf die Ausgabe von 1997) und bei einigen Dingen, die zwar zu
synthetisieren gehen, aber definitiv nichts für Einsteiger sind, die
Fallstricke deutlich herausstellen (u.a. Variablen als FF, Latches,
asynchrone Zähler, FSM mit kombinatorischen Pfaden, interne Tri-States).
Duke