In the past blog articles, we had focused on examples using VMM to discuss creation of a comprehensive verification methodology using SystemVerilog. The need for a common verification methodology has led to creation of Universal Verification Methodology (UVM) and an early adapter’s (EA) release was announced during the last DAC. This release can be downloaded from the Accellera website. Going forward, we will look into some of work and advances in UVM (as it moves to UVM 1.0 from the UVM EA release) as the work by an Accellera committee comprising of representatives from verification user companies such as Cisco, Freescale, Intel, and IBM along with the EDA companies including Cadence, Mentor, and Synopsys.
Some of the major areas of ongoing work include defining time-consuming phases in the simulation, register abstraction layer, and the TLM2 modeling.
Backward compatibility required that any additional time-consuming phases be run parallel to the run() phase defined in the EA release. SoC projects require a common test flow to ensure module-level environments easily integrate into the full-chip environment and the execution of simulation can move from one phase to another phase when all tasks (including all outstanding transactions) of the previous phase have completed. Being able to run these phases in parallel to the single run() phase defined in the EA release is the suggested way to make this enhancement.
Synopsys’ UVM Register Abstraction Layer (RAL) is an application package that can be used to automate the creation of object-oriented models of registers and memories inside a design. Janick Bergeron of Synopsys is leading the effort here that brings in years of earlier work done at Synopsys with SysytemVerilog VMM methodology work.
SystemC TLM2 standard is targeted to enable development of interoperable high-speed transaction-level models for virtual platforms in SystemC. These models need to memory-mapped bus-based systems at high speed such that software can be run on a virtual platform at near real-time speed. TLM2 is a complex standard and difficult to be mapped to languages other than SystemC. Some user-level requirements for a TLM2 implementation in UVM1.0 have been defined and they focus on TLM2 subset that includes generic payloads, blocking and non-blocking transport, and base protocols but no SystemC support.
We will look into some of these developments in more detail as the work on UVM advances at Accellera.
Sunday, August 29, 2010
Monday, April 5, 2010
Reasons for Improved Productivity with VMM for RTL Engineers
When looking at a possible move to use of advanced verification methodologies such as VMM, a natural question that comes to the mind of an RTL verification engineer is whether such a move will be productive. Is it worth the cost of learning a new programming paradigm? Are there significant productivity gains to be had with such a move?
These questions can be answered if we take a closer look at what VMM provides to an RTL verification engineer that is different from the verification environment created at RTL. Productivity gains are a result years of software development work that has resulted in VMM infrastructure that helps streamline the overall verification task. It streamlines the overall task of verification by, i) separating the task of creating the verification environment from the task of writing testcases, ii) creating the verification environment itself in a layered fashion, iii) allowing control of simulation in a standardized fashion, and iv) enabling reuse of the verification work as a by-product. Let’s take a look at each of these points in a bit more detail.
Separation of the verification environment & testcases:
It adds to overall productivity in the complex task of achieving goals of design verification in much the same way as hierarchical design add to the productivity in creating DUTs. A well designed verification environment provides simple controls for verification parameters leading to the ease of creation of testcases that accomplish the goals of verification. The verification hierarchy, at a macro level, consists of a verification environment that interacts with the DUT and a set of test cases interact with the verification environment.
Standardized approach to the creation of verification environment:
The verification environment itself can be created in a hierarchical fashion using a set of standard layers that would be needed in a typical design verification task.
A verification environment provides means for signal-level interaction with the DUT at the lowest level.
These signals can be driven, monitored, and checked via a set of commands that work with a higher-level data structures such as packets and drive signal-level interactions.
The DUT provides capabilities that enable higher-level operations and functional transactions are the abstractions of these higher-level operations performed by the DUT. These higher-level operations can lead to a set of packets being driven on to some interfaces and results monitored and checked on the same or some other interfaces. The functional layer results from a combination of commands in sequential and/or hierarchical fashion.
The transactions at the functional layer can be generated randomly or can be generated in a coordinated fashion to result in a specific sequence of random transactions. You are generating various scenarios that can used by testcases to target specific goals of verification.
A testcase then modifies constraints on transaction generators, defines new scenarios, and synchronizes various transactions occurring to accomplish the goals of a testcase. As a result of these layering structures, the communications between the DUT and the verification environment is at transaction-level as opposed to signal-level resulting in productivity gains in testcase creation.
Standardized simulation control:
Standardized simulation control is possible with the clean separation of verification environment and the testcase along with standard layering of the verification environment. The standard steps in simulation control for a test case after its configuration involves building of the verification environment, configuring the DUT after reset, getting all associated transactors and generators started, detecting the end-of-test condition, stopping transactors and generators, and reporting the results.
Testbench Reuse:
Testbench reuse is a natural outcome of hierarchical creation of the verification environment with standard layers.
• Testcases are created at the very top-level and decoupling them from the environment itself allows for ease of creation. The bulk of the code is written to create the environment that can be reused not only over generations of the same design but also with different designs using some common physical level interfaces.
• The use of standardized and higher-level communication between components enables reuse.
• Standardized transactions via scenario generators enable reuse.
• Layering of the verification environment contributes to reuse at each level and across levels. Signal layer can be used, Signal and command layer can be reused, and so on.
• Even analysis and reporting components can be reused due to their modular construction.
So for an RTL verification engineer, VMM provides a methodology and associated capabilities for efficiently developing a verification environment that is likely to highly reusable. Productivity gains are a result years of software development work that has resulted in the VMM infrastructure that helps streamline the overall verification through modular and flexible development of the verification environment resulting in ease of creation of tetscases.
These questions can be answered if we take a closer look at what VMM provides to an RTL verification engineer that is different from the verification environment created at RTL. Productivity gains are a result years of software development work that has resulted in VMM infrastructure that helps streamline the overall verification task. It streamlines the overall task of verification by, i) separating the task of creating the verification environment from the task of writing testcases, ii) creating the verification environment itself in a layered fashion, iii) allowing control of simulation in a standardized fashion, and iv) enabling reuse of the verification work as a by-product. Let’s take a look at each of these points in a bit more detail.
Separation of the verification environment & testcases:
It adds to overall productivity in the complex task of achieving goals of design verification in much the same way as hierarchical design add to the productivity in creating DUTs. A well designed verification environment provides simple controls for verification parameters leading to the ease of creation of testcases that accomplish the goals of verification. The verification hierarchy, at a macro level, consists of a verification environment that interacts with the DUT and a set of test cases interact with the verification environment.
Standardized approach to the creation of verification environment:
The verification environment itself can be created in a hierarchical fashion using a set of standard layers that would be needed in a typical design verification task.
A verification environment provides means for signal-level interaction with the DUT at the lowest level.
These signals can be driven, monitored, and checked via a set of commands that work with a higher-level data structures such as packets and drive signal-level interactions.
The DUT provides capabilities that enable higher-level operations and functional transactions are the abstractions of these higher-level operations performed by the DUT. These higher-level operations can lead to a set of packets being driven on to some interfaces and results monitored and checked on the same or some other interfaces. The functional layer results from a combination of commands in sequential and/or hierarchical fashion.
The transactions at the functional layer can be generated randomly or can be generated in a coordinated fashion to result in a specific sequence of random transactions. You are generating various scenarios that can used by testcases to target specific goals of verification.
A testcase then modifies constraints on transaction generators, defines new scenarios, and synchronizes various transactions occurring to accomplish the goals of a testcase. As a result of these layering structures, the communications between the DUT and the verification environment is at transaction-level as opposed to signal-level resulting in productivity gains in testcase creation.
Standardized simulation control:
Standardized simulation control is possible with the clean separation of verification environment and the testcase along with standard layering of the verification environment. The standard steps in simulation control for a test case after its configuration involves building of the verification environment, configuring the DUT after reset, getting all associated transactors and generators started, detecting the end-of-test condition, stopping transactors and generators, and reporting the results.
Testbench Reuse:
Testbench reuse is a natural outcome of hierarchical creation of the verification environment with standard layers.
• Testcases are created at the very top-level and decoupling them from the environment itself allows for ease of creation. The bulk of the code is written to create the environment that can be reused not only over generations of the same design but also with different designs using some common physical level interfaces.
• The use of standardized and higher-level communication between components enables reuse.
• Standardized transactions via scenario generators enable reuse.
• Layering of the verification environment contributes to reuse at each level and across levels. Signal layer can be used, Signal and command layer can be reused, and so on.
• Even analysis and reporting components can be reused due to their modular construction.
So for an RTL verification engineer, VMM provides a methodology and associated capabilities for efficiently developing a verification environment that is likely to highly reusable. Productivity gains are a result years of software development work that has resulted in the VMM infrastructure that helps streamline the overall verification through modular and flexible development of the verification environment resulting in ease of creation of tetscases.
Monday, December 7, 2009
Importance of Methodology in SoC Power Management Verification
Power management techniques that leverage voltage as a handle are being extensively used in power sensitive designs. These techniques include: Power Gating (PG), Power Gating with Retention (RPG), Multiple Supply Voltages (MSV), Dynamic Voltage Scaling (DVS), Adaptive Voltage Scaling (AVS), Multi-Threshold CMOS (MTCMOS), and Active Body Bias (ABB). The use of the power management techniques also imply new challenges in validation and testing of designs as new power states are created.
It is important that the lessons learned from validating power management of a design are captured as part of verification methodology and reused in later designs or future versions of the same design. Also, parts of established verification methodology can reused to address tasks needed in power management validation.
Power sequencing protocol is a good example of a task that appears in all power managed designs. Power sequencing typically follows a well-defined set of steps in designs that use power gating and state retention. These set of steps include:
• Disabling or gating the clock
• Saving state of registers in either special registers or in memory that is not powered off
• Enabling isolation for the block that has been powered off
• Disabling power to the block using a power switch
• Enabling power at the end of power gated mode
• Restoring saved register values
• Disabling isolation of the block
• Enabling the gated clock
This sequence or a simple variation sequence depending upon whether state retention is used or not is used in all power gated designs and potentially in different power-modes of the same design. The verification involves following a set of rules and routines to validate the sequence and can be part of infrastructure for verification of all power managed designs.
Another example can be the use of VMM Register Abstraction Layer (RAL) in the context of power management verification. VMM RAL is an application package to create abstract model of registers and memories inside a design that can used in the context of SystemVerilog based verification. It includes:
• Pre-defined tests to verify implementation of registers and memories
• Functional coverage model to ensure various bits of register have been tested
Power management software routines exercise various power modes of the design setting relevant bits in power control registers. VMM RAL can be used to manage this process through tests exercise various power modes through the setting of appropriate bits in power control registers and a coverage model can ensure that various power modes of the design have been exercised.
Power management verification should be seen as an extension of established verification methodology rather than a start from scratch. It does bring new elements like power-aware simulation (which can be seen as additional features in an existing simulator), dealing with specialized power-related signals and controls, and special power-related cells like switches, level-shifters, and isolation logic but these can be dealt with in the context of a verification methodology that builds upon an existing one.
It is important that the lessons learned from validating power management of a design are captured as part of verification methodology and reused in later designs or future versions of the same design. Also, parts of established verification methodology can reused to address tasks needed in power management validation.
Power sequencing protocol is a good example of a task that appears in all power managed designs. Power sequencing typically follows a well-defined set of steps in designs that use power gating and state retention. These set of steps include:
• Disabling or gating the clock
• Saving state of registers in either special registers or in memory that is not powered off
• Enabling isolation for the block that has been powered off
• Disabling power to the block using a power switch
• Enabling power at the end of power gated mode
• Restoring saved register values
• Disabling isolation of the block
• Enabling the gated clock
This sequence or a simple variation sequence depending upon whether state retention is used or not is used in all power gated designs and potentially in different power-modes of the same design. The verification involves following a set of rules and routines to validate the sequence and can be part of infrastructure for verification of all power managed designs.
Another example can be the use of VMM Register Abstraction Layer (RAL) in the context of power management verification. VMM RAL is an application package to create abstract model of registers and memories inside a design that can used in the context of SystemVerilog based verification. It includes:
• Pre-defined tests to verify implementation of registers and memories
• Functional coverage model to ensure various bits of register have been tested
Power management software routines exercise various power modes of the design setting relevant bits in power control registers. VMM RAL can be used to manage this process through tests exercise various power modes through the setting of appropriate bits in power control registers and a coverage model can ensure that various power modes of the design have been exercised.
Power management verification should be seen as an extension of established verification methodology rather than a start from scratch. It does bring new elements like power-aware simulation (which can be seen as additional features in an existing simulator), dealing with specialized power-related signals and controls, and special power-related cells like switches, level-shifters, and isolation logic but these can be dealt with in the context of a verification methodology that builds upon an existing one.
Friday, October 16, 2009
SystemC TLM2.0 and SystemVerilog Verification Methodologies
TLM2.0 is the version 2.0 of Open SystemC (IEEE 1666) Initiative (OSCI) [1] standard and it is a layer on top of SystemC which itself is based on C++ language. TLM stands for Transaction-level Modeling which is an abstraction layer above RTL with the primary goal to accelerate simulation by avoiding detailed pin-level events that occur in RTL simulation.
In recent times, we have seen SystemVerilog based methodologies extend support for SystemC TLM2.0 standard. For example, Synopsys’ VMM Release 1.2 [2] supports TLM2.0 by adding remote procedure call functionality between components and extending support to SystemC modules.
TLM 2.0 is used in virtual platform models that are typically created to validate a system-on-a-chip (SoC) with multiple processor cores, busses, software stacks running on cores, and specialized digital and analog hardware IP blocks. These virtual platforms can accurately model functionality and registers in the SoC design without dealing with clocks and pins and are fast enough to boot software part of the system that may be available long before the creation of system RTL.
TLM provides mechanisms that can described as the glue that ties various IPs together in carrying out virtual platform simulation of the SoC. Some of the use cases of a virtual platform based on TLM are:
• Software Development
• Software Performance Evaluation
• Architectural Analysis
• Hardware Verification
The users of SystemVerilog based methodologies such as VMM leverage infrastructure and knowledge base to create verification needs for validating SoCs. The hardware verification task is similar to the virtual platform development in the sense that the verification works typically gets started even before the RTL may be available.
TLM2.0 core interfaces and sockets (mechanism for interoperability) can connect to VMM channels and notification. With the support of TLM2.0 in SystemVerilog based verification methodologies enables either building of or leveraging existing hardware verification environment early in the SoC design process that can be used to validate the SoC virtual platform model and then used later in validating the SoC at the RTL level.
Virtual platform that is created to accomplish key tasks of early software development, performance evaluation, and architectural analysis leverages and helps solidify a verification infrastructure based on SystemVerilog to be reused later in RTL validation also. Both the virtual platform and the verification teams can benefit from this connection.
[1] www.systemc.org
[2] www.vmmcentral.org
In recent times, we have seen SystemVerilog based methodologies extend support for SystemC TLM2.0 standard. For example, Synopsys’ VMM Release 1.2 [2] supports TLM2.0 by adding remote procedure call functionality between components and extending support to SystemC modules.
TLM 2.0 is used in virtual platform models that are typically created to validate a system-on-a-chip (SoC) with multiple processor cores, busses, software stacks running on cores, and specialized digital and analog hardware IP blocks. These virtual platforms can accurately model functionality and registers in the SoC design without dealing with clocks and pins and are fast enough to boot software part of the system that may be available long before the creation of system RTL.
TLM provides mechanisms that can described as the glue that ties various IPs together in carrying out virtual platform simulation of the SoC. Some of the use cases of a virtual platform based on TLM are:
• Software Development
• Software Performance Evaluation
• Architectural Analysis
• Hardware Verification
The users of SystemVerilog based methodologies such as VMM leverage infrastructure and knowledge base to create verification needs for validating SoCs. The hardware verification task is similar to the virtual platform development in the sense that the verification works typically gets started even before the RTL may be available.
TLM2.0 core interfaces and sockets (mechanism for interoperability) can connect to VMM channels and notification. With the support of TLM2.0 in SystemVerilog based verification methodologies enables either building of or leveraging existing hardware verification environment early in the SoC design process that can be used to validate the SoC virtual platform model and then used later in validating the SoC at the RTL level.
Virtual platform that is created to accomplish key tasks of early software development, performance evaluation, and architectural analysis leverages and helps solidify a verification infrastructure based on SystemVerilog to be reused later in RTL validation also. Both the virtual platform and the verification teams can benefit from this connection.
[1] www.systemc.org
[2] www.vmmcentral.org
Wednesday, September 9, 2009
Key SystemVerilog Resources on the Web
There were some suggestions from readers to have a listing of resources/references for SystemVerilog (SV) and associated methodologies. Here is a list of some these resources that I have used in the past:
· SV Language Standardization, LRM, and Extensions: http://www.systemverilog.org/
· Free SV Language Reference Manual on Web: http://www.eda.org/sv/SystemVerilog_3.1a.pdf
· Verification Methodology Manual (VMM) for SV: http://www.vmmcentral.org/
· Open Verification Methodology(OVM) for SV: http://www.ovmworld.org/
· Blogs:
o Verification Martial Arts: http://www.vmmcentral.org/vmartialarts/
o Verification Guild: http://verificationguild.com/
o Guide to SV-VMM: http://learn-systemverilog.blogspot.com/
· SystemVerilog Books:
o By Janick Bergeron (Review content of the books at this link)
http://books.google.com/books?id=ZWZAkWkNy3cC&printsec=frontcover&dq=SystemVerilog+Manual&source=gbs_similarbooks_s&cad=1#v=onepage&q=SystemVerilog%20Manual&f=false
o By Bergeron, Cerny, Hunter, and Nightingale (Review contents at this link:)
http://books.google.com/books?id=dcET3kKtmH4C&dq=SystemVerilog+Manual&printsec=frontcover&source=in&hl=en&ei=W8CnSr2hA8vZnAfasdWwBw&sa=X&oi=book_result&ct=result&resnum=12#v=onepage&q=&f=false
o Sutherland, Davidmann, and Flake (Review contents at this link:)
http://books.google.com/books?id=EeIVYPd9iDAC&dq=SystemVerilog+Manual&printsec=frontcover&source=in&hl=en&ei=W8CnSr2hA8vZnAfasdWwBw&sa=X&oi=book_result&ct=result&resnum=11#v=onepage&q=SystemVerilog%20Manual&f=false
· SV Language Standardization, LRM, and Extensions: http://www.systemverilog.org/
· Free SV Language Reference Manual on Web: http://www.eda.org/sv/SystemVerilog_3.1a.pdf
· Verification Methodology Manual (VMM) for SV: http://www.vmmcentral.org/
· Open Verification Methodology(OVM) for SV: http://www.ovmworld.org/
· Blogs:
o Verification Martial Arts: http://www.vmmcentral.org/vmartialarts/
o Verification Guild: http://verificationguild.com/
o Guide to SV-VMM: http://learn-systemverilog.blogspot.com/
· SystemVerilog Books:
o By Janick Bergeron (Review content of the books at this link)
http://books.google.com/books?id=ZWZAkWkNy3cC&printsec=frontcover&dq=SystemVerilog+Manual&source=gbs_similarbooks_s&cad=1#v=onepage&q=SystemVerilog%20Manual&f=false
o By Bergeron, Cerny, Hunter, and Nightingale (Review contents at this link:)
http://books.google.com/books?id=dcET3kKtmH4C&dq=SystemVerilog+Manual&printsec=frontcover&source=in&hl=en&ei=W8CnSr2hA8vZnAfasdWwBw&sa=X&oi=book_result&ct=result&resnum=12#v=onepage&q=&f=false
o Sutherland, Davidmann, and Flake (Review contents at this link:)
http://books.google.com/books?id=EeIVYPd9iDAC&dq=SystemVerilog+Manual&printsec=frontcover&source=in&hl=en&ei=W8CnSr2hA8vZnAfasdWwBw&sa=X&oi=book_result&ct=result&resnum=11#v=onepage&q=SystemVerilog%20Manual&f=false
Monday, August 3, 2009
Creating Flexible and Consistent Transactions
Continuing on benefits for those who are used to working with RTL language and building on a methodology-based logging mechanism, we will next look into generation and use of transactions facilitated via a comprehensive VMM verification methodology.
Transactors are components of verification environment that interface between different levels of a protocol implementation. Going back to our ATM example, at a higher level, you will generate ATM frames that will eventually be driven on to a physical interface such as Utopia Level-1 or Level-2. An ATM cell generator mechanism that provides such an interface to the Utopia physical interface is a transactor. So generators, drivers, monitors, and checkers are example of such transactors.
Bus functional models (BFMs) are command-layer transactors which include transaction-level interface on one side and physical interface on the other. Other types of transactors include functional-layer and scenario-layer.
Transactors should be flexible and consistent given that they and consistent given that they are likely to be reused in multiple testcases and potentially across different verification environment. For example, a well-designed USB interface verification environment can be used across many designs that use USB interface. Transactors should meet specific needs for various test cases and hence need to be controllable. Also, transactors should be able to be extended to meet needs of a verification environment.
With the goals of creating flexible and consistent transactions, vmm_xactor provides a template from which we can derive various transactors of typical interest in a verification environment. It contains standard properties and methods to configure and control transactors in a way that results in a consistent usage model for all transactors derived from the same base class.
The properties of vmm_xactor class are similar to the vmm_data class as we discussed in a prior blog and the basic methods of the vmm_xactor class include:
· the constructor method, new()
· start_xactor(): controls execution of the main method, forks it off. It can be extended to include protocol specific behavior.
· reset_xactor(): control execution of the main method, terminates it.
· stop_xactor() and some variations of stop to allow blocking and non-blocking conditions, control execution of the main method, terminates it.
· main() is spawned when start_xactor() is called from upper layers and all threads are forked and join in the body if main() task.
So an ATM Utopia layer driving transactor will extend vmm_xactor to define a transactor as follows:
class utopia1_driver extends vmm_xactor;
//declare property members of the utopia1_layer_driver such as channels, interfaces
function new (string inst, int stream_id = -1, …);
//standard constructor specific code
endfunction: new
virtual function void start_xactor();
super.start_xactor();
//any utopia1_driver specific code
endfunction: start_xactor
virtual function void reset_xactor();
super.reset_xactor();
//any utopia1_driver specific code
endfunction: reset_xactor
virtual function void stop_xactor();
super.stop_xactor();
//any utopia1_driver specific code
endfunction: stop_xactor
virtual protected task main();
super.main();
// code for main functionality of utopia1_driver
forever begin
//generate transaction
//drive transaction
endtask: main
endclass: utopia1_driver
Physical interfaces when specified use “virtual modport interface” that allows each instance of transactor to be connected to a specific interface instance without hardcoding signal naming.
class utopia1_driver extends vmm_xactor;
virtual atm_if.utopia1 sigs;
:
endclass: utopia1_driver
The traditional BFMs are physical-level BFMs and are tied to specific physical-level interface. With vmm_transactor, BFMs need not be tied to physical interfaces but can purely be implementation independent transaction-level BFM.
Transaction-level interface also requires a concept of vmm_channels to remove higher-level layers from the physical interface details. Channel is a conduit that is used to exchange information between transactors and we will next look into channels and transaction-level interfaces
The latest release of VMM (VMM 1.2) also implements a set of transport interface classes based on OSCI TLM 2.0 standard that provide standard transaction-level modeling communication methods. This adds remote procedure call functionality between components and extends support to SystemC modules. As a result, one can now easily integrate reference models written in SystemC with TLM-2.0 transport interface directly in your VMM testbench. As we go further in this blog, we will look into also relevant SystemC developments and how this plays into system-level verification using a SystemVerilog verification methodology.
Transactors are components of verification environment that interface between different levels of a protocol implementation. Going back to our ATM example, at a higher level, you will generate ATM frames that will eventually be driven on to a physical interface such as Utopia Level-1 or Level-2. An ATM cell generator mechanism that provides such an interface to the Utopia physical interface is a transactor. So generators, drivers, monitors, and checkers are example of such transactors.
Bus functional models (BFMs) are command-layer transactors which include transaction-level interface on one side and physical interface on the other. Other types of transactors include functional-layer and scenario-layer.
Transactors should be flexible and consistent given that they and consistent given that they are likely to be reused in multiple testcases and potentially across different verification environment. For example, a well-designed USB interface verification environment can be used across many designs that use USB interface. Transactors should meet specific needs for various test cases and hence need to be controllable. Also, transactors should be able to be extended to meet needs of a verification environment.
With the goals of creating flexible and consistent transactions, vmm_xactor provides a template from which we can derive various transactors of typical interest in a verification environment. It contains standard properties and methods to configure and control transactors in a way that results in a consistent usage model for all transactors derived from the same base class.
The properties of vmm_xactor class are similar to the vmm_data class as we discussed in a prior blog and the basic methods of the vmm_xactor class include:
· the constructor method, new()
· start_xactor(): controls execution of the main method, forks it off. It can be extended to include protocol specific behavior.
· reset_xactor(): control execution of the main method, terminates it.
· stop_xactor() and some variations of stop to allow blocking and non-blocking conditions, control execution of the main method, terminates it.
· main() is spawned when start_xactor() is called from upper layers and all threads are forked and join in the body if main() task.
So an ATM Utopia layer driving transactor will extend vmm_xactor to define a transactor as follows:
class utopia1_driver extends vmm_xactor;
//declare property members of the utopia1_layer_driver such as channels, interfaces
function new (string inst, int stream_id = -1, …);
//standard constructor specific code
endfunction: new
virtual function void start_xactor();
super.start_xactor();
//any utopia1_driver specific code
endfunction: start_xactor
virtual function void reset_xactor();
super.reset_xactor();
//any utopia1_driver specific code
endfunction: reset_xactor
virtual function void stop_xactor();
super.stop_xactor();
//any utopia1_driver specific code
endfunction: stop_xactor
virtual protected task main();
super.main();
// code for main functionality of utopia1_driver
forever begin
//generate transaction
//drive transaction
endtask: main
endclass: utopia1_driver
Physical interfaces when specified use “virtual modport interface” that allows each instance of transactor to be connected to a specific interface instance without hardcoding signal naming.
class utopia1_driver extends vmm_xactor;
virtual atm_if.utopia1 sigs;
:
endclass: utopia1_driver
The traditional BFMs are physical-level BFMs and are tied to specific physical-level interface. With vmm_transactor, BFMs need not be tied to physical interfaces but can purely be implementation independent transaction-level BFM.
Transaction-level interface also requires a concept of vmm_channels to remove higher-level layers from the physical interface details. Channel is a conduit that is used to exchange information between transactors and we will next look into channels and transaction-level interfaces
The latest release of VMM (VMM 1.2) also implements a set of transport interface classes based on OSCI TLM 2.0 standard that provide standard transaction-level modeling communication methods. This adds remote procedure call functionality between components and extends support to SystemC modules. As a result, one can now easily integrate reference models written in SystemC with TLM-2.0 transport interface directly in your VMM testbench. As we go further in this blog, we will look into also relevant SystemC developments and how this plays into system-level verification using a SystemVerilog verification methodology.
Tuesday, July 7, 2009
On Methods Associated with Data Generation
Tasks and functions form the core of the code in various functional verification environments. For example, for bus functional models, you will need tasks such as read, write, request, and grant working over the interface. For data such as packets, cells, and frame to be delivered over an interface defined through a bus functional model, you need methods to copy and compare the data, and to display the data as and when appropriate.
We go back to the previous blog article that talks about efficient data generation using the VMM approach, and now talk about some of the methods associated with data item like the ATM cell.
One of the first methods that we need is called the constructor method for the ATM cell object; this is needed in object-oriented programming to be able to create a new instance of the object such as the ATM cell. Here, we just need to call its parent class’ constructor method called new() which is predefined for us. So defining the constructor methods is fairly mechanical and looks something like this:
//constructor method for the atm_cell class
function new();
super.new(log);
endfunction: new
There is an allocate() method for vmm_data to create a new instance of data transaction. It allocates a new instance of the same type as the object instance and returns a reference to the instance.
//allocate() method for the atm_cell class
function vmm_data allocate(vmm_data to = null);
atm_cell transaction = new;
return transaction;
endfunction: allocate
Typically, for any data item that we create, we will need a printing utility to able to display the relevant portions of the data item being generated. We can define a display method for printing information regarding the ATM cell being generated.
//display method for the atm_cell class
//to print a prefix message followed by vpi and vci fields
function string psdisplay (string prefix-msg);
$sformat (psdisplay, “ %s : [%d :%d]”,
prefix-msg, this.vpi, this.vci);
endfunction: psdisplay
Just like the constructor and allocate methods, the definition of the copy method is fairly mechanical and only has a section of code that is specific to the data item being defined. It copies the current value of the object instance into the specified object instance. If no object instance is specified then a new instance is allocated. The copy method for the ATM cell looks as follows:
//copy method for the atm_cell class
function vmm_data copy (vmm_data to = null);
atm_cell cell_copy;
if (to == null)
cell_copy = new();
else if (!$cast(cell_copy, to)) begin
‘vmm_fatal (this.log, “Not an ATM cell”);
cell_copy = null;
return;
end
super.copy_data(cell_copy);
cell_copy.vpi = this.vpi;
cell_copy.vci = this.vci;
cell_copy.pt = this.pt;
cell_copy.clp = this.clp;
cell_copy.hec = this.hec;
for (i=0; i < 48; i++)
cell_copy.payload[i] = this.payload[i];
copy = cell_copy;
endfunction: copy
The ATM cell specific parts of the copy code are highlighted in red and the rest of the code remains the same for all data copy methods. These are carried out after a call to the base class copy_data method which takes care of all of base member copying. The copy method can create a duplicate of the main transaction. Often, you create a copy of the transaction and alter some fields for generating appropriate transactions.
Similar to the copy method, each data item typically should provide a compare method to allow comparison of data items. It compares the current value of the object instance with the current value of specified object instance and returns TRUE if identical and FALSE if different. If case the value is different then a descriptive text of first difference found is also returned in the specified string. The kind argument may be used to implement different comparison functions i.e., full compare, compare of random fields etc.
//compare method for the atm_cell class
function vmm_data compare (input vmm_data to,
output string diff,
input int kind = -1);
atm_cell cell;
if (to == null) begin
‘vmm_fatal(log, “Cannot compare a NULL reference”);
return 0;
end
else if (!$cast(cell, to) begin
‘vmm_fatal(log, “Not an ATM cell instance compare”);
return 0;
end
if (cell.vpi != this.vpi) begin
$sformat(diff, “vpi %0d != %0d”, this.vpi, cell.vpi);
return 0;
end
if (cell.vci != this.vci) begin
$sformat(diff, “vci %0d != %0d”, this.vci, cell.vci);
return 0;
end
if (cell.pt != this.pt) begin
$sformat(diff, “pt %0d != %0d”, this.pt, cell.pt);
return 0;
end
if (cell.clp != this.clp) begin
$sformat(diff, “clp %0d != %0d”, this.clp, cell.clp);
return 0;
end
if (cell.hec != this.hec) begin
$sformat(diff, “hec %0d != %0d”, this.hec, cell.hec);
return 0;
end
for (i=0; i < 48; i++) begin
if (cell.payload[i] != this.payload[i])
$sformat(
diff, “payload[%0d] %0d != %0d”, i, this.payload[i], cell.payload[i]);
return 0;
end
return 1;
endfunction: compare
Once you have added these properties and methods, a vmm_data class would look something as listed below. Once the data object is created and filled up appropriately to provide a sequence of ATM cells, how do we transfer that information to the DUT? Also, we will need to be able to collect data coming out of DUT into a vmm_data object for further analysis to help validation at higher-level. These bring in the concepts of transactors and channel. We will continue our discussions in upcoming blog articles on verification methodology keeping RTL engineers in mind.
class atm_cell extends vmm_data;
//create a log class for printing facilities
static vmm_log log = new (“ATM_CELL”,“ATM_CELL”);
rand bit [11:0] vpi;
rand bit [15:0] vci;
rand bit [2:0] pt;
rand bit clp;
rand bit [7:0] hec;
rand bit [7:0] payload[48];
//add a constraint to pt
constraint pt_constraint1 {pt > 3;}
//constructor method for the atm_cell class
function new();
super.new(log);
endfunction: new
//allocate() method for the atm_cell class
function vmm_data allocate(vmm_data to = null);
atm_cell transaction = new;
return transaction;
endfunction: allocate
//display method for the atm_cell class
//to print a prefix message followed by vpi and //vci fields
function string psdisplay (string prefix-msg);
$sformat (psdisplay, “ %s : [%d :%d]”,
prefix-msg, this.vpi, this.vci);
endfunction: psdisplay
//copy method for the atm_cell class
function vmm_data copy (vmm_data to = null);
atm_cell cell_copy;
if (to == null)
cell_copy = new();
else if (!$cast(cell_copy, to)) begin
‘vmm_fatal (this.log, “Not an ATM cell”);
cell_copy = null;
return;
end
super.copy_data(cell_copy);
cell_copy.vpi = this.vpi;
cell_copy.vci = this.vci;
cell_copy.pt = this.pt;
cell_copy.clp = this.clp;
cell_copy.hec = this.hec;
for (i=0; i < 48; i++)
cell_copy.payload[i] = this.payload[i];
copy = cell_copy;
endfunction: copy
//compare method for the atm_cell class
function vmm_data compare (input vmm_data to,
output string diff,
input int kind = -1);
atm_cell cell;
if (to == null) begin
‘vmm_fatal(log, “Cannot compare a NULL reference”);
return 0;
end
else if (!$cast(cell, to) begin
‘vmm_fatal(log, “Not an ATM cell instance compare”);
return 0;
end
if (cell.vpi != this.vpi) begin
$sformat(diff, “vpi %0d != %0d”, this.vpi, cell.vpi);
return 0;
end
if (cell.vci != this.vci) begin
$sformat(diff, “vci %0d != %0d”, this.vci, cell.vci);
return 0;
end
if (cell.pt != this.pt) begin
$sformat(diff, “pt %0d != %0d”, this.pt, cell.pt);
return 0;
end
if (cell.clp != this.clp) begin
$sformat(diff, “clp %0d != %0d”, this.clp, cell.clp);
return 0;
end
if (cell.hec != this.hec) begin
$sformat(diff, “hec %0d != %0d”, this.hec, cell.hec);
return 0;
end
for (i=0; i < 48; i++) begin
if (cell.payload[i] != this.payload[i])
$sformat(diff, “payload[%0d] %0d != %0d”, i, this.payload[i], cell.payload[i]);
return 0;
end
return 1;
endfunction: compare
endclass: atm_cell
We go back to the previous blog article that talks about efficient data generation using the VMM approach, and now talk about some of the methods associated with data item like the ATM cell.
One of the first methods that we need is called the constructor method for the ATM cell object; this is needed in object-oriented programming to be able to create a new instance of the object such as the ATM cell. Here, we just need to call its parent class’ constructor method called new() which is predefined for us. So defining the constructor methods is fairly mechanical and looks something like this:
//constructor method for the atm_cell class
function new();
super.new(log);
endfunction: new
There is an allocate() method for vmm_data to create a new instance of data transaction. It allocates a new instance of the same type as the object instance and returns a reference to the instance.
//allocate() method for the atm_cell class
function vmm_data allocate(vmm_data to = null);
atm_cell transaction = new;
return transaction;
endfunction: allocate
Typically, for any data item that we create, we will need a printing utility to able to display the relevant portions of the data item being generated. We can define a display method for printing information regarding the ATM cell being generated.
//display method for the atm_cell class
//to print a prefix message followed by vpi and vci fields
function string psdisplay (string prefix-msg);
$sformat (psdisplay, “ %s : [%d :%d]”,
prefix-msg, this.vpi, this.vci);
endfunction: psdisplay
Just like the constructor and allocate methods, the definition of the copy method is fairly mechanical and only has a section of code that is specific to the data item being defined. It copies the current value of the object instance into the specified object instance. If no object instance is specified then a new instance is allocated. The copy method for the ATM cell looks as follows:
//copy method for the atm_cell class
function vmm_data copy (vmm_data to = null);
atm_cell cell_copy;
if (to == null)
cell_copy = new();
else if (!$cast(cell_copy, to)) begin
‘vmm_fatal (this.log, “Not an ATM cell”);
cell_copy = null;
return;
end
super.copy_data(cell_copy);
cell_copy.vpi = this.vpi;
cell_copy.vci = this.vci;
cell_copy.pt = this.pt;
cell_copy.clp = this.clp;
cell_copy.hec = this.hec;
for (i=0; i < 48; i++)
cell_copy.payload[i] = this.payload[i];
copy = cell_copy;
endfunction: copy
The ATM cell specific parts of the copy code are highlighted in red and the rest of the code remains the same for all data copy methods. These are carried out after a call to the base class copy_data method which takes care of all of base member copying. The copy method can create a duplicate of the main transaction. Often, you create a copy of the transaction and alter some fields for generating appropriate transactions.
Similar to the copy method, each data item typically should provide a compare method to allow comparison of data items. It compares the current value of the object instance with the current value of specified object instance and returns TRUE if identical and FALSE if different. If case the value is different then a descriptive text of first difference found is also returned in the specified string. The kind argument may be used to implement different comparison functions i.e., full compare, compare of random fields etc.
//compare method for the atm_cell class
function vmm_data compare (input vmm_data to,
output string diff,
input int kind = -1);
atm_cell cell;
if (to == null) begin
‘vmm_fatal(log, “Cannot compare a NULL reference”);
return 0;
end
else if (!$cast(cell, to) begin
‘vmm_fatal(log, “Not an ATM cell instance compare”);
return 0;
end
if (cell.vpi != this.vpi) begin
$sformat(diff, “vpi %0d != %0d”, this.vpi, cell.vpi);
return 0;
end
if (cell.vci != this.vci) begin
$sformat(diff, “vci %0d != %0d”, this.vci, cell.vci);
return 0;
end
if (cell.pt != this.pt) begin
$sformat(diff, “pt %0d != %0d”, this.pt, cell.pt);
return 0;
end
if (cell.clp != this.clp) begin
$sformat(diff, “clp %0d != %0d”, this.clp, cell.clp);
return 0;
end
if (cell.hec != this.hec) begin
$sformat(diff, “hec %0d != %0d”, this.hec, cell.hec);
return 0;
end
for (i=0; i < 48; i++) begin
if (cell.payload[i] != this.payload[i])
$sformat(
diff, “payload[%0d] %0d != %0d”, i, this.payload[i], cell.payload[i]);
return 0;
end
return 1;
endfunction: compare
Once you have added these properties and methods, a vmm_data class would look something as listed below. Once the data object is created and filled up appropriately to provide a sequence of ATM cells, how do we transfer that information to the DUT? Also, we will need to be able to collect data coming out of DUT into a vmm_data object for further analysis to help validation at higher-level. These bring in the concepts of transactors and channel. We will continue our discussions in upcoming blog articles on verification methodology keeping RTL engineers in mind.
class atm_cell extends vmm_data;
//create a log class for printing facilities
static vmm_log log = new (“ATM_CELL”,“ATM_CELL”);
rand bit [11:0] vpi;
rand bit [15:0] vci;
rand bit [2:0] pt;
rand bit clp;
rand bit [7:0] hec;
rand bit [7:0] payload[48];
//add a constraint to pt
constraint pt_constraint1 {pt > 3;}
//constructor method for the atm_cell class
function new();
super.new(log);
endfunction: new
//allocate() method for the atm_cell class
function vmm_data allocate(vmm_data to = null);
atm_cell transaction = new;
return transaction;
endfunction: allocate
//display method for the atm_cell class
//to print a prefix message followed by vpi and //vci fields
function string psdisplay (string prefix-msg);
$sformat (psdisplay, “ %s : [%d :%d]”,
prefix-msg, this.vpi, this.vci);
endfunction: psdisplay
//copy method for the atm_cell class
function vmm_data copy (vmm_data to = null);
atm_cell cell_copy;
if (to == null)
cell_copy = new();
else if (!$cast(cell_copy, to)) begin
‘vmm_fatal (this.log, “Not an ATM cell”);
cell_copy = null;
return;
end
super.copy_data(cell_copy);
cell_copy.vpi = this.vpi;
cell_copy.vci = this.vci;
cell_copy.pt = this.pt;
cell_copy.clp = this.clp;
cell_copy.hec = this.hec;
for (i=0; i < 48; i++)
cell_copy.payload[i] = this.payload[i];
copy = cell_copy;
endfunction: copy
//compare method for the atm_cell class
function vmm_data compare (input vmm_data to,
output string diff,
input int kind = -1);
atm_cell cell;
if (to == null) begin
‘vmm_fatal(log, “Cannot compare a NULL reference”);
return 0;
end
else if (!$cast(cell, to) begin
‘vmm_fatal(log, “Not an ATM cell instance compare”);
return 0;
end
if (cell.vpi != this.vpi) begin
$sformat(diff, “vpi %0d != %0d”, this.vpi, cell.vpi);
return 0;
end
if (cell.vci != this.vci) begin
$sformat(diff, “vci %0d != %0d”, this.vci, cell.vci);
return 0;
end
if (cell.pt != this.pt) begin
$sformat(diff, “pt %0d != %0d”, this.pt, cell.pt);
return 0;
end
if (cell.clp != this.clp) begin
$sformat(diff, “clp %0d != %0d”, this.clp, cell.clp);
return 0;
end
if (cell.hec != this.hec) begin
$sformat(diff, “hec %0d != %0d”, this.hec, cell.hec);
return 0;
end
for (i=0; i < 48; i++) begin
if (cell.payload[i] != this.payload[i])
$sformat(diff, “payload[%0d] %0d != %0d”, i, this.payload[i], cell.payload[i]);
return 0;
end
return 1;
endfunction: compare
endclass: atm_cell
Subscribe to:
Posts (Atom)
