In den FPGAs sind PLLS ein Standard für zwei Gründe:
– Um Pfadverzögerungen zu Kompensieren (Bsp. 2)
– Um andere Taktfrequenzen zu erhalten (Bsp. 1)
Neuer Takt
Viele Protokole besitzen ihre eigene Takt-Frequenz. Daher braucht es einige Takte innerhalb eines FPGAs
f_out = (f_in * m) / n // m wird multipliziert, n und g dividiert
Kompensation Verzögerung
Werte im Feedback Pfad v1= 3 ns schieben CLK_IN nach vorne, Werte beim Ausgang v2 = 8 ns verzögern CLK_IN.
Bsp Kompensation
Ausgangslage: Durch Flip-Flop-Verzögerung oder Pfadverzögerung und IO-Verzögerung kommt data 5ns später als CLK_50 beim SRAM an.
1.) Entweder führt man ein PLL in den data-Pfad ein,
dann muss der PLL den CLK_50 vorverlegenv1 = 5 ns
um die Verspätung zu kompensieren,
oder (siehe Bild)
2.) man verzögert den CLK_50 zum SRAM mit genau der Verzögerung,
die der data-Pfad hat v2 = 5 ns . Dann kommt CLK RAM „gleich verzögert “
wie data beim SRAM an.
PLL Rechenbeispiel mit Takterzeugung und Verzögerung
Über den USB-Blaster kann bei altera mit dem Programm SignalTap der Verlauf der internen Signale sichtbar gemacht werden. Der Vorteil zu einem Logic Analyser ist, dass SignalTap intern funktioniert und damit die Signale nicht zuerst nach aussen geführt werden müssen.
Die Screenshots sind von der Präsentation: de.slideshare.net/… quartus tutorial signaltap
Die Signale werden durch Doppelklick bei „node“ ausgewählt. Mit einem * erhält man alle Signale.
Der Tackt muss angegeben werden:
clock setzen
Nach dem Clk sind die Grundeinstellungen wichtig. Kleine FPGAs haben nicht viel Speicher und zeichnen deshalb nur wenig Signale auf…
Am Schluss wird die Konfiguration ins FPGA geladen. (Zuvor sollte man das Projekt .sof bereits einmal hinuntergealden haben.)
Die Signale erscheinen so:
Will man ein Signal detaillierter anschauen, so geht dies so:
– Exportier werden kann nur eine Postscript-Datei <datei.ps>
– Diese wird dann per Konsole mit ps2pdf <datei.ps> in ein pdf gewandelt
Einstellung zur schwarz-weiss Ausgabe
Im Questsim: File/Page_Setup…
– Papter size: A4, Cursor on/off, Grid on/off, Color: B&W, Scaling: Fit to 1 page
File/Write Postscript
– Hacken bei: File name: Pfad und Name angeben
– Signal Selection: Current view (oder All signals oder Selected)
– Time Range: Current view oder Full Range oder Custom
In VHDL gehört die Simulation (schreiben einer Testbench) fix zur Entwicklung dazu. Die Testbench ist in VHDL geschrieben und liegt im Ordner vhdl. Achtung: Nie in Quartus-Projekt einbinden. Quartus kann waits und asserts nicht kompilieren.
Ausgeführt (kompiliert) wird die Testbench über die Konsole vom Simlationsprogramm (per Script):
Simulationsprogramm
Bei altera ist questasim die Vollversion des Simulationsprogramms.
Einbinden der Bibliothek
Ablage
Im Projektordner wird ein Ordner simulation angelegt. In diesen Ordner kommt – über das Einbinden der Bibliothek work – der Unterordner Work.
In diesen legt man das Script zum Starten der Simulation compile.do .
Testbench Datei
– die entity hat keine Ports. Sie besteht nur aus Signalen
– die IOs jeder Componente werden an Signale gehängt
– die Testsignale (stimuli) werden in processen gesetzt
– Signale dürfen nur Signalen zugewiesen werden
– die Tests (Vergleichsergebnis von Signalen)
. finden in den Prozessen statt. Die Processe haben keine Klammern
– stimuli: sind selbst entworfene Signalverläufe
– waits: bestimmen die zeitliche Abfolge unter den
. Signalen
– reports: geben die Resultat aus
. (Konsole oder in File (textbasiertes Testing).
– clk: der clk muss simuliert (erzeugt) werden.
. Dies geschieht durch einen eigenen clk-prozess
clk_generator : process
begin
. wait for 1 * clk_halfp;
. clock_sig <= '1';
. wait for 1 * clk_halfp;
. clock_sig <= '0';
end process;
entity ram_tb is
end ram_tb;
architecture struct of ram_tb is
---------------------------------------------------------------
-- component declaration
---------------------------------------------------------------
component ram
port(
. address : IN STD_LOGIC_VECTOR (15 DOWNTO 0);
. clock : IN STD_LOGIC := '1';
. data : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
. wren : IN STD_LOGIC ;
. q : OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
);
end component;
---------------------------------------------------------------
-- signal instantiation
---------------------------------------------------------------
signal address_sig : STD_LOGIC_VECTOR (15 DOWNTO 0);
signal clock_sig : STD_LOGIC := '1';
signal data_sig : STD_LOGIC_VECTOR (7 DOWNTO 0);
signal wren_sig : STD_LOGIC ;
signal q_sig : STD_LOGIC_VECTOR (7 DOWNTO 0);
signal clk_halfp : time := 10 ns;
signal clk_period : time := 20 ns;
-- eventuell constanten mit resultaten definieren
begin
---------------------------------------------------------------
-- component instantiation
---------------------------------------------------------------
inst_1 : ram
port map (
. address => address_sig,
. clock => clock_sig,
. data => data_sig,
. wren => wren_sig,
. q => q_sig
);
---------------------------------------------------------------
-- Set stimuli in process with timing
---------------------------------------------------------------
test_1: process(all)
. -- Initialwerte setzen
. -- Signale an Komponenten legen (Stimulation)
. -- Warten
. -- Signal von Ausgang Komponente abfangen
. -- Vergleichen des Outputs mit Erwartung
. -- Ausgabe Testresulat
end; -- test_1
end; -- architektur
Wechselt das Inputsignal eines Flip-Flops zur falschen Zeit, ist das Ausgangssignal unsicher. Im besten Fall nimmt der Ausgang dann einen selbst gewählten Wert an (Q ode Q), im schlechten Fall „hängt“ sich das Flip-Flop „auf“ und toggelt permanent zwischen Q und Q.
Kritische Zeit beim Eingang
t_setup: so lange müssen Daten vor dem Clock da sein
. (3 bis 12 ns. Cyclone IV: 8 – 10 ns)
t_hold: so lange müssen Daten nach dem Clock anliegen (0 bis 1 ns)
. Diese Zeit muss grösser sein, als die Durchlaufverzögerung des FF.
t_pd: Durchlaufverzögerung: Zeit der Daten, bis sie am Ausgang anliegen.
Treffen neue Daten vor der minimalen Haltezeit ein, so ist unklar, was am Ausgang anliegt.
Ursache für das Nichteinhalten der t_su
Die Clk-Frequenz hängt vom längsten Verzögerungspfad ab. Ist der eingestellte CLK schneller, so kommt bei mindestens einem FF die Daten zu spät an. Die t_su kann dort nicht eingehalten werden.
Warum ist (nur ein) FF bereits ein Problem?
Weil das FF im schlimmsten Fall zu Toggeln beginnt. Dadurch erhalten alle nachfolgenden FF toggelnde Signale und die ganze Linie ist unbrauchbar.
Ein metastabiles FF zieht die anderen FF mit sich.
Durchlaufverzögerung (propagation delay)
Ein Signal am Eingang erscheint (theortisch) direkt Ausgang. Real jedoch hat jedes Signal eine Gatter- oder Flip-Flop-Verzögerung.
Verzögerung bei Logik
Jedes Gatter braucht eine kurze Zeit, um die Logik auszugeben. Diese nennt man Gatter-Verzögerung bzw. auf englisch progagation delay.
Nimmt man pro Gatter eine Verzögerung von 5 ns, so hat man nach 3 Gattern einen Pfad von 15 ns.
Verzögerung bei Flip-Flop Auch jedes Flip-Flop hat nach dem Clk noch eine Verzögerung. Das Signal liegt nicht unmittelbar nach dem Clk am Ausgang an.
Die Verzögerung (t_pd) darf nicht zu lange sein, weil sonst das Signal nicht mehr anliegt. Die Regel ist, dass die Verzögerung küzer sein muss, als die minimale Haltezeit des Signal (t_hold). Bei den Flip-Flops muss zusätzlich noch die Zeit vor dem Clock berücksichtig werden (t_setup). Mehr dazu unter Metastabilität.
Das Timing (einhalten der Setup- und Hold-Zeit) ist eine Fehlerquelle für ungültige Daten.
Bsp. eines Schreibe-Zyklus
– Ein neuer Zylkus beginnt bei der fallenden Flanke Da Daten leicht verzögert ankommen, beginnt der neue Zyklus
nach der fallenden Flanke. Die Verzögerung darf nicht so gross sein,
dass die setup Zeit verletzt wird.
(t_setup = Zeit, in der Daten vor CLK anliegen müssen)
– Ausführen des Befehls bei steigender Flanke
Hier ist es ein Schreibbefehl. Auch der Lesebefehl wird bei steigender Flanke
ausgeführt.
Der Befehl wird leicht verzögert ausgeführt.
Um den Befehl recht auszuführen, darf die Hold Zeit nicht verletzt werden.
(t_hold = Zeit, in der die Daten nach dem CLK noch anliegen müssen)
Bereits kurz nach der ausführenden Flanke sind die Daten wieder Weg und der neue Zyklus beginnt.
FPGA
Speicher haben intern einen Takt. Dadurch entfällt das Timingproblem.