Icarus Verilog Test Plan

V1.3 9/9/99

1.0 Introduction:

The test suite will encompass four aspects. These are:
1. Basic Syntax coverage.
2. Verify that the compiler correctly identifies illegal 
   use of the language. Example: Wait statements in functions.
3. Correct execution 
4. A collection of "interesting" and hopefully difficult test
   cases.
The coding style will employ self checking code as extensively
as possible. For those cases where this isn't reasonable an
external script will examine the results to verify correctness
either by explicit knowledge of the expected behavior or perhaps
by "Gold files."
All self checking tests will use a consistent method of 
indicating success or failure of the test.
To support easy regression testing, an overall executive script
will be created which will execute each of the component tests
in order, collect the test results, and present them in a 
summary manner.

2.0 Test Philosophy:

The test development/specification uses an onion-skin testing
approach to define what tests are needed.  Further, it is
assumed that there is a core functionality already available
within the compiler supporting this structure.
The basic syntax tests assume that the compiler recognizes
the following constructs and that they dependably
operate.
1. Single module declaration/endmodule boundary.
2. Register variables of length n.
3. if(expression) {} else {} with the expression allowing
   at a minimum comparison of register variables to 
   constants and other variables employing the == and !=
   operators.
4. The $display statement.
5. Constants are recognized.
6. Simple time delay statements, i.e. # 5 ;
7. Basic assignment works, i.e. reg_var = 16'h1234;
Basic syntax tests will be directed at a single language
feature per test. Where it is reasonable - 1 to 3 aspects
of a given feature might be exercised. The idea here is
to be efficient with the test suite, but not overly
complicate the tests.
There are some tests that can't obey this restriction due
to the fact that some language features operate as pairs.
The one example that comes immediately to mind is named
blocks and the disable statement. These two features are
employed in tandem to test both features.

2.1 Test messages

As stated previously, where possible, the tests must
be self checking.  The error messages emitted from the
tests should also be consistent. To this end, the following
is a requirement for self checking routines.
When an error occurs -the message will be of the format:
FAILED - BNF description being tested goes here...
When no failures are detected, the tests will merely
print out:
PASSED
This is intended to allow an easier creation of automated
audit tools for regression purposes.

2.2 Test priorities

Verilog is a very rich language, and yet a small subset of the
language is compatible with synthesis tools. That set of the
language which is most often used for writing test benches
is also a definable subset.  These two subsets will be used
to establish a priority of features to be tested.
Items to definitely be validated LAST will be constructs such
as specify! Haven't even dealt with the specify syntax yet!!

2.3 Strategy

The basic idea behind this test plan is to use the verilog
keywords as the selecting item for a group of tests, then
within a given keyword prepare as many tests as appropriate
to validate the basic usage of these keywords within the
syntax tree of the language.
As an example: ALWAYS
Tests might include cases of:
always @(variable)
always @(var1 or var2)
always @(posedge clk)
always @(negedge clk)
always @(variable or posedge clk)
always @(posedge clk1 or posedge clk2)
always @(posedge clk1 or negedge clk2)
always @(negedge clk1 or negedge clk2) 
etc.
See the test required test elements for the always keyword below.
Note also that an additional nomenclature has been added that indicates the status of the test

3.0 Test descriptions

3.1 "always"

BNF: always statement ;
     statement: blocking_assignment ;
   | non_blocking_assignment ;
   | procedural_continuous_assignements ;
   | procedural_timing_control_statement
   | conditional_statement
   | case_statement
   | loop_statement
   | wait_statement
   | disable_statement
   | event_trigger
   | seq_block
   | par_block
   | system_task_enable

3.1.1 blocking_assignment ;

