clock domain Verständnis

[L. B. (hochpass)]

Nur noch mal zum Verständnis für mich.

Wenn ich einen clock pin mit einem Oszillator am FPGA habe. Intern an 
diesem Pin 2 PLLs (Altera) betreibe, dann sind alle erzeugten Takte aus 
beiden PLLs in der gleichen clock domain und ich muss die Signale 
dazwischen nicht synchronisieren. Quartus schafft in der Timing analyse 
auch die alle Signale mit unterschiedlichen Takten zu untersuchen?

Oder sind nur alle Takte aus einer PLL synchron und durch verwenden von 
2 plls ist die phase zwischen den Plls undefiniert so dass ich 
synchronisieren muss?

Danke schon mal. Mich überkommen gerade Zeifel.

Gruß Hochpass

[Harald F. (hfl)]

Hallo Hochpass,

hast Du wirklich 2 PLLs und erzeugst damit zwei Takte gleicher Frequenz 
und Phasenlage? Und wenn ja, warum?

Grüße,
Harald

[L. B. (hochpass)]

Liegt daran, dass mehrere HW komponenten die Takte benötigen. DDR RAM, 
Prozessorlinks, Serielle links...
125 Mhz, 83,333 Mhz und 300 MHz sind gesetzt, weiterhin verwende ich 
noch 50 Mhz
Die Takte lassen sich nicht mit einer einzigen PLL erzeugen, weil sie es 
nicht packt.

Takte aus einer PLL laufen schon mal synchron und in phase, das sollte 
kein Problem sein, also synchrone clock domains. Die Synchronisation ist 
einfach denke ich.
Bei 2 Plls die aus einer Quelle gespeist wird schafft time quest die 
analyse, daher gehe ich davon aus, dass es auch synchron ist bin mir 
aber nicht sicher.

[J. S. (engineer)]

In dem Fall sind die wie asynchron zu betrachten, da zwar keine 
beliebigen Verhältnisse auftreten können, wohl aber zeitkritische. Die 
Synthese wird Dir das schon anmeckern, wenn Du von 83,3 auf 125 
übersetzen willst und die Flanken keinen Platz mehr für Kombinatorik 
lassen :-)

Um Synchstufen kommst Du nicht herum.

Alle Takte aus einer PLL hat nur den Vorteil, dass die Datenraten 
gegeneinander konstant sind / gemacht werden können, d.h. die Pakete 
laufen nicht auseinander.

Du bist also auf Datenebene synchron - auch Taktebene asynchron.

Sieh Dir die Takte in ModelSIM an und denke Dir hinter jeden 10 ns 
Kombinatorik. Dann siehst Du, was passiert.

[Hochpass (Gast)]

Zwischen 83,333 und 125 zu übertragen ist gar kein Problem. 
Periodendauer ist 12 ns bzw. 8 ns. Es bleiben wenn diese Takte synchron 
laufen immer 4 ns (250 Mhz)für die Logik zwischen den clock domains. 
Wenn man dann noch ein extra Register spendiert schafft das der FPGA 
(Stratix II) locker.

Das gleiche passiert wenn man von 50Mhz (20ns) in die 83,33 Mhz 
(12ns)und und 125 Mhz (8ns) und umgekehrt wechselt es sind immer 4 ns 
für den Fall das die Takte synchron laufen. Nur von 300 Mhz in die 
83,333 und 125 Mhz geht es nicht was verständlich ist.

So ist  meine Denke im Moment und das zeigt mir TimeQuest auch an.

[Klaus F. (kfalser)]

Synchron laufen zwischen 88.3 und 125 MHz heißt für Dich anscheinend, 
dass jede 3. Flanke zusammenfällt.
Ich weiss aber nicht, ob man sich darauf verlassen kann. Ich würde es so 
ohne weiteres nicht.

[Hochpass (Gast)]

Ja genau das heißt es für mich da beide Takte aus einer PLL erzeugt 
werden mit unterschiedlichen Zählern.

Die Takte sind "source synchronous"

[Harald F. (hfl)]

Hochpass schrieb:
> Zwischen 83,333 und 125 zu übertragen ist gar kein Problem.
> Periodendauer ist 12 ns bzw. 8 ns. Es bleiben wenn diese Takte synchron
> laufen immer 4 ns (250 Mhz)für die Logik zwischen den clock domains.

Hallo Hochpass,

der zweite Satz enthält ein "wenn" und genau das wird wohl das Problem 
sein. Nehmen wir mal an, der VCO läuft mit 1 GHz und die beiden 
Taktausgänge kommen von einem Teiler durch 12 und einem Teiler durch 8. 
Wer sagt denn, dass die Zähler zeitgleich einen Nulldurchganz erreichen. 
Es ist doch auch denkbar, dass die Nulldurchgänge um 1 ns versetzt sind, 
oder? Vielleicht kann man das aber auch durch einen Reset der PLL 
erzwingen, dass die Zähler "synchron laufen", wie du das genannt hast. 
Lies doch mal bei der Stratix PLL nach, vielleicht steht da ja was zu 
dem Thema.

Grüße,
Harald

[J. S. (engineer)]

Hochpass schrieb:
> Zwischen 83,333 und 125 zu übertragen ist gar kein Problem.

Ich glaube, ich muss mein Lehrmaterial aus den 90ern hier ins Forum 
stellen, denn seit 15 Jahren muss ich jedem Studi und Neuingenieur 
dasselbe erzählen.

