Subtraktionsglied mit "Borrow Out"

[Burkhard K. (buks)]

Hallo,

lässt sich ein Subtraktionsglied mit "Borrow Out" per VHDL-Coding 
inferieren? Oder muss ich ein entsprechendes Modul eigenhändig 
implementieren? Verwendete Platform ist ein Artix-7 / Nexys4 Board. Im 
XST User Guide 
(ftp://ftp.xilinx.com/pub/documentation/misc/xstug_examples.zip) finde 
ich als Beispiel lediglich einen "8-bit Adder with Carry Out".

Hintergrund der Frage: Mein naiver Versuch ein DC Offset Removal à la 
Xilinx WP279 ("Digitally Removing a DC Offset: DSP Without Mathematics") 
umzusetzen (siehe unten angehängten Code), funktioniert zwar 
grundsätzlich, gelegentlich zeigen extern (an den vorgeschalteten ADC) 
angelegte periodische Signale jedoch Vorzeichenumkehr - aus einem 
(Ko-)Sinus wird dann ein Rechteck mit sinusförmig eingedellten Dach bzw. 
Boden.

Ursache ist ein möglicher Überlauf im Substraktionsglied 
"Msub_to_adder_1". Sofern beim Anlegen des externen Signals die 
initialen Werte dicht an der oberen oder unteren Grenze des 
ADC-Wertebereiches liegen wird der Wert im Akku für den Ergebnisvektor 
zu groß. Per Überlaufbit könnte das Ergenis auf den Maximal- bzw. 
Mininalwert begrenzt werden, um so eine mögiche Vorzeichenumkehr zu 
verhindern.

Gruß,
Burkhard

entity DCremover is
  Generic ( 
    C_DATA_WIDTH: integer := 12;
    C_K_WIDTH    : integer := 18;   -- width K Factor"
    DIN_USGND  : std_logic := '1'
  );
  Port ( 
      clk :  in  STD_LOGIC;
      clr :  in  STD_LOGIC;
      en   :  in  STD_LOGIC;
      din :  in  STD_LOGIC_VECTOR (C_DATA_WIDTH-1 downto 0);
      dout: out  STD_LOGIC_VECTOR (C_DATA_WIDTH-1 downto 0)
  );
end DCremover;

architecture RTL of DCremover is

  constant C_MULT_WIDTH: integer := C_DATA_WIDTH+C_K_WIDTH;

  signal to_subst : signed(C_DATA_WIDTH-1 downto 0);
  signal to_adder : signed(C_DATA_WIDTH-1 downto 0);
  signal accu_next: signed(C_MULT_WIDTH-1 downto 0);
  signal accu_reg : signed(C_MULT_WIDTH-1 downto 0) := (others=>'0');
  alias  accu_msb : signed(C_DATA_WIDTH-1 downto 0) is accu_reg(C_MULT_WIDTH-1 downto C_K_WIDTH);

begin

  process(clk, clr) 
  begin
    if rising_edge(clk) then
      if (clr = '1') then
        accu_reg <= to_signed(0, accu_reg'length);
      elsif(en='1') then
        accu_reg <= accu_next;
      end if;
    end if;
  end process;
  
  to_subst <= signed(not(din(din'high)) & din(din'high-1 downto 0)) when DIN_USGND='1' else
          signed(din);
  to_adder  <= to_subst - accu_msb;
  accu_next<= to_adder + accu_reg;
  dout    <= std_logic_vector(to_adder);
  
end RTL;

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

Burkhard K. schrieb:
> lässt sich ein Subtraktionsglied mit "Borrow Out" per VHDL-Coding
> inferieren?
Du meinst das "Unterlauf" Bit?

> Hintergrund der Frage:
Erlär doch mal dein Problem mit natürlichsprachlichen Worten und WERTEN. 
Dann kann man sich evtl. ganz leicht vorstellen, was du da willst. 
Derzeit ist es irgendwie holprig.

Ich vermute, das Grundproblem hier ist, dass das Ergebnis der Addition 
zweier Vektoren ein Bit breiter ist (bzw. sein kann) als der breitere 
der beiden Vektoren. Und dass eine Subtraktion eigentlich auch nur eine 
Addition ist...

Die von dir gesuchte Information steckt mit hoher Wahrscheinlichkeit in 
diesem zusätzlichen und von dir einfach abgeschnittenen Bit.

BTW: ich finde es extrem verwirrend, wenn da so viele accu_*** 
kursieren. Ich würde da den Überblick verlieren.

BTW2: was heißt denn DIN_USGND? Deutsche Industriennorm mit US Ground?
Oder warum machst du dir nicht die Geschwätzigkeit von VHDL zu Nutzen 
und schreibst "InputValueIsUnsigned"

[Gustl B. (-gb-)]

Der 74193 kann das. Also runterzählen mit borrow out.

[Rick Dangerus (Gast)]

Burkhard K. schrieb:
> lässt sich ein Subtraktionsglied mit "Borrow Out" per VHDL-Coding
> inferieren?
Ich denke ja.

Um zu sehen, ob der Code richtig rechnet, verfüttere ich ihn (inklusive 
Testbench) an einen Simulator. Ich hab Dir mal eine Variante angefügt.


Rick

[Fpgakuechle K. (Gast)]

Gustl B. schrieb:
> Der 74193 kann das. Also runterzählen mit borrow out.

Dort der Schaltplan dazu:
http://www.ee.scu.edu/classes/1998fall/elen021/hwk/ckt193b.GIF

Ob es sich interferen lässt kann dir der library guide verraten:

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug953-vivado-7series-libraries.pdf

Im Abschnitt ADD/SUB Makro Auf Seite 42 steht ganz oben unter Design 
entry method "Interference - NO" Wobei sich das auf den DSP48 
adder/subtracter bezieht. bei carry chain Makros kann das schoon anders 
aussehen und eigentlich kann das synthesetool immer was aus LUT's 
zusammensynthetisieren ohne das man diese per Hand instanziiert. Ob's 
optimal ist sei dahingestellt.

MfG,

[Gustl B. (-gb-)]

Was ist eigentlich dieses interferen? Den 74193 hab ich schon in VHDL 
gemacht, und zwar exakt den Schaltplan nachgebaut den ich zu TTL Stein 
gefunden hatte.

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

Gustl B. schrieb:
> Was ist eigentlich dieses interferen?
Es heißt eigentlich "inferieren" und bedeutet normalerweise, dass eine 
Komponente, die bereits als fertige Hardware vorliegt in ein Design 
eingebunden werden soll.
Es könnte also z.B. eine LUT inferiert werden. Oder ein Schieberegister 
oder ein RAM-Block. Oder ein Flipflop...

Das Wort "inferieren" deutet üblicherweise auf eine sehr hardwarenahe 
Beschreibung hin. So etwas ist beim hiesigen Problem aber eigentlich 
nicht nötig.

[Markus F. (mfro)]

Das Wort "inferieren" gibt's eigentlich gar nicht. Jedenfalls hab' ichs 
im Duden nicht gefunden.

"to infer" heißt (im Englischen) soviel wie "etwas (von etwas anderem) 
ableiten" oder "schlußfolgern". Paßt irgendwie nicht so recht.

Fündig wird man aber im Lateinischen. "inferre" heißt "etwas hinzufügen" 
oder "etwas hineintun". Das paßt schon eher.

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

Markus F. schrieb:
> Das Wort "inferieren" gibt's eigentlich gar nicht. Jedenfalls hab' ichs
> im Duden nicht gefunden.
Besser als das dem Duden noch nicht bekannte "inferieren" sollte man 
deshalb das geläufigere "instanziieren" nehmen... ;-)

[Burkhard K. (buks)]

Danke Euch soweit für die Antworten, Links und die Testbench.

Vielleicht noch ein Wort zur Erläuterung: Ich will die Breite des 
Eingangsvektors beibehalten, um das zu verarbeitende Signal nicht (um 6 
dB) zu dämpfen - ich rechne hier mit Audiosignalen. Würde ich den 
Wertebereich hier erweitern, müsste ich das an anderer Stelle wieder 
herausrechnen.

Den für mich entscheidenden Hinweis hat Lothar geliefert:
 >Und dass eine Subtraktion eigentlich auch nur eine Addition ist...

D.h. dass das "Borrow out" der Subtraktion dem "Carry Out" der Addition 
entspricht - bzw. dem "Überlaufbit" nach dem ich gesucht habe. Da 
vorzeichenbehaftete Werte verarbeitet werden, steckt diese Information 
im MSB-1. Anhand der Kombination MSB & MSB-1 läßt sich entscheiden, ob 
ein Überlauf im positiven- oder negativen Wertebereich erfolgt:

signal to_subst : signed(C_DATA_WIDTH-1 downto 0);
signal subst_wc : signed(C_DATA_WIDTH   downto 0);
signal to_adder : signed(C_DATA_WIDTH-1 downto 0);

...

subst_wc <= to_signed(to_integer(to_subst) - to_integer(accu_msb), subst_wc'length);
to_adder <= C_MAXINT when subst_wc(subst_wc'high downto subst_wc'high-1) = "01" else
            C_MININT when subst_wc(subst_wc'high downto subst_wc'high-1) = "10" else
            subst_wc(subst_wc'high) & subst_wc(subst_wc'high-2 downto 0);

wobei der Vektor subst_wc um ein Bit breiter sein muss als to_adder. Das 
Synthesetool macht daraus:

   Synthesizing Unit <DCremover>.
    Related source file is "...\DCremover.vhd".
        C_DATA_WIDTH = 14
        C_K_WIDTH = 18
        DIN_USGND = '1'
    Found 32-bit register for signal <accu_reg>.
    Found 15-bit subtractor for signal <subst_wc> created at line 75.
    Found 32-bit adder for signal <accu_next> created at line 79.
    Summary:
        inferred   2 Adder/Subtractor(s).
        inferred  32 D-type flip-flop(s).
   Unit <DCremover> synthesized.

Lediglich das RTL-Schaltbild wird durch die nachgeschaltete 
Begrenzerlogik umfangreicher.

Die noch nicht im Duden stehende Sprachschlamperei "Inferieren" möge man 
mir bitte nachsehen - sie ist aber im Gegensatz zu "Instanziieren" 
eindeutig, wie z.B. der Eintrag im "7 Series FPGA Libraries Guide" 
zeigt: Das ADDSUB_MACRO kann zwar instanziiert - aber nicht per Inferenz 
angesprochen werden.

[Fpgakuechle K. (Gast)]

Markus F. schrieb:
> Das Wort "inferieren" gibt's eigentlich gar nicht. Jedenfalls hab' ichs
> im Duden nicht gefunden.
>
> "to infer" heißt (im Englischen) soviel wie "etwas (von etwas anderem)
> ableiten" oder "schlußfolgern". Paßt irgendwie nicht so recht.

Doch das passt 100%. Inferieren heisst hier das das Synthesetool aus der 
(Verhaltens-)beschreibung erkannt hat, das da bspw ein 8 bit binär 
counter gemeint ist und den dort einfügt. Oder das array of integer als 
BRAM-Block interpretiert und einfügt.

Im deutschen gibt es halt keine passende Übersetzung dafür.

Ich überprüfe beispielsweise im Syntheselog ob das tool "infer counter" 
etc.
an der erwartetet Stellen meldet. Andernfalls ist der Code fürs tool 
unverständlich. "Infered latch" sollte man auch beachten, dann ist die 
Beschreibung meist unvollständig.

Da eine Gegenüberstellung Istanziierung/Inferierung:
http://www.fpga.agh.edu.pl/puc/?download=W_PUC_Tips.pdf

MfG,