BNF: always reg_lvalue = [Delay_or_event_control] expression;
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.1A (DN) always reg_lvalue = constant ;
3.1.1B (DN) always reg_lvalue = boolean_expression ;
3.1.1C (DN) always reg_lvalue = # delay_value constant ;
3.1.1D (DN) always reg_lvalue = # delay_value boolean_expression ;
3.1.1E (DN) always reg_lvalue = # (mintypmax_expression) constant ;
3.1.1F (DN) always reg_lvalue = # (mintypmax_expression) boolean_expression ;
3.1.1G (DN) always reg_lvalue = @ event_identifier constant ;
3.1.1H (DN) always reg_lvalue = @ event_identifier boolean_expression ;
3.1.1I (DN) always reg_lvalue = @ (event_expression)  constant ;
3.1.1J (DN) always reg_lvalue = @ (event_expression)  boolean_expression ;
3.1.1K (??) always reg_lvalue = repeat ( expression) @ event_identifier ;
3.1.1L (??) always reg_lvalue = repeat ( expression) @ (event_expression) ;
mintypmax_expression is defined as triplets (min:typ:max)
event_identifier is defined as some reg or wire variable
event_expression consists of a single reg or wire variable,
 or a sequence of such variables separated by the "or" 
 keyword, or a posedge/negedge keyword prefacing a wire or
 reg variable.
Note: there is a dependency between the event_identifier and
the event keyword and -> operator.

3.1.2 non_blocking_assignment ;

BNF: always reg_lvalue <= [Delay_or_event_control] expression;
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.2A (DN) always reg_lvalue <= constant ;
3.1.2B (DN) always reg_lvalue <= boolean_expression ;
3.1.2C (CO) always reg_lvalue <= # delay_value constant ;
3.1.2D (CO) always reg_lvalue <= # delay_value boolean_expression ;
3.1.2E (CO) always reg_lvalue <= # (mintypmax_expression) constant ;
3.1.2F (CO) always reg_lvalue <= # (mintypmax_expression) boolean_expression ;
3.1.2G (CO) always reg_lvalue <= @ event_identifier constant ;
3.1.2H (CO) always reg_lvalue <= @ event_identifier boolean_expression ;
3.1.2I (CO) always reg_lvalue <= @ (event_expression)  constant ;
3.1.2J (CO) always reg_lvalue <= @ (event_expression)  boolean_expression ;
3.1.2K (??) always reg_lvalue <= repeat ( expression) @ event_identifier ;
3.1.2L (??) always reg_lvalue <= repeat ( expression) @ (event_expression) ;
mintypmax_expression is defined as triplets (min:typ:max)
event_identifier is defined as some reg or wire variable
event_expression consists of a single reg or wire variable,
 or a sequence of such variables separated by the "or" 
 keyword, or a posedge/negedge keyword prefacing a wire or
 reg variable.

3.1.3 procedural_continuous_assignements ;

BNF: := always assign reg_assignment 
     | always deassign reg_lvalue ;
     | always force reg_assignment ;
     | always force net_assignment ;
     | always release reg_lvalue ;
     | always release net_lvalue ;
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.3A (DN) always assign reg_lvalue = constant ;
3.1.3B (DN) always assign reg_lvalue = boolean_expression ;
3.1.3C (??) always deassign reg_lvalue ;
3.1.3D (CO) always force reg_lvalue = constant ;
3.1.3E (CO) always force reg_lvalue = boolean_expression ;
3.1.3F (CO) always force net_lvalue = constant ;
3.1.3G (CO) always force net_lvalue = boolean_expression ;
3.1.3H (CO) always release reg_lvalue ;
3.1.3J (CO) always release net_lvalue ;

3.1.4 procedural_timing_control_statement

BNF: always delay_or_event_control statement_or_null ;
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.4A (DNN) always # delay_value ;
3.1.4B (DN)  always # delay_value reg_lvalue = constant ;
3.1.4C (DN)  always # delay_value reg_lvalue = boolean_expr ;
3.1.4D (DNN) always # (mintypmax_expression) ;
3.1.4E (DN)  always # (mintypmax_expression) reg_lvalue = constant ;
3.1.4F (DN)  always # (mintypmax_expression) reg_lvalue = boolean_expr ;
3.1.4G (DNN) always @ (event_expression) ;
3.1.4H (DN)  always @ (event_expression) reg_lvalue = constant ;
3.1.4I (DN)  always @ (event_expression) reg_lvalue = boolean_expr ;
3.1.4J (??)  always repeat ( expression) @ event_identifier ;
delay_value is a constant.
mintypmax_expression is of the form (x:y:z)
event_expression is of the form @ (a), or @(a or b)

