Gibt es eine gute Beschreibung mit Beispielen, wann man welche Constraints definieren sollte? Ich habe z.B. mehrfach Constraints auf Signale gesehen, die vom selben Takt erzeugt und weiterverarbeitet werden. Das sollte doch eigentlich unnötig sein, da dieses Constraint dem Synthesetool doch implizit über die Taktfrequenz bekannt ist, oder?
Das habe ich natürlich angeschaut, es gibt erschreckend viele Möglichkeien, aber es sagt wenig zu der richtigen prizipiellen Vorgehensweise. Und meine obige Frage hat es mir leider auch nicht beantwortet.
Michael S1. schrieb: > wann man welche Constraints definieren sollte? Man sollte z.B. LOC Constraints vergeben, damit die Signale an den richtigen Pins herauskommen... ;-) > Ich habe z.B. mehrfach Constraints auf Signale gesehen, die vom selben > Takt erzeugt und weiterverarbeitet werden. Das sollte doch eigentlich > unnötig sein, da dieses Constraint dem Synthesetool doch implizit über > die Taktfrequenz bekannt ist, oder? Manche verbrennen sich mal anständig die Finger, indem sie (ausser der Pinzuordnung) keine Constraints vergeben. Und danach wird überregelt, und (zusätzlich zum globalen Takt, der auch über DCM hinweg wirkt) jeder erdenkliche Pfad mit einem eigenen Timing-Constraint in die Knie gezwungen. Frei nach dem Motto: Viel hilft viel. Für ein "einfaches" Design, wo nur asynchrone Geschichten angeschlossen sind, reicht es idR. nur den Takt anzugeben. Constrains für die IO-Pins lohnen sich dann bestenfalls, um Busse in halbwegs gleich schnelle Bahnen zu knechten. Einfacher ist es dann aber meist, das Flipflop im IO-Buffer zu verwenden. Takte im FPGA, die über DCM abgeleitet wurden, müssen nicht extra angegeben werden. Es kann allerdings sein, dass dann der Übergang zwischen einer 50MHz und einer abgeleiteten "synchronen" 60MHz Domain eben schon mal 300MHz schnell sein müsste (20ns-16,7ns = 3,3ns --> 300MHz), und dass man dann diesen Pfad extra mal anschauen sollte... > Gibt es eine gute Beschreibung mit Beispielen Sowas ist mir nicht bekannt. Leider.
Michael S1. schrieb: > Gibt es eine gute Beschreibung mit Beispielen, > wann man welche Constraints definieren sollte? > > Ich habe z.B. mehrfach Constraints auf Signale gesehen, die vom selben > Takt erzeugt und weiterverarbeitet werden. Das sollte doch eigentlich > unnötig sein, da dieses Constraint dem Synthesetool doch implizit über > die Taktfrequenz bekannt ist, oder? Meines Erachtens sollten die constraints so früh wie möglich geschrieben sein, also zum ersten map. Parallel zu den constraints darauf achten das alle IO's ausser takte das/Die FF in der IO-Zelle nutzen. Zu jedem i/O Signal sollte das Pin und IO Standard definiert sein, bei InOuts und outputs ebenso slew-rate und Treiberstärke (sofern für diesen Standard erforderlich). Je nach Design sind PullUp/Downs an Ausgängen erforderlich. Sind diese nicht auf dem PCB, muß natürlich ein entsprechendes constraint gesetzt werden. Period constraint für jeden eingehenden Takt. Xilinx spartan3a devices brauchen auch noch einen tip welche Spannung an der AUX-Stromversorgung anliegt; also muss folgende Zeile adapiert und verwendet werden: CONFIG VCCAUX = 3.3; Im timing analyser checken, welche Pfade unconstraint sind und überprüfen ob darunter einige sind die doch eins benötigen. Achtung: Zuviele (unnötige) timing constraints machen PlaceundRoute komplexer und damit langsamer. Zuwenige (nötige) constraints führen zu instabilen (Fehler abhängig von Temp. und Vcc) oder garnicht laufenden Designs. . Optional: Für Analysen mit dem timinganalyser macht es m.E. Sinn timing groups für jede taktdomain zu definieren. Damit lassen sich Pfade zwischen diesen besser finden. Daher definiere ich auch constraints von aus der DCM genrierte Pfade. Auch sollte man beachten das nicht immer die constraints automatisch über die DCM propagiert werden. Pfade die unwichtig für das timing sind (asynchrone system-Reset's) mit TIG (timing Ignore) belegen, das vereinfacht das Place und Route. Alle im PCB ungenutzte pins reservieren, sonst kann es böse Überraschungen geben: CONFIG PROHIBIT = AF25; Placement constraints für DCM und BUFG. Gelegentlich platzieren die Tools diese zentralen resourcen beim ersten lauf ungünstig. Für xilinx gibt es GUI-Tools für die constraint eingabe: PAC (ältere Versionen), Floorplanner?. Die neuen Varianten sind äüßerst instabil, da ziehe ich die händische Vorgehensweise vor, aber es lohnt sich mal diese tools anzutesten zu starten um ein Gefühl für constraining zu bekommen. Und der DRC (DesignRuleCheck) zeigt welche constraints nicht zueinander passen. MfG,
Ich danke euch für die umfangreiche Beschreibungen. Ich werde die Punkte mal bei unserem aktuellen Projekt prüfen, bei dem ich den Eindruck habe, dass zum einen zuviele Constrants drin sind, aber auch wichtige Constraints fehlen, was zu langen Placement Zeiten und Instabilitäten führt. Das ist in dem Projekt besonders problematisch, weil 2/3 des FPGA mit generiertem Code (Instanzierungen und Verdrahtungen) erzeugt wird, von dem es 5-10 Varianten gibt. Ich selbst bin leider kein FPGA Experte (obwohl ich das Prinzip schon verstehe) habe aber die Verantwortung was meine Jungs so machen. Was mich ungeheuer stört ist, dass man bei den XYLINX Tools vor lauter Warnungen die Bäume im Wald nicht sieht. Von der Softwareentwicklung bin ich gewohnt Warnungen, wenn irgend möglich, zu vermeiden.
Michael S1. schrieb: > Was > mich ungeheuer stört ist, dass man bei den XYLINX Tools vor lauter > Warnungen die Bäume im Wald nicht sieht. Ja. Das ist leider so. Mich hat das auch gestört. > Von der Softwareentwicklung bin > ich gewohnt Warnungen, wenn irgend möglich, zu vermeiden. Ich suche mir mit grep nur noch die relevanten Warnungen raus: Beitrag "Re: unbenutztes Signal" Duke
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.