Verification ContinuumTM

VC Verification IP
CXL Subsystem UVM
User Guide
Version R-2021.03-1, March 2021
Copyright Notice and Proprietary Information
 2021 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys,
Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use,
reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/company/legal/trademarks-brands.html.
All other product or company names may be trademarks of their respective owners.
Free and Open-Source Software Licensing Notices
If applicable, Free and Open-Source Software (FOSS) licensing notices are available in the product installation.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.

www.synopsys.com
VC VIP CXL Subsystem
UVM User Guide Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Web Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Synopsys Statement on Inclusivity and Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 CXL Subsystem Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Verification Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Protocol Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.3 LPIF Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 2
Installation and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Installing the Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Installing and Running Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Installing the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Updating an Existing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 3
General Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 High Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 PCIE VIP with Gen5 APN and CXL.io Link and Transaction Layer . . . . . . . . . . . . . . . . . . . . . . 30
3.1.2 CXL.cache/CXL.mem Link and Transaction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.3 CXL ARB/MUX component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.4 Flex Bus and Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 UVM Components of the CXL Subsystem Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 UVM Component for CXL Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Sequencers and Sequence APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Sequencers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2 Sequence APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Configuration Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.1 CXL Subsystem Configuration Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Status Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.1 CXL Subsystem Status Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Feedback
Synopsys, Inc. 3
 Contents VC VIP CXL Subsystem
UVM User Guide

3.6 CXL Subsystem Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.7 Testbench Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8 Available Protocol Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9 Dynamic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10 CXL Subsystem Configuration (svt_cxl_subsystem_configuration) APIs . . . . . . . . . . . . . . . . . . . . . 47
3.11 Configuring CXL System Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.12 DUT Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.12.1 DUT Integration with CXL Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.13 Key Use Cases of Cache Memory Transaction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.14 Transaction Logging Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.14.1 Transaction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.14.2 ARB/Mux Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15 Steps to Move from PCIe VIP based Testbench to CXL Subsystem Based Testbench . . . . . . . . . . . 54
3.15.1 Include the CXL Related Files (Make sure DESIGNWARE_HOME created & set from CXL
Subsystem) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15.2 Include and Import CXL Subsystem Packages in top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15.3 Base Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15.4 Environment: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.16 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.16.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.16.2 Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.16.3 Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.16.4 Usage with DWC CXL Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.16.5 Enumeration FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.16.6 Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.17 CXL 2.0 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.17.1 GPF Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.17.2 Qos Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.17.3 CXL IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.17.4 Memory Interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.18 PM VDM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.18.1 CXL PM VDM and PM Credit initialization APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.18.2 CXL Reset APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.18.3 CXL PMREQ APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.18.4 Warm Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.18.5 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.19 CXL DOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.19.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.19.2 Data Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.19.3 Protocol Checks and Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.20 Hot Plug Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.20.1 Usage API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.20.2 Topologies validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.20.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.20.4 Known limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.21 Viral Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.21.1 Configuration variable / Enabling Viral handling support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.22 TLM Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.22.1 Example usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Feedback
4 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Contents

Chapter 4
CXL Subsystem Verification Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1 Verification Requirements - - Supported CXL Device Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.1 CXL Subsystem VIP as Type 1 Device: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.2 CXL Subsystem VIP as Type 2 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1.3 CXL Subsystem VIP as Type 3 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2 Verification Requirement - Supported Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.1 Topology 1: Connect DUT and VIP at PCIE PIPE/ Serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.2 Topology 2: Connect DUT and VIP at ARB MUX (TLM/ LPIF/ Proprietary) . . . . . . . . . . . . . . 90
4.2.3 Topology 3: Connect DUT and VIP Link Layer Signalling (TLM/ LPIF/ Proprietary) . . . . . . 92
4.2.4 Running CXL Subsystem VIP example Test Cases with Topology #3 . . . . . . . . . . . . . . . . . . . . . 92
4.2.5 Topology 4: Connect DUT and VIP at Transaction Layer Signalling (TLM/Proprietary) . . . . 93

Chapter 5
CXL Application Layer Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1 Agent Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 User API of CXL Subsystem Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 6
CXL.io Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4 Sequencers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.6 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Chapter 7
CXL.mem and CXL.cache Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1.1 CXL.mem and CXL.cache Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1.2 Classes and Applications for Using CXL.mem/cache Component . . . . . . . . . . . . . . . . . . . . . . 112
7.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.3 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.4 Sequencers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.4.1 Description of CXL Cache/mem Sequencers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.5 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.6 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.7 Auto/Default Response Sequence Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.7.1 GO-Err/GO-Err-WritePull Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.8 Backdoor Access to Memcore (Memory Core) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.8.1 Initialize Memory Content Through Backdoor Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.8.2 Accessing the Memory Content Through Backdoor Mechanisms like Peek/Poke . . . . . . . . . 124

Chapter 8
CXL ARB/MUX Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.1.1 Agent Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.1.2 Classes and Applications for Using ARB/MUX Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.3 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Feedback
Synopsys, Inc. 5
 Contents VC VIP CXL Subsystem
UVM User Guide

8.4 Sequencers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.5 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.6 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.7 ARB/MUX Callback svt_cxl_arb_mux_callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Chapter 9
Logical PHY Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.1 Logical PHY Interface (LPIF) Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.1.1 LPIF Usage Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2 Integration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2.2 Generation of LPIF Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.3 LPIF Example Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.4 LPIF Protocol Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.4.1 LPIF Protocol Check Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.5 LPIF Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.6 LPIF XCHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.7 LPIF Specification Version 1.1 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.8 HVP Plans details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.8.1 CXL Cache/Mem HVP Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Chapter 10
Debug Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.1 CXL.cache/mem Transaction Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.1.1 Printing CXL.cache/mem Transaction Data into Log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.1.2 Fields of the CXL.cache/mem Transaction Log Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.2 CXL.io Transaction Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.2.1 Printing CXL.io Transaction Data into Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.2.2 Fields of the Transaction Log Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.3 CXL.io Flit Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.3.1 Printing CXL.io Flit handshaking into Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.3.2 Fields of the CXL.io Flit Log Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.4 ARB/MUX Transaction Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.4.1 Printing Mem Transaction Data into Transaction Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.4.2 Fields of the ARB/MUX Transaction Log Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
10.5 Symbol Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.5.1 Printing Transmitted and Received symbols into Symbol Log File . . . . . . . . . . . . . . . . . . . . . 161
10.5.2 Fields of the Symbol Log Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.5.3 Special Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
10.5.4 Special Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
10.5.5 Synchronization of Simulation Time Between Transaction Log and Symbol Log . . . . . . . . . 163

Feedback
6 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

Preface

About This Manual

This manual contains installation, setup, and usage material for SystemVerilog UVM users of the VC VIP
CXL Subsystem, and is for design or verification engineers who want to verify CXL Subsystem operation
using a UVM testbench written in SystemVerilog.

Web Resources
❖ Documentation through SolvNet: https://solvnetplus.synopsys.com (Synopsys password required)
❖ Synopsys Common Licensing (SCL): http://www.synopsys.com/keys

Customer Support
To obtain support for your product, choose one of the following:
1. Go to https://solvnetplus.synopsys.com and open a case.
Enter the information according to your environment and your issue.
2. Send an e-mail message to [email protected].
Include the Product name, Sub Product name, and Tool Version in your e-mail so it can be routed
correctly.
3. Telephone your local support center.
✦ North America:
Call 1-800-245-8005 from 7 AM to 5:30 PM Pacific time, Monday through Friday.
✦ All other countries:
http://www.synopsys.com/Support/GlobalSupportCenters

Synopsys Statement on Inclusivity and Diversity

Synopsys is committed to creating an inclusive environment where every employee, customer, and partner
feels welcomed. We are reviewing and removing exclusionary language from our products and supporting
customer-facing collateral. Our effort also includes internal initiatives to remove biased language from our
engineering and working environment, including terms that are embedded in our software and IPs. At the
same time, we are working to ensure that our web content and software applications are usable to people of
varying abilities. You may still find examples of non-inclusive language in our software or documentation
as our IPs implement industry-standard specifications that are currently under review to remove
exclusionary language.

Feedback
Synopsys, Inc. 7
 Preface VC VIP CXL Subsystem
UVM User Guide

Feedback
8 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

1
Introduction

1.1 Introduction
This guide describes the use model and high-level architecture of the CXL Subsystem solution for a
Compute Express Link (CXL) based system.
These are the specification references:
❖ Compute Express Link Specification: 20190701_ComputeExpressLink_Specification_r1p1.pdf
Revision 1.1 (June 2019)
❖ Compute Express Link Specification: CXL
Specification_rev2p0_ver1p0_2020Oct26_clean_Approved.pdf
❖ Logical PHY Interface (LPIF) Specification - LPIF 1.0 (March 23, 2019)
✦ Contact Synopsys for LPIF 1.1 specification information.
❖ PCIe Base specification Gen5 v1.0: NCB-PCI_Express_Base_5.0r1.0-2019-05-22.pdf
✦ Key interest: Gen5 and Alternate Protocol Negotiation (APN)
❖ PIPE Specification: phy-interface-pci-express-sata-usb30-architectures-3.1_v5_1_1.pdf
✦ Key interest: SerDes Arch features

1.2 CXL Subsystem Features

1.2.1 Verification Features
❖ Facilitates CXL DUT Verification at Block level, Sub-system level, Chip level (Full Stack) topologies
❖ Facilitates CXL.io, CXL.cache, CXL.mem (Type 1, Type 2, Type 3) devices.
❖ Callbacks, error injection, protocol checks, configuration, status objects, built in sequences.
❖ Multiple topology support is present. For example, full stack, CXL.io only, CXL.cache/mem only
and so on. Refer the chapter 4 for more information.
❖ Supports active mode.
❖ Supports normal PCIE Mode.
❖ CXL.io, CXL.cache and CXL.mem traffic and CXL flex bus framing after successful APN
❖ Supports LPIF/PIPE SerDes Arch / Serial interface
❖ CXL VIP as a host or device can be configured as Type 1, Type 2 or Type 3 device.

Feedback
Synopsys, Inc. 9
 Introduction VC VIP CXL Subsystem
UVM User Guide

❖ Debug features - Logging support

✦ Transaction logging feature for CXL.cache/mem in the transaction layer.
✦ Transaction logging feature for CXL.io at the Transaction layer and Data Link layer level
✦ Transaction logging feature for CXL.io Flits
✦ Transaction logging feature for ARB-MUX component.
✦ Symbol logging feature at Physical layer level
❖ CXL.io/CXL.cache/CXL.mem callbacks
❖ CXL.io/CXL.cache/CXL.mem analysis ports
❖ Protocol checks are supported for these:
✦ CXL.io/cache/mem
✦ LPIF signaling
✦ ARB-MUX
✦ Flex bus

1.2.2 Protocol Features

Chapter Feature Description Status

Chapter 1 Flex Bus Link Features:

Section 1.5 • Native PCIe mode
• CXL mode
• Static configuration of PCIe vs CXL
• Signaling rate - 8GT/s, 16 GT/s or
32GT/s for CXL mode
• Link width - x16, x8, x4, x2 and x1
(degraded mode) in CXL mode
• Bifurcation - x4 in CXL mode

Chapter 2 CXL System Architecture

• Type 1 CXL Device
• Type 2 Device
• Type 3 Device

Feedback
10 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Introduction

Chapter Feature Description Status

Chapter 3 CXL Transaction Layer: • CXL.io -

CXL.io - Note 1: CXL Subsystem Application Layer
• PCIe RC integrated EP VDM transaction and service requests can
• CXL Power management VDM be used for Power Management VDM
exchange and Advanced Error Reporting
• Optional PCIe features required for CXL
(AER) exchange from the test. Existing ATS
• Error Propagation API can be used to override 4th DW
• Memory Type Indication on ATS reserved field bit 3 of byte 4 to indicate CXL
• Deferrable Writes Src.
CXL.cache - Roadmap item*: Autonomous AER
• D2H Request reporting, ATS bit handling and CXL power
• D2H Response management VDM exchange, CXL ATS
• D2H Data • CXL.cache -
• H2D Request All features are supported expect those are
mentioned below.
• H2D Response
Roadmap items*:
• H2D Data
• DCOH in Device
• Cacheability details and request
restrictions • Error Response:
• Poison - Go_Writepull_Drop
• Bogus data for write transactions - GO-I response for RdShared, RdAny,
RdOwn transactions
• Cacheflushed
CXL.mem -
• Snoop Filter in Host
• M2S Req
Note2 - CXL.cache Channel Crediting from
• M2S RwD DL layer side (no restriction from TL side)
• S2M NDR Note3 - Finite number of cache lines
• S2M DRS (Though CXL VIP has configuration
• Forward Progress & Ordering Rules parameter
• Poison svt_cxl_cache_mem_configuration::num_c
ache_lines, VIP assumes it as infinite)
Transaction Flows: Note4 - 32-byte limitations:
• Transaction flows for Type1, Type 2 and - Mix of 32 & 64 byte traffic not
Type 3 devices supported
• Forward flows for Type 2 devices - Only AUTO mode supported for 32B
transfers
- Only Cache traffic supported
- Both TX & RX data packets are
expected to be 32B only when
operating in 32B mode

Feedback
Synopsys, Inc. 11
 Introduction VC VIP CXL Subsystem
UVM User Guide

Chapter Feature Description Status

Chapter 4 CXL Link Layer: Note1 - 32-byte support for mem traffic is
CXL.io - not present (32-byte support for cache
• PCIe Data Link Layer as the link layer of traffic exists)
CXL.io
CXL.mem and CXL.cache Common Link
Layer -
• Link Layer Registers
• Flit Packing Rules
• Link Layer Control Flit
• Link Layer Initialization
• CXL.cache/ CXL.mem Link Layer Retry
• CXL.cache-Side Poison and Viral

Chapter 5 CXL ARB/MUX: vLSM State

• Virtual LSM States • Reset, Active, Retrain, L1.1, L1.2, L1.3,
• ARB/MUX Link Management Packets L1.4, Link Reset, L2
• Arbitration and Data Multiplexing/ Status Synchronization
Demultiplexing Protocol/ARB/MUX Link Management
Packets (ALMP)
• State Request ALMP, State Status
ALMP

• ARB/MUX Bypass Feature

- Supported.

Roadmap items*:
• LinkError/LinkDisable
• DAPM

Chapter 6 Flex Bus Physical Layer: Note 1 - Flits with implied EDS can be seen
• Flex Bus.CXL Framing and Packet only with Null flit (with implied EDS).
Layout CXL.IO / Cache.Mem / ARB-MUX flits are
• Link Training currently not supported for implied EDS.
• Recovery.Idle and Config.Idle
Transactions to L0 Note 2 - L1 Abort Scenario is currently not
• L1 Abort Scenario supported.
• Retimers and Low Latency Mode

Chapter 7 Control and Status Registers: Note 1: VIP configuration and status class
• Configuration Space Registers provide attribute to configure for desired
• Memory Mapped Registers operation & report status
• CXL RCRB Base Register Roadmap item* - Hooks for Control and
Status Registers management, control and
verification

Feedback
12 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Introduction

Chapter Feature Description Status

Chapter 8 Reset, Initialization, Configuration and Note: Warm/Surprise reset is supported

Manageability: Roadmap item* - Cold Resets.
• CXL Boot and Reset
• CXL Device Boot Flow
• CXL Device Sleep State Entry Flow
• Functions Level Reset(LSR)
• Software Enumeration
• Accelerators with Multiple Flex Bus
Links
• Software view of HDM
• Manageability Model of CXL Devices
Matches PCIe

Chapter 9 Power Management: Note 1: CXL Subsystem VIP as Device can

• Policy based Runtime Control - Idle initiate L1 exit based on test control
Power - Protocol Flow Roadmap item* - L2 power management
• Compute Express Link Physical Layer
Power Management States
• CXL Power Management (Link PM
Entry & Exit)
• CXL.io Link Power Management
• CXL.cache + CXL.mem Link Power
Management

Chapter 10 Security - outside of the scope of this N.A

specification

Chapter 11 Reliability, Availability and Serviceability Note 1: Error injection through Callbacks
• Supported RAS Features (CXL.io -TL/DL, CXL.Cache/mem -
• Link CRC and Retry, Link Retraining and DL/ARBMux)
Recovery, eDPC, ECRC, Hot-Plug,
Corrected Error Count Information, Data Note 2: CXL subsystem VIP does not
Poisoning, Viral
support dropping of write data upon
• CXL Error Handling detection of viral.
• CXL Link Down Handling Roadmap item* -: Generation and handling
• CXL Viral Handling of AER
• CXL Error Injection

Chapter 12 Platform Architecture: Note 1: Applicable for Hardware, for digital

• Flex Bus connector Definition simulation CXL Subsystem VIP hooked up
• Topologies to DUT as Serial x16 link.
• Protocol Detection Note 2: Capable of operating at 32.0GTs
x16 or degraded modes (lower rates &
• AIC form factor
lower widths)
• AIC Power Envelope
• Flexbus Slot Auxiliary Power

Feedback
Synopsys, Inc. 13
 Introduction VC VIP CXL Subsystem
UVM User Guide

Chapter Feature Description Status

Chapter 13 Performance Considerations Roadmap item*

Roadmap item/s* - Contact Synopsys for these features.

1.2.3 LPIF Features

Chapter Feature Description Status

Section 1.2 LPIF Signal List: • Table 1

• LPIF Interface Signals for Logical PHY • Table 3
• List of Signals for PCIe support
• Clock Gating Interface Note - Table 2 and 4 not supported
• Configuration Interface

Section 1.3-1.8 • Interface reset requirements Note1 - All mandatory features are
• Exit clock gating mechanism supported except mid-sim reset.
• Data Transfer & Stall mechanism Note2 - Support for CXL.$ (CXL.io,
• Stream ID rules CXL.mem & CXL.cache)
• LPIF Request and Status

Section 1.9-1.18 LPIF State Machine All states are supported.

• Reset, Link Reset, and Retrain
• L2, L1 & L1 sub-states Exception- CXl.io - Reset, Active, L1,
• Active State Disabled state supported.
• Link Error and Disabled

Section 1.19 PTM Support Roadmap item*

Section 1.20 Scaling Scale Up-down Note - Supported scaling by clock

• Changing number of data lanes frequency
• Scaling by clock frequency

Section 1.21 Configuration Interface Roadmap item*

• Sideband transfer of information
• Optional Interface

Section 1.22 Support for Pipelining Note - VIP works with DUT having
• Insertion of staging buffers pipelining support.
• logPHY implementation for pipelining

Feedback
14 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Introduction

Chapter Feature Description Status

Section 1.23 Support for PCIe Roadmap item*

• Encoding for 2.5GT/s & 5.0 GT/s data
rates
• L0s support
• LTSSM to LPIF state mappings

Section 1.24 Support for CXL All features are supported for CXL
• CXL over Flexbus logPHY
• L0s support
• LTSSM to LPIF state mappings

Section 1.25 Bifurcation Support Note - Support present through

• Each bifurcated port is expected to have configuration variables
its own LPIF interface

1.3 Limitations
These features are not supported in this release of CXL Subsystem:
❖ Passive mode
❖ CXL functional coverage
❖ Entry/Exit for L2

Feedback
Synopsys, Inc. 15
 Introduction VC VIP CXL Subsystem
UVM User Guide

Feedback
16 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

2
Installation and Licensing

2.1 Installing the Product

You need to follow these steps for installation of the CXL Subsystem:
❖ Download the .run file (vip_cxl_subsystem_svt_<version>.run) for the CXL Subsystem.
Downloading From the Electronic File Transfer (EFT) (Download Center):
1. Point your web browser to https://solvnet.synopsys.com/DownloadCenter/dc/product.jsp.
2. Enter your Synopsys SolvNetPlus Username and Password.
3. Click ‘Sign In’ button.
4. Choose ‘VC VIP Library’ from the list of available products under ‘My Product Releases’.
5. Select the Product Version from the list of available versions.
6. Click the ‘Download Here’ button for HTTPS download.
7. After reading the legal page, click on ‘Agree and Sign In’.
8. Click on the file name to download.
9. Follow browser prompts to select a destination location.
10. You may download multiple files simultaneously.
Downloading Using FTPS/SFTP
1. Follow the above instructions through the product version selection step.
2. Click the ‘FTPS Download Instructions’/ ‘SFTP Download Instructions’ instead of the ‘Download
Here’ button.
3. Use the common-line lftp/sftp utility to connect to EFT and download using FTPS/SFTP protocol
If you are unable to download the Verification Subsystem IP using above instructions, obtain support for
download and installation over SolvNetPlus.

❖ Set DESIGNWARE_HOME to the absolute path where Synopsys CXL subsystem VIP needs to be
installed:
setenv DESIGNWARE_HOME <absolute_path_to_designware_home>
❖ Execute the .run file by invoking its filename. For example,
vip_cxl_subsystem_svt_<version>.run --dir $DESIGNWARE_HOME.

Feedback
Synopsys, Inc. 17
 Installation and Licensing VC VIP CXL Subsystem
UVM User Guide

The VIP is unpacked, and all the files and directories are installed under the path specified by the
DESIGNWARE_HOME environment variable. The .run file can be executed from any directory. The important
step is to set the DESIGNWARE_HOME environment variable before executing the .run file.
Once the .run file is extracted, you can see the following directories inside the DESIGNWARE_HOME.

Figure 2-1 Directories Inside DESIGNWARE_HOME

The CXL (which is a combination of 3 products - PCIe, CXL and CXL subsystem) gets installed inside the
VIP directory.
After extracting the .run file, you can see the following directories inside VIP directory.
❖ common: This contains the VIP common files and Synopsys Common Licensing files.
❖ svt: svt is set of base classes and library which are created on top of UVM/OVM/VMM
methodologies. All Synopsys VIP's share a common structure and agents, environments, sequencers
are designed in such a way that the VIP conveniently supports all three methodologies.

Inside svt directory, you can find the following directories.

❖ common: This contains the common structure of agents, environments and sequencers etc…
❖ cxl_subsystem_svt: is a superset containing CXL.IO & CXL MEM.Cache (cxl_svt) i.e. contains all the
three components CXL.io, CXL.cache, and CXL.mem
❖ cxl_svt: contains the code/contents related to CXL.cache/mem component only. If you have
cxl_subsystem_env then cxl_svt is automatically included.

cxl_svt is subset cxl_subsystem_svt.

Note

❖ pcie_svt: contains the code/contents related to CXL.io component.

Feedback
18 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Installation and Licensing

2.2 Installing and Running Examples

2.2.1 Installing the Example
These are the steps for installing and running the example tb_cxl_subsystem_uvm_basic_sys:
❖ Install the example using the following steps:
✦ Create a directory where the example needs to be installed.
% mkdir design_dir <provide any name of your choice>
✦ Go inside the directory
% cd <location_where_example_is_to_be_installed>
✦ Create a new directory called 'design_dir' to install the example inside this folder.
% mkdir design_dir
Note: <design_dir> is the project directory where the example is going to be installed. You can
provide any name of your choice.
✦ Check the available examples using the following command:
% $DESIGNWARE_HOME/bin/dw_vip_setup -i home
✦ Install the CXL Subsystem VIP example in the directory named 'design_dir'
% $DESIGNWARE_HOME/bin/dw_vip_setup -path ./design_dir -e
cxl_subystem_svt/tb_cxl_subsystem_uvm_basic_sys -svtb
The above command sets up all the required files inside 'design_dir'. The dw_vip_setup utility
creates three directories under design_dir which contain all the necessary model files. Files for every
VIP are included in these three directories.
You can find the following directories under 'design_dir'.

Figure 2-2 Directories inside 'design_dir'

❖ examples: Each VIP includes example testbenches. The dw_vip_setup utility adds them in this
directory, along with a script for simulation. If an example testbench is specified on the command
line, this directory contains all files required for model, suite, and system testbenches.

Feedback
Synopsys, Inc. 19
 Installation and Licensing VC VIP CXL Subsystem
UVM User Guide

❖ include: This contains language-specific include files. This directory "include/sverilog" is specified
in simulator commands to locate model files.
❖ src: Synopsys-specific include files This directory "src/sverilog/vcs" must be included in the
simulator command to locate model files.
The example would get installed under:
<design_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys

❖ Go inside the example and run the example (using the command mentioned in next step)
%cd <design_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
Here, you can find three directories named 'env', 'tests', 'dut'

Figure 2-3 View of tb_cxl_subsystem_uvm_basic_sys Example

You must use the svt_cxl_subsystem.uvm.pkg package, if the top-level environment that is
Note instantiated in the testbench is svt_cxl_subsystem_env.

Feedback
20 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Installation and Licensing

2.2.1.1 Overview of tb_cxl_subsytem_uvm_basic_sys Example

After extracting the CXL Subsystem VIP example, you can find the following directories and files present
inside the cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys directory.
The class reference for VC Verification IP for CXL Subsystem is available at:
Note
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uv
m_public/html/tb_cxl_subsystem_uvm_basic_sys.html

Files present inside tb_cxl_subsytem_uvm_basic_sys example:

The following files are present inside the example -
cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
top.sv : This file includes all the required packages that must be part of the testbench in order to use the CXL
Subsystem VIP. It also includes the topology specific continent. Further it contains active high 'Reset' block
for the VIP to configure its' internal registers and buffers (at least 100ns)
README: This offers an overview on how to run various test cases that are part of the example with all
possible topologies. It also provides description about the Testbench.
prescript: This is the prescript. This removes the topology file and compile file used in previous simulation.
Also, when using CXL IDE feature, it builds the shared object if ELLIPSYS_HOME is set.
Makefile: This is the script to run the existing test cases in VIP back to back setup

Note: These three option files would be used when using the Makefile options to run the simulation:
vcs_build_options: This file contains the compilation options when using the VCS simulator
vcs_build_options_with_aes: This file contains the compilation options for the VCS simulator to include
ELLIPSYS library files when using CXL IDE feature
vcs_elab_options*: This file contains the elaboration options when using the VCS simulator
sim_build_options : This file contains the compile time options to be picked up irrespective of the simulator
used
sim_run_options : This file contains the Run time options to be picked up irrespective of the simulator
used
ncv_build_options: This file contains the compilation options when using the Xcelium simulator
ncv_run_options* : This file contains the runtime options when using the Xcelium simulator
mti_build_options: This file contains the compilation options when using the MTI simulator
The following are the topology files available as part of the example. These files contain the topology
specific information (Creating the VIP instances and connecting them back to back)
❖ topology_snps_vip_cxl_b2b.svi
❖ topology_snps_vip_cxl_b2b_lpif.svi
❖ topology_snps_vip_cxl_io_dl_b2b.svi

These are the compile files available as part of the example. These compile files are used to manage the
components to be enabled and the interface to be used for the connection
Compile file related to Full Stack topology:

Feedback
Synopsys, Inc. 21
 Installation and Licensing VC VIP CXL Subsystem
UVM User Guide

❖ compile_snps_vip_pcie_serial.f
❖ compile_snps_vip_cxl_io_only_pcie_pipe.f
❖ compile_snps_vip_cxl_io_only_pcie_serial.f
Compile files related to LPIF topology:
❖ compile_snps_vip_io_lpif.f
❖ compile_snps_vip_cache_mem_only_dl_tl_lpif.f
❖ compile_snps_vip_cache_mem_lpif.f

Compile files related to TL+DL topology:

❖ compile_snps_vip_cxl_cache_mem.f
❖ compile_snps_vip_cxl_io_tl_dl_only.f

Compile file related to TL only topology:

❖ compile_snps_vip_cxl_cache_mem_tl.f

For more information of the above topology files and/or compiles files (and for the
Note description about the HDL Interconnect Macros used in topology files and compile options
used in compile files) refer to the following section in VC Verification IP CXL Subsystem VIP
DUT Integration guide

Directories present inside tb_cxl_subsytem_uvm_basic_sys Example:

The following directories are present inside the example -
cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
dut/ : This directory is to keep the DUT specific files. This directory contains the following file in it.
Customer specific files can be included inside this directory.
cust_pre_tb_top.svi - This files is provided for the user in order to include user packages and/or classes
tests/ : All the test cases that are part of the example are present inside this tests directory. The following test
cases are part of the example cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys

Feedback
22 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Installation and Licensing

Example Name Description

tb_cxl_subsystem_uvm_basic This example consists of following:

_sys
❖ CXL Subsystem Host and Device connected back to back.
❖ A top-level module, which includes tests, instantiates
interfaces, HDL interconnect wrapper, generates system
clock, and runs the tests
❖ CXL.io traffic test (ts.cxl_io_random_mem_wr_rd.sv)
❖ Type3 device CXL.mem traffic test
(ts.cxl_tl_type3_mem_wr_rd.sv).
❖ Type1 device CXL.cache traffic test
(ts.cxl_tl_type1_cache_wr_rd.sv)
❖ Type 2 Device test case
(ts.cxl_tl_random_mem_wr_rd.sv)
❖ Backdoor Memory Write test
(ts.cxl_tl_backdoor_mem_wr_rd.sv)
❖ Warm Reset test
(ts.cxl_io_warm_reset.sv)
❖ Type3 device GPF test
(ts.cxl_io_tl_type3_gpf.sv)
❖ IDE Sanity test
(ts.cxl_ide_sanity_test.sv)
❖ CXL DOE test
(ts.cxl_crt_doe_capabilities.sv)
For more details of installing and running the example, refer to the README
file in the example, located at:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/exampl
es/sverilog/tb_cxl_subsystem_uvm_basic_sys/README
OR
<design_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_
subsystem_uvm_basic_sys/README

env/ : All the environment related files are present inside the env directory. The following files and
directories are present inside this directory.
svt_cxl_subsystem_base_test.sv - This is the base test. It will instantiate all the required objects like
agents, env, configuration and status required for using the CXL Subsystem VIP. This will also contain the
basic configurations required to configure the Subsystem VIP
svt_cxl_subsystem_basic_env.sv -
hdl_interconnect_macros.sv - This will contain implementation of all the HDL Interconnect macros. These
macros will be used in topology file for creating VIP instances and for connecting signals.

Feedback
Synopsys, Inc. 23
 Installation and Licensing VC VIP CXL Subsystem
UVM User Guide

svt_cxl_subsystem_ts_env.pkg - This env package file includes all other files present in env directory.
svt_cxl_subsystem_test_suite_utils.svi* - This file is a container for all complex macros which are used at
multiple places to reduce lines of code.
svt_cxl_subsystem_user_defines.svi - This file contains the definition of user defines present in this
testbench
svt_cxl_dispatch_connector.sv - This files contains a connector class which is of type generic and used to
connect dispatch sequencer of a 'local' VIP to blocking put port of a 'remote' VIP in a typical back to back
testbench setup
The following files include the test cases specific to that component
❖ cxl_cache_mem_testlist.svi - This file includes CXL.cache/mem test cases
❖ cxl_io_testlist.svi - This file includes CXL.io test cases
❖ cxl_lpif_testlist.svi* - This file includes CXL LPIF test cases

