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;

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

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 ?

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
?

Richtig Resetten:

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

und noch was:

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

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

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

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

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

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