Anfänger hat Probleme mit parallelen Prozessen

[Norbert (Gast)]

Hallo,

sicherlich mache ich hier irgendeinen dummen Anfängerfehler aber 
momentan komme ich nicht weiter und weiß auch nicht warum. Im folgenden 
VHDL Code werden per DCM zwei verschiedene Taktsignale (100MHz und 
200MHz) erzeugt. Diese werden in zwei parallelen Prozessen 
heruntergeteilt und sollen zwei LEDs mit jeweils unterschiedlichem Takt 
blinken lassen.

Das Seltsame ist, kommentiere ich einen der beiden Prozesse aus und 
synthetisiere das Ganze, läuft es wie erwartet. D.h. die jeweils 
angesteuerte LED blinkt im erwarteten Takt. Synthetisiere ich das Ganze 
jedoch mit beiden Prozessen funktioniert nichts. Es kommen auch keine 
Warnungen oder Fehlermeldungen.

Hier gibts sicherlich Fachleute, die mein Problem auf den ersten Blick 
erkennen und mir helfen können. Vielen Dank schon mal dafür.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Blinkled is
  port(clk:in std_logic;
      rst:in std_logic;
      Led1:out std_logic;
      Led2:out std_logic
      );
end Blinkled;

architecture Behavioral of Blinkled is

signal c1 : integer range 0 to 49999999 := 0; -- 0,5s bei 100MHz fosc
signal x1 : std_logic:= '0';
signal c2 : integer range 0 to 49999999 := 0; -- 0,25s bei 200MHz fosc
signal x2 : std_logic:= '0';
signal clk1: std_logic; 
signal clk2: std_logic; 

component mod_dcm
port
 (-- Clock in ports
  CLK_IN1           : in     std_logic;
  -- Clock out ports
  CLK_OUT1          : out    std_logic;
  CLK_OUT2          : out    std_logic;
  -- Status and control signals
  RESET             : in     std_logic
 );
end component;

begin
inst_mod_dcm: mod_dcm
  port map
   (-- Clock in ports
    CLK_IN1 => clk,
    -- Clock out ports
    CLK_OUT1 => clk1,
    CLK_OUT2 => clk2,
    -- Status and control signals
    RESET  => rst);
   
   process begin
      wait until rising_edge(clk1); -- warten bis zum nächsten Takt 
      if (c1<49999999) then         -- 0…49999999 = 100000000 Takte = 1/2 Sekunde bei 100MHz 
          c1 <= c1+1;                -- wenn kleiner: weiterzählen 
      else                         -- wenn Zählerende erreicht: 
          c1 <= 0;                  -- Zähler zurücksetzen 
          x1 <= not x1;              -- und Signal x1 togglen 
      end if; 
   end process; 
   Led1 <= x1;                       -- Signal x1 an Led1 ausgeben  

   process begin
      wait until rising_edge(clk2); -- warten bis zum nächsten Takt 
      if (c2<49999999) then         -- 0…49999999 = 100000000 Takte = 1/4 Sekunde bei 200MHz 
          c2 <= c2+1;                -- wenn kleiner: weiterzählen 
      else                         -- wenn Zählerende erreicht: 
          c2 <= 0;                  -- Zähler zurücksetzen 
          x2 <= not x2;              -- und Signal x2 togglen 
      end if; 
   end process; 
   Led2 <= x2;                       -- Signal x2 an Led2 ausgeben  
  
end Behavioral;

Vielen Dank schon mal für Eure Hilfe!

Beste Grüße,

Norbert

[V. B. (dr-robotnik)]

Ich bin jetzt nicht so der VHDL-Spezi aber musst Du deinen Prozessen 
nicht eindeutige Namen geben?

Also

blink_led_1: process
begin
...

end process;

und

blink_led_2: process
begin

...

end process;

[V. B. (dr-robotnik)]

Und ist ne sensitivity list in diesem fall nicht auch notwendig?

[Norbert (Gast)]

V. Baumann schrieb:
> Ich bin jetzt nicht so der VHDL-Spezi aber musst Du deinen Prozessen
> nicht eindeutige Namen geben?

Ich weiß nicht. Ich glaube eigentlich nicht. Auf der Website von Lothar 
Miller gibts Beispiele bei denen das nicht so ist. Siehe hier z.B. die 
Stoppuhr in VHDL:

http://www.lothar-miller.de/s9y/

[Norbert (Gast)]

V. Baumann schrieb:
> Und ist ne sensitivity list in diesem fall nicht auch notwendig?

Auf diese Frage hat mir der Synthesizer schon die passende Antwort 
gegeben:

"Process cannot have both a wait statement and a sensitivity list."

Daher denke ich mal, dass das so ok ist. Oder etwa nicht?

[Klaus (Gast)]

V. Baumann schrieb:
> Ich bin jetzt nicht so der VHDL-Spezi aber

... muss unbedingt meinen Senf dazu geben. OK, zu erkennen, dass man 
selber keine Ahnung hat ist schonmal eine wichtige Fähigkeit. Bravo! 
Zweiter Schritt: Überlegen, was sich daraus für Konsequenzen ergeben. 
Wie zum Beispiel, einfach mal die Klappe halten, wenn man keine Ahnung 
hat. Das übst du jetzt besser nochmal.

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

Man darf ruhig mal Raten, auch wenn das nicht von Rat kommt. Das Problem 
hier hat allerdings nichts mit VHDL an sich zu tun...

Wenn die beiden Takte unabhängig voneinander funktionieren, dann wäre es 
interessant, ob die Leds auch blinken, wenn auf beide Takte der selbe 
DCM Ausgang gelegt wird. Wie sieht die DCM Instantiierung aus? Was 
passiert, wenn du den Reset anlegst? Mit welchem Takt gehst du in den 
DCM rein? Kannst du dir mal das locked Siganl des DCM anzeigen?

[V. B. (dr-robotnik)]

Klaus schrieb:
> V. Baumann schrieb:
>> Ich bin jetzt nicht so der VHDL-Spezi aber
>
> ... muss unbedingt meinen Senf dazu geben. OK, zu erkennen, dass man
> selber keine Ahnung hat ist schonmal eine wichtige Fähigkeit. Bravo!
> Zweiter Schritt: Überlegen, was sich daraus für Konsequenzen ergeben.
> Wie zum Beispiel, einfach mal die Klappe halten, wenn man keine Ahnung
> hat. Das übst du jetzt besser nochmal.