Dein Problem ist nicht nur der Fall der Taktdifferenz von 1) vorn, 
sondern auch der von 2) hinten und der des 3) Zusammentreffens. Du musst 
alle Fälle beachten.

Schon die 4ns, die nach Abzug von 2xJitter bestenfalls noch 3.x ns sind, 
limitieren Dir die Schaltung. Z.B. kann für die Clocks keine 
individuelle skew genutzt werden.

Aber was ist bei scheinbar zusammenfallenden Takten?

Routing-Delay und Jitter lassen gerade bei schnellen Bausteinen einen 
Datenbus sozusagen "ausfransen". Wenn Du den genau dann samplest, wenn 
sich die Daten ändern, weil der treibende Takt nur theoretisch genau zum 
Lesenden kommt, die FFs brav verzögern, sodass der lesende Takt nur alte 
Daten bekommt, - in Wirklichkeit aber etwas zu früh dran ist und die FFs 
schon schalten, während der andere noch liest, dann bekommst Du 
garantierte Bitfehler, die zufällig mal da und dort auftauchen.

Wenn man mit nur 1 Synchstufe arbeitet, dann darf keine einzige 
Taktflanke inklusive Jitter irgendeine andere sehen, wenn man das sicher 
designen will. Ansonsten bist Du drauf angewiesen, dass die FFs 
"langsam" genug sind.

Ohne Synchstufe, als lesen aus Kombinatorik (kommt auf die Formulierung 
des Codes an) geht dann garantiert schief.

[Hochpass (Gast)]

Juergen Schuhmacher schrieb:
> Hochpass schrieb:
>> Zwischen 83,333 und 125 zu übertragen ist gar kein Problem.
>
> Ich glaube, ich muss mein Lehrmaterial aus den 90ern hier ins Forum
> stellen, denn seit 15 Jahren muss ich jedem Studi und Neuingenieur
> dasselbe erzählen.
Noch mal zum Hintergrund, ich bin kein Studi und kein Neuingenieur. Also 
mal nicht so hochnäsig Herr Schumacher ;-).
Gibts in den Unterlagen Informationen über den speziellen Fall wie PLLs 
bei Altera arbeiten und wie TimeQuest mit clocks aus einer PLL umgeht. 
Das ist eher die Fragestellung. Wenn ja, dann immer her mit den 
Unterlagen.
Fakt ist:
- TimeQest analysiert Signale mit unterschiedlichen Takten aus einer PLL
- TimeQest analysiert Signale mit unterschiedlichen Takten aus 
unterschiedlichen PLLs, wenn die beiden PLLs mit der gleichen Quelle 
gespeist werden.

> Dein Problem ist nicht nur der Fall der Taktdifferenz von 1) vorn,
> sondern auch der von 2) hinten und der des 3) Zusammentreffens. Du musst
> alle Fälle beachten.
Wenn die takte synchron laufen und timequest die Takte analysiert muss 
ich das nicht. Synchronisationstechniken zwischen synchronen und 
asynchronen clock domains sind hinlänglich bekannt.

> Schon die 4ns, die nach Abzug von 2xJitter bestenfalls noch 3.x ns sind,
> limitieren Dir die Schaltung. Z.B. kann für die Clocks keine
> individuelle skew genutzt werden.
Bekannt, macht aber nix. Der Stratix II schafft internt teilweise weit 
über 400 Mhz wenn man es clever beschreibt, also theoretisch Luft genug.

> .....

> Ohne Synchstufe, als lesen aus Kombinatorik (kommt auf die Formulierung
> des Codes an) geht dann garantiert schief.
Auch in den 90ern hat man doch an alle Ausgänge jedes Moduls Register 
gehängt um das timing zu optimierten? Also keine Kombinatorik. Und jetzt 
wieder von der Theorie zur Praxis ist die theoretische Überlegung hier 
relevant?

Sorry für schlechte Laune, es ist früh am Morgen und ich hatte noch 
keinen Kaffee

[Unbekannter (Gast)]

> Synchron laufen zwischen 88.3 und 125 MHz
DAmit fällt jeder 3./und 2. Takt zusammen. Müsste doch gehen, wenn es 
dieselbe PLL ist.

[H. G. (Gast)]

Unbekannter schrieb:
> Müsste doch gehen, wenn es
> dieselbe PLL ist.
Dies ist es nicht unbedingt, wie der TO beschreibt.

> Intern an diesem Pin 2 PLLs (Altera) betreibe, dann sind alle
> erzeugten Takte aus beiden PLLs in der gleichen clock domain
Nein, es sind verschiedene Takte unterschiedlicher Frequenz. Daher 
verschiedene Domains.

Sie laufen nicht auseinander, ok, aber sie zittern und die Taktflanken 
liegen nicht stets aufeinander, auch wenn es mathematisch so aussieht.

Somit hast Du exakt dieselben Probleme, wie zwischen FPGA und externem 
Chip, die denselben Takt haben.

Beitrag "Verständnisfrage Einsynchronisieren"

[Hochpass (Gast)]

G. H. schrieb:

> Sie laufen nicht auseinander, ok, aber sie zittern und die Taktflanken
> liegen nicht stets aufeinander, auch wenn es mathematisch so aussieht.
>
> Somit hast Du exakt dieselben Probleme, wie zwischen FPGA und externem
> Chip, die denselben Takt haben.
>

Es ist nicht exakt das gleiche Problem wie bei externen Chips:
Bei externen Chips ist die Laufzeit des Takts unbekannt, weil der Takt 
außerhalb des FPGAs läuft und damit mindestens in der Phase und Jitter 
unbekannt ist. -> Clock Netz kann nicht analysiert werden. Hier ist 
logisch dass die Clock Domains als asynchron gelten müssen

