EDA.org Mantis - ISSUES

0003947: What is the utility of add_domain_elements - should it be deprecated?

Under section 6.6 add_domain_elements on page 43 the LRM says:

This command is semantically equivalent to

proc add_domain_elements {dn elements el} {
if { string equal $elements "-elements" }{
create_power_domain $dn -update -elements $el
return 1
} else {
return -code TCL_ERROR \
-errorcode $ecode \
-errorinfo $einfo \
$resulttext
}
}

I guess "add_domain_elements" is more intuitive than "create_power_domain -update" (which seems a little contradictory) - but to we need to support and maintain two ways to do the same thing?

Should add_domain_elements be deprecated?

0004006: UPF Command Return Value specifications are inconsistent and not necessarily useful

The return value specification for UPF commands is not as consistent as it could be, and probably should be. Following is a list of the Return value specifications (from the syntax table in each case) for every UPF command. Those that have the same definition are grouped under one copy of the definition.

Most commands return a 1 if successful. Some commands - in particular, those that define objects - return the name of the created object. However, this is not consistent; for example, commands to create a supply port, supply net, or logic port return the name of the created object, but create_logic_net does not.

For those that return names, the specification usually says "the fully qualified name", but for create_pst, it just refers to "the name".

For those that return names, the specification typically qualifies this with "(from the active scope)", but for create_supply_net, the qualification is "(from the scope in which the net is created)", and for find_objects, the qualification is "(relative to the active scope)". The variation in wording seems to imply subtle differences in meaning, but it is not clear what those differences are.

It would be good to streamline these definitions a bit, especially in light of the UPF Processing steps. Given that UPF command processing necessarily involves constructing an internal representation of the commands so UPF semantic analysis can be done before they are executed (to construct the power intent model), there seems to be little value in any command except those that only have immediate execution semantics (see UPF Processing) to return any values.

Following is the detailed summary of return values:

Return a 1 if successful or raise a TCL_ERROR if not
add_domain_elements
add_power_state
add_pst_state
associate_supply_set
bind_checker
connect_logic_net
connect_supply_set
create_composite_domain
create_hdl2upf_vct
create_logic_net
create_supply_set
create_upf2hdl_vct
describe_state_transition
load_simstate_behavior
map_isolation_cell
map_level_shifter_cell
map_power_switch
map_retention_cell
name_format
save_upf
set_design_attributes
set_design_top
set_domain_supply_net
set_isolation
set_isolation_control
set_level_shifter
set_pin_related_supply
set_port_attributes
set_power_switch
set_retention
set_retention_control
set_retention_elements
set_simstate_behavior
use_interface_cell

Return a list of the found hierarchical names (relative to the active scope); when nothing is found, a null string is returned.
find_objects

If called with an argument, return the argument. If called with no arguments, return the current version number. If the call fails, raise a TCL_ERROR.
upf_version

Return the number of power domains merged or raise a TCL_ERROR if the merge is unsuccessful.
merge_power_domains

Return a 1 if all commands in the loaded UPF file completed successfully, or raise a TCL_ERROR if the command fails or any command in the loaded UPF file fails.
load_upf
load_upf_protected

Return the name of the created PST or raise a TCL_ERROR if the PST is not created.
create_pst

Return the fully qualified name of the created switch or raise a TCL_ERROR if the domain is not created.
create_power_switch

Return the fully qualified name (from the active scope) of the created domain or raise a TCL_ERROR if the switch is not created.
create_power domain

Return the fully qualified name (from the active scope) of the created port or raise a TCL_ERROR if the port is not created.
create_logic_port

Return the fully qualified name (from the active scope) of the created port or raise a TCL_ERROR if any of the port states are not added.
add_port_state

Return the fully qualified name (from the scope in which the net is created) of the created net or raise a TCL_ERROR if the net is not created.
create_supply_net

Return the fully qualified name (from the active scope) of the created port or raise a TCL_ERROR if the port is not created.
create_supply_port

Return the active scope prior to execution of the command as a full path string relative to the active design top if successful or raise a TCL_ERROR if it fails (e.g., if the instance does not exist.)
set_scope

Return the setting of the translation if successful or raise a TCL_ERROR if not.
set_partial_on_translation

