VHDL und abgeleiteter Takt

Heinrich H. OP (Firma: Ich.AG) #1811251
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.

1
library ieee;

2
use ieee.std_logic_1164. all;

3
use ieee.numeric_std. all;

4
entity design is

5
  port (

6
    clk, reset : in  std_logic;

7
    a, b       : in  std_logic;

8
    output     : out std_logic);

9
end design;

10


11
architecture derived_clk_arch of design is

12
  signal clk_cnt_s   : unsigned (3 downto 0);

13
  signal clk_derived : std_logic;

14


15
begin

16


17
  -- purpose: This process sets up a counter to derive

18
  --          the slow clock (clk_derived) from the

19
  --          global clock (clk)

20
  -- type   : sequential

21
  proc_generate_gated_clock : process (clk, reset)

22
  begin

23
    if (reset = '1') then

24
      clk_derived <= '0';

25
      clk_cnt_s   <= (others => '0');

26
    elsif rising_edge(clk) then

27
      if clk_cnt_s =  to_unsigned(7, clk_cnt_s'length) then

28
        clk_cnt_s   <= (others => '0');

29
        clk_derived <= not clk_derived;  -- toggle clock

30
      else

31
        clk_cnt_s <= clk_cnt_s + to_unsigned(1, clk_cnt_s'length);

32
      end if;

33
    end if;

34
  end process proc_generate_gated_clock;

35


36
  -- purpose: This process is sensitive to clk_derived

37
  -- type   : sequential

38
  proc_sensitive_to_clk_derived : process (clk_derived, reset) is

39
  begin  -- process proc_sensitive_to_clk_derived

40
    if reset = '1' then 

41
      output <= '0';

42
    elsif rising_edge(clk_derived) then  -- rising clock edge

43
      output <= a and b;

44
    end if;

45
  end process proc_sensitive_to_clk_derived;

46
  

47
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Christian R. #1811264
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #1811307
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...).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Harald F. #1813724
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren