Lothar Miller

EMV-Optimiertes Schaltreglerlayout

nospam@example.com (Lothar Miller) — Thu, 22 Mar 2012 06:43:00 +0100

Bei einem Schaltreglerdesign (Abwärtswandler, Tiefsetzsteller, Step-Down-Converter, Buck-Converter oder Abwärtsregler) sind vorrangig zwei Strompfade interessant:

Beim Laden der Spule:
Phase 1: Eingangs-C -> Schalter -> Spule -> Ausgangs-C -> Eingangs-C
Beim Freilauf:
Phase 2: Ausgangs-C -> Freilaufdiode -> Spule -> Ausgangs-C

Wie immer, wenn Ströme fließen, gilt es auch hier, die Flächen und Widerstände dieser Stromschleifen möglichst klein zu halten.

Nehmen wir als Ausgangspunkt einen Schaltregler mit dem LM2676, der 24V auf 5V wandeln soll:

Schaltplan Abwärtswandler mit LM2676

Bauteile:

Nummer	Wert
U104	LM2676-ADJ
C131	47u/35V
C132	10n
C133	150u/10V
R131	1k
R132	3k16
V120	30BQ060
L101	33u UP3B-330

Hier sind diese beiden Ströme GELB (Phase 1, Laden) bzw. ORANGE (Phase 2, Leerlauf) eingezeichnet:

Ladestrom gelb / Freilaufstrom orange

Als ersten Versuch mache ich daraus ein einseitiges Layout:

Platinenlayout einseitig

Schön, könnte man sagen. Alle Bauteile hübsch kompakt untergebracht, das ist schon was. Nur die Leiterbahnquerschnitte sind suboptimal, die könnten noch deutlich breiter werden. Aber der Knackpunkt kommt hier: wenn ich die Stromschleifen aus dem Schaltplan ins Layout übertrage, sieht das so aus:

Stromverlauf im einseitigen Layout

Mit einer doppelseitigen Platine wäre dagegen dieses Layout möglich:

Zweiseitiges Layout

Und hier die Stromschleifen:

Strompfade im doppelseitigen Layout

Schon mit wenig Phantasie kann man erkennen, dass das zweite Layout kompakter und aufgeräumter aussieht. Die Schleifen sind räumlich kleiner, die Leiterbahnquerschnitte großzügig und die Leiterbahnverläufe kurz.

In der Praxis hat dann auch das erste Layout bei der EMV-Messung signifikant schlechtere Werte. Nun könnte jemand sagen: Für mich ist das uninteressant, es ist mir egal, ob mein Regler andere stört. Zu Denken sollte aber geben, dass das Ganze ja kein Sender, sondern ein Spannungswandler sein soll. Und die Energie, die in die Luft abgestrahlt wird, kann nicht mehr am Ausgang herauskommen

Als kleine Verschärfung des Stromkreis-Prinzips ist dann noch die Forderung, dass möglichst keine Änderungen des Stromflusses zwischen den beiden Strompfaden sein sollte.

Wenn diese beiden Strompfade berücksichtigt wurde, hat man das Design zu 90% in der Tasche. Aus EMV-Sicht kommt allerdings noch ein dritter dazu, der es richtig knacken lassen kann:
Übergang von Phase 2 nach Phase 1: Eingangs-C -> Schalter -> Diode -> Eingangs-C

Das ist der Recovery-Pfad. Dieser wird interessant beim Einschalten des Schalttransistors, wenn die Diode gerade (noch) leitet. Weil die Diode leitet, braucht sie ein paar Nanosekunden, bis sie sperrt und bildet solange einen Kurzschluss von der Eingangsspannung über den eingeschalteten Transistor über die leitende Diode nach Masse.

Hier in CYAN dieser Strompfad.

Der Recovery-Pfad: ein Kurzschluss für einige ns...

Weil insbesondere auch hier wegen des Kurzschlusses mit sehr steilen Stromwechselflanken gerechnet werden muß, sollte die Fläche dieses Pfades sehr klein ausfallen. Im Fall des ersten Layouts ist diese Forderung nicht im mindesten erfüllt, das Design wird ein Störsender sein:

Eine große Spule mit 1 Windung!

Im zweiten Layout ist dieser Pfad schön kurz:

Das sieht gut aus: ein kompakter Recovery-Pfad

Dieser kurze Pfad hat sich durch die Beachtung des Lade- und Freilaufstromkreises automatisch ergeben.

