EDA.org Mantis - ISSUES

0003609: dpi functions which uses VPI/PLI need to be imported as contexts functions

UVM imports dpi function ie:
import "DPI-C" function int uvm_hdl_force(string path, uvm_hdl_data_t
value);

This function uses PLI/VPI to set design variables.
As per LRM it is written that such function need to be imported as
context functions.

IMHO above declaration should be changed to be compatible with LRM:
import "DPI-C" context function int uvm_hdl_force(string path,
uvm_hdl_data_t value);

NOTE: all other functions using pli need to be contexts:
import "DPI-C" function int uvm_hdl_check_path(string path);
import "DPI-C" function int uvm_hdl_deposit(string path, uvm_hdl_data_t value);
import "DPI-C" function int uvm_hdl_force(string path, uvm_hdl_data_t value);
import "DPI-C" function int uvm_hdl_release_and_read(string path, inout uvm_hdl_data_t value);
import "DPI-C" function int uvm_hdl_release(string path);
import "DPI-C" function int uvm_hdl_read(string path, output uvm_hdl_data_t value);

0004037: Define false vacuity and contributions to pass/fail counters in simulation

* Introduce the term “vacuous false” for a property that is false and vacuous. That condition occurs for the following properties:
“not (property_expr )” when property_expr is vacuous.
“reject_on(expression_or_dist)” or “sync_reject_on(expression_or_dist)” when the xpression_or_dist is true.
* In simulation, clarify the evaluation outcome of a vacuously false property and define its contribution to the fail counter.

ADD to 16.14.8 Nonvacuous evaluations
"A property that evaluates to false, but is vacuous as a result of its vacuity definition is considered vacuous false. In simulation, an assertion of a property that evaluates as vacuous false shall not contribute to the fail count."

0003213: Update definition of sampled value

According to the existing definition, the sampled value of a variable is its value in the Preponed region. This definition does not work for many SV(A) constructs: automatic variables, local variables, sequence methods, free checker variables etc. This approach requires listing many exceptions in different contexts, e.g., "in concurrent assertions the variables are sampled except of ...".

Beside of the need to list sampling exceptions in every relevant place, this definition does not allow applying sampled value functions, such as $past to free checker variables and to sequence method triggered.

To overcome these problems it is better to define sampled values differently for different data types. E.g., sampled value is normally defined as a value in the Preponed region, but the sampled value of a checker free variable is its current value, etc.

0004040: psprintf in UVM 1.1a

UVM 1.1a uses $psprintf which is not a standard SystemVerilog construct. $sformatf should be used instead.

This is a regression from http://eda.org/svdb/view.php?id=3483 [^]

To avoid future regressions, use post_test.pl to catch $psprintf

0002953: Algorithmic generation of covergroup bin contents

The following general approach was suggested to me by a contact at Xilinx.

This is another approach to covergroup bin population that relates to 2506 but is more "generative" rather than "predicated".

The basic idea is to use generate like syntax to describe the population of the bin values rather than the 2506 approach of describing doing (essentially) a universal qualification predicate over the universe of values. The suggestion is that the generative approach would be more intuitive to users and would fit well with other kinds of "generated" constructs that a design would likely use.

covergroup data {
bins r2l [dw+1] = {generate for (ii = 0; ii <= dw; ii++) begin
(1 << ii) - 1
end} ;
}

0001356: Multiple inheritance

Paul Butler of National Instruments recommended --

"I would like SystemVerilog to allow multiple inheritance. The obvious choice might be to mimic the C++ multiple inheritance. Java has a similar feature called an 'interface' that might make a good model for SystemVerilog to follow."

An introduction to multiple inheritance --

http://en.wikipedia.org/wiki/Multiple_inheritance [^]

0003990: Extend connect_supply_set (or rather associate_supply_set) to take a list of supply_set_refs which are to be connected.

Allowing a list of supply_set_refs instead of just one as a parameter to the connect_supply_set command would provide a simple way to connect multiple supply sets.

It would also be necessary to make the "-connect" option optional so that (two or more) supply sets can be connected with out having to also connect their functions to pg_types:

eg connect_supply_set {SS1 SS2 SS3}

0004039: run_phase.is_after(reset_phase) returns true

The Ref Guide describes phase.is_after() as

returns 1 if the containing uvm_phase refers to a phase that is later than the phase argument, 0 otherwise

However, when the containing uvm_phase is the run phase and the phase argument is one of the runtime phases, say reset_phase, the function returns 1. I don't think anyone would expect run is "later than" reset.

0003611: AKA 3611a: Clarify whether a generate statement is a scope in the UPF sense (i.e., can contain UPF-declared items)

I have two doubts regarding the hierarchical path separator character when referencing objects in design.

1. What is the path separator character used to reference items inside the generate block?
e.g.
A. create_power_domain PD –elements { top/mid/gen/bot } # here gen is an if generate block

B. create_power_domain PD –elements { top/mid.gen/bot } # here gen is an if generate block

Which one is a valid reference in UPF? Is this "top/mid/gen/bot" as used in (A) or "top/mid.gen/bot" as used in (B)?

There is some text in the LRM which talks about hierarchical path characters but it is not clear from the text what should be used for generate blocks.
e.g.
Section 4.8 talks about lexical conventions and says that “/” is used for logic hierarchy delimiter and “.” is used for record field delimiter.

Section 3.1 defines what is a logic hierarchy as:
3.1.23 logic hierarchy: The tree structure of design elements specified within a logic design.
3.1.10 design element: An instance of a SystemVerilog module (see IEEE Std 1800),6 VHDL entity (see IEC/IEEE 61691-1-1), or library cell. The term design element is often abbreviated to element.

In above definitions it is not clear, whether generate blocks belong to logic hierarchy or not and hence come to conclusion about using "/" or ".".

2. What are the path delimiters used in the arguments of some of the VHDL/SV UPF package functions. The following is the list of package functions that require hierarchical path to be passed as string.

function supply_on (
supply_name : STRING; -- Path name to supply net, port or
-- root supply driver
voltage : REAL := 1.0 )
return BOOLEAN;

function supply_off (
supply_name : STRING )
return BOOLEAN;
-- Voltage is a real value in volts that is converted into
-- an integer value normalized to microvolts

function supply_partial_on (
supply_name : STRING;
value : REAL := 1.0 )
return BOOLEAN;

function get_supply_value (
supply_name : STRING )
return supply_net_type;

function set_scope( inst_path : STRING )
return Boolean;

function get_object( inst_path : STRING;
qualifier : STRING := "" )
return upf_object_handle;

In these cases, should the hierarchical path be composed of ‘/’ or ‘.’ or is it tool dependent?

0003845: AKA 3611c: Clarify what delimiter(s) are allowed/required in pathnames passed as strings to UPF package functions

0003963: Infinite loop when using memory in upper half of a 64-bit address memory

The problem is created by the mismatched types of the address offset and for-loop iterator. The latter should be 'uvm_reg_addr_t' instead of 'int'.

Line 1620 and 1727 in uvm_mem.svh

0004038: minor ripple effect of 3793

I don't see 3793 edited in the d4 version the alpha LRM, but assuming eventually it will, then -transitive will be removed from set_isolation and set_level_shifter. A minor ripple effect of that is we should remove those two commands from the list of commands on p.85 on set_design_attributes.

0003994: Errors in algorithms for simulation of power states (5.4.3.2)

There are several editorial errors in the algorithms for power state determination on pg 29. There is also a more significant error in the algorithm itself. Finally, there is an underlying requirement that is inherently error prone.

1. Editorial issues

In the algorithm for determination of a supply set power state:

a)1)i) should say
The -supply_expr for *each named power state with a -supply_expr* is evaluated.

a)1)v) should say
...
Implementation tools may presume [that] -logic_expr *does not evaluate* [to] True for any non-matching named power state.

d) should say
After the power state of supply sets is evaluated and prior to the evaluation of user-defined processes and always blocks, the power state of *each power domain* is evaluated.

