Bedingte Zuweisung in Port Map

[Dussel (Gast)]

Moin,
zum Üben habe ich mit VHDL mal einen Ripple-Carry_Addierer aus einzelnen 
Volladdierern aufgebaut.
In der Datei Mehrfachaddierer habe ich über eine for-generate-Schleife 
mehrere Volladdierer hintereinandergeschaltet.

L: for i in 0 to Breite-1 generate
    A: Addierer port map(AV(i),BV(i),CV(i),ErgebnisV(i),CV(i+1));
end generate;

AV und BV sind die Summandenvektoren und CV ein Signalvektor, um das 
jeweilige Carry weiterzureichen. Allerdings muss auf diese Art der 
Carryvektor ein Element mehr haben, als Addierer eingebaut werden, als 
Eingang für den ersten und als Ausgang des letzten. Eigentlich braucht 
Addierer 0 kein Carryeingangssignal, sondern nur den Wert 0. Kann man 
das irgendwie einfach in der Port Map hinkriegen.
Probiert habe ich sowas wie

A: Addierer port map(AV(i),BV(i),'0' when i=0 else CV(i),ErgebnisV(i),CV(i+1));

in verschiedenen Varianten. Das scheint nicht zu funktionieren. Beim 
when wird immer ein Fehler angezeigt.

[Natürlich geht es über loop 1 to Breite-1 und seperater Behandlung für 
den ersten Addierer. Die Frage ist aber, ob es eleganter geht.]

[Dussel (Gast)]

Fünf mal dran gedacht und doch die Anhänge vergessen. :-(

[St. D. (st_d)]

Dussel schrieb:
> [Natürlich geht es über loop 1 to Breite-1 und seperater Behandlung für
> den ersten Addierer. Die Frage ist aber, ob es eleganter geht.]

So oder mit Zwischensignal, eleganter geht's nicht.

[Dussel (Gast)]

Schade. Das ist zwar kein Problem, aber lieber wäre es mir doch anders.

[Fpgakuechle K. (Gast)]

>

A: Addierer port map(AV(i),BV(i),'0' when i=0 else 
> CV(i),ErgebnisV(i),CV(i+1));

verständlichere Signalnamen als AV, BV und CV sind sinnvoller als jede 
elegant anmutende Syntaxverrenkung.

SCNR,

[Dussel (Gast)]

Ich werde mich bessern.

A: Addierer port map(Vektor_der_den_ersten_Summand_als_Binaerzahl_enthaelt(Schleifenlaufvariable),Vektor_der_den_zweiten_Summand_als_Binaerzahl_enthaelt(Schleifenlaufvariable),'0' when Schleifenlaufvariable=0 else Vektor_fuer_die_Carryzwischenergebnisse(Schleifenlaufvariable),Vektor_der_das_Ergebnis_der_Addition_als_Binaerzahl_enthaelt(Schleifenlaufvariable),Vektor_fuer_die_Carryzwischenergebnisse(Schleifenlaufvariable+1));

;-)

Wie gesagt, es ist nur zur Übung. Das soll so nicht weiter verwendet 
werden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dussel schrieb:
> Mehrfachaddierer.txt
> Addierer.txt
> Ich werde mich bessern.
Gut. Dann nenne deine VHDL-Dateien auch *.vhdl...

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Dussel schrieb:
> A: Addierer port map(AV(i),BV(i),'0' when i=0 else
> CV(i),ErgebnisV(i),CV(i+1));

Da CV(0) nie ein Wert durch einen Addierer zugewiesen wird, kannst du es 
selber machen. Schreib irgendwo in der Architecture CV(0)<='0' hin.

Außerdem ist in VHDL üblich im Port Map den formalen und tatsächlichen 
Namen eines Signals anzugeben (Reference by Name).

Tom

[Punkt Setzer (Gast)]

Dussel schrieb:
> Ich werde mich bessern.A: Addierer port
> map(Vektor_der_den_ersten_Summand_als_Binaerzahl_enthaelt(Schleifenlaufv 
ariable),Vektor_der_den_zweiten_Summand_als_Binaerzahl_enthaelt(Schleife 
nlaufvariable),'0'
> when Schleifenlaufvariable=0 else
> Vektor_fuer_die_Carryzwischenergebnisse(Schleifenlaufvariable),Vektor_de 
r_das_Ergebnis_der_Addition_als_Binaerzahl_enthaelt(Schleifenlaufvariabl 
e),Vektor_fuer_die_Carryzwischenergebnisse(Schleifenlaufvariable+1));;-)