3.1.5 conditional_statement

BNF: always if (expression ) statement_or_null ;
     always if (expression ) statement_or_null else statement_or_null ;
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.5A (DN) always if ( constant) statement ;
3.1.5B (DN) always if ( constant) statement else ;
3.1.5C (DN) always if ( constant) statement_1 else statement_2 ;
3.1.5D (DN) always if ( bool_expr ) statement ;
3.1.5E (DN) always if ( bool_expr ) statement else ;
3.1.5F (DN) always if ( bool_expr ) statement_1 else statement_2 ;

3.1.6 case_statement

BNF: always case (expression) case_item { case_item } endcase 
     always casex (expression) case_item { case_item } endcase 
     always casez (expression) case_item { case_item } endcase
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.6A (DN) always case ( reg_value) case_item1; case_item2;  case_item3; endcase  
3.1.6B (DN) always casex ( reg_value) case_item1; case_item2;  case_item3; endcase  
3.1.6C (DN) always casez ( reg_value) case_item1; case_item2;  case_item3; endcase
In the above case_item1-3 will follow the following syntax:
BNF: expression { , expression } : statement_or_null
For casex and casez some of the case expression bit
fields should use the corresponding x or z within some
bit positions.

3.1.7 loop_statement

BNF: always forever statement ;
   | always repeat (expression) statement ;
   | always while (expression) statement ;
   | always for (reg_assignment; expression; reg_assignment) statement
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.7A (DN) always forever statement ;
3.1.7B (DN) always repeat (boolean_expression) statement ;
3.1.7C (DN) always while (boolean_expression ) statement  ;
3.1.7D (DN) always for( reg_lvalue = boolean_expression ; expresson ; 
            reg_lvalue = boolean_expression) statement;

3.1.8 wait_statement

BNF:  always wait (expression) statement_or_null
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.8A (DN) always wait (expression ) statement  ;
A delay statement is used within the above to avoid an always loop-up problem

3.1.9 disable_statement

BNF: always disable task_identifier 
    | always disable block_identifier
To cover this space implement tests with each of the following
structures. These result in infinite loop situations so are compile only.
3.1.9A (CO) always disable task_identifier ;
3.1.9B (CO) always disable block_identifier ;
The above have dependencies upon named blocks and tasks.

3.1.10 event_trigger

BNF: always -> event _identifier ;
To cover this space implement tests with each of the following
structures, and validate correct compilation.
This is an infinite loop situation - so Compile only.
3.1.10 (CO) always -> some_event ;

3.1.11 seq_block

BNF: begin [: block_identifier ] [ block_item_declarations]
        statement ;
     end
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.11A (DN) always begin
                       sequential statements
                    end
3.1.11B (DN) always begin : block_name { block_item_declarations } 
                       sequential statements
                    end
block_item_declaration is defined as any collection of parameter, reg, integer,
integer, real, time or event declarations.
sequential statements are just any normal verilog statements.

3.1.12 par_block

BNF: fork : [block_identifier] [ block_item_declarations ]
           parallel statements
     join
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.1.12A (DN) always fork 
                       parallel executing statements;
                    join
3.1.12B (DN) always fork : block_name
                      parallel executing statements;
                    join
3.1.12C (DN) always fork : block_name 
                       block_item_declarations
                       parallel executing statements;
                    join
block_item_declaration is defined as any collection of parameter, reg, integer,
integer, real, time or event declarations.
parallel executing statements are a collection of 1 or more legal
verilog statements that begin execution simultaneously.

3.1.13 system_task_enable

BNF : system_task_name [ ( expression { , expression } ) ] ;
I'm not going to do this one! I'm lazy.

3.2 "assign"

The assign keyword can be used as a continuous assignment or
as a procedural assignment.
Note that a procedural assignment over-rides a normal 
procedural assignment to a register.
BNF: assign <assignment> ;
To cover this space implement tests with each of the following
structures, and validate correct operation.
3.2A (DN) assign identifier = expression ;
3.2B (DN) assign { ident0, ident1 } = expression ;
3.2C (DN) always @ ( condition)
             begin
               if(condition )
                  assign identifier = expression ;
               else
                  deassign identifier ;
             end
