Dear Readers,
Today I am going to share you one limitation with system Verilog class definition. We know Class is the basic feature to understand if we have to learn System Verilog. Class is the basic construct, data type in System Verilog. Some of the class feature I highlighted in my couple of previous blog posts can be found from here and here.
Methodological approach to name system Verilog class and major advantages
As a verification engineer with a mindset of methodological test bench architecture we prefer to name all data types, variables, blocks with meaningful names and their objects so that anybody with little understanding of that environment will be easily able to understand why is that class defined or what is the significant of adding this parameter? Let me give you a small example:
For example, a team of 3-5 engineers have developed a complex SoC or Block level verification environment using system Verilog. Environment is such complex that it has many classes defined to perform certain functional verification. Now with methodological approach usually engineers defined their test environment by classifying various configurable parameters and feature control and transaction based features and they will develop environment to accommodate these features in respected class called configuration class and transaction class respectively. They have given a names for cfg and transaction class to “rx_dma_cntrl_cfg” and “rx_dma_cntrl_tr”. Here “_cfg” represents configuration class while “_tr” represents transaction class which is quite common approach in today’s test bench developments.
Why do we need to follow these type of small-small things?
Well, answer to this question is “there are many advantage of following these type of approach while developing your test environment at the same time it does not cost you much”
Advantages:
- It helps in debugging the complex test environment as we all know “debugging is not free” and it always consumes amount of time and bandwidth in the verification cycles but we can always try to reduce the debugging efforts by following these small steps.
- Helps engineer to understand environment structure. This will be more helpful when new person joins in the team to work on this type of developed environment. It will surely reduce the reamp-up time for engineer and can easily pick up the tasks to update/modify/enhance such type of test bench environments.
- Helps in maintenance, enhancement and for re-usability
Limitation (while naming meaningful name to class)
We cannot name class starting with numeric number like 0,1,2 etc.. ! Class name is not allowed to have numbers as first character. Meaning you can’t give a class name called “8_bit_dma_env” or “8bit_dma_env”. Simulation will throw an error if you use this approach, instead it can be defined like “eight_bit_dma_env” or “dma8_bit_env” this is allowed because you are not using numeric number as first character of class name.
Let’s take an example of small exercises to understand :
program ASIC_With_Ankit;
class 1_byte_display_test;
int a;
byte awa = 8'hA5;
task display ();
$display ("Byte value =%h", awa);
endtask
endclass
initial begin
1_byte_display_test bdt;
bdt = new ();
bdt.display ();
end
endprogram
Solution :
In above example, you can see the class name uses first character as numberic number “1” which is not allowed in system Verilog and when you try compiling this code, you will see an error given below. But if you try the same example with changing a name to “one_byte_display_test” or “byte1_display_test”, you would be able to compile the same exercises without error
#################### ERROR ######################
-- Compiling program ASIC_With_Ankit
** Error: class.sv(3): near "1": syntax error, unexpected "INTEGER NUMBER", expecting "IDENTIFIER" or "TYPE_IDENTIFIER"
################################################
Hope this is useful information, keep reading “ASIC With Ankit” !
Enjoy !
ASIC With Ankit
