Forum: FPGA, VHDL & Co. Geschwindigskeitunterschiede nach Synthese und Place&Route


von Frank (Gast)


Lesenswert?

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

von schlumpf (Gast)


Lesenswert?

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.

von FPGAküchle (Gast)


Lesenswert?

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.

von Daniel R. (daniel_r)


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

abo

von Daniel R. (daniel_r)


Lesenswert?

Noch was:
Wo sehe ich die max. Taktfrequenz nach Place & Route? Ich kann diese
nirgends finden(in ISE 7.1).ö

Daniel

von FPGAküchle (Gast)


Lesenswert?

#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

von FPGAküchle (Gast)


Lesenswert?

#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.

von Daniel R. (daniel_r)


Lesenswert?

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

von Daniel R. (daniel_r)


Lesenswert?

Könntest Du mir bitte noch kurz erklären, was „Pad to Setup“ und
„Clock to Pad“ bedeutet?

Danke

von FPGAküchle (Gast)


Angehängte Dateien:

Lesenswert?

#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

von Daniel R. (daniel_r)


Lesenswert?

Vielen Dank. :)

Du hast mir soeben ein neues Portal in die Welt der Timings eröffnet
;)

Daniel

von FPGAküchle (Gast)


Lesenswert?

Darf ich mich jetzt "Hüter des Portals" nennen?

;-)

von Daniel R. (daniel_r)


Lesenswert?

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

von FPGAküchle (Gast)


Lesenswert?

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)

von Frank (Gast)


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

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

von Daniel R. (daniel_r)


Lesenswert?

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...

von FPGAküchle (Gast)


Lesenswert?

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

von FPGAküchle (Gast)


Lesenswert?

#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?

von Daniel R. (daniel_r)


Lesenswert?

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.
:)

von Daniel R. (daniel_r)


Lesenswert?

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
Noch kein Account? Hier anmelden.