Das ist weder sinnvoll, noch eine Verbesserung. Sinnvoll ist bspw. die 
Richtung des ports durch eine Endung zu verdeutlichen also:

ENTITY adder IS
PORT (
 a_i:   IN  T_ADDER_OP;
 b_i:   IN  T_ADDER_OP;
 --result: sum_o <= a_i + b_i 
 sum_o:OUT  T_ADDER_OP);
END adder;

Das verhindert Fehler wie versehentliches Lesen vom Output port und 
Beschreiben eines input-ports.

Greetings Earthlings,

[Dussel (Gast)]

Lothar Miller schrieb:
> Gut. Dann nenne deine VHDL-Dateien auch *.vhdl...
Da war ich mir nicht sicher, ob die dann korrekt angezeigt werden. Txt 
kann jeder lesen und, wenn er mein tolles Projekt wirklich für sich 
selber übersetzen will, umbenennen. PlanAhead hat übrigens die Endung 
.vhd angehängt.

Thomas Reinemann schrieb:
> Da CV(0) nie ein Wert durch einen Addierer zugewiesen wird, kannst du es
> selber machen. Schreib irgendwo in der Architecture CV(0)<='0' hin.

signal CV:STD_LOGIC_VECTOR(Breite downto 0):=(others=>'0');

Punkt Setzer schrieb:
> Das ist weder sinnvoll, noch eine Verbesserung.
Danke für den Hinweis -.-

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Dussel schrieb:
> Thomas Reinemann schrieb:
>> Da CV(0) nie ein Wert durch einen Addierer zugewiesen wird, kannst du es
>> selber machen. Schreib irgendwo in der Architecture CV(0)<='0' hin.signal
> CV:STD_LOGIC_VECTOR(Breite downto 0):=(others=>'0');

Wenn schon eine '0' in CV(0) steht, warum willst du sie dann noch 
explizit mit dem "bedingten Port Mapping" zuweisen?

Tom

[Duke Scarring (Gast)]

Dussel schrieb:
> PlanAhead hat übrigens die Endung .vhd angehängt.

