Reset und Lock des DCM Cores

[Hans-Werner (Gast)]

Ich habe einen DCM Core erzeugt. Das Problem ist nun das Resetten des 
DCM Cores und das Warten auf das Locked-Signal.
Der DCM Core soll aus dem 50 MHz Takt des Spartan 3 AN Starter Kits 
einén 300 MHz Takt erzeugen. Habe das durch Simulation nachgeprüft.
Bei der Synthese erhalte ich die unten in den VHDL-Text eingefügten 
Fehlermeldungen. Es soll eine VGA-Ausgabe mit 1024x768 Pixeln erfolgen. 
Hierfür benötige ich einen 75 MHz Pixeltakt. Ziel ist die Nachbildung 
des mit dem Board mitgelieferten Fraktal Programmes in höherer Auflösung 
und in Farbe. Für die noch einzufügende Berechnung der Pixel habe ich 
einen 300 MHz Takt erzeugt, den ich für die Ausgabe auf 75 MHz 
runterteile.
Unten habe ich nur die für die Ausgabe verantwortliche Entity 
aufgeführt.
Es soll die Ausgabe mit 1024x768 Pixeln getestet werden.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity squares is
  port
  (
    clock : in std_logic; -- 50 MHz Clock
    rgb : out std_logic_vector(11 downto 0);
    hsync        : out std_logic;
      vsync        : out std_logic
  );
end squares;

architecture squares_rtl of squares is

  -- Liefert den 75 MHz Pixelclock für 1024x768 Pixel durch
  -- Teilung eines mittels DCM_Core erzeugten 300 MHz Clocks
  -- Der 300 MHz Clock soll für Pixelberechnungen genutzt werden
   component Clock75MHzEntity
  port
  (
    clock       : in std_logic;    -- 50 MHz
    reset       : in std_logic;
    locked      : out std_logic;
    ibufg_out   : out std_logic;
    Clock75MHz  : out std_logic
  );
  end component Clock75MHzEntity;

  -- Steuert die VGA Ausgabe
  component vga_controller
  port(
     enable        : in  std_logic;
     clock        : in   std_logic;
       hsync        : out std_logic;
       vsync        : out std_logic;
     hcount        : out std_logic_vector(10 downto 0);
     vcount        : out std_logic_vector(9 downto 0);
     blank         : out std_logic
     );
  end component vga_controller;
  
  signal clock75MHz : std_logic;
  signal reset : std_logic;
  signal locked : std_logic;
  signal ibufg_out : std_logic;
  
  signal red_out, green_out, blue_out : std_logic_vector(3 downto 0);
  signal hcount : std_logic_vector(10 downto 0); 
  signal vcount : std_logic_vector(9 downto 0);
  signal blank : std_logic;   
  signal enable_vga_controller : std_logic;
  type states is (init, work);
  signal state : states;
begin

  label1 : clock75MhzEntity
  port map
  (    
    clock => clock,
    reset => reset,
    locked => locked,
    -- Was fange ich mit ibufg_out an ? 
    -- Wozu ist das Signal gut ?
    ibufg_out => ibufg_out,
    Clock75mhz => clock75MHz
  );
  
   
  label2 : vga_controller
  port map
  (
    enable => enable_vga_controller,
    clock => clock75mhz,
    hsync => hsync,
    vsync => vsync,
    hcount => hcount,
    vcount => vcount,
    blank => blank
  );

-- Dieser Prozess verursacht folgende Fehler
-- Mapping all equations...
-- ERROR:Xst:2035 - Port <clock> has illegal connections. This port is connected to an input buffer and other components.
-- Input Buffer:
--   Port <I> of node <label1/Inst_DCM300MHzClock/CLKIN_IBUFG_INST> (IBUFG) in unit <squares>
-- Other Components:
--   Port <C> of node <state_0> (FDE) in unit <squares>
--   Port <C> of node <reset> (FDR) in unit <squares>
--   Port <C> of node <enable_vga_controller> (FDE) in unit <squares>

  -- Soll kurz den DCM Core resetten und auf das locked-Signal warten
   process (clock)
  begin
    if rising_edge(clock)
    then
      case state is
        -- Reset the DCM Core
        when init => reset <= '1';
                 state <= work;
        when work => reset <= '0';
                -- DCM Core has locked
                 if locked = '1'
                 then
                  enable_vga_controller <= '1';
                 else
                  enable_vga_controller <= '0';
                 end if;
      end case;
    end if;
  end process;

   -- Falls der DCM Core noch nicht eingelockt hat, können irgendwelche Glitches entstehen
  -- In diesem Fall erfolgt noch keine Ausgabe, da der VGAController nicht enabled ist
  -- Eine simple Farbausgabe
  process (Clock75MHz)
  begin
    if rising_edge(Clock75MHz)
    then
      rgb <= red_out & green_out & blue_out;
      if blank = '0'
      then
        for i in 0 to 3 loop
            red_out(i) <= hcount(3) and vcount(3);
            green_out(i) <= hcount(4) and vcount(4);
            blue_out(i) <= hcount(5) and vcount(5);
          end loop;
       else
        for i in 0 to 3 loop
          red_out(i) <= '0';
          green_out(i) <= '0';
          blue_out(i) <= '0';
        end loop;
       end if;
    end if;     
  end process;
  
  