svt_cxl_subsystem_ts_sequence_collection.svi - This file includes all the sequence collection lists present
inside env/seq_and_cb directory.
seq_and_cb/ - This directory contains all the sequences and sequence collection lists present as part of the
example - cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys

2.2.2 Running the Example

Use one of the following to run the testbench:

2.2.2.1 Use the Makefile

These tests are provided in the tests directory:
i. ts.cxl_io_random_mem_wr_rd.sv
ii. ts.cxl_tl_type3_mem_wr_rd.sv
iii. ts.cxl_tl_type1_cache_wr_rd.sv
iv. ts.cxl_tl_random_mem_wr_rd.sv
Generic gmake command to run any test case:
gmake USE_SIMULATOR=vcsvlog <TEST NAME>
SVT_CXL_SUBSYSTEM_COMPILE_FILE=compile_snps_vip_pcie_serial.f
SVT_CXL_SUBSYSTEM_TOPOLOGY_FILE=topology_snps_vip_cxl_b2b.svi
The above command is to run the test - ts.cxl_io_random_mem_wr_rd.sv for CXL.io traffic
generation with FULL_STACK topology over serial interface using VCS Simulator.

Possible usage scenarios with valid combinations of topology and compile files are present in
Chapter 4 CXL Subsystem Verification Topologies.
You can also invoke the command gmake help to show more options.

Feedback
24 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Installation and Licensing

2.2.2.2 Use the sim script to run the test

For example, to run ts.cxl_io_random_mem_wr_rd.sv, do following:
./run_cxl_subsystem_uvm_basic_sys -w cxl_io_random_mem_wr_rd vcsvlog
The above command is to run the test - ts.cxl_io_random_mem_wr_rd.sv for CXL.io traffic
generation with FULL_STACK topology over serial interface using VCS Simulator.
Invoke ./run_cxl_subsystem_uvm_basic_sys -help to show more options.

2.2.2.3 Running the Example with +incdir+

In the current setup, you must install the VIP under DESIGNWARE_HOME followed by creation of a design
directory which contains the versioned VIP files. With every newer version of the already installed VIP
requires the design directory to be updated. This results in:
❖ Consumption of additional disk space
❖ Increased complexity to apply patches
The alternative approach of directly pulling in all the files from DESIGNWARE_HOME eliminates the need for
design directory creation. VIP version control is in the command line invocation.
The following code snippet shows how to run the basic example from gmake command:
cd <testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
// To run the example using the gmake command with +incdir+
gmake <TEST_NAME> USE_SIMULATOR=vcsvlog
SVT_CXL_SUBSYSTEM_COMPILE_FILE=compile_snps_vip_cxl_io_only_pcie_serial.f VERBOSE=1
WAVES=fsdb SVT_CXL_SUBSYSTEM_ENABLE_LOGGING=1 INCDIR=1
For example, the following compile log snippet shows the paths and defines set by the new flow to use VIP
files right out of DESIGNWARE_HOME instead of design_dir.

vcs -l ./logs/compile.log -Mdir=./output/csrc

+define+DESIGNWARE_INCDIR=<DESIGNWARE_HOME> \
+define+SVT_LOADER_UTIL_ENABLE_DWHOME_INCDIRS
+incdir+<DESIGNWARE_HOME>/vip/svt/cxl_subsystem_svt/R-2020.09-2/sverilog/include \
+incdir+<DESIGNWARE_HOME>/vip/svt/cxl_svt/R-2020.09-2/sverilog/include \
+incdir+<DESIGNWARE_HOME>/vip/svt/pcie_svt/R-2020.09-2/sverilog/include \
-ntb_opts uvm -full64 -sverilog +define+SVT_MEM_SA_STATUS_RD_B4_WR=0
+define+SVT_MEM_SA_STATUS_RD_RD_NO_WR=0 \
+define+UVM_PACKER_MAX_BYTES=1500000 +define+UVM_DISABLE_AUTO_ITEM_RECORDING -f
svt_cxl_subsystem_compile_file.f \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/env/seq_and_cb \
-timescale=1ns/1fs +libext+.v+.sv -y <testbench_dir>/src/verilog/vcs \
-y <testbench_dir>/src/sverilog/vcs \
+define+UVM_VERDI_NO_COMPWAVE -P pli.tab msglog.o -debug_acc+pp+dmptf+thread -
debug_region=cell+encrypt \
+define+SVT_FSDB_ENABLE +define+WAVES_FSDB +define+WAVES=\"fsdb\" +plusarg_save -
debug_access+pp+dmptf+thread \
-debug_region=cell+encrypt -notice -P /global/apps/verdi_2020.03-SP2-
1/share/PLI/VCS/LINUX64/novas.tab \
/global/apps/verdi_2020.03-SP2-1/share/PLI/VCS/LINUX64/pli.a +define+SVT_UVM_TECHNOLOGY
\

Feedback
Synopsys, Inc. 25
 Installation and Licensing VC VIP CXL Subsystem
UVM User Guide

+define+SYNOPSYS_SV
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/. \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/../../env \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/../env \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/env \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/dut \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/hdl_interconnect \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/lib \
+incdir+<testbench_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_
sys/tests \
-o ./output/simvcssvlog -f top_files -f hdl_files

For VIPs with dependency, include the +incdir+ for each dependent VIP.
Note

2.3 Licensing
CXL 2.0 Subsystem features can be enabled by the following license features:
❖ SUB-CXL20-SVT (or)
❖ VIP-LIBRARY2019-SVT+SUB-CXL20-EA-SVT (Library license must be present to use EA key)
CXL 1.1 Subsystem features can be enabled by following license feature:
❖ SUB-CXL-SVT / VIP-LIBRARY2019-SVT

SUB-CXL-SVT / SUB-CXL20-SVT is a superset of VIP-PCIE-G5-SVT license. This means that

Note
you can exercise all PCIe related functionality using this license.

To debug license issues, you can capture the SLI information into a log file by following these steps:
Step1: Set the following environment variables to capture the SLI information.
setenv FLEXLM_DIAGNOSTICS 5
setenv SLI_DEBUG_SERVER 1
setenv SLI_DEBUG_CLIENT 1
Step2: Generate the lic.log using the following command along with the gmake.
gmake .. |&tee lic.log
If you face any license issue, open a case over SolvNetPlus to obtain Synopsys VIP Support.

Feedback
26 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Installation and Licensing

2.4 Updating an Existing Model

To add or update an existing model, do the following:
1. Install the model to the same location as your other VIPs by setting the
$DESIGNWARE_HOMEenvironment variable.
2. CXL subsystem contains dependent components. The .run file contains dependent models such as
cxl_svt, pcie_svt, user has to make sure all the VIP points to the latest version.
You needs to update version of cxl_subsystem_svt along with all other subsystem component while
migrating to a new release.
You can update your design_dir by specifying the version number of the model.
Example:
$DESIGNWARE_HOME/bin/dw_vip_setup -path basic -example
cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys -v R-2020.12-1-T-20201221
$DESIGNWARE_HOME/bin/dw_vip_setup -path basic -update -suite_list ./suitelistfile
Content of suite_list file:
cxl_svt -v R-2020.12-1-T-20201221
pcie_svt -v R-2020.12-1-T-20201221
svt -v R-2020.12
common -v R-2020.12
Invoke $DESIGNWARE_HOME/bin/dw_vip_setup -help to see more options.

Feedback
Synopsys, Inc. 27
 Installation and Licensing VC VIP CXL Subsystem
UVM User Guide

Feedback
28 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

3
General Concepts

3.1 High Level Architecture

CXL Subsystem encapsulates the following components which are connected with each other to implement
the CXL based subsystem environment.
1. CXL.io Link and Transaction Layer with Gen5 APN (type= svt_pcie_device_agent instance= io[0] )
2. CXL.cache/CXL.mem Link and Transaction Layer (type= svt_cxl_env= cache_mem_env)
3. CXL ARB/MUX component. (type= svt_cxl_arb_mux_agent instance= arb_mux[0]()
4. Flexbus component.
This figure shows the high-level architecture of the CXL subsystem.

Feedback
Synopsys, Inc. 29
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.1.1 PCIE VIP with Gen5 APN and CXL.io Link and Transaction Layer
The PCIe VIP link and transaction layer is enhanced to handle the CXL.io protocol messages.
The CXL VIP autonomously negotiates CXL by sending Modified TS Ordered Sets advertising Alternate
Protocol during configuration states.

3.1.2 CXL.cache/CXL.mem Link and Transaction Layer

Link Layer implements Flit Packing/Unpacking, integrity checking, ACK protocol and retry. Transaction
Layer implements Tx/Rx Channel interfaces for each message channel defined by the CXL protocol, and
Flow control mechanism.CXL.cache/CXL.mem Link Layer transaction layers implement the flit
packing/unpacking, ack and retry protocol.

3.1.3 CXL ARB/MUX component

The ARB/MUX dynamically multiplexes the CXL.io and CXL.cache/CXL.mem inbound and outbound
traffic. It interfaces with the PCIe physical layer. For outbound traffic, the ARB/MUX arbitrates between
requests from the CXL.io and CXL.cache/CXL.mem link layers and multiplexes the data to forward to the
physical layer. For inbound traffic, the ARB/MUX determines the protocol ID and forwards the packets to
the appropriate link layer. It implements a vLSM for CXL.io and CXL.cache/CXL.mem, which negotiates
the virtual link state with a link partner vLSM.

Feedback
30 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

3.1.3.1 CXL ARB/MUX

ARB/MUX multiplexes and de-multiplexes CXL.io, CXL.cache/mem, and CXL ARB/MUX link
management packets (ALMPs).Virtual Link State Machine (vLSM): The ARB/MUX maintains vLSM state
for each CXL link layer it interfaces with - CXL.io and CXL.cache/mem.

3.1.4 Flex Bus and Physical Layer

Physical layer is common to CXL.io and CXL.cache/CXL.mem. It negotiates with the physical link. You can
refer the CXL Subsystem Class reference guide for CXL Subsystem Component, sequencer, transaction
classes and other related details.

The class reference for VC Verification IP for CXL Subsystem is available at:
Note
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uv
m_public/html/index.html

3.2 UVM Components of the CXL Subsystem Environment

The Verification VIP for CXL is a suite of advanced verification components and data objects based on
SystemVerilog UVM compliant technology. The Verification Compiler CXL VIP is based on the following
UVM agent architecture and data objects. CXL Subsystem env is the top-level env for CXL based subsystem
which encapsulates the PCIE VIP with Gen5 APN and CXL.io enhancements, CXL Cache/mem layer
(CXL.cache/mem) and CXL ARB/MUX component which are connected with each other to implement the
CXL based system.
svt_cxl_subsystem_env :Defines a CXL Subsystem env for the CXL Subsystem SVT suite. The CXL
Subsystem env encapsulates the PCIE VIP with Gen5 APN and CXL.io enhancements, CXL Cache/mem
layer (CXL.cache/mem) and CXL ARB/MUX component which are connected with each other to
implement the CXL based system.
svt_cxl_subsystem_env
|
|--------> io[$] (type= svt_pcie_device_agent)
|
|--------> arb_mux[$](type= svt_cxl_arb_mux_agent)
|
|--------> io_lpif[$] (type= svt_cxl_io_lpif_agent)
|
|--------> subsystem_app[$] (type= svt_cxl_subsystem_app_agent)
|
|--------> cache_mem_lpif [$](type= svt_cxl_cache_mem_lpif_agent)
|
|--------> cache_mem_env(type= svt_cxl_env)
|
|--------> cache_mem[$] (type= svt_cxl_agent)

Feedback
Synopsys, Inc. 31
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Refer HTML class Reference for more details:

$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/Env_class_list.html

3.2.1 UVM Component for CXL Agents

❖ svt_pcie_device_agent :PCIE SVT agent acting as RC/EP. This generates CXL.io transactions. Refer
the PCIE SVT class reference for more details.
❖ svt_cxl_arb_mux_agent :The svt_cxl_arb_mux_agent encapsulates ARB/MUX driver, sequencer
and monitor.
❖ svt_cxl_io_lpif_agent : Agent class that models IO LPIF component
❖ svt_cxl_cache_mem_lpif_agent : Agent class that models Cache/Mem LPIF component.
❖ svt_cxl_env :The CXL ENV encapsulates the CXL.cache/mem Host or Device agent, CXL system
sequencer and the CXL system configuration. This generates CXL.cache/mem transactions.
Note: svt_cxl_subsystem_env is top level env, and it contains the svt_cxl_env, which is nothing
but the cache_mem_env
✦ svt_cxl_agent : This class is the CXL Agent class. This signifies the cache_mem agent. This
contains the Transaction Layer and Link Layer of CXL Cache/mem component
Refer HTML class reference for more details:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_publi
c/html/Agent_class_list.html

3.3 Sequencers and Sequence APIs

The CXLVIP supports extending UVM sequence item data classes for customizing randomization
constraints. This allows you to disable some reasonable_* constraints and replace them with constraints
appropriate to your system. Individual reasonable_* constraints map to independent fields, each of which
can be disabled.

Feedback
32 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

3.3.1 Sequencers
Each component in the agent has its own service sequencer. All SVT sequences are derived from
uvm_sequence. Sequences or individual sequence items are executed on the appropriate sequencer.
svt_cxl_subsystem_sequencer: This class is the UVM System sequencer class. Top level virtual sequencer
which can be used to control all of the CXL.io/cache/mem and ARB-MUX/LPIF sequencers present in the
CXL Subsystem.

Feedback
Synopsys, Inc. 33
 General Concepts VC VIP CXL Subsystem
UVM User Guide

svt_cxl_subsystem_sequencer
|
|--------> cxl_io_virt_seqr[] (type= svt_pcie_device_virtual_sequencer)
|
|--------> arb_mux_virt_seqr[] (type= svt_cxl_arb_mux_virtual_sequencer)
|
|--------> lpif_virt_seqr[]) (type= svt_cxl_lpif_virtual_sequencer)
|
|-------> subsystem_app_virt_seqr[] (type= svt_cxl_subsystem_app_virtual_sequencer)
|
|--------> cache_mem_system_seqr (type= svt_cxl_system_virtual_sequencer)
|
|----------> cache_mem_virt_seqr (type= svt_cxl_virtual_sequencer)

3.3.1.1 UVM Component for Top Level CXL Sequencers

The list of sequencer is mentioned in this table.

Sequencer Type Description

svt_cxl_system_virtual_sequencer This class is the CXL System sequencer class. This is a

(cache_mem_system_seqr) virtual sequencer which can be used to control all of the
cache mem sequencers that are in the cache mem system

svt_cxl_virtual_sequencer(cache_mem_virt_seqr) This virtual sequencer can be used to control all of the

sequencers that are operating at CXL Transaction and Data
Link Layer.

svt_pcie_device_virtual_sequencer(cxl_io_virt_seqr[]) The device agent class has a virtual sequencer object of

type svt_pcie_device_virtual_sequencer that
connects to all sequencers that are defined under its
hierarchy.

svt_cxl_arb_mux_virtual_sequencer(arb_mux_virt_se This class defines a virtual sequencer that can be

qr[]) connected to the svt_cxl_arb_mux_agent.

svt_cxl_lpif_virtual_sequencer(lpif_virt_seqr[]) This class defines a virtual sequencer that can be

connected to the svt_cxl_lpif_agent.

svt_cxl_arb_mux_service_sequencer This class is UVM Sequencer parameterized by

svt_cxl_arb_mux_service_transaction class
object. This service transaction sequencer is used to
provide Link Up information to Arb/Mux when PL is not
present as a start point for Arb/Mux functionality.

Feedback
34 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

Sequencer Type Description

svt_cxl_lpif_service_sequencer This class is UVM Sequencer parameterized by

svt_cxl_lpif_service_transaction class object.
This sequencer helps modelling user specific LPIF
operations.

svt_cxl_dl_service_sequencer This class is UVM Sequencer parameterized by

svt_cxl_dl_service_transaction class object.

svt_cxl_flit_packer_sequencer This class is UVM Sequencer parameterized by

svt_cxl_flit_packer_transaction class object. This
Flit packer sequencer is used to provide flit packer
transaction with CXL.cache for Request, response and data
or CXL.mem for Request/NDR and Request/Response with
data as a start point for CXL flit packer when to start its
packing during MANUAL Mode. Based on above inputs, flit
packer will wait for receiving respective number of request
from channel sequencers and starts flit packer operation.

svt_cxl_tl_rsp_sequencer This class is UVM Sequencer that provides responses for

the svt_cxl_tl_agent class when configured as a HOST
or a DEVICE. The svt_cxl_tl_agent class is
responsible for connecting this sequencer to the driver if the
agent is configured as UVM_ACTIVE.

svt_cxl_tl_req_sequencer This class is UVM Sequencer that provides stimulus for the
svt_cxl_tl_driver class. The svt_cxl_tl_agent
class is responsible for connecting this sequencer to the
driver if the agent is configured as UVM_ACTIVE.

svt_cxl_channel_sequencer This class is UVM Sequencer parameterized by

svt_cxl_channel_transaction class object. This
Channel sequencer is used to mimic three independent
channels for CXL.cache for Request, response and data
and two independent channels for CXL.mem for
Request/NDR and Request/Response with data. These
channel sequencers provides sequence items of
svt_cxl_channel_transaction type to Data link Layer
Driver for further processing.

Refer HTML class reference for details:

$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/sequencer/class_svt_cxl_subsystem_sequencer.html
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/Sequencer_class_list.html
For the usage of the sequencers related to CXL.io, you can refer the section 5.4 Sequencers, for
CXL.cache.mem sequencers, refer to the section 6.4 Sequencers and for ARB/MUX Sequencers refer to the
section 7.4 Sequencers.
CXL Subsystem has the following transaction and service class:
❖ CXL.io re-use PCIe VIP transaction objects for communication with testbench
✦ Transactions -- Correspond to a transaction item that is to be sent across the bus.

Feedback
Synopsys, Inc. 35
 General Concepts VC VIP CXL Subsystem
UVM User Guide

✧ svt_pcie_driver_app_transaction -- A transaction class that models PCIExpress application

level packets which will be translated into TLPs. Supports all the transaction types supported
by the Driver.
✦ Services -- Commands to give the model that are related to behavior or configuration
✧ svt_pcie_device_agent_service -- A transaction class which supports all the service
types supported by the device agent.
✧ svt_pcie_driver_app_service -- A transaction class which supports all the service
requests that can be processed by the Driver application
✧ svt_pcie_requester_app_service -- A transaction class which supports all the service
requests that can be processed by the Requester application
✧ svt_pcie_target_app_service -- A transaction class which supports all the service
requests that can be processed by the Target application
✧ svt_pcie_io_target_service -- A transaction class which supports all the service requests
that can be processed by the IO Target application
✧ svt_pcie_mem_target_service -- A transaction class which supports all the service
requests that can be processed by the Memory Target application
✧ svt_pcie_cfg_database_service -- A transaction class which supports all the service
requests that can be processed by the Cfg Database application
✧ svt_pcie_global_shadow_service -- A transaction class which supports all the service
requests that can be processed by the Global Shadow Memory application
✧ svt_pcie_tl_service -- A transaction class which supports all the service requests that can
be processed by the Transaction layer
✧ svt_pcie_dl_service -- A transaction class which supports all the service requests that can
be processed by the Data Link layer
✧ svt_pcie_pl_service -- A transaction class which supports all the service requests that can
be processed by the PHY layer
You can refer the PCIe VIP Class reference guide for details.
❖ CXL mem/cache supports the following communication interface with user testbench
✦ svt_cxl_transaction - A transaction class for CXL Transaction layer.
✦ svt_cxl_channel_transaction - A transaction class for CXL Link layer.
❖ svt_cxl_flit - A transaction class for communication with Link Layer to ARB-MUX Layer.

3.3.2 Sequence APIs

Many APIs are available to ease and accelerate the development. You can refer the sequence class
svt_cxl_subsystem_api_collection_sequence for complete details on the available sequence APIs.
Some of the available APIs are:
a. activate_cxl_io_link() - Method to activate PL and DL link up of CXL.io. This is a blocking
method which waits till link is up.
b. generate_cxl_io_mem_wr() - Method to initiate CXL.io Mem.Wr driver app transactions.
c. generate_cxl_io_mem_rd() - Method to initiate CXL.io Mem.Rd driver app transactions. It is a
blocking method and returns payload after successful operation.

Feedback
36 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

d. generate_cxl_tl_rand_mem_traffic() - Method to initiate Random CXL.mem RwD and Req

transactions from the Transaction Layer.
e. generate_cxl_tl_rand_cache_mem_traffic() - Method to initiate Random CXL.cache/mem
transactions from the Transaction Layer based on the device type.
f. generate_cxl_pm_vdm() - Method to initiate CXL PM VDM transactions.
g. pm_credit_initialization() - Method to perform Credit and PM initialization.
h. perform_warm_reset() - Method to perform Warm Reset followed by Hot.Reset entry
i. enumerate_cxl_device () - API to perform the enumeration for CXL device DUT.

You can refer the VC Verification IP for CXL Subsystem class reference available at:
Note
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html/s
equences/class_svt_cxl_subsystem_virtual_api_collection_sequence.html

Feedback
Synopsys, Inc. 37
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.4 Configuration Data Objects

3.4.1 CXL Subsystem Configuration Data Objects
This illustration shows the inheritance diagram for all the configuration objects.

Configuration data objects are abstracted data objects that represent the content of CXL VIP configuration
data and protocol transactions. The top-level configuration data objects are:
svt_cxl_subsystem_link_configuration is used to encapsulate host and device configuration
information.

Feedback
38 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

svt_cxl_subsystem_configuration: CXL Subsystem Configuration data and methods used to configure

CXL Subsystem. It encapsulates CXL cache and mem configurations, ARB-MUX configurations and CXL io
agent configurations.

svt_cxl_subsystem_link_configuration(cust_cfg)
|
|------>svt_cxl_subsystem_configuration(host_cfg/device_cfg)
|
|--------> cxl_io_cfg[] (type= svt_pcie_device_configuration)
|
|--------> arb_mux_cfg[] (type= svt_cxl_arb_mux_configuration)
|
|--------> lpif_cfg[] (type= svt_cxl_lpif_configuration)
|
|--------> subsystem_app_cfg[] (type= svt_cxl_subsystem_app_configuration)
|
|--------> cache_mem_sys_cfg (type= svt_cxl_system_configuration)
|
|----------> host_cfg/device_cfg (type= svt_cxl_cache_mem_configuration)

UVM top level configuration objects:

❖ svt_cxl_system_configuration(cache_mem_sys_cfg): CXL System Configuration
❖ svt_cxl_arb_mux_configuration (arb_mux_cfg[]): This class contains CXL ARB/MUX agent
Configuration.
❖ svt_cxl_lpif_configuration(lpif_cfg[]): This class contains CXL LPIF Configuration
❖ svt_cxl_cache_mem_configuration[host_cfg/device_cfg): This class contains CXL cache
mem agent Configuration. This class acts as a base class for Host and Device agent configuration,
and contains fields required by both the Host and Device agent configurations.
❖ svt_pcie_device_configuration(cxl_io_cfg[]): The PCIe Agent is configured using an object
of class type svt_pcie_configuration. An object of this type with an instance name of pcie_cfg is
defined in svt_pcie_device_configuration class. This class is comprised of data members and
class object members. The object members represent the configuration of sub-components of the
PCIe Agent class.

Refer HTML Class Reference for more details:

$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/Configuration_class_list.html
Usage note for creating instance of svt_cxl_subsystem_link_configuration.

Feedback
Synopsys, Inc. 39
 General Concepts VC VIP CXL Subsystem
UVM User Guide

svt_cxl_subsystem_link_configuration cust_cfg(user_cfg)
Note : <user_cfg> is the configuration attribute handle name which is given by user.
Class user_base_test extends svt_cxl_subsystem_base_test;
/**
* Instance of CXL Subsytem native system environment
*/
svt_cxl_subsystem_env env;
/**
* Instance of CXL Subsytem native system configuration
*/
svt_cxl_subsystem_link_configuration cust_cfg;
virtual function void build_phase( uvm_phase phase );
/** Create the configuration object required for this test */ This create object of CXL
VIP configuration
cust_cfg = svt_cxl_subsystem_link_configuration ::type_id::create("cust_cfg");
endfunction
endclass
Accessing CXL.io or cache/mem Configuration
These can be accessed through below hierarchy.
cust_cfg.host_cfg.cxl_io_cfg[i].apn_mode != svt_pcie_types::APN_PCIE_TLP_DLLP_ONLY
cust_cfg.device_cfg.cache_mem_sys_cfg.device_cfg[i].device_type
=svt_cxl_cache_mem_configuration::TYPE2_DEVICE;
cache_mem_sys_cfg -> is a common handle to cache and mem blocks of VIP. This can accessed as
explained above in a hierarchical manner. For more details, refer to respective chapter 6.2 Configurations
cachemem section.
Example of configuration attributes usage in CXL subsystem
The following illustration shows the inheritance diagram for the svt_pcie_device_configuration
configuration objects. CXL subsystem can be programmed as a Host or a Device.
svt_cxl_subsystem_configuration::set_subsystem_type(subsystem_type_enum subsystem_type)
❖ Setup CXL subsystem as CXL.io, Cache.mem with ARB MUX, Cache.mem & PCIE Only.
svt_cxl_subsystem_configuration::configure_subsystem(subsystem_type_enum);
❖ Set existing or user-created PCIe VIP configuration handle
svt_cxl_subsystem_configuration::set_cxl_io_cfgs(svt_pcie_device_configuration)
❖ Enable/Setup APN negotiation of PCIe VIP. It also sets APN capabilities for Flex bus support.
svt_cxl_subsystem_configuration::configure_flex_bus(common_clk, sync_header_bypass,
retimer_1_aware, retimer_2_aware, pcie_cxl_capables , vendor_id );

Usage Notes for Flex bus configuration:

❖ Flexbus Layer must be configured to support Gen5 rate and Specification version should be 5.0 or
above. Refer below:
cfg.cxl_io_cfg[i].pcie_spec_ver = svt_pcie_device_configuration::PCIE_SPEC_VER_5_0;
cfg.cxl_io_cfg[i].pcie_cfg.pl_cfg.set_link_speed_values(`SVT_PCIE_SPEED_32_0G |
`SVT_PCIE_SPEED_16_0G | `SVT_PCIE_SPEED_8_0G | `SVT_PCIE_SPEED_5_0G |
`SVT_PCIE_SPEED_2_5G);
__

Feedback
40 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

❖ To peform APN negotiation in CXL mode, "configure_flex_bus" API can be used directly after the
specification version is set using "set_spec_ver" API. This allows to configure different settings of
flexbus
/** Configure PCIe APN capabilities for Flex bus operation for both host and device flex
bus */
cust_cfg.host_cfg.configure_flex_bus(0,0,0,0);
cust_cfg.device_cfg.configure_flex_bus(0,0,0,0);
OR
cust_cfg.host_cfg.configure_flex_bus(1,1,0,0);// common_clk enabled with
sync_header_bypass feature
cust_cfg.device_cfg.configure_flex_bus(1,1,0,0);// common_clk enabled with
sync_header_bypass feature

To enable and wait for link up of flexbus, wait_for_flexbus_linkup API can be used available inside
svt_cxl_subsystem_virtual_api_collection_sequence.
For the usage of the configurations related to CXL.io, you can refer the section 5.2 Configuration, for
CXL.cache.mem configurations, refer to the section 6.2 Configurations and for ARB/MUX configurations
refer to the section 7.2 Configurations.

3.5 Status Data Objects

3.5.1 CXL Subsystem Status Data Objects
Status data objects are abstracted data objects that represent the content of CXL Subsystem VIP statistics.
Registered status objects are updated in real time. Separate statistics are kept per layer/application. Status
objects are useful for:
❖ functional coverage
❖ reporting testcase progress
❖ debug

Feedback
Synopsys, Inc. 41
 General Concepts VC VIP CXL Subsystem
UVM User Guide

The top-level status data objects are:

svt_cxl_subsystem_status(host_status/device_status) :This is the CXL Subsystem 'top level' status class. It
encapsulates the IO status, Cache/mem system status and ARB/MUX status class objects corresponding to
the CXL.io, Cache/mem and ARB-MUX agents present in the CXL Subsystem.
|------>svt_cxl_subsystem_status(host_status/device_status)
|
|--------> io_status[](type= svt_pcie_device_status)
|
|--------> arb_mux_status[] (type= svt_cxl_arb_mux_status)
|

Feedback
42 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

|--------> lpif_status[](type= svt_cxl_lpif_status)

|
| --------> subsystem_app_status[](type= svt_cxl_subsystem_app_status)
|
|----------> cache_mem_sys_status (type= svt_cxl_system_status)

UVM component for top level status attribute:

❖ svt_cxl_system_status(cache_mem_sys_status) :This is the CXL System status class that contains an
array of CXL.cache/mem status handles corresponding to each CXL agent
❖ svt_cxl_arb_mux_status(arb_mux_status[]) :This is the CXL ARB_MUX status class used by
arb_mux members.
❖ svt_cxl_lpif_status(lpif_status[]): This is the CXL LPIF status class
❖ svt_cxl_tl_status(tl_status):This class contains status information regarding Transaction layer of
Host, Device agents.
❖ svt_cxl_status:This is the CXL VIP 'top level' status class used by Host, Device agents.
❖ svt_cxl_dl_status(dl_status): This class contains status information regarding a CXL Link Layer
Host, Device agents.
❖ svt_pcie_device_status(io_status[]): The PCIe Agent has a set of state values representing the status
of its constituent blocks at any given time in the test simulation. And these state values are
encapsulated within the svt_pcie_status class. The svt_pcie_device_status class has an object
of type svt_pcie_status instanced as pcie_status.
Refer HTML Class Reference for more details:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/Status_class_list.html
An example of status attribute:
/** Instances of Subsystem status */
svt_cxl_subsystem_status host_status, device_status;
/** Create status objects for Host and Device subsystems */
host_status = svt_cxl_subsystem_status::type_id::create("host_status");
device_status = svt_cxl_subsystem_status::type_id::create("device_status");
a.
if(device_status.io_status[i].pcie_status.pl_status.alternate_protocol_negotia
tion_status != svt_pcie_pl_status::APN_SUCCESSFUL) begin
//statement
end
b.
if(device_status.io_status[i].pcie_status.pl_status.flexbus_enabled) begin
//statement
end
c.
wait((vip_status.cache_mem_sys_status.host_cache_mem_status[link_num].dl_statu
s.rx_cache_rsp_credits== 0)

Feedback
Synopsys, Inc. 43
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Refer to section 6.3 status for details of cache_mem status attribute.

3.6 CXL Subsystem Callbacks

Callbacks provide a means to examine or modify transactions at various points in the protocol stack. This
chapter describes their basic usage, provides some examples, and gives tips for debugging them. Within a
transaction, you can use the transaction handle to:
❖ Understand where in the protocol layers a particular transaction is being processed.
❖ Examine a particular field that was added to a transaction (for example, the Link Layer Sequence
Number).
The top level callbacks are
❖ svt_cxl_arb_mux_callback: CXL ARB/MUX callback class defines the component callback methods
❖ svt_cxl_io_lpif_callback: CXL IO LPIF callback class defines the component callback methods
❖ svt_cxl_cache_mem_lpif_callback: CXL Cache/Mem LPIF callback class defines the component
callback methods
❖ svt_cxl_dl_monitor_callback: CXL DL Monitor callback class defines the component callback
methods
❖ svt_cxl_dl_callback: CXL Data Link Layer callback class defines the component callback methods
❖ svt_cxl_tl_callback: CXL Transaction layer callback class defines the component callback methods

Refer HTML Class Reference for more details:

$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/Callback_class_list.html

3.7 Testbench Interface

DUT Interface
The CXL Subsystem can be connected to the DUT at any of the following signaling interfaces:
❖ LPIF/PCIe PIPE LPC/SerDes Arch
❖ PCIe Serial signaling interface
Refer HTML Class reference for more details:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/interfaces.html
Note:
Refer the CXL Subsystem Host DUT/ Device DUT Integration Guide for more details.
DUT Integration CXL Subsystem
You can use Link Configuration (svt_cxl_subsystem_link_configuration) shipped with CXL
Subsystem which instantiate both Host and Device Subsystem Configuration and provide APIs for easy use
model for DUT integration.
The APIs available in Link Configuration for DUT integration are:
❖ set_dut_type: API to setup DUT type and DUT Side. For example, the following reference
configuration considers VIP as DUT and Host side as DUT.

Feedback
44 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

set_dut_type(`SVT_CXL_SUBSYSTEM_TEST_CONFIGURATION_TYPE::VIP_DUT,svt_cxl_subsystem_confi
guration::HOST_SUBSYSTEM)
❖ set_cxl_subsytem_env_host_cfg: API to setup Host side of Subsystem. For example, the
following configuration does the setup on Host side in full stack topology.
cust_cfg.set_cxl_subsystem_env_host_cfg(0,svt_cxl_subsystem_configuration::IO_TL_DL_ONLY
_STACK);
❖ set_cxl_subsytem_env_device_cfg: API to setup the Device side of Subsystem. For example, the
following configuration does the setup on device side for full stack topology.
cust_cfg.set_cxl_subsystem_env_device_cfg(1,svt_cxl_subsystem_configuration::IO_TL_DL_ON
LY_STACK);
Internally these APIs reuse the Subsystem APIs to setup the Host side.
For example: set_subsystem_type and configure_subsystem APIs.
Refer the CXL Class reference guide for details of these APIs.
In the case of CXL.io enabled topologies, you need to take care of the VIP instance.
Note

