What is the output of the following code :
Thursday, May 8, 2014
Wednesday, May 7, 2014
Tuesday, May 6, 2014
Monday, April 14, 2014
Thursday, April 10, 2014
Deciphering UVM - 1
The Methodology
There is enough written about OVM/UVM and the methodology. The need and use of it etc. etc. UVM is a collaborative effort by the EDA fraternity. It has standardized or atleast attempted to standardize the building of testbenches across the semiconductor industry. The pros and cons can be debated. But thats not the point. I was not quite happy just by using the methodology. So from the "how" the question turned into "why". And thats what I am exploring and in doing so I will go by the first principles way...
Lets look at the very basic building blocks of UVM.
UVM base classes
uvm_void
Present in uvm/src/base/uvm_misc.svh
This is the basic base class from which everything gets created. We can say the basic substratum of UVM (a little exaggeration !!). This is an abstract class with no data members or methods.
The code looks like this
virtual class uvm_void;
endclass
uvm_object
Present in uvm/src/base/uvm_object.svh
The code looks like this
virtual class uvm_object extends uvm_void;
'
'(properties / methods)
'
endclass
The uvm_object class is the base class for all further classes.
This class has approx. 36 methods which can be used for different purposes.
The uvm reference doc has details of how to use these methods. Of course the code also has comments. Some of the important methods are set_name, get_name, get_full_name, get_inst_id, get_inst_count, get_object_type, get_type_name, print, sprint, do_print, convert2string, record, copy, do_copy, compare, pack_bytes, unpack, set_int_local, use_uvm_seeding, reseed etc.There are some pure virtual methods like get_type_name and create.
uvm_report_object
Present in uvm/src/base/uvm_report_object.svh
The code looks like this
class uvm_report_object extends uvm_object;
'
'(properties / methods)
'
endclass
This class provides an interface to the uvm reporting mechanism. Through this interface uvm components generate different kinds of messages.
Some of the methods in this class are uvm_report, uvm_report_info, uvm_report_warning, uvm_report_error, uvm_report_fatal etc., The uvm_report_object takes help from the uvm_report_handler for most of its functions.
uvm_report_handler
Present in uvm/src/base/uvm_report_handler.svh
The code looks like this
class uvm_report_handler;
'
'(properties / methods)
'
uvm_report_handler handles most of the functions of the uvm_report_object. There is a one-to-one relationship between uvm_report_object and uvm_report_handler, but it can be many-to-one if several uvm_report_objects are configured to use the same uvm_report_handler object. The uvm_report_handler delegates handling of its reports to the uvm_report_server. The relationship between uvm_report_handler and uvm_report_server is many-to-one.
uvm_report_server
Present in uvm/src/base/uvm_report_server.svh
The code looks like this
class uvm_report_server extends uvm_object;
'
'(properties / methods)
'
endclass
uvm_report_server is a global server that processes all of the reports generated by an uvm_report_handler. Testbench is not supposed to be using the methods of the uvm_report_server.
uvm_report_catcher
Present in uvm/src/base/uvm_report_catcher.svh
The code looks like this
virtual class uvm_report_catcher extends uvm_callback;
'
'(properties / methods)
'
endclass
The uvm_report_catcher is used to catch messages issued by the uvm_report_servers.
We just discussed the uvm_report* classes just to get a hang of their utility and how things work under the hood.
Going back to our basic uvm_base classes...
uvm_component
Present in uvm/src/base/uvm_component.svh
The code looks like this
virtual class uvm_component extends uvm_report_object;
'
'(properties / methods)
'
endclass
The uvm_component class is the root base class for all uvm components. It contains all the features of uvm_object and uvm_report_object. On top of that it provides interfaces for hierarchy, phasing, configuration, reporting, transaction recording and factory. The uvm_component is automatically seeded during the construction using UVM seeding, if enabled. All other objects must be manually reseeded. Some of the methods in this class are: get_parent, get_full_name, get_children, get_child, set_name, lookup, get_depth, build, build_phase, connect_phase, connect, end_of_elaboration, end_of_elaboration_phase, start_of_simulation_phase, run_phase, run, pre_reset_phase, reset_phase, post_reset_phase, pre_configure_phase, configure_phase, post_configure_phase, pre_main_phase, main_phase, post_main_phase, shutdown_phase, extract_phase, check_phase, report_phase, final_phase, phase_started, phase_ready_to_end, phase_ended, set_domain, get_domain, suspend, resume, status, kill, do_kill_all, stop_phase, set_config_int, set_config_object, set_config_string, get_config_int, get_config_object, get_config_string, check_config_usage, apply_config_settings, print_config_settings, raised, dropped, all_dropped, create_object, create_component, set_type_override_by_type, set_type_override_by_inst, set_type_override, set_inst_override, set_report_verbosity_level_hier, begin_tr, do_being_tr, end_tr, do_end_tr etc.
From the list of the methods in the uvm_component class, we can easily infer is that this is a heavy weight class and host of methods which are at the heart of the UVM methodology. Hence it is important to make the discretion, when to use a uvm_component and when to use a uvm_object which is much lighter in weight.
uvm_transaction
Present in uvm/src/base/uvm_transaction.svh
The code looks like this
virtual class uvm_transaction extends uvm_object;
'
'(properties / methods)
'
endclass
The uvm_transaction class is the root base class for UVM transactions. It inherits all the methods and properties of the uvm_object. On top of that the uvm_transaction class adds a timing and recording interface. This class provides timestamp properties, notification events and transaction recording support. Important to note here, use of this class as a base for user-defined transactions is deprecated. Its subtype/child class uvm_sequence_item, shall be used as the base class for all user-defined transaction types.
Some of the methods in this class are: accept_tr, do_accept_tr, begin_tr, end_tr, get_tr_handle, disable_recording, enable_recording, is_active, get_event_pool, set_initiator, get_initiator, get_begin_time, get_end_time, set_transaction_id, get_transaction_id etc.
uvm_sequence_item
Present in uvm/src/seq/uvm_sequence_item.svh
The code looks like this
class uvm_sequence_item extends uvm_transaction;
'
'(properties / methods)
'
endclass
Well, this is a basic overview of the base classes that ultimately build UVM. The details of the methods and their applications can be found in the uvm source code. From a user perspective this post should connect some of the dots. This is just the beginning, more discussions to follow...
(source : UVM source code)
There is enough written about OVM/UVM and the methodology. The need and use of it etc. etc. UVM is a collaborative effort by the EDA fraternity. It has standardized or atleast attempted to standardize the building of testbenches across the semiconductor industry. The pros and cons can be debated. But thats not the point. I was not quite happy just by using the methodology. So from the "how" the question turned into "why". And thats what I am exploring and in doing so I will go by the first principles way...
Lets look at the very basic building blocks of UVM.
UVM base classes
Present in uvm
This is the basic base class from which everything gets created. We can say the basic substratum of UVM (a little exaggeration !!). This is an abstract class with no data members or methods.
The code looks like this
virtual class uvm_void;
endclass
uvm_object
Present in uvm
The code looks like this
virtual class uvm_object extends uvm_void;
'
'(properties / methods)
'
endclass
The uvm_object class is the base class for all further classes.
This class has approx. 36 methods which can be used for different purposes.
The uvm reference doc has details of how to use these methods. Of course the code also has comments. Some of the important methods are set_name, get_name, get_full_name, get_inst_id, get_inst_count, get_object_type, get_type_name, print, sprint, do_print, convert2string, record, copy, do_copy, compare, pack_bytes, unpack, set_int_local, use_uvm_seeding, reseed etc.There are some pure virtual methods like get_type_name and create.
uvm_report_object
Present in uvm/src/base/uvm_report_object.svh
The code looks like this
class uvm_report_object extends uvm_object;
'
'(properties / methods)
'
endclass
This class provides an interface to the uvm reporting mechanism. Through this interface uvm components generate different kinds of messages.
Some of the methods in this class are uvm_report, uvm_report_info, uvm_report_warning, uvm_report_error, uvm_report_fatal etc., The uvm_report_object takes help from the uvm_report_handler for most of its functions.
uvm_report_handler
Present in uvm/src/base/uvm_report_handler.svh
The code looks like this
class uvm_report_handler;
'
'
'
endclass
uvm_report_handler handles most of the functions of the uvm_report_object. There is a one-to-one relationship between uvm_report_object and uvm_report_handler, but it can be many-to-one if several uvm_report_objects are configured to use the same uvm_report_handler object. The uvm_report_handler delegates handling of its reports to the uvm_report_server. The relationship between uvm_report_handler and uvm_report_server is many-to-one.
uvm_report_server
Present in uvm/src/base/uvm_report_server.svh
The code looks like this
class uvm_report_server extends uvm_object;
'
'
'
endclass
uvm_report_server is a global server that processes all of the reports generated by an uvm_report_handler. Testbench is not supposed to be using the methods of the uvm_report_server.
uvm_report_catcher
Present in uvm/src/base/uvm_report_catcher.svh
The code looks like this
virtual class uvm_report_catcher extends uvm_callback;
'
'
'
endclass
The uvm_report_catcher is used to catch messages issued by the uvm_report_servers.
We just discussed the uvm_report* classes just to get a hang of their utility and how things work under the hood.
Going back to our basic uvm_base classes...
uvm_component
Present in uvm/src/base/uvm_component.svh
The code looks like this
virtual class uvm_component extends uvm_report_object;
'
'
'
endclass
The uvm_component class is the root base class for all uvm components. It contains all the features of uvm_object and uvm_report_object. On top of that it provides interfaces for hierarchy, phasing, configuration, reporting, transaction recording and factory. The uvm_component is automatically seeded during the construction using UVM seeding, if enabled. All other objects must be manually reseeded. Some of the methods in this class are: get_parent, get_full_name, get_children, get_child, set_name, lookup, get_depth, build, build_phase, connect_phase, connect, end_of_elaboration, end_of_elaboration_phase, start_of_simulation_phase, run_phase, run, pre_reset_phase, reset_phase, post_reset_phase, pre_configure_phase, configure_phase, post_configure_phase, pre_main_phase, main_phase, post_main_phase, shutdown_phase, extract_phase, check_phase, report_phase, final_phase, phase_started, phase_ready_to_end, phase_ended, set_domain, get_domain, suspend, resume, status, kill, do_kill_all, stop_phase, set_config_int, set_config_object, set_config_string, get_config_int, get_config_object, get_config_string, check_config_usage, apply_config_settings, print_config_settings, raised, dropped, all_dropped, create_object, create_component, set_type_override_by_type, set_type_override_by_inst, set_type_override, set_inst_override, set_report_verbosity_level_hier, begin_tr, do_being_tr, end_tr, do_end_tr etc.
From the list of the methods in the uvm_component class, we can easily infer is that this is a heavy weight class and host of methods which are at the heart of the UVM methodology. Hence it is important to make the discretion, when to use a uvm_component and when to use a uvm_object which is much lighter in weight.
uvm_transaction
Present in uvm/src/base/uvm_transaction.svh
The code looks like this
virtual class uvm_transaction extends uvm_object;
'
'
'
endclass
The uvm_transaction class is the root base class for UVM transactions. It inherits all the methods and properties of the uvm_object. On top of that the uvm_transaction class adds a timing and recording interface. This class provides timestamp properties, notification events and transaction recording support. Important to note here, use of this class as a base for user-defined transactions is deprecated. Its subtype/child class uvm_sequence_item, shall be used as the base class for all user-defined transaction types.
Some of the methods in this class are: accept_tr, do_accept_tr, begin_tr, end_tr, get_tr_handle, disable_recording, enable_recording, is_active, get_event_pool, set_initiator, get_initiator, get_begin_time, get_end_time, set_transaction_id, get_transaction_id etc.
uvm_sequence_item
Present in uvm/src/seq/uvm_sequence_item.svh
The code looks like this
class uvm_sequence_item extends uvm_transaction;
'
'(properties / methods)
'
endclass
This is the base class for user-defined sequence items as well as for the uvm_sequence class. This class provides the basic functionality for objects, both sequence items and sequences, to operate in the sequence mechanism.
Some of the methods in this class are: get_type_name, set_sequence_id, get_sequence_id, set_item_context, set_use_sequence_info, get_use_sequence_info, set_id_info, set_sequencer, get_sequencer, set_parent_sequence, get_parent_sequence, get_depth, is_item, get_full_name, get_root_sequence_name, get_sequence_path, uvm_report, uvm_report_info etc.
Well, this is a basic overview of the base classes that ultimately build UVM. The details of the methods and their applications can be found in the uvm source code. From a user perspective this post should connect some of the dots. This is just the beginning, more discussions to follow...
(source : UVM source code)
Monday, April 7, 2014
A Ruby routine to generate Kaprekar numbers
What are Kaprekar numbers ?
Kaprekar numbers are special numbers that were discovered by India mathematician Dattaraya Ramchandra Kaprekar. A more detailed explanation of Kaprekar and his numbers can be found here
http://en.wikipedia.org/wiki/Kaprekar_number
http://en.wikipedia.org/wiki/D._R._Kaprekar
This is a humble effort from my side to pay tribute to this great mathematician. Here is a Ruby routine to generate "n" Kaprekar numbers...
The output might look something like this...
Kaprekar numbers are special numbers that were discovered by India mathematician Dattaraya Ramchandra Kaprekar. A more detailed explanation of Kaprekar and his numbers can be found here
http://en.wikipedia.org/wiki/Kaprekar_number
http://en.wikipedia.org/wiki/D._R._Kaprekar
This is a humble effort from my side to pay tribute to this great mathematician. Here is a Ruby routine to generate "n" Kaprekar numbers...
The output might look something like this...
Thursday, March 6, 2014
OpenSource Simulators / Tools for Verification / VLSI Design
It had been a long cherished desire to see the development of opensource community in the VLSI industry. Though companies prefer to have paid tools because of their apparent reliability, many small start-ups never take-off because of the humongous cost of tools. The tools are costly because there is a huge amount of engineering R&D effort that lies behind the convenient user interface. Nevertheless a parallel opensource movement in the semiconductor community would definitely accelerate the technological development in the ASIC area.
The 2013 reports show that the current semiconductor industry revenues total upto $315 billions. Out of that the EDA industry had revenues of approximately 1.72 billions, which is about 0.5% of the entire semiconductor industry revenues. Which effectively explains how the value addition takes place further in the product lifecycle from raw RTL code to finished products. We as verification engineers live in the domain of RTL code and hence our jobs is to do quality verification with the tools available. However tools are not available that easily, they are expensive and smaller companies can afford only limited licenses. Having said that, the EDA industry acts as a key enabler in creating bug-free ASIC.
Within the given framework, ASIC development has to progress for new technologies to be proven fast. Hence a parallel opensource EDA development is not a bad idea. Actually it is a great idea.
What are the current free tools available :-
The 2013 reports show that the current semiconductor industry revenues total upto $315 billions. Out of that the EDA industry had revenues of approximately 1.72 billions, which is about 0.5% of the entire semiconductor industry revenues. Which effectively explains how the value addition takes place further in the product lifecycle from raw RTL code to finished products. We as verification engineers live in the domain of RTL code and hence our jobs is to do quality verification with the tools available. However tools are not available that easily, they are expensive and smaller companies can afford only limited licenses. Having said that, the EDA industry acts as a key enabler in creating bug-free ASIC.
Within the given framework, ASIC development has to progress for new technologies to be proven fast. Hence a parallel opensource EDA development is not a bad idea. Actually it is a great idea.
What are the current free tools available :-
- Fedora Electronics Lab - This is a high-end design and simulation platform with opensource EDA software
- EDA playground - http://www.edaplayground.com - You can type your code and simulate here
- http://dungspreader.blogspot.in/2013_03_01_archive.html - Some great ideas on opensource in verification
- http://www.semiwiki.com/forum/showwiki.php?title=Semi+Wiki:EDA+Open+Source+Tools+Wiki
- http://sourceforge.net/projects/veriwell/
- iverilog.icarus.com/
- http://sourceforge.net/projects/pvsim/
- http://www.veripool.org/wiki/verilator
- http://ghdl.free.fr/
- http://opencores.org/opencores,tools
- http://verilog.comuf.com/free.html
- iverilog.com/
- http://sourceforge.net/projects/gplcver/
- http://www.syncad.com/
- http://opencircuitdesign.com/verilog/
- http://www.myhdl.org/doku.php
- http://rhdl.rubyforge.org/
- http://www.sugawara-systems.com/
- http://verilog.openhpsdr.org/
- http://6004.csail.mit.edu/6.371/cadtools/gtkwave/wave.html
- http://gtkwave.sourceforge.net/
- https://cocotb.readthedocs.org/en/latest/index.html
- https://github.com/potentialventures/cocotb
- http://www.gpleda.org
- http://jeffrey.co.in/blog/2014/01/installing-migen
Monday, March 3, 2014
Constants in SystemVerilog
Here is a brief note on SV - constants. Constants are data objects that never change. SV provides the following types of constants.
Elaboration time constants:-
1) parameter - A parameter has two attributes, type and range.
e.g. parameter logic[7:0] BASE_ADDR = 8;
By default a parameter would take the type and range of the final value assigned to it. By default any parameter would be unsigned. Hierarchical references are not allowed in parameter declarations, reason being these are elaboration type constants. Package references are however allowed in parameter declarations. A parameter can be overridden by a defparam statement. However there is an exception in case of type parameters.
Type parameters:- A parameter constant which specifies a data type, e.g.,
A type parameter cannot be overridden by a defparam statement.
2) localparam - local parameters (localparam) are identical to paramters except they cannot be overridden by defparam or instance parameter value assignments.Inside a compilation unit, generate block, package or class body, parameter and localparam are synonymous.
3) specparam - this is a parameter type intended only for providing timing values or delays. These can be declared within specify blocks or the module body.
Note: specparam and param are not interchangeable.
Run-time constant:-
1) const - const can be set during elaboration and simulation/run time. However localparam can be set only during elaboration time.
The following code-snippet might give some insights into the usage details of the different constant types.
Parameter as $ : Parameter can be assigned a value $ for integer types only.
The LRM gives an example in terms of assertions.
It would be interesting to run the following code-snippet and see how different simulators respond to it.
A note on defparam : Parameter values can be changed in any module, interface or program using cross-module references using the defparam statement.
However the SV-2012 LRM does give an indication to deprecate this feature in future versions, hence it is a good idea to take care of not using this feature where re-usability is of prime importance (which is always !!)
Elaboration time constants:-
1) parameter - A parameter has two attributes, type and range.
e.g. parameter logic[7:0] BASE_ADDR = 8;
By default a parameter would take the type and range of the final value assigned to it. By default any parameter would be unsigned. Hierarchical references are not allowed in parameter declarations, reason being these are elaboration type constants. Package references are however allowed in parameter declarations. A parameter can be overridden by a defparam statement. However there is an exception in case of type parameters.
Type parameters:- A parameter constant which specifies a data type, e.g.,
module m1 (parameter type p1 = shortint);
p1 i = 0; // i here is shortint
initial begin
int j = 0;
j = i + 2;
.
.
end
endmoduleA type parameter cannot be overridden by a defparam statement.
2) localparam - local parameters (localparam) are identical to paramters except they cannot be overridden by defparam or instance parameter value assignments.Inside a compilation unit, generate block, package or class body, parameter and localparam are synonymous.
3) specparam - this is a parameter type intended only for providing timing values or delays. These can be declared within specify blocks or the module body.
Note: specparam and param are not interchangeable.
Run-time constant:-
1) const - const can be set during elaboration and simulation/run time. However localparam can be set only during elaboration time.
The following code-snippet might give some insights into the usage details of the different constant types.
Parameter as $ : Parameter can be assigned a value $ for integer types only.
The LRM gives an example in terms of assertions.
It would be interesting to run the following code-snippet and see how different simulators respond to it.
A note on defparam : Parameter values can be changed in any module, interface or program using cross-module references using the defparam statement.
However the SV-2012 LRM does give an indication to deprecate this feature in future versions, hence it is a good idea to take care of not using this feature where re-usability is of prime importance (which is always !!)
Subscribe to:
Posts (Atom)