Verständnisfrage Einsynchronisieren bei mehreren Taktdomains

[Cihan K. (lazoboy61)]

Hallo,

habe wieder mal einige Fragen bezüglich des Einsynchronisieren von 
asynchronen Signalen. Die ganzen Threads wo das Einsynchronisieren 
diskutiert wurden, habe ich schon gelesen, doch komme grad mit meinem 
Problem noch nicht ganz so klar.

Zu meinem Problem:
Es ist ja bekanntlich das asynchrone Signale über mind. 2 FF 
einsynchronisiert werden müssen, Bsp. ext. Signale die getriggert 
müssen. Dann gibt es noch Fälle, wo man mehrere Taktdomäne hat, die 
miteinander "kommunizieren" müssen. Wenn ich z.B. einen STD_LOGIC_VECTOR 
von einem Taktdomän zum anderen bringen will, mach ich das generel nur 
mit einem FIFO mit 2 CLK Eingängen. Wenn nun ein Signal(1-Bit) von einer 
langsameren Taktebene in eine schnellere hingeführt wird, dann 
synchronisiere ich diesen ebenfalls mit 2 FF ein, bevor ich ihn abfrage. 
Aber manchmal habe ich nun den Fall, wo Signale von der schnelleren 
Taktebene zur langsameren geführt wird und hier in diesem Punkt bin ich 
verwirrt. Muss ich dieses Signal evtl. als "Spike" betrachten? Es kann 
ja sein das er nur für eine Periode des schnellen Taktes aktiv ist, 
sodass der langsamere ihn nicht mehr sieht. Wie müsste ich hier 
einsynchroniseren?

1. Überlegeung:
Auf der Seite von Lothar gibt es ein kleines Bsp. zum Einsynchroniseren 
von Spikes.

http://www.lothar-miller.de/s9y/categories/19-SpikePuls

Leider funktioniert dieses Bsp. bei mir in der Simulation nicht. Hat 
mich äußerst gewundert, aber wenn ich einen Spikein Impuls setze, wird 
dieser nicht erkannt. Es wird aber im RTL die gleiche Schaltung 
dargestellt.

Abgesehen von diesem Bsp. (würde mich auch interessieren warum es nicht 
funkionierte bei mir), wie sollte man nun Signale von schnelleren 
Taktebenen in langsamere einsynchronisieren?

Eine weitere Frage hätte ich noch. Ich habe in meinem Design eine PLL 
die als Input eine 20MHz Clock bekommt, mir dann wieder eine 20MHz Clock 
und eine 140MHz Clock als OUTPUT rausführt. Wenn ich nun das 
"LOCK"-Signal von der PLL verwenden will, mit welcher Taktrate 
(20MHz[Input], 20MHz[OUTPUT] oder 140MHz[OUTPUT]) ist dieser synchron?

Freu mich schon auf eure Antworten.
Danke im voraus

lg Cihan

[Duke Scarring (Gast)]

Cihan Kalayci schrieb:
> Aber manchmal habe ich nun den Fall, wo Signale von der schnelleren
> Taktebene zur langsameren geführt wird und hier in diesem Punkt bin ich
> verwirrt. Muss ich dieses Signal evtl. als "Spike" betrachten? Es kann
> ja sein das er nur für eine Periode des schnellen Taktes aktiv ist,
> sodass der langsamere ihn nicht mehr sieht. Wie müsste ich hier
> einsynchroniseren?
Du kannst natürlich nur so schnell Daten senden, wie die langsame 
Taktdomäne noch verarbeiten kann. Entweder Du garantierst das per Design 
(einfacher, aber nicht bulletproof) oder Du verwendest Handshakesignale.
Bei Handshakes bietet es sich an die Information nicht als Puls zu 
übertragen, sondern im Flankenwechsel, als Toggle. Das funktioniert in 
beide Richtungen schnell -> langsam und langsam -> schnell.

Duke

[Cihan K. (lazoboy61)]