Äh.. hallo? Was ist dir denn über die Leber gelaufen?? Man kann doch mal 
eine Vermutung äußern! Und ich habe sie ja extra als Frage formuliert, 
weil ich mir nicht sicher bin und man gerne darüber diskutieren kann - 
also trag' doch lieber was Konstruktives bei!

[Norbert (Gast)]

Hallo Lothar

> Wenn die beiden Takte unabhängig voneinander funktionieren, dann wäre es
> interessant, ob die Leds auch blinken, wenn auf beide Takte der selbe
> DCM Ausgang gelegt wird.

Diese Frage verstehe ich nicht so ganz. Bei dem Port-Mapping kann ich 
jeweils nur 1:1 Zuweisungen machen. Wenn ich bei beiden Prozessen "wait 
until rising_edge(clk1)" eintrage (wovon ich annehme, dass es das ist, 
was Du meinst), habe ich das selbe Ergebnis, es funktioniert nicht.

>Wie sieht die DCM Instantiierung aus?

Ich füge mal das Listing des funktionalen Modells des DCM ganz unten 
ein. Dir sagt das sicherlich mehr als einem Anfänger wie mir.

>Was passiert, wenn du den Reset anlegst?

Seltsamerweise nichts. D.h. wenn ich einen der Prozesse auskommentiere 
und dann das Ganze synthetisiere und in mein Board lade, blinkt ja 
zumindest eine LED, so wie gewünscht. Ich habe mal folgendes ergänzt ...

port
 (
...
  -- Status and control signals
  RESET             : in     std_logic := '1'
 );

... um RESET zwangsweise auf '1' (oder '0') zu legen aber es macht 
keinen Unterschied. Die LED blinkt munter weiter. Das erstaunt mich 
jetzt aber.

>Mit welchem Takt gehst du in den DCM rein?

Mit dem Systemtakt (100MHz), gepuffert.

>Kannst du dir mal das locked Siganl des DCM anzeigen?

Uff, jetzt übersteigt es meine Kenntnisse und Fähigkeiten. Du meinst, 
mit Chipscope oder so? Ich weiß nicht, ob ich das mit der kostenlosen 
Webpack-Version überhaupt nutzen kann.

Also hier jedenfalls mal das Listing des funktionalen DCM Modells. 
Vielleicht sieht man ja hier welchen Unsinn ich verbockt habe ;-)

------------------------------------------------------------------------------
-- "Output    Output      Phase     Duty      Pk-to-Pk        Phase"
-- "Clock    Freq (MHz) (degrees) Cycle (%) Jitter (ps)  Error (ps)"
------------------------------------------------------------------------------
-- CLK_OUT1___100.000______0.000______50.0______200.000____150.000
-- CLK_OUT2___200.000______0.000______50.0______300.000____150.000
--
------------------------------------------------------------------------------
-- "Input Clock   Freq (MHz)    Input Jitter (UI)"
------------------------------------------------------------------------------
-- __primary_________100.000____________0.010

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

library unisim;
use unisim.vcomponents.all;

entity mod_dcm is
port
 (-- Clock in ports
  CLK_IN1           : in     std_logic;
  -- Clock out ports
  CLK_OUT1          : out    std_logic;
  CLK_OUT2          : out    std_logic;
  -- Status and control signals
  RESET             : in     std_logic
 );
end mod_dcm;

architecture xilinx of mod_dcm is
  attribute CORE_GENERATION_INFO : string;
  attribute CORE_GENERATION_INFO of xilinx : architecture is "mod_dcm,clk_wiz_v3_6,{component_name=mod_dcm,use_phase_alignment=true,use_min_o_jitter=false,use_max_i_jitter=false,use_dyn_phase_shift=false,use_inclk_switchover=false,use_dyn_reconfig=false,feedback_source=FDBK_AUTO,primtype_sel=DCM_SP,num_out_clk=2,clkin1_period=10.0,clkin2_period=10.0,use_power_down=false,use_reset=true,use_locked=false,use_inclk_stopped=false,use_status=false,use_freeze=false,use_clk_valid=false,feedback_type=SINGLE,clock_mgr_type=AUTO,manual_override=false}";
    -- Input clock buffering / unused connectors
  signal clkin1            : std_logic;
  -- Output clock buffering
  signal clk_out1_internal : std_logic;
  signal clkfb             : std_logic;
  signal clk0              : std_logic;
  signal clk2x             : std_logic;
  signal clkfbout          : std_logic;
  signal locked_internal   : std_logic;
  signal status_internal   : std_logic_vector(7 downto 0);
begin


  -- Input buffering
  --------------------------------------
  clkin1_buf : IBUFG
  port map
   (O => clkin1,
    I => CLK_IN1);


  -- Clocking primitive
  --------------------------------------
  
  -- Instantiation of the DCM primitive
  --    * Unused inputs are tied off
  --    * Unused outputs are labeled unused
  dcm_sp_inst: DCM_SP
  generic map
   (CLKDV_DIVIDE          => 2.000,
    CLKFX_DIVIDE          => 1,
    CLKFX_MULTIPLY        => 4,
    CLKIN_DIVIDE_BY_2     => FALSE,
    CLKIN_PERIOD          => 10.0,
    CLKOUT_PHASE_SHIFT    => "NONE",
    CLK_FEEDBACK          => "1X",
    DESKEW_ADJUST         => "SYSTEM_SYNCHRONOUS",
    PHASE_SHIFT           => 0,
    STARTUP_WAIT          => FALSE)
  port map
   -- Input clock
   (CLKIN                 => clkin1,
    CLKFB                 => clkfb,
    -- Output clocks
    CLK0                  => clk0,
    CLK90                 => open,
    CLK180                => open,
    CLK270                => open,
    CLK2X                 => clk2x,
    CLK2X180              => open,
    CLKFX                 => open,
    CLKFX180              => open,
    CLKDV                 => open,
   -- Ports for dynamic phase shift
    PSCLK                 => '0',
    PSEN                  => '0',
    PSINCDEC              => '0',
    PSDONE                => open,
   -- Other control and status signals
    LOCKED                => locked_internal,
    STATUS                => status_internal,
    RST                   => RESET,
   -- Unused pin, tie low
    DSSEN                 => '0');




  -- Output buffering
  -------------------------------------
  clkfb <= clk_out1_internal;


  clkout1_buf : BUFG
  port map
   (O   => clk_out1_internal,
    I   => clk0);


  CLK_OUT1 <= clk_out1_internal;

  clkout2_buf : BUFG
  port map
   (O   => CLK_OUT2,
    I   => clk2x);

