How Verific elaborator handles blackboxes/unknown boxes - Revision history

Hoa at 23:00, 21 April 2021

2021-04-21T23:00:52Z

Hoa at 18:26, 23 December 2020

2020-12-23T18:26:02Z

Hoa at 17:45, 23 December 2020

2020-12-23T17:45:05Z

Hoa at 17:00, 23 December 2020

2020-12-23T17:00:06Z

Hoa at 06:51, 23 December 2020

2020-12-23T06:51:42Z

Hoa at 06:50, 23 December 2020

2020-12-23T06:50:30Z

Hoa at 06:46, 23 December 2020

2020-12-23T06:46:10Z

Hoa: Created page with ">> This page is in progress << '''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.' Sometimes in the Verilog netl..."

2020-12-23T01:45:55Z

Created page with ">> This page is in progress << '''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.' Sometimes in the Verilog netl..."

New page

>> This page is in progress <<

'''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.' Sometimes in the Verilog netlist output, I see modules with names such as 'foo_NamedPorts' or 'bar_OrderedPorts.' They are not in the original RTL design. Where do they come from?'''

First, please read the article on [[Black box, empty box, and unknown box]].

When the elaborator see an instance of an unknown box, it creates a dummy Netlist object so that it can create an Instance object to instantiate it in the Netlist that owns the instance.

Verilog module instantiations can be in two styles: ordered port connections and named port connections.

(1) Ordered port connection example: bb_mox b1 (a, b, c) ;
(2) Named port connection example: bb_mod b2 (.clk(d), .data(e), .out(f)) ;

For such instances of unknown modules, the elaborator has no info about the size, type and direction of the ports.

For (2) it has names of some ports (there may be some more ports which are unconnected).
For (1) it doesn't even have the name of any of the ports.

Also note that port connections for (2) may not be in the order of declaration. For example, bb_mod can very well be declared as: "module bb_mod(out, clk, data)." Therefore, even the module name is the same, the elaborator cannot use the same dummy netlist for both (1) and (2).

Thus it has to create two Netlists with name "OrderedPorts" for (1) and "NamedPorts" for (2). Both are under the Cell with name "bb_mod" and have direction of all ports set to inout.

Also port names for (1) have made-up names p1, p2, etc..

Now when both style of the instances are used in the same design, there are multiple instances of the netlists from same cell but they are actually different (since there is no actual definition).

In writing out the Netlist output file, the writer writes out the first instance with the name of the cell ('foo'), but the instances of other style is written with the name of the netlist appended with the cell name ('foo_OrderedPorts') to avoid conflict and to make the output legal/correct.

To avoid this you can use any of the following:
a) Read in a stub of the module (with only port dir/size) before you call elaborate.
b) You can even read in the stub after elaboration which will overwrite the created dummy netlists.
c) Hook up your own routine which we query to get the port names/size/direction etc using:
static void veri_file::RegisterIsLibertyCellDefinedCB(unsigned (*cb)(const char *cell_name)) ;
static void veri_file::RegisterLibertyCellInterfaceNCB(unsigned (*cb)(const char *cell_name, const char *port_name, int &left_bound, int &right_bound, unsigned &port_direction, unsigned ignore_case)) ;
static void veri_file::RegisterLibertyCellInterfacePCB(const char * (*cb)(const char *cell_name, unsigned port_pos, int &left_bound, int &right_bound, unsigned &port_direction, unsigned ignore_case)) ;
static void veri_file::RegisterLibertyCellInterfaceNames(Set * (*cb)(const char *cell_name)) ;
static void veri_file::RegisterLibertySingleBitBusPort(unsigned (*cb)(const char *cell_name, const char *port_name, unsigned ignore_case)) ;
You have to define your own function and hook them up. We pass cell_name, port_name, port_pos and ignore_case when appropriate.
You have to set/return left_bound, right_bound and port_direction accordingly.

@@ Line 41: / Line 41: @@
   <nowiki>
 module test ();
-   bb_mod b2 (.clk(m), .data(n), .out(q)) ;
+   unknown_mod b2 (.clk(m), .data(n), .out(q)) ;
-   bb_mod b1 (a, b, c) ;
+   unknown_mod b1 (a, b, c) ;
 endmodule
   </nowiki>
@@ Line 58: / Line 58: @@
      wire b;   // test.v(3)
      wire c;   // test.v(3)
