Virkningen af ​​Ur Uncertainity

V

verilog_always

Guest
Hvordan forskellige værdier af Clock Uncertainity virkninger, Placement scenen? Gør forskellige værdier af Clock Uncertainity effekt eventuelle cents / routing resultater?
 
værktøjet arbejder meget hårdt, hvis ur usikkerhed er stor, fordi det gør timingen sværere at opfylde.
 
Usikkerhed henvises til Tidsforskydelse før ur træ er bygget. set_clock_uncertainty er SDC kommandoen til at erklære målet skævt for et design. Dette er den begrænsning givet til PNR værktøjet for at opbygge ur træ. Værktøjet forsøger at ære denne begrænsning ved at forsøge at holde skævhed inden den nævnte grænse. Også STA værktøjer vil bruge denne i stedet for skævhed før CTS. Det vil trække denne værdi for opsætning analyse fra ur vej og tilføje det op for hold analyse. Derfor før CTS, en større værdi, da dette er som en hindring, hvilket gør dette vil helt sikkert påvirke QoR. Når uret netværk er bygget, eller med andre ord, er sat til true set_clock_propagated, er Skew beregnes ud fra netværket og vil blive brugt og dermed det giver ingen mening for en STA værktøj, når indgangen design har udvidet ur. Mens routing eller post CTS optimering, værktøjet stadig tager ind i billedet målet skævt (for f.eks. Scenariet af nyttig skævhed). Derfor ændrer / tweaking vil helt sikkert påvirke resultaterne.
 
Hej, 1 - kan man også bruge usikkerhed som en yderligere margin efter CTS, fx at tage højde for PLL jitter at man ikke har kontrol over det på det fysiske design trin. 2 - Som srideepa sagt ur usikkerhed før CTS kan bruges til at fastsætte setup / hold timing overtrædelser, som påvirker QoR. Da de fleste PR-værktøjer fastsætte timing overtrædelser under / over visse tærskler, kan de ikke røre nogle overtrædelser, som i sidste ende kan pop-up efter CTS. Ændring ur usikkerhed kan være en god måde at fastsætte disse krænkelser "før" CTS, i bekostning af at tilføje nogle flere buffere i designet. Best regards, Gokhan ---
 
Usikkerheden kan anvendes til at modellere forskellige faktorer, som kan reducere den effektive klokperiode. Disse faktorer kan være uret jitter og enhver anden pessimisme, som man måtte ønske at inkludere for timing analyse. set_clock_uncertainty-setup 0,2 [get_clocks CLK_CONFIG] set_clock_uncertainty-hold 0,05 [get_clocks CLK_CONFIG] Bemærk, at uret usikkerhed for opsætning reducerer effektivt de tilgængelige døgnet periode med den angivne mængde (se Fig1 i vedhæftede fil) For hold checks, er uret usikkerhed for hold brugte som et yderligere timing margin, som skal være opfyldt. Hvis der er multi-ur domæne stier (Fig2. i vedhæftet fil), kan derefter blandt ur usikkerhed angives som vist i nedenstående kommandoer. # 100PS bruges som en usikkerhed for opsætning kontrol # 50ps bruges som en usikkerhed for hold kontrol. set_clock_uncertainty-fra VIRTUAL_SYS_CLK til SYS_CLK-hold 0,05 set_clock_uncertainty-fra VIRTUAL_SYS_CLK til SYS_CLK-setup 0,3 set_clock_uncertainty-fra SYS_CLK til CFG_CLK-hold 0,05 set_clock_uncertainty-fra SYS_CLK til CFG_CLK-setup 0,1
 
Hvorfor værdier for opsætning og Hold er anderledes?
 
Selv jeg ønsker at stille det samme spørgsmål. Hvorfor er det, at i de fleste tilfælde ser vi setup ur usikkerhed blive sat mere end hold usikkerhed. Bør ikke de værdier være det samme?
 
generelt holder, vil ikke blive kontrolleret næppe som setup i det mindste før CTS, da uret ikke er reel, og i nogle implementeringer, bekymrede vi abt holder først efter routing, som de virkelige værdier er tilgængelig på dette tidspunkt kun.
 
Hej alle, Efter CTS også, mens kontrollere timing analyse vil vi give forskellige værdier for opsætning og hold usikkerhed. Generelt mere for opsætning og mindre for hold. Hvorfor? Hvad er årsagen til dette? tak og reagrds og Subhash
 
Hej alle, Efter CTS også, mens kontrollere timing analyse vil vi give forskellige værdier for opsætning og hold usikkerhed. Generelt mere for opsætning og mindre for hold. Hvorfor? Hvad er årsagen til dette? tak og reagrds og Subhash
The Hold kontrol kræver ikke uret jitter, der skal indgå i den uvished og dermed en mindre værdi af ur usikkerhed er generelt angivet for hold. HTH, Shitansh Vaghela
 
The Hold kontrol kræver ikke uret jitter, der skal indgå i den uvished og dermed en mindre værdi af ur usikkerhed er generelt angivet for hold. HTH, Shitansh Vaghela
Hvorfor holde kontrol kræver ikke uret jitter der skal indgå i den usikkerhed? Pls svare mig snart
 
Hold usikkerhed er mindre, også fordi du bruger den hurtige hjørnet for timing, så forsinkelserne er kortere.
 
bcoz vi tjekker holde samme kant .. opsætning ly vi tjekker næste edge.i tror så u ved jitter bølgeform ..
 

Welcome to EDABoard.com

Sponsor

Back
Top