Forum: FPGA, VHDL & Co. timing violations, unterschiedliche clock domains


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christian (grobig80)


Lesenswert?

Hallo,

Ich versuche gerade ein Testprojekt zum funktionieren zu bringen wo ich 
2 unterschiedliche Takte habe.
Bisher habe ich der Einfachheit halber immer nur mit einem Takt 
gearbeitet oder von einer schnellen auf eine langsame clock domain 
zugegriffen (Signale über flipflops einsynchronisiert).
Jetzt versuche ich aber genau den umgedrehten Fall, von langsam auf 
schnell und da klappts natürlich mit dem timing überhaupt nicht mehr.
Quartus meckert zu Recht an das timing kann nicht eingehalten werden 
(setup negative slack, ~ -4ns).
Versuche an irgendwelchen constrains rumzubasteln und es damit 
hinzubekommen sind an nicht-wissen kläglich gescheitert von daher hab 
ich es erstmal anders probiert, leider ohne Erfolg.

Also das ganze ist ein USB keyboard -> PS2 converter und PS2 frame 
decoder:
Haupttakt top level entity = 50 MHz
ulpiToPS2 Komponente und PS2decoder Komponente Takt = 60 MHz -30° 
verschoben zu einem externen 60 MHz Takt vom USB phy, generiert durch 
eine PLL, die Verschiebung muss wohl beim deca board so sein sonst gibt 
es Probleme mit dem TUSB1210.

Der PS2decoder hat 3 outputs:
- FrameReceived (1 bit) (wird gesetzt wenn ein PS2 frame empfangen wurde 
und gelöscht wenn FrameAck gesetzt ist)
- FrameError (1 bit) (wird gesetzt wenn ein Fehler im empfangenen PS2 
frame erkannt wurde (parity, stop bit) oder FrameReceive noch gesetzt 
ist(overflow) ansonsten gelöscht)
- FrameData (8 bits)

und 1 input:
- FrameAck (1 bit)

auf diese soll das toplevel entity zugreifen.

Also mein Versuch einfach die Signale jeweils über 2 flipflops zu 
schicken (FrameAck 2 ffs getaktet mit 60 MHz, FrameReceived 2 ffs 
getaktet mit 50 MHz usw.)
hat an der Situation nichts geändert, was mich auch nicht wirklich 
überrascht hat.

Mein nächster und auch letzter Versuch, von dem ich mir eigentlich mehr 
erhofft hatte, war zusätzlich die output Signale zu "verlängern" also 
deren Zustand über n Takte zu halten.

Wahrscheinlich habe ich das total falsch gemacht (Prozess mit nem 
counter und alle x (habe Werte von 4 bis 100 probiert) 60 MHz Takte 
werden die outputs vom ps2Decoder übernommen)
denn das hat absolut nichts geändert, egal wieviele Takte "gehalten" 
wurde.

Hatte versucht mehr oder weniger das umzusetzen was in Cummings "Clock 
Domain Crossing (CDC) Design & Verification Techniques Using 
SystemVerilog" Dokument steht aber anscheinend nicht verstanden.

Hat evtl. jemand nen link zu einem einfachen funktionierenden Beispiel 
design (wenn möglich bitte VHDL) wo sowas gemacht wird?

Oder eine einfache Erklärung was hier die richtige Vorgehensweise ist?

MfG
Christian G.

P.S. evtuelle Fragen kann ich leider erst nach dem WE beantworten

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Takte verschieben wird man i.d.R nur, um Eingangssignale zu sampeln, die 
um die Clock-Flanke herum wechseln.

Zwischen zwei internen Domänen kann man dann vereinfacht arbeiten, wenn 
die Takte tatsächlich ganzzahlig zueinander sind, oder in Sonderfällen, 
wenn für alle Flankenkonstellationen ausreichende Reserven bestehen. 
Dann kann man mit der Periode des schnelleren Takte ein Multi-Cycle 
aufsetzen und das Timing so entspannen.

