[VHDL] Subtrahieren in der FOR-Schleife

[Tandrael (Gast)]

Hallo,

unsere Arbeit an der ALU ist beinahe beendet, die Addition wurde 
inzwischen mit einer FOR-Schleife realisiert, und das Ergebnis stimmt 
nun. Das einzige Problem ist unsere Subtraktion, die im Zweierkomplement 
stattfinden soll. Die Umrechnung ins Zweierkomplement klappt dabei 
problemlos, plötzlich funktioniert jedoch die Addition nicht. Statt 
einfach das Zweierkomplement von B + 000....0000 zu rechnen und somit 
unverändert das Zweierkomplement zu übernehmen, erhalten wir undefined. 
Wo liegt das Problem?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity ALU is
    Port ( A : in  STD_LOGIC_VECTOR (31 downto 0);
           B : in  STD_LOGIC_VECTOR (31 downto 0);
           F : in  STD_LOGIC_VECTOR (2 downto 0);
           Y : out  STD_LOGIC_VECTOR (31 downto 0);
           Z : out  STD_LOGIC;
           Clock : in  STD_LOGIC
  );
  signal O: STD_LOGIC_VECTOR(32 downto 0) := (others => '0');
  signal Bh: STD_LOGIC_VECTOR(31 downto 0);
end ALU;

architecture Behavioral of ALU is
begin
  process (A, B, F, O, Clock)
  begin
    Z <= '0';
    case F is
      when "000" =>
        Y <= A AND B;
      when "001" =>
        Y <= A XOR B;
      when "010" =>
-- A + B
        for k in 0 to 31 loop
          if k = 0 then
            Y(k) <= A(k) XOR B(k);
            O(k) <= A(k) AND B(k);
          else
            Y(k) <= A(k) XOR B(k) XOR O(k-1);
            O(k) <= (A(k) AND B(k)) OR ((A(k) XOR B(k)) AND O(k-1));
          end if;
        end loop;
      when "100" =>
        Y <= A AND NOT B;
      when "101" =>
        Y <= A XOR NOT B;
      when "110" =>
-- A - B
        -- Umdrehen von B
        for k in 0 to 31 loop
          Bh <= NOT(B);
        end loop;
        -- Umgedrehtes B + 1
        for k in 0 to 31 loop
          if k = 0 then
            Bh(k) <= Bh(k) XOR '1';
            O(k) <= Bh(k) AND '1';
          else
            Bh(k) <= Bh(k) XOR O(k-1);
            O(k) <= Bh(k) AND O(k-1);
          end if;
        end loop;
        -- A - B negiert
        for k in 0 to 31 loop
          if k = 0 then
            Y(k) <= A(k) XOR Bh(k);
            O(k) <= A(k) AND Bh(k);
          else
            Y(k) <= A(k) XOR Bh(k) XOR O(k-1);
            O(k) <= (A(k) AND Bh(k)) OR ((A(k) XOR Bh(k)) AND O(k-1));
          end if;
        end loop;
      when "111" =>
-- A - 1
        for k in 0 to 31 loop
          if k = 0 then
            Y(k) <= A(k) XOR '1';
            O(k) <= A(k) AND '1';
          else
            Y(k) <= A(k) XOR '1' XOR O(k-1);
            O(k) <= (A(k) AND '1') OR ((A(k) XOR '1') AND O(k-1));
          end if;
        end loop;
      when others =>
    end case;
  end process;
end Behavioral;

[MaWin (Gast)]

Meinst du nicht, daß hier

 for k in 0 to 31 loop
          Bh <= NOT(B);
        end loop;

die Verwendung von k fehlt ?

[P. K. (pek)]

"Bh" nicht in der Sensitivity-Liste?

Und dann erst noch keine Default-Zuweisung, da gibt's ein Latch bei der 
Synthese.

[Tandrael (Gast)]

MaWin schrieb:
> Meinst du nicht, daß hier
>
>  for k in 0 to 31 loop
>           Bh <= NOT(B);
>         end loop;
>
> die Verwendung von k fehlt ?