-     bb_mod b2 (.clk(m), .data(n), .out(q));   // test.v(2)
+     unknown_mod b2 (.clk(m), .data(n), .out(q));   // test.v(2)
-     bb_mod_OrderedPorts b1 (a, b, c);   // test.v(3)
+     unknown_mod_OrderedPorts b1 (a, b, c);   // test.v(3)
 endmodule
 //
-// Verific Verilog Description of module bb_mod
+// Verific Verilog Description of module unknown_mod
 //
-module bb_mod (clk, data, out);
+module unknown_mod (clk, data, out);
      inout clk;
      inout data;
@@ Line 73: / Line 73: @@
 //
-// Verific Verilog Description of module bb_mod_OrderedPorts
+// Verific Verilog Description of module unknown_mod_OrderedPorts
 //
-module bb_mod_OrderedPorts (p_0, p_1, p_2);
+module unknown_mod_OrderedPorts (p_0, p_1, p_2);
      inout p_0;
      inout p_1;

← Older revision		Revision as of 17:45, 23 December 2020
Line 1:		Line 1:
−	'''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.' Sometimes in the Verilog netlist output, I see modules with names such as 'foo_NamedPorts' or 'bar_OrderedPorts.' They are not in the original RTL design. Where do they come from?'''	+	'''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.'<br />Sometimes in the Verilog netlist output, I see modules with names such as 'foo_NamedPorts' or 'bar_OrderedPorts.'<br />They are not in the original RTL design. Where do they come from?'''

	First, please read the article on [[Black box, empty box, and unknown box]].		First, please read the article on [[Black box, empty box, and unknown box]].

@@ Line 20: / Line 20: @@
 Thus it has to create two Netlists with name "NamedPorts" for (1) and "OrderedPorts" for (2). Both are under the Cell with name "bb_mod" and have direction of all Ports set to inout.
-Also port names for (2) have made-up names p1, p2, etc..
+Also port names for (2) have made-up names p_0, p_1, etc..
 Now when both style of the instances are used in the same design, there are multiple Instances of the Netlists from same Cell but they are actually different (since there is no actual definition).
@@ Line 37: / Line 37: @@
 To use the above APIs, you have to define your own function and hook them up. We pass cell_name, port_name, port_pos and ignore_case when appropriate. You also have to set/return left_bound, right_bound and port_direction accordingly.

@@ Line 3: / Line 3: @@
 First, please read the article on  [[Black box, empty box, and unknown box]].
-When the elaborator see an instance of an unknown box, it creates a dummy Netlist object so that it can create an Instance object to instantiate it in the Netlist that owns the instance.
+When the elaborator sees an instance of an unknown box, it creates a dummy Netlist object so that it can create an Instance object to instantiate it in the Netlist that owns the instance.
 Verilog module instantiations can be in two styles: ordered port connections and named port connections.

@@ Line 1: / Line 1: @@
 '''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.' Sometimes in the Verilog netlist output, I see modules with names such as 'foo_NamedPorts' or 'bar_OrderedPorts.' They are not in the original RTL design. Where do they come from?'''
-First, please read the article on  [[Database/C++: Black box, empty box, and unknown box]].
+First, please read the article on  [[Black box, empty box, and unknown box]].
 When the elaborator see an instance of an unknown box, it creates a dummy Netlist object so that it can create an Instance object to instantiate it in the Netlist that owns the instance.

@@ Line 1: / Line 1: @@
 '''Q: After RTL elaboration on a Verilog design, I see Netlist with names such as 'NamedPorts' or 'OrderedPorts.' Sometimes in the Verilog netlist output, I see modules with names such as 'foo_NamedPorts' or 'bar_OrderedPorts.' They are not in the original RTL design. Where do they come from?'''
@@ Line 9: / Line 7: @@
 Verilog module instantiations can be in two styles: ordered port connections and named port connections.
-(1) Ordered port connection example: bb_mox b1 (a, b, c) ;
+# Named port connection example:
-(2) Named port connection example: bb_mod b2 (.clk(d), .data(e), .out(f)) ;
+ bb_mod b2 (.clk(d), .data(e), .out(f)) ;
 For such instances of unknown modules, the elaborator has no info about the size, type and direction of the ports.