3.2D (DN) always @ (condition)
             begin
               if(condition )
                  assign {ident0,ident1}  = expression ;
               else
                  deassign {ident0,ident1};
             end
A trigger event is defined as some event that will cause
the always block to be evaluated.
SDW - Test dependancy on deassign for procedural assignment.

3.3 "begin/end"

The begin/end pair is considered part of the core logic that
must be available to test the rest of the language.
No explicit test is specified.

3.4 "deassign"

BNF: deassign reg_identifier ;
The "deassign" keyword is used in conjunction with the procedural
assignment. It may be used to "un-assign' the value, thus
it must be tested in conjunction with the procedural assignment.
3.4A (DN) always @ (condition)
            begin
              if (condition1)
                assign reg_identifier = expression ;
              else
              if (condition2)
                assign reg_identifier = expression ;
              else
                deassign reg_identifier;
            end
There is a dependancy on procedural assignment working.

3.5 "defparam"

BNF: defparam <list_of_assignments>
The "defparam" keyword is used to over-ride values established with
the "parameter" keyword, thus depends on the "parameter" keyword
already being functional.
To validate defparam use the following template.
module NameA ();
parameter ident0 = some value;
parameter ident1 = some value ;
endmodule
module NameB ();
NameA testmodA ();
NameA testmodB ();
endmodule
module main ();
defparam NameB.testmodA.ident0 = test value ;           // Validate single val
defparam NameB.testmodB.ident0 = another test value,    // Validate list of vals
         NameB.testmodB.ident1 = another test value;
endmodule
This has a dependancy of parameter and hierarchial addressing.

3.6 "disable"

BNF:    disable task_identifer; 
      | disable block_identifier ;
There is a dependancy on named blocks and tasks working for this 
construct. To test this use the following templates.
3.6A (DN) block_identifier case:
always (posedge clock)
  begin : block_name 
    do something for along time;
  end
initial
  begin
    cause clock ;
    wait awhile;
    disable block_name;
    verify it stopped.;
  end
3.6B (DN) task_name case:
task task_name ;
  do something for along time;
endtask
initial
  begin
    fork
      wait awhile;
      disable task_name;
    join
    verify it stopped;
  end
Note - Needed to use the fork-join to validate.

3.8 "case/endcase/default"

BNF: case (expression) case_item [ case_item ]
     endcase
Where expression must evalue to a value (either scalar
or vector).
case_item follows the following BNF:
case_item : label [,label] : statement_or_null ;
          | default : statement_or_null ;
Use the following templates.
3.8A (DN)
case (expression)
  label1: statement ;
  label2: statement ;
  label3: statement ;
endcase
Use the above template for two situations, the first when expression 
is one of the above labels. The second situation covers the
where expression isn't one of the labels( yielding no action..)
3.8B (DN)
case (expression)
  label1,label2: statement ;
  label3: statement ;
  label4,label5,label6: statement;
endcase
Use the above template for two situations, the first when expression 
is one of the above labels. The second situation covers the
where expression isn't one of the labels( yielding no action..)
3.8C (DN)
case (expression)
  label1,label2: statement;
  label3: ;
  label4: statement ;
endcase
Use the above template for the situation where label3 occurs
to validate no action occurs.
Repeat the above templates with a default clause.

3.9 "casex/endcase/default"

BNF: casex (expression) case_item [ case_item ]
     endcase
Where expression may be any expression which includes values where
some of the bits within a vector are value "X"
case_item follows the following BNF:
case_item : label [,label] : statement_or_null ;
The label may also contain the value x for any bit position.
Use the templates below:
casex (expresion)
  label1: statement_or_null ;
  label2: statement_or_null ;
  label3: statement_or_null ;
endcase
3.9A (DN)
The first situation to validate is where casex operates as a superset
of case, i.e. where all bits of expression and the labels are known values, 
not don't-care "x" values.
3.9B (DN)
The next situation is to validate X within the computed expression
value of the casex, while the labels are all known values.
3.9C (DN)
The next situation is to validate where label valued contain X within
the label vector.
3.9D (DN)
Validate that a non-match causes no action.
3.9E (DN)
Repeat the above template with a default clause and validate
that the non-match case executes the default.

