Hallo zusammen, ich habe gestern auf Quartus 16.0 umgestellt und mein Projekt neu erstellt (selbstgeschriebene VHDL Dateien mitgenommen (5 Stück)) und IP Cores komplett neu angelegt. Das Projekt beinhaltet eine Matrix-Vektor-Multiplikation, eine Wurzel, mehrere MACs, einen Dividierer, 2 CORDIC Einheiten, und Konstanten (sfixed aus VHDL 2008). Die Simulation sah soweit gut aus. Der Grund für die Umstellung war, dass ich nun einen Cyclone V (vorher den C4) benutze und mit Quartus v15.0 einen Fehler ausspuckte, als ich mit dem "Device Installer" die Datei für C5 hinzufügen wollte. In Altera-Forum habe ich gelesen, dass eine Neuinstallation helfen soll. Dann habe ich mir gedacht, dass ich dann direkt auf v16.0 umsteige. Jetzt das Problem: Der Fitter hat 9:29:56 gedauert (9 Stunden und 29 Minuten) und lief gestern Nacht. Ich konnte das gerade gar nicht glauben, also habe ich einmal in die Message Box geguckt. Die Ausgabe ist im Anhang. Die gute Nachricht: Das Fitter Ergebnis ist besser als beim Cyclone 4 und Quartus v15.0. Jedoch hat es dort nur 10min gedauert (für alles). Unter Assignments -> Stettings -> Compiler Settings -> Advanced Settings (Fitter) kann man Einstellungen vornehmen. Jedoch habe ich ehrlich gesagt keine Ahnung von den Einstellungen dort. Hat jemand schon mal ein ähnliches Problem gehabt bzw. hat Erfahrung mit den Fitter Einstellungen? Vielen Grüße und besten Dank im Voraus
So schnell lösen sich die Probleme von selbst. Ich habe die Fitter Settings von v15 und v16 verglichen. Dabei ist mir aufgefallen, dass es in v15 den Einstellungspunkt "Advanced Placement Optimization" nicht gibt. Ist wohl neu in v16 hinzugekommen. Den habe ich jetzt deaktiviert und siehe da: 10min für alles so wie vorher. Einziger Nachteil: Es werden 51% vom FPGA und nicht 50% vebraucht. Aber auf das eine Prozent kann ich versichten :D
Du solltest noch zusehen, dass er die angegebene SDC Datei wieder finden kann, und dir dringend die ganzen kombinatorischen Schleifen ansehen... ;-)
Quartus schrieb: > Jedoch habe ich ehrlich > gesagt keine Ahnung von den Einstellungen dort. Hast Du die Einstellungen mal geändert (in 15.0 oder 16.0)? Kann mir eiglich nicht vorstellen, dass da eine neue Einstellungsoption hinzukommt, die die Zeiten um das zigfache erhöht.
@Olga Danke für den Hinweis. Um ehrlich zu sein, ist es mein erstes größerer FPGA Design und da ist vieles für mich neu. Ich werde mir gleich mal den Artikel von Lothar Miller durchlesen und mir TimeQuest genauer angucken. @Sigi Hatte bei beiden in den Compiler Einstellungen nichts verändert. Mich wundert es ja auch, dass diese kleine Einstellung womöglich die 9 Stunden verursacht hat. Gibt es denn bei dir eine Einstellung die "Advanced Placement Optimization" heißt? Wenn ja, wie ist diese eingestellt?
Auf meinem Rechner hier habe ich nur ältere Quartus-Versionen und diese Option sagt mir mir nichts. Hast Du für Dein Projekt alle Clocks im SDC-File spezifiziert (Timing), denn das kann bei der Synthese viel ausmachen (z.B. Dauer) ? Quartus geht ja bei fehlender Spec von der max. Clockrate aus und gibt sich dann die grösste Mühe dieses Timing zu erreichen.
Kann es sein, dass der Rechner über Nacht in einen eco-Modus verfallen ist und runtergebremst wurde? Wie verhält sich die Zeit, wenn man die neue Option weglässt?
Weltbester FPGA-Pongo schrieb im Beitrag #4681063: > Kann es sein, dass der Rechner über Nacht in einen eco-Modus > verfallen > ist und runtergebremst wurde? > > Wie verhält sich die Zeit, wenn man die neue Option weglässt? Dann ist wieder alles beim alten. Den Eco Modus würde ich ausschließen, da der Fitter beim ersten Anlauf schon 30min+ lief und die ganze Zeit an einer Stelle blieb, die Später dann mit ~4h angegeben wurde. @Sigi Das sdc File fehlte. Ich habe nun versucht mein erstes sdc File zu erstellen. Einige Dinge sind noch etwas unklar (Virtuelle Takte und der Befehl "derive_clock_uncertainty"). Ich hoffe, dass es da bald bei mir "Klick macht". Mit dem SDC file und der von mir wieder reingenommenen Einstellung (der Übeltäter?) dauert alles wieder gewohnt lange (10min). Also war das fehlende sdc File schuld? @Olga Ich habe nun alle Kombinatorischen Schleifen beheben können. Latches werden laut Compilation Report auch nicht erzeugt. Jedoch habe ich nun folgendes Problem: Ich habe extrem schlechte Slacks und entsprechend ein sehr schlechtes fmax. Daran sitze ich gerade. Schon bisschen frustrierend, aber mir war diese Problematik nicht bewusst, daher ist die Zeitplanung für das Projekt etwas "sportlicher" geworden. @all Wenn ich ein sdc File habe, wie sehen für Inputs und Outputs typische Delays aus? Ich habe einen 50MHz Takt (20ns) und min/max auf 4/6 gestellt (Inputs und Outputs). Leider habe ich keine Quelle gefunden, wo beschrieben wurde, nach was für Kriterien die Delays eingestellt werden sollen. Gibt es dafür bewährte "Faustformeln"?
>Jedoch habe ich nun folgendes Problem: >Ich habe extrem schlechte Slacks und entsprechend ein sehr schlechtes >fmax. Daran sitze ich gerade. Schon bisschen frustrierend, aber mir war >diese Problematik nicht bewusst, daher ist die Zeitplanung für das >Projekt etwas "sportlicher" geworden. Du entwickelst professionelle FPGA-Desings und kennst keine kombinatorischen Schleifen? Oha... Gruß Jonas
Dies ist ein Projekt an der Uni, da ich noch Student bin. Als professionell würde ich es daher auf keinen Fall bezeichnen. Nach kleineren VHDL Gehversuchen ist dies mein erstes größeres Projekt. Wobei "groß" sicherlich relativ ist.
Quartus schrieb: > Das sdc File fehlte. Ich habe nun versucht mein erstes sdc File zu > erstellen. Einige Dinge sind noch etwas unklar (Virtuelle Takte und der > Befehl "derive_clock_uncertainty"). Ich hoffe, dass es da bald bei mir > "Klick macht". Vlt macht's ja klick nach der Lektüre div. Tutorials. Von Altera sehr gut: TimeQuest Timing Analyzer Cookbook Dort werden alle Basistechniken vorgestellt. Liest sich gut und schnell. Arbeite auf jeden Fall die Beispiele Rund um die Clock-Netzwerke durch und setze kleine Demos auf und analysiere die Timings in Timequest (graph. Tool). Quartus schrieb: > Mit dem SDC file und der von mir wieder reingenommenen Einstellung (der > Übeltäter?) dauert alles wieder gewohnt lange (10min). Also war das > fehlende sdc File schuld? Dazu müsste man genau die Einstellung kennen (und die Annahmen dahinter). Fehlende SDC-Files werden durch Default-SDC ersetzt (1ns Clock etc.). Wenn dann je nach Einstellung Quartus sich alle Mühe gibt die zu erfüllen.. dann heisst's wohl warten. Quartus schrieb: > Ich habe extrem schlechte Slacks und entsprechend ein sehr schlechtes > fmax. Daran sitze ich gerade. Schon bisschen frustrierend, aber mir war > diese Problematik nicht bewusst, daher ist die Zeitplanung für das > Projekt etwas "sportlicher" geworden. Naja, ein Problem ist, das man am Anfang z.B. viel zu viele Signale unbewusst verknüpft und daraus logisch ein Neues gewinnt. Du musst Dir ja bewusst sein, dass die komplette Logik in LUT4s (bzw. je nach Familie LUT6s) zerlegt wird. Wenn Du also z.B. 24 Signale verknüpfst, dann erhälst Du auch einen entsprechenden LUT-Baum und damit sehr kleines F-MAX. Hier braucht man ein wenig Erfahrung bzw. Techniken um das zu mildern/vermeiden. Aber "schlechte" Slacks müssen ja nicht schlimm sein, Du gibts ja die Taktrate vor und Quartus berechnet daraus das Timing, also auch die Slacks. Wenn das noch ins Timing passt solls nicht weiter stören. Und hohe Taktrate heisst ja auch nicht "höhere" Performance. Du kannst ja komplexe Logik in wenigen Schritten oder vergleichbare "kleine" Logik in vielen Schritten ausführen. Das zu entscheiden ist nicht immer leicht. Quartus schrieb: > Wenn ich ein sdc File habe, wie sehen für Inputs und Outputs typische > Delays aus? Ich habe einen 50MHz Takt (20ns) und min/max auf 4/6 > gestellt (Inputs und Outputs). Leider habe ich keine Quelle gefunden, wo > beschrieben wurde, nach was für Kriterien die Delays eingestellt werden > sollen. Gibt es dafür bewährte "Faustformeln"? Wie gesagt, lies Dir das Tutorial durch, da werden die Netzwerke und die Formeln dazu erklärt. Ohne das gibst Du nur blind irgendwelche Werte ein, die überhaut nicht zu Deiner Schaltung passen. Default-Werte gibt es da nicht. Die ganze Timing-Geschichte muss Du Dir als Designbereich parallel zu Deinem HDL-Design vorstellen, der leider oft genug weggelassen oder viel zu dürftig geplant wird.
Sigi schrieb: > Die ganze Timing-Geschichte muss Du Dir als Designbereich > parallel zu Deinem HDL-Design vorstellen, der leider oft > genug weggelassen oder viel zu dürftig geplant wird. Wieso ist das ein Thema parallel zum HDL-Design? Ich würde eher sagen, dass das der integrale Bestandteil ist, um nicht zu sagen, der Aufhänger. Das Timing das von Außen vorgegeben wird, bestimmt oft den Ansatz innen und das was man tun muss.
Danke Sigi für die ausfühliche Antwort. Die hilft mir wirklich weiter. Das Cookbook hatte ich mir gestern schon angeguckt. Zusammen mit dem Quartus Handbuch (Teil 3 - Verification) hat es heute bei den virtuellen Takten "Klick gemacht". Das Online-Tutorial über TimeQuest und ein Youtube Video von Altera haben auch sehr geholfen sich etwas zurecht zufinden. Zwar hatte ich eine Vorlesung über Integrierte Schaltungen und die ganzen Timingbezeichnungen kenne ich noch. Jedoch ist das Anwenden von theoretischen Wissen oft schwerer als gedacht. Bezüglich der Slacks: Heute Mittag habe ich schon einige Signalverknüpfungen, die unnötig waren, entfernt. Ich hab bisschen gebraucht, bis mir klar wurde, was die Timings beeinflusst. Durch einen Blick auf den RTL Viewer und die Slack Meldung habe ich mir schon gedacht, dass Signalverknüpfungen nicht einfach kreuz-und-quer über das FPGA geroutet werden sollten. Bezüglich der Input- und Output-Delays: Der FPGA kommuniziert mit einem ADC (SPI) und mit einem Seriell-zu-USB Wandler (RS232). Andere ICs, mit denen kommuniziert wird, gibt es nicht. Ich denke, dass dann die Timings anhand der Spezifikation (Datenblatt) der beiden ICs (SPI und RS232) erstellt werden müssen. Alles andere macht für mich nicht viel Sinn. Liege ich damit halbwegs richtig?
Quartus schrieb: > Bezüglich der Input- und Output-Delays: > Der FPGA kommuniziert mit einem ADC (SPI) und mit einem Seriell-zu-USB > Wandler (RS232). Andere ICs, mit denen kommuniziert wird, gibt es nicht. > Ich denke, dass dann die Timings anhand der Spezifikation (Datenblatt) > der beiden ICs (SPI und RS232) erstellt werden müssen. Alles andere > macht für mich nicht viel Sinn. Liege ich damit halbwegs richtig? Bei Seriell-USB wird die Taktrate wohl unter 20 MHz sein, da kannst Du im Prinzip alles Oben genannte ignorieren. Als Beispiel: VGA 640x480 hat 25 MHz. Da sind heutige FPGAs eiglich schon viel zu schnell, Timingprobleme wirst Du da idR kaum bekommen. Wie es bei Deiner ADC-SPI-Geschichte bzgl. Taktrateaussieht kann ich jetzt nicht sagen, aber selbst bei 50 MHz gibt's da keine grossen Probleme. Vlt. ein Tipp: Die IO-Zellen haben alle Register, die direkt mit den jeweiligen Pads verbunden sind. Die kannst Du verwenden und damit sehr gut das Timing per HDL eingrenzen. Das SDC-File dient dann nur noch zur Verifikation, nicht mehr zur Steuerung des Fitters etc. Bei "meinen" VGA-Geschichten mache ich das immer so und habe nie Pixelflimmern. Und was Deine konkrete Platine/Umgebung angeht: Zu den Timings aus dem Datasheet müssen auch noch die Verzögerungen der Platine hinzugerechnet werden. Das aber sollten sehr kleine Werte sein (unter 1 ns). Aber als WICHTIGE Übung würde ich an Deiner Stelle trotzdem mal alle Timings per SDC spezifizieren und per TimeQuest (Xilinx und Lattice haben graphisch nichts vergleichbares) nachmessen. Du hast ja nicht so viele Pins, sollte also schnell gehen.
Sigi schrieb: > Bei Seriell-USB wird die Taktrate wohl unter 20 MHz sein, Je nach Chip geht da auch mehr. Der FT 232 BL kann bis 48 MHz z.B. Der kann da bis zu 3M. Keine Ahung, ob es noch schnellere gibt.
Meine Datenraten sind eher bescheiden. Der ADC tastet mit 12,8 kHz (bei 16 Bit Auflösung) ab und die serielle Übertragung liegt bei 921600 Baud. @Sigi Vielen Dank für die weiteren Tipps. Den Tipp mit der Übung werde ich auf jeden Fall einmal machen. Klingt auf jeden Fall ratsam für mich :) @all Wie lange arbeitet ihr schon mit VHDL+FPGAs? So wie es scheint, habt ihr schon einiges an Erfahrungen gesammelt. Bei mir am Lehrstuhl bin ich der einzige, der mit FPGAs arbeitet (quasi das Studenten-Versuchskaninchen). Daher kann ich schlecht einschätzen, wo man momentan steht.
Quartus schrieb: > Ich habe extrem schlechte Slacks Wieviele Takte (alles mit 'event oder rising_edge oder falling_edge ist ein Takt) hat das Design? Und wie werden die erzeugt?
Das Design benutzt nur eine Taktquelle (Quarz auf dem Eval-Board). PLLs benutze ich nicht und jeder Prozess/jede Komponente benutzt nur das clk Signal gemäß "wait until falling_edge(clk)", welches am FPGA-Pin anliegt. Prozesse, die fallende Flanken benutzen habe ich nicht und den Ausdruck 'event habe ich sonst auch nirgendwo, da ich den "rising_edge"-Ausdruck bevorzuge. Daher ist meine Antwort: Ein Takt wird benutzt. Ich hoffe, dass ich deine Frage damit einigermaßen beantworten konnte. Die schlechten Slacks habe ich im Zusammenhang mit einer FSM. Es werden verschiedene Teilergenisse berechnet, die aufeinander aufbauen. Kleines (Pseudo-)Beispiel: Zustand N-1: ... Zustand N: Berechne arctan(y/x) = phi Zustand N+1: Berechne sin(phi) = A Zustand N+2: Berechne B = A * 123 und C = A * 456 Zustand N+3: ... Zustand N+X: Ergebnisse ausgeben B und C werden in einem Register gespeichert und dann später ausgegeben. Das Ausgangssignal heißt beispielsweise result_out. TimeQuest sagt dann, dass bzgl. A Setup-Zeiten verletzt werden in Verbindung mit result_out. Das es ausgerechnet A ist, welches das langsamste Signal sein soll, macht für mich auch Sinn. Schließlich wird das Signal A an verschiedenen Stellen im Design benutzt (langer Weg) und in Kombination mit einer Multiplikation ausgegeben (Verbindung zum FPGA-PIN). Ob es etwas bringt, wenn ich den Zustand N+2 aufteile und einen weiteren Zustand einbaue (N+2a: B = A * 123 und N+2b: C = A * 456), weiß ich nicht. Das wäre mein nächster Versuch, die Slacks zu reduzieren. Nun fällt mir spontan keine (weitere) Lösung ein, um dieses Problem zu beheben bzw. die FSM anders zu gestalten, da schließlich die Werte/Signale nacheinander berechnet werden müssen. Aber vielleicht habe ich auch einen total schlechten Ansatz bei der FSM. Wie gesagt, ich bin Neuling in Sachen FPGAs.
Quartus schrieb: > Das es ausgerechnet A ist, welches das langsamste Signal sein soll, > macht für mich auch Sinn. Schließlich wird das Signal A an verschiedenen > Stellen im Design benutzt Du kannst dir doch mit der STA (Statischen Timing Analyse) mal anzeigen lassen, welcher Pfad davon kritisch für das Timing ist.
Das Problem schlechter Slacks ist meisst eine komplexe (d.h. tiefe) Kombinatorik, weniger ein häufig genutztes Signal. Dein Automat wird ja hoffentlich nicht das gesamte FPGA füllen, d.h. die Pfade von den Signal-FFs zu den kombinatorischen Blöcken ist relativ kurz. Pfade unterscheiden sich da allerhöchstens um sehr wenige ns. Bei der Analyse gibt's in Quartus mehrere Möglichkeiten. Mach doch einfach mal unter TimeQuest eine "Timing"-Analyse. Da kann neben Quelle und Ziel auch noch "Through"-Option die Pfadmenge näher spezifiziert bzw. eingeschränkt werden. Das je FSM-Zustand gibt Dir dann den kritischen Zustand bzw. Kombinatorik.
Wenn ich mir das Bespiel so ansehen, dann dürfte hier vor allem der arcus tangens voll zuschlagen. Kommt der aus einer Tabelle oder einem CORDIC?
@Sigi und Lothar Im Anhang ist ein Screenshot von TimeQuest. Ich hoffe, dass ich den richtigen Report erstellt habe. @Pongo Der kommt von einer CORDIC Komponente. In Der Liste "Failing Paths" tauchen Signale der atan-CORDIC Einheit jedoch nicht auf. @Sigi Das Signal cos_phi wird wie folgt verrechnet
Vorherige Teileergebnisse waren: - phi und a - sin(phi) und cos(phi) - 2/a - a' und phi' Die Berechnung erfolgt mit Variablen. Zustätzlich werden viele Teilergebnisse vor der Berechnung auf die richtige Länge "gestutzt", sodass phi'' am Ende 16 Vorkomma- und 32 Nachkommabits hat. Die Berechnugnsgenauigkeit in der Simulation mit Modelsim ist ausreichend gut (Ergenisse landen in einer txt-Datei). Laut RTL Viewer wird mit cos(phi) folgendes durchgeführt 1. Multiplikation 2. Addition 3. Multiplikation 4. Addition Ist das schon eine zu tiefe Kombinatorik?
Tipp schrieb: > Ist das schon eine zu tiefe Kombinatorik? Viel zu tief(!), jedenfalls für Deinen Takt (50 MHz?). Du siehst ja schon im Bild, dass der Pfad 29.x ns verschlingt, d.h. mit ein wenig Sicherheit max 30 MHz möglich ist. Ich bin Oben jedenfalls davon ausgegangen, dass die Slacks sehr klein (und positiv!) sind, d.h. kaum noch Luft nach Oben ist. Negativen Slacks (Rot!) sagen Dir ja, dass der Compiler (Synth+Fitter) die Timings nicht einhalten kann. Lass Dir dazu mal "Report Fmax Timing" in TimeQuest ausgeben. Bem.: CORDIC (wie auch viele andere Algos) werden idR in Teilschritte aufgeteilt und diese dann getaktet ausgeführt (Pipelining). Die Ansteuerung erfolgt dann per FSM. Dir wird also nichts anderes übrig bleiben als die Berechnungsstrasse neu zu designen und dabei nur kleine Schritte zuzulassen (und hier beginnt die Kunst gegenüber in Software gegossenen Algos).
Ich habe jetzt meinen Zustandsautomaten angepasst. Die o.g. Formel habe ich in Teilschritte aufgeteilt und die Zwischenergebnisse abgespeichert, sodass pro Takt max. eine Multiplikation oder Addition stattfindet. TimeQuest sagt mir, dass mein fmax nun bei 55MHz liegt. Also quasi 5MHz Puffer zu meinem CLK von 50MHz. Vielen Dank für deine Hilfestellung, Sigi. Ohne deine Erläuterung, dass eine Kombinatorik auf dem FPGA nicht beliebig tief sein darf, würde ich immer noch an dem Problem sitzen. Im Nachhinein ist es natürlich absolut logisch, jedoch fehlte mir einfach das praktische Wissen, es zu berücksichtigen.
Bitte 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.