BACK

1.0 Hierarchy Scopes

 

Verilog HDL constructs that represent hierarchy scope are:

Each scope has its own name space. An identifier name defined within a scope is unique to that scope. References to an identifier name will search first in the local scope, and then search upward through the scope hierarchy up to a module boundary.

Module Definitions
Function Definations
Task Definations 
Procedural Blocks
Specify Blocks

 

Module Definations 

Verilog HDL models are represented as modules.

Syntax

Implicit Internal Connection

module module_name (port_name, port_name, ... );

module_items

endmodule

Explicit Internal Connection

module module_name (.port_name (signal_name ), .port_name (signal_name ), ... );

module_items

endmodule

  • Implicit internal connections connect the port to an internal net or register of the same name.
  • Explicit internal connections connect the port to an internal signal with a different name, or a bit select, part select, or concatenation of internal signals.
  • The keyword macromodule is a synonym for module. Some EDA tools may optimize tool execution performance by flattening macromodule hierarchy.
  • module_items are:
  • module_port_declarations
  • data_type_declarations
  • module_instances
  • primitive_instances
  • procedural_blocks
  • continuous_assignments
  • task_definitions
  • function_definitions
  • specify_blocks
  • Module functionality may be:
    • Behavioral - modeled with procedural blocks or continuous assignment statements.
    • Structural - modeled as a netlist of module instances or primitive instances.
    • A combination of behavioral and structural.
  • Module definitions may not be nested. Instead, modules instantiate other modules.
  • Module definitions may be expressed using parameter constants. Each instance of a module may redefine the parameters to be unique to that instance.
  • Module items may appear in any order, but port declarations and data type declarations should be listed before the ports or signals are referenced.
  •  

    TOP

     

    Function Definations

     

    Syntax

    function [size_or_type] function_name;
       input declarations
       local variable declarations
       procedural_statement or statement_group
    endfunction
        

    Functions return the value that is assigned to the function name.

    • Must have at least one input; may not have outputs or inouts.
    • May not contain timing controls (#, @, or wait).
    • size_or_type (optional) is the return bit range as [msb:lsb], or the keywords integer or real. The default size is 1-bit.

    Example of a Function

    function [7:0] GetByte;        //FUNCTION DEFINITION
      input [63:0] Word;             //declaration order
      input [3:0] ByteNum;           //determines order
      integer Bit;                   //of arguments when
      reg [7:0] temp;                //called
      begin
        for (Bit=0; Bit<=7; Bit=Bit+1)
        temp[Bit] = Word[((ByteNum-1)*8)+Bit];
        GetByte = temp;              //A function returns
      end                            // the value assigned
    endfunction                      // to its name
        
    this_byte = GetByte(data,4);   //FUNCTION CALL
        

     

    TOP

     

    Task Definations

     

    Syntax

    task task_name;
       input, output, and inout declarations
       local variable declarations
       procedural_statement or statement_group
    endtask
        

    Tasks are subroutines.

    • May have any number of inputs, outputs or inouts.
    • May contain timing controls (#, @, or wait).

    Example of a Task

    task read_mem;                 //TASK DEFINITION
      input [15:0] address;          //declaration order
      output [31:0] data;            // determines order
      begin                          // of arguments when
        read_request = 1;            // task is called
        wait (read_grant) addr_bus = address;
        data = data_bus;
        #5 addr_bus = 16'bz; read_request = 0;
      end
    endtask
        
    read_mem(PC, IR);              //TASK CALL
        

     

    TOP

     

    Procedural Blocks

     

    Syntax

    type_of_block @(sensitivity_list)
      statement_group: group_name
      local_variable_declarations
      timing_control procedural_statements
    end_of_statement_group
      

     

    type_of_block is either initial or always

    • initial procedural blocks process statements one time.
    • always procedural blocks process statements repeatedly.

    sensitivity_list (optional) is an event timing control that controls when all statements in the procedural block will start to be evaluated. The sensitivity list is used to model combinational and sequential logic behavior.

    statement_group--end_of_statement_group is used to group two or more procedural statements together and control the execution order.

    • begin--end groups two or more statements together sequentially, so that statements are evaluated in the order they are listed. Each timing control is relative to the previous statement.
    • fork--join groups two or more statements together in parallel, so that all statements are evaluated concurrently. Each timing control is absolute to when the group started.

    group_name (optional) creates a local scope in a statement group. Named groups may have local variables, and may be disabled with the disable keyword.

    local_variable_declarations (optional) must be a register data type (may only be declared in named statement groups).

    timing_control is used to control when statements in a procedural block are executed. Refer to Procedural Timing

    procedural_statement is a procedural assignment to a register variable or a programming statement

    Procedural Block Examples

    Notes

    initial
      fork
        bus = 16'h0000;
        #10 bus = 16'hC5A5;
        #20 bus = 16'hFFAA;
      join
        
    initial procedure executes statements one time; The fork--join group places statements in parallel.
    always @(a or b or ci)
      begin
        sum = a + b + ci;
      end
        
    always procedure executes statements repeatedly.
    always @(posedge clk)
      q <= data; 
    a statement group is not required when there is only one statement

     

    TOP

     

    Specify Blocks

    15.0 Specify Blocks

    Syntax

    specify
       specparam_declarations
       timing_constraint_checks
       simple_pin-to-pin_path_delay
       edge-sensitive_pin-to-pin_path_delay
       state-dependent_pin-to-pin_path_delay
    endspecify
        

     

    15.1 Specparam Declarations

    specparam param_name = value, param_name = value, ...;

    • specparams are constants used to store delays, delay calculation factors, synthesis factors, etc.
    • value may be interger, real, delay, or quoted string.

    15.2 Timing Constraint Checks

    Timing constraint checks are system tasks that model restrictions on input changes, such as setup times and hold times.

    Timing Check Syntax

    $setup(data_event, reference_event, setup_limit, notifier);
    $hold(reference_event, data_event, hold_limit, notifier);
    $setuphold(reference_event, data_event, setup_limit, hold_limit, notifier);
    $skew(reference_event, data_event, skew_limit, notifier);
    $recovery(reference_event, data_event, limit, notifier);
    $period(reference_event, period_limit, notifier);
    $width(reference_event, width_limit, width_threshold, notifier);
    • Timing checks may only be used in specify blocks.
    • The reference_event is and edge of an input signal that establishes a reference point for changes on the data event.
    • The data_event is the input signal that is monitored for changes.
    • The data_event and reference_event signals must be module input ports.
    • The limit and threshold are delay values and use the same syntax as single primitive delays.
    • The notifier (optional) is a reg variable used as a flag. When a timing violation occurs, the model functionality can use the notifier flag to modify the model outputs.

     

    15.3 Pin-to-pin Path Delays

    • Simple path delay statement:

      (input_port polarity:path_token output_port) = (delay);

    • Edge-sensitive path delay:

      (edge input_port path_token (output_port polarity:source)) = (delay);

      • edge (optional) may be either posedge or negedge. If not specified, all input transitions are used.
      • source (optional) is the input port or value the output will receive. The source is ignored by most logic simulators, but may be used by timing analyzers.
    • State-dependent path delay:

      if (first_condition) simple_or_edge-sensitive_path_delay
      if (next_condition) simple_or_edge-sensitive_path_delay
      ifnone simple_path_delay


      • Allows different delays for the same path to be specified, based on other input conditions.
      • condition may only be based on input ports.
      • Most operators may be used with the condition, but should resolve to true/false (a logic X or Z is considered true; if the condition resolves to a vector, only the lsb is used).
      • Each state-dependent delay for the same path must have a different condition or a different edge-sensitive edge.
      • The ifnone condition (optional) may only be a simple path delay, and serves as a default if no other condition evaluates as true.
    • polarity (optional) is either + or P, and indicates whether-or-not the input will be inverted. The polarity token is ignored by most logic simulators, but may be used by timing analyzers.
    • path_token is either *> for full connection or => for parallel connection.
      • Full connection path delay indicates every input bit may have a delay path to every output bit.
      • Parallel connection path delay indicates each input bit is connected to its corresponding output bit (bit 0 to bit 0, bit 1 to bit 1, ...)
    • delay can represent 1, 2, 3, 6 or 12 transitions may be specified. Each transition may have a single delay or a min:typ:max delay range.

    Delays

    Transitions represented (in order)

    1

    all output transitions

    2

    rise, fall output transitions

    3

    rise, fall, turn-off output transitions

    6

    rise, fall, 0->Z, Z->1, 1->Z, Z->0

    12

    rise, fall, 0->Z, Z->1, 1->Z, Z->0,
    0->X, X->1, 1->X, X->0, X->Z, Z->X

     

    Specify Block Examples

    Notes

    (a => b) = 1.8; parallel connection path; one delay for all output transitions
    (a -*> b) = 2:3:4; full connection path; one min:typ:max delay range for all output transitions; b receives the inverted value of a
    specparam t1 = 3:4:6,
              t2 = 2:3:4;
    (a => y) = (t1,t2);
    different path delays for rise, fall transitions
    (a *> y1,y2) = (2,3,4,3,4,3); different delays for 6 output transitions
    (posedge clk => (qb -: d)) = (2.6, 1.8); edge-sensitive path delay; timing path is positive edge of clock to qb; qb receives the inverted value of data
    if (rst && pst) (posedge clk=>(q +: d))=2; state-dependent edge sensitive path delay
    if (opcode = 3'b000)
           (a,b *> o) = 15;
    if (opcode = 3'b001)
           (a,b *> o) = 25;
    ifnone (a,b *> o) = 10;
    state-dependent path delays; an ALU with different delays for certain operations (default delay has no condition)

     

    TOP

     BACK