Forum: FPGA, VHDL & Co. Signalübergabe bei zwei PLL Takten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim (Gast)


Lesenswert?

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.

1
clk_50  |^^^^^|_____|^^^^^|_____|^^^^^|_____|^^^^^|_____
2
sig50   ____________|^^^^^^^^^^^|_______________________
3
4
clk_100 |^^|__|^^|__|^^|__|^^|__|^^|__|^^|__|^^|__|^^|__
5
6
sig100a _____________|^^^^^^^^^^^|______________________
7
sig100b __________________|^^^^^^^^^^^|_________________
1
process(clk_100)
2
begin
3
 if rising_edge(clk_100) then
4
   sig100 <= sig50;
5
 end if;
6
end process;

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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:
1
         _____       _____       _____       _____       
2
clk_50  |     |_____|     |_____|     |_____|     |_____
3
                      ___________
4
sig50   _____________|           |_______________________
5
6
         __    __    __    __    __    __    __    __    
7
clk_100 |  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__
8
9
                            ___________
10
sig100b ___________________|           |_________________

von Tim (Gast)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von Tim (Gast)


Lesenswert?

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.

von FPGA-Ingenieur (Gast)


Lesenswert?

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.

von Tim (Gast)


Lesenswert?

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.

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.