www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Optimierung auf Speed, welche Schalter? Xilinx ISE


Autor: Hochpass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Habe eigentlich schon alles im Betreff geschrieben.
Ich komme mit meinem Design nicht an das Maximum. Welche Schalter bei
der Synthese,Map, ... gibt es die auf Geschwindigkeit optimieren.
Welche sind villeicht sogar kontraproduktiv?
Welche bringen am meisten?

Ach ja, ich habe noch das ISE 7.x

Autor: Sven Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin...

An welches "Maximum"?

Die maximale Taktfrequenz in den Datenblättern ist keinesfalls mit
jedem Design zu erreichen! Ansonsten ist der Constraint Editor gefragt
und den "Effort Level" bei Place/Route hoch.

--
 SJ

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In den Syntheseoptionen kannst Du unter "Xilinx Specific Options"
"Register Balancing" auf "Yes" stellen.

Das kann je nach Design ziemlich viel oder auch wenig bringen.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,
hatte mal die gleiche Frage gestellt.
Leider kann man wohl nicht nach Beitragersteller suchen.

es gibt noch ein Programm Plan Ahead von xilinx ...
(hab damit aber auch nichts gemacht )
 chris

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Xilinx selbst rät zum probieren, einige Schalter sind kontroproduktiv,
andere bringen viel, andere wenig. Das beste ist immer noch eine
Analyse mit timing analyzer (timingan) und FPGA-Editor mit
anschliessender codeänderung am Flaschenhals.

Falls du es erst mit den schalter probieren willst:


-placerund route maximal auf maximalen effort stellen hilft viel wenn
vorher mit weniger effort gearbeitet wurde (par -rl high -pl high)

-ein ebenso wirksamer "Angstschalter" ist map -timing  (aktiviert
"timing driven mapping")

-natürlich stört die Flächenverkleinerung durch Zusammenfassen der
unrelated logic in ein slice. Diese sollte also deaktiviert werden.
map -c 0