Zusammengefasst:
Idealerweise sind alle drei Strompfade (Laden, Freilauf und Recovery) möglichst kompakt. Bei Lade- und Freilaufstromkreis sollte zudem keine Änderung der Stromflussrichtung stattfinden.

Diese Strompfade wurden hier exemplarisch mit einem Step-Down-Wandler dargestellt. Sie sind aber in allen üblichen Schaltreglertopologien mehr oder weniger einfach zu finden. Beim Step-Up-Wandler geht der Recovery-Pfad z.B. über die Diode und den Schalttransistor und schließt so den Ausgangskondensator kurz.

Aber auch die Erfassung und Rückführung der Ausgangsspannung (Feedback) über R132 und R131 sollte genau angeschaut werden. Bei der ersten (schlechteren) Variante fließt der Laststrom vom Ausgangskondensator zum Eingangskondensator und beeinflusst auf dem Rückweg das GND-Potential von R131. So kann (auch abhängig vom Laststrom) die Ausgangsspannung nicht zuverlässig erfasst und geregelt werden. Ein unruhiges Reglerverhalten ist das Ergebnis.
Das ist beim zweilagigen Design besser: hier sind die Last- und Messstromkreise komplett voneinander getrennt. Das Ergebnis ist eine stabilere und rauschärmere Ausgangsspannung.

Auf jeden Fall sollte auch beachtet werden:
1. keine Leitung und auch keine Massefläche unter der Spule. Denn sonst koppelt das Magnetfeld der Spule in die Leiterbahn oder die Masse ein und induziert dort Störströme.

2. die Einspeisung der Spannung erfolgt direkt am Eingangskondensator (wie im Schaltplan eingezeichnet). Wird die Spannung z.B. am Schaltregler eingespeist, dann ist eine erhöhte Störstrahlung zu erwarten, denn der Schaltreglerpin wird ja (das liegt in der Natur der Sache) hochfrequenz ein- und ausgeschaltet.

3. die Auskopplung der geregelten Spannung erfolgt (wie auch der Anschluss des Feedback-Widerstandes R132) direkt am Ausgangskondesator. Das ist leider aus dem Schaltplan nicht so klar ersichtlich. Im beiden Layouts ist es aber korrekt ausgeführt.

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));

Xilinx ISE Step-by-Step

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

Die Xilinx ISE Entwicklungumgebung ist eigentlich nicht kompliziert, nur eben umfangreich. Leicht kann da ein Anfänger mal einen falschen Knopf drücken und verliert sich dann in der Vielfalt der Menüs...

Hier ein bebildertes Tutorial als Schritt-für-Schritt Anleitung, wie man

1) mit ISE ein Projekt aufsetzt,

2) den VHDL-Code für eine blinkende LED schreibt,

3) eine Testbench aufsetzt und den Code mit ISIM simuliert

4) die Pinzuordnung mit PlanAhead vornimmt

5) das Ganze implementiert und

6) mit Impact auf das FPGA lädt.

Zum PDF-Download (1,5MB) HIER clicken.

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.

-use_new_parser YES

nospam@example.com (Lothar Miller) — Wed, 31 Aug 2011 08:00:58 +0200

Leider kann die Xilinx-Synthese nur Arrays bis max. 2 Dimensionen. Der Xilinx SXT User Guide dazu:
XST supports multi-dimensional array types of up to two dimensions.
Das ist lästig, wenn man mehr Dimensionen bräuchte, und der Simulator das problemlos mitmacht...

Ein anderer Effekt ist das Initialisieren von Arrays, das in bestimmten Konstellationen einfach nicht klappt und mit einer Meldung wie
Default value is ignored for signal <my_array>
kommentiert wird. Und auch hier: die Simulation läuft tadellos, nur der Synthesizer schafft die Initialisierung nicht...

Glück gehabt: die Rettung naht verkleidet als undokumentierte Syntheseoption: -use_new_parser yes

Der ist zu finden in den Process-Properties, die mit einem Rechtsclick auf Synthesize-XST auswählbar sind. Dort muß dann Property display level: Advanced ausgewählt und in der letzten Zeile bei Other XST Command Line Options der Schalter -use_new_parser yes eingetragen werden.

