Verilog (IEEE 1364) is a hardware description language (HDL) that can be used to model electric systems for simulation and hardware synthesis and verification.

• reg keyword does not mean Register : Here is something to be cleared up right away when learning Verilog reg is just a variable. In fact the type of the signal that is declared by using ref is called a variable in later versions of Verilog because the the name is so confusing. So, don't let yourself be confused by the name, reg does not necessarily register manifest as a register in hardware.

Origin of the confusion: "Although the Verilog HDL is used for more than just simulation, the semantics of the language are defined for simulation, and everything else is abstracted from this base definition." -- page 64 of Verilog Standard

From a simulation perspective, a reg is assigned through procedural code and in the execution of that code the simulator might require a memory in order to compute the resulting value of a reg.

The code below describes a signal y that is updated with the value a|b|c any time a,b,or c changes. Clearly this is a 3-input OR gate, which is combinatorial. However, the algorithm/code used to describe the function requires a memory of y to compute the resulting value of y. To a simulator, a type reg is distinctly differnt then a wire.

reg y;
always @(a,b,c) begin
y = a;
y = y|b;
y = y|c;
end

This code computes the result of the expression assigning a|b|c and after computing the reult, independant of y, and then schedules an assignment of that result to y.

wire y;
assign y = a|b|c;

A reg is used in procedural-code as variables that may end up being implemented using with if sequential logic is generated and are just represent the output net of combinatorial logic otherwise. Wires on the other hand are for structural connections (nets/wires) between modules or outputs of combinatorial expressions. There is a simple rule to decide if you should use a reg or a wire: if the signal is assigned from a procedural block of code or not. It is so straight forward that in SystemVerilog you can just use the datatype logic and the type of reg or wire is effectively inferred from its use.

Verilog Supports more than the two logic values 0/Low and 1/High. The following Metalogic Values are worth being aware of an may be encountered unintentionally.

z: high-impedance (not driven), supports modeling of bus drivers where multiple potential drivers are connected to one output

x: undetermined, can represent the following

• result when two drivers don’t agree
• output that cannot be definitely determined to be 1 or 0
• unintialized values in simulation

• Take care in specifying the sensitivity list : the contents of sensitivity list needs careful attention. A mistake here is a common cause for diferences between Verilog simulation and synthesized hardware.

  • Some common mistakes : Find out the bug in these code snippets.

      always @ (a,b,c) begin
          x = (c & a) | (~c & b);
      end
    

      always @ (a,c) begin
          x = (c & a) | (~c & x);
      end
    

      always @ (a,b,c) begin
          if (c) x = a;
          else x = b;
      end
    

      always @ (c) begin
          if (c) x = a;
          else x = b;
      end
    

    always @ (a,b,c) begin	     
     if c x = a;
    end
    

• Code interpretation for combinational logic

  • Can you ignore the sensitivity list and reevaluate the procedural block at any and every instant of time or could that change the functional behavior?
  • If it is former then the interpretation can be mapped to a set of output input relationships described by a combinatorial truth table and no memory of the past is required
  • If reevaluation could change the resulting functionality, then you may have described what can only be implemented with some sequential hardware

• If results from any execution of the block directly rely on signals/results generated from a previous execution of the block then sequential logic is describe. This does not include the case when results are saved using external sequential logic.

• Draw the truth table for each block with and without considering the sensitivity list, it should include a row for every possible input combination and the output variables should should never occur in the output columns

1. For the purpose of coding, a reg, wire, or logic should be thought of as label for the the physical wire that is the output of a logic block, not the gate or register itself.
2. Don't try to describe hardware that you can't first draw a representative circuit for...better yet, draw the circuit before coding.
3. When modeling sequential logic, use non-blocking assignments q <= a+b; to assign the output of a register (here the input to the register is a+b)
4. When modeling latches, use non-blocking assignments. (actually don't code any latches for now. If you see any synthesis message for latches, eliminate them.)
5. When modeling combinatorial logic with procedural code always block, use blocking assignments to assign the output. y=a+b;
6. Separate combinatorial and sequential logic into separate always blocks (as much as reasonably possible) to avoid accidental registers and latches. Masters of the art do not need follow this rule
7. When modeling both sequential and combinatorial logic within the same always block, use non-blocking assignments for registers and minimally use blocking statements for intermediate combinatorial logic. y=a+b;q<=y;q_prev<q;
8. Do not mix blocking and non-blocking assignments to the same variable.
9. Do not make assignments to the same variable from more than one always block.

• In some ways VHDL was designed for specification (description of hardware) and Verilog was designed for efficient simulation of hardware.
  VHDL has a more explicit handling and update model of signals that are internal to a module versus signals passed between models.
• With Verilog, synthesizers and simulators don’t always agree on interpretation of code and this can lead to problems for students that think like the simulator only. We have to learn to understand how a simulator “interacts” with the code versus how a synthesizer approaches interpreting the code and mapping it to hardware. Keep both in mind as you learn Verilog.
• Veilog has many potential use models and flexibility in style, so the community of Verilog RTL coders has learned to adopt, by convention only, safe practices like “Suggested Procedural RTL Coding Practices” to achieve deterministic matching between pre-synthesis functional simulation and sythesized hardware behavior.

A) Use non-blocking statements to assign outputs of sequential gates

