Hallo Zusammen, ich arbeite gerade an einem FPGA-Design unter Quartus II 12.0 SP2, welches einen Arria II GX nutzt. Hauptfunktion bildet ein Regler welcher aus mehreren selbst entworfenen Komponenten zu einem QSYS-System zusammengesetzt wurde und mittels PCIe an die Außenwelt angebunden ist. Das komplette Design konnte ich bereits erfolgreich mit einer Fmax > 125 MHz erstellen. Nachdem ich jetzt einige Zeit an dem Design weitergearbeitet habe und die Entwicklungsumgebung auf den neuesten Stand gebracht habe (Quartus II 12.0 SP2), wobei ich leider nicht alle Veränderungen dokumentiert habe, bekomme ich die geforderte Fmax von 125 MHz nicht mehr hin. Die kritischen Pfade habe ich mit TimeQuest ermittelt, diese liegen alle im Bereich der verwendeten (32 Bit) Multiplizierer und Dividierwerke (LPM_DIVIDE). Ich habe bereits einige Register eingefügt, um die Pfade zu entschärfen, aber selbst das reicht nicht. Das Dividierwerk habe ich bereits mit 16 facher Pipeline konfiguriert, damit komme ich immerhin wieder auf etwa 123 MHz. In der alten Version lief der Dividierer mit nur vier Stufen problemlos bei 125 MHz. Nachdem ich nun bereits mehrere Tage versuche den Fehler zu finden, möchte ich an dieser Stelle nachfragen, ob mir jemand einen Tipp hat, in welcher Richtung ich weitersuchen soll. Welche Veränderungen an einem FPGA-Design können dazu führen, dass solche grundlegende Logik plötzlich deutlich langsamer wird? Ich bin mir noch nichtmal im klaren, ob es an einer geänderten Konfiguration, an einem Fehler innerhalb des Designs oder am Software-Update liegt. Deshalb sind alle Ideen willkommen :-) Und noch eine weitere unabhängige Frage: Wie managt ihr die Warn- und Fehlermeldungen bei größeren Designs? Mir fliegen hier an die 800 Meldungen um die Ohren, der größte Teil davon wird durch automatisch generierte QSYS-Teile verursacht. Klar kann man die Meldungen unterdrücken um wenigstens die im Bezug auch die eigenen Teile relevanten nicht zu übersehen. Aber ist das wirklich normal, bei einem fertigen IP-Core (z. B. PCIe) mehrere hundert Warnungen zu erhalten und diese einfach "hinnehmen" zu müssen? Peter
Lass doch mal den Design-Space-Explorer drüberlaufen, wahrscheinlich hattest du in deiner alten Quartus Version das ein oder andere Setting anders gesetzt.
Hallo Peter, ich hatte das Problem bei meinen Tests mit dem Nios auch das das Qsys Design eine geringere Fmax erzeugt hatte. Habe dann den Tipp bekommen bei Qsys auf dem "Project Settings" Tab mal nach der Einstellung für "Limit interconnect pipeline stages to" zu schauen. Was passiert wenn Du diesen Wert auf 4 stellst, wir es dann besser? Gruß, Michael
Danke für eure Antworten! Den "Design-Space-Explorer" kannte ich noch nicht, den lasse ich gerade drüberlaufen und bin gespannt, was für Ergebnisse rauskommen. Zu den "Interconnect pipeline stages": Die habe ich bereits auf 4 gestellt. Mir scheint jedoch, dass nicht die Avalon-Logik zu langsam ist, sondern der kritische Pfad bereits innerhalb der LPM_DIVIDE-Komponente auftritt. Nachfolgend der schlechteste "Top failing path" aus TimeQuest:
1 | Slack: -17.432 |
2 | From Node: sys_msmst:i_qsys|pi_control_slave:i_pi_control|pi_control:i_pi_control|lpm_divide:i_divider|lpm_divide_2or:auto_generated|sign_div_unsign_jqh:divider|alt_u_div_jgg:divider|altshift_taps:DFFQuotient_rtl_0|shift_taps_8p21:auto_generated|altsyncram_hv91:altsyncram4|ram_block5a8 |
3 | To Node: qsys_msmst:i_qsys|pi_control_slave:i_pi_control|pi_control:i_pi_control|lpm_divide:i_divider|lpm_divide_2or:auto_generated|sign_div_unsign_jqh:divider|alt_u_div_jgg:divider|DFFStage[115] |
4 | Launch Clock: i_qsys|i_pcie|pcie_internal_hip|arria_ii.arriaii_hssi_pcie_hip|coreclkout |
5 | Latch Clock: i_qsys|i_pcie|pcie_internal_hip|arria_ii.arriaii_hssi_pcie_hip|coreclkout |
6 | Relationship: 8.000 |
7 | Clock Skew: 0.039 |
8 | Data Delay: 25.340 |
Peter
hi (vor weg.. altera kenn ich nicht wirklich, aber) ein Dividier bräuchte doch "normalerweise" pro bit breite ein Register-Stufe. Wenn du 4 Stufen hattest, musst die logik einer 8 bit Division in einen Schritt passen. Das soll bei > 125 MHz klappen ? Kann ich irgendwie nur schwer glauben. Da glaube ich deine 16 Stufen schon eher, das klingt vernünftig. Cheers.
Puh, wie die Division intern aufgebaut wird fehlt mir das Wissen. Ich meine jedoch dass es schon einmal mit vierfachem Pipelining und 125 MHz ging. Wie auch immer, wenn ich die Division 16-fach pipeline, dann kriege ich den kritischen Pfad bei meinen 32-Bit-Multiplikationen. Und das meine ich hat definitiv schonmal getan... Insgesamt habe ich sieben Multiplikationen (32 x 32 -> 64 Bit), es werden insgesamt 28 "DSP block 18 Bit elements" verwendet, das sollte doch bei der Taktrate drin sein, oder? Peter
Nachtrag: Die 28 "DSP block 18 Bit elements" könnten natürlich auch von der Division kommen und zufällig genau 4x7 Stück sein. Es werden laut "Fitter DSP block usage summary" genau sieben "Simple Multipliers (36-bit)" instanziiert. Das deutet doch wiederum darauf hin, dass er dedizierte Hardare für eine 36-Bit-Multiplikation hat. Sind die derart langsam? Peter
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.