Power Format Comparison Report out

Transcription

1 Power Format Comparison Report out Gary Delp Ranen Fraer David Hui Herve Menager Nick English Dave Allen David Hathaway Gila Kamhi Oscar Siguenza Judith Richardson Dirk Siemer John Biggs

2 Purpose and Agenda Analyze in preparation for merging: Agenda CPF & UPF Key Messages Process Followed Use Cases to be supported Base similarities Discerned differences Questions Use case support Next Steps Reference Materials User Comparison work group 2

3 Key Messages The two specifications describe very similar structures Both specifications provide excellent basis for work Both contain important capabilities not present in the other, e.g. Crisp simulation semantics UPF Rule based identification - CPF Some of the Use Cases need capabilities not contained in either Extension of retention model Defined IP reuse model hierarchy of Power domains / modes/ states Crisp always on This work is not yet complete, it requires some refinement We are here to be asking experts in capabilities User Comparison work group 3

4 Process Followed The analysis and comparison has taken four parallel tracks: Comparing data model Comparing command capabilities Group commands by function Comparing expression Group commands & arguments by action Use Case analysis Support for desired tasks in the design flow User Comparison work group 4

5 Use Cases to be supported and implications Roles/Tasks Design reuse is key Questions center around the separation of the information for: identification, implementation, verification, analysis, and This split allows an IP provider to specify the "what" in the source of the IP with out having to predicate the "how The Identification task requires: Declaring the "atomic" power domains that could be used these can be merged but not split during implementation Declaring the state needs to be retained during shutdown but not prescribing how retention is controlled Declaring the signals that need clamping high/low but not prescribing how isolation is controlled Declaring the legal power states and sequencing with out prescribing absolute voltages User Comparison work group 5

6 Roles in design process IP Providers Block and subsystem provider - identification of feature points Library Provider identification of capabilities provided by cells System Functional designer changes RTL Design Power Architect does not change RTL Methodologist may provide general design rules or checks This drives or checks implementation Verification Validates intent and transformations Power analysis must produce accurate and consistent results between tools. User Comparison work group 6

7 High level examples IP provider creates soft processor with retention locations specified but no strategy defined How do they verify it How is it used Sequencing of switches and relation to retention strategy Additional examples User Comparison work group 7

8 Base similarities Data Model Operate on the Design Naming is in the Design Name space Hierarchy of Always on unclear Both moving toward separation of Identification and implementation Both include power states or modes User Comparison work group 8

9 Power management Structures Power Domain The collection of design objects that share common power attributes Power Supply Relations & Connections between Domains Level shifters Isolation logic [ Gas Stations always on] Power States or modes Controlled by Switches May require Retention Associate with models and corners May require sequencing Affects simulation Structures support tasks of: Identifying elements Managing Implementing Analyzing Reusing + - User Comparison work group 9

10 Power Management Source & Flow Power source files are part of the design source. Combined with the RTL, the power files are used to describe the intent of the designer. This collection of source files is the input to several tools, e.g., simulation tools, synthesis tools, and formal verification tools. Synthesis tools can read the RTL/power design input files and produce a netlist. The tool or the user may produce a new power fileset which, combined with the netlist, represents a further refined version of same design. Also, the power file that is used as input may be reused without change at later stages in the tool flow, or alternate power files may be prepared. In those cases where names change beyond the capability of name mapping to follow, power files with the new names may be needed. A power-aware logical equivalence checker can read the full design filesets and perform the checks including the results of the power commands to ensure equivalence. Place and Route tools read both the netlist and the power files and produce outputs, potentially including output power files Power Source File(s) HDL/ RTL Synthesis Power Source Verilog File(s) (Netlist) P&R Power Source File(s) Verilog (Netlist) Simulation, Logical Equivalence Checking, User Comparison work group 10

11 Design Model

12 User Comparison work group 12

13 Power and Ground Connectivity supply net characterization Power net reuse hierarchy vs flat User Comparison work group 13

14 Power Management constructs Switches Retention How does complex retention get represented. Isolation combination of isolation and level shifting. High to low, low to high, split grounds (type may be more complex than UPF can encompass) Level shifting "Gas Stations" User Comparison work group 14

15 Discerned differences Element selection capability Named groups and rules - CPF Scoping assumptions needs more examination Simulation/modeling mapping Simulation and implementations both need specification Semantic rules included in specification CPF Identify power logic Specification of logic in power source file SAIF spec included in UPF Introductory material included in UPF User Comparison work group 15

