Ur domæne passage timing fejl

S

s3034585

Guest
Hi Guys
I mit design er der 2 clks indkaldt som fastclk og slwclk og de er genereret ved hjælp af DCM.Jeg bruger et signal, som er fra slwclk domæne til at udløse en tilstand maskine i hurtigt CLK.Men før du bruger det jeg synkronisere den ved hjælp af 2 FFS clocked ved hurtig CLK.Stadig jeg får nogle timing fejl og jeg en ude af stand til at forstå det.Kan nogen hjælpe mig med at forstå det ..

Thanks in advance
Tama

fejlen ---->

Slack:-1.899ns (krav - (data path - ur sti påvirke usikkerhed))
Kilde: gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn (FF)
Destination: gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r (FF)
Krav: 0.003ns
Data Path Delay: 1.902ns (Levels af Logic = 0)
Ur Path påvirke: 0.000ns
Kilde Ur: slow_clk stiger på 110135.805ns
Destination Clock: fast_clk stiger på 110135.808ns
Ur Usikkerhed: 0.000ns

Data Path: gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn til gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r
Beliggenhed Delay type Delay (NS) Fysisk Resource
Logisk Resource (r)
------------------------------------------------- -- ------------------
SLICE_X86Y145.YQ Tcko 0.568 gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/transation_done
gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn
SLICE_X86Y144.BY netto (fanout = 1) 0,964 gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn
SLICE_X86Y144.CLK Tdick 0.370 gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r
gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r
------------------------------------------------- -- --------------------------
Total 1.902ns (0.938ns logik, 0.964ns route)
(49,3% logik, 50.7% route)

-------------------------------------------------- ------------------------------

 
Det afhænger af, hvordan du gør synkroniseringen.Ideelt set bør du generere en puls med samme bredde som fastclk periode og bruge den til at udløse din maskine.
Også fra dit indlæg jeg ser det 50,7% af forsinkelser fra rejsen, og dette kan forbedres, hvis du spiller med MAP en PAR indstillinger.Øge routing indsats, brug timing drevet mapping ...

 
Brug mere FF i stedet for 2 til at synkronisere CLK som øger FFreduce sandsynligheden for Metastabilty.

Anmol

 
Hej,

Jeg tror, du får den slack (fejl), fordi kilden ur og destination ur er forskellige.når kilden ur og destination ur er forskellige langs en sti værktøjet formodes at give timing voilations for denne vej.siden du bruger 2 FFS til synkronisering, at skulle fungere fint, og du kan bare ignorere timing voilation.For sådanne tilfælde anbefales det at give TIG (Timing Ignorer) constraint mellem de to ur domæner.Hvis du giver TIG mellem din fastclk og slowclk, denne timing voilation ikke vil blive rapporteret i twr.

Tak.

 
Du er nødt til at definere falske vej for signal passerer fra det ene område til det andet.

 
i din ucf, brug
TIMESPEC "TS_XXX" = fra "slow_clk" TIL "fast_clk" TIG;

måske brugbare.

 
Når corrsing ur domæner, du vil altid få en timing fejl.Det er helt fint.fordi du vil have timing krænkelser i silicium såvel.Nu er der to måder at tackle det:
1.Bare ignorere det
2.Erklære en forkert sti (r) mellem to ur domæner.
Kr.,
Avi
http://www.vlsiip.com

 
En falsk sti er en timing sti, som aldrig er sensibiliseret i virkeligheden, men ikke eksisterer på chippen.Siden STA værktøj ikke kan finde den, og dens kun ingeniør, der kender sin en falsk sti, kan det være muligt, at STA rapporter en timing krænkelse, og faktisk en ingeniører ved, at denne krænkelse er ikke sandt.

Men i dette tilfælde den sti fra et ur domæne til en anden ikke er et "rigtigt falske vej", som det vil være sensibiliserede på chippen.Men da vi ved, at der ville være timing viols og vi har lagt foranstaltninger på plads, så vores silicium virker på trods af, at vi bruger den "falske vej" utility at erklære den en "falske vej", så STA ikke producerer timing fejl:
I design compileren kan du erklære en forkert sti som denne:
set_false_path-fra Clk1-til Clk2
andre eksempler kan ses på
http://www.vlsiip.com/dc_shell eller du kan se manden side af »set_false_path '
Flere spørgsmål?Lad mig vide, og jeg vil forsøge at afklare.
Kr.,
Aviral Mittal

 

Welcome to EDABoard.com

Sponsor

Back
Top