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
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
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.
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
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.
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.
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.
#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
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.
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?sTechX_ID=kc_multiplexer&iLanguageID=1&iCountryID=1&multPartNum=2 von Ihm lesenswert. Aber stürze dich nicht gleich auf den Bus, solange nicht sicher ist, dass die 4MHz dort verloren gehen.
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 .
#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.
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.
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?.
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.
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%;
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.
oder der timing_analyzer /trce findet das pcf nicht ... In welchem Bundesland sitzt du, vielleicht ist ein treffen effektiver?
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.