-mit den Extra Effort level vom par habe ich bei alten versionen
schlechte Erfahrung gemacht, könnte aber bei dir helfen. Schau mal in
die Dok oder teste par -help spartan3   (falls du mit sprtan3 FPGA's
arbeitest

-map mit Ziel balanced (optimiert auf timing ohne zuviel Fläche zu
verschlaudern ist recht brauchbar also map -cm balanced oder map -cm
speed

-die synthese kennt auch zwei Optimierungsziele Speed und area, aber
damit habe ich widersprüchliche Ergebnisse erreicht.

-die F5- F8 Multiplexer machen (bei mir) ein design eher langsamer,
daher steht bei mir  map -k 4

...
Das kannst du alles in der KlickeKacki Oberfläche des ISE
Projektnavigators einstellen, ich bevorzuge commandline Optionen.

Also mal die Dok hinsichtlich map,par und XST studieren und dann
probieren. Oft ist das Placement Scheisse (BUFG,BRAM aus der falschen
Ecke genohmen), da musst Du mit LOCATION constraint dem par helfen.

Nochmals:
analysiere den Design auf den Flaschenhals (timing analyzer, FPGA
Editor) und weite den gezielt auf (Platzierung vorgeben, FF einbauen,
Logik vereinfachen, (asynchrone) resets raus wo unnötig. Das braucht
genausoviel Hintergrundwissen wie das richtige Treffen der Tool
Optionen, führt aber schneller zum Ziel. per Forum ist dir bei dem
unfangreichen Thema nur bedingt geholfen, vielleicht kannst du einen
Kollegen/Guru an dein design locken.

Autor: Hochpass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke
Das sind ja schonmal ein Paar ansätze, die ich teilweise auch schon
verfolgt habe.
Problem ist, dass ich das Design nicht in allen Bereichen kenne, da ich
fertige Cores einsetze.
Die größten Kerne sind ein OpenRisc, eine PCItoWishbone Bridge und dann
mehrere kleinere Kerne am Wishbonebus, die ich teilweise auch selber
geschrieben habe.
Kollegen/Gurus gibts hier leider nicht, da dieses Institut an dem ich
meine Masterarbeit schreibe bisher noch nichts mit FPGAs am Hut hatte.
Das heißt für mich erstmal leiden.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wishbone kann kritisch sein,da hier etliche Busse quer übern FPGA
geroutet werden. Aber auch da hat man möglichkeiten, z.B. die Busse mit
internen Tristates (TBUF) LUT-Muxer oder Carry chain Muxer aufzubauen.
Letzteres ist nach meiner erfahrung die Beste. Dazu müsstest du ja code
geschrieben haben.
Falls Placement das problem (lt. timinganalyzer bestimmt das routing
mehr als 40% der laufzeit) ist 0-wissen über das design nötig. Du musst
nur wissen, wo die BRAMS,BUFG,DCM,MULT18 im chip liegen
(rechts|Links,oben|unten mittig,ECKEN,rechts|links).

Falls das Pinout des FPGA's noch nicht fest steht oder Freiheitsgrade
lässt, kannst Du mal die LOCATION constraints für die Pins weglassen.
Wenn er das schafft, nimm die von den Tools vorgeschlagen
Pin-Locations.

Dann wirst Du nach den Xilinx-PCI Core im Design haben. Xilinx besteht
bei diesen auf feste Pinconstraints und hat 4 (?) im Angebot.
Eins davon solltest du einhalten, sonst geht die PCI-Compliance
verloren.

Tutorial für den timing analyzer könnte im Netz zu finden sein.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Tutorial für den timing analyzer könnte im Netz zu finden sein.

Kein tutorial sondern das Manual in voller Schönheit:

www.xilinx.com/support/ sw_manuals/2_1i/download/timing.pdf

Autor: Hochpass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist nochmal ein Ansatz. Wishbone ist mit Tristates aufgebaut. Habe
einfach das Modul Conbus von Opencores verwendet.
Ist diese Methode nicht auch die Platzsparendere?
Aber das könnte man nochmal umschreiben, da mir XST nach der Synthese
noch einen maximalen Takt angibt der noch 4 Mhz zu gering ist.
Habe schon Timing Constraints für die Synthese angelegt und einige
Timing Ignores eingefügt.


PCI ist auch von Opencores
http://www.opencores.org/projects.cgi/web/pci/home

Pinout ist leider schon fest. Die Platine liegt schon vor mir.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Spartan3 gibbets keine internen tristates mehr, die werden auf MUXer
abgebildet. Das ist langsamer als spartan2e. Der Xilinx Guru
Chapman hat uns persönlich von internen Tristate abgeraten. Für Muxer
ist die Technote

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp...

von Ihm lesenswert. Aber stürze dich nicht gleich auf den Bus, solange
nicht sicher ist, dass die 4MHz dort verloren gehen.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch ein timing report *.twr erzeugen und ins Forum stecken
(vorher zippen, meist gigantisch gross).


Die commandline dazu ist (bitte überprüfen):

trce -e 10000 -s 5 fpga_par.ncd fpga_map.pcf


Also maximal 10000 nicht geschaffte Pfade analysieren bei Speedgrade 5.
Das design steckt nach dem Place&route im File *.ncd, die (automatisch
aus dem ucf erzeugten physical constraints) stecken im *.pcf .

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#hi,
#hatte mal die gleiche Frage gestellt.
#Leider kann man wohl nicht nach Beitragersteller suchen.

Ich helfe mir gern mit google das auch mikrocontroller.net scannt.
Einfach "www.mikrocontroller.net" mit in die Suchbegriffe setzen. Und
es hat wohl noch einen anderen schalter goole nur in den Treffern für
diese website suchen zu lassen.

Autor: Hochpass (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So geht weiter an der Baustelle.
Habe mal versucht die Datei zu erstellen.
Der OpenRisc und der SOC sollten mit 40 Mhz laufen, wenn das irgendwie
möglich ist.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aehm, kann es sein das du keine timing constraints gesetzt hast?!

Ich seh hier nur default period constraints ...
(falsches file?)

Also den Tools musst du sagen wie schnell du dein Design haben möchtest
oder anders gesagt die tools wissen nicht welchen Takt du anlegst. Die
Frage ist nicht, wie schnell der FPGA läuft, sondern ob er mit dem
geforderten takt läuft. Um die höchste taktfrequenz zu ermitteln setzt
man die Geforderte taktperiode immer weiter nach unten, bis die Tools
immerfort mindestens einen Timing error ausgegeben.

Die Angabe der Tools einer maximalen taktfrequenz ohne Vorgaben ist
nie wirklich maximal.

Also schau die mal den constraint editor an. Du musst ein *ucf file
erzeugen (user constraint file), dort wird die taktperiode vorgegeben.
Das sollte das selbe File sein, indem du auch die FPGA-Pins den
einzelnen Signalen zuordnest.

IMHO fehlen dort folgende zeilen:

NET "CLKIN" TNM_NET = "tn_wbclk"
TIMESPEC "TS_wbclk" = PERIOD "tn_wbclk" 30 ns HIGH 50 %;

NET "pci_clk" TNM_NET = "tn_pci_clk"
TIMESPEC "TS_pci_clk" = PERIOD "tn_pci_clk" 30 ns HIGH 50 %;

NET "fpga_pciclk_osc_iob_BUFGP" TNM_NET =
"tn_fpga_pciclk_osc_iob_BUFGP"
TIMESPEC "TS_tn_fpga_pciclk_osc_iob_BUFGP" = PERIOD
"tn_fpga_pciclk_osc_iob_BUFGP" 30 ns HIGH 50 %;

NET "clk_1MHz" TNM_NET = "tn_clk_1MHz"
TIMESPEC "TS_clk_1MHz" = PERIOD "tn_clk_1MHz" 1000 ns HIGH 50 %;

Wobei ich die ersten 3 takte auf 33 MHz gelegt habe. Für PCI wird das
wohl stimmen, bei den anderen beiden musst du deine Vorgaben einsetzen
(25 ns für die 40 MHz).

Setzte dies in das ucf file ein, dann sollte erstmal eine vernünftige
Timinganalyse rauskommen, Kann ganz gut sein das dein design schon
ausreichend schnell ist :-) .


BTW: Ist daran gedacht das Signale zwischen Schaltungsteilen die
unterschiedlichen (nicht phasengleichen) Takten laufen synchronisiert
wertden müssen?.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm nochmal reingeschaut, falsche Optionen?


Report level:             verbose report, limited to 100 items per
constraint
                          unconstrained path report

Environment Variable      Effect
--------------------      ------
NONE                      No environment variables were set
------------------------------------------------------------------------ 
--------

INFO:Timing:2700 - Timing constraints ignored because advanced analysis
with
   offsets was specified.


-> eine Analyse ohne timing constraints nutzt uns nix, bitte keine
"advanced analysis" einstellen.

Autor: Hochpass (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja jetzt habe ich verstanden was du meinst.
Unser Constraints im ucf file sind:


#
# Clock-Nets
#
NET "fpga_clock" TNM_NET = "soc_clock_in";
NET "wb_clk"     TNM_NET = "soc_clock";
#NET "sram_clk"   TNM_NET = "sram_clk";
NET "pci_clk"    TNM_NET = "pci_clk";
NET "fpga_pciclk_iob" TNM_NET = "pci_clk";
NET "fpga_pciclk_osc_iob" TNM_NET = "pci66_clk";
NET "can_clk"    TNM_NET = "clk_20MHz";
NET "clk_20MHz"  TNM_NET = "clk_20MHz";
NET "clk_1MHz"   TNM_NET = "clk_1MHz";

#
# Clock timing specs
#
TIMESPEC "TS_soc_clock_in" = PERIOD "soc_clock_in" 20 ns HIGH 50%;
TIMESPEC "TS_soc_clock"    = PERIOD "soc_clock"    25 ns HIGH 50%;
#TIMESPEC "TS_sram_clk"     = PERIOD "sram_clk" "TS_soc_clock" *
1 PHASE + 9.45 ns; # 135°

TIMESPEC "TS_pci_clk"      = PERIOD "pci_clk"      30 ns HIGH 50%;
TIMESPEC "TS_pci66_clk"    = PERIOD "pci66_clk"    15 ns HIGH 50%;
TIMESPEC "TS_clk_20MHz"    = PERIOD "clk_20MHz"    50 ns HIGH 50%;
TIMESPEC "TS_clk_1MHz"     = PERIOD "clk_1MHz"   1000 ns HIGH 50%;

Autor: Hochpass (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Oder die?

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber der report ist auch nicht brauchbar:

INFO:Timing:2698 - No timing constraints found, doing default
enumeration.

Also entweder finden die tools (ngdbuild) das ucf-file nicht, oder
place&route (par) läuft mit der option -ignore_timing.
Schau dir mal das reportfile vom place&route (*.par) an. Bevor das
nicht stimmt, sind die timingreports unnütz.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder der timing_analyzer /trce findet das pcf nicht ...
In welchem Bundesland sitzt du, vielleicht ist ein treffen effektiver?

Autor: Hochpass (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bin Hannoveraner
Hab nochmal analysiert!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.