Lothar Miller - VHDL

Qualifier

nospam@example.com (Lothar Miller) — Thu, 10 Nov 2011 13:16:56 +0100

Es gestaltet sich in VHDL oft nicht so einfach, dem Synthesizer etwas Glasklares zu vermitteln. Nehmen wir mal diese einfache Aufgabe: Eine Konstante x"1234" soll an einen Vektor (std_logic_vector oder unsigned) zugewiesen werden. Weil die Länge des Vektors noch nicht feststeht, soll vorher ein resize() durchgeführt werden.
Wenn man das jetzt einfach so hinschreibt:

slv <= std_logic_vector(resize(x"1234", slv'length));

Dann erlebt man ein blaues Wunder. Obwohl eigentlich auf Anhieb erkennbar ist, was hier passieren soll, zickt der Compiler herum und meldet sowas wie:

Expression in type conversion to std_logic_vector has 2 possible definitions in this scope, for example, SIGNED and UNSIGNED.

Was ist passiert?
resize() kann signed oder unsigned für diese Konstante zurückliefern. Weil der Synthesizer selber aber nicht entscheiden kann, welcher Datentyp gemeint ist, weiß er auch nicht, ob die resize() Funktion die Konstante als signed oder unsigned zu betrachten hat.
Dies kann ihm mit einem Qualifier gesagt werden: unsigned' sagt, dass der folgende Wert als unsigned zu betrachten ist.

slv <= std_logic_vector(unsigned'(resize(x"1234", slv'length)));

Das hilft dem Synthesizer aus der Klemme, denn jetzt weiß er was das Ziel ist und er verwendet die gewünschte Implementierung der Funktion.

Hier mal eine kleine Aufstellung, was geht und was nicht:

signal slv  :  std_logic_vector (15 downto 0);
signal uv   :  unsigned (15 downto 0);


slv <= std_logic_vector(resize(x"1234", slv'length));
--> Expression in type conversion to std_logic_vector has 2 possible definitions in this scope, for example, SIGNED and UNSIGNED.

slv <= std_logic_vector(unsigned'(resize(x"1234", slv'length)));
--> ok, das Ergebnis von resize ist ein unsigned Vektor