3.10 "casez/endcase/default"

BNF: casez (expression) case_item [ case_item ]
     endcase
Where expression may be any expression which include values where
some of the bits within a vector are value "z"
case_item follows the following BNF:
case_item : label [,label] : statement_or_null ;
The label may also contain the value x for any bit position.
Use the templates below:
casez (expresion)
  label1: statement_or_null ;
  label2: statement_or_null ;
  label3: statement_or_null ;
endcase
3.10A (DN)
The first situation to validate is where casez operates as a superset
of case, i.e. where all bits of expression and the labels are known vlues, 
not tri-state "z" values.
3.10B (DN)
The next situation is to validate Z within the expression
value of the casez, while the labels are all known values.
3.10C (DN)
The next situation is to validate where label valued contain Z within
the label vector.
Validate that a non-match causes no action.
3.10D (DN)
Repeat the above template with a default clause and validate
that the non-match case executes the default.

3.11 "function/endfunction"

Functions have two parts to their BNF - that of the function
declaration, and the other being the function call.  Note also
that there is a dependency between continuos assignments and
functions within continuos assignments.
BNF:    function [ range_or_type ] function _identifier ; 
        function_item_declaration ;
        statement 
        endfunction
        function_identifier ( expression [, expression] ) ;
Implement the following templates to validate this structure.
3.11A (??) Template 1: Validate that a function without at least one argument causes
            an error.
function function_name ;
     function_name = expression ;
endfunction
3.11B (DN) Template 2: Validate basic function
function [31:0] function_name  ;
    input [31:0] ident1 ;
    function_name = ident1 ;
endfunction
3.11C (DN) Template 3: Calling a function from within a function
function [31:0] funct1 (ident1) ;
   input [31:0] ident1 ;
   funct1 = ident1 ;
endfunction
function [31:0] funct2 (ident2) ;
   input [31:0] ident2 ;
   funct2 = funct1(ident2) ;
endfunction
Validate that return of funct2(expression) equals expression.
3.11D (DN) Template 4: Calling a function from within a continuos assignment.
wire [31:0] ident1 ;
function [31:0] funct1 (ident2) ;
  input [31:0] ident2 ;
  funct1 = ident2 ;
endfunction
assign ident1 = funct(ident2);
3.11E (??)
Finally - validate that calling a task from within a function
causes an error.
3.11F (DN) Validate a register in a function
(Peter Monta - pmonta@imedia.com)
module top;
  function bar;
    input [1:0] arg;
    reg result;
    begin
      result = |arg;
    end
    bar = result;
  endfunction
endmodule

3.12 "module/endmodule"

The following BNF is for module declaration.
BNF: module module_name ; endmodule
   | module module_name (); endmodule
   | module module_name (port_list); port_list_declarations; endmodule
The following BNF is for module instantiation.
BNF: module_name instantiation_name (port_list) ;
Verify the following templates are acceptable to the compiler - they
don't have any function, they just shouldn't cause compiler errors.
3.12A (DN) Template 1:
module module_name;
endmodule
Template 2:
module module_name (); 
endmodule ;
Template 3:
module module_name (port_list);
port_list_declarations;
endmodule
Verify that we can instantiate a module with a port list AND
functionality via the following two templates.
module mod1 (ident1,out1) ;
input ident1 ;
output out1 ;
 some_functionality ;
endmodule
mod1 inst1 (val1,out1);
mod1 inst2 (.ident1(val2),.out1(out2));
Template 4;
module foo ({a,b}, c)
    output a, b;
    input c;
    stuff...
endmodule
3.12B (DN) Template 5: Module with an output ONLY
module foo(a);
  output a;
  assign a = 1'b1;
endmodule

module top;
  foo foo1(.a());
endmodule

3.13 "macromodule/endmodule"

SDW - Can't find this - wait.

3.14 "task/endtask"

BNF: task task_identifier ; 
     [io_declarations];
     [local_declarations];
     statement ;
     endtask
io_declarations will consist of 1 or more input or output 
declarations.
local_declarations will consist of any combinations of reg
and wire defines.
Instatiate the following templates to validate possible task
usage.  Note that issues such as addressing external state
from within the task is left till later.
3.14A (DN) Template 1.
Task with no I/O declarations, or internal state
task task_name ;                
  simple_assignment ;
