Erklärung dcm s3e

[Clemens M. (panko)]

hi,

Ich habe mir über das Karnevalswochenende vorgenommen mich des obigen 
Themas anzunehmen und da sind natürlich Fragen aufgetaucht.
Nachdem ich erst mal ziemlich dröge die xilinx pdf gewälzt habe, ist mir 
das zu bunt geworden und ich habe mir 'hands on' zu Herzen genommen. Mit 
folgendem code habe ich die 50 MHz vom Nexys 2 verdoppelt. Mit dem 
coregenerator eine single dcm ausgewählt und den CLK_FB als intern 
zurückgekoppelt eingestellt.
Ein nächster Schritt wird sicher sein, den Eingangstakt zu teilen oder 
einen krummen Takt zu bauen. Aber dafür muss ich das einfach besser 
verstehen.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity dcm_top is
    Port ( clk : in  STD_LOGIC;
           led : out  STD_LOGIC);
end dcm_top;

architecture Behavioral of dcm_top is
signal led_s : std_logic;
signal count_s : integer range 0 to 50000000/1 := 0;
signal clk_s : std_logic;
signal dcm_lock : std_logic;
component dcm
   port ( CLKIN_IN        : in    std_logic; 
          CLKIN_IBUFG_OUT : out   std_logic; 
          CLK2X_OUT       : out   std_logic; 
          LOCKED_OUT      : out   std_logic);
end component;


begin
  led <= led_s;
  --clk_s <= clk; --das dann an die dcm
  instantiate_dcm : dcm port map(
    CLKIN_IN => clk,   
      CLKIN_IBUFG_OUT => open,
      CLK2X_OUT => clk_s,
      LOCKED_OUT => dcm_lock );
  
  toggle : process begin
    wait until rising_edge(clk_s);
    if( dcm_lock = '1' ) then
      if(count_s < 50000000/1) then
        count_s <= count_s + 1;
      else
        count_s <= 0;
        led_s <= not led_s;
      end if;
    end if; --dcm_lock
  end process toggle;

end Behavioral;

Meine primäre Frage gilt dem Signal CLKIN_IBUFG_OUT, der auf open 
gesetzt sein kann. Kann als Frage, denn wozu zwingt der Coregenerator 
das Signal auf, wenn man es doch offen lässt?
Wie ich es verstanden habe, würde die Sache bei mir so laufen, daß der 
Eingangstakt (bei dem Nexys ja ein global clk Eingang) über einen global 
Buffer Input in den CLK_IN der dcm gelangt. Vom Ausgang dann über einen 
Buffer ins Taktnetzwerk. Die Rückkopplung auf CLK_FB hat die Komponente 
tatsächlich selber gemacht.
Meine Frage also: warum  CLKIN_IBUFG_OUT => open und warum ist CLK_IN 
mit clk zufrieden? Ich beziehe das auf ug331 S.69 wo es mir so scheint, 
als ob eben CLK_IN aus diesem Buffer kommen müsste.
Wäre der Eingangstakt eigentlich zusätzlich zu einer angeschlossenen dcm 
noch als clk im design verfügbar, oder müsste dafür eine zweite dcm 
angeschlossen werden?

EDIT: ich habe den logischen Weg gewählt und es einfach mal probiert - 
"Port <clk> has illegal connections. This port is connected to an input 
buffer and other components." hört sich so an, als ob das tatsächlich 
nicht geht. Macht auch Sinn. Eine zweite dcm an einen Buffer kann ich 
aber vermutlich generieren?

Verworrene Fragen, aber ich hoffe jemand versteht es, mir zu helfen.

Ach und zuletzt: wann müsste man eigentlich von Hand irgendwelche Buffer 
Zuweisungen machen? Das habe ich auf auto gelassen. Auto klingt einfach 
und funktionierend ;-)

[Gustl B. (-gb-)]

Diese Formatierung von port map, also mit den => Pfeilen sehe ich hier 
öfters und finde sie leicht verwirrend.

