Wo ist der Unterschied? Einmal Latch, einmal nicht.

[Gustl B. (-gb-)]

Hallo, um etwas zu lernen probiere ich gerade Dinge aus. Da hab ich also 
einen Volladdierer:

s <= x xor y xor c_in;
c_out <= (x and y) or ((x xor y) and c_in);

So und daraus möchte ich einen 8Bit Addierer aufbauen. Ja, das kann man 
mit generate machen, aber will ich nicht.

Erste Lösung:

signal c_vec: std_logic_vector(8 downto 0):=(others => '0');
signal x_vec,y_vec,s_vec: std_logic_vector(7 downto 0):=(others => '0');
--c_vec ist eins länger weil eben Übertrag.
begin
process (x_vec,y_vec,c_vec) begin
  for I in 0 to 7 loop
    s_vec(I) <= x_vec(I) xor y_vec(I) xor c_vec(I);
    c_vec(I+1) <= (x_vec(I) and y_vec(I)) or ((x_vec(I) xor y_vec(I)) and c_vec(I));
  end loop;
end process;

Da macht die Synthese aus c_vec ein Latch.

Schreibe ich das ohne Loop aus:

s_vec(0) <= x_vec(0) xor y_vec(0) xor c_vec(0);
s_vec(1) <= x_vec(1) xor y_vec(1) xor c_vec(1);
s_vec(2) <= x_vec(2) xor y_vec(2) xor c_vec(2);
s_vec(3) <= x_vec(3) xor y_vec(3) xor c_vec(3);
s_vec(4) <= x_vec(4) xor y_vec(4) xor c_vec(4);
s_vec(5) <= x_vec(5) xor y_vec(5) xor c_vec(5);
s_vec(6) <= x_vec(6) xor y_vec(6) xor c_vec(6);
s_vec(7) <= x_vec(7) xor y_vec(7) xor c_vec(7);

c_vec(1) <= (x_vec(0) and y_vec(0)) or ((x_vec(0) xor y_vec(0)) and c_vec(0));
c_vec(2) <= (x_vec(1) and y_vec(1)) or ((x_vec(1) xor y_vec(1)) and c_vec(1));
c_vec(3) <= (x_vec(2) and y_vec(2)) or ((x_vec(2) xor y_vec(2)) and c_vec(2));
c_vec(4) <= (x_vec(3) and y_vec(3)) or ((x_vec(3) xor y_vec(3)) and c_vec(3));
c_vec(5) <= (x_vec(4) and y_vec(4)) or ((x_vec(4) xor y_vec(4)) and c_vec(4));
c_vec(6) <= (x_vec(5) and y_vec(5)) or ((x_vec(5) xor y_vec(5)) and c_vec(5));
c_vec(7) <= (x_vec(6) and y_vec(6)) or ((x_vec(6) xor y_vec(6)) and c_vec(6));
c_vec(8) <= (x_vec(7) and y_vec(7)) or ((x_vec(7) xor y_vec(7)) and c_vec(7));

Gibt es kein Latch.
Wo ist der Unterschied? Das ist doch alles kombinatorisch?

Edit:
Mit

fulladd: for I in 0 to 7 generate
  c_vec(I+1) <= (x_vec(I) and y_vec(I)) or ((x_vec(I) xor y_vec(I)) and c_vec(I));
  s_vec(I) <= x_vec(I) xor y_vec(I) xor c_vec(I);
end generate;

gibt es auch kein Latch. Also wieso gibt es bei der for loop im process 
eines?

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

Gustl B. schrieb:
> Da macht die Synthese aus c_vec ein Latch.
Mit allen 9 Bits? Welcher Synthesizer, welche Toolchain?

[Gustl B. (-gb-)]

Ja, alle 9 Bits. Ist das aktuelle Vivado.

Aber:
Ich hatte das immer nur simuliert und das RTL Analysis > Schematic 
angeguckt. Wenn man das wirklich implementieren lässt, dann kommt das 
Gleiche bei raus. Immer 11 LUTs. Ist jedenfalls verwirrend ...

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

Gustl B. schrieb:
> Ich hatte das immer nur simuliert und das RTL Analysis > Schematic
> angeguckt.
Was sind dort das Enable-Signale (Latch-Signale) an diesen Latches?
Sind die statisch auf '1'/aktiv?

Dann dürfte das ein Automatismus sein, der erkennt, dass ein Signal auf 
sich selbst zugewiesen wird. Und daraus reflexartig ein Latch bastelt, 
das von nachfolgenden Optimierungsstufen auf normale Logik reduziert 
wird...

[Gustl B. (-gb-)]

So sieht das aus im Vivado.

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

Gustl B. schrieb:
> So sieht das aus
Wie erwartet: alle Latches immer durchlässig,  bis auf das niedrigste, 
das die 0 gespeichert hat.

[Gustl B. (-gb-)]

Genau, hatte mich nur verwirrt, aber landet nicht in der Hardware, alles 
gut. Gibt es sonst irgendwelche Gründe process oder generate zu 
bevorzugen?