end xilinx;

Jedenfalls schon mal vielen Dank für Deine Hilfe. Nur mal nebenbei 
bemerkt, ich finde Deine Website wirklich klasse. Die Beispiele haben 
mir schon sehr geholfen. Aber dass ich dort abgekupfert hab, hast Du ja 
sicherlich schon bemerkt :-)

Beste Grüße,

Norbert

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

Norbert schrieb:
> Also hier jedenfalls mal das Listing des funktionalen DCM Modells.
Wer hat denn da die ganzen Clockbuffer reingebastelt? Sind die alle 
nötig? Das macht die Toolchain üblicherweise von sich aus...

>> Kannst du dir mal das locked Siganl des DCM anzeigen?
> Uff, jetzt übersteigt es meine Kenntnisse und Fähigkeiten.
Du nimmst das Signal locked_internal und gibst es über einen zu 
definierenden Port an ein LED aus...

> Wenn ich bei beiden Prozessen "wait until rising_edge(clk1)" eintrage
> (wovon ich annehme, dass es das ist, was Du meinst), habe ich das selbe
> Ergebnis, es funktioniert nicht.
Das ist nurn wirklich kurios. Sieh dir mal die "Technology Schematic" 
deines Designs an und kontrollier, ob du alle erwarteten Komponenten 
findest...

Norbert schrieb:
> Es kommen auch keine Warnungen oder Fehlermeldungen.
Oft ist eine lapidare "Info" der einzige Hinweis auf einen kapitalen 
Fehler...

[Sauron (Gast)]

Hast du denn eine constrain auf dem Takteingang ?
der Fpga muss ja schliesslich wissen, mit welcher Frequenz er betrieben 
wird.

[Christian R. (supachris)]

Lothar Miller schrieb:
> Norbert schrieb:
>> Also hier jedenfalls mal das Listing des funktionalen DCM Modells.
> Wer hat denn da die ganzen Clockbuffer reingebastelt? Sind die alle
> nötig? Das macht die Toolchain üblicherweise von sich aus...

Neenee, jedenfalls nicht wenn man den DCM manuell instanziiert. Beim 
Core Generator kann man das anklicken, aber ansonsten muss man sich 
darum selber kümmern.

[Schlumpf (Gast)]

hast du den gleichen Effekt, wenn du wahlweise den einen oder den 
anderen Prozess auskommentierst?
Sprich:

clk1-Prozess auskommentiert, dann funktioniert clk2-Prozess
clk2-Prozess auskommentiert, dann funktioniert clk1-Prozess

Auch wenn alles "sauber" aussieht, das Output-Buffering in der DCM 
erfolgt für die beiden Ausgänge nicht identisch.. Vielleicht führt das 
auf eine Spur.

[Schlumpf (Gast)]

Das war Quatsch von mir... sehe es grad selber "clk_out1_internal" ist 
der Feedback..

[Schlumpf (Gast)]

use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
use ieee.numeric_std.all;

Das könnte ggf auch eine Ursache sein...

Ersetze das mal durch

use ieee.numeric_std.all;

[Norbert (Gast)]

Hallo an alle und vielen Dank für die Fragen zu meinem Problem.

>Wer hat denn da die ganzen Clockbuffer reingebastelt?

Das war der wundersame Clock Wizard of Xilinx.

>Sind die alle nötig?

Man hat mir in diesem Thread auf meine Fragen zum DCM hin geantwortet, 
dass das nötig sei.

Beitrag "Xilinx Digital Clock Manager, einfache VHDL Beispiele gesucht"

Außerdem ist das die Standardvorgabe des Templates.

>Du nimmst das Signal locked_internal und gibst es über einen zu definierenden 
Port an ein LED aus...

Ok, ich habe LOCKED auf ein Signal vom Typ std_logic gemapt und damit 
eine LED angesteuert. Die LED ist an und leuchtet hell. Das Signal ist 
sicherlich konstant auf '1'.

>hast du den gleichen Effekt, wenn du wahlweise den einen oder den anderen Prozess
>auskommentierst?
>Sprich:

>clk1-Prozess auskommentiert, dann funktioniert clk2-Prozess
>clk2-Prozess auskommentiert, dann funktioniert clk1-Prozess

Ja, genauso verhält es sich.

>Das könnte ggf auch eine Ursache sein...

Leider nicht, hab ich auch schon ausprobiert.

Was ich dazu noch sagen möchte, ich beschäftige mich nun seit ziemlich 
genau 3 Wochen (!) mit der Materie. Solange ist es nun her, seit ich 
mein Nexys 3 Board bekommen habe und mir das Webpack von Xilinx auf 
meinen PC installiert habe. Am 12.06. hatte ich in dem Forum noch eine 
Frage zu der Lizenz der Xilinx Software gestellt. Zu diesem Zeitpunkt 
wußte ich noch überhaupt nichts über die Xilinx Software und VHDL kannte 
ich nur aus der Beschreibung von Wikipedia. Außerdem bin ich schon über 
50. Man versteht leider nicht mehr alles so schnell wie früher.

Glücklicherweise habe ich mal ein wenig Ada programmiert. Da kommt einem 
wenigstens der Syntax von VHDL schon mal recht bekannt vor. Das ist 
zumindest ein Pluspunkt den ich noch habe.

Naja, aber ich gebe die Hoffnung nicht auf, dass die Lösung dieses 
Problems noch gefunden wird. Danke an Euch alle für Eure Hilfe!

Beste Grüße,

Norbert

[Norbert (Gast)]

Lothar Miller schrieb:
> Das ist nurn wirklich kurios. Sieh dir mal die "Technology Schematic"
> deines Designs an und kontrollier, ob du alle erwarteten Komponenten
> findest...

Ich glaube, die Antwort wird Dir nicht gefallen. Da sieht man ein großes 
grünes Kästchen namens "Blinkled" mit den Eingängen rst und clk und den 
Ausgängen Led1, Led2 und Led3 (die dritte Led auf der ich das LOCKED 
Signal ausgebe).

Wenn ich zweimal drauf klicke um in die nächste Auflösungsstufe zu 
gelangen werde ich erschlagen von sehr vielen kleinen grünen Kästchen 
und richtig vielen roten Leitungen. Das hat leider keinen großen 
Wiedererkennungswert. Irgendwas dazwischen wäre nicht schlecht. Aber ich 
habe keine Ahnung, ob sowas möglich ist.