Du schreibst:

CLKIN_IN => clk,

Was bewirkt das? Müsste der Pfeil nicht die andere Richtung haben? Es 
wird doch den CLKIN_IN die clk zugewiesen und nicht anders herum?

Ich schreibe port map immer so:

instantiate_dcm : dcm port map(clk,open,clk_s,dcm_lock);

Dabei geht der erste Eintrag, also clk, an den ersten Eintrag der 
component Definition, also hier an CLKIN_IN. Und alle Weiterin der 
Reihenfolge nach.

Oder habe ich einen Denkfehler?

[Duke Scarring (Gast)]

Clemens M. schrieb:
> Kann als Frage, denn wozu zwingt der Coregenerator
> das Signal auf, wenn man es doch offen lässt?
Der Code, den der Coregenerator generiert, ist nicht immer logisch. 
(Aber fast immer verwirrend ;-)
Vielleicht ist das Signal drin, weil es in einer anderen Konfiguration 
gebraucht wird.

> Wäre der Eingangstakt eigentlich zusätzlich zu einer angeschlossenen dcm
> noch als clk im design verfügbar, oder müsste dafür eine zweite dcm
> angeschlossen werden?
Wenn ich mir UG331 [1], Seite 47, Bild 2-2 "Spartan-3E and Extended 
Spartan-3A Family Internal Quadrant-Based Clock Structure" anschaue, 
eher nicht. Du kannst aber aus einer DCM verschiedene Takte rausholen 
und im Design verwenden.

> Ach und zuletzt: wann müsste man eigentlich von Hand irgendwelche Buffer
> Zuweisungen machen?
Ich instanziiere die DCM immer per Hand. Da kommt ein IBUFG (oder 
IBUFGDS) an den Eingangstakt. Die restlichen Buffer (für DCM-Feedback 
und das interne Design) macht der Synthesizer (zumindest beim Spartan 6) 
automatisch.

Duke

[1] http://www.xilinx.com/support/documentation/user_guides/ug331.pdf

[Duke Scarring (Gast)]

Gustl Buheitel schrieb:
> Ich schreibe port map immer so:
>
> instantiate_dcm : dcm port map(clk,open,clk_s,dcm_lock);
Genau das vermeide ich wie die Pest.
Das mag zwar bei Code schreiben etwas Tipparbeit sparen, aber man muß 
sich merken, an welcher Position welches Signal steht.
Und die Reihenfolge hab ich längst vergessen, wenn ich nach einer 
gewissen Zeit mal wieder in den Code schauen muss.

