Hallo,
ich hätte mal eine Frage zur Maximum Frequency. Ich habe auch schon die
Sufu benutzt, doch bin noch ein bisschen verwirrt.
Bin gerade an einem Projekt dran, indem ich auf eine Compact Flash Karte
schreiben und lesen will. Die Routinen bzw. FSM ist dafür schon fertig
und funktioniert auch super.
Den Systemtakt, mit dem ich die ganzen Module takte, habe ich über eine
DCM erzeugt, die mir aus 100MHz Quarzfrequenz einen 200 MHz schnellen
Systemtakt erzeugt.
In der UCF habe ich nur für den 200 MHz Takt eine Constraint gesetzt:
1
Net"CLK200"TNM_NET="SYSCLK";
2
TIMESPECTS_SYSCLK=PERIOD"SYSCLK"5nsHIGH50%;
Nun sagt mir aber mein Synthese-Report:
Timing Summary:
---------------
Speed Grade: -1
Minimum period: 7.990ns (Maximum Frequency: 125.156MHz)
Minimum input arrival time before clock: 3.254ns
Maximum output required time after clock: 3.920ns
Maximum combinational path delay: 3.762ns
Bedeutet das, dass mein Design nicht schneller als 125 MHz laufen kann?
Bin in dieser hinsicht verwirrt. Ist die Maximum Frequency evtl.
schneller mit einer PLL anstatt einer DCM?
Oder sagt die Angabe im Report etwas anderes aus. Wie würde ich evtl.
dann mein Design scneller kriegen, falls die Angabe wirklich die
maximale Freq. für mich ist?
Würde mich über jede Anregung sehr freuen.
PS: Benutze das Xilinx Entwicklungsboard ML507 mit dem Virtex 5
MfG Cihan
Diese Frequenzausgabe der Synthese ist nur ein ganz grober Richtwert.
Nach Place&Route kann das noch wesentlich schneller oder langsamer
werden, je nach Optimierungspotenzial. Lass doch mal komplett
durchlaufen, dann siehst du, ob das Design schnell genug ist und dein
Takt-Constraint eingehalten wird.
Nach einem kompletten Durchlauf gibt er mit aber keine Frequenzangabe
mehr. Allerdings habe ich auch keine Timing Fehler, kann ich mir dann
sicher gehen, dass mein SystemClock von 200 MHz problemlos eingehalten
wird?
Oder kann man die tatsächliche max. Frequenz nach dem Durchlauf irgendwo
sehen?
Cihan
Wobei ich sehe gerade im Post-PAR Static Timing Report folgendes:
Timing summary:
---------------
Timing errors: 0 Score: 0 (Setup/Max: 0, Hold: 0)
Constraints cover 32417 paths, 0 nets, and 14512 connections
Design statistics:
Minimum period: 13.661ns{1} (Maximum frequency: 73.201MHz)
Maximum path delay from/to any node: 3.523ns
hier ist die max. Freq. sogar niedriger. Ich verwende übrigens auch
Chipscope in meinem Design. Kann dieses unter Umständen die max Freq.
verlangsamen?
Cihan
Wenn der sagt "All constraints met" dann passt das Timing für die
Constraints die du vorgegeben hast. Da müsste ja in der Tabelle auch
drin stehn, ob die 200MHz eingehalten werden.
D.h. in Klar-Text, wenn man die Constraints in der UCF angibt und nach
der Durchlauf keine Timing Fehler entstehen, kann man sich sicher gehen,
dass die max. Frequenz, in mienem Beispiel 200 MHz, eingehalten werden.
Habe ich das nun richtig verstanden?
Danke für deine Anregungen
Cihan
Nein, es gilt nur wenn du auch die Constraints RICHTIG gesetzt hast.
Kuck nach ob im Timing Report bei 5ns irgentwas mit <=5ns steht.
Wenn du die 5ns nicht findest, dann war dein Constraint nicht richtig
gesetzt und er hat es gar nicht beachtet.
Cihan Kalayci schrieb:> In der UCF habe ich nur für den 200 MHz Takt eine Constraint gesetzt:Net
"CLK200" TNM_NET = "SYSCLK";
> TIMESPEC TS_SYSCLK = PERIOD "SYSCLK" 5 ns HIGH 50%;
Du musst nicht für die 200MHz einen Constraint setzen, sondern für die
100 MHz am Eingang. Die Tools rechnen sich dann selber Constraints für
Takte aus, die aus einem DCM/PLL kommen.
Sieh mal im Timing/Trace-Report nach, ob dort überhaupt ein 200 MHz
Constraint auftaucht.
Tom
Thomas Reinemann schrieb:> Cihan Kalayci schrieb:>> In der UCF habe ich nur für den 200 MHz Takt eine Constraint gesetzt:Net> "CLK200" TNM_NET = "SYSCLK";>> TIMESPEC TS_SYSCLK = PERIOD "SYSCLK" 5 ns HIGH 50%;>> Du musst nicht für die 200MHz einen Constraint setzen, sondern für die> 100 MHz am Eingang. Die Tools rechnen sich dann selber Constraints für> Takte aus, die aus einem DCM/PLL kommen.
M.E. ist es besser die constraints selber zu setzen und nicht darauf
hoffen das die Tools alles über die PLLS propagieren und ableiten.
> Sieh mal im Timing/Trace-Report nach, ob dort überhaupt ein 200 MHz> Constraint auftaucht.
Ja, das sollte man tun. der Report sollte die Endung *.par tragen, auf
die bunten ISE Reporttabellen würde ich mich allein stützen. Der
spannenden teil vom Report sieht so aus:
**************************
Generating Clock Report
**************************
+---------------------+--------------+------+------+------------+-------
------+
| Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+---------------------+--------------+------+------+------------+-------
------+
| sys_clk_BUFGP | BUFGMUX0| No | 82 | 0.005 | 1.015 |
+---------------------+--------------+------+------+------------+-------
------+
* Net Skew is the difference between the minimum and maximum routing
..
Timing Score: 0
Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.
------------------------------------------------------------------------
------------------------------
Constraint | Check | Worst Case |
Best Case | Timing | Timing
| | Slack |
Achievable | Errors | Score
------------------------------------------------------------------------
------------------------------
NET "sys_clk_BUFGP/IBUFG" PERIOD = 17 ns | SETUP | 3.836ns|
13.164ns| 0| 0
HIGH 50% | HOLD | 0.873ns|
| 0| 0
------------------------------------------------------------------------
------------------------------
Alternativ kannst du die Statische timing analyse allein laufen lassen:
timingan.exe und dabei mit automatisch erzeugten und selbstedfinierten
constraints zu experiementieren . Sehr aufschlussreich ist auch das
Erzeugen eines "unconstrained paths report".
MfG
Fritz Jaeger schrieb:>> Du musst nicht für die 200MHz einen Constraint setzen, sondern für die>> 100 MHz am Eingang. Die Tools rechnen sich dann selber Constraints für>> Takte aus, die aus einem DCM/PLL kommen.>> M.E. ist es besser die constraints selber zu setzen und nicht darauf> hoffen das die Tools alles über die PLLS propagieren und ableiten.
Was ist der Grund für dieses Erachten? Hast du Beispiele, in denen das
automatische Erzeugen von Constraints nicht geklappt hat? Mir ist dies
noch nie passiert, d.h. weder bei Actel noch Lattice noch Xilinx.
Tom
Fritz Jaeger schrieb:> M.E. ist es besser die constraints selber zu setzen und nicht darauf> hoffen das die Tools alles über die PLLS propagieren und ableiten.
Ob es funktioniert lässt sich aber leicht nachprüfen. Ist das constraint
im Report da, dann hats auch funktioniert.
Wenn du das aber nicht glaubst, dann musst du drauf hoffen das mehrere
synchrone Takte aus einem DCM automatisch wieder erkannt werden, damit
die Timing Analyse mögliche Taktübergänge als synchron erkennt und
dementsprechend behandelt.
Den 100MHz clock vor dem DCM zu constrainen macht deshalb wesentlich
mehr Sinn. Zumal mir noch nicht untergekommen ist das dies nicht erkannt
wurde.
Sowohl Xilinx, synplify als auch Quartus haben damit seit mehreren
Jahren absolut keine Probleme. Anwenderfehler?
>Ob es funktioniert lässt sich aber leicht nachprüfen. Ist das constraint>im Report da, dann hats auch funktioniert.
Die Überprüfbarkeit ist m.E. kein Grund eine potentieel fehlerträchtige
Vorgehensweise als "besser" klassifizieren
als die übliche Modulbasierte Vorgehensweise.
Besteht ein FPGA aus mehreren Funktionsblöcken die in mehreren
Taktdomänen liegen wird für jede domän eine Taktvorgabe spezifiziert und
die ist dan Grundlage für das constraint dieses Blöckes. Die tatsächlich
realisierte Takterzeugung
(FPGA-intern: PLL, DCM, BUFGMUX-Pulse, clock divider, local clocking
oder
FPGA extern (XTAL,VCXO) interessiert hier nicht.
So stellt man sicher, das das Modul wiederverwendet (Re-USE) werden
kann:
-ASIC statt FPGA
-FPGA-Familie ohne (verfügbare) DCM
-FPGA mit anderen Clockpining (keine didicated Clk- Eingänge)
Ebenfalls lassen sich die Module auch einzeln durch overconstrainen
"ausmessen" also
die maximale Taktung ermitteln.
Ebenso ist es für die üblichen Requirement based Entwicklungen absolut
notwendig, das jedes Requirement in
Quelltext identifizierbar ist. Das wird eben nur dadurch gewärleistet
indem man jeder Taktdomänspezifikation ein
Constraint zuordnet und nicht in einem globalen Takt-constraint und
einem PLL-Parameterfile versteckt.
>Wenn du das aber nicht glaubst, dann musst du drauf hoffen das mehrere>synchrone Takte aus einem DCM automatisch wieder erkannt werden, damit>die Timing Analyse mögliche Taktübergänge als synchron erkennt und>dementsprechend behandelt.
Das meinst Du jetzt nicht im Ernst?
FF die an unterschiedlichen Taktnetzen hängen, sollte man nie als
synchron ansehen oder
von der Software als synchron erkennen lassen. Unterschiedliche Ausgänge
bedeuten unterschiedliche
Regelstrecken und damit unterschiedliche Phasen resp. Phasenjitter. Soll
die STA Pfade zwischen FF an
unterschiedlichen Taktnetzwerken mit einbeziehen dann setz man ein FROM
TO constraint. Oder ein FALSE PATH wenns wurscht ist.
Oder man behandelt den Übergang als multicycle Path. Eine allgemeine
Behandlung von Taktübergängen
gibt es nicht. Ferner würde das propagieren von Period-Constraint zu den
einzelnen DCM-Ausgängen in
dem von dir geschilderten Fall nicht zu einem contraint für mehrere
Netze führen und damit nicht
zu einer Zusammenführung mehrere Taktnetzwerke.
Und ich lese grad das xilinx in der neuen ISE die Taktnetzwerk
generierung geändert hat. Klassische modulbasierte
Vorgehensweise (Taktgenerierung und getaktete Mosdule getrennt
constrainen) ist leicht auf solche änderungen adaptierbar, da
gekapselt. Andernfalls musst du für neue Toolversionen denn Design an
mehren Stellen anpassen.
Wenn du allerdings nur eine Taktdomäne mit 1:1 Taktübersetzung im FPGA
treibst, brauchst du du dir darüber keine Gedanken zu machen.
MfG
Fritz Jaeger schrieb:> Das meinst Du jetzt nicht im Ernst?> FF die an unterschiedlichen Taktnetzen hängen, sollte man nie als> synchron ansehen oder> von der Software als synchron erkennen lassen. Unterschiedliche Ausgänge> bedeuten unterschiedliche> Regelstrecken und damit unterschiedliche Phasen resp. Phasenjitter
Das meine ich sehr wohl ernst, denn das schafft die heutige
Software(xilinx/altera) problemlos wenn man das Constraints auf den
Eingang des DCM setzt.
Der Jitter sowie Skew wird angegeben und automatisch verrechnet,
Probleme gabs hier damit noch nie, selbst bei "krummen" Takten (50 auf
125 was effektiv nur 4ns lässt, etc).
Fritz Jaeger schrieb:> Soll> die STA Pfade zwischen FF an> unterschiedlichen Taktnetzwerken mit einbeziehen dann setz man ein FROM> TO constraint. Oder ein FALSE PATH wenns wurscht ist.
Warum soll ich mir die Mühe machen wenn die Software es selber kann?
Und wer soll diesen Code noch pflegen?
Constraints stehen naturgemäß nicht direkt neben dem Code.
Fritz Jaeger schrieb:> Und ich lese grad das xilinx in der neuen ISE die Taktnetzwerk> generierung geändert hat.
Kann ich nicht bestätigen, funktioniert alles weiter wie bisher.
Fritz Jaeger schrieb:> Klassische modulbasierte> Vorgehensweise (Taktgenerierung und getaktete Mosdule getrennt> constrainen) ist leicht auf solche änderungen adaptierbar
wohl kaum. Gibts eine Änderung in den Tools kann es sein das deine
ganzen Constraints ignoriert oder falsch interpretiert werden.
Weniger ist hier mehr. Hunderte Übergänge (die eigentlich gar keine
sind, weil sychron zum langsamsten Takt) neu zu beschreiben kann nicht
wirklich dein Wunsch sein.
Fritz Jaeger schrieb:> Die Überprüfbarkeit ist m.E. kein Grund eine potentieel fehlerträchtige> Vorgehensweise als "besser" klassifizieren
Ich halte das automatische Verfahren für viel fehlerfreier als eine von
Menschenhand zusammengestellte Liste die typischerweise Lücken oder auch
Überschuss enthält.
Fritz Jaeger schrieb:> Ebenfalls lassen sich die Module auch einzeln durch overconstrainen> "ausmessen" also> die maximale Taktung ermitteln.
Unfug, wenn du das vor hast musst du eh für das einzelne Modul
kurzfristig ein zweites constraint setzen, sonst hast du gleichzeitig
alle Module an einem bestimmten Takt,z.b. 100 MHz, geprüft, wenn du das
Constraint von 10ns auf 9ns setzt.
Abgesehen davon musst du nur überlegen wie unsinnig das ist wenn dort
ein Taktübergang auf synchron laufende z.b. 50Mhz aus der selben DCM
dabei ist. Da wirds nix mehr mit testen, von 20ns auf 9ns wird kein
Spaß.
Ah natürlich, dann änderst du mal eben alle entsprechenden Constraints
für das Modul in der Hoffnung das du keinen Fehler machst.
Aber wenn man deine Posts so liest glaubt man eh du bist unfehlbar, dann
schaffst du das schon.
Platzierst du eigentlich noch die Luts per Hand oder glaubst du dem Tool
das es das mittlerweile ohne Fehler beherrscht?
Fritz Jaeger schrieb:
...
tzu schrieb:
...
Ich denke die Wahrheit liegt irgendwo dazwischen.
Noch dazu kommt, das jeder einen anderen Erfahrungsstand und andere
Anforderungen hat.
Duke
tzu schrieb
> Ah natürlich, dann änderst du mal eben alle entsprechenden Constraints> für das Modul in der Hoffnung das du keinen Fehler machst.> Aber wenn man deine Posts so liest glaubt man eh du bist unfehlbar, dann> schaffst du das schon.
Klar wenn man keine Sachargumente mehr hat kann man die Gegenseite immer
noch diffamieren
und mit wilden Behauptungen in Misskredit bringen. Ich habe nie
behauptet unfehlbar zu sein, Du tust das.
Ich habe viel Erfahrungen gesammelt, daran kannst du teilhaben oder die
Klappe halten. Und ich habe darauf
hingewiesen wie man seine constraint überprüft und mit diesen
experiementiert (timingan.exe),
Du dagegen schwafelst von unfehlbaren tools.
> Platzierst du eigentlich noch die Luts per Hand oder glaubst du dem Tool> das es das mittlerweile ohne Fehler beherrscht?
Auch bei Fehlerfreie Tools kann man den Code hinsichtlich
Wartbarkeit/Lesbarkeit optimieren.
Das aber heutige tools fern von Optimum sind beweist nicht nur die
halbjährlichen Patches von Xilinx, sondern auch
dies sie gerade wieder mal mit Vivado eine Toolsuite anpreisen die 4x
schneller sein soll und bessere routing-Ergebnisse
erzielt. Man sieht, da sind noch genügend Reserven die man sich mit
wohlplatzierten Optimierungen erschliesst.
Vorausgesetzt, man weis wie das geht und ist der Software nicht
hoffnungslos ausgeliefert.
tzu schrieb:
>> Und ich lese grad das xilinx in der neuen ISE die Taktnetzwerk>> generierung geändert hat.> Kann ich nicht bestätigen, funktioniert alles weiter wie bisher.
Dann lies doch mal Beitrag "Neuanmeldung" . Wenn Du
dann immer noch meinst,
alles wäre beim Alten, dann schreib Xilinx, das deren Changelog nicht
stimmt.
> Weniger ist hier mehr. Hunderte Übergänge (die eigentlich gar keine> sind, weil sychron zum langsamsten Takt) neu zu beschreiben kann nicht> wirklich dein Wunsch sein.
Bei Hunderten Übergangen hast Du aber deine Taktdomainen völlig
fehl-spezifiziert. Falls es es wirklich
soviele sein müssten, dann wäre eine grosse Domäne mit einem hohen Takt
angebracht, die langsam zu schalteten bildet man per
CE-Pulse nach. Und selbst wenn, mit textuellen wildpatterns und sichere
Benamsung (bspw eindeutige Process labels) ist das
setzen eines constraints über hunderte/tausende Pfade kein Problem.
Im übrigen sei Dir das Studium der Xilinx UG612 und der Guidelines
DO254-UG-001 angeraten. Erstere listet die Kompromisse auf,
die das automatische Propagieren von constraints über eine DCM nötig
macht (Transformation conditions: keine weiteren
constraints an diese TIMEGRP insbesonders kein FROM TO
(multicyvl) und OFFSET IO-constraining) und wie man diese
Einschränkungen durch händische Massnahmen umgeht.
Zweitere zeigt auf wie man VHDL-Code für sicherheitskritische
Anwendungen verfasst und wie man Taktübergänge dabei behandelt
(keine Automatik bei intern generierten Takten sondern individuelle
Code-Reviews).
Replik verfassenkannst Du Dir sparen, deine nick steht gleich neben hjk
im killfile.
In diesem Sinne...
PLONK
PS
Duke schrieb:
> Noch dazu kommt, das jeder einen anderen Erfahrungsstand und andere> Anforderungen hat.
Genau deswegen ist nicht hinnehmbar, das hier pauschal von einer
"besseren" Lösung geschrieben wird.
MfG,
Fritz Jaeger schrieb:> Klar wenn man keine Sachargumente mehr hat kann man die Gegenseite immer> noch diffamierenFritz Jaeger schrieb:> Replik verfassenkannst Du Dir sparen, deine nick steht gleich neben hjk> im killfile.>> In diesem Sinne...Fritz Jaeger schrieb:> Genau deswegen ist nicht hinnehmbar, das hier pauschal von einer> "besseren" Lösung geschrieben wird.
Schade das Selbstreflektion nicht zu Deinen Stärken zu gehören scheint.
Dein Fachwissen wäre eine Bereicherung für das Forum.
Aber Fachwissen alleine reicht nicht. Eine gewisse soziale Kompetenz
gehört auch dazu. Immerhin ist Mawin jetzt kein Einzelfall mehr...
Duke
Fritz Jaeger schrieb:> Ich habe viel Erfahrungen gesammelt, daran kannst du teilhaben
Das ist deine Meinung.
Bei Leuten die eine Selbstgefälligkeit an den Tag gehen das es schon
stinkt juckt es mir sowieso in den Fingern ihnen die Grenzen ihres
Denkens aufzuzeigen.
Ich sage auch entgegen deiner Meinung nicht das meine Methode in jeder
Hinsicht besser wäre (lies nach, steht nirgends). Ich versuche nur deine
veralteten Ansichten für die Leser hier ein wenig den modernen
Möglichkeiten gegenüber zu stellen, sozusagen den advocatus diaboli zu
spielen.
Das dir das nicht passt ist offensichtlich und umso lieber tue ich es.
Vielleicht öffnet das den Geist auch im gehoben Alter noch.
Fritz Jaeger schrieb:> Auch bei Fehlerfreie Tools kann man den Code hinsichtlich> Wartbarkeit/Lesbarkeit optimieren.
mein reden. Ein einziges Constraint gegen eine ganze Latte. Was ist da
wohl übersichtlicher.
Fritz Jaeger schrieb:> Falls es es wirklich> soviele sein müssten, dann wäre eine grosse Domäne mit einem hohen Takt> angebracht, die langsam zu schalteten bildet man per> CE-Pulse nach
Au ja, am besten an viele 10000 FF alle per CE, na auf den Routing pfad
hab ich Lust. Die Übersichtlichkeit im Code ist bestimmt auch ganz toll
und Wiederverwendbarkeit der absolute Wahnsinn. Aber immerhin müssen wir
dann nicht mehr auf Funktionen vertrauen die die Tools seit Jahren
beherrschen, da haben wir echt was gewonnen.
Fritz Jaeger schrieb:> Und selbst wenn, mit textuellen wildpatterns und sichere> Benamsung (bspw eindeutige Process labels) ist das> setzen eines constraints über hunderte/tausende Pfade kein Problem.
Stimmt, sowas wie kryptische Umbenennung durch Optimierung des
Synthesetools kann eh nur den Anfängern passieren die nicht jede LUT per
hand instanziieren nach dem sie per Karnaugh selbst optimiert haben...
tzu schrieb:> Bei Leuten die eine Selbstgefälligkeit an den Tag gehen das es schon> stinkt juckt es mir sowieso in den Fingern ...> Ich versuche nur ... ... advocatus diaboli zu spielen.
...
> Das dir das nicht passt ist offensichtlich und umso lieber tue ich es.
...
Vorsicht Troll - Bitte nicht Füttern!
Nur weil du keine Kritik vertragen kannst sind meine berechtigten
Einwände keineswegs getrolle, wie auch andere Leute hier bestätigt
haben.
Viel mehr zeigt es was von jemandes Empfehlungen zu halten ist, der sich
selbst als Vollprofi darstellen will, aber nicht damit klar kommt das es
berechtigte andere Meinungen gibt.
Im Gegensatz zu dir halte ich eine, wenn auch ruppig geführte,
Diskussion für wesentlich fruchtbarer als ein Herunterbeten von Phrasen
ohne Begründugen und Alternativen.
Das Gegenüberstellen und Abwägen von verschiedenen Ansichten gehört zu
einer anspruchvollen Arbeit dazu und fördert mit Sicherheit den
Lernprozess des Lesers.
Ich bin der Meinung, dass alle Taktdomänenübergänge, die einem bekannt
sind, per Constraint (in welcher Form auch immer) im Timing-Summary zur
Anzeige gebracht werden sollten. Somit kann man mit anderen Methoden
(anderen Constraints) anschließend überprüfen, ob man
Taktdomänenübergänge hat, die man nicht sauber behandelt (sprich
übersehen) hat (bspw. über klassische 2-FF-Syncstufe).
So machen wir es und fahren bislang gut damit.
Schön, DASS das Forum so lebendig ist :-)
Stachele
Hast du dafür mal ein Beispiel?
Kann an der Uhrzeit liegen, aber verstehe grad nicht wie das gemeint
ist.
Klingt irgentwie nach echten Taktübergängen und nicht nach synchronen
Takten aus einer DCM/PLL.
Die Möglichkeit einer automatischen Prüfung auf Vollständigkeit ohne
händisches Durchsehen klingt jedenfalls interessant.
Thread beobachten
Seitenaufteilung abschalten