VERILOG CODING STYLES FOR IMPROVED SIMULATION EFFICIENCY

Clifford E. Cummings [email protected] / www.sunburst-design.com Sunburst Design, Inc. 14314 SW Allen Blvd. PMB 501 Beaverton, OR 97005

INTERNATIONAL CADENCE USER GROUP CONFERENCE OCTOBER 5-9, 1997 SAN DIEGO, CALIFORNIA

Verilog Coding Styles for Improved Simulation Efficiency

Clifford E. Cummings Sunburst Design, Inc. 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97007 Phone: 503-641-8446 Email: [email protected] Abstract
This paper details different coding styles and their impact on Verilog-XL simulation efficiency. 3.1 Case Vs. If Efficiency Summary The results in Table 1 show that, using Verilog-XL, this 8-item case structure took about the same amount of memory to implement as the if/else-if structure but the case statement was about 6% faster.
module CaseMux8 (y, i, sel); output y; input [7:0] i; input [2:0] sel; reg wire wire y; [7:0] i; [2:0] sel; sel) i[0]; i[1]; i[2]; i[3]; i[4]; i[5]; i[6]; i[7];

1. Introduction
What are some of the more optimal ways to code Verilog models and testbenches to shorten simulation times? This paper is a collection of interesting coding style comparisons that have been run on Verilog-XL.

2. Verilog Efficiency Testing

The intent of this paper is to help identify which Verilog coding styles are more efficient than others; thereby, increasing design and simulation efficiency. All of the Verilog benchmarks in this paper are intended to show the efficiency of how specific coding styles run on the same simulator. This paper is not intended to be a benchmark comparison between different simulators. All of the benchmarks were run on a Sparc 5, running Solaris 2.5, with 32MB of memory and 500MB of swap space. Verilog-XL, version 2.21, compiled with Undertow version 5.3.3, was used for these benchmarks. Note: over time, measured efficiency will likely change as newer versions of the same simulator are introduced and as simulators become more efficient.

always @(i or case (sel) 3'd0: y = 3'd1: y = 3'd2: y = 3'd3: y = 3'd4: y = 3'd5: y = 3'd6: y = 3'd7: y = endcase endmodule

Figure 1

3. Case Statements Vs. Large If/Else-If Structures

Question: Is there a simulation efficiency difference in coding large case statements as equivalent if/else-if statements? The testcase for this benchmark is a synthesizable 8-to-1 multiplexer written as both a case statement and as a large if/else-if construct. Figure 1 shows the code for the case-statement multiplexer, Figure 2 shows the code for the equivalent if/else-if-statement multiplexer.

module IfMux8 (y, i, sel); output y; input [7:0] i; input [2:0] sel; reg wire wire y; [7:0] i; [2:0] sel;

always @(i or sel) if (sel == 3'd0) else if (sel == 3'd1) else if (sel == 3'd2) else if (sel == 3'd3) else if (sel == 3'd4) else if (sel == 3'd5) else if (sel == 3'd6) else if (sel == 3'd7) endmodule

y y y y y y y y

= = = = = = = =

i[0]; i[1]; i[2]; i[3]; i[4]; i[5]; i[6]; i[7];

Figure 2 International Cadence Users Group 1997 Rev 1.1 2 Verilog Coding Styles For Improved Simulation Efficiency

Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 CaseMux8 IfMux8

Data Structure (bytes of memory) 92252 92912 Table 1

Memory Usage Percentages 100.00% 100.72%

Simulation CPU Time (in seconds) 1209.3 1282.0

CPU Simulation Percentages 100.00% 106.01%

4. Begin-End Statements
Question: Is there a simulation efficiency difference when extra begin-end pairs are added to Verilog models? The testcase for this benchmark is a synthesizable D flipflop with asynchronous reset. In Figure 3 the synthesizable flip-flop was written with no begin-end statements in the always block (they are not needed for this model). In Figure 4, the same flip-flop was written with three unnecessary begin-end statements. 1000 flipflops were then instantiated into a testbench and simulated.

4.1 Begin-End Efficiency Summary The results in Table 2 show that, using Verilog-XL, the flip-flop with three extra begin-end statements took about 6% more memory to implement and about 6% more time to simulate as the flip-flop with no begin-end statements.

// Includes unneeded begin-end pairs module dff (q, d, clk, rst); output q; input d, clk, rst; reg q; always @(posedge clk or posedge rst) begin if (rst == 1) begin q = 0; end else begin q = d; end end endmodule

// Removed unneeded begin-end pairs module dff (q, d, clk, rst); output q; input d, clk, rst; reg q; always @(posedge clk or posedge rst) if (rst == 1) q = 0; else q = d; endmodule

Figure 3

Figure 4

Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 Undertow 5.3.3 nobegin begin

Data Structure (bytes of memory) 4677676 4953264

Memory Usage Percentages 100% 105.89%

Simulation CPU Time (in seconds) 9403.2 9960.4

CPU Simulation Percentages 100% 105.93%

Table 2

International Cadence Users Group 1997 Rev 1.1

Verilog Coding Styles For Improved Simulation Efficiency

5. `define Vs. Parameters

Question: What simulation efficiency difference is there between using `define macros and parameters? How is parameter efficiency affected by redefining parameters using parameter redefinition in the model instantiation and by using defparam statements? The testcases for this benchmark were models with nine parameter delays (Figure 5) and nine `define-macro delays (Figure 6). Testbenches were created with defined-macros (Figure 7), defparam statements (Figure 8) and #-parameter redefinition (Figure 9).

5.1 Define & Parameter Efficiency Summary The results in Table 3 show that, parameter redefinition and defparams occupy about 25% - 35% more memory than do `define statements.

module paramchk (y, i, en); output [9:0] y; input i, en; parameter Tr_min = 2; parameter Tr_typ = 5; parameter Tr_max = 8; parameter Tf_min = 1; parameter Tf_typ = 4; parameter Tf_max = 7; parameter Tz_min = 3; parameter Tz_typ = 6; parameter Tz_max = 9; bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) bufif1 #(Tr_min:Tr_typ:Tr_max,Tf_min:Tf_typ:Tf_max,Tz_min:Tz_typ:Tz_max) endmodule b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 (y[9],i,en); (y[8],i,en); (y[7],i,en); (y[6],i,en); (y[5],i,en); (y[4],i,en); (y[3],i,en); (y[2],i,en); (y[1],i,en); (y[0],i,en);

