Uvm ML Ref

Incisive® Verification Kits
UVM Multi-Language Reference

Product Version 12.1
June 2012
© 2009-2012 Cadence Design Systems, Inc. All rights reserved worldwide.
Printed in the United States of America.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or registered trademarks of
Open SystemC Initiative, Inc. in the United States and other countries and are used with permission.
Product Incisive® Plan-to-Closure Methodology contains technology licensed from, and copyrighted by: Open SystemC
Initiative, Inc. and is © 1996-2006 by all contributors, all rights reserved; (c) 2007-2008 Cadence Design Systems, Inc., and
(c) 2007-2008 Mentor Graphics, Inc., all rights reserved. Associated Apache license terms may be found at
$SOCV_KIT_HOME/.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document are attributed to
Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks, contact the corporate legal department at
the address shown above or call 800.862.4522. All other trademarks are the property of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and contains trade secrets and
proprietary information owned by Cadence. Unauthorized reproduction or distribution of this publication, or any portion of it,
may result in civil and criminal penalties. Except as specified in this permission statement, this publication may not be copied,
reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission
from Cadence. Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to print
one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its customer;
2. The publication may not be modified in any way;
3. Any authorized copy of the publication or portion thereof must include all original copyright, trademark, and other
proprietary notices and this permission statement;
4. The information contained in this document cannot be used in the development of like products or software, whether
for internal or external use, and shall not be used for the benefit of any other party, whether or not for consideration
Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the
part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any
representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document.
Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any
liability for damages or costs of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14
and DFAR252.227-7013 et seq. or its successor.
Terms of Use: Permission to internally use, modify, or distribute these source code files is hereby granted, provided that the
following conditions are met:
Customers may only modify or use this material for internal purposes related to integrated circuit design within Cadence's
design and verification environment. Customer shall not (1) copy this material except to the extent necessary to fulfill the
purpose stated above; (2) distribute this material to any third party without express written permission from Cadence; (3) allow
this material to be accessed or used by third parties or anyone other than customer's employees whose duties require such access
or use; or (4) distribute these materials for profit or commercial advantage.
Subject to compliance with the terms and conditions herein and the agreement under which this material is provided (the
“Agreement”), Cadence agrees to provide, or have provided, Maintenance Service as defined in the Agreement for the Term of
Use specified in the Agreement.
THIS SOFTWARE IS PROVIDED “AS IS” COMPLETELY WITHOUT ANY WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS ARE DISCLAIMED.
IN NO EVENT SHALL CADENCE BE LIABLE FOR ANY CLAIMS OR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES, LOSS OF USE, DATA, PROFITS, OR BUSINESS INTERRUPTION)
HOWEVER CAUSED, OR ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Contents
1 About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

1.1 Conventions in This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
2 Multi-Language UVM (ML-UVM) Features for e and SystemVerilog .

2-1
2.1 Requirements for Multi-Language Verification Environments . . . . . . . . . . . . . . . . . . . 2-1
2.2 Multi-Language UVM (ML-UVM) Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.2.1 Enabling the ML-UVM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.3 Multi-Language Trees of UVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.3.1 Specifying Top Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.3.1.1 -uvmtest Switch for irun (and ncsim) . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.3.1.2 -uvmtop Switch for irun (and ncsim) . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.3.1.3 Top Entities Build Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.3.2 Example: Specifying Top Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.4 Synchronized Elaboration Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.4.1 Elaboration Phases in the Various Languages . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.4.2 Synchronized Elaboration Phases with ML-UVM . . . . . . . . . . . . . . . . . . . . . . 2-8
2.4.3 Starting Point for Quasi-Static Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
2.4.4 Using the UVM-SV Configuration Database . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
2.4.5 Required Changes to User Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
2.4.6 Example: Synchronized Elaboration Phases . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
2.4.6.1 Trivial SystemVerilog Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.4.6.2 Trivial e Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.4.6.3 Trivial e Test File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.4.6.4 Using the e Test as the First Top Entity . . . . . . . . . . . . . . . . . . . . . . 2-15
2.4.6.5 Using the SystemVerilog Component as the First Top Entity . . . . . 2-16
2.4.6.6 Using Multi-Step Mode Simulation instead of irun . . . . . . . . . . . . . 2-17
2.5 Data Communication Using TLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
UVM Multi-Language Reference iii

Contents
2.5.1 Advantages of Using TLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18

2.5.2 Requirements for Using TLM in Multi-Language Verification Environments . . .
2-19
2.5.3 Connecting TLM Ports Across Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.5.3.1 Summary of ML-UVM Features for TLM . . . . . . . . . . . . . . . . . . . 2-20
2.5.3.2 Connecting TLM Ports Between e and SystemVerilog . . . . . . . . . . 2-21
2.5.3.3 ML-UVM External Path Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
2.5.4 Passing Transactions Across Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
2.5.4.1 Type Mapping between e, SystemVerilog, and SystemC . . . . . . . . 2-23
2.5.5 Example: e to SystemVerilog TLM Port Connection . . . . . . . . . . . . . . . . . . 2-24
2.5.6 Example: Passing a Compound Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.5.7 Matching TLM Ports in ML-UVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
2.6 Limitations in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
3 Using SystemVerilog Sequences in an e Testbench . . . . . . . . . . .3-1

3.1 About Running Sequences in Multi-Language Environments . . . . . . . . . . . . . . . . . . . . 3-1
3.2 Mixed-Language Sequences API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.2.1 ml_proxy_seq_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.2.1.1 update_item_after_done() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3.2.2 ml_uvm_sequencer_stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.2.2.1 Accessing the ml_uvm_seq Package . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.2.2.2 assign_sequencer() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.2.2.3 prepare_item_to_send() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
4 Multi-Language UVM (ML-UVM) Reference . . . . . . . . . . . . . . . . . . .4-1

4.1 ML-UVM irun Command Line Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.1 -uvmtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.2 -uvmtop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.1.3 -ml_uvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
4.2 ML-UVM e Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
4.2.1 ml_uvm.connect_names() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
4.3 ML-UVM SystemVerilog Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
4.3.1 ml_uvm::connect() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
4.3.2 ml_uvm::connect_names() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
4.3.3 ml_uvm::external_if() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
UVM Multi-Language Reference iv

Contents
5 UVM Interface Generator (UIG) Reference . . . . . . . . . . . . . . . . . . . .5-1

5.1 Overview of UIG Task Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.2 UIG Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
5.2.1 run_uig.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
5.3 e Export File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
5.3.1 e Export File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
5.3.2 #include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
5.3.3 Top-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
5.3.4 UVM Component Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
5.3.5 Sequence Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
5.3.6 in|inout|out Field Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
5.3.7 Item Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
5.3.8 Method Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
5.3.8.1 to_e_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
5.3.8.2 from_e_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
5.3.9 Event Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
5.3.9.1 to_e_event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
5.3.9.2 from_e_event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
5.3.10 Subcomponent Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43
5.3.11 DUT Interface Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
5.3.12 Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49
5.3.13 Field Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-52
5.3.14 Interface Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
5.3.15 Signal Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-60
5.3.16 Clocking Block Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-63
5.3.17 Clocking Signal Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66
5.4 Importing an e Export File for UVCs with Multiple Packages . . . . . . . . . . . . . . . . . . 5-67
5.4.1 Creating an SV UVC Proxy Based on an Existing Proxy . . . . . . . . . . . . . . . 5-68
5.4.2 Reusing Data Types and Components from an Existing SV UVC Proxy . . . 5-68
5.4.2.1 Reusing Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68
5.4.2.2 Reusing Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69
5.4.3 Extending the Hierarchy of Class Data Types . . . . . . . . . . . . . . . . . . . . . . . . 5-70
5.4.4 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71
5.5 Dynamic e Configuration API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71
5.5.1 Using the UIG Dynamic Config API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72
5.5.2 Using Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-73
5.5.3 Using Defines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-74
5.5.4 uig_get_num_instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-75
UVM Multi-Language Reference v

Contents
5.5.5 uig_get_uvm_path_by_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-76

5.5.6 uig_get_field_value_<type> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77
5.5.7 uig_get_dut_interface_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-78
5.5.8 uig_get_dut_interface_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-78
5.5.9 uig_get_array_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79
6 mltypemap Utility: Automatic Generation of Data Types . . . . . . . .6-1

6.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1.1 Mapping from e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.1.1.1 Mapping from e to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
6.1.1.2 Mapping from e to SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
6.1.2 Mapping from SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
6.1.2.1 Mapping from SystemVerilog to e . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
6.1.2.2 Mapping from SystemVerilog to SystemC . . . . . . . . . . . . . . . . . . . . 6-6
6.1.3 Mapping from SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
6.1.3.1 Mapping SystemC to e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
6.1.3.2 Mapping SystemC to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.2 Invoking mltypemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.2.1 Irun Arguments for Invoking mltypemap . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.3 Mapping Types with mltypemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
6.3.1 maptypes Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
6.3.2 Output Files Generated by maptypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
6.3.2.1 Output Files Generated for SystemVerilog . . . . . . . . . . . . . . . . . . . 6-13
6.3.2.2 Output Files Generated for e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.3.2.3 Output Files Generated for SystemC . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.3.3 Mapped Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.3.4 Mapping Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.3.4.1 Mapping a Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
6.3.4.2 UVM Field Properties (pack, print, and so on) . . . . . . . . . . . . . . . . 6-15
6.3.5 Mapping e when Subtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
6.3.6 Referencing when Subtypes in Configuration Commands . . . . . . . . . . . . . . 6-16
6.3.7 Mapping Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
6.3.8 Mapping Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
6.3.8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
6.3.9 Mapping Typedefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
6.3.9.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
6.4 Configuring mltypemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
6.4.1 configure_scope Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
6.4.2 configure_type Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
UVM Multi-Language Reference vi

Contents
6.4.3 configure_field Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23

6.4.4 configure_enum_item Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
6.4.5 print_type Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
6.4.6 configure_code Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
6.5 mltypemap Limitations for this Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
7 Multi-Language TLM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

7.1 Multi-Language TLM 2.0 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.1.1 Multi-Language Socket Binding in SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.1.1.1 Registration of Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.1.1.2 Inter-Language Connection of Sockets . . . . . . . . . . . . . . . . . . . . . . . 7-4
7.1.2 Transaction Type Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
7.1.3 Generic Payload Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
7.1.4 Generic Payload Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
7.1.5 Interface Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
7.2 TLM 2.0 Interface User View for e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
7.2.1 Introduction—TLM 2.0 Interface Example . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
7.2.2 Data Types Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
7.2.2.1 Generic Payload Extensions in e . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
7.2.2.2 Generic Payload Extensions in SystemC . . . . . . . . . . . . . . . . . . . . . 7-14
7.2.3 Master Driver (BFM) Using the Initiator Socket . . . . . . . . . . . . . . . . . . . . . . 7-15
7.2.4 Slave Driver (BFM) Using the Target Socket . . . . . . . . . . . . . . . . . . . . . . . . 7-17
7.2.5 Driving the Simulation with Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
7.2.5.1 Simple Write Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
7.2.5.2 Non-Blocking Read Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
7.2.5.3 Memory Management Considerations . . . . . . . . . . . . . . . . . . . . . . . 7-21
7.2.6 Comparison of TLM2 with Previous Manual Solution . . . . . . . . . . . . . . . . . 7-21
7.2.7 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
7.2.7.1 ML-TLM1 Interface does not Support tlm_generic_payload . . . . . 7-22
7.2.7.2 Classes and Struct in Extensions Must Derive from uvm_object . . 7-22
7.2.7.3 Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
7.2.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
7.2.8.1 Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
7.2.8.2 The Memory Slave Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
7.2.8.3 The Initiator Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
7.2.8.4 Using types derived from tlm_generic_payload . . . . . . . . . . . . . . . 7-26
7.2.8.5 Using Arrays in Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26
7.2.8.6 Using Nested Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
7.2.8.7 Defining an AMBA_PV sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28
7.2.8.8 Different Use Cases of Slave Driver . . . . . . . . . . . . . . . . . . . . . . . . 7-29
UVM Multi-Language Reference vii

Contents
8 SystemC in Mixed-Language UVM . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

8.1 Creating Quasi-Static Top Modules with the Simulator Command . . . . . . . . . . . . . . . . 8-2
8.2 Creating Quasi-Static Top Modules Programmatically . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.3 Quasi-Static Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
8.4 Loading a SystemC Library into ncsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
8.5 Mixed-Language Connection of Quasi-Static SystemC Ports and Exports . . . . . . . . . . 8-6
8.6 Registering SystemC Ports and Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
8.7 Mixed-Language UVM Connection Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
8.8 SystemVerilog Mixed-Language UVM Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
8.9 Using irun on Mixed-Language SystemVerilog-SystemC UVM Designs . . . . . . . . . . 8-12
8.10 Compatibility with SystemVerilog UVM Use Model . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
8.11 Connection of Static SystemC Ports and Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
8.12 Passing Transaction Data by Value across SystemC Language Boundary . . . . . . . . . 8-18
8.12.1 Passing Legacy SystemC Types Across the Boundary . . . . . . . . . . . . . . . . . 8-18
8.12.2 The uvm_object Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
8.12.3 Pack and Unpack Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
8.13 SystemC Quasi-Static Phase Alignment with SystemVerilog UVM . . . . . . . . . . . . . . 8-23
8.14 Disabling a Root SystemVerilog Process Blocked in Mixed-Language UVM Call Chain .
8-24
8.15 Simulator Tcl Command Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
8.16 SimVision Support for Quasi-Static SystemC Hierarchies . . . . . . . . . . . . . . . . . . . . . 8-25
8.17 Effect of ncelab Options on Quasi-Static Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
8.18 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
UVM Multi-Language Reference viii

1 About This Book
This manual describes the commands for the Universal Verification Methodology (UVM)
Multi-Language implementation.
To find out … Read …
The utilities for building multi-language verification Chapter 2 “Multi-Language UVM (ML-UVM)
environments, where some Universal Verification Features for e and SystemVerilog”
Components (UVCs) are implemented in e and others
in SystemVerilog
About the API that lets you send sequences from a Chapter 3 “Using SystemVerilog Sequences
top-level e test to be run by a SystemVerilog in an e Testbench”
component
irun invocation commands and utilities for Chapter 4 “Multi-Language UVM (ML-UVM)
Multi-Langue UVM Reference”
How to build a UVM-compliant interface for a UVC Chapter 5 “UVM Interface Generator (UIG)
Reference”
How to generate data types between different Chapter 6 “mltypemap Utility: Automatic
languages Generation of Data Types”
About the interface between e and SystemC using Chapter 7 “Multi-Language TLM 2.0”
TLM 2.0
How SystemC® can participate in UVM-based Chapter 8 “SystemC in Mixed-Language

(Universal Verification Methodology) verification UVM”
libraries as a design top, in parallel with
SystemVerilog and e language top modules
UVM Multi-Language Reference 1-1

About This Book
Conventions in This Book
1.1 Conventions in This Book

