1 / 47

UPF v1.0 Standard Questions and Clarifications

UPF v1.0 Standard Questions and Clarifications. April 4, 2007. Overview. Unified Power Format Standard has been passionately embraced by semiconductor designers and EDA developers Enthusiastic users have submitted a multitude of suggestions for improving UPF

symona
Download Presentation

UPF v1.0 Standard Questions and Clarifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UPF v1.0 StandardQuestions and Clarifications April 4, 2007

  2. Overview • Unified Power Format Standard has been passionately embraced by semiconductor designers and EDA developers • Enthusiastic users have submitted a multitude of suggestions for improving UPF • Recommend use of a database for issue tracking • Text + graphics support • Prioritization • Taxonomy • Incorporate refinements into next generation working draft with consensus • Review a few example issues

  3. (SAB topics) • N-well, P-well bias supply semantics – factor in corruption conditions, operating modes, and auto-connection semantics. • User defined power states for a domain (or more accurately, the set of nets connected to logic -- power, ground, bias) where the specification is in terms of the power, ground and bias net states. (What constitutes ON, PARTIAL_ON and OFF WRT to voltage levels and voltage thresholds managed via bias nets.) This has implications for level shifter requirements as well as simulation semantics. • A complete semantic specification of PARTIAL_ON. For example, can registers retain state in partial_on? This could be part of previous bullet. • TI has interest in more supply-aware capabilities. • Revisit set_pin_related_supply command. • User-defined specification of corruption values for a type, including random.

  4. (Verif 1 of 5) Will libraries referenced by netlist + UPF be PG-complete? • If PG pins exist in a simulation library, then they must be connected; to do that, the simulator must understand the *type* of the pin, but this information is not available in Verilog libraries today. • UPF will explicitly connect some netlist PG pins but imply connections by pin type to others • PG pins might not exist in a simulation library and, even if they do exist, pin types are not explicitly defined in Verilog • Need a standard definition of library pin types • Secondary problem: PG pins might not exist in a library at all, but synthesis gives a directive to connect regardless, so simulation and verification tools need to infer PG pins and corruption semantics Supply-Retention-VDD VDD Supply-Default-VDD VDD Supply-Retention-VSS VSS VSS Supply-Default-VSS

  5. (Verif 1 of 5) Will libraries referenced by netlist + UPF be PG-complete? Proposed solution: • Verilog pragmas (or attributes) to identify supply pin types for simulation libraries • Simulation and verification tools must auto-connect unconnected PG pins to default UPF supply nets, guided by pin type pragma • If a library model does not have a PG pin but UPF attempts to explicitly connect to one, simulation and verification tools must create the pin and impose default UPF power-down semantics(supply:OFF -> nets in the library component go to X) • Requires Verilog simulation library authors to supply pin type pragmas (or attributes) matching .LIB definitions • Requires simulation and verification tools to implement correct auto-connection • Logic simulation only needs to know what to corrupt • Verification can read the library when needed

  6. (Verif 2 of 5) What power-down corruption semantics apply when netlist has PG pins and UPF supply net? • UPF corruption semantic currently overrides library behavior when supply net is “off” Supply-VDD Component-defined and UPF default power-down corruption??? VDD VSS Supply-VSS UPF default power-down corruption

  7. (Verif 2 of 5) What power-down corruption semantics apply when netlist has PG pins and UPF supply net? Proposed solution: • Redefine UPF semantics: • Default power-down corruption semantics do not apply to any logic simulation library component model that has a PG pin; such models are assumed to implement their own corruption (verification hole if they do not in fact do so) • Default power-down corruption semantics apply to every other component in the circuit • Explicit connection of supply ports on model must be power aware, and default simulation corruption should then not be applied • If the element has a logic simulation model, and if the model has a PG pin, then the model must implement its own corruption semantics

  8. (Verif 3 of 5) How to map the UPFVSS ON == 1 semantic to library components conventionally assumingVSS ON == 0, and functional pins that implementation tools tie to VSS as logical 0? X when VSS is “ON”! Supply-VDD: OFF:0, ON:1 VDD OUT = VDD & ~VSS ? (IN1 & IN2) : X VSS Supply-VSS: OFF: 0, ON:1 • No problem if supply network is either entirely defined in UPF or entirely defined in netlist • Consider use of value conversion table as an option to connect supply net, with simple default behavior • Flow consideration: to create the table, must know the correct translation • Synthesis must emit the model; could require user to provide conversion table • Conversion table may be difficult to verify in the unrestricted, general case

  9. (Verif 3 of 5) How to map the UPFVSS ON == 1 semantic to librarycomponents conventionally assumingVSS ON == 0, and functional pins that implementation tools tie to VSS as logical 0? • Consider assume/enforce industry conversion to UPF semantics for library models, and implementation tools should emit a translation function when it uses VSS as logical 0. • Alternatives: • UPF change • Industry convention change • Implementation tools understanding/mapping of library cell power-down functions • Implementation tools may assume ground is logic zero; use Tie-Lo cell?

  10. (Verif 4 of 5) How to handle redundant constructs in UPF + netlist? Post-synthesis netlist implements retention registers and isolation cells, but UPF also directs (re-)creation of same. Is set_retention a constraint or a directive? Synthesis emits a constraint that implementation tools must satisfy. Constraint is interpreted as: check to see if it exists, if not then implement. Simulation: not interpret as a constraint, interpret as the intended form of circuit modification – i.e. implement this. Compare to assertion – verification fails if it triggers, and implementation tools can safely assume that it never happens and optimize accordingly.

  11. (Verif 5 of 5) UPF retention constructs can't capture real clock-low/clock-high retention register behavior • How can the current model verify gate-level netlists against RTL with retention behavior specified via UPF, since real gate-level behavior is very unlikely to match UPF specification? • This is a problem for RTL+UPF as well as netlist+UPF • Accurate model requires UPF extension and register inference in the logic simulator • Consider generic model using generic simulation language, or very complex syntax for model • Can’t verify at RTL if not have defined simulation behavior • Expect rigorous use of “macro”, where designers simultaneously specify cell and simulation model that are self-consistent • Legal operating conditions, but save and restore protocol can’t be captured using existing command syntax; requires knowledge of related clock signal • Possible solution: supply full retention model; this may require simulation and verification tools to do register inferencing and mapping; need synthesizable simulation model of generalized retention register

  12. (Synth 1 of 5) Semantic Clarifications • 6.6 connect_supply_net • A supply port can only be connected once at each level of logical hierarchy. Once connected, subsequent attempt to connect to the same supply port, from either the already connected supply net, or from another supply net, is an error. This restriction is required to have a unique mapping from a net segment in the final netlist to the corresponding supply net. • RM-26 • The –port and –pin options in connect_supply_net are ambiguous. There seems to be no concept of “pins” in simulation. Also, there is not a clear definition of what a “library cell” and how it differs from is. An AND gate would have a verilog model for simulation. • So I think we need to have only one of them, and they refer to interface points on verilog models, vhdl entities, or library cells. • Can -port and -pin be merged into one option (say –port) in an errata doc? • Since most simulation tools have no concept of pins, the –pins option should not be there. To make the so called ‘pin-specific’ connection to a power pin on a mapped cell, -ports should be used, and the implementation tool shall recognize them correctly.

  13. (Synth 2 of 5) Semantic Clarifications • 6.9 create_power_switch • The definition of when a switch is “on” seems to be confusing. It currently says: • The switch is on if the value on the control port(s) equals an “on” state Boolean expression; • Would the following be better? • The switch is in one of the “on” states (and thus is on) if the Boolean expression corresponding to the on_state is evaluated to be TRUE.

  14. (Synth 2 of 5) Semantic Clarifications • 6.33 upf_version • More clarification about this command is needed: • When this command is used in a UPF file with the version string specified, it is saying that the UPF commands in this file has been written conforming to the syntax and semantics of the specified version. Tools supporting this or newer version should be able to read this UPF file. • If any commands in the UPF file does not conform to the syntax of the upf_version, tools should give errors.

  15. (Synth 3 of 5) Semantic Clarifications • 6.15 load_upf • When -version is specified, one can only easily check that the UPF file conform to the version as specified by -version. Tools have to interpret the loaded UPF file based on the latest version supported by the tools, since supporting multiple interpretations is too much an overhead. • By conforming, we mean: • The upf_version string command in the UPF file matches exactly the version specified by -version of this command. • It is expected that all commands in the file conform to the syntax of the specified upf_version. • 6.22 save_upf • Perhaps it should be clarified that in the written UPF file, the intended UPF version will be recorded by having "upf_version version_string" at the beginning of the UPF file.

  16. (Synth 4 of 5) Semantic Clarifications • 6.25 set_isolation • It probably does not make sense to allow nets or design elements (instance of modules or library cells) in -elements list. Pins or ports should be sufficient. • Also, we need to clarify the meaning of the input/outputs of a power domain. Suggestion: • Output of a power domain is the output ports of the root cells of the power domains • Input of a power domain is input ports of the root cells of a power domain • Output/inputs refer to the actual directions rather then what was defined in RTL • 6.27 set_level_shifter • Also need to clarify the meaning of input/output of a power domain, • It makes more sense to allow only pins/ports in the -elements list.

  17. (Sim 1 of 4) UPF Questions • In create_power_domain in UPF spec, it says that the list is specified regardless of the –scope command and later it says that –scope command specifies the current scope for this command. This is confusing. • Isolation_sense is missing on in set_isolation_control argument description. So it is not clear what the default value is. • Will the upf_version command used down the hierarchy specifying a different upf version will overwrite the upf_version for that file? • In command set_scope “instance” is not optional which means if it is called with no instance, it should be an error. But the UPF 1.0 says that if it is called with no instance, the scope is set to the top level design. • In create_power_switch command, it says that the switch is either on or off and does not talk about the partial state. • For connect_supply_net, it should return “null” like other commands instead of ‘0’ (Seems like typo)

  18. (Sim 2 of 4) UPF Questions • Which port vct applies to? • For merging power domains what happens to isolated power and retention power. • If power and ground net have different states like one is on and other is partial, what happens? • In bind_checker, how do we specify the net_name for different elements? • Is the element list, in bind_checker based on current_scope? • In set_power_switch why should the control port be an existing one (Are we talking about the net which connect to it)? Also how do you add output_port since it already exists after using create_power_switch?

  19. (Sim 3 of 4) UPF Questions • In all the map commands when you give list, then which cell is going to be used? • What is specified by –port option in map_isolation_cell command? • If –elements list is not specified in map commands then the default should be whatever is specified in set command? • Why is isolation_sense semantics different from save/restore sense ? • What kinds of checks need to be performed on set_design_top option instance? • If both –resue and –resolve are specified, then it should be an error if –resolve is not the same as previously specified when creating the supply net.

  20. (Sim 4 of 4) UPF Questions • Will the scope name in scope_option be always given from root or it will be given from current scope. • Named states for on and partial on states are derived from input port state. Where do we find the named states for off and error states. • In create_power_switch, what does it mean by “it is an error if specified control port does not exist”. Does it mean the net connected to control port? • In set_power_switch, if we are adding more control ports, then more ack ports would be needed, assuming ack ports correspond to control port since there are multiple of ack ports and only one output port. • We say that all the map commands and set_pin_related_supply command are not relevant to simulation. I am not sure if a user has a library model of say isolation cell, then how he will use it. Same is the issue with the set_pin_related_supply

  21. (UPF) Feedback • Class 1: clarification of content to match my understanding of agreements: • Class 2: Suggested additions to enhance clarity (next version) • Class 3: Topics for additional consideration **Gary’s feedback** • So far I have just made it through p 45 for this level of comments. • GD-1 • Page 1, line 1, class 3: tcl variable scoping • Do the semantics of read UPF include any tcl variable scoping rules? When you start to read a file, do you have the option (like you do with shell command files) to choose to source a file or read a file? In one case it is as if the file were included in the “sourcing” file. In the other case, the state is saved, the file read, and then global variables are restored. • GD-2 • Page 14, line 55, class 1: Add information about the hierarchical aspect of names. • b) The name of the power domain shall not be the same as instances and ports in the same scope. • We should be clear on which names are global, and which are hierarchical. Is x/x/foo different from x/y/foo, and do power domains have hierarchy? • GD-3 • Page 15, line 27, class 2: precedence of regular expressionsIf 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. • Is it an error for a command to set a set of attributes with one regular expression, and then set, using another regular expression, where some elements overlap between the regular expressions? If not, is there a defined precedence? • GD-4 • missing, class 3: Semantic Rules • Generally, calling out the semantic rules and providing labels (numbers) in the standard LRM will be useful for validating errors.

  22. (UPF) Feedback • GD-5 • Page 17, line 23, class 1: The supply state itself consists of two pieces of… • “During simulation, each supply port and net maintains two pieces of information: a supply state and avoltage value. The supply state itself consists of two pieces of information: an on/off state and a full/partialstate. The on/off state of a supply port and net is asserted when it is connected to a supply pad that is on andit is de-asserted when there is no connected path to a supply pad or the supply pad is off. By default, supplypads are on; however, they may be turned off to model off-chip switches using a language-specificsimulation control. The full/partial state represents the conductance of a switch along the supply path; it isasserted when the switch is partially on, and de-asserted when it is fully on or fully off. The voltage valueand full/partial state of a supply net are valid only when its on/off state is asserted. The voltage value is thesame as the voltage of the connected supply pad.” • Suggest instead something like: • During simulation, each supply port and net maintains two pieces of information: a supply state and avoltage value. The supply state itself consists of two pieces of data: the specified power state (Footnote? The specified power state takes the two LSB of the 32 bit field and encodes them to prove three enumerated values: ON, OFF and PARTIAL_ON) and a reserved set of bits whose values have not been specified. The state of a supply port and net is ON when it is connected to a supply pad that is ON. The state of a supply port and net is OFF when there is no connected path to a supply pad or the supply pad is OFF. By default, supplypads are ON; however, they may be turned off to model off-chip switches using a language-specificsimulation control. The PARTIAL_ON state represents the conductance of a switch along the supply path; it isasserted when the switch is PARTIAL_ON. The voltage value is valid only when the state is ON. The voltage value is thesame as the voltage of the connected supply pad. • The rest of this section needs similar updates. • GD-6 • Page 25, line 10, class 2: Add a table: Command argument conventions - HierarchyAn example of naming and merging in a hierarchy will be useful. Can power domain names be hierarchical? I assume that they are defined in a scope and then can be referred to in a scope. This part can use a clarifying example.

  23. (UPF) Feedback • GD-7 • Page 25, line 10, class 2: Add a table: Command argument conventions – regular expressions • A treatment of regular expressions in the command argument list -- where they are assumed to be expanded. If commands that can take single pins or ports can use a regular expression, what happened with multiple matches, can domains be referred to by regex, etc… • GD-8 • Page 25, line 10, class 2: Add a table: Command argument conventions – pins and ports • A treatment of pins and ports, that pins are a subset of the generalization called ports, that pins are only used on library objects, things like this… • GD-9 • Page 25, line 5, class 3: Groups of commands • A list of commands that effect each class of operations or a table of the commands as rows and functions as columns would act as a useful introduction • Some commands define the structure, others modify the interpretation, some would be packaged with IP, others would be specified with use. I am thinking specifically of the retention points, identified with the IP, and implements with the specific use. We started discussing this, reviewing the commands and separating them out by sequence of specification and refinement; we should continue this. • RM-1 • Page 26, line 44: • Current: • Return the fully qualified name (from the current scope) of the created port or a null string if the port is created. • Proposed: Return a 1 if successful or a 0 if not. • RM-2 • Page 26, line 52: • Since supply states are now inherited from supply port, and we allow multiple ports to drive a supply net based on resolution function, how do we resolve states coming from different ports? This is not specified properly anywhere.

  24. (UPF) Feedback • GD-10 • Page 28, line 12, class 3: 6.5 Bind Checker • -module checker_name The name of a SystemVerilog module containing the verification code. • It seems that it would be very useful to generalize this beyond SystemVerilog; other modules for example those in SystemC would have similar utility. • RM-3 • Page 32, line 36-37: • Current: • This scope is the current scope for this command; it defines the domain boundary within the logic design. .. • Proposed: Remove it • RM-5 • Page 35, line 17: • Current: • The create_pst command …. of supply nets. • Proposed: • The create_pst command …. of supply nets. This command can only be used when the current scope is at the top-level design instance. • GD-11 • Page 35, line 23, class 3: PST semantics and use in simulation • The power state table has no simulation semantics. It is tool-dependent error if an illegal (unspecified) combination of states occurs. • The treatment of imported IP and the combination of power state tables is a place for valuable work. The semantics need to be defined in combination with the merge power domain command. • RM-6 • Page 38, line 25: • Current: The name of the supply net holding the logical net name; this shall be a simple (non-hierarchical) name. • Proposed: The name of the supply net; this shall be a simple (non-hierarchical) name. • RM-7 • Page 38, line 29: • Current: The scope where the logical net name is defined. • Proposed: The specified scope for the purpose of getting the logical net name.

  25. (UPF) Feedback • RM-8 • Page 38, line 34-37: • Current: • The get_supply_net command provides the ability to find the logical net name associated with a supply net in the specified domain for the specified scope. If -domain is not specified, the power domain of the current scope is used. If -scope is not specified, the scope of -domain is used. If both -scope and -domain are not specified, the current scope is used. • Proposed: • If -domain is specified, the get_supply_net command returns the logical net in the specified scope that is connected to the specified supply net in the specified domain. If -scope is not specified, the scope of -domain is used. If this supply net does not exist in the extent of the power domain at the specified scope, a null string is returned. • If -domain is not specified, the command returns the net with the specified name in the current scope or the scope defined by –scope. • Sec. 6.15 load_upf • RM-9 • Page 39, line 14: • Current: The version of upf_file_name. See also: 6.32 • Proposed: The UPF version according to which the loaded UPF file will be interpreted. • Sec. 6.16 map_isolation_cell • Page 40, line 6-11: • RM-10 • Current: • map_isolation_cell isolation_name • -domain domain_name • [-elements list] • [-lib_cells list] • [-lib_cell_type lib_cell_type] • [-lib_model_name lib_model_name {-port {port_name net_name}}*] • Proposed: • map_isolation_cell isolation_name • -domain domain_name • [-elements list] • [-lib_cells list] • [-lib_model_name lib_model_name {-port {port_name net_name}}*] • I wrote my concerns with this one separately in the email...

  26. (UPF) Feedback • Sec. 6.17 map_level_shifter • RM-11 • Page 41, line 5-8: • Current: map_level_shifter_cell lever_shifter_name -domain domain_name -lib_cells list [-elements list] • Proposed: map_level_shifter_cell lever_shifter_strategy_name -domain domain_name -lib_cells list [-elements list] • RM-12 • Page 41, line 11-12: • Current: lever_shifter_name Identify the isolation strategy specified in a set_level_shifter command (see 6.26) for the specified domain. • Proposed: lever_shifter_strategy_name Identify the level shifter strategy specified in a set_level_shifter command (see 6.26). • Page 41, line 26-27: • RM-13 • Current: If –elements is specified, the elements shall be in the domain. When –elements is not specified, this strategy • applies to all elements requiring level shifters within the power domain. • Proposed: If –elements is specified, the elements shall be in the domain. When –elements is not specified, the mapping applies to all elements covered by the level shifter strategy within the power domain. • Sec. 6.19 map_retention_cell • RM-14 • Page 43, line 6-11: • Current: map_retention_cell retention_name -domain domain_name [-elements list] • [-lib_cells list] [-lib_cell_type lib_cell_type] [-lib_model_name lib_cell_name {-port port_name net_name}*] • Proposed: map_retention_cell retention_name -domain domain_name [-elements list] • [-lib_cells list] [-lib_model_name lib_cell_name {-port {port_name net_name}}*]

  27. (UPF) Feedback • GD-12 • Page 44, line 27, class 3: Merge Power domains • “The merge_power_domains command merges two or more existing power domains into a single, new power domain. The merged domains can no longer be referenced.” • There was some discussion of the potential for aliasing the power domain names that have been merged rather than eliminating them. IP Core based validation code may include modules that need to reference the power domains of the IP, and after the power domains of the IP are merged into system level domains, it appears that the sub domain would not be available, or the new name would need to be discovered. This use case needs more consideration. • Sec. 6.25 set_isolation • RM-15 • Page 48, line 41-49: • Current: • –isolation_supply_nets can specify a single power net, a single ground net, or both. If only an isolation power net is specified, then the primary ground serves as the isolation ground. If only an isolation ground net is specified, then the primary power net serves as the isolation power. • At least one of -power_net or -ground_net shall be specified, unless -no_isolation is specified. If only • -power_net is specified, the primary ground net shall be used as the isolation ground supply. If only • -ground_net is specified, the primary power net shall be used as the isolation power supply. If both are • specified, then these options specify the supply nets to be used as the isolation power and ground nets. • Proposed: At least one of –isolation_power_net or –isolation_ground_net shall be specified, unless -no_isolation is specified. If only an isolation power net is specified, then the primary ground serves as the isolation ground. If only an isolation ground net is specified, then the primary power net serves as the isolation power. • Sec. 6.26 set_isolation_control • RM-16 • Page 50, line 29-31: • Current: Excepting the set_isolation_control command is executed within the current scope, and the addition of the – • location option, the semantics here are equivalent to having specified the isolation control signal and sense • with the set_isolation command • Proposed: Delete!

  28. (UPF) Feedback • RM-17 • Sec. 6.27 set_level_shifter • Page 51, line 5: • Current: set_level_shifter lever_shifte_name • Proposed: set_level_shifter lever_shifter_strategy_name • RM-18 • Page 52, line 11: • Current: lever_shifter_name Level shifter strategy name (used only for reporting). • Proposed: lever_shifter_strategy_name Level shifter strategy name. • RL-1 • set_net_related_supply **Rolf’s request** • Purpose Define the related power/ground pair for a signal port/net in a domain • Syntax set_net_related_supplydomain_name [-portslist] [-netslist] -related_power_netsupply_net_name • -related_ground_netsupply_net_name • Arguments domain_name The domain where the default supply nets are to applied. • -portslist A list of ports that is to have a related power/ground supply defined. • -netslist A list of nets that is to have a related power/ground supply defined. • -related_power_netsupply_net_name The supply net to which the pin is related. • -related_ground_netsupply_net_name The supply net to which the pin is related. • Return value Return 1 if it succeeds and 0 if it fails. • The set_net_related_supply command provides the ability to define the related power and ground pins for a signal or port in a power domain. This command overrides the default corruption semantic of the signal net connected to the port. The signal net shall derive its corruption semantic from the related supply nets. • Input port: If either of the related supply nets are OFF the signal port and the driven net shall be cor­rupted. • Output port: The related supply nets of an output port can be used to infer isolation and or level shifters. • Nets: If related supply nets are defined on a net, they shall be inherited by the connected ports, unless specified by via the -port option or specified by a set_related_supply_pin command (see 6.28). • Syntax example: • set_net_related_supply domain_A -port {In1 Out2} -net {net1} -related_power_net VDDX -related_ground_net VSSX

  29. (UPF) Feedback • RM-19 • Page 54, line 31: • Current: retention_name Retention strategy name (used only for reporting). • Proposed: retention_name Retention strategy name. • RM-20 • Page 55, line 1-4: • Current: At least one of -power_net or -ground_net shall be specified. If only -power_net is specified, the primary ground net shall be used as the retention ground supply. If only -ground_net is specified, the primary power net shall be used as the retention power supply. If both are specified, then these options specify the supply nets to be used as the retention power and ground nets. • Proposed: At least one of –retention_power_net or –retention_ground_net shall be specified. If only –retention_power_net is specified, the primary ground net shall be used as the retention ground supply. If only –retention_ground_net is specified, the primary power net shall be used as the retention power supply. If both are specified, then these options specify the supply nets to be used as the retention power and ground nets.

  30. (UPF) Feedback • RM-21 • Page 55, line 12-14: • Current: • If -save_signal is specified, then -restore_signal shall be specified. If -save_signal is not specified, then • -restore_signal shall not be specified. If the save and restore signals are not specified, then they shall be • specified in a set_retention_control command (see 6.30). • Proposed: The save and restore signals of retention registers shall be specified in a set_retention_control command (see 6.30). • RM-22 • Page 56, line 13: • Current: retention_name Retention strategy name (used only for reporting). • Proposed: retention_name Retention strategy name. • RM-23 • Page 56, line 41-43: • Current: Excepting the set_retention_control command is executed within the current scope, the semantics here are equivalent to having specified the retention control signals, senses, and assertions with the set_retention command. See also: 5.3.2. • Proposed: Delete! • Page 91, line 25, class 1 or 2: Table B1—UPF logic value VHDL mapping • This table needs to be updated to reflect the change from the separate bit access of supply_net_type.state(0) to reflect the change to the enumerated value of ON, OFF, and PARTIAL_ON

  31. (UPF) Feedback • ER-sim • ----------------------------------------------------------------------- • **Deferred Jan 30th issues (kept together for clarity in future resolution)[any page/line #s reference the Jan 23rd draft]** • I'm OK with your clarification of the boolean operators permitted in 6.  We had discussed the semantics of an error if a control port is something other than 0 or 1.  Although we must allow for this as an initial state, but simulation tools can handle that. • For multiple driven nets, I agree that the implementation semantics are null.  But, the simulation semantics specify the situations that simulation tools can handle when switching is distributed.  If the users create a situation that isn't supported, they'll see an error or warning. • On PSTs, other people have pointed out that PSTs are a system-level specification.  The UPF spec provides no provisions nor defines any semantics for merging PSTs.  If a tool wishes to support mutliple inter-related PSTs, then that is currently outside the definition of UPF.  They can do it, but UPF requires them to create each independently and to re-specify overlapping state information.  I agree with your methodology recommendation of specifying the states on ports and not nets. • I attempted to specify the ability to define a "hierarchy" of PSTs.  But, that didn't make the cut.  I think it would be beneficial to allow this or some other way of explicitly capturing relationships between PSTs (merging).  The user would specify a PST.state in the "upper level" PST row instead of a port or net state.  This would then allow users to create the relationships without reproducing redundant port/net state information in 2 or more PSTs.  Something we can look at providing in the next version. • -Steve Bailey

  32. (UPF) Feedback • My comments are interspersed below. Arturo •  Answers to the questions directed at me are embedded below. • BTW, the -lib_cells and -lib_cell_type issue would be a relatively substantive change.  I wouldn't want to attempt to get that in during the review period.  But, we should come to agreement and get that fixed as soon as possible after the Accellera board approves and we move to the next step. • I don't think the other ones (based on my response/understanding) require any changes to the spec right now.  We could add clarification of the limited boolean expressions for create_power_switch later -- primarily because I think the limitations are inherent in what is being specified so there's no pressure to do it immediately.  Similarly, we could add clarification for the implicit net in the map_isolation_cell case.  Again, I'm not worried because I can't think of any other way it could be done. -Steve Bailey • Hi Joe, Ed, Andrew, Steve, • (1) To Ed: • I agree with you that the current wording in the document for –current_scope is misleading. We proposed a different wording in the feedback doc, please check. We also think that –include_scope if a better name. • SIM-1 • (2)Question for Andrew: • Get_supply_net: Can we specify that this command returns the logical net instead of logical net name? Since it is going to be used like get_nets. The return value on the screen will be the name of the net of course. • SIM-2 • (3) Question for Steve: • Since supply states are now inherited from supply port, and we allow multiple ports to drive a supply net based on resolution function, how do we resolve states coming from different ports? This is not specified properly anywhere.[SAB] Is there something missing from section 5.1.5?  Note, Arturo wrote this section, I reviewed and thought it was complete. • Unresolved:  Net can be connected only to a single output. • one_hot:  Multiple outpus can be connected.  At most, one of the outputs may be ON at any particular time.  (Paragraph starting on line 34 provides more detail.  What is missing?) • parallel:  Multiple outpus connected to supply net.  Any number of outputs may be ON at a particular time but they shall all supply the same voltage value.  (Paragraph starting at line 40 provides more detail.  What is missing?)

  33. (UPF) Feedback • Section 6.11 create_supply_net • An argument/option was added to specify the resolution (default is unresolved as specified in 5.1.5 -- should be repeated here but at least it is specified in the doc). • [AS] I believe Renu’s question may have nothing to do with the resolution function. Note that other than the unresolved restriction, which implementation tools may enforce, resolution is a concept applicable only to simulation. Let me restate the question: Consider two or more ports, each of which includes a power state specification (PST). If these ports are connected together (via one or more nets) what are the power-state semantics of the resulting (interconnected) network? Can the PST’s be merged? If so how? • My personal bias – power states are global so the simplest (and safest) thing would be to make it an error to specify PST on two or more interconnected ports. Several options to relax the above are possible: for example, we could choose to allow merging of identical PST’s or PST’s that differ only in the name – but not on the voltage values or states. Etc… • Typically, it’s better to start out with a more restrictive set of rules. Restrictions can always be relaxed at a latter time without creating backward compatibility issues. • [RM] Actually, I am not thinking about the case where there are multiple drivers. But just states are put on different supply ports, lets say one is the driver and the other is the load of the same supply net. Which one is valid? How do we resolve conflicts? • [SAB2] Doesn't this get into mixed signal simulation?  This is a topic we haven't addressed at all.  I don't know of anything similar in logic simulation today.  Perhaps the closest is timing gate simulation with SDF annotation where a tool outside the simulator determines the timing delays based on wire length, capacitive loading, etc.  I don't see this as an issue with what we have today.  If more accurate modeling of the voltage levels, voltage swings, etc. are required, we'll need a much more thorough analysis and solution then just this one aspect.

  34. (UPF) Feedback • SIM-3 • (4) Question for Steve: • Map_isolation_cell and map_retention_cell commands: • - lib_cell_type: Does this refer to a specific lib-cell attribute? This is not defined anywhere. Does this require a change to the Liberty standard? This option is not properly defined and we suggest to remove it.[SAB] Yes, it was to refer to a cell attribute in the implementation library.  To further explain the background, the lib cell model provides the functional specification.  There can be a 1:Many mapping between the functionality and the implementation cell.  The attribute would be common to all implementation cells that share the same functionality.  The implementation cells differ only on other characteristics (timing, loading).  It was expected that the synthesis tool would choose the best one based on these other criteria. • [RM] My question  remains, what attribute in .lib are we referring to? • [SAB2] I assumed there must have been an existing Liberty attribute that would be obvious to use.  Your question indicates there isn't one.  So, we'll need to add that information to the standard. • - lib_cells: How does this option interact with -lib_cell_type? Are they both needed? Does one have precedence over the other? I would suggest to have only -lib_cells and remove -lib_cell_type.[SAB] I see where you are going with the question.  I cannot say.  This question needs to be put to the users.  I don't recall -lib_cells being part of the consideration and it might be left-over from previous contemplated usage.  I would need to defer to someone who recalls or the users to determine if both -lib_cell_type and -lib_cells are required. • You are running out of colors, and not wanting to add any more, I will just say that for Q4, I believe the intention for the -lib_cell_type option wrt to retention cells was to use the power_gating_cell attribute in liberty. There isn’t really anything comparable for isolation cells, there is an attribute to identify and isolation cell, but nothing else that I am aware of. [Andrew] • -lib_model_name: I am not sure how we can give the net-name for each port on the lib_model, since there is one net in the design that needs to split into 2 parts before inserting the iso cell. So we don't have a net name for the new net (its tool decided).[SAB] You are correct for isolation.  The port being isolated has an implicitly created net (connects the original port to the input data port of the iso cell).  We can tighten the semantics here by specifying the port name is used to connect to the input of the isolation cell where the port name refers to the implicit net that is created since ports can't be directly connected.  The original port itself must be connected to some logic net, the user can make that explicit connection as well as the net already exists.  I don't think there is any other reasonable way to approach this.

  35. (UPF) Feedback • SIM-4 • (5) Question for Steve: • Map_retention_cell has same issues as map_isolation cell.[SAB] Yes for -lib_cells and -lib_cell_type. • No for the port connections.  There aren't any implicitly created nets that the user needs to explicitly connect.  If they need to do an explicit mapping, then it is assumed they know the clk/enable, reset, and other control signals.  We don't change the original register's connectivity (we aren't sticking a new driver in between the object and everything that uses it).  We only save and restore its contents. • [RM]:  There is no easy way for the simulator to know exactly what net will be connected to the reset/set pins on the lib cell. It almost needs to do a mapping to figure this out and there is no guarantee this will match what synthesis will do anyway. • [SAB2]:  The simulator does not connect the reset/set pins on the library cell, the synthesis tool does.  The simulator needs to know what to connect to the simulation model ports.  While it is possible for a simulator to do a front-end synthesis and figure it out (at least under certain situations such as a required port naming convention), the reason for requring the port mapping information is so a simulator is not required to do that -- we've avoided requiring simulators to do synthesis.  The user is burdened with that requirement if they are going to do an explicit mapping and want the simulation to use a model that reflects the specific retention cell (type) behavior that will be used. • I see no other option to do this.  If the user wants an accurate verification of what they are telling synthesis to use, they have to provide a model that provides that accuracy and information as to how to connect it to logic nets in the design.  If we do not do this, then we fail at ensuring the UPF simulation matches the synthesis. • BTW, Jim and I had a similar discussion yesterday related to the set_pin_related_supply command.  We'll need more discussion about that command as well.  It seems that set_pin_related_supply may be OK for synthesis.  The concern is that the semantics are under-specified for simulation -- that simulation may need more information to ensure that the existing simulation model for the hard macro is simulated with expected power-aware behavior.  The issue comes down to:  The library implementation cell of the hard macro is power aware.  The existing simulation model is almost assuredly not power aware.  Therefore, while synthesis is happy to know nothing about the internals of the cell, it is likely that the user needs to augment the non-power aware HDL model with additional UPF information to ensure the power-aware verification matches.  Synthesis would ignore the additional information (as with the HDL model, if the user gets the behavioral specification wrong -- inconsistent with the cell's real behavior -- that is the user's problem.  UPF or tools supporting UPF wouldn't be able to tell the user that there is a problem.

  36. (UPF) Feedback • SIM-5 • (6) create_power_switch: what kind of Boolean operations do we allow? (Comment from Arturo):   • Page 33, create power switch. • -        The Boolean function needs to be restricted to be only the following operators: • o        !     => negation • o        &    => logical conjunction • -        Any other operator shall be an error.[SAB]  Unfortunately, we didn't understand what was underlying Arturo's comment about constant boolean function (if I recall correctly) and couldn't get it clarified in time.  Now that I have time to think this over, I believe I understand Arturo's restrictions.  The boolean function is always in terms of the control port(s).  On, partial-on, off and error states as well as the ack port value can always be specified simply as the current value of a single (perhaps multi-bit) supply port as in a one-hot encoding:  00100.  Or as a combined logical evaluation of multiple control ports (presumably of a single bit, but it isn't required to be single bit), using the same example with positional naming:  !cp0 & !cp1 & cp2 & !cp3 & !cp4. • The only problem is that if you wish to capture as error states when any control port bit is undefined (X or Z), then I don't think this restriction will suffice.  For example, if you want to explicitly catch 00x00 as a named error state, wouldn't you need to write the expression as (!cp0 & !cp1 & (cp2 === X) & !cp3 & !cp4)?  So, if we added the equivalency operator, I think we would cover everything. • [AS] I believe you understood the main gist of my comment. Let me clarify. • I believe that the intent of the switch function is to specify explicitly the conditions under which the various (internal) switches are conducting, in a tabular form. For example, consider a 3-transistor power switch with 3 inputs: A, B, and C. The ON conditions could be written as: •    !A & !B &  C •    !A &  B & !C •     A & !B & !C • These represent a one-hot mapping of the inputs, written in tabular form as: • A  B  C •    0  0  1 •    0  1  0 •    1  0  0 • But, the same functional behavior can be specified using the OR function: A | B | C. • The latter specification is indeed more succinct, but it also tends to hide much of the intent. Is it a 3-transistor power switch, or a 3-input OR gate controlling a one transistor power switch? • The former (tabular) mapping makes it possible for tools to better determine the user’s intent – and perhaps even synthesize the corresponding switches. This might enable more analysis and automation than the “catch-all” option of mapping the switch to a cell. A similar reasoning could be applied to the error states. • An additional concern is that the more general Boolean functions might lead to overlapping ON and ERROR states. The standard does not currently specify how to deal with such ambiguity. A pedantic reading of the text might conclude that an overlap between ON and ERROR states is always resolved as on ON – which is just a coincidence of how the text is written, and certainly not the intent. If we restrict the syntax to negation and conjunction, users will not be able to unwittingly specify overlapping states. And, if they do, we should explicitly state which state takes precedence: On or Error. • As for specifying X or Z as error states on the control inputs of a switch, that is unnecessary as Section 5.1.2 already states: • “If any of the control signals is X or Z, or the control signals match one of the error-state Boolean functions, the behavior of the power switch is undefined; in this case, implementations may issue a warning or an error.” • Hence, X or Z is by default an error condition so it’s not necessary for users to specify that as an error state. The conservative implementation is used to help users avoid extraneous states in the power distribution logic. In this context, an X/Z means a simulation unknown; not a don’t-care.

  37. (UPF) Feedback • **Deferred Feb 14th issues from John Biggs (kept together for clarity in future resolution) [any page/line #s reference the v0.9/d4 draft]** • JB-1 • Actually I tried to create a UPF file which describes the power schema intrinsic to the design of an ARM core - ie just the implementation independent parts of a complete UPF file. You could think of these as the power constraints inherent in the IP.Specifically this seems to boil down to:  o create_power_domain  o set_isolation  o set_retention  o create_pstAll the rest of UPF seems to be extrinsic to the design - ie it is implementation specific as so is created and applied during the implementation of the IP.Here is some more feedback: Problems:o The Power State Table is to implementation specific.   - The power state table uses port_states which are defined as absolute voltages - unfortunately this is implementation specific and so should not be specified in the design.   - We need to allow for an abstract "not off" state so that you can declare a things like "CORE=OFF & RAM=!OFF“ with out having to specify the RAM voltage.   - Having the ability to declare "illegal states" might     be more concise eg illegal_state(CORE=!OFF & RAM=OFF)SAB>  I also believe the PST capabilities can be beefed up.  I hadn't thought of an abstract state (ON, essentially ON with undefined voltage level).  However, I have thought that we need to support hierarchical PST specification or have a way of specifying relationships between 2 or more PSTs.  I think IP providers could benefit from that ability.  For example, ARM could define a PST for a core and then "export" the states of the core's PST so that a system integrator could define the system states, in part, by reference to the ARM core PST states.  Abstracting the voltage levels would add more value.Which, brings me to a question.  Would you really want to define no voltage level?  Or would it be more appropriate to define a constraintwhich would be a voltage range?  If it all depends on the actual implementation, then even a voltage range would likely be too much information.

  38. (UPF) Feedback • o The set_isolation command should specify the power net used to power the clamp as again this is implementation specific.   - All we really need is some form of assertion/constraint which says how a signal should be clamped if it is clamped.   - Can we move the isoltaion_power_net part of set_isolation to the set_isolation_control command?   - Also it would be nice to be able to say everything is clamped LO *except* these few signals which are clamped HI.       Unfortunately this is specifically declared to be an error as the same elements have been specified twice.SAB>  In this case, I had made assumptions on usage/methodology. Perhaps I was the only one making such assumptions.  My assumption is that the IP provider would define supply ports for the isolation power and ground supplies and then connect supply nets to them.  The set_isolation command would then reference those nets.  The IP provider would specify everything they need to specify and leave it to the system integrator to connect the actual supplies to be used for isolation to the supply ports.On the 3rd bullet, it is definitely the intent to be able to do what you are asking.  In reading the set_isolation command text, I think the problem is that the error check is too rigid and doesn't allow this situation ("It is an error if multiple isolation strategies specify the same design element, pins, ports or nets.")  But, if you look above this statement, the draft also says:  "If there are multiple isolation strategies for one domain, then, per strategy, -elements can be used to specify the elements to isolate.  If -elements is specified, the elements shall be in the domain_name.  If -elements directly specifies a port by name (not implicitly, by specifying the port's instance or an ancestor of that instance), then the isolation strategy shall apply to that port regardless of whether the port's mode matches the one specified by the -applies_to option."  This almost captures the intent, but is too narrowly defined.In any case, we can revisit the wording to clear up any confusion in this area.  I'm confident that everyone will agree that the intent is to allow you to do what you want to do.

  39. (UPF) Feedback • Questions/comments:JB-3 •   o Does merge_power_domain dissolve the clamps between the merged domains?SAB>  Literally, no.  "All strategies and mappings defined for the list of power domains shall be applied prior to the merge ..."However, if implementation tools do not optimize away isolation cells made irrelevant by a merge_power_domain command, then they wouldn't be doing a very good job.  Verification (simulation) tools could also optimize them away but the pressure for simulators to do it is less than for implementation tools.  The benefit in simulation would be slightly (perhaps imperceptible) faster simulation.I don't see this any different than optimizing away unneeded level shifters and isolation cells based on PST specification.  o I note that the UPF spec allows switches to be either inside or outside the power domain - this is not obvious and I spent some time believing that they were only allowed outside the power domain. It is a pity we couldn't agree on a definitive place for switches.SAB>  Actually, the spec is quite clear that switches are always inside a power domain.  I believe you are really referring to whether the switch is inside the power domain that utilizes the supply that the switch controls or outside that domain within a "parent" domain.  (I put parent in quotes as UPF does not really define a nesting of power domains.  The nesting comes from the design elements and scope of the power domains.)Personally, I tend to see the switches inside the power domain utilizing the supply it controls.  But, it was equally clear that other people see it the opposite way (excluding the top level domain).  We intentionally allowed either as we didn't want UPF to dictate this aspect of the methodology because there was no consensus on enforcing one over the other.  o Given that we go into so much detail describing various power domain configurations (figs 4,5,6 & 7) I think it would be worth describing in a bit more detail what it means to have switches inside and outside the power domain.

  40. (UPF) Feedback • SAB>  My CS/software engineering background is responsible for my bias that you encapsulate information local to where that information is needed.  This reduces dependencies in other parts of the design so that changes that should be local are indeed local.  One example of this influence is my description above that an IP provider would define supply ports for the isolation supply(ies).  It is also why I view the switch as usually being internal to a PD that uses the switched supply.However, it seemed to me that the implementation guys seemed to have the opposite view of mine.  It might be tied to the point you raise below on what is the switch's auto-connected supplies.  o When the switches are inside the domain I assume it is illegal to have more than one "logical" switch - however I don't see this mentioned anywhere in the spec.SAB>  No it isn't illegal.  Is there a reason that it should be? • JB-4 •   o I note that a power domain is a collection of elements which share a common primary power supply and that an element is defined as a verilog module then I guess switches created during implementation are allowed in the power domain even though they have a different primary power as the are not strictly "elements" in the design.SAB>  The supply of a switch was never discussed as far as I can recall. I believe the reason why is that implementation tools should know enough about the switch from the context to know what supply it requires.And, an epiphany, this would be the relevance for domain location.  Does the switch take its supply as the primary supply for the domain or is its supply determined in some other way (for example, the driver of the control signal(s)).  I'll explore this question further with other SNPS and LAVA as they may have been assuming something I wasn't.  Whatever assumptions there are, the real point is that the semantics of the switch supply auto-connection needs to be explicit.    - However if switches were to be instantiated in the RTL then they would be elements in the design and so would not be allowed in the same power domain as the elements they switch as they have a different primary power.

  41. (UPF) Feedback • SAB>  Well, they could be.  But, the user would need to explicitly connect supplies other than the primary supplies to the switch and the switch model would need to be supply-aware.  UPF does allow that.Typos:  o Section 5.3: pp23 ll11 the example of the set_retention is not consistent with the spec.SAB>  Fixed in current draft (v0.9_d4, attached).  I haven't yet posted this on the web but will. • JB-5a •   o Section 6.4: pp27 ll20 should refer to port state names and refer to section 6.3 not net state names and section 6.11SAB>  Correct but not fixed in current draft.  We seemed to have missed this one. • JB-5b •   o Section 6.12: pp37 ll36 what is the "-default_value" in the code example?SAB>  This is eliminated from the example as states are defined in a separate command (add_port_state).  The default state is the first state defined for the port.  The default state is relevant only if the port is a "top-level" supply pad that has no supply net source connected to it. It provides a state that simulation initializes the port to.  This is described in section 5.1.  However, I think we lost a bit on consistency in the specification as 5.1 says by default they are ON but doesn't reference 6.3's default state which is what it should do. • JB-5c •   o Section 6.24: pp50 ll22 I think it would be clearer to say "applies to the same design element" than "specify the same design element"SAB>  This is the specific wording that goes with the previous discussion.  I think this statement plus the others I referenced above need to be considered together to ensure the intent is clear. Personally, I don't think the error statement is needed as it simply states the precedence rules defined elsewhere.   o Section 6.24: pp49 ll42 -elements includes pins/ports seems to be inconsistent with the definition of elements.SAB>  Yes, but I think we can live with it.  The description is accurate.  I think it is worth changing only if we need to know if it is a design element or a port or pin (due to confusion in the name space).

  42. (UPF) Feedback • JS-1 • There are currently no auto-connect semantics for switches in UPF. What semantic is necessary to supply power to a switch that has active elements such as acknowledge logic? •       Switch supply ports are [only] connected to supply nets explicitly. A supply net argument is required (not optional) for each supply port. Supply connections to switches do not have any restrictions, assumptions, or enforced relationships with respect to primary supply or ground nets. •      There were a variety of conceptions debated during the course of UPF development.  The most frequently discussed conceptual alternatives were essentially: "is the switch in the scope or the  extent of the power domain?"  It was not so much a question of: "is the switch in the domain or its parent?"  Another strongly recommended (but ultimately rejected) conception was that the switch could be an element of the logic hierarchy but did not necessarily have a requirement for membership in a particular power domain at all. Again, the idea that: "switches may exist as elements that exist in the logical hierarchy but not necessarily in any particular power domain" was rejected by the UPF TSC. •       What we did all agreed to in UPF is: "The create_power_switch command defines an instance of a power switch in the power domain.  The switch is created within the scope of the power domain."  Note that the scope of the power domain defines a completely unambiguous specific location in the logic hierarchy.

  43. (UPF) Feedback • RL-2 • Regarding the set_pin_related_supply I think the "For simulation, “ should be remove from the below paragraph as it also applies to implementation.Current text: "For simulation, the -related_power_pin and -related_ground_pin define the supplies for the drivers of the ports in the -pins list for all instances of the library_cell module. This overrides any auto-connection of primary retention and/or isolation supplies for the driver."Proposed text: "The -related_power_pin and -related_ground_pin define the supplies for the drivers of the ports in the -pins list for all instances of the library_cell module. This overrides any auto-connection ofprimary retention and/or isolation supplies for the driver.“ • There is insufficient information in the command for an implementation tool. But, there doesn't seem to be sufficient information for a simulation tool.The problem comes down to the fact that simply associating a supply with a pin doesn't give enough information to a simulator for it to ensure the simulation results will match whatever is going to happen in the real hardware.  If the fan-in to the logic driving the output includes passage through a register (actually think of 2 registers in series), what assumptions can the simulator make on the supplies of the fan-in logic?  What value is propagated through to the driver of the output, etc?The only situation that I think will work without ambiguity (given the current semantics) is the one you had described before:  A wire is passed through the domain but the input side is connected to the output via a buffer or inverter (creates a driver in the domain).  In this simple, case it should work fine as there is no dependence on other signals or logic in the domain.  However, the standard does not limit its use to this simple case.The thinking is that there would be no problem in implementation because the synthesis tool doesn't infer anything.  It is a hardmacro.  So, what we need to review is whether specifying only this command is sufficient to ensure the power-aware simulation behavior matches what the macro would actually do.I'm hopeful that we can get this better defined so it works for both simulation and implementation.  As to your suggested change, it seems to be OK from my perspective as it looks to be a minor change (that is, it should be the same for implementation tools).

  44. (UPF) Feedback • RM-24 • create_supply_port , etc. responses • I don't recall the standard specifying what scope is used (presumably the current scope, but it should be specified).  Second, if the need is to identify an existing HDL port to be used as a supply port, then we really aren't creating anything.  We are just making the HDL port "visible" to UPF.  Primary purpose of doing so (I think) is to then identify a set of states that port can drive and to use that information in the PST.  This seems like a very useful thing to do (make the PA model white box to UPF).  My concern is that we really have insufficient information in the standard to make this a reality.  (Perhaps we should parallel the power switch situation where we have create_power_switch and set_power_switch?  Define set_power_port which doesn't create a port but identifies an existing HDL port as a supply port with all relevant information associated with it.) • One more thing for us to review more carefully in the near future. • -Steve Bailey • Hi, We did discuss that –domain should be optional for create_supply_port. We need to be able to read in RTL which has power ports. And supply nets can connect to these existing ports. These ports are not specified as “belonging” to any power domain. So the restriction does not work uniformly with RTL and UPF. Regards, Renu. • Steve, I believe this was changed to an optional argument before we had the clear definition of scope / extent. Now we have this I agree this should be a required argument. I.e. my interpretation on this is • create_supply_port VN1 –domain PD1   ;# This will create the port VN1 on the scope of the power domain PD1 • Renu do you agree? I know in your original proposal many months back the intention was to be able to create ports on any logical level. But with the semantics for extent / scope and the punch through capabilities we have agreed on I don’t see this as required any more. Regards Andrew • Did we really intend to make -domain an optional argument for create_supply_port?  I believe it is meant to be a required argument.

  45. (UPF) Feedback • RM-25 • One more issue: Set_isolation –elements: elements can be either port/pins or nets. Since ports and nets can have the same names, it is unclear whether user specified a port or net. Also, if the specified object is a net with a large fanout, it is not clear where the isolation should be put. Allowing nets is adding ambiguity, so I am wondering if we can take out nets?

  46. (UPF) Feedback • KK-1 • Thanks Steve, I agree with Biggsy - once one starts incorporating hierarchical UPFs,users need a way to link to PSTs/states that come with the IP. Kevin Kranen • -----Original Message-----Yes.  I think we should review this area as it might make sense to allowspecification of states on supply net for convenience even if everypower source really comes either off chip or from a switch or regulatoron chip.  At a minimum, the changes you noted as to supply port vs. netneed to be incorporated.I've also had a side discussion with Biggs and we believe that the PSTshould also be able to specify states from another PST so that one PSTcan be defined in terms of another.  For example, an IP supplier canidentify the power states for their IP and a system integrator candefine the system PST in terms of supply port/net states and statesdefined in another PST. -Steve Bailey -----Original Message----- • Thanks Steve, Your explanation makes sense as long as users explicitly create portsfor every supply net that enters each domain - no automated port creation for supply nets. Sounds like we need to make minor tweaks in add_pst_state.The list of supply net state names (see 6.11),Should readThe list of supply port state names (see 6.3),Is that right ?If so  - one more question - should create_pst then have -supply_portsas it's argument rather than supply_nets ?

  47. Add more UPF feedback here

More Related