Hallo zusammen,
ich habe einen funktionierenden VHDL-Code. Ich wollte ihn ändern und
dabei u. A. zwei Arrays von je 4 Byte einführen. Dazu die
Type-Deklaration
Wenn ich nur diese eine Zeile einfüge (z. B. direkt hinter
architecture), egal ob ich sie variiere oder ein Signal damit deklariere
oder nicht, ich bekomme bei dem ansonsten unveränderten Code für die
Zeile
1
caseInputReg2(1downto0)&InputReg(1downto0)is
(und zwei weitere, ähnliche Zeilen) die Fehlermeldung
1
Error (10327): VHDL error at FP_Setup.vhd(141): can't determine
2
definition of operator ""&"" -- found 2 possible definitions
Ist das normal? Wenn ja, warum? Kann man was dagegen machen? Oder spinnt
der Compiler? (Oder ich?)
ersetzt.
System: Quartus 16
Nebenbei, du empfiehlst, zwei der von mir vorgesehenen Libraries durch
numeric_std zu ersetzen. Könnte das Änderungen im Code (nicht nur hier)
erfordern? Das habe ich nicht so schnell erkannt.
DZDZ
Nachtrag:
Ich habe es mal mit use IEEE.NUMERIC_STD.ALL; versucht.
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.NUMERIC_STD.ALL;
4
--use IEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
entityFP_Setupis
Zuerst hat er mir eine neue Fehlermeldung erzeugt. Danach scheint es
nicht zulässig zu sein, einen std_logic_vector einfach mit + 1 zu
incrementieren, hier:
1
MuxCount<=MuxCount+1;
Aber der alte Fehler wie oben beschrieben ist geblieben.
Der Zahn der Zeit schrieb:> case InputReg2(1 downto 0) & InputReg(1 downto 0) is
Hier ist das Problem, dass der Ergebnistyp der &-Verknüfpung unklar ist,
weil für die Berechnung kein Ziel angegeben wurde und std_logic_vector
ein Subtype von std_ulogic_vector ist.
In der "umgebauten" Lösung ist das Ergebnis klar: ein std_logic_vector,
weil ja Input2Reg10 ein std_logic_vector ist.
Im ursprünglichen Ansatz könnte das Ergebnis auch ein std_ulogic_vector
sein. Es gibt also zwei möglich &-Operatoren. Ergo musst du da passend
casten, dass der Datentyp der dem Case übergeben wird, eindeutig ist.
> Nebenbei, du empfiehlst, zwei der von mir vorgesehenen Libraries durch> numeric_std zu ersetzen. Könnte das Änderungen im Code (nicht nur hier)> erfordern? Das habe ich nicht so schnell erkannt.
Ja. Die herstellerunabhängige numeric_std hat andere (aber
orthogonalere) Konvertierungen und Casts als die Synopsys Packages.
Hallo Lothar,
vielen dank für die Hilfe. Aber ich kriege es noch immer nicht hin.
> Ergo musst du da passend> casten, dass der Datentyp der dem Case übergeben wird, eindeutig ist.
Hm. Casten. Ein neuer Begriff für mich. Bei Lothar Miller steht:
> Cast vs. Konvertierung:> Von std_logic_vector nach signed/unsigned und zurück wird "nur"> gecastet mit singed(), unsigned() und std_logic_vector().
Danach müsste ich mit
zum Ziel kommen, bekomme aber die selbe Fehlermeldung :-(
Zugegeben, bisher hatte ich nur mit den wenigsten Types zu tun und die
Unterschiede zwischen ihnen sind mir nur teilweise bekannt - so wie
vieles andere auch.
Aber immerhin, die nahe liegende Frage, ob das wirklich etwas damit zu
tun haben kann, dass nur eine einzige Zeile mit einer Type-Deklaration
hinzu gekommen ist, beantwortet die neue Fehlermeldung:
1
Error (10647): VHDL type inferencing error at FP_Setup.vhd(161): type
2
of expression is ambiguous - "SLV_CY7_Bytes" or "std_logic_vector" are two
3
possible matches
Ich vermute, dass er jetzt nicht weiß, ob er aus der Concatenation einen
1-dimensionalen Vektor mit 4 Bit oder ein Array mit 2x2 Bit machen soll.
Gibt es unter diesen Umständen noch eine elegantere Lösung als mein
"Workaround"?
Der Zahn der Zeit schrieb:> case std_logic_vector(InputReg2(1 downto 0) & InputReg(1 downto 0)) is
Hier ist es das gleiche Problem wie oben:
Du willst etwas mit std_logic_vector()nach std_logic_vector casten, aber
dazu muss das tool wissen was es ist das gecastet werden soll. Und das
ist
InputReg2(1 downto 0) & InputReg(1 downto 0)
mit
use IEEE.STD_LOGIC_ARITH.ALL;
und
use IEEE.STD_LOGIC_UNSIGNED.ALL;
statt
use IEEE.NUMERIC_STD.ALL;
gibt es also weiterhin das alte problem.
Ja, die IEEE.NUMERIC_STD.ALL erscheint erstmal umständlicher weil man
nicht einfach mit std_logic_vector rechnen kann, aber das ist auch gut
und richtig so. Ein std_logic_vector ist erstmal nur ein Kabelbaum,
viele Drähte. Da ist noch keine Zahlendarstellung festgelegt, also auch
keine Rechenregeln. Ist das eine Vorzeichenbehaftete Zahl?
Erst unsigned/signed/integer sagt aus was das als Zahl ist dieses Bündel
Drähte.
Hat man data als std_logic_vector kann man aber trotzdem 1 addieren:
data <= std_logic_vector(unsigned(data)+1)
Man castet den Kabelbaum nach unsigned (= man betrachtet den Kabelbaum
als Zahl, in dem Fall unsigned), dann ist klar welche Zahl das ist und
man kann addieren, das Ergebnis wird dann wieder als Kabelbaum
betrachtet.
Hallo Gustl
danke erst mal.
Gustl B. schrieb:> Hier ist es das gleiche Problem wie oben:> ...> gibt es also weiterhin das alte problem.
Ich denke, dass ich das oben bereits erkannt und auch beschrieben hatte,
was das eigentliche Problem ist.
Wir kommen von Thema ab, aber dennoch zum Thema signed und unsigned: 1.
ich bin kein Profi, 2. ich habe schon eine ganze Menge VHDL geschrieben
3. das war bestimmt nicht sehr professionell, aber teilweise recht
komplex und 4. ich erwarte hier jetzt keinen für mich individuell
geschriebenen Grundlagenkurs zu VHDL. Also:
signed und usigned (oder natural oder positive) habe ich noch nie
verwendet. standard_logic_vector (SLV) und integer dagegen ständig.
Natürlich weiß ich immer, ob meine SLV gerade vorzeichenbehaftet sind
oder er nicht.
Wenn ich nun also zu (m)einem SLV einen integer (per Definition
vorzeichenbehaftet - korrekt?) addiere, wann wird dabei etwas anders
oder evtl. klarer, wenn ich signed und usigned einführe oder caste?
Beispiel:
1
SLV_Data_1<=x"ff";
2
SLV_Data_2<=SLV_Data_1+1;
ergibt x"00". Perfekt, wenn mein SLV vorzeichenbehaftet ist, und ein
normaler Überlauf, wenn er es nicht ist - aber im Sinne normaler
Verhaltensweise von Zählern. Mit Subtraktion und/oder negativen Integers
würde prinzipiell nichts grundsätzlich anderes entstehen.
Der einzigen Unterschied, den ich erkenne, ist, dass der Überlauf bei
signed und usigned an anderer Stelle geschieht, aber spielt das irgendwo
eine Rolle? Im Gegensatz zu einer ALU im µC wird doch kein Overflow-Flag
generiert?
Halt, doch, bei > < -Vergleichen könnte es hilfreich sein. Da muss ich
bei Vergleichen mit vorzeichenbehafteten SLV natürlich aufpassen. Aber
umständlich ist das auch nicht.
Grüße, DZDZ
Hallo Gustl,
mannomann, das war ja eine wirklich nette Extraleistung. Ich habe dabei
einiges Neues gelernt, das finde ich gut. Mit File-Compare habe ich mir
die Änderungen angesehen und die Hintergründe kapiert.
Damit wird allerdings meine Theorie
> Ich vermute, dass er jetzt nicht weiß, ob er aus der Concatenation einen> 1-dimensionalen Vektor mit 4 Bit oder ein Array mit 2x2 Bit machen soll.
über den Haufen geworfen. Entweder, ich erkenne nicht, warum durch
numeric_std die Concatenation jetzt eindeutig wird oder - ja, was dann?
Ich gehe davon aus, dass bei dir ohne numeric_std die selbe
Fehlermeldung auftritt.
Grüße, DZDZ
Der Zahn der Zeit schrieb:> mannomann, das war ja eine wirklich nette Extraleistung.
Vielen Dank!
Der Zahn der Zeit schrieb:> Mit File-Compare habe ich mir> die Änderungen angesehen und die Hintergründe kapiert.
So soll das sein, man lernt nie aus.
Der Zahn der Zeit schrieb:> Entweder, ich erkenne nicht, warum durch> numeric_std die Concatenation jetzt eindeutig wird oder - ja, was dann?
Hm also
1
caseInputReg2(1downto0)&InputReg(1downto0)is
2
when"0100"|"1011"=>
3
...
ist völlig korrekt. Das war nie der Fehler. Sorry, dass ich das oben
vermutet hatte. Es werden einfach je zwei Bits z. B. 10 und 01 zu 1001
zusammengehängt.
Also der Hintergrund ist wohl wie Lothar geschrieben hatte. Das ist
eigentlich kein Fehler im VHDL, sondern die Bibliotheken die eingebunden
sind scheinen unter Quartus unterschiedliche Definitionen für & zu
haben.
Der Zahn der Zeit schrieb:> Ich gehe davon aus, dass bei dir ohne numeric_std die selbe> Fehlermeldung auftritt.
Das hatte ich mir gar nicht angeguckt ... oho, mal gucken ... O^o krass,
auch hier läuft die Synthese durch. Also bei VIVADO (Xilinx) gab es nie
irgendwelche Probleme mit Deinem Code.
Quartus II (11) meckert auch bei
Lothar M. schrieb:>> Ich gehe davon aus, dass bei dir ohne numeric_std die selbe>> Fehlermeldung auftritt.> Ohne numeric_std lässt sich das Ganze nicht mehr übersetzen, weil es ja> nicht mal mehr einen Typ "unsigned" gibt. Sieh dir einfach mal den> Quellcode des numeric_std Packages an...
Er meinte seinen originalen Code ohne die numeric_std. Und in der Tat,
da läuft die Synthese bei VIVADO problemlos durch, Quartus meckert bei
dem &
Gustl B. schrieb:> Und in der Tat, da läuft die Synthese bei VIVADO problemlos durch,> Quartus meckert bei dem &
Ich verweise nochmal auf den VHDL-2008 Schalter bei den
Synthesizereinstellungen...