Forum: FPGA, VHDL & Co. Quartus v16.0 - Dauer des Fitters


von Quartus (Gast)


Angehängte Dateien:

Lesenswert?

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

von Quartus (Gast)


Lesenswert?

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

von Olga (Gast)


Lesenswert?

Du solltest noch zusehen, dass er die angegebene SDC Datei wieder finden 
kann, und dir dringend die ganzen kombinatorischen Schleifen ansehen... 
;-)

von Sigi (Gast)


Lesenswert?

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.

von Quartus (Gast)


Lesenswert?

@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?

von Sigi (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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?

von Quartus (Gast)


Lesenswert?

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"?

von ne ne ne (Gast)


Lesenswert?

>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

von Quartus (Gast)


Lesenswert?

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.

von Sigi (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Quartus (Gast)


Lesenswert?

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?

von Sigi (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Quartus (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von Quartus (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Sigi (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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?

von Tipp (Gast)


Angehängte Dateien:

Lesenswert?

@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?

von Sigi (Gast)


Lesenswert?

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).

von Quartus (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.