Figure 5

module definechk (y, i, en); output [9:0] y; input i, en; bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) bufif1 #(`Tr_min:`Tr_typ:`Tr_max,`Tf_min:`Tf_typ:`Tf_max,`Tz_min:`Tz_typ:`Tz_max) endmodule b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 (y[9], (y[8], (y[7], (y[6], (y[5], (y[4], (y[3], (y[2], (y[1], (y[0], i, i, i, i, i, i, i, i, i, i, en); en); en); en); en); en); en); en); en); en);

Figure 6 International Cadence Users Group 1997 Rev 1.1 4 Verilog Coding Styles For Improved Simulation Efficiency

`define `define `define `define `define `define `define `define `define

Tr_min Tr_typ Tr_max Tf_min Tf_typ Tf_max Tz_min Tz_typ Tz_max

2 5 8 1 4 7 3 6 9

`define CNT 1000000 `define cycle 20 `timescale 1ns / 1ns module tb_define; wire [9:0] y9, y8, y7, y6, y5, y4, y3, y2, y1, y0; reg i, en; reg clk; definechk definechk definechk definechk definechk definechk definechk definechk definechk definechk i9 i8 i7 i6 i5 i4 i3 i2 i1 i0 (y9, (y8, (y7, (y6, (y5, (y4, (y3, (y2, (y1, (y0, i, i, i, i, i, i, i, i, i, i, en); en); en); en); en); en); en); en); en); en);

initial begin clk = 0; forever #(`cycle/2) clk = ~clk; end initial begin i = 0; en = 1; repeat (`CNT) begin @(negedge clk) i = ~i; end @(negedge clk) i = ~i; repeat (`CNT) begin @(negedge clk) en = ~en; end @(negedge clk) i = ~i; repeat (`CNT) begin @(negedge clk) en = ~en; end `ifdef RUN @(negedge clk) $finish(2); `else @(negedge clk) $stop(2); `endif end endmodule

Figure 7

International Cadence Users Group 1997 Rev 1.1

Verilog Coding Styles For Improved Simulation Efficiency

