mikrocontroller.net

Forum: FPGA, VHDL & Co. Multicycle-Path Quartus


Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

hat jemand ein Beispiel - bei Google finde ich keins :'( - mit dem man 
einen Multicycle-Path für einen kompletten std_logic_vector $A nach 
std_logic_vector $B definiert?

Der Vector hat 1458Bit, weshalb jedes Bit einzeln definieren etwas sehr 
unschön wäre.

Bei sowas befindet man sich aber gleich in Regionen, wo man kaum noch 
Informationen findet.

Man könnte die schlechten Pfade nach der Timing-Analyze einzeln explizit 
definieren, das ist aber ein seltsam aufwändiger Brute-Force-Ansatz und 
nach dem Routen sind es ja eh wieder andere Pfade, die nicht passen.

Ich würde daher gerne den gesamten Vektor als Multicycle-Path 
definieren.

Hat jemand eine Ahnung, wie das funktioniert?

Vielen Dank!
Mampf

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ob das Kommando, das Vivado generiert hat auch in Quartus 
funktioniert? Vivado bietet da immerhin eine hübsche Gui dafür ...

set_multicycle_path -from [get_pins -hierarchical *state*] -to [get_pins 
-hierarchical *mid*] 2

Autor: Martin O. (ossi-2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bei mir hat das geklappt:

set_multicycle_path -from regB[*] -to sumAB[*] -setup 2
set_multicycle_path -from regB[*] -to sumAB[*] -hold 1

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin O. schrieb:
> Bei mir hat das geklappt:
>
> set_multicycle_path -from regB[*] -to sumAB[*] -setup 2
> set_multicycle_path -from regB[*] -to sumAB[*] -hold 1

Vielen Dank! Das probier ich aus :)

Autor: Martin O. (ossi-2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich find es immer total schwierig herauszubekommen wie man die Signale 
richtig spezifiziert.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin O. schrieb:
> Ich find es immer total schwierig herauszubekommen wie man die
> Signale
> richtig spezifiziert.

Die Signal sucht man sich m.E. am besten im Timing-Report von TimeQuest 
raus, kopiert sie von dort und "schmückt" sie anschließend im .sdc-File 
mit den passenden tcl-Wildcards.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab herausgefunden - falls ich keinen Fehler gemacht habe - 
dass ich eigentlich multicycle-path gar nicht wollte ... Scheinbar hat 
der Router dann versucht, alles andere auch zu verzögern, sodass es 
wieder zusammen passt oder so ... Ganz seltsam.

Ich probier gerade set_max_delay aus, weil ich denke, dass das 
eigentlich ist, was ich benötige.

Diese "mid"-register sind ziemlich statisch, weshalb er da das Timing 
(fast) gar nicht berücksichtigen soll.

Auch beim setzen der Register hab ich einige Taktzyklen Zeit, weshalb 
sich der Router mit dem Timing da nicht abmühen soll.

Bin mal gespannt, ob das timing-technisch was bringt.

Für state -> mid hab ich jetzt mal 15ns angegeben, für mid -> state 20 
... Das sollte doch ausreichend sein :)

Ohne constraints hat der Timing-Report einen Setup-Slack von -5,3ns bei 
5ns Clock gemeldet für state -> mid. Ich hätte das quasi ignorieren 
können, da es eh funktioniert, aber ich denke, wenn der Router nicht 
quasi durch sinnloses optimieren abgelenkt wird, könnte der Rest besser 
werden.

: Bearbeitet durch User
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Diese "mid"-register sind ziemlich statisch, weshalb er da das Timing
> (fast) gar nicht berücksichtigen soll.
>
> Auch beim setzen der Register hab ich einige Taktzyklen Zeit, weshalb
> sich der Router mit dem Timing da nicht abmühen soll.

Ich habe den leisen Verdacht, daß Du möglicherweise doch einen 
Multicycle-Pfad haben wolltest und jetzt mit set_max_delay und 
set_min_delay irgendwas asynchrones "hinzwirbeln" willst. Einfach 
deswegen, weil set_min_delay und set_max_delay meist stumpf falsch ist.

Ohne Multicycles geht TimeQuest davon aus, daß die nächstgelegene 
Taktflanke am Zielregister die ist, zu der die (kombinatorisch 
ermittelten) Daten stabil abgreifbar sein müssen.

set_multicycle_path sagt "du brauchst dich nicht abmühen, mir reicht's, 
wenn das Ergebnis da ist, wenn ich beim nächsten (oder übernächsten) Mal 
vorbeikomme".

Das ist ein Versprechen.