If TCL_ERROR is raised, then errorcode, errorinfo, and resulttext are also available.

0003986: UPF Command Return Value specifications are inconsistent and not necessarily useful

0003980: Deprecate -include_scope of create_power_domain

Per WG discussion on Dec. 9 2011, the resolution is to deprecate -include_scope.
Related mantis is 3122. Also, see discussion notes covering this topic in:
https://docs.google.com/a/p1801.org/?tab=oo&pli=1#advanced-search/q=3775 [^]

0003979: Deprecate -scope of create_power_domain

Per WG discussion on Dec. 9 2011, the resolution is to deprecate -scope.
See google docs: https://docs.google.com/a/p1801.org/?tab=oo&pli=1#advanced-search/q=3775 [^]

The related mantis is 3775

0003957: Change the name of Appendix B to reflect the fact that it contains Package UPF

The entry for Appendix B in the Category field above is mislabeled as "Supply net logic type", which seems strange given that 99% of the appendix is about package UPF. This apparently came about because Appendix B starts with a short paragraph about representing supply net type values before presenting B.1 VHDL and B.2 SystemVerilog, both of which contain respective versions of the package. The title of the appendix appears to have come from that short paragraph. It would be better if this appendix were entitled Package UPF, with the section on supply net logic type as B.1, the VHDL UPF package as B.2, and the SystemVerilog UPF package as B.3.

0003955: Correct VHDL package UPF to avoid use of reserved word as a parameter name

Package UPF contains function assign_supply_state, which has a parameter named "after". This is a VHDL reserved word. Reserved words can only be used as keywords, not as user-defined (or predefined) identifiers, so the package won't (or at least shouldn't) compile as is. This parameter name should be changed to something else, such as "delay".

The same function exists in both VHDL and Verilog UPF packages. Ideally both would use the same non-reserved identifier.

I've marked this as an Errata, which is the closest thing to Bug that is available in the category list.

0003945: Predefined VCTs of hdl_type SV have an additional ' in the definition this is not consistent with the syntax

The predefined VCTs which provide conversion to/from SV logic type have and addition ' character in before (and after in some cases ) the logic values. This is not consistent with the syntax defined create_hdl2upf_vct and create_upf2hdl_vct commands. e.g.