slv <= std_logic_vector(resize(unsigned(x"1234"), slv'length));
--> Expression in type conversion to unsigned has 7 possible definitions in this scope, for example, std_ulogic_vector and std_logic_vector.

slv <= std_logic_vector(resize(unsigned'(x"1234"), slv'length));
--> ok, die Konstante x"1234" ist ein unsigned Wert

uv <= resize(unsigned(x"1234"), uv'length);
--> Expression in type conversion to unsigned has 7 possible definitions in this scope, for example, std_ulogic_vector and std_logic_vector.

uv <= resize(unsigned'(x"1234"), uv'length);
--> ok, die Konstante x"1234" ist ein unsigned Wert

uv <= resize(x"1234", uv'length);
--> ok, der Typ von uv wird für resize verwendet

Bis zu einer Vektorlänge von 31 Bit geht es auch so:

slv <= std_logic_vector(to_unsigned(16#1234#, slv'length));

Hello World!

nospam@example.com (Lothar Miller) — Fri, 23 Sep 2011 11:59:39 +0200

Eine blinkende LED ist das "Hello World!" der Hardware.

Man kann daran erkennen, dass die Versorgung funktioniert, die Logik arbeitet und anhand der Blinkfrequenz einen Zähler beurteilen. Also schon einiges, was so eine einzelne Funzel einem sagen kann

Leider funktioniert diese einfache Variante eines Blinklichts nur in der Simulation:

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
 
entity BlinkLED is 
    Port (led : buffer  STD_LOGIC := '0'); 
end BlinkLED; 
 
architecture Behavioral of BlinkLED is 
begin 
   led <= not led after 500 ms;    -- LED alle 500 ms toggeln 
end Behavioral;

Warum geht das nicht? Es gibt keine "einstellbaren Verzögerungsglieder" (ähnlich wie Monoflops oder RC-Glieder...) im FPGA. Alles, was mit Zeiten zu tun hat, muss in einem FPGA als Zähler aufgebaut werden, der einen Takt mitzählen und beim Erreichen eines passenden Endwertes eine Reaktion auslöst.
Also brauchen wir einen Takt und einen Zähler. In der Regel ist am FPGA ein Quarz mit z.B. 50MHz angeschlossen. Für eine halbe Sekunde müssen also 25 Millionen Takte gezählt werden. Das ergibt eine Registerkette mit 25 Bits (mit diesen 25 Bit wären maximal 2^25=33554432 Zählschritte möglich).
Und diese 25 Register werden mit einem festen Wert 24999999 verglichen. Warum 24999999 und nicht 25000000?
Weil 0...24999999 schon 25000000 Schritte sind. Einfacher wird es vielleicht mit kleineren Zahlen: ein Zähler, der 5 Schritte abzählen muß, braucht die Zahlen 0, 1, 2, 3 und 4.

Also zusammengefasst:
Ein Takt geht auf einen Zähler, der mit einem festen Wert verglichen wird, bei dessen Erreichen zurückgesetzt wird und gleichzeitig eine Aktion auslöst: die LED wird getoggelt.

Hier ist der VHDL-Quellcode für so ein Blinklicht:

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
use IEEE.NUMERIC_STD.ALL; 
 
entity BlinkLED is 
    Port ( clk : in  STD_LOGIC; 
           led : out  STD_LOGIC); 
end BlinkLED; 
 
architecture Behavioral of BlinkLED is 

signal c : integer range 0 to 24999999 := 0; -- 0,5s bei 50MHz fosc
signal x : std_logic:= '0';  

begin 
   process begin  
      wait until rising_edge(clk); -- warten bis zum nächsten Takt 
      if (c<24999999) then         -- 0…24999999 = 25000000 Takte = 1/2 Sekunde bei 50MHz 
          c <= c+1;                -- wenn kleiner: weiterzählen 
      else                         -- wenn Zählerende erreicht: 
          c <= 0;                  -- Zähler zurücksetzen 
          x <= not x;              -- und Signal x togglen 
      end if; 
   end process; 
   led <= x;                       -- Signal x an LED ausgeben 
end Behavioral;

Zur Funktionsweise:
mit einem Zähler werden 25 Millionen Takte eines 50 MHz Taktes abgezählt (also 0..24999999). Wenn der Zählerendwert erreicht wurde, wird der Zähler zurückgesetzt und gleichzeitig ein lokales Signal x getoggelt. Dieses Signal wird dann an den led Ausgang gegeben.

Das lokale Signal x brauchen wir, weil der Port led als out deklariert ist, und daher entsprechend den VHDL Richtlinien nicht lesbar ist.
Und um den Schlauen zuvorzukommen: Nein, es ist keine gute Idee, den Port led als buffer oder inout zu deklarieren, nur damit er zurückgelesen werden und so ein lokales Signal gespart werden kann. Das ist eher ein Kündigungsgrund oder sollte wenigstens einen strengen Verweis in der Personalakte nach sich ziehen...
Als kleiner Lichtblick: ab VHDL 2008 können auch out Ports wieder zurückgelesen werden, diese Ports verhalten sich dann ähnlich wie buffer. So ist es dann möglich, z.B. einen Zähler direkt auf einen out Port zu erzeugen.

Und hier die kompakte Stimuli-"Testbench":

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
use IEEE.NUMERIC_STD.ALL;  
  
entity tb_BlinkLED is 
                                   -- leere Entity --> Testbench
end tb_BlinkLED; 
  
architecture behavior of tb_BlinkLED is
   component BlinkLED 
   port( clk : IN  std_logic; 
         led : OUT  std_logic ); 
   end component; 
    
   signal clk : std_logic := '0';  -- lokale Signale der Testbench
   signal led : std_logic;         -- werden an den Prüfling angeschlossen

begin
   uut: BlinkLED                   -- der Prüfling wird verdrahtet
   port map ( clk => clk, 
              led => led ); 
 
   clk <= not clk after 10 ns;     -- einen 50MHz Takt erzeugen
end;

Wer dieses Blinklicht zum ersten Mal mit ISE realisieren will, der kann sich die Schritt-für-Schritt Anleitung HIER mal ansehen.

Für alle, die noch nicht genug haben kommt hier der Binärzähler auf 8 LEDs.

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
use IEEE.NUMERIC_STD.ALL; 
 
entity BinaryLED is 
    Port ( clk  : in  STD_LOGIC; 
           leds : out STD_LOGIC_VECTOR(7 downto 0)); 
end BinaryLED; 
 
architecture Behavioral of BinaryLED is 

signal c : integer range 0 to 12499999 := 0; -- 0,25s bei 50MHz fosc
signal x : unsigned (7 downto 0) := (others=>'0');  

begin 
   process begin  
      wait until rising_edge(clk); -- warten bis zum nächsten Takt 
      if (c<12499999 ) then        -- 0..12499999 = 12500000 Takte = 1/4 Sekunde bei 50MHz 
          c <= c+1;                -- wenn kleiner: c weiterzählen 
      else                         -- wenn Zählerende erreicht: 
          c <= 0;                  -- Zähler c zurücksetzen 
          x <= x+1;                -- und Zähler x hochzählen 
      end if; 
   end process; 
   leds <= std_logic_vector(x);    -- Signal x an LEDs ausgeben 
end Behavioral;

Im Großen und Ganzen ist das Beispiel gleich wie das obere. Nur wird hier statt der einzelnen LED ein unsigned-Vektor hochgezählt. Das Hochzählen von Vektoren hat den Vorteil, dass der Überlauf von 11111111bin = 255dez nach 00000000bin = 0dez automatisch passiert.

Ich hätte den Zähler x natürlich wie den Zähler c auch als integer machen können, dann hätte der Code (für eine fehlerfreie Simulation) aber so aussehen müssen:

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
use IEEE.NUMERIC_STD.ALL; 
 
entity BinaryLED is 
    Port ( clk  : in  STD_LOGIC; 
           leds : out STD_LOGIC_VECTOR(7 downto 0)); 
end BinaryLED; 
 
architecture Behavioral of BinaryLED is 

signal c : integer range 0 to 12499999 := 0; -- 0,25s bei 50MHz fosc
signal x : integer range 0 to 255 := 0;  

begin 
   process begin  
      wait until rising_edge(clk); -- warten bis zum nächsten Takt 
      if (c<12499999 ) then        -- 0..12499999 = 12500000 Takte 
          c <= c+1;                -- wenn kleiner: c weiterzählen 
      else                         -- wenn Zählerende erreicht: 
          c <= 0;                  -- Zähler c zurücksetzen 
          if (x<255) then          -- ist Zähler x schon "oben" angekommen
             x <= x+1;             -- nein: Zähler x hochzählen 
          else
             x <= 0;               -- ja: zurücksetzen
          end if;
      end if; 
   end process; 
   -- Signal konvertieren und casten und an LEDs ausgeben 
   leds <= std_logic_vector(to_unsigned(x,8)); 
end Behavioral;

Der nächste logische Schritt ist dann, die Erzeugung des Fortschaltimpulses in einem eigenen Prozess zu erzeugen.

library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
use IEEE.NUMERIC_STD.ALL; 
 
entity BinaryLED is 
    Port ( clk  : in  STD_LOGIC; 
           leds : out STD_LOGIC_VECTOR(7 downto 0)); 
end BinaryLED; 
 
architecture Behavioral of BinaryLED is 

signal c : integer range 0 to 12499999 := 0; -- 0,25s bei 50MHz fosc
signal t : std_logic := '0';
signal x : integer range 0 to 255 := 0;  

begin 
   process begin  
      wait until rising_edge(clk); -- warten bis zum nächsten Takt 
      if (c<12499999 ) then        -- 1/4 Sekunde bei 50MHz 
          c <= c+1;                -- wenn kleiner: c weiterzählen 
          t <= '0';                
      else                         -- wenn Zählerende erreicht: 
          c <= 0;                  -- Zähler c zurücksetzen 
          t <= '1';                -- Flag für Tick setzen
      end if; 
   end process; 

   process begin  
      wait until rising_edge(clk); -- warten bis zum nächsten Takt 
      if (t='1') then              -- sind schon wieder 0,25 sec vorbei?
          if (x<255) then          -- ist Zähler x schon "oben" angekommen
             x <= x+1;             -- nein: Zähler x hochzählen 
          else
             x <= 0;               -- ja: zurücksetzen
          end if;
      end if; 
   end process; 

   -- Signal konvertieren und casten und an LEDs ausgeben 
   leds <= std_logic_vector(to_unsigned(x,8)); 
end Behavioral;

Wie man klar sieht, gibt es in diesem Design nur und genau einen einzigen Takt clk. Das ist der Quarzoszillator, der aussen am FPGA angeschlossen ist. Mit diesem Takt läuft das ganze Design. Für Anfänger gilt:
Der Takt ist wie der Highlander: es kann nur einen geben.

Bubblesort

nospam@example.com (Lothar Miller) — Thu, 21 Apr 2011 11:22:18 +0200

Hier jetzt mal eine Umsetzung des allseits bekannten Bubblesort-Algorithmus in VHDL.
Zuerst die rein kombinatorische Variante:

library IEEE;
use IEEE.STD_LOGIC_1164.all;

package BSTypes is
  type BSData_Typ is array (0 to 9) of integer range 0 to 127;
end BSTypes;

package body BSTypes is
end BSTypes;




library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.bstypes.all;

entity Bubblesort is
    Port ( di  : in  BSData_Typ;
           do  : out BSData_Typ );
end Bubblesort;

architecture Behavioral of Bubblesort is
begin

   process (di) 
   variable din  : BSData_Typ;
   variable temp : integer;
   variable n    : integer;
   variable oncemore : boolean;
   begin
      din      := di;
      n        := din'length;
      oncemore := TRUE;
      while oncemore = TRUE and n > 1 loop
         oncemore := FALSE;
         for i in 0 to din'length-2 loop
            if din(i) > din(i+1) then 
               temp     := din(i);   -- Dreieckstausch
               din(i)   := din(i+1);
               din(i+1) := temp;
               oncemore := TRUE;
            end if;
         end loop;
         n := n-1;
      end loop;
      do <= din;
   end process;
   
end Behavioral;

In einem Spartan 3 FPGA braucht diese Lösung abhängig vom Abbruch (über die Variable oncemore) unterschiedlich viele Ressourcen:
Mit Abbruch: Number of Slices 1293 Number of 4 input LUTs 2272
Ohne Abbruch: Number of Slices 976 Number of 4 input LUTs 1701

Der offensichtlichste Unterschied ist, dass der in der Software effizientere Abbruch (wenn das Array schon vor Ablauf aller Kombinationen schon komplett sortiert ist) in der Hardware nur Nachteile mit sich bringt.

Nachfolgend eine getaktete Lösung, die auf Kosten der Rechenzeit deutlich weniger Ressourcen braucht. Bubblesort.zip
Insbesondere fällt hier der Unterschied zwischen der Variante mit und der ohneAbbruch wesentlich geringer aus:
Mit Abbruch: Number of Slices 168 Number of 4 input LUTs 250
Ohne Abbruch: Number of Slices 167 Number of 4 input LUTs 245

-- Typdefinition BSData_Typ s.o.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.bstypes.all;

entity Bubblesort is
    Port ( di    : in  BSData_Typ;
           do    : out BSData_Typ;
           start : in  std_logic;
           done  : out std_logic;
           clk   : in  std_logic);
end Bubblesort;

architecture Behavioral of Bubblesort is
signal busy     : boolean := FALSE;
signal din      : BSData_Typ;
signal n,i      : integer range 0 to din'length;
begin

   process 
   variable temp : integer;
   begin
      wait until rising_edge(clk);
      if (busy=FALSE) then
         if (start='1') then
            din  <= di;
            busy <= TRUE;
            n    <= 0;
            i    <= 0;
         end if;
      else
         if (n < din'length) then
            if (i<din'length-1) then
               if din(i) > din(i+1) then
                  temp     := din(i);   -- Dreieckstausch
                  din(i)   <= din(i+1);
                  din(i+1) <= temp;
               end if;
               i <= i+1;
            else
               i <= 0;
               n <= n+1;
            end if;
         else
            busy <= FALSE;       
            do   <= din;
         end if;
      end if;
   end process;
   
   done <= '1' when start='0' and busy=FALSE else '0';

end Behavioral;

Das ist die Testbench für die kombinatorische Variante:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
use ieee.math_real.all;
use work.bstypes.all;
 
ENTITY tb_BubbleSort IS
END tb_BubbleSort;
 
ARCHITECTURE behavior OF tb_BubbleSort IS 
    COMPONENT Bubblesort
    Port ( di  : in  BSData_Typ;
           do  : out BSData_Typ );
    END COMPONENT;

   --Inputs
   signal di : BSData_Typ := (3,6,1,8,7,2,4,5,9,0);
   --Outputs
   signal do : BSData_Typ;
   
BEGIN
  -- Instantiate the Unit Under Test (UUT)
   uut: Bubblesort PORT MAP (
          di => di,
          do => do
        );

   -- Stimulus process
   stim_proc: process
    variable rand  : real;
    variable seed1 : positive := 234;
    variable seed2 : positive := 567;
   begin    
      wait for 100 ns;  
      loop
         for i in 0 to 9 loop
            UNIFORM(seed1, seed2, rand);
            di(i) <= integer(TRUNC(rand*127.999));
         end loop;
         wait for 10 ns;
         for i in 0 to 8 loop
            assert do(i)<=do(i+1) report "Falsche Reihenfolge!" severity failure;
         end loop;
       end loop;
   end process;

END;

Und das kommt dabei heraus:

Waveform der Testbench für den kombinatorischen Sortierer

Und hier können die Dateien gezippt heruntergeladen werden: Bubblesort.zip

DCF77 Decoder

nospam@example.com (Lothar Miller) — Fri, 14 Jan 2011 09:20:00 +0100

Ein DCF-Signal besteht aus Impulsfolgen, die pro Sekunde mit unterschiedlich langen High-Pegeln eine 0 (=100ms high) bzw. eine 1 (=200ms high) codieren. Die 59. Sekunde wird zur Synchronisation verwendet und wird mit low-Pegel ausgegeben. Die steigende Flanke nach der 58. skeunde ist daher dann die Sekunde 0.

Die Auswertung des DCF-Signals wird also von einem Zähler übernommen, der mit einer steigenden Flanke zurückgesetzt wird. Bei einer fallenden Flanke wird dann entsprechend dem Zählerstand eine '0' (<150ms) oder eine '1' (>150ms) übernommen.
Alternativ kann auch beim Zählerstand 150ms einfach der Pegel des DCF-Signals eingelesen werden.

Erreicht der Zähler einen Wert größer 1 Sekunde, war das die 59. Sekunde. Bei der der nächsten steigenden Flanke des DCF-Signals werden dann die eingelesenen Bits zur weiteren Verarbeitung über ein Pufferregister bereitgestellt.

In dem folgenden Code sollte vor der Synthese eine der beiden Varianten (beide funktionieren gleich gut) der Bit-Auswertung auskommentiert werden

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

entity DCF77 is
    Generic( fclk : integer := 50000000 ); -- 50MHz
    Port   ( clk       : in  std_logic; 
             dcf       : in  std_logic;
             dcf_sec0  : out std_logic;
             bitsout   : out std_logic_vector (58 downto 0) );
end DCF77;

architecture Behavioral of DCF77 is
constant cntmax    : integer := (11*fclk)/10;        -- 1.1 sec
constant cntsample : integer := (15*fclk)/100;       -- 150 ms
signal cnt         : integer range 0 to cntmax := 0; -- Zähler bis 1.1 sec
signal dcfsr       : std_logic_vector(2 downto 0);
signal bits        : std_logic_vector(58 downto 0):= (others=>'0');
begin
   process begin
      wait until rising_edge(clk);
      -- Einsynchronisieren
      dcfsr <= dcfsr(1 downto 0) & dcf;
   
      -- erst Zaehler hochzählen (sättigend bei 1.1 sec)
      if (cnt < cntmax) then 
         cnt <= cnt+1; 
      end if;
      
      -- steigende Flanke vom DCF-Signal
      dcf_sec0 <= '0';             -- für 1 Taktzyklus bei Sekunde 0 aktiv
      if (dcfsr(2 downto 1)="01") then 
         if (cnt = cntmax) then    -- Überlauf? ja: Sekunde 59 war da
            dcf_sec0 <= '1';       -- Sekunde 0 anzeigen
            bitsout <= bits;       -- die gesammelten Daten übergeben
            bits <= (others=>'0'); -- Bit-Schiebegregister zuruecksetzen
         end if;
         cnt <= 0;
      end if;
   
      -- Variante 1: einlesen bei fallender Flanke vom DCF-Signal
      if (dcfsr(2 downto 1)="10") then 
         if (cnt < cntsample) then           -- kurzer Impuls? Grenze 150ms
            bits <= '0' & bits(58 downto 1); -- ja: 0 von links einschieben
         else
            bits <= '1' & bits(58 downto 1); -- nein: 1 von links einschieben
         end if;      
      end if;
      -- --> Ressourcenverbrauch    
      -- Number of Slices       88
      -- Number of Slice FFs    137
      -- Number of 4 input LUTs 104
      
      -- Variante 2: bei Zeitpunkt "150ms" einlesen   
      if (cnt = cntsample) then             -- DCF-Signal einlesen bei 150ms
          bits <= dcfsr(2) & bits(58 downto 1); 
      end if;
      -- --> Ressourcenverbrauch
      -- Number of Slices       87
      -- Number of Slice FFs    137
      -- Number of 4 input LUTs 103

   end process;
end Behavioral;

Zusammen mit der Testbench unten ergeben sich folgende Waveforms:

Überblick

Detail mit Sekunde 59 und darauffolgender Datenübergabe

Hier der DCF77-Decoder incl. Testbench zum Download: DCF77.zip

Mit diesem Decoder werden nur die rohen Daten bereitgestellt. In dem Modul darüber muß dann noch die gesamte Plausibilitätskontrolle (Parity), die Validierung und die weitere Verwaltung der empfangenen Daten realisiert werden.

BCD nach ASCII

nospam@example.com (Lothar Miller) — Thu, 25 Nov 2010 15:43:53 +0100

Sollen Zahlen z.B. an ein Display oder über eine serielle Schnittstelle ausgegeben werden, dann ist es naheliegend, sie zuerst in ein BCD-Format und anschliessend in ASCII umzuwandeln.
Hier werden mehrere Lösungsmöglichkeiten für die Umwandlung einer BCD-Zahl in ein ASCII-Format aufgezeigt.

Der Lösungsansatz bei der Addiererlösung ist folgender:

Wenn di eine Zahl von 0..9 ist, dann addiere eine ASCII-0 dazu.
Wenn di eine Zahl von 10..15 ist, dann subtrahiere 10 und addiere ein ASCII-A dazu.

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

entity BCD2ASCII is
    Port ( di : in  STD_LOGIC_VECTOR (3 downto 0);
           do : out STD_LOGIC_VECTOR (7 downto 0));
end BCD2ASCII;

-- Dierekte Beschreibung als Distributed BROM
-- Maximum combinational path delay: 7.276ns
-- Number of Slices         3
-- Number of 4 input LUTs   6
architecture Behavioral of BCD2ASCII is
   type Rom16x8 is array (0 to 15) of std_logic_vector (7 downto 0);
   constant BCDRom : Rom16x8 := ( 
       std_logic_vector(to_unsigned(character'pos('0'),8)),
       std_logic_vector(to_unsigned(character'pos('1'),8)),
       std_logic_vector(to_unsigned(character'pos('2'),8)),
       std_logic_vector(to_unsigned(character'pos('3'),8)),
       std_logic_vector(to_unsigned(character'pos('4'),8)),
       std_logic_vector(to_unsigned(character'pos('5'),8)),
       std_logic_vector(to_unsigned(character'pos('6'),8)),
       std_logic_vector(to_unsigned(character'pos('7'),8)),
       std_logic_vector(to_unsigned(character'pos('8'),8)),
       std_logic_vector(to_unsigned(character'pos('9'),8)),
       std_logic_vector(to_unsigned(character'pos('A'),8)),
       std_logic_vector(to_unsigned(character'pos('B'),8)),
       std_logic_vector(to_unsigned(character'pos('C'),8)),
       std_logic_vector(to_unsigned(character'pos('D'),8)),
       std_logic_vector(to_unsigned(character'pos('E'),8)),
       std_logic_vector(to_unsigned(character'pos('F'),8)));
begin
   do <= BCDRom(to_integer(unsigned(di)));
end Behavioral;


-- Über eine when-else Anweisung --> es wird ein Distributed BROM instatiiert
-- Maximum combinational path delay: 7.276ns
-- Number of Slices         3
-- Number of 4 input LUTs   6
architecture Behavioral of BCD2ASCII is
begin
     do <= x"30" when di=x"0"  else  
           x"31" when di=x"1"  else  
           x"32" when di=x"2"  else  
           x"33" when di=x"3"  else  
           x"34" when di=x"4"  else  
           x"35" when di=x"5"  else  
           x"36" when di=x"6"  else  
           x"37" when di=x"7"  else  
           x"38" when di=x"8"  else  
           x"39" when di=x"9"  else  
           x"41" when di=x"A"  else  
           x"42" when di=x"B"  else  
           x"43" when di=x"C"  else  
           x"44" when di=x"D"  else  
           x"45" when di=x"E"  else  
           x"46";
end Behavioral;


-- Mit Addierer, die Konstate 10 wird direkt vom ASCII-Wert 'A' abgezogen (selbe Klammerebene)
-- Maximum combinational path delay: 7.276ns
-- Number of Slices         3
-- Number of 4 input LUTs   6
architecture Behavioral of BCD2ASCII is
begin
     do <= std_logic_vector(resize(unsigned(di),8)+to_unsigned(character'pos('A')-10,8))  when unsigned(di)>9  else  
           std_logic_vector(resize(unsigned(di),8)+to_unsigned(character'pos('0'),8));
end Behavioral;

-- Wie vorher, die Konstate 10 wird aber auf einer anderen Klammerebene abgezogen --> ein Subtrahierer wird instatiiert!
-- Maximum combinational path delay: 10.471ns
-- Number of Slices         6
-- Number of 4 input LUTs   10
--architecture Behavioral of BCD2ASCII is
begin
     do <= std_logic_vector(resize(unsigned(di),8)+to_unsigned(character'pos('A'),8)-10)  when unsigned(di)>9  else  
           std_logic_vector(resize(unsigned(di),8)+to_unsigned(character'pos('0'),8));
end Behavioral;

Die ersten 3 Lösungen resultieren in gleichem Ressourcenverbrauch und in der selben Geschwindigkeit.

Sehr interessant ist aber der Unterschied zwischen der (optisch fast gleichen) 3. und 4. Lösung. Dort wurde nur die Subtraktion der Konstante 10 etwas verlegt, und XST fügt dann in die Hardware einen Subtrahierer ein. Dadurch wird das Design größer und langsamer!

PS/2 Tastatur

nospam@example.com (Lothar Miller) — Tue, 26 Oct 2010 08:07:18 +0200

Zur Eingabe von Daten bietet sich eine PS/2 Tastatur an. Die Dinger gibts für ein paar Euros und das Protokoll ist in der einfachsten Variante sehr überschaubar.

Ich habe hier mehrere Implementationen: die Erste ist sehr einfach gehalten und gibt alle empfangenen Scancodes incl. Break und Extended Keycodes einfach mit einem Handshake weiter an ein übergeordnetes Modul:

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

entity PS2_Keyboard is
    Port ( PS2_Data    : in  std_logic;
           PS2_Clk     : in  std_logic;
           RxData      : out std_logic_vector(7 downto 0);
           RxActive    : out std_logic;
           DataReady   : out std_logic; -- Handshake-Signal: Daten bereit
           DataFetched : in  std_logic; -- Handshake-signal: Daten übernommen
           CLK         : in  std_logic);
end PS2_Keyboard;

architecture Behavioral of PS2_Keyboard is
signal RxTimeout   : integer range 0 to 500000 := 0; -- max. 10ms
signal RxRegister  : std_logic_vector(10 downto 0) := (others=>'1');
signal DataSR      : std_logic_vector(1 downto 0)  := (others=>'1');
signal ClkSR       : std_logic_vector(1 downto 0)  := (others=>'1');
type PS2RXStateType is (IDLE, RECEIVE, READY); 
signal PS2RXState : PS2RXStateType := IDLE;

begin
   process begin
      wait until rising_edge(CLK);
      RxTimeout <= RxTimeout+1;
      
      DataSR    <= DataSR(0) & PS2_Data;
      ClkSR     <= ClkSR(0)  & PS2_Clk;
      
      if (ClkSR = "10") then -- fallende Flanke am PS2_CLK
         RxRegister <= DataSR(1) & RxRegister(10 downto 1);
      end if;

      case PS2RXState is
      when IDLE =>
         RxRegister <= (others=>'1');
         RxActive   <= '0';
         DataReady  <= '0';
         RxTimeout  <= 0;
         if (DataSR(1) = '0' and ClkSR(1) = '1') then -- STARTBIT erkannt
            PS2RXState <= RECEIVE;
            RxActive   <= '1';       
         end if;
      when RECEIVE =>
         if (RxTimeout = 500000) then     -- 10 ms
            PS2RXState <= IDLE;
         elsif (RxRegister(0) = '0') then -- Startbit ganz durchgeschoben?
            DataReady  <= '1';            -- SCANCODE empfangen
            RxData     <= RxRegister(8 downto 1);
            PS2RXState <= READY;
         end if;
      when READY =>                       -- warten, bis Daten abgeholt sind
         if (DataFetched='1') then
            PS2RXState <= IDLE;
            DataReady  <= '0';
            RxActive   <= '0';            
         end if;
      end case;
   end process;
end Behavioral;

Realisiert wurde dieses PS/2 Interface in Form eines 11 Bit breiten Schieberegisters, das zu Beginn im Zustand IDLE mit '1'en vorbelegt wird. Mit jeder fallenden Flanke am PS2-Clk wird dieses Schieberegister um 1 Bit von links her weitergeschoben. In das MSB wird dabei der Zustand des einsynchronisierten PS2-Data Pins eingetragen.
Nachdem ein Startbit erkannt wurde, wechselt der Zustand auf RECEIVE und es werden solange Bits eingeschoben, bis das Startbit das rechte Ende (Bit0) des Schieberegisters erreicht hat. Dann werden die Daten in das Pufferregister übernommen und im Zustand READY gewartet, bis die Daten abgeholt sind.

Zusammen mit dieser Testbench:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
 
ENTITY PS2_tb IS
END PS2_tb;
 
ARCHITECTURE behavior OF PS2_tb IS 
 
   procedure PS2Send( signal din :  in std_logic_vector(7 downto 0); 
                      signal ps2c : OUT std_logic;
                      signal ps2d : OUT std_logic) is
   variable parity : std_logic := '1';
   begin
      wait for 1 ns;
      ps2c  <= '1';
      ps2d  <= '1';
      wait for 5us;
      ps2d  <= '0';  -- startbit
      wait for 20us;
      ps2c  <= '0';
      wait for 40us;
      ps2c  <= '1';
      wait for 20us;
      
      parity := '1';
      for i in 0 to 7 loop
         ps2d <= din(i);
         if(din(i)='1') then 
            parity := not parity; 
         end if;
         wait for 20us;
         ps2c  <= '0';
         wait for 40us;
         ps2c  <= '1';
         wait for 20us;
      end loop;
      
      ps2d <= parity;  -- parity
      wait for 20us;
      ps2c  <= '0';
      wait for 40us;
      ps2c  <= '1';
      wait for 20us;
   
      ps2d <= '1';     -- stopbit
      wait for 20us;
      ps2c  <= '0';
      wait for 40us;
      ps2c  <= '1';
      wait for 20us;
   end procedure;
   
    -- Component Declaration for the Unit Under Test (UUT)
    COMPONENT PS2_Keyboard
    PORT(
         PS2_Data : IN  std_logic;
         PS2_Clk : IN  std_logic;
         RxData : OUT  std_logic_vector(7 downto 0);
         RxActive : OUT  std_logic;
         DataReady : OUT  std_logic;
         DataFetched : IN  std_logic;
         CLK : IN  std_logic
        );
    END COMPONENT;
    
   signal TxData : std_logic_vector(7 downto 0);

   --Inputs
   signal PS2_Data : std_logic := '1';
   signal PS2_Clk : std_logic := '1';
   signal DataFetched : std_logic := '0';
   signal CLK : std_logic := '0';

    --Outputs
   signal RxData : std_logic_vector(7 downto 0);
   signal RxActive : std_logic;
   signal DataReady : std_logic;

   -- Clock period definitions
   constant CLK_period : time := 20 ns; -- 50MHz
 
BEGIN
 
   -- Instantiate the Unit Under Test (UUT)
   uut: PS2_Keyboard PORT MAP (
          PS2_Data => PS2_Data,
          PS2_Clk => PS2_Clk,
          RxData => RxData,
          RxActive => RxActive,
          DataReady => DataReady,
          DataFetched => DataFetched,
          CLK => CLK
        );

   -- Clock process definitions
   CLK <= not CLK after CLK_period/2;

   -- Stimulus process
   DataFetched <= DataReady after 10 us; -- fake handshake
   
   stim_proc: process
   begin      
      -- hold reset state for 100 ns.
      wait for 100 ns;   
      
      TXData<=x"AA";
      PS2Send(TXData,PS2_Clk,PS2_Data);
      wait for 100 us;   

      TXData<=x"55";
      PS2Send(TXData,PS2_Clk,PS2_Data);
      wait for 100 us;   

      TXData<=x"11";
      PS2Send(TXData,PS2_Clk,PS2_Data);
      wait for 100 us;   

      TXData<=x"80";
      PS2Send(TXData,PS2_Clk,PS2_Data);
      wait for 100 us;   

      TXData<=x"01";
      PS2Send(TXData,PS2_Clk,PS2_Data);
      wait for 100 us;   

      TXData<=x"C3";
      PS2Send(TXData,PS2_Clk,PS2_Data);
      wait for 100 us;   
      
      wait;
   end process;
END;

ergibt sich dann folgende Waveform:

Waveform Simulation PS2 Interface

Hier die zusammengepackte Quelldatei und die passende Testbench:
Download PS2_Simplest.zip

In der zweiten Variante werden die Steuerkommandos (Break und Extended Keycode) in Flags umgewandelt:
Download PS2_Simple.zip

Die dritte Variante schliesslich erlaubt auch das Senden von Kommandos an die Tastatur. Damit können dann z.B. die LEDs auf der Tastatur an- und ausgeschaltet werden.
Download PS2_Full.zip

Wurzel in VHDL

nospam@example.com (Lothar Miller) — Tue, 03 Aug 2010 18:44:00 +0200

Eine Wurzel zu ziehen kann recht aufwendig sein. Erschwert wird das Ganze, wenn es in VHDL geschehen soll. Hier eine Gegenüberstellung des Ressourcenverbrauchs einer rein kombinatorischen Lösung verglichen mit einer sequentiellen getakteten Variante in einem Xilinx Spartan3 XC3S200 FPGA.

Hier als Bezugspunkt die parallel implementierte kombinatorische Lösung:

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

entity SQRT is
    Generic ( b  : natural range 4 to 32 := 16 ); -- Breite 
    Port ( value  : in   STD_LOGIC_VECTOR (15 downto 0);
           result : out  STD_LOGIC_VECTOR (7 downto 0));
end SQRT;

architecture Behave of SQRT is
begin
   process (value)
   variable vop  : unsigned(b-1 downto 0);  
   variable vres : unsigned(b-1 downto 0);  
   variable vone : unsigned(b-1 downto 0);  
   begin
      vone := to_unsigned(2**(b-2),b);
      vop  := unsigned(value);
      vres := (others=>'0'); 
      while (vone /= 0) loop
         if (vop >= vres+vone) then
            vop   := vop - (vres+vone);
            vres  := vres/2 + vone;
         else
            vres  := vres/2;
         end if;
         vone := vone/4;
      end loop;
      result <= std_logic_vector(vres(result'range));
   end process;
end;

Mit diesem Ansatz ergibt sich folgender Ressourcenbedarf:

So eine Wurzel braucht schon Platz...

Und jetzt zum Vergleich die Variante mit der getakteten Berechnung der Wurzel:

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

entity SQRT is
    Generic ( b  : natural range 4 to 32 := 16 ); -- Breite 
    Port ( clk    : in   STD_LOGIC;
           start  : in   STD_LOGIC;
           value  : in   STD_LOGIC_VECTOR (15 downto 0);
           result : out  STD_LOGIC_VECTOR (7 downto 0);
           busy   : out  STD_LOGIC);
end SQRT;

architecture Behave of SQRT is
signal op  : unsigned(b-1 downto 0); -- 
signal res : unsigned(b-1 downto 0); -- 
signal one : unsigned(b-1 downto 0); -- 

signal bits : integer range b downto 0;
type zustaende is (idle, shift, calc, done);
signal z : zustaende;

begin
   process begin
      wait until rising_edge(clk);
      case z is 
         when idle => 
            if (start='1') then 
               z <= shift; 
               busy <= '1';
            end if;
            one <= to_unsigned(2**(b-2),b);
            op  <= unsigned(value);
            res <= (others=>'0');

         when shift =>
            if (one > op) then
               one <= one/4;
            else
               z   <= calc;
            end if;

         when calc =>
            if (one /= 0) then
               if (op >= res+one) then
                  op   <= op - (res+one);
                  res  <= res/2 + one;
               else
                  res  <= res/2;
               end if;
               one <= one/4;
            else
               z    <= done;
            end if;
            
         when done =>
            busy <= '0';
            -- Handshake: wenn nötig warten, bis start='0'
            if (start='0') then 
               z <= idle; 
            end if;
      end case;
   end process;
   
   result <= std_logic_vector(res(result'range));
end;

Das Design Summary zeigt jetzt einen deutlich kleineren Ressourcenverbrauch an, wobei der Verbrauch an Slices insgesamt nicht mal so sehr viel höher ist:

... aber es geht auch wesentlich kompakter

Die Wurzelberechnung basiert auf diesem C Code:

int sqrt(int num) {
    int op = num;
    int res = 0;
    int one = 1 << 30; // The second-to-top bit is set: 1L<<30 for long

    // "one" starts at the highest power of four <= the argument.
    while (one > op)
        one >>= 2;
   
    while (one != 0) {
        if (op >= res + one) {
            op -= res + one;
            res += 2 * one;
        }
        res >>= 1;
        one >>= 2;
    }
    return res;
}

Breite eines Vektors berechnen (log2)

nospam@example.com (Lothar Miller) — Mon, 26 Apr 2010 10:29:54 +0200

Manchmal möchte man, dass sich die Wortbreite von Vektoren eines VHDL-Moduls z.B. über ein Generic einstellen lassen. Natürlich kann man das Ganze händisch machen:

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

entity CalcBW is
    Generic ( COUNT_MAX : natural  := 100;
              COUNT_WIDTH : natural := 7     -- 7 Bits sind nötig.
             );
    Port ( clk   : in  STD_LOGIC;
           count : out STD_LOGIC_VECTOR (31 downto 0) := (others=>'0')
          );
end CalcBW;

architecture Behavioral of CalcBW is
signal   cnt  : unsigned (COUNT_WIDTH-1 downto 0) := (others=>'0');
begin
  process begin
     wait until rising_edge(clk);
     if (cnt < COUNT_MAX) then  cnt <= cnt+1;
     else                       cnt <= (others=>'0'); 
     end if;
  end process;
  count(cnt'range) <= std_logic_vector(cnt);
end Behavioral;

Wesentlich eleganter ist aber, wenn hier z.B. nur der Zählerendwert übergeben und daraus in dem VHDL-Modul die nötige Vektorbreite berechnet wird. Das kann z.B. so gemacht werden:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
USE ieee.math_real.log2;
USE ieee.math_real.ceil;

entity CalcBW is
    Generic ( COUNT_MAX : natural := 100
             );
    Port ( clk   : in  STD_LOGIC;
           clear : in  STD_LOGIC;
           count : out STD_LOGIC_VECTOR (31 downto 0) := (others=>'0')
          );
end CalcBW;

architecture Behavioral of CalcBW is
constant COUNT_WIDTH : integer := INTEGER(CEIL(LOG2(REAL(COUNT_MAX+1))));
signal   cnt  : unsigned (COUNT_WIDTH-1 downto 0) := (others=>'0');
begin
  process begin
     wait until rising_edge(clk);
     if (cnt < COUNT_MAX) then  cnt <= cnt+1;
     else                       cnt <= (others=>'0'); 
     end if;
  end process;
  count(cnt'range) <= std_logic_vector(cnt);
end Behavioral;

Mit den in der MATH_REAL Bibliothek enthaltenen Funktionen LOG2 wird zuerst die tatsächliche Bitzahl ausgerechnet und mit CEIL auf das nächste Bit aufgerundet. So erhält man z.B. für die Werte 100 und 126 die nötigen 7 Bits, für einen Wert von 129 dann 8 Bits.

Asynchroner Reset

nospam@example.com (Lothar Miller) — Wed, 10 Mar 2010 18:15:00 +0100

Warum sollte man keinen (wirklich) asynchronen Reset in einem FPGA-Design verwenden?
Was ist denn eigentlich am asynchronen Reset so schlimm?

Es gibt mehrere Argumente gegen einen solchen Reset:

~~****************************************~~
Die Flipflops im FPGA (hier Xilinx) können in zwei Modi betrieben werden:
1) als asynchrones FF mit asynchronen Clear- und Preset-Eingängen
2) als synchrones FF mit synchronen Set- und Reset-Eingägen
Wenn die übliche Lehrbuch-VHDL-Schreibweise eines getakteten Prozesses verwendet wird:

process (reset,clk)
begin
   if reset = '0' then
       :
   elsif rising_edge(clk) then
       :
   end if;
end process;

dann muß die Synthese das FF asynchron mit Clear und Preset konfigurieren. Sie kann dann z.B. einen synchronen Zählerreset nicht auf den Reset-Eingang legen, weil ja gar kein solcher Eingang vorhanden ist. Der synchrone Zählerreset muß dann mit zusätzlicher Logik und mehr Verdrahtungsaufwand aufgebaut werden. Dies resultiert in einem erhöhten Ressourcenverbrauch und in einem langsameren Design, weil evtl. eine Logikebene mehr eingefügt werden muß. Hier finden sich ausführliche Erklärungen und Untersuchungen zum Thema:
http://www.mikrocontroller.net/topic/108606
http://www.mikrocontroller.net/topic/110266

~~****************************************~~
Wesentlich schlimmer als nur der zusätzliche Ressourcenverbrauch ist aber, dass ein asynchroner Reset zu undefiniertem Verhalten des Designs beim Verlassen des Resetzustands führen kann. Aufgrund unterschiedlicher Laufzeiten innerhalb des FPGAs sehen einzelne Register den Reset zeitverzögert weggehen. Wenn dann gerade ein Takt kommt, kann es sein, dass die eine Hälfte des FPGAs noch im Resetzustand ist, die andere Hälfte aber schon arbeitet.

Hier eine einfache Beschreibung mit einem Vektor (= ein paar Register), der im Reset auf einen definierten Wert gesetzt wird. Nachdem der Reset weggenommen ist, wird der Vektor mit jedem Takt getoggelt und gleichzeitig auf die beiden gültigen Werte verglichen. Ist der Wert des Vektors ungleich des Resetwerts oder seines Komplements, dann haben nicht alle FFs gleichzeitig den Resetzustand verlassen. Wären das jetzt keine Register eines simplen Vektors, sondern FFs einer State-Machine, dann hätte diese gleich nach dem Reset einen beliebigen Zustand eingenommen.

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

entity AsyncReset is
    Port ( clk : in  STD_LOGIC;
           rst    : in  STD_LOGIC;
           leds : out  STD_LOGIC_VECTOR(7 downto 0));
end AsyncReset;

architecture Behavioral of AsyncReset is
signal x : std_logic_vector(15 downto 0) := x"5555";
signal error : unsigned(7 downto 0) := x"00";
begin
   process (clk,rst) begin
      if rst='0' then                        -- asynchroner Reset low aktiv
         x <= x"AAAA";
      elsif rising_edge(clk) then
         x <= not x;                         -- alle Register toggeln         
         if (x/=x"5555" and x/=x"AAAA") then -- wenn ungleich:   
            error <= error+1;                -- Fehler mitzählen
            x <= x"AAAA";                    -- mit definierten Wert weitermachen
         end if;
      end if;
   end process;
   leds <= std_logic_vector(error);          -- auf LEDs ausgeben
end Behavioral;

Mit diesem Testaufbau kann mit ein paar LEDs und einem Taster oder Signalgenerator als Resetquelle das oben beschriebene Verhalten dargestellt werden: obwohl der Vektor x nur "AAAA" oder "5555" sein kann, zählt der Zähler error hoch.
Dies kann mit einer Verhaltensimulation niemals nachvollzogen und herausgefunden werden. Bestenfalls eine aufwendige Post-Route-Simulation würde bei geeigneter und unabhängiger Wahl des Takts in der Testbench evtl. Setup- und Hold-Zeit-Verletzungen anzeigen.

~~****************************************~~
In die selbe Ecke kommt man, wenn der asynchrone Reset dann noch kombinatorisch erzeugt wird:

process (a,b,c,clk)
begin
   if a='0' and b='1' and c='0' then
       :
   elsif rising_edge(clk) then
       :
   end if;
end process;

Hier ist wegen des Auftreten von Glitches bei der kombinatorischen Verknüpfung der Reset sehr anfällig. Es kann sein, dass z.B. in einer FSM nur einzelne FFs beeinflusst werden, und so die Zustandsmaschine ungültige Übergänge macht oder in undefinierten Zuständen landet.
Da hilft es auch nichts, sich selber Sand in die Augen zu streuen, und das Ganze zum Beispiel so zu schreiben:

process (reset,clk)
begin
   if reset = '1' then          -- sieht zwar schön aus...
       :
   elsif rising_edge(clk) then
       :
   end if;
end process;

reset <= not a and b and not c; -- ... ist aber trotzdem kombinatorisch

Graycode Umwandlung

nospam@example.com (Lothar Miller) — Sun, 17 Jan 2010 20:40:00 +0100

Der Graycode wird verwendet, wenn asynchron eine Positionsinformation übertragen werden soll (wie z.B. von einem Drehencoder), denn bei der Gray-Codierung wird bei einem Zählschritt zum nächsten immer nur 1 Bit umgeschaltet. Eine weitere Anwendung für den Graycode ist auch die Übertragung des Füllstands eines Fifos (also eigentlich die Position eines Zeigers im Fifo). Auch hier ist von Vorteil, dass die auswertende Logik höchstens um 1 Adressschritt falsch liegt.

Als Beispiel:
Ist die Zählstand des Fifos auf 7 (= binär 0111) und es wird weitergezählt auf 8 (=binär 1000), dann werden bei binärer Übertragung alle Bits umgeschaltet. Bei asynchroner Abtastung könnte jetzt kurzzeitig jede beliebige Kombination von 0000 bis 1111 auftauchen.
Bei einer Übertragung im Graycode sieht der Schritt von 7 nach 8 so aus: 0100 --> 1100. Hier wird also garantiert keine falsche Information generiert, sondern entweder der alte Wert (7) oder der neue Wert (8) erkannt.

Hier sind ein paar Umwandlungsroutinen, deren Grundlagen auf www.wisc-online.com schön erklärt sind.

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

entity Gray is
    Port ( gin  : in   STD_LOGIC_VECTOR (15 downto 0);
           bout : out  STD_LOGIC_VECTOR (15 downto 0);
           bin  : in   STD_LOGIC_VECTOR (15 downto 0);
           gout : out  STD_LOGIC_VECTOR (15 downto 0));
end Gray;

architecture Behavioral of Gray is
 signal gi   : unsigned(15 downto 0);
 signal go   : unsigned(15 downto 0);
 signal bi   : unsigned(15 downto 0);
 signal bo   : unsigned(15 downto 0);
 signal bop2 : unsigned(15 downto 0);
begin
  bi <= unsigned(bin);
  gi <= unsigned(gin);
  gout <= std_logic_vector(go);
  bout <= std_logic_vector(bo); -- alternativ bop2;
  
  Gray2BinaryPower2: process (gi) 
  variable temp : unsigned(15 downto 0);
  begin
     temp := gi;
     temp := temp xor shift_right(temp,8);
     temp := temp xor shift_right(temp,4);
     temp := temp xor shift_right(temp,2);
     temp := temp xor shift_right(temp,1);
     bop2 <= temp;
  end process;

  Gray2Binary: process (gi) 
  variable temp : unsigned(gi'left downto 0);
  begin
     temp := gi;
     for i in gi'left-1 downto 0 loop
        temp(i) := gi(i) xor temp(i+1);
     end loop;
     bo <= temp;
  end process;

  Binary2Gray: process (bi) 
  begin
     go <= bi xor '0'&bi(bi'left downto 1);
  end process;

end Behavioral;

Die Berechnung über Gray2BinaryPower2 funktioniert nur mit Busbreiten, die eine 2er Potenz sind, also 4, 8, 16... Zudem muß dann die Anzahl der shift-Operationen angepasst werden. Im obigen Beispiel ist eine Busbreite von 16 Bits verwendet, für einen 8 Bit Graycode entfiele der shift_right(temp,8).

Hier gibt es die VHDL-Datei und die passende Testbench gezippt: GrayBinary.zip

Wer sowas für C braucht, sollte mal dort schauen: Graycode-Umwandlung in C