Hallo,
Folgende Situation:
FPGA: Spartan6
verwendete Ressourcen: ISERDES2 + IODELAY2
Datenrate: bis 1100 Mbit/s (max. SERDES Geschwindigkeit = 1080 MBit/s)
Für den SERDES braucht man eine PLL die eine VCO Frequenz von 400 bis
1080 MHz erzeugen kann.
Intern arbeite ich mit einem 10 bit Datenbus, so dass die interne
Taktrate 1/10 der seriellen Datenrate, also 108 MHz beträgt.
Das Timing Constraint für den internen Clock wurde auf 107.99 MHz
gesetzt.
Soweit funktioniert auch alles!
Wenn ich nun "härtere" Constraints setzen will, also z.B. statt 107.99
MHz 120 MHz, dann bekomme ich folgenden DRC Error bei "Map":
1
ERROR:PhysDesignRules:1859 - The computed value for the VCO operating
2
frequency of PLL_ADV instance xxx/pll_base_inst/PLL_ADV is calculated to
3
be 1200.00000 MHz. This falls above the operating range of the PLL VCO
4
frequency for this device of 400.000000 - 1080.000000 MHz. Please adjust
5
either the input frequency CLKIN_PERIOD, multiplication factor
6
LKFBOUT_MULT or the division factor DIVCLK_DIVIDE, in order to achieve a
7
VCO frequency within the rated operating range for this device.
Ich weiß, dass ich mich mit diesem Constraint außerhalb der
Spezifikation des FPGAs befinde, was aber noch nicht heißen muss, dass
es nicht geht.
Auch wenn ich innerhalb der 1080MBit bleibe, würde ich die Constraints
gerne härter setzen.
Ich hoffe jmd. kann mir bei meinem Problem helfen!
Vielen Dank!
BF schrieb:> Ich weiß, dass ich mich mit diesem Constraint außerhalb der> Spezifikation des FPGAs befinde, was aber noch nicht heißen muss, dass> es nicht geht.
Dann bleibt dir eigentlich nur übrig, das höchstmögliche zu fordern
(107.99 MHz), und dann dafür zu sorgen, dass das FPGA beim Betrieb mit
120 MHz nicht an die Grenzen kommt (Temperatur, Spannung...). Denn die
Tools werden dir immer auf die Finger klopfen, wenn du mehr willst,
als das Design oder das FPGA (theoretisch) hergibt. Das ist ihre
Aufgabe.
Hallo Lothar,
genau das ist ja mein Problem. Ich würde ja gerne für die nachfolgende
Logik die Timing Constraints auf 120 MHz setzen, oder nach Map&Route die
Timing Analyse per Hand checken, was natürlich auf Dauer aufwendig und
umständlich werden könnte.
Natürlich hat das Vorgehen von Xilinx auch seine Daseinsberechtigung...
Schade, dass es hierfür keinen einfachen Workaround gibt...
Ich hab neulich auch mit so einer VCO Freq too high warnung gekämpft und
hab mir dann halt ein anderes M/N Verhältnis ausdenken müssen, dass
innerhalb der Specs ist und für mich akzeptable Ausgangsfrequenzen
erzielt. Dass es mit 10% über der lt Datenblatt maximalen Freq des VCO
noch funktioniert mag sein, wohl fühlen würde ich mich mit solchem
Herumgefummel an der Clock allerdings nicht.
BF schrieb:> Natürlich hat das Vorgehen von Xilinx auch seine Daseinsberechtigung...> Schade, dass es hierfür keinen einfachen Workaround gibt...
Frag doch mal bei Xilinx nach. Eventuell gibt es eine Umgebungsvariable
um den Fehler in eine Warnung zu verwandeln.
Duke
BF schrieb:> Ich würde ja gerne für die nachfolgende> Logik die Timing Constraints auf 120 MHz setzen,
Warum, was soll das bringen?
Die Berechnungen der Durchlaufzeiten von Xilinx sollten schon alle
möglichen Betriebsbedingungen abdecken, es sollte also nicht nötig sein,
enger zu constrainen als notwendig.
Klaus Falser schrieb:> es sollte also nicht nötig sein,> enger zu constrainen als notwendig.
Ich mache das z.B., um die potentiell kritischen Pfade zu ermitteln.
Vielleicht kennt da jemand auch noch eine bessere Methode?
Duke
Duke Scarring schrieb:> Ich mache das z.B., um die potentiell kritischen Pfade zu ermitteln.
Da kannst du dir aber schnell was in die Tasche lügen:
Ich habe die Erfahrung gemacht, dass ein zu eng eingeschränktes (und
damit eigentlich nicht realisierbares) Design keine sinnvollen Aussagen
zum kritischen Pfad zulässt, weil sich dann P&R irgendwie versteigt.
Evtl. könnte die umgekehrte Version klappen: schrittweise mit
ansteigender Frequenz so lange implementieren, bis es nicht mehr geht.
Dann das zuletzt erreichte Timing analysieren...
> Vielleicht kennt da jemand auch noch eine bessere Methode?
Noch nicht...
Verdammt, da hatte ich nicht richtig gelesen. Aber ich verstehe das
Vorgehen auch nicht so ganz, wenn die PLL diese Freq nicht mag, was für
einen Sinn hat es, das nachgelagerte Design so zu bauen, als bekäme es
eine höhere Input-Frequenz? Erkenntnisgewinn sehe ich auch keinen
großen, ich weiß ja typischerweise auch so, wo ich viel Kombinatorik
implementiert habe und wo nicht. Und wie Lothar schon schrieb, das kann
auch komisch laufen, man dreht ja nicht nur an den kritischen Pfaden
herum.
Also wenn schon dann die spannenden Unterkomponenten separat
implementieren und das Timing checken.
Wie läuft das in diesem Fall eigentlich, drehst du nur die Input Freq
für das Design auf und lässt den Rest dann das Tool machen? Evtl kann
man in den Timing Constraints die Werte für die derived clock explizit
überschreiben, dann müsste die PLL mit der tatsächlichen Frequenz
behandelt werden und der nachgelagerte Teil mit den härteren
Constraints.
Aber wie gesagt, viel Sinn sehe ich darin auch nicht. Höchstens zur
Behandlung von clock jitter hat overconstrainen für mich bisher Sinn
gemacht.
Overconstraining macht bspw. dann Sinn, wenn man einen asymmetrischen
Eingangstakt verwenden muss, so dass Setup/Hold-Fenster verschoben und
u.U. verletzt werden.
Willy
Einen assymetrischen Takt kann man, zumindest bei Xilinx, angeben und
die Tools können das dann berücksichtigen.
Alle Aussagen, die ich bis jetzt von FPGA-Spezialisten bekommen habe,
gehen dahin, dass man das Design möglichst genau, aber nicht
über-constrainen soll, weil die Tools sich sonst an den unwichtigen
Teilen verrennen.
Willy schrieb:> Overconstraining macht bspw. dann Sinn, wenn man einen asymmetrischen> Eingangstakt verwenden muss, so dass Setup/Hold-Fenster verschoben und> u.U. verletzt werden.>> Willy
Hmm, aber wenn die Timing Parameter von einem FF mal verletzt sind kann
man die statische Timinganalyse doch ohnehin kübeln, oder?
Thread beobachten
Seitenaufteilung abschalten