Forum: FPGA, VHDL & Co. Clock im Spartan-II


von Heinrich H. (Firma: Ich.AG) (hhanff)


Lesenswert?

Hallo!

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???
1
-- purpose: Buffer the data for one load_clk cycle.
2
-- type   : sequential
3
-- inputs : load_clk, rst_load_clk
4
-- outputs: 
5
  data_buf_proc : process (load_clk, rst_load_clk)
6
  begin  -- process data_out
7
    if rst_load_clk = '0' then          -- asynchronous reset (active low)
8
      load_clk_event <= '0';
9
    elsif load_clk'event and load_clk = '1' then  -- rising clock edge
10
      if load_n = '0' then
11
        load_clk_event <= not load_clk_event;
12
      end if;
13
    end if;
14
  end process data_buf_proc;

von Mathi (Gast)


Lesenswert?

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

von Heinrich H. (Firma: Ich.AG) (hhanff)


Lesenswert?

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
1
rising_edge(load_clk)
ist mir bekannt, wird von mir aber nicht verwendet, weil Emacs beim 
erstellen eines neuen Prozesses immer den veralteten aber nicht falschen 
Code
1
load_clk'event and load_clk = '1'
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.... ;)

von glück (Gast)


Lesenswert?

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.

von Stefan Salewski (Gast)


Lesenswert?

>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?

von Falk B. (falk)


Lesenswert?

@ 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

von Heinrich H. (Firma: Ich.AG) (hhanff)


Lesenswert?

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

von Mathi (Gast)


Lesenswert?

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

von Mathi (Gast)


Lesenswert?

Ich seh gerade, dass ein Register schon durch load_clk_sig realisiert 
ist. Also fehlt nur noch ein Register...

von Thomas H. (mac4ever)


Lesenswert?

glück wrote:
1
load_clk_sig <= load_clk;
2
load_clk_old <= load_clk_sig;

Sind bei mir zwei Register ...

von Mathi (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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

von Heinrich H. (Firma: Ich.AG) (hhanff)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

@ 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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.