B) Use blocking statements to assign outputs of combinatorial gates

C) Avoid unnecessary latches when coding for FPGAs, but when necessary use non-blocking statements

• Latches fall outside the scope of basic synchronous timing analysis assumptions and complicate timing and functional testing.

D) Do not make assignments to the same variable from more than one always block

• it confuses synthesizers and can lead to non-deterministic simulation behavior if multiple assignments are made at the same point in time

E) Consider what each output bit is assigned for any possible evaluation under any input and sequential state condition

• When mixing sequential and combinatorial code, it is easy to get into the mindset of coding for sequential logic outputs (which commonly defaults to retaining previous values in many cases) and overlook what happens with the intermediate combinatorial logic in all cases
• When coding sequential code missed cases can lead to unintended enables, storing and use of old data

F) Do not attempt to use any delay operator for the purpose of affecting hardware synthesis

Related guidelines:
http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf page 22

Poor, uses blocking Assignment

module dffb (q, d, clk, rst);
  output q;
  input d, clk, rst;
  reg q;
  always @(posedge clk)
    if (rst) q = 1'b0;
    else q = d;
endmodule

Good, uses Non-blocking Assignment

module dffx (q, d, clk, rst);
  output q;
  input d, clk, rst;
  reg q;
  always @(posedge clk)
    if (rst) q <= 1'b0; //coding all sequential always blocks, even simple single-block modules, using nonblocking assignments.
    else q <= d;
endmodule

Combinatorial:

reg y;
always @(a,b)
   y = a & b;

In this isolated block you might have have alternatively tried and used
y <= a & b;
but we will follow a convention explained later whereby we use blocking for all combinatorial logic

Sequential (registered-output combinatorial logic):

reg q;
always @(posedge clk)
   q <= a & b;

// Combinational Logic
reg y;
always @(a,b)
    y = a & b;

// Sequential Logic mixed with Implied Combinational Logic
reg q;
always @(posedge clk)
    q <= a & b;

// Sequential mixed with Explicit Combinational Logic 
reg q;
always @(posedge clk): someBlockName
    reg _q;
    _q = a & b;
    q <= _q;

// Poor, uses blocking Assignment
module dffb (q, d, clk, rst);
    output q;
    input d, clk, rst;
    reg q;
    always @(posedge clk)
      if (rst) q = 1'b0;
      else q = d;
endmodule

// Coding all sequential always blocks,even simple single-block modules,using non-blocking assignments.
// Good, uses Non-blocking Assignment
module dffx (q, d, clk, rst);
  output q;
  input d, clk, rst;
  reg q;
  always @(posedge clk) begin
    if (rst) q <= 1'b0;
    else q <= d;
  end
endmodule

Determinitisic, Cycle-Accurate Descriptions are used obtain matching of synthesized hardware function to pre-synthesis simulated function

In VHDL, Variables update immediately upon assignment and do not facilitate communication between processes. Signals are used to communicate between processes and are updated at the end of a simulation cycle.

In Verilog, we can adopt a coding conventions that mimics this by using named blocks

Sequential Circuit with Embedded Combinatorial:

always @(posedge clk) begin
   {a,b,c} <= {l|m,m|n,(n|l)&e};
end

Separated Combinatorial and Sequential with explicit naming and modeling of combinatorial outputs:

reg a_prereg,b_prereg,c_prereg,c_or;
always @(l,m,n) begin   
   c_or = n|l;
   {a_prereg,b_prereg,c_prereg} = {(l|m),(m|n),c_or&e};