[Gustl B. (-gb-)]

Und es ghet weiter:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity addierer is Port(
  x : in STD_LOGIC_VECTOR (7 downto 0);
  y : in STD_LOGIC_VECTOR (7 downto 0);
  s : out STD_LOGIC_VECTOR (8 downto 0));
end addierer;

architecture Behavioral of addierer is

signal c_vec: std_logic_vector(8 downto 0):=(others => '0');

begin

s(8) <= c_vec(8);

process (x,y,c_vec) begin
  for I in 0 to 7 loop
    c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
    s(I) <= x(I) xor y(I) xor c_vec(I);
  end loop;
end process;

Hier bleibt s(8) immer auf unknown 'U'. Steckt man die Zeile
s(8) <= c_vec(8);
aber mit in die loop, dann sieht es in der Simulation korrekt aus. 
Wieso?

Wieder: Wenn man das als generate schreibt

s(8) <= c_vec(8);
fulladd: for I in 0 to 7 generate
  c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
  s(I) <= x(I) xor y(I) xor c_vec(I);
end generate;

dann passt es auch so in der Simulation. Ja, es kommt wieder identische 
Hardware raus, aber ich möchte verstehen wieso sich die Simulation so 
seltsam verhält.

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

Probier mal das hier:

 process (x,y,c_vec) begin
   for I in 0 to 7 loop
     c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
     s(I) <= x(I) xor y(I) xor c_vec(I);
   end loop;
   s(8) <= c_vec(8);
 end process;

[Gustl B. (-gb-)]

Funktioniert auch wie gewünscht in der Simulation. Aber wieso muss diese 
Zeile
s(8) <= c_vec(8);
überhaupt in den Process? Die sollte sich doch auch so in jedem 
Simulationsschritt neu berechnet werden.

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

Gustl B. schrieb:
> Funktioniert auch wie gewünscht in der Simulation.
> Aber wieso muss diese Zeile s(8) <= c_vec(8); überhaupt in den Process?
Probier mal das hier noch aus:

process (c_vec) begin
  s(8) <= c_vec(8);
end process;

process (x,y,c_vec) begin
  for I in 0 to 7 loop
    c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
    s(I) <= x(I) xor y(I) xor c_vec(I);
  end loop;
end process;

Das ist das, was der Simulator aus der originalen nebenläufigen 
Beschreibung macht. Und jetzt sieht man, dass da möglicherweise multiple 
Treiber auftreten könnten (wenn man mal nicht auf den Bereich der 
Laufvariable achtet).

Und dann weils grad so schön ist, probier das noch aus:

s(8) <= c_vec(8) after 1 ns;

process (x,y,c_vec) begin
  for I in 0 to 7 loop
    c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
    s(I) <= x(I) xor y(I) xor c_vec(I);
  end loop;
end process;

Bin gespannt... ;-)

Gustl B. schrieb:
> Hier bleibt s(8) immer auf unknown 'U'.
'U' ist nicht Unknown, sondern Uninitialized.
https://www.csee.umbc.edu/portal/help/VHDL/misc.html

[Gustl B. (-gb-)]

Lothar M. schrieb:
> 'U' ist nicht Unknown, sondern Uninitialized.

Stimmt, ja ist klar, eine Unaufmerksamkeit meinerseits.

So, beide Beschreibungen erzeugen ein 'U' für s(8) in der Simulation.

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

Und jetzt noch einer:   ;-)

process (c_vec) begin
  s(8) <= c_vec(8);
end process;

process (x,y,c_vec) begin
  for I in 0 to 7 loop
    c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
  end loop;
  s(0) <= x(0) xor y(0) xor c_vec(0);
  s(1) <= x(1) xor y(1) xor c_vec(1);
  s(2) <= x(2) xor y(2) xor c_vec(2);
  s(3) <= x(3) xor y(3) xor c_vec(3);
  s(4) <= x(4) xor y(4) xor c_vec(4);
  s(5) <= x(5) xor y(5) xor c_vec(5);
  s(6) <= x(6) xor y(6) xor c_vec(6);
  s(7) <= x(7) xor y(7) xor c_vec(7);
end process;

[Gustl B. (-gb-)]

Das simuliert so wie es soll, also kein 'U'. Aber was haben wir da jetzt 
gelernt? Die Loop sollte doch exakt das Gleiche machen wie wenn man das 
zu Fuß einzeln hinschreibt? (Dafür gibt es die doch.)

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

Gustl B. schrieb:
> Aber was haben wir da jetzt gelernt?
Es gibt im Simulator ein Problem mit einer vermeintlichen Multisource, 
wenn dem Vektor aus 2 Prozessen (oder eben 1 Prozess und 1 nebenläufigen 
Zuweisung) zugewiesen wird. Wenn man sich das genau anschaut, ist dieses 
Verhalten sogar "genormt"...  :-/