Cihan Kalayci schrieb:
> 1. Überlegeung:
> Auf der Seite von Lothar gibt es ein kleines Bsp. zum Einsynchroniseren
> von Spikes.
>
> http://www.lothar-miller.de/s9y/categories/19-SpikePuls
>
> Leider funktioniert dieses Bsp. bei mir in der Simulation nicht. Hat
> mich äußerst gewundert, aber wenn ich einen Spikein Impuls setze, wird
> dieser nicht erkannt. Es wird aber im RTL die gleiche Schaltung
> dargestellt.

Das Bsp. von Lothar funktioniert, wenn ich aus
rising_edge(spikein) ein spikein = '1' AND spikein'EVENT mache.

Müsste man es ähnlich wie Lothars Bsp. machen oder gibt es bessere 
Lösungen. Wie macht ihr es immer.

Cihan

[Cihan K. (lazoboy61)]

Duke Scarring schrieb:
> Cihan Kalayci schrieb:
>> Aber manchmal habe ich nun den Fall, wo Signale von der schnelleren
>> Taktebene zur langsameren geführt wird und hier in diesem Punkt bin ich
>> verwirrt. Muss ich dieses Signal evtl. als "Spike" betrachten? Es kann
>> ja sein das er nur für eine Periode des schnellen Taktes aktiv ist,
>> sodass der langsamere ihn nicht mehr sieht. Wie müsste ich hier
>> einsynchroniseren?
> Du kannst natürlich nur so schnell Daten senden, wie die langsame
> Taktdomäne noch verarbeiten kann. Entweder Du garantierst das per Design
> (einfacher, aber nicht bulletproof) oder Du verwendest Handshakesignale.
> Bei Handshakes bietet es sich an die Information nicht als Puls zu
> übertragen, sondern im Flankenwechsel, als Toggle. Das funktioniert in
> beide Richtungen schnell -> langsam und langsam -> schnell.
>
> Duke

Du meinst also, dass ich z.B. bei der pos. Flanke meines Signals(der 
schnelleren Taktebene) ein anderes Signal nur invertiere und dieses 
immer in den andere Taktdomänen (egal ob schneller oder langsamer) 
Abfrage? Ich müsste aber dieses erzeugte Signal doch auch 
einsynchroniseren, oder?

Cihan

[Duke Scarring (Gast)]

Cihan Kalayci schrieb:
> Ich müsste aber dieses erzeugte Signal doch auch
> einsynchroniseren, oder?
Ja, dann wenn Du setup- und hold-time-Verletzungen nicht ausschließen 
kannst.

Duke

[Cihan K. (lazoboy61)]

Duke Scarring schrieb:
> Cihan Kalayci schrieb:
>> Ich müsste aber dieses erzeugte Signal doch auch
>> einsynchroniseren, oder?
> Ja, dann wenn Du setup- und hold-time-Verletzungen nicht ausschließen
> kannst.
>
> Duke

Danke dir für deine hilfreiche Antwort.

Eines interressiert mich aber noch stark. Zu welcher Clock ist das 
"LOCKED" Singal von einer PLL synchron? Ich will dieses Signal in 
manchen Programmteilen verwenden, um Funktionen zu sperren oder 
aktivieren.

Wie im Beitrag 1 beschrieben wurde, habe ich eine PLL die 20MHz als 
INPUT, 20MHz als OUTPUT und 140MHz als OUTPUT hat. Wenn ich jetzt das 
Datenblatt der PLL lese steht folgendes drin:
"Synchronous output that goes high when the PLL
has achieved phase alignment and frequency
matching"
Aber ebend zu was (welche Clock) synchron. Oder sollte ich dieses Signal 
asynchron betrachten und mit dem Spike-Bsp. von Lothar auf Flanke prüfen 
und damit ein anderes Signal Togglen, um dieses dann zu verwenden?

Wenn der LOCKED zur 20MHz synchron wäre, dann könnte ich es ja wie 
gewohnt über 2 FFs einsynchronisieren in den schnelleren Taktebenen. Da 
bezweifele ich aber.

Bräuchte in dieser Hinsicht noch Hilfe.

Cihan

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Cihan Kalayci schrieb:
> Das Bsp. von Lothar funktioniert, wenn ich aus
> rising_edge(spikein) ein spikein = '1' AND spikein'EVENT mache.
Dann initialisiere mal das Eingangssignal spikein in deiner Testbench 
mit '0', denn die Funktion rising_edge fragt nur noch zusätzlich auf
AND spikein'LAST='0'   ab. Und ein Übergang von 'U' nach '1' ist keine 
steigende Flanke...