end architecture squares_rtl;

[bko (Gast)]

Aus der Fehlremeldung gehr hervor das die DCM 
Netzliste"clock75MhzEntity"
schon einen "IBUFG" im Takteingang "clock" enthält.
Weil du den Eingang "clock" dann noch im einem Prozess
benutzt muss die XIlinx Synthese noch einen "IBUFG"
in dieses Netz einfügen.

Der Router (par) kann aber nicht zwei IBUFS auf einen
Pin legen !

Aber in deinem VHDL_Code steht schon die richtige
Frage zur Lösung dieses Problems:
ich zitiere: "-- Was fange ich mit ibufg_out an ?
                -- Wozu ist das Signal gut ?"

  (...)
 -- Soll kurz den DCM Core resetten und auf das locked-Signal warten
   process (clock)   <<<--- nimm hier doch mal das "ibufg_out"
  begin                      
    if rising_edge(clock) <<-- und auch hierda 
    then
  (...)

[Matthias G. (mgottke)]

>

> entity squares is
>   port
>   (
>     clock : in std_logic; -- 50 MHz Clock
>     :
>   );
> end squares;
>
>   label1 : clock75MhzEntity
>   port map
>   (
>     :
>     -- Was fange ich mit ibufg_out an ?
>     -- Wozu ist das Signal gut ?
>     ibufg_out => ibufg_out,
>     Clock75mhz => clock75MHz
>   );

> -- ERROR:Xst:2035 - Port <clock> has illegal connections. This port is
> connected to an input buffer and other components.
> -- Input Buffer:
> --   Port <I> of node <label1/Inst_DCM300MHzClock/CLKIN_IBUFG_INST>
> (IBUFG) in unit <squares>

Als Du Deinen Core "clock75MhzEntity" generiert hast, da hast Du 
ausgewählt, dass ein ibufg (das ist der Port-Eingangsbuffer der das 
Eingangssignal auf eine interne Clock-Leitung legt) im DCM enthalten 
sein soll. Das funtioniert soweit gut, wenn Du das eingehende 
Clocksignal der Entity nur an den generierten DCM legst ohne es noch 
irgendwo zu verwenden.
In Deinem Fall hat er nämlich einen Eingangsbuffer (vermutlich auch 
einen ibug) generiert, der an den Prozess der Reseterzeugung geleitet 
wird. Jetzt will er auf das interne Signal nochmal einen Eingangsbuffer 
routen, denn so stehts im DMC-Core drinn. Das geht aber nicht.

Du hat nun folgende zwei Möglichkeiten: Du generierst den DCM-Core ohne 
den ibufg, dann verschwindet auch das ibufg_out, oder Du führst den 
clock nur an die DCM und kannst deine 50MHz am ibufg_out (das ist dann 
nämlich der Ausgang den Eingangsbuffers) an den Reset-Prozess routen. Im 
RTL-Schaltplan ist das gut zu sehen, wenn Du bis dahin kommst. Die 
Simulation funktioniert deshalb, da ein ibufg nur das Eingangssignal 1:1 
weiter gibt. Die Simulation weiß ja nicht von dem physischen Aufbau der 
Buffer an den Ports.

Bei letzterer Möglichkeit könnte Dein Code so aussehen:

entity squares is
  port
  (
    clock : in std_logic; -- 50 MHz Clock
    :
  );
end squares;
:
  label1 : clock75MhzEntity
  port map
  (
    clock => clock,
      :
    ibufg_out => clock50MHz,
    Clock75mhz => clock75MHz
  );