-For (2) it has names of some ports (there may be some more ports which are unconnected).
+For (1) it has names of some ports (there may be some more ports which are unconnected).<br />For (2) it doesn't even have the name of any of the ports.
-For (1) it doesn't even have the name of any of the ports.
-Also note that port connections for (2) may not be in the order of declaration. For example, bb_mod can very well be declared as: "module bb_mod(out, clk, data)." Therefore, even the module name is the same, the elaborator cannot use the same dummy netlist for both (1) and (2).
+Also note that port connections for (1) may not be in the same port expression order as in the declaration of the (unavailable) instantiated module. For example, bb_mod can very well be declared as: "module bb_mod(out, clk, data)." Therefore, even the module name is the same, the elaborator cannot use the same dummy netlist for both (1) and (2).
-Thus it has to create two Netlists with name "OrderedPorts" for (1) and "NamedPorts" for (2). Both are under the Cell with name "bb_mod" and have direction of all ports set to inout.
+Thus it has to create two Netlists with name "NamedPorts" for (1) and "OrderedPorts" for (2). Both are under the Cell with name "bb_mod" and have direction of all Ports set to inout.
-Also port names for (1) have made-up names p1, p2, etc..
+Also port names for (2) have made-up names p1, p2, etc..
-Now when both style of the instances are used in the same design, there are multiple instances of the netlists from same cell but they are actually different (since there is no actual definition).
+Now when both style of the instances are used in the same design, there are multiple Instances of the Netlists from same Cell but they are actually different (since there is no actual definition).
 In writing out the Netlist output file, the writer writes out the first instance with the name of the cell ('foo'), but the instances of other style is written with the name of the netlist appended with the cell name ('foo_OrderedPorts') to avoid conflict and to make the output legal/correct.
 To avoid this you can use any of the following:
-  a) Read in a stub of the module (with only port dir/size) before you call elaborate.
+# Read in a stub of the module (with only port type/direction/size) before elaborating the design.
-  b) You can even read in the stub after elaboration which will overwrite the created dummy netlists.
+# You can also read in the stub after elaboration which will overwrite the created dummy Netlists.
-  c) Hook up your own routine which we query to get the port names/size/direction etc using:
+# Hook up your own routine which we query to get the port names/size/direction, etc. using these APIs:
-        static void veri_file::RegisterIsLibertyCellDefinedCB(unsigned (*cb)(const char *cell_name)) ;
+ - static void veri_file::RegisterIsLibertyCellDefinedCB(unsigned (*cb)(const char *cell_name)) ;
-        static void veri_file::RegisterLibertyCellInterfaceNCB(unsigned (*cb)(const char *cell_name, const char *port_name, int &left_bound, int &right_bound, unsigned &port_direction, unsigned ignore_case)) ;
+ - static void veri_file::RegisterLibertyCellInterfaceNCB(unsigned (*cb)(const char *cell_name, const char *port_name, int &left_bound, int &right_bound, unsigned &port_direction, unsigned ignore_case)) ;
-        static void veri_file::RegisterLibertyCellInterfacePCB(const char * (*cb)(const char *cell_name, unsigned port_pos, int &left_bound, int &right_bound, unsigned &port_direction, unsigned ignore_case)) ;
+ - static void veri_file::RegisterLibertyCellInterfacePCB(const char * (*cb)(const char *cell_name, unsigned port_pos, int &left_bound, int &right_bound, unsigned &port_direction, unsigned ignore_case)) ;
-        static void veri_file::RegisterLibertyCellInterfaceNames(Set * (*cb)(const char *cell_name)) ;
+ - static void veri_file::RegisterLibertyCellInterfaceNames(Set * (*cb)(const char *cell_name)) ;
-        static void veri_file::RegisterLibertySingleBitBusPort(unsigned (*cb)(const char *cell_name, const char *port_name, unsigned ignore_case)) ;
+ - static void veri_file::RegisterLibertySingleBitBusPort(unsigned (*cb)(const char *cell_name, const char *port_name, unsigned ignore_case)) ;
-You have to define your own function and hook them up. We pass cell_name, port_name, port_pos and ignore_case when appropriate.
-You have to set/return left_bound, right_bound and port_direction accordingly.
+To use the above APIs, you have to define your own function and hook them up. We pass cell_name, port_name, port_pos and ignore_case when appropriate. You also have to set/return left_bound, right_bound and port_direction accordingly.