UPF & IPF

UPF-ն ընդդեմ IPF-ի հպանցիկ

Երկու ձևաչափերն էլ Tcl-ի վրա հիմնված են, երկուսն էլ power-ի մասին են, և երկուսն էլ սնուցում են նույն ավելի լայն power-integrity signoff գործընթացը, որ այս փաստաթղթային հավաքածուն արդեն ծածկում է — բայց դրանք գործում են design հոսքի հակառակ ծայրերում և պատասխանում են բոլորովին տարբեր հարցերի։

Սնման տիրույթներ & Սնուցման հավաքածուներ

Ամեն ինչ UPF-ում կառուցվում է երկու primitive-ի վրա. սնման տիրույթ-ը խմբավորում է logic-ը, որ կիսում է ընդհանուր power control, իսկ սնուցման հավաքածու-ը խմբավորում է իրական power/ground հանգույցները, որոնք սնուցում են domain-ը։ UPF-ը շերտավորվում է RTL-ի վրայից՝ առանց դրան դիպչելու — նույն Verilog-ը ստանում է տարբեր power վարքագիծ՝ կախված միայն նրանից, թե որ UPF ֆայլն է դրա կողքին բեռնվում։

Կառուցելով քայլ առ քայլ, հրաման առ հրաման

# Create the top-level power domain (always-on context)
create_power_domain PD_TOP -include_scope

# Create a power domain scoped to just the GPU instance
create_power_domain PD_GPU -elements {gpu_inst}

# Define supply nets (the actual power/ground rails)
create_supply_net VDD_TOP -domain PD_TOP      # 1.2V supply for top
create_supply_net VDD_GPU -domain PD_GPU      # switchable supply for GPU
create_supply_net VSS     -domain PD_TOP      # common ground

# Group related supplies into a named supply set
create_supply_set SS_TOP -function {power VDD_TOP} -function {ground VSS}
create_supply_set SS_GPU -function {power VDD_GPU} -function {ground VSS}

# Attach each supply set to its domain
associate_supply_set SS_TOP -handle PD_TOP
associate_supply_set SS_GPU -handle PD_GPU

Power State-եր & Power Switch-եր

Power state-ը անվանված, օրինական լարման արժեք է, որ սնուցման հանգույցը կարող է ընդունել (add_power_state). power switch-ը UPF օբյեկտն է, որ մոդելավորում է իրական header/footer switch cell-ը, որ վերահսկում է՝ արդյոք domain-ի սնուցումը միացած է upstream always-on rail-ին (create_power_switch)։ Միասին դրանք այն են, ինչ domain-ը դարձնում է «power-gateable», այլ ոչ միայն multi-voltage։

# Power states: legal voltage values for each supply
add_power_state VDD_TOP -state {ON 1.2}
add_power_state VDD_GPU -state {ACTIVE 0.9} -state {OFF off}

# Power switch: models the physical header/footer switch cell
create_power_switch PSW_GPU -domain PD_GPU \
  -input_supply_port  {vin  VDD_TOP} \
  -output_supply_port {vout VDD_GPU} \
  -control_port       {ctrl gpu_power_enable} \
  -on_state            {on vin {ctrl}}

Switch-ը կարդալով. vin-ը always-on input rail-ն է, vout-ը switched output-ն է, որ իրականում սնուցում է PD_GPU-ն, և ctrl-ը enable signal-ն է։ -on_state {on vin {ctrl}} clause-ը ասում է «output-ը 'on' state-ում է, drive արված vin-ից, երբ control condition-ը ճշմարիտ է» — երբ gpu_power_enable-ը deassert է անում, vout-ը (և հետևաբար VDD_GPU-ն) չունի վավեր on-state, և domain-ը off է։

Isolation ռազմավարություններ

Երբ սնման տիրույթը gate արվում է off, դրա output-ները float են անում դեպի undefined արժեք։ Եթե այդ undefined signal-ը հասնում է always-on logic-ին, այն կարող է աղավաղել հաշվարկը, առաջացնել shoot-through հոսանք (թե՛ PMOS-ը, թե՛ NMOS-ը միջանկյալ լարումում conducting), կամ receiving flip-flop-ը դարձնել metastable։ Isolation cell-երը նստում են սահմանին և clamp են անում domain-ի output-ները հայտնի-ապահով արժեքի (0 կամ 1), երբ domain-ը off է — և կրիտիկական, isolation cell-երն իրենք սնուցվում են always-on սնուցումով, ոչ թե gate արվող domain-ով, ուստի դրանք շարունակում են գործել այն բանից հետո, երբ իրենց isolate արվող domain-ը կորցրել է power-ը։