end
always @(posedge clk) begin
   {a,b,c} <= {a_prereg,b_prereg,c_prereg};
end

Merged Style with local internal variables supporting "cycle-acurate" hardware reprentation and simuation
local variables require the use of a named block, but the advantage is that this prevents accidential use elsewhere

always @(posedge clk) begin: someBlockName
   reg _a,_b,_c,_c_or; //variables indended for use in this block only
   					   // though this is not enforced
   _c_or = n|l;
   {_a,_b,_c} = {l|m,m|n,_c_or&e};
   {a,b,c} <= {a_prereg,b_prereg,c_prereg};
end

What is the value of a signal when nothing is observing it?

• A cycle-accurate simulation only needs to have the correct result at the end of every cycle.
• A cycle-accuracte model for simulation or synthesis only needs to produce the correct output result.
• If "peaking" at _a,_b,_c in simulation, they will only change on the positive clock edge, though in sythesized hardware they would update with changes of l,m,n normally as combinatorial circuits do.

Xilinx tools, at the time of this writing, will generate extra edge-sensitive hardware for _a,_b,_c,_c_or, and then since they are not used elsewhere Xilinx will report that hardware is trimmed leaving only our inteded output. This makes many distracting warning that I hope are removed in newer software adopting the newer SystemVerilog constructs like always_ff.

• The following is poor style. It creates potential confusion and potential mistakes of use elsewhere in the circuit by delaring _c_or,_a,_b,_c and making them available outside the block. Using _c_or outside the block would actually genrate a new register outputing a delayed version of _c_or. Using _a,_b,_c would result in a new register that would be recognized to be the same as a,b,c respectively

    reg _a,_b,_c;
    always @(posedge clk) begin
      {_a,_b,_c} = {l|m,m|n,n|l};
      {a,b,c} <= {a_prereg,b_prereg,c_prereg};
    end
  

• Good: uses named block and local scope

   always @(posedge clk) begin: blockC
     reg _a,_b,_c;
     {_a,_b,_c} = {l|m,m|n,n|l};
     {a,b,c} <= {_a,_b,_c};
   end
  

• use for mixed sequntial and combinational blocks

reg y;
always @(posedge clk, negedge clr_n)
begin: blockY                 
 /************************************************//**/  
 /* Depends on a,b, current value of y, clr_n     //**/
 /************************************************//**/  
 /**/ reg y_prereg,partial;                        /**/
 /**/  y_prereg=1'bx;partial=1'bx;                 /**/
 /**/  if (!clr_n) y <= 1'b0;                      /**/
 /**/  else begin                                  /**/
 /**/    partial = a & b;                          /**/
 /**/    y_prereg = ~a | partial;                  /**/
 /**/    y <= y_prereg;                            /**/
 /**/  end                                         /**/
 /****************************************************/
 /* Output: block updates value of y               /**/
 /* Side effect: updates to y_prereg and partial   /**/
 /************************************************//**/  
end

Some examples quoted from https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8299595 IEEE Std 1800-2017

• Unsized, unsigned homogenious literals. Assignment using any of the following sets all bits to specified value:
  '0, '1, 'X, 'x, 'Z, 'z

• Plain unsized, unsided decimal is provided without any extra decaration:

  456
  

• In general

  • Start with optional bit size specifier

  • Provide tick '

  • specify literal reprensentation type with b,h,d or alternatives B,H,D

  • provide the value using the syntax of the literal

    • underscores _ for reablity may be freed used except for the first character

  • left padding rules are non-trivial and beginners are recommended to avoid, but simple use of unsized literals is reasonable '0,'1,'z,'x

  • Examples:

    4'b1001      // 4-bit binary number
    8'b1001_1011 // 8-bit binary number
     'h2AF       // 12-bit hex
    5 'D 3       //  5-bit decimal number
    12'hx        // 12-bit unknown number
      'x         // all x
    

• ? is an alternative for z in literals. ? and z have a special meaning in certain contexts, which will be explained later.

• Signed Literals will be covered later.

• in general, the output connection is provided as the first argument, with a variable number of arguments for port connections
• an intance name is provided after the primative type and before the connections
  The outputs must be type wire (or alernatively logic in the case of SystemVerilog)
• Ex Not:

  not inv1 (out,in)
  