Gruß, Norbert

[Schlumpf (Gast)]

Ist die Pinzuordnung korrekt? Also hast du in deinem projekt 
abgespeichert, welches Signal auf welchen physikalischen Pin gemappt 
ist, oder überlässt du das dem "Zufall"?

[Norbert (Gast)]

Schlumpf schrieb:
> Ist die Pinzuordnung korrekt? Also hast du in deinem projekt
> abgespeichert, welches Signal auf welchen physikalischen Pin gemappt
> ist, oder überlässt du das dem "Zufall"?

Nenee, ich hab schon eine UCF Datei mit den entsprechenden 
physikalischen Zuordnungen für Takt, LEDs usw. Da wird nichts dem Zufall 
überlassen. Mal abgesehen davon, da käme auch nicht viel Sinnvolles raus 
wenn das alles zufällig stattfinden würde.

[Schlumpf (Gast)]

Nun, dein Code sieht korrekt aus und auch sonst scheinst du alles 
richtig zu machen, soweit ich das anhand der Informationen, die du uns 
gibst, überblicken kann. Daher dachte ich, ob der Fehler vielleicht an 
einer Stelle zu suchen sei, die du uns noch nicht mitgeteilt hast.
Weil, ganz ehrlich: Ich mag nicht so recht glauben, dass es sich hier um 
einen Bug bei der IDE handelt

[Norbert (Gast)]

Schlumpf schrieb:
> Weil, ganz ehrlich: Ich mag nicht so recht glauben, dass es sich hier um
> einen Bug bei der IDE handelt

Das ursächliche Problem befindet sich ca. 70cm vor dem Bildschirm. 
Dessen bin ich mir ziemlich sicher.

[Klaus (Gast)]

Norbert schrieb:
> Das ursächliche Problem befindet sich ca. 70cm vor dem Bildschirm.
> Dessen bin ich mir ziemlich sicher.

Das trifft aber auch auf die Programmierer der Toolchain zu ;-)

[Norbert (Gast)]

Naja, mal ehrlich, jeder, der in der IT Branche tätig ist, kennt dieses 
Phänomen. Setze einen ahnungslosen Anfänger vor eine komplexe IT 
Anwendung und er produziert Fehler am laufenden Band, die selbst alle 
Fachleute in Erstaunen versetzen.

Ganz einfach deshalb, weil er Dinge mit der Software macht, die einem 
erfahrenen Anwender niemals in den Sinn kommen würden. Man kann nicht 
jegliche Fehlbedienung bei einer komplexen Software mit entsprechenden 
Eingaberestriktionen und Plausibilitätskontrollen abfangen. Das ist 
unmöglich.

Und genau das ist mit Sicherheit mein momentanes Problem. Wenn der 
Fehler gefunden wird, lachen sehrwahrscheinlich alle hier in dem Forum 
darüber und daraus wird der nächste Stammtischwitz in 
Hardwaredesignerkreisen.

Ganz nach dem Motto: "Hast du schon gehört, da hat doch tatsächlich 
jemand ..."

[Klaus (Gast)]

Alle möglichen Fehlerursachen, die den Experten eingefallen sind, 
scheinen ja ausgeschlossen. Lad doch mal das Projekt als Zip hoch. 
Vielleicht fällt ja jemandem noch was auf.

[Schlumpf (Gast)]

Norbert, jetzt lass mal die Kirche im Dorf. Hier lacht bestimmt keiner, 
falls wir den Fehler überhaupt finden.
Jeder hat irgendwann mal angefangen und selbst wenn der Fehler ganz 
offensichtlich wäre, würden sich nur diejenigen daran belustigen, die 
sonst nichts zu lachen haben.
Du hast höflich gefragt, hast dich vorbildlich an die Netiquette 
gehalten, hast alle aus deiner Sicht relevante Informationen 
bereitgestellt und daher besteht kein Grund, dass du befürchten musst, 
dass du am Ende ausgelacht wirst.

Offensichtlich ist es bis jetzt noch keinem gelungen, anhand der zur 
Verfügung gestellten Informationen das Problem einzukreisen.
Jetzt gibt es zwei Möglichkeiten:
entweder du rückst auch noch Informationen raus, die aus deiner Sicht 
vielleicht unrelevant sind, oder wir einigen uns darauf, dass du keinen 
Fehler gemacht hast, und die IDE buggy ist.

[Norbert (Gast)]

Ich könnte, wie vorgeschlagen, das komplette Projekt hochladen. Aber 
ohne entsprechende Modifikationen könnte damit nur jemand was anfangen, 
der auch ein Digilent Nexys3 besitzt.

Ansonsten kann ich ein einfaches Rezept nennen falls jemand das 
nachvollziehen möchte. Einfach mit dem Clocking Wizard ein DCM Modul 
generieren, das zwei Ausgänge mit 100MHz und 200MHz hat. Alle 
Einstellungen so übernehmen wie sie standardmäßig vorgegeben werden und 
dann einfach den VHDL Code drumherum stricken, wie er in meinem 
Eingangsposting zu sehen ist. Ursprünglich fehlt lediglich der "LOCKED" 
Ausgang, den hatte ich deselektiert und dann später zur Beantwortung der 
Frage von Lothar im Modul wieder aktiviert. Aber das spielt keine Rolle. 
Die Instantiation Templates werden vom Clocking Wizard fertig vorgegeben 
und brauchen nur noch mit copy&paste in den eigenen VHDL Code eingefügt 
zu werden, wie in meinem Beispiel oben zu sehen ist.

Hier gibts ein Beispielvideo zum DCM. Leider ohne Ton aber man kann 
sehen, wie es funktioniert.

http://www.youtube.com/watch?v=5IR4Yno8U0w

Jeder, der die Web-Pack Software auf seinem PC installiert hat, kann das 
alles in wenigen Minuten nachvollziehen. Man muß nur noch die Ports für 
entsprechende LED-Ansteuerung und für den Systemtakt entsprechend dem 
eigenen Prototyping Board in der UCF-Datei eintragen und schon kann man 
nach dem Durchlauf der Tool-Kette den fertigen Code in seinen FPGA 
hineinladen und ausprobieren.

Das ist eigentlich alles. Geht recht schnell und ist kein Hexenwerk. Wer 
es mag, kann das Ganze ja mal auf seiner Hardware austesten. Bin mal 
gespannt, ob es eventuell bei jemandem so läuft, wie es sollte.

