Some of the observations about the Complex Verification Environments
1. Verification Environment will generally have a number of agents (or UVCs).
2. Testbench will have different modes and configurations at the top level
3. Agents will have different configurations and randomizations to play with.
Its indeed a laborious task of keeping track of these configurations if not planned and organized properly. There is a need to structure the configurations in an intuitive way so that it not only helps the Verification Team collaborate better but also easy to sustain the Verification Environment.
Following is suggested by UVM user guide:-
1. Each agent should have all the agent level configurations captured in a configuration object (uvm_object)
2. Environment will have a config object for the environment level or chip level.
Picture Courtesy- Accellera
That sounds pretty straight-forward to understand and implement. However the main aim of the providing configuration objects is to allow the test (or testcase writer) to control/configure the fields in the configuration objects to achieve the test goal or to create various scenarios of interest. This requires some scheme to organize the config objects.
What is the scheme for handling various config objects in the environment?
As we know, Agents' config objects are generally in compliation scope of that particular agent as follows:-
Fig2. abc_pkg
In order to keep the configuration objects organized in a structured way, and still allow the test writer to intuitively use the config objects, following scheme is devised. The scheme is illustrated using the following piece of code.
Fig3. Illustration of scheme for handling config objects in UVM testbench
Also, the env_config is instantiated in the test, test writer can access the env_config and agent level configs hierarchically to control the configurations of testbench.
What are the Advantages?
1. Verification Environment will generally have a number of agents (or UVCs).
2. Testbench will have different modes and configurations at the top level
3. Agents will have different configurations and randomizations to play with.
Its indeed a laborious task of keeping track of these configurations if not planned and organized properly. There is a need to structure the configurations in an intuitive way so that it not only helps the Verification Team collaborate better but also easy to sustain the Verification Environment.
Following is suggested by UVM user guide:-
1. Each agent should have all the agent level configurations captured in a configuration object (uvm_object)
2. Environment will have a config object for the environment level or chip level.
That sounds pretty straight-forward to understand and implement. However the main aim of the providing configuration objects is to allow the test (or testcase writer) to control/configure the fields in the configuration objects to achieve the test goal or to create various scenarios of interest. This requires some scheme to organize the config objects.
What is the scheme for handling various config objects in the environment?
As we know, Agents' config objects are generally in compliation scope of that particular agent as follows:-
Fig2. abc_pkg
In order to keep the configuration objects organized in a structured way, and still allow the test writer to intuitively use the config objects, following scheme is devised. The scheme is illustrated using the following piece of code.
Also, the env_config is instantiated in the test, test writer can access the env_config and agent level configs hierarchically to control the configurations of testbench.
What are the Advantages?
- Easy and intuitive way of accessing configurations information not only for Test writers but also design engineers/managers to review the configurations. Review of configuration capabilities of the testbench is very important because this drives the verification and its goals
- Environment config contains only the pointers to the agent level configs and actual config object of a given agent resides within the compilation scope of that agent. Thus, Agent are kept pretty independent and they don't access environment level config object and hence agent can be reused across different environment with almost no change required.
- Tests access the agent level config through environment level config object and hence all the configurations done in the testcase are streamlined and this makes the testcases easy to understand.