set_isolation ISO_GPU -domain PD_GPU \
  -isolation_supply_set SS_TOP \
  -clamp_value 0 \
  -isolation_signal gpu_iso_enable \
  -isolation_sense high \
  -location parent

Retention ռազմավարություններ

Domain-ի power gating-ը սովորաբար կորցնում է ամեն flip-flop-ի state-ը՝ ստիպելով դանդաղ software re-initialization արթնանալիս (միլիվայրկյաններ)։ Retention-ը ավելացնում է երկրորդ, always-on, low-voltage supply (սովորաբար 0.6–0.8V) հատուկ կառուցված retention flip-flop-երին, որպեսզի state-ը պահպանվի power-down ցիկլի ընթացքում գրեթե-զրո արտահոսքով և վերականգնվի միկրովայրկյաններում՝ միլիվայրկյանների փոխարեն — հեռախոսի ակնթարթորեն արթնանալու (հպումով) և տեսանելիորեն հետ մնալու տարբերությունը։

# Retention supply: a second, always-on, low-voltage net
create_supply_net VDD_RET -domain PD_CPU
create_supply_set  SS_CPU_RET -function {power VDD_RET} -function {ground VSS}
add_power_state    VDD_RET -state {RETENTION 0.6}

# Basic retention: every flip-flop in the domain
set_retention RET_CPU -domain PD_CPU \
  -retention_supply_set SS_CPU_RET \
  -retention_condition {cpu_retention_enable}

# Selective retention: only the state actually worth saving
set_retention RET_CRITICAL -domain PD_CPU \
  -retention_supply_set SS_CPU_RET \
  -retention_condition {retention_enable} \
  -elements {
    cpu_inst/control_unit/config_regs
    cpu_inst/control_unit/status_regs
    cpu_inst/mmu/tlb_state
  }

Selective retention-ը (-elements-ի միջոցով) գործնական default-ն է իրական design-ներում. ամեն flip-flop retain անելն արժենում է 30–50% լրացուցիչ area յուրաքանչյուրի վրա, ուստի թիմերը սովորաբար retain են անում միայն control/status register-ները և re-initialize են անում bulk datapath state-ը (ALU operand-ներ, ժամանակավոր buffer-ներ) արթնանալիս, քանի որ այդ state-ն ամեն դեպքում էժան է վերահաշվարկել։

Level Shifter-ներ

Երբ signal-ը մեկ լարման domain-ից անցնում է մյուսը, receiving domain-ի gate-երը կարող են ճիշտ չմեկնաբանել sender-ի լարման swing-ը։ 0.9V-ով drive արված signal-ը, որ հասնում է 1.2V domain-ի input-ին, կարող է չգրանցվել որպես մաքուր logic-1 (low-to-high crossing). 1.2V signal-ը, որ ուղղակիորեն drive է անում 0.6V gate-երի մեջ, կարող է overstress անել ավելի փոքր-լարման տրանզիստորների բարակ oxide-ը (high-to-low crossing)։ Level shifter cell-երը նստում են այս domain սահմաններին և թարգմանում լարման swing-ը, որպեսզի receiving domain-ը տեսնի մաքուր, full-rail signal։

set_level_shifter LS_LOW_TO_HIGH -domain PD_LOW \
  -applies_to outputs \
  -rule low_to_high \
  -location parent

Isolation-ի նման, -location parent-ը տիպիկ ընտրությունն է՝ level shifter cell-ը տեղադրելով source domain-ից անմիջապես դուրս, որպեսզի այն drive արվի երաշխավորված հասանելի supply-ով։ Շատ իրական design-ների պետք են level shifter-ներ երկու ուղղություններով միաժամանակ, եթե domain-ը թե՛ signal-ներ է ուղարկում ավելի-բարձր-voltage հարևանին, թե՛ ստանում է signal-ներ դրանից — -rule-ը կարող է դրվել low_to_high, high_to_low, կամ both՝ կախված crossing-ից։

UPF-ը design հոսքում