Mit diesem Schalter ergibt sich dann eine wundersame Wandlung:

  -- XST13: OK  
  TYPE array_typ1 is array (natural range <>) of std_logic;
  TYPE array_typ2 is array (natural range <>, natural range <>) of std_logic;

  -- XST13 default: Fehler  / mit "-use_new_parser yes": OK
  TYPE array_typ3 is array (natural range <>, natural range <>, natural range <>) of std_logic;
  TYPE array_typ4 is array (natural range <>, natural range <>, natural range <>, natural range <>) of std_logic;
  TYPE array_typ5 is array (natural range <>, natural range <>, natural range <>, natural range <>, natural range <>) of std_logic;

Hier der komplette Quelltext dazu: PackageTypedef.vhd

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

Xilinx New Source

nospam@example.com (Lothar Miller) — Wed, 13 Apr 2011 09:19:00 +0200

Wenn mit Xilinx ISE ein neues Projekt oder Source-File angelegt wird, fragt der Wizzard nach EA und Bitbreiten. Nach einem Klick auf "DONE" wird dann ein neues Sourcefile angelegt, in dem aber ein riesiger Header und die alten Synopsys-Libs eingebunden sind:

--------------------------------------------------------
-- Company: 
-- Engineer: 
-- 
-- Create Date:    11:21:38 01/04/2010 
-- Design Name: 
-- Module Name:    Defaulttext - Behavioral 
-- Project Name: 
-- Target Devices: 
-- Tool versions: 
-- Description: 
--
-- Dependencies: 
--
-- Revision: 
-- Revision 0.01 - File Created
-- Additional Comments: 
--
--------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity Defaulttext is
    Port ( clk : in  STD_LOGIC;
           d : in  STD_LOGIC;
           o : out  STD_LOGIC);
end Defaulttext;

architecture Behavioral of Defaulttext is

begin


end Behavioral;

Das musste ich geändert haben:
Ich will als Standard-Lib die NUMERIC_STD einbinden, die UNISIM soll raus, und der Header etwas verschlankt werden.

ISE Version 13
Hier müssen dazu die beiden TCL-Scripte
C:\Xilinx\ISE_DS\ISE\data\projnav\scripts\dpm_sourceTasks.tcl
C:\Xilinx\ISE_DS\ISE\data\testbnch2.tcl
angepasst werden.

Im Script dpm_sourceTasks.tcl wird die Erzeugung eines neuen VHDL-Sourcecodemodul gesteuert. Hier muss die Prozedur proc dpm_sourceCreateVHDL geändert werden. Hier hat sich im Gegensatz zu früheren Versionen (siehe Beschreibung unten) das $_fs in ein $hFile geändert.

Im testbnch2.tcl wird die Generierung der Testbench gesteuert. Hier hat sich einiges getan, und ich musste erst mal die automatische Reset-Suche pensionieren. Auch die Taktgenerierung hat mir nicht gefallen, so dass sich da ebenso einiges geändert hat.

Damit die Suche nicht so schwer fällt, gibt es hier meine beiden Templates zum Download: IseTemplates.zip

ISE Versionen 9 bis 11
Etwa in der Mitte dieses TCL-Scripts
C:\Xilinx\data\projnav\scripts\dpm_sourceTasks.tcl
findet sich die Stelle, die angepasst werden muss:

      $_iHdlData GetPorts _portIter
      puts $_fs "----------------------------------------------------------"
      puts $_fs "-- Engineer: Lothar Miller"
      puts $_fs "-- "
      puts $_fs "-- Create Date:    $_ts "
      puts $_fs "-- Design Name: "
      puts $_fs "-- Module Name:    $_entityName - $_archName "
      puts $_fs "----------------------------------------------------------"
      puts $_fs "library IEEE;"
      puts $_fs "use IEEE.STD_LOGIC_1164.ALL;"
      puts $_fs "use IEEE.NUMERIC_STD.ALL;"
      puts $_fs ""

Nach der Änderung dieser Datei kommt beim Erzeugen eines neuen Projekts/Sourcefiles der gewünschte Customer-Header.

--------------------------------------------------------
-- Engineer: Lothar Miller
-- 
-- Create Date:    11:21:38 01/04/2010 
-- Design Name: 
-- Module Name:    Defaulttext - Behavioral 
--------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Defaulttext is
    Port ( clk : in  STD_LOGIC;
           d : in  STD_LOGIC;
           o : out  STD_LOGIC);
end Defaulttext;

architecture Behavioral of Defaulttext is

begin


end Behavioral;

Für die Voreinstellungen beim Erstellen der Simulationsdatei gilt der Pfad

C:\Xilinx\data\testbnch2.tft

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