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? Hast du vielleicht architecture begin vergessen?
Warum deklarierst Du ein SIGNAL als INOUT? Das macht nur Sinn in einer Entity.
Wenn Du den Vergleich in einem Prozess durchführst, dann nimm ein
1 | if ADR = val01 then |
2 | buf01 <= '1' |
3 | else
|
4 | buf01 <= '0' |
5 | end if; |
Mit ein wenig mehr Code kann ich meine Glaskugel eingepackt lassen. Viele Grüße Fred
>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. VHDL unterscheidet 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...
:
Bearbeitet durch Moderator
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.
Ich habe gerade folgendes Design mit Vivado (Xilinx) synthetisiert, implementiert und ein Bitfile generiert.
1 | library ieee; |
2 | use ieee.std_logic_1164.all; |
3 | |
4 | entity main is |
5 | port ( |
6 | adr : inout std_logic_vector (11 downto 0); |
7 | buf01 : inout std_logic |
8 | ); |
9 | end main; |
10 | |
11 | architecture arch_1 of main is |
12 | constant val01 : std_logic_vector(11 downto 0) := "101010100001"; |
13 | begin |
14 | buf01 <= '1' when (adr=val01) else '0'; |
15 | end arch_1; |
Das ganze funktioniert also ohne Variablen, Prozesse und ifThenElse und fast genau so, wie Du es am Anfang vorgeschlagen hast.
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.
:
Bearbeitet durch User
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...
Zwar OT, aber weil's grad zu den vorhergehenden Beiträgen passt: Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"
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,
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.