Hallo Leute, bin am Konfigurieren eines Spartan-6 inklusive Transceiver, FIFOs und einigem an selbstgemachten. Habe nun beim post-route-kompilieren einzelner Funktionsblöcke schon die Nase voll, weil es einfach teilweise ewig dauert, selbst wenn ich nur eine kleine Sache an einem IP Core ändere. Meine Specs: HP Elite Book mit Core i5-2520M @ 2,5 GHz Windows XP 32 Bit SP3 (2,94 GB RAM nutzbar von 4 GB) Und ne normale HDD mit (wahrscheinlich) 5400 rpm wie ich denke... Jetzt die große Frage: Was bringt am meisten Leistungsschub? SSD oder Upgrade auf Windows 7?? Beides wäre unter Umständen möglich. Ich glaube an der RAM Menge liegts bei meinen doch wieder recht kleinen Designs (die Console sagt auch was von kanpp 300 MB Usage) nicht und auch im Task-Manager zeigt nur selten ein Core von den vieren (HT) volle Auslastung... Als ich das Design früher auf nem Netzlaufwerk hatte, ging es sogar deutlich langsamer als jetzt, was mich vermuten lässt, dass es an den Festplattenzugriffen liegt... Also was bringt am meisten? (1) SSD (2) Windows 7 (3) Ein Teil des RAMs als virtuelles Laufwerk deklarieren... :/ oder (1) + (2)... Danke vielmals! Schönen Gruß
Was ist denn lange? Ich hab hier ein Virtex 4 Design, Auslastung etwa 20%, BlockRam 100% das dauert auf einer Z800 unter Windows 7 x64 etwa eine halbe Stunde komplett zu bauen. Ein Spartan 6 LX150 Design mit viel Logik aber relativ wenig BlockRAM dauert noch länger. Da helfen auch keine 16GB RAM und auch keine 10.000 u/min HDD. Da sind kaum HDD-Zugriffe dabei. Solche komplexen Sachen dauern halt, deshalb simuliert man ja bis alles klappt und implementiert dann erst.
SSD macht zwar das Arbeiten insgesamt viel schneller, bringt aber für das rechenintensive P&R nichts, vorrausgesetzt du hast genügend RAM. Da P&R CPU und Memoryintensiv und obendrein single threaded ist, hilft nur Taktfrequenz und grosser CPU Cache. Bei dieser Art von Anwendung hat sich in letzter Zeit (seit CoreDuo) nur wenig an Leistungsverbesserung getan. (bezogen auf die Taktfrequenz) Multicore hilft nur wenn das die Application auch unterstützt, Diamond von Lattice kann mehrere P&R Prozesse parallel ausführen und danach das beste Ergebnis auswählen. Was aber nur dann nütztlich ist wenn das Design eine hohe Taktfrequenz braucht und deswegen nicht jeder P&R Lauf erfolgreich ist.
Was dauert denn so lang bzw. in welchem Verhältnis steht das? Die üblichen Trödler sind Synthese, Mapping und Routing... Bei der Synthese kann man meistens nicht so viel machen. Selbst wenn man schon vor-synthetisierte Cores als .ngc einbindet, muss xst das ganze nochmal flach durchoptimieren, wenn es irgendwie Performance haben soll. Das dauert... Man könnte noch an den Optimierungen rumspielen (zB. Registerbalancing) aber spart nicht viel Realzeit, kostet dafür Timing... Wirklich viel kann man bei map/par erreichen. Ein paar grobe und grosszügige Plazierungsconstraints für Module (ala INST "MODULE_x/*" = XY:xy", am besten in der Nähe der dazugehörigen Pins) reduziert den Suchraum schon stark. Es gibt manchmal auch so Routingblindgänger, wo ewig rumgemacht wird, bis das Timing erreicht wird. Wenn man am Seed rumspielt (-t <x>) flutscht es auf einmal durch. Je ähnlicher die Designs sind, um eher bleiben die Blindgänger bei einem bestimmten Seed.
Hallo O_o, wenn das ein Trollversuch werden sollte, funktioniert er nicht. Die Linux Versionen der ISE sind ein wenig schneller als das Windows Pedant. Die SSD sollte man allerdings noch aus der Kette nehmen. Idealerweise: 64Bit Linux + 32Bit ISE + 16GB+ Hauptspeicher + komplette ISE Toolchain und Projekt in RAMdisk ... Gruß Vanilla
Gibt es Vergleichzahlen, um wieviel schneller die ISE auf Linux läuft? Und wieso eine 32-Bit Version auf einem 64 Bit System?
Ich verstehe auch nicht wieso das nicht schneller ist. Hier lastet das nur maximal einen Kern aus, macht also so 25% Last und braucht kaum RAM. Die 10 Minuten kann man zwar warten, aber es schränkt schon ein, vor allem wenn man nach dem Trial&Error Prinzip vorgeht und immer die Hardware LEDs zum debuggen nutzt. Die rund 10 Minuten braucht es hier bei einem 60% vollem Spartan3 1200, bei kleineren Sachen geht das Ganze auch schon in weit unter einer Minute. Aber ich wünsche mir eine Version die mal die ganze Hardware nutzt zum rechnen.
die synthese tasks lassen sich nicht parallelisieren, d.h. dir bringen octa core und was auch immer nix... d.h. einen core und den so schnell wie möglich...
Gustl Buheitel schrieb: > allem wenn man nach dem Trial&Error Prinzip vorgeht und immer die > Hardware LEDs zum debuggen nutzt. Dafür gibts die Simulation. Bei uns hier ist ein häufiges Implement wirklich nur noch in ganz verzwickten Fällen nötig. 10 Minuten geht doch noch. Mach mal ein Design für einen großen Virtex 6, dann kannst du erst mal richtig warten.
franke schrieb: > die synthese tasks lassen sich nicht parallelisieren, d.h. dir bringen > octa core und was auch immer nix... d.h. einen core und den so schnell > wie möglich... Wobei algorithmisch nichts dagegenspricht, 8-Kerne den Suchbaum durchsuchen zu lassen, ...
D. I. schrieb: > Wobei algorithmisch nichts dagegenspricht, 8-Kerne den Suchbaum > durchsuchen zu lassen, ... Wenns denn so einfach wäre. Ein kurze Webrecherche zu dem Thema hat mir gezeigt, dass es da noch keinen Durchbruch gibt. Die meisten Ansätze versuchen das Problem mit Partitionierung in kleinere Einheiten zu zerlegen und jede Partition einzel zu lösen. Genetische Algorythmen für das TSP scheinen erfolgversprechend zu sein, aber auch da noch kein Durchbruch. Das einzige was auch in teuren Tools gängig ist, mehrere P&R Prozesse mit unterschiedlichem Seed zu starten, und danach das beste Ergebniss zu verwenden. Das bringt aber für die Turnarround Zeit gar nichts. Ausserdem, 10 Minuten ist noch gar nichts. Bei meinem aktuellen Projekt sind es 2 Stunden, und dann ist obendrein P&R nur in ca 10-20% der Fälle erfolgreich. PS: TSP = Traveling Salesmam Problem.
Christian R. schrieb: > Gibt es Vergleichzahlen, um wieviel schneller die ISE auf Linux läuft? > Und wieso eine 32-Bit Version auf einem 64 Bit System? Hallo Christian, Belastbare Vergleichszahlen kann ich nicht presäntieren, die gemachten Tests sind nicht unbedingt represantiv bewegten sich aber im Bereich von einigen zehn Sekunden bis mehreren Minuten in einem mittelprächtigen Design (70% Resourcennutzung in einem V5-FX110 Design). (64Bit Linux Version) Interessanter Weise hat alleine der Bitgen unter Windows rund eine halbe Minute längter gebraucht als unter Windows. Zum Thema warum die 32Bit Version schneller rend als die 64Bit Version? Da gibts mehrere Gründe: 1) Der 32bit Compiler mit dem die ISE compiliert ist erzeugt kleineren Code, der optimaler gecacht bleibt. 2) Mutmaßlich braucht die 32Bit ISE auch weniger Speicher für P&R da 32Bit Daentypen und Speichertabelleneinträge nutzt und deshalb auch weniger Cachemisses als die 64Bit Version hat. Für die Linuxversion insgesamt dürfte aber vor allem sprechen, das das Filehandling unter Linux insgesamt performater ist als unter Windows.
Vanilla schrieb: > Tests sind nicht unbedingt represantiv bewegten sich aber im Bereich von > einigen zehn Sekunden bis mehreren Minuten in einem mittelprächtigen > Design (70% Resourcennutzung in einem V5-FX110 Design). (64Bit Linux > Version) Und welche Laufzeit braucht das Design? d.h. wieviel ist der Laufzeitunterschied in %? Wie verteilt es sich auf die einzelen Prozesse? (Synthese, Mapping, Place&Route)
Lattice User schrieb: > Vanilla schrieb: > Und welche Laufzeit braucht das Design? d.h. wieviel ist der > Laufzeitunterschied in %? > Wie verteilt es sich auf die einzelen Prozesse? (Synthese, Mapping, > Place&Route) Die Zeiten lagen größenordnungsmäßig bei 50 Minuten in Synthese und Mapping, Place&Route brauchten je nachdem wie gut er durch kam, zwischen einer viertel Stunde und anderthalb Stunden.
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.