Im Normalfall muss man sampeln und synchronisieren, d.h. man muss mit 
einen ausreichen schnellen Takt abtasten, auf Stabilität prüfen oder 
(Normalfall) diese annehmen (z.B. mit einem strobe) und dabei gfs. 
Nyqist beachten. Dies kann man bei Taktkonstellationen von besser als 
1:2 in gewohnter Weise. Bei kleiner als 1:2, z.B. bei 2:3 geht es durch 
parallele Strukturen mit jeweils einem Multicycle auf den langsameren 
Takt, um die Eingangsfrequenz zu "halbieren" und sicherzustellen, dass 
der Zieltakt beide Flanken sieht.

Idealfall:

Wenn in der Zieldomain etwas Dynamik an Verarbeitung zugelassen werden 
kann, was ausreichende Bandbreite erfordert, sind asynchrone FIFOs die 
beste Wahl. Im Einzelfall ist das ein Triple-Buffer oder bei günstigen 
Konstellationen ein Wechselbuffer, der wiederum zu ähnlich funktioniert, 
wie die Vorgehensweise "parallele Struktur + MultiCon".

von DSGV-Violator (Gast)


Lesenswert?

Die Probleme an taktdomainübergängen löst man nicht mit 
timing-constraints sondern per Schaltungstechnik: DualPort-RAM, FIFO, 
kette aus synchronidierungs-FF.
Aus dem TO-posting geht jetzt nicht hervor, woran der TO "Das Scheitern" 
seiner Lösungsansätze erkannt haben will. Simulation? Oder kotzt dem die 
Toolchain irgendwas Unappetitliches vor die Füße?

Der Code ist im Falle von Synchronisierungs-FF so simple das es sich 
nicht lohnt diesen als Beispiel hier anzugeben. Pulsverlängerung über 
mehrere Takte kann da schon trickreicher sein.

Seite 16 des PDF;s zeigt blockbilder verschiedene synchronizer. Einfach 
das mit den einschlägigen VHDL-Mittel zur FF-Beschreibung umsetzen.

http://ebook.pldworld.com/_eBook/FPGA%EF%BC%8FHDL/-Examples-/clock%20synchronization.pdf

von Gustl B. (gustl_b)


Lesenswert?

DSGV-Violator schrieb:
> kette aus synchronidierungs-FF.

Und trotzdem braucht es zusätzlich noch ein Constraint damit die 
Toolchain auch weiß was man da macht und dann auch keine 
Timingverletzung meldet.

Also false path zwischen den Signalen oder Clocks.

: Bearbeitet durch User
von DSGV-Violator (Gast)


Lesenswert?

> Und trotzdem braucht es zusätzlich noch ein Constraint damit die
> Toolchain auch weiß was man da macht und dann auch keine
> Timingverletzung meldet.

Ich geh davon aus, das es kein constraint gibt wenn kein constraint 
explizit definiert wurde und sich daher das einzusynchronisierende 
Signal in den der Klasse der unconstrained pathes findet und somit nicht 
in die STA eingeht.

Aus den normalerweise definierten period constraint für eine einzelne 
clock domain (Baseline constraints), bastelt IMHO die STA nicht 
automatisch eins für domainwechselnde signale. Also erwarte ich nicht, 
das da irgendwas zu false path umdeklariert werden muß.

Aber natürlich schadet es sicher nicht, sich mal alle Pfade anzeigen zu 
lassen, die die STA für domain crosser hält: 
https://docs.xilinx.com/r/en-US/ug949-vivado-design-methodology/Constraining-Clock-Domain-Crossings

Und wenn man mal an Taktübergangen ein constraint setzt, dann kann das 
auch bewusst ein kleines sein: Da die FF eher kurz im metastabilen 
Zustand verweilen, verringert eine kurze Signallaufstrecke die 
Wahrscheinlichtkeit, das der Metastabile Zustand in das nachgeschaltetet 
FF propagiert.

