Transferring e "when" Subtypes to UVM SV via TLM Ports—UVM-ML OA Package

The UVM-ML OA (Universal Verification Methodology - Multi-Language - Open Architecture) package features the ability to transfer objects from one verification framework to another via multi-language TLM ports. Check out Appendix A if you are a first-time user of UVM-ML OA.

This feature makes many things possible, such as:  

• Sequence layering where one framework generates the sequence item and the other drives it to the DUT bus
• Sequence layering where one framework invokes sequences in the other so that both item generation and DUT bus driving is done from a single framework
• Monitoring the DUT using a different framework and still obtaining a scoreboard in a single framework
• And more...

An issue arises when the object that we want to send via the TLM port is an e "when" subtype, since other frameworks do not have such type determinants. This will probably cause a type mismatch between the two frameworks that will probably be expressed by unpacking less/more bits than packed.

The recommended solution is to use the Incisive mltypemap utility, which automatically maps the specified data type to its equivalent representation in the target framework.

However, mltypemap currently does not support e "when" subtypes in terms of creating a different individual type in the target framework for each "when" subtype. Instead it creates one type that contains all of the fields from all "when" subtypes, including their determinants.

Therefore, after using mltypemap, you should use the determinants to determine which "when" subtype was received by the TLM port and extract only the relevant portion of the received object.

Example:

1.Suppose we want to send an e struct called "packet" from e to SV via a TLM put port. "packet" has two "when" subtypes: SINGLE and DOUBLE. The "when" subtype determines how many data fields this packet has (in this case, one or two). Note that there is no need to mark the fields as "physical". Mltypemap will automatically define them as physical unless told otherwise.

 The packet definition is as follows: (file name: packet.e)

Since the packet is sent to SV, an equivalent representation in SV must be defined for it. Therefore a mltypemap TCL input file needs to be created, that will:

1. Configure the generated code to be UVM ML OA compatible
2. Provide the source type
3. Provide the target type name
4. Provide the target framework 
5. Optional - you can decide which fields will not be mapped by using config_type  ... -skip_field

This is how the TCL file maptype_to_sv.tcl should look:

 This TCL input file should be used with the mltypemap utility together with the e source file:

3. Three files were generated as a result of this command: packet_ser.e, packet.svh, and packet_set.sv. Be sure to include these three files in the source file list. The packet_ser files determine which fields to serialize/deserialize (you may have chosen to omit some fields from being serialized  by using the TCL config_type command with the -skip_field option). packet.svh includes the new type's definition in SV : (file name : package.svh)

 

 Note that the "when" subtypes are incorporated into the field's names. For example, the field "data_1" in the e "when" subtype DOUBLE't packet is represented here as ‘DOUBLE__t__data_1'. We will use this information when we fetch the data from the TLM implementation of our TLM put imp.

4.      Now suppose we want to send different "when" subtypes of the same type through one TLM port, we would have to define the TLM port in both frameworks.

Output port put_port in the e side (File name:  producer.e ): 

 And in SV, we define the input port, put imp (file name: consumer.sv):

 The TLM put imp must be registered with the backplane, and must also be connected to the e TLM put port. Suppose our hierarchy in SV is uvm_test_top.sv_env.cons.put_imp , and in e it is sys.env.prod.put_port. Then the registration and connection will be as follows (done in uvm_test_top, file name: test.sv):

 

5. In SV, the can_put and try_put functions and put task of the TLM put imp port will need to be defined in order to determine whether we have a SINGLE't packet or a DOUBLE't packet (file name : consumer.sv): 

 The above example shows how to send a struct that represents a data item, but the proposed solution could also be applied to other functionally directed struct types, like sequences.

Suppose we would like to send some sequences from a sequence library in e to be started in SV. All we need to do is map the e sequence library to SV using the mltypemap utility, and then in the SV code, determine which sequence was received from e, extract its relevant fields, and start the equivalent SV sequence with the fields that were extracted from the received sequence struct.

This solution enables users to use TLM ports to send e "when" subtypes to the target framework. The ability to use TLM ports has many advantages over previous solutions, such as  independence frpm a stub file, and the ability to connect the same port to different languages by only changing the UVM path. 

 

Appendix A: Applying the UVM_ML_OA Features If Previously Unused in Your Multi-Language Environment

If you did not previously use the UVM_ML_OA features in your multi-language environment, apply them to the environment as follows:

1. Download and untar the UVM ML OA package from uvm world from here . You will need to register if you are not already registered.
2. Set the environment variables and source the setup.csh script (as explained in README_INSTALLATION.txt) which is located in the ml/ folder in the untarred folder.
3. In the file that contains your top module (the module that instantiates the DUT and that includes your UVM sv VC and the uvm_pkg packages ), do the following:

a.  Import the uvm_ml package: 

 

 b.  In an initial block, create a string array, where each string points to the top-level entity of each framework in your environment. (In the example below, it is is only the e test file.)

 c.  Replace the run_test() statement with uvm_ml_run_test(). Provide uvm_ml_run_test() with the string array from the previous step and with the SV test name. (In the example below, the SV test is also the top entity in the UVM SV framework.)

 

For more information on UVM ML OA constructs, syntax, and other features, go to the UVM ML OA documentation in <uvm_ml_install_dir>/ml/README.html.