2 Clocks im Schieberegister

[Maik R. (kiamur)]

Hallo!

Nachdem ich jetzt schon ein paar coole Sachen im FPGA hinbekommen habe, 
stehe ich nun vor einem kleinen Problem, welches sich für mich als 
hartnäckiger herausstellt, als angenommen.

Ich möchte gerne ein Schieberegister mit sagen wir mal 1µs Taktfrequenz 
schieben lassen (-> 1Mhz). Zwischendrin möchte ich mit den Daten im 
Schieberegister ein paar Berechnungen anstellen (hauptsächlich 
statistische Datenauswertung). Dazu möchte ich einen höheren Takt 
beutzen, damit ich für die Berechnungen vor dem nächsten Schieben eine 
vielzahl an "Berechnungstakten" habe. Der Plan ist diesen Takt auf 50Mhz 
zu setzen.

Das Problem ist nun, dass ich in das Entity beide Takte von außen 
vorgeben möchte, da sie dann synchron zum einbettenden Entity laufen, 
welches diese beiden Takte auch schon benutzt.

Dazu habe ich folgendes Entity erstellt:

entity shift_register_p2 is
port(fast_clk     : in std_logic;
     shift_clk    : in std_logic;
     data_in      : in std_logic_vector(10 downto 0);
     data_out     : out std_logic_vector(10 downto 0)
     );
end entity shift_register_p2;

"fast_clk" ist dabei der Berechnungstakt, und "shift_clk" der 
Schiebetakt.

Das Schieberegister wird dann als 2D-Array erstellt, und in einem 
process, der sensitive auf den shift_clk ist, "bewegt".

Nun habe ich versucht in einem weiteren process, der auf das fast_clk 
Signal sensitive ist, etwas logik zu implementieren. Leider wird das 
aber nicht syntetisiert. Es läuft zwar alles Problemlos durch, aber das 
Synthese Tool schmeißt alles weg, was in diesem zweiten Prozess steht. 
Im RTL-Viewer sehe ich dann immer den fast_clk-Pin, an dem nichts 
angeschlossen ist. Ich habe auch schon versucht das fast_clk-Signal mit 
in die sensitiv-Liste des ersten processes mit aufzunehmen, aber das 
klappt auch nicht.

Ich benutze einen Altera Stratix FPGA und Quartus II 7.0.

Hat jemand einen Tip, wie ich das Problem lösen kann?

Danke
Maik

[Jan M. (mueschel)]

Was haengt denn am Ausgang von deiner Berechnungslogik? Falls da nichts 
ist, darf die Synthese das wegoptimieren.

Ansonsten Vorsicht mit den beiden Takten und der Uebergabe von einer 
Clock zur anderen. Lass besser das Schieberegister auch mit 50MHz 
laufen, generiere dir aus der langsamen Clock ein einen Takt langes 
Signal und benutze das als Clockenable.

[Falk B. (falk)]

@ Maik Ritter (kiamur)