• The other key primatives avaible are nand,or,and,or,xor,xnor, though other primatives exist

  ...
  wire a,b,c,d,e,x,y,z;
  ...
  or orX (x,a,b);
  or orY (y,c,d);
  and i0 (z,x,y,e);
  

Continous assignment may be decribed implicity with the wire declartion or provided explicilty later along with an assign keyword

...
wire a,b,c,d,e;
...
wire x = a | b; //implicit continous assignment
wire z;
...
assign z = x & (c&d) & e ; 

Keyword: Implicit Continous Assignment

The stimulus (input)

• Designs can be instantiated and driven by other HDL code, typically called a testbench, that drives test signals
• Alternatively, some simulators support a scripting language to drive input signals
  The output
• Use $display $monitor or $strobe statements to print result to screen or file
• Create a value change dump file (VCD)
  • Can be read and displayed by many tools
• May Directly use a GUI to select and display signals

• For a beginner, treat Verilog as Hardware Description Language, not a software coding language. Start off learning Verilog by describing hardware for which you can design and draw a schematic; then translate this to HDL.
• Plan by partitioning the design into sections and modules and coding styles that should be used.
• Identify existing modules, memory components needed, and data-path logic, as well as the control signals required to make those operate as desired.
• Simulate each part with a testbench before putting system together. Update testbenches and resimulate them as your design evolves.
• Large memory blocks are often provided by the manufacturer to be instantiated. Smaller memory elements may be coded or embedded into other descriptions of the design
• Data-path logic can be embedded coded with data-flow, structural elements, or complex synthesizable behavioral descriptions.
• Some styles explicitly separate Comb. Logic and Seq Logic, but this is up to you.
• Best practice is to develop a consistent approach to design, as well as a consistent coding style. It makes designing, coding, and debugging easier for you with time. An inconsistent hack-it-together and hack-until-it-works approach is not conducive to becoming more efficient.
• Typically, complex control is implemented by a synthesizable behavioral case-statement-based state-machine, while simpler control could be implemented with any combinatorial description style. Data-path logic (comb. and sequential) can be integrated into the overall state machine or separated out (better for incremental simulation).

Possible Blueprint:

Wires and registers with specified precision and sign
Arithmetic and bitwise operations
Comparison Operations
Bitvector Operations (selecting multiple bits from a vector, concatenation)
Logical Operators
Selection (muxes)
Indexed Storage (arrays)
Organizational syntax elements and Precedence
Modules (Hardware) Definition and Instantiation

Verilog 2000 has New Port Declaration Options

Verilog 95 code:

module memory( read, write, data_in, addr, data_out);
input  read;
input  write;
input  [7:0] data_in;
input  [3:0] addr;
output  [7:0] data_out;

reg [7:0] data_out;

After the port list, port direction must be declared to be input, output, or inout as well as the width if more than one bit
Type declaration: type is by default a wire unless another type is provided

Verilog 2k with direction and data type listed:

module memory(
  input wire read,
  input wire write,
  input wire [7:0] data_in,
  input wire [3:0] addr,
  output reg [7:0] data_out
);

Verilog 2k with no type in port list

module memory(
  input  read,
  input  write,
  input  [7:0] data_in,
  input  [3:0] addr,
  output reg [7:0] data_out
);

ports are declared as wire by default, override with keyword reg keyword

However, there is a stylistic disadvantage to exposing type in port declaration. In the following two examples, the function is the same but the type for y must change.

Verilog 2000 – port y as reg

module dff2y(output reg qA,
             output reg qB,
             output reg y,
             input dA,
             input dB,
             input en_n, 
             input clk)

  always@(posedge clk)
    if (~en_n) begin
      qA <= dA;
      qB <= dB;
    end

  always @(qA,aB) begin
    y = 1’b0;
    if (a&b) begin
      y = 1;
    end
  end
end

Verilog 2000 – port y as wire

module dff2y(output reg qA,
             output reg qB,
             output wire y,
             input dA,
             input dB,
             input en_n, 
             input clk)

  always@(posedge clk)
    if (~en_n) begin
      qA <= dA;
      qB <= dB;
    end

    assign y = qA&qB;
end

y is not the output of a register though declared as reg along with qA and qB in the left module declaration It is arguable that such an internal coding implementation detail does not belong in the presentation of an “external” interface

Verilog 2000 -- hiding reg while exposing port direction using an intermediate signal