Gruß, Norbert

[Schlumpf (Gast)]

Norbert schrieb:
> Aber
> ohne entsprechende Modifikationen könnte damit nur jemand was anfangen,
> der auch ein Digilent Nexys3 besitzt.

Ist das tatsächlich so?
der "Experte" braucht dazu u.U. die reale Hardware gar nicht, sondern 
schaut sich mal in Ruhe an, was die Synthese so reported.

Poste doch mal deinen Synthese- und PaR-Report..

[bko (Gast)]

Der(die,das?) DCM_SP sollte eigtl. auch so tun
aber evtl. hilft dies weiter:
Aus den "Spartan-6 FPGA Clocking Resources User Guide"
http://www.xilinx.com/support/documentation/user_guides/ug382.pdf
"The RST input must be asserted for three valid CLKIN cycles or longer."
Also RST 3 clocks lang 1 dann erst 0.

[Norbert (Gast)]

bko schrieb:
> Der(die,das?) DCM_SP sollte eigtl. auch so tun
> aber evtl. hilft dies weiter:
> Aus den "Spartan-6 FPGA Clocking Resources User Guide"
> http://www.xilinx.com/support/documentation/user_guides/ug382.pdf
> "The RST input must be asserted for three valid CLKIN cycles or longer."
> Also RST 3 clocks lang 1 dann erst 0.

Der DCM ist nicht das eigentliche Problem. Die Taktsignale an den beiden 
Ausgängen werden ja beide mit den richtigen Frequenzen erzeugt. Das läßt 
sich nachvollziehen wenn man den Code mit jeweils einem auskommentierten 
Prozess synthetisiert. Oder wenn man wahlweise jeweils den einen oder 
den anderen Takt in die wait-Anweisung setzt. Die LED blinkt genau mit 
der erwarteten Frequenz.

Ich habe mittlerweile eher das Gefühl, dass der FPGA mit den zwei 
getrennten Taktfrequenzen in den zwei getrennten Prozessen innerhalb der 
selben Entität nicht zurecht kommt weil der Synthesizer irgendwas 
durcheinander wirft. Ist aber nur so ein Gefühl. Man könnte ja anstatt 
des DCM mal einen einfachen Teiler nehmen, der einem zwei getrennte 
Taktfrequenzen erzeugt und schauen, wie es dann aussieht. Ich muß das 
mal austesten.

[Norbert (Gast)]

Schlumpf schrieb:

> Poste doch mal deinen Synthese- und PaR-Report..

Ich persönlich halte es eher für zielführend, wenn jemand, der wirklich 
Interesse an der Lösung dieses Problems hat, den "Versuchsaufbau" anhand 
meines Rezepts nachstellt. Das ist schnell getan und einfach zu machen. 
Ehrlich gesagt, wundert es mich schon ein wenig, dass das noch niemand 
getan hat.

Bitte verstehe mich nicht falsch, das ist keine Faulheit von mir. Aber 
die Menschen glauben im Grunde nur das, was sie selbst nachvollziehen 
können und genau das möchte ich damit erreichen. Selbst wenn ich hier 
nun weitere Diagnoseinformationen ins Forum stelle (die recht 
umfangreich sind), kommen weitere Fragen der Art, wie hast du dieses 
oder jenes eingestellt, schau mal hier oder schau mal da und probiere 
mal dies und mach mal das. Das bringt es nicht wirklich.

Wie schon gesagt, wenn jemand wirklich Interesse an der Lösung des 
Problems hat, das Rezept zum Nachstellen liegt vor und der Aufwand ist 
wirklich minimal. Es dauert nur wenige Minuten. Der Sourcecode kann 
direkt mit copy&paste übernommen werden, es ist so gut wie kein weiterer 
Tippaufwand erforderlich. Und sicherlich hat fast jeder hier im Forum 
auch irgendeine Form von Hardware, auf der er das Ganze dann in der 
Realität nachvollziehen kann.

Wer weiß, vielleicht tritt das Problem nur bei einem Spartan 6 auf und 
bei einem 3E ist es nicht vorhanden? Möglich wäre alles.

Gruß, Norbert

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

Norbert schrieb:
> Ich habe mittlerweile eher das Gefühl, dass der FPGA mit den zwei
> getrennten Taktfrequenzen in den zwei getrennten Prozessen innerhalb der
> selben Entität nicht zurecht kommt weil der Synthesizer irgendwas
> durcheinander wirft.
Nein, das sicher nicht. Manche schaffen es ohne weiteres, 5 Takte (z.B. 
von Tastern) in einem Modul zu verwenden...

> Der DCM ist nicht das eigentliche Problem. Die Taktsignale an den beiden
> Ausgängen werden ja beide mit den richtigen Frequenzen erzeugt.
Aber eben immer nur eine davon. Das ist kurios.

Mach es doch mal so, dass das DMC-Modul nur die Frequenz verdoppelt, und 
der 100MHz Oszillatortakt direkt im Basismodul verdrahtet wird.

[Schlumpf (Gast)]

> Ich persönlich halte es eher für zielführend, wenn jemand, der wirklich
> Interesse an der Lösung dieses Problems hat, den "Versuchsaufbau" anhand
> meines Rezepts nachstellt.

Da bin ich anderer Meinung

> Bitte verstehe mich nicht falsch, das ist keine Faulheit von mir. Aber
> die Menschen glauben im Grunde nur das, was sie selbst nachvollziehen
> können und genau das möchte ich damit erreichen.

Also du möchtest nicht nur DASS dir geholfen wird, sondern würdest auch 
noch gerne festlegen WIE dir geholfen wird.
Mit dem Hintergrund, dass für uns der Lerneffekt möglichst groß ist?
Bist du Lehrer?

> Wie schon gesagt, wenn jemand wirklich Interesse an der Lösung des
> Problems hat, das Rezept zum Nachstellen liegt vor und der Aufwand ist
> wirklich minimal.

Wenn man selber mit Xilinx arbeitet, ist er gering, da gebe ich dir 
recht. Aber ich werde mir jetzt sicher nicht wegen dir die IDE laden und 
installieren.

Nun, ich hätte dir wirklich gerne geholfen, indem ich mir deine Reports 
angeschaut hätte. Aber da du der Meinung bist, dass das nicht 
zielführend sei, ziehe ich mich an dieser Stelle zurück. Ich kann dir 
dann leider nicht mehr weiterhelfen.

