Hallo, ich habe verschiedene Schaltungen in VHDL und nutze FPGAs zur Verifikation. Zur Synthese nutze ich Xilinx 8.1sp3 (gleiche probleme gibt es jedoch auch mit allen versionen, es scheint also nicht versionsabhängig zu sein). Nach der Synthese reportiert mir ISE eine Geschwindigkeit von 78MHz, nach dem Place & Route bleibt davon nicht mehr allzuviel übrig, die erforderlichen 33MHz werden mit ach und krach erreicht. Scheinbar sind die dazugekommen IO-Pads dafür verantwortlich? Wie kann man die Geschwindigkeit wieder erhöhen, denn der große Unterschied zw. interner clockfrequenz und externer (mit pads) ist mir doch ein "wenig" zu groß Frank
Das Prblem wirst du immer haben, denn wenn du eine reine Synthese durchführst, dann "kennte" er die Laufzeiten durch die einzelnen LEs, aber nicht die Laufzeiten für das Routing. Bei P&R wird dann diese Information bekannt und somit die Laufzeit größer. Du könntest versuchen, bei der Synthese auf Speed udn nicht auf Area zu otimieren. Ausserdem solltest du darauf achten, dass du dein FPGA nicht voll auslastest, denn dann kann er irgendwann nicht mehr optimal routen, da sich kaum noch Möglichkeiten ergeben. Gib auch bitte Constraints für die zu erreichende Frequenz vor. Wenn du einem Syntehsetool nicht mitteilst, wie schnell dein Design nachher laufen soll, dann kannst du nicht davon ausgehen, dass es immer das schnellste erzeugt. Kannst auch versuchen, den Effort höher zu setzen (Musst dir dann halt nen Kaffee holen:-)) Spiel einfach ein bisschen mit diesen Parametern rum.
Grundsätzlich die Angabe zur maximalen Taktfrequenz aus dem Synthesetool ignorieren. Nicht mit Korrekturfaktoren 0.5 -0.9 arbeiten, nicht versuchen mit neueren versionen genauerer Ergebnisse zu erreichen sondern die Angabe schlicht wegwerfen. Nur die nach dem place&Route stimmt. Also schon während der Entwicklung komplett Durchläufe (inkl. Place and route) durchführen um frühzeitig Fläschenhälse zu erkennen. Dabei das constraint für den Takt ca 10 - 15% höhersetzen. Nichts ärgerlicher als ein design das halbfertig den geforderten takt schafft und bei zunehmender fertigstellung (weniger Platz im FPGA) langsamer wird. dann schlägt man sich mit timingproblemen rum, wenn man keine zeit mehr dafür hat und grossräumig neustricken muss.
Wenn wir schon bei den Timing Constraints sind: Kann mich da mal jemand einweihen, was man mit denen so anstellen kann? Was bewirken die denn? Was besagt dabei Pad to Setup , Clock to Pad und Period? Was bringt es, wenn ich dort etwas einstelle? Wird das Design dann anders gerouted? Daniel
Noch was: Wo sehe ich die max. Taktfrequenz nach Place & Route? Ich kann diese nirgends finden(in ISE 7.1).ö Daniel
#Wo sehe ich die max. Taktfrequenz nach Place & Route? Ich kann diese #nirgends finden(in ISE 7.1) Vielleicht etwas missverständlich, die max. Taktfrequenz für das Design wird nie angegeben. Im PAR report (*.par) steht ob das Timing constraint eingehalten worden und wo es nach diesem lauf steht. Hast du z.B ein period constraint für den takt auf 10 ns gesetzt, setht im PAR report in der tabelle für alle timing constraint vielleicht was von 9.81 ns und unter der Tabelle die Zeile all constraint all meet. In der regel gibt man für das design eine Taktfrequenz vor, also die mit der die Aufgabe (Transferrate etc) erfüllt wird und pappt den entsprechenden Oszillator aufs board. Mit einer höheren Taktung wird man das board wegen EMV, Verlustleistung nicht betreiben wollen. Die maximale taktfrequenz kannst du durch Hocchschrauben des Periodconstraints, mehreren PAR LÄufen und ausprobieren der optimalen Syntheseschalter ermitteln. Oder kurz du musst es mühsam ausprobieren. Manchmal wird Overconstraining empfohlen, also eine utopische Taktfrequenz angeben (z.B. 500 MHz), tools laufen lassen und dann schauen was die Tools geschafft haben (z.B. 183 MHz). Aber dieser Wert ist auch nur geschätzt: -bei Xilinx brechen die Tools ab, sobald ein Pfad entdeckt wird für denn es absolut kein routing mit der geforderten Zeit gibt. -nach meinen Erfahrungen ist die angegebene Periode nach overconstraining auch noch nicht das Ende der Fahnenstange. Ich hat mal sowas: 53MHz nicht geschaft, Angabe 50 MHz wären drin 50 MHz geschaft, angabe 51 Mhz wären drin 51 MHz geschafft abgabe 51 Mhz wären drin 52 MHZ geschafft, angabe 52 MHZ sind drin Also die taktung angeben und schauen, ob's geroutet wird. Warum das so ist? ich tippe auf traveling salesman problem: http://de.wikipedia.org/wiki/Traveling-Salesman-Problem Die Aufgabe für die Tools ist es nicht, das schnellste design zu implementieren (was ein recht rechenzeitintensives Problem ist) sondern aus allen Lösungen, die Funktion erfüllen (Netzliste) das design zu finden|auszuwählen das die Randbedingung (engl. constraint) z.B. "Pfade zw. FF kürzer|gleich 2 ns) erfüllen. Da muss man a bisserl umdenken und trotzdem bei klaren verstand bleiben
#Was bringt es, wenn ich dort etwas einstelle? Wird das Design dann #anders gerouted? BTW: was bedeutet abo hier??? Ja,nein, vielleicht. Also was macht Place und route. Place Route bekommt eine Datei vom map. Da steht ein Kochrezept (netzliste) drin, z.B.: -man nehme 3 slices,eine dcm und eine handvoll routing kanäle (Netzte) -an der DCM knote man ein Ende eines Netzes an das Pin fout ein anderes Ende knuppert man an das Pin Y1 eines Slices, -dann nehme man das zweite slice, knüppert ein Ende des netzes an Y2, ein weiteres Ende an A1 und noch ein Ende an CY - .... Also es steht nicht drin: -welches slice von den tausend zu nehmen ist -was als netz zu nehmen ist (long line, slice interconnect, etc) aber es steht der schaltplan drin (ohne zu verraten wie die verbindungen zu machen ist) . Der Placer hat nun auszuwählen welches slice und welche DCM zu nehmen ist. In der dummsten Optimierungstufe denkt er dabei nicht viel nach (das kostet ja rechenzeit) sondern beginnt in einer ecke (meist links oben) und füllt von dort den FPGA. Das ist sehr gut an den DCM's zu beobachten, der Placer nimmt (fast?) immer die DCM links oben und (fast?) nie die DCM's aus der unteren reihe, wenn er nicht muss. So geht er stur ducrh das Kochrezept, er nimmt von oben die komponente (slice,dcm,etc) und legt diese auf den nächsten freien Platz. Ändert sich die reihenfolge in der Liste (vielleicht weil man die Reihenfolge der instanziierung der Komponenten ändert, oder einen anderen Signalnamen vergibt, oder das Voodoo des synthesetools einen Vollmond hat)) ändert sich auch die Position der Komponente im FPGA. Mit Optimierung high ist er ein bißchen schlauer. Allerdings ist mir unbekannt, was schlauer meint. Irgendwie versucht er nun die Komponenten so zu legen da sie nicht weit verstreut sind. Vielleicht sortiert er das Kochrezept nach Komponentennamen? das Problem ist, das die tools nicht wissen, was sie machen sollen ausser alle Komponenten irgendwie auszuwählen und zu verschalten. Der router ist dann ohne Timingconstraints ähnlich hilflos. Er macht sich die Arbeit leicht (und damit die rechenzeit kurz) in dem auch er an einer Ecke (vom slice) anfängt und von dort die Routingkanäle zur nächsten Komponente auswählt. Ein echtes Routen (ziehen von Kupferbahnen,Drähten) ist das beim FPGA nicht. Im FPGA ist das Kupfer ja schon fertig als routingressourcen. Der router muss nur auswählen welche er für die geforderte verbindung aktiviert. Es gibt unterschiedlich schnelle und unterschiedlich lange routingresourcen. Einige reichen von oben nach unten, davon ist ein teil schneller als der andere. Es gibt kurze verbindungen von einem slice zu anderen. Auch damit kann man durch den ganzen FPGA gehen, wenn dieses Slices in Durchfahrt geschaltet ist. Also eine LUT, bei der nur ein Eingang genutzt wird und er Ausgang immer den selben wert wie der eingang hat. Mit timing constraints kann er nun dafür sorgen, da schnelle signale schnelle routing resourcen bekommen und langsame signale auf den kurvigen schleichpfaden zum Ziel kommen. Je nach optimierungsschalter wird er nun unterschiedlich komplizierte methoden anwenden, das routing entsprechend dem timing anzupassen. Die tools versuchen aber nicht "Optimal" sein. Also das schnellste design zu bauen. Sind z.B 5 ns gefordert, wird er nicht unbedingt prüfen ob er die schnellen Kanäle (z.B. 2ns) nutzen kann, wenn er alles mit den langsameren (z.B. 4 ns) Kanälen schafft. In der regel arbeitet das place und route nach der Devise "baue schnell ein korrektes Design" also "erfülle was gefordert und denke sowenig wie nötig nach". Das das kostet Rechenzeit und kein User wartet gern stundenlang auf das Ende des Place und route.
Vielen vielen Dank für die ausführliche Erklärung, FPGAküchle!!! Dann werde ich mal ein bisschen rumprobieren wie ich meine Designs noch ein bisschen schneller bekomme. Daniel
Könntest Du mir bitte noch kurz erklären, was Pad to Setup und Clock to Pad bedeutet? Danke
#Könntest Du mir bitte noch kurz erklären, was Pad to Setup und #Clock to Pad bedeutet? Hm ich hab mal einen Auszug aus meiner DA angehangen. Da ist die die statische Timinganalyse beschrieben. Folgend kurz das selbe. -Entscheidend für die max. Taktfrequenz ist die Signallaufzeit zwischen zwei FlipFlops, die durch die selbe Taktleitung hetrieben werden. Diese Laufzeit besteht aus mehreren Teilzeiten (clock_to_Output_delay, setup_time, etc). Die max. taktfrequenz ist der Kehrwert der größten Laufzeit. -das "period" constraint bestimmt die Obergrenze dieser Laufzeit für zwei FF innerhalb des FPGA. -der Fall "ein FF auf dem FPGA, das andere ausserhalb des FPGA,beide am selben takt" wird durch zwei weitere constraints bestimmt. -Bei diesen constraints gibt man die Zeit an die für den FPGA übrig bleibt, also für FPGA-Outputs: t_taktperiode - t_auf_dem_PCB - t_setup externes FF -Für ausgänge bestimmt Clock to Pad wieviel Zeit vergehen darf, die das Signal vom letzten FF bis zum FPGA_pin wandert -> wie weit darf das letzte FF vom Pin wegliegen. -Für Eingänge bestimmt "Pad to Setup" wieviel zeit bleibt um ein Signal vom Pin in ein FF zu transportieren. ->wie weit darf das Erste FF vom Pin wegliegen. Detailliertes findet sich in der Xilinx-Doc . Ergänzung: üblicherweise versucht man Logik zw. Pin/PAD und FF zu vermeiden und ein FF zu verwenden das so nah wie möglich am Pin/Pad liegt. Dazu gibt es die speziellen IOB-FF die in jeder Padzelle liegen. Die Padzelle ist das Stück Silizium an das FPGA-Pin angeschlossen ist. Deshalb zieht man die constraints für Clock to Pad und Pad to Setup heftig an (ca 2ns). Falls diese constraints nicht erreicht werden, ist entweder Logik zw. FF und Pin beschrieben worden, oder der mapper hat einen schlechten Tag bzw. ungünstige Einstellungen. Natürlich muss man immer noch nachrechnen ob PCB (ca 500ps) und das externe FF nicht zuviel vom Time budget (Taktperiode) aufbrauchen. So und schau ich mal das das ins hiesige wike wandert -> http://www.mikrocontroller.net/articles/Kategorie:FPGA_und_Co
Vielen Dank. :) Du hast mir soeben ein neues Portal in die Welt der Timings eröffnet ;) Daniel
Darf ich mich jetzt "Hüter des Portals" nennen? ;-)
Ja, Du darfst dich mit Stolz und Ehre "Hüter des Portals" nennen. ;) Ich habe jetzt ein bisschen mit den Constraints rumgespielt und dabei folgendes Problem festgestellt: Angenommen ich setzt die Period-Constraint auf 5ns, Pad to Setup und Clock to Pad auf 2ns. Wenn ich dann Place & Route durchlaufen lasse bricht dieses ab mit der Meldung, mindestens eine Timing-Constraint sei unmöglich einzuhalten. In der Tabelle steht dann, dass Pad to Setup aktuell mindestens 3,8ns und Clock to Pad mindestens 7,3ns benötigt. Die Period Constraint kann eingehalten werden. Um das Design auf den FPGA zu bekommen muss Place & Route ja bekanntermaßen fehlerfrei durchlaufen. Dies kann ich meines Wissens nach ja nur bewerkstelligen, indem ich die Constraints lockere. Also habe ich die Constraints auf die Werte eingestellt, die der Tabelle bei actual zu entnehmen waren. Nach dem nächsten PAR Durchlauf stand in der Tabelle unter actual für Period nun 6,8ns(zuvor 4,8). Für Pad to Setup wird nun 3ns angegeben(zuvor 3,8) und für Clock to Pad wird 9,7ns angegeben(zuvor 7,3). Also war PAR in diesem Fall wieder mal faul, obwohl die Optimierung auf High eingestellt ist. Es würde aber doch schneller gehen. Warum macht PAR hier so einen Mist? Gibt es Möglichkeiten alles raus zu holen? Daniel
Letzter beitrag für heute: die timing angaben aus einem lauf mit "impossible to meet" constraints sind weitgehend zu vergessen, da der router nicht vollständig durchlief. Die angaben in einem solchen fall sind IMHO absolut best case, oder sogar noch besser (also schwachsinn). Das erklärt zumindest warum dein period nach oben gewandert ist. 6.8 ns als period klingen eigentlich sehr gut. das besser zu kriegen erfordert meistens VHDL code umschreiben. Was meistens etwas hilft, ist ein aktiviertes "timing_driven beim map. Du kannst ein design in den FPGA laden, bei dem einige constraints nicht erfüllt werden, aber keines darf davon als "unmöglich" gebrandmarkt sein. Place&Route samt bitgen läuft schon durch. Es kann auch Absicht sein, constraints zu setzten, die nicht erfüllt werden, aber dazu ein anderes mal. Bei den PAD constraints ist wichtig, was der externe chip braucht. Dein hohes clock to pad (7.3) sschaut nach FF im inneren aus (nicht das IOB-FF) genutzt. Auch kannst du oft mit anderen Signalconstraints an dem Signal für dieses pad verbessern. Also für diesen output slew=fast und Drive=24 setzten. (Das sieht aber die EMV nicht gern -> ground bounce etc)
In dem Zusammenhang habe ich noch eine Frage. Das Timing hängt ja offensichtlich auch stark mit der Platzierung der IO-Pads zusammen. Blöderweise haben FPGA-Boards meist verschiedene Steckerbänke. Zum Anschluss eines solches Boards an den PC (z.b. für PCI) wählt man nun eine Pfostenleiste aus und lötet dafür ein Kabel. Bis auf die CLock, die ja idealerweise direkt in ein CLockpin geht, verteilt man die anderen Signale frei auf die Pfostenleiste. Intelligenter wäre doch, wenn man Constraints in Xilinx vorgeben könnte welche Pins zur Verfügung stehen, man dann sein Design routen lässt und aus dem nachfolgenden Padreport sein Kabel lötet? DAs problem ist also: kann man ISE dazu zwingen sein Place auf bestimmte Pads einzuschränken? Frank
Hi, auch von mir ein nettes danke schoen zur ausfuehrlichen Beschreibung. Ich hoffe einer von den Profi's hat, vielleicht Lust ein VHDL / FPGA / CPLD Tutorial wie das AVRGCC Tutorial anzufangen. Ich als total Anfänger habe zuviel Angst bloedsinn zu schreiben ;) Gruß, Dirk
Mach Dir keine Gadanken. Learning by doing ist das Beste. Nimm Dir irgendwelche Aufgaben vor und löse sie mit den Mitteln, die Du kennst. Nach und nach lernt man dazu, indem man nicht weiterkommt, sich dann Infos holt usw...
DAs problem ist also: kann man ISE dazu zwingen sein Place auf bestimmte Pads einzuschränken? Man kann pins mit "PROHIBIT" vom map und den rest ausschliessen. Dann hats noch AREAGROUP (o.ä) aber das ist wohl nicht was du brauchst
#Ich hoffe einer von den Profi's hat, vielleicht Lust ein VHDL / FPGA / #CPLD Tutorial wie das AVRGCC Tutorial anzufangen. wenn überhaupt geht das nur im wikirudel und bezieht sich auf ein evalboard. Das dann jeder für das tutorial braucht. Und dann geht IMHO als tutorial nur Xilinx oder Altera (sonst werdens zwei) ... Ist halt ein riesenaufwand. Hm mein Grosshirn fragt gerade an, warum es keine (geschriebenen) Tutorials fürs Fahrrad fahren gibt. Gibt es Prozesse die nicht oder schlecht per Tutorial vermittelbar sind?
Ich finde auch, es lohnt nich ein Tutorial zu schreiben. >>Es kann auch Absicht sein, constraints zu setzten, die nicht erfüllt >>werden, aber dazu ein anderes mal. Eine Weiterführung des Themas würde mich sehr erfreuen, FPGAküchle. :)
Ich kriege Clock to Pad und Pad to Setup einfach nicht unter 7ns. Wie bringe ich ISE bei, die I/O Flipflops zu nehmen? Daniel
Bitte 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.