Lothar Miller

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:

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:

Als ersten Versuch mache ich daraus ein einseitiges Layout:

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:

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

Und hier die Stromschleifen:

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.

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:

Im zweiten Layout ist dieser Pfad schön kurz:

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.

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

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.

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.