Grüße

[Norbert (Gast)]

Also jetzt wird es noch kurioser. Wenn ich zusammen mit dem zweiten 
Prozess die Zeile

   Led2 <= x2;

auskommentiere (dazu muß ich natürlich auch Led2 in der UCF-Datei 
auskommentieren), dann läuft der andere Prozess, d.h. die Led1 blinkt.

Kommentiere ich nur den gesamten zweiten Prozess von process begin bis 
end process aus, lasse aber die oben erwähnte Zeile stehen, kommt zwar 
eine Warnung, dass das Signal x2 Null enthält und niemals einen anderen 
Wert zugewiesen bekommt (was ja auch korrekt ist aber nicht stört), 
läuft auch nichts mehr.

D. h. alleine der Umstand, dass ich die Zuweisung des Signals x2 an Led2 
auskommentiere oder drin lasse, bewirkt hier, dass es entweder läuft 
oder nicht läuft.

Wie würde Mr. Spock vom Raumschiff Enterprise nun sagen?

Faszinierend!

>Nein, das sicher nicht. Manche schaffen es ohne weiteres, 5 Takte (z.B.
>von Tastern) in einem Modul zu verwenden...

Ich glaube, ich muß mich mal in meinem Arbeitszimmer umschauen ob nicht 
irgendwo eine versteckte Kamera installiert ist.


>Mach es doch mal so, dass das DMC-Modul nur die Frequenz verdoppelt, und
>der 100MHz Oszillatortakt direkt im Basismodul verdrahtet wird.

Ok, versuchen wir das mal ...

[Norbert (Gast)]

Lothar Miller schrieb:
> Mach es doch mal so, dass das DMC-Modul nur die Frequenz verdoppelt, und
> der 100MHz Oszillatortakt direkt im Basismodul verdrahtet wird.

Das bekomme ich leider nicht hin weil der DCM sich den Systemtakt krallt 
und das funktionelle Modell des DCM sich nicht editieren läßt.

Ok, ich gebe auf. Ich habe mir mal dieses Video angesehen, verstehe aber 
nur wenig davon, was der nette Herr erzählt.

http://www.xilinx.com/csi/training/spartan-6-clocking-resources.htm

Auf jeden Fall erzählt er viel darüber, was mit Virtex FPGAs möglich ist 
und mit der Spartan Serie nicht funktioniert. Und er erzählt einiges, 
worauf man bei der Verwendung des DCM in Verbindung mit der Spartan 
Serie achten muß. Er erwähnt auch einige Sachen, von denen abgeraten 
wird.

Die Verwendung unterschiedlicher Takte in getrennten Prozessen könnte ja 
möglicherweise, aus welchen Gründen auch immer, dazugehören. Wenn ich 
das, was in dem Video erzählt wird, auch verstehen kann, habe ich 
sicherlich die Lösung zu meinem Problem aber davon bin ich noch ein 
gutes Stück entfernt.

Auf jeden Fall danke ich allen Forenteilnehmern, die versucht haben, mir 
mit Ratschlägen zu helfen.

Beste Grüße,

Norbert

[Dr. Schnaggels (Gast)]

Wurde die Frage von Sauron schon beantwortet?

[Dr. Schnaggels (Gast)]

Was sagt eine Gatternetzlisten-Timing-Simulation?

Also ran an den Speck: .vho zusammen mit .sdf simulieren und schauen ob 
in der Simulation etwas blinkt...

[Norbert (Gast)]

Dr. Schnaggels schrieb:
> Wurde die Frage von Sauron schon beantwortet?

Öhm, nein. Ich vermute mal, er meint das hier:

NET "clk"            LOC = "V10" | IOSTANDARD = "LVCMOS33";
Net "clk" TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 100000 kHz;

Die zwei genutzten Clock Signale werden ja vom DCM generiert.

Ist das die gewünschte Auskunft?

[Norbert (Gast)]

Dr. Schnaggels schrieb:
> Was sagt eine Gatternetzlisten-Timing-Simulation?
>
> Also ran an den Speck: .vho zusammen mit .sdf simulieren und schauen ob
> in der Simulation etwas blinkt...

Ich muß mal schauen, ob in der kostenfreien Version Modelsim nutzbar 
ist. Ansonsten muß ich mir mal iSIM anschauen. Damit habe ich mich noch 
nicht befaßt.

Aber danke für den Hinweis. So eine Simulation kann ja auch einiges 
aufzeigen.

[Sigi (Gast)]

Stell doch einfach mal deine VHDL-Dateien und die UCF-Datei
hier rein. Aus deinen Komentaren kann man jedenfalls
offensichtlich nicht den Fehler finden. Ein einfaches
Projekt ist ja schnell aufgesetzt.

[Norbert (Gast)]

Dr. Schnaggels schrieb:
> Was sagt eine Gatternetzlisten-Timing-Simulation?
>
> Also ran an den Speck: .vho zusammen mit .sdf simulieren und schauen ob
> in der Simulation etwas blinkt...

Ok, ich habe lediglich das Limit der Zähler in den beiden Prozessen 
verkleinert um die Blinkfrequenz zu erhöhen weil sich ansonsten der 
Simulator zu Tode läuft.

Hier das Resultat (siehe Anlage). Alles läuft wie es soll. Beide Takte 
sind vorhanden und die LEDs blinken wie gewünscht. Aber das ist ja nur 
eine Simulation und nicht die Realität.

[Schlumpf (Gast)]

Norbert schrieb:
> Aber das ist ja nur > eine Simulation und nicht die Realität.

Wenn du VHO und SDF simuliert hast, dann kommt es aber der Realität 
recht nahe. Denn das ist letztendlich das, was am Ende deiner Synthese 
und PaR rauskommt.
Sollte die Synthese etwas wegoptimiert haben, dann würdest du das in der 
Simulation sehen.

Hast du hingegen eine RTL-Simulation durchgeführt, dann gebe ich dir 
recht. Dann ist es in deinem speziellen Fall nicht sonderlich 
aussagekräftig.

[Norbert (Gast)]

Also das ist jetzt wirklich lustig. Sobald ich eine der beiden Ports für 
die LEDs in der UCF-Datei auskommentiere, blinkt jeweils die andere LED 
(im richtigen Takt!!!), deren Port noch in der UCF-Datei drin ist.

Ich habe das jeweils mit beiden LEDs ausprobiert.