>Ich möchte gerne ein Schieberegister mit sagen wir mal 1µs Taktfrequenz
>schieben lassen (-> 1Mhz). Zwischendrin möchte ich mit den Daten im
>Schieberegister ein paar Berechnungen anstellen (hauptsächlich

???
Komische Sache.

>Das Problem ist nun, dass ich in das Entity beide Takte von außen
>vorgeben möchte, da sie dann synchron zum einbettenden Entity laufen,
>welches diese beiden Takte auch schon benutzt.

Mit mehrfachen Takten muss man SEHR vorsichtig sein. Besser ist auf 
jeden Fall die Nutzung von Clock enable.

Taktung FPGA/CPLD

>Das Schieberegister wird dann als 2D-Array erstellt, und in einem
>process, der sensitive auf den shift_clk ist, "bewegt".

???
2D Array als Schieberegister. Klingt eher, als ob du einen RAM brauchst.

>in die sensitiv-Liste des ersten processes mit aufzunehmen, aber das
>klappt auch nicht.

Du musst dir mal klar machen, was du da zusammenstrickst. Einfach 
"irgendwie zwei Takte Verwenden" geht einfach nicht.

>Hat jemand einen Tip, wie ich das Problem lösen kann?

Erstmal klarer formulieren was wirklich gemacht werden soll.

MFG
Falk

[Maik R. (kiamur)]

Hallo!

>>Was haengt denn am Ausgang von deiner Berechnungslogik? Falls da nichts
>>ist, darf die Synthese das wegoptimieren.

Ja, das hatte ich auch erst vermutet. deswegen habe ich einen Zähler 
erstellt, der mit dem schnellen Takt inkrementiert werden soll. Damit 
der Zähler auch benutzt wird, habe ich ihn dann auch noch zurücksetzen 
lassen. Das ganze sieht so aus:

process(fast_clk)
begin
    if(fatst_clk'event and fast_clk = '1') then
        if(conv_integer(sr(9)(10 downto 7)) = 1) then
            counter <= counter + 1;
        end if;
        if(counter = 33333) then
            counter <= 0;
        end if;
    end if;
end process;

Da müsste doch eigentlich etwas Logik draus synthetisiert werden, oder?
(Das hat natürlich alles noch keinen Sinn. Ist nur zum Testen . . . )

>>generiere dir aus der langsamen Clock ein einen Takt langes
>>Signal und benutze das als Clockenable.

Wichtig ist mir, dass beide Clocks von außen in das Entity gegeben 
werden, damit ich die Synchronisation zur Außenwelt nicht verliere. Aber 
ich glaube, du meinst das auch anders, oder? Ich habe nur noch nicht so 
ganz verstanden, wie . . .

Gruß
Maik

[Falk B. (falk)]

@  Maik Ritter (kiamur)

Poste doch mal kompletten Quelltext, solche Fragmente nützen wenig.

>Wichtig ist mir, dass beide Clocks von außen in das Entity gegeben
>werden, damit ich die Synchronisation zur Außenwelt nicht verliere. Aber

??? Wo kommen denn die beiden Takte her?

MFg
Falk

[Maik R. (kiamur)]

@falk:

>>Erstmal klarer formulieren was wirklich gemacht werden soll.

Ich habe Daten in meinem Schieberegister, die jede µs weitergeschoben 
werden müssen. Mit den daten, die dann für eine µs an einer bestimmten 
Stelle im Schieberegister stehen, möchte ich berechnungen anstellen. 
Diese Berechnungen werde ich u.U. nicht in einem µs Takt schaffen. 
Deswegen habe ich mir gedacht, dass die Daten ja für eine µs statisch an 
einer Stelle im Schieberegister gespeichert sind. So lange kann ich doch 
mit einem schnelleren Takt berechnungen mit diesem Datensatz 
durchführen, und das Ergebnis dann ggf. an die Speicherstelle im 
Schieberegister zurückschreiben. Nach einer µs wird das Ergebnis dann 
weitergeschoben, und das Spiel geht wieder von vorne los. Natürlich muss 
ich aufpassen, dass alles in der µs fertig wird, aber das sollte nicht 
das Problem sein (, oder?!?).

>>???
>>2D Array als Schieberegister. Klingt eher, als ob du einen RAM brauchst.

Naja, ein Schieberegister ist ja wohl auch eine Art RAM . . .

Implementierung:

type sr_array is array (9 downto 0) of std_logic_vector(10 downto 0);
signal sr : sr_array;

>>Mit mehrfachen Takten muss man SEHR vorsichtig sein. Besser ist auf
>>jeden Fall die Nutzung von Clock enable.

Okay, das hat Jan ja auch schon vorgeschlagen, aber wie mache ich das in 
diesem Fall am elegantesten? Wie gesagt, es ist sehr wichtig, dass die 
beiden Takte zur "Außenwelt" synchron gehalten werden müssen . . .

Gruß
Maik

[Jan M. (mueschel)]

Mal schnell etwas zusammenkopiert:

  process(CLK_FAST)
    begin
      if rising_edge(CLK_FAST) then
        if RESET = '1' then
          this_slow_clk <= '0';
          last_slow_clk <= '0';
        else
          this_slow_clk <= CLK_SLOW;
          last_slow_clk <= this_slow_clk;
        end if;
      end if;
    end process;

clk_slow_en <= '1' when (this_slow_clk = '1' and last_slow_clk = '0') else '0';

--Hier ein langsamer Prozess:
   process(CLK_FAST)
    begin
      if rising_edge(CLK_FAST) and clk_slow_en = '1' then

Der zweite Prozess erhaelt nun genau mit jeder langsamen steigenden 
Clockflanke fuer genau einen Takt ein enable Signal, laeuft also genau 
so schnell wie diese Clock.

[Maik R. (kiamur)]

@Falk
>>Poste doch mal kompletten Quelltext, solche Fragmente nützen wenig.
Geht nicht. Ich denke, da hat die Firma was dagegen . . . Außerdem ist 
das schon eine ganze Menge.

Das Entity, welches ich jetzt schreiben möchte wird einfach in Reihe zu 
einem seriellen Datenstrom "geschaltet", welcher mit einem Takt von 1µs 
eintrifft (Daher muss dies der Schiebetakt sein, aber eben auf dem 
gleichen Takt, wie der Datenstrom außerhalb des Entitys, also im 
einbettenden Entity bewegt wird.)

Das in Reihe schalten funktioniert schon wunderbar. Wenn ich nicht im 
Schieberegister tue, dann erfahren die Signale "nur" eine Verzögerung 
von 10µs (am Simulator getestet). Ansonsten bleiben die Daten 
unverändert

Jetzt möchte ich halt die daten doch verändern, und dazu einige 
Berechnungen durchführen. Dazu benötige ich den höheren Takt . . .

Nachdem die daten dieses Entity wieder verlassen haben soll das darüber 
liegende system eben nicht "merken", dass da etwas passiert ist, und mit 
den daten genauso weiterarbeiten, wie vor dem Zeitpunkt, wo das Entity 
"eingebaut wurde" . . .

Ist vielleicht etwas umständlich. Es ermöglicht mir aber das erweitern 
des vorhandenen Systems, ohne dass ich daran etwas ändern muss . . .

[Maik R. (kiamur)]

@Jan: Vielen Dank für den Code . . .
Das RESET Signal ist von dir eingefügt, richtig? Das wird ja wohl 
grundsätzlich nicht benötigt, oder?

Ansonsten muss ich das wohl auch noch mal ausprobieren, um es richtig zu 
verstehen. Beim ersten Drüberschauen sieht es mir aber so aus, als ob 
der langsame Prozess in deiner Implementierung um einen schnellen Takt 
verzögert abgearbeitet wird, als wenn ich die Taktflanke des langsamen 
Clocks direkt auswerten würde.

Mich würde nur noch mal interessieren, warum  mein process Code, den ich 
oben gepostet habe nicht synthetisiert wird . . . .

[Falk B. (falk)]

@ Maik Ritter (kiamur)

>weitergeschoben, und das Spiel geht wieder von vorne los. Natürlich muss
>ich aufpassen, dass alles in der µs fertig wird, aber das sollte nicht
>das Problem sein (, oder?!?).

Ach nein? Oben sagst du, dass du das nicht jede us schaffst.

Mir ist das Ganze immer noch mystisch. Was soll das denn werden? Das 
klingt mir nach FIR-Filter.

>diesem Fall am elegantesten? Wie gesagt, es ist sehr wichtig, dass die
>beiden Takte zur "Außenwelt" synchron gehalten werden müssen . . .

WO KOMMEN DIESE TAKTE HER?!!

MFg
Falk

[Maik R. (kiamur)]

>>Ach nein? Oben sagst du, dass du das nicht jede us schaffst.

Hmmm, wenn jede µs EIN Takt kommt, und dann der Datensatz 
weitergeschoben wird (weil die Schiebetaktung des Schieberegisters eben 
1µs ist), dann habe ich ja sogar gar keine Möglichkeit Berechnungen mit 
dem Datensatz an dieser Speicherstelle durchzuführen.
Wenn ich jetzt aber noch einen zweiten Takt habe, der mit 50MHz taktet, 
dann habe ich ja in der einen µs, in der der Datensatz auf der einen 
Speicherstelle verharrt 50 Takte, um mit diesem Datensatz 
herumzurechnen. Danach kann ich dann entscheiden, ob beim nächsten 
µs-Takt der original Datensatz an die nächste Speicherstelle geschoben 
werden soll, oder das Ergebnis meiner Berechnungen.
Das Entescheidende ist, dass ich eben nicht nur schieben möchte, sondern 
zwischendrin auch noch was berechnen. Das Schieben MUSS aber synchron 
zur Außenwelt geschehen, weil dort die Daten mit der selben Taktung in 
das Schieberegister reingeschoben, und am Ausgang abgeholt werden.

>>WO KOMMEN DIESE TAKTE HER?!!
Wie gesagt, es sind im Prinzip die selben (noch nicht mal die gleichen, 
sondern wirklich die SELBEN) Taktsignal, mit denen auch außerhalb des 
Entitys die daten geschoben werden.
Jetzt könnte man fragen, warum ich dann ein neues Entity erstelle, und 
nicht alles im schon existierenden Entity erledige.
Es geht halt einfach darum, dass ich mein Projekt gerne in Module 
unterteile, die alle eine bestimmte Aufgabe haben. Deswegen habe ich ein 
Controller-Entity, welches alle anderen Modul-Entitys als Component 
aufnimmt. Der Controller kümmert sich um die Synchronisation der 
einzelnen Module, und um die phjysiklaische Verbindung zur Außenwelt.

Ich habe zum Beispiel ein ADC-Interface Modul, ein UART-Modul, Zwei 
Signalverarbeitungsmodule, die auch wieder Module beinhalten, usw.

Jetzt möchte ich eben ein weiteres Entity-Modul in den Controller 
einbauen, was mir ja auch schon gelungen ist (s.o. die Daten werden vom 
Controller an dieses neue Entity übergeben, und erscheinen dann (bis 
jetzt unmodifiziert) 10µs später wieder am Ausgang, so dass der 
Controller die Daten zum UART-Interface schicken kann.

Jetzt möchte ich die Daten aber nicht nur um 10µs verzögern, sondern 
auch noch bearbeiten. Deswegen benötige ich in dem Entity eine 
Möglichkeit zwischen den Takten zum Schieben auch noch ein paar 
Berechnungen durchzuführen. Dafür brauche ich halt den höheren Takt, der 
meinem Entity auch vom Controller zugeführt wird, weil dieser ja für die 
verteilung und somit synchronisation der Daten und Takte zuständig ist.

In dem Controller habe ich 3 Takte: den Chrystal takt vom FPGA 
Oszillator(50MHZ), den Takt mit dem ich die ADC durchführe 25MHZ, und 
einen µs-Takt, den ich zum Schieben der Daten in diesem Entity, und für 
Zeitstempel benötige.

Ich hoffe es wird jetzt langsam klarer.

Bis jetzt funktioniert auch alles wunderbar und völlig problemlos. Nur 
diese neue "Idee" von mir mit dem Berechnen zwischen den Schiebetakten 
habe ich noch nicht im Griff. Ich kann mir aber nicht vorstellen, dass 
das nicht gehen soll . . .


Gruß
Maik

[Falk B. (falk)]

@ Maik Ritter (kiamur)

>Wenn ich jetzt aber noch einen zweiten Takt habe, der mit 50MHz taktet,
>dann habe ich ja in der einen µs, in der der Datensatz auf der einen
>Speicherstelle verharrt 50 Takte, um mit diesem Datensatz
>herumzurechnen. Danach kann ich dann entscheiden, ob beim nächsten

Klar.

>Wie gesagt, es sind im Prinzip die selben (noch nicht mal die gleichen,
>sondern wirklich die SELBEN) Taktsignal, mit denen auch außerhalb des
>Entitys die daten geschoben werden.

Die SELBEN können es nicht sein, denn 1MHz ist nicht gleich 50 MHz.
Allerdings kann der 1 MHz vom 50 MHz durch Teilung abgeleitet sein. In 
diesem Fall ist die Sache klar.

NIMM CLOCK ENABLES FÜR DEN 1 MHZ TAKT UND LASS ALLES MIT 50 MHz LAUFEN!

>In dem Controller habe ich 3 Takte: den Chrystal takt vom FPGA
>Oszillator(50MHZ), den Takt mit dem ich die ADC durchführe 25MHZ, und
>einen µs-Takt, den ich zum Schieben der Daten in diesem Entity, und für
>Zeitstempel benötige.

Die zwei langsameren sind wahrscheinlich vom 50 MHz Takt abgeleitet, 
nicht?

>habe ich noch nicht im Griff. Ich kann mir aber nicht vorstellen, dass
>das nicht gehen soll . . .

Es geht. Du lässt alles mit 50 MHz laufen und schiebst nur zu jedem 50. 
Takt. Dammit ist alles schön synchron.

MFG
Falk

[Maik R. (kiamur)]

>>Die SELBEN können es nicht sein, denn 1MHz ist nicht gleich 50 MHz.
>>Allerdings kann der 1 MHz vom 50 MHz durch Teilung abgeleitet sein. In
>>diesem Fall ist die Sache klar.

Mit die SELBEN meine ich, das der 1MHz Takt im Controller der selbe ist, 
wie der 1MHz Takt im neuen Entity, weil dieser an dem Eingang shift_clk 
anliegt.

>>Die zwei langsameren sind wahrscheinlich vom 50 MHz Takt abgeleitet,
>>nicht?

Exakt!

>>Es geht. Du lässt alles mit 50 MHz laufen und schiebst nur zu jedem 50.
>>Takt. Dammit ist alles schön synchron.

Theoretisch ja. Was ich aber benötige ist eine Sicherheit, dass der 1MHz 
Takt im neuen Entity exakt synchron zum 1MHz Takt im Controller ist, 
weil dies ja der Takt ist. mit dem die Daten transportiert werden. Er 
darf also nicht so aussehen:

-|----|----|----|----|----|----|----|----  : Controller
---|-----|----|----|----|----|----|----|-- : neues Entity

sondern es muss so sein:

-|----|----|----|----|----|----|----|----  : Controller
-|----|----|----|----|----|----|----|----  : neues Entity

Aus diesem Grund wollte ich eben den µs-Takt und den 50MHz Takt vom 
Controller aus übergeben, da dann beide mit den SELBEN Takten arbeiten . 
. .

[Falk B. (falk)]

@ Maik Ritter (kiamur)

>>Die zwei langsameren sind wahrscheinlich vom 50 MHz Takt abgeleitet,
>>nicht?

>Exakt!


>Theoretisch ja. Was ich aber benötige ist eine Sicherheit, dass der 1MHz
>Takt im neuen Entity exakt synchron zum 1MHz Takt im Controller ist,

???
Erster April?

Wenn du einfach das selbe Signal für beide Module verwendest geht das in 
Ordnung. Aber nochmal der DIRGENDE Hinweis. Lass das mit abgeleiteten 
Takten, nimm CE!

Taktung FPGA/CPLD

>Aus diesem Grund wollte ich eben den µs-Takt und den 50MHz Takt vom
>Controller aus übergeben, da dann beide mit den SELBEN Takten arbeiten .

Na dann mach das doch einfach.

MfG
Falk

[Maik R. (kiamur)]

>>Erster April?

Nee, 10. August . . . .

>>Na dann mach das doch einfach.

Naja, weil ich es eben nicht so einfach hinbekomme habe ich ja diesen 
Thread hier eröffnet. Sag mir doch bitte, wie du es machen würdest . . .

Vielleicht noch einmal zur Wiederholung was meine eigentliche Frage war: 
Ich habe 2 Takte, die ich meinem Schieberegister Entity übergebe. Mit 
dem langsamen möchte ich schieben, mit dem schnellen möchte ich 
berechnen. Beide sollen die ihnen zugewiesene Aufgabe auf der positiven 
Taktflanke erledigen (-> deswegen wollte ich ja für jeden einen process 
mit entsprechender Sensitivität erzeugen).

Genau das bekomme ich aber irgendwie nicht hin . . . .

Gruß
Maik

[Falk B. (falk)]

@ Maik Ritter (kiamur)

>Naja, weil ich es eben nicht so einfach hinbekomme habe ich ja diesen
>Thread hier eröffnet. Sag mir doch bitte, wie du es machen würdest . . .

>Vielleicht noch einmal zur Wiederholung was meine eigentliche Frage war:
>Ich habe 2 Takte, die ich meinem Schieberegister Entity übergebe. Mit

Du musst dich von dem Gedanken an zwei Takte lösen! Es gibt nur einen 
echten Takt, 50 MHz. Das andere ist ein CE!

>Genau das bekomme ich aber irgendwie nicht hin . . . .

Du hast das Prinzp von CE noch nicht verstanden.

Sinngemäss so. Das Clock enable muss logischerweise überall in deinem 
Design als 1 MHz "Takt" verwendet werden.

-- Clock enable, 1 MHz

process(clk50M)
begin
  if rising_edge(clk50M) then
    if cnt_1M=0 then
      cnt_1M <= 0+49;
      ce_1M <= '1';
    else
      cnt_1M <= cnt_1M +1;
      ce_1M <='0';
    end if;
  end if;
end process;

-- Schieben und berechnen

process(clk50M)
begin
  if rising_edge(clk50M) then
    if ce_1M='1' then
      -- schieben
    else
      -- rechnen
    end if;
  end if;
end process;

MFG
Falk

[Mark (Gast)]

Hallo Maik,

versuchs dochmal so:
es gibt 2 Taktwelten, C1 = 1MHz, C2 = 50 MHz
mit C1 läuft Dein Schieberegister

mit C2 taktest Du erstmal 2..3 Flip-Flops, die ebenfalls ein 
Schieberegister bilden. An den D-Eingang kommt das langsame Taktsignal 
C1.
Nun verknüpfst Du die Ausgänge so, dass diese Logik die steigende Flanke
von C1 erkennt. Dieses Signal ist für die Taktwelt C2 das Zeichen, dass
nun ein neuer Wert aus dem Schieberegister gelesen werden kann.
Jetzt hast Du 50 Takte minus N zur Verfügung, um damit rumzurechnen.
N ist das Delay zur Flankenerkennung. Ein Multiplexer kann nun dieses
Ergebnis oder den Originalwert zum Weiterschieben auswählen.
Musst darauf achten, dass für den Pfad des MUX der an der 50 MHz
Taktwelt hängt ein entspr. Timing-Constraint gesetzt wird, also
z.B. 20ns Register Tsu, wenn das Ergebnis eben erst 20ns vor der 
nächsten 1MHz Flanke fertig ist.

Sorry, die Angst vor verschiedenen Takten ist berechtigt aber wers nicht 
probiert kommt nicht weiter !

[Maik R. (kiamur)]

Ich werde es jetzt mal so versuchen . . . .

Prinzipiell habe ich den existierenden 1MHz Takt ja schon im Controller 
genau so vom 50MHz Takt abgeleitet. Ich mache jetzt das Ganze im neuen 
Entity also noch einmal. Ich wollte halt das 1MHz Signal aus dem 
Controller beutzen, um nicht überall ein eigenes 1MHz Signal generieren 
zu müssen. . . .

Was CE bedeutet war mir schon klar (Trotzdem Danke für das 
Code-Beispiel, denn ich habe es noch nie implementiert). Ich hätte es 
halt gerne auf die andere Art gelöst, weil im Controller das 1MHz Signal 
dafür benutzt wird, einen Zähler zu inkrementieren, dessen Wert jedem 
Datensatz angefügt wird, wenn er das neue Schieberegister wieder 
verlässt (um die Abstände der Datensätze untereinander festhalten zu 
können). Um da keine Inkonsistenzen zu erhalten hätte ich halt gerne 
dieses schon existierende 1MHz Signal benutzt. . . .

Gruß
Maik

[Roger S. (edge)]

Mark wrote:
> versuchs dochmal so:
> es gibt 2 Taktwelten, C1 = 1MHz, C2 = 50 MHz
> [...]

Es sieht so aus als gibts da eine 50MHz Taktquelle von dem alles 
abgeleitet wird, mit dem Controller ist wohl das FPGA gemeint. Somit ist 
das Beste fuer Maik dem Ratschlag von Falk zu folgen.
Extra einen langsameren Takt zu generieren und dann aus dieser Domaene 
die Signale wieder in die 50MHz reinsynchronisieren ist voelliger 
Bloedsinn.

Cheers, Roger

[Maik R. (kiamur)]

@Mark: Danke für den Beitrag. Das muss ich wohl erst mal genauer unter 
die Lupe nehmen, bis ich es verstanden habe . . . . Hört sich aber 
interessant an.

Gruß
Maik

[Maik R. (kiamur)]

@roger: Nein, mit dem Controller ist NICHT der FPGA gemeint!

Der Controller ist das TOP-LEVEL-ENTITY in meinem Design, in dem alle 
Takte generiert werden, die im Design benötigt werden.
Damit dann alle eingebetteten Entities die SELBEN Takte beutzen, wollte 
ich eben dem Schieberegister Entity den 50MHz- und den 1MHZ-Takt vom 
Controller (ich habe das TOP-Level Entity halt Controller genannt) auf 
die Ports knallen, damit ich jetzt nicht wieder ein neues 1MHZ-Signal im 
eingebetteten Entity generieren muss, obwohl doch schon eins im Design 
existiert . . . .

Wow, ich muss mich ja ganz schön undeutlich ausdrücken, wenn ihr solche 
Verständnisprobleme habt. . . .

Gruß
Maik

[Roger S. (edge)]

Maik Ritter wrote:

> @roger: Nein, mit dem Controller ist NICHT der FPGA gemeint!
> [...]
> Der Controller ist das TOP-LEVEL-ENTITY in meinem Design,
> [...]
> (ich habe das TOP-Level Entity halt Controller genannt)

ja bravo! genau das habe ich ja gemeint, es geht ja primaer darum wo 
alle deine Takte herkommen. Nach deinem ersten post zu urteilen kann der 
shift clock von extern kommen, nach deinen letzten Beschreibungen 
generierst du den jedoch im FPGA selbst.

Desshalb auch  der Rat von mir. Lass das generieren von irgendwelchen 
Takten, sondern NUTZE CLOCK ENABLES.
Du kannst dass 1us CE in deiner Controller entity einmal generieren und 
dann an die anderen entities weiterreichen, somit ist alles perfekt 
synchron.

Im Prinzip schaffst du dir Probleme die du eigentlich garnicht hast!

Cheers, Roger

[Mark (Gast)]

Hallo Maik,

also offenbar leitest Du alles aus dem 50MHz Takt ab. Dann ist die
Synchronisation - wie von mir vorgeschlagen - nicht nötig. Generier Dir 
in der Top-Level Entity das 1MHz Ena-Signal und führe es in alle Module 
wo es gebraucht wird, dann hast Du ein sauberes Taktkonzept.

[Volker (Gast)]

Falk wrote:

process(clk50M)
begin
  if rising_edge(clk50M) then
    if cnt_1M=0 then
      cnt_1M <= 0+49;
      ce_1M <= '1';
    else
      cnt_1M <= cnt_1M +1;
      ce_1M <='0';
    end if;
  end if;
end process;

Kann mir das mal jemand erläutern, vielleicht habe ich auch nur einen 
schlechten Tag, ab ich verstehe nicht, wann cnt_1M 0 werden soll.

Danke

Volker

[Falk B. (falk)]

@ Volker (Gast)

Jaja, man sollte hin und wieder mal bissel langsamer arbeiten, dafür 
gründlicher  . . . :-(
Sollte ein Minus sein

process(clk50M)
begin
  if rising_edge(clk50M) then
    if cnt_1M=0 then
      cnt_1M <= 0+49;
      ce_1M <= '1';
    else
      cnt_1M <= cnt_1M -1;
      ce_1M <='0';
    end if;
  end if;
end process;

MFG
Falk