This manual uses variations in typefaces to help you locate and interpret information easily. These type
variations are explained in Table 1-1.
Table 1-1 Document Conventions
Typeface Represents
courier font Indicates code. For example:
do burst_response keeping {
courier bold Used to highlight important sections of code, like actions. For example:
do burst_response keeping {
Also used to identify user input. The following example indicates that the
user enters the command “demo.sh -h”, in response to which the system
displays the command options for demo.sh:
% demo.sh –h
Usage: demo.sh -h[elp] [-test_case <test_name>]
[-seed <seed number>]
[-run_mode batch]
bold The bold font indicates keywords in descriptive text. For example, the
following sentence contains keywords for the show ini command and the
get_symbol() routine:
You can display these settings with the show ini setting command or
retrieve them within e code with the get_symbol() routine.
italic The italic font represents user-defined variables that you must provide.
For example, the following line defining the syntax for the command
option “-seed” instructs you to type “-seed” as it appears, and then the
actual seed number:
-seed seed_number
[ ] square brackets Square brackets indicate optional parameters. For example, in the
following construct the keywords “list of” are optional:
var name: [list of] type
[ ] bold brackets Bold square brackets are required. For example, in the following construct
you must type the bold square brackets as they appear:
extend enum-type-name: [name,…]

About This Book
Conventions in This Book
Table 1-1 Document Conventions (continued)
Typeface Represents
construct, … An item, followed by a separator (usually a comma or a semicolon) and an

ellipsis is an abbreviation for a list of elements of the specified type. For
example, the following line means you can type a list of zero or more
names separated by commas.
extend enum-type-name: [name,…]
| The pipe character indicates alternative syntax or parameters. For

example, the following line indicates that either the bits or bytes keyword
should be used:
type scalar-type (bits | bytes: num)
cmd-prompt> Denotes the prompt for the Cadence tool you are running, for example,
Incisive® Design Team Simulator or Incisive® Enterprise Specman
Simulator.
> Denotes a third-party VHDL simulator prompt.
% Denotes the UNIX prompt.

2 Multi-Language UVM (ML-UVM)
Features for e and
SystemVerilog
This chapter describes new utilities for building multi-language verification environments, where some
UVM-based Verification Components (UVCs) are implemented in e and others in SystemVerilog. The
focus of the guidelines here is to support a true multi-language approach, where the user is aware of the
different implementation languages of the various UVCs and combines the UVCs using dedicated
multi-language features in the Incisive Enterprise Simulator - XL (IES-XL).
This chapter contains:
● “Requirements for Multi-Language Verification Environments” on page 2-1

● “Multi-Language UVM (ML-UVM) Features for e and SystemVerilog” on page 2-1
● “Multi-Language Trees of UVCs” on page 2-3
● “Synchronized Elaboration Phases” on page 2-7
● “Data Communication Using TLM” on page 2-18
● “Limitations in This Release” on page 2-30
● “Limitations in This Release” on page 2-30
2.1 Requirements for Multi-Language Verification

Environments
Mixing e and SystemVerilog UVCs in a multi-language verification environment introduces several key
requirements:
● Instantiation and configuration

Multi-Language UVM (ML-UVM) Features for e and SystemVerilog
Multi-Language UVM (ML-UVM) Features
Each UVC must be instantiated and configured appropriately according to its part within the overall
verification environment. The UVCs together form a logical multi-language hierarchy, which in
turn must be mapped to several disjoint trees of UVCs, each tree being in its own language domain.
● Synchronized elaboration
Each of the supported verification languages defines its own elaboration phases. These phases must
be synchronized to let the various parts of the verification environment be constructed and
connected in a coordinated fashion. For example, binding communication ports between e and
SystemVerilog UVCs can only occur once the SystemVerilog hierarchy has been created, which
happens only after simulation begins.
● Passing of data across language boundaries
The UVCs comprising the verification environment must be able to exchange information, usually
in the form of transactions. Transaction Level Modeling (TLM) interfaces provide a standard and
common approach for such communication schemes. However, when the UVCs are implemented in
different languages, it must be possible to connect TLM interfaces across language boundaries.
Notes
● The Multi-Language UVM (ML-UVM) features support SystemC. However, this chapter focuses
on e and SystemVerilog UVCs. For more information on using SystemC models in a multi-language
environment, see Chapter 8 “SystemC in Mixed-Language UVM”.
● The ML-UVM features are supported only with the UVM SystemVerilog class library included with
IES and IES-XL. The open-source version of the class library (available from
http://www.uvmworld.org) cannot be used with the ML-UVM features, as it does not include the
necessary hooks.
Taking an existing SystemVerilog environment built on top of the open source class library and
running it with the class library in IES is trivial, as the later is a fully compatible superset of the
open-source library.
● This chapter does not cover approaches where an API layer is created for a given UVC in a different
language than the UVC’s core implementation. Unlike the true multi-language approach described
in this document, creating an API layer hides to some extent the core implementation of the UVC.
The API layer makes the UVC look-and-feel as if natively written in the API layer’s language. For
example, a UVC implemented in e can have a SystemVerilog API layer, allowing it to be used just
as a native SystemVerilog UVC. For more information on this alternative approach, see
“SystemVerilog Class Based over e” in the UVM Multi-Language Methodology.
2.2 Multi-Language UVM (ML-UVM) Features

When enabled, the Multi-Language UVM (ML-UVM) features in IES-XL provide the following
capabilities:
● Multi-language test selection and top entity instantiation

Enabling the ML-UVM Features
ML-UVM supports command-line control to instantiate top entities in a multi-language

environment. The topmost entity of the entire hierarchy - the test - is also explicitly declared via the
command line. These let UVCs in different languages be combined to create a logical
multi-language tree.
● Synchronization of elaboration phases

ML-UVM provides a centralized control over the invocation of all elaboration phases in e,
SystemVerilog and SystemC. The phases are invoked in a coordinated fashion so that the various
portions of the verification environment are configured, constructed, and connected across all
language boundaries. Furthermore, users have control over the order in which elaboration phases
are invoked, allowing customized configuration.
● Multi-language TLM connectivity

ML-UVM provides the ability to connect TLM interfaces across language boundaries. This enables
seamless connectivity between UVCs, regardless of their implementation language.
2.2.1 Enabling the ML-UVM Features

ML-UVM consists of features implemented in the various tools that are included in IES-XL, including
Specman, NC-SC, NC-Sim, and the UVM SystemVerilog class library. ML-UVM features are enabled
only when you specify one of the following irun command line options:
● -uvmtest to declare the root entity of the logical multi-language testbench

(See “-uvmtest” on page 4-1.)
● -uvmtop to declare a top entity
(See the“-uvmtop” on page 4-3.)
● -ml_uvm to enable ML-UVM
(See “-ml_uvm” on page 4-4.)
See Also
● The irun Command chapter of the irun User Guide, available with IES-L and IES-XL.
2.3 Multi-Language Trees of UVCs

When modeling a Device Under Test (DUT) in HDL or SystemC, a static hierarchy is defined in a
declarative way. The declarative nature of a static hierarchy lets it be fully defined during elaboration.
However, multi-language verification environments in e and SystemVerilog are usually more dynamic,
operating with quasi-static objects like units in e and uvm_component classes in SystemVerilog.
Quasi-static objects are created dynamically at run time and are guaranteed to persist throughout the
simulation. The hierarchy of such a verification environment is very different from the static DUT
hierarchy that is created during elaboration.

Multi-Language Trees of UVCs
There are two potential kinds of multi-language hierarchies:
● Single multi-language hierarchical tree

● Parallel single-language hierarchical trees
The current release of ML-UVM supports only the parallel trees approach. In absence of support for the
single multi-language tree, parallel trees can be used as a workaround for the logical hierarchy by
ordering the independent trees. The parallel trees have separate topmost components, but they may
communicate via TLM ports.
Figure 2-1 on page 2-4 shows a simple multi-language verification environment consisting of e and
SystemVerilog UVCs. The logical tree on the left represents the logical hierarchy of the UVCs, as we
would like to think about it. The very top is an e test that configures and controls an e module UVC. A
module UVC verifies a module-level or cluster-level DUT and would typically control several interface
UVCs. Each interface UVC connects to one interface of the DUT, like an Ethernet port, AHB, USB or
any other standard or proprietary protocol. In the diagram, the e module UVC controls two
SystemVerilog interface UVCs to actually drive the DUT signals.
Figure 2-1 Multi-Language UVC Trees
Single Logical Tree Multiple Single-Language Trees
e test Language
Boundary
e top SV tops
Module e test
UVC (e) Interface
UVC (SV)
TLM Communication Module

Signal-level
UVC (e) Communication
Interface
UVC (SV) DUT
TLM Communication
Signal-level
Communication Legend
e
DUT SV
Unlike the logical tree, from an implementation perspective this environment must actually be
represented by two single-language trees each operating in its own language domain. The right side of
the figure shows the e domain containing the e test and the module UVC with the e test as a top entity.

Specifying Top Entities
Similarly, the SystemVerilog interface UVC instances are top entities in the SystemVerilog domain. The
data communication between the UVCs in both cases is shown as TLM-based communication.
Tests as Top Entities

The various verification languages ML-UVM supports differ in concepts and semantics. One such
difference is in the concept of a test. In e, a test is a designated source file that contains logic to extend
and configure an existing e verification environment. In contrast, a test in UVM SystemVerilog is an
actual object (class instance) that instantiates the SystemVerilog verification environment underneath it.
For ML-UVM, both e test files and SystemVerilog test classes are considered to be top entities in their
language domains.
2.3.1 Specifying Top Entities

Multiple top entities can be created in each language domain. Typically, a top entity would be a test or a
UVC instantiated in one language but used by a UVC in another language. In the case of a test top entity,
it has no logical parent. In the case of a UVC top entity, its logical parent may be instantiated in another
language domain. In both cases, an entity without a parent in its own language domain must be
instantiated by ML-UVM.
2.3.1.1 -uvmtest Switch for irun (and ncsim)

You control the instantiation of the root entity through the use of the -uvmtest command line switch for
irun and ncsim. There must be only one root for the testbench, and therefore only one entity can be
instantiated with the -uvmtest option.
Specifying the test entity explicitly provides the following benefits:
1. The test is instantiated first, and goes through each of the elaboration phases first, before any other
top entities.
2. In SystemVerilog, the test instance will always have a fixed name – uvm_test_top – as in pure
SystemVerilog UVM environments. This consistent naming ensures that other parts in the
verification environment can access components in SystemVerilog with a full path that is fixed for
all the tests associated with a specific configuration. In addition, consistent test instance name
enables merging coverage results from simulations with different tests.
For more information, see “-uvmtest” on page 4-1

Example: Specifying Top Entities
2.3.1.2 -uvmtop Switch for irun (and ncsim)

You control the instantiation of top entities by ML-UVM through the use of the -uvmtop command line
switch for irun and ncsim. The -uvmtop command line switch declares a top entity in any language
supported by ML-UVM (e, SystemVerilog, or SystemC). One or more -uvmtop switches can be used to
specify one or more top entities. For example:
% irun ... \
-uvmtest e:test.e \
-uvmtop SV:ahb_env ...
-uvmtop SV:eth_env ...
For more information, see “-uvmtop” on page 4-3.
2.3.1.3 Top Entities Build Order

The test entity specified with -uvmtest is created and built first, and can thus configure other
components lower in the hierarchy.
The other top entities declared on the irun command line using -uvmtop switches are built according to
the order in which they are specified. The exact same order applies to the other elaboration phases (e.g.
connect).
For details on the elaboration flow with multiple top entities, see “Synchronized Elaboration Phases” on
page 2-7.
2.3.2 Example: Specifying Top Entities

The following example instantiates two top entities: an e test file (test.e) and a UVM SystemVerilog env
class (derived from uvm_env which in turn derives from uvm_component).
% irun \
my_top_sv_testbench_file.sv \
my_top_e_testbench_file.e \
-uvmtest e:test.e \
-uvmtop SV:env \
...
The top SystemVerilog testbench file begins with the following:

‘include "uvm_macros.svh"
module top_module;
import uvm_pkg::*;
import ml_uvm::*; // Required for ML-UVM
...

Synchronized Elaboration Phases
The e test file itself is identical to a test file in a pure-e environment. It does not require any additional
logic to support ML-UVM.
The above code example illustrates the following guidelines:
● You must use the UVM SystemVerilog library in a package.

Make sure you do not ‘include the UVM class library in your code using:
‘include "uvm.svh" // BAD! ERROR in multi-language flows
Instead, simply import the uvm_pkg package in any scope that uses it:
import uvm_pkg::*; // GOOD
● You must explicitly import the ml_uvm package in your SystemVerilog code.
This gives your code access to the ml_uvm SystemVerilog package and enables the features of
ML-UVM. Make sure to have at least one import statement for the ml_uvm package in your code.
Otherwise, all ML-UVM features are disabled.
Note Make sure to import the ml_uvm package from within a module, or another package, and
not in the compilation unit scope.
● You must include the uvm_macros.svh file.

To have access to all of the macros defined in the UVM class library, you must explicitly ‘include
the above file. Without the ‘include statement, no UVM library macros will be available in your
code, because the UVM library is compiled in a separate compilation step.
● Do not specify the UVM package file on the irun command line.
With the use of -uvmtop, irun will automatically compile the UVM and ml_uvm SystemVerilog
packages in a separate compilation step.
2.4 Synchronized Elaboration Phases

Phases are standard functions and tasks that are automatically executed by the underlying engine (or
library) in a specific order for all quasi-static components. Implementation of the phase functions and
tasks is provided by the user. This overrides (in SystemVerilog and SystemC) or extends (in e) the
predefined empty virtual functions/tasks.
2.4.1 Elaboration Phases in the Various Languages

Each of the three languages used for functional verification defines its own elaboration phases. Specman
e defines the following phases:
● pre_generate()

Synchronized Elaboration Phases with ML-UVM
● post_generate()
● connect_pointers()
● connect_ports()
● check_generation()
● run()
UVM SystemVerilog standardizes the following initial phases:
● build_phase()
● connect_phase()
● end_of_elaboration_phase()
● start_of_simulation_phase()
The SystemC LRM defines the following initial phases of the static components:
● end_of_construction()
● end_of_elaboration()
● start_of_simulation()
Note All of the phases, except the run phase in UVM SystemVerilog, are non-blocking (cannot
consume simulation time).
See Also
● “Test Phase Flow” in the Specman e Language Reference
● “Simulation Phase Methods” in the UVM User Guide
● “Callback Phases” in the SystemC Language Reference, and “Methodology for Hierarchy
Construction” in the SystemC Library Reference
2.4.2 Synchronized Elaboration Phases with ML-UVM

Without ML-UVM, the elaboration phases in different languages are completely disconnected.
Furthermore, the order in which they are executed is predefined by the tools and cannot be controlled by
users.
This is not sufficient to support multi-language environments. For example, consider an environment
with both e and SystemVerilog components. If a top test entity in e is used, the e portions must be
elaborated first, followed by the SystemVerilog portions. However, with a similar environment using a
SystemVerilog top test entity, the opposite order is used: SystemVerilog portions elaborated first,
followed by the e portions.

Despite the terminology and naming differences, the language-specific phases have much in common.
ML-UVM establishes the correspondence between the phases and provides a mechanism that
synchronizes them at run time. The synchronization is achieved by interleaving the invocation of the
existing phases in all languages. Each logical phase is executed for all quasi-static components of the
testbench, regardless of the component’s language of implementation. Figure 2-2 on page 2-9 shows the
synchronization of phases across the different languages supported by ML-UVM.
Figure 2-2 Alignment of Elaboration Phases in a Multi-Language Environment
SystemC e UVM SV
end_of_construction()
end_of_construction pre_generate(), build_phase()
post_generate()
connect_pointers(), connect_phase()
connect_ports()
end_of_elaboration() check_generation() end_of_elaboration_phase()
start_of_simulation() run() start_of_simulation_phase()
The order of execution of the phases at the same level (for example, end_of_construction in SystemC, e
generation, and build in UVM SystemVerilog) is controlled by users according to the order of -uvmtop
command line switches. This does not depend on the language itself.
ML-UVM can handle two main kinds of top entities:
● Explicit top entities are those defined using the -uvmtop command line switch.
● Implicit top entities are those that exist by default (for example sys in e) or are created procedurally
in the testbench, with no parent in their language domain. For example, in SystemVerilog you might
have a uvm_component instance with a null parent that was created using a static initializer.
ML-UVM invokes the phases in explicit top entities and their children in the order in which their
respective -uvmtop switches were specified. Once all explicit top entities have gone through a certain
phase, ML-UVM invokes the same phase in all implicit top entities.
The order of phase invocation in implicit top entities matches their instantiation order within each
language domain. The order between language domains is arbitrary.

e Testbench as a Single Top Entity

Given the nature of e, ML-UVM treats top entities in e differently than in the other languages. Although
multiple -uvmtop switches can name top e entities (files), ML-UVM treats the entire e testbench as a
single tree under the sys top entity. Therefore, the following applies to the e testbench:
● As a single top entity, the entire e testbench goes through each of the elaboration phases at once.
● If you specify an e test file as a top entity using -uvmtop, its order relative to other -uvmtop switches
determines when the e testbench goes through its phases.
● If you do not have an e test file, like other implicit top entities the e testbench will go through its
phases last, after all other explicit top entities.
Example
Consider an environment that specifies three explicit top entities:
% irun -uvmtest SV:sv_test \
-uvmtop e:test.e \
-uvmtop SV:sv_env ...
Based on the order of explicit top entities, ML-UVM invokes the elaboration phases in the following
order:
1. Build:
a. build_phase() for sv_test in SystemVerilog
b. pre_generate() and post_generate() for all units in the e environment
c. build_phase() for sv_env in SystemVerilog
2. Connect:
a. connect_phase() for sv_test in SystemVerilog
b. connect_pointers() and connect_ports() for all units in the e environment
c. connect_phase() for sv_env in SystemVerilog
3. Check:
a. end_of_elaboration_phase() for sv_test in SystemVerilog
b. check_generation() for all units in the e environment
c. end_of_elaboration_phase() for sv_env in SystemVerilog

Starting Point for Quasi-Static Elaboration
2.4.3 Starting Point for Quasi-Static Elaboration

Without ML-UVM, UVM SystemVerilog requires that you activate the elaboration explicitly by
invoking the global run_test() task, typically inside an initial block. This applies to SystemVerilog only.
It creates a race condition between the initialization activities of the testbench and of the DUT.
Similarly, an e verification environment must be elaborated (pre-run generation) by an explicit test

command. Here too, the test command applies only to the e portion of the environment. It must be
invoked before SystemVerilog and SystemC simulation has started.
ML-UVM obsoletes both of the above by implementing an automated mechanism to trigger the phases
in all supported languages. The appropriate time to execute the quasi-static testbench phases is at the
beginning of simulation, before any concurrent design processes. Such timing enables execution of the
procedural code for phases in all languages (construction of testbench components, connection of ports,
initialization of stimuli, and so on). It avoids race conditions between testbench elaboration and the
DUT.
ML-UVM takes care of instantiating and starting the quasi-static elaboration phases. This occurs at the
following point in simulation time zero:
● After the TCL run command has been entered at the ncsim prompt (or after the run command in
batch mode)
● After static initialization of the DUT and the testbench, including initialization of HDL variable
declarations and initialization of static SystemVerilog class members
● Before execution of any DUT processes, including SystemVerilog initial blocks
Launching the Run Phase and Blocking Threads

The UVM SystemVerilog run phase is a blocking task. With ML-UVM this phase is scheduled for
execution after execution of all elaboration phases and before the execution of any initial/always block
(or any other behavioral construct) in the DUT.
Execution of the testbench threads in the other languages (e and SystemC) happens as before, because
they are not synchronized with any phase.
2.4.4 Using the UVM-SV Configuration Database

UVM 1.0 introduced the configuration database, which can be used to configure attributes in UVM
components. Unlike the older set_config_*-based API, the configuration database allows configuration
of any type of attributes, including virtual interfaces. As a result, it is a common methodology to
configure virtual interface variables in the testbench through configuration calls inside an initial block in
the top module. The following example illustrates this:

Using the UVM-SV Configuration Database
// Plain UVM-SV example

// This code is *incompatible* with ML-UVM
module top;
...
// interface instance
my_interface intf_0();
initial begin
// configure the virtual interface in the testbench class
uvm_config_db#(virtual my_interface)::set(null, "*_tb", "vif", intf_0);
run_test();
end
endmodule
Note The above code will not work with ML-UVM. With ML-UVM, all the SV top
components—including the test, if used—are constructed before any initial blocks are executed. As a
result, the configuration call will occur too late, and thus will not have the desired effect. Furthermore,
it's likely that checks inside the testbench, which ensure that a virtual interface was properly configured,
will fire during one of the elaboration phases before the initial block even executes. In addition, the code
invokes run_test(), which is redundant (a warning message will be printed) because ML-UVM takes
care of it already.
To accommodate ML-UVM, you need to change your testbench by eliminating any configuration done
inside initial blocks. The same logic should be moved into a function of the module, which should be
called during initialization of a new auxiliary variable in the same module.
The following code shows the above example modified to work properly with ML-UVM:
// Modified example for ML-UVM
// This code will work with ML-UVM
module top;
...
// interface instance
my_interface intf_0();
// configuration logic moved from an initial block into a function

function bit config_virt_interfaces();
// configure the virtual interface in the testbench class
uvm_config_db#(virtual my_interface)::set(null, "*_tb", "vif", intf_0);
return 1;
endfunction
// the function is called to initialize an auxiliary variable

bit config_virt_interfaces_done = config_virt_interfaces();
endmodule

Required Changes to User Code
2.4.5 Required Changes to User Code

Table 2-1 on page 2-13 summarizes the changes required to user code and scripts when working with
ML-UVM in a multi-language environment. Recall that ML-UVM is in effect once you use one of the
command line options described in “Specifying Top Entities” on page 2-5.
Table 2-1 Summary of Required Changes to User Code with ML-UVM
Obsoleted Replacement Description
run_test() N/A Do not call the run_test() task explicitly in your

[UVM SystemVerilog SystemVerilog code. If you do, a warning
global task] message is printed, and the call is ignored.
test N/A Do not issue the test command to Specman. If you

[Specman command] do, a warning message is printed and the call is
ignored.
+UVM_TESTNAME … -uvmtest … Use the -uvmtest switch to identify a

[irun command line SystemVerilog test, instead of the
switch] +UVM_TESTNAME switch.
set_config* and Move into build() Do not use set_config* or uvm_config_db calls
uvm_config_db# calls functions of top inside initial blocks. They will not have any effect
inside initial blocks component(s), or a since with ML-UVM elaboration phases are
function called invoked (and the SV component hierarchy fully
during initialization built) before any initial blocks are executed.
Instead, move the set_config* calls to the build()
hook of one of your top SV components. If you
are trying to configure virtual interfaces from
within the an initial block, see the section “Using
the UVM-SV Configuration Database” on page
2-11.
Tip If you mistakenly use the +UVM_TESTNAME command line option along with ML-UVM, the
following error is issued at run-time:
UVM_FATAL @ 0: uvm_test_top [ILLCRT] It is illegal to create a component
once phasing reaches end_of_elaboration. The current phase is
start_of_simulation.
2.4.6 Example: Synchronized Elaboration Phases

This section shows a small example that illustrates the synchronization of elaboration phases between e
and SystemVerilog. The example also shows how the order of -uvmtop switches affects elaboration.

Example: Synchronized Elaboration Phases
2.4.6.1 Trivial SystemVerilog Testbench

First, consider a simple SystemVerilog testbench file that defines a UVM component named my_sv_env.
// File: top.sv
‘include "uvm_macros.svh"
module top;
import uvm_pkg::*;
import ml_uvm::*;
class my_sv_env extends uvm_env;

‘uvm_component_utils(my_sv_env)
function new (string name, uvm_component parent=null);

super.new(name,parent);
‘message(UVM_LOW, ("SV env created!"))
endfunction
virtual function void build_phase(uvm_phase phase);

super.build_phase(phase);
‘message(UVM_LOW, ("SV env in build phase!"))
endfunction
virtual function void connect_phase(uvm_phase phase);

super.connect_phase(phase);
‘message(UVM_LOW, ("SV env in connect phase!"))
endfunction
endclass
endmodule
The main purpose of the above code is to print a message when the component goes through its main
elaboration phases (build and connect).
2.4.6.2 Trivial e Testbench

Next, consider the following simple e testbench file that does a similar thing using an e unit.
// File: top.e
<’
unit my_e_top_u {

pre_generate() is also {
message(LOW, "In pre_generate!");
};
connect_ports() is also {
message(LOW, "In connect_ports!");
};
};
extend sys {
my_e_top: my_e_top_u is instance;
};
’>
2.4.6.3 Trivial e Test File

The following defines a simple e test file that just configures the e testbench.
// File: test.e
<’
extend my_e_top_u {
short_name(): string is only {
result = "E_ENV";
};
};
’>
You can now use both the e test file and the SystemVerilog component that were defined as top entities
to be instantiated by ML-UVM.
2.4.6.4 Using the e Test as the First Top Entity

To invoke simulation naming the e test as the first top entity, use the following command:
% irun \
top.sv \
top.e \
-uvmtest e:test.e \
-uvmtop sv:my_sv_env
The order of top entities on the command line determines the order in which entities are instantiated and
elaborated by ML-UVM. Therefore, the e testbench should be first in each elaboration phase, followed
by the SystemVerilog components. The simulation log file shows:

ncsim> run
Loading test.e ...
read...parse...update...patch...h code...code...clean...
[0] hier=my_sv_env: SV env created!
Doing setup ...
Generating the test using seed 1...
[0] E_ENV: In pre_generate!
[0] hier=my_sv_env: SV env in build phase!
[0] E_ENV: In connect_ports!
[0] hier=my_sv_env: SV env in connect phase!
As you can see in the last four lines in the log, elaboration is performed in the expected order:
1. The e environment goes through pre-run generation (shown by the E_ENV printout in the
pre_generate() phase).
2. The SystemVerilog portion is built next (shown by the printout from the SystemVerilog env going
through build_phase() ).
3. Port connection in e takes place (shown by the E_ENV printout in the connect_ports() phase).
4. Port connection in SystemVerilog follows (shown by the printout from the SystemVerilog env going
through connect_phase() ).
2.4.6.5 Using the SystemVerilog Component as the First Top Entity

Next, use the following command to invoke simulation naming the SystemVerilog env component as the
first top entity:
% irun \
top.sv \
top.e \
-uvmtest sv:my_sv_env \
-uvmtop e:test.e
Note For simplicity, same SystemVerilog env component as the first top entity is used. In a realistic
environment, the first top entity would always be a test, either in e or SystemVerilog.
This time, the SystemVerilog entity should be built first, followed by the e environment. The simulation
log file now shows:
ncsim> run
[0] hier=my_sv_env: SV env created!
Loading test.e ...
read...parse...update...patch...h code...code...clean...
[0] hier=my_sv_env: SV env in build phase!

Doing setup ...

Generating the test using seed 1...
[0] E_ENV: In pre_generate!
[0] hier=my_sv_env: SV env in connect phase!
[0] E_ENV: In connect_ports!
As seen in the last six lines in the log, the elaboration is performed in the expected order:
1. The SystemVerilog portion is built first (shown by the printout from the SystemVerilog env going
through build_phase()).
2. The e environment goes through pre-run generation next (shown by the E_ENV printout in the
pre_generate() phase).
3. Port connection in SystemVerilog takes place (shown by the printout from the SystemVerilog env
going through connect_phase()).
4. Port connection in e follows (shown by the E_ENV printout in the connect_ports() phase).
2.4.6.6 Using Multi-Step Mode Simulation instead of irun

The previous examples have utilized irun to simplify compilation and invocation. If needed, the
multi-step flow (e.g. ncvlog-ncelab-ncsim) can too be used for multi-language environments. The
following shows how this is applied to the example shown in Section 2.4.6.5, “Using the SystemVerilog
Component as the First Top Entity,” on page 2-16:
#!/bin/sh
UVM_HOME=`ncroot`/tools/uvm
ML_UVM_SRC=`ncroot`/tools/uvm/ml
echo "sn load test.e ; run" > sn_cmds.tcl
## First, prepare the Specman stub file

specman -command "load top.e; write stubs -ncsv"
ncvlog \
-messages \
-sv \
-incdir ${UVM_HOME}/src \
${UVM_HOME}/src/uvm_macros.svh \
${UVM_HOME}/src/uvm_pkg.sv \
${ML_UVM_SRC}/ml_uvm_pkg.sv \
top.sv \
specman.sv \
-nowarn PMBDVX \
-nowarn ENUMERR

Data Communication Using TLM
ncelab \
-messages \
worklib.top \
worklib.specman \
-access +rw
ncsim \
-messages \
-uvmtest sv:my_sv_env \
-uvmtop e:test.e \
-input sn_cmds.tcl \
worklib.top:module
2.5 Data Communication Using TLM

Transaction Level Modeling (TLM) communication provides a standard mechanism to connect
high-level verification components. All three languages supported by ML-UVM (e, SystemVerilog and
SystemC) provide TLM interfaces, each supporting connections within its own language domain.
ML-UVM adds a unique capability of connecting TLM interfaces across language boundaries.
2.5.1 Advantages of Using TLM

In comparison with the existing e/SystemVerilog and e/SystemC method ports, multi-language TLM
connectivity provides the following advantages:
● Method ports allow binding a single e method to a SV/SC function or task. A TLM interface
encapsulates a number of related functions and tasks.
● Method ports are e-specific. They support binding on the e side only. Multi-language TLM ports can
be instantiated and bound in any supported language.
● External method ports require generation of glue SystemVerilog or SystemC code (known as the
stubs file). Implementation of multi-language TLM ports is generic. It does not require additional
code generation.
● An input e method port is associated with a global SystemVerilog or SystemC function/task, which
requires a special unit mapping logic to support multiple instances. The connection of multi-language
TLM ports is natively done by instance.
● The mltypemap utility can be used to generate data types in a target language based on data types in
a source language. These data types can then be used as data types in ML UVM transactions using
ML UVM TLM ports.

Requirements for Using TLM in Multi-Language Verification Environments
2.5.2 Requirements for Using TLM in Multi-Language

Verification Environments
Using TLM ports to communicate between UVCs in a multi-language environment introduces the
following requirements:
● Matching or mapping TLM port types between the various languages

Each of the three verification languages that ML-UVM supports (e, SystemVerilog, and SystemC)
implements the standard TLM interface types. Table 2-4 on page 2-28 in “Matching TLM Ports in
ML-UVM” on page 2-28 shows the mapping between the TLM port types in the various languages.
Chapter 6 “mltypemap Utility: Automatic Generation of Data Types” discusses a utility you can use to
generate data types across language boundaries.
● Connecting TLM ports across language boundaries

This is a key functionality, letting UVCs connect to other UVCs regardless of their implementation
language. It should be possible to specify how to connect the various TLM ports in a multi-language
environment in any of the supported languages. Furthermore, it should be easy to connect ports by
their logical name so that the actual connecting logic is language-neutral and need not change when
UVCs are replaced with different implementations.
● Passing of transaction objects across languages

TLM ports are predominantly used to pass transactions. In a multi-language UVM environment,
these would typically include:
● Sequence items — Generated by one component and needing to be driven to the DUT by another
● Monitor transactions — Collected by a monitor and broadcast to other components for checking
and coverage collection
Passing an object across a language boundary requires the ability to map an object of a given type
in one language domain to a completely different class type in the other language domain. Past
attempts to enable such communication required adding significant amounts of manually-created
code. The extra code managed the packing and unpacking of objects to a binary form that would
then be passed across the language boundary. The same functionality is better handled by the
underlying engines in each language, reducing dramatically the potential for user error and
maintenance effort over time.
The ML-UVM features added to the underlying tools in IES-XL address the above requirements as
described in the following sections.

Connecting TLM Ports Across Languages
2.5.3 Connecting TLM Ports Across Languages

ML-UVM adds the ability to connect TLM ports across language boundaries. For that functionality, you
must use the utilities that ML-UVM provides in each of the three supported languages (e,
SystemVerilog, and SystemC) to register ports and connect them to implementations, either in the same
language domain or across a language boundary.
Note In SystemVerilog and SystemC, the ML-UVM utilities should be used instead of the built-in
utilities in the respective language or UVM library implementation.
See Also
● “Executing Specman Code Asynchronously” in the Specman Integrators Guide contains information
about working in mixed verification environments and using timeless models where Specman is often
called asynchronously.
2.5.3.1 Summary of ML-UVM Features for TLM

ML-UVM provides new utilities in each of the three supported languages (e, SystemVerilog, and
SystemC) to register and connect TLM ports. The utilities are implemented differently in each of the
languages, as shown in Table 2-2 on page 2-20.
Table 2-2 ML-UVM Utilities for TLM Connection
Language ML-UVM Utilities Access Method
e ● external_uvm_path() Predefined in Specman/e

(attribute of TLM ports)
● ml_uvm.connect_names()
SystemVerilog ● ml_uvm::connect() Functions in the ml_uvm package.

● ml_uvm::connect_names()
● ml_uvm::external_if()
SystemC ● ml_uvm::ml_uvm_register() Functions in the ml_uvm namespace

● ml_uvm::ml_uvm_connect()
For more information on the e utilities, see “Using e TLM Interface Ports” in the Specman Testbench
Integrators Guide. The SystemVerilog utilities are described in this document. For more information on
the SystemC utilities, see Chapter 8 “SystemC in Mixed-Language UVM”.

Connecting TLM Ports Across Languages
2.5.3.2 Connecting TLM Ports Between e and SystemVerilog

When connecting TLM ports between e and SystemVerilog, the connection logic can reside in any one
of the languages supported by ML-UVM or a combination thereof.
To perform port connections in e:
1. Do either of the following:
● To connect e ports, use a constraint to set their external_uvm_path() attribute.

● To connect any arbitrary ports in any of the supported languages, use the
ml_uvm.connect_names() method during the connect_ports phase.
2. Make sure that the SystemVerilog ports/implementations to which you are connecting have been
registered with ML-UVM using a call to the ml_uvm::external_if() SystemVerilog function. If
needed, you may add calls to ml_uvm::external_if() in your SystemVerilog testbench layer to
register any existing TLM ports/implementations in the SystemVerilog UVCs.
To perform port connections in SystemVerilog:
1. Use either ml_uvm::connect() or ml_uvm::connect_names() during the connect phase.
2. Make sure that any e ports to which you refer have been bound externally using a bind(port,
external) constraints in the e code. If needed, you can easily add bind(port, external) constraints in
the e testbench layer by extending any unit of the underlying e UVCs.
For a complete example, see “Example: e to SystemVerilog TLM Port Connection” on page 2-24.
Note If using one of the procedural connection approaches above, make sure to invoke it in the correct
phase: connect_ports() in e, connect() in SystemVerilog. These phases are executed after all testbench
components are created and before the correctness of connections is checked.
Using the Language-Neutral Connection Methods

ML-UVM enables the connection logic in both e and SystemVerilog to connect ports/implementations
in a fully language-neutral fashion. The connect_names() function mentioned above in both e and
SystemVerilog facilitates language-neutrality by connecting ports/implementations using only their
string ML-UVM path rather than an actual handle (or reference).
The strings passed to connect_names() can be dynamically calculated during the elaboration phases,
based on configuration from the top testbench layer. This lets you create reusable connection logic that
can be applied as is regardless of the language domain where the actual UVCs and their
ports/implementations are instantiated.

Passing Transactions Across Languages
2.5.3.3 ML-UVM External Path Strings

The various ML-UVM utilities shown in Table 2-2 on page 2-20, take a string argument that designates
a full path to a TLM port in any one of the supported languages. The ML-UVM path string is defined as
explained in Table 2-3 on page 2-22.
Table 2-3 ML-UVM Path for TLM Connection
Language ML-UVM Path Example
e e path of a port, as returned by a unit’s sys.env.master.put_port

e_path()
SystemVerilog Full name of the port/implementation, uvm_test_top.env0.master0.put_imp

as returned by a component’s
get_full_name()
SystemC Full name of the port/implementation, model.in_port

as returned by get_full_name()
The fact that the external path in all languages is specified as a string expression, lets UVCs and
connection logic be independent of the implementation language of other parts of the testbench.
The external path does not need to contain any indication of the implementation language. The
underlying ML-UVM implementation finds the corresponding port (or implementation) according to the
name and path of the topmost component for that language. For example, sys is a predefined topmost
component for all e units and ports, the names of the topmost UVM SystemVerilog components are
registered in the UVM library, and so on.
Note All topmost components must have unique names, resulting in unique ML-UVM paths.
2.5.4 Passing Transactions Across Languages

ML-UVM supports the passing of transaction objects across the various supported languages. The
transaction types must derive directly or indirectly from the basic object type in the language that can be
dynamically allocated:
● any_struct in e
● uvm_object in SystemVerilog and SystemC
To be passed across a language boundary, an object is first packed into a bitstream using the packing
utilities defined by the language itself (in e), the UVM library (in SystemVerilog), or by users (in
SystemC). The bitstream is then passed to the other language, and unpacked there into an instance of the
target object type.

Passing Transactions Across Languages
Passing transactions across languages is always done by value and not by reference. A consumer
component that received a transaction can modify any of its attributes, but none of the modifications are
visible on the producer side. Similarly, if the producer modifies the transaction while it is being handled
by the consumer, none of the modifications are visible to the consumer.
Note Native TLM implementations vary by the approach chosen for passing transactions within the
same language. Pure SystemC TLM passes transactions by value in the TLM 1.0 standard, and by
reference in the TLM 2.0 standard. TLM implementations in pure SystemVerilog or e pass transactions
by reference.
2.5.4.1 Type Mapping between e, SystemVerilog, and SystemC

ML-UVM supports automatic type mapping using the mltypemap utility. This utility can be used to
generate data types in a target language based on data types in a source language. These data types can
then be used as data types in ML UVM transactions using ML UVM TLM ports.
Using mltypemap lets you avoid manually coding type definitions, which can be complex, tedious, and
error prone.
mltypemap is a TCL-based tool that is invoked from irun. When you invoke mltypemap, you must
enter the appropriate mltypemap-related flags plus all the compilation flags necessary for irun to
compile the files and elaborate the snapshot (in the case of SystemVerilog inputs).
For information on invoking mltypemap and its commands, see Chapter 6 “mltypemap Utility: Automatic
Generation of Data Types”.
Without using the mltypemap utility, transaction types in different languages are compatible if they
match at the binary representation level. This requires that all attributes (fields) in the two transactions
match in type and declaration order. Only compatible transaction types can be packed into a bitstream in
one language and then successfully unpacked to a valid object in another language.
For e structs which make use of when-subtypes, mltypemap must be used to create the corresponding
SystemVerilog/SC types.
The only legal type mappings are those provided in Table 6-1 on page 6-17 and Table 8-2 on page 8-21.
If you use a mapping outside these tables, the mapping may or may not work, depending on the
implementation. Even if it does work in a particular release, there are no guarantees it will continue to
work in future releases, because the implementation may change from one release to another. Where
possible, use the mltypemap utility which will ensure only legal mappings are used.
Refer to “Mapping Types with mltypemap” on page 6-11 for more information on type mapping across
languages.
For a complete example, see:
● “Example: Passing a Compound Transaction” on page 2-26

Example: e to SystemVerilog TLM Port Connection
● “Examples” on page 6-1
2.5.5 Example: e to SystemVerilog TLM Port Connection

The following example illustrates an e TLM put port connected to a SystemVerilog put implementation,
showing port connection logic done in both of languages.
Consider first the SystemVerilog code. A driver class defines a put implementation and registers it with
ML-UVM using the external_if() function.
File: top.sv
class burst extends uvm_transaction;
...
endclass
class driver_c extends uvm_driver;

...
uvm_put_imp #(burst, driver_c) burst_ip;
function new(string name = "driver_c", uvm_component parent);

super.new(name, parent);
burst_ip = new("burst_ip", this);
endfunction // new
// Implementing the put export

extern virtual task put(burst t);
extern virtual function bit try_put(burst t);
extern virtual function bit can_put();
extern virtual function tlm_event ok_to_put();
endclass
class sv_tb extends uvm_env;

driver_c driver;
...
endclass
The sv_tb class shown above is instantiated by ML-UVM as a top entity by naming it with a -uvmtop
command line switch.
Next, consider the e code that defines a TLM put port with a matching transaction type.
File: top.e
struct burst like any_sequence_item {
... // Burst attributes here

Example: e to SystemVerilog TLM Port Connection
};
unit e_generator_u {
burst_op : out interface_port of tlm_put of burst is instance;
...
drive_burst( b: burst) @clock is {
burst_op$.put(b); // Put burst on port
};
};
extend e_tb {
generator: e_generator_u is instance;
};
Connection In e
To connect the ports in e, place the following logic in a separate e file that configures the testbench.
extend e_tb {
keep bind(generator.burst_op, external);
ml_uvm.connect_names("sys.generator.burst_op",
"sv_tb.driver.burst_ip");
};
Note The order of arguments to connect_names matters. The first argument must be the port or out
interface_port in e. The second argument must be the export - implementation in SystemVerilog, or in
interface_port in e.
The connection from e would apply only if the SystemVerilog port has been registered with ML-UVM
through a call to ml_uvm::external_if(). You can add the call from the SystemVerilog testbench layer:
driver_c driver;
...
ml_uvm::external_if(driver.burst_ip, "burst");
endfunction
endclass
Connection in SystemVerilog
Similarly, the port connection can be done in SystemVerilog instead of e.

Example: Passing a Compound Transaction

driver_c driver;
...
function void connect_phase(uvm_phase phase);
ml_uvm::external_if(driver.burst_ip, "burst");
ml_uvm::connect_names("sys.generator.burst_op",
"sv_tb.driver.burst_ip");
endfunction
endclass
Note The order of arguments to connect_names matters. The first argument must be the port or out
interface_port in e. The second argument must be the export - implementation in SystemVerilog, or in
interface_port in e.
For the above connection to work, the e port should be bound externally. This can easily be added in the
e testbench level.
extend e_tb {
keep bind(generator.burst_op, external);
};
2.5.6 Example: Passing a Compound Transaction

The following example illustrates two compatible transaction types, one in e and the other in
SystemVerilog. The main transaction is a burst that has both scalar attributes and an embedded object, as
well as a dynamic array of data. This is representative of realistic UVCs.
First, consider the ❅ code. It defines the embedded object type (header) and the compound transaction
(burst).
File: top.e
type color_t :[ RED = 0,
BLUE = 1,
GREEN = 4 ] (bits: 3);
struct header {
%data: byte;
};
struct burst like any_sequence_item {

%address : uint;
keep soft address in [100..500];
%color: color_t;
%header: header;

Example: Passing a Compound Transaction
%data_bits: list of bit;

keep soft data_bits.size() in [5..10];
};
Next, consider the matching SystemVerilog code.
File: top.sv
typedef enum bit [2:0] { SV_RED=’d0,
SV_BLUE=’d1,
SV_GREEN=’d4 } color_t;
class header extends uvm_transaction;

byte unsigned data;
‘uvm_object_utils_begin(header)
‘uvm_field_int(data, UVM_ALL_ON)
‘uvm_object_utils_end
endclass
class burst extends uvm_sequence_item;

int unsigned address;
color_t color;
header header;
bit data_bits[];
‘uvm_object_utils_begin(burst)
‘uvm_field_int(address, UVM_ALL_ON)
‘uvm_field_enum(color_t, color, UVM_ALL_ON)
‘uvm_field_object(header, UVM_ALL_ON)
‘uvm_field_array_int(data_bits, UVM_ALL_ON)
‘uvm_object_utils_end
endclass
The above example illustrates the following guidelines:
● Class type names must match.

The transaction type names as well as the names of nested class types must be the same in both e
and SystemVerilog. In our example, the top transaction is named burst, and the nested class is
named header. Mismatching names will cause run-time errors.
● Use only physical fields in the e transactions.

Only the physical fields — those marked with ‘%’ — in e transactions are packed when the
transaction is passed to SystemVerilog. TLM ports in e use a dedicated packing mechanism, and are
not affected by logic you may have placed in the do_pack() and do_unpack() methods of the e
transactions.

Matching TLM Ports in ML-UVM
● Enumerated types must match in bit size and numeric values.

Enumerated types can be passed across languages. However, you must make sure to have both the
bit size and numeric values of the enumerated literals match in both e and SystemVerilog. It is not
required for the enumerated literals themselves to have matching names.
In our example, both enumerated types are defined with a bit size of three. In addition, the numeric
values are assigned explicitly and are made to match. For example, GREEN in e and SV_GREEN
in SystemVerilog have the same numeric value of four.
● You must use the UVM SystemVerilog field automation macros.

When defining the SystemVerilog transactions, it is critical to use the UVM field automation
macros. Since packing and unpacking is implemented in the UVM class library rather than the
language, you must use the ‘uvm_object_* and ‘uvm_field_* macros to have the
packing/unpacking logic implemented.
Pay special attention to the order of ‘uvm_field_* macros, which determine the packing and
unpacking order. They must match the order of field declarations in the counterpart e struct.
2.5.7 Matching TLM Ports in ML-UVM

Table 2-4 on page 2-28 shows the mapping between the various TLM port/implementation types in the
three languages supported by ML-UVM.
The table shows only the port types. Each port type has an associated implementation types, with the
name derived as follows:
● SystemC: “sc_export” instead of “sc_port”

● SystemVerilog: “_export” or “_imp” suffix instead of “_port”
● e: “export interface_port” or “in interface_port” instead of “out interface_port”
Table 2-4 TLM Port Type Mapping in the ML-UVM Supported Languages
SystemC SystemVerilog e
sc_port< tlm_blocking_ uvm_blocking_put_port #(T) out interface_port of

put_if<T> > tlm_blocking_put of type
sc_port< tlm_non_ uvm_nonblocking_put_port out interface_port of

blocking_put_if<T> > #(T) tlm_nonblocking_put of type
sc_port< tlm_put_if<T> > uvm_put_port #(T) out interface_port of tlm_put of type
sc_port< tlm_blocking_ uvm_blocking_get_port #(T) out interface_port of

get_if<T> > tlm_blocking_get of type

Matching TLM Ports in ML-UVM
Table 2-4 TLM Port Type Mapping in the ML-UVM Supported Languages (continued)
SystemC SystemVerilog e
sc_port< tlm_non_ uvm_nonblocking_get_port out interface_port of

blocking_get_if<T> > #(T) tlm_nonblocking_get of type
sc_port< tlm_get_if<T> > uvm_get_port #(T) out interface_port of tlm_get of type
sc_port< tlm_blocking_ uvm_blocking_peek_port out interface_port of

peek_if<T> > #(T) tlm_blocking_peek of type
sc_port< tlm_non_ uvm_nonblocking_peek_port out interface_port of

blocking_peek_if<T> > #(T) tlm_nonblocking_peek of type
sc_port< tlm_peek_if<T> uvm_peek_port #(T) out interface_port of tlm_peek of

> type
sc_port< tlm_blocking_ uvm_blocking_get_peek_port out interface_port of

get_peek_if<T> > #(T) tlm_blocking_get_peek of type
sc_port< tlm_non_ uvm_nonblocking_get_peek_ out interface_port of

blocking_get_peek_if<T> port #(T) tlm_nonblocking_get_peek of type
>
sc_port< tlm_get_peek_ uvm_get_peek_port #(T) out interface_port of tlm_get_peek

if<T> > of type
sc_port< tlm_transport_ uvm_blocking_transport_port out interface_port of

if<T1,T2> > #(T1,T2) tlm_blocking_transport of (type1,
type2)
N/A uvm_nonblocking_transport_ out interface_port of

port #(T1,T2) tlm_nonblocking_transport of
(type1, type2)
N/A uvm_transport_port #(T1,T2) out interface_port of tlm_transport

(see note below) of (type1, type2)
sc_port< tlm_analysis_ uvm_analysis_port #(T) out interface_port of tlm_analysis of

if<T> > [TLM 2.0] type
Note An sc_port<tlm_transport_if<T1, T2>> in SystemC can be connected to a uvm_transport_imp

#(T1, T2) in SystemVerilog by virtue of the fact that simple ports can be connected to more derived
exports.

Limitations in This Release
2.6 Limitations in This Release

This release of ML-UVM has the following known limitations pertaining to multi-language TLM
connectivity:
● Multi-language TLM is supported with IES-XL only, and not with any third-party simulators.
● Passing of transactions by reference through TLM ports is not supported.
● Only transactions of a SystemVerilog class (derived from uvm_object) and e struct types are supported
in TLM communication.
● There is no automated checking of type conformance for multi-language TLM ports.
● A SystemC port/export can be bound across a language domain only to its counterpart
implementation/port. So, for example, connecting a SystemC port to an e/SystemVerilog port, or a
SystemC export to an e/SystemVerilog implementation/export is not supported.
● Multiple binding (multiport) for multi-language connections is supported only for analysis ports
between e and SystemVerilog.
● Blocking calls between Specman/e threads and SystemVerilog/SystemC threads are preemptive. This
means that control does not pass from one language to another immediately, but rather involves the
simulation scheduler. This consumes an additional Specman tick and one cycle of simulation time,
in contrast to communication between SystemVerilog and SystemC threads.
● The default length (in bits) of a transaction passed in a multi-language TLM port is the value of
UVM_STREAMBITS SystemVerilog constant - 4096. To increase this limit you can use the
documented define UVM_PACK_MAX_SIZE. For example:
% irun -defineall UVM_PACK_MAX_SIZE=<value-in-bits>
● The functions ok_to_put(), ok_to_get(), ok_to_peek() in the relevant TLM ports are not supported
by ML-UVM. Some of these are also not supported by UVM SystemVerilog.
● The TLM master and slave interfaces are not supported by ML-UVM.
● The e testbench must be explicitly configured to work with SystemVerilog using one of the following
options:
● -snsv command line switch in irun (for the SystemVerilog/e only mode)
● agent() attribute in any one of the instantiated e units
● The TCL command uvm_phase -stop_at does not stop simulation at the build, connect,
end_of_elaboration, and start_of_simulation phases when in ML-UVM mode.
● Process control features (for example, disable in SystemVerilog or quit() in e) in the various
supported languages should not be used on threads that perform cross-language communication. The
result of using process control features on such threads is unpredictable.

3 Using SystemVerilog
Sequences in an e Testbench
This topic describes the API that lets you send sequences from a top-level e test to be run by a
SystemVerilog component. It contains the following sections:
● “About Running Sequences in Multi-Language Environments” on page 3-1

● “Mixed-Language Sequences API” on page 3-2
3.1 About Running Sequences in Multi-Language

Environments
This topic describes the features and methodology that let you send sequences from a top-level e test to
be run by a SystemVerilog component. Figure 3-1 on page 3-2 shows a sample e module-level
verification environment enclosing a SystemVerilog component.
To run sequences in a component of another language, you need to do the following:
1. Create a sequencer stub in the SystemVerilog component.
See “Mixed-Language Sequences API” on page 3-2.
2. Create a proxy sequencer in the e environment.
3. Connect the proxy sequencer to the stub.

Using SystemVerilog Sequences in an e Testbench
Mixed-Language Sequences API
Figure 3-1 Module-Level Mixed-Language Verification Environment
e top-level test
Virtual
sequencer
Data item Proxy
struct sequencer
ML
UART SV-OCV sequencer APB e-OCV
stub UART
Rx agent DUT Slave
Tx agent Master
APB
Sequencer Sequencer
Monitor Monitor
UART
Driver Driver
3.2 Mixed-Language Sequences API

The following topics describe the mixed-language sequences API:
● “ml_proxy_seq_driver” on page 3-2

● “ml_uvm_sequencer_stub” on page 3-4
3.2.1 ml_proxy_seq_driver
A proxy sequence driver forwards sequences to the SystemVerilog UVM sequencer through the
sequencer stub with which it is associated. The ml_proxy_seq_driver unit, which is derived from
any_sequence_driver, is the base unit type for e proxy sequence drivers.

ml_proxy_seq_driver
Any do-item requests on a proxy sequencer are delegated to the SystemVerilog sequencer, while the e
side generates the items. You can execute items in the SystemVerilog sequencer from the e side by using
the do action, or the wait_for_grant(), deliver_item(), and wait_for_item_done() methods inherited
from any_sequence_driver. Grab requests are delegated to the SystemVerilog sequencer in the same
way.
Any do-sequence requests for sequence kinds that do not have a body() TCM are delegated to the
SystemVerilog sequencer after generation. However, do requests for sequence kinds that have a body()
are executed locally.
Note Both item and sequence types in e must be mapped to the corresponding SystemVerilog item
and sequence types.
When declaring a sequence for a mapped data item, you must use ml_proxy_seq_driver, or a unit type
derived from it, as a base for the sequence driver. Use the standard sequence statement with the
sequence_driver_type option. You must bind each instance of the proxy sequencer in e to the
corresponding sequencer stub in SystemVerilog by using the external_uvm_path() unit attribute. This
attribute specifies the SV-UVM component path for method port communication relative to the
containing unit.
For example:
sequence packet_seq using item=packet,
sequence_driver_type=ml_proxy_seq_driver;
unit my_uvc_wrapper_agent like uvm_agent {

driver : packet_seq_driver is instance;
// UVM path to SV sequencer stub relative to this agent’s UVM path:

keep driver.external_uvm_path() == "my_seqer_stub";
};
The ml_proxy_seq_driver unit contains the “update_item_after_done()” member.
3.2.1.1 update_item_after_done()
Purpose
User hook method to update the original item after its handling is done
Syntax
update_item_after_done(original: any_sequence_item, foreign: any_sequence_item)

ml_uvm_sequencer_stub
Parameters
original The original e item that was delivered by the current do request.
foreign The actual item that was sent to the SystemVerilog sequencer by the current
do request in its current state.
Description
This method is called automatically on a proxy sequence driver after an item is signaled as done in the
SystemVerilog sequencer, just before the do action unblocks. You can override or extend this method to
update field values from the current SystemVerilog item to the original item generated in e so, for
example, the BFM response data can be read from the item in the sequence right after the do action.
By default, this method is empty.
Example
extend packet_seq_driver {
update_item_after_done(original: any_sequence_item,
foreign: any_sequence_item) is also {
original.as_a(packet).data = foreign.as_a(packet).data;
};
};
3.2.2 ml_uvm_sequencer_stub
Purpose
Serve as a mediator between an e proxy sequence driver and a SystemVerilog sequencer
Description
A sequencer stub receives requests from an e proxy sequencer and delegates them to its assigned
sequencer. Its purpose is to encapsulate communications and data conversions. You must instantiate a
sequencer stub in SystemVerilog for each sequencer instance that will serve e sequences. You associate
the sequencer stub with an e proxy sequence driver by using the external_uvm_path() unit attribute in
e.
Use the SV package ml_uvm_seq that ships with the Specman installation to declare a sequencer
stub. To use it, you must add the following command-line options to your compilation flow, as
additional command-line arguments to irun or ncvlog:
setenv ML_SEQ_DIR `sn_root -home`/src
irun \
... \

${ML_SEQ_DIR}/ml_uvm_seq.sv \
-incdir ${ML_SEQ_DIR}
To introduce your own item preparation code, derive a new component class from
ml_uvm_sequencer_stub by overriding the prepare_item_to_send() hook method.
The ml_uvm_sequencer_stub class contains the following members:
● assign_sequencer() on page 3-5

● prepare_item_to_send() on page 3-6
3.2.2.1 Accessing the ml_uvm_seq Package

The SV package ml_uvm_seq used in the previous section ships with the Specman installation. To
use it, you must add the following command-line options to your compilation flow, as additional
command-line arguments to irun or ncvlog:
setenv ML_SEQ_DIR `sn_root -home`/src
irun \
... \
${ML_SEQ_DIR}/ml_uvm_seq.sv \
-incdir ${ML_SEQ_DIR}
3.2.2.2 assign_sequencer()
Purpose
Assign a sequencer to a sequencer stub
Syntax
void assign_sequencer(uvm_sequencer_base seqer);
Description
This method associates a sequencer, seqer, with a sequencer stub. It must be called before
end_of_elaboration, preferably during the build phase, otherwise an error is issued.
Example
The following example instantiates a sequencer and a user-defined sequencer stub side-by-side under an
env component.

class my_uvc_seqer_stub extends ml_uvm_seq::ml_uvm_sequencer_stub;

‘uvm_component_utils(my_uvc_sequer_stub)
...
endclass
class my_uvc_env extends uvm_env;

my_uvc_sequencer seqer;
my_uvc_seqer_stub seqer_stub;
‘uvm_component_utils(my_uvc_env)
virtual function void build();

super.build();
seqer = my_uvc_sequencer::type_id::create("seqer", this);
seqer_stub = my_uvc_seqer_stub::type_id::create("seqer_stub",this);
seqer_stub.assign_sequencer(seqer);
endfunction
endclass
3.2.2.3 prepare_item_to_send()
Purpose
User hook method to locally randomize the item and prepare it to be sent
Syntax
void prepare_item_to_send(inout uvm_sequence_item item);
Description
This virtual function is called automatically before an item is sent to the SystemVerilog sequencer. You
can override it in a subclass of ml_uvm_sequencer_stub to modify the item that was received from the
e proxy sequence driver. In particular, the item can be fully or partially randomized.
The parameter is declared inout to enable sending a different object than the one received from the e
side. In these cases, the new item must be created using the ‘uvm_create_on macro.
Example
class my_uvc_seqer_stub extends ml_uvm_seq::ml_uvm_sequencer_stub;
‘uvm_component_utils(my_uvc_seqer_stub)
virtual function void prepare_item_to_send(

inout uvm_sequence_item item);
packet p;

Limitations
assert($cast(p,item));
if (p.use_data == 1)
p.data.rand_mode(0); // Field randomization determined by flag
assert(p.randomize());
endfunction
endclass
3.2.3 Limitations
Features that are not supported in SystemVerilog cannot be supported by an e proxy sequence driver,
because it delegates all requests to the SystemVerilog sequencer. Features that are not supported by
SystemVerilog include the following:
● do API services—queue_item(), wait_for_next_grant(), and abort_do_request()

● Item-level is_relevant() callbacks
● rerun() of sequence drivers and units in general
Features that are not supported in e cannot be supported for multi-language sequences, because they are
not part of the e interface that programmers expect. These features include the following:
● Response routing
● Some arbitration schemes that are unique to SystemVerilog UVM
Some advanced features in e have analogous functionality in SystemVerilog, but are not supported for
multi-language sequences in the current release. These include the following:
● Sequence priorities
● Sequence-level is_relevant() callbacks
● Sequence stop() method
User-defined sequences on the e side are not registered in the SystemVerilog sequence library by the
sequencer. Therefore, they cannot be chosen randomly and invoked by SystemVerilog sequences.

4 Multi-Language UVM (ML-UVM)
Reference
This chapter documents irun invocation commands and utilities for multi-langue UVM, and contains:
● “ML-UVM irun Command Line Switches” on page 4-1

● “ML-UVM e Utilities” on page 4-5
● “ML-UVM SystemVerilog Utilities” on page 4-6
See Also
● Chapter 6 “mltypemap Utility: Automatic Generation of Data Types”
4.1 ML-UVM irun Command Line Switches

This section contains:
● -uvmtest on page 4-1

● -uvmtop on page 4-3
● -ml_uvm on page 4-4
4.1.1 -uvmtest
Purpose
Enable ML-UVM and declare a top test entity in a multi-language verification environment. Use this
option for the single topmost entity, which is the logical root of the entire multi-language hierarchy.

Multi-Language UVM (ML-UVM) Reference
-uvmtest
Category
Command line switch for irun and ncsim
Syntax
% irun -uvmtest [language:]entity-name ...
% ncsim -uvmtest [language:]entity-name ...
Description
Use this switch to declare the test, which is the logical root of the multi-language testbench hierarchy.
You can only specify one entity with the -uvmtest option, and it can be in any one of the supported
languages.
Use this option to specify either your e test file name, or SystemVerilog/SystemC test class. If your root
is a SystemVerilog test class, an instance of it is created with the name uvm_test_top, as in a pure
SystemVerilog testbench.
The command line switch takes an entity name consisting of a language identifier and an entity name.
The language identifier marks the language domain of the top entity. It can be one of the following:
● sv (or SV) for SystemVerilog

● e (or E) for e
● sc (or SC) for SystemC
The entity name can be one of the following:
● e test file name

● UVM SystemVerilog class name, representing a test (or another type derived from
uvm_component)
● SystemC class name
The following rules apply to the -uvmtest command line switch:
● Can be used only once in a command.

● You can omit the “e:” language identifier if you specify an e test file name with a .e suffix. If you
omit the language identifier and the name has no .e suffix, it is assumed to be a SystemVerilog class
name. You cannot omit the SC language identifier.
Cadence recommends that you always include a language identifier, for clarity and readability.
● The -uvmtest switch replaces the +UVM_TESTNAME switch in multi-language environments. It

is an error to use both -uvmtest and +UVM_TESTNAME in the same irun command line.

-uvmtop
● You cannot specify an e unit type name with -uvmtest. Only e test files are supported as top entities
in e.
● If you specify -uvmtest, the command line switches -uvm and -ml_uvm are turned on and need not
be specified explicitly.
Examples
● Naming an e test file as a top entity:
% irun -uvmtest e:my_test.e ...
● Naming an UVM SystemVerilog test class (similar to the pure UVM SystemVerilog
+UVM_TESTNAME switch) as a top entity:
% irun -uvmtest SV:my_test_class ...
● Naming two top entities — an e test and an UVM SystemVerilog env class:
% irun -uvmtest e:my_test.e \
-uvmtop SV:my_ethernet_env ...
4.1.2 -uvmtop
Purpose
Enable ML-UVM and declare a top entity in a multi-language verification environment. Use this option
to name entities which are top entities in their language domain, because their parent entity is in another
language domain.
Cadence recommends that you use the -uvmtest option and not -uvmtop to name the test - the root of the
logical testbench hierarchy. For more information see Section 4.1.1, “-uvmtest,” on page 4-1.
Category
Syntax
% irun -uvmtop [language:]entity-name ...
% ncsim -uvmtop [language:]entity-name ...

-ml_uvm
Description
Use this switch to declare a top entity in one of the language domains. To specify several top entities, use
this switch multiple times, each naming one of the entities. Each of the entities you name has a parent
entity in another language domain, and therefore is a top entity (no parent) in its own language domain.
This option should not be used for the root entity of the logical testbench hierarchy, where -uvmtest
should be used instead. For more information, see Section 4.1.1, “-uvmtest,” on page 4-1.
This command line switch takes an entity name consisting of a language identifier and an entity name,
as described in Section 4.1.1, “-uvmtest,” on page 4-1.
The following rules apply to the -uvmtop command line switch:
● The order of top entities as declared on the command line determines the order in which they are
created and built. Therefore, make sure to name the test as the very first top entity.
● You can omit the “e:” language identifier if you specify an e test file name with a .e suffix. If you
omit the language identifier and the name has no .e suffix, it is assumed to be a SystemVerilog class
name. You cannot omit the SC language identifier.
Cadence recommends that you always include a language identifier, for clarity and readability.
● You cannot specify an e unit type name with -uvmtop. Only e test files are supported as top entities
in e.
● If you specify -uvmtop, the command line switches -uvm and -ml_uvm are turned on and need not
be specified explicitly.
Examples
● Naming two top entities — an e test root and an UVM SystemVerilog env class:
% irun -uvmtest e:my_test.e \
-uvmtop SV:my_ethernet_env ...
4.1.3 -ml_uvm
Purpose
Enable the ML-UVM features.
Category

ML-UVM e Utilities
Syntax
% irun -ml_uvm ...
% ncsim -ml_uvm ...
Description
Use this switch to enable ML-UVM when no -uvmtop switch is used. This is useful in cases when you
have a top e layer where the e test file is being loaded by other means (for example through a TCL
command) and a SystemVerilog OVC that is instantiated by other means than an -uvmtop switch.
The following rules apply to the -ml_uvm switch:
● If you are using SystemVerilog components, you must have at least one import statement to import
the ml_uvm package in your SystemVerilog source:
import ml_uvm::*; // Required for ML-UVM
● When you specify the -ml_uvm command line switch, the -uvm switch is implicitly added, causing
irun to compile the UVM package that is included with your IES release.
4.2 ML-UVM e Utilities

● ml_uvm.connect_names() on page 4-5
4.2.1 ml_uvm.connect_names()
Purpose
Language-neutral connection of TLM ports in a multi-language environment.
Category
e method
Syntax
ml_uvm.connect_names(port_path: string,
export_path: string);

ML-UVM SystemVerilog Utilities
Parameters
port_path ML-UVM paths of a port to be connected in any of the supported languages.

Must be a full ML-UVM path, as defined in “ML-UVM External Path Strings”
on page 2-22.
export_path ML-UVM path of the export/implementation to be connected in any of the

supported languages. Must be a full ML-UVM path, as defined in “ML-UVM
External Path Strings” on page 2-22.
Description
Call this method in your e code during the connect_ports phase. It lets your e code connect any two
ports/implementations by their UVM path, regardless of the language domain where they are
implemented.
Note This function can connect only ports/implementations that were registered with ML-UVM. This
includes:
● e ports for which a bind(port, external) constraint was specified

● SystemVerilog ports/implementations for which ml_uvm::external_if() was called
● SystemC ports/exports for which ml_uvm::ml_uvm_register() was called
For more details on TLM ports in e, see “Using TLM Interface Ports” in the Specman Integrators Guide.
Example
extend my_env_unit {
ml_uvm.connect_names("tb.env0.monitor.packet_done_port",
"tb.scoreboard0.packet_done_export");
};
};
4.3 ML-UVM SystemVerilog Utilities

This section describes the utilities implemented in the UVM SystemVerilog class library that ships with
the IES release.
Note ML-UVM cannot be used with any of the open-source UVM SystemVerilog class library
versions.

ml_uvm::connect()
● ml_uvm::connect() on page 4-7

● ml_uvm::connect_names() on page 4-8
● ml_uvm::external_if() on page 4-9
4.3.1 ml_uvm::connect()
Purpose
Connect a SystemVerilog TLM port/implementation to another port/implementation named by its
ML-UVM path. The target port/implementation may be defined in any supported language.
Category
SystemVerilog function in the ml_uvm package
Syntax
package ml_uvm;
function void connect(uvm_if_base_abstract port_or_export,
string external_path,
string T1_name,
string T2_name = "");
Parameters
port_or_export Handle to the TLM port or implementation to be connected.
external_path ML-UVM path of the target port/implementation. Use a full ML-UVM path, as
defined in “ML-UVM External Path Strings” on page 2-22.
T1_name Type name of the transaction class passed by the port. This name must match
the transaction type in the port/implementation definition.
T2_name Type name of the second transaction type, when applicable (for example, in
uvm_transport_port). This name must match the second transaction type in the
port/implementation definition.

ml_uvm::connect_names()
Description
Use this function to connect a SystemVerilog TLM port/implementation to a matching
port/implementation named through its full ML-UVM path. The external_path argument can reference
any TLM port/implementation in any language supported by ML-UVM.
Note This external_path parameter can name only a port/implementation that was registered with
ML-UVM. This includes:
● e port for which a bind(port, external) constraint was specified

● SystemVerilog port/implementation for which ml_uvm::external_if() was called
● SystemC port/export for which ml_uvm::ml_uvm_register() was called
Example
import ml_uvm::*;

driver_c driver;
...
ml_uvm::connect(driver.burst_ip,
"sys.generator.burst_op",
"burst");
endfunction
endclass
4.3.2 ml_uvm::connect_names()
Purpose
Language-neutral connection of multi-language TLM ports/implementations.
Category
Syntax
package ml_uvm;
function void connect_names(string port_path,
string export_path);

ml_uvm::external_if()
Parameters
port_path ML-UVM paths of a port to be connected in any of the supported languages.

Must be a full ML-UVM path, as defined in “ML-UVM External Path Strings” on
page 2-22.
export_path ML-UVM path of the export/implementation to be connected in any of the

supported languages. Must be a full ML-UVM path, as defined in “ML-UVM
External Path Strings” on page 2-22.
Description
Use this function to connect any two ports by their UVM path, regardless of the language in which they
are implemented. This function is equivalent to the ml_uvm.connect_names() method in e, described in
“ml_uvm.connect_names()” on page 4-5.
Note This function can connect only ports/implementations that were registered with ML-UVM. This
includes:
● e ports for which a bind(port, external) constraint was specified

● SystemVerilog ports/implementations for which ml_uvm::external_if() was called
● SystemC ports/exports for which ml_uvm::ml_uvm_register() was called
Example
import ml_uvm::*;

...
ml_uvm::connect_names("tb.env0.monitor.packet_done_port",
"tb.scoreboard0.packet_done_export");
endfunction
endclass
4.3.3 ml_uvm::external_if()
Purpose
Register a SystemVerilog port or implementation with ML-UVM prior to connecting it. The
port/implementation can then be connected by logic in the same or another language domain.

ml_uvm::external_if()
Category
Syntax
package ml_uvm;
function void external_if (uvm_if_base_abstract port_or_export,
string T1_name,
string T2_name = "");
Parameters
port_or_export Handle to the TLM port or implementation to be registered with ML-UVM.
T1_name Type name of the transaction class passed by the port. This name must match
the transaction type in the port/implementation definition
T2_name Type name of the second transaction type, when applicable (for example, in
uvm_transport_port). This name must match the second transaction type in
the port/implementation definition.
Description
Call this function before or during the SystemVerilog connect phase to register ports and
implementations with ML-UVM. Once registered, connection logic in other language domains can
connect the port/implementation.
Example
import ml_uvm::*;
class driver_c extends uvm_driver;

...
uvm_put_imp #(burst, driver_c) burst_ip;

ml_uvm::external_if(burst_ip, "burst");
endfunction
endclass

5 UVM Interface Generator (UIG)
Reference
The UVM Interface Generator (UIG) is a utility that builds a UVM-compliant interface for a Universal
Verification Component (UVC). An UVM interface enables verification engineers to use the UVC in a
multi-language environment such as the one shown in Figure 5-1, where the top-level language (shown
in orange) is different from the language used to define the UVC (shown in light blue).
Figure 5-1 Multi-Language Verification Environment
Test
Scoreboard Module System Multi Channel Stimuli
UVM UVM
Monitor Stimuli Interface Interface Monitor Stimuli Monitor Stimuli
Monitor Stimuli
TLM TLM TLM TLM TLM
BFM BFM BFM TLM TLM
TBA TLM
Collector Driver Collector Driver Collector Driver Collector Driver
DUT
BUS HW
CPU USB
Mem Bridge Periph USB
You can use UIG to develop a class-based SystemVerilog (SV) interface to a UVC defined in e. Cadence
provides another utility – UIC (UVM Interface Customizer) to help you configure and tailor UIG to your

UVM Interface Generator (UIG) Reference
Overview of UIG Task Flow
specific e UVC. For a step-by-step description of how to do this, see Chapter 4, “SystemVerilog Class
Based over e”, in the UVM Mixed-Language Methodology.
New for 10.2

The OVM interface generator utility (OIG) was renamed to UVM interface generator (UIG) in 10.2.
UIG still supports OVM and is fully backward compatible with OIG, including the run script, .eexp file
format and all utility and configuration methods. This means that although many attributes and methods
are now using UVM and UIG in their names, their previous names (using OVM and OIG) also still exist,
and are still usable as before.
The default behavior of UIG in 10.2 is to create a UVM-SV interface, and not OVM-SV. To generate
OVM-SV code, add -lang OVM-SV to the run_uig.sh command line.
Statement of Support for UIG

This chapter outlines a methodology of using UIG to wrap e UVCs in SystemVerilog.
Please use the following email alias to provide feedback and get additional support:
uig_support@cadence.com
This chapter covers the following topics:
● “Overview of UIG Task Flow” on page 5-2

● “UIG Invocation” on page 5-5
● “e Export File” on page 5-8
● “Importing an e Export File for UVCs with Multiple Packages” on page 5-67
● “Dynamic e Configuration API” on page 5-71
See Also
● Chapter 4, “SystemVerilog Class Based over e”, in the UVM Mixed-Language Methodology.
5.1 Overview of UIG Task Flow

The Developer Task Flow
The UVM Interface Generator facilitates the tasks involved in developing an SV interface to an existing
UVC by creating much of the required code automatically. Figure 5-2 shows the files created by the
developer and those created by UIG.

Figure 5-2 Creation of a Mixed-Language UVC
developer-created files
export proxy UIG-created files

file UIG UVC
UVM UVC
adaptor
DUT
config
interface
file
dynamic
config svh
file files
internal
eVC +
e files
e glue
logic
To create a class-based SV interface for an existing UVC, you need to:
1. Install the UVM Interface Generator.
UIG is delivered as part of IES and consumes an IES license. It resides under
/specman-install-dir/specman/packages/uig.
2. Create an e export file.
The e export file identifies the components in the UVC that you want to make available to the SV
integrator and to end users to enable configuration of the UVC, the generation and driving of
stimuli, and connecting to the UVC monitors.
For every exported e component (env, agent, sequencer, monitor, and so on), UIG creates a proxy
UVM-compliant SV component (class). The proxy component contains tasks and functions that end
users can invoke to activate different capabilities in the UVC.
In the export file, you can also associate one or more DUT interfaces with a proxy component. For
each DUT interface, UIG creates a virtual interface handle of the exported interface type in the
proxy component class. The end users use the virtual interface handle to map ports in the UVC to
DUT signals.

3. Extend the UVC.
You must create e glue logic to enable interaction between the UVC components and the SV proxy
components.
For more information, see the SystemVerilog Class Based over e chapter of the UVM for
Multi-Language Environments document. This chapter provides a methodology overview of the
whole process, and points to a workshop in the following location with all the low-level details:
$SOCV_KIT_HOME/doc/kit_topics/uvm_mixed/sv_over_e/workshop
4. Configure Specman’s SystemVerilog adapter.
Specman’s SystemVerilog adapter provides mappings between e and all SystemVerilog integer data
types. UIG creates baseline mappings between e user-defined types and the corresponding SV
types. However, you can refine those mappings to specify, for example, that the names of the
enumerated values are the same in SV as they are in e.
5. Run UIG to generate the UVM SystemVerilog interface.
To facilitate analysis, UIG creates an HTML description of the generated interface.
6. Create a dynamic configuration file.
This e file is compiled by the end user and queries the UVM proxy environment at run time to
construct, connect and configure the topology of the UVC to reflect the UVM proxy environment.
7. [Optional] Create an SV sequence library.
An SV sequence library provides the end user with a UVM way of doing sequences. These
sequences also show users how to write their own SV UVM sequences.
8. Test the generated UVM interface in simulation.
To test the UVM interface, you have to create a simple SV environment, including an SVE
configuration file, a testbench, and a test.
9. Package the UVM UVC.
The final tasks include moving the UVM-related files into the appropriate subdirectories, if they are
not already there, and writing the user documentation.
Note Cadence recommends that you follow a gradual, iterative process, starting by exporting a small,
simple feature of the eVC and testing that feature in simulation. Then you gradually add other features
to the SV interface, testing each feature as it is developed. This iterative process is described in Chapter
5, “SystemVerilog Class Based over e”, in the UVM Mixed-Language Methodology manual in the
KITSOCV release.

UIG Invocation
End User Task Flow

Figure 5-3 shows the UVM UVC portion of the end user’s verification
Figure 5-3 End User Environment
SV
UVM
tests IES
SV
UVM
SVE
SV UVM user-created files

sequences
UVM UVC
UVM
UVC
The end user performs the following tasks:
1. Configure the UVM UVC topology and attributes.
2. Create an instance of the UVM proxy.
3. Create the SV verification environment that uses the UVM proxy.
4. (Optional) Customize sequence generation.
5. (Optional) Customize coverage, checkers and scoreboards.
6. Edit and run SystemVerilog tests.
5.2 UIG Invocation

The UVM Interface Generator is invoked using the run_uig.sh script. The script is located in
INCISIV-install-dir/SPMNnn/specman/packages/uig/bin.

UIG Invocation
5.2.1 run_uig.sh
Syntax
`sn_which.sh uig/bin/run_uig.sh`
e-UVC-top-files
adapter-config-file
-eexp export-file
[-lang UVM-SV | UVM11-SV | OVM-SV]
[-out base-prefix]
[-import export-file]
[-debug NONE | MEDIUM | FULL]
Syntax Example
`sn_which.sh uig/bin/run_uig.sh`
vr_axi_top.e
vr_axi_adapter_config.e
-eexp vr_axi.eexp
Parameters
e-UVC-top-files You must provide to UIG all the top-level file(s) of the e UVC
extensions you made for ML UVM as well as the original
top-level file(s) of the eVC.
See the Universal Verification Methodology (UVM) for

Mixed-Language Environments manual for more information on
these modifications.
adapter-config-file The name of the e file that configures Specman’s SystemVerilog

adapter. This file controls the mapping of e data types to SV data
types.
-eexp export-file The name of a Nested Text Format (NTF) file that controls and
configures the export of entities in an eVC to SV. The default file
extension is eexp.
[-lang UVM-SV] A case-insensitive keyword specifying the target HDL language:
● UVM-SV—creates UVM1.0ea-compliant code

● UVM11-SV—creates UVM1.1-compliant code
● OVM-SV—creates OVM-compliant code
The default is UVM-SV.

UIG Invocation
[-out base-prefix] The prefix for all generated files. The default is the UVC’s
package name. Use this flag only when you want the prefix of
the files to be different from the UVC’s package name.
Note To modify the UVC’s package name, use the

external_package_name export file attribute.
[-import export-file] Specifies the name of a Nested Text Format (NTF) file that
controls and configures the export to SV of entities in a
previously exported eVC. The default file extension is eexp. You
can use this option to reuse the components of a previously
exported eVC.
Note You must also provide the eVC’s source files to UIG
when using this option.
[-debug NONE|MEDIUM|FULL] Controls UIG’s verbosity. Starting in the 9.2 release, MEDIUM
and FULL have the same effect. The default is NONE.
Note Using this switch is intended for debugging only. Do

not use it for generating production quality code.
Description
Table 5-1shows the files generated by run_uig.sh. By default, the base_prefix is the UVC’s package
name, but you can modify the prefix with -out.
Table 5-1 Generated Files
File Description
base_prefix_classes_imp.svh This file contains the generated UVM proxy class

implementations.
base_prefix_dut_intf.svh This file contains the DUT interface definitions.
base_prefix_uvm.e These files contains internal e code. There is a separate e file

base_prefix_uvm_common.e for each e package from which components are exported.
base_prefix_uvm_package_name.e

e Export File
Table 5-1 Generated Files
File Description
base_prefix_classes.svh | The base_prefix_classes.svh file contains the generated UVM

proxy classes and ìncludes the exported data types, ports and
base_prefix_component_name.svh implementation files in a single SystemVerilog package.
Alternatively, if the create_file_per_class attribute is TRUE,

a separate base_prefix_component_name.svh file is created
for each exported component.
base_prefix_uvm_utilities.svh This file contains utility code.
base_prefix_uvm_sv.html This file documents the environment generated by UIG.
base_prefix_ports.svh This UVM stubs file contains code needed for

inter-operability between e and SV.
base_prefix_query.svh This file contains the SV coded needed for querying the UVM
component configuration from Specman.
base_prefix_top.sv This file must be loaded or compiled before simulation. It

includes all other files with the ìnclude directive.
base_prefix_types.svh This UVM stubs file contains the exported data type
definitions.
base_prefix_dut_intf_name.svh For each DUT interface defined in the export file, an

implementation file is created. This file contains the
interface’s internal implementation.
base_prefix_extensions.svh This file contains `defines that allow extending the interface
of the generated components.
5.3 e Export File

The e export file is a Nested Text Format (NTF) file that controls and configures the export of entities in
the eVC to SV. This file is a required input of the run_uig.sh script.
The e export file defines the exported entities in terms of attributes and elements. Attributes are defined
either at the top-level or inside an element. Elements can also contain other elements. Attributes and
elements are defined using the following syntax:
attribute-name : attribute-value;...
element-type element-name {
attribute-name : attribute-value;...

e Export File Syntax
element-type element-name {...};...

};...
This section covers the following topics related to the export file:
● “e Export File Syntax” on page 5-9

● “#include” on page 5-13
● “Top-Level Attributes” on page 5-14
● “UVM Component Element” on page 5-16
● “Sequence Element” on page 5-24
● “Item Element” on page 5-29
● “Method Elements” on page 5-35
● “Event Element” on page 5-39
● “Subcomponent Element” on page 5-43
● “DUT Interface Element” on page 5-47
● “Configuration Element” on page 5-49
● “Interface Element” on page 5-54
● “Signal Element” on page 5-60
● “Clocking Block Element” on page 5-63
● “Clocking Signal Element” on page 5-66
5.3.1 e Export File Syntax

#include <file-name>
import : <e-file-name>;
top_e_file[s] : <e-filename-list>;
load_after_build : <e-filename>;
external_package_name : <package-name>;
include_in_top_file : <file-name>;
include_in_package : <file-name>;
create_file_per_class : [FALSE, TRUE];
export_file : <export-file-name>;
uig_e_file[s] : <file-name-list>;
extend_type : <type-name>;
pre_declaration_code : <pre-declaration-code-string>;
post_declaration_code : <post-declaration-code-string>;
typedef_code : <typedef-code>;
<uvm_component_type> <unit-name> {
external_name : <uvm-component-type-name>;
comment : <description-of-component>;

extends : <unit-name>;
class_code : <class-code-string>;
build_code : <build-code-string>;
new_function_code : <new-function-code-string>;
connect_code : <connect-code-string>;
post_build_code : <post-build-code-string>;
control_active_passive : [FALSE, TRUE];
constrain_count : [TRUE, FALSE];
create_assign_vi : [TRUE, FALSE];
create_pointer_to_parent_config: [TRUE, FALSE];
use_ml_sequencer : [FALSE, TRUE];
external_package_name : <package-name>;
start_of_build_code : <start-of-build-code-string>;
end_of_build_code : <end-of-build-code-string>;
use_layering : [FALSE, TRUE];
sequence <sequence-name> {
comment : <description-of-sequence>;
in : <field-name[,field_name]*>;
inout : <field-name[,field_name]*>;
out : <field-name[,field_name]*>;
external_name : <foreign-language-method-name>;
create_sequence_class : [FALSE, TRUE];
use_ml_sequence : [FALSE, TRUE];
external_class_name : <foreign-language-class-name>;
in|out|inout <field-name> {
comment : <description-of-field>;
external_name : <external-name-of-field>;
is_rand : [TRUE, FALSE];
};
};
item <item-name> {
comment : <description-of-item>;
gen_method : <method-name>;
update_method : <method-name>;
sv_item : <item-type-name>;
interaction_mode : [PULL_MODE, PUSH_MODE];
send_method : <method-name>;
convert_e_item_method : <method-name>;
convert_external_item_method : <method-name>;
update_e_item_method : <method-name>;

update_external_item_method : <method-name>;
e_response_method : <method-name>;
external_response_method : <method-name>;
response_method : <method-name>;
external_type : <external-e-type-name>;
response_type : <e-response-type-name>;
use_response : [FALSE, TRUE];
update_after_gen : [TRUE, FALSE];
};
to_e_method <method-name> {
comment : <description-of-method>;
};
from_e_method <method-name> {
comment : <description-of-method>;
method_code : <method-code-string>;
create_analysis_port: [FALSE, TRUE];
analysis_port_name : <port-name>;
optimization_mode : [USER_DEFINED, NONE];
};
to_e_event <event-name> {
comment : <description-of-event>;
external_name : <foreign-language-event-name>;
data_method : <method_name>;
external_class_name: <event-class-name>;
};
from_e_event <event-name> {
comment : <description-of-event>;
external_name : <foreign-language-event-name>;
data_method : <method_name>;
external_class_name : <event-class-name>;
create_analysis_port: [FALSE, TRUE];
analysis_port_name : <port-name>;
optimization_mode : [USER_DEFINED, NONE];
data_transfer_mode : [USER_DEFINED, NONE];
};
subcomponent <field-name> {
comment : <description-of-subcomponent>;
external_name : <foreign-language-field-name>;
component_type : <exported-component-type-name>;
control_build : [FALSE, TRUE];

control_field : <foreign_field_name>;
control_value : <foreign_field_value>;
build_by_default: [FALSE, TRUE];
is_list : [FALSE, TRUE];
};
dut_interface <field-name> {
comment : <description-of-dut-interface>;
interface_type : <exported-interface-type-name>;
use_in_assign_vi : [TRUE, FALSE];
propagate_to_subcomponents: [TRUE, FALSE];
};
config <foreign-language-field-name> {
comment : <description dut interface>;
use_config_object : [FALSE, TRUE];
external_class_name : <uvm-class-type-name>;
include_fields : <struct-type_name.field_name>;
exclude_fields : <struct-type_name.field_name>;
default : [FALSE, TRUE];
create_default_object : [FALSE, TRUE];
field_name_in_parent_config: <field_name>;
field <field-name> {
comment : <description-of-field>;
external_name: <foreign-language-field-name>;
e_type : <e-type>;
external_type: <external-type>;
external_kind: <external-kind>;
default_value: <value>;
is_rand : [FALSE, TRUE];
is_static : [FALSE, TRUE];
is_listL : [FALSE, TRUE];
};
};
};
interface <unit-name> {
comment : <description-of-interface>;
external_name : <foreign-language-interface-name>;
interface_code : <interface-code-string>;
include_signals : <port-name>;
deep_include_signals : <port-name>;

#include
exclude_signals : <port-name>;
external_package_name : <foreign-language-package-name>;
pre_declaration_code : <pre-declaration-code-string>;
post_declaration_code : <post-declaration-code-string>;
signal_code : <signal-code-string>;
implementation_code : <implementation-code-string>;
signal <port-name> {
comment : <description-of-signal>;
external_name : <foreign-language-signal-name>;
net_type : <net-type-name>;
data_type : <data-type-name>;
signal_size : <signal-size-string>;
list_size : <list-size>;
create_as_port : [FALSE, TRUE];
signal_kind : [DRIVER, VERILOG_WIRE];
port_direction : [INOUT,INPUT,OUTPUT];
initial_value : <initial-value>;
create_as_packed_array: [FALSE, TRUE];
create_array : [TRUE, FALSE];
list_delimiter : <delimiter>;
};
clocking_block <clocking-block-name> {
comment : <description of clocking block>;
external_name : <foreign-language-clocking-block-name>;
default : [FALSE, TRUE];
clocking_event : <clocking-event>;
default_sampling_skew: <skew>;
default_driving_skew : <skew>;
clocking_code : <clocking-block-code-string>;
include_signals : <unit-name>.<port-name>;
exclude_signals : <unit-name>.<port-name>;
clocking_signal <port-name> {
comment : <description-of-signal>;
external_name: <foreign-language-signal-name>;
sampling_skew: <skew>;
driving_skew : <skew>;
direction : [INOUT, INPUT, OUTPUT];
};
};
};
5.3.2 #include
An e export file can include other e export files using an #include statement:

Top-Level Attributes
#include <file-name>
Notes
● There is no semi-colon in the end of the #include statement.
● This directive can be used on any line in the file.
● UIG uses $SPECMAN_PATH when searching for the file.
5.3.3 Top-Level Attributes

Table 5-2 shows the attributes that you can define at the top-level of an e export file, outside of any
element.
Table 5-2 Top-Level Attributes
Syntax Value Description
create_file_per_class: If FALSE (the default), one file is created for all generated component class
bool definitions. If TRUE, each component class is generated in its own file.

Top-Level Attributes
top_e_file: filename-list | Specifies one or more e files that the end user must compile or load for
top_e_files: filename-list simulation, typically:
● The top file for the UVC

● The e file generated by UIG (e_uvc_uvm.e)
● The top file that imports any UVM-specific extensions to the UVC.
● The dynamic configuration file
For each top_e_file attribute, UIG creates a pragma directive in the

base_prefix_top.sv file to instruct irun to load or compile the specified files.
For example, given the following top_e_file attribute:
top_e_file: vr_usb/e/api/sv/generated_api/vr_usb_uvm.e \
vr_usb/e/api/sv/vr_usb_uvm_top.e; \
vr_usb/e/vr_usb_adapter_config.e
UIG adds the following pragma to vr_usb_top.sv:

//pragma uig_irun top_e_files = \
vr_usb/e/api/sv/generated_api/vr_usb_uvm.e \
vr_usb/e/api/sv/vr_usb_uvm_top.e \
vr_usb/e/vr_usb_adapter_config.e
Notes
● You must use this attribute to specify the base_prefix_uvm.e file that is
generated by UIG.
● You can use the import attribute to import all the required files from
base_prefix_uvm.e and then specify only base_prefix_uvm.e in
top_e_files.
● Do not use this attribute for the dynamic configuration file if it has any
define-as-computed macros that rely on information from
SystemVerilog. Instead, use the load_after_build attribute.
import: e-filename The name of an e file to be imported by the base_prefix_uvm.e file generated
by UIG.
load_after_build: The name of an e file to be loaded after the SV build phase is done. You can
e-filename use this attribute to load e files with define-as-computed macros that rely on
information from the SV side.
external_package_name: The name of the SV package to contain the exported entities. The default is
package-name the UVC’s package name.

UVM Component Element
include_in_top_file: The name of a file to be included in the generated SV top file,

filename e_uvc_name_top.sv.
include_in_package: The name of a file to be included in the generated package.

filename
uig_e_file: filename | A list of all the e pathnames needed by UIG to generate the UVC, in other
uig_e_files: filename-list words, a list of the pathnames of all the e files that must be passed to the UIG
run script. The path of the files must be relative to the root of the UVC, for
example:
my_uvc/e/api/sv/my_uvc_uvm_top.e
my_uvc/e/api/sv/my_uvc_adapter_config.e
Note This attribute is required.
export_file: filename The pathname of the e export file. The pathname must be relative to the root
of the UVC, for example:
my_uvc/misc/my_uvc_uvm_sv.eexp
export_type: type-name If you are extending a type that has previously been exported and that type is
not explicitly mentioned in the .eexp file or in the imported eexp file, you
must specify its typename here.
typedef_code: code Specifies code to be added to the typedef area of the UVC package.
post_declaration_code: Specifies code to be added after all other declarations in the generated UVC
code package.
pre_declaration_code: Specifies code to be added before any other declarations in the generated
code UVC package.
5.3.4 UVM Component Element
Purpose
Define a exported component

Context
Top-level (not within any other element)
Syntax
uvm-component-type e-unit-name {
attribute | element;...
};
Syntax Example
monitor vr_axi_agent_monitor {
//The name of class type in SV
external_name : vr_axi_agent_monitor;
...
};
Parameters
uvm-component-type Determines what kind of UVM component is generated from the e unit. It must be
one of the following:
component Is the base type for all UVM components.
env Is the base type for UVM environments. Environments

usually contain agents as subcomponents.
agent Is the base type for UVM agents. Agents usually contain
three subcomponents:
● sequencer
● driver
● monitor
driver Is the base type for UVM drivers.
monitor Is the base type for UVM monitors.
sequencer Is the base type for UVM sequencers and can be used to
export an e unit derived from any_sequence_driver.
virtual_sequencer Is the base type for UVM virtual sequencers and can be
used to export an e unit derived from
any_sequence_driver.

e-unit-name The name of the exported e unit or when subtype. If the name includes special
characters, it must be enclosed in quotes. For example:
env "SV_IC'sv_type vr_axi_env" {...};
attribute See Table 5-3 on page 5-19.
element An UVM component element can contain the following kinds of elements:
● method elements
● event elements
● subcomponent elements
● dut_interface elements
● config elements
Note sequence elements and item elements can only be contained in
sequencer elements
Description
UIG creates a proxy UVM class for every exported component. This class contains tasks and functions
that end users can invoke to activate different capabilities in the eVC.
You can export a component as any one of the following uvm_component types:
● uvm_env
● uvm_agent
● uvm_sequencer
● uvm_driver
● uvm_monitor
Note Different export file attributes and elements are associated with each uvm_component type.
See “Example 1” on page 5-21 and following for examples of exporting various types of UVM
components.

Element Attributes
Table 5-3 UVM Component Element Attributes
external_name: Specifies the name of the exported component in SV. For example:
uvm-component-type-name
comment: component-description Free text within double quotes that defines text to be added as a
comment to the generated code. You can use the <text></text>
tags for multiple lines. For example:
comment: <text>Collects the transfers/bursts,
then emits events on the status of traffic to
and from the DUT</text>;
extends: unit-name Specifies that this exported component inherits from the specified
unit in the foreign language. The specified unit must be a supertype
of the exported component in e. Inheriting components cannot
override/extend any constructs already exported in the supertype,
except for from_e_method. The supertype can be declared in an
imported eexp file.
class_code: string Inserts additional code into the exported class. Use the <text>
</text> tags to insert multiple lines of code.
build_code: string Inserts additional code at the end of the component’s build
function. Use the <text> </text> tags to insert multiple lines of
code.
new_function_code: string Inserts additional code at the end of the component’s new function.
Use the <text> </text> tags to insert multiple lines of code.
connect_code: string Inserts additional code at the end of the component’s connect
code.
post_build_code: string Inserts additional code at the end of the component’s post_build
code.
control_active_passive: bool When TRUE (the default for agents), a field called is_active is
automatically created in the component. You can use the value
assigned to the field by users to control the active/passive attribute
of the e agent unit. When FALSE, this field is not created.

constrain_count: bool If TRUE (the default), UIG adds the constraint “keep soft count
==0”, and no sequences are generated unless the end user
over-rides this constraint. If FALSE, no constraint is added, and the
default sequence is generated.
Note This attribute is for sequencer components only.
create_pointer_to_parent_config: When TRUE (the default), a pointer to the component’s parent

bool configuration object is created. The pointer is set to the parent’s
object in the component’s build function. When FALSE, this
pointer is not created.
external_package_name: The name of the SV package to contain the exported entities. The
package-name default is the UVC’s package name.
use_ml_sequencer: bool Specifies whether this sequencer uses the 9.2 multi-language
sequence API or the 8.2 sequence model. For further information,
see “9.2 Multi-Language Sequence Use Model” on page 5-31 or see
the migration guide available here:
$SOCV_KIT_HOME/doc/kit_topics/uvm_mixed/sv_over_e/new_s
equence_model_92ml.pdf.
start_of_build_code: string Inserts additional code at the start or end of the component’s build
end_of_build_code: string function.
use_layering: bool Specifies whether this sequencer uses the layering facilities
enabled by the 9.2 multi-language sequence API. Setting this to
TRUE might require the implementation of additional conversion
methods.
For more information and examples on multi-language sequences,

see “9.2 Multi-Language Sequence Use Model” on page 5-31 or see
the migration guide available here:
$SOCV_KIT_HOME/doc/kit_topics/uvm_mixed/sv_over_e/new_s
equence_model_92ml.pdf.

create_assign_vi: bool When TRUE (the default), a function called “assign_vi” is created
in the component. This function handles the DUT interface
connections for all DUT interfaces declared in the component.
When FALSE, no function is created. You might want to set this
attribute to FALSE if, for example, you have several DUT
interfaces in a component and want to have a different function for
setting each one. In this case, you can add your own function using
class_code.
Example 1 Exporting an Environment

env "SV_IF'sv_type vr_axi_env" {
external_name: vr_axi_if_env;
subcomponent master {
component_type: vr_axi_master;
is_list: FALSE;
};
subcomponent slave {
component_type: vr_axi_slave;
is_list: FALSE;
};
};
Example 2 Exporting an Agent

agent "PASSIVE'active_passive vr_axi_interconnect" {
external_name: vr_axi_interconnect_agent;
config cfg {
include_fields : vr_axi_interconnect_config.*;
use_config_object : TRUE;
};
subcomponent slave_input_ports {
component_type: vr_axi_slave;
is_list: TRUE;
};
subcomponent master_output_ports {
component_type: vr_axi_master;

is_list: TRUE;
};
from_e_method convert_id_tag{};
};
Example 3 Exporting a Driver

driver vr_axi_slave_bfm {
external_name: vr_axi_slave_driver;
to_e_method is_bfm_empty {};

from_e_method sv_user_choose_next_bus_signals{};
to_e_method enable_user_override_signal{};
to_e_method disable_user_override_signal{};
};
Example 4 Exporting a Sequencer

sequencer vr_axi_master_driver {
// The name of class type in SV

external_name: vr_axi_master_sequencer;
constrain_count: FALSE;
// SV sequence item definition

// vr_axi_master_driven_burst is the e sequence item
// vr_axi_master_burst is the SV sequence item
item vr_axi_master_driven_burst {
sv_item: vr_axi_master_burst;
};
//////////////////////////////////////////////////////////
// Events to be exported to SV //
//////////////////////////////////////////////////////////
from_e_event sv_burst_ended {
comment : "Emitted when a burst ends on the sequencer";
data_method: get_ended_sv_burst;
external_name: master_burst_ended;
};
//////////////////////////////////////////////////////////
// Exported methods to be used in SV is_relevant //
//////////////////////////////////////////////////////////
to_e_method can_send_read_burst {};

to_e_method can_send_write_burst {};

to_e_method can_start_exclusive_seq_for_id_tag {};
//////////////////////////////////////////////////////////
// Exported sequences (mapped sequence) //
//////////////////////////////////////////////////////////
sequence API_READ {
in : address;
in : burst_kind;
in : length;
in : size;
out : read_memory;
external_name : read;
comment: <text>This task sends read burst with default parameters.
The task returns once the read burst has ended and updates
the read data. Only normal access is supported</text>;
};
...
//////////////////////////////////////////////////////////
// dut interface of master driver (pointer to signals) //
//////////////////////////////////////////////////////////
dut_interface vr_axi_signal_interface {
interface_type:vr_axi_master_signal_map ;
};
};
Example 5 Exporting a Monitor

monitor vr_axi_agent_monitor {
//The name of class type in SV

//////////////////////////////////////////////////////////
// Events to be exported to SV //
//////////////////////////////////////////////////////////
from_e_event read_burst_started {
comment : "Emitted on read burst start";
data_method: get_started_read_burst_info;
};
from_e_event write_burst_started {
comment : "Emitted on write burst start";
data_method: get_started_write_burst_info;

Sequence Element
};
...
//////////////////////////////////////////////////////////
// Methods exported to SV //
//////////////////////////////////////////////////////////
to_e_method write_memory{};
//////////////////////////////////////////////////////////
// dut interface in the monitor (pointer to signals) //
//////////////////////////////////////////////////////////
};
};
5.3.5 Sequence Element
Purpose
Defines the sequence types for which the UVM interface is built
Context
Only allowed within a sequencer element
Syntax
sequence sequence-name {
attribute;...
};
Syntax Example
sequence API_READ {
in : address;
in : burst_kind;
in : length;
in : size {
external_name: real_size;
};

Sequence Element
out : read_memory;
external_name : read;
comment: <text>This task sends a read burst with default parameters;
The task returns once the read burst has ended,
and updates the read data;
Only normal access is supported;</text>;
};
Parameters
sequence-name The name of the sequence, in other words, the when subtype that defines the
exported sequence. For example:
sequence RANDOM {...};
element The sequence element can contain an in|inout|out field element.
Description
For every exported sequence, a task is created in the sequencer component class.
● The task name is the external_name, if defined. Otherwise, it is the sequence name.
● The parameters of the tasks reflect the fields in the e export file. For an input field, there is an input
parameter. For an output field, there is an output parameter.
● The names of the parameters reflect the names of the fields.
● The types of the parameters are the SystemVerilog equivalent types of the corresponding e types.
● The order of the parameters reflects the order of the field declarations in the e export file.
● A maximum of 14 fields is currently allowed per exported sequence.
● When this task is called, it causes a do action for the sequence that is constrained using the given
parameters. When returning from the task, the output parameters have the value of the fields in the
sequence struct, as they were when the do action was terminated.
If the create_sequence_class attribute is TRUE, a class deriving from uvm_sequence is also created.
● The class name is the external_name, if defined. Otherwise, it is the sequence name.
● The fields of the class reflect the fields in the export file.
● The names of the class fields reflect the names of the fields in the eexp file.
● The types of the fields are the SystemVerilog equivalent types of the corresponding e types.
● The sequence is registered automatically with the sequencer.

Sequence Element
● The body() task of the sequence calls the sequencer task that is created in the sequencer component
class (as explained above).
In 9.2, UIG enables the use of the multi-language sequence API. If you used the use_ml_sequencer
attribute, a sequence class is created by default for this sequence, since this is mandatory for multi
language sequences.
For more information and examples on multi-language sequences, see “9.2 Multi-Language Sequence
Use Model” on page 5-31 or New Sequence Model.

Sequence Element
Element Attributes
Table 5-4 Sequence Element Attributes
external_name: sequence-name Specifies the name of the exported sequence in SV.
comment: sequence-description Free text within double quotes that defines text to be added as a
tags for multiple lines.
in: field-name-list A comma-separated list of the names of the fields that are used to
constrain the entity. These fields must be generatable.
Multiple in attributes are allowed. For example, the following

in : address;
in : burst_kind;
is equivalent to
in : address, burst_kind;
Note These fields become the parameters of the generated SV
task and the fields of the generated class.
out: field-name-list A comma-separated list of the names of the fields that are to be
returned after the do action is executed. For example:
out : read_memory;
inout: field-name-list A comma-separated list of the names of the fields that are used to
constrain the entity and that are to be returned after the do action
is executed.
class_code: string Inserts additional code into the class of the exported entity. Use the
<text> </text> tags to insert multiple lines of code.
use_ml_sequence: bool If TRUE, specifies that this sequence must be used with the 9.2
multi-language sequence API. Valid only if use_ml_sequencer is
set to TRUE in the containing sequencer component.
The default is FALSE.

in|inout|out Field Element
Table 5-4 Sequence Element Attributes
create_sequence_class: bool If FALSE (the default), a task in the sequencer component class is
created for each exported sequence. If TRUE, UIG generates a
SystemVerilog class that represents the sequence, similar to pure
UVM SystemVerilog sequences.
Notes
● If use_ml_sequence is set to TRUE, create_sequence_class
is also TRUE by default.
● Cadence recommends specifying a TRUE value for the
create_sequence_class attribute. If you do not enable this
attribute, UIG only places a task in the sequencer that
represents the sequence. Tasks can be easily called by end
users, but they cannot be invoked with the ‘uvm_do or
‘uvm_do_with macro.
external_class_name: string Specifies the name of the generated sequence class, if

create_sequence_class is set to TRUE.
5.3.6 in|inout|out Field Element
Purpose
Define a field that constrains or is returned by a sequence
Context
Within a sequence element
Syntax
in|inout|out : field-name {
attribute;...
};
Syntax Example
in : size {
external_name: real_size;

Item Element
is_rand: TRUE;
};
Parameters
field-name The name of the field that constrains or is to be returned by the sequence element.
attribute See Table 5-15.
element The field element cannot contain any other elements.
Description
You can use this element to specify the names of the fields that are used to constrain the entity and/or
that are to be returned after the do action is executed.
Element Attributes
Table 5-5 Field Element Attributes
external_name: name Specifies the name of the field in SV.
comment: field-description Free text within double quotes that defines text to be added as a
is_rand: bool If TRUE, the field is created as a generatable field. The default is
FALSE.
5.3.7 Item Element
Purpose
Defines the data type that is constrained and sent by the sequencer
Context
Only allowed within a sequencer element

Item Element
Syntax
item type-name{
attribute;...
};
Syntax Example
item vr_axi_slave_driven_burst_response {
sv_item: vr_axi_slave_burst_response;
};
Parameters
type-name The name of the exported e type.
Note Only one item element may be exported per sequencer.
element The item element cannot contain any other elements.
Description
You can declare only one item element for an exported sequencer component.
8.2 Sequence Use Model

Note The 8.2 sequence use model is deprecated and will be removed in a future release.
When an item element is declared, UIG creates infrastructure for synchronizing the UVM sequencer
with the e sequencer. The e sequencer runs a special sequence that listens for do actions on the UVM
side, and pulls these items.
Generation can be performed twice:
● During the do action on the UVM side

● During late generation on the Specman side
If you are using the PULL_MODE interaction mode, you must provide a method for checking and
generating an e item according to a UVM item, as well as a method for updating the UVM item
according the e item. These methods must be defined in the sequence struct. UIG looks for these
methods with the names specified by the gen_method and update_method attributes.
If you are using the PUSH_MODE interaction mode, you must provide a method that gets an SV item as
a parameter, checks it for validity, generates a corresponding e item and sends it to the e driver. UIG
looks for this method with the name specified by the send_method attribute.

Item Element
The item exported into SV and the e item most likely have to be two different e types. In this case the
exported item has to be the actual e item, and the SV item has to be specified in the e export file using
the attribute sv_item.
The exported item is automatically generated as deriving from uvm_sequence_item, with all the
relevant field macros and the correct new function.
You can control how the item is exported using the adapter unit configuration.
9.2 Multi-Language Sequence Use Model
In 9.2, UIG enables the usage of the multi-language sequence API. It enables true SystemVerilog
sequencer proxy because the generated proxy does not maintain its own do queue. Instead, the proxy
delegates all calls to e sequence drivers. It removes multiple current limitations, including the layering
of sequencers, grab/ungrab across-languages, and delicate timing issues in pipelined protocols.
Using the multi-language sequence API requires you to define and implement several conversion
methods in the exported sequence driver. These methods are used to pass data (request and response
items) between the languages. The following attributes control the names of the conversion methods:
● convert_e_item_method specifies the method used to convert the e representation of the external
item to the e item type. The default signature of this method is:
gen_e_from_sv_item(sv_item: <sv-item-type>) : <e-item-type>;
● convert_external_item_method specifies the method used to convert the e item to the e
representation of the external item type. The default signature of this method is:
gen_sv_from_e_item(sv_item: <e-item-type>) : <sv-item-type>;
● update_e_item_method is used in layered protocols and specifies the method used to update the e
item according to the changes made in the foreign language. The default signature of this method is:
update_e_from_sv_item(e_item: <e-item-type>, sv_item: <sv-item-type>);
● update_external_item_method specifies the method used to update the e representation of the
external item according to the generation made in Specman. The default signature of this method is:
update_sv_from_e_item(sv_item: <sv-item-type>, e_item: <e-item-type>);
● external_response_method specifies the method used to convert the e response to the external
response type. Only needed if the use_response attribute is specified. The default signature of this
method is:
gen_sv_from_e_response(e_response: <e-response-type>) :
<sv-response-type>);
For further information, see “Example Conversion Methods” on page 5-34.

Item Element
Element Attributes
Table 5-6 Item Element Attributes (8.2 Use Model)
comment: item-description Free text within double quotes that defines text to be added as a
class_code: class-code-string Inserts additional code into the class of the exported entity. Use the
interaction_mode: mode The mode of interaction between the e sequencer and driver.
Possible values are PULL_MODE and PUSH_MODE. The
default is PULL_MODE.
Note PUSH_MODE is a feature of eRM that is not widely

used. It is not supported explicitly by UVM, but you can require
UIG to generate SV code that emulates PUSH_MODE, if your
UVC requires it.
external_name: name Specifies the name of the exported item type in SV.
sv_item: type-name The name of an e struct that represents the SV data item. For
example:
send_method: name The name of a method defined in the e sequencer unit that gets an
SV item as a parameter, checks it for validity, generates a
corresponding e item and sends it to the e driver. Valid only for
PUSH_MODE. The default is send_item().
gen_method: name The name of a method defined in the e sequence struct that gets an
SV item as a parameter, checks it for validity and returns a
generated e item. Valid only for PULL_MODE. The default is
gen_e_from_sv_item().
update_method: name The name of a method defined in the e sequence struct that gets an
e item as a parameter, and returns an SV item. Valid only for
PULL_MODE. The default is update_sv_from_e_item().

Item Element
Table 5-7 Item Element Attributes (9.2 Multi-Language Use Model)
comment: item-description Free text within double quotes that defines text to be added as a
class_code: class-code-string Inserts additional code into the class of the exported entity. Use the
interaction_mode: mode The mode of interaction between the e sequencer and driver.
Possible values are PULL_MODE and PUSH_MODE. The
default is PULL_MODE.
Note PUSH_MODE is a feature of eRM that is not widely

used. It is not supported explicitly by UVM, but you can require
UIG to generate SV code that emulates PUSH_MODE, if your
UVC requires it.
external_name: name Specifies the name of the exported item type in SV.
sv_item: type-name The name of an e struct that represents the SV data item. For
example:
send_method: name The name of a method defined in the e sequencer unit that gets an
SV item as a parameter, checks it for validity, generates a
corresponding e item and sends it to the e driver. Valid only for
PUSH_MODE. The default is send_item().
convert_external_item_method The name of a sequencer method that converts the e representation

: method-name of the external item type to the e item.
convert_e_item_method: The name of a sequencer method that converts the e item type to
method-name the e representation of the external item.
external_response_method: The name of a sequencer method that handles the external

method-name response.
e_response_method: The name of a sequencer method that handles the e response.

method-name
update_external_item_method: The name of a sequencer method that updates the e representation

method-name of the external item according to the e item.

Item Element
Table 5-7 Item Element Attributes (9.2 Multi-Language Use Model)
update_e_item_method: The name of a sequencer method that updates the e item according
method-name to the e representation of the external item.
update_after_gen: bool Indicates whether to update the foreign language item after
generation is done on the e side.
Note Any BFM manipulation performed on the item is not

propagated. To return the item with the BFM changes, use the
response mechanism.
use_response: bool Specifies whether to return a response when the item is done.
response_type: e-type Specifies the type of the response, if it differs from the item type.
external_type: type The name of an e struct that represents the SV data item. For
example:
external_type: vr_axi_slave_burst_response;
Example Conversion Methods

The following are very simple implementations of two of the conversion methods. It is likely that you
have to manipulate the objects more than is shown here.
gen _e_from_sv_item(sv_item: vr_axi_master_burst) :
vr_axi_master_driven_burst is {
if (sv_item != NULL) {
gen result keeping {
it.data = sv_item.data;
it.address = sv_item.address;
};
};
};
update_sv_from_e_item(sv_item: vr_axi_mater_burst, e_item:

vr_axi_master_driven_burst) is {
if (e_item != NULL) {
sv_item.address = e_item.address;
sv_item.data = e_item.data;
};
};
For further information on migrating to the 9.2 use model, see the migration guide available here:
$SOCV_KIT_HOME/doc/kit_topics/uvm_mixed/sv_over_e/new_sequence_model_92ml.pdf.

Method Elements
5.3.8 Method Elements

Method elements define a regular e method or a TCM to be exported:
● to_e_method on page 5-35 defines an e method to be called from SV

● from_e_method on page 5-36 defines an empty hookup method in SV that is called after the specified
e method executes
See Also
5.3.8.1 to_e_method
Purpose
Define a regular e method or TCM to be called from SV
Context
Within any UVM component element
Syntax
to_e_method method-name {
attribute;...
};
Syntax Example
to_e_method *_write_* {
external_name : xbus_$1_write_to_$2;
};
Parameters
method-name The name of the e method as defined in e. Wildcards are allowed. The
external_name can use $1 ($2, $3, …) to refer to the wildcards.

Method Elements
element The to_e_method element cannot contain any other elements.
Description
For every to_e_method element, a task or a function is created:
● If the e method is a TCM, it is a task.

● If the e method is non-time-consuming, it is a function.
● The parameters of the task or function are the same as those of the method in e.
● The names of the parameters are the same as in e.
● The types of the parameters are the SV equivalent types of the corresponding e types.
● When users call the task or function, the corresponding method in e is invoked. (This is similar to
input method ports.)
Element Attributes
Table 5-8 To e Method Element Attributes
external_name: method-name Specifies the name of the exported method in SV. If not specified,
the e name is used.
comment: method-description Free text within double quotes that defines text to be added as a
5.3.8.2 from_e_method
Purpose
Define an empty hookup method in SV that is called after the specified e method executes
Context

Method Elements
Syntax
from_e_method method-name {
attribute;...
};
Syntax Example
from_e_method *_read_* {
external_name : xbus_$1_read_from_$2;
};
Parameters
method-name The name of the e method as defined in e. Wildcards are allowed. The
element The from_e_method element cannot contain any other elements.
Description
When the e export file defines a from_e_method element, a callback is created. A callback is
function/task that is called at the end of execution of the e method.
● If the e method is a TCM, the callback is a task.

● If the e method is non-time-consuming, the callback is a function.
● The parameters of the task or function are the same as those of the method in e.
● The names of the parameters are the same as in e.
● The types of the parameters are the SV equivalent types of the corresponding e types.
● The default implementation of the created tasks/functions is just to return.
● You can add your own implementation to the callback using the method_code attribute.
● You can use the create_analysis_port attribute to create an analysis port based on the exported
method. In this case the method must return no value and take a struct configured to derive from
uvm_object as a parameter. Every time the method is called, the analysis port calls its write function
with the object passed as a parameter to the method.
● By default, UIG creates a configuration field per method for controlling the exported callback. The
UVC user can use the configuration field to disable the callback and improve performance. You can
prevent the creation of this field by setting the optimization_mode attribute to NONE.

Method Elements
Element Attributes
Table 5-9 From e Method Element Attributes
external_name: method-name Specifies the name of the exported method in SV. If not specified,
the e name is used.
method_code: string Defines SV code to be added to the SV method. Use the <text>
create_analysis_port: bool Creates an analysis port based on the exported method.
analysis_port_name: name The name of the created analysis port, implying that the
create_analysis_port attribute is set to TRUE.
Analysis ports allow a component (such as a monitor) to produce

a stream of transactions regardless of whether there is a target
actually connected to it. Modular analysis components (such as
scoreboards) are then connected to the analysis port, and each
analysis component processes the transaction stream in a particular
way. For more information, search for “Analysis Communication”
in the UVM User Guide.
optimization_mode: If USER-DEFINED (the default), creates configuration field for

[USER-DEFINED, NONE] each method to enable control of the exported callback. The UVC
user can use the configuration field to disable the callback and
improve performance. If NONE, the configuration field is not
created and the user cannot disable the callback.
Example 1
To add code to the empty hookup method created for the from_e_method, enter the code between
<text></text> markers in a method_code attribute. At the end of the execution of my_from_e_method,
the SV code defined in the method_code attribute is executed. For example:
agent my_agent {
...
from_e_method my_from_e_method {
external_name: my_from_e_method;
method_code:
<text>`message(UVM_LOW, "[%m] in my_from_e_method... ");

Event Element
</text>;
};
};
5.3.9 Event Element