> Müsste man es ähnlich wie Lothars Bsp. machen
Was denn?

Cihan Kalayci schrieb:
> Abgesehen von diesem Bsp. (würde mich auch interessieren warum es nicht
> funkionierte bei mir), wie sollte man nun Signale von schnelleren
> Taktebenen in langsamere einsynchronisieren?
Einsynchronisieren ist unabhängig von der Taktgeschwindigkeit der 
beteiligten Domänen.

[Cihan K. (lazoboy61)]

Lothar Miller schrieb:
> Cihan Kalayci schrieb:
>> Das Bsp. von Lothar funktioniert, wenn ich aus
>> rising_edge(spikein) ein spikein = '1' AND spikein'EVENT mache.
> Dann initialisiere mal das Eingangssignal spikein in deiner Testbench
> mit '0', denn die Funktion rising_edge fragt nur noch zusätzlich auf
> spikein'LAST='0' ab. Und ein Übergang von 'U' nach '1' ist /keine/
> steigende Flanke...

Ja, das ist der Grund gewesen. Jetzt funktioniert es so wie du es 
beschrieben hast.

Ist es jetzt sinnvoller Signale von schnelleren Taktebenen durch den 
Spikedetector zu erkennen und anschließend zu synchronisieren oder 
sollte man besser mit der Toggle-Methode arbeiten, so wie Duke es 
beschrieben hat?

die Frage mit dem LOCKED Signal der PLL ist für mich immernoch offen, 
ich suche schon seit ner Weile, doch die Antwort dazu finde ich nicht.

Ich hätte dazu nur eine weitere Theorie. Ich habe meine PLL als "SOURCE 
SYNCHRONOUS" eingestellt. Würde das heißen, das mein LOCKED Signal nun 
zum INPUT synchron ist? Bräuchte unbedingt Aufklärung dazu.
Danke im voraus

Cihan

[Duke Scarring (Gast)]

Cihan Kalayci schrieb:
> die Frage mit dem LOCKED Signal der PLL ist für mich immernoch offen,
> ich suche schon seit ner Weile, doch die Antwort dazu finde ich nicht.

Im Zweifelsfall würde ich davon ausgehen, daß das Signal asynchron ist.

Duke

[Cihan K. (lazoboy61)]

Duke Scarring schrieb:
> Cihan Kalayci schrieb:
>> die Frage mit dem LOCKED Signal der PLL ist für mich immernoch offen,
>> ich suche schon seit ner Weile, doch die Antwort dazu finde ich nicht.
>
> Im Zweifelsfall würde ich davon ausgehen, daß das Signal asynchron ist.
>
> Duke

Das wäre auf jeden Fall Nummer sicher.
Dann ist es ja eigentlich schlecht dokumentiert von Xilinx, ohne konkret 
etwas zu behaupten. Schade eigentlich.

Vielleicht weiss es ja jemand, warten wir mal ab.

Danke an alle Beteiligten für ihre Beiträge.

Cihan

[Cihan K. (lazoboy61)]

So, hab jetzt mal die Logik von Lothar genommen und habe mir mal den 
Spikedetector für meinen LOCKED Signal meiner PLL vorbereitet.

Da ich nicht weiss mit welcher Clock das LOCKED Signal synchron ist, 
habe ich es asynchron betrachtet und über die pos. und neg. 
Flankenerkennung dank 2er Merker-FF detektiert und anschließend 
einsynchronisiert. Über einen kleinen Multiplexer wird dann der Ausgang 
Spikeout(Bsp. zum Resetten von Modulen oder deaktivieren von bestimmten 
Funktionen) erzeugt.

Hier der Quellcode:

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;

ENTITY Spikedetector IS
  PORT ( 
      clk                          :  IN    STD_LOGIC;
      spikein                      :  IN    STD_LOGIC:= '0';
      spikeout                      :  OUT  STD_LOGIC
      );
END Spikedetector;