`define CNT 1000000 `define cycle 20 `timescale 1ns / 1ns module tb_defparam; wire [9:0] y9, y8, y7, y6, y5, y4, y3, y2, y1, y0; reg i, en, clk; paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam paramchk defparam defparam defparam i9 (y9, i, en); i9.Tr_min=0; defparam i9.Tf_min=3; defparam i9.Tz_min=6; defparam i8 (y8, i, en); i8.Tr_min=0; defparam i8.Tf_min=3; defparam i8.Tz_min=6; defparam i7 (y7, i, en); i7.Tr_min=0; defparam i7.Tf_min=3; defparam i7.Tz_min=6; defparam i6 (y6, i, en); i6.Tr_min=0; defparam i6.Tf_min=3; defparam i6.Tz_min=6; defparam i5 (y5, i, en); i5.Tr_min=0; defparam i5.Tf_min=3; defparam i5.Tz_min=6; defparam i4 (y4, i, en); i4.Tr_min=0; defparam i4.Tf_min=3; defparam i4.Tz_min=6; defparam i3 (y3, i, en); i3.Tr_min=0; defparam i3.Tf_min=3; defparam i3.Tz_min=6; defparam i2 (y2, i, en); i2.Tr_min=0; defparam i2.Tf_min=3; defparam i2.Tz_min=6; defparam i1 (y1, i, en); i1.Tr_min=0; defparam i1.Tf_min=3; defparam i1.Tz_min=6; defparam i0 (y0, i, en); i0.Tr_min=0; defparam i0.Tf_min=3; defparam i0.Tz_min=6; defparam

i9.Tr_typ=1; i9.Tf_typ=4; i9.Tz_typ=7; i8.Tr_typ=1; i8.Tf_typ=4; i8.Tz_typ=7; i7.Tr_typ=1; i7.Tf_typ=4; i7.Tz_typ=7; i6.Tr_typ=1; i6.Tf_typ=4; i6.Tz_typ=7; i5.Tr_typ=1; i5.Tf_typ=4; i5.Tz_typ=7; i4.Tr_typ=1; i4.Tf_typ=4; i4.Tz_typ=7; i3.Tr_typ=1; i3.Tf_typ=4; i3.Tz_typ=7; i2.Tr_typ=1; i2.Tf_typ=4; i2.Tz_typ=7; i1.Tr_typ=1; i1.Tf_typ=4; i1.Tz_typ=7; i0.Tr_typ=1; i0.Tf_typ=4; i0.Tz_typ=7;

defparam i9.Tr_max=2; defparam i9.Tf_max=5; defparam i9.Tz_max=8; defparam i8.Tr_max=2; defparam i8.Tf_max=5; defparam i8.Tz_max=8; defparam i7.Tr_max=2; defparam i7.Tf_max=5; defparam i7.Tz_max=8; defparam i6.Tr_max=2; defparam i6.Tf_max=5; defparam i6.Tz_max=8; defparam i5.Tr_max=2; defparam i5.Tf_max=5; defparam i5.Tz_max=8; defparam i4.Tr_max=2; defparam i4.Tf_max=5; defparam i4.Tz_max=8; defparam i3.Tr_max=2; defparam i3.Tf_max=5; defparam i3.Tz_max=8; defparam i2.Tr_max=2; defparam i2.Tf_max=5; defparam i2.Tz_max=8; defparam i1.Tr_max=2; defparam i1.Tf_max=5; defparam i1.Tz_max=8; defparam i0.Tr_max=2; defparam i0.Tf_max=5; defparam i0.Tz_max=8;

initial begin clk = 0; forever #(`cycle/2) clk = ~clk; end initial begin i = 0; en = 1; repeat (`CNT) @(negedge clk) i = ~i; @(negedge clk) i = ~i; repeat (`CNT) @(negedge clk) en = ~en; @(negedge clk) i = ~i; repeat (`CNT) @(negedge clk) en = ~en; `ifdef RUN @(negedge clk) $finish(2); `else @(negedge clk) $stop(2); `endif end endmodule

Figure 8

International Cadence Users Group 1997 Rev 1.1

Verilog Coding Styles For Improved Simulation Efficiency

`define CNT 1000000 `define cycle 20 `timescale 1ns / 1ns module tb_param; wire [9:0] y9, y8, y7, y6, y5, y4, y3, y2, y1, y0; reg i, en; reg clk; paramchk paramchk paramchk paramchk paramchk paramchk paramchk paramchk paramchk paramchk #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) #(0,1,2,3,4,5,6,7,8) i9 i8 i7 i6 i5 i4 i3 i2 i1 i0 (y9, (y8, (y7, (y6, (y5, (y4, (y3, (y2, (y1, (y0, i, i, i, i, i, i, i, i, i, i, en); en); en); en); en); en); en); en); en); en);

initial begin clk = 0; forever #(`cycle/2) clk = ~clk; end initial begin i = 0; en = 1; repeat (`CNT) begin @(negedge clk) i = ~i; end @(negedge clk) i = ~i; repeat (`CNT) begin @(negedge clk) en = ~en; end @(negedge clk) i = ~i; repeat (`CNT) begin @(negedge clk) en = ~en; end `ifdef RUN @(negedge clk) $finish(2); `else @(negedge clk) $stop(2); `endif end endmodule

Figure 9

Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 define paramredef defparam

Data Structure (bytes of memory) 162448 201236 220568

Memory Usage Percentages 100.00% 123.88% 135.78%

Simulation CPU Time (in seconds) 1436.9 1427.2 1420.0

CPU Simulation Percentages 100.00% 99.32% 98.82%

Table 3

International Cadence Users Group 1997 Rev 1.1

Verilog Coding Styles For Improved Simulation Efficiency

6. Grouping of Assignments Within Always Blocks

Question: Is there a penalty for splitting assignments into multiple always blocks as opposed to grouping the same assignments into fewer always blocks? The testcase for this benchmark is a conditionally complied set of four assignments in four separate always blocks, or the same four assignments in a single always block (Figure 10). 6.1 Always Block Grouping Efficiency Summary The results in Table 4 show that, four assignments in four separate always blocks is about 34% slower than placing the same assignments in a single always block

`define ICNT 10000000 `define cycle 100 `timescale 1ns / 100ps module AlwaysGroup; reg clk; reg [7:0] a, b, c, d, e; initial begin clk = 0; forever #(`cycle) clk = ~clk; end initial begin a = 8'haa; forever @(negedge clk) a = ~ a; end initial begin repeat(`ICNT) @(posedge clk); `ifdef RUN @(posedge clk) $finish(2); `else @(posedge clk) $stop(2); `endif end `ifdef GROUP4 // Group of four always blocks always @(posedge clk) begin b <= a; end always @(posedge clk) begin c <= b; end always @(posedge clk) begin d <= c; end always @(posedge clk) begin e <= d; end `else // // always b <= c <= d <= e <= end `endif endmodule Four assignments grouped into a single always block @(posedge clk) begin a; b; c; d;