3.8 Available Protocol Checks

Different protocol checks are present for CXL.io/cache/mem, LPIF signaling and ARB/MUX. The complete
list is present in the following location:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/protocolChecks.html
Usage Notes on LPIF Protocol Checks:
You can view the LPIF specific protocol checks that are supported in the CXL subsystem VIP. You can find
the complete list in HTML class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/protocolChecks.html?col_0=LPIF_CHECKS#item_cxl_subsystem_svt

Here is a glimpse of protocol check table. You can select the Group as LPIF to see all the available checks.
For specific features, you can selec the Sub Group. For example, here selected sub group is "Active State
Rules". You can see all the available checks under this category. The details of every check are present in
Reference and Description column.

Feedback
Synopsys, Inc. 45
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Also you can select a particular instance name and the hyperlink will take you to the instance description.
You will find below fields there:
❖ Check Description - Describes which signal/cfg VIP checks to trigger the protocol checker
❖ Pass condition - How should the signal/cfg behave to pass the checker
❖ Fail condition - How should the signal/cfg behave to fail the checker
❖ Applicable device type - DUT type for which the checker is valid
❖ Additional information - Any VIP related parameters which can trigger the checker.
For example, refer below snippet:

3.9 Dynamic Configuration

The configurations set during the build phase can be dynamically modified during the run phase if the test
requires a change in the configuration of the Subsystem VIP. The VIP provides reconfiguration() APIs
which can be used.
1. reconfiguration() method inside svt_cxl_subsystem_sequencer:
a. Test Sequences can invoke this in body() after modification of any layer configuration attributes.
For example:
svt_configuration cfg;
p_sequencer.host_seqr.get_cfg(cfg);
void'($cast(link_cfg.host_cfg, cfg.clone()));
<do necessary updates to the link_cfg.host_cfg object>
p_sequencer.host_seqr.reconfigure(link_cfg.host_cfg);
2. reconfiguration() method inside svt_cxl_subsystem_env:
a. Tests can use this in their run phase after modification of any layer configuration attributes.
Example:
svt_configuration cfg;
env.host_env.get_cfg(cfg);
void'($cast(cust_cfg.host_cfg, cfg.clone()));
<do necessary updates to the cust_cfg.host_cfg object>
env.host_env.reconfigure(cust_cfg.host_cfg);
The targeted modification can be on a specific layer of the Subsystem VIP or across multiple layers
depending on what the test is trying to achieve.

Feedback
46 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

It is must to get the cfg (using get_cfg) and clone it first before applying the changes using
Note reconfiguration.

3.10 CXL Subsystem Configuration (svt_cxl_subsystem_configuration) APIs

CXL subsystem can be programmed as a Host or a Device.
svt_cxl_subsystem_configuration::set_subsystem_type(subsystem_type_enum
subsystem_type)
For example, set_subsystem_type(svt_cxl_subsystem_configuration::HOST_SUBSYSTEM);
❖ Setup CXL subsystem as CXL.io, Cache.mem with ARB MUX, Cache.mem & PCIE Only.
svt_cxl_subsystem_configuration::configure_subsystem(subsystem_type_enum);
❖ Enables/Setup APN negotiation of PCIe VIP. It also sets APN capabilities for Flex bus support.
svt_cxl_subsystem_configuration::configure_flexbus(<common_clk bit,
sync_header_bypass, retimer_1_aware, retimer_2_aware, pcie_cxl_capables)
✦ common_clk : Specifies if common clock mode is supported or otherwise.
✦ sync_header_bypass : Specifies standard or low latency mode of operation.
✦ retimer_1_aware ; Specifies Re-timer 1 aware capability.
✦ retimer_2_aware ; Specifies Re-timer 2 aware capability.
✦ pcie_cxl_capables : Specifies the override values for pcie_capable, cxl_io_capable,
cxl_mem_capable, and cxl_cache_capable.
❖ Set existing or user-created PCIe VIP configuration handle
svt_cxl_subsystem_configuration::set_cxl_io_cfgs(svt_pcie_device_configuration)

3.11 Configuring CXL System Address Map

System Address Map specifies the address ranges dedicated for each CXL component, such as Host or
Device, accessible to the entire CXL system. This means that the address ranges are global parameters and
not local properties of any component, sub-component, or a cluster of components. All components
recognize and honor the address ranges specified in the svt_cxl_system_confiuration. However, at
present only cxl cache_mem transaction layer host and device components are using system address map
to check correct transaction routing.
You must follow these steps to apply effective System Address Map:
1. svt_cxl_system_configuration is instantiated within the
svt_cxl_subsystem_link_configuration. This means that cache_mem_sys_cfg is constructed
within the link configuration. The same svt_cxl_system_configuration object handle
cache_mem_sys_cfg is also provided to the host or device specific subsystem configurations. Refer
the diagram and code example for same.

Feedback
Synopsys, Inc. 47
 General Concepts VC VIP CXL Subsystem
UVM User Guide

function svt_cxl_subsystem_link_configuration::new(vmm_log log = null);

static vmm_log shared_log = new("svt_cxl_subsystem_link_configuration", "class");
super.new((log == null) ? shared_log : log,
svt_cxl_subsystem_suite_spec_override::get_suite_spec());
`else
function new(string name = "svt_cxl_subsystem_link_configuration");
super.new(name, svt_cxl_subsystem_suite_spec_override::get_suite_spec());
`endif
`ifdef SVT_VMM_TECHNOLOGY
cache_mem_sys_cfg = svt_cxl_system_configuration::create_instance(this,
"cache_mem_sys_cfg", `__FILE__, `__LINE__);
cache_mem_sys_cfg.log.set_instance($sformatf("%s.cache_mem_sys_cfg",
log.get_instance()));
this.log.is_above(cache_mem_sys_cfg.log);
`else

Feedback
48 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

cache_mem_sys_cfg =
svt_cxl_system_configuration::type_id::create("cache_mem_sys_cfg");
`endif
`ifdef SVT_VMM_TECHNOLOGY
host_cfg = svt_cxl_subsystem_configuration::create_instance(this, "host_cfg",
`__FILE__, `__LINE__);
host_cfg.log.set_instance($sformatf("%s.host_cfg", log.get_instance()));
this.log.is_above(host_cfg.log);
`else
host_cfg = svt_cxl_subsystem_configuration::type_id::create("host_cfg");
`endif
host_cfg.cache_mem_sys_cfg = this.cache_mem_sys_cfg;
`ifdef SVT_VMM_TECHNOLOGY
device_cfg = svt_cxl_subsystem_configuration::create_instance(this, "device_cfg",
`__FILE__, `__LINE__);
device_cfg.log.set_instance($sformatf("%s.device_cfg", log.get_instance()));
this.log.is_above(device_cfg.log);
`else
device_cfg = svt_cxl_subsystem_configuration::type_id::create("device_cfg");
`endif
device_cfg.cache_mem_sys_cfg = this.cache_mem_sys_cfg;
endfunction: new
1. Specify the address ranges for each host and device cxl cache_mem agents by calling
set_addr_range(<host/device>, <host/device agent index>, <start_addr>,
<end_addr>,<host_indices_can_access_addr>,<device_indices_can_access_addr>.
The API sets the address range for a specified Host or Device agent and this address range
specifically refers to the memory attached to the corresponding Host or Device agent. By specifying
distinct address ranges for each Host and Device, it is possible to query the Host or Device agent
memory to which a specific address belongs.

Feedback
Synopsys, Inc. 49
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Set the address range as below,

function void svt_cxl_subsystem_base_test::create_cfg();
`svt_note("create_cfg", "Entering...");
.
.
.

if(configure_system_address_map) begin
// configure system address ranges for each HOST and DEVICE component for Register
and Memory access

cust_cfg.cache_mem_sys_cfg.set_addr_range(svt_cxl_cache_mem_configuration::DEVICE,-1,
'h0, 'h3fff); //register space

cust_cfg.cache_mem_sys_cfg.set_addr_range(svt_cxl_cache_mem_configuration::DEVICE, 0,
'h8000, 'hffff); //memory
cust_cfg.cache_mem_sys_cfg.set_addr_range(svt_cxl_cache_mem_configuration::HOST,
-1, 'h4000, 'h7fff); //register space
cust_cfg.cache_mem_sys_cfg.set_addr_range(svt_cxl_cache_mem_configuration::HOST,
0, 'h10000, 'h1ffff);//memory
end
end
create_cfg_called = 1;
end

`svt_note("create_cfg", "Exiting...");
Endfunction

The register spaces are indicated by setting host/device agent index as -1. This ensures that no host
or device requests are expected to these address ranges.
2. CXL Cache_Mem request generating sequences must also be updated, so that it generates traffic
targeting to the valid address ranges. For example, the device that generates transactions to Host or
Device address ranges. Otherwise, CXL VIP reports as routing error. An example sequence is given
below with system address range specific assignments and constraints.
task svt_cxl_tl_virtual_cache_mem_sequence::body();
< variable declarations... >
raise_phase_objection();
................
fork
// Cache Request
begin //{
int addr_range_index;
foreach(cache_req_xact[i]) begin

if(cache_req_xact[i] == null) begin

`svt_xvm_create_on(cache_req_xact[i], p_sequencer.tl_req_seqr);
cache_req_xact[i].cfg = this.cfg;
addr_range_index = cfg.sys_cfg.get_rand_addr_range_index(~is_host);
rand_status = cache_req_xact[i].randomize() with {xact_protocol ==
((cfg.agent_type == svt_cxl_cache_mem_configuration::HOST) ?
svt_cxl_common_transaction::CACHE_H2D_XACT:
svt_cxl_common_transaction::CACHE_D2H_XACT);

if(addr_range_index >= 0) {

Feedback
50 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

addr >= cfg.sys_cfg.addr_ranges[addr_range_index].start_addr;

addr <= cfg.sys_cfg.addr_ranges[addr_range_index].end_addr;
} else {
addr inside {0,64,128,256};
}

if(cfg.agent_type == svt_cxl_cache_mem_configuration::HOST){
xact_type dist { svt_cxl_transaction::H2D_SNPDATA := snpdata_wt,
..............
svt_cxl_transaction::D2H_CACHEFLUSHED := cacheflushed_wt
};}
};

End

`svt_xvm_send(cache_req_xact[i]);
track_responses(cache_req_xact[i]);
track_data(cache_req_xact[i]);
end
end

//Mem Req
begin
int addr_range_index;
foreach(mem_req_xact[i]) begin
if (cfg.agent_type == svt_cxl_cache_mem_configuration::HOST) begin
if(mem_req_xact[i] == null) begin
`svt_xvm_create_on(mem_req_xact[i], p_sequencer.tl_req_seqr);
mem_req_xact[i].cfg = this.cfg;
addr_range_index = cfg.sys_cfg.get_rand_addr_range_index(0);
//TODO open the xact_type
rand_status = mem_req_xact[i].randomize() with {xact_protocol ==
svt_cxl_common_transaction::MEM_REQ_XACT;
if(addr_range_index >= 0) {
addr >= cfg.sys_cfg.addr_ranges[addr_range_index].start_addr;
addr <= cfg.sys_cfg.addr_ranges[addr_range_index].end_addr;
} else {
addr inside {0,64,128,256};
}
end
`svt_xvm_send(mem_req_xact[i]);
track_responses(mem_req_xact[i]);
track_data(mem_req_xact[i]);
check_completion_timeout(mem_req_xact[i], 10000);
end //if(HOST)
end //foreach(memreq)
end //MemReq
join
fork
forever get_response(rsp);
join_none
`svt_xvm_debug("body", "Waiting for all responses to be received");
wait (trans_count == received_responses);
`svt_xvm_debug("body", "Received all responses. Dropping objections");
drop_phase_objection();
`svt_note(method_name, "Ending.................");
endtask : body

Feedback
Synopsys, Inc. 51
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.12 DUT Interface

The CXL Subsystem can be connected to the DUT at any of the following signaling interfaces:
❖ LPIF/PCIe LPC/ PIPE SerDes Arch
❖ PCIe Serial signaling interface

Note
Refer the Chapter ‘PCIe Verification Topologies’ from PCIe VIP User guide for details on DUT integrations.
This chapter provides details of PCIe Unified VIP component. Refer the section ‘DUT integration’ for DUT
integration details.

3.12.1 DUT Integration with CXL Subsystem

You can use Link Configuration (svt_cxl_subsystem_link_configuration) shipped with CXL
Subsystem which instantiate both Host and Device Subsystem Configuration and provide APIs for easy use
model for DUT integration.
The APIs available in Link Configuration for DUT integration are:
❖ set_dut_type: API to setup DUT type and DUT Side. For example, the following reference
configuration considers VIP as DUT and Host side as DUT.
set_dut_type(`SVT_CXL_SUBSYSTEM_TEST_CONFIGURATION_TYPE::VIP_DUT,svt_cxl_subsyste
m_configuration::HOST_SUBSYSTEM);)
✦ `SVT_CXL_SUBSYSTEM_SNPS_DUT_TYPE can be used to replace the DUT TYPE setting. The default
value of define is VIP_DUT.
❖ set_cxl_subsytem_env_host_cfg: API to setup Host side of Subsystem. For example, the following
configuration does the setup on Host side in full stack topology.
cust_cfg.set_cxl_subsystem_env_host_cfg(0,svt_cxl_subsystem_configuration::IO_TL_
DL_ONLY_STACK);
❖ set_cxl_subsytem_env_device_cfg: API to setup the Device side of Subsystem. For example, the
following configuration does the setup on device side for full stack topology.
cust_cfg.set_cxl_subsystem_env_device_cfg(1,svt_cxl_subsystem_configuration::IO_T
L_DL_ONLY_STACK);
Internally these APIs reuse the Subsystem APIs to setup the Host side.
For example: set_subsystem_type and configure_subsystem APIs.
Refer the CXL Class reference guide for details of these APIs.

Note
In the case of CXL.io enabled topologies, you need to take care of Unified VIP instance.

3.13 Key Use Cases of Cache Memory Transaction Layer

1. Coherent Traffic Generation and Coherency Checks
Even though all aspects of coherency are not yet supported, CXL VIP can be used for coherent and
memory traffic generation and perform related protocol checks.

Feedback
52 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

❖ Device and Host both can send coherent requests to allocate or de-allocate a cacheline targeted to the
Host attached Memory address range. CXL VIP establishes the required transaction flow and track
allocation and de-allocation of the targeted cache lines. It also performs the read and write from the
attached memory based on the requirement of the corresponding transaction.
Example Scenario:
✦ Device sends allocating coherent request for Exclusive Ownership
✦ Allocates the cacheline once response is received from the Host
✦ Performs a store operation and modifies the cacheline data
✦ Host at a later point sends Snoop to claim the ownership
✦ Device invalidates the line in it's cache and forwards the data to Host
✦ Host receives snoop response and allocates the cacheline with snoop data in it's cache
✦ Later Host can update Host attached memory with the cacheline data
2. System Address Map based Routing Check
Host and Devices can be configured with the applicable address ranges as a System Address Map
and CXL VIP performs request routing check. If any coherent or memory request is found to be sent
to any unmapped address space, then VIP reports an error.
This feature can be used to verify any unintended request sent by any connected component, which
are either Host or Device.
✦ Host and Device both can be configured with the same or overlapped address ranges by setting
allow_overlapping_addr to ‘1’ in svt_cxl_system_configuration

3.14 Transaction Logging Support

Transaction Trace logging feature is supported for CXL IO/Cache/mem Protocols of CXL Subsystem SVT
for the following layers.

3.14.1 Transaction Layer

Transaction Layer trace creates log files of CXL Cache/mem transactions. Logging enabling attribute would
be svt_cxl_cache_mem_configuration::enable_transaction_logging.
Example code present in the test to enable the transaction logging for the HOST is shown here:
for (int i = 0 ; i < cust_cfg.host_cfg.cache_mem_sys_cfg.num_cache_mem_agent; i++)
begin
cust_cfg.host_cfg.cache_mem_sys_cfg.cache_mem_cfg[i].enable_transaction_logging =
1;
end
By default, the log gets generated / saved with Hierarchy of the component appended with. xact_log.
Example: uvm_test_top.env.device_env.cache_mem_env.cache_mem[0].tl_driver.xact_log
If you want to print the transaction log with user-defined name, add it as:
for (int i = 0 ; i < cust_cfg.host_cfg.cache_mem_sys_cfg.num_cache_mem_agent; i++)
begin
cust_cfg.host_cfg.cache_mem_sys_cfg.cache_mem_cfg[i].transaction_log_filename=
"debug_log";
end

Feedback
Synopsys, Inc. 53
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.14.2 ARB/Mux Layer

ARB/Mux Layer trace creates log files of CXL IO/Cache/mem input transactions coming from DL/PHY
layer. Logging enabling attribute would be
svt_cxl_arb_mux_configuration::enable_transaction_logging.
Example code present in the test to enable the transaction logging for the HOST is shown here:
if(cust_cfg.host_cfg.num_arb_mux != 0) begin
for (int i = 0 ; i < cust_cfg.host_cfg.num_arb_mux; i++) begin
cust_cfg.host_cfg.arb_mux_cfg[i].enable_transaction_logging = 1;
end
end
By default, the log gets generated/ saved with Hierarchy of the component appended with. xact_log.
Example:
uvm_test_top.env.device_env.arb_mux[0].driver.xact_log
uvm_test_top.env.host_env.arb_mux[0].driver.xact_log
If you want to print the transaction log with user-defined name, add it as:
if(cust_cfg.host_cfg.num_arb_mux != 0) begin
for (int i = 0 ; i < cust_cfg.host_cfg.num_arb_mux; i++) begin
cust_cfg.host_cfg.arb_mux_cfg[i].transaction_log_filename = "debug_log";
end
end

3.15 Steps to Move from PCIe VIP based Testbench to CXL Subsystem Based
Testbench
These are the list of steps/changes based on PCIE VIP Unified Testbench
(tb_pcie_svt_uvm_unified_vip_sys) to have support for CXL Subsystem, and also these are steps based
on single instance usage.

3.15.1 Include the CXL Related Files (Make sure DESIGNWARE_HOME created & set from
CXL Subsystem)

3.15.2 Include and Import CXL Subsystem Packages in top

// CXL UVM package
`include "svt_cxl.uvm.pkg"
`include "svt_cxl_subsystem.uvm.pkg"
--------

// Import the CXL VIP Package

import svt_cxl_uvm_pkg::*;
// Import the CXL SubSystem VIP
import svt_cxl_subsystem_uvm_pkg::*;

3.15.3 Base Test

❖ Create CXL Subsystem configuration
// CXL Configuration for CXL Host or Device.
svt_cxl_subsystem_configuration cxl_cfg;
❖ Pass configuration to environment or place from where PCIe VIP agent instance is created.

Feedback
54 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

cxl_cfg = svt_cxl_subsystem_configuration::type_id::create($sformatf("cxl_cfg"),this);
You need to set Subsystem Id & Host/Device subsystem for configuration variable subsystem_type
as HOST_SUBSYSTEM/DEVICE_SUBSYSTEM.

Note
An API to configure the host/device is planned to be offered through which you can do complete
configuration without the need for individual configuration.
cxl_cfg.subsystem_id = <Subsystem ID>;
/** Passing existing PCIe VIP configuration from TB. */
cxl_cfg.set_cxl_io_cfgs(<PCIe VIP Configuration handle>);
/** Configuring CXL Subsystem as CXL IO. */
cxl_cfg.configure_subsystem(svt_cxl_subsystem_configuration::PCIE_IO_FULL_STACK);
/** Setting up CXL subsystem as Host. */
cxl_cfg.set_subsystem_type(svt_cxl_subsystem_configuration::HOST_SUBSYSTEM);
/** Configure PCIe APN capabilities for Flex bus operation for flex bus */
cxl_cfg.configure_flex_bus(0,0,0,0);
uvm_config_db#(svt_cxl_subsystem_configuration)::set(this, {env_name,"*"}, "cxl_cfg",
cxl_cfg);
Note
For complete details on Configuration APIs, you can refer CXL Subsystem Class reference guide.
Class Reference for VC Verification IP for CXL Subsystem is available at:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/index.html

3.15.4 Environment:
❖ Capture the configuration from test and pass the configuration to CXL Subsystem
if(uvm_config_db#(svt_cxl_subsystem_configuration)::get(get_parent(), get_name(),
"cxl_cfg", cxl_cfg)) begin
`uvm_info("build_phase", "Using test case provided cxl_cfg", UVM_LOW)
end
else `uvm_fatal("build_phase", "Expecting test case provided cxl_cfg")

❖ Create CXL Subsystem Host/Device ENV and pass the existing PCIe VIP component through
uvm_config_db
//Pass configurations to individual component E.g. Host component.
uvm_config_db#(svt_cxl_subsystem_configuration)::set(this, "cxl_host_env", "cfg",
cxl_cfg);
// Passing existing PCie VIP Root component to CXL Host.
uvm_config_db#(svt_pcie_device_agent)::set(this, "cxl_host_env",
"io_agent[0]",root);

/** Create status objects for Host subsystems */

host_status = svt_cxl_subsystem_status::type_id::create("host_status");

/** Pass status objects for Host */

uvm_config_db#(svt_cxl_subsystem_status)::set(this, "cxl_host_env",
"shared_subsystem_status", this.host_status);

/** Create the Host Env */

cxl_host_env = svt_cxl_subsystem_env::type_id::create("cxl_host_env", this);

Feedback
Synopsys, Inc. 55
 General Concepts VC VIP CXL Subsystem
UVM User Guide

❖ Create the CXL subsystem Sequencer and connect PCIe sequence with CXL sequencers, such as
connecting CXL Host sequence with PCIe Sequencer.
/** Create Subsystem sequencer for host */
cxl_env_seqr = svt_cxl_subsystem_sequencer::type_id::create("cxl_env_seqr",this);

cxl_env_seqr = cxl_host_env.subsystem_virt_seqr;
root.virt_seqr = cxl_env_seqr.cxl_io_virt_seqr[0];
Note
Avoid using combination of PCIE VIP API ‘<PCIe VIP
Configuration>.pcie_cfg.pl_cfg.set_modified_ts_mode_values’ and ‘<CXL Subsystem
configuration>.configure_flex_bus(0,0,0,0);’. This might result in unexpected behavior.
❖ Subsystem VIP provides svt_cxl_subsystem_link_configuration(encapsulates host_cfg and
device_cfg of svt_cxl_subsystem_configuration) and svt_cxl_subsystem_link_status
(encapsulates host_status and device_status of svt_cxl_subsystem_status) to provide easier control
over link. You can use these classes instead of creating them individually. See the VIP example areas
for more details on usage. Based on link behavior, additional APIs are also part of these classes.

3.16 Enumeration
This section provides the CXL 2.0 Enumeration applicable for devices such as, D1 - CXL 1.1 Device, D2 -
CXL 2.0 Device.

3.16.1 Requirements
❖ CXL Defined Configuration space DVSECs (8.1)
❖ CXL Register Interface (8.2.8)
❖ CXL Memory Register (8.2.5)
❖ CXL Command Interface (8.2.9)
❖ Component register enumeration & Base address of capabilities.
❖ CXL 1.1 device Enumeration for CXL 2.0 defined applicable DVSECs & memory mapped
capabilities.

3.16.2 Key Updates

CXL 2.0 Device is an Endpoint device, while CXL1.1 was RCiEP. In CXL, the registers are distributed in
configuration space and memory space. CXL 2.0 introduced additional DVSECs for CXL1.1 as well as 2.0
device.
CXL 2.0 device memory mapped registers are available in one of the BAR of the device which can be found
from Register Locator DVSEC.
Overall, the CXL 2.0 memory space is divided in to three register regions:
❖ Component Registers
❖ BAR Virtualization ACL Register Block
❖ CXL Memory Device Registers

Feedback
56 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

Naming convention in CSR Status class are referenced from CXL Compliance Tests chapter and
Note register names defined in Control and Status Registers.

3.16.3 Use Model

CXL VIP provides an API to perform enumeration on a CXL Device - enumerate_cxl_device(). It enumerates
CXL.io resources, RCRB and Membar0 registers. The basic actions performed by the API are:
❖ CXL.io resources are enumerated through
svt_pcie_device_virtual_ep_enumeration_sequence.
❖ Checking for device type correctness.
❖ Reading PCIe Express Configuration space Register for DVSEC Capability presence
The enumerate_cxl_device API is enhanced to enumerate Configuration space & Memory mapped
registers for CXL 1.1 as well as 2.0 device. Internally many other APIs (Refer the HTML Class reference
svt_cxl_subsystem_sequence_collection file) are created which are triggered from the
enumerate_cxl_device API by default but you can override those if required to do additional operations.
Enumeration status for configuration space and memory space mapped capabilities are available in CSR
(Control and Status Register) Status class. CSR Status class svt_cxl_subsystem_csr_status is available in
CXL Subsystem Status class.

3.16.3.1 CXL 1.1/2.0 Configuration space Registers (DVSECs) (Section 8.1)

Table 124 from CXL 2.0v0.9 specifies CXL DVSECs mandatory/options for CXL Devices. Following is
snippet of the same from specification.

Table 3-1 CXL DVSEC ID Assignment

Highest
DVSEC
DVSEC Revision Not
CXL Capability ID ID Mandatory1 Permitted Optional

PCIe DVSEC for CXL Device 0 1 D1,D2,LD, FMLD P,UP1,

(Section 8.1.3) DP1,R,
USP,DSP

Non-CXL Function Map DVSEC 2 0 P,UP1, D1,D2,LD,

(Section 8.1.4) DP1,R, DSP FMLD,USP

CXL 2.0 Extensions DVSEC for 3 0 R, USP, DSP P,D1, D2,

Ports (Section 8.1.5) LD,FMLD,
UP1, DP1

GPF DVSEC for CXL Ports 4 0 R, DSP P,D1, D2,

LD,FMLD,
UP1, DP1,
USP

Feedback
Synopsys, Inc. 57
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Table 3-1 CXL DVSEC ID Assignment

Highest
DVSEC
DVSEC Revision Not
CXL Capability ID ID Mandatory1 Permitted Optional

GPF DVSEC for CXL Devices 5 0 D2, LD P,UP1, DP1, D1

R, USP, DSP,
FMLD

PCIe DVSEC for Flex Bus Port 7 1 D1, D2, LD, FMLD, P
(Section8.1.8) UP1, DP1, R, USP,
DSP

Register Locator for DVSEC 8 0 D2, LD, FMLD, R, USP, P D1, UP1,
(Section8.1.9) DSP DP1

MLD DVSEC (Section8.1.10) 9 0 FMLD P, D1, D2, LD,

UP1, DP1, R,
USP, DSP

PCIe DVSEC for Test Capability 0Ah 0 D1 P, LD, D2

(Section 14.16.1) FMLD,DP1,
UP1, R, USP,
DSP