:
  -- Soll kurz den DCM Core resetten und auf das locked-Signal warten
   process (clock50MHz)
  begin
    if rising_edge(clock50MHz)

Das Signal clock50MHz ist dabei nicht vom Reset oder Funktion der DCM 
abhängig.

Viel Erfolg
Matthias

PS: Ups, sehe gerade ein anderer war schon schneller mit der gleichen 
Antwort.

[Hans-Werner (Gast)]

Hallo bko

Nach deiner vorgeschlagengen Änderung erhalte ich folgendes:

WARNING:Route - CLK Net:ibufg_out is being routed on general routing 
resources. If you are trying to use local clocking
   techniques, evaluate the placement of the clock's source and loads to 
ensure it meets the guidelines for local
   clocking. Otherwise, consider placing this clock on a dedicated clock 
routing resource. For more information on clock
   routing resources, see the target architecture's user guide.

Einfach nicht beachten, oder ?

[Hans-Werner (Gast)]

Hallo Matthias

Als Du Deinen Core "clock75MhzEntity" generiert hast, da hast Du
ausgewählt, dass ein ibufg (das ist der Port-Eingangsbuffer der das
Eingangssignal auf eine interne Clock-Leitung legt) im DCM enthalten
sein soll.

Wann und wo habe ich das ausgewählt ?
Welches Menü, welcher Parameter, welcher Wert ?

Du hat nun folgende zwei Möglichkeiten: Du generierst den DCM-Core ohne
den ibufg, dann verschwindet auch das ibufg_out, oder Du führst den
clock nur an die DCM und kannst deine 50MHz am ibufg_out (das ist dann
nämlich der Ausgang den Eingangsbuffers) an den Reset-Prozess routen.

Wie generiere ich den DCM-Core ohne den ibufg ?
Habe es schon versucht, finde keine passende Einstellung.
Der DCM Core für die 300 MHz ist in die clock75MHzEntity eingebunden, da 
momentan die 300 MHz nur für die Generierung der 75MHz verwendet werden. 
Die 300MHz werden (momentan) noch nicht benutzt. Der clock_ibufg_out 
wird vom DCM Core weiter nach "oben" gereicht.
Wenn ich das richtig verstehe soll ich den "normalen" 50 MHz Takts des 
Boards nur an den Eingang des DCM Cores legen. Der ibufg_out liefert 
dann die 50 MHz für die restlichen Prozesse. Der DCM Core hat also nur 
einen Fan In von 1.
Verstehe nicht warum es dann funktionieren soll wenn ich den ibufg_out 
weglasse. Dann kann ich beliebig viele Prozesse an den 50MHz Clock legen 
?

[Matthias G. (mgottke)]

Hallo Hans-Werner

> Wann und wo habe ich das ausgewählt ?
> Welches Menü, welcher Parameter, welcher Wert ?

Das obige habe ich aus meiner Erinnerung geschrieben, da ich das gleich 
Problem mal vor so ca. einem Jahr hatte. Dort habe ich das Problem am 
RTL-Schaltplan erkannt. Ich habe gerade mal den coregen angeschmissen. 
Wenn ich das noch recht weis ist das der Parameter "CLKIN Source". Dort 
musst Du "Internal" verwenden.
Die Angabe bezieht sich auf die "Single DCM Version 9.204i"

Viel Erfolg
Matthias

[Gustl B. (-gb-)]

Vielen Dank! Ich hatte auch den Fehler:

ERROR:Xst:2035 - Port <clock> has illegal connections. This port is 
connected to an input buffer and other components.

-gb-

[Ralf (Gast)]

Richtig Resetten:

http://www.mikrocontroller.net/articles/Reset_f%C3%BCr_FPGA/CPLD

[Ralf (Gast)]

und noch was:

http://www.mikrocontroller.net/articles/VHDL#Synchroner_oder_asynchroner_Reset

[Duke Scarring (Gast)]