ARCHITECTURE BEHAVIORAL OF Spikedetector IS

SIGNAL  sr0_p                        :      STD_LOGIC := '0';
SIGNAL  sr1_p                        :      STD_LOGIC := '0';
SIGNAL  merkin_p                      :      STD_LOGIC := '0';

SIGNAL  sr0_n                        :      STD_LOGIC := '0';
SIGNAL  sr1_n                        :      STD_LOGIC := '0';
SIGNAL  merkin_n                      :      STD_LOGIC := '0';

BEGIN

-- Merker-FF
PROCESS(sr1_p, spikein)
BEGIN

IF (sr1_p = '1') THEN 
  merkin_p <= '0';
ELSIF (spikein = '1' AND spikein'EVENT) THEN 
  merkin_p <= '1'; 
END IF;

END PROCESS;
   
-- Merker-FF
PROCESS(sr1_n, spikein)
BEGIN

IF (sr1_n = '1') THEN 
  merkin_n <= '0';
ELSIF (spikein = '0' AND spikein'EVENT) THEN 
  merkin_n <= '1'; 
END IF;

END PROCESS;
  
-- Asynchrones Merker-FF eintakten
PROCESS(clk)
BEGIN

IF (clk = '1' AND clk'EVENT) THEN
  sr0_p <= merkin_p; 
  sr1_p <= sr0_p;
  
  sr0_n <= merkin_n; 
  sr1_n <= sr0_n;
  
  IF sr1_p = '1' THEN
    sr1_p <= '0';
    spikeout <= '1';
  ELSIF sr1_n = '1' THEN
    sr1_n <= '0';
    spikeout <= '0';
  END IF;
END IF;

END PROCESS;
  
END BEHAVIORAL;

Als Dateianhänge ist zum einen RTL-Schematic und eine kleine Simulation 
mit ISIM drin. In der Simulation habe ich 4 Beispiele drin. In den 
ersten beiden sind Spikes kleiner als eine Periode der zu 
synchronisierenden Clock, im Beispiel 3 ist es länger als eine Periode 
und in Beispiel 4 sind zwei Spikes hintereinander, jeweils kleiner als 
eine Periode. Im Bsp. 4 sieht man auch sehr gut, dass der Output nur für 
den ersten Spike erzeugt wird. Da mein LOCKED Signal eher mit Beispiel 3 
zu vergleichen wäre, sieht die Welt für mich in Ordnung aus.

Mich würde es nun interessieren, ob meine Überlegung, mein Design in 
Ordnung ist. Laut Simulation sieht alles sauber aus und ich könnte 
Spikeout als synchronen Reset benutzen. Würde mich über Feedback, bzw. 
evtl. Verbesserungen oder anderen Lösungsvorschläge sehr freuen.

Die Variante was Duke mit dem Togglen meinte kann ich auch mit dieser 
Logik realisieren, was mir aber in erster Linie nicht viel weiterhilft.
Das was als Input kommt muss bei mir auch als Output rauskommen.

Cihan

[Cihan K. (lazoboy61)]

Habe aus versehen die Signal-Namen in dem Simulationsbild 
weggeschnitten.

Hier nochmal mit Signal-Namen ;-)

sorry

Cihan

[Cihan K. (lazoboy61)]

Kein Feedback...

Ich habe es so wie oben beschrieben in mein Design eingebaut und 
funktioniert erstmal ohne jegliche Fehleranzeichen. Wäre aber weiterhin 
noch an Feedback bezüglich meiner Synchronisierung interressiert. Vllt. 
meldet sich ja noch jemand.

Danke
Cihan

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Cihan Kalayci schrieb:
> Ich habe es so wie oben beschrieben in mein Design eingebaut und
> funktioniert erstmal ohne jegliche Fehleranzeichen.
War zu erwarten. Wenn du mit deinen Simulationsergebnissen zufrieden 
bist: das Ding wird genau das tun, was die Simulation sagt.

> wird dann der Ausgang Spikeout (Bsp. zum Resetten von Modulen
Ich würde nicht wollen, dass ein Modul von einem kurzen (EMV-,ESD-)Spike 
zurückgesetzt werden würde. Ich würde da dogar eher einen Tiefpass 
reinbauen, dass das Reset-Signal mindestens 1us anliegen muss...

[Cihan K. (lazoboy61)]

Lothar Miller schrieb:
> Cihan Kalayci schrieb:
>> Ich habe es so wie oben beschrieben in mein Design eingebaut und
>> funktioniert erstmal ohne jegliche Fehleranzeichen.
> War zu erwarten. Wenn du mit deinen Simulationsergebnissen zufrieden
> bist: das Ding wird genau das tun, was die Simulation sagt.
>
>> wird dann der Ausgang Spikeout (Bsp. zum Resetten von Modulen
> Ich würde nicht wollen, dass ein Modul von einem kurzen (EMV-,ESD-)Spike
> zurückgesetzt werden würde. Ich würde da dogar eher einen Tiefpass
> reinbauen, dass das Reset-Signal mindestens 1us anliegen muss...

Das LOCKED Signal von der PLL geht ja in den Spikedetector rein. Der 
Sinn ist ja für dieses "asynchrone" Signal mit den anderen Taktdomains 
zu synchronisieren. In den obigen Beiträgen habe ich ja nach diesem 
LOCKED Signal gefragt, zu welcher Clock er von der PLL synchron ist, ob 
es der 20MHz Input, 20MHz Output oder auch der 140MHz Output ist. Wenn 
es mit den 20MHz synchron wäre, könnte ich ja in den anderen 
Taktdomains, die bei mir alle > 20MHz sind über 2 FFs synchronisieren. 
Aber wenn es mit der 140MHz synchron wäre, dann brauche ich sowas wie 
diesen Spikedetector, da alle meine anderen Taktdomains <= 100MHz sind. 
Abgesehen von Spikes, das LOCKED Signal ist entweder für eine gewisse 
Zeit(mind. > 100us) HIGH oder LOW, Spikes treten hier nicht auf. Von 
dahin passt ja das dritte Beispiel aus der Simulation ganz gut in mein 
Design rein.

Die Frage in diesem Thread war ja, wie man Signale von schnelleren in 
langesemere Taktebenen einsynchronisiert, auch wenn sie 1 Puls groß 
sind. Eine Variante war ebend die Methode mit dem Togglen und die andere 
habe ich oben vorgestellt mit dem Spikedetector. Man sollte aber hier an 
den Detector ein "normales" Signal anlegen, der zum "Reset" oder nur zum 
synchronisieren dient.

Danke nochmal hier an alle Beteiligten.

lg Cihan

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Cihan Kalayci schrieb:
> Zu welcher Clock ist das "LOCKED" Singal von einer PLL synchron?
Zum Eingangstakt. Denn nur der liegt auch zuverlässig an, wenn die 
Ausgangstakte noch nicht stabil sind.

Duke Scarring schrieb:
> Im Zweifelsfall würde ich davon ausgehen, daß das Signal asynchron ist.
In der Prxis mache ich das auch so. Denn es kann auch bei ungeregelter 
PLL durchaus ein instabiler Takt auf den Ausgängen auftauchen, der dann 
garantiert asynchron zu irgendwas anderem ist...

[Cihan K. (lazoboy61)]

Lothar Miller schrieb:
> Cihan Kalayci schrieb:
>> Zu welcher Clock ist das "LOCKED" Singal von einer PLL synchron?
> Zum Eingangstakt. Denn nur der liegt auch zuverlässig an, wenn die
> Ausgangstakte noch nicht stabil sind.

Das ist doch mal ne Aussage. D.h. eigentlich hätte ich es auch über 2 
FFs machen können, aber...

> Duke Scarring schrieb:
>> Im Zweifelsfall würde ich davon ausgehen, daß das Signal asynchron ist.
> In der Prxis mache ich das auch so. Denn es kann auch bei ungeregelter
> PLL durchaus ein instabiler Takt auf den Ausgängen auftauchen, der dann
> garantiert asynchron zu irgendwas anderem ist...

So wie ich es verstehe, ist es nicht verkehrt gewesen, wenn ich es über 
einen Detector synchronisiere, wo man dann auf jeden Fall auf der 
sicheren Seite ist.

Cihan