1. P-PCI Express Device, D1 - CXL 1.1 Device, D2-CXL 2.0 Device, LD-Logical Device, FMLD- Fabric Manager
Owned LD 0xFFFF, UP1 - CXL 1.1 Upstream Port RCRB, DP1- CXL 1.1 Downstream Port RCRB, R- CXL 2.0
Root Port, USP- CXL Switch Upstream Port, DSP - CXL Switch Downstream Port

This is the table mapping the DVSEC's/Capabilities/Memory Mapped Regions with the CSR Status class
attribute:

CXL DVSECs

DVSECs/Capabilty CSR Status class attributes

PCIe DVSEC for CXL Device cxl_device_dvsec

Non-CXL Function Map DVSEC non_cxl_function_dvsec_base

GPF DVSEC for CXL Devices cxl_gpf_device_dvsec_base

PCIe DVSEC for Flex Bus Port cxl_flexbus_dvsec_base

Register Locator DVSEC cxl_register_dvsec_base

CXL DVSEC for Test Capability cxl_test_capability_dvsec_base

Additional Capabilities

Memory Device Configuration Space Layout device_serial_num_ext_capability_base

DOE compliance/CDAT DOE_capability_base

Register Locator DVSEC Information

Feedback
58 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

Register BIR register_bir[]

Register Block Identifier register_block_identifier[]

Register Block Offset register_block_offset[]

Memory Mapped Register pointers

CXL Component Registers cxl_device_component_register_base_addr

BAR Virtualization ACL Register Block cxl_device_bar_virtualization_acl_register_block_base_

addr

CXL Memory Device Registers cxl_memory_device_register_base_addr

CSR Status class is available in CXL Subsystem Status class and this can be used at sequence. The following
is reference usage:
<host status>.csr_status[link_num].cxl_device_dvsec

3.16.3.2 CXL Component Registers (Section: 8.2.3)

CXL 2.0 Enumeration, Component registers are reached through the Register locator DVSEC. Register Block
Identifier should be "01" and Register BIR points to BAR which capture Component register.
Reference snippet from CXL Specification for Component registers:

VIP Enumeration API captures the base address of Component registers, and you can add the offset and
traverse the specific registers.
Component Register Base address in CSR Status class : cxl_device_component_register_base_addr
For example, cxl_device_component_register_base_addr + 1000h will lead to CXL.Cache and CXL.mem
Registers.

Feedback
Synopsys, Inc. 59
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.16.3.3 Capability Base address (CXL_Capability_ID Assignment Table 142)

❖ cxl_device_comp_register_cap_base_addr[int] => Indexing based on Capability ID

Reference snippet from the VIP execution transcript:

3.16.3.4 BAR Virtualization ACL Register Block (Section: 8.2.7)

CXL 2.0 Enumeration, BAR Virtualization ACL registers are reached through Register locator DVSEC.
Register Block Identifier must be ‘02’ and Register BIR points to BAR which capture BAR Virtualization
ACL register block.
CSR Status class attributes for Register Block:
cxl_device_bar_virtualization_acl_register_block_base_addr

Feedback
60 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

3.16.3.5 CXL Memory Device Registers (Section: 8.2.8)

CXL 2.0 Enumeration, CXL Memory Device registers are reached through Register locator DVSEC. Register
Block Identifier should be ‘03’ and Register BIR points to BAR which capture CXL Memory Device register.
CSR Status class attributes for Register Block: cxl_memory_device_register_base_addr

CXL Registers Interface (Section: 8.2.8)

At the beginning of the CXL device register block is a CXL Device Capabilities Array Register which defines
the size of the CXL Device Capabilities Array followed by a list of CXL Device Capability headers. Each
header contains an offset to the capability specific register structure from the start of the CXL device register
block.
Following is the table describe overall Capability ID mapping.

Capability ID Range Capability Information

0000h - 3FFFh Generic CXL Device Capabilities

4000h -7FFFh Specific Capabilities associated with class code

Register in PCIe Header (offset 09h)

8000h - FFFFh Vendor Specific Capabilities

CSR Status class keep each capability information captured through associative array:
cxl_device_capability_base_addr[int]
For example:
cxl_device_capability_base_addr[1] - Device Status Register
cxl_device_capability_base_addr[2] - Primary Mailbox
cxl_device_capability_base_addr[3] - Secondry Mailbox
cxl_device_capability_base_addr[4000] - Memory Device Status Register

3.16.3.6 CXL Command Interface (Section: 8.2)

Primary and Secondary Mailbox Capabilities (Capability ID as 2 and 3) identified through CXL Register
Interface Capabilities provides the ability to issue a command to device. You need to follow the CXL
Specification defined flow to initiate a command over CXL Command interface.
This table captures the Primary/Secondary mailbox Registers extraction from VIP enumeration:

Primary Mailbox Capability Register cxl_device_capability_base_addr[2] + 00h

Primary Mailbox Control Register cxl_device_capability_base_addr[2] + 04h

Primary Mailbox Command Register cxl_device_capability_base_addr[2] + 08h

Primary Mailbox Status Register cxl_device_capability_base_addr[2] + 10h

Primary Mailbox Background Command Status cxl_device_capability_base_addr[2] + 18h

Register

Feedback
Synopsys, Inc. 61
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Primary Mailbox Payload Register cxl_device_capability_base_addr[2] + 20h

Similarly, Secondary Mailbox Registers can also be extracted.

3.16.3.7 Use Model for Command Interface

You can initiate MRd/MWr TLP to Primary Mailbox Command Registers as described in specification.
CXL 2.0v0.9 Specification section 8.2.8.4 Reference for Command Registers Interface usage:
The flow for executing a command is described below. The term caller represents the entity submitting
the command:
1. Caller reads MB Control Register to verify doorbell is clear => MemRd to "Primary Mailbox Control
Register".
2. Caller writes Command Register => MemWR to "Primary Mailbox Control Register"
3. Caller writes Command Payload Registers if input payload is non-empty => MemWr to "Primary
Mailbox Payload Register"
4. Caller writes MB Control Register to set doorbell => MemWR to "Primary Mailbox Control Register"
5. Caller either polls for doorbell to be clear or waits for interrupt if configured => MemRd to "Primary
Mailbox Control Register" or wait for Interrupt.
6. Caller reads MB Status Register to fetch Return code => MemRd to "Primary Mailbox Status
Register".
7. If command successful, Caller reads Command Register to get Payload Length => MemRd to
"Primary Mailbox Payload Register"
8. If output payload is non-empty, then the host reads Command Payload Registers.
MSI TLP can be captured through the analysis port.

3.16.3.8 Use Model to Control Parameter

The enumeration API use model is used to control parameter of enumeration. For example, bus number, all
capabilities enumeration and so on.
You can pass the svt_pcie_ep_enumeration_pf_control handle with enumerate_cxl_device API to
control much more parameters.
You can refer the following code:

// Checking required configuration space for CXL device.