Figure 10

Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 group1 group4

Data Structure (bytes of memory) 85712 87544

Memory Usage Percentages 100.00% 102.14%

Simulation CPU Time (in seconds) 1196.6 1607.2

CPU Simulation Percentages 100.00% 134.31%

Table 4

International Cadence Users Group 1997 Rev 1.1

Verilog Coding Styles For Improved Simulation Efficiency

7. Port Connections
Question: Is there a penalty for passing data over module ports as opposed to passing data by hierarchical reference? The idea for this benchmark came from a paper presented by Martin Gravenstein[1] of Ford Microelectronics at the 1994 International Verilog Conference. The testcase for this benchmark is a pair of flip-flops. The first flip-flop has no ports and testbench communication with this model was conducted by hierarchical reference. The second flip-flop is a model with normal port communication with a testbench (Figure 11).
`ifdef NOPORTS module PortModels; reg [15:0] q; reg [15:0] d; reg clk, rstN; always @(posedge clk or negedge rstN) if (rstN == 0) q <= 0; else q <= d; endmodule `else module PortModels (q, d, clk, rstN); output [15:0] q; input [15:0] d; input clk, rstN; reg [15:0] q; always @(posedge clk or negedge rstN) if (rstN == 0) q <= 0; else q <= d; endmodule `endif

7.1 Ports/No Ports Efficiency Summary The results in Table 5 show that, communicating with a four-port model as opposed to referencing the ports hierarchically required about 46% more simulation time Model port usage and communication is still recommended; however, passing monitor data over ports would be simulation-time expensive. It is better to reference monitored state and bus data hierarchically These results also suggest that models with extra levels of hierarchy will significantly slow down a simulation

Figure 11

Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 NoPorts Ports

Data Structure (bytes of memory) 90948 89436

Memory Usage Percentages 100.00% 98.34%

Simulation CPU Time (in seconds) 1343.7 1967.4

CPU Simulation Percentages 100.00% 146.42%

Table 5

International Cadence Users Group 1997 Rev 1.1

Verilog Coding Styles For Improved Simulation Efficiency

`define ICNT 10000000 `define cycle 10

8. `timescale Efficiencies
Question: Are there any simulator performance penalties for using a higher precision `timescale during simulation? The testcase for this benchmark is a buffer and inverter with propagation delays that are simulated with a variety of `timescales (Figure 12). 8.1 `timescale Efficiency Summary The results in Table 6 show that, using a `timescale of 1ns/1ps requires about 156% more memory and about 99% more time to simulate than the same model using a timescale of 1ns/1ns.