Sind jedoch beide Ports/Pins für beide LEDs in der UCF-Datei enthalten, 
funktioniert nichts.

Keine Fehler, keine Warnungen.

Routing Results:
All Signals Completely Routed

Timing Constraints:
All Constraints Met

0 timing errors detected. (0 component switching limit errors)

Ich glaube langsam, diese blöde Software will mich veräppeln. Das gibts 
doch nicht!

[berndl (Gast)]

Schlumpf schrieb:
> Sollte die Synthese etwas wegoptimiert haben, dann würdest du das in der
> Simulation sehen.

nee, ganz sicher nicht. Synthese und Simulation haben erstmal nix 
miteinander zu tun. Das sind sogar wahrscheinlich verschiedene 
Compiler...

Der S6 den der Norbert verwendet hat ja schon einige Macken. Und 
Design-bugs pflegen die bei Xilinx erstmal (wenn sie's nicht wissen) 
weder in den Synthese-Compiler noch in den Simulator ein.

Es geht eigentlich darum, eine Testschaltung zu entwickeln, die die 
(Fehl-)Funktion des Chips belegt. Und mitgelieferte Testschaltungen des 
Boardherstellers verwenden selten PLLs mit 2 Ausgangstakten...

Mag ja sein, dass das Teil einfach einen Schlag hat...

[Norbert (Gast)]

Schlumpf schrieb:
> Hast du hingegen eine RTL-Simulation durchgeführt ...

Hallo Schlumpf,

da muß ich leider passen. Ich habe das Ganze mit iSIM simuliert. Das ist 
(soweit ich das verstanden habe) nur eine Simulation des VHDL Modells.

Für die RTL Simulation braucht man wohl Modelsim. Das ist in meiner 
Webpack Software nicht (mehr) dabei.

[Norbert (Gast)]

berndl schrieb:
> Mag ja sein, dass das Teil einfach einen Schlag hat...

Also ich habe nun eine andere Variante ausprobiert, bei der ich an 
Stelle des DCM folgenden Generator verwende, der aus dem Eingangstakt 
drei unterschiedliche Ausgangstakte in 3 verschiedenen Phasenlagen 
erzeugt. Damit funktioniert es mit 3 Prozessen und 3 blinkenden LEDs 
einwandfrei.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity clock_gen is
 port(
  clock: in std_logic;
  reset: in std_logic;
  clk_a: out std_logic;
  clk_b: out std_logic;
  clk_c: out std_logic
  );
end clock_gen;
architecture flow of clock_gen is
 signal u_temp : std_logic_vector(2 downto 0);
begin
 
 p1: process(clock, reset)
 begin
  if reset = '1' then
   u_temp <= "100";
  elsif clock'event and clock = '1' then
   u_temp <= u_temp(0) & u_temp(2) & u_temp(1);
  end if;
 end process;
 clk_a <= u_temp(2);
 clk_b <= u_temp(1);
 clk_c <= u_temp(0);

end flow;

[berndl (Gast)]

Norbert schrieb:
> Ich glaube langsam, diese blöde Software will mich veräppeln. Das gibts
> doch nicht!

welche ISE genau verwendest du?

War hier ja auch schon Thema, aber koenntest du die .ucf, .xise, *.vhd 
mal hier hochladen?

Welches Board verwendest du? Evalboard oder eigenes?

[Norbert (Gast)]

berndl schrieb:
> Der S6 den der Norbert verwendet hat ja schon einige Macken.

Darüber habe ich auch schon an anderen Stellen einiges gelesen. Mit dem 
S6 sind die Entwickler nicht sonderlich froh.

Mittlerweile bin ich schon am zweifeln, ob ich nicht doch besser das 
Vorgängerboard mit einem 3E-1200 genommen hätte. Da hätte ich zudem noch 
mehr LUTs zur Verfügung gehabt.

[bko (Gast)]

Norbert schrieb:
> Also das ist jetzt wirklich lustig. Sobald ich eine der beiden Ports für
> die LEDs in der UCF-Datei auskommentiere, blinkt jeweils die andere LED
> (im richtigen Takt!!!), deren Port noch in der UCF-Datei drin ist.
>
> Ich habe das jeweils mit beiden LEDs ausprobiert.
>
> Sind jedoch beide Ports/Pins für beide LEDs in der UCF-Datei enthalten,
> funktioniert nichts.
>
Leg doch mal die LED-Ausgänge im UCF auf andere Pins
(auf eine Steckerleiste oder so) und schließe
dort mal 2 LEDs+Widerstand an.

[Norbert (Gast)]

berndl schrieb:
> welche ISE genau verwendest du?
>
> War hier ja auch schon Thema, aber koenntest du die .ucf, .xise, *.vhd
> mal hier hochladen?
>
> Welches Board verwendest du? Evalboard oder eigenes?

Ok, ich lade die gewünschten Dateien mal als ZIP-Archiv hoch. Den DCM 
muß man aber eventuell mit dem Wizard nochmal neu kreieren.

Meine ISE Version ist 14.5

Das Board ist ein Digilent Nexys3

[Schlumpf (Gast)]

berndl schrieb:
> nee, ganz sicher nicht. Synthese und Simulation haben erstmal nix
> miteinander zu tun. Das sind sogar wahrscheinlich verschiedene
> Compiler...

Richtig, haben sie nicht.. aber das Modell, welches simuliert wird, hat 
sehr wohl etwas mit der Synthese zu tun. Stichwort: Backannotation
Und wenn dieses, von der Synthese generierte Modell, bereits den Fehler 
zeigen würde, könnte man mit nahezu 100%iger Sicherheit darauf 
schließen, dass das Design irgendwo in der Toolchain zerhagelt wird.

[Tschaebe (Gast)]

Norbert,

ich habe aus Interesse mal den Code von ganz oben implementiert - läuft 
ohne Probleme auf meinem Nexys3.
Dann habe ich mal dein Projekt genommen - läuft nicht - hm.

Der Fehler liegt im .ucf file: "rst" ist nicht constraint, lag also mal 
da, mal da - und je nach Beschaltung ist rst high oder low und es tut 
oder auch nicht.

Das steht übrigens im pad Report (siehe Anhang), da steht bei "rst" ein 
"unlocated" ;-)

[Norbert (Gast)]

