Hallo zusammen, ich habe einen ziemlich vollgepackten (99%) Spartan-3 (XC3S1000), auf dem das clk-Netz ein Path-Delay von 13,7 ns hat. Durch die vier DCMs und Takt-Puffer sollte es ja möglich sein, die Taktleitung in mehrere Netze aufzuteilen. Daher meine Frage(n): Wie teile ich das Taktnetz praktikabel auf und stelle dabei sicher, dass 1) das gesamte Design synchron bleibt 2) die Optimierungsmöglichkeiten beim Implementieren nicht zu sehr beschnitten werden? Das Design besteht aus vier identischen, hochspezialisierten Cores und einer Statemachine drumherum. Ein erste Idee ist zwei DCMs jeweils einen Takt generieren zu lassen und die Takte über kreuz als Regelgröße in die DCMs rückzuführen... Danke & Gruß Christian
mehrere DCM ist nicht gut. versuch mal einfach mehrere BUFGs zu benutzen, eg DCM out zu 4 BUFGs und dann diese clk benutzen, fure jedes von 4 cores sein eigenes BUFG antti
Hmm, klingt einfach. Fast zu einfach ;-) Ich werde es versuchen, danke...
Der Erfolg ist leider mäßig, da die Logic Utilisation förmlich explodiert (116%). Ich glaube nicht, dass ich da noch viel mit einem höheren Effort Level erreichen kann. Im Moment läuft jedenfalls die Synthese mit nur zwei (statt vier) Taktnetzen. Hat jemand eine Idee beide Wünsche (Optimierung mit mehreren kurzen Taktnetzen) unter einen Hut zu bekommen? Gruß Christian
muhsame arbeit fürs optimimierung, immer wieder in fpga editor nachgucken was wirklich lost ist. xilinx tools machen manchmal mist. zum beispiel wenn ein SRL16 din einen daten eingangs inverter braucht was man mit eingangs inverter in slice machbar ware, da nimmt xilinx ISE einfach einen zusats LUT!! nur ein beispiel. dh heisst man kann nicht voll vertrauen das ISE alles immer bestens macht, tut es nicht :( antti
ein globales Taktnetz hat bei Dir wirklich 13,7 ns Delay ? Das ist ganz ordentlich... Die andere Frage ist : ist das ein Problem ? Es gibt ja offenbar nur 1 Takt, wie schnell ist der ? Wieso geht die Logik auf 116 % wenn Du statt einem glob. Clock-Buffer 4 nimmst ? Da stimmt doch was nicht . Ein BUFG für jeden Core sollte doch OK sein.
das SOLLTE OK SEIN stimmt bei xilix nicht so immer :) manches was man denkt sollte ist es jedoch nicht. antti
Das Netzlänge konnte ich jetzt in einem zweigeteilten Taktnetz und mit einigen kleinen Optimierungen auf gute 10ns reduzieren. Das ist zwar noch nicht das, wo wir hinwollen aber immerhin erträglich. @FPGA-User Im Moment läuft das System nur mit 60MHz, das Mindeste wären 100MHz (die wir nun fast erreicht haben) und das Wunschziel liegt in der Region 150-200MHz. Die verwendeten IPs (es handelt sich um hochoptimierte Krypto-IPs die mit verschiedenen Schlüsseln arbeiten) arbeiten bis ca. 250MHz. Fehlfunktionen/Rechenfehler dürfen wir uns eigentlich nicht leisten. > Die andere Frage ist : ist das ein Problem ? Nunja, ich fände es gewagt den Takt bei dieser Pfadlänge deutlich über 100MHz zu setzen. Zumindet sind die Ergebnisse für mich wenig vorhersehbar. Vielleicht kann man durch einige Handarbeit im Floorplanner die Gefahr abschätzen!?! > Wieso geht die Logik auf 116 % wenn Du statt einem glob. > Clock-Buffer 4 nimmst ? Da stimmt doch was nicht . Das Problem, das ich sehe ist, dass die vier Cores identisch sind . Im Fall eines gemeinsamen Taktnetzes dürften sich große Teile der internen Kontrolllogik "wegoptimieren" lassen, da die Zustände der IPs synchron sind. Ich vermute, dass bei getrennten Taktnetzen - die zwar synchron laufen, aber durch die Namen getrennt sind - diese Optimierung nicht mehr durchgeführt wird.
@Christian na das sind ja schon erste Fortschritte. Hinter meiner Frage "ist das ein Problem" steckt folgendes: Angenommen, Du hast nur 1 globalen Takt im FPGA, was ideal wäre, und Du setzt ein Clock-Constraint auf diesen Takt, dann gibt es aus meiner Sicht erstmal 2 Möglichkeiten a) Timing-Analyzer(TAN) meldet Fehler b) TAN meldet keine Fehler/Timing-Verletzungen Was sagt der TAN bei Dir, wenn Du 100 MHz vorgibst ? Geht das durch? Im Fall b) sollte Dir das Delay auf dem Clocknetz doch egal sein können, Hauptsache die Timing-Analyse sagt: "All constraints were met" oder ?
Habt ihr mal andere synthese tools ausprobiert, precision und synplify erzeugen in der regel bessere ergebnisse als xst.
@FPGA-User Im Design gibt es zwei Takte, einen Bustakt von 33MHz und den möglichst hohen Core-Takt der per DCM aus dem Bustakt generiert wird. Der Bustakt treibt ansonsten nur eine kleine Kommunikationsschicht am Bus und ist unproblematisch. Auf die naheliegende Lösung den Takt versuchsweise mit einer Clock-Constraint zu belegen bin ich natürlich noch nicht gekommen. :-/ Das werde ich gleich nächste Woche ausprobieren, ich habe das aktuelle Design übers Wochenende leider nicht zur Hand. @Tobias In der Lösung mit nur einem Taktnetz war der Unterschied zwischen Synplify Pro und XST marginal, ich werde aber auch das in der nächsten Woche noch einmal ausprobieren. Außerdem werden wir den größten Teil der Toplevel-Statemachine nun in den externen Buscontroller auslagern. Ich bin fast sicher, dass sich dadurch ein großer Sprung in der Geschwindigkeit erreichen lässt. Vielen Dank bereits jetzt für die Tips, ich werde mich wieder melden, sobald ich neue Ergebnisse habe. Aber jetzt ist erstmal Wochenende :-)
@Christian das hast Du doch nicht ernst gemeint, dass Du kein Clock-Constraint gesetzt hattest ;-) Einen randvollen 3s1000 und die Synthese ohne Constraints gestartet, bei 2 Taktnetzen und DCMs mit dem Ziel 150 - 200 MHz , nee das kann nich sein ....
Peinlich genug ist es ja... in den Tools ist zwar überall die Optimierung hochgedreht, aber in den Constraints haben wir es wirklich nicht gesetzt. Man, man, man, Sachen gibt es duckundweg
Hallo nochmal, späte Antwort, aber die Priorität liegt im Moment auf anderen Teilen des Projekts. Die Constraints und einige kleine Optimierungen haben scheinbar geholfen, das Design lässt sich nun ohne Fehlermeldung auch mit 150 MHz synthetisieren und läuft auch - in den meisten Fällen. Bei niedrigerem Takt in allen Fällen. Dem ist noch auf den Grund zu gehen :-( Noch eine andere (blöde?) Frage: wenn ich bei der Synthese den DCM weglasse und auf einem Dev-Board direkt den Takt einstellen will liefert mir der Timing-Report bis zu halb so lange (!) Pfadlängen für das interne Taktnetz wie mit vorgeschaltetem DCM. Ist das ein Phänomen auf das ich keine Hinweise in den Xilinx-Docs finde oder liegt das wirklich an der Pfadverlängerung durch einschleifen des DCMs? Gruß Christian
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.