if((link_cfg.dut_type != `SVT_CXL_SUBSYSTEM_TEST_CONFIGURATION_TYPE::VIP_DUT) &&

(link_cfg.dut_side == svt_cxl_subsystem_configuration::DEVICE_SUBSYSTEM)) begin

svt_pcie_ep_enumeration_pf_control device_parms;
device_parms=new();
device_parms.max_num_functions_supported=max_num_function;
device_parms.enable_sriov =0;
device_parms.max_num_vfs_per_pf = 32;

Feedback
62 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

device_parms.bus_number = 8'hD0;
device_parms.device_number=5'b11000;
host_seq.disable_cxl_upstream_membar0_enumeration =
disable_cxl_upstream_membar0_enumeration;
host_seq.disable_cxl_upstream_rcrb_enumeration = disable_cxl_upstream_rcrb_enumeration;
// Enumeration API for CXL Device.
host_seq.enumerate_cxl_device(0/*link num*/,max_num_function/*Max Number of
Function*/,0/*SRIOV*/,32/*Max VFs per PF*/,,device_parms);
//

3.16.4 Usage with DWC CXL Controller

❖ Program Controller for Cache/Mem enable before APN negotiation.
CXL Controller Databook reference section "CXL Register Module".
❖ Internally, there is an issue with completion handling with "TD=1", which means that the TLP Digest
bit asserted. It is recommended to de-assert for completions.
If CXL Applications are responsible for generating completion, then you can disable the generation
of CPL with TD bit asserted.

3.16.5 Enumeration FAQ

1. How to setup CXL 1.1 RCRB Address ?
Use these configuration attributes to control the RCRB base address and Membar0 programming in
RCRB.  
These are available in Subsystem Configuration.  
/**
* sets the Upstream port RCRB base address, first Memory access after link
* initiation will be initiated on this address by host.
* Note : This address should not lie inside any of the BAR ranges.
*/
rand bit[63:0] upstream_port_rcrb_base_addr=64'h0000_0000_0001_1000;

/**
* sets the Upstream port MEMBAR base address.
* 64K Memory range is required for MEMBAR.
* Note : This address should not lie inside any of the BAR ranges.
*/
rand bit[63:0] upstream_port_membar0_base_addr=64'h0000_0000_0002_0000;
Reference Access path:  
cust_cfg.host_cfg.upstream_port_rcrb_base_addr
cust_cfg.host_cfg.upstream_port_membar0_base_addr 
2. How to manage multiple instances of EP Enumeration status?

Feedback
Synopsys, Inc. 63
 General Concepts VC VIP CXL Subsystem
UVM User Guide

 The cxl_io_enumeration_status_id attribute is added in

svt_cxl_subsystem_virtual_api_collection_sequence Sequence. You need to program this
attribute and it is be mapped internally with
pcie_root_hierarchy_%0d_ep_enumeration_status.
3. How to program different BARs for different instances or control of BAR ranges to be programmed
for DUT?
If you need non-overlapping BAR addresses for multiple EP instances, then you must set the
following attributes of device_parms:  
enable_incremental_bar_allocation =1 (So that random mode of BAR selection is not
enabled) 
Then you need to specify non-overlapping values for following limits for each EP instance:  
min_non_pref_mem_base_addr, max_non_pref_mem_base_addr, min_io_base_addr, max_io_
base_addr, min_pref_mem_base_addr and max_pref_mem_base_addr.

3.16.6 Debug

3.16.6.1 Transcript
The Enumeration of CSR Status class can be used to get some information about the capabilities
enumerated. The following snippet is for CXL1.1 mode enumeration for CXL 2.0 device.

3.16.6.2 XACT File

To debug the configuration space information through XACT file, you must dump the one Data word of
Payload also. This helps to reach directly to places applicable for CXL.
Normally Payload of CFG TLP is byte swapped, and hence it is necessary to be vigilant on Endianness.
Finding CXL DVSECs in XACT File

Feedback
64 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

❖ Search for "981e" (Reverse of CXL Device ID IE98h).

✦ Line 385 in snippet.
❖ DVSECs has Capability ID of 23, so just before this 981e TLP it should be DVSEC Capability.
✦ Line 378 in snippet.
❖ Next offset read should give us DVSEC ID.
❖ Line 392 in snippet.

3.17 CXL 2.0 Features

As mentioned in the Licensing section, CXL 2.0 features can be enabled and used when using the
Note license SUB-CXL20-SVT (or)VIP-LIBRARY2019-SVT+SUB-CXL20-EA-SVT.
The spec version must be set to spec_ver = svt_cxl_types::CXL_VER_2_0.

3.17.1 GPF Feature

The APIs under svt_cxl_subsystem_sequence_collection. Refer the Class reference document “PM
VDM API” group. Other CXL PM VDM related APIs are also part of this API.

3.17.1.1 CXL GPF APIs

perform_cxl_gpf(): to perform GPF VDM exchange and moves from Phase 1 followed by
Phase 2.
perform_cxl_gpf_phase1() : to perform GPF VDM exchange for Phase 1.
perform_cxl_gpf_phase1() : to perform GPF VDM exchange for Phase 2.
start_traffic_post_gpf (): to start generating traffic post GPF phase 2. By default, VIP will
stop generating new traffic post GPF Phase 2 completion.

Feedback
Synopsys, Inc. 65
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.17.1.2 Example Usage

These variables are to be removed and same to be replaced by variables in CXL Subsystem App
configuration:
1. perform_cxl_gpf(int link_num = 0,
bit[3:0] p1_timeout_base = 1,
bit[3:0] p1_timeout_scale = 0,
bit[3:0] p2_timeout_base = 1,
bit[3:0] p2_timeout_scale = 0,
bit powerfail_expected = 0,
bit disable_caching = 0);
2. perform_cxl_gpf_phase1(int link_num = 0,
bit[3:0] p1_timeout_base = 1,
bit[3:0] p1_timeout_scale = 0,
bit powerfail_expected = 0,
bit disable_caching = 0);
3. perform_cxl_gpf_phase2(int link_num = 0,
bit[3:0] p2_timeout_base = 1,
bit[3:0] p2_timeout_scale = 0,
bit p1_ended_with_err = 0);

3.17.1.2.1 Configuration Variables for GPF

The variables are added as part of svt_cxl_subsystem_app_configuration,
gpf_p1_timeout_scale_down and gpf_p2_timeout_scale_down to help you to further scale down the
GPF phase timeout values. These variables are added as control to reduce the huge timeout values when the
time_base and time_scale variables are resultant of GPF control register access.

3.17.1.3 Known Limitations

❖ No support claimed for GPF in Device VIP, support only for Host VIP.
❖ No support claimed for Type 1 / 2 Device involved.

3.17.2 Qos Telemetry

1. These parameters of the svt_cxl_cache_mem_configuration class need to be set to the following
values to enable this feature:
✦ enable_qos_telemetry = 1;
✦ spec_ver = svt_cxl_types::CXL_VER_2_0;
2. svt_cxl_system_configuration API set_qos_telemetry_control_parameters() to control
throttling:
✦ @param dev_idx Device agent index for which QoS Telemetry address range is to be specified.
Index for Nth device is specified by (N-1), starting at 0.
✦ @param start_addr Start address of the QoS Telemetry address range.
Currently, CXL VIP considers complete device address range for QoS. Therefore, if it is set to any
value, it considers the device start address only.
✦ @param end_addr End address of the QoS Telemetry address range

Feedback
66 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

Currently, CXL VIP considers complete device address range for QoS.
Therefore, if it is set to any value, it considers the device end address only.
✦ @param thrtl_window Throttling th parameter which indicates when to sample the loadmax
value for throttling control.
This argument is used by host VIP only.
✦ @param normal_delta_time The wait time which will be increased for moderate load (or)
decreased for light load
This argument is used by host VIP only.
✦ @param severe_delta_time The wait time which will be increased for moderate load (or)
decreased for light load
This argument is used by host VIP only.
✦ @param max_thrtl_wait_time The maximum wait time which is allowed before sending the
transaction from the TL layer.
This argument is used by host VIP only.
Example
✦ Host VIP
Suppose previous transaction was sent without waiting for any delay.
So, wait time for previous transaction (previous_wait_time) was 0ns.
Now,the sampled Loadmax value at host end is SEVERE_OVERLOAD.
Hence, the new transaction needs to wait for:
wait_time = severe_delta_time i.e.(previous_wait_time + severe_delta_time) before sending
from the TL layer.
Now, suppose the sampled Loadmax value at host end is MODERATE_OVERLOAD.

Therefore, the new transaction needs to wait for

wait_time = (severe_delta_time+normal_delta_time)
i.e.(previous_wait_time + normal_delta_time) before sending from the TL layer.
Now, suppose, the sampled Loadmax value at host end is LIGHT_LOAD.
Therefore, the new transaction needs to wait for
wait_time = (severe_delta_time+normal_delta_time-normal_delta_time) i.e.(previous_wait_time
- normal_delta_time) before sending from the TL layer.
✦ extern function void set_qos_telemetry_control_parameters(int dev_idx, bit
[`SVT_CXL_MAX_ADDR_WIDTH-1:0] start_addr, bit [`SVT_CXL_MAX_ADDR_WIDTH-1:0]
end_addr, int thrtl_window, int normal_delta_time, int severe_delta_time, int
max_thrtl_wait_time);
✦ svt_cxl_tl_cache_mem_resp_sequence API get_dev_load() to populate the device load value to
svt_cxl_transaction object.
This API calculate the device load based on the pending transactions at device end. This API
internally gets pending transactions and based on numbers it decide the device load. You can
modify this API to calculate the dev load.

Feedback
Synopsys, Inc. 67
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3.17.2.1 Usage Example

Host VIP parameters:
cust_cfg.cache_mem_sys_cfg.set_qos_telemetry_control_parameters();
cust_cfg.cache_mem_sys_cfg.host_cfg[0].enable_qos_telemetry=1;
cust_cfg.host_cfg.set_spec_ver(svt_cxl_types::CXL_VER_2_0, 0);
Device VIP parameters:
cust_cfg.cache_mem_sys_cfg.set_qos_telemetry_control_parameters();
cust_cfg.cache_mem_sys_cfg.device_cfg[0].enable_qos_telemetry=1;
cust_cfg.device_cfg.set_spec_ver(svt_cxl_types::CXL_VER_2_0, 0);

"cust_cfg" is the handle of svt_cxl_subsystem_link_configuration.

The value of svt_cxl_transaction::dev_load can be changed by extending the
svt_cxl_tl_cache_mem_resp_sequence and overriding the get_dev_load() task
task svt_cxl_tl_cache_mem_resp_sequence::get_dev_load ( svt_cxl_transaction xact )
Find the details below:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_class_refere
nce/html/sequences/class_svt_cxl_tl_cache_mem_resp_sequence.html#item_get_dev_load
 For example:
cust_cfg.cache_mem_sys_cfg.set_qos_telemetry_control_parameters(0, 'h8000,
'hffff,50,5,10,300);

task svt_cxl_tl_cache_mem_resp_sequence::get_dev_load(svt_cxl_transaction xact);

xact.dev_load = svt_cxl_types::SEVERE_OVERLOAD;
endtask
Note
This is just an illustration, and you must keep in mind other aspects while changing the
dev_load.
 
Keywords to debug QoS scenarios:
❖ "get_qos_wait_time"
❖ "set_qos_telemetry_control_parameters"
❖ "Throttling "

3.17.2.2 Known Limitations

❖ Device load is calculated based on internal loading. Currently, it does not consider below methods:
✦ Egress Port Backpressure
✦ Temporary Throughput Reduction

3.17.3 CXL IDE

3.17.3.1 IDE
❖ Prerequisites: Synopsys DesignWare Cores Cryptography Library

Cryptographic algorithms are not shipped as part of VIP deliverable. As a prerequisite, you must have
Note access to Access to Synopsys Designware Core Cryptographic Software Library (CSL).

Feedback
68 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

❖ Cryptography Library version : 4.30a

❖ CXL IDE feature is supported for VCS simulator only

3.17.3.2 Usage Notes

Compile time requirements to execute with IDE:
Cryptography Library : libellipsys.a
VIP DPI-C Object file : svt_aes.o or svt_aes_dpi.cpp
Reference for building object file : $(GCC) -B/usr/bin -DLinux -Damd64 -Dx86_linux -I./ -
I$(VCS_HOME)/include -I$(ELLIPSYS_HOME)/src/headers -DELP_SOURCE -DELPSOFT -DELPAES -
DELPDEBUG_TRACE -DELPMEM_QUIET -DELPSTACK_QUIET -DELPTESTING -DELP_SOURCE -
DELPSOFT -lellipsys -Wno-deprecated -m64 -fPIC -shared -O3 -o svt_aes_dpi.o -c svt_aes_dpi.cpp
Compile time Macro : SVT_AES_DPI_ENABLE
Cryptography Library Linking requirements:
❖ Link Ellipsys Library :
ELLIPSYS_HOME = <Cryptography Library Install Path>/ellipsys
-CFLAGS -I<ELLIPSYS_HOME>
❖ Link Header file : -CFLAGS -I<ELLIPSYS_HOME>/src/header
Configuration attributes or APIs:
❖ Use configure_cxl_ide API of svt_cxl_cache_mem_configuration to configure VIP for IDE.
<LinkConfiguration>.cache_mem_sys_cfg.<host/device>_cfg[i].configure_cxl_ide(svt_
cxl_types::CONTAINMENT, host_tx_key, device_tx_key);
All the CXL IDE configuration attributes are listed under cxl_dl_ide_members group.
Steps to run IDE Sanity test in Example:
1. Add the following define in sim_build_options file:
+define+SVT_AES_DPI_ENABLE
2. Set the ELLIPSYS_HOME environment variable:
setenv ELLIPSYS_HOME <Cryptography Library Install Path>/ellipsys
3. Copy the vcs_build_options_with_aes to vcs_build_options.
4. Run the test case:
gmake USE_SIMULATOR=vcsvlog cxl_ide_sanity_test
SVT_CXL_SUBSYSTEM_COMPILE_FILE=compile_snps_vip_pcie_serial.f
SVT_CXL_SUBSYSTEM_TOPOLOGY_FILE=topology_snps_vip_cxl_b2b.svi
EN_SVT_CXL_IDE=1 ELLIPSYS_HOME=" <Cryptography Library Install Path>/ellipsys"
The above command is to run the test - ts.cxl_ide_sanity_test.sv with FULL_STACK
topology over serial interface using VCS Simulator.

3.17.3.3 Debug
AES-GCM Trace file to debug:
You can enable the trace file from AES-GCM Layer to debug the message encrypted or decrypted via
"enable_transaction_logging" attribute available in Cache-Mem Configuration.

Feedback
Synopsys, Inc. 69
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Following is the snippet for the trace file :

3.17.4 Memory Interleaving

CXL VIP Host and Device agent components support interleaved set of addresses. The agent components
can be grouped together in one interleaved set. The agents within an interleaved set supports a unique non-
overlapping set of address ranges. For example, assume that there are 2 Devices within an interleaved set.
Device 0 supports address range 0 to 255, Device 1 supports address range 256 to 511, Device 0 supports
address range 512 to 767, Device 1 supports address range 768 to 1023, and so on. What it means is that
Device 0 would process transactions with addresses 0 to 255, 512 to 767 and so on.

3.17.4.1 CXL Device Agent

CXL TL layer monitor issues error if it observes memory transactions with an address which must not be
accessed by CXL device agent.

3.17.4.2 CXL Host Agent

Host VIP checks if the memory address generated by it falls in the interleaving address range. If the address
does not lie in the interleaving address range for this Host, then the Host VIP generates error through
is_valid() check. Host VIP would still transmit the transaction.

3.17.4.3 CXL System Configuration Controls

This configuration API need to be programmed to enable this feature. Refer to CXL class reference for more
details:

Feedback
70 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

❖ svt_cxl_system_configuration::configure_memory_interleaving_parameters(bit
is_host_interleaved_group, bit [`SVT_CXL_MAX_ADDR_WIDTH-1:0] interleaving_start_addr, bit
[`SVT_CXL_MAX_ADDR_WIDTH-1:0] interleaving_end_addr, int interleave_granularity, int
interleave_ways, int tgt_agent_id[]);

3.17.4.4 Usage Examples

1. Two Interleaved CXL Devices (i.e. 2 interleave ways) with 256 Bytes Interleave Granularity:
You need to configure the VIP as below:
cust_cfg is a handle of svt_cxl_subsystem_link_configuration:
cust_cfg.cache_mem_sys_cfg.device_cfg[0].spec_ver = svt_cxl_types::cxl_ver_2_0;
cust_cfg.cache_mem_sys_cfg.configure_memory_interleaving_parameters(0, 'h8000, 'hffff, 256,
2, {0,1});
You need to call reconfigure method in connect_phase() after above configuration settings.
device_env is handle of svt_cxl_subsystem_env.
device_env.cache_mem_env.reconfigure(cust_cfg.cache_mem_sys_cfg);
The VIP takes care of the interleaving based on the above configuration settings. In the above use case 1, VIP
generates an error under the following cases:
✦ svt_cxl_transaction::addr[8] == 0 address comes on agent_id 1
✦ svt_cxl_transaction::addr[8]==1 comes on agent_id 0

CXL VIP does not support multi host or multi device topology. So, the configuration API
Note configure_memory_interleaving_parameters should be called for only one host or
device(i.e. interleave ways=1).

Example:
cust_cfg.cache_mem_sys_cfg.configure_memory_interleaving_parameters(0, 'h8000, 'hffff,
256, 1, {0});

3.18 PM VDM Features

CXL subsystem application layer now handles the PM VDM feature handshakes. These are the features and
their APIs available inside sequence collection. With introduction of App layer, these APIs are
modified/enhanced to utilize Subsystem App configurations and auto response flow.
These APIs are under svt_cxl_subsystem_sequence_collection. Refer Class reference document for
“application layer “ and “PM VDM API” group.

3.18.1 CXL PM VDM and PM Credit initialization APIs

1. Before any PM VDM feature initiation, the pm_credit_initialization() API need to be invoked
from VIP to perform PM credit initialization.
2. generate_cxl_pm_vdm() is used to populate and generate any type of CXL PM VDM messages.

Feedback
Synopsys, Inc. 71
 General Concepts VC VIP CXL Subsystem
UVM User Guide

3. restore_credits() is used to restore credits to the remote partner. (Invoked internally by the other
APIs for the features supported)

3.18.2 CXL Reset APIs

✦ reset_prep_vdm_exchange() is used to perform any Reset type VDM exchange. (Warm, Sleep
State etc...)
✦ perform_warm_reset() API is used to perform Warm Reset VDM exchange and Hot.Reset
entry.
This internally invokes reset_prep_vdm_exchange API for the VDM exchange.

3.18.3 CXL PMREQ APIs

❖ initiate_pm_req(): API to initiate PMReq.Req from Device
❖ initiate_pm_rsp(): API to initiate PMReq.Rsp from Host
You do not need to invoke this API unless PM.Rsp needs to be initiated unilaterally.
❖ Initaite_pm_go(): API to initiate PMReq.Go from Host
You do not need to invoke this API unless PM.Go needs to be initiated unilaterally.
❖ perform_pm_req_entry(): API to perform PMReq Entry with handshake between Req, Rsp and Go
This API invokes/waits till PMReq entry handshake is successful.

3.18.4 Warm Reset

To perform warm reset, you must complete the power management and credit initialization and then send
reset request. The CXL power management messages are sent as PCIe Vendor Defined Type0 messages
with a 4DW data payload.
PM Credits and initialization process is link local. PM2IP.CREDIT_RTN and PM2IP.AGENT_INFO messages
are required to initialize Power Management messaging protocol intended to facilitate communication
between the Downstream and the Upstream Port.
 This can be achieved by using the API: pm_credit_initialization
Description:
task svt_cxl_subsystem_virtual_api_collection_sequence::pm_credit_initialization (
int link_num = 0 ) 
API to perform Credit and PM initialization.
For warm reset, the host shall issue a CXL PM VDM defined as ResetPrep (ResetType = Warm Reset;
PrepType = General Prep) to the CXL device. CXL device shall flush any relevant context to the host and
take any additional steps that are necessary for the CXL host to enter LTSSM Hot-Reset. After all the Reset
preparation is completed, the CXL device issues a CXL PM VDM defined as ResetPrepAck (ResetType =
Warm Reset; PrepType =
General Prep)
 The above can be done through the API: perform_warm_reset
Description -

Feedback
72 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

task svt_cxl_subsystem_virtual_api_collection_sequence::perform_warm_reset (
int link_num = 0 ) 
API to perform Warm Reset VDM exchange and moving to Detect via Hot.Reset entry. (Implicitly calls
reset_prep_vdm_exchange API with value of 8'h10)
Usage example
vip_seq.pm_credit_initialization();
vip_seq.perform_warm_reset();
 Logs Snippet
 Transaction log shows the Message with Data VDM packets.

Waveform will show the LTSSM going into Hot Reset state:

Signals:
<test_top>.spd_0.m_ser.port0.pl0.ascii_ltssm_rx_state[255:1]
<test_top>.spd_0.m_ser.port0.pl0.ascii_ltssm_tx_state[255:1]
<test_top>.spd_0.m_ser.port0.pl0.ascii_phy_rate[959:1]
 Keywords to debug:
❖ pm_credit_initialization

Feedback
Synopsys, Inc. 73
 General Concepts VC VIP CXL Subsystem
UVM User Guide

❖ generate_cxl_pm_vdm
❖ perform_warm_reset
❖ reset_prep_vdm_exchange

3.18.5 Known Limitations

❖ No response timeouts or protocol checks are implemented currently for VDM messages.

3.19 CXL DOE

The Data Object Exchange capability provides a mechanism for software to directly exchange data with a
function through the use of configuration reads and writes. This section outlines how DOE discovery and
data transfers take place.

3.19.1 Overview
The class svt_pcie_device_virtual_doe_sequence is introduced to encapsulate a DOE transfer. You
must provide all the fields defined in this specification for a doe_transaction. It performs the following
steps:
1. Read the DOE status register. Check that the DOE busy bit is clear. If not, start the polling routine
until the busy bit is clear.
2. Write the provided DOE structure to the DOE write data mailbox register. The user is responsible
for constructing a proper DOE structure.
3. Set the DOE go bit in the DOE control register.
4. Optionally set the DOE interrupt register.
5. If the interrupt register is set, wait for MSI interrupt. If not, you must poll the data object ready bit in
configurable intervals.
6. If polling and polling timeout is hit, write the abort bit in the DOE control register and end the
transaction and update status with failure.
7. After the MSI is received or while polling, read the DOE status register. Ensure that the DOE error
bit is clear. If not, flag an error. If interrupts are enabled, check that the interrupt status bit is set.
8. Check that the data object ready bit is set. If an interrupt is received and the data object ready bit is
not set, then flag an error. If an error occurs, abort the transaction and update the status as
unsuccessful.
9. Once a response is ready, read data, one dword at a time from the DOE read data mailbox.
10. If interrupts are used, write 1 to the interrupt status bit to clear it.
11. You must update the status as successful or unsuccessful after all data has been read and return the
data.
There is no attempt to interpret the data that was exchanged. It is at your discretion to process this data.
Example using DOE discovery:
The DOE discovery object contains 3 DW. The first 2 DW are described as above. For PCIE the vendor ID is
‘h0001. For CXL the vendor ID is ‘h1E98. Since a DOE discovery object is 3DW the length is set to 3. The
discovery 1DW payload is defined as:

Feedback
74 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

Table 3-2 DOE Discovery Request Data Object Contents(1DW)

Bit Location Description

7:0 Index - Indicates DOE Discovery entry index queried. Indices must start
at 00h and increase monotonically by 1.

31:8 Reserved - Requesters must place 00 0000h in this field. Responders

must ignore the value in this field.

You need to construct a 3DW array using these definitions and assign it to write_mailbox in the doe
transaction.
This transaction uses interrupts. If during discovery the attached device did not support
Note interrupts, then the interrupt_enable bit must not be set.

Example pseudo-code:
svt_pcie_device_virtual_doe_sequence doe_discovery;
doe_discovery =
svt_pcie_device_virtual_doe_sequence::type_id:create(“doe_discovery”);
doe_discovery.write_mailbox.push_back({8’b0, 8’b0, 16’h1e98}); // 8 reserved bits, data
object type=discover, CXL ID
doe_discovery.write_mailbox.push_back(32’h0000_0003);
doe_discovery.write_mailbox.push_back(32’h0000_0000); // Index 0 points to discovery.
So we are asking if the device is capable of CXL discovery.
doe_discovery.doe_capabilities_base_addr = 12’h0abcd;
doe_discovery.interrupt_enable = 1’b1; // use interrupts.
doe_discovery.doe_polling_interval = 1000; // poll every 1us
doe_discovery.doe_timeout = 1000000; // command timeout after 1ms.
doe_discovery.interrupt_number = 7; // Look for MSI with bit 7 set to indicate the
device’s read mailbox is ready.
start_item(doe_discovery);
finish_item(doe_discovery);
get_response(doe_discovery);
if (doe_discovery.status != doe_discovery::SUCCESSFUL) $dislpay(“ERROR!”);
else begin// check the contents of read_mailbox_data
for (int i=0; i<doe_read_mailbox.size();i++) begin
$display(doe_discovery.read_mailbox[i]); // print the response
…
end
end

3.19.2 Data Classes

These fields will be used for DOE transfer:
1. bit [11:0] doe_capabilities base_addr- This address points to the beginning of the DUT’s doe
capabilities extended capabilities register. The sequence will add offsets to this base address to
access the DOE control, read and write mailbox registers.
2. bit [31:0] doe_read_mailbox_data[$]- Data from the DOE read mailbox.
3. bit [31:0] doe_write_mailbox_data[$]- Data to be sent to the DOE write mailbox.

Feedback
Synopsys, Inc. 75
 General Concepts VC VIP CXL Subsystem
UVM User Guide

4. interrupt_enable- Indicates whether the interrupt bit should be set when writing to the DOE control
register.
5. interrupt_number- Indicates the MSI interrupt number that should be used to determine if the DOE
read mailbox is ready.
6. int doe_polling_interval_ns- Indicates the polling interval to be used to check the data_object_ready
bit.
7. int doe_timeout_ns- Indicates the amount of time the DOE sequence should wait before declarding a
timeout on the DOE transfer.
8. typedef enum doe_status- Indicates wether or not the DOE transaction was successful.

3.19.3 Protocol Checks and Exceptions

1. A DOE timeout error is issued if the transaction does not complete in the time specified in the
sequence.
2. An error is flagged if the doe error bit is set in the doe status register.
3. If a DOE interrupt was received but the data object ready bit is not set then flag an error.
4. If you are using interrupts, check that the interrupt status bit is set in the DOE status register.
5. Check whether the PCIe specification version is 4.0 or greater before executing a DOE sequence.

3.20 Hot Plug Feature

Hot plug flow comprises of Hot removal, and Hot add. Hot removal results into Flexbus link down, PCIe
unplug, and other CXL components unplugged as well. Hot add results into Flexbus link up, PCIe
plugging-in and other CXL components plugging-in. Mid-sim reset feature is supported as one of the Hot
Plug flow i.e. “Hot removal followed by immediate Hot add”.

3.20.1 Usage API

VIP provides a sequence to execute Hot Plug flow namely svt_cxl_subsystem_app_hot_plug_sequence.
The sequence offers controllability on various arguments as listed below. The details are available in Class
reference.
❖ Hot Plug type
❖ Wait event for Hot removal.
❖ Timed delay for Hot add.
❖ Blocking or non-blocking nature of sequence execution
❖ Option to preserve applicable settings.

3.20.2 Topologies validated

Validated with VIP-VIP topologies as listed below.
❖ Full stack with CXL.IO and CXL.Cache/Mem
❖ All supported LPIF topologies

3.20.3 Validation
Preliminary validation covers following scenario.

Feedback
76 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

❖ Hot plug type – HOT_REMOVAL_AND_AND, Wait event – NONE, Port ID – 0

❖ Blocking execution of sequence invocation.
❖ Invoked when system is idle.
❖ When it is invoked, Flexbus goes down and entire Subsystem is unplugged until Hot added back.
❖ Once Hot added, Flexbus comes back up, followed by DL initialization and PM credit initialization
and entire Subsystem is back up again.
❖ Test execution of basic traffic flow post Hot Plug execution.

3.20.4 Known limitations

❖ Additional fine grain controls are TBD.
❖ Hot removal of LPIF topology results in ‘unplug’ of ALL stacks present over LPIF. Additional fine
grain controls are yet to be implemented.
❖ CXL.Cache/Mem reset spec requirements are being analyzed. Some of the functional aspects listed
below are yet to be implemented:
✦ TL handling of modified cache lines during hot removal
✦ TL handling of cache and mem configuration compatibility with host during hot add
❖ These Hot Plug sequence arguments are not completely validated yet:
✦ Non-blocking sequence invocation.
✦ Hot Plug types - HOT_ADD_AND_REMOVAL, HOT_ADD, HOT_REMOVAL
✦ Hot removal wait event – LINK_IP, PM_INIT, SYS_IDLE, TIME_DELAY
❖ These topologies are not yet validated for Hot Plug flow:
✦ Full stack CXL.IO ONLY topology.
✦ Full stack CXL.IO and CXL Cache/Mem DL only.
✦ TLM modes

3.21 Viral Handling

3.21.1 Configuration variable / Enabling Viral handling support
svt_cxl_cache_mem_configuration::enable_viral_handling is set by default enabling the feature at
Cache-mem Transaction and Link Layer.
Process to enter viral state
Make the Link layer to enter into Viral by inserting un-correctable error i.e sending unexpected Init.Param.
Use the sequence API send_init_param() as below to insert it.
vip_seq.send_init_param();
Under TL Only Topology
Use this API to bring the Cache-mem TL into Viral state. This can be invoked based on Viral detection at
DUT DL.

Feedback
Synopsys, Inc. 77
 General Concepts VC VIP CXL Subsystem
UVM User Guide

vip_seq.update_cxl_viral_status(.cache_mem_link_num(link_num),.viral_state(svt_cxl_type
s::VIRAL_ACTIVE));
Also indicate the Retry.Ack reception/ sending as shown. This is required to start executing the protocol
checks for the Mem read transaction’s responses at Host end.
vip_seq.update_cxl_viral_status(.cache_mem_link_num(link_num),.viral_state(svt_cxl_type
s::VIRAL_COMMUNICATED));
Process to Exit out of viral state
Any Conventional reset say, hot, warm or cold reset must cause the Viral exit, as shown:
// Initiating reset at Host end to push Host and devices out of Viral state
vip_seq.enter_hot_reset();

3.22 TLM Port

At the transaction layer, data link layer, and ARB/MUX, TLM ports are available.
 The same connector class - svt_cxl_dispatch_connector is used at all the levels (ARB/MUX, Link Layer
and Transaction Layer)
 Description about svt_cxl_dispatch_connector:
This is type generic.
Usage is as follows:

Usage in typical back to back setup: 

Dispatch connector to connect dispatch sequencer of a 'local' VIP to blocking put port of a 'remote' VIP in a
typical back to back testbench setup

3.22.1 Example usage

❖ TLM Port declaration in TL back to back:
svt_cxl_dispatch_connector #(svt_cxl_channel_transaction,
`SVT_XVM(blocking_put_imp_rx_cache_req_chan)#(svt_cxl_channel_transaction,
svt_cxl_tl)) h2d_tl_cache_req_chan_connector;
❖   TLM Port declaration in DL back to back:
svt_cxl_dispatch_connector #(svt_cxl_flit,
`SVT_XVM(blocking_put_imp_rx_cxl_flit)#(svt_cxl_flit, svt_cxl_dl))
h2d_dl_flit_connector;
 Files for reference: 
<design_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys/env/svt
_cxl_dispatch_connector.sv

<design_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys/env/sv
t_cxl_subsystem_basic_env.sv
For more details, refer the class reference:

Feedback
78 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide General Concepts

https://spdocs.synopsys.com/dow_retrieve/latest/vg/snps_vip_lib/class_ref/cxl_subsystem
_svt_uvm_class_reference/html/tlm_ports.html

Feedback
Synopsys, Inc. 79
 General Concepts VC VIP CXL Subsystem
UVM User Guide

Feedback
80 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

4
CXL Subsystem Verification Topologies

4.1 Verification Requirements - - Supported CXL Device Types

The CXL Subsystem VIP supports all three types of Devices.
❖ Type 1 Device:
❖ Type 2 Device:
❖ Type 3 Device:

4.1.1 CXL Subsystem VIP as Type 1 Device:

The CXL Subsystem VIP can be used as either 'Host' or 'Device' when using it in Type 1 Device mode. You
need to do the following required configuration for using the CXL Subsystem VIP based on the
requirement.

Feedback
Synopsys, Inc. 81
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

CXL Subsystem VIP supports the Type1 CXL.cache transactions and all CXL.io transactions when using in
this mode.

4.1.1.1 Required Configurations

For using CXL Subsystem VIP as Type1 Device do the following configuration.
When using CXL Subsystem VIP as 'Host' -
<cust_cfg>.host_cfg.cache_mem_sys_cfg.host_cfg[0].device_type =
svt_cxl_cache_mem_configuration::TYPE1_DEVICE;
When using CXL Subsystem VIP as 'Device' -
<cust_cfg>.device_cfg.cache_mem_sys_cfg.device_cfg[0].device_type =
svt_cxl_cache_mem_configuration::TYPE1_DEVICE;

Feedback
82 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL Subsystem Verification Topologies

4.1.1.2 Reference Test Case Available in CXL VIP Example Area

Following test case is available in the example cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
Test name: ts.cxl_tl_type1_cache_wr_rd.sv
Description: This test is for Type 1 Device CXL.cache traffic.
Note: The above test is created for VIP back to back setup. You can use it as a reference for creating the test
cases related to Type 1 Device.

4.1.2 CXL Subsystem VIP as Type 2 Device

CXL Subsystem VIP can be configured and used as a Type 2 Device. Based on the CXL Subsystem VIP
Usage, which is as either Host or Device, the required configuration related to Type 2 Device usage needs to
be done.

Feedback
Synopsys, Inc. 83
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

CXL Subsystem supports all three kinds of transactions (CXL.io, CXL.cache, and CXL.mem traffic) when
using it in Type 2 Device.

4.1.2.1 Required Configurations

For using CXL Subsystem VIP as Type2 Device do the following configuration.
When using CXL Subsystem VIP as 'Host' -
<cust_cfg>.host_cfg.cache_mem_sys_cfg.host_cfg[0].device_type =
svt_cxl_cache_mem_configuration::TYPE2_DEVICE;

When using CXL Subsystem VIP as 'Device' -

<cust_cfg>.device_cfg.cache_mem_sys_cfg.device_cfg[0].device_type =
svt_cxl_cache_mem_configuration::TYPE2_DEVICE;

4.1.2.2 Reference Test Case Available in CXL VIP Example Area

This test case is available in the example cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
Test name: ts.cxl_tl_random_mem_wr_rd.sv
Description: This test is for CXL.cache and CXL.mem traffic.

The above test is created for CXL.cache and CXL.mem traffic in VIP back to back setup. You can use
Note it as a reference for creating the test cases related to Type 2 Device.

4.1.3 CXL Subsystem VIP as Type 3 Device

CXL Subsystem VIP can be used as either 'Host' or 'Device' when using it in Type 3 Device. Type 3 Device
usage is enabled by doing the below required configuration.

Feedback
84 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL Subsystem Verification Topologies

CXL Subsystem VIP supports the Type3 CXL.mem transactions when using in this mode.

4.1.3.1 Required Configurations

For using CXL Subsystem VIP as Type3 Device do the following configuration.
When using CXL Subsystem VIP as 'Host' -
<cust_cfg>.host_cfg.cache_mem_sys_cfg.host_cfg[0].device_type =
svt_cxl_cache_mem_configuration::TYPE3_DEVICE;
When using CXL Subsystem VIP as 'Device' -
<cust_cfg>.device_cfg.cache_mem_sys_cfg.device_cfg[0].device_type =
svt_cxl_cache_mem_configuration::TYPE3_DEVICE;

Feedback
Synopsys, Inc. 85
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

4.1.3.2 Reference Test Case Available in CXL VIP Example Area

Following test case is available in the example cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys
Test name: ts.cxl_tl_type3_mem_wr_rd.sv
Description: This test is for Type 3 Device CXL.mem traffic.

The above test is created for VIP back to back setup. You can use it as a reference for creating
Note the test cases related to Type 3 Device.

4.2 Verification Requirement - Supported Topologies

The CXL Subsystem VIP can be used as any of the Device mentioned above in various topologies.
The CXL Subsystem VIP solution supports the following verification requirements by connecting the VIP
and the DUT based on the corresponding topology.

Table 4-1 Verification Topologies

Verification Requirement Topology

Full stack verification of CXL Connect DUT and VIP at PCIE PIPE/Serial Interface
features

Verification of CXL features at Connect DUT and VIP at ARB/MUX (TLM/LPIF/Proprietary)

ARB/MUX

Verification of CXL.mem and Connect DUT and VIP link layer signaling (TLM/LPIF/Proprietary)
CXL.cache features at link layer

Verification of CXL.mem and Connect DUT and VIP transaction layer signaling (TLM/Proprietary)
CXL.cache features at Transaction
layer

This diagram shows the topologies supported for the Verification requirement.

Feedback
86 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL Subsystem Verification Topologies

Figure 4-1 Verification Requirements and Topologies

All possible topologies with different modes

The above four topologies are further divided into sub-topologies.
This table shows all supported topologies in different modes.

Topology Connection at Mode Description and Device Types Supported

#1 Full stack PIPE with CXL.io CXL Subsystem VIP connected at the PIPE interface
and with the DUT. CXL.io, CXL.cache & CXL.mem
CXL.cache/CXL.me components are enabled. All Device Types ( 1, 2 and 3)
m are supported.

#1 Full stack PIPE with only CXL Subsystem VIP connected at the PIPE interface
CXL.io with the DUT. Only CXL.io component is enabled.

#1 Full stack Serial with CXL.io CXL Subsystem VIP connected at the Serial interface
and with the DUT. CXL.io, CXL.cache & CXL.mem
CXL.cache/CXL.me components are enabled. All Type 1, 2 and 3 Device
m types are supported.

#1 Full stack Serial with only CXL Subsystem VIP connected at the Serial interface
CXL.io with the DUT. Only CXL.io component enabled.

#2 ARB Mux LPIF with CXL.io and CXL Subsystem VIP connected at the LPIF interface
CXL.cache/CXL.me with the DUT. CXL.io, CXL.cache & CXL.mem
m components are enabled. All Type 1, 2 and 3 Device
types are supported.

#2 ARB Mux LPIF with only CXL Subsystem VIP connected at the LPIF interface
CXL.io with the DUT. Only CXL.io component is enabled. All
Type 1, 2 and 3 Device types are supported.

Feedback
Synopsys, Inc. 87
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

Topology Connection at Mode Description and Device Types Supported

#2 ARB Mux LPIF with only CXL Subsystem VIP connected at the LPIF interface
CXL.cache/CXL.me with the DUT. Only CXL.cache & CXL.mem component
m is enabled. All Type 1, 2 & 3 Device types are
supported.

#2 ARB Mux TLM with CXL.io and CXL Subsystem VIP connected with DUT using TLM
CXL.cache/CXL.me ports. Only CXL.io component is enabled. All Type 1, 2
m & 3 Device types are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

#2 ARB Mux TLM with only CXL.io CXL Subsystem VIP connected with DUT using TLM
ports. Only CXL.io component is enabled. All Type 1, 2
& 3 Device types are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

#2 ARB Mux TLM with only CXL Subsystem VIP connected with DUT using TLM
CXL.cache/CXL.me ports. Only CXL.cache & CXL.mem component is
m enabled. All Type 1, 2 & 3 Device types are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

#3 Link Layer LPIF with CXL.io and CXL Subsystem VIP connected with the DUT using
CXL.cache/CXL.me LPIF interface . CXL.io, CXL.cache & CXL.mem
m components are enabled. All Type 1, 2 & 3 Device types
are supported

#3 Link Layer LPIF with only CXL Subsystem VIP connected with the DUT using
CXL.io [only TL+DL] LPIF interface with only Transaction and Link layer
enabled. Only CXL.io component is enabled. All Type 1,
2 & 3 Device types are supported

#3 Link Layer LPIF with only CXL Subsystem VIP connected at the LPIF interface
CXL.cache/CXL.me with the DUT. Only CXL.cache & CXL.mem component
m is enabled. All Type 1, 2 & 3 Device types are supported

#3 Link Layer TLM with CXL.io and CXL Subsystem VIP connected with DUT using TLM
CXL.cache/CXL.me ports at link layer. CXL.io, CXL.cache & CXL.mem
m components are enabled. All Type 1, 2 & 3 Device types
are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

#3 Link Layer TLM with only CXL.io CXL Subsystem VIP connected with DUT using TLM
ports at link layer. Only CXL.io component is enabled.
All Type 1, 2 & 3 Device types are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

Feedback
88 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL Subsystem Verification Topologies

Topology Connection at Mode Description and Device Types Supported

#3 Link Layer TLM with only CXL Subsystem VIP connected with DUT using TLM
CXL.cache/CXL.me ports at link layer. Only CXL.cache & CXL.mem
m component is enabled. All Type 1, 2 & 3 Device types
are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

#4 Transaction Layer TLM with only CXL Subsystem VIP connected with DUT using TLM
CXL.cache/CXL.me ports at the Transaction layer. Only CXL.cache &
m CXL.mem component is enabled. All Type 1, 2 & 3
Device types are supported.
Note: TLM to DUT signaling interface BFM is provided
by user (or) is part of the DUT module.

4.2.1 Topology 1: Connect DUT and VIP at PCIE PIPE/ Serial

CXL Subsystem VIP is providing the following modes of usage under Topology #1
❖ PIPE with CXL.io and CXL.cache/CXL.mem
❖ PIPE with only CXL.io
❖ Serial with CXL.io and CXL.cache/CXL.mem
❖ Serial with only CXL.io

Feedback
Synopsys, Inc. 89
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

4.2.1.1 Running CXL Subsystem VIP Example Test Cases with Topology #1
Here is the list of valid combinations of topology and compile files to be used for Topology #1
Valid Combinations of Compile and Topology Files for Full Stack Topology

Full Stack (Serial)

CXL.io traffic test compile_snps_vip_pcie_serial.f

cxl_io_random_mem_wr_rd topology_snps_vip_cxl_b2b.svi

Type 3 Device CXL.mem test compile_snps_vip_pcie_serial.f

cxl_tl_type3_mem_wr_rd topology_snps_vip_cxl_b2b.svi

Type 1 Device CXL.cache test compile_snps_vip_pcie_serial.f

cxl_tl_type1_cache_wr_rd topology_snps_vip_cxl_b2b.svi

Type 2 Device compile_snps_vip_pcie_serial.f

random traffic test topology_snps_vip_cxl_b2b.svi
cxl_tl_random_mem_wr_rd

CXL Warm Reset test: (With 2.0 APN compile_snps_vip_pcie_serial.f

negotiation) topology_snps_vip_cxl_b2b.svi
cxl_io_warm_reset

Type3 device GPF test compile_snps_vip_pcie_serial.f

ts.cxl_io_tl_type3_gpf.sv topology_snps_vip_cxl_b2b.svi

IDE Sanity test compile_snps_vip_pcie_serial.f

ts.cxl_ide_sanity_test.sv topology_snps_vip_cxl_b2b.svi

CXL DOE test compile_snps_vip_pcie_serial.f

ts.cxl_crt_doe_capabilities.sv topology_snps_vip_cxl_b2b.svi

4.2.2 Topology 2: Connect DUT and VIP at ARB MUX (TLM/ LPIF/ Proprietary)

Feedback
90 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL Subsystem Verification Topologies

CXL Subsystem VIP is providing the following modes of usage under Topology #2
❖ LPIF with CXL.io and CXL.cache/CXL.mem
❖ LPIF with only CXL.io
❖ LPIF with only CXL.cache/CXL.mem
❖ TLM with CXL.io and CXL.cache/CXL.mem
❖ TLM with only CXL.io
❖ TLM with only CXL.cache/CXL.mem

Feedback
Synopsys, Inc. 91
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

4.2.3 Topology 3: Connect DUT and VIP Link Layer Signalling (TLM/ LPIF/ Proprietary)

CXL Subsystem VIP is providing these modes of usage under Topology #3

❖ LPIF with CXL.io and CXL.cache/CXL.mem
❖ LPIF with only CXL.io [only TL+DL]
❖ LPIF with only CXL.cache/CXL.mem
❖ TLM with CXL.io and CXL.cache/CXL.mem
❖ TLM with only CXL.io
❖ TLM with only CXL.cache/CXL.mem

4.2.4 Running CXL Subsystem VIP example Test Cases with Topology #3
Here is the list of valid combinations of topology and compile files to be used for Topology #3

Valid Combinations of Compile and Topology Files for TL+DL (with and without LPIF) Topology

TL+DL topology (without LPIF) LPIF topology

CXL.io traffic test compile_snps_vip_cxl_io_tl_dl_only.f compile_snps_vip_io_lpif.f

cxl_io_random_mem_wr_r topology_snps_vip_cxl_io_dl_b2b.svi topology_snps_vip_cxl_b2b_lpif.svi
d

Feedback
92 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL Subsystem Verification Topologies

TL+DL topology (without LPIF) LPIF topology

Type 3 Device CXL.mem compile_snps_vip_cxl_cache_mem.f compile_snps_vip_cache_mem_only_dl_tl_lpif.

test topology_snps_vip_cxl_b2b.svi f
cxl_tl_type3_mem_wr_rd topology_snps_vip_cxl_b2b_lpif.svi

Type 1 Device CXL.cache compile_snps_vip_cxl_cache_mem.f compile_snps_vip_cache_mem_only_dl_tl_lpif.

test topology_snps_vip_cxl_b2b.svi f& topology_snps_vip_cxl_b2b_lpif.svi
cxl_tl_type1_cache_wr_rd

Type 2 Device compile_snps_vip_cxl_cache_mem.f -NA-

random traffic test topology_snps_vip_cxl_b2b.svi
cxl_tl_random_mem_wr_r
d

4.2.5 Topology 4: Connect DUT and VIP at Transaction Layer Signalling (TLM/Proprietary)

CXL Subsystem VIP is providing the following mode of usage under Topology #4
❖ TLM with only CXL.cache/CXL.mem

4.2.5.1 Running CXL Subsystem VIP Example Test Cases with Topology #4
Here is the list of valid combinations of topology and compile files to be used for Topology #4

Feedback
Synopsys, Inc. 93
 CXL Subsystem Verification Topologies VC VIP CXL Subsystem
UVM User Guide

Valid Combinations of Compile and Topology Files for TL Only Topology

TL Only topology

CXL.io traffic test -NA-

cxl_io_random_mem_wr_rd

Type 3 Device CXL.mem test compile_snps_vip_cxl_cache_mem_tl.f

cxl_tl_type3_mem_wr_rd topology_snps_vip_cxl_b2b.svi

Type 1 Device CXL.cache test compile_snps_vip_cxl_cache_mem_tl.f

cxl_tl_type1_cache_wr_rd topology_snps_vip_cxl_b2b.svi

Type 2 Device compile_snps_vip_cxl_cache_mem_tl.f

random traffic test topology_snps_vip_cxl_b2b.svi
cxl_tl_random_mem_wr_rd

Feedback
94 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

5
CXL Application Layer Agent

5.1 Agent Overview

CXL Subsystem has added an application layer which sits on top of CXL.io stack and CXL.Cache/Mem
stack. It communicates with internal components of CXL Subsystem and is responsible for following
features of an CXL Subsystem.
❖ Hot Plug
❖ Power Management(PM VDM) Controller

Feedback
Synopsys, Inc. 95
 CXL Application Layer Agent VC VIP CXL Subsystem
UVM User Guide

CXL Subsystem VIP uses the rx_tlp_out_port TLM port of PCIe TL and Target App. You are
recommended to use the rx_tlp_peek_port in their testbench instead of this put_port.

5.2 User API of CXL Subsystem Application

❖ Provides svt_cxl_subsystem_app_configuration class to control various attributes of an
application.
❖ Provides svt_cxl_subsystem_app_status class that provides internal status of an application.
❖ Provides svt_cxl_subsystem_app_transaction class for issuing transactions. Also provides
associated sequences.
❖ Provides dedicated svt_cxl_subsystem_app_vdm_transaction for PM/Error VDM transactions
which is encapsulated inside svt_cxl_subsystem_app_transaction.
❖ Provides svt_cxl_subsystem_app_service class for issuing commands. Also, provides associated
sequences.
❖ Provides svt_cxl_subsystem_app_virtual_sequencer for issuing transaction and command
sequences.

Feedback
96 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

6
CXL.io Agent

6.1 Overview

Figure 6-1 CXL.io Agent View

The CXL VIP, at its highest level, encapsulates the PCIe UVM VIP, which is composed of the
svt_pcie_device_agent class acting as the CXL.io agent. This will generate CXL.io transactions.
CXL VIP leverages the PCIe VIP agent for all CXL.io operations in a similar way where CXL protocol
leverages PCIe features for non-coherent load/store interface for IO devices.

Feedback
Synopsys, Inc. 97
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

svt_pcie_device_agent class, encapsulates the PCIe Agent (Class type=svt_pcie_agent)-an application

layer that comprises of Driver Application, Requester Application, and Target Application (Memory, I/O,
Configuration database). These applications are used to generate the CXL.io traffic through different APIs.

Feedback
98 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.io Agent

❖ The Application Layer: The CXL VIP has a layer on top of the CXL.io stack representing the software
layer in a real application of the PCIe bus. The application layer is responsible for generating and
handling transactions. The application layer of the CXL.io agent is the layer that is typically
programmed by the test to generate stimulus or respond to the incoming requests. The application
layer has the following blocks that perform specific functions:
✦ Driver Application (Type=svt_pcie_driver_app, Instance=driver[0]): The Driver application
provides a simple interface that can be used to quickly create CXl.io transaction requests
(memory read/write request, I/O read/write requests etc.,). The application deals with driver
application transaction objects (svt_pcie_driver_app_transaction) which is an abstract
description of the transaction layer packet.
✦ Requester Application (Type=svt_pcie_requester_app, Instance=requester): The requester
application can be used to generate PCIe memory/read transaction to a remote target. The
application can be configured to choose addresses at random (constrained by
minimum/maximum configuration parameters) and have varying lengths (again, constrained
by minimum/maximum configuration parameters) and generate traffic at a requested
bandwidth (again, constrained by minimum/maximum configuration parameters). This
application will be useful where a background exerciser of write/read request is required.
✦ Target Application (Type=svt_pcie_target_app, Instance=target[0]): The target application is the
block that automatically responds to various inbound CXL.io requests. Read transaction requests
can be optionally broken up into multiple completions, potentially interleaved with other read
completions by configuration. The target application has auxiliary blocks that represent the
completion memory used while generating completions. These blocks include Memory Target,
IO Target and Configuration Database. The blocks comprise of a sparse memory allowing a wide
variety memory/IO addresses/registers to be accessed by a DUT.
✦ Memory Target (Type=svt_pcie_mem_target, Instance=mem_target): The memory target is the
PCIe VIP's sparse memory model used to store write data and return read data to the incoming
memory requests. This sparse memory model responds to a wide variety of addresses (32-bit
and 64-bit) when accessed by a requester. The memory target has APIs to write into its sparse
memory through backdoor or read from its sparse memory through backdoor to meet different
kinds of testing requirements.
✦ I/O Target (Type=svt_pcie_io_target, Instance=io_target): The I/O target is the PCIe VIP's
sparse memory model used to store write data and return read data to the incoming I/O
requests. This sparse memory model responds to a wide variety of addresses (32-bit and 64-bit)
when accessed by a requester. The I/O target has APIs to write into its sparse memory via
backdoor or read from its sparse memory via backdoor to meet different kinds of testing
requirements.
✦ Configuration Database (Type=svt_pcie_cfg_database, Instance=
svt_pcie_target_app::cfg_database): The configuration database is the sparse memory model of
PCIe VIP that is used to store write data and return read data to the incoming configuration
requests. This sparse memory model responds to a wide variety of addresses (type 0, type 1,
extended capability registers, and so on) when accessed by a requester. The configuration
database has APIs to write into its sparse memory through backdoor or read from its sparse
memory through backdoor to meet different kinds of testing requirements.

Feedback
Synopsys, Inc. 99
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

✦ PCIe Agent: The PCIe Agent encapsulates the UVM drivers that represents the Transaction
Layer, the Data-link Layer, and the Physical Layer of the PCIe protocol stack. The
svt_pcie_agent class represents this encapsulation in the PCIe VIP. The PCIe agent class is
instanced as pcie_agent within svt_pcie_device_agent. The agent class consists of the
following layers:
✧ The Transaction Layer (Type=svt_pcie_tl, Instance=pcie_tl): The svt_pcie_tl class defines
functions of the transaction layer (TL) in the PCIe VIP. The applications transfer transaction
requests to the TL for transmission. The TL composes the transaction layer packet (TLP) and
hands it down to the data-link layer located below it. The transaction layer also receives TLPs
from the data-link layer which gets routed up to the correct application. It is also possible for
the test to interface directly with the TL to generate TLPs. But it is recommended to use the
application layers.
✧ The Data-link Layer (Type=svt_pcie_dl, Instance=pcie_dl): The svt_pcie_dl class defines
the functions of the data-link (DL) layer in the PCIe VIP. The TL transfers TLPs to the DL to
be framed with a sequence number and a CRC and ensure the remote receiver receives the
packet without any errors. The DL also performs the other standard functions of link
management using data-link layer packets (DLLPs).
✧ Physical Layer (Type=svt_pcie_pl, Instance=pcie_pl): The svt_pcie_pl class defines the
functions of the physical layer (PL) in the PCIe VIP. The PL breaks down packets it receives
(from the DL) into symbols and encodes them as per the specification before transmission. It
also composes packets from data received on the receive data lanes and sends them back to
the DL. It also performs other functions to maintain the link such as the LTSSM and functions
for low power and so on. This includes Flex Bus also. Refer Chapter 3 for more details.

Feedback
100 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.io Agent

6.2 Configuration
The CXL.io Agent is configured using an object of class svt_pcie_device_configuration (cxl_io_cfg[] as
the handle) defined within the top level configuration class svt_cxl_subsystem_configuration of CXL
VIP. This class has other class objects defined within it to form a hierarchy that corresponds to the hierarchy
inside the CXL.io Agent.

Refer the Section 3.4 for top level configuration class details. This chapter assumes that you
Note have already created environment.

Figure 6-2 CXL.io Configuration Hierarchical View

svt_pcie_device_configuration (cxl_io_cfg[])
|
|--------> driver_cfg[] (type=svt_pcie_driver_app_configuration)
|
|--------> requester_cfg (type=svt_pcie_requester_app_configuration)
|
|--------> target_cfg[] (type=svt_pcie_target_app_configuration)
|
|--------> pcie_cfg (type=svt_pcie_configuration)

Feedback
Synopsys, Inc. 101
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

|
|--------> tl_cfg (type=svt_pcie_tl_configuration)
|
|--------> dl_cfg (type=svt_pcie_dl_configuration)
|
|--------> pl_cfg (type=svt_pcie_pl_configuration)

This class is comprised of direct variables and class objects that are used to configure other agents/drivers
that are part of the CXL.io agent.

Example with the usage:

❖ How to configure Polling Active timeout for Host?
You can configure the Polling Active LTSSM state timeout for the CXL.io agent.
/** Create the top level configuration handle **/
svt_cxl_subsystem_link_configuration cust_cfg;
/** Configuring the Polling Active LTSSM state timeout for ith CXL.io agent **/
// Sample Format ->
//<cust_cfg>.<host_cfg/device_cfg>.cxl_io_cfg[0].pcie_cfg.pl_cfg.<pl_cfg_attrbute>
cust_cfg.host_cfg.cxl_io_cfg[0].pcie_cfg.pl_cfg.polling_active_timeout_ns = 240000;
You can refer the svt_cxl_subsystem_base_test.sv and svt_cxl_subsystem_base_env.sv in
the installed unified example for more details on the usage.

Only the top-level configuration handle is user-defined. After that, the instance handle
Note names remains fixed and must not be changed by the user.

6.3 Status
Status is used to get run time information of PL/DL/TL layer aspects of a CXL.io agent. The CXL.io Agent
provides a set of state values representing the status of its sub-components at anytime in the test simulation.
svt_cxl_subsystem_status is the CXL Subsystem 'top level' status class. It encapsulates the IO status
class object corresponding to the CXL.io agents present in the CXL Subsystem.

Refer Section 3.5 for top level status class details. This chapter assumes the you have already
Note created the environment.

The svt_pcie_device_status class (io_status[] as handle) will provide us the CXL.io agent status.

Feedback
102 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.io Agent

Figure 6-3 CXL.io Status Hierarchial View

svt_pcie_device_status (io_status[])
|
|--------> driver_status[] (type = svt_pcie_driver_app_status)
|
|--------> requester_status (type= svt_pcie_requester_app_status )
|
|--------> target_status [] (type = svt_pcie_target_app_status)
|
|--------> pcie_status (type = svt_pcie_status)
|
|--------> tl_status (type = svt_pcie_tl_status)
|
|--------> dl_status (type = svt_pcie_dl_status)
|
|--------> pl_status (type = svt_pcie_pl_status)

Example usage:
How to check Host APN status?

Feedback
Synopsys, Inc. 103
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

/** Instances of Subsystem status */

svt_cxl_subsystem_status host_status;
/** Check the if the APN handshake is successful for CXL.io agent in
cxl_test_report_phase**/
// Sample Format ->
//<status_class_obj_handle>.io_status[0].pcie_status.pl_status.<status_attribute>
if
(host_status.io_status[0].pcie_status.pl_status.alternate_protocol_negotiation_status
== svt_pcie_pl_status::APN_SUCCESSFUL)
`svt_note(method_name, "APN Successful for Host");
You can refer the svt_cxl_subsystem_base_test.sv and svt_cxl_subsystem_base_env.sv in the
installed unified example for more details on the usage.

