Physical Aware SoC Assembly

Nekoč smo bili zadovoljni z idejo, da sta lahko svet logične zasnove in fizične izvedbe v veliki meri ločena. Čez zid vrzite logično zasnovo, ekipe za sintezo in P&R pa bodo poskrbele za ostalo. Ta zamisel je nekoliko zadela, ko smo ugotovili, da se mora sinteza fizično zavedati. Prodajalci orodij za sintezo so se okrepili in lahko zdaj optimizirajo glede na omejitve tlorisa. Problem rešen? Ne čisto. Zdaj potrebujemo fizično ozaveščeno sestavo SoC, saj fizične omejitve posegajo v zasnovo SoC.

Omejitve upravljanja porabe energije

Splošno znan razlog za ta premik so otoki moči in napetosti. Te morajo poganjati ustrezna napajalna vodila, ki se povezujejo z napetostnimi regulatorji ali zunanjimi viri energije. To je zelo fizična omejitev. Pa kaj? Vi se odločite, kateri bloki morajo iti v katere domene, in te informacije posredujete skupini za implementacijo. Poskrbeli bodo za tloris in pogon avtobusov. Ampak tukaj je problem. Sodobni SoC morda potrebujejo na stotine teh področij, ki se razvijajo in spreminjajo z razvojem dizajna in z izboljšanjem optimizacije porabe energije.

Napajalna vodila morajo biti konsolidirana med domenami s skupnimi zahtevami po energiji, da se zmanjšajo površine in zastoji, ki jih prinašajo ta vodila in regulatorji. To tudi pomeni, da morajo biti funkcije, združene v skupna vodila, blizu skupaj v tlorisu. Kar se razteza skozi zbiranje funkcij znotraj skupine v dodatno raven hierarhije za poenostavitev življenja razvojne ekipe UPF, ekipe za preverjanje in ekipe za implementacijo. Še enkrat, morda mora biti neka podfunkcija IP-ja v drugi domeni kot ostali IP, zato morate ta del prestrukturirati v drugo skupino. Te spremembe niso enkratne odločitve. Hierarhične optimizacije za moč lahko ostanejo nekoliko tekoče, dokler ne veste, da dosegate svoje cilje glede moči. Včasih precej pozno v načrtovanju.

Ponovna uporaba podsistema

O ponovni uporabi pogosto razmišljamo v smislu naslovov IP. Komercialno dobavljeni bloki ali preizkušene interne funkcije. Vendar pa je ponovna uporaba enako pomembna, morda bolj pomembna, za vnaprej oblikovane podsisteme, čeprav običajno ne kot natančna ponovna uporaba. Nekatere spremembe, ki jih boste morda morali narediti tukaj, so spet posledica izbir upravljanja porabe energije. Morda izbire hierarhije, ki ste jih izbrali za prejšnjo zasnovo, niso povsem primerne za izpeljanko in jih je treba prilagoditi. Nekatere funkcije, ki so bile v vedno vklopljeni domeni, se morajo premakniti v preklopno domeno, nekatere preklopljene funkcije pa morajo biti zdaj vedno vklopljene.

Včasih potrebe po premikanju funkcij v hierarhiji ne motivira moč. Pomislite na primer na pomnilniški podsistem. Zasnovan, odpravljen napak in preizkušen na terenu v vaši prvi izdaji izdelka. Isti podsistem želite uporabiti v izpeljanem izdelku. Toda glede na tloris bo DDR PHY obrnjen v zasnovo, ne proti robu matrice. Ponovno bi radi naredili nekaj prestrukturiranja, da bi poenostavili premikanje tega v implementaciji.

Skupščina za prestrukturiranje

RTL je zelo zmogljiv, vendar eno področje, ki mu resnično ne uspe, je prilagodljivost v hierarhiji načrtovanja. Ko enkrat določite hierarhijo, jo postane zelo težko spremeniti. Za preproste spremembe bi lahko razmislili o skriptiranju, vendar ta pristop hitro zmanjka goriva. Poskusite premakniti dva primerka iz bloka v drug blok na isti ravni. Nekatere povezave boste morali z gumijastim trakom priviti nazaj v prvotni blok, po možnosti prek novih vrat. Ali pa jih lahko zamenjate z neposrednimi povezavami v drugem bloku. Potem bi morali odstraniti odvečna vrata na obeh blokih. In tako naprej.

Kompleksnost premikanja funkcij po hierarhiji hitro postane očitna. Pristopi, ki temeljijo na scenarijih, so preprosto pretežki. Sintaksa SystemVerilog ali VHDL še dodatno poslabša težavo. To so transformacije, ki zahtevajo resno znanje in izkušnje EDA in validacijo pri več strankah. Še vedno morate zagnati preverjanje enakovrednosti med seznamoma omrežij pred in po, da dvakrat preverite. Toda želite, da je to potrditev, ne korak v neskončnem ciklu popravkov.

O Arteris IP SoC/razvojni izdelek vmesnika strojne in programske opreme (HSI). zagotavlja avtomatizirano podporo za to prestrukturiranje v sestavu SoC. Preizkušen na številnih modelih. Naj bodo te zapletene transformacije drugačna priložnost za vašo ekipo izdelkov in ne ovira.

Delite to objavo prek: Vir: https://semiwiki.com/ip/304204-physically-aware-soc-assembly/