CPF File Structure
Command Categories
The following table shows how the CPF commands can be categorized.
 | It is recommended to define the library-cell related commands in a separate file which can be sourced in the CPF file (using the include command) in a higher-level CPF file. |
Typical Command Usage
To perform functional verification, you need the following minimum set of commands to specify the power structures when starting from RTL:
set_design
end_design
set_macro_model
end_macro_model
create_power_domain
create_nominal_condition
create_power_mode
create_state_retention_rule
create_isolation_rule
To drive synthesis and test, you need at least the following commands in addition to the commands listed above:
define_library_set
define_isolation_cell
define_level_shifter_cell
define_state_retention_cell
update_nominal_condition
update_power_mode
To drive physical implementation and signoff analysis, you need at least the following commands in addition to all commands listed above:
create_power_nets
create_ground_nets
create_power_switch_rule
update_power_domain
create_operating_corner
create_analysis_view
Command Dependency
Some CPF commands reference objects defined in previous commands. This implies that a certain command order is required. If this order is violated, an error will be issued.
Information Precedence
If you define a CPF object in a specific scope multiple times with the same name, the last definition takes precedence, unless specified otherwise.
The last definition prevails and only instance A is added to power domain PD1.
In the following example, the nominal condition
changeis defined first, next used in the power mode definition of modeM1, then redefined and used again in the power mode definition ofM2.create_nominal_condition -name high -voltage 1.2
create_nominal_condition -name low -voltage 1.0
create_nominal_condition -name change -voltage 0
create_power_mode -name M1 -domain_conditions {PD1@high PD2@change PD3@low}
create_nominal_condition -name change -voltage 1.2
create_power_mode -name M2 -domain_conditions {PD1@high PD2@change PD3@off}Because the last definition in the scope takes precedence, the last definition of nominal condition
changewill be used and applied to both power mode definitions (M1andM2).You can add implementation details for CPF objects using multiple update commands as long as each command specifies unique information. If the same information is specified, the information specified in the last command takes precedence.
update_power_domain -name PD1 -primary_power_net VDD1
update_power_domain -name PD1 -pmos_bias_net VDD_bias
update_power_domain -name PD1 -primary_power_net VDD2The result of these commands is that VDD2 is considered as the primary power net for power domain PD1. The second command specifies that power domain PD1 has a body bias net for the p-type transistors of all functional gates in power domain PD1.These 3 commands combined give the same result as the following command:
Similarly, you can add specification details for special library cells using multiple define commands, as long as each command specifies unique information. If the same information is specified, the information specified in the last command takes precedence.
For example, the isolation cell definition for cell
ISO1will include all the information from bothdefinecommmands.define_isolation_cell -cells {ISO1 ISO2 ISO3} -enable en -location to
define_isolation_cell -cells {ISO1} -always_on_pins {en}If information defined in the CPF file conflicts with information in the referenced library, the information in the CPF file takes precedence.
Information Inheritance
The general purpose commands are scope sensitive:
set_array_naming_style
set_cpf_version
set_hierarchy_separator
set_register_naming_style
set_time_unit
set_power_unit
By default, the scope inherits the values of the previous scope.
You can change the values for the current scope, but these values only apply as long as you are within the scope.
Example
Assume the following design hierarchy:
# the following command sets the hierarchy separator to / for all scopes set_hierarchy_separator /set_design Top
# the following command changes the hierarchy separator from / to . for Topset_hierarchy_separator .set_instance A_inst
set_design A
...
# the current scope inherits . as the hierarchy separator
# the following command changes the hierarchy separator to / for the current scopeset_hierarchy_separator /...
end_design
# the scope changes to Top and the hierarchy separator changes back to .
# because . is the hierarchy separator for Top
...
set_instance A_inst.A1_inst
# the following command changes the hierarchy separator to / for the current scopeset_hierarchy_separator /set_design A1
...
end_design
# the scope changes to Top and the hierarchy separator changes back to .
# because . is the hierarchy separator for Top
...
end_design
Object References
CPF commands reference design and CPF objects. An object reference is always relative to the current scope (part of the design that is visible).
By default, the scope starts at the top design and by default all elements in the design hierarchy are visible. You can change the scope using the set_instance command. After a set_instance command, the scope is reduced to a portion of the design.
You can only reference objects within the current scope or in a lower scope. The current scope is always considered to be the top. Top level does not necessarily refer to the top level of the design. In the current scope, top refers to the topmost level of the hierarchy of the scope.
To reference an object that is part of the current scope, you can use its name.
To reference an object that is below the current scope, specify the hierarchical name (path to the object). The object reference starts from the top of the scope. Therefore you can omit the hierarchical separator at the beginning of a path which denotes the top of the current scope.
Note:
If your current scope is the root-level hierarchy and the root-level hierarchy has multiple top modules, the search for design objects starts from all top modules.
Referencing Design Objects
Referencing a Pin or Port
Whenever you reference a pin or port in an expression, either
The pin or port must exist in the design
The port must have been declared as a virtual port using the
-ports,-input_ports,-output_ ports, or-inout_portsoption of theset_designcommand.
Referencing a Power Supply Net
When you reference a power supply net, either
The net must exist in the design
The net must have been created using the
create_bias_net,create_ground_nets, orcreate_power_netscommand.
Referencing RTL registers
To reference RTL registers, use the RTL register name. For arrays of registers, you can also use indexes to select bits of the array.
Examples
reg [5:4][3:2] c;
reg c1;
The following command will select register
c1and the entire array ofc.The following command will select the entire array of
c.The following command selects registers
c[5][3]andc[5][2]:The following command selects registers
c[5][3]andc[4][3]:
Referencing Verilog Generated Instances
To reference a Verilog generated instance, follow the Verilog-2001 naming style for generated instances.
Example
parameter SIZE = 2;
genvar i, j, k, m;
generate
for (i=0; i<SIZE+1; i=i+1) begin:B1 // scope B1[i]
M1 N1(); // instantiates B1[i].N1
for (j=0; j<SIZE; j=j+1) begin:B2 // scope B1[i].B2[j]
M2 N2(); // instantiates B1[i].B2[j].N2
for (k=0; k<SIZE; k=k+1) begin:B3 // scope B1[i].B2[j].B3[k]
M3 N3(); // instantiates B1[i].B2[j].B3[k].N3
end
end
if (i>0)
for (m=0; m<SIZE; m=m+1) begin:B4 // scope B1[i].B4[m]
M4 N4(); // instantiates B1[i].B4[m].N4
end
end
endgenerate
The generated instance names that should be used are:
B1[0].N1, B1[1].N1B1[0].B2[0].N2, B1[0].B2[1].N2B1[0].B2[0].B3[0].N3, B1[0].B2[0].B3[1].N3, B1[0].B2[1].B3[0].N3B1[1].B4[0].N4, B1[1].B4[1].N4
The following command references the registers in the generated instances B1[0].N1 and B1[1].N1.
create_state_retention_rule -name sr1 ... -instances {B1[*].N1.q*}
Referencing an Instance
When you reference a hierarchical instance, the instance and all of its children will be selected.
Consider the following rule for the following hierarchy
create_state_retention_rule -name sr1 -instances A/A* -exclude A/A3
Topflop
A
A1A2flopA3flopB
The -instances option selects instances A1, A2 and A3 in hierarchical instance A. However since A1, A2 and A3 are hierarchical instances themselves, this command selects the leaf-level flops in A1, A2 and A3. The -exclude option removes A/A3/flop from the selected list.
Referencing CPF Objects
You can only reference a CPF object that was already created.
To reference CPF object created in the current scope, you can use the same name.
To reference a CPF object created below of the current scope, use the hierarchical name of the CPF object. This is the defined name of the CPF object prefixed with the hierarchical name of the scope in which the CPF object is created with respect to the current scope.
All CPF objects except for the library set are scope sensitive.
Library set objects are defined in a global non-hierarchical namespace. Name conflicts are resolved according to Information Precedence.
Assume a design with the following hierarchy:
Top
Inst1 (mod1)
Inst2 (mod2)
Inst3 (mod3)
Inst4 (mod4)
The names in parentheses are the corresponding module names. Consider the following CPF file:
1. set_design Top
2. create_power_domain -name PD1 -default
3. create_power_domain -name PD2 -instances Inst1
4. set_instance Inst2
5. set_design mod2
6. create_power_domain -name PD1 -instances Inst3
7. create_isolation_rule -name ir1 -from PD1 -isolation_condition standby1
8. create_isolation_rule -name ir2 -from PD2 -isolation_condition standby2
9. create_power_domain -name PD3 -instances Inst4
10. end_design
11. create_isolation_rule -name ir3 -from PD1 -isolation_condition standby3
12. create_level_shifter_rule -name lsr1 -from Inst2.PD1
13. create_state_retention_rule -name srr1 -domain PD3 ...
14. end_design
In this CPF file, two power domains with the same name PD1 are created (lines 2 and 6). This is allowed because they are created in two different scopes.
When referencing power domain PD1 inside scope Inst2 (line 7), the only matching power domain is the power domain PD1 created on line 6.
Referencing power domain PD2 on line 8 causes an error, because there is no power domain created with name PD2 in the scope of Inst2.
Referencing power domain PD3 on line13 also causes an error because power domain PD3 was not created at the top level, even though a power domain PD3 was created inside scope Inst2 (line 9).
To reference power domain PD1 defined for scope Inst2 from the top level, the hierarchical path name of object PD1 with respect to the current scope (top level) must be used (line 12).