Alles klar, danke, da ist die Loop überflüssig, ändert aber nichts am 
Fehler.

Peter K. schrieb:
> "Bh" nicht in der Sensitivity-Liste?
>
> Und dann erst noch keine Default-Zuweisung, da gibt's ein Latch bei der
> Synthese.

Bh in die sensitivitylist einzutragen bringt nichts, das mit der 
Default-Zuweisung habe ich leider nicht ganz verstanden.

[P. K. (pek)]

Tandrael schrieb:
> Bh in die sensitivitylist einzutragen bringt nichts, das mit der
> Default-Zuweisung habe ich leider nicht ganz verstanden.

Wenn Bh nicht in jedem Ast des Prozesses zugewiesen wird, ergibt sich 
ein nicht getakteter Speicher (= Latch).

wenn Du das "Bh <= NOT(B);" aus der Bedingung (case) rausnimmst und 
gleich nach dem "begin" des Prozesses einfügst, ist das mal gelöst.

Weil Du aber ein Signal zuweist (welches simulativ erst beim nächsten 
"Durchgang"/Tick des Prozesses ändert), muss "Bh" in die 
Sensitivity-Liste.

[Tandrael (Gast)]

Peter K. schrieb:
> Tandrael schrieb:
>> Bh in die sensitivitylist einzutragen bringt nichts, das mit der
>> Default-Zuweisung habe ich leider nicht ganz verstanden.
>
> Wenn Bh nicht in jedem Ast des Prozesses zugewiesen wird, ergibt sich
> ein nicht getakteter Speicher (= Latch).
>
> wenn Du das "Bh <= NOT(B);" aus der Bedingung (case) rausnimmst und
> gleich nach dem "begin" des Prozesses einfügst, ist das mal gelöst.
>
> Weil Du aber ein Signal zuweist (welches simulativ erst beim nächsten
> "Durchgang"/Tick des Prozesses ändert), muss "Bh" in die
> Sensitivity-Liste.

Das Bh in die Sensitivitylist einzutragen haben wir versucht, es hat 
jedoch das Problem nicht gelöst.

[MaWin (Gast)]

> Alles klar, danke, da ist die Loop überflüssig,
> ändert aber nichts am Fehler.

Nö, das war nur der erste Fehler, in dem Stil geht es weiter:

die

     for k in 0 to 31 loop
          if k = 0 then
            Bh(k) <= Bh(k) XOR '1';
            O(k) <= Bh(k) AND '1';
          else
            Bh(k) <= Bh(k) XOR O(k-1);
            O(k) <= Bh(k) AND O(k-1);
          end if;
        end loop;


kann doch nicht funktionieren, welches Bh(k) soll denn nach dem Takt 
gemeint sein, und woher soll die O(k-1) vor dem Takt kommen ?

Mir scheint, ihr habt die sequentielle Denkweise eines FOR aus einer 
Programmiersprache im Kopf, und nicht die parallele Anordnung von 
Funktionsblöcken in VHDL, macht also den typischen VHDL Denkfehler eines 
Informatikers statt eines Etechniks.

[Tandrael (Gast)]

MaWin schrieb:
> Mir scheint, ihr habt die sequentielle Denkweise eines FOR aus einer
> Programmiersprache im Kopf, und nicht die parallele Anordnung von
> Funktionsblöcken in VHDL, macht also den typischen VHDL Denkfehler eines
> Informatikers statt eines Etechniks.

Das kann sehr gut sein, was würde das Problem denn lösen?

[Matthias (Gast)]

Tandrael schrieb:
> Peter K. schrieb:
>> "Bh" nicht in der Sensitivity-Liste?
>>
>> Und dann erst noch keine Default-Zuweisung, da gibt's ein Latch bei der
>> Synthese.
>
> Bh in die sensitivitylist einzutragen bringt nichts, das mit der
> Default-Zuweisung habe ich leider nicht ganz verstanden.

Ohne Default-Zuweisung denkt er sich "Ok, Werte behalten". Da es sich um 
reine Kombinatorik handelt (keine Clock ala rising_edge), baut er ein 
Latch, das bestimmt nicht beabsichtigt ist...