Bei 2 Takten die aus einer PLL kommen ist dem Tools die Herkunft bekannt 
und der Jitter und Phase der Takte untereinander ebenso (jedenfalls 
Altera und deren Tools sollte sie bekannt sein). ->Clock Netz kann 
analysiert werden. Größerer Jitter der Takte oder Phasenversatz aus 
einer PLL führen eigentlich nur dazu, dass das Tool mit größeren Setup 
und Hold Zeiten rechnen muss also weniger Zeit für Kombinatorik bleiben. 
-> Die Clock domains können analysiert werden und TimeQuest macht das 
auch.

Sollte das gleiche sein wie bei der erzeugung der Takte für DDR 
Interface, wenn 4 Takte mit 90° Phasenversatz erzeugt wird. Auch hier 
werden die Zeiten analysiert und nicht seperat für sich betrachtet.


Wenn ich mal Zeit hab werde ich mal den Altera Support beschäftigen und 
das Thema klären.
Im Moment hab ich keine Zeit, weil ich den Mist auf meinem Schreibtisch 
fertig mache muss.

[H. G. (Gast)]

> dem Tools die Herkunft bekannt und der Jitter
Das ist ja das, wovon ich spreche. Du musst den Jitter berücksichtigen 
und den Taktversatz. Ok, das Tool wird Dir dabei helfen und beim chip 
brauchst Du eine Brille, den Kopf und ein Datenblatt :-)

Was sagt denn das Tool zu Deinem Aufbau?

Wie gross ist der Jitter?

Gibt es eine Verbesserung, wenn Du noch ein Zwischenregister dazwischen 
setzt?

> Hier ist
> logisch dass die Clock Domains als asynchron gelten müssen
asynchron ist nicht gleich asynchron

Bei einem externen Chip reicht es, in der Mitte zu sampeln und gut ist.


Hochpass schrieb:
> weil ich den Mist auf meinem Schreibtisch
> fertig mache muss.
Ok, dann mache den Mist fertig :-)

[Hochpass (Gast)]

G. H. schrieb:
>> dem Tools die Herkunft bekannt und der Jitter
> Das ist ja das, wovon ich spreche. Du musst den Jitter berücksichtigen
> und den Taktversatz. Ok, das Tool wird Dir dabei helfen und beim chip
> brauchst Du eine Brille, den Kopf und ein Datenblatt :-)
Genau, wenn mir die Timing Analyse sagt: Failing Paths = 0 dann ist 
alles gut. Das ist jedenfalls meine Erwartung auch wenn ich 
unterschiedliche Clocks aus einer PLL habe

> Was sagt denn das Tool zu Deinem Aufbau?
Wenn ich von 125Mhz nach 50 Mhz schreibe ist der maximale delay was ich 
haben darf 4ns
Wenn ich von 300Mhz nach 125 Mhz schreibe ist das max delay 0,6666ns was 
natürlich nicht geht in einem Stratix II

> Wie gross ist der Jitter?
So genau will ich es ja nicht wissen, reicht wenn Time Quest das weiß. 
Oder kann man Quarts bewegen die Info auszuspucken? Wäre ja interessant.

> Gibt es eine Verbesserung, wenn Du noch ein Zwischenregister dazwischen
> setzt?
Ja wenn ich nur Register zwischen Clock domains habe ohne Kombinatorik 
und Fanout = 1 ist es definiv besser. Was auch logisch ist. Aber das ist 
ja eh guter Programmierstil am Augang von jedem Modul Register zu setzen

>> Hier ist
>> logisch dass die Clock Domains als asynchron gelten müssen
> asynchron ist nicht gleich asynchron
> Bei einem externen Chip reicht es, in der Mitte zu sampeln und gut ist.
Du meinst bei Synchronen Interfacen wie z.B. SPI? Wenn man gut rechnet 
stimmt das. ;-) Ist aber off topic

>
> Hochpass schrieb:
>> weil ich den Mist auf meinem Schreibtisch
>> fertig mache muss.
> Ok, dann mache den Mist fertig :-)
Es konvergiert. Die Synchronen Resets nerven noch ein wenig.

[J. S. (engineer)]

> Also mal nicht so hochnäsig
Ist bei mir durch die Gleitsichtbrille bedingt

> Aber das ist ja eh guter Programmierstil
> am Augang von jedem Modul Register zu setzen

Abgesehen, dass ich das eher "Design-Stil" nennen würde, stimmt das so 
pauschal nicht. Die vielen latches erschweren mitunter die 
Zusammenfassung asynchroner Logik, speziell bei VHDL für ASICs. aber das 
soll nicht das Thema sein. In jedem Fall sollte man Latches gezielt 
setzen, denn der Versatz, der damit erzeugt wird, muss anderswo gfs 
berücksichtigt werden.

Aber jetzt ganz konkret:

Wenn Du eines setzt, wie Du es wohl vorhast, dann führst Du ja genau 
die von mir oben erwähnte zusätzliche Synchronisationsstufe ein, statt 
direkt aus der Quelldomäme einzutakten. Du hast also 2FFs zwischen den 
Domänen hängen und damit nichts anderes, als eine 2stufige 
Einsynchronisation der üblichen Art, statt Kombinatorik direkt in 
Kombinatorik weiterzuverwenden, wie es in einer wirklichen Domain ja 
möglich ist.

