SystemVerilog Ports & Data Types For Simple, …

1 HDLCON 20021 SystemVerilog Ports & data Types For Simple, Rev and enhanced HDL ModelingSystemVerilog Ports & data Types For Simple, efficient and enhanced HDLM odelingClifford E. CummingsSunburst Design, introduced an enhanced and abbreviatedmethod to declare module headers, Ports and data Accellera SystemVerilog effort will further enhanceVerilog design by abbreviating the capability toinstantiate modules with implicit port connections andinterface Types . These capabilities and additionalcomplimentary enhancements are detailed in this IntroductionTo declare, or not to declare, that is the question!Verilog-1995[1] had verbose and redundant portdeclaration requirements. Verilog-2001[2] introduced the ANSI-C -style enhancement to remove port declarationredundancy from the Verilog language.

2 AccelleraSystemVerilog proposals will further enhance portdeclarations with the introduction of interfacedeclarations. The evolution of and enhancements toVerilog port declarations are detailed in this those who prefer a requirement that all variablesbe declared before they are used, Verilog-2001introduced a new none option for the`default_nettype compiler directive. The usage anddisadvantages of this enhancement are also discussed inthis Accellera SystemVerilog proposedenhancement is to permit instantiation of modules withimplicit connections. This proposed enhancement is alsodetailed and promoted in this paper concludes with guidelines to increaseVerilog and SystemVerilog design Verilog-1995: verbose module headersVerilog-1995 had the annoying requirement that allmodule Ports had to be declared two or three Verilog-1995 code for the muxff block diagram ofFigure 1 is shown in Example 1 - muxff Block Diagrammodule muxff1 (q, d, clk, ce, rst_n); output q; input d, clk, ce, rst_n; reg q; wire y; always @(posedge clk or negedge rst_n) if (!)

3 Rst_n) q <= 0; else q <= y; assign y = ce ? d : q;endmoduleExample 1 - Verilog-1995 version of the muxff moduleA Verilog-1995 version of this model requires that theq-port be declared three times: once in the module header,once as an output port and once as a reg-variable datatype. The d, clk, ce and rst_n Ports must all bedeclared twice: once in the module header and once asinput data Ports (the port-wire data type declaration isnot required).Verilog-1995 requires that an internal 1-bit wiredriven by a continuous assignment must be declared. They-wire declaration in Example 1 - Verilog-1995 versionof the muxff module is 20022 SystemVerilog Ports & data Types For Simple, Rev and enhanced HDL ModelingTo avoid extra wire and wire-bus declarations that canexist in a large Verilog design, some engineers haveadopted the strategy to make the continuous assignment inthe wire declaration itself, as shown in Example 2[3].

4 Module muxff2 (q, d, clk, ce, rst_n); output q; input d, clk, ce, rst_n; reg q; // Embedded wire declaration to // eliminate the need for separate wire // declaration and assign statement wire y = ce ? d : q; always @(posedge clk or negedge rst_n) if (!rst_n) q <= 0; else q <= y;endmoduleExample 2 - Verilog-1995 version of the muxff modulewith combined wire declaration & assignmentThe only disadvantage to making net-assignmentdeclarations in a design is that the declarations tend to bedispersed throughout the RTL code, which seemssomewhat strange. My own preference is to make alldeclarations at the top of the module and then makeassignments where appropriate throughout the RTL code;however, making the dispersed net-assignmentdeclarations throughout the RTL code is a reasonablemeans to reduce all of the extra net declarations in amodel, a goal that I only other problem associated with making net-assignment declarations is when a right-hand-sidevariable is required in an assignment before it is those cases, the separate net or net-bus declaration requirement to make all of the extra port and extranet declarations seemed to be both verbose Verilog-2001.

5 ANSI-C style portsVerilog-2001 introduced an abbreviated module portdeclaration enhancement, often referred to as ANSI-C style port declarations, where each module port could bedeclared just once and include the port position, portdirection and port data type all in a single Verilog-2001 code for the muxff block diagram ofFigure 1 is shown in Example muxff3 ( output reg q, input d, clk, ce, rst_n); always @(posedge clk or negedge rst_n) if (!rst_n) q <= 0; else q <= y; assign y = ce ? d : q;endmoduleExample 3 - Verilog-2001 version of the muxff moduleThe Verilog-2001 version of this model has combinedthe q port-header, port-direction and data type into asingle declaration. The other Ports have similarly beencombined into a single port-header, port-directiondeclaration (the port-wire data type declaration is againnot required).

6 Also note that the y-wire declaration is not required inthe Verilog-2001 version of this model. Verilog-2001internal wire declaration requirements are discussed inthe next Verilog-2001: `default_nettype noneAs noted in section 2, 1-bit internal wires driven fromcontinuous assignments had to be explicitly declared inVerilog-1995. Verilog-2001 removed this inconsistencyfrom the Verilog also introduced the`default_nettype compiler directive option none. This option forces Verilog-2001-compliant compilers torequire that all wire declarations be explicitly engineers prefer the requirement that all wiredeclarations be explicitly made while others would preferto do away with the additional verbiage and potentialsource of misspelled identifiers and default, the implied net type of a module is Verilog-1995 Standard allowed a different default nettype to be specified by adding the compiler directive`default_nettype and then selecting an argumentfrom one of the following list: wire, tri, tri0, wand,triand, tri1, wor, trior and added a new `default_nettypeoption, none.

7 Specifying a none option tells thecompiler that all net variables must be declared and thatno default type is debatable intent of this option is to assistengineers in finding typos more easily since everyidentifier in a design must have a the circuit of Figure 2. This is the intendedlogic for a simple 20023 SystemVerilog Ports & data Types For Simple, Rev and enhanced HDL ModelingFigure 2 - Test-module intended logicThe Verilog code of Example 4 was intended toimplement the circuit of Figure 2, but two commonmistakes were made: (1) the output of the buffer waslabeled outl (letter l ) instead of out1 (digit 1), and(2) the input of the inverter was labeled outO (letter O )instead of out0 (digit 0). With implicit wire data Types ,this circuit compiles without error but will simulateincorrectly due to two disconnects in the circuit as shownin Figure testmod1( output out1, out1_n, input in1, in2); and u1 (out0, in1, in2); // Typo: should be out1 (1 not l) buf u2 (outl, out0); // Typo: should be out0 (0 not O) not u3 (out1_n, outO);endmoduleExample 4 - Verilog testmod1code with no`default_nettype compiler directiveFigure 3 - Verilog testmod1 actual logicThe Verilog code of Example 5 includes the newVerilog-2001 option none for the compiler directive,` design will fail compilation with two syntaxerrors indicating that the identifiers outl and outO have not been declared (see Figure 4).

8 Because the errorswere caught during compilation instead of simulation, thetheory is that this design is easier to debug.`default_nettype nonemodule testmod2( output wire out1, out1_n, input wire in1, in2); wire out0; and u1 (out0, in1, in2); // Typo: should be out1 (1 not l) buf u2 (outl, out0); // Typo: should be out0 (0 not O) not u3 (out1_n, outO);endmoduleExample 5 - Verilog testmod2 code with `default_nettypenone compiler directiveFigure 4 - Verilog testmod2 syntax-error logicUnfortunately, additional declarations provideadditional opportunities to introduce errors. A problemwith the Example 6 Verilog code is that the model isactually correct but in the process of adding the additionalwire declarations to satisfy the `default_nettypenone option, three typos actually occurred in the wiredeclarations (outl, ou1_n and outO).