Tandrael schrieb:
> entity ALU is
>     Port ( A : in  STD_LOGIC_VECTOR (31 downto 0);
>            B : in  STD_LOGIC_VECTOR (31 downto 0);
>            F : in  STD_LOGIC_VECTOR (2 downto 0);
>            Y : out  STD_LOGIC_VECTOR (31 downto 0);
>            Z : out  STD_LOGIC;
>            Clock : in  STD_LOGIC
>   );
>   signal O: STD_LOGIC_VECTOR(32 downto 0) := (others => '0');
>   signal Bh: STD_LOGIC_VECTOR(31 downto 0);
> end ALU;

Das auch Signale in der Entity vorkommen, ist mir neu.

"A+B" kannst du in einer Zeile berechnen. Auch Overflow & andere Flags 
kannst du trotzdem noch berechnen. Im Falle vom Overflow genügt es ein 
angehängtes Bit im Ergebnis mehr zu nehmen.

Bei "A-B" gilt ähnliches: Geht auch in ein,zwei Zeilen mit ggf 
notwendiger Erweiterung bzgl Flags(N,Z,C,O,..):

architec...

 pSUB : process(A,B,...
  variable v_zweierkomp : std_logic_vector(31 downto 0) := (others => '0');
  variable v_tmp : std_logic_vector(32 downto 0) := (others => '0');
 begin
  v_zweierkomp := std_logic_vector(unsigned(not B) + 1);
  v_tmp := ('0' & A) + ('0' & v_zweierkomp);   -- und eben Anpassung, dass     Flags passend gesetzt werden
 end process;

 Y <= v_tmp(31 downto 0);
 O <= v_tmp(32);

end

In der FOR-Schleifen müsstest variablen verwenden, da die den Wert 
gleich annehmen.

LG

[Tandrael (Gast)]

Matthias schrieb:
> "A+B" kannst du in einer Zeile berechnen. Auch Overflow & andere Flags
> kannst du trotzdem noch berechnen. Im Falle vom Overflow genügt es ein
> angehängtes Bit im Ergebnis mehr zu nehmen.
>
> Bei "A-B" gilt ähnliches: Geht auch in ein,zwei Zeilen mit ggf
> notwendiger Erweiterung bzgl Flags(N,Z,C,O,..):

Das haben wir versucht, mit unsigned und was weiß ich nicht allem. Ging 
bei uns nie, deswegen die Forschleifen. Unser Programm hat ja auch schon 
mal komplett funktioniert, die Iverflows etc. waren kein Problem, nur 
ging die einfache Addition Z = A + B nicht, selbst A = A + 1 ging nicht. 
Andere Nutzer haben unser Programm über ALDEC ausprobiert, ging, aber 
bei uns kam immer Fehler raus. Nach der ersten Addition 0000....0000X, 
und danach immer nur XXXX....XXXX. Keine Ahnung, woran das liegt.

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

Dass das Bh ein Latch beschreibt ist hier unwichtig, denn für den zu 
betrachtenden Fall ist dieses Latch transparent...

Tandrael schrieb:
> Das Bh in die Sensitivitylist einzutragen haben wir versucht, es hat
> jedoch das Problem nicht gelöst.
Stochern im Nebel.

Leider ist diese (m.E. unsinnige) Beschreibung genau das Beispiel, in 
dem eine Variable angebracht wäre. Denn mit solchen Zuweisungen wie

   O(k) <= (A(k) AND B(k)) OR ((A(k) XOR B(k)) AND O(k-1));

muss der Prozess evtl. nach jedem einzelnen Schleifendurchlauf neu 
auferufen werden...

MaWin schrieb:
> kann doch nicht funktionieren, welches Bh(k) soll denn nach dem Takt
> gemeint sein, und woher soll die O(k-1) vor dem Takt kommen ?
Da ist weit&breit kein Takt im ganzen Design. Der Clock steht nur zur 
Verwirrung da (und sorgt für seltsames Verhalten)...