Tschaebe schrieb:
> Norbert,
>
> ich habe aus Interesse mal den Code von ganz oben implementiert - läuft
> ohne Probleme auf meinem Nexys3.
> Dann habe ich mal dein Projekt genommen - läuft nicht - hm.
>
> Der Fehler liegt im .ucf file: "rst" ist nicht constraint, lag also mal
> da, mal da - und je nach Beschaltung ist rst high oder low und es tut
> oder auch nicht.
>
> Das steht übrigens im pad Report (siehe Anhang), da steht bei "rst" ein
> "unlocated" ;-)

Hallo Tschaebe,

vielen Dank für den Hinweis. Da weiß ich wenigstens, dass ich den Fehler 
gemacht habe. Aber dazu habe ich mal eine dumme Frage. Wie sieht denn 
der Eintrag in der UCF-Datei aus? Kann ich dafür einfach einen Eingang 
eines  Tasters der Platine zuweisen? Oder muß dieser Eintrag in der 
UCF-Datei eine bestimmte Form haben? Liegt er eventuell an einem ganz 
bestimmten Port des FPGA?

Danke schon mal für weitere Hinweise.

Gruß, Norbert

[Norbert (Gast)]

Also es funktioniert jetzt und meine weitere Frage ist auch schon 
beantwortet.

Vielen Dank an den wahren Helden des Forums ;-)

Beste Grüße,

Norbert

[Tschaebe (Gast)]

Das ist im Prinzip ähnlich wie mit den clk und Led-Pins.

Ich habe gedacht, dass Du den reset per Button auslösen willst, also 
habe ich das dann einfach in dem Master ucf von Digilent entsprechend 
geändert (habe mal die entsprechend geänderte master .ucf von Digilent 
angehängt).

## Buttons
NET "rst"         LOC = "B8"  |IOSTANDARD = "LVCMOS33";   #Bank = 0, Pin 
name = IO_L33P,                           Sch name = BTNS

Der Netzname entspricht dabei dem I/O Portnamen in deinem VHDL Code (ich 
habe noch nie geschaut, ob das bei Xilinx case sensitive ist, habe es 
einfach mal angenommen)

Prinzipiell musst Du
* entweder alle Eingänge (eigentlich alle I/Os in deinem Toplevel), die 
du verwendest (also auch "rst"!) fest zuweisen,
* oder nach Deine Platine nach dem bauen, was P&R für FPGA Pins 
verwendet. Nachdem du schon ein Nexys3 hast also ersteres ;-))

Ansonsten hast du ev. offene oder falsch belegte Eingänge (nicht gut) 
oder Ausgänge die gegen die restliche Beschaltung Deines Boards treiben 
(auch nicht gut).

Die nächste Frage wäre dann, ob du "rst" überhaupt brauchst (wurde hier 
auch schon verschiedentlich behandelt)

Gruss,
Tschaebe

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

Tschaebe schrieb:
> da steht bei "rst" ein "unlocated" ;-)
Aua! Das hatte ich auch schon und es ist hier das eigentliche Problem, 
denn die DCM brauchen unbedingt einen Reset, sonst kommen die nicht 
richtig ans Laufen...

Dazu der UG382 auf Seite 70::

RST:  Reset DCM block. 
      Hold RST pulse High for at least three valid CLKIN cycles

> Die nächste Frage wäre dann, ob du "rst" überhaupt brauchst
Für ein Design eigentlich nicht, weil es ja Initwerte gibt ...
> (wurde hier auch schon verschiedentlich behandelt)
... aber dann muss trotzdem irgendwie ein Zähler laufen, der mindestens 
3 Eingangstakte abzählt und dann den Reset am DCM wegnimmt. Das war 
früher schon so und wird liebevoll weitergepflegt:
http://www.xilinx.com/support/answers/20724.htm

Und immer wieder gibt es auch sonst Probleme mit nicht richtig 
zurückgesetzten DCM: http://www.xilinx.com/support/answers/34675.htm

[Dr. Schnaggels (Gast)]

>da steht bei "rst" ein "unlocated" ;-)

OK, das hätte man in der Backannotation-Simulation auch nicht gesehen 
:-))

[Christian R. (supachris)]

Dr. Schnaggels schrieb:
> OK, das hätte man in der Backannotation-Simulation auch nicht gesehen

Wohl aber in den mehrfach eingeforderten Log-Dateien der Toolchain. Dann 
hätte man das viel eher finden können.

[Dr. Schnaggels (Gast)]

Es ist prinzipiell eine gute Idee sich ein kleines Skript zu schreiben, 
das in den Log-Dateien nach bestimmten Schlagwörtern sucht.

[Sigi (Gast)]

Spartan3(E) DCM und Reset:
Die DCM braucht eigentlich kein Reset, sie läuft
auch ohne an. Wenn man aber doch Reset verwendet,
dann sollte man sich an die 3-Zyklen-Regel halten.
(habs selber mal ausprobiert, bei 1 oder 2 bleibt
die DCM stehen).

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

Sigi schrieb:
> Spartan3(E) DCM und Reset:
> Die DCM braucht eigentlich kein Reset, sie läuft
> auch ohne an.
Das kann ich nicht in allen Fällen bestätigen....

[Norbert (Gast)]

Lothar Miller schrieb:
> Sigi schrieb:
>> Spartan3(E) DCM und Reset:
>> Die DCM braucht eigentlich kein Reset, sie läuft
>> auch ohne an.
> Das kann ich nicht in allen Fällen bestätigen....

Also man kann auf jeden Fall im Clocking Wizard den Reset-Eingang 
deselektieren. Dann generiert er den DCM ohne Reset-Eingang und der 
läuft, zumindest nach meiner bisherigen (wenn auch geringen) Erfahrung 
eiegntlich problemlos.

[Christian R. (supachris)]

Aus dem Konfig-Reset heraus geht das. Wenn aber zwischendurch mal der 
EIngangstakt abhanden kommt, kommt auch der S3 DCM nicht wieder korrekt 
zum Laufen ohne Reset. Beim Spartan 6 hingegen, um den es hier ging 
läuft ohne manuellen Reset der DCM selbst nach der Konfig nicht immer 
zuverlässig an. Aber da hilft die Verknüpfung mit dem Status-Ausgang aus 
dem Clocking User Guide sehr zuverlässig.

[Duke Scarring (Gast)]

Sigi schrieb:
> Spartan3(E) DCM und Reset:
> Die DCM braucht eigentlich kein Reset, sie läuft
> auch ohne an.
Das hängt m.E. auch von den verwendeten Funktionen (DLL, DFS, DPS) ab.

Duke