class apb_env extends uvm_env;

2 apb_config cfg; // configuration class for this environment 3 apb_master_agent master; // APB master (Bridge)

4 apb_slave_agent slaves[]; // APB can have multiple slave agents 5 apb_bus_monitor bus_monitor; // Shared bus monitor

6 ‘uvm_component_utils_begin(apb_env) 7 ‘uvm_field_object(cfg, UVM_DEFAULT) 8 ‘uvm_component_utils_end

9 function new(string name, uvm_component parent);

10 super.new(name, parent);

11 endfunction : new

12 // Additional class methods

13 extern virtual function void build();

14 extern virtual function void assign_vi (virtual apb_if vif);

15 endclass : apb_env

16 function void apb_env::build 17 uvm_object config_obj;

18 super.build();

19 if (cfg == null)begin

20 ‘uvm_info(get_type_name(),"Using default_apb_config", UVM_MEDIUM) 21 $cast(cfg,factory.create_object_by_name("default_apb_config","cfg"));

22 end

23 if (cfg.has_bus_monitor) begin

24 bus_monitor = apb_bus_monitor::type_id::create("bus_monitor", this);

25 bus_monitor.cfg = cfg;

26 end

27 master = ahb_master_agent::type_id::create("master",this);

28 master.cfg = cfg;

29 // Build slaves

30 slaves = new[cfg.slave_configs.size()];

31 // Create multiple slaves and give each a unique name 32 foreach slaves[i] begin

33 slaves[i] = ahb_slave_agent::type_id::create(

34 $psprintf("slaves[%0d]",i) ,this);

35 slaves[i].cfg = cfg.slave_configs[i];

36 endfunction : build

37 function void apb_env::assign_vi(virtual apb_if vif);

38 // Based on the configuration, assign master, slave and bus monitor 39 // signals.

40 endfunction : assign_vi

Note Similarly to the agent, create is used to allocate the environment components. This allows introducing derivations of the sub-components later. For the APB protocol, there is a single master and a variable number of slaves.

The user is not required to call build() explicitly. The SystemVerilog UVM Class Library will do this for all created components. When all of the components’ build() functions are complete, the UVM will call each component’s connect() function. Any connections between child components should be made in the connect() function of the parent component. This ensures that all components have been created before they are connected.

5.8.2 Point-to-Point Environments

In point-to-point protocols, such as transmit-receive communication protocols or buses that define a single master and slave interaction, we need a reusable environment class. Beyond consistency (an integrator always uses environments and their standard attributes), the agents in such environment may share a single monitor.

Block diagrams of point-to-point environments are illustrated in Figure 5-8, Point-to-Point UVC Configured to Verify a Master or a Slave Device. A point-to-point UVC needs to support verifying both master and slave agents for check and coverage. This is achieved by using the agent is_active attribute. To verify a slave, you instantiate the environment with an active master agent and a passive slave agent to check and collect coverage on the agent. To verify a master, the slave will be active and the master will be passive. If you want to collect coverage or check an internal bus, both the master and slave should be set to passive mode.

Figure 5-8 Point-to-Point UVC Configured to Verify a Master or a Slave Device

Note In the development process, users may want to create both the agents and co-develop them against each other. The interesting part in a point-to-point environment is the monitor. This is highly protocol-dependent, but if the same signals are being used for both master and slave, then one collector and monitor are enough. This means that the bus monitor is both the slave and master monitor. For consistency, and keeping the same use model, we recommend adding a pointer from both the master and slave to this joint monitor. Figure 5-9, Interface UVC with Shared Monitor and Collector depicts this configuration.

Figure 5-9 Interface UVC with Shared Monitor and Collector

Figure 5-9 Interface UVC with Shared Monitor and Collector

5.8.3 The UVM Configuration Mechanism

A UVC is developed on a per-protocol basis for general purpose, protocol-related use. It may support various features or operation modes that are not required for a particular project. The UVM provides a standard configuration mechanism which allows you to define the UVC’s configuration to suit the current project’s requirements. The UVC can get this configuration information during the build phase or run phase, and within the constructor. The UVM configuration mechanism is tailored to enable reuse, but additional guidelines should be followed to achieve reusability.

5.8.3.1 Making the UVC Reusable

There are times when the developer knows the context in which the developing UVC will be used. In such cases, developers should take care to separate the requirements of the UVC’s protocol from those of the project and avoid hard-coding configuration parameters with project specific values. We strongly recommend using only the interface-protocol documentation in developing the UVC. Later, developers can consult their project’s documentation to see if there are some generic features which might be useful to implement. For example, they should be able to configure slave devices to reside at various locations within an address space, instead of hard-coding the address to a specific location used in the project.

As another example, if within a protocol frame a few bits are defined as reserved, they should stay reserved within the UVC. The verification logic that understands how a specific implementation uses these bits should be kept outside the global generic code.

As a developer, it is critical to identify these generic parameters and document them for the environment users.

5.8.3.2 Configuration Requirements

There are many verification component configuration requirements. The configuration mechanism is used by the testbench integrator and the test writer who wishes to modify the default configuration for a specific test case. The verification component should check the validity of the configuration, to make sure proper settings are applied before simulation run time. A user should be able to randomize the configuration and collect coverage on the randomized values. It should also be possible to use configuration of a subsystem in a larger system, set the system default configuration and leave it up to the user to further control the configuration. Configuration should be extensible, as some users may want to add a new project-specific configuration attribute or constraints. While project specifics and modification are always possible, the following sections describe the recommend configuration flow.

5.8.3.3 UVC Configuration Object

The UVM allows users to specify configuration objects for components either as separate fields or as a group contained within a configuration object. Using the configuration attribute for scalar settings is simpler than allocating a configuration class. However, for most real-world applications, users find a configuration object to be more practical. The number of attributes in real-world UVCs quickly grows beyond the one or two planned attributes. Creating a configuration object allows for a place to capture dependencies between individual attributes in constraints. Users can easily print the attributes, pass them by value or by reference to a different object (even in a different language), wrap existing sub-environments configuration within a larger class, and much more.

Both agents and environments should have their own configuration class. For example, agents have a configuration class that holds the standard and protocol-specific attributes. The environment class will have a configuration class that contains the agent config classes (may be an array in the case of a multi-drop BUS). Testbench configuration classes should wrap the multiple environment configuration classes. Each layer can impose constraints on its field configuration classes or between siblings. An example of an interface environment configuration class is illustrated below.

Example 5–12 APB Configuration Classes (slave, master and env config)

Example 5–12 APB Configuration Classes (slave, master and env config)