`ifdef `endif `ifdef `endif `ifdef `endif `ifdef `endif

Time_1ns Time_100ps Time_10ps Time_1ps

`timescale 1ns / 1ns `timescale 1ns / 100ps `timescale 1ns / 10ps `timescale 1ns / 1ps

module TimeModel; reg i; wire [1:2] y; initial begin i = 0; forever #(`cycle) i = ~i; end initial begin repeat(`ICNT) @(posedge i); `ifdef RUN @(posedge i) $finish(2); `else @(posedge i) $stop(2); `endif end buf #(2.201, 3.667) i1 (y[1], i); not #(4.633, 7.499) i2 (y[2], i); endmodule

9. Displaying $time Values

Question: Are there any simulator performance penalties for displaying different $time values to STDOUT during simulation? Do the $time display format specifiers affect simulation performance? The idea for this benchmark came from a paper presented by Jay Lawrence[2] of Cadence at the 1995 ICU. The testcase for this benchmark is a set of different display commands of time values (Figure 13). 9.1 Display $time Efficiency Summary Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 Time_1ns Time_100ps Time_10ps Time_1ps Data Structure (bytes of memory) 83916 83920 92620 214476 Table 6 Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 No_Display One_Display Two_Display Two_Display0 Two_Format0 Two_RtimeFormat0 Data Structure (bytes of memory) 84784 84924 85060 85064 85024 85832 Table 7 International Cadence Users Group 1997 Rev 1.1 10

Figure 12 The results in Table 7 show that, needless display of $time values is very costly in simulation time Memory Usage Percentages 100.00% 100.00% 110.37% 255.58% Simulation CPU Time (in seconds) 1395.0 1459.4 1718.1 2777.8 CPU Simulation Percentages 100.00% 104.62% 123.16% 199.13%

Memory Usage Percentages 100.00% 100.17% 100.33% 100.33% 100.28% 101.24%

Simulation CPU Time (in seconds) 906.6 1297.3 1646.1 1624.5 1348.4 1328.1

CPU Simulation Percentages 100.00% 143.10% 181.57% 179.19% 148.73% 146.49%

Verilog Coding Styles For Improved Simulation Efficiency

