Low Power Design Verification of Complex Chips

964 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
964
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Low Power Design Verification of Complex Chips

  1. 1. 1Narasimha KarunakarAMD India LtdChallenges, Possible Solutions and Flow Changesfor Low Power Design Verification ofComplex Chips
  2. 2. 2AgendaLow power design techniques overviewPower Aware Verification (PAV) challengesPossible solutionsDesign guidelinesVerification guidelines
  3. 3. 3Low Power Design Techniques:Requirement than ImprovementHigher clock frequencies + Higher device density=> High power dissipationConflicts with increasing importance on batterylife and power savingsExponential growth in usage ofHandhelds/Laptops/MobilesPerformance/Watt is the new mantra!!
  4. 4. 4Low Power Techniques OverviewSupply voltage reductionBased on speed requirementMulti-Vt (Threshold Voltage) Library cellsHigh Vt transistors for low speed blocks => Low static leakagecurrent
  5. 5. 5Low Power Techniques OverviewPower switchingShut down when idle.Leakage power & Switching power is lowered.Top level module outside power gatingModule underPower gatingSwitching circuitPower PortPower Port
  6. 6. 6Low Power TechniquesOverviewLevel shifterIsolation cell
  7. 7. 7Next…Low power design techniques overviewPower Aware Verification (PAV) challengesPossible solutionsDesign guidelinesVerification guidelines
  8. 8. 8Power Aware Verification challengesConventional verification infrastructure isnot PAV readyNo notion of voltage/powerProtection gates modeling absent in RTLPower Ports & Power Switches not modeledChecks on missing protection gates notdone
  9. 9. 9Power Aware Verification challengesPower up and Recovery sequence checksinadequateAll voltage/power planes tied to 1’b1 or1’b0 – no sequencingReset asserted at time 0 allows signals to beinitialized at the beginning itselfFlops retain value even when domain ispowered off
  10. 10. 10Next…Low power design techniques overviewPower Aware Verification (PAV) challengesPossible solutionsDesign guidelinesVerification guidelines
  11. 11. 11Possible solutionsMake Verification environmentvoltage/power awareAble to Simulate Real silicon behavior (‘Z’/’X’when power down)Model power switches & protection gatesCheck for illegal power state transitionsSupport for recovery sequencesBring all state points to ‘X’ at power-upInitialization sequence should get them back to definedstate
  12. 12. 12Possible solutionsSome Tool vendors that address the above challengesSynopsyso MVtools (MVSim & MVRC)o UPF (Unified Power Format)Cadenceo Incisive verification flowo CPF (Common Power format)
  13. 13. 13Next…Low power design techniques overviewPower Aware Verification (PAV) challengesPossible solutionsDesign guidelinesVerification guidelines
  14. 14. 14Why Guidelines (RTL & PAV)Support power-aware tools/infrastructureAvoid hang issuesAvoid false failsMinimize debug timeCatch issues early in design cycle
  15. 15. 15RTL design guidelinesModeling the protection gates in RTLInstantiation in RTLFor SAPR flow & Custom flowsFind bugs early in the gameFirewall the ports when chip ‘PwrOk’ is not setCorrect Protection gates to be implemented betweenpower domains
  16. 16. 16RTL design guidelinesPartition & BoundaryVoltage island boundaries alignmentNo Multiple Power domain in a final leaf moduleBelow Ex: a11 shouldn‘t have multiple power domainsinside it.TOPA1A2A3a11VDD_A1VDD_A1VDD_A11 VDD_A3VDD_A3VDD_A2VSS
  17. 17. 17RTL design guidelinesInitialization of states/regs & MemoriesOnly after power ONAt least one power port in the port list.//*** Wrong Initialization ***//initial beginnum_phases = 5b11100;end//*** Correct Initialization ***//always @(posedge VDD_IP) beginnum_phases = 5b11100;end
  18. 18. 18RTL design guidelinesExpression in instantiationWrong/No power domain assigned to ‘AND’IP1 instance_a (.A_B ( A & B),....);IP1 on PD1 A_B ANDANDANDANDANDANDANDANDANDANDAB IP2 on PD2
  19. 19. 19RTL design guidelinesAvoid Constants in Port mappingAvoid constants (1b1/1b0) & shouldn’t cross domainboundariesmodule modA;modB inst_modB (.in1(abc), .in2(1b0));//DOMAIN_Bendmodulemodule top;modA inst_modA (.vdd_main(vdd_main),.vdd_sub(vdd_sub));endmoduletopvdd_mainvdd_submodAin1modB in2PowerPorts
  20. 20. 20RTL design guidelinesCorrect coding practice: Use Power railsmodule modA;modB inst_modB (.in1(abc), .in2(vdd_sub));//DOMAIN_Bendmodulemodule top;modA inst_modA (.vdd_main(vdd_main),.vdd_sub(vdd_sub));endmodule
  21. 21. 21Next…Low power design techniques overviewPower Aware Verification (PAV) challengesPossible solutionsDesign guidelinesVerification guidelines
  22. 22. 22Verification guidelinesCheckers should be aware of:Current power state of the module to which it is associatedShould know that signal is ‘Z’/’X’ during power down.Qualify the checks with PwrOk or Reset of the modulevoid Monitor() {if(RTL_IP_IReset != RTL_IP_IReset[-1]) {return();}}ORvoid Monitor() {If (RTL_PwrOk.IsX ==1 or RTL_PwrOk == 1’b0) {return();}}
  23. 23. 23Verification guidelinesAlways assume 4-state values for RTL signals:Qualify the control signal to see if it is ‘Z’/’X’Then check for correct value of the signal (1’b1 or1’b0)In C/C++ Domain ‘X’ is seen as 1’b1 & ‘Z’ is seen as1’b0
  24. 24. 24Verification guidelines// *** Wrong coding ***//void Monitor() {if(RTL_BIST_Complete == 1) {…// checks//}// *** Correct coding ***//void Monitor() {if (RTL_BIST_Complete == 1 && RTL_BIST_Complete.IsXorZ()!= 1) {…// checks//}
  25. 25. 25Verification guidelines• Test plan is to check if it is not ‘X’ or ‘Z’// *** Correct coding ***//void Monitor() {if (IntState == SLEEP) {if(RTL_DramReset.IsXorZ() == 1 || RTL_DramReset == 1){Error (“Un-expected X/Z”);} else {}
  26. 26. 26ReferencesDiagrams on “Power reduction techniques”Synopsys Low-Power Flow User Guide (Version A-2007.12, December 2007)
  27. 27. 27Good ByeTHANKS FOR YOUR TIME

×