16 COM EG: Port Creation for a Hierarchical Flow top_chip Default (always on) IPInst DRAM Standby (virtual domain) (on/off) IPMod DRAM TAGRAM shutoff there is no power down control port shutoff at RTL Isolation logic inserted at full chip level based on IP CPF information standby PD1 (on/off) IPmod.cpf set_design IPMod ports {shutoff} create_power_domain \ -name Standby \ -boundary_ports {DRAM[0:15] TAGRAM[0:15]} \ -instances DRAM -shutoff_condition {shutoff} end_design FullChip.cpf set_design top_chip create_power_domain \ name PD1 \ instance create_power_domain name Default default set_instance IPInst \ port_mapping { {shutoff standby} } source IPmod.cpf create_isolation_rule \ -from IPInst/Standby \ isolation_condition standby \ end_design User Comparison work group 16

17 COM EG: Module Based CPF alu.cpf set_design alu create_state_retention_rule -name srpg \ -instances z* end_design FullChip.cpf set_design top_chip both are instantiated from module alu FFs z* in alu_inst/aui will be mapped to state-retention flops FFs z* in alu_inst/lui will not be mapped to state-retention flops create_power_domain -name PDau \ -instances alu_inst/aui \ -shutoff_condition {pcu_inst/pso[0]} \ default_restore_edge {pcu_inst/pg1} create_power_domain -name PDlu \ -instances alu_inst/lui \ -shutoff_condition {pcu_inst/pso[1]} set_instance alu_inst/aui source alu.cpf set_instance alu_inst/lui source alu.cpf end_design User Comparison work group 17

18 COM EG: Handle Feed-Through Net top I1 I2 PD1: always on, default W1 inv1 inv2 I3 I5 I4 PD2: switchable W2 inv3 pse I6 PD3: always on identify_always_on_driver pins { I6/pse } User Comparison work group 18

19 logic independence vs. boolean expression capability using boolean expressions for power shutoff rules is very very convenient Using this for "What if" exploration during early work This is not an arbitrary HLL function, but just a boolean function of pins UPF specifiys the system Think of this as an assertion check in the design intent The signals required to implement a particular power control intent may differ between implementations, therefore a single signal choice to be used over all stages or alternatives of implementation may not be available. User Comparison work group 19

20 Structural comparison Precedence Create vs update User Comparison work group 20

21 Precedence To support concise, easily written low power specifications, UPF supports default and generic application of low power design intent. Consequently, multiple low power design intent specifications may conflict with each other. This section defines the rules for resolving conflict in many situations. 1. Logic definition has the highest precedence. UPF does not modify the functional behavior specified in the HDL code. A UPF specification extends the logic definition to incorporate power-aware behavior. The HDL logic specification defines a set of legal implementations. Therefore, the logic definition has the highest precedence. 2. UPF power-aware specification within HDL code has the next highest precedence. To the extent power-aware information can be specified in HDL code, that HDL-resident power-aware specification has precedence over any power-aware information specified outside that code. 3. Inherited power-aware attributes have the lowest precedence. A power-aware intent specification can apply to an object when it is specified directly on the object or an ancestor of the object. (The command definitions specify when a command creates an inheritable attribute.) When more than one power-aware intent specification exists for a given object: 1. If a power-aware intent specification was applied directly to the object, then that specification applies. It is applied directly to the object when the object is referenced in the command explicitly, including through regular expressions that expand to what would otherwise have been an explicit reference to the object. 2. If the power-aware intent specification was applied to an ancestor of the object, then the specification applied at the closest ancestor applies. This includes references to ancestors from the expansion of regular expressions. Precedence ambiguity It is an error if the precedence rules fail to uniquely identify a single power-aware attribute that applies to an object. The closest ancestor with power-aware intent is determined by starting at the object and then tracing back its instance lineage up to the top of the design. The first ancestor encountered in this hierarchical trace back is the closest ancestor. User Comparison work group 21

22 Error semantics Purpose CPF UPF User Comparison work group 22

23 logic independence vs. boolean expression capability Second main concern is having logic in the "side file" that is not in the HDL If the model is similar to test insertion, then XXX User Comparison work group 23

24 Questions Use case support User Comparison work group 24

25 Identification of elements is there a power domain X which has an output Y connected to power domain Z such that the voltage difference is greater than Q. potential for a roadmap capability wildcards name based references between representations of the design referencing collections - making names for collections If the designer during refinement adds, for example, a switch, is there a directive that allows the identification of a complex block or cell that implements the high level description. XXX User Comparison work group 25

26 Multi-Domain Issues I have a net that goes from one to many domains, which domain is the net associated with? If a cell has multiple supplies how are the simulation semantics expressed. Interaction between isolation and level shifting how is order specified? User Comparison work group 26