C.6 UPF2SV_LOGIC
create_upf2hdl_vct UPF2SV_LOGIC
-hdl_type sv
-table {{UNDETERMINED 'X}
{PARTIAL_ON 'X}
{FULL_ON '1}
{OFF '0}}

----
This should be

C.6 UPF2SV_LOGIC
create_upf2hdl_vct UPF2SV_LOGIC
-hdl_type sv
-table {{UNDETERMINED X}
{PARTIAL_ON X}
{FULL_ON 1}
{OFF 0}}

as per following statement on page 70 and example on page 71.
When converting to SystemVerilog logic type, the set of legal values is 0, 1, X, and Z.

Syntax examples:
create_upf2hdl_vct upf2vlog_vdd
-hdl_type {sv}
-table {{OFF X} {FULL_ON 1} {PARTIAL_ON 0}}

The affected vcts are
C.5 SV_LOGIC2UPF
C.6 UPF2SV_LOGIC
C.7 SV_LOGIC2UPF_GNDZERO
C.8 UPF_GNDZERO2SV_LOGIC
C.10 SV_TIED_HI
C.12 SV_TIED_LO

0003910: Correct syntax of set_design_attributes to be consistent with tcl syntax

In 1801-2009 UPF, the syntax for set_design_attributes includes the option

-attribute name value

which can appear multiple times.

According to 0003040, which talks about the consistency of add_power_state with tcl syntax,

"According to section 6.1, All parameters begin with a hyphen (-)....". So -state defines a parameter. According to Tcl syntax, a parameter has three basic data types:

a. Scalar (or string)
b. List (an ordered list of scalars)
c. Array (or hash)"

This implies that the syntax for the -attribute option of set_design_attributes should be

-attribute { name value }

since the 'value' of this parameter consists of a list of two items, not a single item or a general array/hash.

0003868: AKA 3194c: Shall we define 'sibling' in Definitions?

Whilst the other values of 'location' define where in the hierarchy (domain or logical?) the cells should be inserted the value 'sibling' does not seem to.

"sibling—a new sibling is created into which the isolation cells are placed."

1. This infers that new hierarchy is created to store the cells of this strategy but where should this reside? Should we assume the location for this new hierarchy is derived from automatic location or something else?

2. This probably depends on the answer to #1 but is one sibling used per strategy or per domain?

3. Should 'sibling' be entered in 3.1 Definitions?

Location sibling is also used in 6.41 and 6.42.

0003867: AKA 3194b: Clarification on '-location sibling' where tools should create one hierarchy per strategy, per domain or per port?

0003864: AKA 2799b: Clarify the semantics of -source/-sink, relates to the difference between driving logic vs driving design elements

module A (out1);
output out1;
endmodule
module B (in1);
input in1;
endmodule
module TOP();
A instA(.out1(across));
B instB(.in1(across));
endmodule

set_scope
create_power_domain PD_yellow –include_scope
create_power_domain PD_red –elements instA
create_power_domain PD_blue –elements instB
set_isolation iso1 –domain PD_red –source PD_red –sink PD_blue

Question – does the net ‘across’ exist in domain PD_yellow
i.e. does the net go from PD_red to PD_yellow and then from PD_yellow to PD_blue, or does it go directly from PD_red to PD_blue?
So does the isolation rule select instA/out1 as being a source and instB/in1 as being a sink?

0003793: Remove -transitive=TRUE (currently the default) in set_isolation and set_level_shifter

The description of the -transitive option in set_isolation and set_level_shifter says:

"When -transitive is TRUE (the default), the command applies to the
descendants of the elements."

The problem is, isolation and level_shifter cells are always inserted at domain interface. This implies that the strategy never applies to the decendants anyways, i.e., -transitive being TRUE or FALSE makes no difference.

In contrast, -transitive in set_retention has its meaning.

0004031: uvm_pack_* macros ignore endianness

The macros don't consider the big_endian field like the functions they replace.

`define uvm_pack_intN(VAR,SIZE) \
packer.m_bits[packer.count +: SIZE] = VAR; \
packer.count += SIZE;

vs.

function void uvm_packer::pack_field_int(logic [63:0] value, int size);
for (int i=0; i if(big_endian == 1)
m_bits[count+i] = value[size-1-i];
else
m_bits[count+i] = value[i];
count += size;
endfunction

0004030: `uvm_pack_ macros lack begin/end

The implementation of the `uvm*pack_* macros are multi-lines but are not enclosed within a begin/end block, preventing the macro from being treated as a single statement.

0003707: Clarify how the default driver/receiver supplies of primary inputs/ouputs are determined

The attributes of driver_supply/receiver_supply of primary input/output ports determines the isolation/level shifter strategy which involves nets connected to those ports. User can specify the two attributes using set_port_attributes however a default definition will be handy.

It is reasonable to assume the default driver_supply of primary input ports and default receiver_supply of the primary output ports is the primary supply set of the default power domain of current scope, i.e. domain created with -include_scope

0003415: Check the example and decide whether SLEEP_MODE should involve reverse bias rather than forward bias - fix

A very minor point, but I think the SLEEP_MODE in the example on page 47 should be reverse bias (nwell>power) and not forward bias (power>nwell) as shown:

-state SLEEP_MODE {–logic_expr {SW_ON && interval(clk_dyn posedge negedge) >= 100ns}
-supply_expr {{power == ‘{FULL_ON, 0.8}}
&& {ground == ‘{FULL_ON, 0}}
&& {nwell == ‘{FULL_ON,0.6}}}
–simstate CORRUPT_STATE_ON_CHANGE}

0003320: Clarification on the instantiation hierarchy for '-location sibling' in set_isolation/level_shifter, see also 3194

0003194: AKA 3194a: Clarification on the term 'sibling' when used to define location. (see 3320 for #1)

0003043: Review and revise Clause 3 Definitions as required.

The definition of driver (3.1.12) is “any design element that supplies a value to a net, either directly, or indirectly via a port. Ports are not drivers.” However, this doesn’t correlate well with the statement in 4.1 that says “A net that is not driven by design elements in a particular domain is not corrupted by that domain; input ports and assignment statements are not considered drivers in this context.” This statement is intended to support the semantics of always-on signals that pass through a switched domain. Unfortunately, the definition of driver in 3.1.12 restricts the effect of this statement to work only for pass through signals that originate in a parent context. It does not appear to work for pass through signals that originate in a nested context.

Suppose module instance A contains instance B which contains instance C, and each of A, B, C are in a separate power domain. Suppose B is switched, and A and C are always on. The current definition allows a signal from A to pass through B on its way to C and remain uncorrupted. That signal passes through an input port of B and an input port of C, neither of which is a driver, and therefore the signal is not corrupted. But a signal coming from C passing through B on its way to A will be corrupted, because it must go through an output port of B, and output ports are considered drivers, so when the domain of B goes down, the signal entering A will be corrupted.

Perhaps the definition of a driver should be changed to read as follows:

3.1.12 driver: Any logic that supplies a computed value to a net or port, or conditionally supplies a value to a net or port. Ports themselves are not drivers, nor are Verilog continuous assignment statements or VHDL unconditional concurrent signal assignment statements that simply pass an input value to an output net, port, or signal, with no computation involved.”

This proposed definition refers to "computed" values or "conditional" assignment because these imply combinational or sequential logic, whereas unconditional, continuous assignments do not.

This definition should also state whether a Verilog buf primitive is considered to be a driver. I believe all other primitives should be considered drivers.

0003042: Clarify whether Verilog primitives create drivers

The definition of design element (3.1.10) mentions (System)Verilog module instances, VHDL entity instances, and library cells. There is no mention of Verilog primitives. Should a Verilog primitive be considered a design element? I.e., is it possible to specify that a Verilog primitive instance belongs to a given power domain?

0003040: Revise add_power_state syntax to conform to UPF conventions

The add_power_state is defined as:
add_power_state object_name
{-state state_name {[-supply_expr {boolean_function}] [-logic_expr {boolean_function}]
[-simstate simstate] [-legal | -illegal] [-update]}}*
[-simstate simstate][-legal | -illegal]
[-update]

According to section 6.1, All parameters begin with a hyphen (-)....". So -state defines a parameter. According to Tcl syntax, a parameter has three basic data types:

a. Scalar (or string)
b. List (an ordered list of scalars)
c. Array (or hash)

The current syntax is not compliant with the Tcl syntax!

I suggest to correct the command syntax as:

add_power_state object_name
{-state {state_name [-supply_expr {boolean_function}] [-logic_expr {boolean_function}]
[-simstate simstate] [-legal | -illegal] [-update]}}*
[-simstate simstate][-legal | -illegal]
[-update]

This correction is consistent with Tcl syntax and similar to add_port_state command:

add_port_state port_name {-state {name }}*

0002966: Check that use of {} is self-consistent and consistent with tcl and revise as needed.

Please notate changes needed.

0002965: Clarify that add_power_state requires an empty set of braces in certain cases (cf 3040)

add_power_state PdA.primary
-state GO_MODE {–logic_expr SW_ON –simstate NORMAL
-supply_expr {{power == ‘{FULL_ON, 0.8}}
&& {ground == ‘{FULL_ON, 0}}
&& {nwell == ‘{FULL_ON,0.8}}}
-state OFF_MODE {–logic_expr !SW_ON
-supply_expr {power == ‘{OFF}}
–simstate CORRUPT}
-state OVERVOLTAGE_MODE {–logic_expr !SW_ON
-supply_expr {power == ‘{FULL_ON, 1.3 5.0}}
–simstate CORRUPT
-illegal }
-state {ILLUSTRATION1}
-state ILLUSTRATION2 {} # {} is Currently required
-state ILLUSTRATION3

-state SLEEP_MODE {
–logic_expr
{SW_ON
&& interval(clk_dyn posedge negedge)>= 100ns}
-supply_expr {{power == ‘{FULL_ON, 0.8}}
&& {ground == ‘{FULL_ON, 0}}
&& {nwell == ‘{FULL_ON,0.6}}}
–simstate CORRUPT_STATE_ON_CHANGE}
-legal

0002868: FAQ: Clarify whether -transitive is allowed with no value

The syntax example in 7.1 (find_objects) is:

find_objects ... -transitive.

The syntax specification specifies that the -transitive should take the values TRUE | FALSE.

This occurs elsewhere throughout the syntax examples in the spec, e.g. section 7.18.