Har vi skal leve op til skæve grænse?

[designer_ec]

Hej, Hvis design have en god timing dvs design mødes setup og hold, men skævhed ikke er møde som pr skævt limit.Is det problem for design? eller vi har brug for at mødes skævhed contrain also.If ikke overholder skew grænse, hvad der vil være problemet.

 

[hfooo1]

Jeg tror thereis ingen problemer, men u kan analysere skævt Vios

 

[MarcS]

Der er ikke noget problem. Skråtstil er et middel til ophør, ikke et mål i sig selv. Hvis alt hvad du setup og hold tider er OK, så er alt fint. Når det er sagt, mange layout hold insistere på at opnå den specificerede skew målet, fordi de tror det gør banen mere robust over for variationer.

 

[ushisna]

Hvad jeg føler er sat op og holde gang parametre har en afhængighed af skæve værdi also.Skew ændringer vil påvirke oprette og holde time.Youe har sagt, at der ikke foreligger en overtrædelse af hold og oprette tiden krav, som indebærer, at skævhed værdi er ikke forårsage nogen problemer. Men en ubetydelighed skew skal tages hensyn til dette, jeg føler mig så:. |

 

[apallix]

Skråtstil er helt afgørende. Lad os sige du har en fat-margin på 50ps i et flop-flop stien og skew er> 50ps, så dit kredsløb vil helt sikkert ikke ved alle frekvenser. [Size = 2] [color = # 999999] Lagt efter 2 minutter: [/color] [/size] i mit ovenstående eksempel, jeg går ud fra, at holde marginen måles under forudsætning af et ideelt ur netværk, hvilket typisk er tilfældet.

 

[MarcS]

Apallix, bør du læse designer_ec oprindelige spørgsmål omhyggeligt. Han anfører, at kredsløbet timingen gerninger og alt setup og hold tider er opfyldt. Du er forvirrende lokale skævt med globale skævt, og du er også forvirrende en skæv grænse med egentlige skævt. Lad os sige, at tage dit eksempel, at du designe dit kredsløb med en hældning margin på 50ps. Det betyder ikke, at enhver flop-til-flop forsinkelsen er på den kritiske kanten af møde timing (slack = 0). Der er mange mange flop-til-flop forsinkelser, der har masser af positive slap, så de kan tåle en masse lokale (tilstødende flop) skæve og stadig arbejde. Det er typisk kun den kritiske vej, som har nul slap, og der du ønsker skew fra én flip-flop til den næste at være mindre end 50ps, men den globale skævhed kan være meget større. Den globale skew måler forskellen mellem de tidligste og de seneste ankomsttider til enhver floppet i uret - også selvom der er aldrig et signal, der går mellem dem! Så du kan nemt overtræder din globale skæve grænsen og stadig have et kredsløb, der fungerer udmærket. Tænk over det.

 

[apallix]

Hej presserester, jeg er enig med dig reg lokale skæve og globale skævt. Men ét spørgsmål er, betyder STA omfatter ur skævt, når den måler hold og opsætning marginer? Min erfaring som en brugerdefineret kredsløb designer er, at STA antager, at alle ure er ideelle med ingen skævt, når den måler setup og holde marginerne og skæve (lokal eller global) er beregnet ved en separat flow og forventes at opfylde sine grænser.

 

[jarodz]

Hej apallix, STA Værktøjet vil analyse ur forsinkelse (den sande uret træer), når du bruger "set_propagated_clock" (primetime) på post_CTS tidspunkt. Med venlig hilsen, Jarod

 

[MarcS]

Hej apallix: STA kan køre, før uret netværk er blevet oprettet (= ideelle ur) eller efter ur-netværket er blevet indsat (= opformeret ur). I ideal-tilstand, er du ret i, at uret er antaget at ankomme overalt med nul skævt, men SDC begrænsninger gøre at bygge i en margen for ur skew kaldes ur usikkerhed. Så den tid til rådighed for et signal at gå fra at lancere FF til fange FF er = Clk_period - setup tid - clk_uncertainty. I opformeret tilstand, dog kan alle uret ankomsttider på alle FF beregnes præcist, og der er ingen forudsætninger om skævt. Timingen ligning (for opsætning) bliver: Clk_period> = Datapath_delay + Setup + Capture_clock_insertion_delay - Launch_clock_insertion_delay Bemærk hvordan der er ingen estimater eller grænser her - hver eneste forsinkelse kan være præcis beregnes. Hvis ligningen (og lignende en for hold) er tilfreds så timingen fungerer, uanset hvad skew er.