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.
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.
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.
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!!
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
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
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.
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.
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 ;
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)
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 ;
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.
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;
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
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.
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 ;
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.
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.
BNF : system_task_name [ ( expression { , expression } ) ] ;
I'm not going to do this one! I'm lazy.
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.
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.
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.
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.
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.; end3.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.
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.
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.
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.
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
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
SDW - Can't find this - wait.
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 functionfunction foo;
initial begin what_ever; task_name (in_1,in_2,out_1,out_2); what_ever end
Template 6:
3.14F (DN) Task with delaytask mytask
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.
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
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;
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 ;
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
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.
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.
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 ;
This is considered a fundamental core function and will not be directly tested/
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.
Input is considered a core keyword and is not explicitly tested.
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)
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;
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)
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.
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
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
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
We don't care yet ;-)
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