Der Unterschied ist nur, dass die erste FF-Kette mit dem einen Takt und 
die andere mit dem anderen Takt getrieben wird. Dadurch entsteht aber 
erst das Problem, dass die Takte aufgrund von Jitter (so klein er auch 
ist) sich negativ überlappen können. Ob Timequest das erkennt und 
verhindert, weiss ich ehrlich gesagt nicht, denn bei dieser 
Konstellation hätte die Kombinatorik ja alle Zeit der Welt (nämlich fast 
den ganzen Takt) - das Ergebnis wäre nur um einen Takt verschoben da und 
dies wie gesagt bitweise!

Wenn man es so macht, wie ich es bechreibe, nämlich Kombinatorik über 
2FFs in die neue Domäne, wobei beide FFs konventinell von der Zieldomäne 
getaktet werden, geschieht das nicht, weil die Zeit zwischen 
Kombinatorik-Ende und FF-Takt1 wegfällt und als Reserve für mehr Jitter 
zur Verfügung steht. Meine (und es ist die "übliche") Kombination ist 
schneller, einfacher zu validieren und hat mehr Timingreserve.

[abc (Gast)]

Das wird timequest wohl genauso machen wie die Timing analyse von Xilinx 
auch:

die jeweiligen Jitter und unsicherheiten werden addiert und von der 
möglichen Zeit abgezogen.

Damit hat man zwar ggf wenig Zeit zwischen den 2 FF unterschiedlicher 
Taktdomänen einer PLL, aber solange das klappt ists auch sicher.

Vorraussetzung ist natürlich immer das man die Contraints richtig 
gesetzt hat, was bei mehreren Takten aus einer PLL leicht ist, weil man 
eh nur den Eingangstakt angibt.


Die Timinganalysen sind in der Hinsicht echt gut, konnte mich bisher 
immer drauf verlassen.

[L. B. (hochpass)]

Juergen S. schrieb:
>> Also mal nicht so hochnäsig
> Ist bei mir durch die Gleitsichtbrille bedingt
>
Genehmigt
>> Aber das ist ja eh guter Programmierstil
>> am Augang von jedem Modul Register zu setzen
>
> Abgesehen, dass ich das eher "Design-Stil" nennen würde, stimmt das so
> pauschal nicht. Die vielen latches erschweren mitunter die
> Zusammenfassung asynchroner Logik, speziell bei VHDL für ASICs. aber das
> soll nicht das Thema sein. In jedem Fall sollte man Latches gezielt
> setzen, denn der Versatz, der damit erzeugt wird, muss anderswo gfs
> berücksichtigt werden.
Na gut, wenns kein Programmierstil ist, dann lass dir gesagt sein, dass 
es auch keine Latche sind sonder Flip-Flops. Wer auf nem FPGA Latches 
programmiert, entschuldigung designt, macht was flasch. Lies nochmal 
nach im Lehrmaterial der 90er warum das so ist ;-)
Und über FFs am Ausgang können wir uns in einem neuen Thread ja nochmal 
unterhalten. Synthesetools können auch Kombinatorik über FF Grenzen 
hinaus optimieren. Ich kenne keinen Grund warum man auf nem FPGA am 
ausgang kein FF platziert außer dass man einen Takt verlieren könnte.


> Aber jetzt ganz konkret:
> .....
> Wenn man es so macht, wie ich es bechreibe, nämlich Kombinatorik über
> 2FFs in die neue Domäne, wobei beide FFs konventinell von der Zieldomäne
> getaktet werden, geschieht das nicht, weil die Zeit zwischen
> Kombinatorik-Ende und FF-Takt1 wegfällt und als Reserve für mehr Jitter
> zur Verfügung steht. Meine (und es ist die "übliche") Kombination ist
> schneller, einfacher zu validieren und hat mehr Timingreserve.
Fast alles richtig was du sagtst aber:
1. Um einen Bus zu synchronisieren braucht man mehr als 2 FFs 
hintereinander an jedem signal damit nichts schief geht, daher mehr 
Aufwand.
2. Macht die Methode am meisten Sinn, wenn man zusätzlich die richtigen 
constraints setzt wie TIG bei Xilinx oder false path bei Altera. Dann 
brauchen die Tools nicht an der Stelle rumoptimieren, damit dass design 
gemapt werden kann bei dem die timings eingehalten werden können.

Wenn man aber deine Methode benutzt und constraints setzt ist es eben 
NICHT einfach zu validieren, da die Tools diese Stelle nicht überwachen 
und die funktionale Simulation sich nicht mehr wie die Hardware 
verhällt.

[L. B. (hochpass)]

abc schrieb:

> die jeweiligen Jitter und unsicherheiten werden addiert und von der
> möglichen Zeit abgezogen.
Macht Sinn

> Damit hat man zwar ggf wenig Zeit zwischen den 2 FF unterschiedlicher
> Taktdomänen einer PLL, aber solange das klappt ists auch sicher.
Genau das habe ich heute auch in der Anleitung von time quest gefunden. 
Bei zwei Takten wird der kleinste jemals auftretende Abstand der 
Taktflanken gesucht und mit der Zeit an der Stelle zwichen den clock 
domains mit dieser Zeit analysiert. Wenn der Jitter noch abgezogen wird 
und die Laufzeit auf den clocknetzten muss es funktionieren.