27 Questions for the Workshop General mapping from high level intent to implementation, not just signals names, guide implementation, how is the element identetified in the implementation to.xxx - Switching strategy Retention specifications - what if the implememtna strategy does not require save and restore. Switching strategy that may require more signals Sequencing requirements - how are they specified. if this does not "belong" in the power format, then how does the implementation "identify itself" to the power specification. User Comparison work group 27

28 Questions for the Workshop Relationship between intent and implementation (and modeling) User Comparison work group 28

29 Next Steps User Comparison work group 29

30 Thank you

31 Reference Material Object model(s) Command lists Concept list Comparison of command groups

32 CPF & UPF Power Domains Herve Menager & Judith Richardson

33 Power domains What UPF CPF Comments Creation of the power domain (create_power_domain) Allow instances and children s to be associated to PD set_pin_related_supply??? Allow instances and children s to be associated to PD CPF allow ports and pins to be associated with PD, CPF seems more powerful Because it allows interface abstraction: -From within one IP block matching a PD, specify which ios interface to a different PD outside. -From a parent level, specify which child s pins are associated to a PD -Implication for buffering, global connections, etc Creation of the power domain No concept of default domain. Instances not assigned don t have an explicit domain Default domain In CPF instances MUST be in a domain.default is the placeholder for non specifically assigned Tool behavior dependency. Talk about own experience User Comparison work group 33

34 Power domains What UPF CPF Comments Shut-off control of the Power Domain Create_power_domain has not condition / expression associated. Purely specifying which instances are in the domain. Involving Create_power_domain to specify shut-off condition Update power switch rule to change shut-off condition CPF is unclear as to why we would have to specify different shut-off between the create_power_domain and the update_power_switch_rule Create_power_switch has a control port that has to be existing explicit signal. So not supporting as a boolean expression Has a boolean expression to control shut-off Create and update in CPF seems to be doing very different things. User Comparison work group 34

35 CPF & UPF retention, isolation, level-shift Ranan Fraer & Gila Kamhi

36 Isolation CPF Commands create_isolation_rule update_isolation_rules UPF Commands set_isolation set_isolation_control map_isolation_cell define_isolation_cell map_isolation_cell User Comparison work group 36

37 Isolation Specification Criteria CPF UPF Comparison General 1) Rule Centric 1) Domain centric UPF has some redundancy, more error-prone Isolation control 1) Expression 1) Signal 2) Triggered by shut-off in 2) Sense drivers/loads 1) UPF ensures visibility of control signals in synthesis 2) CPF expression is Verilog/VHDL or language= indep.? 3) CPF need for #2 is questionable User Comparison work group 37

38 Isolation Specification (cont.) Criteria CPF UPF Comparison Isolated Elements 1) Cross- domain 2) I/O selection 3) Explicit include/ 1)Domain-centric 2) I/O selection 3) Explicit include CPF cross-domain view better supported exclude Clamp_Value H,L, Latch (Default 0) H,L, Latch, Z (Default 0) UPF allows Z (?) value User Comparison work group 38

39 Isolation Implementation Criteria CPF UPF Comparison RTL/CKT sync 1) Map to explicit cells 1) Map to explicit cells 2) Synthesis model for isolation cells 3) Combine w/ level shifting 2) Simulation/Synthesis model for isolation cells UPF supports simulation model CPF allows to combine level shifter Supply of isolation Per isolation cell CKT level Per domain/rule RT level UPF more compact Location From/To only From/To/parent/ Fanout/Automatic UPF more flexibile User Comparison work group 39

40 Level Shifter CPF Commands create_level_shifter_rule UPF Commands set_level_shifter update_level_shifter_rules map_level_shifter define_level_shifter_cell map_level_shifter User Comparison work group 40

41 Level Shifter Specification Criteria CPF UPF Comparison General 1) Rule Centric 1) Domain centric UPF has some redundancy, more error-prone Level Shifter Elements 1) Cross- domain 2) I/O selection 3) Explicit include/exclude 1) Domaincentric 2) I/O selection 3) Explicit include CPF cross-domain view better supported User Comparison work group 41

42 Level Shifter Implementation Criteria CPF UPF Comparison Voltage Threshold A level_shifter_cell definition is supported Voltage threshold when level shifter is required. Default is 0. CPF takes care of this info through level_shifter_cell definition Location From/To only From/To/parent/ UPF more flexible Fanout/Automatic Type 1) H-> L; L->H; or Both With split grounds H- >L may be unclear Control Exclude selected elements Exclude shifting of selected elements CPF more flexible User Comparison work group 42

