View source for Modules/design units with " default" suffix in their names

<pre style="color: red"> This article is currently under construction </pre>

'''Q: After static elaboration, there are modules/design units with "_default" or "_1, _2" suffix in their names. Why? And what are they? '''

==== Modules with "_default" suffix ====

Static elaboration process is a multiple-iteration process and modules/design units may be modified differently in each iteration.

We need to keep original version of modules/design units as they are immediately after analysis so that they can be copied for different parameter/generic settings in each iteration and body of copied modules/design units can be elaborated (generate unroll, array instance processing, etc.) differently for each parameter/generic setting.

Another reason to copy instantiated modules/design units with "_default" name is in mixed language elaboration. Here a Verilog module may instantiate a VHDL entity which has been elaborated earlier with different generic values. In that case during Verilog elaboration we will not get original contents of instantiated entity.

Moreover, to support incremental elaboration we need to keep original modules/design units, as lower level units can be elaborated earlier.

In Verilog, we have a runtime-flag "veri_remove_suffix_default_from_copied_module_names" to rename modules from "<orig_name>_default" to "<orig_name>". This will work only when runtime-flag "veri_cleanup_base_modules" is set.

==== Interfaces with "_default" suffix ====

SystemVerilog interfaces can be used in any of the following ways :

*  As interface instantiations.
*  As interface ports.
*  As virtual interfaces.
*  As hierarchical names.

Interface is always copied with '_default' suffix since we do not know for sure if there is a virtual interface in the hierarchy below which is yet to be processed.

The copied interface (with '_default' suffix) will be the one that is elaborated and specified in the virtual interface declaration, interface instance, or top-level module port.  Every instantiated module containing interface type ports will also be copied during static elaboration since its interface port names may have been modified as well.

Virtual interfaces can appear in many different parts of a design, and may or may not be associated with interface instances. Virtual interfaces are not stored in Verific's pseudo-tree, so after static elaboration we do not know whether an interface is used as a virtual interface or not, or where it is being used.  Without this knowledge, we cannot arbitrarily change all the references of an interface from  '<interface_name>_default'  to  '<interface_name> because the references may become invalid. Because of this, we do not have flags to remove the '_default' from the interface names as we do for modules.

The '_default_<n>' suffix may also be added due to the presence of hierarchical references in an interface or bind statements containing interface instantiations.

Verific VIPER #19809 has more details.

==== Modules with "_<N>" suffix ====

Modules can be copied with _<N> suffix for hier-ref present/going via them.

Example:
 <nowiki>
module top ;
    test      t  () ;
    test #(0) t0 () ;
    test #(1) t1 () ;
    test #(2) t2 () ;
endmodule
 
module test ;
    parameter P = 0 ;
    wire [P:0] sig ;
    bot b1 () ;
endmodule
 
module bot ;
    initial $display(test.sig) ;
endmodule
 </nowiki>

Here "bot" has to be copied 3 times with _<N> suffix so that they can point to 3 different "sig" of 3 different sizes.
The same can happen for bind statements as well. Different bind instances can be added to different instances of the same module.

==== Modules with "_copy<N>" suffix ====

Modules can be copied with _copy<N> suffix when a module with _<N> is already present in the same library.

Example:
 <nowiki>
module top ;
    test      t  () ;
    test #(0) t0 () ;
    test #(1) t1 () ;
    test #(2) t2 () ;
endmodule
 
module test ;
    parameter P = 0 ;
    wire [P:0] sig ;
    bot b1 () ;
endmodule
 
module bot ;
    initial $display(test.sig) ;
endmodule
 
module bot_2 ;
endmodule
 </nowiki>

Here "bot_2" already exists and hence the copied "bot" which we wanted to name "bot_2" is renamed to "bot_copy<N>".

==== Modules with "_<N>_<M>" suffix ====

Modules can even be copied with _<N>_<M> suffix in some corner cases with name conflict as well as hier-refs.

Example:
 <nowiki>
module top ;
    test      t  () ;
    test #(0) t0 () ;
    test #(1) t1 () ;
    test #(2) t2 () ;
    bot_2 b1 () ;
endmodule
 
module test ;
    parameter P = 0 ;
    wire [P:0] sig ;
    bot b1 () ;
endmodule
 
module bot ;
    initial $display(test.sig) ;
endmodule
 
module bot_2 ;
    generate
        test #(2) t1 () ;
    endgenerate
endmodule
 </nowiki>

Here instead of "bot_copy<N>", one of the elaborated versions of "bot" which is to be renamed to "bot_2" is actually named as "bot_2_1".

==== How to get the original name or the original module ====

APIs to retrieve the original name of the module or to get the original module itself (only when the original module is available):

 <nowiki>
VeriModule::GetOriginalModuleName()
VeriModule::GetOriginalModule()
 </nowiki>