Jianfeng Liu, Jaehan Jeon, Mi-Suk Hong, KyungTae Do, HyoSig Won, JungYun Choi, Kee Sup Kim System LSI Division Samsung Electronics Co., Ltd.

Transcription

1 Jianfeng Liu, Jaehan Jeon, Mi-Suk Hong, KyungTae Do, HyoSig Won, JungYun Choi, Kee Sup Kim System LSI Division Samsung Electronics Co., Ltd.

2 The evolution of smart phones and tablet has ever driven the continuous improvement of computing and communication capability of mobile SoCs Sophisticated low power design technologies have been applied in the mobile SoC designs, which require a unified power specification to manage the integration complexity across all the design and verification steps MultiMedia Internet Smart Power Control DVFS Power Gating Adaptive Body Bias Map/Nav Social Network Complex HW Game & Cam Multi-Vth Multi-VDD Clock Gating Low Power CTS High-K Metal Gate O/S 1 SOI

3 UPF 1.0 was standardized by Accellera, later revised into IEEE IEEE is on the way to release later this year We have used UPF 1.0 with bottom-up hierarchy design flow EDA tools have been more stable for UPF 1.0 support, which is very important for product design Bottom-up hierarchy flow is the only feasible approach in the era of billion gate SoC design Each block has its own UPF file Easy to manage and reuse UPF file Block RTL Block UPF Block UPF Block UPF DC (Block-Level) Block Netlist+UPF ICC (Block-Level) TOP RTL Block ILM Block ILM TOP UPF DC ( Level) -level Netlist+UPF ICC (TOP-Level) Full Chip Netlist+UPF 2

4 There are many challenges in deploying UPF hierarchy flow in SoCs A single power specification is used in multiple tools and steps in design and verification flow. A small change in UPF may incur significant TAT overhead in SoC design schedule The complicated interactions between library, design, UPF and EDA tools makes the debug process difficult The huge complexity of billion gate SoC, the complex low power techniques, special design styles of SoCs and the bottom-up hierarchy flow put significant challenges in UPF deployment the UPF file becomes too big to manage in billion gate SoC era The complexity of power state table (PST) increase almost exponential with the number of power domains Some RTL coding styles are difficult or not compatible with UPF flow Custom design styles requires special attention in UPF flow UPF EDA Tools 3

5 Library PVT Corners In UPF flow, voltages values should be matched between liberty, synopsys tools script and UPF Liberty library (.db/.lib) for all the PVT corners needed for SoC design should be available The library physical (FRAM) views should match liberty library (.db) Update FRAM when mismatch happens - Icc_shell> update_mw_port_by_db db mem.db mw_lib mem.mw DC (mapping supply name & value ) # liberty library voltage_map (VDDP, ); voltage_map (VDDI, 0.9) VDD_IO_A VDDP Liberty (pg_pin) # synopsys tool scripts VDD_CORE VDDI set_voltage 2.97 object {VDD_IO_A} set_voltage 0.9 object {VDD_CORE} UPF (create supply port, net) cell domain # UPF add_port_state VDD_IO_A state {bst_io_on 2.97} add_port_state VDD_CORE state {bst_core_on 0.9} 4

6 UPF compliant libraries should be available for not only standard cells (SC) and power management cells (PMK), but also memories and Macros There isn t any strict UPF compliance checker for Macro libraries. Communication between library design and SoC designer is important to make UPF compliant library Case A: An power port in a Macro was initially defined as a signal port in libraries, which caused warning in UPF flow After discussion, the port is corrected as power port in library Case B: the related supply net of an input Pin of a Macro is wrong, causing level shifter insertion Update the library for correct related_supply_net attribute VDD_TOP VDD_TOP: 1.65V VDD_M: 1.9V Macro IP VDD_O DVDD VDDM A Macro VSS VSS 5

7 It is utterly important to write UPF correctly in the early phase, to avoid design turnover and save project turn-around-time. Power net should be declared for all the design elements inside its power domain, not only for the existed design elements, but also for newly inserted power management cells by UPF and the buffers and physical cells in all the implementation stages This rule also applies when connecting power to logic 1 tie Isolation strategy: If a power domain boundary pin is driven by a constant, the clamp value of isolation cells should align to the constant at the domain boundary Isolation is not need for floating power domain outputs Make a default rule when writing isolation policy, for possible stitch signals added by DFT or P&R tools For MCMM flow, it is mandatory to add worst, nominal, best voltage conditions in UPF with add_port_state command Eg. add_port_state VDD state {VDD_wst 0.95} state {VDD_nom 1.0} -state {VDD_bst 1.05} 6

8 For correct buffering in the implementation flow, it is important to use set_related_supply_net in UPF to set correct related_supply_net for start and end port of wire TOP(AO) : VDDI /VSSI Block (shut-down): VVDD/VSSI : Always-on : Shut-down I_Feed n1 ao n2 n3 n4 nn M1 ao M2 ao M3 ao ao MN no_ao_net1 no ao attr. BUF O_Feed *SRSN: set_related_supply_net RSN : related_supply_net SRSN: VDDI, VSSI (UPF) Cell M1~MN has feed-through wire Lib. Pins have ao attribute at in/out Pin SRSN: VVDD, VSSI (default) I_Feed TOP(AO) : VDDI /VSSI n1 ao Block (shut-down): VVDD/VSSI n2 n3 n4 nn M1 ao M2 ao M3 ao ao MN ao_net1 set ao attr. AON O_Feed : Always-on : Shut-down *SRSN: set_related_supply_net RSN : related_supply_net SRSN: VDDI, VSSI (UPF) Cell M1~MN has feed-through wire Lib. Pins have ao attribute at in/out Pin 7 SRSN: VDDI, VSSI (set)