> Vorraussetzung ist natürlich immer das man die Contraints richtig
> gesetzt hat, was bei mehreren Takten aus einer PLL leicht ist, weil man
> eh nur den Eingangstakt angibt.
Danke, das hab ich gesucht. In meinem Fall haut das sogar mit 2 PLLs hin 
die die gleichen Takt am Eingang haben. Ich werde morgen mal 
ausprobieren ob es besser ist in dem Fall die PLLs source synchronous 
laufen zu lassen, was den den jitter erhöht soweit ich weiß aber evtl 
den offset der takte minimiert.

>
> Die Timinganalysen sind in der Hinsicht echt gut, konnte mich bisher
> immer drauf verlassen.

Das war bisher auch mein Ansatz. Constraints ans clocknetz und das 
Design ist erst fertig, wenn die timing fehler bei 0 sind. Probleme 
treten dann auf wenn man von Hand asynchrone clock domains verbindet und 
timing ignores setzt. 2-3 mal am Tag kann sowas zuschlagen, wenn man 
nicht sauber designed hat. Schmerzhafte suche sowas.

@abc
Danke
Plls/DCMs und clocknetze können manchmal die Hölle sein ;-)

[J. S. (engineer)]

In jedem Fall muss er zweimal Jitter berechnen und auch deutlich mehr 
ansetzen, weil bei zwei Takten eine ausgeprägte Gegenläufigkeit 
auftreten kann (einer unterhalb der Sollfrequenz und der andere drüber).

Die Analyse ist auch komplizierter, da er im Grund zwei Flanken beachten 
muss - siehe Fehlerfall 2 rechts. (Datenbits abwechselnd grün und blau, 
erscheinen nach einer übergangsphase türkis je nach Laufzeit am nächsten 
FF)

[Duke Scarring (Gast)]

L. B. schrieb:
> 1. Um einen Bus zu synchronisieren braucht man mehr als 2 FFs
> hintereinander an jedem signal damit nichts schief geht, daher mehr
> Aufwand.
Kommt auf den Bus an. Für die Datensignale würde ich keine 2 FFs 
einbauen. Wer stellt denn dann  sicher das alle Bits mit dem richtigen 
Takt eingesampelt werden? So bekommst Du u.U. Datenmüll, da ein paar 
Bits im Takt X gültig sind und die nächsten erst im Takt X+1.

Für Busse synchronisiert man nur die Steuerleitungen (read_enable, 
write_enable). Dann weiß man auch, wann gültige Daten anliegen.


L. B. schrieb:
> Genau das habe ich heute auch in der Anleitung von time quest gefunden.
> Bei zwei Takten wird der kleinste jemals auftretende Abstand der
> Taktflanken gesucht und mit der Zeit an der Stelle zwichen den clock
> domains mit dieser Zeit analysiert.
So macht es Xilinx auch. Allerdings braucht man bei dieser Methode keine 
zwei FFs, weil die Timinganalyse sicherstellt, das schon am ersten FF in 
der neuen Taktdomäne alle Bedingungen eingehalten werden.

Bei der Methode mit den abgeleiteten Takten empfehlen sich kleine 
Teilerverhältnisse der Frequenzen (z.B. 1:2 oder 1:3 statt 9:10)

Duke

[H. G. (Gast)]

Duke Scarring schrieb:
> zwei FFs,
... sind nur nötig wegen Metastabilität.

L. B. schrieb:
> dann lass dir gesagt sein, dass
> es auch keine Latche sind sonder Flip-Flops.

Woraus bestehen Deiner Ansicht nach Latches?

[Hagen R. (hagen)]

Gerald Hellinghaus schrieb:
> Duke Scarring schrieb:
>> zwei FFs,
> ... sind nur nötig wegen Metastabilität.
>
> L. B. schrieb:
>> dann lass dir gesagt sein, dass
>> es auch keine Latche sind sonder Flip-Flops.
>
> Woraus bestehen Deiner Ansicht nach Latches?

aus FFs, aber die richtige Frage lautet: welcher "Takt" in Relation zum 
Takt des restlichen synchronen Design wird für diese FFs benutzt. Und 
bei Latches ist es eben so das sie kombinatorisch "getaktet" werden und 
nicht synchron getaktet sind.

[Hagen R. (hagen)]

Ontopic, was noch nicht angesprochen wurde:
wenn ein festes Teilervehältnis zwischen den Takten existiert dann kann 
man auch mit einfach Clock-Enable arbeiten und aus einem einzigen Takt 
durch Taktteilung diesen Clock-Enable erzeugen.

Gruß Hagen

[H. G. (Gast)]

Hagen Re schrieb:
> bei Latches ist es eben so das sie kombinatorisch "getaktet" werden und
> nicht synchron getaktet sind.

ok, klar, deshalb ja auch immer die Warnung, keine latches in den 
Designs zu verbauen.

Hagen Re schrieb:
> Ontopic, was noch nicht angesprochen wurde:
> wenn ein festes Teilervehältnis zwischen den Takten existiert dann kann
> man auch mit einfach Clock-Enable arbeiten und aus einem einzigen Takt
> durch Taktteilung diesen Clock-Enable erzeugen.

Da verstehe ich den Bezug zur Fragestellung nicht.

[Duke Scarring (Gast)]

Gerald Hellinghaus schrieb:
>> zwei FFs,
> ... sind nur nötig wegen Metastabilität.
Jaaa, aber nur bei externen Signalen mit unbekannten Taktbezug. Genau 
hier -- in diesem Beispiel -- ging es um zwei bekannte korrelierte 
Takte.

Duke

[Hagen R. (hagen)]

