CLOCK_SIGNAL constraint

achso, folgende Zeile hatte ich statt der 3. oben auch schon probiert:

1

attribute clock_signal of clk_geteilt : signal is "yes";

Klang nach der Warnung nach zu urteilen auch logischer, weil dieses
Signal ja das durch eine Kombinatorik erzeugte ist. Funzte trotzdem
nicht.

Grüße
T.M.

Hab jetzt was im Design geändert und die Warnung is weg :-)
Nur noch:
"...INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not
automatically buffered by XST with BUFG/BUFR resources. Please use the
buffer_type constraint in order to insert these buffers to the clock
signals to help prevent skew problems..."
aber das dürfte nicht so schlimm sein, oder?

Grüße
T.M.

Hallo T.M.,

prinzipiell sollte man Clock Signale nicht einfach runtertakten, es sei
denn man nutzt dafür vorgesehene PLLs oder DCMs oder so. Das Problem ist
nämlich, dass Dein erzeugtes Clock-Signal nicht als solches erkannt
wird, und deshalb auch kein Clock-Netz verwendet wird. D.h. Du bekommst
Laufzeitunterschiede, die gerade bei einem Clock-Signal net so toll
sind.

Probier's doch mal anders. Lege sowohl Dein generiertes Signal als
auch den ursprünglichen Clock an Deine State Machine an. Vorausgesetzt
die High-Phase vom runtergeteilten Clock ist max. 1 Orginal-Clock-Takt
lang (z.B. wenn Du die Frequenz nur durch 2 geteilt hast, ansonsten
musst Du das Signal halt anpassen), kannst Du das generierte Signal als
Clock-Enable verwenden. Alles klar?

Gruß
Ines

Eine andere Möglichkeit ist noch alle FF mit dem selben Takt zu
betreiben und die FF, die mit dem niedrigeren Takt laufen sollen mit
einem Enable zu versehen. Wobei das Enablesignal von einem Taktteiler
generiert wird.

Gruß Jörn

Enable mache ich so

1

if clk'event and clk = '1' then

2

  if clk_enable = '1' then

3

    FF_aus <= FF_ein;

4

  end if;

5

end if;

Sehe ich das richtig?

Ja!

Ines