Bedingte Zuweisung in Port Map

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

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

>

1

A: Addierer port map(AV(i),BV(i),'0' when i=0 else 

2

> CV(i),ErgebnisV(i),CV(i+1));

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

SCNR,

Ich werde mich bessern.

1

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.

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:

1

ENTITY adder IS

2

PORT (

3

 a_i:   IN  T_ADDER_OP;

4

 b_i:   IN  T_ADDER_OP;

5

 --result: sum_o <= a_i + b_i 

6

 sum_o:OUT  T_ADDER_OP);

7

END adder;

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

Greetings Earthlings,

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.

1

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 -.-

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

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 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.

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,

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?

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.

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 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,

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.

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.