module dff2y(  output qA,
               output qB,
               output y,
               input dA,
               input dB,
               input en_n, 
               input clk)

  reg qA_int,qB_int,y_int;
  
  assign qA = qB_int;
  assign qB= qA_int;
  assign y= y_int;

always@(posedge clk)
    if (~en_n) begin
      qA_int <= dA;
      qB_int <= dB;
    end

  always @(qA,aB) begin
    y_int = 1’b0;
    if (a&b) begin
      y_int = a&b;
    end
  end
end

Implicit port mapping uses the order of the ports in the definition to imply connections to local nets

Instantiation with Implicit Port Mapping

module dff2y_en( output qA, qB,
                 output y, // at the instiation, y is a wire regardless of the internal code implementation 
                 input dA, dB,
                 input en, 
                 input clk)

  wire en_n = ~en;   // wire en_n;
                     // assign en_n = ~en;

  dff2y dff2yInstance(
           qA,qB,  //dff out A B 
               y,  //and of qA&qB
           dA,dB,  //dff inputs
            en_n,  //input clk en
             clk); //clk
endmodule

Explicit port mapping uses the port names prefixed with . and allows reordering, no-connect, and omission of ports

Instantiation with Explicit Port Mapping

module dff2y_en(  output y,
                  input dA, dB,
                  input en, 
                  input clk)

  dff2y dff2yInstance(
           .dA(dA),
           .dB(dB), 
           .qA(), //qA not used (no-connect)
                  //qB omitted
           .y(y), 
           .en_n(~en), //**
           .clk(clk)); //clk
endmodule