UPF-ը գրվում է վաղ և վերաօգտագործվում, անփոփոխ, ամեն downstream գործիքի կողմից — այդ հետևողականությունն է դրա ստանդարտացման ամբողջ իմաստը։

IPF. Instance Power File

Այնտեղ, որտեղ UPF-ը նկարագրում է intent, IPF-ը տանում է տվյալ. հարթ տեքստային ֆայլ, որ թվարկում է, թե որքան power (կամ հոսանք) է design-ի ամեն instance-ն իրականում քաշում, գեներացված power-estimation գործիքով — սովորաբար Synopsys PrimePower-ով — և սպառված RedHawk-SC-ի PowerView օբյեկտի կողմից static IR-drop-ի և electromigration-ի signoff-ի համար (տես Static Analysis)։ RedHawk-SC-ն աջակցում է երկու IPF layout, մանրամասն 9-column ձևին և ավելի պարզ 3-column ձևին։

IPF-ը static power հոսքում

RedHawk-SC-ի PowerView-ն, ըստ էության, ամբողջական scenario view-ի թեթև տարբերակ է, որ միայն instance power է հետևում — այն կարող է ուղղակիորեն import անել hand-off IPF ֆայլ, ինքը հաշվել power-ը SwitchingActivityView-ի toggle rate-երից, կամ convert անել հոսանքները առկա analysis-ից։ Երբ այն import է անում IPF, ծածկույթը կարևոր է. appnote-ը հստակ ասում է, որ ֆայլից բացակայող instance-ները ստանում են զրո վերագրված power, ուստի թերի IPF-ը լուռ under-count է անում իրական էներգասպառումը, եթե չծածկված instance-ների համար վերևից չշերտավորվի fallback switching-activity-driven հոսք։

# Load a design's IPF file into a PowerView for static analysis
pwr = db.create_power_view(dv=dv, power_file_names='power.ipf.gz', tag='pwr')

# Use that PowerView in a static scenario for IR-drop / EM signoff
scn = db.create_scenario_view(power_view=pwr, scenario_type='Static',
                                options=options, voltage_levels=voltage_levels, tag='scn')

# ...later, export an IPF back out of a PowerView (e.g. after adjustment)
# PowerView.write_instance_power_file(file_name, comment=None)

Մի քանի IPF ֆայլ կարող են համակցվել մեկ power_files ցուցակում, յուրաքանչյուրը scoped լինելով կոնկրետ instance_name-ի, cell_name-ի, կամ scaling_factors dict-ով՝ կոնկրետ սնուցման հանգույցի ներդրումը վերասանդղակելու համար — և ցուցակում ուղիղ մեկ ֆայլ կարող է նշվել 'override': True՝ առաջնություն ստանալու համար, եթե նույն instance-ը հայտնվի մեկից ավելի source ֆայլում։

UPF-ն ընդդեմ IPF-ի, կողք-կողքի

Կարճ ասած. առանց UPF-ի chip-ի power architecture-ն ընդհանրապես չունի formal, գործիք-անկախ նկարագրություն։ Առանց IPF-ի (կամ RedHawk-SC-ի power-sourcing այլ մեթոդներից մեկի) EMIR Analysis էջում գտնվող static IR-drop-ի և EM analysis-ը ընդհանրապես չունի per-instance power թվեր, որոնցից աշխատել։ Դրանք մրցակից ձևաչափեր չեն — դրանք հաջորդական կախվածություններ են նույն signoff շղթայում։

Աղբյուրներ

• IEEE 1801 — Unified Power Format Standard — IEEE Xplore
• Introduction to UPF — ChipVerify
• UPF Isolation Strategies — ChipVerify
• UPF Retention Strategies — ChipVerify
• Unified Power Format — Wikipedia
• Common Power Format — Wikipedia
• An Inside Look at UPF 4.0 — Semiconductor Engineering
• IPF (Instance Power File) 9-column և 3-column ձևաչափի specification-ը, օրինակ տվյալները և static-flow-ի կիրառումը — AppNote_Static_Power_Analysis_In_RedHawk-SC.pdf (ներքին Synopsys/Ansys RedHawk-SC փաստաթուղթ)
• PrimePower: RTL to Signoff Power Analysis — Synopsys
• RedHawk-SC | SoC Power Integrity & Reliability Software — Synopsys