`define hcycle 12.5 `define ICNT 1000000 `timescale 1ns / 100ps module DisplayTime; reg clk; time rClkTime, fClkTime; real rRealTime, fRealTime; initial begin clk = 0; forever #(`hcycle) clk = ~clk; end initial begin repeat(`ICNT) @(posedge clk); `ifdef RUN @(posedge clk) $finish(2); `else @(posedge clk) $stop(2); `endif end `ifdef NoDisplay // display with no time values always @(negedge clk) begin fClkTime = $time; $display ("Negedge Clk"); end `endif `ifdef OneDisplay // display with one time value always @(negedge clk) begin fClkTime = $time; $display ("Negedge Clk at %d", fClkTime); end `endif `ifdef TwoDisplay // display with two time values always @(negedge clk) begin fClkTime = $time; $display ("Posedge Clk at %d - Negedge Clk at %d", rClkTime, fClkTime); end `endif `ifdef TwoDisplay0 // display with two time values always @(negedge clk) begin fClkTime = $time; $display ("Posedge Clk at %0d - Negedge Clk at %0d", rClkTime, fClkTime); end `endif `ifdef TwoFormat0 // display with two time values always @(negedge clk) begin fClkTime = $time; $display ("Posedge Clk at %0t - Negedge Clk at %0t", rClkTime, fClkTime); end `endif `ifdef TwoRtimeFormat0 // display with two time values initial $timeformat(-9,2,"ns",15); always @(negedge clk) begin fRealTime = $realtime; $display ("Posedge Clk at %0t - Negedge Clk at %0t", rRealTime,fRealTime); end `endif `ifdef TwoRtimeFormat0 `else `endif endmodule always @(posedge clk) rRealTime = $realtime; always @(posedge clk) rClkTime = $time;

Figure 13 International Cadence Users Group 1997 Rev 1.1 11 Verilog Coding Styles For Improved Simulation Efficiency

10. Clock Oscillators

Question: Are there any significant simulator performance advantages to implementing a clock oscillator using an always block, forever loop or Verilog gate primitives? The testcase for this benchmark are three conditionally compiled clock oscillator implementations, clocking a flip-flop model (Figure 14). 10.1 Clock Oscillator Efficiency Summary The results in Table 8 show that, gate clock oscillators were about %85% slower than behavioral clock oscillators.

`define ICNT 100_000 `define cycle 100 `timescale 1ns / 1ns module Clocks; reg d, rstN; `ifdef ALWAYS reg clk; // driven by a procedural block initial clk = 0; always // free running behave clk #1 #(`cycle/2) clk = ~clk; `endif `ifdef FOREVER reg clk; // driven by a procedural block initial begin clk = 0; forever #(`cycle/2) clk = ~clk; end `endif `ifdef GATE // free running clk #3 (gate) reg start; wire clk; // driven by a gate initial begin start = 0; #(`cycle/2) start = 1; end nand #(`cycle/2) (clk, clk, start); `endif dff d1 (q, d, clk, rstN); initial begin rstN = 0; d = 1; @(negedge clk) rstN = 1; repeat(`ICNT) @(posedge clk); `ifdef RUN @(posedge clk) $finish(2); `else @(posedge clk) $stop(2); `endif end // Veritools Undertow-dumpfile option `ifdef UT initial begin $dumpfile(dump.ut); $vtDumpvars; end `endif endmodule

11. Efficiency - Final Word

Simulation efficiency should not be the only Verilog coding criteria. Code readability, simulation accuracy and displaying timely simulation and diagnostic information might actually increase design productivity. However, reckless use of inefficient coding styles when a more efficient alternative exists is detrimental to simulation productivity. Again, these benchmarks were only run on Verilog-XL. Mileage may vary on other simulators.

12. References
[1] M. Gravenstein, "Modeling Techniques to Support System Level Simulation and a Top-Down Development Methodology," International Verilog HDL Conference Proceedings 1994, pp 43-50 [2] J. Lawrence & C. Ussery, "INCA: A Next-Generation Architecture for Simulation," International Cadence Users Group Conference Proceedings 1995, pp 105109

Figure 14

Sparc5/32MB RAM 491MB Swap Solaris version 2.5 Verilog-XL 2.2.1 - Undertow 5.3.3 Always Forever Gate AlwaysUT ForeverUT GateUT

Data Structure (bytes of memory) 88104 88168 88588 90368 90432 90696

Memory Usage Percentages 100.00% 100.07% 100.55% 102.57% 102.64% 102.94%

Simulation CPU Time (in seconds) 1359.2 1371.0 2562.7 2446.5 2481.5 3448.8

CPU Simulation Percentages 100.00% 100.87% 188.54% 180.00% 182.57% 253.74%

Table 8 International Cadence Users Group 1997 Rev 1.1 12 Verilog Coding Styles For Improved Simulation Efficiency

Author & Contact Information

Cliff Cummings, President of Sunburst Design, Inc., is an independent EDA consultant and trainer with 20 years of ASIC, FPGA and system design experience and ten years of Verilog, synthesis and methodology training experience. Mr. Cummings, a member of the IEEE 1364 Verilog Standards Group (VSG) since 1994, chaired the VSG Behavioral Task Force, which was charged with proposing enhancements to the Verilog language. Mr. Cummings is also a member of the IEEE Verilog Synthesis Interoperability Working Group and the Accellera SystemVerilog Standardization Group Mr. Cummings holds a BSEE from Brigham Young University and an MSEE from Oregon State University. E-mail Address: [email protected] This paper can be downloaded from the web site: www.sunburst-design.com/papers (Data accurate as of January 4th, 2002)

International Cadence Users Group 1997 Rev 1.1

13

Verilog Coding Styles For Improved Simulation Efficiency