Implicit net declaration of a net holding the result ~en. This is NOT allowed if default net declaration is disabled. ie using `default net_type none

Combinatorial

reg y;
always @(a,b)
   y = a & b;

In this isolated block you might have have also used y<= a & b; but we will follow a convention explained later whereby we use blocking for all combinatorial logic

Sequential (registered-output combinatorial logic):

reg q;
always @(posedge clk)
   q <= a & b;

1. Separate always blocks for combinatorial and sequential logic

• Comb. assignments use blocking statements
• Seq. assignments use non-blocking statements
• Encourages conscious distinct treatment and recognition of combinatorial and sequential logic. Often this style is recommended for beginners.

2. Sequential and combinatorial logic in same block with combinatorial logic embedded in sequential assignments

• Seq. assignments use non-blocking statements

3. Sequential and combinatorial logic in same block with both combinatorial and sequential assignments

• Comb. assignments use blocking statements
• Seq. assignments use non-blocking statements

• An outcome of this course is that you understand each of the three styles and that you can convert code from one style to the other “at will” when coding both combinartorial and sequential logic.
• It is not sufficient to know only one style, but at first focus heavily first on mastering style 1 (separate comb. And seq.) and fall back to it when uncertain. It requires a more explicit identification of sequential and combinatorial elements in a circuit.
• The other styles can be less cumbersome to code, but do not force students to explicitly identify the partition of conspiratorial and sequential hardware and sometimes starting with those styles can lead to misunderstanding the mapping of RTL to hardware.

Separated Combinatorial and Sequential Logic:

reg y,y_prereg,partial;
always @(a,b,c) begin
   partial = a & b;
   y_prereg = c | partial;
end

always @(posedge clk) begin
   y <= y_prereg;
end

Mentally, associate the variable name (e.g. y) with the output of the register, not the register itself.

Implicit Mix of Combinatorial and Sequential Logic:

reg y,partial;
always @(posedge clk) begin
   partial = a & b;
   y <= c | partial;
end

Explicit Mix of Combinatorial and Sequential Logic:

reg y,y_prereg,partial;
always @(posedge clk) begin
   partial = a & b;
   y_prereg = a | partial;
   y =<= y_prereg;
end

Separated Combinatorial and Sequential Logic:

reg y,y_prereg,partial;
always @(a,b,c) begin
   partial = a & b;
   y_prereg = a | partial;
end

always @(posedge clk, negedge clr_n) begin // Asynchronous control signals must appear in the sensitivity list
  if (!clr_n) y <= 1'b0;
  else y <= y_prereg;

end

Typically Templates can be found in a synthesizer manual or through the
development GUI

You need to follow template statles that the synthesizer recognizes. Check the documentation of a synthesizer for additional coding style requirements.

Both of the following examples generate an error in Xilinx ISE:

ERROR:Xst:899 - "top.v" line 28: The logic for <partial> does not match 
a known FF or Latch template. The description style you are using to describe 
a register or latch is not supported in the current software release.

Problem Code 1:

reg y,partial;
always @(posedge clk, negedge clr_n) begin
  partial = a & b;
  if (!clr_n) y <= 1'b0;
  else y <= ~a | partial;
end

Problem Code 2:

reg partial,y_prereg;

always @(posedge clk, negedge clr_n)
begin
  if (!clr_n) begin
    partial = a & b;
    y_prereg = ~c | partial;
    y <= 1'b0;
  end
  else begin
    partial = a & b;
    y_prereg = ~c | partial;
    y <= y_prereg;
  end
end
endmodule

The following code is more compact than the initial separated version, but leads to warnings

reg y,y_prereg,partial;
always @(posedge clk, negedge clr_n)
//------
begin
  if (!clr_n) y <= 1'b0;
  else begin
    partial = a & b;
    y_prereg = ~a | partial;
    y <= y_prereg;
  end
end
//-------

implied registers and latches are trimmed since they are only used inside this procedural code block and feed into another signal

If the are used outside, additional sequential logic would be generate to provide the saved values externally

WARNING:Xst:646 - Signal <y_prereg> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:646 - Signal <partial> is assigned but never used. This unconnected signal will be trimmed during the optimization process.

The warning tells us that these are not used externally to the procedural block and so they are trimmed-- we’ll call this a trimmable implementation and I allow it even though beginners probably should avoid this style.

The variable scope used for y_prereg and partial is unessisary.

If you follow our coding guidelines, you must use blocking assignment for outputs of combinatorial logic even if within edge-triggered procedural blocks.
Any signal that is both
(1) assigned by a BLOCKING assignment AND
(2) assigned withing an edge triggered block

I) should be considered as an internal net and you
should not (AND MAY NOT FOR THIS COURSE) use
that net outside the block in which it is assigned
II) must be declared as a local variable, requiring a
named block (see prev. slide), and thus enforcing I)

reg y;
always @(posedge clk, negedge clr_n)
begin: blockY                 
 /*************************************************//**/  
 /* Depends on a,b, pre-existing value of y, clr_n //**/
 /*************************************************//**/  
 /**/ reg y_prereg,partial;                         /**/
 /**/  y_prereg=1'bx;partial=1'bx;                  /**/
 /**/  if (!clr_n) y <= 1'b0;                       /**/
 /**/  else begin                                   /**/
 /**/    partial = a & b;                           /**/
 /**/    y_prereg = ~a | partial;                   /**/
 /**/    y <= y_prereg;                             /**/
 /**/  end                                          /**/
 /*****************************************************/
 /* Output: block updates value of y                /**/
 /* Side effect: updates to y_prereg and partial    /**/
 /*************************************************//**/  
end

module mydevice_tb();
  reg clk, rst; // many signals will be reg since they are driven by procedural code in the testbench
  reg x1, x2; 
  wire y1, y2; // Outputs from the module under test are simply structural connections at this level so wires are used


  
  mydevice DUT(clk,rst, y1,y2, x1,x2); //An instance of the device under test

  
  initial clk = 0; // An initial statement or block can set initial values of signals

  always begin  //A always block with delays can be used to drive cyclic signals
    #50; //delay 
    clk = ~clk;
  end

  initial begin //Stops simulation at T=1000
    #1000 
    $finish;
  end

  // Initial value  and a change at T=10
  initial begin 
    rst = 1;
    #10; //delay 
    rst = 0;
  end

  /* Intialize signals immediately if not otherwise initialized, 
     then add delays and assignments We'll see other examples later, 
     but at first avoid changing signals input to clocked blocks at 
     the same time as the clock edge it is sensitive to
  */

  initial begin 
    y1=0;
    y2=0;

    #50; //delay 
    y1=1;
    #50; //delay
    y1=0;
    y2=1;
    #50; //delay 
    y1=1;
    y2=0;
  end

// This testbench includes no print or output statements, so it is assumed 
that a results waveform viewer (GUI) is used

endmodule //end testbench module

For more discussion, see http://www.sunburst-design.com/papers/CummingsHDLCON2002_Parameters_rev1_2.pdf

Avoid magic numbers and use local parameters
localparam is new with Verilog 2001 For older code, you might also see the keyword parameter, but that defines a value that can be overridden when a module is instantiated

localparam a=31; //int
localparam a=32,b=31; //int (multiple on one line)
localparam byte_size=8, byte_max=bytesize-1; //int
localparam a =6.22; //real
localparam delay = (min_delay + max_delay) /2;//real
localparam initial_state = 8'b1001_0110; //reg

In C, standard variable types are constrained by the processor architecture, but for custom hardware it makes sense to allow declaring a variables of various bit lengths. We do this by appending the type with and bit address range.
“A net or reg declaration without a range specification shall be considered 1 bit wide and is known as a scalar. Multibit net and reg data types shall be declared by specifying a range, which is known as a vector.” IEEE Verilog Specification
Standard bit vectors defined by a high to low index are created with square brackets and colon preceding the identifier
<type> [<HighBit>:<LowBit>] id;
They are accessed using square brackets for single bits and additionally using a colon if accessing a slice of bits. Examples from IEEE Specification:

reg[3:0] v;  // a 4-bit vector reg made up of (from most to 
             // least significant) v[3], v[2], v[1], and v[0]
reg [-1:4] b; // a 6-bit vector reg
reg [4:0] x, y, z; // declares three 5-bit regs

Expanding and slicing vectors is supported for evaluation and assignment

reg[7:0] v;
wire msb,lsb;
wire [3:0] highNibble, 
           lowNibble;
wire [7:0] s;


…

assign lsb = v[0];
assign msb = v[7];
assign highNibble = v[7:4];
assign lowNibble = v[3:0];

s[3:0] = 4’b0000;
s[7:0] = lowNibble;

Whereas vectors essentially define a new variable type with a specified bit range and length, array allow creating an addressable group of elements of the same type
Standard arrays defined by a high to low index are created with square brackets and colon following the identifier
id[:];
They are accessed using square brackets

reg x[11:0];  //scalar reg array with length of 12
…
//within procedural code…
x[3] = 1’0;

Standard memories vectors defined using both bit vector and object array notation
<type> [<HighBit>:<LowBit>] id [<HighAddress>:<LowAddress>];
The objects (e.g. words) can be accessed like this:
id[address]
Individual bit slices can be accessed like this:
id[address][highbit:lowbit]

• Following code from http://www.verilogtutorial.info/chapter_2.htm

reg [7:0] ram[0:4095]; // 4096 memory cells that are 8 bits wide

//code excerpt from Chapter 2 SRAM model
input [11:0] ABUS;  // 12-bit address bus to access all 4096 memory cells
inout [7:0] DATABUS;// 8-bit data bus to write into and out of a memory cell
reg  [7:0] DATABUS_driver;
wire [7:0] DATABUS = DATABUS_driver; //inout must be driven by a wire
....
for (i=0; i <= 4095; i = i + 1)  // Setting individual memory cells to 0
  ram[i] = 0;
end
....
ram[ABUS] = DATABUS;  //writing to a memory cell
....
DATABUS_driver =  ram[ABUS]; //reading from a memory cell

I STRONGLY recommend sticking with high to low indexing for all array and vectors definitions and access Create a mix leads to errors.
One reasonable exception for read access is
bit order reversing for a bus:

wire [31:0] a;
wire [31:0] b;

assign b = a[0:31]

Integar types

• 4-State: reg, logic(SystemVerilog),integertype,: 4-state
• 2-State: int,shortint,longint,byte,bit

Signedness:

• Default Signed: byte, shortint, int, integer, and longint default to signed

• Default Unsigned: time, bit, reg, and logic

• Signedness can be provdided using keywords signed and unsigned

  int unsigned ui;
  int signed si;
  

Real:

• real is same as C double, also realtime
• shortreal is the same as C float
• Unlike C Real to integer conversion is defined as rounding
• Upon conversion to a real type, z and x are interpretted as zero

Conversions:

• Recommended to use explicit conversion using casting or system tasks like $realtobits (see Verilog Manual)

What follows is a quick overview of a subset of operators in Verilog. This will familiarize you sufficiently with various operators and syntax so that you can start working with Verilog, though more advanced details will be discussed in later lectures.
Some additional examples may be found here:
http://www.asic-world.com/verilog/operators1.html
http://www.asic-world.com/verilog/operators2.html

wire [3:0] a,y;
assign a = 4’b0101;
assign y = ~a;

wire [3:0] a = 4’b0101,b= 4’b0011,y;
assign y = a&b; //produces 0001 

wire a = 4’b0001;
wire y1,y2;
assign y1 = |a;
assign y2 = |a;

In this code, I assigned combinatorial variables x (don’t care) at the top of the code to see if Xilinx ISE not complain, but it still does. Following it are two versions along with the Xilinx ISE synthesis report.

reg y;
always @(posedge clk, negedge clr_n)
begin: blockY
  reg y_prereg,partial;
  y_prereg=1'bx;partial=1'bx;
     if (!clr_n) y <= 1'b0;
  else begin
    partial = a & b;
    y_prereg = ~a | partial;
    y <= y_prereg;
  end
end

Trimmable Without Combinatorial Assignment to X:

module trimmable(output reg y, input a, input b, input clk,input clr_n);
always @(posedge clk, negedge clr_n)
begin: blockY
  reg y_prereg,partial;
  if (!clr_n) y <= 1'b0;
  else begin
    partial = a & b;
    y_prereg = ~a | partial;
    y <= y_prereg;
  end
end
endmodule

Started : "Synthesize - XST".
Running xst...
Command Line: xst -intstyle ise -ifn "/home/robucci/Nextcloud/covail/Courses/CMPE415/XilinxProjects/test_synth/trimmable.xst" -ofn "/home/robucci/Nextcloud/covail/Courses/CMPE415/XilinxProjects/test_synth/trimmable.syr"
Reading design: trimmable.prj

=========================================================================
*                          HDL Compilation                              *
=========================================================================
Compiling verilog file "trimmable.v" in library work
Module <trimmable> compiled
No errors in compilation
Analysis of file <"trimmable.prj"> succeeded.
 

=========================================================================
*                     Design Hierarchy Analysis                         *
=========================================================================
Analyzing hierarchy for module <trimmable> in library <work>.


=========================================================================
*                            HDL Analysis                               *
=========================================================================
Analyzing top module <trimmable>.
Module <trimmable> is correct for synthesis.
 

=========================================================================
*                           HDL Synthesis                               *
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <trimmable>.
    Related source file is "trimmable.v".
WARNING:Xst:646 - Signal <blockY/y_prereg> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:646 - Signal <blockY/partial> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
    Found 1-bit register for signal <y>.
    Summary:
inferred   1 D-type flip-flop(s).
Unit <trimmable> synthesized.


=========================================================================
HDL Synthesis Report

Macro Statistics
# Registers                                            : 1
 1-bit register                                        : 1

=========================================================================

Trimmable With Combinatorial Assignment to X:

module trimmable(output reg y, input a, input b, input clk,input clr_n);
always @(posedge clk, negedge clr_n)
begin: blockY
  reg y_prereg,partial;
  y_prereg=1'bx;
  partial=1'bx;
  if (!clr_n) y <= 1'b0;
  else begin
    partial = a & b;
    y_prereg = ~a | partial;
    y <= y_prereg;
  end
end
endmodule

Started : "Synthesize - XST".
Running xst...
Command Line: xst -intstyle ise -ifn "/home/robucci/Nextcloud/covail/Courses/CMPE415/XilinxProjects/test_synth/trimmable.xst" -ofn "/home/robucci/Nextcloud/covail/Courses/CMPE415/XilinxProjects/test_synth/trimmable.syr"
Reading design: trimmable.prj

=========================================================================
*                          HDL Compilation                              *
=========================================================================
Compiling verilog file "trimmable.v" in library work
Module <trimmable> compiled
No errors in compilation
Analysis of file <"trimmable.prj"> succeeded.
 

=========================================================================
*                     Design Hierarchy Analysis                         *
=========================================================================
Analyzing hierarchy for module <trimmable> in library <work>.


=========================================================================
*                            HDL Analysis                               *
=========================================================================
Analyzing top module <trimmable>.
Module <trimmable> is correct for synthesis.
 

=========================================================================
*                           HDL Synthesis                               *
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <trimmable>.
    Related source file is "trimmable.v".
WARNING:Xst:646 - Signal <blockY/y_prereg> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:646 - Signal <blockY/partial> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
    Found 1-bit register for signal <y>.
    Summary:
	inferred   1 D-type flip-flop(s).
Unit <trimmable> synthesized.


=========================================================================
HDL Synthesis Report

Macro Statistics
# Registers                                            : 1
 1-bit register                                        : 1

=========================================================================