Gerald Hellinghaus schrieb:
> Hagen Re schrieb:
>> Ontopic, was noch nicht angesprochen wurde:
>> wenn ein festes Teilervehältnis zwischen den Takten existiert dann kann
>> man auch mit einfach Clock-Enable arbeiten und aus einem einzigen Takt
>> durch Taktteilung diesen Clock-Enable erzeugen.
>
> Da verstehe ich den Bezug zur Fragestellung nicht.

Naja, so wie ich die Eingangsfrage verstehe gehts um folgendes:

- ein externer Takt zb. 50MHz
- zwei interne PLLs mit diesem externen takt liefern jeweils 90MHz und 
30MHz.

Man kann nun:

1.) zwei PLLs für 50-90Mhz und 50-30Mhz benutzen
2.) eine PLL für 50-90MHz benutzen und synchrones Designe mit 
Teilerfaktor 3

Bei 2 hat man also nur eine Taktbasis a 90MHz für das komplette 
synchrone Design. Alle Operationen die mit 30Mhz laufen sollen werden 
ebenfalls im gleichen Prozess mit 90Mhz Takt betrieben aber mit einem 
Clock-Enable mit Faktor 90/3Mhz real "getaktet".

Also so:

signal Cnt3: integer rang 0 to 2 := 0;
signal Clk3: std_logic = '0';

process (Clk)
begin
  if rising_edge(Clk) then

    if Cnt3 = 0 then
      Clk3 <= '1';
      Cnt3 <= 2;
    else
      Clk3 <= '0';
      Cnt2 <= Cnt2 -1;
    end if;

    if Clk3 = '1' then
      -- hier alles mit Clk getaktet aber nur mit Clk/3 enabled. 
    end if;
  end if;
end process;

Gruß hagen

[J. S. (engineer)]

Hagen Re schrieb:
> eine PLL für 50-90MHz benutzen und synchrones Designe mit
> Teilerfaktor 3
Das geht bei den Takten des TO wahrscheinlich nicht, denn ...

> 125 Mhz, 83,333 Mhz und 300 MHz

ergäben eine nicht erreichbare FPGA-Systemfrequenz. Man muss also auf 
Datenebene synchroniseren.

Duke Scarring schrieb:
> Für Busse synchronisiert man nur die Steuerleitungen (read_enable,
> write_enable). Dann weiß man auch, wann gültige Daten anliegen.

Bei echten Bussen liegen die enables aber auch schon mit präparierten 
Verzögerungen / Setups vor. Beim Synchronisieren verlierte man ja einen 
Takt. Wenn sich die Daten da wieder ändern können, muss schon parallel 
mitgesampelt werden.


Duke Scarring schrieb:
>>> zwei FFs,
>> ... sind nur nötig wegen Metastabilität.
> Jaaa, aber nur bei externen Signalen mit unbekannten Taktbezug

Also, wenn der Taktbezug bekannt ist, dann lege ich den Takt so hin, 
dass ich gar keine Flanke sehe. Dann habe ich nur eine Verzögerung und 
bin immer hinter dem anderen Takt. Daher sind gegeneinander jitternde 
Takte ja auch ein Problem. Wenn er nicht bekannt ist, muss ich 
unterstellen, dass ich die Flanke treffe.

Metastabilität ist übrigens ein viel seltenerer Fall, als man glaubt. 
Die heutigen Technologien schalten so schnell und verstärken so hoch, 
dass sich FFs eigentlich immer rechtzeitig zur nächsten Flanke 
entscheiden, was sie gesehen haben wollen.

L. B. schrieb:
> Wenn man aber deine Methode benutzt und constraints setzt ist es eben
> NICHT einfach zu validieren, da die Tools diese Stelle nicht überwachen
Das müssen sie ja nicht, weil der Fehler gar nicht auftreten kann, 
sondern durch die Designmethode umgangen wird. Du selbst plädierst ja 
für die guten Designmethoden hinsichtlich FFs.

> und die funktionale Simulation sich nicht mehr wie die Hardware
Warum sollte die Simulation nicht so wie die Hardware laufen????
In beiden Fällen wird das Verhalten korrekt simuliert. Die Validierung 
wird nur einfacher, weil ich die clock domain crossing Fälle nicht 
simulieren muss.

> latches und keine FFs
Aus Sicht des empfangenden Taktes sind FFs mit dem alten Takt gegenüber 
ihm asynchron verzögerte Daten und wirken funktionstechnisch wie 
latches. Man unterscheide die Funktion "latch" von dem "Bauelement" - 
wie bei Widerstand und Widerstand.

> Synthesetools können auch Kombinatorik über FF Grenzen
> hinaus optimieren.
Ja, mit eben dem von mir angemerkten Mehraufwand.

> Ich kenne keinen Grund warum man auf nem FPGA am
> ausgang kein FF platziert
Wir sprechen nicht vom FPGA Ausgang sondern von den von Dir 
proklamierten FFs am "Ausgang jedes Moduls"

[abc (Gast)]

@ Hagen:


prinzipiell geht das oft schon, hat aber den immensen Nachteil, das dann 
der komplette, langsame Teil der Logik, welcher nur mit enable arbeitet, 
die gleichen Timings erreichen muss wie der schnellere Teil.

Das erschwert das Timing ungemein, zudem durch das enable eventuell auch 
noch ein Eingang mehr pro LUT belegt wird und das clock enable über 
große Teile des Chips geroutet werden muss.

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