Only the top-level status handle is user-defined. After that, the instance handle names remain fixed
Note and must not be changed by the user.

6.4 Sequencers
The CXL.io Agent class (svt_pcie_device_agent) has different UVM sequencer objects to schedule
transaction requests or service requests on any of its subcomponent Drivers. A UVM sequencer is an arbiter
that controls the transaction flow from multiple stimulus generators. The sequencers communicate with
drivers using the TLM interfaces.

Refer Section 3.3 for top level sequencer details. This chapter assumes that you have already created
Note environment.

For CXL.io, svt_pcie_device_virtual_sequencer(cxl_io_virt_seqr[] as handle) class handle is

present inside svt_cxl_subsystem_sequencer (Top level virtual sequencer).

Feedback
104 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.io Agent

Using the cxl_io_virt_seqr[], you can use all the sequencers present for the CXl.io agent.
Example Usage:
How to access the sequencer hierarchy for pl_seqr?

Feedback
Synopsys, Inc. 105
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

Assuming you already have created the handle for top-level virtual sequencer as host_seqr, for using any
sequencer of CXL.io Agent, you can use cxl_io_virt_seqr[]. It contains of pcie_virt_seqr for pl/dl/tl
protocol layer sequencers. Inside pcie_virt_seqr, you will have pl_seqr.
<p_sequencer/top_level_seqr_handle>.cxl_io_virt_seqr[0].pcie_virt_seqr.pl_seqr
Refer this figure and follow the colored part.

Feedback
106 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.io Agent

Only the top-level sequencer handle is user-defined. After that, the instance handle names remain
Note fixed and must not be changed by the user.

Feedback
Synopsys, Inc. 107
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

6.5 Sequences
Many sequences are present for CXL.io agent. They can be divided in two categories:
❖ Transaction sequences
❖ Service sequences.
Refer the HTML class reference for more information.
Example Usage:
How do I enable link up or send a Memory TLP?
/** Creating object handle of sequence class */
/** PCIe PL Link sequences */
svt_pcie_pl_service_set_phy_en_sequence pl_link_en_seq;
/** PCIE DL Link Enable sequence */
svt_pcie_dl_service_set_link_en_sequence dl_link_en_seq;
/** PCIE Driver APP Mem traffic sequence for Mem Write/Read transactions */
svt_pcie_driver_app_mem_request_sequence mem_wr_seq, mem_rd_seq;

……
bit[32:0] local_addr;
bit[9:0] local_len;
……
/** Enabling PHY for CXL.io agent */
`svt_uvm_do_on_with(pl_link_en_seq,
p_sequencer.cxl_io_virt_seqr[0].pcie_virt_seqr.pl_seqr, {phy_enable == 1'b1;})

/** Enabling DL link for CXL.io 0th agent */

`svt_uvm_do_on_with(dl_link_en_seq,
p_sequencer.cxl_io_virt_seqr[0].pcie_virt_seqr.dl_seqr, {enable == 1'b1;})

/** Initiating MEM_WR transaction for CXl.io agent*/

`svt_uvm_create_on(mem_wr_seq,p_sequencer.cxl_io_virt_seqr[0].driver_transaction_seqr[0
])
`svt_uvm_rand_send_with(mem_wr_seq, {transaction_type ==
svt_pcie_driver_app_transaction::MEM_WR;
address inside {[32'h4000_0000 : 32'h8000_0000]};
length == 10;
first_dw_be
== 4'b1111;
last_dw_be == 4’b1111;
})
local_addr = mem_wr_seq.address;
local_len = mem_wr_seq.length;

Feedback
108 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.io Agent

/** Initiating MEM_RD transaction for CXl.io agent */

`svt_uvm_create_on(mem_rd_seq,p_sequencer.cxl_io_virt_seqr[0].driver_transaction_seqr[0
])
`svt_uvm_rand_send_with(mem_rd_seq, {transaction_type ==
svt_pcie_driver_app_transaction::MEM_RD;
address == local_addr;
length == local_len;
first_dw_be == 4'b1111;
last_dw_be == 4’b1111;
})

Here p_sequencer represents the top-level virtual sequencer

Note (svt_cxl_subsystem_sequencer). Refer Section 3.3 for more details.

6.6 APIs
There are various APIs that are available to ease the development process. All the APIs are present in the
svt_cxl_subsystem_virtual_api_collection_sequence class. This sequence is for API based traffic
generation for complete Subsystem.
As an example, there are APIs to generate memory request for CXL.io such as generate_cxl_io_mem_rd,
generate_cxl_io_mem_wr and so on.
For complete list of available APIs and their input parameters, refer the HTML class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/sequences/class_svt_cxl_subsystem_virtual_api_collection_sequence.html

Example with the usage:

How do I activate CXL.io link using APIs?
/** In base sequence, this sequence handle is set with vip sequencer */
svt_cxl_subsystem_virtual_api_collection_sequence vip_seq;
/** Extend your custom sequence from base sequence and use the API */
/** Blocking API till CXL.io link up */
// Sample format -> <sequence_handle>.<api_name>(input/output parameters);
vip_seq.activate_cxl_io_link(0); // input int io_link_num
Refer HTML Class reference for more details on this API:
$DESIGNWARE_HOME
/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html/sequences/class
_svt_cxl_subsystem_virtual_api_collection_sequence.html#item_activate_cxl_io_link

Feedback
Synopsys, Inc. 109
 CXL.io Agent VC VIP CXL Subsystem
UVM User Guide

Feedback
110 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

7
CXL.mem and CXL.cache Agent

7.1 Overview
7.1.1 CXL.mem and CXL.cache Agent
The CXL Subsystem environment, svt_cxl_subsystem_env contains the svt_cxl_env class which
comprises the CXL Cache/mem Agent - is the CXL Cache/mem component with the Transaction Layer and
Link Layer.

Figure 7-1 CXL.cache/mem Agent View

The following component is present inside the svt_cxl_env.

Feedback
Synopsys, Inc. 111
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

❖ svt_cxl_agent
svt_cxl_agent encapsulates the Transaction Layer and Link Layer of CXL Cache/mem component. This
comprises of Driver, Monitor, and Sequencer at Transaction Layer level and Data Link Layer level.
Components present inside the svt_cxl_agent
❖ CXL Transaction Layer Driver (Type= svt_cxl_tl, Instance= tl_driver):
The svt_cxl_tl_monitor class defines the functions of the CXL Cache/mem Transction Layer (TL)
Monitor in the CXL Subsystem VIP. Once the CXL transaction on the bus is complete, the completed
sequence item is provided to the analysis node of monitor, which can be used by the testbench.
❖ CXL Transaction Layer Monitor (Type= svt_cxl_tl_monitor, Instance= tl_mon):
The svt_cxl_tl_monitor class defines the functions of the CXL Cache/mem Transction Layer (TL)
Monitor in the CXL Subsystem VIP. Once the CXL transaction on the bus is complete, the completed
sequence item is provided to the analysis node of monitor, which can be used by the testbench.
For the available Analysis TLM Ports at this level, refer the svt_cxl_tl_monitor class in the HTML
Class reference.
Link to HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_publi
c/html/monitor/class_svt_cxl_tl_monitor.html
❖ CXL Transaction Layer Sequencers
You can provide CXL sequences to the CXL Transaction Layer sequencer. All the available CXL
Transaction Layer sequencers are discussed in the Section 6.4 Sequencers.
❖ CXL Data Link Layer Driver (Type= svt_cxl_dl, Instance= dl_driver):
The svt_cxl_dl class defines the functions of the CXL Cache/mem Data Link Layer (DL) Driver in
the CXL Subsystem VIP. Within the Data Link Layer, the CXL driver gets sequences from the CXL
sequencer. The CXL driver then drives the CXL transactions on the CXL node.
❖ CXL Data Link Layer Monitor(Type= svt_cxl_dl_monitor, Instance= dl_mon):
The svt_cxl_dl_monitor class defines the functions of the CXL Cache/mem Data Link Layer (DL)
Monitor in the CXL Subsystem VIP. Once the CXL transaction on the bus is complete, the completed
sequence item is provided to the analysis node of monitor, which can be used by the testbench.
For the available Analysis TLM Ports at this level, refer the svt_cxl_dl_monitor class in the HTML
Class reference.
Link to HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html/
monitor/class_svt_cxl_dl_monitor.html
❖ CXL Data Link Layer Sequencers
You can provide CXL sequences to the CXL Data Link Layer sequencer. All the available CXL Data
Link Layer sequencers are discussed in the section 6.4 Sequencers.

7.1.2 Classes and Applications for Using CXL.mem/cache Component

The following classes have members and tasks related to CXL.cache/mem component features and
operation.

Feedback
112 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.mem and CXL.cache Agent

❖ Component Class svt_cxl_env: Encapsulates the CXL.cache/mem

❖ Configuration class svt_cxl_system_configuration: This class contains members to configure the
behavior of the CXL.Cache/mem Agent.
❖ Status class svt_cxl_system_status: Used for returning the status related to CXL.Cache/mem Agent
to the testbench.

7.2 Configuration
The CXL.Cache/mem Agent is configured using an object of class svt_cxl_system_configuration
(cache_mem_sys_cfg is the handle) defined within the top level configuration class
svt_cxl_subsystem_configuration of CXL Subsystem VIP.

Refer the Section 3.4 for top level configuration class details. This chapter assumes that you have
Note already created the environment.

svt_cxl_system_configuration contains instances of the class

svt_cxl_cache_mem_configuration

Feedback
Synopsys, Inc. 113
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

svt_cxl_cache_mem_configuration is used to configure the CXL.Cache/mem agent.

svt_cxl_system_configuration (cache_mem_sys_cfg)
|
|--------> host_cfg/device_cfg (<host_cfg/device_cfg>)
For all the available configuration attributes and functions related to CXL.Cache/mem agent, refer to the
HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/configuration/class_svt_cxl_cache_mem_configuration.html

Example usage:
How to configure the DL Credit return priority between CXL.cache Vs CXL.mem for Host?
svt_cxl_subsystem_link_configuration cust_cfg;
/** Configuring the CXL.Cache/mem agent **/
// Sample Format ->
//<cust_cfg>.<host_cfg/device_cfg>.cache_mem_sys_cfg.<host_cfg[0]/device_cfg[0]>.<Cache
/mem configuration attribute>
/** Setting DL Credit return priority mode as PROT_PRIORITY_MODE - This indicates that the protocol
selected for credit return on the next outgoing flit will be based on the priority of protocol. If the desired
protocol (CXL.Cache or CXL.mem) has at least 1 credit, it gets priority over the other.**/
cust_cfg.host_cfg.cache_mem_sys_cfg.host_cfg[0].dl_credit_return_priority_mode =
svt_cxl_cache_mem_configuration::PROT_PRIORITY_MODE ;

Only the top-level configuration would be defined by you. After that, the instance handle
Note names remains fixed and must not be changed by you.

7.3 Status
This figure highlights the svt_cxl_system_status, which contains the set of status attributes related to
CXL Cache/mem Component that is present inside the top level status class: svt_cxl_subsystem_status.

Refer Section 3.5 for top level status class details. This chapter assumes that you have already
Note created environment svt_cxl_system_status is the Status class used to get the information
about CXL.Cache/mem Agent's status. svt_cxl_subsystem_status is the CXL Subsystem 'top
level' status class. It encapsulates the CXL.Cache/mem status class as an object.

Feedback
114 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.mem and CXL.cache Agent

svt_cxl_system_status contains instances of the class svt_cxl_status for both Host and Device
statuses
svt_cxl_status contains all the status attributes related to the CXL.Cache/mem agent.
svt_cxl_system_status (cache_mem_sys_status)
|
|--------> svt_cxl_status(host_cache_mem_status[0]/
device_cache_mem_status[0]>)
|
|--------> svt_cxl_tl_status (tl_status)
|
|--------> svt_cxl_dl_status (dl_status)
❖ CXL Transaction Layer Status (Type= svt_cxl_tl_status, Instance= tl_status):
svt_cxl_tl_status is a Transaction Layer Status class. This contains information related to the
CXL.Cache/mem Transaction Layer. Refer to the documentation of #svt_cxl_tl_status class for
more details.
❖ CXL Link Layer Status (Type= svt_cxl_dl_status, Instance= dl_status):
svt_cxl_dl_status is a Link Layer Status class. This contains information related to the
CXL.Cache/mem the Link layer. Refer to the documentation of #svt_cxl_dl_status class for more
details.
For all the available status attributes related to CXL.Cache/mem agent, refer to the HTML Class reference:

Feedback
Synopsys, Inc. 115
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/status/class_svt_cxl_system_status.html
Example usage:
How to wait for CXL.Cache/mem DL link to be up?
/** Instances of Subsystem status */
svt_cxl_subsystem_status host_status;
// Sample Format:
//<subsystem_status_class_obj_handle>.cache_mem_sys_status.
<host_cache_mem_status[0]/device_cache_mem_status[0]>.dl_status.<status_attribute>
/** wait for the CXL.Cache/mem DL link to be up**/
wait(host_status.cache_mem_sys_status.host_cache_mem_status[0].dl_status.curr_fsm_state
== svt_cxl_dl_status::LINK_UP);

Only the top-level status handle is user-defined. After that, the instance handle names
Note remains fixed and must not be changed by the user.

7.4 Sequencers
There are two kinds of sequencers available in CXL Subsystem VIP.
1. Service Sequencers
These are used to schedule service sequences. These won't create any transactions and are used to
request a change in the behavior of the VIP.
2. Transaction Sequencers
These are used to schedule transactions sequences. These sequencers will generate the transactions.
The following figure highlights the svt_cxl_system_virtual_sequencer, which contains all the
sequencers related to CXL Cache/mem Component, present inside the top level sequencer class -
svt_cxl_subsystem_sequencer.

Feedback
116 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.mem and CXL.cache Agent

Only the top-level sequencer handle is user-defined. After that, the instance handle names remains
Note fixed and must not be changed by the user.

svt_cxl_system_vitual_sequencer contains the instance of the class svt_cxl_virtual_sequencer.

svt_cxl_virtual_sequencer is the CXL.Cache/mem virtual sequencer used to control all of the
sequencers that are operating at CXL Transaction and Data Link Layer.
svt_cxl_system_virtual_sequencer (cache_mem_system_seqr)
|
|--------> svt_cxl_virtual_sequencer(cache_mem_virt_seqr[0]>)
|
|--------> svt_cxl_tl_req_sequencer (tl_req_seqr)
|
|--------> svt_cxl_tl_rsp_sequencer (tl_rsp_seqr)
|
|--------> svt_cxl_channel_sequencer (dl_cache_req_seqr)

Feedback
Synopsys, Inc. 117
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

|
|--------> svt_cxl_channel_sequencer (dl_cache_rsp_seqr)
|
|--------> svt_cxl_channel_sequencer (dl_cache_data_seqr)
|
|--------> svt_cxl_channel_sequencer (dl_mem_ndr_seqr)
|
|--------> svt_cxl_channel_sequencer (dl_mem_data_seqr)
|
|--------> svt_cxl_flit_packer_sequencer
(dl_flit_packer_seqr)
|
|--------> svt_cxl_flit_sequencer (flit_seqr)
|
|--------> svt_cxl_dl_service_sequencer (dl_svc_seqr)
|
|--------> svt_cxl_dl_command_sequencer (dl_cmd_seqr)

7.4.1 Description of CXL Cache/mem Sequencers

This table lists all the CXL Cache/mem Sequencers available at Transaction Layer and Data Link Layer.
List of CXL Cache/mem Sequencers

Sequencer Class Instance Available at Description

svt_cxl_tl_req_sequencer tl_req_seqr CXL Transaction CXL.cache/mem Request

Layer sequencer

svt_cxl_tl_rsp_sequencer tl_rsp_seqr CXL Transaction CXL.cache/mem Response

Layer sequencer

svt_cxl_channel_sequencer dl_cache_req_seq CXL Data Link CXL.cache Request Channel

r Layer Sequencer for the Tx Request

svt_cxl_channel_sequencer dl_cache_rsp_seqr CXL Data Link CXL.cache Response Channel

Layer Sequencer for the Tx Response

svt_cxl_channel_sequencer dl_cache_data_se CXL Data Link CXL.cache Data Channel

qr Layer Sequencer for the Tx Data

svt_cxl_channel_sequencer dl_mem_ndr_seqr CXL Data Link CXL.mem Non-Data

Layer Request/Response Channel
Sequencer

svt_cxl_channel_sequencer dl_mem_data_seq CXL Data Link CXL.mem Data

r Layer Request/Response Channel
Sequencer

svt_cxl_flit_packer_sequencer dl_flit_packer_seqr CXL Data Link CXL Flit packer Sequencer

Layer

Feedback
118 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.mem and CXL.cache Agent

Sequencer Class Instance Available at Description

svt_cxl_flit_sequencer flit_seqr CXL Data Link CXL flit sequencer to dispatch

Layer flits to Arb/Mux from DL

svt_cxl_dl_service_sequencer dl_svc_seqr CXL Data Link Sequencer which can supply

Layer Link Service requests to the DL
driver.

svt_cxl_dl_command_sequence dl_cmd_seqr CXL Data Link CXL link command sequencer to

r Layer dispatch control information from
DL to Arb/Mux

svt_cxl_tl_service_sequencer tl_svc_seqr CXL Transaction Sequencer which can supply TL

Layer Service requests to the TL driver.
For triggering CXL Cache/mem
TL service sequence, use the
service sequencer -
svt_cxl_tl_service_sequencer
vip_seqr.cache_mem_system_s
eqr.cache_mem_virt_seqr[0].tl_s
vc_seqr

You need to choose the sequencer based on the sequence type.

For example, if you want to generate the response using this sequence -
svt_cxl_tl_cache_mem_resp_sequence then the following response sequencer must be chosen.
vip_seqr.cache_mem_system_seqr.cache_mem_virt_seqr[0].tl_rsp_seqr
If you want to use the TL Transaction sequence -to generate the traffic at Transaction layer level then the
following sequencer should be choosen.
vip_seqr.cache_mem_system_seqr.cache_mem_virt_seqr[0]
For triggering CXL Cache/mem DL service sequence, use the service sequencer -
svt_cxl_dl_service_sequencer
vip_seqr.cache_mem_system_seqr.cache_mem_virt_seqr[0].dl_svc_seqr

7.5 Sequences
Similar to Sequencers there are two types of sequences related to CXL Cache/mem available in CXL
Subsystem VIP.
Those are:
1. Transaciton Sequences
2. Service Sequences
Transaction Sequences are used to generate traffic at different layers. On the other hand, Service sequences
are used for changing the behavior of VIP.
For the description about all the CXL Cache/mem sequences available, refer to the HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/sequencepages.html

Feedback
Synopsys, Inc. 119
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

These transaction sequences are present at CXL Cache/meme Transaction Layer and Data Link Layer in the
CXL Subsystem VIP.
List of CXL.cache/mem Transaction sequences present at each layer

Sequencer Name Level Description

svt_cxl_tl_virtual_cache_mem_sequence At Transaction For generating TL Cache/Mem

Layer Request/Response/Data transfers

svt_cxl_tl_cache_mem_resp_sequence At Transaction For generating random response for cache_mem

Layer TL Host and Devices

svt_cxl_dl_virtual_cache_mem_sequence At Data Link Layer For generating all the DL Cache/Mem

Request/Response/Data transfers

Example Usage:
How do I generate Single CXL.mem request using the Transaction sequence available ?
/* CXL.Cache/mem transaction sequence to generate the CXL.cache/mem requests */
svt_cxl_tl_virtual_cache_mem_sequence tl_cache_mem_seq;
/* Put the constraints to take no. of Mem Requests with Data (i.e. Mem Write) to 1 and remaining to 0 */
`uvm_do_on_with(
tl_cache_mem_seq,
vip_seqr.cache_mem_system_seqr.cache_mem_virt_seqr[0],
{ tl_cache_mem_seq.num_mem_rwd == 1;
tl_cache_mem_seq.num_mem_req == 0;
tl_cache_mem_seq.num_cache_req == 0;});

Here vip_seqr represents the top-level virtual sequencer (svt_cxl_subsystem_sequencer) for

Note VIP. Refer to Section 3.3 for more details.

7.6 APIs
The APIs related to CXL.Cache/mem component are available in the CXL Subsystem VIP. These can be
used to create sequences (The existing sequences which are part of the example -
cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys can be referred for the usage of the APIs).
These APIs are present inside the sequence class - svt_cxl_subsystem_api_collection_sequence
For complete details on the available sequence APIs, refer to HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/sequences/class_svt_cxl_subsystem_virtual_api_collection_sequence.html
To use these APIs, you can create their own sequence class by extending from the API base sequence class
and use the APIs to activate the link and to initiate the traffic.

Feedback
120 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.mem and CXL.cache Agent

Example for using generate_cxl_tl_rand_mem_traffic() methods:

class svt_cxl_subsystem_ts_tl_mem_req_sequence extends
svt_cxl_subsystem_ts_api_base_sequence;
……….
………

virtual task body();

int unsigned host_seq_cnt; int unsigned device_seq_cnt;

`svt_note("body", "Entered ..."); super.body();

void'(svt_config_int_db#(int unsigned)::get(null, get_full_name(),
"cache_mem_link_num", cache_mem_link_num));
`svt_debug("body", $sformatf("cache_mem_link_num %0d ",cache_mem_link_num ));

void'(svt_config_int_db#(int unsigned)::get(null, get_full_name(), "num_mem_req",

num_mem_req));
`svt_debug("body", $sformatf("num_mem_req %0d ",num_mem_req ));

void'(svt_config_int_db#(int unsigned)::get(null, get_full_name(), "num_mem_rwd",

