Rename

Renaming a name with find-and-replace changes things that merely look alike. Rename is scope-aware: it changes only the names that refer to this declaration, in all files, and checks first that the new name keeps the meaning of your code. Click a name, a declaration or any usage of it (the blinking text cursor is the caret), and choose Refactor | Rename… (⇧F6 on macOS, Shift+F6 on Windows/Linux). In the Rename dialog (a field with the current name, a few checkboxes, and Refactor and Cancel buttons; the IDE may instead let you type the new name in place and press Enter), type the new name and click Refactor. The declaration and every usage that Find Usages would list are updated, in all files.

The Search in comments and strings checkbox is off by default, which is what you want in the steps below. Tick it only if you also want matching words in comments and string literals changed.

What the video shows

1. In classes/shapes.sv, the caret is on the virtual method area of class shape; ⇧F6 (Shift+F6) opens the Rename dialog.
2. The new name get_area is entered and Refactor is clicked.
3. The overrides in square and circle and the call s.area() are renamed too.

Nearly every declared construct can be renamed (not checkers or user-defined primitives) — see Supported constructs. Before changing anything, the plugin checks that the rename keeps the meaning of your code; if it would not, you get a list of conflicts first.

Try it

Open the sample project and wait until indexing has finished (the progress bar at the bottom right disappears). You do not need to change sim.f: files in the project folder that it does not list (rtl/legacy_reg.v, classes/shapes.sv) are renamed too. If the IDE renames in place instead of showing a dialog, type the new name and press Enter; in every step below, “click Refactor” means that. To check a step, open each file it names and look at the quoted line. Undo after each step with Edit | Undo (⌘Z / Ctrl+Z) while an editor tab is focused; one undo reverts the rename in every file. Check that the names are back before the next step (for example module counter in rtl/counter.sv). Besides the files named in a step, the body of the macro COUNTER in rtl/defines.svh (counter __name (.clk(__clk), …); the macro keeps its name) also follows renames of counter and its ports: that is the Macro bodies row in What is renamed together.

1. Open rtl/counter.sv, put the caret on counter in module counter, press ⇧F6 (Shift+F6), type up_counter and click Refactor. The module and its end label endmodule : up_counter change, and so do the instantiation in rtl/top.sv and the body of the macro COUNTER in rtl/defines.svh: counter __name (…) becomes up_counter __name (…); the macro is still named COUNTER.
2. In rtl/counter.sv, rename the port clk to clock. @(posedge clock …) is updated, and in rtl/top.sv the implicit connection .clk becomes .clock(clk), and .clk(__clk) inside the body of the macro COUNTER becomes .clock(__clk).
3. In rtl/top.sv, put the caret on rst_n in the module header module top(input logic clk, input logic rst_n); and rename it to reset_n. The implicit connection .rst_n becomes .rst_n(reset_n): the port of counter is a different declaration, so only the signal in top is renamed.
4. Open rtl/legacy_reg.v and rename q in output [7:0] q; to dout. The port list, the output declaration, the reg declaration and the assignment all change.
5. Open classes/shapes.sv, put the caret on area in virtual function real area(); inside class shape (the first one in the file) and rename it to get_area. The overrides in square and circle and the call s.area() are renamed too.
6. In rtl/top.sv, rename busy in logic busy; to active. In rtl/top.sv, initial $display(g_lane[0].busy); becomes … g_lane[0].active … (a hierarchical reference: block name, then signal).
7. In rtl/counter_pkg.sv, rename the enum member IDLE to RESET. rtl/counter.sv pulls in the names of counter_pkg with import counter_pkg::*;, so state <= IDLE; becomes state <= RESET;.

If every step matched, Rename works on your installation. If one did not, see If it doesn’t work.

What is renamed together

Some declarations belong together and are always renamed as a group:

Situation	What happens
End labels	endmodule : counter, endclass : my_item, endfunction : f, end : seq follow the name.
Virtual methods	Renaming a virtual method renames the whole override family: the base declaration and every override in derived classes, plus all calls. You can start from the base method or from any override.
Constraints	Constraints override by name, so renaming one renames the constraints of that name in base and derived classes, the out-of-block bodies (constraint C::c_x {…}) and uses such as item.c_x.constraint_mode(0).
Macro bodies	A `define body that instantiates the module by name follows the rename of the module, of its ports and of its parameters: .state_i ( __d ) becomes .state_x ( __d ) in the macro, so every instance the macro’s calls create stays connected. Line continuations (\) are kept. Renaming to one of that macro’s formals is a conflict: every call would replace the name with its argument.
Covergroups	Renaming a covergroup also renames its endgroup : label and its uses (cg = new;, w.cg.sample()).
Verilog-95 ports	In module m(clk, q); output [7:0] q; reg [7:0] q; the port list entry, the output declaration and the reg/wire declaration are one signal and are renamed together.
Implicit port connections	.clk is SystemVerilog’s shorthand for .clk(clk): it connects a port and a signal of the same name. Renaming either one rewrites it as an explicit connection: .clock(clk) when the port is renamed, .clk(clock) when the signal is.
Generate branches	A label or signal declared in mutually exclusive if/else generate branches is one name; renaming it renames every branch, so hierarchical references stay valid.
Duplicate definitions	If the same module or function is defined in several files (for example alternatives selected with `ifdef), usages refer to all of them, so all definitions are renamed. A dialog lists the extra definitions first (see Rename conflicts).
verilog-mode AUTO_TEMPLATEs	A module’s name at the head of an AUTO_TEMPLATE comment (/* legacy_reg AUTO_TEMPLATE () in a file with its instances, or in its own file, is renamed with the module, so Expand AUTOs still applies the template. As verilog-mode reads heads: only one starting its line counts (not after code), and the name matches without case (/* Sub AUTO_TEMPLATE is renamed too). Find Usages lists heads written in the module’s case, in any file.

With the default options, text in comments (other than AUTO_TEMPLATE heads) and in string literals is not changed: after renaming the property vif, the configuration key in uvm_config_db#(virtual my_if)::get(this, "", "vif", vif) is still "vif".

If it doesn’t work

You see	Likely cause	What to do
Refactor | Rename… is greyed out, or nothing is renamed	The caret is not on a name, or indexing is not finished	Click the name itself; wait for the progress bar at the bottom right
A usage was not renamed	It is in inactive `ifdef code, in a comment or string, or in a file outside the project folder or attached as a library (library files are never modified)	See Conditional compilation and Known limitations; tick Search in comments and strings for text
A dialog lists conflicts	The new name would change what some code refers to	See Rename conflicts; pick another name or Cancel

Examples

Renaming the port clk of counter to clock

// rtl/top.sv, before
counter #(.MAX(20)) u_counter(.clk, .rst_n, .count(count), .done(done));
// after
counter #(.MAX(20)) u_counter(.clock(clk), .rst_n, .count(count), .done(done));

Renaming the Verilog-95 output q to dout — before

module legacy_reg(clk, d, q);
  output [7:0] q;
  reg [7:0] q;
  always @(posedge clk)
    q <= d;

After

module legacy_reg(clk, d, dout);
  output [7:0] dout;
  reg [7:0] dout;
  always @(posedge clk)
    dout <= d;

Limitations

• Names written inside a macro definition are not updated, except when the body instantiates the module (see Macro bodies above). Macro names themselves are renamed like any other name: see Macros.
• Files attached as libraries are never modified. If a rename would require it — for example renaming a method that overrides a method of a library class — you get a conflict instead.
• If the base class is not available at all (for example the UVM library is not in the project), renaming a method that overrides a base-class method cannot be checked: the rename goes ahead and the method no longer overrides the base method.
• See Known limitations for the complete list.