abc schrieb:
> das dann der komplette, langsame Teil der Logik, welcher nur mit enable
> arbeitet, die gleichen Timings erreichen muss wie der schnellere Teil.
Nein. Du selber siehst das ja schon, dass du da 3 mal mehr Zeit hättest. 
Und das mußt du der Toolchain nur noch sagen. Sieh dir das Thema 
Multi-Cyles und die passenden Constraints mal an...

> zudem durch das enable eventuell auch noch ein Eingang mehr pro LUT
> belegt wird
Du siehst z.B. bei Xilinx an einem FDSRE, dass das nicht stimmt. Der CE 
braucht nur Routing-Ressourcen, er geht aber nicht über eine LUT auf den 
D-Eingang:
http://www.xilinx.com/itp/xilinx5/data/docs/lib/lib0176_160.html

[abc (Gast)]

Lothar Miller schrieb:
> Du siehst z.B. bei Xilinx an einem FDSRE, dass das nicht stimmt. Der CE
> braucht nur Routing-Ressourcen

Gilt nur wenn dieser Eingang NICHT durch die eigentliche Logik auch 
genutzt werden würde, was aber durchaus sein kann.
(Das meinte ich mit "eventuell")


Multicycles geht natürlich wenn man Spaß daran hat die Signalnamen alle 
ins Constraintfile reinzufrimeln(Registernamen ändern sich gerne oder 
werden zusammengefasst) und bei späteren Änderungen nicht mehr durch zu 
blicken.

Ich persönlich mag das nicht. Zu fehlerträchtig und zeitfressend, gerade 
wenn viele Teile in unterschiedlicher Taktdomäne laufen.


Bei mehreren Takten aus einer pll bekommt man alles inklusive von der 
Timinganalyse ohne Knoten im Hirn. Perfekt.

[Hagen (Gast)]

abc schrieb:
> Gilt nur wenn dieser Eingang NICHT durch die eigentliche Logik auch
> genutzt werden würde, was aber durchaus sein kann.
> (Das meinte ich mit "eventuell")

 Ja, aber dann kombiniert die Synthese diese "zusätzliche" Logik mit der 
"Enable-Teiler"-Logik als Kombinatorik. Man muß nur aufpassen das diese 
Kombinatorik noch schnell läuft.

Es gibt also kein "eventuell" in diesem Fall.

Gruß Hagen

[Hagen (Gast)]

abc schrieb:
> Multicycles geht natürlich wenn man Spaß daran hat die Signalnamen alle
> ins Constraintfile reinzufrimeln(Registernamen ändern sich gerne oder
> werden zusammengefasst) und bei späteren Änderungen nicht mehr durch zu
> blicken.

Bei Altera+ModelSim weiß ich das man dort die Multicycle-Abhängigkeiten 
autom. ermittelt werden. Nur bei denen wo das nicht geht muß man das per 
Hand konfigurieren.

Gruß Hagen

[Hagen (Gast)]

>Ich persönlich mag das nicht. Zu fehlerträchtig und zeitfressend, gerade
>wenn viele Teile in unterschiedlicher Taktdomäne laufen.

Das ist es ja gerade: wenn man mit CE arbeiten kann dann reduziert es 
die Anzahl der zu synchronisierenden Clock Domains, fast ohne Nachteile, 
und damit kann die Synthese besser arbeiten.

Gruß Hagen

[Hagen (Gast)]

abc schrieb:
> Bei mehreren Takten aus einer pll bekommt man alles inklusive von der
> Timinganalyse ohne Knoten im Hirn. Perfekt.

Falsch, das hängt nämlich von den Takten ab die man mit der PLL erzeugt. 
Je größer der GCD und LCM zwischen den Takten (GCD größter gemeinsammer 
Teiuler, LCM letzter gemeinsammer Teuler) ist, ausser er ist 1, je 
schlechter lassen sich diese Takte zueinander synchron halten durch die 
Synthese.

Angenommen der GCD zweier Takte ist 1. Beide Takte sind also 
teilerfremd. In diesem Fall muß man immer zwischen diesen beiden 
Taktdomains synchronisieren. Dieser Fall kann bei Takten aus einer PLL 
nicht real auftreten.

Solange das Teilerverhältnis zwischen zwei Takten nicht ohne Rest sauber 
teilbar ist muß man mit Problemen zwichen diesen beiden Taktdomains 
rechnen.

Sobald das Teilerverhltnis ohne Rest ist kann man mit CE's arbeiten. Das 
muß immer sauber synchron werden und somit gilt das dann theoretisch 
auch für die Takte aus einer PLL erzeugt.

Ich bevorzuge CE's wenn sie anwendbar sind.

Gruß Hagen

[Hagen (Gast)]

Hagen schrieb:
> Angenommen der GCD zweier Takte ist 1. Beide Takte sind also
> teilerfremd. In diesem Fall muß man immer zwischen diesen beiden
> Taktdomains synchronisieren. Dieser Fall kann bei Takten aus einer PLL
> nicht real auftreten.

Ich präszesiere:

Dieser Fall kann bei Takten aus allen PLLs, die mit gleichen Basistakt 
oder aus einem abgeleiteten Takt aus diesem Basistakt arbeiten, nicht 
real auftreten.

Gruß Hagen

[H. G. (Gast)]

Hagen schrieb:

> Sobald das Teilerverhltnis ohne Rest ist kann man mit CE's arbeiten
Eigentlich eine triviale Erkenntnis.

aber das Thema dreht sich ja darum, wie man es macht, wenn das nicht 
geht

[berndl (Gast)]

Gerald Hellinghaus schrieb:
> aber das Thema dreht sich ja darum, wie man es macht, wenn das nicht
> geht

