VHDL und abgeleiteter Takt

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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.

[Christian R. (supachris)]

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.

[Michael S. (Firma: www.das-labor.org) (laborsauron)]

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

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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.....

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[Harald F. (hfl)]

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.

[Weltbester FPGA Pongo (Gast)]

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.