Die Chips von Xilinx sind gut, aber ihre Software ist leider nicht das 
Maß der Dinge :-(

Auch bei der Verwendung von VHDL geht Xilinx nicht mit gutem Beispiel 
voran (z.B. intensiver Verwendung von std_logic_unsigned).

Duke

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Duke Scarring schrieb:
> (z.B. intensiver Verwendung von std_logic_unsigned).
... oder der Verwendung von Vektoren mit verkehrter Bitwertigkeit (Busse 
mit 0 to 31 statt 31 downto 0).

[Dussel (Gast)]

Thomas Reinemann schrieb:
> Wenn schon eine '0' in CV(0) steht, warum willst du sie dann noch
> explizit mit dem "bedingten Port Mapping" zuweisen?
Einfach wegen der Logik. Ich habe zum Beispiel acht Addierer, also habe 
ich auch acht Carryausgänge. Warum soll also der Vektor, an den die 
Carryausgänge angeschlossen werden, neun Elemente haben?
Außerdem gibt der Synthesizer trotz der expliziten Zuweisung eine 
Warnung aus.

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Dussel schrieb:

> Außerdem gibt der Synthesizer trotz der expliziten Zuweisung eine
> Warnung aus.

Weil dieses Konstrukt
        L: for i in 0 to Breite-1 generate
            A: Addierer port 
map(AV(i),BV(i),CV(i),ErgebnisV(i),CV(i+1));
        end generate;

nun einmal einen CV von 0 bis Breite haben will.

Tom

[Dussel (Gast)]

Thomas Reinemann schrieb:
> Weil dieses Konstrukt
> […]
> nun einmal einen CV von 0 bis Breite haben will.
Und den bekommt es auch.
Die Warnung ist, dass dem Carryeingang von Addierer(0) kein Signal(wert) 
zugewiesen ist und er deshalb auf '0' gelegt wird.

[Punkt Setzer (Gast)]

Dussel schrieb:
> Einfach wegen der Logik. Ich habe zum Beispiel acht Addierer, also habe
> ich auch acht Carryausgänge. Warum soll also der Vektor, an den die
> Carryausgänge angeschlossen werden, neun Elemente haben?
> Außerdem gibt der Synthesizer trotz der expliziten Zuweisung eine
> Warnung aus.

Du musst in Signalen denken und für carry sind es nunmal 9 Signale.
Eins ist davon offen, es treibt kein Senke. Nichtdesto trotz exestiert 
es.

MfG,

[Punkt Setzer (Gast)]

Dussel schrieb:
> Die Warnung ist, dass dem Carryeingang von Addierer(0) kein Signal(wert)
> zugewiesen ist und er deshalb auf '0' gelegt wird.

Hast du auch wie bereits zweimal hingewiesen cv(0) mit '0' 
"initialisiert"?! dann sollte sich diese Warning erübrigen. Wie lautet 
die warning im original?

[Dussel (Gast)]

Punkt Setzer schrieb:
> Hast du auch wie bereits zweimal hingewiesen cv(0) mit '0'
> "initialisiert"?!
Ich finde den Hinweis nur ein Mal. Und den Vektor habe ich komplett mit 
0 initialisiert, wie ich oben schrieb. Nur das Signal habe ich nicht 
explizit nochmal auf '0' gelegt.

Den genauen Text der Warnung kann ich jetzt nicht nachsehen, weil ich 
Windows nicht gestartet habe. Wenn das wichtig ist, kann das später noch 
schreiben. Es war etwas wie 'CV(0) is read but never assigned. It is 
automatically tied to '0' '.

Punkt Setzer schrieb:
> Du musst in Signalen denken und für carry sind es nunmal 9 Signale.
Das ist alles klar. Meine Schaltung funktioniert ja auch wie erwartet. 
Es wäre meiner Meinung nach einfach schöner, wenn alles gleichartig [mir 
fällt das passende Wort nicht ein] wäre. Ich habe acht Addierer, acht 
Eingänge pro Summand, acht Ausgänge, aber neun Carrys.
Deshalb habe ich gefragt.

[Klaus F. (kfalser)]

Vielleicht ist es das, was Du suchst:

L: for i in 0 to Breite-1 generate
    B0 : if i = 0 generate 
       A: Addierer port map(AV(i),BV(i),'0',ErgebnisV(i),CV(i));
    end generate;

    B : if i > 0 generate 
       A: Addierer port map(AV(i),BV(i),CV(i-1),ErgebnisV(i),CV(i));
    end generate;
end generate;

Du sollest Dir aber angewöhnen, die Port Signale über Namen zuzuweisen.

[Fpgakuechle K. (Gast)]

Dussel schrieb:
> Punkt Setzer schrieb:
>> Hast du auch wie bereits zweimal hingewiesen cv(0) mit '0'
>> "initialisiert"?!
> Ich finde den Hinweis nur ein Mal. Und den Vektor habe ich komplett mit
> 0 initialisiert, wie ich oben schrieb. Nur das Signal habe ich nicht
> explizit nochmal auf '0' gelegt.

Genau das könnte das Problem sein. Die Zuweisung bei der Signal 
deklaration ist hier nur für die SIMULATION, für die SYNTHESE ist die 
Leitung offen.

Du musst die Leitung aber auf einen festen Wert legen oder wie der 
Hardwerker sagt: "klemmen". In manchen VHDL code ist das erkennbar in 
dem die Konstante "GND" verwendet wird. Schreibe also wie Thomas 
Reinemann am 18.07 um 08:03 vorgeschlagen eine direkte Zuweisung in die 
architecture und die warning sollte entschwinden.

PORT map ist eben eine echte verdrahtung. Stzell dir vor du müsstest die 
ports wie IC-Anschlüße in echt verdrahten. Dann liesst sich einen 
Portmap wie:

Ziehe einen Draht von GND ('0') zum Carry in-pin des ersten HA
Ziehe einen Draht vom Carry Out-pin des ersten HA zum Carry in-pin des 
zweiten HA
...
Ziehe einen Draht vom CarryOut-pin des letzten HA und lasse ihn in der 
Luft hängen


In VHDL programmiert man nicht - man denkt in Hardware.

MfG,

[Da D. (dieter)]

Fpga Kuechle schrieb:
> Genau das könnte das Problem sein. Die Zuweisung bei der Signal
> deklaration ist hier nur für die SIMULATION, für die SYNTHESE ist die
> Leitung offen.

Falsch. Leider hält sich dieses Gerücht hartnäckig. Aber jeder (mir 
bekannte) Synthesizer unterstützt Initialisierungen bei der Deklaration.

[Fpgakuechle K. (Gast)]

Da Dieter schrieb:
> Fpga Kuechle schrieb:
>> Genau das könnte das Problem sein. Die Zuweisung bei der Signal
>> deklaration ist hier nur für die SIMULATION, für die SYNTHESE ist die
>> Leitung offen.
>
> Falsch. Leider hält sich dieses Gerücht hartnäckig. Aber jeder (mir
> bekannte) Synthesizer unterstützt Initialisierungen bei der Deklaration.

Bei der Initialisierung von FF vielleicht . Wenn aber die Warning 
korrekt wiedergegeben wurde:

Zitat: "Es war etwas wie 'CV(0) is read but never assigned. It is
automatically tied to '0' '. "/Zitat.

ist hier nicht die initialisierung bei der Deklaration erkannt worden um 
die Leitung an '0' zu legen. Deshalb schrieb ich ja auch: "deklaration 
ist HIER nur für die Simulation". Wenn es um eine Beschreibung von 
Fliflops geht wäre der Fall anders, hier ist aber nur kombinatorik im 
Spiel.

MfG,

[Mike (Gast)]

Da Dieter schrieb:
> Fpga Kuechle schrieb:
>> Genau das könnte das Problem sein. Die Zuweisung bei der Signal
>> deklaration ist hier nur für die SIMULATION, für die SYNTHESE ist die
>> Leitung offen.
>
> Falsch. Leider hält sich dieses Gerücht hartnäckig. Aber jeder (mir
> bekannte) Synthesizer unterstützt Initialisierungen bei der Deklaration.

Das kommt vermutlich aus der ASIC-Welt. Ein normales FF hat beim 
Einschalten erst einmal einen zufälligen Wert. (Alle?) FPGAs können den 
bei der Konfiguration aber vorbelegen.

[Fpgakuechle K. (Gast)]

Mike schrieb:
> Da Dieter schrieb:
>> Fpga Kuechle schrieb:
>>> Genau das könnte das Problem sein. Die Zuweisung bei der Signal
>>> deklaration ist hier nur für die SIMULATION, für die SYNTHESE ist die
>>> Leitung offen.
>>
>> Falsch. Leider hält sich dieses Gerücht hartnäckig. Aber jeder (mir
>> bekannte) Synthesizer unterstützt Initialisierungen bei der Deklaration.
>
> Das kommt vermutlich aus der ASIC-Welt. Ein normales FF hat beim
> Einschalten erst einmal einen zufälligen Wert. (Alle?) FPGAs können den
> bei der Konfiguration aber vorbelegen.

Das geschilderte Problem ist nicht ausschließlich Frage der 
Halbleitertechnologie sondern ob das Synthesetool den Init-wert bei der 
deklaration ignoriert oder verwendet. Bei Xilinx sind alle FF nach der 
konfiguration initilisiert 
(http://notes-application.abcelectronique.com/077/77-43424.pdf S.5) - 
ist stellt sich aber die Frage woher es diesen Initwert nimmt. Das kann 
ein constraint sein, ein generic bei der FF-Instanziierung oder eine 
VHDL-Synthese die den initwert ignoriert oder nicht.

MfG

PS:Das problem der nichtinitialisierten FF kann man auch mit einem POR 
(PowerOn-Reset) auflösen. So wurde es auch bei den älteren Xilinx FPGAs 
(Spartan2) gemacht.

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Mike schrieb:
> Das kommt vermutlich aus der ASIC-Welt. Ein normales FF hat beim
> Einschalten erst einmal einen zufälligen Wert. (Alle?) FPGAs können den
> bei der Konfiguration aber vorbelegen.

Bei den FPGAs von Microsemi geht das Technologie-bedingt nicht. Da 
braucht man einen Reset.

Tom