Signalübergabe bei zwei PLL Takten

[Tim (Gast)]

Vielleicht ist die Frage trivial, aber so richtig bin ich aus anderen 
Beiträgen nicht schlau geworden.

Ich habe eine PLL/DCM die mir beispielsweise einen 50 und 100 MHz Takt 
liefert. Nun möchte ich ein Signal auf die schnellere Taktdomäne senden.

Kann ich es einfach rüberreichen? wenn sig50 startet, kommt dann sig100a 
oder sig100b heraus? oder kann man es nicht sagen? Wichtig ist für 
taktgenau zu sagen, wann das Signal gesampelt wurde.

clk_50  |^^^^^|_____|^^^^^|_____|^^^^^|_____|^^^^^|_____
sig50   ____________|^^^^^^^^^^^|_______________________

clk_100 |^^|__|^^|__|^^|__|^^|__|^^|__|^^|__|^^|__|^^|__

sig100a _____________|^^^^^^^^^^^|______________________
sig100b __________________|^^^^^^^^^^^|_________________

process(clk_100)
begin
 if rising_edge(clk_100) then
   sig100 <= sig50;
 end if;
end process;

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

Es kommt sigB heraus, weil (bzw. wenn) das sig50 als Reaktion auf clk_50 
ja so gar nicht existiert. Das Bild müsste so aussehen:

         _____       _____       _____       _____       
clk_50  |     |_____|     |_____|     |_____|     |_____
                      ___________
sig50   _____________|           |_______________________

         __    __    __    __    __    __    __    __    
clk_100 |  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__

                            ___________
sig100b ___________________|           |_________________

[Tim (Gast)]

Folge ich damit richtig, dass man davon ausgehen kann, dass clk_100 auch 
keinen unbekannten skew durch das Routing bekommt?
Es wird also sicher gestellt, dass clk_100 sich nicht verzögert und 
damit auch nicht eine Flanke vorher das Datum übernimmt?

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

Tim schrieb:
> Es wird also sicher gestellt, dass clk_100 sich nicht verzögert und
> damit auch nicht eine Flanke vorher das Datum übernimmt?
Wenn du das der Toolchain mit der passenden Verdrahtung und 
entsprechenden Constraints mitteils, dann ja.

> dass clk_100 auch keinen unbekannten skew durch das Routing bekommt? Es
> wird also sicher gestellt, dass clk_100 sich nicht verzögert
Das sind die Grundlagen eines synchronen Designs...

[Duke Scarring (Gast)]

Tim schrieb:
> Folge ich damit richtig, dass man davon ausgehen kann, dass clk_100 auch
> keinen unbekannten skew durch das Routing bekommt?
Da Du den DCM erwähnt hast, gehe ich davon aus, das die Xilinx-Tools zum 
Einsatz kommen. Dort erzeugt das Tool automatisch abgeleitete 
Constraints.
Daher kenn das Tool auch den Skew und die zulässigen Setup- und 
Hold-Zeiten.

Duke

[Tim (Gast)]

Lothar M. schrieb:
> Das sind die Grundlagen eines synchronen Designs...

leider haben mich andere Meinungen verunsichert.

Natürlich sind zwei Punkte wichtig:
* ob die Simulation/Modell dies unterstützt
* ob der Synthes/P&R Flow dies unterstützt

Bei Ersteren scheint man wohl manchmal über die Delta-Delays zu 
stolpern. Wie z.b. hier 
http://www.fpgarelated.com/showthread/comp.arch.fpga/80535-1.php

laut link:
wenn das Modell unterschiedliche Delta-Zeiten liefert, kann ein 
"shoot-through" wie bei sig100a entstehen.

Ein Test der DCM in Vivado2015.2 zeigt jedoch bei mir einsauberes 
Verhalten.

Demnach sind beide Punkte in Ordnung.

Vielen Dank für die Hilfe.

[FPGA-Ingenieur (Gast)]

Die Simulation ist hier mit Vorsicht zu genießen, weil sie den Jitter 
nicht nachstellt. Da gibt es immer mehrere Kombinationen. Ich würde den 
100er um 90 Grad verstellen, damit die Taktflanken nicht beieinander 
sind. Dann hast Du engere, aber saubere Verhältnisse. Signalübergabe mit 
Synchronizer.

[Tim (Gast)]

FPGA-Ingenieur schrieb im Beitrag #4344093:
> Die Simulation ist hier mit Vorsicht zu genießen, weil sie den
> Jitter
> nicht nachstellt. Da gibt es immer mehrere Kombinationen. Ich würde den
> 100er um 90 Grad verstellen, damit die Taktflanken nicht beieinander
> sind. Dann hast Du engere, aber saubere Verhältnisse. Signalübergabe mit
> Synchronizer.

Das beißt sich wieder mit der oberen Aussage, dass man sich bei der 
phasengleichen Anordnung darauf verlassen kann.

Die Verhaltensimulation stellt ja auch keine FF und Gatterdelays dar.

Ich wäre jetzt davon ausgegangen, dass der Jitter in der 
clock_uncertainty mit berücksichtigt wird und das Routing 
gegebenenfalls, das Datum oder den Clock verzögert. So kenne ich es 
zumindest bei einer einzelnen Taktdomän.

Das wären jetzt doch zwei verschiedene Herangehensweisen.