Eigene Clock auf Clocktree legen?

[S. K. (quaxx)]

Moin,

ich benötige für ein Projekt verschiedene Taktgeschwindigkeiten. Mein 
Standardtakt hat eine Frequenz von 100MHz.
Für diverse Counter erzeugt mir der IP-Core "Clock-Wizard" einen 
zusätzlichen 300MHz Takt.

Nun kommt das Problem: Eine Komponenten benötigt einen 140kHz-Takt. 
Diesen kann ich nicht über den Clock-Wizard erzeugen lassen. Also habe 
ich über einen Counter und Comparewert einen 140kHz selber erzeugt. 
(nicht 100%ig diese Freqeunz, aber nahe genug dran, für meine 
Anwendung):

 Zaehler_140kHz_Takt: process(clk300)
 begin
    if rising_edge(clk300) then
        if cnt_140 < 2140   then          
            cnt_140 <= cnt_140 +1;
        else
            cnt_140 <= 0;           
        end if;   
     end if;
 end process; 
 
Takterzeugung_140kHz: process(cnt_140)      
 begin   
    if cnt_140 < 2140/2 then
        clk140 <= '0';
    else
        clk140  <= '1';
    end if;
 end process;

Nun ist das Problem, dass das Timing nicht hin haut. Dies wird vorallem 
daran liegen, dass mein selbererzeugter Takt als Signal anliegt, aber 
nicht auf dem Clocklayer (Clock tree?) geroutet wird.


Meine Frage ist nun:
Kann ich dem Implementierungstool die Info geben, dass hier "clk140" auf 
dem Clocklayergeroutet werden soll? Oder muss ich dies Erzeugung 
komplett anders gestalten?
Ich habe etwas über "BUFGCE" und dem constraint "create_generate_clock" 
gelesen, bin aber nicht wirklich schlau daraus geworden, wie genau 
dieses implementiert wird.

Habt ihr da eine Idee?

[Turmuhr Schätzer (Gast)]

S. K. schrieb:
> Ich habe etwas über "BUFGCE" und dem constraint "create_generate_clock"
> gelesen, bin aber nicht wirklich schlau daraus geworden, wie genau
> dieses implementiert wird.

um ein signal auf den clocktree zu bekommen musst du es an die 
"schnittstelle" zum clocktree legen. Diese Schnittstelle ist der BUFG 
(und seine Varianten). Du musst also den BUFG instanziieren.

--

>"Nun kommt das Problem: Eine Komponenten benötigt einen 140kHz-Takt."
Takt ist nicht gleich takt, deine Komponente braucht sicherlich nur ein 
140 kHz Puls. das kannst du auch mit counter erzeugen und rausgeben. die 
clock-constraints und der clock-tree sind bei einem solchen 
"Pseudo"-Takt unnötig.

[Hans kanns (Gast)]

Turmuhr Schätzer schrieb:
> Takt ist nicht gleich takt, deine Komponente braucht sicherlich nur ein
> 140 kHz Puls.

Macht man bekannterweise mit enable.

Andererseits lassen sich aus 100MHz sehr wohl 140kHz als echten Takt aus 
einer PLL erzeugen, indem man mit 7 multiplizert und dann durch 500 
teilt, wie eine einfache ->Primfaktorzerlegung aus Klasse 8 ergibt.

Mir graust es immer wieder zu sehen, dass solche einfachen Dinge nicht 
klar sind, bez. Leutz. die das nicht drauf haben, FPGAs machen wollen.

[S. K. (quaxx)]

Turmuhr Schätzer schrieb:

> um ein signal auf den clocktree zu bekommen musst du es an die
> "schnittstelle" zum clocktree legen. Diese Schnittstelle ist der BUFG
> (und seine Varianten). Du musst also den BUFG instanziieren.


Alles klar, habs nun hinbekommen und mein Problem hat sich wie erhofft 
dadruch gelöst



Hans kanns schrieb:
> Turmuhr Schätzer schrieb:

> Mir graust es immer wieder zu sehen, dass solche einfachen Dinge nicht
> klar sind, bez. Leutz. die das nicht drauf haben, FPGAs machen wollen.

Naja irgendwann muss man mit sowas anfangen und sich einarbeiten, dann 
kennt man die offensichtlichen Lösungen evtl noch nicht. Wenn jeder 
alles können würde, dann bräuchte man keine Foren mehr.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Die Frage ist auch, ob man nicht mit einem 140 kHz Clock Enable arbeiten 
moechte? Dazu noch passende Multicycle Constraints, dann freut sich auch 
der Router. :-)

[S. K. (quaxx)]

Hatte ich mir anfangs auch mal überlegt, aber es hat sich 
herausgestellt, dass ich auch die fallende Flanke des Clock benötige. 
Daher hatte ich mich gegen den Enable entschieden ;)

[Christophz (Gast)]

Tobias B. schrieb:
> Die Frage ist auch, ob man nicht mit einem 140 kHz Clock Enable arbeiten
> moechte? Dazu noch passende Multicycle Constraints, dann freut sich auch
> der Router. :-)

S. K. schrieb:
> Hatte ich mir anfangs auch mal überlegt, aber es hat sich
> herausgestellt, dass ich auch die fallende Flanke des Clock benötige.
> Daher hatte ich mich gegen den Enable entschieden ;)

Dann halt ein 280 kHz Clock Enable oder zwei Enables mit je 140 KHz?

Was spricht gegen eine solche Lösung?

[S. K. (quaxx)]

Christophz schrieb:
> Dann halt ein 280 kHz Clock Enable oder zwei Enables mit je 140 KHz?
>
> Was spricht gegen eine solche Lösung?

Eigentlich garnichts, habe ich nicht drüber nachgedacht. Irgendwann 
sieht man den Wald vorlauter Bäumen nicht mehr^^

Werde ich für die Zukunft im Hinterkopf behalten, nun läuft es alles 
ohne Probleme mit dem Takt auf dem clock tree.

[Mampf F. (mampf)]

S. K. schrieb:
> Nun ist das Problem, dass das Timing nicht hin haut. Dies wird vorallem
> daran liegen, dass mein selbererzeugter Takt als Signal anliegt, aber
> nicht auf dem Clocklayer (Clock tree?) geroutet wird.

Wenn ich sowas lese, vermute ich einen gedanklichen Fehler ...

Weiter oben wurde ja schon angemerkt, dass du vmtl keinen Clock mit 
140kHz brauchst, sondern nur einen Pulse.

Den würdest du dann Taktsynchron zu den 300kHz so erzeugen und nutzen 
zB:

Zaehler_140kHz_Takt: process(clk300)
 begin
    if rising_edge(clk300) then
        clk140k <= '0';
        if cnt_140 < 2140   then          
            cnt_140 <= cnt_140 +1;
        else
            clk140k <= '1';
            cnt_140 <= 0;           
        end if;   
     end if;
 end process; 

process(clk300)
begin
  if rising_edge(clk300) then
    if clk140k='1' then
      -- irgendwas, was 140kHz clock braucht
    end if;
  end if;
end process;

[Edi M. (Gast)]

S. K. schrieb:
> dass ich auch die fallende Flanke des Clock benötige.

Du weißt inzwischen, dass das kein Takt ist (und eine "clock" schon gar 
nicht)?