In reply to hisingh:
Those sections address the topic of formal arguments
1800’2017: 16.8 Declaring sequences
1800’2017: 16.8.1 Typed formal arguments in sequence declarations
I wrote many many assertions, and I rarely see the need to declare sequences unless I am using the endpoints. I also rarely, if any, find the need to use formal arguments because assertions typically address very specific requirements and reusability is really very rare.
Thus, most of my sequence and property declarations have no formal arguments.
Of course, 1800 is a spec, thus to be complete, all kinds of rules an restrictions are defined; and they are confusing!
Typed formal arguments declared as local variables can be exported to the calling unit, such as the property or sequence, if they are prefixed with the reserved word local and are declared of direction inout or output. Variables declared in the assertion variable declaration region (i.e., those not in the port list) cannot be exported. Exporting of local variables enables the passing of local variables belonging to a host (e.g., property or sequence) to be executed by another unit (e.g., sequence), with the end results being transferred back to the original local variables of the host. Essentially, the local variables of one host are bound to the actual local variables of the actual arguments of another unit. This capability allows the easier integration of multiple simpler properties or sequences into complex properties or sequences. Your example represents this.
The following also acts this bounding.
sequence L_seq( local output int Ldata ); // What's the direction ( input / output / inout / ref ?? )
int k;
(1, k=20)// Used the 1 to simplify the test
( 1 , Ldata = 32 , $display(" TIME: %2t Ldata is %0d " , $time , Ldata ) ) ;
endsequence
...
1 ##1 L_seq( Hdata ) |-> ( 1 , $display(" TIME: %2t Hdata is %0d " , $time , Hdata ) ) ;
Again, my recommendation, forget about passing arguments; it makes the code harder to read particularly when writing many small assertions.
Ben Cohen http://www.systemverilog.us/ben@systemverilog.us
** SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
…
Avoid defining properties/sequences with arguments, especially if they are only going to be written once and right next to the assertion statement that uses it. It just added an extra layer of associations that can be difficult to follow. A better way is using the let statement
let x = really_long_signal_name_that_has_x_buried_inside_it;
let y = really_long_signal_name_that_has_y_buried_inside_it;
property p
x |-> y;
endproperty
But there are plenty of places where using arguments is helpful when there is repetition. In that case
Avoid declaring data types with arguments. Property/sequence definitions work similar to macros; the body of the definition just gets expanded into the location of the sequence/property location. Only declare formal data types if the property/sequence needs a particular datatype to function properly (e.g you plan non selecting a bit 0 of an argument and that needs to be the LSB).
Avoid declaring argument directions unless they are needed for the flow of local variables There might be other places, but I’ve never seen anyone use directions.
It does not make sense to say there are implicit default data types and directions for property/sequence arguments because they can be more complex like ‘$’ and ‘A ##1 B’.