num_mem_rwd));
`svt_debug("body", $sformatf("num_mem_rwd %0d ",num_mem_rwd ));

repeat (sequence_length) begin

`svt_debug({get_name(),".body"}, $sformatf("Executing Host Sequence Count [%0d]
................", host_seq_cnt));

host_seq.generate_cxl_tl_rand_mem_traffic(.cache_mem_link_num(cache_mem_link_num),
.num_mem_req(num_mem_req), .num_mem_rwd(num_mem_rwd)); host_seq_cnt++;
end

`svt_note("body", "Exiting..."); endtask: body

Example for using generate_cxl_tl_rand_cache_mem_traffic() methods

class svt_cxl_subsystem_ts_tl_cache_req_sequence extends
svt_cxl_subsystem_ts_api_base_sequence;
……….
………

virtual task body();

int unsigned host_seq_cnt; int unsigned device_seq_cnt;
`svt_note("body", "Entered ..."); super.body();
fork
begin
repeat (sequence_length) begin
`svt_debug({get_name(),".body"}, $sformatf("Executing Host Sequence Count [%0d]
................", host_seq_cnt));

host_seq.generate_cxl_tl_rand_cache_mem_traffic(.cache_mem_link_num(0),.num_cache_req(1
), .num_mem_req(0), .num_mem_rwd(0)); host_seq_cnt++;
end end begin
repeat (sequence_length) begin

Feedback
Synopsys, Inc. 121
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

`svt_debug({get_name(),".body"}, $sformatf("Executing Device Sequence Count [%0d]

................", device_seq_cnt));

device_seq.generate_cxl_tl_rand_cache_mem_traffic(.cache_mem_link_num(0),.num_cache_req
(1), .num_mem_req(0), .num_mem_rwd(0));
device_seq_cnt++; end
end join
`svt_note("body", "Exiting..."); endtask: body
Example and Usage for using update_cxl_tl_mem_poison() method
This API is applicable for CXL.Mem and can be used for user specific poison injection/clearing at a given
Device address

virtual task body();

int unsigned host_seq_cnt;
int unsigned device_seq_cnt;
bit [(`SVT_CXL_MAX_ADDR_WIDTH-1):0] addr = 'h8000;
bit [(`SVT_CXL_MAX_DATA_WIDTH-1):0] clean_data;
`svt_note("body", "Entered ...");
clean_data ='h1234;
super.body();

fork
begin
// Guarded against the TL B2B topology
if (link_cfg.get_subsystem_comp_avlb(1,
svt_cxl_subsystem_configuration::CACHE_MEM_LL))
host_seq.activate_cache_mem_link(.link_num(cache_mem_link_num));

end
begin
// Guarded against the TL B2B topology
if (link_cfg.get_subsystem_comp_avlb(0,
svt_cxl_subsystem_configuration::CACHE_MEM_LL))
device_seq.activate_cache_mem_link(.link_num(cache_mem_link_num));
end
join
// Inject Poison at given address using TL Service Request
device_seq.update_cxl_tl_mem_poison(.cache_mem_link_num(0),
.addr(addr),.poison(1));
// Clear Poison for given address using TL Service Request
device_seq.update_cxl_tl_mem_poison(.cache_mem_link_num(0),
.addr(addr),.poison(0),.data(clean_data));
`svt_note("body", "Exiting...");
endtask: body

7.7 Auto/Default Response Sequence Support

Auto response generation from the Host and Device VIP's Cache Memory Transaction Layer is supported.
Therefore, a response sequence is set as default sequence for the Host and Device response sequencer. If you
wish to drive your own sequence as a response sequence, you can just set the respective configuration
variable, svt_cxl_cache_mem_configuration::enable_tl_user_rsp_seq variable to 1 in the test. The

Feedback
122 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL.mem and CXL.cache Agent

following code allows you to disable the default response sequence for all the Cache Memory Host and
Device response sequencers of the Transaction Layer.
virtual function void build_phase(uvm_phase phase ); string method_name =
"build_phase"; super.build_phase( phase );
for (int i = 0; i < cust_cfg.host_cfg.cache_mem_sys_cfg.num_host_agent ; i++) begin
cust_cfg.host_cfg.cache_mem_sys_cfg.host_cfg[i].enable_tl_user_rsp_seq = 1;
end
for (int i = 0; i < cust_cfg.device_cfg.cache_mem_sys_cfg.num_device_agent ; i++)
begin
cust_cfg.device_cfg.cache_mem_sys_cfg.device_cfg[i].enable_tl_user_rsp_seq = 1;
end
endfunction
After enabling this user-defined response sequence configuration, you can create your own response
sequence and use it in the test case.

7.7.1 GO-Err/GO-Err-WritePull Response

GO-Err and GO-Err-WritePull response generation from the Host VIP are supported. Host VIP sends
GO-Err response for D2H reads that targets an address, which is not accessible by the device.
For correct address range, the Host VIP sends only positive responses for D2H transactions. You can extend
the response sequence to enable GO-Err/GO-Err-WritePull response.

7.8 Backdoor Access to Memcore (Memory Core)

7.8.1 Initialize Memory Content Through Backdoor Access
The memory content can be accessed by creating the mem backdoor handle and getting the mem backdoor
instance from the sequencer in svt_cxl_agent. You can access the memory array through backdoor by
getting the svt_mem_backdoor handle for memcore.
To pre-load or dump the contents of memory core the APIs like initialize, load and dump can be used.
Follow these steps for such operations:
Step 1: Create a handle to svt_mem_core
svt_mem_core host_mem_backdoor;
Step 2: Point the back door handle to the memory core which is instantiated inside the sequencer
// For CXL Host / Device agents, cache_mem_virt_seqr[] provides pointer to the sequencer present in
the svt_cxl_agent, same used to get the backdoor handle as shown:
host_mem_backdoor =
p_sequencer.host_seqr.cache_mem_system_seqr.cache_mem_virt_seqr[cache_mem_link_num].get_
backdoor();
For more details you can refer the svt_mem_backdoor_base and svt_mem_backdoor APIs in the HTML
documentation at:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/svt_uvm_class_reference/html/clas
s_svt_mem_backdoor_base.html
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/svt_uvm_class_reference/html/clas
s_svt_mem_backdoor.html

Feedback
Synopsys, Inc. 123
 CXL.mem and CXL.cache Agent VC VIP CXL Subsystem
UVM User Guide

Look for testcase ts.cxl_tl_backdoor_mem_wr_rd.sv in the basic examples which are present at:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/examples/sverilog
The test uses the sequence which is present in the HTML documentation at:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/examples/sverilog/tb_cxl_subsystem_uv
m_basic_sys/env/seq_and_cb/svt_cxl_subsystem_ts_cache_mem_sequence_collection/svt_cxl_s
ubsystem_ts_backdoor_mem_tl_wr_rd_sequence.sv
Step 3: Perform memory content initialization/ pre-loading using the API as below:
// Different initialization patterns are allowed, refer the HTML documentation
host_mem_backdoor.initialize(svt_mem_backdoor::INIT_CONST,0,0,((1 <<
link_cfg.cache_mem_sys_cfg.host_cfg[cache_mem_link_num].addr_width)-1));

7.8.2 Accessing the Memory Content Through Backdoor Mechanisms like Peek/Poke
To access memory content using backdoor approach, follow above Step 1 and Step 2 to create the backdoor
handle to memcore. Refer the above-mentioned test and sequence for reference. Then follow this step:
Step 3: Perform memory content write followed by read operation using the peek and poke APIs as below:
// First argument is aligned logical address, second argument is data to be poked into memory
void'(host_mem_backdoor.poke(address, data));
// First argument is aligned logical address, second argument is data peeked from the memory.
void'(host_mem_backdoor.peek(address, data));

The address must be aligned wrt the data width (defined by SVT_CXL_MAX_DATA_WIDTH), and the
Note address width will be defined by SVT_CXL_MAX_ADDR_WIDTH.
To run test ts.cxl_tl_backdoor_mem_wr_rd.sv, do following:
For running with Full Stack topology, use compile_snps_vip_pcie_serial.f
gmake USE_SIMULATOR=vcsvlog cxl_tl_backdoor_mem_wr_rd
SVT_CXL_SUBSYSTEM_COMPILE_FILE=compile_snps_vip_pcie_serial.f
For running with TL+DL topology, use compile_snps_vip_cxl_cache_mem.f
gmake USE_SIMULATOR=vcsvlog cxl_tl_backdoor_mem_wr_rd
SVT_CXL_SUBSYSTEM_COMPILE_FILE=compile_snps_vip_cxl_cache_mem.f
For running with TL Only topology, use compile_snps_vip_cxl_cache_mem_tl.f
gmake USE_SIMULATOR=vcsvlog cxl_tl_backdoor_mem_wr_rd
SVT_CXL_SUBSYSTEM_COMPILE_FILE=compile_snps_vip_cxl_cache_mem_tl.f

Feedback
124 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

8
CXL ARB/MUX Agent

8.1 Overview
8.1.1 Agent Overview
ARB/MUX is needed for sharing the same Physical Layer for multiple Link Layers. On Data Path,
multiplexing is done at Flit level. Link Layers for each stack have separate credit checks before reaching
ARB/MUX. On Control Path, ARB/MUX provides abstraction and coordination with the remote side for
ACTIVE/PowerManagement transitions.
The svt_cxl_arb_mux_agent encapsulates ARB/MUX driver, sequencer and monitor. The
svt_cxl_arb_mux_agent can be configured to operate in active mode. The svt_cxl_arb_mux_agent is
configured using configuration svt_cxl_arb_mux_configuration. For transmit path,
svt_cxl_arb_mux_sequencer will receive the dispatched CXL.cache/mem flits from the DL driver. Within
the svt_cxl_arb_mux_agent, the svt_cxl_arb_mux driver gets svt_cxl_flit type sequence items from
the svt_cxl_arb_mux_agent sequencer. The driver also gets CXL.io Flits (svt_pcie_dl_packet) from PCIE
DL layer. The svt_cxl_arb_mux driver and monitor components within svt_cxl_arb_mux_agent call
callback methods at various phases of execution of CXL.cache/mem/io Flit. After the transaction on the bus
is complete, the completed sequence item is provided to the analysis port of port monitor, which can be
used by the testbench.
Virtual Link State Machine (vLSM) and ALMPs
The ARB/MUX maintains vLSM state for each CXL link layer it interfaces with - CXL.io and CXL.mem. It
receives requests from power management controller (PMC), local link layer and the remote ARB/MUX on
behalf of a remote link layer to resolve a single state request to forward to the physical layer.
The ARB/MUX uses ALMPs to communicate virtual link state transition requests and responses associated
with each link layer to the remote ARB/MUX. CXL ALMP transaction generated whenever there is ALMP
State Request or Status from Host or Device.
❖ ALMP transaction generated whenever there is L1.x, L2 request from Host or Device.
❖ ALMP transactions are generated after link-up and on successful ALMP handshake indicate
ARB_MUX is in active state and can accept packets from Data Link Layers.
❖ When link is up in cxl.io mode ALMP generation is bypassed as there is only one active link.
❖ Different vLSM states are RESET_NOP, ACTIVE, DAPM, L1_1, L1_2, L1_3, L1_4, L2, LINKRESET,
LINKERROR, RETRAIN LINKDISABLE

Feedback
Synopsys, Inc. 125
 CXL ARB/MUX Agent VC VIP CXL Subsystem
UVM User Guide

Description of the vLSM States

vLSM State Description

Reset Power-on default state

Active Normal operation state (PCIe – L0)

Retrain Link training (PCIe – Recovery)

L1.1, L1.2, L1.3, L1.4 Power savings states (PCIe – L1 substates)

SLEEP_L2 Power savings state (PCIe – L2)

LinkReset Reset propagation state (PCIe - HotReset)

LinkDisable Disabled state

LinkError Error state

DAPM Resolves to one of L1.1, L1.2, L1.3,L1.4

Figure 8-1 vLSM states for CXL.io and CXL.cache/mem

Feedback
126 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL ARB/MUX Agent

Figure 8-2 vLSM flow for L1 state transition

Link Management Packets(ALMPs)

ALMPs are 1DW packets with the format shown below. If the ARB/MUX detects an error in the ALMP,
then it initiates a retrain of the link (Recoveryflow). For data integrity protection, the 1DW packet is
replicated four times on the lower 16-bytes of a 528-bit flit
Two types of ALMPs:
Request: Initiates transitions of the remote vLSM
Status: Indicates reception of Request or used for vLSM synchronization after Retrain.

Figure 8-3 ALMP Packet Format

8.1.2 Classes and Applications for Using ARB/MUX Component

In CXL VIP, you can enable number of ARB/MUX through this define. It is done through MACRO
SVT_CXL_MAX_NUM_ARB_MUX.
Number of ARB MUX in the subsystem (svt_cxl_subsystem_configuration), rand int num_arb_mux = 0

Feedback
Synopsys, Inc. 127
 CXL ARB/MUX Agent VC VIP CXL Subsystem
UVM User Guide

Min value: 0
Max value: \`SVT_CXL_MAX_NUM_ARB_MUX (`SVT_CXL_MAX_NUM_ARB_MUX)

This parameter (num_arb_mux) is to be treated as read-only for any accesses from outside the
Note CXL subsystem configuration Writing/modifying this attributes may lead to unexpected
results from the VIP.

8.2 Configuration
Use the svt_cxl_arb_mux_configuration to define the overall behavior of the ARB/MUX component.
You must note that most configurable attributes are defined as SystemVerilog types. Consult the CXL
HTML Class Reference on declared data types.
Refer Section 3.4 for top level configuration class details. This chapter assumes the you have already
Note created the environment.

Figure 8-4 Configuration for CXL ARB/MUX Agent

For all the available configuration attributes and functions related to CXL ARB/MUX agent, refer to the
HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/configuration/class_svt_cxl_arb_mux_configuration.html

Feedback
128 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL ARB/MUX Agent

Example usage:
How to introduce the delay while sending the ALMP requests from VIP to remote IO vLSM?

svt_cxl_subsystem_link_configuration cust_cfg;
/** Configuring the CXL.Cache/mem agent **/
// Sample Format ->
//<cust_cfg>.<host_cfg/device_cfg>.arb_mux_cfg[0].<host_cfg[0]/device_cfg[0].< ARB/MUX
configuration attribute>

/*Set the confiugrations for the dealy, in ns, after which VIP will send Active State
Request ALMP to remote IO vLSM during ARB/MUX Initialization */

/*Configurations from Host VIP side*/

for (int i = 0 ; i < cust_cfg.host_cfg.cache_mem_sys_cfg.num_host_agent ; i++) begin
cust_cfg.host_cfg.arb_mux_cfg[i].io_state_req_l1_almp_delay_ns_min_val = 150;
cust_cfg.host_cfg.arb_mux_cfg[i].io_state_req_l1_almp_delay_ns_max_val = 250;
end

/*Configurations from Device VIP side*/

for (int i = 0 ; i < cust_cfg.device_cfg.cache_mem_sys_cfg.num_device_agent; i++)

begin
cust_cfg.device_cfg.arb_mux_cfg[i].io_state_req_l1_almp_delay_ns_min_val = 100;
cust_cfg.device_cfg.arb_mux_cfg[i].io_state_req_l1_almp_delay_ns_max_val = 200;
end

8.3 Status
The svt_cxl_arb_mux_status class gives the specific status information related to ARB/MUX component.

Refer Section 3.5 for top level status class details. This chapter assumes the you have already
Note created the environment.

Feedback
Synopsys, Inc. 129
 CXL ARB/MUX Agent VC VIP CXL Subsystem
UVM User Guide

Figure 8-5 Status for CXL ARB/MUX Agent

For all the available status attributes related to CXL ARB/MUX agent, refer to the HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/status/class_svt_cxl_arb_mux_status.html

Example usage:
How to wait for CXL.io vLSM to be in L1 states when creating low power scenario?
// Sample Format:
//<subsystem_status_class_obj_handle>.arb_mux_status[0].<ARB//MUX status_attribute>

/** wait for the CXL.io vLSM to be inside L1 States*/

wait (host_seq.cxl_subsystem_status.arb_mux_status[0].cxl_io_current_vlsm_fsm_state
inside {`SVT_CXL_TEST_L1_STATES});

In this example, we used the cxl_subsystem_status handle of type -

Note svt_cxl_subsystem_status present inside
svt_cxl_subsystem_virtual_api_collection_sequence (host_seq is a handle of this type)

Only the top-level status handle is user-defined. After that, the instance handle names remain fixed and
must not be changed by the user.

Feedback
130 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL ARB/MUX Agent

8.4 Sequencers
CXL ARB/MUX agent has these service sequencers present for providing information to Arb/Mux for
Arb/Mux functionality. For transmit path, svt_cxl_arb_mux_sequencer receives the dispatched
CXL.cache/mem flits from the DL driver. Within the svt_cxl_arb_mux_agent. The svt_cxl_arb_mux
driver gets svt_cxl_flit type sequence items from the svt_cxl_arb_mux_agent sequencer.

Figure 8-6 Sequencer for CXL ARB/MUX Agent

The top level sequencer of ARB/MUX are the following:

svt_cxl_arb_mux_virtual_sequencer (arb_mux_virt_seqr)
|

Feedback
Synopsys, Inc. 131
 CXL ARB/MUX Agent VC VIP CXL Subsystem
UVM User Guide

|--------> svt_cxl_arb_mux_service_sequencer (arb_mux_svc_seqr)

|--------> svt_cxl_dl_command_sequencer (dl_cmd_seqr)

|--------> svt_cxl_flit_sequencer (flit_seqr)

List of sequencers present in ARB/MUX layer are:

svt_cxl_arb_mux_virtual_sequencer This class defines a virtual sequencer that can be connected

to the svt_cxl_arb_mux_agent.

svt_cxl_arb_mux_service_sequencer This class is UVM Sequencer parameterized by

svt_cxl_arb_mux_service_transaction class object.
This service transaction sequencer is used to provide Link
Up information to Arb/Mux when PL is not present as a start
point for Arb/Mux functionality

svt_cxl_dl_command_sequencer This class is Sequencer that provides stimulus for the

svt_cxl_dl_command_driver class. The
svt_cxl_dl_command_agent class is responsible for
connecting this uvm_sequencer to the driver if the agent is
configured as UVM_ACTIVE

svt_cxl_flit_sequencer This class is Sequencer that provides stimulus for the

svt_cxl_flit_driver class. The
svt_cxl_flit_agent class is responsible for connecting
this uvm_sequencer to the driver if the agent is configured
as UVM_ACTIVE.

8.5 Sequences
List of sequences present at ARB/MUX layer:

Sequence Name Description

svt_cxl_arb_mux_service_base_sequence This sequence is the base class for CXL ARB MUX Service
sequences. All the other sequences are extended from this
sequence.

svt_cxl_arb_mux_init_sequence This sequence initiate Arb/Mux initialization through service

sequencer. This sequence shall be used only in topologies
where PCIe PL is not available.

8.6 APIs
The APIs related to CXL.ARB/MUX component are available in the CXL Subsystem VIP. These can be used
to create sequences (The existing sequences which are part of the example -
cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys can be referred for the usage of the APIs).

Feedback
132 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL ARB/MUX Agent

These APIs are present inside the sequence class:

svt_cxl_subsystem_virtual_api_collection_sequence
For complete details on the available sequence APIs, refer to HTML Class reference:
$DESIGNWARE_HOME/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html
/sequences/class_svt_cxl_subsystem_virtual_api_collection_sequence.html
Example of using generate_arb_mux_dl_cmd() methods
task generate_arb_mux_dl_cmd(int
link_num=0,svt_cxl_arb_mux_service_transaction::service_type_enumservice_type);
Method to activate DL link up of CXL.Cahe/Mem.This is a blocking method which waits till link is up and
generates dl_commands intermediately. ‘link_num’ indicates Cache Mem Link/instance to initiate traffic.
We can use this API as below.
host_seq.generate_arb_mux_dl_cmd(0,svt_cxl_arb_mux_service_transaction::LINK_RECOVERY);
#1;
host_seq.generate_arb_mux_dl_cmd(0,svt_cxl_arb_mux_service_transaction::LINK_ACTIVE);

8.7 ARB/MUX Callback svt_cxl_arb_mux_callback

ARB/MUX callback used by tests to inject ALMP error into the flits transmitted by the svt_cxl_arb_mux
driver to PL layer and also to inject PID error into the flits.
It has the following functions that can be used in error injection. We can refer to the HTML class reference
for description of these callback functions.

virtual function void post_tx_cache_mem_dl_command_seq_item_get ( svt_cxl_arb_mux driver,

svt_cxl_dl_command cxl_dl_cmd_xact, ref bit drop )

virtual function void post_tx_cache_mem_dl_flit_seq_item_get ( svt_cxl_arb_mux driver, svt_cxl_flit

cxl_flit_xact, ref bit drop )

virtual function void post_tx_io_dl_packet_seq_item_get ( svt_cxl_arb_mux driver, svt_pcie_dl_packet

pcie_dl_packet, ref bit drop )

virtual function void post_tx_io_pl_service_seq_item_get ( svt_cxl_arb_mux driver, svt_pcie_pl_service

pcie_pl_service, ref bit drop )

virtual function void pre_tx_drive_almp_data ( svt_cxl_arb_mux driver, svt_cxl_almp_transaction

almp_data )

Example:

class svt_cxl_arb_mux_almp_err_injection_cb extends svt_cxl_arb_mux_callback;

/**Specifies the almp count on which ALMP error to be injected */

int unsigned almp_err_count = $urandom_range(1,3);

/**Specifies the value of ALMP error to be injected */

int unsigned almp_err_value = $urandom_range(1,84);

Feedback
Synopsys, Inc. 133
 CXL ARB/MUX Agent VC VIP CXL Subsystem
UVM User Guide

/**Specifies the byte number on which ALMP error to be injected */

int unsigned byte_error = $urandom_range(0,9);

/**Specifies the almp byte_2 error values by corrupting rsvd fields to be injected */
int unsigned almp_byte2_error = $urandom_range(13,127);

/**Class Constructor*/
function new ( string name = "svt_cxl_arb_mux_almp_err_injection_cb");
super.new(name);
endfunction

/** Overriding pre_tx_drive_flit, a callback method of svt_cxl_arb_mux driver class*/

virtual function void pre_tx_drive_almp_data(svt_cxl_arb_mux driver,
svt_cxl_almp_transaction almp_data);
string method_name = "pre_tx_drive_almp_data";
`svt_xvm_note(method_name,$sformatf("Entered Callback Override to inject ALMP
Error"));
`svt_note("pre_tx_drive_almp_data"," extended injection class");
if (driver.common.error_injection ==1) begin
`svt_note("pre_tx_drive_almp_data", "Error injection enabled");
end

`svt_note (method_name,$sformatf("almp_err_cnt is %h",almp_err_count));

if((driver.common.error_injection==1) && (driver.common.almp_count ==
almp_err_count)) begin
case (byte_error)
'h0:
begin //ALMP byte_0 error
`svt_note(method_name,$sformatf("Value before Injecting the ALMP Error on the
BYTE0 ALMP DATA : \n %h",almp_data.almp_flit[(`SVT_CXL_ALMP_BYTE_WIDTH-1):0]));
almp_data.almp_flit[(`SVT_CXL_ALMP_BYTE_WIDTH-1):0] = $urandom_range(1,255);
`svt_note(method_name,$sformatf("ALMP after injecting the Error on BYTE0 is :
\n %h ",almp_data.almp_flit[(`SVT_CXL_ALMP_BYTE_WIDTH-1):0]));
end
endcase
end
endfunction : pre_tx_drive_almp_data
endclass : svt_cxl_arb_mux_almp_err_injection_cb

//For registering the callback in the testcase

/** Instance of CXL ARB MUX ALMP Error Injection Call back */
svt_cxl_arb_mux_almp_err_injection_cb drv_almp_err_cb;

virtual function void connect_phase(uvm_phase phase);

`uvm_info ("connect_phase", "Entered...", UVM_LOW)
super.connect_phase(phase);

for (int i = 0 ; i < `SVT_CXL_SUBSYSTEM_MAX_NUM_LINKS ; i++) begin

drv_almp_err_cb = new("drv_almp_err_cb");
svt_cxl_arb_mux_callback_pool::add(env.host_env.arb_mux[i].driver,
drv_almp_err_cb);

Feedback
134 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide CXL ARB/MUX Agent

svt_cxl_arb_mux_callback_pool::add(env.device_env.arb_mux[i].driver,
drv_almp_err_cb);
end
endfunction :connect_phase

Feedback
Synopsys, Inc. 135
 CXL ARB/MUX Agent VC VIP CXL Subsystem
UVM User Guide

Feedback
136 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

9
Logical PHY Interface

9.1 Logical PHY Interface (LPIF) Use Model

9.1.1 LPIF Usage Modes
LPIF VIP can be used in these two modes:
1. Link-LPIF: When LPIF VIP is connected to PHY DUT, it acts as Link-LPIF and drives all lp_* signals.
This mode is enabled by setting svt_cxl_subsystem_configuration:: is_phy_lpif to 0.
2. PHY-LPIF: When LPIF VIP is connected to Link DUT, it acts as PHY-LPIF and drives all pl_* signals.
This mode is enabled by setting svt_cxl_subsystem_configuration:: is_phy_lpif to 1.

9.2 Integration Steps

9.2.1 Interface
1. Instantiate svt_cxl_subsystem_if in TOP module. Refer HTML Class reference for more details:
$DESIGNWARE_HOME
/vip/svt/cxl_subsystem_svt/latest/doc/cxl_subsystem_svt_uvm_public/html/interface
s.html#intf_svt_cxl_if
2. Assign input signals to the interface(lclk ,reset ,tb_clk).
3. Pass interface for environment access through uvm_config_db.
svt_config_vif_db#(virtual svt_cxl_subsystem_if)::set(null, "*_test_top.env.host_env",
"vif", cxl_if);
svt_config_vif_db#(virtual svt_cxl_subsystem_if)::set(null, "*_test_top.env.device_env",
"vif", cxl_if);
See this topology file for more details:
<design_dir>/examples/sverilog/cxl_subsystem_svt/tb_cxl_subsystem_uvm_basic_sys/topology
_snps_vip_cxl_b2b_lpif.svi

9.2.2 Generation of LPIF Agent

You can use the following API of svt_cxl_subsystem_configuration to configure the
svt_cxl_subsystem_env for LPIF:
configure_subsystem(subsystem_topology, if_type, is_phy_lpif)

Feedback
Synopsys, Inc. 137
 Logical PHY Interface VC VIP CXL Subsystem
UVM User Guide

Attribute Supported Values

subsystem_topology Currently supported values are:

• svt_cxl_subsystem_configuration::IO_TL_DL_ONLY_STACK
• svt_cxl_subsystem_configuration ::CACHE_MEM_STACK (supported
only when subsystem bottom_layer is LINK and top_layer is
TRANSACTION.)

If_type svt_cxl_subsystem_types:LPIF_IF

is_phy_lpif 1,0
indicates whether the agent will drive the pl_* signals (1'b1) or lp_* signals
(1'b0)

9.3 LPIF Example Testbench

To run tests with LPIF, refer to the Section 4.2.3.2 Running CXL Subsystem VIP example test cases with
Topology #3 In this, you would find the valid combinations of topology and compile files to be used.

9.4 LPIF Protocol Checks

These are the LPIF specific protocol checks that are supported in the CXL subsystem VIP:

S.No Protocol Check Name Check Description

1 lp_state_req_encoding Verify that lp_state_req does not indicate any reserved encodings

2 pl_state_sts_encoding Verify that pl_state_sts does not indicate any reserved encodings

3 pl_link_cfg_value Verify that pl_lnk_cfg does not indicate any reserved encoding when
pl_state_sts=RETRAIN or ACTIVE.

4 lp_port_activity Verify that none of the lp_* signal change their values till pl_portmode_val
is asserted

5 pl_speedmode_value Verify that pl_speedmode does not indicate any reserved encoding when
pl_state_sts=RETRAIN or ACTIVE.

6 lp_exit_cg_ack_assertion_aftr_e Verify that LL asserts lp_exit_cg_ack, within user specified time, in

xit_cg_req response to pl_exit_cg_req assertion by PHY

7 pl_exit_cg_req_deassertion_bfr_ Verify that when lp_exit_cg_ack is deasserted, pl_exit_cg_req was 0. Also

exit_cg_ack verify that lp_exit_cg_ack gets deasserted, within user specififed time,
after pl_exit_cg_req gets deasserted

8 pl_exit_cg_req_val_wrt_rst_and_ Verify that once asserted while exiting LP states or reset, pl_exit_cg_req
low_pwr_state stays asserted untill LTSSM advances

9 pl_exit_cg_req_is_glitch_free Verify that once asserted, pl_exit_cg_req does not toggle till
lp_exit_cg_ack gets asserted

10 lp_stallack_deasserted_at_reset Verify that when reset is asserted, lp_stallack is deasserted

Feedback
138 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Logical PHY Interface

S.No Protocol Check Name Check Description

11 pl_stallreq_hgh_wn_stallack_de Verify that when PHY asserts pl_stallreq, lp_stallack is clear.

assrt

12 pl_state_sts_transit_frm_active_ Verify that when pl_state_sts changes from ACTIVE to any other state,
state both pl_stallreq and lp_stallack are high.

13 pm_or_cg_rmvd_for_active_stat Verify that PHY asserts pl_exit_cg_req before updating pl_state_sts to

e_entry ACTIVE

14 lpif_exit_condition_from_reset_st Verify that PL transition to the ACTIVE state upon observing lp_state_req
ate == RESET (NOP) for at least one clock while pl_state_sts is indicating
RESET; and then followed by observing lp_state_req == ACTIVE

15 stallack_low_when_stallreq_or_r Verify that when LL deasserts lp_stallack, pl_stallreq is deasserted or

eset_deassrtd reset is asserted.

16 stallack_val_wrt_lp_valid_and_lp Verify that when LL asserts lp_stallack, lp_valid and lp_irdy are both
_irdyl deasserted as well on the same lclk edge.

17 pl_portmode_val_asserted_bfr_p Verify that when PHY asserts pl_protocol_vld, pl_portmode_val was 1.

l_protocol_vld

18 stallreq_low_wn_stallack_or_res Verify that when PHY deasserts pl_stallreq, lp_stallack is high or reset is
et_assrtd asserted. Also verify that pl_stallreq deasserts, within user specified time,
after lp_stallack is asserted.

19 lpif_stallack_hgh_whn_stallreq_a Verify that when LL asserts lp_stallack, pl_stallreq is high or reset is

ssrtd asserted. Also verify that LL asserts lp_stallack, within user specified time,
after PHY asserts pl_stallreq.

20 phy_exiting_pm_state_upon_req Verify that PHY asserts pl_exit_cg_req, within user specified time, after LL
uest updates lp_state_req from PM to ACTIVE

21 initiate_exit_cg_req_to_exit_pm Verify that PHY asserts pl_exit_cg_req the pl_state_sts is updated to a

non-PM value

22 remove_cg_when_ll_init_pm_exi Verify that when pl_state_sts is L1.x and LL update on lp_state_req is

t seen, then lp_wake_req assertion must have taken place

23 lp_wake_ack_transition_wrt_lp_ Verify that pl_wake_ack is 1 only when lp_wake_req is asserted and gets
wake_req cleared when lp_wake_req has de-asserted

24 pl_wake_ack_toggled_wrtr_lclk Verify that pl_wake_ack only toggles when lclk is operational

25 transit_through_retrain_exit_frm_ Verify that pl_state_sts gets updated to RETRAIN if previous pl_state_sts

l1x_to_active was a PM state. Also verify that after RETRAIN, next state is ACTIVE.

26 stall_req_ack_handshake Verify that PHY asserts pl_stallreq, within user specified time, after LL
updates lp_state_req to a PM state.

27 trdy_val_aftr_stallreqack_comple Verify that after successful completion of Stall protocol, PHY keeps pl_trdy
tion deasserted till pl_state_sts updates to ACTIVE

Feedback
Synopsys, Inc. 139
 Logical PHY Interface VC VIP CXL Subsystem
UVM User Guide

S.No Protocol Check Name Check Description

28 pl_state_sts_updated_to_pm Verify that PHY updates pl_state_sts to the requested PM (decided after
DAPM & L1.x resolution) state, within user specified time, on successful
completion of Stall protocol.

29 pl_phyinl1_pl_phyinl2_val_in_l1_ Verify that PHY asserts pl_phyinl1 or pl_phyinl2, within user specified time,
or_l2 when lp_state_req was DAPM/L1.x or L2 respectively after successful
completion of Stall protocol.

30 l1x_pl_state_sts_val_for_dapm Verify that when LL requested DAPM, PHY updated pl_state_sts with any
of the L1.x values.

31 l1x_substate_pl_state_sts_return Verify that when LL requested L1.x, PHY updated pl_state_sts with same
ed or a lower L1.x value.

9.4.1 LPIF Protocol Check Coverage

LPIF Protocol checks generate coverage for Pass and Fail scenarios through the following attributes present
in svt_cxl_lpif_configuration class:

enable_lpif_chk_cov Attribute used to control LPIF protocol check coverage.

When set to 1'b1, it enables LPIF check coverage.

lpif_check_cov_fail_ctrl Attribute used to control LPIF FAIL protocol check coverage. When set to
1'b1, it enables LPIF FAIL check coverage.

lpif_check_cov_pass_ctrl Attribute used to control LPIF PASS protocol check coverage.

When set to 1'b1, it enables LPIF PASS check coverage.

9.5 LPIF Service Requests

These are the LPIF service requests that have been added:
1. DEASSERT_PL_TRDY: Directs PHY LPIF VIP to deassert pl_trdy signal of interface for number of
lclk edges specified by 'num_clk_edges' attribute of service class. This service call would be ignored,
if pl_trdy is low or pl_state_sts is not active.
The following VIP sequence has been added to exercise this service request:
svt_lpif_deassert_pl_trdy_sequence
2. ASSERT_PL_EXIT_CG_REQ: Directs PHY LPIF VIP to assert pl_exit_cg_req signal of interface.
This service call would be ignored, if pl_state_sts is not active or if either of pl_exit_cg_req or
lp_exit_cg_ack is 1.
The following VIP sequence has been added to exercise this service request:
svt_lpif_assert_pl_exit_cg_req_sequence.

9.6 LPIF XCHECK

To check the presence of ‘X/Z’ on LPIF interface signals, you must pass the macro SVT_ENABLE_XCHECK in
the setup.

Feedback
140 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Logical PHY Interface

9.7 LPIF Specification Version 1.1 Support

1. New signals in compliance with LPIF specification v1.1 are added to the interface in Q-2020.03-T-
20200428 release.
2. Configuration variable to enable LPIF spec version is added.

svt_cxl_lpif_configuration::lpif_ Specifies LPIF specification version number. The default

spec_ver value remains LPIF spec 1.0 when not configured.
Configuration type: Static
When set to SVT_LPIF_SPEC_VER_1_0, LPIF spec
1.0 is enabled
When set to SVT_LPIF_SPEC_VER_1_1, LPIF spec
1.1 is enabled

9.8 HVP Plans details

HVP Plan can be found at location
<DESIGNWARE_HOME_PATH>/vip/svt/cxl_subsystem_svt/latest/doc / VerificationPlans

Details of all Plans

Plan Toplevel/subplan Location

cxl_subsystem_svt_lpif_top_level_pan.hvp Toplevel VerificationPlans

cxl_subsystem_svt_link_lpif_dut_pc_subplan Subplan VerificationPlans/

.hvp protocol_check_plans/link_lpif_dut

cxl_subsystem_svt_phy_lpif_dut_pc_subpla Subplan VerificationPlans/

n.hvp protocol_check_plans/phy_lpif_dut

cxl_subsystem_svt_lpif_fc_subplan.hvp Subplan VerificationPlans/

functional_coverage_plans

Riders for using Specification Linking:

The specification used for spec linking is LPIF 1_1.The same specification must be present in parallel to
subplans to leverage spec linking. You need to add the specification document here.
Usage Details:

DUT Operation VIP Operation Plan

Either Either cxl_subsystem_svt_lpif_fc_subplan.hvp

PHY LPIF LINK LPIF cxl_subsystem_svt_link_lpif_dut_pc_subplan.hvp

LINK LPIF PHY LPIF cxl_subsystem_svt_phy_lpif_dut_pc_subplan.hvp

Feedback
Synopsys, Inc. 141
 Logical PHY Interface VC VIP CXL Subsystem
UVM User Guide

Attributes Used:

Attributes Default value Description

ENV_PATH env.device_env.cache_mem_lpif Path to AGENT ENV

AGENT_ID 0 Agent ID number

Back annotating with Verdi

a. To invoke Verdi coverage, you need to add the -cob option to the Verdi command line. You can
also specify the directory name in the command line while invoking Verdi coverage as shown
below:
> verdi -cov &
> verdi -cov -covdir <filename>.vdb &
b. In the Verdi GUI, select File > Open/Add Database to load the database.

c. Select Plan > Open Plan to load the HVP plan.

Feedback
142 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Logical PHY Interface

d. Opening the plan will automatically back annotate the coverage based on the HVP.

e. For Cache/Mem TL Protocol checks, load modifiers to filter the checks based upon Agent Type.
Click this Load modifiers icon in the Hvp window.

Select the file tl_protocol_check_coverage_filter.hvpmod from the Hvp window.

Feedback
Synopsys, Inc. 143
 Logical PHY Interface VC VIP CXL Subsystem
UVM User Guide

9.8.1 CXL Cache/Mem HVP Plans

<DESIGNWARE_HOME_PATH>/vip/svt/cxl_svt/latest/doc/VerificationPlans
Details of all plan:

Plan Top Level/ Sub plan Location

cxl_svt_checker_coverage_ Toplevel VerificationPlans/protocol

top_level_plan.hvp _check_plans

cxl_compute_express_link_ Subplan VerificationPlans/

spec_r1_1_transaction_laye protocol_check_plans
r_pc_subplan.hvp

cxl_compute_express_link_ Subplan for CXL 2.0 VerificationPlans/protocol

spec_r2_0_transaction_laye _check_plans
r_pc_subplan.hvp

Riders for using Specification Linking:

The specification used for spec linking is CXL 1.1. The same specification must be present in parallel to
subplans to leverage spec linking. You need to add the specification document here.
Attributes Used:

Attribute Description

ENV_PATH Path to AGENT ENV

AGENT_ID AGENT ID number

APPLICABLE_AGENT_TYPE The agent type for which the

protocol check is applicable

Feedback
144 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Logical PHY Interface

Modifier for CXL.Cache/Mem TL Protocol checks:

Modifier name: tl_protocol_check_coverage_filter.hvpmod
Location: VerificationPlans/ protocol_check_plans

Refer /VerificationPlans/protocol_check_plans/Readme_Protocol_Checks_Plan for further details.

Feedback
Synopsys, Inc. 145
 Logical PHY Interface VC VIP CXL Subsystem
UVM User Guide

Feedback
146 Synopsys, Inc.
 VC VIP CXL Subsystem
UVM User Guide

10
Debug Features

To ease the debugging process, Synopsys CXL Subsystem Verification IP provides you the following
logging support:
❖ CXL.cache/mem Transaction Logger
❖ CXL.io Transaction Logger
❖ CXL.io Flit Logger
❖ ARB/MUX Transaction Logger
❖ Symbol Logger
Transaction logging feature is supported for CXL IO/ Cache/ mem Protocols of CXL Subsystem SVT for
capturing the information at the following layers
❖ Transaction Layer and Data Link Layer:
At this level, VIP can capture both CXL.io transactions (TLPs, DLLPs) and CXL.Cache/mem
transactions into separate log files. Those are CXL.io Transaction Logger and CXL.cache/mem
Transaction Logger respectively.
Along with CXL.io Transaction Logger (which captures the information about TLPs and DLLPs
transmitted from and received by VIP), CXL.io Flit Logger is also supported. This log captures the
CXL.io flits handshake between CXL.io Data Link layer and ARB/MUX
❖ ARB/MUX Layer:
At this level, the transactions arrived and created at ARB/MUX will be captured into ARB/MUX
transaction log file.
❖ Flex bus Physical Layer:
At this level, VIP captures the symbols transmitted and received (with respect to VIP) on the lanes
into a separate log file.

By default, no transaction log file is generated (all the transaction log files generation is disabled by
Note default). To enable all the transaction log files generation, use the following command line option.
CXL Subsystem VIP specific command line option:
SVT_CXL_SUBSYSTEM_ENABLE_LOGGING=1

Or

Feedback
Synopsys, Inc. 147
 Debug Features VC VIP CXL Subsystem
UVM User Guide

Configurations available for enabling individual log file generation can also be used.

10.1 CXL.cache/mem Transaction Logger

10.1.1 Printing CXL.cache/mem Transaction Data into Log file
Transaction Layer trace creates log files of CXL Cache/mem transactions. Logging enabling attribute would
be svt_cxl_cache_mem_configuration::enable_transaction_logging.
Example code present in the test to enable the transaction logging for the HOST through configuration is
shown here:
for (int i = 0 ; i < cust_cfg.host_cfg.cache_mem_sys_cfg.num_cache_mem_agent; i++)
begin
cust_cfg.host_cfg.cache_mem_sys_cfg.cache_mem_cfg[i].enable_transaction_logging =
1;
end
By default, the log gets generated / saved with file name as mentioned below
<test_name>_<host/device_components_instance_number>_cm_<host/device> appended with .
xact_log.
For example, if the test - cxl_tl_random_mem_wr_rd is ran then the CXL.cache/mem transaction log file
will gets generated with the following file name:
cxl_tl_random_mem_wr_rd_0_cm_device.xact_log (if VIP is Device)
cxl_tl_random_mem_wr_rd_0_cm_host.xact_log (if VIP is Host)

If you want to print the transaction log with user-defined name, add it as:
for (int i = 0 ; i < cust_cfg.host_cfg.cache_mem_sys_cfg.num_cache_mem_agent; i++)
begin
cust_cfg.host_cfg.cache_mem_sys_cfg.cache_mem_cfg[i].transaction_log_filename=
"debug_log";
end

If different components are programmed to generate the transaction log with same name then a
Note combined transaction log will be generated.

10.1.2 Fields of the CXL.cache/mem Transaction Log Header

The fields of CXL.Cache/mem Transaction log header are described in this section. These fields are listed
from left to right as they appear on the header.
Sample header:

Reporter Start End D Type Obj T Tag/ Addres Respon Meta Meta Snp RSP Rsp N Data
Time Time I Num C ID s se / Field Value Type pre data T [Hex
(ns) (ns) R [Hex] Opcod ]
e

Feedback
148 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

Field: Reporter
Description:
This field represents an instance of the VIP in the test environment. The transaction log information is
reported for this VIP instance.

Field: Start Time (ns)

Description:
This field represents the simulation time in "ns" when the transaction is started.

Field: Start Time (ns)

Description:
This field represents the simulation time in "ns" when the transaction is ended.

Field: DIR
Description:
This field represents the direction of the transaction, based on the source and destination components

Field: Type
Description:
This field represents the Request Transaction type

Field: Obj Num

Description:
This field represents the Object Number which is a unique number being assigned by VIP to each
transaction, N/A for channel transaction

Field: TC
Description:
This field represents the Traffic Class of the Request

Field: Tag / ID
Description:
This field represents the Tag for the mem transactions and ID for the cache transaction

Field: Address
Description:

Feedback
Synopsys, Inc. 149
 Debug Features VC VIP CXL Subsystem
UVM User Guide

Address of transaction
Field: Response/ Opcode
Description:
Response type for cxl_transaction, Request / response Opcode for the cxl_channel_transaction

Field: Meta Field

Description:
Meta Field, applicable only for Mem transaction

Field: Meta Value

Description:
Meta Value, applicable only for Mem transaction

Field: Snp Typ

Description:
Snoop type associated with the transaction

Field: Rsp pre

Description:
Rsp pre field of response

Field: Rsp Data

Description:
Rsp Data field of transaction

Field: NT
Description:
Non-Temporal type of transaction

Field: DATA
Description:
Data involved with the data transfer
DATA print:
Print of DATA in the log will be in 4 double word format(2 MSB, 2 LSB are picked).

Feedback
150 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

10.2 CXL.io Transaction Logger

All the CXL.io traffic (inbound or outbound transactions) to and from CXL Subsystem VIP are sent to the
CXL.io Transaction Logger. These transactions are distilled and written (one transaction per line) to the
transaction log file.
By default, the transaction logger is disabled. To enable it, and cause it to start writing transactions to a file,
use the enable_transaction_logging member of the svt_pcie_configuration class. The transaction
log filename can also be mentioned.

10.2.1 Printing CXL.io Transaction Data into Log File

In the following code, it is shown how to print TLP payload data to the Transaction log.
You must first enable transaction logging. By default, it is off. Also, set the filename of the transaction log.
for (int i = 0 ; i < cust_cfg.host_cfg.num_cxl_io ; i++) begin
cust_cfg.host_cfg.cxl_io_cfg[i].pcie_cfg.enable_transaction_logging = 1'b1;
cust_cfg.host_cfg.cxl_io_cfg[i].pcie_cfg.transaction_log_filename =
"cxl_io_transaction.log");
end
Next, set how many dwords of the payload you want the model to write into the transaction log file.
/** Set the payload display limit */
svt_pcie_dl_disp_pattern::default_max_payload_print_dwords = 1024;
Note the default is zero. In the example, it has been set to 1024.

10.2.2 Fields of the Transaction Log Header

The fields of the transaction log header are described in this section. These fields are listed from left to right
as they appear on the header.
Field: Reporter
Description:
This field represents an instance of the VIP in the test environment. The transaction log information is
reported for this VIP instance.

Field: Start Time (ns)

Description:
This field represents the simulation time in ns when the transaction starts.

Field: End Time (ns)

Description:
This field represents the simulation time in ns when the transaction ends.

Field: Dir
Description:
This field represents the direction of the transaction from the VIP instance. "T" represents a transmit

Feedback
Synopsys, Inc. 151
 Debug Features VC VIP CXL Subsystem
UVM User Guide

transaction. "R" represents a receive transaction.

Field: TLP Type/DLLP Type

Description:
This field represents the type of TLP (Transaction Layer Packet) or DLLP (Data Link Layer Packet) as
defined in Table 2-3 and Table 3-1 of the PCIe Specification respectively. For TLP memory read (MRd) and
memory write (MWr) packets, a "32" or "64" is appended to the type. This number represents a 32-bit or 64-
bit memory addressing.
For example:
MRd32
MWr64

Field: R_ID /Tag | ST

Description:
This field has 2 different representations for a TLP transaction. The Requester ID and Tag are displayed, or
the Steering Tag is displayed. This field is blank for DLLP transactions.

Field: Seq Num

Description:
This field represents the sequence number of the transaction.

Field: TC VC
Description:
This field represents the value of the Traffic Class field of the TLP.

Field: TH
Description:
This field represents the 1-bit TH field of the common TLP packet header. The TH field is an indication of
the TLP Processing Hints (TPH) and the Optional TPH TLP Prefix when applicable presented in the TLP
header.

Field: PH
Description:
This field represents processing hint.

Field: IDO RO
Description:
These 2 fields represent the Ordering Attribute Bits as defined in Table 2-10 of the PCIe Specification.

Feedback
152 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

The table is shown below:

Attribute Bit [2] Attribute Bit[1]

(IDO) (RO) Ordering Type Ordering Model

0 0 Default Ordering PCI Strongly Ordered

Model

0 1 Relaxed Ordering PCI-X Relaxed

Ordering Model

1 0 ID-based Ordering Independent ordering

based on
Requester/Completer
ID

1 1 Relaxed Ordering plus ID- Logical "OR" of

Based Ordering Relaxed Ordering and
IDO

Field: NS
Description:
This field represents the No Snoop bit value of the TLP.

Field: Address
Reg#/MsgRt/Cpl
HdrFC DataFC
Description:
This field has multiple representations. For a TLP transaction, the value(s) displayed depends on the TLP
type as shown in the following table. For a DLLP transaction, the Flow Control header and data are
displayed.

TLP Field Description

<address> Memory Request:

This field presents the memory

<address> IO request:
This field represents the IO address

Feedback
Synopsys, Inc. 153
 Debug Features VC VIP CXL Subsystem
UVM User Guide

TLP Field Description

BDF: <> R: <> Configuration request:

or "BDF" represents the bus device function
BDF:<> O: <> "R" represents the register number
"O" represents the register byte offset. This offset is not displayed by default.
To enable the display, you must set the dl_trace_options[1] attribute of the
PCIe configuration class (svt_pcie_configuration).
For example:
<agent_cfg>.pcie_cfg.dl_trace_options[1]=1

<message> Message request:

This field represents the message routing as defined in Table 2-18 of the
PCIe Specification.

ID: <> Stat: <> Completion request:

"ID" represents the Completion ID.
"Stat" represents the Completion status as defined in Table 2-29 of the PCIe
Specification. The status are SC, UR, CRS and CA.

DLLP Field Description

<header> <data> Flow Control header and data

Field: BE | ST
BC
MCode
Description:
This field has multiple representations of a TLP transaction.

TLP Field Description

<byte enable> Memory request/IO request/ Configuration request:

This field represents the byte enable.

<steering tag> Memory request:

When the TH field has a value of "1", this field represents the steering tag
value

BC: < > Completion request:

BC represents the byte count

<message code> Message request:

This field represents the message code as define in Table F-1 of the PCIe
Specification

Feedback
154 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

Field: Len/Idx DW
Description:
This field has 2 representations of a TLP transaction.

TLP Field Description

<payload length> For the TLP Header displayed on the first row of data, this field represents the
length of the payload in double word (DW)

<data index> For the TLP payload displayed from the second row of data and on, this field
represents the accumulative count of DW data

Field: Prefix / Header / Data

(All values in Hex)
Description:
This field represents the raw dword values of a TLP transaction.
❖ Values with an "(H)" prefix represent header DWORDs.
❖ Values with a "(P)" prefix represent the PCIe Prefix DWORDS.
❖ When the model is configured to show transaction data, values with a "(D)" prefix represent payload
DWORDS.
By default, only the TLP header data is displayed along with the header fields. You can enable the
display of payload data by using one of the following methods:
a. In the build phase of the simulation, set the static attribute
default_max_payload_print_dwords of class svt_pcie_dl_disp_pattern to the default
maximum number of payload DWORDs to be displayed.
b. Set the SVT_PCIE_XACT_LOG_MAX_PAYLOAD_DWORDS_DEFAULT macro to the default maximum
number of payload DWORDs to be displayed.
Payload data for CfgWr and CfgRd (corresponding CplD) are displayed with a single DWORD. By default,
this DWORD value is displayed in the Big Endian format. Alternatively, you can enable the DWORD to be
displayed in the Little Endian format by setting the "dl_trace_options[0]" attribute of the PCIe configuration
class (svt_pcie_configuration).
For example:
Default Big Endian payload data
0 06001000
Enable Little Endian format
<agent cfg>.pcie_cfg.dl_trace_options[0] = 1;
Little Endian payload data
0 00100006 LittleEndian
Field: EP
Description:
This field represents the poison bit as defined in the PCIe Specification.

Feedback
Synopsys, Inc. 155
 Debug Features VC VIP CXL Subsystem
UVM User Guide

Field: ECRC
Description:
This field represents the ECRC value of a TLP as defined in the PCIe Specification.

Field: LCRC
CRC
Description:
This field has 2 representations. For a TLP transaction, the LCRC value as defined in the PCIe
Specification is displayed. For a DLLP transaction, the CRC value as defined in the PCIe
Specification is displayed.
Field: TX/RX Error
Description:
This field represents the type of error injection when error injection is enabled in a transmit (tx)
transaction. For a receive (rx) transaction, this field represents the detected error.

Error Injection Type Description

BadSeq Illegal Sequence Number

CodeViol TX code Violation

CrcEr CRC Error

Disparity Disparity Error

DupSeq Duplicate Sequence Number

EIErr Scenario injects error, then VIP reported this

HdrCRC PCIE 8G Header CRC Error

HdrPAR PCIE 8G Header Parity Error

LCRC LCRC Error

NAK NAK Received for TLP

NoACK Missing ACK for Transaction

NoEND Missing END

NoSTART Missing START

NoSTP NoSTART Missing START

NullLCRC Nullified TLP with corrupt CRC

NullTLP Nullified TLP

ReplCnt Replay count of 4 exceeded

Feedback
156 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

10.3 CXL.io Flit Logger

10.3.1 Printing CXL.io Flit handshaking into Log File
Logging of CXL.io Data Flit transmission and reception is possible by configuring the CXL Subsystem VIP
like below.
❖ Enable the CXL.io Flit mode
❖ Enable the CXL.io Flit logging
Example usage:
<cust_cfg>.host_cfg.cxl_io_cfg[0].pcie_cfg.dl_cfg.enable_cxl_io_flit_mode = 1'b1;
<cust_cfg>.host_cfg.cxl_io_cfg[0].pcie_cfg.enable_cxl_io_flit_logging = 1'b1;

10.3.2 Fields of the CXL.io Flit Log Header

Sample Header

Time TX/RX Flit Data

The fields of the CXL.io flit log header are described in this section. These fields are listed from left to right
as they appear on the header.

Field: Time
Description: This field represents the simulation time in ns when the transaction starts

Field: TX/RX
Description: This field represents the direction of the Flit. It will specify whether the flit is transmitted or
received with respect to VIP.

Field: Flit Data

Description: This field represents the 64 byte Flit Data.

10.4 ARB/MUX Transaction Logger

VIP captures all the transactions from DL/PHY to ARB/MUX and from ARB/MUX to DL/PHY into the
ARB/MUX Transaction Log file.
The transactions transmitted or received from Data Link layer and Physical layer are differentiated by
specifying the direction field as 'DL_IO/DL_CM' and 'PHY' respectively.

10.4.1 Printing Mem Transaction Data into Transaction Log File

ARB/Mux Layer trace creates log files of CXL IO/Cache/mem input transactions coming from DL/PHY
layer. Logging enabling attribute would be:
svt_cxl_arb_mux_configuration::enable_transaction_logging.

Example code present in the test to enable the transaction logging for the HOST is shown here:

Feedback
Synopsys, Inc. 157
 Debug Features VC VIP CXL Subsystem
UVM User Guide

if(cust_cfg.host_cfg.num_arb_mux != 0) begin
for (int i = 0 ; i < cust_cfg.host_cfg.num_arb_mux; i++) begin
cust_cfg.host_cfg.arb_mux_cfg[i].enable_transaction_logging = 1;
end
end
By default, the log gets generated/ saved with Hierarchy of the component appended with. xact_log.
Example:
uvm_test_top.env.device_env.arb_mux[0].driver.xact_log
uvm_test_top.env.host_env.arb_mux[0].driver.xact_log

If you want to print the transaction log with user-defined name, add it as:
if(cust_cfg.host_cfg.num_arb_mux != 0) begin
for (int i = 0 ; i < cust_cfg.host_cfg.num_arb_mux; i++) begin
cust_cfg.host_cfg.arb_mux_cfg[i].transaction_log_filename = "debug_log";
end
end

10.4.2 Fields of the ARB/MUX Transaction Log Header

Sample Header:

Flit/
DLLP
SubT
ype
TLP
Type
R_ID
Requ Flit _Tag/
est Type ST | | |Phy | | | |
(IO/ IO VLSM Slot |llr |
CM/ DLLP/ Req/ Credit For |E- |Re-|Re- |Em-
ALM TLP/ Sts Return mat |Vi-|Wr-
Event Flit VSLM P) VLSM State Count S0 |Free|Wrap|
Reporter Time Dir Type [Prv Req/S [Req | S1 A |Seq|try|Init|pty|ra
[Curr
(ns) (Tx/ (IO/ VLS ts Data | S2 C BE SZ CRC l| Ptr|Buf |Val |
VLSM
Rx) CM) M] ====> ] Rsp] S3 K

Field: Reporter
Description:
This field represents the VIP component (HOST/DEVICE) with respect to which the Transactions received
or transmitted are mentioned

Field: Event time (ns)

Description:

Feedback
158 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

This field represents the time when ARB Mux is observing the event

Field: Flit Dir (Tx/Rx)

Description:
This filed represents the Flit/ALMP Transaction Direction (Tx/Rx) from VIP perspective.
Tx(DL_IO): Outbound Flit from IO DL to ArbMux ,
Tx(DL_CM): Outbound Flit from CM DL to ArbMux,
Tx(PHY): Outbound Flit/ALMP from ArbMux to PHY,
Rx(PHY): Inbound Flit/ALMP from PHY to ArbMux
Rx(DL_CM): Inbound Flit from ArbMux to CM DL

Field: VLSM Type (IO/CM)

Description:
This filed represents which VLSM detected Transaction. i.e IO or CM

Field: Request (IO/CM/ALMP) / [Prv VLSM ]

Description:
This field has 2 representations.
Request(IO/CM/ALMP) - Indicates type of request IO/CM/ALMP_IO/ALMP_CM .
[Prv VLSM ] - Represents Previous IO/CM VLSM State on VLSM State Transition.

Field: Flit Type / IO DLLP/TLP / VLSM Req/Sts

Description:
This field has 3 representations.
Flit Type - Indicates CM Flit type ADF (All Data Flit) or NON_ADF
IO DLLP/TLP - Indicates type of IO packet (DLLP/TLP).
VLSM Req/Sts - Indicates ALMP Type VLSM request or status
Field: Flit/ DLLP SubType / TLP Type R_ID_Tag/ST / VLSM Req/Sts State / [Curr VLSM]
Description:
This field has 4 representations.
Flit/DLLP SubType - Indicates CM flit type(RETRY/INIT/LLCRD..etc) and DLLP packet type
(ACK/INITFC2_P_VC/INITFC1_CPL/UPDATEFC_NP_VC..etc)
TLP Type R_ID_Tag/ST - Indicates TLP Type (MWr32/MRd32/MWr64/MRd64/CplD ..etc)
VLSM Req/Sts State - Indicates VLSM State for requested ALMP request or status.
[Curr VLSM] - Represents Currents IO/CM VLSM State on VLSM State Transition.

Feedback
Synopsys, Inc. 159
 Debug Features VC VIP CXL Subsystem
UVM User Guide

Field: Credit Return Count [Req | Data | Rsp]

Description:
In case of Control Flit, this field represents the Credit return count for Req, Data and Rsp.
C - indicates Cache Credit information and M - indicates Mem Credit information

Field: Slot Format S0 S1 S2 S3

Description: This field represents the flit slot format.

Field: ACK
Description: This field indicates an acknowledgment of 8 successful flit transfers

Field: BE
Description:This field represents the Byte Enable field of the flit header

Field: SZ
Description:This Size field reflects the transmission of data at the half cache line granularity

Field: CRC
Description:This field represents CRC of the flit

Field: E-Seq | Retry | Phy-Reinit | Empty | Viral | WrPtr | FreeBuf | llrWrapVal

Description:
This field has multiple representations of the transaction.
E-Seq - Indicates the requester's retry sequence number
Retry - Indicates the local NUM_RETRY LLR variable.
Phy-Reinit - Indicates the NUM_PHY_REINIT LLR variable.
Empty - Indicates that the LLR contains no valid data.
Viral - Indicates that the
transmitting agent is in a Viral state
WrPtr - Indicates WrPtr value of the retry queue.
FreeBuf - Indicates free LLRB entries.
llrWrapVal - Indicates the expected sequence number for Control Flit.

Feedback
160 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

The Flit details are printed when flit is received from IO/CM DL. When Stream is received from PHY
Note layer, only flit type IO/CM is printed.

10.5 Symbol Logger

10.5.1 Printing Transmitted and Received symbols into Symbol Log File
One log file is created for each simulation. All agents share the log file. Each agent must be enabled
independently as shown in this example. If more than one symbol_log_filename is set, then the last one
set within the simulation serves as the filename. It is recommended that you have only one agent set the
filename.
Example:
for (int i = 0 ; i < cust_cfg.host_cfg.num_cxl_io ; i++) begin
/** Enable Symbol logging */
cust_cfg.host_cfg.cxl_io_cfg[i].pcie_cfg.enable_symbol_logging = 1'b1;
cust_cfg.host_cfg.cxl_io_cfg[i].pcie_cfg.symbol_log_filename ="symbol.log"; //
Recommended to only set the filename once
end

The symbol log filename is appended to the full hierarchical name of the port0 instance
Note generating it.

10.5.2 Fields of the Symbol Log Header

The fields of the symbol log header are described in this section. These fields are listed from left to right as
they appear on the header. Note that the Symbol logging is performed at the PIPE interface. If the PIPE
interface is configured as multiple bytes, all bytes transferred at a time step are logged at the same time step.
Field: TIME
Description: This field represents the simulation time in ns.

Field: INSTANCE
Description: This field represents an instance of the VIP in the test environment. The symbol log
information is reported for this VIP instance.
Field: < lane symbols >
Description: This field represents symbols on the active lane(s). The format of the field header is:
[R00] [R01] [R02] … [R<n>] | [T00] [T01] [T02] … [T<n>] Where, "R" represents the receive symbol on the
lane. "T" represents the transmit symbol on the lane.
<n> is the number of the highest configured lane.
The encodings of the lane symbols are listed in the following tables.
Field: LTSSM State

Feedback
Synopsys, Inc. 161
 Debug Features VC VIP CXL Subsystem
UVM User Guide

Description: This field represents the state of the LTSSM state machine as defined in section 4.2.5 of the
PCIe specification. For states such as L0 and L0s where the receive (rx) and transmit (tx) LTSSM states may
diverge, the rx and tx states are displayed separately. Otherwise, only a single state is displayed for both rx
and tx states.

10.5.3 Special Encodings

Special Symbol Encodings for All Link Data Rates

Symbol Description

z Electrical Idle

? Invalid or unknown value

. No information available to log. This may occur at startup, at changes to link

speed or link width, or if the Rx and Tx sides are operating at offset time steps
at either 2.5GT/s or 5 GT/s

q Error injection pending: appended on each symbol that will have disparity
inverted. Only applies on Tx lanes

j Error injection pending: appended on each symbol that will have a random bit
flipped. Only applies on TX lanes.

v Error injection pending: appended on each symbol that will have an invalid
encoding. Only applies on TX lanes.

For link operation at 8GT/s, symbols after the sync headers are prepended with encodings of the sync
headers listed in this table.
Sync Header Encodings for Link Operation at 8GT/s

Symbol Description

@ 2'b'00 (Reserved)

* 2'b'01 (OS block)

= 2'b'10 (Data block)

$ 2'b'11 (Reserved)

Additional encodings for link operation at 8GT/s are listed in this table.
Special Character Encodings for Link Operation at 8GT/s

Symbol Description

:: Data skip cycle (no valid data)

+ Start of TLP Token. Prepended on 1st symbol of token. Replaces = symbol at

start of block. Only noted on TX lanes.

^ Start of DLLP Token. Prepended on 1st symbol of token.

Replaces = symbol at start of block. Only noted on TX lanes.

Feedback
162 Synopsys, Inc.
VC VIP CXL Subsystem
UVM User Guide Debug Features

Symbol Description

} End of packet. Appended on last symbol of a tlp or dllp. Only noted on TX

lanes

Q Error injection pending on last symbol of a tlp or dllp: appended if last symbol
has disparity inverted. Only applies on TX lanes.

J Error injection pending on last symbol of a tlp or dllp: appended if last symbol
has a random bit flipped. Only applies on TX lanes.

V Error injection pending on last symbol of a tlp or dllp: appended if last symbol
has an invalid encoding. Only applies on TX lanes.

10.5.4 Special Messages

Configuration Messages in the Symbol Log
In addition to lane symbols, messages that indicate link changes are displayed in the symbol log. These
messages are prepended by "--".
For example:
spd_0 -- Detected change in link width from 1 to 4.
spd_0 -- Detected change in data rate to 32 Gt/s. TX Precoding: Off, RX Precoding: Off. See file header for
special encodings.
Symbol Log with OS Information
The current symbol log format has been enhanced to include OS information. This enhanced format is
enabled by setting the configuration attribute
svt_pcie_configuration::enable_enhanced_symbol_log_format to 1. When the enhanced format is
enabled, the symbol log will also contain information about when and what OS are terminated on
individual lanes. The default value of enable_enhanced_symbol_log_format is 0. For most operating
systems this would be on the last symbol of the OS, but for some operating systems that have indeterminate
length like SKP OS the completion information would be associated with the COM/sync header of the next
OS/data block.

10.5.5 Synchronization of Simulation Time Between Transaction Log and Symbol Log
Transaction logging times represent times at the periphery of the VIP. Symbol logging times are captured at
the PIPE interface, which may be internal or external to the VIP depending on the interface type. For Serial
and PMA interface, there is no correlation between the time displayed in the transaction log and the symbol
log. Due to delay through the PHY layer, symbols are logged at a different time than the transaction log for
the same packet.
For PIPE interface, the simulation time displayed in the transaction log and symbol log are synchronized for
the same packet. The ‘Start Time’ of the transaction log corresponds to the time of a transaction with the
"STP" or "SDP" symbol in the symbol log. The ‘End Time’ of the transaction log corresponds to the time of a
transaction with the ‘END’ symbol in the symbol log.

Transaction Log Symbol Log

Start Time (ns) TIME with ‘STP’ or ‘SDP’ symbol

End Time (ns) TIME with ‘END’ symbol

Feedback
Synopsys, Inc. 163
 Debug Features VC VIP CXL Subsystem
UVM User Guide

Feedback
164 Synopsys, Inc.