By Ronak Bhatt, Verification Engineer, eInfochips
For any design verification (DV) project, following best coding practices make life easier for the teammates. On the other hand, bad coding style leads to a lot of issues when the code is reused, or when it is handed over from one owner to another for any future enhancements. At times, it leads to a lot of rework and patches in the code, and makes the code really difficult to maintain in later stages of the project or for the future projects where it needs to be reused.
Quite often, while working on a design verification project, a need arises to divide a larger piece of code into a smaller chunks to make the code easier to read and debug (and also for the reusability purpose). Such smaller pieces of codes can be used at varied locations in the DV environment for multiple components/modules, etc.
Tasks and functions can be used to break the large, complex code into smaller and much simpler pieces of code which is easy to read and understand. Functions and tasks are mainly used to execute common functionality at several places in verification environment, but their usage is limited to the module or class access boundary in which they are defined. For some piece of code which is common and frequently used in different and completely isolated modules, the function/task can’t be directly reused due to their access boundary limitations.
To take a simple example, if a task-function has common code for two different monitors and for two different interfaces, a DV engineer mostly adds duplicate code in both the monitors. There are many other cases where we see code duplication. “System Verilog Macro” is one of the many solutions to address such duplication.
Such macro is very efficient and can help save a lot of time if used properly in the SV environment. This paper talks about such SV Macro and their syntaxes and also offers a few examples of where it can be used to save time during design verification.
What is a macro?
The term ‘macro’ refers to the substitution of a line or a few lines of text code. The directive “`define” creates a macro for substitution code. Once the macro is defined, it can be used anywhere in a compilation unit scope, wherever required.
It can be called by (`) character followed by the macro name. A macro can be defined with argument(s). Argument(s) are useful to customize the macro to use widely, like a function-task. Such macro argument(s) can be defined with default values so that if an DV engineer won’t pass any specific value, the macro substitutes the default value.
Single line macro:
As shown in the sample code above, macro “val” and “addition” are single line macros.
The above code is an example of a multiline macro. As shown above, for the multiline macro, the new line is preceded by a backslash “”. If the backslash is not present for a line, it is considered as the last line of the macro. The backslash will not be present in actual code where the macro is used and where the actual macro code is substituted.
Note: There should be no space or character after the backslash “” at the end of a line –otherwise the compiler shouts an error.
Possible syntaxes used to define a macro based on the usage of the below three special characters (quotations) along with the arguments, the actual code that it replaces has a different meaning. All possible macros can be formed using these three quotes:
1. “``” (Double tick)
The “``” quotation can be used to form a signal/variable name by using given argument.
Actual code the macro replaces:
We can see the ARG1 = 3 is used to form the variable’s name. (I.e. m_mst_3 and mst_3_lcl)
2. “`” “(Tick followed by a double quote)
The “`” “ quotation can be used to interpret the argument as a string. Example:
Actual code the macro replaces:
We can see the ARG1 is replaced with string name “a” in the $display statement.
3. “`\`” “(Tick followed by backslash followed by a double quote)
The “ `\” “ quotation is used to replace the argument with an escape sequence.
Actual code the macro replaces:
We can see that the argument is replaced with “ ”reg_a” “ in the $display line which prints as “Reg name : “reg_a”, value : ‘hXYZ” when it is executed.
The below section shows basic examples of use case scenarios where the macros can be used based on the DV needs. The usages of such macro can be extended to many more use cases.
Macro usage for coverpoint(s)
If the DV engineer wants to cover walk0/walk1 pattern bins of multiple variables of same width, then he/she can create and use the macro for all such signals for which walk1/walk0 cover bins are required.
Macro usage for a covergroup
Many times in a verification project, there is a need to write the same coverage at different places, for example, same code in master and slave components. We can define common macro for covergroup, which can be used in all such components.
“STRING” is an argument to the “bus_cg_macro” macro. Covergroup, coverpoints and their bins are substituted considering the “STRING” argument wherever the macro is used.
Macro usage in SV Assertion
As with coverage, many times in DV projects, we have some common assertions which can be used at multiple places and different components.
For example, there is a need to check that in master and slave, a signal value keeps changing at every clock cycle if the reset is not present. We can define a macro and use it for both master and slave.
Macro usage in Test Case Code
In a self-checking register write/read test, after each read, the read value is checked against expected read data. Considering design complexity, we may have multiple blocks and for each block we may have corresponding register test. For each such test we can have a common macro for self-check.
Macro usage in Procedural block
Macro to cover procedural block code which is common across multiple places.
Macro for procedural block:
This paper covers a few example macros, but DV engineers can create and use similar macros as per their project requirement and for reusability purpose.
Using SV macro, with the proper syntaxes explained in this paper, the DV engineer can break up the larger complex code in smaller chunk and can reuse it at many places. A macro can be used anywhere in the compilation unit after it is defined. The engineer can form identifier names using macro through input arguments.
Also, he/she can reuse names which are being used by ordinary identifiers/names. For example, ‘signal_name’ and ‘`signal_name’ are treated differently. He/she can define the macro multiple times and at the time of macro call, the latest definition is read by the compiler and is considered for that call.
SV macro is one of the most powerful features out there and if used properly with a thorough understanding and applied wisely in a DV project, it can help to save a lot of time and can make the code more readable and efficient.
About the author
Ronak Bhatt is a Verification Engineer at eInfochips. He has an industry experience of 1.8 years in ASIC Design Verification and has working experience in IP level and Chip level functional verification. He has hands-on experience in Functional and SVA-based verification.
If you wish to download a copy of this white paper, click here