Section 17.5

LRM-100

Change in Syntax 17-2 (change in red):

sequence_expr ::=

  cycle_delay_range sequence_expr { cycle_delay_range sequence_expr }

| sequence_expr cycle_delay_range sequence_expr { cycle_delay_range sequence_expr }

| expression { , function_blocking_assignment variable_assignment } [ boolean_abbrev ]

| ( expression {, function_blocking_assignment variable_assignment } ) [ boolean_abbrev ]

| sequence_instance [ sequence_abbrev ]

| ( sequence_expr ) [ sequence_abbrev ]

| sequence_expr and sequence_expr

| sequence_expr intersect sequence_expr

| sequence_expr or sequence_expr

| first_match ( sequence_expr )

| expression throughout sequence_expr

| sequence_expr within sequence_expr

Section 17.6

LRM-58

Change (change in red):

A sequence can be declared in

—      a module as a module_or_generate_item

—      an interface as an interface_or_generate_item

—      a program as a non_port_program_item

—      a clocking domain as a clocking_item

—      a package

—      a compilation-unit scope

—      $root

Section 17.7.2

LRM-100

Change in Syntax 17-5 (change in red):

sequence_expr ::=

...

| expression { , function_blocking_assignment variable_assignment } [ boolean_abbrev ]

| ( expression {, function_blocking_assignment variable_assignment } ) [ boolean_abbrev ]

| sequence_instance [ sequence_abbrev ]

| ( sequence_expr ) [ sequence_abbrev ]

...

Section 17.8

LRM-100

Change in Syntax 17-13 (change in red):

sequence_expr ::=

...

| expression { , function_blocking_assignment variable_assignment } [ boolean_abbrev ]

| ( expression {, function_blocking_assignment variable_assignment } ) [ boolean_abbrev ]

Section 17.9

LRM-105

Change in Syntax 17-13 (change in red):

— $inset (<expression>, <expression> {, <expression> } ) returns true if the first expression is equal to at least one of the subsequent expression arguments.

— $insetz (<expression>,<expression> {, <expression> } ) returns true if the first expression is equal to at least other expression argument. The comparison is performed using casez semantics, so ‘z’ or ‘?’ bits are treated as don’t-cares.

Section 17.10

LRM-58

Change (change in red):

A property can be declared in

—      a module as a module_or_generate_item

—      an interface as an interface_or_generate_item

—      a program as a non_port_program_item

—      a clocking domain as a clocking_item

—      a package

—      a compilation-unit scope

—      $root

Section 17.12

LRM-58

Change (change in red):

A concurrent assertion statement can be specified in:

—      an always block or initial block as a statement, wherever these blocks can appear\

—      a module as a module_or_generate_item

—      an interface as an interface_or_generate_item

—      a program as a non_port_program_item

—      $root

Section 17.14

LRM-58

Change (change in red):

The bind directive can be specified in

—      a module as a module_or_generate_item

—      outside of all other declarations in a compilation unit

—      $root

Section 17.15 (New)

LRM-73

Add (change in red):

17.15 The expect statement

 

The expect statement is a procedural blocking statement that allows a property to be declared and also to wait for the first successful match of the property. The syntax of the expect statement is given below.

 

statement_item ::=                                                                                                                        // from Annex A.6.4

  …

| expect ( property_spec ) [ action_block ]

| expect ( property_instance ) [ action_block ]

Syntax 17-18: Expect statement (excerpt from Annex A)

 

The expect statement accepts the same syntax used to assert a property. An expect statement causes the executing process to block until the given property successor fails. The expect statement unblocks at the earliest match of the property (i.e., first_match). The statement following the expect is scheduled to execute after processing the Observe region following the success of the property, or the first failed attempt. In either case (i.e., the property succeeds or fails), the specified property terminates its evaluation when the process unblocks.

 

When executed, the expect statement automatically starts evaluating the given property on the subsequent clocking event, that is, the first attempt shall take place on the next clocking event. When the process unblocks (due to the property succeeding or failing) the property stops being evaluated. If the property fails at its clocking event, the optional else clause of the action block is executed. If the property succeeds the optional pass statement of the action block is executed.

 

The semantics of the expect statement are to block until first match (or failure) of the given property and whose starting time is greater than the time at which the expect statement executes.

 

program tst;

initial begin

     # 200ms;

expect( @(posedge clk) a ##1 b ##1 c ) else $error( “expect failed” );

ABC: ...

end

endprogram

 

In the above example, the expect statement blocks the second statement in the initial block of program tst until the sequence a -> b -> c is recognized starting with the following clocking event (posedge clk) after 200ms. If the sequence is matched at the corresponding time, the process is unblocked and continues to execute on the statement labeled ABC. If the sequence fails then the else clause is executed, which in this case generates a run-time error. For the expect above to succeed, the sequence a–>b–>c must start on the clocking event (posedge clk) immediately after time 200ms.  If a is false on the first clocking event after 200ms, the expect fails. If a is true on the first clocking event after 200ms and b is false one clocking event later, the expect will also fail.

 

The expect statement can be incorporated in any procedural code, including tasks or class methods. Because it is a blocking statement, the property expression can safely refer to automatic variables as well as static variables. For example, the task below waits between 1 and 10 cycles for the variable data to have a particular value, which is an automatic argument. The second argument is used to return the result of the expect, 1 for success and 0 for failure.

 

integer data;

...

task automatic wait_for( integer value, output bit success );

expect( @(posedge clk) ##[1:10] data == value ) success = 1; else

success = 0;

endtask

 

initial begin

   bit ok;

wait_for( 23, ok );        // wait for the value 23

...

 end