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:
1
entityshift_register_p2is
2
port(fast_clk:instd_logic;
3
shift_clk:instd_logic;
4
data_in:instd_logic_vector(10downto0);
5
data_out:outstd_logic_vector(10downto0)
6
);
7
endentityshift_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
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.
@ 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
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:
1
process(fast_clk)
2
begin
3
if(fatst_clk'eventandfast_clk='1')then
4
if(conv_integer(sr(9)(10downto7))=1)then
5
counter<=counter+1;
6
endif;
7
if(counter=33333)then
8
counter<=0;
9
endif;
10
endif;
11
endprocess;
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
@ 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
@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:
>>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
clk_slow_en <= '1' when (this_slow_clk = '1' and last_slow_clk = '0') else '0';
15
16
--Hier ein langsamer Prozess:
17
process(CLK_FAST)
18
begin
19
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.
@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 . . .
@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 . . . .
@ 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
>>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
@ 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
>>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 .
. .
@ 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
>>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
@ 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
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 !
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
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
@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
@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
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
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.
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
@ 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