endtask
initial 
  begin
    what_ever;
    task_name ;
    what_ever;
  end
This should affect a global variable.
3.14B (DN) Template 2.
Task with input only.
task task_name ;                
  input in_1;
  simple_assignment using in_1 ;
endtask
initial 
  begin
    what_ever;
    task_name (in_1);
    what_ever;
  end
3.14C (DN) Template 3.
Task with input AND output.
task task_name ;
  input in_1;
  output out_1;
  out_1 = in_1;   
endtask
initial
begin
  what_ever;
  task_name (in_1,out_1);
  what_ever
end
3.14D (DN) Template 4.
Task with multiple inputs, multiple outputs.
task task_name ;
  input in_1;
  input in_2;
  output out_1;
  output out_2;
  some_functions of out_1 and out_2;
endtask
initial
begin
  what_ever;
  task_name (in_1,in_2,out_1,out_2);
  what_ever
end
3.14E (DN) Template 5:
Task which calls a function
function foo;
   input in1 ;
   foo = in1;
endfunction
   
task mytask ;

  input in1 ,in2;
  output out1,out2;
   begin
       out1 = foo( ~foo(in1));
       out2 = foo (in2);
   end
endtask
initial
begin
  what_ever;
  task_name (in_1,in_2,out_1,out_2);
  what_ever
end
Template 6:
3.14F (DN) Task with delay
task mytask
   input in1;
   output out1;
      out1 = #delay in1;
endtask

initial
  begin
       out1 = 0;
       fork
            mytask(in1,out1)
            check out1 before and after delay period
        join
   end
Note - has a dependency on fork/join working to
validate.



3.15 "event"

BNF: event list_of_event_identifiers;
     -> event_identifier;
The event identifier is easiest to test in conjunction with the
"always @" thus has a dependency.
Template:
event event_1, event_2;
always @ event_1 
  begin
    what_ever;
  end
always @ event_2 
  begin
     what_ever;
  end
initial 
  begin
    some_delay -> event_1;
    some_delay -> event_2;
    some_delay -> even_1;
  end

3.16 "for"

