|
Anzeige
|
Clock im Spartan-IIHallo! ich benutze ein Spartan II FPGA von Xilinx und möchte Daten die ich von einem uC erhalte in ein RAM schreiben. Dazu generiert der uC einen "Clock". Dieser "Clock" hat KEIN Duty Cycle von 50:50 und hat auch KEINE gleichbleibende Frequenz. Meine Frage: Kann ich diesen "Clock" dann der Sensitivity List eines Prozesses verwenden so wie ich es in folgendem Beispiel getan habe???
Gast
#743344
Ja, Du darfst den Clock ganz normal verwenden. ABER WIE GENERIERST DU DEN CLOCK? Es ist ganz wichtig das der NICHT durch kombinatorischer Logik erzeugt wird!!! Poste doch mal Deinen Code der den Clock generiert. Und anstatt load_clk'event and load_clk = '1' verwende besser rising_edge(load_clk). Das erhöht die Übersichtlichkeit. Gruß, Mathi Danke für die schnelle Antwort. Der uC erzeugt den Clock. Er geht dann auf einen Pin vom FPGA und wird von mir wie oben gezeigt verwendet. Wenn ich richtig liege wird der Clock dann ja nicht durch kombinatorische Logik erzeugt und kann von mir ganz normal verwendet werden, obwohl er weder konstant, noch einen gleichbleibenden Duty Cycle hat. Richtig? Der Syntax
ist mir bekannt, wird von mir aber nicht verwendet, weil Emacs beim erstellen eines neuen Prozesses immer den veralteten aber nicht falschen Code
erzeugt und ich mir nicht die Mühe machen will das jedesmal zu ändern. Sicherlich kann man das auch bei Emacs einstellen... aber naja... auch die Mühe habe ich mir nicht gemacht.... ;)
Gast
#743434
Ob rising_edge(load_clk) oder load_clk'event and load_clk = '1' spielt
für die Synthese keine Rolle. Unterschiede gibt es allerdings (in
zugegeben seltenen Fällen) bei der Simulation.
Eine andere Möglichkeit, deinen externen Clock zu verwenden:
clk_int: fpga-interner clock, sehr viel schneller als uc-clock
process(clk_int, rst)
begin
if rising_edge(clk_int)
if reset
... bla bla ...
elsif
load_clk_sig <= load_clk;
load_clk_old <= load_clk_sig;
if (load_clk_sig = '1' and load_clk_old = '0') then
... aktion ...
end if;
end if;
end if;
end process;
Sollte so am stabilsten laufen.
Gast
#743443
>Der uC erzeugt den Clock. Er geht dann auf einen Pin vom FPGA und wird >von mir wie oben gezeigt verwendet. Wenn ich richtig liege wird der >Clock dann ja nicht durch kombinatorische Logik erzeugt und kann von mir >ganz normal verwendet werden, obwohl er weder konstant, noch einen >gleichbleibenden Duty Cycle hat. Richtig? Der Clock. Kann man das nicht schöner ausdrücken? Takt oder Clock-Signal vielleicht? Und wenn Frequenz und Tastverhältnis (Duty-Cycle) stark variieren -- sollte man das dann überhaupt "Clock" nennen, oder lieber neutral von einem Signal sprechen? @ Stefan Salewski (Gast) >Der Clock. >Kann man das nicht schöner ausdrücken? >Takt oder Clock-Signal vielleicht? ACK! >Und wenn Frequenz und Tastverhältnis (Duty-Cycle) stark variieren -- >sollte man das dann überhaupt "Clock" nennen, oder lieber neutral von >einem Signal sprechen? Dan ist es eher ein Strobesignal. MFG Falk glück wrote: > Ob rising_edge(load_clk) oder load_clk'event and load_clk = '1' spielt > für die Synthese keine Rolle. Unterschiede gibt es allerdings (in > zugegeben seltenen Fällen) bei der Simulation. > > Eine andere Möglichkeit, deinen externen Clock zu verwenden: > > clk_int: fpga-interner clock, sehr viel schneller als uc-clock > > process(clk_int, rst) > begin > if rising_edge(clk_int) > if reset > ... bla bla ... > elsif > load_clk_sig <= load_clk; > load_clk_old <= load_clk_sig; > if (load_clk_sig = '1' and load_clk_old = '0') then > ... aktion ... > end if; > end if; > end if; > end process; > > Sollte so am stabilsten laufen. Die Antwort war genau das was ich gesucht habe.... Du glaubst ja gar nicht was Du mir für einen Gefallen getan hast... Im FPGA hab ich mir mit Hilfe der DLL und dem Systemclock mit 27MHZ einen Takt mit 108MHz generiert und mit diesem den Burst oder "clock" vom uC abgetastet so wie Du's oben beschrieben hast... Jetzt erstmal Bett gehen und Morgen weiterfreuen.... Gruß aus Bremen, Hendrik
Gast
#743560
Achte aber darauf das Du das Signal load_clk erst in die Taktdomäne des clk_int einsynchronisieren musst. Sonst kann es zu metastabilen Zuständen kommen. Einfach zwei Register davorschalten. Gruß, Mathi
Gast
#743561
Ich seh gerade, dass ein Register schon durch load_clk_sig realisiert ist. Also fehlt nur noch ein Register... glück wrote:
Sind bei mir zwei Register ...
Gast
#743749
Die Abfrage geschieht aber auf load_clk_sig load_clk_old = '0'. load_clk_old geht damit durch zwei Register. Aber load_clk_sig nicht. @ Hendrik H. (Firma MARUM/RCOM) (hhanff) >Im FPGA hab ich mir mit Hilfe der DLL und dem Systemclock mit 27MHZ >einen Takt mit 108MHz generiert und mit diesem den Burst oder "clock" >vom uC abgetastet so wie Du's oben beschrieben hast... Naja, man kann es auch übertreiben. Solche Sachen mit Überabtastung machen ab einer bestimmten Frequenz nur noch wenig Sinn. und 27 MHz würde ich da schoin dazuzählen. Warum nicht ganz normal mit den 27 MHz die Daten eintakten? MFG Falk Falk Brunner wrote: > Naja, man kann es auch übertreiben. Solche Sachen mit Überabtastung > machen ab einer bestimmten Frequenz nur noch wenig Sinn. und 27 MHz > würde ich da schoin dazuzählen. Warum nicht ganz normal mit den 27 MHz > die Daten eintakten? > > MFG > Falk Die 108MHz brauche ich eh für eine andere Aufgabe. Daher ist es denke ich kein Problem diesen Takt auch zu verwenden, oder? Gruß h @ Hendrik H. (Firma MARUM/RCOM) (hhanff) >Die 108MHz brauche ich eh für eine andere Aufgabe. Daher ist es denke >ich kein Problem diesen Takt auch zu verwenden, oder? Doch. Denn das asynchrone Eintakten eines Datenbusses ist nicht so trivial wie es aussieht. Und allein mit zwei FlipFlops zum Abtasten und Abfangen metastabiler Zustände ist es nicht getan. Wie gesagt, was spricht gegen ein ganz normales Eintakten der Daten direkt mit dem Takt/Strobe vom uC? Gar nichts. MFG Falk Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