Ralf schrieb:
> Richtig Resetten:
Ich verwende statt diesem komischen SRL16 sowas:

    signal reset_shreg   : std_ulogic_vector(3 downto 0) := (others => '1');
    signal reset         : std_ulogic := '1';

    ...

    reset_generator_p: process
    begin
        wait until rising_edge( clk);
        reset_shreg <= reset_shreg(reset_shreg'left-1 downto 0) & '0';
        reset       <= reset_shreg(reset_shreg'left);
        if async_reset_pin = '1' then
            reset_shreg <= (others => '1');
        end if;
    end process;

Ralf schrieb:
> und noch was:
Kannst Du da evtl. noch ein paar Quellen mit angeben?
Es gab da m.E. mal was von Peter Alfke (Xilinx)...

Duke

[Sigi (Gast)]

@Duke Scarring,
>   ...
>   reset <= reset_shreg(reset_shreg'left);
>   ...

warum <reset> im Prozess und nicht Ausserhalb,
so hast du ein Takt Verzögerung und zusätzlich ein FF;
Ausserhalb aber nicht.

[Duke Scarring (Gast)]

Sigi schrieb:
> warum <reset> im Prozess und nicht Ausserhalb,
> so hast du ein Takt Verzögerung und zusätzlich ein FF;
> Ausserhalb aber nicht.
Das ist richtig.
Aber auf einen Takt früher oder später kommt es beim Reset nicht an. Ich 
habe schon mal ein MIG-Design gesehen, in dem das Reset-Shift_Register 
30 Bits lang war. Durch ein entsprechendes Fanout-Constraint wurde das 
Register dann zu einem Baum vergrößert. Wichtig ist ja (wenn man 
überhaupt einen Reset braucht), daß der überall gleichzeitg losgelassen 
wird.

Duke

[Manuel U. (muml)]

Wäre es allgemein nicht sinnvoller den einsynchronisierten externen 
Reset nur auf die DCMs zu legen und dann aus den kombinierten 
Lock-Signalen den eigentlichen globalen Reset abzuleiten (natürlich auch 
wieder einsynchronisiert). So könnte man sich Enable-Signale für 
einzelne Module sparen (bezgl. der Vermeidung von Spikes) und nur den 
globalen Reset verwenden.
So habe ich das in einem Referenzdesign von Inrevium gesehen.

Gruß, Manuel

[Sigi (Gast)]

@Manuel U.,

>Wäre es allgemein nicht sinnvoller den einsynchronisierten externen
>Reset nur auf die DCMs zu legen und dann aus den kombinierten
>Lock-Signalen den eigentlichen globalen Reset abzuleiten ...

so einfach ist es leider nicht. Sind Deine Komponenten von einer
stabilen/best. Clk abhängig, dann ist das locked-Signal eher als
Enable zu empfehlen (sonst laufen Deine Komponenten ja schon vor
einem Locked-Reset an und produzieren Müll).

Zum Locked: Je nach Familie ist Locked synchron zum Clkout etc.
Muss auch berücksichtigt werden. Da selten resettet wird, kann
man aber auch Glück haben :))

[Manuel U. (muml)]

> [...] Sind Deine Komponenten von einer
> stabilen/best. Clk abhängig, dann ist das locked-Signal eher als
> Enable zu empfehlen (sonst laufen Deine Komponenten ja schon vor
> einem Locked-Reset an und produzieren Müll).

Hi Sigi, da wären meine Komponenten aber doch noch im Reset-Zustand. Sie 
würden erst anlaufen, wenn der aus dem Locked-Signal abgeleitete Reset 
die Komponenten freigibt (und dann ist ja der Clock bereits 
stabil/locked).
Oder gibt es Fälle, in denen Komponenten nicht mehr im Reset-Zustand 
sein sollen, aber noch auf eine DCM warten müssen?

Grüße, Manuel

[Sigi (Gast)]

>.., da wären meine Komponenten aber doch noch im Reset-Zustand. Sie
>würden erst anlaufen, wenn der aus dem Locked-Signal abgeleitete Reset
>die Komponenten freigibt (und dann ist ja der Clock bereits
>stabil/locked).

Grob betrachtet hast du natürlich recht, ein Problem kann aber z.B.
dann auftreten, wenn im laufenden Betrieb ein Reset an die DCM
geschickt wird. Das Locked-Signal (uU nicht zu den Clk-Signalen
synchron) muss erst einsynchronisiert werden und kann damit zu
Verzögerungen führen, d.h. einzelne Komponenten laufen weiter etc.
... ist iA nicht so einfach zu Beantworten, wurde aber schon das
ein oder andere Mal im Xilinx-Forum thematisiert.

[Martin K. (mkmannheim)]

Ich würde sagen, dann muss jeder domain, die das locked verarbeitet 
zusätzlich auch noch den eigentlichen Reset mitnehmen, vorodern und 
ausweren.

Das Problem ist ja weniger der beginnde Reset, sondern der endende!