Event elements export events to e from SV or from e to SV:
● to_e_event on page 5-39 creates an e event that is triggered by an SV event

● from_e_event on page 5-41 creates an SV event that is triggered by an e event
See Also
5.3.9.1 to_e_event
Purpose
Create an e event that is triggered by an SV event
Context
Syntax
to_e_event event-name {
attribute;...
};
Syntax Example
to_e_event reset_done {
external_name : report_reset_to_e_uvc;
};

Event Element
Parameters
event-name The name of the e event to be defined. Wildcards are allowed. The external_name
can use $1 ($2, $3, …) to refer to the wildcards.
element The to_e_event element cannot contain any other elements.
Description
For every event in the e export file, a corresponding UVM event class (uvm_event) is created, and an
object of this event type is created in the exported component. The event object name is the
external_name, if it is defined. Otherwise, it is the e event name. The event class name is the
external_class_name, if it is defined, or the name of the object with _event appended.
For to_e_event element, an e event is emitted each time the SystemVerilog event is triggered.
For each event, a task emit_event_name is created in the exported component. These tasks are used by
Specman and by the UVM event class, and should not be used directly by the user. The UVM library
documentation defines the API that users can use to interact with the event.
Element Attributes
Table 5-10 To e Event Element Attributes
external_name: event-name Specifies the name of the triggering event in SV. If not specified,
the e event-name is used.
comment: event-description Free text within double quotes that defines text to be added as a
external_class_name: The SV name of the generated class for the event.