Bei der ausführlichen Beschreibung ist die Reihenfolge egal und es passt 
auch noch ein Kommentar an jedes Signal:

    dcm_sp_i0: dcm_sp
        generic map (
            CLKDV_DIVIDE            => 2.0,     -- Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
                                                -- 7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
            CLKFX_MULTIPLY          => fx_mul,  -- Can be any integer from 2 to 32
            CLKFX_DIVIDE            => fx_div,  -- Can be any integer from 1 to 32
            CLKIN_DIVIDE_BY_2       => FALSE,   -- TRUE/FALSE to enable CLKIN divide by two feature
            CLKIN_PERIOD            => 20.0,    -- Specify period of input clock
            CLKOUT_PHASE_SHIFT      => "NONE",  -- Specify phase shift of "NONE", "FIXED" or "VARIABLE"
            CLK_FEEDBACK            => "1X",    -- Specify clock feedback of "NONE", "1X" or "2X"
            DESKEW_ADJUST           => "SYSTEM_SYNCHRONOUS", -- "SOURCE_SYNCHRONOUS", "SYSTEM_SYNCHRONOUS" or
                                                             -- an integer from 0 to 15
            DLL_FREQUENCY_MODE      => "LOW",   -- "HIGH" or "LOW" frequency mode for DLL
            DUTY_CYCLE_CORRECTION   => TRUE,    -- Duty cycle correction, TRUE or FALSE
            PHASE_SHIFT             =>    0,    -- Amount of fixed phase shift from -255 to 255
            STARTUP_WAIT            => TRUE     -- Delay configuration DONE until DCM_SP LOCK, TRUE/FALSE
        )
        port map (
            CLK0        => clk0,             -- 0 degree DCM CLK ouptput
            CLK90       => clk90,            -- 90 degree DCM CLK output
            CLK180      => clk180,           -- 180 degree DCM CLK output
            CLK270      => clk270,           -- 270 degree DCM CLK output
            CLK2X       => clk2x,            -- 2X DCM CLK output
            CLK2X180    => open,             -- 2X, 180 degree DCM CLK out
            CLKDV       => clkdv_int,        -- Divided DCM CLK out (CLKDV_DIVIDE)
            CLKFX       => clkfx_int,        -- DCM CLK synthesis out (M/D)
            CLKFX180    => open,             -- 180 degree CLK synthesis out
            LOCKED      => clk_ready,        -- DCM LOCK status output
            PSDONE      => psdone,           -- Dynamic phase adjust done output
            STATUS      => dcm_sp_i0_status, -- 8-bit DCM status bits output
            CLKFB       => clk0,             -- DCM clock feedback
            CLKIN       => clk,              -- Clock input (from IBUFG, BUFG or DCM)
            PSCLK       => clk,              -- Dynamic phase adjust clock input
            PSEN        => psen,             -- Dynamic phase adjust enable input
            PSINCDEC    => psincdec,         -- Dynamic phase adjust increment/decrement
            RST         => arst              -- DCM asynchronous reset input
        );
        psovfl     <= dcm_sp_i0_status(0);
        clkdv      <= clkdv_int;
        clkfx      <= clkfx_int;
        clk50      <= clk0;

> Oder habe ich einen Denkfehler?
In dem Fall: ja :-)

Duke

[Gustl B. (-gb-)]

Oh ok, Danke! Wieder was gelernt, also wird in der Schreibweise

CLKIN_IN => clk

tatsächlich entgegen der Pfeilrichtung zugewiesen, gut zu wissen.

[Clemens M. (panko)]

Weiß man denn, an welchem IBUFG der clk ankommt? Das kann vom pin 
unterschiedlich verdrahtet sein?
Ist die obige componente vielleicht da, daß man das nicht wissen muss?
Könnte ich  CLKIN_IN oder CLKIN_IBUFG_OUT aus dem generierten code 
rauswerfen?

[Duke Scarring (Gast)]

Clemens M. schrieb:
> Weiß man denn, an welchem IBUFG der clk ankommt?
Ja. Weil Du ja sagst, an welchem Pin der Takt anliegt. Wenn der Pin die 
GCLK-Funktion enthält, hängt da dran auch der entsprechende IBUFG.
 sein?

> Könnte ich  CLKIN_IN oder CLKIN_IBUFG_OUT aus dem generierten code
> rauswerfen?
Versuch macht kluch.
Ich denke schon. Der Core-generator erzeugt ja für die DCM-Sachen keine 
Netzlisten, sondern einigermaßen lesbaren VHDL (oder Verliog) Code.

Duke

[Clemens M. (panko)]

Ich probier mal weiter. War mir nicht klar geworden, daß zu einem pin 
ein fester Buffer gehört. Ich dachte die könnten auch irgendwie geroutet 
werden.

Wenn ich noch irgendwas überhaupt nicht verstehe pushe ich mich noch 
mal.

Danke einstweilen!

[Duke Scarring (Gast)]

Clemens M. schrieb:
> Ich probier mal weiter. War mir nicht klar geworden, daß zu einem pin
> ein fester Buffer gehört. Ich dachte die könnten auch irgendwie geroutet
> werden.
Prinzipiell ja. Aber für globale Netzwerke (wie den Takt) gibt es 
dedizierte Pins. Und die sollte man auch dafür nutzen.

Duke