Interessanterweise ist das bei altera/intel anders formuliert ("is 
essential*")
https://www.intel.com/content/www/us/en/support/programmable/articles/000080400.html

Wobei es doch scheint, das intel hier von taktdomainen spricht, die 
tatsächlich einen fixen bezug zueinander haben (phasenstarr).

Die Einsynchronisation zwischen complett unäbhängigen Taktdomainen zählt 
da wohl eher nicht darunter.

Früher (ISE) hiess es, es nicht mit der Anzahl der definierten 
constraints, auch der  false path constraints "nicht zu übertreiben". 
weil das die STA signifikant verlangsamt. Nur constrainen was nötig, und 
asnychrone Pfade zähl(t?)en nicht darunter.

von Gustl B. (gustl_b)


Lesenswert?

DSGV-Violator schrieb:
> und sich daher das einzusynchronisierende Signal in den der Klasse der
> unconstrained pathes findet und somit nicht in die STA eingeht.

Wenn das Signal von Extern kommt ja, aber wenn da Clock Constraint

DSGV-Violator schrieb:
> Aus den normalerweise definierten period constraint für eine einzelne
> clock domain

gesetzt ist, dann glaubt die STA dass alle Signale die mit einer dieser 
Clocks getaktet sind zu dieser Clockdomain gehören. Will man also von 
einem getakteten Signale einer Clock zu einem getakteten Signal einer 
anderen Clock, so muss man einen False Path oder die Clocks/Signale 
asynchron setzen.

von Markus F. (mfro)


Lesenswert?

DSGV-Violator schrieb:
> Interessanterweise ist das bei altera/intel anders formuliert ("is
> essential*")
> 
https://www.intel.com/content/www/us/en/support/programmable/articles/000080400.html

Das ist für die "Timing Driven Synthesis" u.U. wichtig. Ein einfaches 
set_false_path sagt der nur "interessiert mich nicht". Wenn's dann ums 
Optimieren geht, fasst der Fitter den CDC-Timingpfad gar nicht an und 
legt ihn im dümmsten Fall einmal quer durchs ganze Design.

Die im Link genannte Vorgehensweise "isoliert" die Clock-Domänen über 
Clock Groups und definiert einen Max-Delay über die CDC-Logik. Damit 
"sieht" der Fitter, dass uns der Pfad eben doch interessiert.

Ich denke, das wird bei Vivado (das auch Timing-Driven Synthese 
beherrscht?) auch nicht anders gehandhabt werden.

von DSGV-Violator (Gast)


Lesenswert?

Markus F. schrieb:

> Die im Link genannte Vorgehensweise "isoliert" die Clock-Domänen über
> Clock Groups und definiert einen max_delay über die CDC-Logik. Damit
> "sieht" der Fitter, dass uns der Pfad eben doch interessiert.

Das klingt für mich nach einem Widerspruch zur Aussage von Gustl:

> Und trotzdem braucht es zusätzlich noch ein Constraint damit die
> Toolchain auch weiß was man da macht und dann auch keine
> Timingverletzung meldet.
> Also false path zwischen den Signalen oder Clocks.

Also bei Signalen zwischen (internen,nicht phasen starren) clockdomains 
haben wir jetzt drei Möglichkeiten:

 * [NO_CON]     kein explizites constraint
 * [FALSE_PATH] set_false_path constraint ?
 * [MAX_DEL]    set_max_delay constraint ?

Und es wurde angedeutet das man für STA und timing_driven_synthesis dies 
Unterschiedlich handhaben könnte.
Vielleich kann man es so reglementieren, das bei der STA als 
Verificationsschritt der requiremets alle constraints gesetzt werden 
müßen, während man bei der (zeitinsensiven) timing-driven synthesis sich 
auf die für die Synthese erforderlichen beschränkt und diese ergänzt, 
falls die STA Verletzungen meldet die sich nicht durch HDL-Code 
Optimierungen beheben lassen?

Daher tendiere ich persönlich zu Variante [NO_CON] und falls die STA 
meckert auf [MAX_DEL]. Das der Pfad exterm lang wird (> 10 ns) , ist mir 
bei Xilinx mit ihren vielen fein granularen routing ressourcen noch 
nicht passiert, da seh ich die Gefahr eher bei altera mit den Long und 
short lines zum routing.

von Markus F. (mfro)


Lesenswert?

DSGV-Violator schrieb:
> drei Möglichkeiten:
>
>  * [NO_CON]     kein explizites constraint
>  * [FALSE_PATH] set_false_path constraint ?
>  * [MAX_DEL]    set_max_delay constraint ?

NO_CON ist bei Intel keine Option (es sei denn, man stört sich nicht an 
knallroten Timing Reports). Die Quartus STA betrachtet immer alle 
Pfade, die nicht explizit (entweder über clock groups oder 
set_false_path) isoliert/ausgeschlossen werden.
Deswegen ist die richtige Option, schlicht das zu machen, was in dem 
von dir verlinkten Artikel steht.

von Gustl B. (-gb-)


Lesenswert?

Markus F. schrieb:
> Deswegen ist die richtige Option, schlicht das zu machen, was in dem
> von dir verlinkten Artikel steht.

Ich finde auch false_path OK. Wenn einem egal ist ob das Signal 
vielleicht erst mehrere Takte später da ist, dann ist das ein schneller 
Weg um Timingfehlermeldungen zu vermeiden.
Mache ich gerne und das funktioniert gut wenn man seinen Code kennt.

Wichtig ist auch die Realität korrekt mit Constraints anzugeben. Takte 
die nicht phasenstarr sind sollte man auch so über asynchrone Clocks 
definieren.

von Markus F. (mfro)


Lesenswert?

Christian schrieb:
> Der PS2decoder hat 3 outputs:
> - FrameReceived (1 bit) (wird gesetzt wenn ein PS2 frame empfangen wurde
> und gelöscht wenn FrameAck gesetzt ist)
> - FrameError (1 bit) (wird gesetzt wenn ein Fehler im empfangenen PS2
> frame erkannt wurde (parity, stop bit) oder FrameReceive noch gesetzt
> ist(overflow) ansonsten gelöscht)
> - FrameData (8 bits)

Wenn Du hier nur - so habe ich dich jedenfalls verstanden - die Received 
und Error Bits synchronisierst, müssen die Daten (FrameData) längst 
nicht mehr aktuell sein, wenn die synchronisierten Bits auf der anderen 
Seite des CDC ankommen.

Der sicherste Weg dürfte hier sein, bei FrameReceived alle Signale 
aneinander zu kleben, durch einen dual clock FIFO zu schicken und auf 
der anderen Seite wieder auseinander zu nehmen.

: Bearbeitet durch User
von DSGV-Violator (Gast)


Angehängte Dateien:

Lesenswert?

Christian schrieb:
> Der PS2decoder hat 3 outputs:

Blockbild über die beiden(?) domains PS2 und USB sollte stark den 
Überblick erleichtern. PS2-Tastatur ist eigentlich schnarch langsam da 
Zappelt doe signale im zweistelligen µs Bereich (siehe Anhang aus: 
https://www.networktechinc.com/ps2-prots.html)

> die Verschiebung muss wohl beim deca board so sein sonst gibt
> es Probleme mit dem TUSB1210.

wo sitzt dieser Chip konkret? Sowie es ausschaut, musst du lediglich ein 
funktionierendes ULPI-IF verwenden.

https://www.ti.com/lit/ds/symlink/tusb1210.pdf?ts=1682244132263&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252Fde-de%252FTUSB1210

der ULPI-chip scheint den clock zu seinen signalen mitzuliefern also 
scheint es nicht weiter kompliziert zu sein:

https://ww1.microchip.com/downloads/en/AppNotes/en562704.pdf

von Gustl B. (gustl_b)


Lesenswert?

DSGV-Violator schrieb:
> PS2-Tastatur ist eigentlich schnarch langsam

Und weil das so ist, braucht man keine zweite Taktdomäne sondern kann 
alles mit einem schnellen Takt machen. Mit dem tastet man die sehr viel 
langsameren Eingänge ab. Man kann sie entprellen, Flankenerkennung 
machen, ...

von Christian (grobig80)


Lesenswert?

Hallo,

vielen lieben Dank für die ganze Hinweise und links, alles absolut 
wertvoll für mich!

Ja, ein wenig peinlich, das "Problem" ließ sich innerhalb 1 min. lösen.

Also ihr habt natürlich absolut Recht, die PS2 Signale sind total 
langsam im Vergleich zum Rest des designs. Deshalb hatte ich auch schon 
synchronisation und Flankenerkennung etc. in den PS2decoder eingebaut.

Was am Ende gefehlt hat waren wirklich nur zwei Zeilen die einen false 
path setzen zwischen den PS2 signalen von der ulpi Komponente zum 
PS2decoder und halt den PS2decoder mit der main 50MHz clock laufen 
lassen.

... einen schönen Sonntag noch!

von -gb- (Gast)


Lesenswert?

DSGV-Violator schrieb:
> sich daher das einzusynchronisierende
> Signal in den der Klasse der unconstrained pathes findet und somit nicht
> in die STA eingeht.

Das stimmt aber so nicht. Das tool wird vielmehr versuchen, das timing 
zu treffen, was ihm gfs nicht möglich ist. Unconstrained ist der Path 
nicht.

DSGV-Violator schrieb:
> Da die FF eher kurz im metastabilen
> Zustand verweilen, verringert eine kurze Signallaufstrecke die
> Wahrscheinlichtkeit,
Warum sollte das so sein? Wenn das FF verspätet kippt, ist ein 
entfernter plaziertes FFs dagegen resistenter, weil in dem Fall eines 
glitches, das Zucken nur in der Nähe zu einer ausreichenden Amplitude 
führt, weiter weg aber einen geringen Hub hat und damit weniger 
wahrscheinlich als falsch erkannt wird.

Gustl B. schrieb:
> Also false path zwischen den Signalen oder Clocks.
False path darf man laut unseren design Vorgaben gar nicht verwenden. Es 
muss ein verlängertes Timing Constraint aufgesetzt werden und zwar nur 
auf dieses Signal und nicht auf den gesamten Takt.

Markus F. schrieb:
> Die im Link genannte Vorgehensweise "isoliert" die Clock-Domänen über
> Clock Groups und definiert einen Max-Delay über die CDC-Logik. Damit
> "sieht" der Fitter, dass uns der Pfad eben doch interessiert.
Ja und nein. Der Placer "sieht" dass er entspannter arbeiten darf und 
die Timing Analyse hat eine weniger enge Vorgabe, welche dann bei 
Prüfung durchgeht. Interessieren tut uns das Signal in beiden Fällen: 
Ist nichts angegeben, welchen die weitergetretenen Vorgaben von dem 
jeweiligen Takt in Verbindung mit der jeweils annehmenden Taktflanke.

von Gustl B. (gustl_b)


Lesenswert?

Georg B. schrieb:
> False path darf man laut unseren design Vorgaben gar nicht verwenden.

Zum Glück arbeite ich wo anders. Ich finde es nicht gut wenn Dinge 
pauschal verboten werden. Gerade im Beispiel oben mit einer sehr 
langsamen Clock und einer schnellen Clock machen doch

Georg B. schrieb:
> ein verlängertes Timing Constraint

nicht wirklich Sinn. Eigentlich macht auch der langsame Takt keinen Sinn 
sondern man nimmt den schnellen Takt und erzeugt sich enable Signale.
Ich finde false_path macht auch zwischen Clocks Sinn wenn man weiß was 
man macht.

Wenn man da überall schön dual Clock FIFOs drinnen hat oder eintaktet 
oder das mit Handshake übergibt, dann reicht es mir das mit false path 
zu constrainen.

von DSGV-Violator (Gast)


Lesenswert?

> DSGV-Violator schrieb:
>> Da die FF eher kurz im metastabilen
>> Zustand verweilen, verringert eine kurze Signallaufstrecke die
>> Wahrscheinlichtkeit,
> Warum sollte das so sein? Wenn das FF verspätet kippt, ist ein
> entfernter plaziertes FFs dagegen resistenter, weil in dem Fall eines
> glitches, das Zucken nur in der Nähe zu einer ausreichenden Amplitude
> führt, weiter weg aber einen geringen Hub hat und damit weniger
> wahrscheinlich als falsch erkannt wird.
Nope, da hat man Zusammenhang zwischen propagation delay: t_prop und 
recovery time: t_rec nicht verstanden.

Wenn beim ersten FF eine timing Verletzung auftritt, erscheint für die 
dauer von t_rec ein metastabiler Zustand am Q-Ausgang, der t_prop später 
am D-Eingang des/der folgenden FF auftritt.
Nimmt man beispielhaft an, die Takt-periode sei 10 ns, t_rec sei 5 ns 
und für den t_prop zwischen FF1 und FF2 rechnet man zwei Varianten 
durch:
 * t_prop_near (nah platziertes FF)  = 4ns und
 * t_prop_far  (fern platziertes FF) = 9ns.

Daraus ergibt sich folgender zeitlicher Verlauf:
 * FF1 fällt von t=0 bis t=t_rec = 5ns in einen metastabilen Zustand,
 * FF2_near 'sieht' diesen metastabilen Zustand T_prop_near später, also 
von t= 4 bis 9 ns
 * FF2_far 'sieht' diesen metastabilen Zustand T_prop_far später, also 
von t = 9 bis 14 ns.

Da aller 10 ns der Takt kommt, wird das fern platzierte FF getaktet, 
wenn an dessem Eingang der metastabile Zustand anliegt; der metastabile 
Zustand propagiert also tiefer in das Design. Dagegen das nah platzierte 
FF wird getaktet, zu einem zeitpunkt zu dem der metastabile Zustand an 
seinem Eingang schon wieder abgeklungen ist.

++++
>> sich daher das einzusynchronisierende
>> Signal in den der Klasse der unconstrained pathes findet und somit nicht
>> in die STA eingeht.

> Das stimmt aber so nicht. Das tool wird vielmehr versuchen, das timing
> zu treffen, was ihm gfs nicht möglich ist. Unconstrained ist der Path
> nicht.

Nicht jedes tool ist gleich und wo kein constraint gesetzt ist, gibt es 
auch kein timing das einzuhalten ist. Das sieht man insbesonders an den 
tools die kein SDC-Format für timing spezifikation kennen, wie die ISE. 
Das period-constraint der ISE trifft nur FF in der selben Taktdomain:

"If the clocks are not related, the cross clock domain paths are not 
analyzed."
Xilinx UG612 V13.2 p.120
https://redirect.cs.umbc.edu/~tinoosh/cmpe691/tutorials/timing-constraint-guide.pdf

Will man den Pfad durch das tool analysiert haben, muß man explizit ein 
FROM TO constraint setzen.

von -gb- (Gast)


Lesenswert?

Gustl B. schrieb:
> false_path macht auch zwischen Clocks Sinn wenn man weiß was
> man macht.

dann nimmst du dir aber die Möglichkeit, dass das Werkzeug das Timing 
prüft.

von Markus W. (mwww)


Lesenswert?

Zur Ergänzung:

Bei Vivado gibt es das constraint ASYNC_REG, um Vivado anzuweisen, 
solche Einsynchroniserungs-FlipFlops möglichst nah beeinander zu halten. 
Das plus false_path verwende ich bei meinen CDC-FFs.

https://docs.xilinx.com/r/en-US/ug912-vivado-properties/ASYNC_REG

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> Ich finde auch false_path OK. Wenn einem egal ist ob das Signal
> vielleicht erst mehrere Takte später da ist, dann ist das ein schneller
> Weg um Timingfehlermeldungen zu vermeiden.

Das ist aber kein sauberer Weg. Dafür haben wir ja das 
MultiCycleContraint. Man sollte das schon so "einpferchen" wie es real 
benötigt wird.

DSGV-Violator schrieb:
> Die Probleme an taktdomainübergängen löst man nicht mit
> timing-constraints

Indirekt schon, wenn man dort, wo man entspannen kann, auch entspannt, 
weil durch die timing-gesteuerte Platzierung sich auch das routing 
ändert, womit sich dann das reale timing der Schaltung ändert und somit 
die timing-checks an anderen Stellen wieder gut ausgehen können.

von Gustl B. (-gb-)


Lesenswert?

J. S. schrieb:
> weil durch die timing-gesteuerte Platzierung sich auch das routing
> ändert

Das liest man oft, aber kann man das irgendwie mal mit Zahlen oder 
Berichten untermauern? Klar, ich glaube schon dass das stimmt, habe ich 
auch selber schon gesehen. Aber wie weit geht diese Optimierung? Werden 
da wirklich "Umwege" geroutet damit ein Signal gegenüber eines anderen 
Signals verzögert wird? Werden automatisch Idelays eingebaut (habe ich 
noch nicht gesehen aber vielleicht auch nicht die passenden Constraints 
verwendet)?

J. S. schrieb:
> Gustl B. schrieb:
>> Ich finde auch false_path OK. Wenn einem egal ist ob das Signal
>> vielleicht erst mehrere Takte später da ist, dann ist das ein schneller
>> Weg um Timingfehlermeldungen zu vermeiden.
>
> Das ist aber kein sauberer Weg. Dafür haben wir ja das
> MultiCycleContraint.

Ja und nein. So wie ich das verstehe sagt man mit dem MultiCycle 
Contraint eben, nach wie vielen Takten man das Signal stabil (!) haben 
will. Aber was soll ich da hinschreiben wenn mir das egal ist und ich 
das in der anderen Taktdomäne selber eintakte in mehrere FFs?
false_path ist aus meiner Sicht die Anweisung "bemühe dich gar nicht", 
also genau das was ich an dem Punkt will.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> J. S. schrieb:
>> weil durch die timing-gesteuerte Platzierung sich auch das routing
>> ändert
>
> Das liest man oft, aber kann man das irgendwie mal mit Zahlen oder
> Berichten untermauern?

Das lässt sich ja leicht ausprobieren, wenn man die post routing Analyse 
bemüht. Außerdem merkt man es ja daran, dass sich das timing der 
Problempfade verbessert (es sei denn, er verrennt sich, was ja auch 
passieren kann).

Gustl B. schrieb:
> Werden da wirklich "Umwege" geroutet damit ein Signal gegenüber eines
> anderen Signals verzögert wird?
Das wohl nicht, jedenfalls nicht ausdrücklich. Wozu auch? Der Werdegang 
ist der, dass das entspannte Signal weiter hinten in die Liste wandert 
und später angefasst wird. Damit werden die zeitkritischen Signale 
früher behandelt, haben bessere Optionen und indirekt wird das 
entspannte Signal "umständlicher" geroutet.

So richtig zutage tritt das bei gut gefüllten FPGAs, bzw SLRs.

Gustl B. schrieb:
> Aber was soll ich da hinschreiben wenn mir das egal ist
Das kann einem streng genommen nicht egal sein, weil es aus 
funktioneller Sicht immer eine Anforderung für die maximale Zeit gibt, 
die vergehen darf, bevor ein Design auf eine Signaländerung reagiert - 
auch wenn es Millisekunden sind und damit Tausende Zyklen. In solchen 
Fällen ist ja auch immer ein funktioneller oder formeller Nachweis zu 
führen, dass das klappt. Dabei muss u.U. die Latenz des designs 
berücksichtigt werden. Das ist regelmäßig bei Schaltungen der Fall, die 
irgendwelche Alert-Signale von Chips verarbeiten sollen, aber noch 
Filter und Signaldekodierung im Pfad haben.

In dem Fall, wo das nicht definiert ist, kann man natürlich tatsächlich 
ein Ignore auf den Pfad setzen.

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.