d)1)i) should say
The -supply_expr for *each named power state with a -supply_expr* is evaluated.

d)1)v) should say
...
Implementation tools may presume [that] -logic_expr *does not evaluate* [to] True for any non-matching named power state.

2. Algorithm issue

A more significant issue is that the algorithm (for both supply sets and power domains) focuses on supply expressions if *any* power state definition has a non-empty [?] supply expression. In this case, any power state that only has a logic expression isn't evaluated at all.

I believe the intent was to say something more like this:

for each named power state of the {supply set, power domain}
if the power state defn has a supply expression, then
if the supply expression evaluates to True, then
if the power state defn also has a logic expression, then
if the logic expression evaluates to True, then
the object is in the named power state
else
error (supply expr true but not logic expr)
end
else
the object is in the named power state
end
end
else if the power state defn has a logic expression, then
if the logic expression evaluates to True, then
the object is in the named power state
end
end
end

3. Synchronization of logic and supply expressions

The algorithm requires that both the logic and supply expression evaluate to True at the same time, if both are specified. This is inherently problematic.

If the intent is that the logic expression represents a control condition on a switch, and the supply expression represents the output of the switch (such that the supply is always on when the control is on), it is possible that (a) the control would be turned on when the input supply is off, or that (b) there will be a delay between the control turning on and the output supply turning on. The fact that a UPF power switch already has an ack delay highlights just how close we are to this algorithm failing.

If the intent is that the logic expression represents a control condition on a switch, and the supply expression represents the input supply of the switch, then the situation is worse: it is almost certain that the control input will be off in some cases when the supply is still on.

It may be appropriate to relax this requirement somewhat. First we need to define what it is we are trying to model - the (instantaneous?) toggling of a power switch, or the inputs that enable a power switch to provide power. Depending upon which of these we want to represent, the semantics should be adjusted accordingly.

0002857: AKA 2857a: Clarify meaning of -transitive FALSE, -transitive TRUE on find_objects

Clarification on find_object -transitive

Assuming design:

module sc_t3 (clk, o1, o2);
input clk;
output o1, o2;
inv_f1 inst1(.a(clk), .y(o1));
mod_1 inst2(.a(clk), .y(o2));
endmodule

module mod_1 (a, y);
input a;
output y;
inv_f1 inst3(.a(clk), .y(clkz));
endmodule

inv_f1 is a leaf cell.

Are these the expected results?

set_scope sc_t3

1. find_objects . -pattern * -object_type port -transitive TRUE
Return: clk o1 o2 inst1/a inst1/y inst2/a inst2/y inst2/inst3/a inst2/inst3/y

2. find_objects . -pattern * -object_type port -transitive FALSE
Return: clk o1 o2

3. find_objects . -pattern * -object_type port -transitive TRUE -leaf_only
Return: inst2/inst3/a inst2/inst3/y

4. find_objects . -pattern * -object_type port -transitive FALSE -leaf_only
Return:

5. find_objects . -pattern * -object_type port -transitive TRUE -non_leaf
Return: clk o1 o2 inst1/a inst1/y inst2/a inst2/y

6. find_objects . -pattern * -object_type port -transitive FALSE -non_leaf
Return: clk o1 o2

7. find_objects inst2 -pattern * -object_type port -transitive TRUE
Return: inst2/a inst2/y inst2/inst3/a inst2/inst3/y

8. find_objects inst2 -pattern * -object_type port -transitive FALSE
Return: inst2/a inst2/y

0002849: Clarify that whenever a supply net ref is required, the supply net handle can be used

Supply_set_name.function can be used where UPF spec calls for a supply_net_name.

e.g.:
create_power_switch sc_t3_switch -domain PD_sc_t3 \
-output_supply_port {vdd PD_sc_t3.primary.power} \
-input_supply_port {vddc PD_sc_t3.default_isolation.power } \

0002604: AKA 2604a: Request to add scope to set_power_switch

- Description says:

switch_name The name of the switch instance in the logic design relative to the active
scope; this shall be a simple name.

It should rather be a rooted name.

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.

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?

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.