Mit einem lokalen Signal zum Auftrennen dieser Zuweisung gehts dann 
wieder (siehe Screenshot):

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity addierer is Port(
  x : in STD_LOGIC_VECTOR (7 downto 0);
  y : in STD_LOGIC_VECTOR (7 downto 0);
  s : out STD_LOGIC_VECTOR (8 downto 0));
end addierer;

architecture Behavioral of addierer is
signal c_vec: std_logic_vector(8 downto 0):=(others => '0');
signal s_vec: std_logic_vector(7 downto 0):=(others => '0');
begin

s(8)          <= c_vec(8); 
s(7 downto 0) <= s_vec;

process (x,y,c_vec) begin
  for I in 0 to 7 loop
    c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
    s_vec(I) <= x(I) xor y(I) xor c_vec(I);
  end loop;
end process;

end Behavioral;

Die Simulatoren Active-HDL und ISIM verhalten sich übrigens gleich wie 
der Vivado-Simulator.

[Gustl B. (-gb-)]

HM komisch. Ich hätte erwartet, dass ein std_logic_vector von der 
Simulation nicht als ein Stück berechnet wird sondern als einzelne 
std_logic. Hier wird das ja nicht als Speicher sondern nur als Kabelbaum 
verwendet.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Nochmal zu den Latches:
Die Zuweisungen in Prozessen gehen der Reihe nach, Zeile für Zeile.
Generate baut dir eine normale Logikwolke.
Wenn eine Logikwolke gewollt ist -> generate.

Beim Prozess gibt es einen latch, weil c_vec(0) Im prozess nie 
beschrieben wird, aber ausgelesen.
Daher muss er den Vektor Zwischenspeichern -> Latch.
Die Synthese erkennt aaber, dass das Murks ist und wirft die Lacthes 
wieder raus.

Also mach mal:

signal c_vec: std_logic_vector(8 downto 0):=(others => '0');
signal x_vec,y_vec,s_vec: std_logic_vector(7 downto 0):=(others => '0');
--c_vec ist eins länger weil eben Übertrag.
begin
process (x_vec,y_vec,c_vec) begin
  c_vec(0) <= '0';
  for I in 0 to 7 loop
    s_vec(I) <= x_vec(I) xor y_vec(I) xor c_vec(I);
    c_vec(I+1) <= (x_vec(I) and y_vec(I)) or ((x_vec(I) xor y_vec(I)) and c_vec(I));
  end loop;
end process;

Ich bin gespannt,

[Gustl B. (-gb-)]

Funktioniert und auch das funktioniert:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity addierer is Port(
  x : in STD_LOGIC_VECTOR (7 downto 0);
  y : in STD_LOGIC_VECTOR (7 downto 0);
  s : out STD_LOGIC_VECTOR (8 downto 0));
end addierer;

architecture Behavioral of addierer is

signal c_vec: std_logic_vector(8 downto 0):=(others => '0');

begin

process (x,y,c_vec) begin
   s(8) <= c_vec(8);
   for I in 0 to 7 loop
      s(I) <= x(I) xor y(I) xor c_vec(I);
      c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
   end loop;
end process;

end Behavioral;

Wobei s(8) <= c_vec(8); wieder im Process stehen muss. Ich finde das 
seltsam weil in der loop werden nur s(7 downto 0) berechnet. Wieso 
berechnet die Simulation s(8) nicht komplett eigenständig? Also gerne 
einen Simulationsschritt später, dann hat sich c_vec(8) geändert und 
somit ändert sich auch s(8). Irgendwie ist das unlogisch ausser man sagt 
dass die Simulation std_logic_vector immer als ganzes berechnet.
Eigentlich soll die Simulation doch das zeigen was dann auch das FPGA 
macht.
Die Post-Synthesis Simulation zeigt natürlich immer das richtige 
Verhalten.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Weil innerhalb Prozessen nichts nebenläufig stattfindet.
Daher werden Speicher verbaut wenn da was nicht definiert ist.

[Gustl B. (-gb-)]

Beispiel:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity addierer is Port(
  x : in STD_LOGIC_VECTOR (7 downto 0);
  y : in STD_LOGIC_VECTOR (7 downto 0);
  s : out STD_LOGIC_VECTOR (8 downto 0));
end addierer;

architecture Behavioral of addierer is

signal c_vec: std_logic_vector(8 downto 0):=(others => '0');

begin

s(8) <= c_vec(8);

process (x,y,c_vec) begin
   for I in 0 to 7 loop
      s(I) <= x(I) xor y(I) xor c_vec(I);
      c_vec(I+1) <= (x(I) and y(I)) or ((x(I) xor y(I)) and c_vec(I));
   end loop;
end process;

end Behavioral;

Na selbst wenn das im Process nacheinander berechnet wird, dann sollte 
doch nach dem Durchlauf oder mehreren Durchläufen am Ende c_vec(8) 
stabil sein. Und da s(8) nicht im process auftaucht sollte das doch dann 
den Wert von c_vec(8) bekommen. Aber s(8) bleibt auf 'U'. Das finde ich 
unlogisch.