Dann musst du halt dafuer sorgen, dass deine saemtlichen Eingangssignale 
fuer Clockdomain-B in der Clockdomain-A ausreichend lange stabil bleiben 
um sie in Domain-B einzutakten. Dann kannst du in Domain-B tun was du 
nicht lassen kannst, denn stabile Eingangssignale haben kein Problem 
mit Setup/Hold...
Und natuerlich muessen alle Ausgaenge von Domain-B so lange stabil 
bleiben, dass du dann wieder nach Domain-A rueberkommst.
Du brauchst also Ein- und Ausgangsseitig 'Hold' Flipflops und jeweils 
mindestens ein sicheres Controlsignal das den Taktuebergang validiert. 
Und das ist deine Verantwortung als Designer...

Achja, weil's oben mal hiess, bei Multicycle muss man so viele Signale 
spezifizieren und sich Signalnamen bei der Synthese aendern: Ich 
spezifiziere nur das Clock-Enable Signal mit z.B. 3xCLK im .ucf und 
sorge an den Uebergaengen fuer stabile Signale. Und dann geht das mit 
der Toolchain ohne Probleme...

[L. B. (hochpass)]

Na hätte nicht gedacht dass sowas noch bei der Diskussion noch 
herauskommt.
Aber es zeigt mir:
1. Viele Wege führen nach Rom
2. Nutzen und Funktion einer Pll wird häufig nicht verstanden
3. Timing Analysen werden häufig nicht verstanden

Aber man lernt nie aus. Ich hab jedenfalls einig Ideen mitgenommen, die 
ich testen werde :-)

[berndl (Gast)]

Bei solchen Sachen wie 'multicycle' oder mehrere PLLs/Takte stell dir 
einfach vor: Wie muessten externe Signale aussehen, damit ich die in 
meine Logik sauber reinbekomme. Du darfst dir also was wuenschen, musst 
es aber auch entsprechend im FPGA implementieren, dann funktioniert das. 
Die Toolchains koennen heute schon eine Menge... Ein Blatt Papier mit 
ein paar Sequenzen hilft da ungemein, der Rest ist eigentlich gesunder 
Menschenverstand (oder Logik-Verstand...)

[Hagen (Gast)]

>Aber es zeigt mir:
> 1. Viele Wege führen nach Rom
>2. Nutzen und Funktion einer Pll wird häufig nicht verstanden
Na Hauptsache , Du hast jetzt was verstanden

[Hagen R. (hagen)]

Das letzte Posting stammt nicht von mir, ich vergreife mich 
grundsätzlich nicht im Tonfall und führe auch keine persönlichen 
Flamewars.

Gruß Hagen

[M.K. (Gast)]

Bevor das Geflame losgeht, stelle ich eine Frage zur Sache, weil mich 
das interessiert:

Ist es für die Compilezeit bedeutsam, ob die Synthese so komplexe 
Fragestellungen lösen muss, oder macht das nicht viel aus?

Wenn man z.B. alle kombinatorisch macht und Register hinten dran fügt, 
dann kann ich doch mit register retiming alles glatt bügeln - es kostet 
aber Zeit.

[Weltbester FPGA-Pongo (Gast)]

M.K. schrieb:
> Ist es für die Compilezeit bedeutsam, ob die Synthese so komplexe
> Fragestellungen lösen muss,

In der Regel, sehr wohl! Ich hatte mal ein Seminar, wo auf 
synthesefreundlichen Code abgehoben wurde. Da gibt es schon einige 
Unterschiede in der Formulierung und vor allem in Fragen des designs 
selbst.

Hochpass schrieb:
> Es ist nicht exakt das gleiche Problem wie bei externen Chips:
> Bei externen Chips ist die Laufzeit des Takts unbekannt,

Der Takt ist auch in einem FPGA nicht wirklich bekannt und wird durch 
Berechung "geschätzt". Damit kommt man zu einer Aussagqualität, die 
nicht besser ist, als der externen Talt-SPEC durch constraints.

[berndl (Gast)]

Weltbester FPGA-Pongo schrieb im Beitrag #2341420:
> M.K. schrieb:
>> Ist es für die Compilezeit bedeutsam, ob die Synthese so komplexe
>> Fragestellungen lösen muss,
>
> In der Regel, sehr wohl! Ich hatte mal ein Seminar, wo auf
> synthesefreundlichen Code abgehoben wurde. Da gibt es schon einige
> Unterschiede in der Formulierung und vor allem in Fragen des designs
> selbst.

Loriot-Mode ON: Ach!

>
> Hochpass schrieb:
>> Es ist nicht exakt das gleiche Problem wie bei externen Chips:
>> Bei externen Chips ist die Laufzeit des Takts unbekannt,
>
> Der Takt ist auch in einem FPGA nicht wirklich bekannt und wird durch
> Berechung "geschätzt". Damit kommt man zu einer Aussagqualität, die
> nicht besser ist, als der externen Talt-SPEC durch constraints.

User-Mode ON: Ach!

[Peder (Gast)]

Kann man mal jemand das Problem ins Deutsche übersetzen?

[berndl (Gast)]

Peder schrieb:
> Kann man mal jemand das Problem ins Deutsche übersetzen?

Welches Problem denn? :o)
* Clock domain?
* Uebergang zwischen verschiedenen Clock domains?
* ...

Um es mit Didi Hallervorden zu sagen: 'Ich brauche mehr Details'...

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

Wozu den alten Thread ausgraben?

@Peder: Was ist deine Frage?