mikrocontroller.net

Forum: FPGA, VHDL & Co. VHDL und abgeleiteter Takt


Autor: Heinrich H. (Firma: Ich.AG) (hhanff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe heute eine Frage zum Thema abgeleiteter Takt.
Im folgenden VHDL Modell wird intern durch einen Zähler ein langsamer 
Takt aus dem Systemtakt abgeleitet und dieser langsame Takt dann auf die 
Sensitivitätsliste und die rising_edge() Funktion des folgenden 
Prozesses gegeben.
library ieee;
use ieee.std_logic_1164. all;
use ieee.numeric_std. all;
entity design is
  port (
    clk, reset : in  std_logic;
    a, b       : in  std_logic;
    output     : out std_logic);
end design;

architecture derived_clk_arch of design is
  signal clk_cnt_s   : unsigned (3 downto 0);
  signal clk_derived : std_logic;

begin

  -- purpose: This process sets up a counter to derive
  --          the slow clock (clk_derived) from the
  --          global clock (clk)
  -- type   : sequential
  proc_generate_gated_clock : process (clk, reset)
  begin
    if (reset = '1') then
      clk_derived <= '0';
      clk_cnt_s   <= (others => '0');
    elsif rising_edge(clk) then
      if clk_cnt_s =  to_unsigned(7, clk_cnt_s'length) then
        clk_cnt_s   <= (others => '0');
        clk_derived <= not clk_derived;  -- toggle clock
      else
        clk_cnt_s <= clk_cnt_s + to_unsigned(1, clk_cnt_s'length);
      end if;
    end if;
  end process proc_generate_gated_clock;

  -- purpose: This process is sensitive to clk_derived
  -- type   : sequential
  proc_sensitive_to_clk_derived : process (clk_derived, reset) is
  begin  -- process proc_sensitive_to_clk_derived
    if reset = '1' then 
      output <= '0';
    elsif rising_edge(clk_derived) then  -- rising clock edge
      output <= a and b;
    end if;
  end process proc_sensitive_to_clk_derived;
  
end derived_clk_arch;


Ist ein solches abgeleitetes Signal in der Sensitivitätsliste eines 
Prozesses zulässig, oder handele ich mir so irgendwelche Nachteile 
bezüglich Clock Skew / Glitches ein.

Vorweg: Ich hätte im 1. Prozess ein Clock-Enable Signal erzeugt und 
dieses im 2. Prozess nach rising(edge) in einer if-Abfrage verwandt.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Henni H. schrieb:

> Vorweg: Ich hätte im 1. Prozess ein Clock-Enable Signal erzeugt und
> dieses im 2. Prozess nach rising(edge) in einer if-Abfrage verwandt.

Auf jeden Fall die bessere Variante. Der geteilte Clock aus dem obigen 
Beispiel wird zunächst nicht auf globale Clock-Netzwerke gebracht. Kann 
man eventuell mit einem speziellen Buffer hinbiegen, trotzdem nicht 
sinnvoll. Ein Clock Enable Signal, genau 1 Takt lang ist wesentlich 
besser. Dann bekommen alle FlipFlops den gleichen Takt aus dem globalen 
Taktnetzwerk.

Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dazu gibt es was in der Artikelsammlung:
http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD

Autor: Heinrich H. (Firma: Ich.AG) (hhanff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Sauron schrieb:
> Dazu gibt es was in der Artikelsammlung:
> http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD

Hatte ich auch schon gesehen. Mit anderen Worten: Bei der Art wie ich's 
oben mache sind Glitches eigentlich kein Problem mehr, aber Clock Skew 
ist hier problematisch.....

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Henni H. schrieb:
> Ist ein solches abgeleitetes Signal in der Sensitivitätsliste eines
> Prozesses zulässig,
Den Prozess an sich kümmert das überhaupt nicht. Das Ganze wird auch 
tatsächlich so verdrahtet, wie du es willst. Nur eben nicht auf einem 
Taktnetz.

> oder handele ich mir so irgendwelche Nachteile
> bezüglich Clock Skew / Glitches ein.
Skew ja, weil der Takt auf der "normalen" Verdrahtungsebene per 
Handschlag zu jedem beteiligten FF geführt wird.
Glitches nicht, denn der clk_derived stammt ja aus einem FF.

So etwas kannst du dir erlauben, wenn du auf dem FPGA räumlich begrenzt 
(!) einen 2. Takt hast. Dann ist die Verdrahtung noch recht kompakt und 
der Skew wird sich noch nicht allzu sehr auswirken...
Für einen globalen langsameren Takt solltest du aber die Taktmanager des 
FPGAs hernehmen (DCM, PLL...).

Autor: Heinrich H. (Firma: Ich.AG) (hhanff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> So etwas kannst du dir erlauben, wenn du auf dem FPGA räumlich begrenzt
> (!) einen 2. Takt hast. Dann ist die Verdrahtung noch recht kompakt und
> der Skew wird sich noch nicht allzu sehr auswirken...

... oder wenn ich einen Takt für ein FPGA-externes Modul erzeugen 
möchte, z.B. einen I2C Slave.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heinrich H. schrieb:
> ... oder wenn ich einen Takt für ein FPGA-externes Modul erzeugen
> möchte, z.B. einen I2C Slave.
Ein SCL? Das ist m.E. kein Takt, sondern ein simpler IO-Pin (zudem ein 
recht langsamer). Irgendwelche Delays dort werden mit anderen Mitteln 
angegangen...

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt ein paar Regeln zu Takten von digitalen Schaltungen. Dein Satz:

>Ich hätte im 1. Prozess ein Clock-Enable Signal erzeugt und
>dieses im 2. Prozess nach rising(edge) in einer if-Abfrage verwandt.

zeigt, dass Du die wichtigste dieser Regeln kennst (synchrones Design). 
Trotzdem, es gibt Fälle, in denen ein zweiter (dritter) Takt sinnvoll 
und richtig ist. So kann es sein, dass durch die Einführung von 
zusätzlichen Takten ein nennenswerter Teil der Schaltung weniger Strom 
verbraucht. Ob man den langsameren Takt mittels einer Logik oder einer 
PLL erzeugt, ist dabei egal. Moderne FPGA verfügen über mehrere 
Clock-Netzwerke, und die kann man schon nutzen. Allerdings muss man dann 
auch die Taktdomänen als unabhängig ansehen, also Synchronisationsstufen 
für Domänenübergänge einbauen. Nur dann ist man wirklich sicher und 
braucht sich um den Skew keine Sorgen mehr zu machen.

Autor: Weltbester FPGA Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist aber nur im Falle von ganzzahligen Verhältnissen egal, ob man es 
mit DCMs oder Teilern macht und dann gibt es (eigentlich) keine 
CLK-Übergänge.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.