class-name

Event Element
5.3.9.2 from_e_event
Purpose
Create an SV event that is triggered by an e event
Context
Syntax
from_e_event event-name {
attribute;...
};
Syntax Example
from_e_event read_burst_started {
comment : "Emitted on read burst start";
data_method: get_started_read_burst_info;
};
Parameters
event-name The name of the e event as defined in e. Wildcards are allowed. The
element The from_e_event element cannot contain any other elements.
Description
For every event in the e export file, a corresponding UVM event class (uvm_event) is created, and an
object of this event type is created in the exported component. The event object name is the
external_name, if it is defined. Otherwise, it is the e event name. The event class name is the
external_class_name, if it is defined, or the name of the object with _event appended.
For a from_e_event element, the SystemVerilog event is triggered every time the e event is emitted.
A from_e_event can declare a data_method, which must be the name of a method that has no
parameters and returns an object configured to derive from uvm_object using the adapter unit

Event Element
configuration. If this method is declared, the result of this method is sent with the e event, and the user
can retrieve it from the uvm event.
If data_method is used, you can use the create_analysis_port attribute to create an analysis port based
on the exported event. In this case, every time the event is triggered, the analysis port calls its write
function using the object passed with event as parameter.
By default, UIG creates configuration fields that allow the UVC user to disable the event and data
transfer. You can remove these fields by setting the optimization_mode and data_transfer_mode
attributes to NONE.
Note The data in the event is stored as an uvm_object, so casting its attributes is required in order to
use it.
For each event, a task emit_event_name is created in the exported component. These tasks are used by
Specman and by the UVM event class, and should not be used directly by the user. The UVM library
documentation defines the API that users can use to interact with the event.

Subcomponent Element
Element Attributes
Table 5-11 From e Event Element Attributes
external_name: event-name Specifies the name of the event to be created in SV. If not specified,
the e event-name is used.
external_class_name: The SV name of the generated class for the event.

class-name
data_method: method-name The name of a method in the exported unit that returns data to be
sent with the event.
create_analysis_port: bool Creates an analysis port based on the exported event.
analysis_port_name: name The name of the created analysis port, implying that the
create_analysis_port attribute is set to TRUE.
optimization_mode: If USER-DEFINED (the default), creates configuration field for

[USER-DEFINED, NONE] each event to enable control of the exported event. The UVC user
can use the configuration field to disable the event and improve
performance. If NONE, the configuration field is not created and
the user cannot disable the event.
data_transfer_mode: If USER-DEFINED (the default), creates configuration field for

[USER-DEFINED, NONE] each event to enable control of the exported data transfer (if any).
The UVC user can use the configuration field to disable the data
transfer and improve performance. If NONE, the configuration
field is not created and the user cannot disable the transfer.
5.3.10 Subcomponent Element
Purpose
Export a subcomponent of the exported component
Context
Within a UVM component element

Syntax
subcomponent subcomponent-name {
};
Syntax Example
env "SV_IC'sv_type vr_axi_env" {
external_name: vr_axi_ic_env;
subcomponent masters {
external_name: masters;
};
subcomponent slaves {
external_name: slaves;
};
subcomponent passive_interconnect {
component_type: "PASSIVE'active_passive vr_axi_interconnect";
is_list: FALSE;
};
};
Parameters
subcomponent-name The name of the exported e subcomponent. If the exported subcomponent is not a
field of the exported component, the attribute component_type is required. The
value specified by component_type must correspond to a UVM component
exported elsewhere in the e export file. For example:
agent "PASSIVE'active_passive vr_axi_interconnect" {
external_name: vr_axi_interconnect_agent;
...
};
env "SV_IC'sv_type vr_axi_env" {
...
subcomponent passive_interconnect {
component_type:
"PASSIVE'active_passive vr_axi_interconnect";
....
};
};
element The subcomponent element cannot contain any other element.

Description
For every subcomponent element in the export file, a field of the appropriate subcomponent type is
created in the parent component. If the subcomponent element is the name of a field in the enclosing e
unit, the type of the subcomponent object is the exported type of the field. Otherwise, the user must
specify the component type. In any case, that type must be an exported component in the export file.
The name of the field is the external_name if one is defined. Otherwise, it is the name of the
subcomponent in the export file.
If the exported e field is a list, or the is_list attribute is set to TRUE, a dynamic array is created. The size
of the dynamic array is controlled by a generatable configuration attribute UIG creates under the name
num_subcomponent-name. For example, if the “slaves: subcomponent in the Syntax example above is a
list, UIG defines an unsigned integer configuration field named “num_slaves”. Your e code for dynamic
configuration can query the value of this configuration field to obtain the number of instances in the list.
Note The num_* field is placed in the container component or within the default configuration object
if use_config_object is TRUE.

Element Attributes
Table 5-12 Subcomponent Element Attributes
external_name: Specifies the name of the exported subcomponent in SV.

subcomponent-name
comment: Free text within double quotes that defines text to be added as a
subcomponent-description comment to the generated code. You can use the <text></text>
component_type: string The actual name as defined in e of the unit type to be exported. This
name must be provided if subcomponent-name does not match an
actual field name in the exported environment.
is_list: bool If TRUE, the subcomponent is exported as a list.If FALSE, a single

instance of the subcomponent is exported. If subcomponent-name
matches an actual field in the exported environment, this attribute
is ignored.
control_build: bool If FALSE, the subcomponent is built by default. If TRUE, a

configuration property of the component is used to control
building the subcomponent. See Example 1 and 2 below.
control_field: name Specifies the configuration property of the component to be used

to control building the subcomponent. If such a property does not
already exist, it is created. The default is
build_subcomponent_name. See Example 2 below.
control_value: string Specifies the value of the control field for which the subcomponent
is built. See Example 2 below.
build_by_default: string If control_build is TRUE and control_field is not used, this

attribute specifies a default value for the
build_subcomponent_name configuration property.
Example 1
In this example, a new bit field with the default name “build_mon” is created in the env’s config class.
Its default value is 0 because build_by_default is FALSE. So by default, this monitor is not built.
env my_env {
...
subcomponent mon {
control_build : TRUE;

DUT Interface Element
build_by_default: FALSE;
};
...
};
Example 2
In this example, a new bit field “do_not_create_agents” is created in the env’s config class. If
“do_not_create_agents” is 0 (the value specified by control_value), the array of agents is created. The
default value for “do_not_create_agents” is 0 because build_by_default is FALSE. So by default, the
array of agents is built.
env my_env {
...
external_name: env;
subcomponent agents {
control_build: TRUE;
control_field: do_not_create_agents;
control_value: 0;
build_by_default: FALSE;
};
...
};
5.3.11 DUT Interface Element
Purpose
Specify the DUT interface to be exported for a UVM component
Context
Syntax
dut_interface e-unit-name {
attribute;...
};
Syntax Example
sequencer vr_axi_slave_driver {
...

DUT Interface Element
};
};
Parameters
e-unit-name If the exported DUT interface is not a field of the exported component, the attribute
interface_type is required. The value specified by interface_type must
correspond to an interface element defined elsewhere in the e export file. For
example:
sequencer vr_axi_slave_driver {
...
};
};
interface vr_axi_master_signal_map {
...
;
element The dut_interface element cannot contain other elements.
Description
Multiple dut_interface elements are allowed in a single component.
This element defines a DUT interface for the exported component. For every dut_interface element in
a component, a virtual interface handle of the exported interface type is created in the exported
component class. If the DUT interface element is a name of a field in the exported unit, the type of the
virtual interface handle is the exported type of the field. Otherwise, the user must specify the interface
type. In any case, that type must be exported in the export file as an interface element.
The name of the virtual interface handle is the external_name if it is defined. Otherwise, it is the name
of the DUT interface element.
If a component has one or more DUT interfaces, by default a function called assign_vi() is created in the
component in order to set the virtual interface handles. (See create_assign_vi in Table 5-3 on page
5-19.) The function’s parameters are all the DUT interfaces defined for the component. If the component
is an agent, and it has subcomponents that themselves have DUT interface elements of the same type, by
default the agent’s assign_vi() function propagates the relevant interfaces to the subcomponents.
According to the UVM flow, this function should be called by the user in connect_phase().

Configuration Element
Element Attributes
Table 5-13 DUT Interface Element Attributes
external_name: Specifies the name of the exported DUT interface in SV.

DUT-interface-name
DUT-interface-description comment to the generated code. You can use the <text></text>
interface_type: string The name of an exported interface type, defined elsewhere in the
export file. Must be provided if DUT interface is not based on an
actual e field of the exported component.
propagate_to_subcomponent: If TRUE (the default), this interface is propagated to all

bool subcomponents that have an interface of this type.
external_package_name: The name of the SV package to contain the exported entities. The
package-name default is the UVC’s package name.
use_in_assign_vi: bool If TRUE (the default), the containing component’s assign_vi

function includes a parameter to set this interface.
5.3.12 Configuration Element
Purpose
Export configuration properties for a UVM component
Context
Syntax
config sv-field-name {
};
Syntax Example
config cfg {
include_fields: vr_axi_component.*;

include_fields: vr_axi_interface.*;
include_fields : vr_axi_master_config.*;
field is_default {
e_type: bool;
default_value: TRUE;
}:
};
Parameters
sv-field-name The name of the exported e unit that contains ports to be connected to the DUT.
element The config element cannot contain other elements.
Description
UIG allows the definition of properties in the SystemVerilog proxy classes to be used for configuration.
The exported attribute can originate from a field in the associated e unit but this is not a requirement.
You can use this feature to reflect any e UVC attribute that the SystemVerilog user should assign to
control the configuration and behavior of the e UVC.
The config element defines configuration properties for an exported component.
To take a configuration property from the associated e unit (or any other e struct), specify the fields
using the include_fields and exclude_fields attributes. To create properties not based on any e field, use
the field element. (See “Field Element” on page 5-52 for more information.)
You can use the use_config_object attribute to encapsulate several configuration properties in a class. If
set to TRUE, a configuration class is created for the component and a field of this class type is created in
the component.
The name of the configuration object’s field is the external_name, if one is defined. Otherwise, it is the
name of the configuration element in the export file. The name of the configuration class is the
external_class_name if one is defined. Otherwise it is component_type_name_config.
If a parent component has a configuration object, UIG automatically adds to the parent’s configuration
class a configuration object for each of the subcomponents that also has a configuration object. Values
for these objects are automatically propagated to the subcomponents during the parent’s build function.
In sequencer, driver and monitor elements, an uvm_object field is automatically created to hold the
parent’s configuration. This field is set during the parent’s build function if the parent has a
configuration object.

Element Attributes
Table 5-14 Configuration Element Attributes
external_name: Specifies the name of the exported configuration struct in SV.

config-struct-name
config-struct-description comment to the generated code. You can use the <text></text>
use_config_object: bool If TRUE, creates a configuration class for use with the component.
If FALSE (the default), all configuration properties of this
component are placed directly in the component class itself. For
example:
use_config_object : TRUE;
external_class_name: string The SV name of the generated class.
class_code: string Defines SV code to be added to the class. Use the <text> </text>
tags to insert multiple lines of code.
new_function_code: string Specifies code to be added to the class constructor (the new
function). Use the <text> </text> tags to insert multiple lines of
code.
include_fields: Specifies the names of specific fields that are used as configuration
struct-name.field-name properties of the exported component. Wildcards are allowed for
the field name.
exclude_fields: Specifies the names of specific fields that are not used as
struct-name.field-name configuration properties of the exported component. Used to refine
the choice of fields made with include_fields. Wildcards are
allowed for the field name.
create_default_object: bool If TRUE, a default configuration object is created for every

component for which the end user does not instantiate an object. If
FALSE (the default), an error is issued if a configuration object of
a component is not set by the end user.
field_name_in_parent_config: Use this attribute to specify the name of the field that is created in
name this component’s parent configuration class.

Field Element
Table 5-14 Configuration Element Attributes
default: bool Indicates that this is the default config element. If no config
element has this attribute, the first element defined is the default.
All the properties that UIG creates automatically, including the
configuration objects of the subcomponents, are created in the
default configuration object.
5.3.13 Field Element
Purpose
Define a configuration field not based on an e field
Context
Within a config element
Syntax
field field-name {
attribute;...
};
Syntax Example
field has_checks {
e_type: bool;
default_value: TRUE;
is_rand: TRUE;
};
Parameters
field-name The name of the field to be created in the config element.
element The field element cannot contain any other elements.

Field Element
Description
You can use this element to create configuration fields not based on any e field.
You can specify the field’s type in one of two ways:
● Specifying the e_type attribute creates a field of an SV type that is equivalent to the specified e type.
● Specifying the external_type attribute creates a field of the specified SV type. It must be a valid
SystemVerilog type.
Notes
● UIG does not check whether the external_type specified is valid. If it is not valid, a compilation
error occurs when you try to compile the UVC.
● When specifying an external_type, use the external_kind attribute to tell UIG what kind of type it
is. Currently, UIG supports only scalar, enumeration or string types.

Interface Element
Element Attributes
Table 5-15 Field Element Attributes
external_name: name Specifies the name of the field in SV.
comment: field-description Free text within double quotes that defines text to be added as a
e_type: e-type-name A valid e type name. UIG checks that the specified type is valid
and then sets the generated field’s type to the equivalent
SystemVerilog type.
external_type: SV-type-name A valid SystemVerilog type name.
external_kind: kind One of scalar, enum, or string.
default_value: value The default value of the field.
is_rand: bool If TRUE, the field is created as a generatable field. The default is
FALSE.
is_static: bool If TRUE, the field is created as a static field. The default is FALSE.
is_list: bool If TRUE, the field is created as an array. The default is FALSE.
5.3.14 Interface Element
Purpose
Define an exported DUT interface
Context
Top-level, not within any other element
Syntax
interface e-unit-name {
};

Interface Element
Syntax Example
interface vr_axi_master_signal_map {
// The name of class type in SV
external_name: vr_axi_signals;
...
signal awaddr {
...
};
clocking_block clk_blk {
...
};
};
Parameters
e-unit-name The name of the exported e unit that contains ports to be connected to the DUT.
element The interface element can contain signal and clocking_block elements. These
elements define the contents of the generated interface.
Description
All communication between the generated UVM components and the DUT as well as between Specman
and the DUT must be done using a SystemVerilog interface (a SV signal map):
generated-UVM-components => SV-interface => DUT
Specman => SV-interface => DUT
When you define an interface element, UIG creates the SV-interface for you. You can define more than
one interface element in an export file. For each interface declaration in the export file, UIG creates a
SystemVerilog interface that includes by default signals matching all the simple ports and all the input
event ports declared in the base type of the exported unit.
You can control which ports are exported by:
● Including only selected ports

● Excluding some selected ports
● Including ports declared under when subtypes
See “Example Selectively Including/Excluding Ports” on page 5-58 for more information.
You can define signal and clocking_block elements within the interface element to control in more detail
how the ports are exported.

Interface Element
By default, the ports are exported as signals. You can configure each signal to be created as a port
instead of as a signal using the create_as_port attribute.
If you already have SV module that defines a signal map, you can use this instead of or in addition to
defining an interface element. See “Example HDL Wrapper” on page 5-58 for more information.

Interface Element
Element Attributes
Table 5-16 Interface Element Attributes
external_name: Specifies the name of the exported interface in SV.

interface-name
interface-description comment to the generated code. You can use the <text></text>
deep_include_signals: The names of simple ports to be exported as signals of the

port-name interface. deep_include_signals looks for ports in the exported
unit and all its when subtypes. Simple ports not matched by
deep_include_signals are not exported.
The syntax for port-name is [struct_name.]port_name. Regular

expressions using Specman style or AWK style are allowed.
exclude_signals: port-name The names of simple ports that are not to be exported as signals of
the interface. Simple ports not matched by exclude_signals are
exported.

include_signals: port-name The names of simple ports that are exported as signals of the
interface. include_signals looks for ports in the exported unit only,
not in its when subtypes. Simple ports not matched by
include_signals are not exported.

interface_code: string Inserts additional code into the exported entity. Use the <text>
post_declaration_code: code Specifies code to be added after all other declarations in the
generated interface.
pre_declaration_code: code Specifies code to be added before any other declarations in the
generated interface.
implementation_code: string Inserts additional code into the implementation section of the
interface. Use the <text> </text> tags to insert multiple lines of
code.

Interface Element
Table 5-16 Interface Element Attributes
signal_code: string Inserts additional code into the signal section of the interface. Use
the <text> </text> tags to insert multiple lines of code.
Example Selectively Including/Excluding Ports

To select the ports to be exported and exclude all others, use include_signals. To export ports that are
defined under when subtypes of the exported unit, use deep_include_signals. To prevent some port
from being exported and export all others, use exclude_signals. For example:
unit signal_map {
p1: in simple_port of bit;
p2: out simple_port of bit;
when MASTER signal_map {
p3: in simple_port of bit;
};
};
interface signal_map {
include_signals: p*; // matches p1 and p2
deep_include_signals: /p3/; // matches p3
deep_include_signals: "MASTER signal_map.p3"; //matches p3
exclude_signals: "/write_enable/"
};
Example HDL Wrapper

If you already have an HDL wrapper module (an SV module that defines a signal map), you can use this
instead of or in addition to defining an interface element.
Note You can export multiple HDL wrappers or use an HDL wrapper in combination with a
UIG-generated interface.
To reuse the HDL wrapper module:
1. In the eexp file, define an hdl_wrapper container.

hdl_wrapper <wrapper-name> {
};

Interface Element
2. Within the hdl_wrapper container, use include_signals, exclude_signals, or

deep_include_signals attributes and signal elements to identify any simple ports with
verilog_wire() or driver() attributes.
Note You cannot define a clocking_block element in the hdl_wrapper container.
3. Invoke run_uig.sh as usual.
UIG generates implementation code for the ports you specified. If you defined multiple
hdl_wrapper containers, each exported HDL wrapper is stored in a different file. The name of the
exported wrapper file is wrapper-name_imp.svh, where wrapper-name is the name of the
hdl_wrapper container that you defined in Step 1.
4. Open the SV file that defines the signal map and add a ‘include line with the name of the
UIG-generated svh file.
e Code
unit vr_axi_signal_map {
data: out simple_port of int;
keep data.verilog_wire() == TRUE;
address: out simple_port of int;
keep data.driver() == TRUE;
};
eexp file
hdl_wrapper vr_axi_signal_map {
include_signals: address;
include_signals: data;
signal address {
signal_kind: verilog_wire;
net_type: wire;
...
};
signal data {
signal_kind: driver;
net_type: wire;
...
};
...
};
HDL wrapper module (SV)

module vr_axi_hdl_wrapper;

Signal Element
bit reset;
bit clock;
wire [31:0] address;

wire [31:0] data;
// this line is added after UIG has generated the implementation

ìnclude "vr_axi_signal_map_imp.svh"
endmodule : vr_axi_hdl_wrapper
vr_axi_signal_map_imp.svh (generated by UIG)

logic [31:0] address_dp;
assign address = address_dp;
...
5.3.15 Signal Element
Purpose
Controls the export of specific ports
Context
Within an interface element
Syntax
signal e-port-name {
attribute;...
};
Syntax Example
signal wstrb {
signal_size: "[(`VR_AXI_MAX_DATA_WIDTH/8)-1:0]";
};
// Do not pass this signal.

signal write_enable {
create_as_port: TRUE;
};

Signal Element
Parameters
e-port-name The name of the e port to be exported. By default, for all simple port fields of the
exported unit, matching signals are created in the interface.
element The signal element cannot contain any other elements.
Description
This element configures the exported interface signals:
● The name of the signal is the external_name if specified, or else the port’s field name.
● The net type of the signal is the net_type if specified, or else the signal is a variable.
● The data type of the signal is the data_type if specified, or logic by default. This is also the default
data type for nets.
● If the exported field is a list of simple ports, you must specify the list size using the list_size attribute.
By default, an unpacked array is created. If the size of the port’s element type is 1 bit (bit, bool, mvl)
and the create_packed_array attribute is set to TRUE, a packed array is created instead. To create
separate signals for each port in the list instead of an array, set the create_array attribute to FALSE.
● The signal’s packed dimensions are signal_size if specified, or the size of the exported port element
type.
● By default, each port is not exported as an interface port. If the create_as_port attribute is TRUE,
the signal is exported as an interface port with the direction specified by the port_direction attribute.
The default direction is inout.
Notes
● To define a signal with a variable width, you can use `defines. For example:
signal p {
signal_size: "[`MAX_WIDTH-1:0]";
};
● When defining external names for the exported signals, you can use wildcards and $ variables in the
expression. The number of $ variables is equal to the number of wildcards in the expression and the
variable index starts at 1. Both AWK-style and Specman-style expressions are supported. For
example:
interface my_signal_map {
external_name: signal_map;
signal p*ma* {
external_name: s$1ma$2;
};
};

Signal Element
Element Attributes
Table 5-17 Signal Element Attributes
external_name: signal-name Specifies the name of the exported signal in SV. The default is the
e port field name.
comment: signal-description Free text within double quotes that defines text to be added as a
net_type: string Specifies the net type of the signal. If not defined, the signal is a
variable.
data_type: string Specifies the data type of the signal. If not defined, the default is
logic. This is also the default data type for nets.
signal_kind: keyword Specifies that the e port has either a DRIVER or

VERILOG_WIRE port attribute.
initial_value: value A string specifying the initial value to be driven to the signal.
Note Valid only when signal_kind is also specified.
signal_size: string Specifies the packed dimensions of the signal. The default is the
size of the exported port element type.
list_size: string If the exported signal is a list of simple ports, this attribute is
required to specify the size of the generated array.
create_as_port: bool If TRUE, the signal is created as a port of the interface. The default
is FALSE.
port_direction: direction One of INPUT, OUTPUT or INOUT, specifying the direction of

the interface port. The default is INOUT.
create_array: bool If TRUE (the default), a list of simple ports is exported as an array.
If FALSE, separate signals are created for every port in the list.
Each signal’s name is appended with its index in the list.
list_delimiter: string If create_array is used, this string is used to separate the created
signal’s name and its index.
create_as_packed_array: If FALSE (the default), a list of simple ports is exported as an

bool unpacked array. If TRUE, a list of simple ports is exported as a
packed array. This is valid only for single-bit wide signals.

Clocking Block Element
5.3.16 Clocking Block Element
Purpose
Define a clocking block for the created interface
Context
Within an interface element
Syntax
clocking_block clocking-block-name {
attribute;...
};
Syntax Example
clocking_event: "clk";
default_driving_skew: "#0";
clocking_code: <text>always @clk $display("[%m] clk = ",clk);</text>;
};
Parameters
clocking-block-name The name of the generated clocking block
element The clocking_block element can contain a clocking_signal element.
Description
This element is not based on a field of the exported unit.
SystemVerilog clocking blocks specify timing and synchronization requirements on signals in the DUT.
You can sample or drive signals with optional skews relative to a certain clock. This allows you to
sample the value a signal had some time in the past, as well as to drive a signal with a certain delay, all
relative to some clock.
You can define one or more clocking blocks in an interface but only one of them can be the default
clocking block, as defined in the SystemVerilog LRM.

Within a clocking block, you can declare default driving and sampling skews. Using the
include_signals and exclude_signals keywords you can select which signals are present in the clocking
block. Using a clocking_signal element, you can define signals (declared within this given interface) to
be sampled and/or driven within the clocking block.

Element Attributes
Table 5-18 Clocking Block Element Attributes
external_name: Specifies the name of the clocking block in SV.

clocking-block-name
clocking-block-description comment to the generated code. You can use the <text></text>
clocking_event: event An event with which the driving and sampling of the clocking
signals is to be synchronized. Any legal event for SV clocking
blocks is valid here.
clocking_code: string Inserts additional code into the clocking block. Use the <text>
default: bool If TRUE, the clocking block is created as the default clocking
block. The default is FALSE
default_driving_skew: string A string specifying a default time skew for driving inout and
output signals. For example: “#2”. There is no default driving
skew.
default_sampling_skew: A string specifying a default time skew for sampling input and
string inout signals. The default is “#0”.
exclude_signals: port-name The names of simple ports that are not to be included in the
clocking block. Simple ports not matched by exclude_signals are
included.

