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
•
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
(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.
(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-RetentionVDD
Supply-Retention-
VDD
Supply-DefaultVDD
VDD
VSS
VSS
Supply-DefaultVSS
VSS
(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
(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
VDD
Supply-VSS
Component-defined
and UPF default
power-down
corruption???
VSS
UPF default
power-down
corruption
(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
(Verif 3 of 5) How to map the UPF
VSS ON == 1 semantic to library
components conventionally assuming
VSS ON == 0, and functional pins that implementation tools tie to
VSS as logical 0?
Supply-VDD:
OFF:0, ON:1
VDD
Supply-VSS:
VSS
OUT = VDD & ~VSS ? (IN1 & IN2) : X
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
(Verif 3 of 5) How to map the UPF
VSS ON == 1 semantic to library
components conventionally assuming
VSS 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?
(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.
(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
(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.
(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.
(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.
(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.
(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.
(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)
(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?
(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.
(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
(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.
(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 a voltage
value. The supply state itself consists of two pieces of information: an on/off state and a full/partial state. The
on/off state of a supply port and net is asserted when it is connected to a supply pad that is on and it is deasserted when there is no connected path to a supply pad or the supply pad is off. By default, supply pads are
on; however, they may be turned off to model off-chip switches using a language-specific simulation control. The
full/partial state represents the conductance of a switch along the supply path; it is asserted when the switch is
partially on, and de-asserted when it is fully on or fully off. The voltage value and full/partial state of a supply net
are valid only when its on/off state is asserted. The voltage value is the same 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 a voltage
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, supply pads are ON; however,
they may be turned off to model off-chip switches using a language-specific simulation control. The
PARTIAL_ON state represents the conductance of a switch along the supply path; it is asserted when the switch
is PARTIAL_ON. The voltage value is valid only when the state is ON. The voltage value is the same 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.
(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.
(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.
(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...
•
•
(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}}*]
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
(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!
(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_supply domain_name [-ports list] [-nets list] -related_power_net supply_net_name
-related_ground_net supply_net_name
Arguments
domain_name The domain where the default supply nets are to applied.
-ports list
A list of ports that is to have a related power/ground supply defined.
-nets list
A list of nets that is to have a related power/ground supply defined.
-related_power_net supply_net_name
The supply net to which the pin is related.
-related_ground_net supply_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 corrupted.
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
•
•
•
•
•
(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.
•
(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
•
•
•
•
•
•
•
•
•
•
•
(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
(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?)
(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.
•
•
•
•
•
•
•
•
•
•
•
(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.
•
•
•
•
•
•
•
•
•
•
•
•
•
(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.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
(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.
•
•
•
(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_pst
All 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 constraint
which would be a voltage range? If it all depends on the actual implementation, then even a voltage range would likely be too much
information.
(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.
•
(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.
•
(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.
•
(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.11
SAB> 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).
(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.
•
•
(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 autoconnection 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 of
primary 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).
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
(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.
(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?
•
(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 allow
specification of states on supply net for convenience even if every
power source really comes either off chip or from a switch or regulator
on chip. At a minimum, the changes you noted as to supply port vs. net
need to be incorporated.
I've also had a side discussion with Biggs and we believe that the PST
should also be able to specify states from another PST so that one PST
can be defined in terms of another. For example, an IP supplier can
identify the power states for their IP and a system integrator can
define the system PST in terms of supply port/net states and states
defined in another PST. -Steve Bailey
•
-----Original Message----Thanks Steve, Your explanation makes sense as long as users explicitly create ports
for 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 read
The list of supply port state names (see 6.3),
Is that right ?
If so - one more question - should create_pst then have -supply_ports
as it's argument rather than supply_nets ?
Add more UPF feedback here