Welche Möglichkeiten habe ich, einen bestehenden PC für Synthesen zu optimieren? Genannt wurden bisher: - Command Line verwenden, also ohne GUI / IDE - viel RAM Gerade zum RAM habe ich mir Gedanken gemacht: Die Tools laufen ja nicht so richtig viel schneller, wenn man ein 64-Bit-System benutzt, abgesehen von dem RAM-Speicher. So eine arge Verbesserung habe ich da aber noch nicht gesehen, wenn ich z.B. WinXP32 und Win7-64 vergleiche. Ich führe das auf die Nutzung der Festplatte zurück: Xilinx z.B. ist Weltmeister im Anlagen von files. Wäre denkbar, mit W64 einen grossen RAM-Speicher zu verwenden und diesen als virtual RAM-Disk zu benutzen? Wie liesse sich das einstellen?
Ralli schrieb: > Welche Möglichkeiten habe ich, einen bestehenden PC für Synthesen zu > optimieren? Genannt wurden bisher: > > - Command Line verwenden, also ohne GUI / IDE > - viel RAM > > Gerade zum RAM habe ich mir Gedanken gemacht: > > Die Tools laufen ja nicht so richtig viel schneller, wenn man ein > 64-Bit-System benutzt, abgesehen von dem RAM-Speicher. So eine arge > Verbesserung habe ich da aber noch nicht gesehen, wenn ich z.B. WinXP32 > und Win7-64 vergleiche. Ich führe das auf die Nutzung der Festplatte > zurück: Xilinx z.B. ist Weltmeister im Anlagen von files. Afaik liefen die Xilinx Toools unter Linux ein gutes Stück schneller als die Windows Pedants. Der Austausch der Projekt Harddisk gegen eine (leere) SSD bringt auch einiges (Stichwrd Disk-IOs). Alternativ auch gerne eine Ramdisk entsprechender Größe... > > Wäre denkbar, mit W64 einen grossen RAM-Speicher zu verwenden und diesen > als virtual RAM-Disk zu benutzen? wie gesagt, Disk-IO ist durchaus ein Thema... > Wie liesse sich das einstellen? Kennt jemand eine 64Bit Windows Version? Gruß Vanilla
Vielleicht wäre eine schnelle Festplatte die richtige Lösung wenn XILINX viele Daten schreibt. z.B. so etwas: OSZ PCI-Express SSD http://www.amazon.de/OCZ-PCI-Express-240GB-interne-Festplatte/dp/B005F30JBM
Bevor man blind rumrät sollte man in Erfahrung bringen, was denn dabei die Performance-Bremse ist: - CPU, nur 1 Thread relevant - CPU, Last auf mehrere Threads verteilt - Disk-I/O bremst CPU - RAM zu knapp, führt zu Paging SSD bringt nur was, wenn viel Disk-I/O beteiligt ist. Also ob während der Synthese wirklich viel auf der Platte malocht wird und die CPU derweil nicht zum arbeiten kommt. Nicht aber, wieviele Files der Installer auf die Platter klatscht. Process Explorer kriegt raus, wie die Lastverteilung auf Threads ist. Ist das bloss einer, und der ist voll ausgelastet, dann ist einzig die CPU relevant, und zwar der Turbo-Modus. Der Rest zählt dann wenig.
:
Bearbeitet durch User
A. K. schrieb: > Bevor man blind rumrät sollte man in Erfahrung bringen, was denn dabei > die Performance-Bremse ist? > > - CPU, nur 1 Thread relevant > - CPU, Last auf mehrere Threads verteilt > - Disk-I/O bremst CPU > - RAM zu knapp, führt zu Paging > > SSD bringt nur was, wenn viel Disk-I/O beteiligt ist. Also ob während > der Syntese wirklich viel auf der Platte malocht wird, nicht wieviele > Files der Installer auf die Platter klatscht. > > Process Explorer kriegt raus, wie die Lastverteilung auf Threads ist. > Ist das bloss einer, und der ist voll ausgelastet, dann ist einzig die > CPU relevant, und zwar der Turbo-Modus. Der Rest zählt dann wenig. Bis vor einigen Versionen startete die gesamte Xilinx Synthese ledigich einen Thread. In neueren Versionen ist wohl das Placing? multithreading, einen grossen Performanceschub bzw. Auslastung von mehr als einer CPU konnte ich in den gemonitorten Projekten nicht beobachten. Imho ist ein schneller Kern mit großen Caches deutlich mehr wert wie ein Sack voll weiterer CPU-Kerne. Die Menge des zur Verfügung stehenden RAMs ist nur für größere FPGAs von Relevanz. Hierzu gibt es von Xilinx aber entsprechende Dokumentation. Imho lassen sich größere Projekte auf den Boliden nicht mit einem 32Bit Windows synthetisieren... Gruß Vanilla
A. K. schrieb: > SSD bringt nur was, wenn viel Disk-I/O beteiligt ist. Also ob während > der Synthese wirklich viel auf der Platte malocht wird und die CPU > derweil nicht zum arbeiten kommt. Nicht aber, wieviele Files der > Installer auf die Platter klatscht. Die Größe der Xilinx Installation ist zwar schon inflationär, aber es geht hier tatsächlich um Disk-IO der zig bis hunderten teils temporären Files welche Xilinx anlegt, schreibt appended und anschliessend verwirft bzw. auf der Platte zurücklässt... Das können je nach Projekt dann schon ein paar hundert MB sein, welche in kleinen Häppchen dahinerstellt und prozessiert wurden... Die ganze Xilixn Toolchain kann Ihre Herkunft einer Vielzahl kleiner? Funktionen welche sich lustig einander zu pipen nicht verhelen. Das ganze ist in der UNIX Welt gang und gebe und dort entsprechend optimiert. Das dürfte auch schlussendlich der Grund sein, warum die Xilinx-ISE unter Linux immer schneller fertig war wie unter Windows...
Moin, Vanilla hat recht, vor ca. 4 Jahren lief ISE, entweder 9.x oder 10.x bei mir fast doppelt so schnell unter Linux wie unter Windows. Aber nix multithreaded Synthese, das lustige war allerdings, dass der IDE-Task zur Anzeige des drehenden "busy"-Icons einen Kern schon fast ausgelastet hat.. Also ist der Umstieg auf Makefile/Commandline schon mal gar nicht so schlecht, Memory spart man auch etwas. Ich würde der Kiste bevorzugt viel RAM spendieren, und unter Linux auch mal eine RAM-Disk für vielen Temporärkram einsetzen. Das half zumindest in der Vergangenheit bei riesigen GCC-Projekten. Allerdings braucht man doch oft die Temporärdateien als nichtflüchtig, und das HD-Caching ist unter Linux ziemlich gut, dass man damit heuer wohl nicht mehr viel Performance rausholt. Grüssle, - Strubi
Ich hab das erst letztens mal wieder getestet, unter Win x64 ist es bis auf ein paar Sekunden die für die xml zu html Transformation drauf gehen egal ob Command Line oder ISE, die ruft doch die gleichen Programme auf. Auch eine SSD bringt nicht viel, die allermeiste Zeit wird im RAM gearbeitet. Viel RAM und eine CPU mit viel Cache bringen einiges. Mein Arbeitsplatz Rechner ist eine HP Z620 mit 16GB und einem Xeon das geht sehr ordentlich. Map und par können inzwischen MT aber nur beschränkt und wenn man nicht die -power Option an hat.
Ein Rechnerverbund bringt dann vermutlich auch nichts, oder? Ich kenne das aus dem Bereich des Renderings, wo sie 8-16 Rechner zusammenschalten, um auf Tempo zu kommen.
Dazu müsste die Software erst mal parallelisiert sein. Aber bei Xilinx kann XST überhaupt kein MT, MAP nur maximal 2 Threads und PAR kann theoretisch alle CPU Kerne benutzen, aber zeitlich btingt das nach meinen Messungen nichts weiter. Ich vermute die Algoritmen lassen sich nicht so ohne weiteres parallelisieren, sonst hätten die das schon längt getan. Bei großen Designs übersetzt man ja eh nur selten, erst wenn die Simulation alles OK ansagt. Ich muss auf ein Artix 7 200T Design trotz der Z620 noch etwa eine Stunde warten, und da ist der nicht mal halb voll.
Christian R. schrieb: > Ich vermute die Algoritmen lassen sich > nicht so ohne weiteres parallelisieren, Parallelisierung bestehender sequentieller Programme ist harte Arbeit, wenn sich das von der Arbeitsweise des Programms nicht grad aufdrängt. Solche Kosten investiert man nur, wenn man dadurch mehr Gewinn einfährt. Den machen die aber über die FPGAs selbst, nicht über das Programm - und sucht sich wirklich jemand FPGAs nach der Laufzeit des Designprogramms aus?
:
Bearbeitet durch User
A. K. schrieb: > und > sucht sich wirklich jemand FPGAs nach der Laufzeit des Designprogramms > aus? Wenn du mal 1 1/2 Stunden gewartet hast bis alles durch ist und dabei ein FPGA-Entwickler zuschaut oder du immer auf 5 andere warten musst, bis du einen beschissenen Bugfix durchbringst und das ganze 2 Stunden dauert dann - JA!
Wenn möglich, bestücken wir generell größere FPGAs in Prototypen. Dadurch laufen die Tools schneller und man kann auch Alternative Implementierungen ausprobieren (von Debug-Designs gar nicht zu sprechen). Meine Erfahrungen mit Quartus allgemein: MacBook Pro 13 i5 mit 2.5 GHz, SSD und 16 GByte, Windows/Linux//Quartus in VMware ist rund doppelt so schnell fertig, wie native auf einem älteren Xeon E5420 (2.5 GHz Quad-Core) mit Festplatte und 8 GByte RAM. Auf einem i7-2600K (SSD, 16 GByte RAM, 3,4 GHz) ist das Desin rund 3-4 Mal schneller durch, als auf dem Xeon. Also: Xeon: 100 % MacBook i5 200 % i7-2600K 300 % Der nächste Rechner wird mindestens 32 GByte RAM haben, 6 Kerne und SSD sowieso. Ich habe keine Lust mehr extra Rechner für FPGA-Designs anzuschmeißen, muss also alles in VMwares laufen. Grüße Kest
Kest schrieb: > Wenn möglich, bestücken wir generell größere FPGAs in Prototypen. > Dadurch laufen die Tools schneller und man kann auch Alternative > Implementierungen ausprobieren (von Debug-Designs gar nicht zu > sprechen). Das größere FPGAs generell schneller synthetisiert werden mag ich nicht unterschreiben. Oft machen gerade zu grosse FPGAs durchaus Probleme, vor allem dann wenn Schaltungsteile sich geometrisch über einen weiten Bereich erstrecken (IOs), dann noch Besonderheiten (DSP/Multiplier), BRAM und ggfs. Regional Clocks in Spiel kommen... Da passiert es dann schon mal gerne dass die XST zwischenrein beim größeren FPGA das RAM (im Rechner) ausgeht, die XST das Handtuch wirft oder aber auch nach ein paar zusätzlichen Stunden dann doch eine Lösung findet. Das gleiche Design lief auf einem kleineren FPGA (Füllgrad im kleineren 50-60%) in wenigen Minuten durch... Is also kein generelles Heilmittel Manchmal hilft auch den letzten FPGA Synteselauf als Guide mitzugeben, kann aber ebenfalls wiederum fürchterlich schief gehen. Tröstet es eigentlich wenn ich erzähle das 1989 ein Syntheselauf für einen XC2064 (64 FFs, 64 4fach--LUT, keine BRAMs, keine ...) ein Syntheselauf auf einer Highend Maschine ( 80486-EISA Rechner (Full-Size AT mit 16MB Speicher!!!), 80486-33MHz, EISA Cache SCSI-Controller mit >20MB/s !!!) gerne mal 24 Stunden gedauert hat, einem das Design dann mit 98% vor die Füsse geworfen hat und man dann nochmals 2 Stunden gebraucht hat um die fehlenden 2 Verbindungen von Hand zu verlegen.
Vanilla schrieb: > Tröstet es eigentlich wenn ich erzähle Ja, ich kann mich auch noch an Designs hier 2004 erinnern, die 512 Makrozellen eines XC2C512 benutzt haben und dann ISE nach mehreren Stunden sagte, dass es doch nicht ganz reinpasst...und die Rechner waren für damalige Verhältnisse schon recht schnell. Deswegen simuliert man ja und implementiert erst wenn nötig.
Kest schrieb: > Der nächste Rechner wird mindestens 32 GByte RAM haben, 6 Kerne und SSD > sowieso. Ich habe keine Lust mehr extra Rechner für FPGA-Designs > anzuschmeißen, muss also alles in VMwares laufen. > > Grüße > Kest Hallo Kest, das hat vor allem auch dann Vorteile wenn Du dein FPGA Design mehrere Jahre supporten musst. Eine Syntheseumgebung in eine VM gesperrt und Du kannst sicher sein dein Design auch nach Jahren noch lauffähig zu synthetisieren. Bei Xilinx z.B. war es in den vergangenen Jahren mehr als einmal passiert, dass neuere ISE-Versionen ältere Coregen-Componenten nicht weiter unterstützen, neuere Versionen kein lauffähiges Design mehr ergaben (kein Fehler in der (Logik-) Simulation feststellbar, von Dritt-Firmen gelieferte Netzlisten IPs nicht mehr einzubinden waren oder,oder...
Vanilla schrieb: > das hat vor allem auch dann Vorteile wenn Du dein FPGA Design mehrere > Jahre supporten musst. Deshalb gibt es beim Datenrelease von einem Projekt auch ein VMWare-Image mit allen Tools, mit denen man alles compilieren/synthetisieren kann :-) Mittlerweile sind das schon einige ;-) Es ist auch einfacher verschiedene Tool-Versionen auszuprobieren, als wenn man alles native installiert. Ein Glück kann Altera alle Quartus Versionen parallel installieren, und es funktioniert auch ganz gut (samt ModelSIM und NIOS-Stuff) Ich muss aber sagen, ein langsamer Rechner ist auch als eine erzieherische Maßnahme zu verstehen ;-) "Kleine" Änderungen oder "mal schnell was ausprobieren" ist dann nicht drin
Kest schrieb: > Ich muss aber sagen, ein langsamer Rechner ist auch als eine Und als allgemeine Ausrede wieso die Arbeit nicht in der projektierten Zeit erledigt werden konnte ;-) (geschrieben auf einem AMD Turion Dual Core mit 1,75 GiB RAM und magnetischer Festplatte)
Wir verwenden ganz normale PCs mit 2,4GHz und 4GB RAM, die aber offiziell als "Workstation" deklariert sind. Wenn man sich mit sowas abquälen muss, dauert es dann halt. Wir machen aber auch nur ganz kleine FPGAs.
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.