43 Retention CPF Commands create_state_retention_rule update_state_retention_rules UPF Commands set_retention set_retention_control map_retention_cell define_retention_cell map_retention_cell User Comparison work group 43

44 Retention Specification Criteria CPF UPF Comparison General 1) Rule Centric 1) Domain centric CPF is more compact e.g., in UPF mapping which sequentials to retention cells and which elements to define as retention seq. is verbose in case it is not the same list Retention Elements 1) Domain-centric 2) Explicit include 1) Domain-centric 2) Explicit include No diff Retention Control 1) Restore/Save Expression 1) Restore/Save Signal 2) Sense 1) UPF signal restriction ensures visibility of all signals in synthesis 2) Language-Independence of syntax of CPF expressions needs to be ensured User Comparison work group 44

45 Retention Specification (cont.) Criteria CPF UPF Comparison Supply of Retention No Allows Power/GND nets specific for retention if it is different than primary supply CPF does not explicitly support but supports through define_retention_cell Assertions No explicit support Explicit support of retention related assertions that ensure that save/restore signals are not simultaneously activated User Comparison work group 45

46 Retention Implementation Criteria CPF UPF Comparison RTL/CKT sync 1) Map to explicit cells 2) Synthesis model for isolation cells 1) Map to explicit cells 2) Simulation/Synthesis model for isolation cells UPF supports simulation model 3) Supports the definition of isolation cell User Comparison work group 46

47 Command Comparison CPF Command concepts not implemented in UPF THIS IS A WORK IN PROGRESS your input requested!!! User Comparison work group 47

48 Command Comparison UPF Command concepts not implemented in CPF THIS IS A WORK IN PROGRESS your input requested!!! User Comparison work group 48

49 Backup User Comparison work group 49

50 Isolation Used to isolate signals originating in a design element whose power is shut off from a part of the design which still remains powered on and able to read those signals Through name_format command mapping to isolation cells in SCH is done Syntax : set_isolation outputs_only -domain PD1 -isolation_supply_nets VDDbackup /* can specify a single power net, a single ground net or both. If only a power net is specified, primary ground is adopted for isolation ground and if ground net is specified, primary power is adopted for isolation power */ -isolation_signal cpu_iso /* The signal that causes the specified element to drive its clamped value */ -isolation_sense low /* if isolation signal has the same value as isolation_sense, then the clamp value is driven; otherwise, non-isolated value is driven */ -clamp_value 1 /* The value to which the input or output shall be clamped */ -applies_to outputs /* determines whether domain s inputs or outputs or both are isolated */ User Comparison work group 50

51 Isolation HDL Modeling set_isolation command determines which ports are to be isolated and where in the logic hierarchy the resulting isolation cells are to be created <non_isolated>) if (<enable>== <isolation_sense>) <isolated> = <clamp_value>; else <isolated> = <non_isolated>; The isolation behavior applies only when enable signal contains a deterministic value(0 or 1) and power supply to the corresponding isolation elements in on. If power supply to the corresponding isolation elements is turned off or the enable signal is X or Z, the isolated signal is driven to X User Comparison work group 51

52 Retention Determines which registers in a power-domain need to be retention registers and sets the corresponding save and restore signals for the retention registers Through pre-build retention assertions, verification tools can trigger when the indicated RTL signals are active simultaneously with : restore signal save signal Both restore and save signal set_retention power_domains {PD_a} -save_signal save_a save_sense high -restore_signal restore_a restore_sense low -assert_rs_mutex // (save_a &&!restore_a) == 0 -assert_rs_mutex {reset_a low} // ((save_a!restore_a) &&!reset_a) == 0 -assert_s_mutex {clock_a posedge} // // save_a && (posedge clock_a) == 0 User Comparison work group 52

53 Retention: HDL Modeling Edge-triggered FF with active low cl or negedge reset) begin if (!reset) else end q < =0; q <=d; Retention MPP (UPF) command set_retention -elements {inst_a{ inst_a} -save_signal save_1 save_sense posedge restore_signal restore_1 restore_sense negedge Simulation Semantics/Modeling req save_q; //shadow register save_1) begin //save process save_q <= q; end restore_1) begin //restore process q <= save_q; end Note : The above code is not appropriate for synthesis; it simply provides simulation model for accurate save/restore modeling User Comparison work group 53

54 And More Backup User Comparison work group 54

55 Cell Battery Multiple cells (as in a flashlight) Multiple batteries (ganged for more current) Multiple batteries (ganged for more voltage) + - User Comparison work group 55

56 SPDT SP3T SPST User Comparison work group 56