Offset In Constraint

[BrauchHilfe (Gast)]

Hallo,

ich habe gerade enorme Verständnisschwierigkeiten bei der Benutzung von 
Offset In Constraints. Warum braucht man diese?
Warum sollte ich angeben wollen, um wie viel Zeit vergehen muss, bis 
eine Taktflanke (am ersten Register im FPGA? oder am Clock-Pad? des 
FPGAs) ankommen darf, bevor die entsprechenden Daten stabil (an diesem 
Register? oder etwa am Pad-Eingang?) anliegen.

Es scheint ja so, dass die Überprüfung dieser Constraints in der Timing 
Analyse immer unter Beachtung der entsprechenden Period-Constraints 
gemacht werden. Richtig?

Offset Out Constraints machen für mich da schon mehr Sinn. Schließlich 
will man ja, dass die entsprechenden ICs hinter dem FPGA ( die mit dem 
gleichen Takt arbeiten) für ihre Register und deren Setup-Time das 
Datensignal auch rechtzeitig "sehen".

Mir ist vor allem schleierhaft, was das Mapping/Place and Route mit der 
Constraint-Info macht. Längere/kürzere Wege für die Daten/die Clock 
durch den FPGA wählen, damit das eine oder andere Signal entsprechend 
(relativ zum anderen) verzögert ist?

Irgendwie wird mir das aus den Xilinx Dokumenten überhaupt nicht klar. 
Dort wird nur beschrieben, wie ich das festlege. Aber mir wären 
Beispiele lieber, bei denen aufgrund einer nicht gemachten Constraint 
eine Schaltung nicht so funktioniert wie sie soll.

Ich beziehe mich auf:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ug612.pdf[/url

[J. S. (engineer)]

Ja, die Xilinx Dokumentation. Ein Kapitel für sich. Da liesse sich viel 
zuschreiben :-)

Um Deine konkrete Frage zu beantworten: Das offset-In constraint is 
deshalb nötig, damit das tool "weiss" wieviel delay es sich durch das 
unweigerlich autretende routing im Chip gegenüber dem Takt erlauben 
kann.

Die Daten sind ja nicht permanent und auch nicht nur zu einem Zeitpunkt 
gültig, sondern haben einen Bereich nach- oder um die Taktflanke herum, 
in dem man sie sampeln kann. Das muss angegeben werden.

BrauchHilfe schrieb:
> Längere/kürzere Wege für die Daten/die Clock
> durch den FPGA wählen, damit das eine oder andere Signal entsprechend
>(relativ zum anderen) verzögert ist?
Bei der "timing driven placement" Methode tut er genau das.
Im Regelfall geht es darum, dass der Analyzer das design checken und die 
timing reserven prüfen kann. Was nicht geht (manche aber offenbar 
glauben) einfach das constraint angeben und hoffen, dass der Chip dann 
schon richtig arbeitet. Das muss man schon selber tun, d.h. die Daten 
müssen zum theoretisch optimalen Zeitpunkt gesampelt werden. Um den 
Zeitpunkt herum herrscht dann etwas Spielraum für das tool.

[BrauchHilfe (Gast)]

Und woher weiß ich, wie viel Zeit ich dem Tool geben kann, sprich, wie 
viel Offset in Before-Zeit ich angeben kann?

Ich hab doch keine Ahnung welches Delay (wie langdas Signal am Pad noch 
gültig ist) das Datensignal von der Quelle bis zum Pad hat um auf ein 
entsprechende Delaydifferenz zum Taktsignal schließen zu können (dessen 
Skew von Quelle (anderer IC? oder Taktquelle) ich bis zum Pad ebenfalls 
nicht kenne)

Für mich ist das alles sehr suspekt. Schließlich heißt es ja 
"Constraint" und damit gebe ich ja eine BEDINGUNG an und keine 
Information à la "du hast noch so viel Zeit das Datensignal vom Pad zum 
Register (nach Setuptime)).

Nebenbei bemerkt: Wie spielt da der Period Constraint mit rein? Im 
Grunde gebe ich mit diesem an der Stelle hier doch den Takt des Netzes 
bis zum ersten Register des FPGAs an? Oder ist das doch der Period 
Constraint zwischen zwei Registern im FPGA? Oder für alle, wenn ich 
überall den gleichen Takt hab?

[BrauchHilfe (Gast)]

Hab ich ganz vergessen:

Zunächst einmal danke ich dir für deine Hilfe. Ich bin verzweifelt auf 
der Suche nach guten Quellen um das Thema besser zu verstehen, aber der 
einzige Anhaltspunkt war für mich bisher nur die Dokumentation von 
Xilinx.
Bücher oder ähnliches scheinen Mangelware zu sein. Vielleicht hat ja 
Altera bessere Dokus?

[J. S. (engineer)]

BrauchHilfe schrieb:
> Und woher weiß ich, wie viel Zeit ich dem Tool geben kann, sprich, wie
> viel Offset in Before-Zeit ich angeben kann?

Du gibst dem tool indirekt "Zeit", indem Du es zwingst, das design so zu 
bauen, dass es funktioniert. Funktionieren heisst an dieser Stelle, dass 
der Takt zu den Daten passt. Das ist in diesem Fall eine Information, 
die von Aussen kommt, also von einem vorgeschalteten Chip. Du musst 
wissen, wie die Daten reinkommen.

Kleine Anmerkung:

Genau genommen ist ein OIC aus logischer Sicht gar kein constraint, 
sondern das Gegenteil, nämlich eine Unschärfeangabe, die das tool nicht 
etwa einschränkt, sondern ihm Freiheiten gibt. Ohne diese Aufweichung 
müsste das tool nämlich dafür sorgen, dass der Takt exakt zu den 
theoretisch wechselnden Daten passt, was darauf hinaus liefe, edge 
aligend zu bauen und maximal die Jitterreserve zu applizieren, weil die 
immer vorhanden ist und daher auch im FPGA zugelassen werden müsste. Das 
aber ist jetzt mehr Begriffstheorie, die man bei der Firma Xilinx 
beiseite lassen muss, da dort nicht logisch gedacht oder deklariert wird 
und diese Äusserung meine ich absolut ernst!

Es hilft also nichts, sich an die seltsame Xilinx Deklaration zu 
gewöhnen und dem tool alles mit auf den Weg zugeben.

Tatsächlich ist ein OIC definitiv von Nöten, weil es neben der Jitter- 
und time of valid Problematik ja nicht nur edge aligned Daten von Aussen 
gibt, sondern auch center aligned, die zudem auch noch mit der 
Gegenflanke wechseln könnten.

Praktisch sieht es also so aus, dass Du einfach das spezifizierst, was 
von Aussen angelegt wird.