SIGNAL buf01 : INOUT std_logic;
SIGNAL ADR : INOUT std_logic_vector(11 downto 0);
CONSTANT val01 : std_logic_vector(11 downto 0) := "101010100001";
ich versuche vergeblich, 2 std_logic_vector ADR und val01 mit = zu
vergleichen und das Ergebnis in buf01 zu geben
buf01 <= ADR = val01;
Quartus 15 meldet nur
Error (10327): VHDL error at meinTest.vhd(76): can't determine
definition of operator ""="" -- found 0 possible definitions
versuche ich das ganze mit
buf01 <= '1' WHEN ADR = val01 ELSE '0';
gibt es nur die Fehlermeldung
Error (10500): VHDL syntax error at meinTest.vhd(76) near text "WHEN";
expecting ";"
Bei allem Googlen habe ich keinen anderen Ansatz gefunden als die beiden
Wege und den Grund für die Fehlermeldung finde ich auch nicht. Was mache
ich falsch ?
Gruß,
dasrotemopped.
dasrotemopped schrieb:> ich versuche vergeblich, 2 std_logic_vector ADR und val01 mit = zu> vergleichen und das Ergebnis in buf01 zu geben>> buf01 <= ADR = val01;
ein vergleich liefert typ boolean du weist aber einen std_logic zu
> versuche ich das ganze mit>> buf01 <= '1' WHEN ADR = val01 ELSE '0';
Das muesste aber richtig sein, vielleicht steckt der fehler darin das
buf01 Richtung inout ist?
>wie schaut den das gesamte file aus?
ohne den Vergleich lässt sich der VHDL Code problemlos compilieren.
>Warum deklarierst Du ein SIGNAL als INOUT?
hab viel ausprobiert und das ist der letzte Stand.
ADR und buf01 müssen nicht nur geschrieben sondern auch gelesen werden.
Die Signale sind alle in der Entity deklariert.
>ein vergleich liefert typ boolean du weist aber einen std_logic zu
dann werde ich mal morgen früh das "if then else" probieren
Gruß,
dasrotemopped.
dasrotemopped schrieb:>>wie schaut den das gesamte file aus?>> ohne den Vergleich lässt sich der VHDL Code problemlos compilieren.
Was nicht bedeutet das der Fehler im Vergleich steckt. Die
Beschreibungsform von Vergleichen ist in VHDL kontextabhängig. Je nach
dem ob der Vergleich sequentiell oder nebenläufig ausgeführt werden soll
ändert sich der Syntax bspw consitional assignment versus IF THEN ENDIF
>>Warum deklarierst Du ein SIGNAL als INOUT?>> hab viel ausprobiert und das ist der letzte Stand.
Mit Verlaub, dieses "rumprobieren" hat dich zu einer abstrusen Syntax
geführt bei der Quartus ausser dem Schwanken der weisen Fahne keine
Optionen hat.
> ADR und buf01 müssen nicht nur geschrieben sondern auch gelesen werden.> Die Signale sind alle in der Entity deklariert.
INout funktioniert synthesetauglich aber auch bei Entities nur unter
ganz genau definierten Randbedingungen.
MfG,
dasrotemopped schrieb:> SIGNAL buf01 : INOUT
Vergiss diesen "Schlamperstil" am besten sofort.
Input wird nur für richtige bidirektionale Ports verwendet. Niemal aber,
um sich ein lokales Signal zu sparen. Das ist m.E. ein berechtigter
Kündigungsgrund.
Ähnlich wie die Verwendung von "Goto" in einem C-Programm.
dasrotemopped schrieb:> ADR und buf01 müssen nicht nur geschrieben sondern auch gelesen werden.
Glaube ich nicht. Welches Bauteil im Inneren eines FPGAs sollte denn
so ein "bidirektionales" Register abbilden können. Zur Erinnerung: HDL
heißt Hardware Beschreibungen Sprache, du darfst also nur etwas
beschreiben, was es in einem FPGA auch tatsächlich gibt. Einen
bidirektionalen Port gibt es seit gut 5 FPGA Generationen aus guten
Gründen nicht mehr.
dasrotemopped schrieb:> Die Signale sind alle in der Entity deklariert.
Und somit vermutlich keine Signale, sondern Ports. In einem Port taucht
allerdings das Keyword "signal" nicht auf. VHDLunterscheidet das sehr
sorgfältig. So wie auch die anderen Datentypen sehr restriktiv
gehandhabt werden. Da wird so eine undurchdachten, hingerotzte
Beschreibung dann einfach mit allen möglichen Fehlern abgewatscht.
> VHDL error at meinTest.vhd(76):
Zeig doch einfach mal genau das VHDL File das diesen "Fehler" zeigt.
Dann lässt sich der Fehler zuordnen und sinnvoll drüber diskutieren...
mit
if ADR = val01 then
buf01 := '1';
else
buf01 := '0';
end if;
hats geklappt.
ADR und buf01 sind jetzt auch Variablen statt Signale.
Läuft noch mal geschmeidiger.
Jetzt geht's ans Testen.
Muss noch viele GAL/Abel Konstrukte nach CPLD/VHDL umsetzen.
Die nächste Frage kommt bestimmt, an die Eigenheiten von VHDL
muss ich mich erst mal gewöhnen.
Gruß und THX für die Hilfe,
dasrotemopped.
Sorry, ich war zu voreilig. Die Bitfile-Generierung meldet am Ende einen
DRC-Fehler, sehe ich gerade, weil die Ports inout sind aber dennoch nur
gelesen bzw. geschieben werden. Hier muss noch etwas Logik drumherum,
die die Richtung festlegt, aber mit dem Vergleich hat das ganze nichts
zu tun.
Vancouver schrieb:> Das ganze funktioniert also ohne Variablen, Prozesse und ifThenElse und> fast genau so, wie Du es am Anfang vorgeschlagen hast.
Es gilt für den TO jetzt zu verinnerlichen:
Innerhalb von Prozessen muss "if - then - else" oder "case" verwendet
werden, ausserhalb von Prozessen "<= when - else".
Abgesehen davon: Die Verirrungen zu INOUT und Variablen wurden ja schon
ausgiebig kommentiert.
dasrotemopped schrieb:> ADR und buf01 sind jetzt auch Variablen statt Signale.> Läuft noch mal geschmeidiger.
Du solltest auf Variablen verzichten. Siehe
Beitrag "Variable vs Signal"
Es gibt wenige Anwendungsfälle, bei denen die Verwendung von Variablen
sinnvoll ist, z.B. Paritätsbildung über einen Vektor mit einer for Loop
o.ä.
So wie Deine Signale bezeichnet sind, gehe ich davon aus, dass auf
keinen Fall als Variablen verwenden solltest. Variablen dienen lediglich
als Zwischenergebnis innerhalb eines Clock Cycles und sollten keine
speichernde Funktion haben.
Viele Grüße
M.
dasrotemopped schrieb:> ich versuche vergeblich, 2 std_logic_vector ADR und val01 mit = zu> vergleichen und das Ergebnis in buf01 zu geben
Genau dieses Thema hatten wir vor geraumer Zeit schon mal. Fazit damals
war: keine std_logic_vector's verwenden, sondern was anderes (was genau,
ist mir grad entfallen). Mich hatte es in diesem Zusammenhang die innere
Unlogik geärgert: überall wird eben dieses "std_logic_vector" gelehrt
und das allererste, was einem danach passiert, ist daß man auf die Nase
fällt, weil Rechnen und Vergleiche so ziemlich das allerhäufigste sind,
was man braucht.
Lothar M. schrieb:> Das ist m.E. ein berechtigter> Kündigungsgrund.>> Ähnlich wie die Verwendung von "Goto" in einem C-Programm.
Ahhh.. schon wieder so ein Fanatiker, der gegen grundlegende
Bestandteile von Programmiesprachen derart wettert. Stattdessen wird
dann while(1) geschrieben, was natürlich furrrrchtbar viel sauberer ist.
Igitt.
W.S.
W.S. schrieb:> Ahhh.. schon wieder so ein Fanatiker, der gegen grundlegende> Bestandteile von Programmiesprachen derart wettert.
ER kennt sich aus.
W.S. schrieb:> Stattdessen wird dann while(1) geschrieben, was natürlich> furrrrchtbar viel sauberer ist.
Genau das. Wer zumindest ein bisschen Ahnung hat, weiß warum.
W.S. schrieb:> Stattdessen wird dann while(1) geschrieben, was natürlich furrrrchtbar> viel sauberer ist.
Die beidem Syntaxelemente sich doch überhaupt nicht vergleichbar...
Aber prinzipiell ist eine while Schleife grundlegend sauberer als eine
mit goto zusammengeschusterte. Denn die while Schleife ist immer einem
Anweisungsblock {} zugeordnet. Ein goto springt wild über Blöcke weg.
Auf jeden Fall braucht ein goto in einem C-Programm eine extrem gute
Ausrede. Anfänger finden die nicht...
W.S. schrieb:> dasrotemopped schrieb:>> ich versuche vergeblich, 2 std_logic_vector ADR und val01 mit = zu>> vergleichen und das Ergebnis in buf01 zu geben>> Genau dieses Thema hatten wir vor geraumer Zeit schon mal. Fazit damals> war: keine std_logic_vector's verwenden, sondern was anderes (was genau,> ist mir grad entfallen). Mich hatte es in diesem Zusammenhang die innere> Unlogik geärgert: überall wird eben dieses "std_logic_vector" gelehrt> und das allererste, was einem danach passiert, ist daß man auf die Nase> fällt, weil Rechnen und Vergleiche so ziemlich das allerhäufigste sind,> was man braucht.
Naja Hardware ist eben abstrahiert, da kann ein Vector aus
signalleitungen ein Bus/Leitungsbündel sein übern den Daten beliebigen
Kontext gehen, bspw. Stiftleiste/Prozessorbus.
Diese "Daten" wird man nicht inkremetieren, addierenen etc. wollen.
Anders bei DSP-Strukturen oder adress-Zähler wo dieser vector ein
Sensorsample/Samplestream/linear addresierte Speicher repräsentiert wo
Berechnung auf und mit diesen Daten sehr wohl sinnvoll sind. Deshalb ist
die kategorische Nichtverwendung von std_logic auch Humbug, genau wie
die sture Verwendung wo ein eingeschränkter integer oder signed oder
unsigned sinnvoller, weil mit "Blick auf die verwendeten
Daten-Operationen getroffen" ist.
Das ist in C nicht anders. Da werden einem auch zuerst die
maschinenunabhängigen WischiWaschi-Typen wie integer oder schlimmer noch
float beigebracht und im täglichen Überlebenskampf wechselt man ziemlich
schnell zu Typen mit bekannter bitbreite die schön übersichtlich in der
lokalen types.h definiert sind: Uint_16, uint_32, double_ieee_754 ...
Dann sieht man auch, wann ein Vergleich von char mit integer immer
ungleich ergibt (ohne implizite Typ-umwandlungen) und deshalb gnadenlos
wegoptimiert wird.
MfG,