include_signals: port-name The names of simple ports that are included in the clocking block.
include_signals looks for ports in the exported unit only, not in its
when subtypes. Simple ports not matched by include_signals are
not included.


Clocking Signal Element
Example 1
In the following example, all exported signals (specified by the wildcard “*”) are DUT inputs (specified
by “direction: output”) and will be driven with the default skew of #2 when an event occurs on “aclk”.
clocking_event: aclk;
default_driving_skew: "#2";
clocking_signal: * {
direction: output;
};
};
5.3.17 Clocking Signal Element
Purpose
Define one or more signals to be sampled and/or driven within the clocking block
Context
Within an clocking_block element
Syntax
clocking_signal port-name {
attribute;...
};
Syntax Example
clocking_signal clk_sig {
direction: INPUT;
driving_skew: "#2";
};
Parameters
port-name The name of the exported port in the interface, as specified by include_signals or
deep_include_signals. The syntax for port-name is [struct_name.]port_name.
Regular expressions using Specman style or AWK style are allowed. See
“Interface Element” on page 5-54 for examples.

Importing an e Export File for UVCs with Multiple Packages
element The clocking_signal element cannot contain any other elements.
Description
This element is not based on fields of the exported unit, but on signals already exported in the interface.
You can declare an optional input and/or output skews for the signals.
Element Attributes
Table 5-19 Clocking Signal Element Attributes
external_name: name Specifies the name of the signal in SV.
clocking-signal-description comment to the generated code. You can use the <text></text>
direction: direction INPUT clocking signals (DUT outputs) can be sampled but not
driven. OUTPUT clocking signals (DUT inputs) can be driven but
not sampled. INOUT clocking signals can be sampled and driven.
The default is INPUT.
driving_skew: string A string specifying a time skew for driving the clock signal. For
example: “#2”. The default is the default_driving_skew specified
for the clocking block.
sampling_skew: string A string specifying a time skew for sampling the clock signal. For
example: “#2”. The default is the default_sampling_skew
specified for the clocking block.
5.4 Importing an e Export File for UVCs with Multiple

Packages
Importing an e export file lets you create SystemVerilog interfaces for UVCs with multiple packages
that share common types. You can:
● Create a SV UVC based on an existing SV UVC

● Reuse data types and components from an existing SV UVC
● Extend the hierarchy of class data types based on when or like subtypes

Creating an SV UVC Proxy Based on an Existing Proxy
When the SV interfaces are created in this way, users of the UVC can:
● Use any combination of UVC packages together in the same environment.

● Write generic code, such as a scoreboard, that handles types from any combination of UVC packages.
See Also
● “Creating an SV UVC Proxy Based on an Existing Proxy” on page 5-68
● “Reusing Data Types and Components from an Existing SV UVC Proxy” on page 5-68
● “Extending the Hierarchy of Class Data Types” on page 5-70
● “Known Limitations” on page 5-71
5.4.1 Creating an SV UVC Proxy Based on an Existing Proxy

To create an SV UVC proxy based on an existing one:
● Use the -import invocation option to the run_uig.sh script.
run_uig.sh <top-e-files> -eexp <eexp_file> \
-import <imported-eexp-file>
Providing an export file using the -import flag makes UIG read the export file but not generate code
for it. The actual export file given using the -eexp flag can use any component exported in the
reference package
For example:
run_uig.sh cdn_smbus_top.e -e cdn_smbus_cb.eexp -i cdn_i2c_cb.eexp
5.4.2 Reusing Data Types and Components from an Existing

SV UVC Proxy
5.4.2.1 Reusing Components

The reusing export file may contain references to any component exported in the reference export file
including DUT interfaces. All generated code based on a reference package will be qualified with the
needed package prefix. As a result, the reference package has to be compiled before the reusing package.
For example, reusing a sequencer:
cdn_i2c_cb.eexp:
sequencer cdn_i2c_master_sequence_driver {
external_name: cdn_i2c_master_sequencer;

Reusing Data Types and Components from an Existing SV UVC Proxy
...
};
cdn_smbus_cb.eexp
agent cdn_smbus_master_agent {
external_name: cdn_smbus_master_agent;
subcomponent sequencer {
component_type: cdn_i2c_master_sequence_driver;
};
...
};
5.4.2.2 Reusing Data Types

Any data type created in the reference package and reused in the reusing package must be explicitly
mentioned in the adapter unit configuration of the relevant package. Otherwise it is created again. The
syntax for this is:
remove_type_declaration(cur_type: rf_type): bool;
If this method returns TRUE for any given type, this type's declaration will not be created in the relevant
package. The “relevant package” means any package for which this code is loaded during UIG
invocation.
For example, assume you exported cdn_i2c_master_transaction in the I2C package, and you want to
reuse it in the SMBUS package. The following method must be added to the I2C adapter unit
configuration to prevent this type from being created again in the SMBUS package:
extend cdn_i2c_config_unit {
remove_type_declaration(cur_type: rf_type) : bool is also {
if (cur_type.get_name() == "cdn_i2c_master_transaction") {
result = TRUE;
};
};
};
Notes
● The adapter unit's package_name field must be set to the type's package. Otherwise this code does
not have any impact. Since probably an adapter unit for this package (reference package) already
exists, it is best to extend this unit and add the method to it. This extension should only be loaded
when generating the reusing package.

Extending the Hierarchy of Class Data Types
● Make sure to use the get_package_name() method to explicitly specify the destination package of a
type. This also must be done in an adapter unit whose package_name field is the same as the package
in which the type is declared in. This method should be loaded when generating the reference package
and the reusing package.
5.4.3 Extending the Hierarchy of Class Data Types

Any class hierarchy created in the reference package may be extended in the reusing package. You can
do this using like inheritance or when subtypes. These are translated into single inheritance in SV. As
when you reuse data types, any parts of the hierarchy already exported in the reference package must be
specified explicitly using the remove_type_declaration method, or else they are created again in the
reusing package. You must also use get_package_name in the proper adapter unit for all types in order
to achieve the desired results.
For example, assume you exported cdn_i2c_master_transaction in the I2C package, and you want to
create a class inheriting from it in the SMBUS package:
Type Definitions:
package cdn_i2c;
struct cdn_i2c_master_transaction {
...
};
package cdn_smbus;
struct cdn_smbus_master_transaction like cdn_i2c_master_transaction {
...
};
Adapter Unit Configuration (for cdn_smbus):

extend cdn_i2c_config_unit {
remove_type_declaration(cur_type: rf_type) : bool is also {
result = TRUE;
};
};
get_package_name(cur_type: rf_type) : string is also {
result = "cdn_i2c";
};
};
};
unit cdn_smbus_config_unit {
get_package_name(cur_type: rf_type) : string is also {
if (cur_type.get_name() == "cdn_smbus_master_transaction") {

Known Limitations
result = "cdn_smbus";
};
};
};
extend sys {
cdn_smbus_config_unit is instance;
keep cdn_smbus_config_unit.package_name == "cdn_smbus";
};
● Extending the hierarchy using when subtypes must be done using the when hierarchy adapter unit
configuration. The reference package does not have to use when hierarchy, but in order to export a
when subtype of a type exported in the reference package, the reusing package must configure the
when hierarchy.
● When subtypes are always defined in the context of the package of the when base, even if the subtype
is explicitly defined in another package. This means that all when hierarchy configuration must be
done in the adapter unit of the when base's package.
● If the reusing package does not explicitly export a construct that uses the extended types, the
extend_type top level export file attribute must be used to tell UIG that a type needs extending.
Without this attribute UIG will not create the extension.
5.4.4 Known Limitations

● All exported components (units) must not be related. A unit and its subtype cannot be exported
together in the same package or in different packages.
● Enumerated types cannot be extended in SystemVerilog. As a result, all exported enumerated types
must contain all the relevant items when exported, usually in the first exported package.
5.5 Dynamic e Configuration API

The end user configures the proxy UVM components created by UIG to create a verification
environment. In order to create an e verification environment that reflects the user’s SV environment,
you must provide a dynamic e configuration file.
The file uses the UIG configuration API to query the UVM user environment and build the e
environment accordingly. This file must be loaded at simulation time and might also be needed during
UIG invocation and stub generation, depending on the UVC.
You can enable dynamic configuration in one or more of the following ways:
● “Using the UIG Dynamic Config API” on page 5-72

● “Using Macros” on page 5-73
● “Using Defines” on page 5-74

Using the UIG Dynamic Config API
Note All dynamic configuration files must be stored in e_uvc-dir/e/api/sv/generic_config.
5.5.1 Using the UIG Dynamic Config API

The following API methods query various aspects of the UVM environment. These methods return the
actual values from the UVM environment only during simulation, after the UVM build phase has
completed. In order to support interface generation and stub generation, when the actual user
environment is not available, you must provide these methods with default values.
Note Although configuration properties might be comprised of complex objects, only integer and
string values can be queried.
Table 5-20 UIG Dynamic Config API: Quick Reference
Method Description
uig_get_num_instances on Returns the total number of instances of a specific exported type

page 5-75
uig_get_uvm_path_by_id on Returns the full UVM path of an instance using the component’s id
page 5-76
uig_get_field_value_<type> Retrieves a field value from a specific UVM exported component

on page 5-77
uig_get_dut_interface_path Returns the full hierarchical path of a DUT interface instance

on page 5-78
uig_get_dut_interface_id on Returns the id of a DUT interface instance

page 5-78
uig_get_array_size on page Returns the size of an array field under the component or inside a
5-79 configuration object of the component
Each exported unit needs to have two UVM unit attributes defined, as described in Table 5-21. For the
top-level e entities (one or more units of type any_env), you first set the uvm_unit_id arbitrarily and

Using Macros
then retrieve the uvm_path. For each subcomponent, because its place in the unit hierarchy is
important, you calculate the uvm_path based on the parent’s path and then set the uvm_unit_id.
Table 5-21 UIG Unit Attributes: Quick Reference
Attribute Description
uvm_unit_id() This attribute identifies the instance ID of a specific SystemVerilog

proxy class instance associated with the e unit instance. UIG
generates SystemVerilog logic that assigns unique instance IDs for
each instance of a proxy class. Instance IDs are consecutive
unsigned integers starting with 0. Each proxy class type has its own
series of instance IDs, starting with 0.
uvm_path() This attribute specifies the full UVM path of the SystemVerilog
proxy class instance associated with an e unit. The UVM path
attribute must hold the same string value that would be returned by
calling the proxy class instance’s get_full_name() function. This
function is defined in the UVM SystemVerilog uvm_component
class. For top level instances, you know the ID of the instance and
can use the uig_get_uvm_path_by_id() utility function to obtain
the path.
See Also
● “Dynamic e Configuration API” on page 5-71
5.5.2 Using Macros

You need to use macros to configure anything that is not set by user-defined constraints. For example, if
you want to extend an enumerated type or if you configure something in the e environment with a
macro, now you need a define as computed macro to calculate these values for the SV environment.
Note If you use define as computed macros to dynamically configure the UVC, you must specify
those with the load_after_build attribute in the e export file. These macros are compiled only after the
SV environment is built.
The following example shows the use of a define as computed macro to extend an enumerated type and
add values defined in SV. This is typically part of the dynamic configuration logic.
Usage Example:
acme_uvc_soft_extend acme_uvc acme_uvc_env_name_t uvc_name acme_uvc_env_u;
This example:

Using Defines
● Assumes the SV code has proxy classes of type “acme_uvc_env_u” in a package called “acme_uvc”
● Assumes each of those classes has an exported string config field called “uvc_name”
● Creates e code that extends the “acme_uvc_env_name_t” enumerated type with all the values
assigned to the uvc_name field in all SV instances of acme_uvc_env_u
For example, if the SV has two instances of acme_uvc_env_u, with their uvc_name field equal to
“ENV0” and “ENV1”, the macro invocation above generates the following code:
extend acme_uvc_env_name_t: [ENV0, ENV1]
Macro Code:
define <acme_uvc_soft_extend'statement>
"acme_uvc_soft_extend <sv_pkg'name> <e_type'name> <sv_field'string>
<sv_type'name>,..." as computed {
var list_size: uint;
var uvm_path: string;
var names: list of string;
var idx:uint;
var name: string;
for each (sv_t) in <sv_type'names> {
list_size = uig_get_num_instances(<sv_pkg'name>, // SV package name
sv_t); // SV type
for {idx=0; idx<list_size; idx+=1} do {
uvm_path = uig_get_uvm_path_by_id(<sv_pkg'name>, // SV package name
sv_t, // SV type name
idx); // serial ID
name = uig_get_field_value_string(<sv_pkg'name>, // SV package name
sv_t, // SV type name
uvm_path, // SV path
<sv_field'string>); // SV field name
names.add(name);
};
};
names = names.sort(it).unique(it);
var rfe:rf_enum = rf_manager.get_type_by_name(<e_type'name>).as_a(rf_enum);
var cur_names : list of string = rfe.get_items().apply(it.get_name());
var new_names : list of string = names.all(it not in cur_names);
return appendf("extend %s: [%s]", <e_type'name>, str_join(new_names, ","));
};
5.5.3 Using Defines

Defines are usually used to allow signals to have varying width.

uig_get_num_instances
To create a define whose value can be re-defined by the end-user:
1. Specify the default value for this define both in e and in SV.
For example, in e:
#ifdnef MAX_WIDTH
#define MAX_WIDTH 100
#endif
And in SV:
ìfdnef MAX_WIDTH
`define MAX_WIDTH
èndif
You can store the defines file in e_uvc-dir/sv.
2. Include the defines file in the list of files to be compiled.
3. Instruct the user to over-ride the value in one of the following ways:
a. Use the irun command option -defineall
For example:
irun .... -defineall "MAX_WIDTH 32"
Or
irun .... -defineall MAX_WIDTH=32
b. Put the define in SV header file and give its name as a parameter to irun.
For example, in an SV file “my_e_uvc_defines.svh”:

`define MAX_WIDTH 32
And then on the irun invocation line:
irun -uvmenvdefines my_uvc_defines.svh
5.5.4 uig_get_num_instances
Purpose
Return the total number of instances of a specific exported type
Syntax
uig_get_num_instances(package_name: string, type_name: string, default_value: int =0):int

uig_get_uvm_path_by_id
Syntax Example
extend sys {
//number of AXI envs with interconnect from SV world
vr_axi_sv_ic_axi_envs : list of vr_axi_env is instance;
keep vr_axi_sv_ic_axi_envs.size() ==
uig_get_num_instances("vr_axi","vr_axi_ic_env",1);
...
};
Parameters
package_name The name of the UIG-generated SV package.
type_name The name of the type of the exported component.
default_value The value to be used during interface generation and stubs generation, when the
actual user environment is not available. The default is 0.
5.5.5 uig_get_uvm_path_by_id
Purpose
Returns the full UVM path of an instance using the component’s id.
Syntax
uig_get_uvm_path_by_id(package_name: string, type_name: string, uvm_unit_id: int):string
Syntax Example
env.uvm_path() ==
uig_get_uvm_path_by_id("vr_axi","vr_axi_ic_env",env.uvm_unit_id())
Parameters
uvm_unit_id The unique ID of the exported component.
Note No default value is needed for this method. An empty string is returned during interface and
stub generation.

uig_get_field_value_<type>
5.5.6 uig_get_field_value_<type>
Purpose
These methods retrieve a field value from a specific UVM exported component
Syntax
uig_get_field_value_int (package_name: string, type_name: string, path: string, field_name: string,
default_value: int = 0):int
uig_get_field_value_string (package_name: string, type_name: string, path: string, field_name: string,

default_value: string = “”):string
uig_get_field_value_bool (package_name: string, type_name: string, path: string, field_name: string,

default_value: bool = FALSE):bool
uig_get_field_value_long (package_name: string, type_name: string, path: string, field_name: string,

default_value: int(bits: 1024) = 0):int (bits: 1024)
Syntax Example
slave.uvm_unit_id() ==
uig_get_field_value_int("vr_axi","vr_axi_slave_agent",
slave.uvm_path(),"id", 0);
slave.config.interface.bus_endiannes ==
uig_get_field_value_string("vr_axi",
"vr_axi_slave_agent", slave.uvm_path(),"cfg.bus_endiannes",
"LITTLE").as_a(vr_axi_endianness_t);
Parameters
path The uvm path of an exported component that is defined with the type type_name
in a package package_name.
field_name Can be a path under the component, if the required field is inside a configuration
object.
actual user environment is not available.

uig_get_dut_interface_path
Description
uig_get_field_value_int() returns a 32-bit signed integer. uig_get_field_value_long() returns a
1024-bit signed integer. You can retrieve numerated types using the int and string methods.
5.5.7 uig_get_dut_interface_path
Purpose
Return the full hierarchical path of a DUT interface instance
Syntax
uig_get_dut_interface_path(package_name: string, type_name: string, path: string, field_name: string,
default_value: string = “”):string
Syntax Example
slave.hdl_path() == uig_get_dut_interface_path("vr_axi",
"vr_axi_slave_agent",slave.uvm_path(),"vr_axi_signal_interface","");
Parameters
field_name The name of the virtual interface field under the exported component.
5.5.8 uig_get_dut_interface_id
Purpose
Return the id of a DUT interface instance

uig_get_array_size
Syntax
uig_get_dut_interface_int(package_name: string, type_name: string, path: string, field_name: string,
default_value: int = 0):int
Syntax Example
slave.id() == uig_get_dut_interface_id("vr_axi",
"vr_axi_slave_agent",slave.uvm_path(),"vr_axi_signal_interface","");
Parameters
field_name The name of the virtual interface field under the exported component.
5.5.9 uig_get_array_size
Purpose
Returns the size of an array field under the component or inside a configuration object of the component
Syntax
uig_get_array_size(package_name: string, type_name: string, path: string, field_name: string,
default_value: int = 0)
Syntax Example
slave.array.size() == uig_get_array_size("vr_axi",
"vr_axi_slave_agent",slave.uvm_path(),"vr_axi_slave_array","");
Parameters

uig_get_array_size
field_name The name of the array field.

6 mltypemap Utility: Automatic
Generation of Data Types
This chapter describes a utility called mltypemap. This utility can be used to generate data types in a
target language based on data types in a source language. These data types can then be used as data types
in ML UVM transactions using ML UVM TLM ports.
Using mltypemap lets you avoid manually coding type definitions, which can be complex, tedious, and
error prone.
The supported source languages are SystemVerilog, e, and SystemC. The supported target languages are
SystemVerilog, e, and SystemC.
This chapter contains the following:
● “Examples” on page 6-1

● “Invoking mltypemap” on page 6-10
● “Mapping Types with mltypemap” on page 6-11
● “Configuring mltypemap” on page 6-19
● “mltypemap Limitations for this Release” on page 6-28
6.1 Examples
The following sections contain simple, runnable examples for mltypemap. The examples are divided
into sections based on the three source languages (e, SystemVerilog, or SystemC) and show how to
convert to each of the other two.
● “Mapping from e” on page 6-2

● “Mapping from SystemVerilog” on page 6-4
● “Mapping from SystemC” on page 6-7

mltypemap Utility: Automatic Generation of Data Types
Mapping from e
6.1.1 Mapping from e

This section shows how to convert from e to either SystemVerilog or SystemC, using three files:
● run_mltypemap.sh— Invokes irun with the mltypemap option, and specifies a Tcl run file and e
input file
● test.e — The e source file. Its types will be mapped to either SystemVerilog or SystemC.
● do.tcl — The configuration file, specific for each output language.
● Configures mltypemap using the configuration commands described in “Configuring mltypemap”
on page 6-19
● Invokes the mapping process using the maptypes command described in “Invoking mltypemap”
on page 6-10
The mapped type is msg. It is mapped along with its two subtypes big_msg and small_msg.
File: run_mltypemap.sh
irun \
-mltypemap_input do.tcl \
test.e
File: test.e
<'
package dt;
type kind_t : [GOOD, BAD];
struct msg {
kind : kind_t;
!top_unit : any_unit; // pointer to unit - do not map
};
struct big_msg like msg {

private counter : int; // note: private fields are not mapped by default
data : list of byte;
};
struct small_msg like msg {

data : int;
};
'>

Mapping from e
6.1.1.1 Mapping from e to SystemVerilog
File: do.tcl
# This will generate UVM code
# to generate OVM code add the configuration command
# configure_code -ovm
# change the scope from dt to sv_dt

configure_scope -scope e:dt -to_scope sv_dt
# skip field top_unit since it cannot be mapped

configure_type -type e:dt::msg -skip_field top_unit
# change the enumerated items

configure_enum_item -type e:dt::kind_t -item GOOD -to_name MSG_GOOD;
configure_enum_item -type e:dt::kind_t -item BAD -to_name MSG_BAD;
# change all field names to be prefixed with m_

configure_field -type e:dt::* -field {/(.*)/} -to_name {m_$1}
# do the actual mapping

maptypes -from_type e:dt::msg -base_name sv_dt -to_lang sv
Output Files
The output of the irun command for the SystemVerilog target language is three files, with base name
sv_dt:
● sv_dt.svh—Contains the types definitions.

● sv_dt_ser.sv—Contains serialization code for SV.
● sv_dt_ser.e—Contains serialization configuration code for e.
6.1.1.2 Mapping from e to SystemC
File: do.tcl
# This will generate UVM code
# to generate OVM code add the configuration command
# configure_code -ovm
# change the scope from dt to sc_dt

Mapping from SystemVerilog
configure_scope -scope e:dt -to_scope sc_dt
# skip field top_unit since it cannot be mapped

configure_type -type e:dt::msg -skip_field top_unit
# change the enumerated items

configure_enum_item -type e:dt::kind_t -item GOOD -to_name MSG_GOOD;
configure_enum_item -type e:dt::kind_t -item BAD -to_name MSG_BAD;
# change all field names to be prefixed with m_

configure_field -type e:dt::* -field {/(.*)/} -to_name {m_$1}

maptypes -from_type e:dt::msg -base_name sc_dt -to_lang sc
Output Files
The output of the irun command for the SystemC target language is three files, with base name sc_dt:
● sc_dt.h—Contains the types definitions in SC.

● sc_dt.cpp—Contains implementation of UVM member functions for the mapped types.
● sc_dt_ser.e—Contains serialization configuration code for e.
6.1.2 Mapping from SystemVerilog

This section shows how to convert from SystemVerilog to e or SystemC, using three files:
● run_mltypemap.sh — Invokes irun with the mltypemap option, and specifies a Tcl run file and
SV input file
● test.svh — The SystemVerilog source file
on page 6-19
on page 6-10
The mapped type is msg. It is mapped a long with the type data, which is used for one of its fields.
irun \
-uvm \

test.svh
File: test.svh
ìfndef TEST_SVH
`define TEST_SVH
ìnclude "uvm_macros.svh"
package dt;
import uvm_pkg::*;
class data extends uvm_object;

bit [63:0] addr;
byte bytes[];
int do_not_map_me;
ùvm_object_utils_begin(data)
ùvm_field_int(addr,UVM_ALL_ON)
ùvm_field_array_int(bytes,UVM_ALL_ON)
ùvm_field_int(do_not_map_me,UVM_ALL_ON)
ùvm_object_utils_end
function new (string name="data");
super.new(name);
endfunction
endclass : data
class msg extends uvm_object;

string name;
data d;
ùvm_object_utils_begin(msg)
ùvm_field_string(name,UVM_ALL_ON)
ùvm_field_object(d, UVM_ALL_ON)
ùvm_object_utils_end
function new (string name="msg");
super.new(name);
endfunction
endclass : msg
endpackage : dt
èndif

6.1.2.1 Mapping from SystemVerilog to e
File: do.tcl
# map the scope dt to sn_dt
configure_scope -scope sv:dt -to_scope sn_dt
# skip the field do_not_map_me

configure_type -type sv:dt::data -skip_field do_not_map_me
# map the field msg.d as generatable in Specman

configure_field -type sv:dt::msg -field d -rand
# map the types

maptypes -from_type sv:dt::msg -base_name sn_dt -to_lang e
Output Files
The output of the irun command for the e target language is four files, with base name sn_dt:
● sn_dt_top_file.e—Top file, imports all the e generated files.

● sn_dt_vr_dt.e—Contains the mapped types of package vr_dt. When e is the target language, there
is one file per package.
● sn_dt.e—Imports all the mapped files (created per-package).
● sn_dt_ser.e—Serialization configuration for e.
● sn_dt_ser.sv—Contains serialization code for SV
6.1.2.2 Mapping from SystemVerilog to SystemC
File: do.tcl
# map the scope dt to sc_dt
configure_scope -scope sv:dt -to_scope sc_dt
# skip the field do_not_map_me

configure_type -type sv:dt::data -skip_field do_not_map_me
# map the types

maptypes -from_type sv:dt::msg -base_name sc_dt -to_lang sc

Mapping from SystemC
Output Files
The output of the irun command for the SystemC target language is three files, with base name sc_dt:
● sc_dt.h—Definitions of mapped types in SC

● sc_dt.cpp—Implemenation of UVM member methods in SC
● sc_dt_ser.sv—Contains serialization code for SV
6.1.3 Mapping from SystemC

This section shows how to convert from SystemC to SystemVerilog or e, using four files:
● run_mltypemap.sh — Invokes irun with the mltypemap option, and specifies a Tcl run file and
SV input file
● test.cpp and test.h — The SystemC source files
on page 6-19
on page 6-10
The mapped type is msg. It is mapped along with the type data, which is used for one of its fields.
In these examples, mltypemap will map the type packet defined in the two source files: test.cpp and
test.h.
irun \
-uvm \
test.cpp \
-sysc \
-compile
File: test.cpp
#include "test.h"
namespace dt {
packet::packet() {}
packet::~packet() {}

void packet::do_print(ostream& os) const {

os << "packet = " << name << endl;
}
void packet::do_pack(uvm_packer& p) const {

p << addr << name << data;
}
void packet::do_unpack(uvm_packer& p) {
p >> addr;
p >> name;
p >> data;
}
void packet::do_copy(const uvm_object* rhs) {
const packet* drhs = DCAST<const packet*>(rhs);
if (!drhs) { cerr << "ERROR in do_copy" << endl; return; }
addr = drhs->addr;
name = drhs->name;
data = drhs->data;
}
bool packet::do_compare(const uvm_object* rhs) const {
if (!drhs) { cerr << "ERROR in do_compare" << endl; return true; }
return
addr == drhs->addr &&
name == drhs->name &&
data == drhs->data;
}
}
File: test.h
#ifndef PACKET_H
#define PACKET_H
#include "ml_uvm.h"
using namespace uvm;
namespace dt {
class packet : public uvm_object {

public:
// use macro to generate necessary methods that factory needs

UVM_OBJECT_UTILS(packet)
packet();
virtual ~packet();

// implement mandatory pure virtual methods
virtual void do_print(ostream& os) const;
virtual void do_pack(uvm_packer& p) const;

virtual void do_unpack(uvm_packer& p);
virtual void do_copy(const uvm_object* rhs);
virtual bool do_compare(const uvm_object* rhs) const;
public:
sc_int<64> addr;
std::string name;
std::vector<sc_int<8> > data;
};
// register the data object with the factory

UVM_OBJECT_REGISTER(packet)
}; // namespace dt
#endif
6.1.3.1 Mapping SystemC to e
File: do.tcl
# configure the scope
configure_scope -scope sc:dt -to_scope sn_dt

maptypes -from_type sc:dt::packet -base_name sn_dt -to_lang e
Output Files for e

The output of the irun command for the e target language is four files, with base name sn_dt:
● sn_dt_top_file.e—Top file, to import all the e generated files.

● sn_dt_vr_dt.e—Contains the mapped types of package vr_dt. When e is the target language, there
is one file for package.
● sn_dt.e—Import all the mapped files (created per-package).

Invoking mltypemap
● sn_dt_ser.e—Serialization configuration for e.
6.1.3.2 Mapping SystemC to SystemVerilog
File: do.tcl
# configure the scope
configure_scope -scope sc:dt -to_scope sv_dt

maptypes -from_type sc:dt::packet -base_name sv_dt -to_lang sv
Output Files for SystemVerilog

The output of the irun command for the SystemVerilog target language is two files, with base name
sv_dt:
● sv_dt.svh—Contains definition of SV mapped types.

● sv_dt_ser.sv—Serialization code for SV.
6.2 Invoking mltypemap

mltypemap is a TCL-based tool that is invoked from irun. When you invoke mltypemap, you must
enter the appropriate mltypemap-related flags plus all the compilation flags necessary for irun to
compile the files and elaborate the snapshot (in the case of SystemVerilog inputs).
When you invoke mltypemap, irun performs the following steps:
1. Compile all the source files.
Note When working with SystemC input, the input file must be a single CPP file and the
argument –sysc has to be given. More than one input file is currently not supported for SystemC.
2. Elaborate the design (in case of SystemVerilog).
3. Invoke mltypemap and display its TCL prompt.
4. Abort.
6.2.1 Irun Arguments for Invoking mltypemap

Following are the irun arguments for invoking mltypemap:

Mapping Types with mltypemap
irun -mltypemap_input input-file -mltypemap_tcl
irun Arguments
Argument Description
-mltypemap_tcl Invokes mltypemap in interactive mode (displays its TCL prompt).
-mltypemap_input input-file Identifies the name of an input file that contains TCL commands for
mltypemap. Typically this file contains mltypemap configuration
commands and one or more mltypemap map commands.
Examples
To invoke irun with e files:

irun -mltypemap_input do.tcl file.e
To invoke irun with SV files:

irun -mltypemap_input do.tcl test.svh -ovm
To invoke irun with SystemC files:

irun -mltypemap_input do.tcl types.cpp -sysc -compile
Note Refer to the irun User Guide for information about irun options such as –compile, –ovm, and
–sysc.
6.3 Mapping Types with mltypemap

You use the mltypemap TCL command maptypes to invoke the mapping process. In general, this
command should be called after the necessary configuration commands have been executed. The
configuration commands are described in “Configuring mltypemap” on page 6-19.
This section contains the following:
● maptypes Command on page 6-12

● “Output Files Generated by maptypes” on page 6-13
● “Mapped Data Types” on page 6-14
● “Mapping Classes” on page 6-14
● “Mapping e when Subtypes” on page 6-16
● “Mapping Scalars” on page 6-17

maptypes Command
● “Mapping Enumerated Types” on page 6-18

● “Mapping Typedefs” on page 6-19
6.3.1 maptypes Command
Syntax
maptypes –to_lang lang -from_type type-name -base_name base-name
Syntax example
maptypes –to_lang sv –from_type e:ahb::ahb_packet –base_name ahb_datatypes
Parameters
Parameter Description
–to_lang lang The name of the target language. The accepted language names are:
● e (or sn)
● sv
● sc
The language names are case insensitive. This parameter is

mandatory and can be repeated.
Note When types are mapped to two or more target languages,

Cadence recommends doing so in a single invocation.
-from_type type-name The name of the source type. The type-name must be the full name
(including package/namespace qualifiers) and must contain the
language prefix (e, SV, SC).
This parameter is mandatory and may repeat. Examples:

-from_type e:my_pkg::my_struct
–from_type sv:package1::my_data_item
-base_name base-name The base name for the output files. This parameter is mandatory.
The base name can contain a directory path to a folder. For example:
-base_name my_types
-base_name my_dir/my_dt

Output Files Generated by maptypes
Description
As described above, you use the mltypemap TCL command maptypes to invoke the mapping process.
Note that the input to mltypemap must be a type defined inside a package, and, therefore, its name must
be qualified with the package name:
● In e, all types that are not defined explicitly inside a package, are defined inside the package “main”.
To map such a type, the “main” qualifier has to be used (for example, -from_type e:main::packet).
● In SystemVerilog, only types defined inside a package are supported. Types defined inside a module,
or types defined inside the compilation scope are not supported.
● In SystemC, types should be defined in namespace, or in the global namespace. Types defined inside
classes are currently not supported.
Example
The following command generates type definitions in SystemVerilog for the e type ahb_packet:
mltypemap> maptypes –from_type e:ahb::ahb_packet \
-to_lang sv \
-base_name ahb_datatypes
This command generates three files: ahb_datatypes.svh, ahb_datatypes_ser.sv and ahb_datatypes_ser.sv.

(see “Output Files Generated by maptypes” on page 6-13).
6.3.2 Output Files Generated by maptypes

When the maptypes command is executed, mltypemap generates the following code:
● Data type definition in the target language

● Serialization code in the target language
● Serialization code in the source language
6.3.2.1 Output Files Generated for SystemVerilog

If SystemVerilog is the target language, all type definitions are generated in a file called base-name.svh.
In addition, a serialization code is generated if SystemVerilog is the source or target language. The
serialization file name is base-name_ser.sv.

Mapped Data Types
6.3.2.2 Output Files Generated for e

When e is the target language, a file is generated for each package (because, in e, each package must be
defined in a separate file). Therefore, the following files are generated:
● base-name.e: a file importing all type definitions

● base-name_package-name.e: a file containing the type definitions for each of the generated packages.
● base-name_top_file.e: created only when e is the target language, this file imports all other files
In addition, serialization code is generated if e is the source or target language. The serialization file
name is base-name_ser.e.
6.3.2.3 Output Files Generated for SystemC

When SystemC is the target language, the following files are created:
● base-name.h: definition of the generated files

● base-name.cpp: implementation of the UVM methods of the generated classes
Limitation: No serialization code is generated to SystemC, because SystemC uses the default UVM
packing for ML serialization.
6.3.3 Mapped Data Types

By default, the scope of the target type is the same as the scope of the source type. Types defined in
global scope will be mapped to scope named global_scope. This can be configured using the
configure_scope and configure_type commands. See:
● configure_scope Command on page 6-21

● configure_type Command on page 6-21
6.3.4 Mapping Classes

A class is mapped by mapping all its fields. By default, the mapped fields are the public, non static
fields.
When a class is mapped, all its subtypes are mapped as well. Also, the parent classes of this class are
mapped. By default, the name of the mapped class is as the name of the source class.
You can change the default settings with the configure_type command (see configure_type Command
on page 6-21).

Mapping Classes
This section contains the following:
● “Mapping a Field” on page 6-15

● “UVM Field Properties (pack, print, and so on)” on page 6-15
6.3.4.1 Mapping a Field

A field is mapped into a corresponding field in the target language. The default name of the field is its
source name. The access level (private/local, protected or public) of the field is the same access level as
the source field.
By default, only public, non static fields are passed. The mapping of a field can be configured using the
configure_field command. (see configure_field Command on page 6-23).
When a non-public field is passed, you can specify the setter/getter methods for the source field, as well
as for the target field.
Limitation: Setters/getters are not supported in the current release.
Static Fields
By default, static fields are not mapped. Mapping of static fields is not supported, and a run-time error is
given if a static field is configured to be passed.
Randomization Modifier
“rand” or “randc” fields in SystemVerilog are mapped to a generated field in e. Generated fields in e are
mapped to “rand” field in SV.
6.3.4.2 UVM Field Properties (pack, print, and so on)

For each a class, a code is generated to support basic UVM functionality. In SystemVerilog this code
includes generating the appropriate UVM macro for each field, and in SystemC this code includes
generating the code for the UVM methods. By default, a field is part of each of the operations.
mltypemap lets you configure certain aspects of this by specifying if a field should be packed, printed
or so on.

Mapping e when Subtypes
6.3.5 Mapping e when Subtypes

The current version of mltypemap supports only flattening of when subtypes. That is, when an e struct
is mapped and this struct has when subtypes, then all the when subtypes are flattened into the target
class. To avoid ambiguity in the field names, the field name is the C name of the field in e (usually
prefixed with the determinant value).
For example:
type packet_kind : [BIG,SMALL];
struct packet {
kind : packet_kind;
when BIG packet {
data: byte;
};
when SMALL packet {
data : int(bits:100);
};
};
In this case, the struct packet has two when subtypes, BIG packet and SMALL packet. By default, all
fields defined under when will be flattened into the type packet, and their default names will be
BIG__data and SMALL__data.
If a struct in e contains a field whose type is a when subtype, this field is mapped to a field whose type
is the base type of the when subtype. For example:
struct data {
rp : RED packet;
};
In this case, the mapped type of “data” will have a field whose type is the mapped type of “packet”, not
of “RED packet”. For example, if the target language is SV, then:
class data {
packet rp;
};
6.3.6 Referencing when Subtypes in Configuration

Commands
When you need to refer to a when subtype in any of the configuration commands, you need to specify
the when subtype name enclosed in double quotes. For example, suppose you are mapping this class:
package user_pkg;
type packet_kind : [BIG,SMALL];

Mapping Scalars
struct packet {
kind : packet_kind;
when BIG packet {
data: byte;
};
when SMALL packet {
data : int(bits:100);
};
};
Suppose further that you would like to skip the field SMALL'packet.data. The proper command
would be:
configure_type -type "e:SMALL user_pkg::packet" -skip_field data
6.3.7 Mapping Scalars

The following table describes how two-value scalars are mapped.
Table 6-1 Mapping for Two-Value Scalars
e SystemVerilog SystemC
bit bit sc_uint<1>
byte byte unsigned sc_uint<8>

(unsigned char)
uint(bits:8) byte sc_int<8>

(unsigned char)
int(bits:16) shortint sc_int<16>

(short)
uint(bits:16) shortint unsigned sc_uint<16>

(unsigned short)
int int Int

(sc_int<32>)
uint int unsigned unsigned int

(sc_int<32>)
int(bits:64) longint sc_int<64>

(Int64)

Mapping Enumerated Types
Table 6-1 Mapping for Two-Value Scalars
e SystemVerilog SystemC
uint(bits:64) longint unsigned sc_uint<64>

(uint64)
uint(bits:n) bit[n-1:0] sc_uint<n> (for n <= 64)

sc_biguint<n> (for n > 64)
int(bits:n) bit unsigned [n-1:0] sc_int<n> (for n <= 64)

sc_bigint<n> (for n > 64)
sc_bv<n>
Note Four-value scalars are not supported, and an error is given if a field on such a type is passed.
When the input language is SystemVerilog, mltypemap can be configured to map four-value scalars as
two-value scalars, the configuration can be done globally using configure_code -lang sv
-map_all_as_2value, or per field using configure_field option -map_as_2value. See also
“configure_field Command” on page 6-23 and “configure_code Command” on page 6-26.
Note When mapping scalars of size 8,16,32 or 64 bits to SystemC, the mapping can be controlled
using configuration option -use_cpp_type or -use_sc_type. See also “configure_field Command” on
page 6-23.
6.3.8 Mapping Enumerated Types

For a source enumerated type, a target enumerated type is created. You can control the name of the target
enumerated type and the mapping of literals names. The target enumerated type will have the same bit
width as the source type.
You can use the command configure_type to configure the mapping of the enum type and the command
configure_enum_item to configure the mapping of the enum items themselves. (See configure_type
Command on page 6-21 and configure_enum_item Command on page 6-25.)
6.3.8.1 Example
Given the following enum in e:
type color : [RED = 10; GREEN = 20 ; BLUE = 30];
The following type definition will be generated in SystemVerilog:

typedef enum { RED =10, GREEN = 20 ; BLUE = 30} color;

Mapping Typedefs
6.3.9 Mapping Typedefs

For a source typedef, a target typedef is created. You can use the command configure_type to configure
the mapping of the typedef, specifically the target’s name. (See the configure_type Command on page
6-21.)
Notes
● Specman only supports numeric typedefs. If the output language is e, all non-numeric typedefs (to
classes, or aliases for other types), will not be created, and the underlying types will be used instead.
● Typedefs defined inside a class scope will be created in the target language inside a namespace with
the class’s name, and not inside a class scope.
6.3.9.1 Example
Given the following typedef in SystemVerilog:
typedef bit signed[17:0] int18;
The following typedef will be generated in SystemC:

typedef sc_int<18> int18;
The following typedef will be generated in e:

Type int18: int(bits:18);
6.4 Configuring mltypemap

This section describes the TCL API for mltypemap configuration. The configuration commands are
usually written before the maptypes command. When maptypes command is invoked, it will apply all
the configuration commands to the built types. If a configuration command was not applied to any
instance, a non-fatal error is given. Cadence recommends looking for these errors because they might
indicate typos in the configuration commands.
There are four configuration commands used to configure type-related entities: configure_scope,
configure_type, configure_field and configure_enum. The configure_code command used for global
configuration regarding the generated code. In addition, there is a print_type command that can be used
to get information about types and the configuration commands applied to them.

Configuring mltypemap
Using regular expressions

To describe the entity which the configuration command applies to (for example, scope, type, field,
enum-item), regular expressions can be used. The regular expression syntax is a POSIX regular
expression syntax, and the regular expression has to be written inside slashes. For arguments which have
to include the language prefix (such as scopes and types), the regular expression does not apply to the
language prefix, and the language prefix has to be written outside of the regular expression.
For example, to apply configuration type command to all types of package vr_ahb, that start with the
prefix my_, the following command has to be written:
configure_type -type e:/vr_ahb::my_/ …
For some configuration properties, sub matches can be used to set the new value of the configuration.
This is done by using $0,..,$9 in the appropriate property, and by adding () to group the sub matches in
the regular expression (where $0 refer to the full match). For example, to map all fields of type packet
starting with sv_ to start with sn_, the following command can be given:
configure_field -type sv:sv_ahb::packet -field {/^sv_(.*)/} -to_name {sn_$1} …
For simple regular expressions containing only the expression for any number of characters (.*), the
regular expression can be written as a wildcard (*), and without slashes. That is, the following are equal:
-type e:/vr_ahb::my.*bus/
-type e:vr_ahb::my*bus
If a certain property was re-configured, then the last configuration command wins and no warning is
given.
To get more information about the configuration, the print_type command can be used, which prints for
a given type the configuration commands that were applied to this type. See print_type Command on
page 6-26 for more details.
This section describes the following commands:
● configure_scope Command on page 6-21

● configure_type Command on page 6-21
● configure_field Command on page 6-23
● configure_enum_item Command on page 6-25
● print_type Command on page 6-26
● configure_code Command on page 6-26

configure_scope Command
6.4.1 configure_scope Command
Syntax
configure_scope -scope scope-name-or-regex -to_name field-name
Syntax Example
configure_scope –scope e:vr_ahb –to_name cdn_ahb
Parameters
-scope scope-name-or-regex Name of source scope. This name should include the language prefix.
For example: -scope e:vr_ahb
-to_name field-name The name of the target scope. This name can contain $0..$9 refer to
the sub-matches of the scope-name-or-regex.
Description
This command should be used to configure properties of a scope (only its target name).
Note that a scope of a type can be defined using configure_scope or configure_type. If both commands
are relevant for a specific type, then the configure_type takes effect, because it is more specific.
6.4.2 configure_type Command
Syntax
configure_type
-type source-type-name-or-regex
-skip_field field-name-or-regex
-pass_field field-name-or-regex
-to_name name
-to_scope scope-name
-use_existing
-skip_type
Syntax Example
configure_type –type e:vr_ahb::ahb_burst -skip_field driver \
-skip_field parent_unit -to_name AhbBusrt

configure_type Command
Parameters
-type source-type-name-or-regex Name of the source type. This name should be qualified and should
include the language prefix. For example:
-type sv:cdn_ahb::ahb_burst
-skip_field field-name-or-regex Name of a field to be skipped. This parameter can be repeated for
several fields and a regular expression can be used. This should be
used to tell mltypemap to skip fields which by default are passed.
-pass_field field-name-or-regex Name of field to be passed. The parameter can be repeated for several
fields and a regular expression can be used. This should be used to
tell mltypemap to pass field which by default is skipped.
-to_name name Target name of the type. The target name should be the simple, non
qualified name. For example, “-to_name packet”. Note that this name
can contain $0..$9; refer to sub matches in the
source-type-name-or-regex.
-to_scope scope-name Name of the scope where the type has to be defined. By default, the
target scope is the same as the scope of the source type. Note that the
scope can be set also using the configure_scope command; in this
case, the configure_type command wins since it is more specific.
-use_existing Tells mltypemap to not generate a type definition for this type, but
rather to use the existing definition. mltypemap assumes that this type
already exists with the name as given with -to_name. This
configuration should typically be used to support consecutive
invocations of mltypemap, for example, if part of the hierarchy was
already generated by previous invocation.
-skip_type Tells mltypemap to skip this type. Relevant only if this type has to be
generated as a subtype of a parent type. In this case, the type and all
its subtypes will be skipped. This configuration should be used if a
sub-hierarchy of a mapped class is not relevant for ML
communication.
Description
Use this command to configure properties of an exported type. The -type argument should be used to
describe the source type. The other parameters are used for the configuration itself.

configure_field Command
See Also
● “Referencing when Subtypes in Configuration Commands” on page 6-16
6.4.3 configure_field Command
Syntax
configure_field
-field field-name-or-regex
-to_name field-name
-norand | -rand | -randc
-public | -protected | -private
-pack | -nopack
-print | -noprint
-compare | -nocompare
-copy | -nocopy
-dec|-hex|-bin
-to_cpp_pointer
-use_cpp_type | -use_sc_type
-map_as2value
Syntax Example
configure_field –type sv:vr_axi::axi_packet
-field data
-to_name AxiData
-nopack
-hex
Parameters
-type source-type-name-or-regex Name of source type. This name should be qualified and should
include the language prefix. The name can contain regular
expressions. For example:
-type sv:cdn_axi::axi_packet
-field field-name-or-regex Name of the source field. This switch is mandatory.

configure_field Command
-to_name field-name The target name of the field. This name can contain $0..$9 to refer to
sub-matches in field-name-or-regex.
-norand | -rand | -randc Controls the randomization type of the target field. Relevant only if
target is e or SystemVerilog. The default is the same as the source
field.
-public | -protected | -private Controls on the target access level of the field. (The default is the
same access level as the source field.)
-pack | -nopack Controls whether this field should be part of the packing. Default is
pack.
-print | -noprint Controls whether this field is printed. Has no affect if the target
language is e. Default is print.
-compare | -nocompare Controls whether this field should be part of the comparing. Has no
affect if the target language is e. Default is compare.
-copy | -nocopy Controls whether this field should be part of the copying. Has no
affect if the target language is e. Default is copy.
-dec | -hex | -bin Sets the radix for this field. Has no effect if the target language is e.
-to_cpp_pointer Relevant when the target language is SystemC, indicate that the field
should be mapped into pointer in C++.
-use_cpp_type | -use_sc_type Integers of 8,16, and 64 bits are mapped by default to SC types:
sc_(u)int<8>, sc_(u)int<16> and sc_(u)int<64> respectively. Integers
of size 32 bits are mapped by default to C++ type int or unsigned int.
This option can be used to change the default of such mapping. The
mapping is done per field, and the field can be of the integer type of
dynamic or static array of this type.
-map_as2value Instructs mltypemap to map a four-value scalar field as two-value.

This is relevant only for SystemVerilog fields whose type is
four-value scalar or array of four-value scalars.
Note that the mapping of four-value scalar as two-value scalars can

be done globally using the configure_code command. When the
latter is used, this command has no impact.

configure_enum_item Command
Description
Use this command to configure properties of an exported field. The -type and -field parameters should
be used to describe the source field. The other parameters are used for the configuration itself.
See Also
6.4.4 configure_enum_item Command
Syntax
configure_enum_item
-item enum-item-name-or-regex
-to_name enum-item-name
Syntax Example
configure_enum_item –type sv:vr_ahb::color –item RED –to_name AHB_RED
Parameters
-type source-type-name-or-regex Name of source enumerated type. This name should be qualified and
should include the language prefix. The name can contain regular
expressions.
-item enum-item-name-or-regex Name of the source enum item. This name can contain regular
expressions.
-to_name enum-item-name The target name of the enum item. The default is the same name as
the source enum item. The target name can contain $0..$9 refer to
sub-matches in the enum-item-name-or-regex.
Description
Use this command to configure the target name of an enumerated type item. The -type and -item
parameters should be used in order to describe the source item.

print_type Command
6.4.5 print_type Command
Syntax
print_type
Syntax Example
print_type -type sv:vr_ahb::burst
Parameters
-type source-type-name-or-regex Name of type to be printed. The name can contain regular
expressions. This argument can be repeated.
Description
Print information about a specific type or types. The command will print basic information on the type.
And, if any configuration was applied to it, on the relevant configuration properties.
See Also
6.4.6 configure_code Command
Syntax
configure_code
-lang SV | SC | SN | e
-header_code code
-gen_adapter_config
-adapter_config_name adapter-config-unit-name
-ovm|-uvm
-map_all_as_2value
Syntax Example
configure_code –lang sv -header code {ìnclude "my_kind_pkg.svh"}

configure_code Command
configure_code -ovm | -uvm
Parameters
-lang SV | SC | SN | e Name of target language for which the configuration will be applied.
This is mandatory argument.
-header_code code Instructs mltypemap to add the code in the top of the generated
header code.
-gen_adapter_config Instructs mltypemap to generate adapter config settings when

mapping types from SV to e. More information on this can be found
in e over Class-Based SystemVerilog chapter of the UVM
Multi-Language Methodology.
-adapter_config_name Name of the adapter unit name. Relevant only when

adapter-config-unit-name -gen_adapter_config is given. The default name is the base-name
suffixed with _adapter_config.
-ovm|-uvm Instructs mltypemap to generate UVM or OVM compliant code. The

default is uvm. Note that this option is general, and the language
should not be given.
-map_all_as_2value Instructs mltypemap to map all SystemVerilog four-value scalars as

two-value scalars. Relevant only when the -lang is SV.
Description
Use this command for general configuration of the generated code.
The option -header_code can be used to insert code into the generated header code. This is useful, for
example, when existing types are used and their header file has to be imported/included.
The third and fourth options are used to instruct mltypemap to generate adapter unit code for the e over
SV flow. Refer to e over Class-Based SystemVerilog chapter of the UVM Multi-Language Methodology
for more reference on this. The generated adapter config code implements the necessary logic to allow
the mapped types to be passed between the source and target languages through method ports. The
adapter config hooks used are described in “Mixed-Language Sequences API” on page 3-2.
Note that in this case, the adapter unit code will be generated in file called base-name_adapter_config.e.
The -ovm|-uvmoption instructs mltypemap whether to generate OVM or UVM code. The default is to
generate UVM code. Note that this option is general, and cannot be applied to a specific language.

mltypemap Limitations for this Release
The -map_all_as_2value option instructs mltypemap to map all four-value scalars as two-value scalars.
Note that this can be configured also per-field using the configure_field -map_as_2value option, Note
however, that when global configuration is given, the per-field configuration has no impact.
6.5 mltypemap Limitations for this Release

The current version of mltypemap is the first phase of implementation, and has the following
limitations:
● Parameterized types are not supported.

● Setters/getters are not supported. Thus, if private/protected fields are mapped, the serialization code
may not be compiled.
● Static fields cannot be mapped.
● No serialization code is generated for SystemC. Thus, all fields in SystemC should be paced
(otherwise an error is given).
● when subtypes are mapped as flattened classes. Mapping when subtypes into a hierarchy of classes
is not supported.
● You cannot trim part of the when hierarchy. When a struct containing when subtypes is flattened,
all its when subtypes are passed.
● SystemVerilog input limitation: Packed structs are not supported.
● Mapping of units and sequencers (drivers in e) are not supported. These fields must be configured
as skipped.

7 Multi-Language TLM 2.0
This chapter describes
● “Multi-Language TLM 2.0 Interface” on page 7-1— describes the SystemC side of the multi-language
TLM2 interface.
● “TLM 2.0 Interface User View for e” on page 7-10 — the basic use model of the TLM 2.0 interface
for e, and includes an example that demonstrates the feature.
You can find additional information in the Incisive Specman Elite Testbench documentation that
describes the additions to Specman to support TLM 2.0 in both e-to-e and multi-language transactions.
It describes the TLM2.0 data types and related types, the TLM2.0 sockets, and socket binding. The new
information is available in these locations:
● “e Ports” chapter of the Specman e Language Reference

● “Using e TLM 2 Sockets” chapter of the Specman Integrators Guide
7.1 Multi-Language TLM 2.0 Interface

This section describes the SystemC side of the new multi-language TLM 2.0 (ML-TLM2) interface.
This interface is based on the “UVM Integration with SystemC TLM2” example, delivered by Cadence to
Accellera in 2010.
This version of the ML-TLM2 supports only an interface between e and SystemC. The interface
between SystemVerilog UVM TLM2 and other languages will be added later. The e side is described in
the Incisive Specman Elite Testbench documentation.
This version:
● Supports ML communication via combined forward and backward, blocking and non-blocking
transport interfaces
● Automates binding of SystemC and e initiator and target sockets

Multi-Language TLM 2.0
Multi-Language Socket Binding in SystemC
● Allows passing of the generic payload, phase and timing annotation arguments through the interface
methods of the sockets in different languages
● Supports extensions of the generic payload
7.1.1 Multi-Language Socket Binding in SystemC

To enable ML socket connection, the SystemC user must include the ml_tlm2.h header file (located in
CDS_INST_DIR/tools/uvm-1.1/uvm_lib/uvm_ml/sc/ml_uvm). The file contains declarations of
the Cadence proprietary function ml_tlm2_connect() and macros such as the following:
ML_TLM2_REGISTER_INITIATOR
ML_TLM2_REGISTER_TARGET
ML_TLM2_GP_BEGIN
ML_TLM2_GP_END
ML_TLM2_GP_EXT_BEGIN
ML_TLM2_GP_EXT_END
ML_TLM2_FIELD
7.1.1.1 Registration of Sockets

A SystemC socket needs to be registered procedurally before it can be connected to a foreign language
socket. This requirement is similar to the existing ML-TLM1 mechanism. The registration macros
ML_TLM2_REGISTER_TARGET and ML_TLM2_REGISTER_INITIATOR can be invoked only in
the module construction phase (for example, in a constructor of a SystemC module).
Table 7-1 ML_TLM2_REGISTER_TARGET and ML_TLM2_REGISTER_INITIATOR
Macros, Argument Definitions
module_i A reference to a module which instantiates the target socket
tran_t Transaction type (an actual run-time argument can be a subtype derived from
the type declared here)
sckt A socket field (class member) name (not quoted) in module_i
buswidth Bus width
Return value Full hierarchical socket name which should be later supplied to
ml_tlm2_connect(). The type of the return value is STL std::string.

The macro can only be used in a class that has a name() method (for example, a module); in particular it
cannot be used in sc_main(). The supported socket types are the standard types tlm_target_socket,
tlm_initiator_socket and their subclasses (for example, simple_target_socket).
Example
#include "systemc.h"
#include "ml_tlm2.h"
using namespace tlm;

using namespace tlm_utils;
…
class simple_memory : public sc_module {
public :
…
// target socket where the TLM2 transactions are received
simple_target_socket<simple_memory> tsocket;
// b_transport implementation method for the TLM2 transactions

virtual void b_transport(tlm_generic_payload& tx, sc_time& dt);
virtual tlm_sync_enum nb_transport_fw(tlm_generic_payload& tx,
tlm_phase& phase,
sc_time& delay );
…
};
class top_sc_dut : public sc_module {
public :
simple_memory mem_0; // simple memory module instance
top_sc_dut(sc_module_name name_) : sc_module(name_), mem_0(){

std::string full_socket_name =
ML_TLM2_REGISTER_TARGET(
mem_0,
tlm_generic_payload,
tsocket,
32
);
…
}
};
Macros ML_TLM2_REGISTER_TARGET_WITH_PROTOCOL and

ML_TLM2_REGISTER_INITIATOR_WITH_PROTOCOL are the same as
ML_TLM2_REGISTER_TARGET and ML_TLM2_REGISTER_INITIATOR with exception that they
allow registering sockets defined with user-defined protocol types.
When using the _WITH_PROTOCOL option, add as a fifth parameter the struct describing the protocol
types. For example:
struct extended_burst_protocol_types {
typedef extended_burst tlm_payload_type;
typedef tlm_phase tlm_phase_type;
};
7.1.1.2 Inter-Language Connection of Sockets

The sockets defined in different languages can be connected with help of function ml_tlm2_connect()
defined in ml_tlm2.h in namespace ml_uvm.
Syntax:
void ml_tlm2_connect(std::string initiator_socket_name, std::string target_socket_name, bool
map_transactions = [0|1] )
Table 7-2 ml_tlm_2_connect Definition
std::string initiator_socket_name Full hierarchical socket name. If the initiator socket is in
SystemC, the full name should be obtained with help of
ML_TLM2_REGISTER_INITIATOR[_WITH_PROT
OCOL]
std::string target_socket_name Full hierarchical socket name. If the target socket is in
SystemC, the full name should be obtained with help of
ML_TLM2_REGISTER_TARGET[_WITH_PROTOC
OL]

Table 7-2 ml_tlm_2_connect Definition
bool map_transactions Enables transaction mapping between the forward and
backward paths of a non-blocking transaction.
A value of 0—the default behavior—is that the actual

transaction passed to the backward path (the initiator’s
implementation for nb_transport_bw) is not the same
object as the user sent on the forward path (using
nb_transport_fw) to the target.
A value of 1 forces the mechanism into mapping

forward and backward transactions so the same object
that was sent is also on the backward path. (SystemC
users will expect both objects to be the same, because in
SystemC, objects are passed by reference. In
multi-language connections, objects are passed by copy,
so the user will see two different objects.)
Return value void
The e socket names must match the normal e port hierarchical names (starting from sys). The order of
the arguments is significant—the initiator socket name should always be specified before the target
socket name.
Continuing the example from the example in Section 7.1.1.1, “Registration of Sockets,” on page 7-2:
Example
top_sc_dut(sc_module_name name_) : sc_module(name_), mem_0(){
… // See above
string full_target_socket_name =
ML_TLM2_REGISTER_TARGET(mem_0,
tlm_generic_payload,tsocket,32);
ml_tlm2_connect("sys.simple_env.driver.initiator_socket",
full_target_socket_name);
}
Socket connection can be done in any supported language, not necessarily on the SystemC side; you can
currently connect from either e or SystemC.

Transaction Type Registration
7.1.2 Transaction Type Registration

ML-TLM2 requires that all supported transaction types, other than tlm_generic_payload, shall derive
from the base class tlm_generic_payload. Additionally, the transaction types, derived from the base
class tlm_generic_payload, must be registered using the macros ML_TLM2_GP_BEGIN,
ML_TLM2_FIELD[_...] and ML_TLM2_GP_END, as shown in the example below.
The transaction type registration is necessary because it automates the data transformation procedures
used by the underlying implementation.
The user can specify these macros in any scope (in a .h or .cpp file) where the transaction type is
visible.
Table 7-3 ML_TLM2_GP_BEGIN and ML_TLM_2_GP_END Macros, Argument
Definition
T Transaction type
The list of supported data member (field) types can be found in Section 8.12, “Passing Transaction Data
by Value across SystemC Language Boundary,” on page 8-18 in the UVM Multi-Language Reference. A
transaction class data member can also be a class derived from uvm_object or std::vector<T>.
Classes that are not derived from uvm_object cannot be used as transaction members.
Each field of the user-defined transaction class, which is passed between the languages, must be
specified using one of the following macros: ML_TLM2_FIELD, ML_TLM2_FIELD_ENUM,
ML_TLM2_FIELD_ARRAY or ML_TLM2_FIELD_ARRAY_ENUM. The macro ML_TLM2_FIELD
must be used for all supported field types, except enumerated types and pointers used for declaration of
C-style arrays. A field of an enumerated type must be registered using ML_TLM2_FIELD_ENUM. An
array declared using a pointer must be registered using ML_TLM2_FIELD_ARRAY or
ML_TLM2_FIELD_ARRAY_ENUM (if the array elements are enumerated types). Note that
std::vector must also be registered using ML_TLM2_FIELD and not ML_TLM2_FIELD_ARRAY.
Table 7-4 ML_TLM2_FIELD Macro, Argument Definition
F Field (class member) name
Note The syntax uses non-quoted field names, such as ML_TLM_FIELD(name) rather than
ML_TLM_FIELD("name"). Refer to the section “Example” on page 7-7 to see code showing this syntax.

Transaction Type Registration
Table 7-5 ML_TLM2_FIELD_ENUM Macro, Argument Definitions
T Field (class member) type
f Field (class member) name
Table 7-6 ML_TLM2_FIELD_ARRAY and ML_TLM2_FIELD_ARRAY_ENUM Macros,

Argument Definitions
T Array element type
F Field (class member) name
n Number of array elements. The actual argument shall be any
expression that can be evaluated in the context of the macro. If the
size is represented by a class member it shall be specified using the
macro ML_TLM2_LOCAL (see example below)
Example
#include <vector>
#include "ml_tlm2.h"
…
using namespace std;
enum pv_burst_t {
PV_FIXED = 0,
PV_INCR,
PV_WRAP
};
class extended_burst: public tlm_generic_payload
{
public:
extended_burst() : m_cache_hint(0), m_burst(PV_FIXED) {}
unsigned char m_cache_hint;
pv_burst_t m_burst;
int m_transfer_size;
int * m_transfer;
vector<int> m_vector;
};
ML_TLM2_GP_BEGIN(extended_burst)
ML_TLM2_FIELD(m_cache_hint)

Generic Payload Extensions
ML_TLM2_FIELD_ENUM(pv_burst_t, m_burst)
ML_TLM2_FIELD(m_transfer_size)
ML_TLM2_FIELD_ARRAY(int, m_transfer,
ML_TLM2_LOCAL(m_transfer_size))
ML_TLM2_FIELD(m_vector)
ML_TLM2_GP_END
7.1.3 Generic Payload Extensions

ML-TLM2 supports only extensions which inherit from the tlm_extension base class. Additionally, an
extension type needs to be registered using the macros ML_TLM2_GP_EXT_BEGIN and
ML_TLM2_GP_EXT_ END (see the example below). An extension can be added to a transaction on a
per-instance basis; hence it should not be specified in ML_TLM2_GP_BEGIN/END which is
type-specific.
Table 7-7 ML_TLM2_GP_EXT_BEGIN and ML_TLM2_GP_EXT_END Macros, Argument
Definition
T Extension type
The class members (fields) of the extension shall be registered with help of the macros
ML_TLM2_FIELD, ML_TLM2_FIELD_ENUM, ML_TLM2_FIELD_ARRAY or
ML_TLM2_FIELD_ARRAY_ENUM, described above.
Example
Let’s assume that the type extended_burst from the examples above contains a registered extension of
type ID_extension as follows:
struct ID_extension: tlm::tlm_extension<ID_extension>
{
ID_extension() : transaction_id(0) {}
…
unsigned int transaction_id;
};
Then the type registration should be provided as follows:

ML_TLM2_GP_EXT_BEGIN(ID_extension)
ML_TLM2_FIELD(transaction_id)
ML_TLM2_GP_EXT_END(ID_extension))

Generic Payload Memory Management
7.1.4 Generic Payload Memory Management

The ML-TLM2 user does not control allocation of the SystemC incoming transactions (directed from e
to SystemC). Thus, the implementation takes responsibility of the memory management (allocation and
de-allocation) by providing an explicit memory manager per type of transaction. The transaction is
returned to the memory manager’s pool at the end of the incoming call.
The transactions are passed by copy, unlike in native SystemC TLM2. From the user perspective, it
means that the outgoing transactions can be de-allocated immediately, because the same objects will
never appear, for example, on the backward path. The user must not expect to receive the same pointers
to the incoming transactions in the sequential non-blocking interface calls.
Note that TLM 2.0 does not support a memory manager for the tlm_phase objects. Thus, the ML-TLM2
implementation reuses the objects, allocated for the incoming SystemC calls, using an internal pool. Do
not use these objects, except in the context of the functions b_transport() and nb_transport_fw().
SystemC TLM2 requires that all data in the tlm_generic_payload data array is in simulation
host-endian format. It is the UVM-e user’s responsibility to ensure that all data is in simulation
host-endian format when sending or receiving data from a SystemC TLM2 model.
7.1.5 Interface Limitations

Limitations are:
● The ML interface class type arguments (the generic payload and the phase) are passed by copy.
Consequently, the changes made to argument values are not immediately visible across language
boundaries. They are updated at the end of the call.
● The following features of the SystemC TLM2 standard are not supported in the current ML-TLM2
implementation:
● User-defined transaction types other than tlm_generic_payload and its subclasses
● User-defined extension types other than derived from tlm_extension
● User-defined, non-default, phase types
● Multi-sockets
● The global quantum
● The direct memory interface (DMI)
● Payload event queues
● Callbacks registration

TLM 2.0 Interface User View for e
● Though internal implementation of ML-TLM2 is transparent to the user, be aware that the underlying
mechanism is built on top of the existing ML UVM infrastructure. Consequently, the user must use
irun in the ML UVM mode (using one of the following switches: -uvmtest, -uvmtop, or -ml_uvm,
described in “ML-UVM irun Command Line Switches” on page 4-1).
● Enabling transaction mapping using ml_tlm2_connect() results in a performance cost because more
copying between objects occurs.
7.2 TLM 2.0 Interface User View for e

This section describes the basic use model of the TLM 2.0 interface for e. It is based on an “Example” on
page 7-22 that demonstrates the feature, and contains some detailed code examples.
See Also
● “Multi-Language TLM 2.0 Interface” on page 7-1 for the SystemC interface description.
● “e Ports” chapter of the Specman e Language Reference
● “Using e TLM 2 Sockets” chapter of the Specman Integrators Guide
7.2.1 Introduction—TLM 2.0 Interface Example

The TLM 2.0 interface for e provides communication between e and SystemC using TLM 2.0 sockets
and tlm_generic_payload. All code examples in this section are based on a simple example
demonstrating the various communication modes—AT (blocking) and LT (non-blocking)— and the use
of tlm_generic_payload extensions.
The user’s SystemC code should include ml_tlm2.h. To compile the code, you must add the following
to the compiler command line:
-I`ncroot`/tools/uvm/uvm_lib/uvm_ml/sc/ml_uvm
See the “Example” on page 7-22 for an example irun command file.
The example uses two SystemC TLM modules: a memory model used as a slave having a target socket
and an initiator module used as a master driving an initiator socket. See the “Example” on page 7-22 for
detailed definition of the models.
The testbench is represented simply by a driver (BFM) connected to the SystemC module through
ML-TLM2 sockets.

Introduction—TLM 2.0 Interface Example
e Testbench Top SystemC Module
Sequencer Master BFM Memory Module

e e SystemC
Slave BFM Initiator Module

e SystemC
The following code shows the top-level SystemC module, which instantiates the two modules (memory
and initiator) and binds their sockets to the testbench driver sockets in the constructor.
class top_sc_dut : public sc_module {
public :
simple_memory mem_0; // tlm2 slave
simple_initiator init_0; // tlm2 master
top_sc_dut(sc_module_name name_); // constructor
};
The constructor is used to create and bind the interfaces to the sockets.
● Use the macros ML_TLM2_REGISTER_INITIATOR and ML_TLM2_REGISTER_TARGET to

register each socket in the SystemC module; the macro returns the full path to the socket.
● Use the ml_tlm2_connect() method to bind the initiator and target sockets to the target socket.
● Use the full path returned from the MACRO above to identify the SystemC socket.
● Use the e_path to identify the e socket.
The constructor code for the top-level SystemC module is as follows:

top_sc_dut(sc_module_name name_) : sc_module(name_)
,mem_0("mem_0", 0x2000)
,init_0("init_0")
{
std::string full_target_socket_name =
ML_TLM2_REGISTER_TARGET(mem_0, tlm::tlm_generic_payload, tsocket, 32);
ml_tlm2_connect("sys.simple_env.master_driver.MASTER'i_socket",
full_target_socket_name);
std::string full_init_socket_name =
ML_TLM2_REGISTER_INITIATOR(init_0, tlm::tlm_generic_payload, isocket, 32);
ml_tlm2_connect(full_init_socket_name,
"sys.simple_env.slave_driver.SLAVE't_socket");
}

Data Types Definition
Note Connecting the testbench to the DUT can be done from the e side as well. To do this, remove
the ml_tlm2_connect() in the code above and add in “simple_env”:
master_driver.i_socket.connect("top_sc_dut.mem_0.tsocket");
slave_driver.t_socket.connect("top_sc_dut.init_0.isocket");
};
The argument of the connect method shall be a quoted, full SystemC path, as returned by the
ML_TLM2_REGISTER_... macro.
7.2.2 Data Types Definition

The basic data type used in TLM 2.0 is tlm_generic_payload, which is a predefined type both in e and
in SystemC TLM. The transaction can optionally have one or more extensions. The definition of the e
tlm_generic_payload is:
struct tlm_generic_payload like any_sequence_item {
// fields
%m_address: uint(bits:64);
%m_command: tlm_command;
%m_data: list of byte;
%m_length: uint;
%m_response_status: tlm_response_status;
%m_byte_enable: list of byte;
%m_byte_enable_length: uint;
%m_streaming_width: uint;
%m_extensions: list of tlm_extension;
// methods
// sets
A transaction (burst) in e can be defined as tlm_generic_payload:

data_list: list of byte;
keep data_list.size() < 100;
!burst: tlm_generic_payload;
gen burst keeping {
it.m_command == TLM_WRITE_COMMAND;
it.m_address == 0x1000;
it.m_data == data_list;
it.m_length == data_list.size();
it.m_byte_enable == {};
it.m_byte_enable_length == 0;
it.m_streaming_width == 1;

it.m_response_status == TLM_INCOMPLETE_RESPONSE;
it.m_extensions.size() == 0;
};
Because tlm_generic_payload is like any_sequence_item, you can use this type directly in a do
statement in a sequence.
extend WRITE gp_burst_seq {
body() @driver.clock is only {
do burst keeping { // random read
it.m_command == TLM_READ_COMMAND;
it.m_length == data_len;
it.m_data.size() == data_len;
};
};
};
7.2.2.1 Generic Payload Extensions in e

To generate a new extension in e, define the type based on tlm_extension_base. For example, the
amba_pv_extension can be defined as follows:
struct amba_pv_extension like tlm_extension {
%m_burst_length: uint;
%m_size: uint;
%m_ctrl: amba_pv_control;
%m_burst: amba_pv_burst_t;
};
struct amba_pv_control {
%m_id: uint;
%m_privileged: bool;
%m_non_secure: bool;
%m_instruction: bool;
%m_exclusive: bool;
%m_locked: bool;
%m_bufferable: bool;
%m_cacheable: bool;
%m_read_allocate: bool;
%m_write_allocate: bool;
keep soft m_id == 0;
};

Then, a new extension can be generated as follows (most fields of m_ctrl are randomized):
!axi_extension: amba_pv_extension;
!amba_ctrl: amba_pv_control;
gen amba_ctrl keeping {
.m_id == 11;
.m_privileged == TRUE;
};
gen axi_extension keeping {
.m_burst_length == 16;
.m_burst == AMBA_PV_FIXED;
.m_ctrl == amba_ctrl;
.m_size == 4;
};
Note The extensions above are generated before the tlm_generic_payload, and then added
procedurally to tlm_generic_payload using:
burst.m_extensions.add(axi_extension);
See the “Example” on page 7-22 for an example of generating the tlm_generic_payload with its
extensions in a single “do”.
7.2.2.2 Generic Payload Extensions in SystemC

The corresponding type definition in the SystemC model is as follows:
● The first part is standard SystemC TLM definition of the extension.

● The last part is macro definitions for making this extension known to ML TLM2 such that it can be
transferred properly across the language boundary.
It is important that the order of the fields in the SystemC ML_TLM2 type registration macro be the same
as the order of the fields in e.
struct amba_pv_extension: tlm::tlm_extension<amba_pv_extension>
{
amba_pv_extension() : m_burst_length(0), m_size(0), m_ctrl(0),
m_burst(AMBA_PV_FIXED) {}
virtual ~amba_pv_extension() { };
virtual tlm_extension_base* clone() const {return t; }
virtual void copy_from(tlm_extension_base const &ext) { }
unsigned int m_burst_length;
unsigned int m_size;
amba_pv_control *m_ctrl;
amba_pv_burst_t m_burst;
}
// Declare the extension for ML_TLM2
ML_TLM2_GP_EXT_BEGIN(amba_pv_extension)

Master Driver (BFM) Using the Initiator Socket
ML_TLM2_FIELD(m_burst_length)
ML_TLM2_FIELD(m_size)
ML_TLM2_FIELD(m_ctrl)
ML_TLM2_FIELD_ENUM(amba_pv_burst_t, m_burst)
ML_TLM2_GP_EXT_END(amba_pv_extension)
Simple types and vectors use the ML_TLM2_FIELD declaration. For enumeration types use
ML_TLM2_FIELD_ENUM, specifying also the type as shown above.
Note amba_pv_control in the example above is a class in SystemC. For ML_TLM2 to be able to
transfer a class across language boundary, the struct must be a uvm_object defined as follows, with the
pack and unpack methods defined as required by ML_TLM:
class amba_pv_control: public uvm_object {
public:
unsigned int m_id;
bool m_privileged;
bool m_non_secure;
bool m_instruction;
bool m_exclusive;
bool m_locked;
bool m_bufferable;
bool m_cacheable;
bool m_read_allocate;
bool m_write_allocate;
UVM_OBJECT_UTILS(amba_pv_control)
amba_pv_control() {}
virtual ~amba_pv_control() {}
virtual void do_print(ostream& os) const ;
virtual void do_pack(uvm_packer& p) const ;
virtual void do_unpack(uvm_packer& p) ;
virtual void do_copy(const uvm_object* rhs) ;
virtual bool do_compare(const uvm_object* rhs) const ;
}
7.2.3 Master Driver (BFM) Using the Initiator Socket

The master driver has a pull_and_drive TCM which continuously gets items from the sequencer and
sends them out through the initiator socket. To support both AT and LT use models, we added the
“blocking” switch, which controls whether the driver uses the blocking or non-blocking interface. In
addition, there is a "debug" switch that controls the usage of the transport_dbg interface.
A driver with an initiator socket must implement the nb_transport_bw() method. This method is called
by the socket when the backward channel returns the result. The code below shows an example that must
be extended according to the specific application.

Master Driver (BFM) Using the Initiator Socket
extend MASTER simple_driver {

i_socket : tlm_initiator_socket is instance;
blocking: bool; // operate in blocking(true) or non-blocking(false) mode
debug: bool; // Use debug transport channel
sequencer: simple_sequencer; // pointer to the sequencer
t: time;
ph: tlm_phase_enum;
run() is also {
start pull_and_drive_items(); // sending items from sequencer
};
// pull items from the sequencer and send them for execution to the DUT
pull_and_drive_items() @ sequencer.clock is {
while (TRUE) {
var req := sequencer.get_next_item();
t = 0;
if debug then {
var len := i_socket$.transport_dbg(req);
} else if blocking then { // use blocking interface
i_socket$.b_transport(req, t); // response returned in req
} else { // use non-blocking interface
// response received in callback nb_transport_bw()
ph = BEGIN_REQ;
var status := i_socket$.nb_transport_fw(req, ph, t);
if(status == TLM_COMPLETED) { // immediate response
ph = BEGIN_RESP;
status = nb_transport_bw(req, ph, t);
};
};
// indicate to the sequencer that item processing has completed
emit sequencer.item_done;
};
};
// example implementation of response from non-blocking transaction
nb_transport_bw(resp: tlm_generic_payload, phase: *tlm_phase_enum, t: *time):
tlm_sync_enum is {
if(resp.m_response_status != TLM_OK_RESPONSE) {
dut_error("nb_transport_bw response error: ", resp.m_response_status);
};
message(HIGH, "Response from nb_transport_bw: ", resp.m_command);
if(t != 0) { message(LOW, "Delay expected ", t); };
if(resp.m_command == TLM_READ_COMMAND && phase == BEGIN_RESP) {
print resp.m_data;
};
return TLM_ACCEPTED;
};
};

Slave Driver (BFM) Using the Target Socket
Note nb_transport_bw() is a non-time-consuming method, and therefore it cannot implement any

delays. Normally, the testbench should not have to deal with delays. But if there is a need to handle them,
a TCM must be started from this method.
7.2.4 Slave Driver (BFM) Using the Target Socket

A driver with a target socket must implement the b_transport(), nb_transport_fw(), and
transport_dbg(). These methods are called by the socket when the forward channel is used by the
initiator. The code below shows an example that must be extended according to the specific application.
Note The source of the figures below is the TLM 2.0 LRM. The numeric values are shown as
examples, and are different from the actual values in the code examples described below.
Figure 7-1 The Backward Path
Phase Target
Simulation time = 100ns
Call -, BEGIN_REQ, 0ns
BEGIN_REQ
Return TLM_ACCEPTED,-,-
-, END_REQ, 0ns Call
END_REQ Return
TLM_ACCEPTED,-,-
-, BEGIN_RESP, 0ns Call
BEGIN_RESP Return
TLM_ACCEPTED,-,-
Call -, END_RESP, 0ns

END_RESP
Return TLM_COMPLETED,-,-?
Note that nb_transport_fw() is a method that cannot call time consuming code. This is why it starts a
TCM to manage the time consuming operations involved in getting the response and then respond
through the nb_transport_bw() interface.
The example code below assumes that there is a user method respond() that gets the transaction as a
parameter and returns the result.
extend SLAVE simple_driver {
t_socket : tlm_target_socket is instance;

Slave Driver (BFM) Using the Target Socket
sequencer: simple_sequencer; // pointer to the sequencer

tm: time;
// implement b_transport blocking transaction
b_transport(tr: tlm_generic_payload, t: *time): tlm_generic_payload
@sys.any is {
wait delay(t); // simulate some delay
tr = respond(tr); // return response by modifying the request
}; // b_transport()
// implement nb_transport - non-blocking transaction
nb_transport_fw(tr: tlm_generic_payload, phase: *tlm_phase_enum, t: *time):
tlm_sync_enum is {
if(phase != BEGIN_REQ && phase != END_RESP) {
dut_error("SLAVE driver nb_transport_fw received phase ", phase);
};
start nb_transport_fw_respond(tr, phase, t);
}; // nb_transport_fw
// Time consuming method started from non-blocking call
nb_transport_fw_respond(tr: tlm_generic_payload, phase: tlm_phase_enum,
t: time)@sys.any is {
wait delay(t); // simulate delay
if(phase == BEGIN_REQ) {
phase = END_REQ; // acknowledge the request
tm = 0;
var status := t_socket$.nb_transport_bw(tr, phase, tm);
if(status != TLM_COMPLETED && status != TLM_ACCEPTED) {
dut_error("SLAVE driver nb_transport_bw received unexpected status ",
status);
};
phase = BEGIN_RESP; // send the response
tm = 0;
status = t_socket$.nb_transport_bw(respond(tr), phase, 0);
if(status != TLM_COMPLETED && status != TLM_ACCEPTED) {
dut_error("SLAVE driver nb_transport received unexpected status ",
status);
};
} else if(phase == END_RESP) { // nothing to do
} else {
dut_error("SLAVE driver received unexpected phase ", phase);
};
};
transport_dbg(tr: tlm_generic_payload): uint is {
if (tr.m_command == TLM_READ_COMMAND) {
tr.m_data.clear();
for i from 0 to tr.m_length-1 {
tr.m_data.add(i%256);
};

Driving the Simulation with Sequences
};
return tr.m_length;
};
};
Note The TLM 2.0 LRM defines several use cases for a slave driver. (See sections 4.1.2.9 through
4.1.2.11, “Message sequence chart.”) The code above is similar to the first use case “Using the backward
path.” The code “Example” on page 7-22 has additional code demonstrating the other use cases.
7.2.5 Driving the Simulation with Sequences

This section shows how to use sequences to drive the DUT.
7.2.5.1 Simple Write Sequence

A simple example of writing a sequence is shown below. It generates and sends a WRITE transaction
with a random list of bytes.
extend WRITE gp_burst_seq {
address: uint(bits:64);
data_len: int;
keep soft data_len in [4..4095];
keep data_list.size() == data_len;
do burst keeping {
it.m_command == TLM_WRITE_COMMAND;
it.m_address == address;
};
};
};
When the driver is working in blocking mode, at the end of the “do”, the response status indicates
whether the transaction was successful. If the socket is used in non-blocking mode, the transaction might
not be completed, and a response may be received on the backward path later.
The read sequence is similar, and in the case of blocking calls, both the m_response_status and m_data
fields are updated upon completion.

Driving the Simulation with Sequences
7.2.5.2 Non-Blocking Read Sequence

To use the non-blocking interface, you must constrain the driver (modifying the code example above) as
follows:
keep blocking == FALSE; // set driver to non-blocking
};
The non-blocking read sequence returns as soon as the request is delivered. In this example, we generate
the item first and then execute it using driver.execute_item().
extend NB_READ gp_burst_seq {
keep soft address[1:0] == 0; // address should be word-aligned by default
data_len: int;
!rd_burst: tlm_generic_payload;

gen rd_burst keeping {
it.m_command == TLM_READ_COMMAND;
it.m_data.size() == data_len;
};
driver.execute_item(rd_burst);
}; // body()
}; // extend NB_READ
The response is received in the driver’s nb_transport_bw() which can be extended by the user. The
default implementation is as follows:
nb_transport_bw(resp:tlm_generic_payload, p:*tlm_phase, t:*time):
tlm_sync_e is only {
if(resp.m_command == TLM_READ_COMMAND &&
resp.m_response_status == TLM_OK_RESPONSE && p == BEGIN_RESP) {
print resp.m_data;
};
};
};

Comparison of TLM2 with Previous Manual Solution
7.2.5.3 Memory Management Considerations

The initiator is responsible for managing the memory for transactions. When the initiator is e, ML-TLM
manages the transactions in a pool. When the initiator is SystemC, the user is responsible for
implementing the appropriate memory management.
In ML-TLM however, common methods of memory management might not work well because the
response transaction returned by e is not the same as the original request generated in SystemC.
Whenever possible, use an ad-hoc memory manager that takes into consideration the fact that
transactions passed through language boundaries are copied rather than passed by reference.
7.2.6 Comparison of TLM2 with Previous Manual Solution

This section compares the new automated multi-language TLM2 mechanism with the previous TLM1
manual solution.
The TLM 2 interface further enhances the “UVM Integration with SystemC TLM2” example, provided by
Cadence to Accellera. The basic approach of using TLM1 ML as an underlying implementation
mechanism remains intact.
The main areas of enhancement are:
● Support of the native SystemC tlm_generic_payload and its subclasses

The transactions do not derive from the special uvm_gp class. The new predefined macros
ML_TLM2_GP_BEGIN and ML_TLM2_GP_EXT_BEGIN automate packing and unpacking of
the transaction and extensions. Inheritance (subclasses of tlm_generic_payload) is supported by an
underlying factory of the wrapper classes.
● Automation of the ML connection
Predefined macros ML_TLM2_REGISTER_TARGET/INITIATOR() and function
ml_tlm2_connect() hide the hooking details from the user, including automatic instantiation of the
tlm1_to_tlm2 converter. The user does not need to instantiate the converter explicitly. The above
functions also spare the user the need to explicitly connect the underlying TLM1 ports and exports.
● Support of the non-blocking interfaces, including the transport forward and backward calls
● Support of the TLM2 standard phases and delay annotation arguments
● Performance improvement
The new mechanism packs tlm_generic_payload fields directly to and unpacks from the data
stream that crosses the language boundary. This implementation allows the elimination of copying
the data fields from tlm_generic_payload to the wrapper and vice versa.
● Support of tlm_generic_payload extensions

Known Limitations
The new mechanism supports extensions derived from the base class tlm_extension. The user can
choose between using the extensions or subclasses of tlm_generic_payload. In any case, it’s the
user’s responsibility to take care of compatibility between the transaction class definitions in
SystemC and e.
7.2.7 Known Limitations
7.2.7.1 ML-TLM1 Interface does not Support tlm_generic_payload

The new tlm_generic_payload type in e is not derived from uvm_object. As a result, it cannot be
transferred through the ML-TLM1 interfaces such as analysis_port, which are only supported for
uvm_object.
7.2.7.2 Classes and Struct in Extensions Must Derive from uvm_object

To be able to pass classes across language boundaries, you must use uvm_object. If an extension
contains a class likethe amba_pv_extension, this embedded class must be modified to inherit from
uvm_object. See Section 7.2.2.1, “Generic Payload Extensions in e,” on page 7-13.
7.2.7.3 Time Parameter

The testbench should not normally deal with time parameter received from the DUT. If however
transactions are received with non-zero time value, the testbench should either flag it as an error, or
spawn a TCM which can implement the wait before acting on the transaction.
7.2.8 Example
The example code is the implementation of the TLM 2.0 interface example described in Section 7.2.1,
“Introduction—TLM 2.0 Interface Example,” on page 7-10. It has a memory module implemented in
SystemC that accepts read and write commands from the e testbench. In addition it has an initiator
module which sends read and write instructions to a slave BFM in the testbench.
7.2.8.1 Running the Example

To run the example using irun, you must set the right parameters for the simulators. In our example, we
used two environment variables to point to the relevant code:
TLM_GP_ROOT is the path to the example package that can be set using:
setenv TLM_GP_ROOT `sn_which.sh ml_tlm2`
ML_UVM is the path to the ml_uvm code in the IES release:

Example
setenv ML_UVM `ncroot`/tools/uvm/uvm_lib/uvm_ml/sc/ml_uvm
Below is an example of simple run.f file that can be used with irun.
// specify that the design is SystemC TLM 2.0
-sysc
-tlm2
// turn on tlm2 transaction recording
-sctlmrecord
// specify the SC env as a top
-sctop top_sc_dut
// specify SystemC include dirs
-I${TLM_GP_ROOT}/examples/sc
-I${ML_UVM}
-DSC_INCLUDE_DYNAMIC_PROCESSES
// enable debug and visibility
-access +rw
-g -debug
// do not compile the e code (slower to simulate, but faster to bring up)
-nosncomp
-snsc
-intelligen
// enable Specman's sequence recording in the Simvision waveform
-snprerun "trace seq trans"
-snprerun "set message MEDIUM"
// turn on NC-SystemC synchronization mechanism
-scsynceverydelta ON
// specify SystemC test files
${TLM_GP_ROOT}/examples/sc/simple_memory.cpp
${TLM_GP_ROOT}/examples/sc/top_sc_dut.cpp
${TLM_GP_ROOT}/examples/sc/simple_initiator.cpp
// specify top e testbench files
${TLM_GP_ROOT}/e/ml_tlm2_top.e
${TLM_GP_ROOT}/examples/e/simple_tb.e
7.2.8.2 The Memory Slave Module

The code below shows the definition of the slave memory module with its target socket.
class simple_memory : public sc_module,
,tlm::tlm_fw_transport_if<tlm::tlm_base_protocol_types>
{
public :
tlm::tlm_target_socket<32, tlm::tlm_base_protocol_types> tsocket;
simple_memory(sc_module_name name_, unsigned size_ = 0x100000);
~simple_memory();

Example
virtual void b_transport(tlm::tlm_generic_payload& tx, sc_time& dt);

virtual tlm::tlm_sync_enum nb_transport_fw(tlm::tlm_generic_payload& trans,
tlm::tlm_phase& phase, sc_time& delay );
void mem_read_write(tlm::tlm_generic_payload& tx);
void peq_cb(tlm::tlm_generic_payload& trans, const tlm::tlm_phase& phase);
virtual bool get_direct_mem_ptr(tlm::tlm_generic_payload& trans, tlm::tlm_dmi&
dmi_data) {
return false;
}
virtual unsigned int transport_dbg(tlm::tlm_generic_payload& trans) {
return 0;
}
private :
unsigned size; // size of the memory (in bytes)
unsigned char * mem_array; // actual memory data
public :
peq_with_cb_and_phase<simple_memory, tlm::tlm_base_protocol_types> m_peq;
};
The code above uses TLM sockets. To use simple sockets instead, you can declare the socket as follows:
simple_target_socket<simple_memory, 32, tlm::tlm_base_protocol_types > tsocket;
Note When using simple socket there is no need to implement get_direct_mem_ptr() and
transport_dbg(). Also, for simple sockets, you can register a callback for every interface method.
The constructor for this module using TLM socket is as follows:

simple_memory(sc_module_name name_, unsigned size_) :
sc_module(name_),
tsocket("tsocket"),
size(size_),
m_peq(this, &simple_memory::peq_cb)
{
tsocket(*this);
mem_array = new unsigned char[size];
}
The constructor using simple sockets looks as follows:

simple_memory(sc_module_name name_, unsigned size_) :
sc_module(name_),
tsocket("tsocket"),
size(size_),
m_peq(this, &simple_memory::peq_cb)
{
tsocket.register_b_transport(this, &simple_memory::b_transport);
tsocket.register_nb_transport_fw(this, &simple_memory::nb_transport_fw);

Example
mem_array = new unsigned char[size];

}
7.2.8.3 The Initiator Module

The following code shows the initiator module with its initiator socket.
class simple_initiator: public sc_module,
virtual public tlm::tlm_bw_transport_if<tlm::tlm_base_protocol_types>
{
public :
mm<tlm_generic_payload> m_mm;
int data[16];
tlm_utils::peq_with_cb_and_phase<simple_initiator,
tlm::tlm_base_protocol_types> m_peq;
tlm::tlm_initiator_socket<32, tlm::tlm_base_protocol_types> isocket;
void invalidate_direct_mem_ptr(sc_dt::uint64 start_range,
sc_dt::uint64 end_range) {};
SC_HAS_PROCESS(simple_initiator);
simple_initiator(sc_module_name name_);
void thread_process();
void peq_cb(tlm::tlm_generic_payload& trans, const tlm::tlm_phase& phase);
tlm::tlm_sync_enum nb_transport_bw(tlm::tlm_generic_payload& trans,
tlm::tlm_phase& phase, sc_time& delay );
};
The code above uses TLM sockets. To use simple sockets instead one can declare the socket as follows:
simple_initiator_socket<simple_initiator, 32, PROTOCOL_TYPES> isocket;
The constructor with TLM socket is as follows:

simple_initiator(sc_module_name name_) :
sc_module(name_),
m_peq(this, &simple_initiator::peq_cb),
isocket("isocket")
{
isocket(*this);
SC_THREAD(thread_process);
}
The constructor with simple socket is slightly different:
simple_initiator(sc_module_name name_) :
sc_module(name_),
m_peq(this, &simple_initiator::peq_cb),
isocket("isocket")
{
isocket.register_nb_transport_bw(this,

Example
&simple_initiator::nb_transport_bw);
SC_THREAD(thread_process);
}
7.2.8.4 Using types derived from tlm_generic_payload

To use a derived type instead of pure tlm_generic_payload, you must declare this type so that
ML_TLM2 will be able to transfer it across the language boundary.
Assume your derived type contains two additional fields.

struct extended_burst like tlm_generic_payload {
%m_cache_hint: byte;
%m_cache_status: byte;
};
In SystemC code the type is declared as follows:

class extended_burst: public tlm_generic_payload
{
public:
extended_burst() : m_cache_hint(0), m_cache_status(0) {}
unsigned char m_cache_hint; // cache hint
unsigned char m_cache_status; // cache status
};
ML_TLM2_GP_BEGIN(extended_burst)
ML_TLM2_FIELD(m_cache_hint)
ML_TLM2_FIELD(m_cache_status)
ML_TLM2_GP_END(extended_burst)
When using derived types, you should also define the protocol types and use this struct when creating
the interface.
struct extended_burst_protocol_types {
typedef extended_burst tlm_payload_type;
typedef tlm_phase tlm_phase_type;
};
In the top-level constructor, define the interface as follows:

std::string full_target_socket_name =
ML_TLM2_REGISTER_TARGET_WITH_PROTOCOL(mem_0, extended_burst, tsocket, 32 ,
extended_burst_protocol_types);
7.2.8.5 Using Arrays in Extensions

To use array fields in extensions, you must pass the length of the array before the array address as
follows:

Example
struct amba_pv_extension: public tlm_extension<amba_pv_extension> {

int m_array_size;
int * m_array;
};
ML_TLM2_GP_EXT_BEGIN(amba_pv_extension)
ML_TLM2_FIELD(m_array_size);
ML_TLM2_FIELD_ARRAY(int,m_array,ML_TLM2_LOCAL(m_array_size));
ML_TLM2_GP_EXT_END(amba_pv_extension)
This will match the corresponding e code:

struct amba_pv_extension like tlm_extension {
%!m_array_size: int;
%m_array: list of int;
};
7.2.8.6 Using Nested Classes

Objects passed across the language boundary must be derived from uvm_object. If the transaction
contains a member that is a nested class, it should be defined according to the rules of uvm_object in the
SystemC side and registered accordingly.
For example, if the following e struct is used as a member of an extension or a class derived from
tlm_generic_payload:
struct nested_class {
%nested_int: int;
};
Then, the SystemC code must define it as follows:

class nested_class: public uvm_object {
public:
int nested_int;
UVM_OBJECT_UTILS(nested_class)
nested_class() {}
virtual ~nested_class() {}
virtual void do_print(ostream& os) const {
os << "nested_class: {" << nested_int << "}" << endl;
}
virtual void do_pack(uvm_packer& p) const {
p << nested_int;
}
virtual void do_unpack(uvm_packer& p) {
p >> nested_int;
}
virtual void do_copy(const uvm_object* rhs) {
const nested_class* drhs = DCAST<const nested_class*>(rhs);

Example
if (!drhs) { cerr << "ERROR in nested_class::do_copy" << endl; return; }

nested_int = drhs->nested_int;
}
virtual bool do_compare(const uvm_object* rhs) const {
const nested_class* drhs = DCAST<const nested_class*>(rhs);
if (!drhs) {
cerr << "ERROR in nested_class::do_compare" << endl;
return true;
}
return (nested_int == drhs->nested_int);
}
};
UVM_OBJECT_REGISTER(nested_class)
7.2.8.7 Defining an AMBA_PV sequence

You can create a higher-level sequence that encapsulates the generation of the tlm_generic_payload
with its extensions. The following example shows it for an AMBA_PV transaction. It makes use of the
mid_do() method, which is called after the generation of the item, but before it is sent.
extend AMBA_SEQ gp_burst_seq {
rw: tlm_command;
keep soft rw == TLM_IGNORE_COMMAND;
keep address[1:0] == 0;
data_len: int;
keep data_len[1:0] == 0;
keep data_list.size() == data_len;
burst_kind: amba_pv_burst_t;
keep soft burst_kind == AMBA_PV_INCR;
burst_length: uint;
keep soft burst_length in [1 .. 16];
trans_size: uint;
keep soft trans_size in [1,2,4,8,16,32,64,128];
mid_do(burst: tlm_generic_payload) is {
var axi_extension: amba_pv_extension;
gen axi_extension keeping {
.m_burst_length == burst_length;
.m_size == trans_size;
.m_burst == burst_kind;
};
burst.m_extensions.add(axi_extension);

Example
}; // mid_do(burst)
do burst keeping {
it.m_command == rw;
};
}; // body()
}; // extend AMBA_SEQ
7.2.8.8 Different Use Cases of Slave Driver

In the example above, we used the use case using the backward path as described in section 4.1.2.9 in the
TLM 2.0 LRM. Other use cases are described below.
Using the Return Path

In this use case, the slave acknowledges the request immediately, and uses the return path to send the
response.

Example
Figure 7-2 Using the Return Path

Phase Initiator Target

BEGIN_REQ
Return TLM_ACCEPTED, 10ns
END_REQ Simulation time = 110ns
-, BEGIN_RESP, 0ns Call

BEGIN_RESP
TLM_COPMPLETED, END_RESP, 5NS Return
END_RESP Simulation time = 155ns
In this case, the response sequence is simplified. Once the response is calculated it is sent using the
backward path and the transaction is terminated.
nb_transport_fw(tr: tlm_generic_payload, phase: *tlm_phase_enum, t: *time):
tlm_sync_enum is {
if(phase != BEGIN_REQ) { // acknowledge the request
dut_error("SLAVE driver nb_transport_fw received unexpected phase ", phase);
};
start nb_transport_fw_respond(tr, phase, t);
phase = END_REQ;
return TLM_UPDATED;
}; // nb_transport_fw
nb_transport_fw_respond(tr: tlm_generic_payload, phase: tlm_phase_enum,

t: time)@sys.any is {
if(phase == BEGIN_REQ) {
phase = BEGIN_RESP; // send the response
tm = 0;
var status := t_socket$.nb_transport_bw(respond(tr), phase, tm);
if(status != TLM_COMPLETED && status != TLM_UPDATED) {
dut_error("SLAVE driver received unexpected status ", status);
};

Example
} else {
dut_error("SLAVE driver received unexpected phase ", phase);
};
};
Early Completion
In this use case the slave responds to the request immediately, without using the return path. The
response is done by simply modifying the fields of the request.
Figure 7-3 Early Completion
Phase Initiator Target

BEGIN_REQ
Return TLM_COMPLETED, - , 10ns Return
END_RESP Simulation time = 110ns
In this case, the response is immediate and the transaction completes immediately.
nb_transport_fw(tr:tlm_generic_payload, phase:*tlm_phase_enum, t:*time):
tlm_sync_enum is {
if(phase != BEGIN_REQ) {
dut_error("SLAVE driver nb_transport_fw received phase ", phase);
};
if(t != 0) { message(LOW, "Delay expected ", t); };
phase = BEGIN_RESP;
t = 0;
tr = respond(tr); // return response by modifying the request
return TLM_COMPLETED;
};

8 SystemC in Mixed-Language
UVM
SystemC® can participate in UVM-based (Universal Verification Methodology) verification libraries as
a design top, in parallel with SystemVerilog and e language top modules.
To participate in creation of a verification library, a SystemC module (sc_module) has to be part of the
quasi-static hierarchy created by the simulator, rather than a static hierarchy created at elaboration stage
before invocation of the simulator. To enable this functionality, you must instruct the simulator to create
such a hierarchy before simulating your test.
The simulator performs creation and elaboration of a quasi-static hierarchy as a separate step after the
static hierarchy of the design has been created by the elaborator. The quasi-static hierarchy is created and
elaborated at simulation time 0:
● After the simulator prompt appears

● After you enter the run command at the simulator prompt
● After all SystemVerilog static initializers have executed
● Before any processes have executed
This particular point in time at which quasi-static elaboration occurs is referred to as the preinitial point
of the simulation. If a breakpoint triggers during execution of SystemVerilog static initializers, control
returns to the ncsim prompt, and SystemC quasi-static hierarchy creation and elaboration is not
performed yet. In this case, you must enter the run command again to finish executing all of the
SystemVerilog static initializers, and to perform creation and elaboration of the SystemC quasi-static
hierarchy. Typically, your first run command takes the simulation to the preinitial point, and triggers
SystemC quasi-static elaboration.
To determine the stage of quasi-static elaboration performed by the simulator, you can use the output of
the CFC function sc_quasi_static_elab_status() after calling the function from the ncsim
prompt with the Tcl call command. The output is one of the following lines:

SystemC in Mixed-Language UVM
Creating Quasi-Static Top Modules with the Simulator Command
● Before SystemC Quasi-Static Elaboration, if SystemC quasi-static elaboration has not started yet
● During SystemC Quasi-Static Elaboration, if SystemC quasi-static elaboration is in progress
● After SystemC Quasi-Static Elaboration, if SystemC quasi-static elaboration is over
The SystemC quasi-static hierarchy is visible in ncsim only after quasi-static elaboration; that is, after
the quasi-static end_of_simulation phase has been completed.
This chapter contains the following sections:
● “Creating Quasi-Static Top Modules with the Simulator Command” on page 8-2
● “Creating Quasi-Static Top Modules Programmatically” on page 8-3
● “Quasi-Static Elaboration” on page 8-4
● “Loading a SystemC Library into ncsim” on page 8-5
● “Mixed-Language Connection of Quasi-Static SystemC Ports and Exports” on page 8-6
● “See Also” on page 8-8
● “Mixed-Language UVM Connection Function” on page 8-9
● “SystemVerilog Mixed-Language UVM Use Model” on page 8-10
● “Using irun on Mixed-Language SystemVerilog-SystemC UVM Designs” on page 8-12
● “Compatibility with SystemVerilog UVM Use Model” on page 8-12
● “Connection of Static SystemC Ports and Exports” on page 8-15
● “Passing Transaction Data by Value across SystemC Language Boundary” on page 8-18
● “SystemC Quasi-Static Phase Alignment with SystemVerilog UVM” on page 8-23
● “Disabling a Root SystemVerilog Process Blocked in Mixed-Language UVM Call Chain” on page 8-24
● “Simulator Tcl Command Support” on page 8-24
● “SimVision Support for Quasi-Static SystemC Hierarchies” on page 8-25
● “Effect of ncelab Options on Quasi-Static Hierarchies” on page 8-25
● “Limitations” on page 8-26
8.1 Creating Quasi-Static Top Modules with the

Simulator Command
To create a SystemC quasi-static top module, provide the following option to the simulator (ncsc_run,
ncsim, or irun):
-uvmtop SC:sctop_name
The argument to the -uvmtop option is either:

Creating Quasi-Static Top Modules Programmatically
● An sc_module class name, which you must register using the NCSC_MODULE_EXPORT macro
● You cannot specify the sc_main() function as an argument to -uvmtop.
● An uvm_component class that has been registered with UVM_COMPONENT_REGISTER
To create multiple SystemC tops, you can specify the option multiple times. For example:
% ncsim -uvmtop SC:sc_test1 -uvmtop SC:sc_test2 ...
However, you cannot specify the same SystemC module or the same SystemC UVM component more
than once as an argument to the -uvmtop option.
You can also use the -uvmtop option to specify SystemVerilog and e quasi-static design tops. General
syntax of the option is as follows:
-uvmtop SV_name | SC_name | e_name
SV_name::=[SV:]SV_UVM_name
SC_name::=SC:SC_module_name
e_name::=e:e_unit_name
Note If you omit the SC: or e: specification, the parameter to -uvmtop is assumed to be a
SystemVerilog UVM class.
8.2 Creating Quasi-Static Top Modules

Programmatically
You can also use programmatic means to create SystemC quasi-static tops, in which you can instantiate
SystemC modules directly:
● The class ncsc_global_quasi_static_functions contains all of the phase-specific member

methods present in the existing class ncsc_global_functions. The startup() and
end_of_construction() member methods of this class object can directly instantiate SystemC
quasi-static tops:
class ncsc_global_quasi_static_functions() {
public:
virtual void startup();
virtual void end_of_construction();
virtual void connect();
virtual void end_of_elaboration();
virtual void start_or_simulation();
virtual void start_of_save();
virtual void end_of_save();
virtual void start_of_restore();
virtual void end_of_restore();
virtual void end_of_simulation();
};

Quasi-Static Elaboration
● The simulator option -loadscsim accepts an optional bootstrap function name. Quasi-static
SystemC modules can also be directly instantiated from such bootstrap functions. For more
information about this option, refer to “Loading a SystemC Library into ncsim” on page 8-5.
Note SystemC quasi-static verification design tops cannot instantiate static HDL components like
Verilog modules. Also, a SystemC quasi-static component cannot instantiate a SystemVerilog UVM class
because the simulator supports only parallel quasi-static verification tops from different languages.
The following example shows an ncsc_global_quasi_static_functions object creating a

SystemC quasi-static top in its startup() member method:
Example 1 Creating a SystemC Quasi-Static Top

SC_MODULE(test_top) {
public:
SC_CTOR(test_top) { }
};
test_top* t_top;
class my_quasi_static_global_func : public
ncsc_global_quasi_static_functions {
public:
void startup() {
cout << sc_time_stamp()
<< “: in ncsc_global_quasi_static_functions::startup, “
<< “creating new quasi-static top test_top” << endl;
t_top = new test_top(“test_top”);
}
};
static my_quasi_static_global_func qsg;
8.3 Quasi-Static Elaboration

The simulator creates a quasi-static hierarchy at the preinitial time after you enter the first run
command. Therefore, it is illegal to create SystemC modules, ports, exports, or prim_channel objects
at the following times:
1. After static elaboration has ended and before quasi-static elaboration starts, including the time
between the first ncsim prompt and the first run command
2. After quasi-static elaboration has ended
A SystemC object created during quasi-static elaboration is a quasi-static object. To query if it is a

quasi-static object, you can use the following member method of the sc_object class:
bool sc_object::is_quasi_static();

Loading a SystemC Library into ncsim
The following steps are performed during quasi-static elaboration at preinitial time, in the given order:
1. The startup() member methods of all SystemC ncsc_global_quasi_static_functions()

objects are invoked.
2. All SystemC bootstrap functions specified as arguments to the ncsim -loadscsim option are
invoked in the order in which they were specified on the command line. The bootstrap functions can
create SystemC quasi-static tops.
3. All quasi-static tops specified through the -uvmtop option are constructed, in the order in which
they were specified on the ncsim command line.
4. The end_of_construction member methods of all SystemC quasi-static objects are invoked,
followed by the end_of_construction member methods of all SystemC
ncsc_global_quasi_static_functions objects.
5. The end_of_elaboration member methods of all SystemC quasi-static objects are invoked,
followed by the end_of_elaboration member methods of all
ncsc_global_quasi_static_functions objects.
6. The start_of_simulation member methods of all SystemC

ncsc_global_quasi_static_functions objects are invoked, followed by the
start_of_simulation member methods of all quasi-static objects.
How the SystemC quasi-static phases align with the corresponding quasi-static phases in SystemVerilog
UVM and e is described in “SystemC Quasi-Static Phase Alignment with SystemVerilog UVM” on page
8-23.
After the start of simulation, the quasi-static components are treated by the simulator similarly to static
components. For example, the end_of_simulation callback is invoked at the same point in time for
all static and quasi-static components.
In accordance with the SystemC LRM, a process created during quasi-static construction or during
quasi-static end_of_construction is a static process, and a process created after quasi-static
end_of_elaboration is a dynamic process.
However, from the simulator perspective, the processes created during quasi-static elaboration are not
dynamic, and thus are not affected by the ncsim option +scDisableDynamicHierarchy.
8.4 Loading a SystemC Library into ncsim

Because the SystemC quasi-static hierarchy is known only to the simulator, you can load the SystemC
code containing the quasi-static hierarchy as a shared library to ncsim, or link statically to ncsim. To do
so, you can use the -loadscsim option:
-loadscsim library_name[:bootstrap]

Mixed-Language Connection of Quasi-Static SystemC Ports and Exports
where:
● library_name is a shared object that contains the bootstrap function. The library must reside in
one of the directories of LD_LIBRARY_PATH. If library_name does not end in .so, then after first
checking for presence of the library name, an additional check is performed for the existence of the
library with .so added. The symbols of the library are loaded into the global namespace.
● bootstrap is a symbol within the library called at preinitial time. Its C prototype is as follows:
void bootstrap()
You can apply multiple -loadscsim options to ncsim. The simulator then loads each SystemC shared
object provided as an argument to an option. On the Tcl reset command, each such library is unloaded
and reloaded.
Note The simulator (ncsim) accepts the shortest unique prefix for options. So, you can specify
-loadsc to ncsim, while for irun and ncsc_run the full name is necessary to direct it properly to ncsim.
If you specify a -loadscsim option to ncsim, you must also provide at least one -loadsc option to
ncelab. That is, if ncsim is loading in additional SystemC libraries, then ncelab must be informed that
there is SystemC in the design through the -loadsc option.
For example, you can specify a static.cpp file and provide the name of that file as an argument to
ncsc_run or irun to build this file and the corresponding .so file, and provide it to ncelab with the
-loadsc option. If your design does not have any HDL tops, then you must also specify a SystemC top
as a static top to ncsc_run or irun:
% ncsc_run static.cpp -top static_top -loadscsim
lib_quasi_static.so:bootstrap
-uvmtop SC:quasi_static_top
You can also link a SystemC library into ncsim statically, in addition to dynamic linking. For static
linking, the syntax is as follows:
-loadscsim [library_name]:bootstrap
The library_name can be omitted; you can provide only a bootstrap function name.
8.5 Mixed-Language Connection of Quasi-Static

SystemC Ports and Exports
A SystemC quasi-static sc_port templated by a TLM 1.0 interface can be connected to a quasi-static
export templated by a matching TLM 1.0 interface in another language (SystemVerilog UVM or e).
Similarly, a quasi-static port in another language (SystemVerilog UVM or e) templated by a TLM 1.0
interface can be connected to a SystemC quasi-static sc_export templated by a matching TLM 1.0
interface.

Mixed-Language Connection of Quasi-Static SystemC Ports and Exports
Table 8-1 on page 8-7 shows the matching SystemVerilog UVM TLM exports and the e TLM exports
corresponding to SystemC TLM 1.0 ports. In this release, interfaces with blocking calls are also
supported between e and SystemC.
Table 8-1 Matching SystemC TLM 1.0 Interfaces
SystemC Port SystemVerilog UVM Export e export
sc_port<tlm_blocking_put_if> uvm_blocking_put_imp in interface_port of

tlm_blocking_put
sc_port<tlm_non_blocking_put_if> uvm_nonblocking_put_imp in interface_port of

tlm_nonblocking_put
sc_port<tlm_put_if> uvm_put_imp in interface_port of

tlm_put
sc_port<tlm_blocking_get_if> uvm_blocking_get_imp in interface_port of

tlm_blocking_get
sc_port<tlm_non_blocking_get_if> uvm_nonblocking_get_imp in interface_port of

tlm_nonblocking_get
sc_port<tlm_get_if> uvm_get_imp in interface_port of

tlm_get
sc_port<tlm_blocking_peek_if> uvm_blocking_peek_imp in interface_port of

tlm_blocking_peek
sc_port<tlm_non_blocking_peek_if> uvm_nonblocking_peek_imp in interface_port of

tlm_nonblocking_peek
sc_port<tlm_peek_if> uvm_peek_imp in interface_port of

tlm_peek
sc_port<tlm_blocking_get_peek_if> uvm_blocking_get_peek_imp in interface_port of

tlm_blocking_get_peek
sc_port<tlm_non_blocking_get_peek_ uvm_nonblocking_get_peek_imp in interface_port of

if> tlm_nonblocking_get_peek
sc_port<tlm_get_peek_if> uvm_get_peek_imp in interface_port of

tlm_get_peek
sc_port_<tlm_master_if> uvm_master_imp in interface_port of

tlm_master

Registering SystemC Ports and Exports
SystemC Port SystemVerilog UVM Export e export
sc_port<tlm_slave_if> uvm_slave_imp in interface_port of

tlm_slave
sc_port<tlm_transport_if> uvm_transport_imp in interface_port of

tlm_transport
sc_port<tlm_analysis_if>, uvm_analysis_imp in interface_port of

tlm_analysis_port tlm_analysis
Note The list of TLM 1.0 sc_export types corresponding to SystemVerilog UVM TLM ports and e
TLM ports is similar to the above list.
TLM 2.0 defines a SystemC interface equivalent to the SystemVerilog UVM analysis interface
(uvm_analysis_port, and uvm_analysis_imp). If your SystemC code uses
tlm_analysis_interface, you must compile it with the -tlm2 option to irun or ncsc_run, which
allows including the TLM 2.0 headers, rather than the TLM 1.0 headers.
Cross-language port-export connections in which the export interface is derived from the port interface
qualify for matching. In other words, a simple port can be connected to a complex (having more
inheritance) export. For example, it is legal to connect an sc_port<tlm_peek_if> to an
uvm_get_peek_imp.
From the list of the SystemC TLM 1.0 interfaces listed above, this release of IES does not support those
interface functions for cross-language invocations that return a reference to an event. The following
code is an example of such an interface function:
template < typename T >
class tlm_nonblocking_get_if : public virtual sc_interface
{
public:
virtual const
sc_event &ok_to_get( tlm_tag<T> *t = 0 ) const = 0;
};
See Also
● Table 2-4 on page 2-28 in the section “Matching TLM Ports in ML-UVM” on page 2-28
8.6 Registering SystemC Ports and Exports

A SystemC quasi-static port or export that needs to connect to quasi-static verification exports and ports
in other languages must be registered in SystemC code, using the templated function

Mixed-Language UVM Connection Function
ml_uvm_register(). Registration is supported only for sc_port and sc_export types that are
templated by a TLM 1.0 interface. If you attempt to register any other kind of sc_port or sc_export,
the simulator issues a run-time error message. You can perform registration at any time during static
elaboration, and up to the end_of_construction phase in quasi-static elaboration:
namespace ml_uvm {
template <typename IF>
void ml_uvm_register(sc_port<IF>& port, bool send = true);
template <typename IF>
void ml_uvm_register(sc_export<IF>& xport, bool receive = true);
}
Note The second argument to these functions is optional and can be omitted.
8.7 Mixed-Language UVM Connection Function

After the registration step, you need to connect a quasi-static port in one language to a quasi-static export
in another language, using hierarchical names. You can perform this connection in any language,
including SystemC. A mixed-language UVM connection function is used to specify such a connection.
The SystemC mixed-language UVM connection function is ml_uvm_connect():
bool ml_uvm_connect(
std::string port_full_name, std::string export_full_name
);
The first argument to the ml_uvm_connect() function is the path of a quasi-static port, and the second
argument is the path of a quasi-static export.
Other languages like SystemVerilog and e also provide a similar connection function. To connect a
SystemC port to a SystemVerilog/e export, you can specify the connection in any language: SystemC,
SystemVerilog, or e. Similarly, to connect a SystemVerilog/e port to a SystemC export, the connection
can again be specified in any language: SystemC, SystemVerilog, or e.
You can call ml_uvm_connect() during static elaboration and quasi-static elaboration, up to the
end_of_construction phase. The SystemVerilog mixed-language UVM connection function can be
called only from the SystemVerilog UVM connect phase. All ml_uvm_connect() calls made in
SystemC take effect just before the quasi-static SystemC phase end_of_elaboration, before all port
bindings have been propagated in SystemC.
Although a connection function is typically used to connect cross-language ports and exports, it is also
legal to use a connection function to connect SystemC ports to SystemC exports (for example, across
disjointed SystemC quasi-static hierarchies). Moreover, each language supports indirect port-export
connections specified through mixed-language UVM connection functions.
The following inputs to ml_uvm_connect() result in an error:
● A hierarchical path for port_name or export_name that does not exist

SystemVerilog Mixed-Language UVM Use Model
● Mismatched TLM 1.0 interfaces between the port and the export (for example, when an
sc_port<tlm_put_if> is connected to uvm_get_imp
● Mismatched transaction data type between the port and the export. Data type equivalence is
established only by the same class name. See Table 8-1 on page 8-7 for more details.
It is legal to register a SystemC export with an ml_uvm_register() call but to leave it unconnected.
If a SystemC port is registered, but not connected, an error is not issued when quasi-static elaboration is
over. However, if the port is accessed during simulation (that is, a port interface function is invoked), the
simulator issues a run-time error. In other words, a port can be left unconnected, as long as it is not
accessed.
8.8 SystemVerilog Mixed-Language UVM Use Model

SystemVerilog UVM distinguishes between import and export, while in SystemC sc_export can
represent functionality of both.
Note In this release, only uvm_xxx_imp types are supported for mixed-language UVM connections;
uvm_xxx_export types are not supported.
The SystemVerilog mixed-language UVM functionality is available in the package ml_uvm. You must
import the ml_uvm package into your design to make this functionality available:
module topmodule;
import ml_uvm::*;
...
endmodule
The ml_uvm package contains three functions:
1. Mixed-language UVM connection function 1:

function void connect(
uvm_if_base_abstract port_or_imp,
string external_path,
string T1_name,
string T2_name = ““
);
The first argument is a handle to a SystemVerilog UVM parameterized port or import. The second
argument is the full path of the SystemC/e export or port to which the first argument is connected.
The second and third arguments are the string names of the actual instantiation values of the
parameter for the parameterized port or import that appears as the first argument. For parameterized
ports/imports with one parameter, the fourth argument is not filled in.

SystemVerilog Mixed-Language UVM Use Model
You call the connect() function only in the connect phase of SystemVerilog UVM. For example,
to connect the SystemVerilog UVM port uvm_blocking_put_port # (T) out inside the
component producer instantiated as producer prod #(packet) prod inside the parent
component top, to a SystemC export sctop.cons.in, issue the following connect() statement
in the connect() function of top:
ml_uvm::connect(prod.out, “sctop.cons.in”, packet);
2. Registration function
function void external_if (
uvm_if_base_abstract port_or_imp,
string T1_name,
string T2_name = ““
);
The first argument is a handle to a SystemVerilog UVM parameterized port or import that will be
connected to a SystemC/e export or port using the SystemVerilog mixed-language UVM connection
function ml_uvm::connect_names(), or the SystemC mixed-language UVM connection
function ml_uvm_connect().
The second and third arguments are the string names of the actual instantiation values of the
parameter for the parameterized port or import that appears as the first argument. For parameterized
ports/imports with one parameter, the fourth argument is not filled in.
3. Mixed-language connection function 2:

function void connect_names(string path1, string path2);
The first argument is the full path of a SystemVerilog UVM, SystemC, or e port. The second
argument is the full path of the export in SystemVerilog UVM, SystemC, or e, to which the port is
being connected.
You call the connect_names() function only in the connect phase of SystemVerilog UVM.
Note To use this connection function, you must first register with ml_uvm::external_if()
any SystemVerilog UVM port/import that appears in this function.
Your SystemVerilog UVM code should not call run_test(). The run phase is automatically launched
at preinitial time if an -uvmtop option has been provided to ncsim. Refer to “Compatibility with
SystemVerilog UVM Use Model” on page 8-12 for more details on run_test() usage with the present
use model.
The SystemVerilog UVM top levels specified as -uvmtop options are tracked in the variable
uvm_top_levels[], which is a queue of all top-level uvm_component objects. Depending on how
UVM is included in the design, this variable appears at different scopes:
After a simulation has past the preinitial point, the variable uvm_top_levels[] shows all of the
SystemVerilog UVM top components, specified as -uvmtop arguments.

Using irun on Mixed-Language SystemVerilog-SystemC UVM Designs
The SimVision Design Browser shows the SystemVerilog UVM tops specified as -uvmtop arguments
under the uvm_top_levels[] variable. For easier identification, uvm_top_levels[] appears in red
on the left pane of the Design Browser.
8.9 Using irun on Mixed-Language

SystemVerilog-SystemC UVM Designs
To simulate mixed-language SystemVerilog-SystemC UVM designs, you must use irun.
It is also recommended that you import the ml_uvm and uvm_pkg packages in SystemVerilog source
code. As a good practice, you can also include the uvm_macros.svh file:
module topmodule;
import uvm_pkg::*;
import ml_uvm::*;
‘include “uvm_macros.svh”
...
endmodule
8.10 Compatibility with SystemVerilog UVM Use

Model
Note The mixed-language UVM solution in this release of IES supports the SystemVerilog UVM
version 2.01.
The existing SystemVerilog UVM use model supports instantiation of SystemVerilog quasi-static
components from a process after simulation starts running (for example, from an initial block). You can
also specify the test top name through the irun option +UVM_TESTNAME.
The SystemVerilog UVM phases are triggered by the programmatic API run_test(), called from a
SystemVerilog process.
Using -uvmtop implies a use model, in which all of the SystemVerilog UVM phases occur at preinitial
time, rather than triggered by run_test(), and are aligned with the corresponding quasi-static phases
of SystemC and e, as listed in Table 8-3 on page 8-23. Because the run phase is also launched at
preinitial time, your design should not call run_test() explicitly.
If you do not specify the -uvmtop option, the SystemVerilog UVM use model is in effect for backwards
compatibility; that is, the SystemVerilog UVM phases do not occur at preinitial time, but are triggered
by run_test().
If you specify -uvmtop, it will be an error to instantiate SystemVerilog quasi-static components

programmatically; that is, the two use models cannot be mixed and matched. More specifically, if you
are using -uvmtop and also run_test(“test”) at the same time, or explicitly instantiating an

Compatibility with SystemVerilog UVM Use Model
uvm_component from an initial block, the simulator triggers an error message. The run_test()
method does not trigger an error message, but generates a warning, and is treated as no-op. It is also an
error to specify both -uvmtop and +UVM_TESTNAME at the same time.
Besides using the -uvmtop option, SystemC quasi-static tops can be created by the
ncsc_global_quasi_static_functions::startup() routines, or by the ncsim
loadscsim:bootstrap functions, which represents a SystemC-only quasi-static use model. Such a
SystemC-only use model can orthogonally co-exist with the SystemVerilog UVM use model of
programmatically instantiating SV quasi-static tops, in which case the SystemC quasi-static phases
occur at preinitial time, and are not aligned with the SystemVerilog UVM quasi-static phases; nor is
there any communication between the SystemC quasi-static hierarchy and the SystemVerilog UVM
hierarchy through the connection functions. See “Connection of Static SystemC Ports and Exports” on
page 8-15 for a description of the connection functions.
Example 2 Registration and Connection in Mixed-Language UVM

In this example, a producer module in SystemC with a sc_port<tlm_blocking_put_if> port is
connected to an uvm_blocking_put_imp export in a consumer module in SystemVerilog UVM. In
SystemC, you register the producer port using the ml_uvm_register() function. Similarly, in
SystemVerilog UVM, the user registers the consumer export. Either SystemC or SystemVerilog can
issue the mixed-language UVM connection function call. In this example, SystemC calls
ml_uvm_connect():
sc_test_top sv_test_top
producer consumer
sc_port<tlm_blocking_put_if> uvm_blocking_put_imp
SystemC SystemVerilog
SystemC Code:
// producer.h
#include “systemc.h”

Compatibility with SystemVerilog UVM Use Model

template <typename T>
SC_MODULE(producer) {
public:
sc_port<tlm_blocking_put_if<T> > p;
SC_CTOR(producer) : prt( prt ) { SC_THREAD(run); }
void run() {
T t;
for (int i = 0; i < 10; i ++) {
wait(10, SC_NS);
// fill in t
...
prt->put(t);
}
}
};
// top.cpp
#include <ml_uvm.h>
#include producer.h
#include packet.h
using namespace ml_uvm;
SC_MODULE(sc_test_top) {
public:
producer producer_i<packet>;
SC_CTOR(sc_test_top) : producer_i(“producer”) {
ml_uvm_register(producer_i.prt); // register SC port
}
void end_of_construction() {
// connect SC port to SV UVM export
ml_uvm_connect(“sctop.producer.prt”, “svtop.consumer.exprt”);
}
};
SystemVerilog code:
// consumer.sv
class consumer # (type T = int) extends uvm_threaded_component;
uvm_blocking_put_imp #(T, consumer #(T)) exprt;
typedef consumer#(T) this_type;
‘uvm_component_utils_begin(this_type)
‘uvm_component_utils_end
virtual function put();
...
endfunction
endclass
// test_top.sv
module topmodule;
import uvm_pkg::*

Connection of Static SystemC Ports and Exports
import ml_uvm:*; // import SV Unilang package

‘include “consumer.sv”
class sv_test_top extends uvm_test;
consumer #(packet) c;
‘uvm_component_utils(sv_test_top)
function new(string name, uvm_component parent=null);
endfunction
function void build();
c = new(“consumer”, this);
ml_uvm::external_if(c.exprt, packet ); // register SV export
endfunction
endclass
The simulator command line is as follows:

% ncsim -uvm SC:sc_tst_top -uvmtop sv_test_top snapshot_name
8.11 Connection of Static SystemC Ports and Exports

All ports in the static SystemC hierarchy must be bound during elaboration. You can bind a static
sc_port manually to an interface object. For example, an sc_out port can be bound to sc_signal. If
you need to access objects in the static SystemC hierarchy from the quasi-static SystemC hierarchy
(OOMR-like connections), you must use the sc_find_object()function and the hierarchical names
of the objects as arguments.
Static sc_port objects templated by the TLM 1.0 interfaces can take advantage of the
ml_uvm_register(sc_port<IF>&) function, described in “Registering SystemC Ports and Exports”
on page 8-8, to register using this function. This fulfills two requirements for an sc_port object:
1. Binds the static sc_port to an object that implements the port interface, and therefore, satisfies the
requirement that all ports must be bound by the end of static elaboration
2. During ncsim quasi-static elaboration, the static sc_port can be connected to a quasi-static export
in any language, including SystemC, using a mixed-language UVM connection function like
ml_uvm_connect(). This gives you the flexibility of having the static sc_port be connected to
an export in different languages in different ncsim runs through different connection functions,
without changing the static hierarchy code. This is an important benefit, especially when the static
hierarchy represents a DUT, and the quasi-static hierarchy represents a test.
Similarly, static sc_export objects templated by the TLM 1.0 interfaces can also register using the
ml_uvm_register(sc_export<IF>&) function. Registration is not necessary for exports because
there is no binding requirement on sc_export objects. It is an optional step that provides the same
cross-language connection flexibility for sc_export described above. Namely, a static SystemC

sc_export registered through ml_uvm_register() becomes eligible for connection to a quasi-static

port from any language using a mixed-language UVM connection function.
Example 3 Static SystemC DUT Instantiated by SystemVerilog Top Module

In this example, a static SystemC DUT has an sc_port at which it produces outputs accessed by a
monitor test component. It also has an sc_export at which it consumes inputs from a driver test
component that drives the DUT. The static DUT is instantiated in a static testbench top module, and the
ml_uvm_register() functions are used to register the DUT’s port and export. Such a static hierarchy
is self-contained and satisfies the SystemC port binding rules. After this static DUT hierarchy is
elaborated by ncelab, the SystemVerilog UVM quasi-static test top connects to the static SystemC
testbench during simulation, and drives the DUT monitoring its results.
sc_testbench_top sv_test_top
DUT
monitor
sc_port<tlm_blocking_put_if> uvm_blocking_put_imp
sc_export<tlm_blocking_put_if> uvm_blocking_put_port
driver
SystemC SystemVerilog
SystemC Code:
// dut.h
#include “systemc.h”
SC_MODULE(dut) {
public:
sc_port<tlm_blocking_put_if<T> > monitor_port;
sc_export<tlm_blocking_put_if<T> > driver_export;
SC_CTOR(producer) :

monitor_port(“monitor_port”), driver_export(“driver_export”) {
SC_THREAD(run);
}
void run() { ... } // transform the input and write it out
};
// testbench_top.cpp
#include dut.h
#include packet.h
using namespace ml_uvm;
SC_MODULE(sc_testbench_top) {
public:
dut dut_i<packet>;
SC_CTOR(sc_testbench_top) : dut_i(“dut”m) {
// register SC DUT monitoring port
ml_uvm_register(dut_i.monitor_port);
// register SC DUT driving export
ml_uvm_register(dut_i.driver_export); m
}
};
SystemVerilog code:
// test_top.sv
module topmodule;
import uvm_pkg::*;
import ml_uvm::*; // import SV unilang package
‘include “monitor.sv”
‘include “driver.sv”
class sv_test_top extends uvm_test;
monitor #(packet) m;
driver #(packet) d;
‘uvm_component_utils(sv_test_top)
function new(string name, uvm_component parent=null);
endfunction
function void build();
m = new(“monitor”, this);
d = new(“driver”, this);
// register SV test monitor export
ml_uvm::register_imp(m.monitor_export, “packet”);
// no need to explicitly register SV test driver port
endfunction
function void connect();
// connect SV test driver port to SC DUT driver export
ml_uvm::connect_names(d.driver_port.get_full_name(),
“testbench_top.dut.driver_export”
);

Passing Transaction Data by Value across SystemC Language Boundary
// connect SC DUT monitor port to SV test monitor export

ml_uvm::connect_names(“testbench_top.dut.monitor_port”,
m.monitor_export.get_full_name()
);
endfunction
endclass
The elaborator and simulator commands line are as follows:

% ncelab -loadsc testbench_top.so sc_testbench_top
% ncsim sc_testbench_top -uvmtop sv_test_top
8.12 Passing Transaction Data by Value across

SystemC Language Boundary
You can call many of the SystemC TLM 1.0 interface functions across the language boundary in a
mixed-language UVM test, pass transaction data as a function argument, or return transaction data. For
example:
class tlm_blocking_put_if : sc_interface
public:
void put(T& data) = 0;
};
This transaction data is typically a user-defined SystemC class or a basic language data type. Because
mixed-language UVM supports TLM 1.0, and TML 1.0 specifies a pass-by-value semantics, all
transaction data are passed by value. The arguments for TLM function calls that cross the language
boundary must be a class that derives from uvm_object.
The SystemC mixed-language UVM packer also supports the basic primitive types:
● bool, char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned
long, long long, unsigned long long, sc_logic, sc_bv, sc_lv, sc_int, sc_uint,
sc_bigint, sc_bigint
● string, char*
The valid argument for cross-language TLM calls is a class derived from uvm_object because the
SystemVerilog mixed-language UVM unpacker supports only objects. The member fields of such a
class can be any of the primitive data types listed above.
8.12.1 Passing Legacy SystemC Types Across the Boundary

As described above, the data type passed across the boundary in mixed-language UVM communication
is uvm_object. If you have a SystemC design with a legacy type in it that does not inherit from

The uvm_object Class
uvm_object, and you want this design to participate in mixed-language UVM communication, you can
define converters at the language boundary to convert to/from the legacy type from/to a corresponding
type that inherits from uvm_object. With this approach, your original design can stay unchanged and
continue using the legacy type. You can find an example of converting a legacy type at:
‘ncroot‘/tools/systemc/examples/ml_uvm/legacy_type_converter
8.12.2 The uvm_object Class

A class derived from uvm_object must provide the following routines:
● A create() function that takes no arguments and returns an instance of itself as an uvm_object*
● A get_type_name() function that returns the name of the class as a string
● A print function
● Pack and unpack functions
● A copy function
● A compare function
You can satisfy the first two requirements by including the macro UVM_OBJECT_UTILS inside the class
declaration. However, you should provide the constructor, pack/unpack routines, and print routines.
In addition, you must register the class with the SystemC UVM factory, so that the factory can create
instances of it. This is satisfied by including the macro UVM_OBJECT_REGISTER outside of the class
declaration.
The following is an example of an uvm_class definition:

public:
UVM_OBJECT_UTILS(packet)
packet() { data = 17; }
virtual ~packet() { }
virtual void do_print(ostream& os) const {
os << data << endl;
}
p << data;
}
p >> data;
}
virtual void do_copy(const uvm_object* rhs) {
data = drhs->data;
}

Pack and Unpack Functions
virtual bool do_compare(const uvm_object* rhs) const {

if (!(data == drhs->data)) return false;
return true;
}
private:
int data;
};
UVM_OBJECT_REGISTER(packet)
8.12.3 Pack and Unpack Functions

The do_pack() and do_unpack() functions take an uvm_packer& as an argument. The uvm_packer
has a << operator for packing and a >> operator for unpacking. The do_pack()/do_unpack()
functions should list the fields to be packed/unpacked. You can string the fields together or put them on
separate lines:
(*p) << field1 << field2;
(*p) << field3;
Each argument to the << and >> operators must be either an uvm_object or one of the supported
primitive types: bool, char, unsigned char, short, unsigned short, int, unsigned int, long,
unsigned long, long long, unsigned long long, sc_logic, sc_bv, sc_lv, sc_int, sc_uint,
sc_bigint, sc_bigint. If a field is an uvm_object, you can pass it as a pointer or as an object.
Passing it as a pointer preserves the derived class information. However, when crossing the language
boundary, the object is passed by value only.
If a field is not of one of the supported types, it must be converted to one or more objects of supported
types. For example, if a field is a structure that contains subfields of supported types, you can pass the
subfields as a pointer:
(*p) << field4.i1 << field4.i2 << field5;
The pack and unpack functions preserve derived type information. For example, if you declare a class
derived from header, as follows:
class derivedheader : public header{
public:
UVM_OBJECT_UTILS(derivedheader)
derivedheader() { s = “dddd”; }
...
};
UVM_OBJECT_REGISTER(derivedheader)
and the packed class derived from uvm_object has a member field
header* head;

the pack and unpack functions for the packed class are:
p) << head << addr;
}
p >> head >> addr;
}
Because head is passed as a pointer, if it is pointing to a derivedheader, the head field points to
derivedheader when the packet is unpacked.
On the other hand, if the pack and unpack functions are written as follows, the head field points to a
header (base class) when the packet is unpacked:

p << *head << addr;
}
p >> *head >> addr;
}
For a packed object to be successfully unpacked, the packing and unpacking functions must agree on the
class names, the field types, and the field ordering.
Because the unpacking can occur in a different language than the packing, this generally means that the
pack routine in one language must match the unpack routine in the other language for the class of the
same name. The simplest way to ensure this is to make the class definitions in the two languages match,
and both languages pack/unpack all of the fields. However, it is possible for the class definitions to
differ, as long as the pack and unpack routines match.
The legal mapping between SystemVerilog and SystemC for the primitive data types is shown in Table
8-2 on page 8-21. For example, if your SystemC data object packet derives from uvm_object and
contains two member fields of type sc_logic and sc_int<64>, the corresponding packet object in
SystemVerilog should derive from uvm_object and contain two member fields of type logic and
bit[63:0], respectively.
Table 8-2 Mapping between SystemVerilog and SystemC
SystemVerilog Data Type SystemC Data Type

bit bool
logic sc_logic
bit[N-1:0] sc_bv<N>, sc_int<N>, sc_uint<N>,

sc_bigint<N>, sc_biguint<N>
logic[N-1:0] sc_lv<N>

SystemVerilog Data Type SystemC Data Type

byte char
byte unsigned unsigned char
shortint short
shortint unsigned unsigned short
int int
int unsigned unsigned int
longint int64
longint unsigned uint64
string std::string, char*
dynamic array std::vector
If the class names on both sides do not match, and one side packs an uvm_object that the other side
does not recognize, an error message is printed. The size of the two objects is also checked, and error
messages are generated for too few or too many bits. Besides this, no other error checking is performed.
For example, if one side packs a char and the other side is expecting an int, the result is a crash.
A field of type enum is passed across the language boundary as the basic non-enumeration type that it
represents (usually int). So, when packing and unpacking, you have to pack/unpack the corresponding
basic data type, and then cast it to the enum type.
If you have a class with enum members, you can declare << and >> operators when you declare the enum
inside your class. Then the pack/unpack functions can simply call << and >>, as usual. For example:
...
enum state_t { OK=1, ERROR };
friend uvm_packer& operator << (uvm_packer& p, state_t v) {

p << (int)v;
return p;
}
friend uvm_packer& operator >> (uvm_packer& p, state_t& v) {

int i;
p >> i;
v = state_t(i);
return p;
}

SystemC Quasi-Static Phase Alignment with SystemVerilog UVM
state_t state;
...
p << data;
p << state;
p << address;
}

p >> data;
p >> state;
p >> address;
}
...
};
8.13 SystemC Quasi-Static Phase Alignment with

SystemVerilog UVM
During quasi-static elaboration, some of the SystemC phases are aligned with the corresponding
SystemVerilog UVM and e phases. The following table shows how the quasi-static phases line up across
the languages. For a given phase (like SystemC end_of_construction), different languages come up
to phase in a non-deterministic order.
Table 8-3 Phase Alignment between SystemC, SystemVerilog, and e
SystemVerilog UVM
SystemC Quasi-Static Phase Phase e Phase
startup - -
-loadscsim:bootstrap - -
uvm_component::build, build generate

end_of_construction
connect connect connect_pointers and

connect_ports
end_of_elaboration end_of_elaboration check_generation
end_of_simulation end_of_simulation run
execute processes, including run -

uvm_component::run
uvm_component::extract extract extract

Disabling a Root SystemVerilog Process Blocked in Mixed-Language UVM Call Chain
SystemVerilog UVM
SystemC Quasi-Static Phase Phase e Phase
uvm_component::check check check
uvm_component::report report finalize
end_of_simulation - -
It is recommended that you create all of the UVM test hierarchy in the SystemVerilog UVM phase
build. The SystemC end_of_construction phase can also create new quasi-static SystemC
modules. Also, you need to bring up to phase the newly created quasi-static components created in these
phases.
8.14 Disabling a Root SystemVerilog Process

Blocked in Mixed-Language UVM Call Chain
If a blocking mixed-language UVM call chain originates in SystemVerilog, it is possible that the root
SystemVerilog process becomes disabled while the call chain is blocked in SystemC or in
SystemVerilog. This can occur explicitly due to disable being called on the root SystemVerilog
process, or implicitly through a global_stop_request() construct issued in SystemVerilog. In such
cases, any user SystemC code in the call chain is bypassed by throwing sc_kill_exception. If in
your SystemC code you wish to handle with this scenario differently for a specific purpose (for example,
to perform cleanup), your code can catch sc_kill_exception, take the appropriate actions, and then
again throw back sc_kill_exception.
8.15 Simulator Tcl Command Support

The following simulator Tcl commands are supported for SystemC objects in quasi-static hierarchies:
● scope
● scope -top: quasi-static tops are listed in the top list after the preinitial time
● describe
● value
● deposit
● force
● release
● probe
● stop
● reset

SimVision Support for Quasi-Static SystemC Hierarchies
Immediately after reset, the simulation state is rolled back to time 0 before preinitial time, and
thus before quasi-static elaboration has completed. Therefore, the quasi-static hierarchy does not
exist immediately after reset. After you issue the first post-reset run command, the same
quasi-static hierarchy that existed before reset is re-constructed.
Because the quasi-static hierarchy disappears immediately after reset, any probes that were issued
on SystemC quasi-static objects before reset, are invalid after the reset, and you need to reissue
your probe commands.
In addition, the SHM database variable used for the original probe command before reset cannot
be reused for new probe commands after a reset. Instead, the reset count is stored in a new SHM
database variable. For example, if you probe the quasi-static SystemC signal sig, probing the same
signal after the first reset is recorded as the variable _1_sig in the SHM database, and as the
variable _2_sig after the second reset, and so on.
Your probe commands are not automatically reapplied after a reset, and the simulator issues a
warning message on reset, if the design contains SystemC quasi-static hierarchy in which any
quasi-static objects have been probed. You can upgrade the severity of the warning message to
error, if you do not want to see the default reset behavior.
8.16 SimVision Support for Quasi-Static SystemC

Hierarchies
After quasi-static elaboration completes, the new SystemC quasi-static hierarchy is updated in the
Design Browser window with the same navigation support as the static hierarchy.
In Post Processing Mode (ncsim -ppe), you do not have access to the quasi-static test hierarchies for
design navigation. However, you can use the saved databases and the Waveform window to view objects
in the quasi-static hierarchy.
Because the quasi-static hierarchy does not exist immediately after the reset, there is a brief period of
time, between reset and the first run command, when the SimVision windows continue to show the
SystemC quasi-static hierarchy, even though the hierarchy no longer exists. The simulator generates a
warning message when reset is issued, if the design contains SystemC quasi-static hierarchy, and
SimVision is connected to the simulator.
8.17 Effect of ncelab Options on Quasi-Static

Hierarchies
The following ncelab options that affect functionality in the static SystemC code are carried over to
ncsim to also apply to the quasi-static SystemC code.
● -DPI_VOID_TASK

Limitations
If this option has been specified to ncelab, the SystemC quasi-static code must also honor this
option by making all DPI import tasks return void. Similarly, if this option has not been specified to
ncelab, the quasi-static code must make all DPI import tasks return int.
● -NOASSERT
This ncelab option disables PSL assertions in the quasi-static SystemC code.
● -SCCREATEVIEWABLES
This option creates ncsc_viewable objects inserted by ncsc_wizard in the SystemC quasi-static
code.
● -SCPARAMETER arg
This option can be used to associate values with top-level quasi-static SystemC modules.
8.18 Limitations
● Because this release of IES supports only parallel quasi-static verification tops, you cannot instantiate
quasi-static components in one language within a quasi-static component in another language.
● The Tcl command reset is supported for quasi-static hierarchy in SystemC-only designs that do not
use any mixed-language UVM constructs like ml_uvm_register() or ml_uvm_connect(). For
mixed-language UVM SystemVerilog-SystemC designs, or SystemC-SystemC designs, reset is
not available.
● The simulator Tcl commands save and restart are not supported for designs containing SystemC
quasi-static hierarchies in this release of IES.

Index
Symbols print_type 6-26

-compare argument for configure_field command
#include statement 5-13 6-24
configuration database, UVM-SV 2-11
A configuration element 5-49
-adapter_config_name argument configure_code command 6-26
for configure_code command 6-27 configure_enum_item command 6-25
advantages of using TLM 2-18 configure_field command 6-23
API, dynamic e configuration 5-71 configure_scope command 6-21
assign_sequencer() 3-5 configure_type command 6-21
connect_names(), mixed-language UVM
connection function 8-11
B connect(), mixed-language UVM connection
-base_name argument for maptypes command function 8-10
6-12 connecting
BFM using initiator socket 7-15 e and SystemVerilog 2-25
BFM using targetsocket 7-17 SystemVerilog 2-25
-bin argument for configure_field command 6-24 TLM ports across languages 2-20
TLM ports between e and SystemVerilog
C 2-21
converters, of legacy types 8-18
classes, mapping 6-14 -copy argument for configure_field command
clocking block element 5-63 6-24
clocking signal element 5-66
commands
configure_code 6-26
D
configure_enum_item 6-25 data communication using TLM 2-18
configure_field 6-23 data type generation 6-1
configure_scope 6-21 data types
configure_type 6-21 TLM 2.0 7-12
maptypes 6-12 -dec argument for configure_field command 6-24
mltype example 6-13 defines, using for configuration 5-74
UVM Multi-Language Reference Index-1

Index
do_pack(), SystemC UVM function 8-20 enabling ML-UVM features 2-3

do_unpack(), SystemC UVM function 8-20 enumerated types, mapping 6-18
documentation conventions 1-2 examples
-DPI_VOID_TASK, ncelab option, effect of assign_sequencer() 3-5
quasi-static hierarchies 8-25 mapping types from e to SV 6-2
DUT interface element 5-47 mapping types from SC to e 6-9
mapping types from SC to SV 6-10
E mapping types from SV to e 6-4, 6-6
mltypemap 6-13
e path for TLM connection 2-22
dynamic e configuration API 5-71 prepare_item_to_send() 3-6
utilities 4-5 run_uig.sh 5-6
export file 5-8 specifying top entities 2-6, 2-10
export file, importing 5-67 synchronized elaboration phases 2-13
output files for maptypes 6-14 update_item_after_done 3-4
test file 2-15 external_if(), mixed-language SystemVerilog
testbench 2-14 registration function 8-11
testbench as single top entity 2-10
testbench, using SV sequences in 3-1
to SystemVerilog TLM port connection 2-24
F
top, e file for TLM port connection 2-24 -field argument for configure_field command
top.e file for passing a compound transaction 6-23
2-26 field element 5-52
types mapped to SV, example 6-2 fields, mapping 6-15
when subtypes, mapping 6-16 files
elaboration phases in various languages 2-7 do.tcl example for type mapping 6-3, 6-6,
elements 6-7, 6-10
clocking block 5-63 e export for UIG 5-8
clocking signal 5-66 run_mltypemap.sh 6-4, 6-7, 6-9
configuration 5-49 top.sv example for TLM port connection
DUT interface 5-47 2-24
field 5-52 trivial e test to configure a testbench 2-15
from_e_event 5-41 from_e_event 5-41
from_e_method 5-36 from_e_method 5-36
in|inout|out field 5-28 -from_type argument for maptype command 6-12
interface 5-54
item 5-29 G
method 5-35
sequence 5-24 -gen_adapter_config argument for
signal 5-60 configure_code command 6-27
subcomponent 5-43 generic payload
to_e_event 5-39 extensions 7-8
to_e_method 5-35 memory management 7-9
UVM component 5-16

Index
H methods
assign_sequencer() 3-5
-header_code argument for configure_code prepare_item_to_send() 3-6
command 6-27 update_item_after_done() 3-3
-hex argument for configure_field command 6-24 ML sequences API 3-2
hierarchy, extending 5-70 ml_proxy_seq_driver 3-2
ml_tlm_2_connect 7-4
I ML_TLM_2_GP_END 7-6
in|inout|out field element 5-28 ML_TLM2_FIELD 7-6
initiator 7-15 ML_TLM2_FIELD_ARRAY 7-7
interface element 5-54 ML_TLM2_FIELD_ARRAY_ENUM 7-7
irun ML_TLM2_FIELD_ENUM 7-7
arguments for mltypemap 6-10 ML_TLM2_GP_BEGIN 7-6
command line switches for ML-UVM 4-1 ML_TLM2_GP_EXT_BEGIN 7-8
is_quasi_static(), method of class sc_object to ML_TLM2_GP_EXT_END 7-8
query a SystemC object 8-4 ML_TLM2_REGISTER_INITIATOR 7-2
-item argument for configure_enum_field ML_TLM2_REGISTER_TARGET 7-2
command 6-25 -ml_uvm command-line switch for irun 4-4
item element 5-29 ml_uvm_connect(), mixed-language UVM
connection function 8-9
ml_uvm_register(), function to register SystemC
L ports and exports for UVM connections
-lang argument for configure_code command 8-9
6-27 ml_uvm_sequencer_stub 3-4
launching run phase and blocking threads 2-11 ml_uvm::connect() 4-7
legacy types, conversion of 8-18 ml_uvm.connect_names() 4-5
limitations mltypemap
for typemap 6-28 command example 6-13
in early access release 2-30 configuring 6-19
SV sequences in e testbench 3-7 example: e to SV 6-2
-loadscsim, simulator option to link a SystemC example: SC to e 6-9
quasi-static hierarchy 8-4 example: SC to SV 6-10
example: SV to e 6-4, 6-6
M invoking 6-10
irun arguments 6-10
macros, using for configuration 5-73 limitations in this release 6-28
-map_all_as_2value argument utility 6-1
for configure_code command 6-27 when subtypes support 6-16
map_as2value argument for configure_field -mltypemap_input argument for irun 6-11
command 6-24 -mltypemap_tcl argument for mltypemap 6-11
maptypes ML-UVM
command 6-12 e utilities 4-5
mapping classes 6-14 external path strings 2-22
output files 6-13 features for TLM, summary 2-20
memory management considerations 7-21

Index
irun command line switches 4-1 -print argument for configure_field command
mixed-language SystemVerilog UVM 6-24
package 8-10 print_type command 6-26
reference 2-28, 4-1 -private argument for configure_field command
SystemVerilog utilities 4-6 6-24
multi-language -protected argument for configure_field
trees of UVCs 2-3 command 6-24
UVM (ML-UVM) 2-1 -public argument for configure_field command
features 2-2 6-24
N Q
ncsc_global_quasi_static_functions() 8-3 quasi-static
example 8-4 elaboration, steps 8-5
-NOASSERT, ncelab option, effect of quasi-static hierarchy, definition 8-1
hierarchies 8-26
-nocompare argument for configure_field R
command 6-24
-nocopy argument for configure_field command -rand argument for configure_field command
6-24 6-24
-nopack argument for configure_field command -randc argument for configure_field command
6-24 6-24
-noprint argument for configure_field command requirements
6-24 using TLM in multi-language verification
-norand argument for configure_field command environments 2-19
6-24 run_test(), API to trigger SystemVerilog UVM
phases 8-11
run_uig.sh 5-6
O
-ovm argument for configure_code command S
6-27
SC
types mapped to e, example 6-9
P types mapped to SV, example 6-10
-pack argument for configure_field command sc_quasi_static_elab_status(), function to
6-24 determine the status of SystemC
pack_fields(), SystemC UVM function 8-20 quasi-static elaboration 8-1
-pass_field argument for configure_type scalars, mapping 6-17
command 6-22 -SCCREATEVIEWABLES, ncelab option, effect
passing of quasi-static hierarchies 8-26
compound transaction 2-26 +scDisableDynamicHierarchy ncsim option,
transactions across languages 2-22 effect on quasi-static hierarchy 8-5
preinitial point, definition 8-1 -scope argument for configure_scope command
prepare_item_to_send() 3-6 6-21

Index
-SCPARAMETER, ncelab option, effect of generic payload extensions in SystemC 7-14

quasi-static hierarchies 8-26 interface 7-1
scripts, run_uig.sh 5-6 example 7-10
sequence element 5-24 user view 7-10
sequences interface limitations 7-9
API for ML 3-2 known limitations 7-22
driving simulation 7-19 master driver using initiator socket 7-15
non-blocking read 7-20 slavemaster driver using initiator socket 7-17
SV in e testbench 3-1 Socket Binding in SystemC 7-2
signal element 5-60 transaction type registration 7-6
-skip_field argument for configure_type tlm_generic_payload 7-12, 7-26
command 6-22 -tlm2, irun or ncsc_run option to include TML 2.0
-skip_type argument for configure_type header files 8-8
command 6-22 -to_cpp_pointer argument for configure_field
slave 7-17 command 6-24
sockets 7-15, 7-17 to_e_event 5-39
specifying top entities 2-5 to_e_method 5-35
starting point for quasi-static elaboration 2-11 -to_lang argument for maptypes command 6-12
subcomponent element 5-43 -to_name argument
synchronized elaboration phases 2-7 for configure_field command 6-24
example 2-13 for configure_scope command 6-21
with ML-UVM 2-8 for configure_type command 6-22
SystemC -to_name argument for configure_enum_field
output files for maptypes 6-14 command 6-25
SystemC class containing methods to create -to_scope argument for configure_type command
quasi-static hierarchy 8-3 6-22
SystemVerilog top entities build order 2-6
output files for maptypes 6-13 top.e
testbench 2-14 example e to SV TLM port connection 2-24
top.sv file example for passing a compound transaction
for passing a compound transaction 2-27 2-26
for TLM port connection 2-24 top.sv
types mapped to e, example 6-4, 6-6 example e to SV TLM port connection 2-24
example for passing a compound transaction
T 2-27
-type argument
tests, as top entities 2-5 for configure_enum_field command 6-25
TLM 2.0 7-1 for configure_field command 6-23
comparison with previous solution 7-21 for configure_type command 6-22
data types definition 7-12 for print_type command 6-26
example 7-22 type mapping 6-19
generic payload between e, SystemVerilog, SystemC,
extensions 7-8 overview 2-23
memory management 7-9 example from e to SystemVerilog 6-2
generic payload extensions in e 7-13

Index
example from SystemC to e 6-9 -uvmtop Switch for irun 2-6

example from SystemC to SystemVerilog
6-10
example from SystemVerilog to e 6-4, 6-6
U
UIG invocation 5-5
uig_get_dut_interface_id 5-78
uig_get_dut_interface_path 5-78
uig_get_field_value_<type> 5-77
uig_get_num_instances 5-75
uig_get_uvm_path_by_id 5-76
update_item_after_done() 3-3
-use_cpp_type argument for configure_field
command 6-24
-use_existing argument for configure_type
command 6-22
-use_sc_type argument for configure_field
command 6-24
using
e test as the first top entity 2-15
language-neutral connection methods 2-21
SystemVerilog component as the first top
entity 2-16
utilities
ML-UVM for e 4-5
SystemVerilog ML-UVM 4-6
-uvm argument for configure_code command
6-27
UVM component element 5-16
UVM_OBJECT_REGISTER, SystemC UVM
macro, uvm_object class 8-19
UVM_OBJECT_UTILS, System 8-19
UVM_OBJECT_UTILS, SystemC UVM macro,
uvm_object class 8-19
uvm_object, SystemC class, definition 8-19
+UVM_TESTNAME, irun option to specify
SystemVerilog test top names 8-12
uvm_top_levels, variable recording
SystemVerilog UVM top levels 8-11
-uvmtest command-line switch for irun 4-1
-uvmtop SC, ncsim or irun option to create a
SystemC quasi-static design top 8-2
-uvmtop command line switch for irun 4-3

Uvm ML Ref

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Uvm ML Ref

Încărcat de

Drepturi de autor:

Formate disponibile

Incisive® Verification Kits

UVM Multi-Language Reference

1 About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

2 Multi-Language UVM (ML-UVM) Features for e and SystemVerilog .

UVM Multi-Language Reference iii

2.5.1 Advantages of Using TLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18

3 Using SystemVerilog Sequences in an e Testbench . . . . . . . . . . .3-1

4 Multi-Language UVM (ML-UVM) Reference . . . . . . . . . . . . . . . . . . .4-1

UVM Multi-Language Reference iv

5 UVM Interface Generator (UIG) Reference . . . . . . . . . . . . . . . . . . . .5-1

UVM Multi-Language Reference v

5.5.5 uig_get_uvm_path_by_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-76

6 mltypemap Utility: Automatic Generation of Data Types . . . . . . . .6-1

UVM Multi-Language Reference vi

6.4.3 configure_field Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23

7 Multi-Language TLM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

UVM Multi-Language Reference vii

8 SystemC in Mixed-Language UVM . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

UVM Multi-Language Reference viii

To find out … Read …

How SystemC® can participate in UVM-based Chapter 8 “SystemC in Mixed-Language

UVM Multi-Language Reference 1-1

1.1 Conventions in This Book

var name: [list of] type

extend enum-type-name: [name,…]

UVM Multi-Language Reference 1-2

Table 1-1 Document Conventions (continued)

construct, … An item, followed by a separator (usually a comma or a semicolon) and an

extend enum-type-name: [name,…]

| The pipe character indicates alternative syntax or parameters. For

type scalar-type (bits | bytes: num)

> Denotes a third-party VHDL simulator prompt.

% Denotes the UNIX prompt.

UVM Multi-Language Reference 1-3

This chapter contains:

● “Requirements for Multi-Language Verification Environments” on page 2-1

2.1 Requirements for Multi-Language Verification

● Instantiation and configuration

UVM Multi-Language Reference 2-1

2.2 Multi-Language UVM (ML-UVM) Features

● Multi-language test selection and top entity instantiation

UVM Multi-Language Reference 2-2

ML-UVM supports command-line control to instantiate top entities in a multi-language

● Synchronization of elaboration phases

● Multi-language TLM connectivity

2.2.1 Enabling the ML-UVM Features

● -uvmtest to declare the root entity of the logical multi-language testbench

2.3 Multi-Language Trees of UVCs

UVM Multi-Language Reference 2-3

There are two potential kinds of multi-language hierarchies:

● Single multi-language hierarchical tree

Figure 2-1 Multi-Language UVC Trees

Single Logical Tree Multiple Single-Language Trees

TLM Communication Module

UVM Multi-Language Reference 2-4

Tests as Top Entities

2.3.1 Specifying Top Entities

2.3.1.1 -uvmtest Switch for irun (and ncsim)

Specifying the test entity explicitly provides the following benefits:

For more information, see “-uvmtest” on page 4-1

UVM Multi-Language Reference 2-5

2.3.1.2 -uvmtop Switch for irun (and ncsim)

For more information, see “-uvmtop” on page 4-3.