9 This design will fail compilation with three syntaxerrors indicating that the identifiers out1, out1_n and out0 have not been declared (see Figure 5). Thesethree identifiers are actually correct but the declarationsfor these identifiers are wrong. The error messages haveactually hidden the real errors in this design, whichoccurred in the declarations.`default_nettype nonemodule testmod3(out1, out1_n, in1, in2); output out1, out1_n; input in1, in2; wire outl, ou1_n; // Typos wire in1, in2;HDLCON 20024 SystemVerilog Ports & data Types For Simple, Rev and enhanced HDL modeling wire outO; // Typo and u1 (out0, in1, in2); buf u2 (out1, out0); not u3 (out1_n, out0);endmoduleExample 6 - Verilog testmod3 code with declarationerrorsFigure 5 - Verilog testmod3 correct logic (but does notcompile)VHDL has a similar requirement that all identifiers,including 1-bit signals, must be declared.

10 My experiencein doing top-level VHDL ASIC designs has proven to befrustrating because of this doing large VHDL designs, I discovered that Ispent almost as much time in the top-level blocksdebugging pages of signal declarations as I did debuggingactual RTL experience has been that adding pages ofdeclarations is almost as error prone as doing RTL design,that adding all of the declarations can be very verbose andthat error messages can be very confusing (indicating asyntax error in the error-free RTL code while hiding thefact that the error is in the declaration).Although finding typos before simulation is desirable,a more reasonable approach to the problem would be acompiler or lint tool that could scan RTL source code toinsure that each identifier has at least one driving sourceand one receiver.