Du mußt dann in deinem Design sicherstellen, daß das auch wahr ist (Du 
am Zielregister tatsächlich auch erst frühestens zur "versprochenen" 
Taktflanke mit den Daten etwas anstellst). Das wird wahrscheinlich nicht 
ohne Designänderung funktionieren, wenn nicht z.B. sowieso schon 
irgendwie ein "valid" Signal oder ein "Flankenzähler" vorhanden ist. 
Wenn Du das aber gemacht hast, wird das Timing auf diesem 
kombinatorischen Pfad unkritisch und der Fitter kann sich anderen 
Engpässen widmen.

set_min_delay und set_max_delay ist eine Ebene drunter. Damit legst Du 
das Fenster für die gewünschte "Signalankunft" praktisch willkürlich 
(unabhängig von irgendwelchen Signalflanken rein über die Delays) fest. 
Das kann richtig sein (wenn Du das Zeitfenster triffst, das 
set_multicycle_path auch ausgewählt hätte, dann kannst Du aber auch 
gleich - ohne potentielle Fehlerquelle - eben das nehmen), meist dürfte 
es aber schlicht danebenliegen: die Timing-Analyse paßt (weil 
"angelogen"), aber dein Design funktioniert trotzdem nicht.

: Bearbeitet durch User
Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Ich habe den leisen Verdacht, daß Du möglicherweise doch einen
> Multicycle-Pfad haben wolltest und jetzt mit set_max_delay und
> set_min_delay irgendwas asynchrones "hinzwirbeln" willst. Einfach
> deswegen, weil set_min_delay und set_max_delay meist stumpf falsch ist.

Ja ich glaub du hast recht ... Bei meinem ersten Versuch hatte ich 
vergessen, den -hold Parameter zu setzen, weswegen er dann wohl Register 
dupliziert hat.

Mit korrekt gesetztem Multipath halbiert sich der negative Setup-Slack 
gleich auf die Hälfte und es funktioniert immer noch.

Vielen vielen Dank für deine anderen Erklärungen!

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Mit korrekt gesetztem Multipath halbiert sich der negative Setup-Slack
> gleich auf die Hälfte und es funktioniert immer noch.

Schön.

Ein negativer Setup-Slack ist allerdings immer falsch. Das bedeutet, daß 
Du (zumindest aus Timing-Analyzer-Sicht) die Daten verwendest, bevor sie 
da sind.

Weil das wohl eher unwahrscheinlich ist, wenn's trotzdem funktioniert, 
stimmt mit deinen Constraints wahrscheinlich noch immer etwas nicht - 
sie passen nicht zum Design.

: Bearbeitet durch User
Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Weil das wohl eher unwahrscheinlich ist, wenn's trotzdem funktioniert,
> stimmt mit deinen Constraints wahrscheinlich noch immer etwas nicht -
> sie passen nicht zum Design.

Nein nein, der Clock ist einfach zu hoch xD

Aus Performance-Gründen overclocke ich das Design ganz erheblich, kurz 
bevor es nicht mehr funktioniert :)

Irgendwann fängt es dann an Fehler (manchmal) zu produzieren, aber der 
Geschwindigkeits-Gewinn trotz Fehlerkorrektur (d.h. nochmal rechnen 
lassen) ist deutlich höher.

: Bearbeitet durch User
Autor: Da D. (dieter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte sag uns, dass es ein reines privates Hobbyprojekt ist! ;-)

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da D. schrieb:
> Bitte sag uns, dass es ein reines privates Hobbyprojekt ist! ;-)

Haha ja, natürlich xD

Sowas würde ich in dieser Form niemals verkaufen xD

Nur für den "internen Betrieb" gedacht :)

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Irgendwann fängt es dann an Fehler (manchmal) zu produzieren, aber der
> Geschwindigkeits-Gewinn trotz Fehlerkorrektur (d.h. nochmal rechnen
> lassen) ist deutlich höher.

Wie stellst Du falsche Ergebnisse fest? Oder anders, wenn Du schon 
weißt, was rauskommen muß, warum rechnest Du dann überhaupt?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Mampf F. schrieb:
>> Irgendwann fängt es dann an Fehler (manchmal) zu produzieren, aber der
>> Geschwindigkeits-Gewinn trotz Fehlerkorrektur (d.h. nochmal rechnen
>> lassen) ist deutlich höher.
>
> Wie stellst Du falsche Ergebnisse fest? Oder anders, wenn Du schon
> weißt, was rauskommen muß, warum rechnest Du dann überhaupt?

Naja, man kann das Ergebnis leicht auf Korrektheit überprüfen - man 
sucht quasi den Input, der ein korrektes Ergebnis erzeugt und das muss 
man per Brute-Force machen, leider :)

So ähnlich wie Proof-of-Work bei Bitcoin.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.