BNF:  for (reg_assignment;loop_condition; reg_assignment) statement;
reg_assignment consists of a single reg_lvalue = expression.
loop_condition consists of some expression which evaluates to true(thus
execute the loop again) or false (don't execute the loop).
Template 1:
The simplest form of the the for loop.
reg [3:0] val1;
initial 
  for(val1 =0; val1 < constant ; val1 = val1 + 1)     
     some_action;
Template 2:
reg [3:0] val1;
initial 
  for(val1 =0; val1 <= expression ; val1 = val1 + 1)     
     some_action;
Template 3:
reg [3:0] val1;
initial 
  for(val1 =0; val1 <= expression ; val1 = val1 + 1)     
     begin
           some_action;
     end;

3.17 "force"

BNF:    force reg_assignment ;
      | force net_assignment ;
Use the following templates to validate the correct behavior:
Templates:
  force reg_lvalue = constant ;
  force reg_lvalue = boolean_expression ;
  force net_lvalue = constant ;
  force net_lvalue = boolean_expression ;

3.18 "forever"

BNF: forever statement ;
Use the following templates to validate the correct behavior.
Template 1:
forever clock = #10 ~clock ;
Template 2:
forever begin
          several statements in serial.
        end

3.19 "fork/join"

BNF: fork : block_identifier
       block_item_declaration
       [ statement ]
     join
The block_item_declaration can be one of a parameter declaration,
register declaration, integer declaration , real declaration or
time declaration.
Dependencies exist for all of these types and the fork/join. The
register is the only declaration that is assumed to be a core
available declaration so it is all that is used at this time.
fork statements with block_identifers occur in conjunction with
the disable statement. Thus a dependancy.
Template 1:
   fork
      statement_1;
      statement_2;
   join
Validate that both statements occur.
Template 2:
   fork
     statement_1 modifies reg_val;
     @(reg_val) statement_2;
   join
Validate that statement_2 occurs, and occurs AFTER statement_1.
Template 3:
   fork : block_name
       statement_1;
       statement_2 that causes block_name to disable after some
          period of time.
   join
Validate that the disable causes statement 1 to end prematurely.

3.20 "function/endfunction" (Note - this section copied from "always")

Functions have two parts to their BNF - that of the function
declaration, and the other being the function call.  Note also
that there is a dependency between continuos assignments and
functions within continuos assignments.
BNF:    function [ range_or_type ] function _identifier ; 
        function_item_declaration ;
        statement 
        endfunction
        function_identifier ( expression [, expression] ) ;
Implement the following templates to validate this structure.
Template 1: Validate that a function without at least one argument causes
            an error.
function function_name ;
     function_name = expression ;
endfunction
Template 2: Validate basic function
function [31:0] function_name ( ident1) ;
    input [31:0] ident1 ;
    function_name = ident1 ;
endfunction
Template 3: Calling a function from within a function
function [31:0] funct1 (ident1) ;
   input [31:0] ident1 ;
   funct1 = ident1 ;
endfunction
function [31:0] funct2 (ident2) ;
   input [31:0] ident2 ;
   funct2 = ident2 ;
endfunction
Validate that return of funct2(expression) equals expression.
Template 4: Calling a function from within a continuos assignment.
wire [31:0] ident1 ;
function [31:0] funct1 (ident2) ;
  input [31:0] ident2 ;
  funct1 = ident2 ;
endfunction
assign ident1 = funct(ident2);
Finally - validate that calling a task from within a function
causes an error.

3.21 "if/else" (Note - this section copied from "always")

BNF: if (expression ) statement_or_null ;
     if (expression ) statement_or_null else statement_or_null ;
To cover this space implement tests with each of the following
structures, and validate correct operation.
if ( constant) reg_lvalue = boolean_expression ;
if ( boolean_expression ) reg_lvalue = boolean_expression ;
if ( constant) reg_lvalue = boolean_expression else ;
if ( constant) reg_lvalue = boolean_expression else
                      reg_lvalue = boolean_expresion ;

3.22 "initial"

This is considered a fundamental core function and
will not be directly tested/

3.23 "inout"

BNF: inout [range] identifer;
This keyword must be used in conjunction with the module/endmodule
keywords. These are "core" keywords and thus the dependancy isn't
relevant.
To cover this space implement tests with each of the following
structures, and validate correct operation.
Template 1:
This template validates inout as a bit width and uses global
values to set conditions. It should be possible to cause a
1'bz value on the output, or force 0/1/or in_1's output onto
inout tri_0;
module mod_name_1 (tri_0,in_1);
inout tri_0;
input in_1;
tri_0 = some_condition ? in_1 : 1'bz ;
tri_0 = some_other_condition_0 ? 1'b0 : 1'bz ;
tri_0 = some_other_condition_1 ? 1'b1 : 1'bz ;
endmodule
Template 2:
This template validates inout as a bit width and uses
global values to set conditions. Here tri_0 can be
used as both an input AND an output.
module mod_name_1 (out_1,tri_0,in_1)
input in_1;
inout tri_0;
output out_1;
out_1 = some_condition ? tri_0 : in_1 ;
tri_0 = some_other_condition ? 1'b0  : 1'bz;
tri_0 = some_third_condition ? 1'b1 : 1'bz ;
endmodule
Repeat the above with multiple bit vector definitions of all of the
above.

3.24 "input"

Input is considered a core keyword and is not explicitly tested.

3.25 "negedge"

Negedge is used as part of the event control syntax.  It's used
as part of an event expression.
BNF: @ ( negedge identifier)  
   | @ ( negedge identifier or event_expression )
Where event_expression can be yet another negedge phrase, posedge
phrase, or just a signal identifier.
To cover this space implement tests with each of the following
structures, and validate correct operation.
@ ( negedge signal_1) 
@ ( negedge signal_1 or negedge signal_2)
@ ( negedge signal_1 or signal_2 )
@ ( negedge signal_1 or negedge signal_2 or negedge signal_3)
@ ( negedge signal_1 or negedge signal_2 or signal_3)

3.26 "output"

Output is considered a core keyword and is not explicitly tested.
3.27 "parameter"
BNF: parameter assignment ;
   | parameter assignment,assignment* ;
To cover this space implement tests with each of the following
structures, and validate correct operation.
parameter ident_1 = value ;
parameter ident_1 = value, ident_2 = other_value;
parameter ident_1 = value, ident_2 = other_value, ident_3 = third_value;

3.28 "posedge"

Posedge is used as part of the event control syntax.  It's used
as part of an event expression.
BNF: @ ( posedge identifier)  
   | @ ( posedge identifier or event_expression )
Where event_expression can be yet another posedge phrase, negedge
phrase, or just a signal identifier.
To cover this space implement tests with each of the following
structures, and validate correct operation.
@ ( posedge signal_1) 
@ ( posedge signal_1 or posedge signal_2)
@ ( posedge signal_1 or signal_2 )
@ ( posedge signal_1 or posedge signal_2 or posedge signal_3)
@ ( posedge signal_1 or posedge signal_2 or signal_3)

3.29 "release"

BNF: release signal_name ;
The "release" keyword is dependent on the "force" keyword, and must
be used in conjunction with "force" (since it undoes the force...).
Use the following template ;
assign signal_1 = initial_value ;
force signal_1 = some_value ;
some time later...
release signal_1;
Validate that signal_1 returns to the initial_value.

3.30 "repeat"

BNF: repeat ( expression ) statement ;
Where expression evaluates to the repeat count of the statement.
Use the following templates:
repeat ( Constant ) single_statement ;
repeat ( Constant ) 
   begin
     series of statements ;
   end
repeat ( calculated value ) statement ;
repeat ( calculated value ) 
   begin
     series of statements ;
   end

3.31 "wait"

BNF: wait ( expression ) statement_or_null ;
where expression must equate to true or false.
To cover this test space use the following templates:
wait ( reg_var )  ;
wait ( reg_var ) single_statement ;
wait ( reg_var ) begin
                    series of statements ;
                 end
wait ( calculated result ) ;
wait ( calculated result ) single statement ;
wait ( calculated result ) begin
                            series of statements;
                           end

3.32 "while"

BNF: while ( expression ) statement ;
where expression must equate to true or false.
To cover this test space use the following templates:
while ( reg_var) single_statement ;
while ( rev_var ) begin
                      series of statements ;
                  end

4.0 Verilog Gate modules
4.1 Drive strength
4.1.1 "supply"
4.1.2 "strong"
4.1.3 "pull"
4.1.4 "large"
4.1.5 "small"
4.1.6 "weak"
4.1.7 "medium"
4.1.8 "highz"
4.2 "and"
4.3 "buf"
4.4 "bufif"
4.5 "bufif1"
4.6 "cmos"
4.7 "rcmos"
4.10 "nand"
4.11 "nmos"
4.12 "nor"
4.13 "not"
4.14 "notif0"
4.15 "notif1"
4.16 "or"
4.19 "pulldown"
4.20 "pullup"
4.21 "pmos"
4.22 "rnmos"
4.23 "rpmos"
4.24 "rtran"
4.25 "rtranif0"
4.26 "rtranif1"
4.31 "tran"
4.32 "tranif0"
4.33 "tranif1"
4.43 "xnor"
4.44 "xor"

5.0 Verilog Expressions and types.

5.1 "Verilog types
5.1.1 "time"
5.2 "scalared"
5.3 "integer"
5.4 "reg"
5.5 "wire"
5.6 "wand"
5.7 "wor"
5.8 "tri"
5.9 "tri0"
5.10 "tri1"
5.11 "triand"
5.12 "trior"
5.13 "trireg"
5.14 "triwire"
5.15 "supply"

5.7 Basic operator operation
5.8 Operator precedence.

6.0 "primitive/endprimitive"
6.1 "table/endtable"

7.0 "specifiy/endspecify"


     We don't care yet ;-)

8.0 Contributed Tests

These are a series of tests that are contributed from the geda archive:

8.1 Verify that IVL searches other than the current scope when
       instantatiating a parameter - Ed Carter
8.2 Verify LOTS of different MODULE port sytax - especially input only
      modules.  - Stefan Thiede