Post-izkārtojums un pēc sintēzes STA jautājumiem.

[eng.obd_md]

Sveiki, Mans dizains strādā perfekti labi pēc post-sintēzi (izmantojot DC) pie pulksteņa likme ir 5 ns. Vietā un maršruts (izmantojot sastopas), es saņēmu 50 iestatīšanu pārkāpj ceļu. Es centos, lai modelētu netlist un tā strādāja, bet ar pulksteni 40 ns (varētu būt nevis stūrī, bet tas nestrādāja ar 5 ns vai pat 20 ns). Mans jautājums: vai ir iespējams veikt optimizāciju šeit un cik efektīvi tas var būt, man būtu iespēja simulēt pie 5 ns. Tāpat, kā var šāda optimizācija jāveic?

 

[yx.yang]

Sveiki, Mans dizains strādā perfekti labi pēc post-sintēzi (izmantojot DC) pie pulksteņa likme ir 5 ns. Vietā un maršruts (izmantojot sastopas), es saņēmu 50 iestatīšanu pārkāpj ceļu. Es centos, lai modelētu netlist un tā strādāja, bet ar pulksteni 40 ns (varētu būt nevis stūrī, bet tas nestrādāja ar 5 ns vai pat 20 ns). Mans jautājums: vai ir iespējams veikt optimizāciju šeit un cik efektīvi tas var būt, man būtu iespēja simulēt pie 5 ns. Tāpat, kā var šāda optimizācija jāveic?

Par "Es saņēmu 50 iestatīšanu pārkāpj ceļu.", 50 līdzekļi 50ns vai 50ps? Ja tas ir 50ns, jūs varat iet sim pie CLK periodā ir 40ns ir, jo: 1): Tu simulācijas modelis neaptver visus gadījumus. 2): Daži ceļš ar lielu pārkāpumu amybe viltus ceļā vai vairāku veloceliņa. 3): Daži raksts nekad nevar notikt ar savu dizainu, savukārt DC / PT nekad zināt, ka. Ja tas ir 50ps, jums ir ne tikai setup laika problēmu, bet arī turēt laika problēmu, pārrobežu pulksteni domēna problēma, ... .

 

[eng.obd_md]

Paldies par atbildi, patiesībā 50 ir ceļu skaits pārkāpt kāda uzstādīšanas laiks. Bet es esmu joprojām mulsina tāpēc, ja tie ir viltus ceļus kā nāk simulācijas nedarbojas ar 5 ns pulksteni.

 

[venky4u]

tas ir savvaļas minējums .. Es neesmu pārliecināts par to. šķiet, ka tas jūs izmantojat dizaina funkcionālā režīmā ar DC netlist, un, ja jūs darbojas skenēšanas režīmā SKT, biežums izmantot skenēšanas režīmā darbībām ir atšķirīgs no funkcionālajiem veidiem un parasti tas ir mazāks. tāpēc šis varētu būt izraisa problēmu.

 

[ebuddy]

Sveiki, Mans dizains strādā perfekti labi pēc post-sintēzi (izmantojot DC) pie pulksteņa likme ir 5 ns. Vietā un maršruts (izmantojot sastopas), es saņēmu 50 iestatīšanu pārkāpj ceļu. Es centos, lai modelētu netlist un tā strādāja, bet ar pulksteni 40 ns (varētu būt nevis stūrī, bet tas nestrādāja ar 5 ns vai pat 20 ns). Mans jautājums: vai ir iespējams veikt optimizāciju šeit un cik efektīvi tas var būt, man būtu iespēja simulēt pie 5 ns. Tāpat, kā var šāda optimizācija jāveic?

jūsu sintēze rīks, do "ziņot laiku", un jo sastopas, do ziņojuma laiku atkal. Uzzinātu, kāpēc laiks ir pasliktinājies 10 reizes. Kāds ir jūsu standarta šūnu procesu? Varu derēt, nav jautājums par optimizāciju. Tur kaut kas nav kārtībā vai nu ar savu sintēzi vai jūsu izkārtojumu.

 

[srideepa]

Sveiki, PNR rīks pievienojot DataPath nokarāšanos aptuveni 35 ns (neizskatot pulksteni šķībs), izklausās ļoti šaubīgs. Optimizācija var veikt, izmantojot optDesign komandu vietu, pulksteni un maršruta posmos. Bet jums ir jāuzsver, ka laiks ir jūsu prioritāte. Zemāk ir daži no maniem jautājumiem: Vai jums, izmantojot pašus ierobežojumus gan rīkiem? Vai jums ir set_propagated_clock patieso jūsu postLayout SDC failu? Vai jūs sākot ar 65% - 70% izmantošanu? Vai jūs pārbaudīt savu iestatīšanas atslābums pēc pulksteņa stadijā, kā arī? Beidzot, jūs varat saņemt palīdzību, lai pārbaudītu savas PDR skriptus? Sveicieni, R.Srideepa