9 Special attention needs to be paid when writing UPF for bottom-up hierarchy flow For the control signals of isolation/power-switch/retention cells in UPF, ILM boundary pins should be used in hierarchy flow For bottom-up hierarchy flow, a separate UPF file is needed to specify the isolation strategy for parent location If isolation location is parent, then isolation cells will be placed outside a block. Therefore, the isolation control signal is not accessible inside the block This isolation strategy should be prepared as a separate file, for top-level implementation Block The isolation control signal is out-of-scope inside block 8

10 Two key issues for writing UPF for complex SoC: Reusability and PST complexity To improve reusability of UPF, the following procedure is used in our design flow to write UPF with tcl ## Designer Write initial UPF with tcl create_power_switch ${DOMAIN}_SW \ -domain ${DOMAIN} \ -input_supply_port {in ${Real_VDD}} \ -output_supply_port {out ${Virtual_VDD}} \ -control_port {SW_${DOMAIN}} \ -on_state {${DOMAIN}_ON in {!SW_${DOMAIN}}} map_power_switch ${DOMAIN}_SW \ -domain ${DOMAIN} \ -lib_cells $DEFAULT_POWER_SWITCH To tackle the complexity of power state table (PST), the following procedure is used in our design flow to write PST with wildcard and state subset expansion support ## Designer Write initial UPF with wildcard add_port_state VDD state {ON 1.0} state {OFF off} add_port_state VDDS state {ON 1.0} state {OFF off} add_port_state VDDC state {HV 1.2} state {LV 0.8} state {OFF off} create_pst top_pst supplies {VDD VDDS VDDC} add_pst_state s0 pst top_pst state { ON * {HV,LV}} Design compiler save_upf before compile ## Golden UPF from DC save_upf command create_power_switch PD1_SW \ -domain PD1 \ -input_supply_port {in VDD_PD1} \ -output_supply_port {out VVDD_PD1} \ -control_port {SW_PD1} \ -on_state {PD1_ON in {!SW_PD1}} map_power_switch PD1_SW \ -domain PD1 \ -lib_cells {HEADBUF16_X1M_A9TR} 9 Samsung In-house tcl procedure ## PST obtained in golden UPF create_pst top_pst supplies {VDD VDDS VDDC} add_pst_state s01 pst top_pst state { ON ON HV} add_pst_state s02 pst top_pst state { ON OFF HV} add_pst_state s03 pst top_pst state { ON ON LV} add_pst_state s04 pst top_pst state { ON OFF LV}

11 While UPF flow makes low power flow integration more fluent, it brings several limitations for implementing low power techniques in SoCs. In UPF flow, Isolation cells and level shifters can only added at power domain boundary UPF support for modeling low power scheme inside Macros is limited UPF support for modeling top level power constraints to block level is limited To overcome these constraints, the SoC design has to be modified. RTL modification for inserting isolation cells for Macro input A wrapper is created to add isolation cells Macro Wrapper Macro Macro 10

12 Example: When the output of one power domain is multi-fanout signals, which drives different power domains, it is difficult to describe this situation in UPF. Assume that Block A, B, C are defined as defined as different power domains, which can power ON/OFF independently. TOP can only be power OFF when all the block A, B and C are OFF Case A: RTL modification is not needed. User can define isolation policy as inputs for block B and C Case B: This case need RTL change, i.e. duplicate the multi-fanout at block A for driving TOP domain Block A Block B Block C Block A Block B Block C 11

13 Due to high complexity of the UPF development in hierarchy designs, EDA vendors tight support and collaboration is valuable Case A: A macro has internal footer switch, while SoC uses header switch Problem: EDA tool can not treat correctly for the isolation requirement between Macro and SoC, and a lot of warning messages were issued Work-Around: set_related_supply_net was used to solve this temporally EDA tool has been enhanced to solve this for the derivative products VDD Case B: Some IO libraries are wide-range IO, which can be used with different voltage connections Problem: EDA tool treat this case as operation condition violation, and tool crashes happens Work-Around: Duplicate library temporally EDA tool has been enhanced: voltage value in UPF can override the operation condition specified in IO liberty library VDD_TOP: 3.0V DIN SLEEPN Internal Logic VSSI DOUT PAD PWR_PAD (PAD_B) 1.65V AY IP_B (3.0V) VSS 12

14 The recipes summarized in this presentation are based on the experience of successful deployment of the UPF flow in several Samsung SoC tapouts The major benefits obtained from UPF deployment Build the accurate power specification for complex SoC designs Minimize the integration efforts of low power design flow for derivative products Align the low power specification across implementation and verification flow Pending issues in UPF flow DK release generally has a fixed version for a specific technology node. However, A lot of new features in UPF flow are only available in new library compiler version, which make it difficult to maintain DK release. To avoid TAT issue, a detailed guide and ECO-like flow is needed when UPF has to be changed at later P&R stages 13

15 UPF has provided several advantages for seamless low power flow integration. However, it brings significant challenges in practical design flow as well. In this presentation, we outlined the details of challenging issues of UPF deployment in hierarchy implementation flow, such as the impact of UPF update on TAT, the complicated interaction between design, UPF, library and EDA tools, the increased UPF file size and complex power state table etc. We have shared our know-how to overcome these challenges. We presented our methodology in four aspects: making correct library release, guideline to write UPF, how to adapt the design to UPF flow and recent collaborations with EDA vendors on tool enhancement. The UPF methodology summarized in this presentation has helped us to deploy the UPF hierarchy flow successfully in several Samsung SoC tapeouts 14