SoC Designer CDP v4.1 HDL Cosimulation Guideinfocenter.arm.com/help/...soc_designer_cdp_v41_hdl_cosimulation_g… · SoC Designer CDP v4.1 HDL Cosimulation Guide Preface About this

SoC DesignerVersion 9.1

CDP v4.1 HDL Cosimulation Guide

Copyright © 2017 ARM Limited or its affiliates. All rights reserved.ARM DUI1078A

SoC DesignerCDP v4.1 HDL Cosimulation GuideCopyright © 2017 ARM Limited or its affiliates. All rights reserved.

Release Information

Document History

Issue Date Confidentiality Change

A 24 February 2017 Non-Confidential First release.

Non-Confidential Proprietary Notice

This document is protected by copyright and other related rights and the practice or implementation of the information contained inthis document may be protected by one or more patents or pending patent applications. No part of this document may bereproduced in any form by any means without the express prior written permission of ARM. No license, express or implied, byestoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.

Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to usethe information for the purposes of determining whether implementations infringe any third party patents.

THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES,EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OFMERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSEWITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, ARM makes no representation with respect to, and hasundertaken no analysis to identify or understand the scope and content of, third party patents, copyrights, trade secrets, or otherrights.

This document may include technical inaccuracies or typographical errors.

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES,INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, ORCONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISINGOUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCHDAMAGES.

This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or disclosure ofthis document complies fully with any relevant export laws and regulations to assure that this document or any portion thereof isnot exported, directly or indirectly, in violation of such export laws. Use of the word “partner” in reference to ARM’s customers isnot intended to create or refer to any partnership relationship with any other company. ARM may make changes to this document atany time and without notice.

If any of the provisions contained in these terms conflict with any of the provisions of any signed written agreement covering thisdocument with ARM, then the signed written agreement prevails over and supersedes the conflicting provisions of these terms.This document may be translated into other languages for convenience, and you agree that if there is any conflict between theEnglish version of this document and any translation, the terms of the English version of the Agreement shall prevail.

Words and logos marked with ® or ™ are registered trademarks or trademarks of ARM Limited or its affiliates in the EU and/orelsewhere. All rights reserved. Other brands and names mentioned in this document may be the trademarks of their respectiveowners. Please follow ARM’s trademark usage guidelines at http://www.arm.com/about/trademark-usage-guidelines.php

Copyright © 2017, ARM Limited or its affiliates. All rights reserved.

ARM Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.

LES-PRE-20349

Confidentiality Status

This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license restrictions inaccordance with the terms of the agreement entered into by ARM and the party that ARM delivered this document to.

Unrestricted Access is an ARM internal classification.

SoC Designer

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. 2Non-Confidential

http://www.arm.com/about/trademark-usage-guidelines.php

Product Status

The information in this document is Final, that is for a developed product.

Web Address

http://www.arm.com

SoC Designer


http://www.arm.com

ContentsSoC Designer CDP v4.1 HDL Cosimulation Guide

PrefaceAbout this book ...................................................... ...................................................... 7Feedback .................................................................................................................... 10

Chapter 1 Introduction1.1 About the SoC Designer CoDesign Package .......................................................... 1-12

Chapter 2 Installing and Configuring Cosimulation Software2.1 CDP Licensing .................................................... .................................................... 2-142.2 CoDesign Package components ...................................... ...................................... 2-152.3 Minimum Requirements ............................................. ............................................. 2-162.4 Preparing for Cosimulation ...................................................................................... 2-172.5 Preparing for Cosimulation with ModelSim and Verilog ..................... ..................... 2-212.6 Preparing for Cosimulation with NCSim and Verilog ....................... ....................... 2-232.7 Preparing for Cosimulation with VCS with Verilog ......................... ......................... 2-252.8 Starting SoC Designer Cosimulation ................................... ................................... 2-272.9 Restarting Cosimulation ............................................. ............................................. 2-312.10 Interaction between SoC Designer Simulator and an HDL simulator ...................... 2-33

Chapter 3 CDP HDL Cosimulation Reference3.1 Configuring CDP ...................................................................................................... 3-353.2 Generated files for Cosimulation ...................................... ...................................... 3-393.3 CDP synchronization model .......................................... .......................................... 3-423.4 Combinatorial signals ............................................... ............................................... 3-43


3.5 Modifying RTL memory codes for debug support .................................................... 3-443.6 Configuring endianness ............................................. ............................................. 3-463.7 Controlling Cosimulation through environment variables .................... .................... 3-473.8 Creating a new transactor ........................................... ........................................... 3-483.9 Direct HDL signal linking ............................................ ............................................ 3-50

Appendix A AMBA® 3 AXI4 TransactorsA.1 About the AXI4 transactors ............................................................................ Appx-A-52A.2 Component port interfaces ...................................... ...................................... Appx-A-53A.3 Model parameters .......................................................................................... Appx-A-54A.4 Supported signal bit widths ............................................................................ Appx-A-55A.5 RTL memory debug support .......................................................................... Appx-A-58

Appendix B AMBA® 3 AXIv2 TransactorsB.1 About the AXIv2 transactors .......................................................................... Appx-B-60B.2 Component port interfaces ...................................... ...................................... Appx-B-61B.3 Model parameters .......................................................................................... Appx-B-62B.4 Supported signal bit widths ............................................................................ Appx-B-63B.5 RTL memory debug support .......................................................................... Appx-B-65

Appendix C AMBA® 2 AHBv2 TransactorsC.1 About the AHBv2 transactors .................................... .................................... Appx-C-67C.2 AHBv2M_T2S transactor features ................................ ................................ Appx-C-69C.3 AHBv2M_S2T transactor features ................................ ................................ Appx-C-71C.4 AHBv2S_T2S transactor features ................................ ................................ Appx-C-73C.5 AHBv2S_S2T transactor features ................................ ................................ Appx-C-75C.6 Debugging features ........................................... ........................................... Appx-C-77C.7 Supported signal bit widths ............................................................................ Appx-C-78

Appendix D AMBA® APB TransactorsD.1 About the APB transactors ...................................... ...................................... Appx-D-80D.2 Component port interfaces ...................................... ...................................... Appx-D-81D.3 Model parameters .......................................................................................... Appx-D-83D.4 Debugging features ........................................... ........................................... Appx-D-84

Appendix E Converting CDP 3.0 test bench files to CDP 4.0 test bench filesE.1 Upgrading to CDP 4.0 .................................................................................... Appx-E-86

Appendix F TroubleshootingF.1 Troubleshooting situations ...................................... ...................................... Appx-F-88


Preface

This preface introduces the SoC Designer CDP v4.1 HDL Cosimulation Guide.

It contains the following:• About this book on page 7.• Feedback on page 10.


About this bookThis book describes how to use the SoC Designer CoDesign Package to provide a Cosimulationenvironment that combines RTL designs and cycle-accurate software models.

Product revision status

The rmpn identifier indicates the revision status of the product described in this book, for example, r1p2,where:

rm Identifies the major revision of the product, for example, r1.pn Identifies the minor revision or modification status of the product, for example, p2.

Intended audience

This book is written for engineers who use SoC Designer together with RTL simulators. It assumes theyhave experience creating and using SoC Designer or SystemC models.

Using this book

This book is organized into the following chapters:

Chapter 1 IntroductionThis chapter describes Cosimulation and transactors.

Chapter 2 Installing and Configuring Cosimulation SoftwareThis chapter describes the installation and configuration of SoC Designer CoDesign Cosimulationsoftware.

Chapter 3 CDP HDL Cosimulation ReferenceThis chapter provides reference information for the SoC Designer CoDesign PackageCosimulation software.

Appendix A AMBA® 3 AXI4 TransactorsThis appendix describes the AXI4 Cosimulation transactor models.

Appendix B AMBA® 3 AXIv2 TransactorsThis appendix describes the AXIv2 Cosimulation transactor models.

Appendix C AMBA® 2 AHBv2 TransactorsThis appendix describes the AHBv2 HDL Cosimulation transactor models.

Appendix D AMBA® APB TransactorsThe appendix describes the APB HDL Cosimulation models.

Appendix E Converting CDP 3.0 test bench files to CDP 4.0 test bench filesThis appendix describes information that applies only to systems running CDP 3.0.

Appendix F TroubleshootingThis appendix provides information about Cosimulation functionality and troubleshootingscenarios.

Glossary

The ARM Glossary is a list of terms used in ARM documentation, together with definitions for thoseterms. The ARM Glossary does not contain terms that are industry standard unless the ARM meaningdiffers from the generally accepted meaning.

See the ARM Glossary for more information.

Typographic conventions

italicIntroduces special terminology, denotes cross-references, and citations.

Preface About this book


http://infocenter.arm.com/help/topic/com.arm.doc.aeg0014-/index.html

boldHighlights interface elements, such as menu names. Denotes signal names. Also used for termsin descriptive lists, where appropriate.

monospaceDenotes text that you can enter at the keyboard, such as commands, file and program names,and source code.

monospaceDenotes a permitted abbreviation for a command or option. You can enter the underlined textinstead of the full command or option name.

monospace italicDenotes arguments to monospace text where the argument is to be replaced by a specific value.

monospace boldDenotes language keywords when used outside example code.

<and>Encloses replaceable terms for assembler syntax where they appear in code or code fragments.For example:

MRC p15, 0, <Rd>, <CRn>, <CRm>, <Opcode_2>

SMALL CAPITALS

Used in body text for a few terms that have specific technical meanings, that are defined in theARM Glossary. For example, IMPLEMENTATION DEFINED, IMPLEMENTATION SPECIFIC, UNKNOWN, andUNPREDICTABLE.

Timing diagrams

The following figure explains the components used in timing diagrams. Variations, when they occur,have clear labels. You must not assume any timing information that is not explicit in the diagrams.

Shaded bus and signal areas are undefined, so the bus or signal can assume any value within the shadedarea at that time. The actual level is unimportant and does not affect normal operation.

Clock

HIGH to LOW

Transient

HIGH/LOW to HIGH

Bus stable

Bus to high impedance

Bus change

High impedance to stable bus

Figure 1 Key to timing diagram conventions

Signals

The signal conventions are:

Signal levelThe level of an asserted signal depends on whether the signal is active-HIGH or active-LOW.Asserted means:• HIGH for active-HIGH signals.• LOW for active-LOW signals.

Lowercase nAt the start or end of a signal name denotes an active-LOW signal.



Additional reading

This book contains information that is specific to this product. See the following documents for otherrelevant information.

ARM publications• SoC Designer User Guide (ARM DUI 0956).• SoC Designer Tools API Reference Manual (ARM DUI 1063).• SoC Designer Installation Guide (ARM DUI 0953).• ESL API Developer's Guide.• SoC Designer SystemC Linking Guide (ARM DUI 1041).• MxScript Reference Manual (ARM DUI 1011).• SoC Designer Standard Component Library Reference Manual (ARM DUI 1044).

The following publications provide reference information about the ARM® or AMBA®

architecture:• AMBA® Specification• AMBA® AHB Transaction Level Modeling Specification.• AMBA® AXI Transaction Level Modeling Specification.• ARM® Architecture Reference Manual.

Other publications• IEEE 1666 SystemC Language Reference Manual, (IEEE Standards Association).• SPIRIT User Guide, Revision 1.2, SPIRIT Consortium.



Feedback

Feedback on this product

If you have any comments or suggestions about this product, contact your supplier and give:• The product name.• The product revision or version.• An explanation with as much information as you can provide. Include symptoms and diagnostic

procedures if appropriate.

Feedback on content

If you have comments on content then send an e-mail to [email protected]. Give:

• The title SoC Designer CDP v4.1 HDL Cosimulation Guide.• The number ARM DUI1078A.• If applicable, the page number(s) to which your comments refer.• A concise explanation of your comments.

ARM also welcomes general suggestions for additions and improvements. Note

ARM tests the PDF only in Adobe Acrobat and Acrobat Reader, and cannot guarantee the quality of therepresented document when used with any other PDF reader.

Preface Feedback


mailto:[email protected]

Chapter 1Introduction

This chapter describes Cosimulation and transactors.

Note

This guide covers only Cosimulation features of the SoC Designer CoDesign Package ( CDP ) . CDP inthis book refers only to the Cosimulation features.

It contains the following section:• 1.1 About the SoC Designer CoDesign Package on page 1-12.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. 1-11Non-Confidential

1.1 About the SoC Designer CoDesign PackageThe SoC Designer CDP supports HDL Cosimulation. The CDP allows you to combine an ESL designwith an RTL design simulated in VCS, ModelSim, NCSim, or another RTL-level simulator. Also, SoCDesigner CDP adds software debug capability to your verification environment.

With the RTL-based design open in SoC Designer Canvas, you select the pins on the ESL-basedsubsystem that you want to expose to the larger RTL system. SoC Designer CDP generates aninstantiation of the ESL-based system into the RTL system and simulates the entire design as a whole.

SoC Designer CDP supports:• Combinatorial signals in cosimulation.• A wide variety of transactors.• Rapid system model construction. Building an ESL-based SoC system model requires that all ESL IP

model libraries are available.• Verification of ESL IP models through the re-use of HDL test benches. SoC Designer Cosimulation

enables integrated simulation of ESL IP models and HDL-based test benches.

1 Introduction1.1 About the SoC Designer CoDesign Package


Chapter 2Installing and Configuring Cosimulation Software

This chapter describes the installation and configuration of SoC Designer CoDesign Cosimulationsoftware.

It contains the following sections:• 2.1 CDP Licensing on page 2-14.• 2.2 CoDesign Package components on page 2-15.• 2.3 Minimum Requirements on page 2-16.• 2.4 Preparing for Cosimulation on page 2-17.• 2.5 Preparing for Cosimulation with ModelSim and Verilog on page 2-21.• 2.6 Preparing for Cosimulation with NCSim and Verilog on page 2-23.• 2.7 Preparing for Cosimulation with VCS with Verilog on page 2-25.• 2.8 Starting SoC Designer Cosimulation on page 2-27.• 2.9 Restarting Cosimulation on page 2-31.• 2.10 Interaction between SoC Designer Simulator and an HDL simulator on page 2-33.


2.1 CDP LicensingThe SoC Designer CoDesign Package requires a separate license. Contact ARM for more information.

2 Installing and Configuring Cosimulation Software2.1 CDP Licensing


2.2 CoDesign Package componentsThis section describes the transactors and Cosimulation libraries present in the CoDesign Package.

This section contains the following subsections:• 2.2.1 Transactors present in the CoDesign Package on page 2-15.• 2.2.2 Cosimulation kernel libraries on page 2-15.

2.2.1 Transactors present in the CoDesign Package

The following transactors are part of the package:

AHBv2M_T2S AHB Master Interface Transaction-to-Signal transactorAHBv2M_S2T AHB Master Interface Signal-to-Transaction transactorAHBv2S_T2S AHB Slave Interface Transaction-to-Signal transactorAHBv2S_S2T AHB Slave Interface Signal-to-Transaction transactorAHBv2LiteM_T2S AHBLite Master Interface Transaction-to-Signal transactorAHBv2LiteM_S2T AHBLite Master Interface Signal-to-Transaction transactorAHBv2LiteS_T2S AHBLite Slave Interface Transaction-to-Signal transactorAHBv2LiteS_S2T AHBLite Slave Interface Signal-to-Transaction transactorAXIv2_T2S AXI Transaction-to-Signal transactorAXIv2_S2T AXI Signal-to-Transaction transactorAPB_T2S APB 2.0 Transaction-to-Signal transactorAPB_S2T APB 2.0 Signal-to-Transaction transactorAPB3_T2S APB 3.0 Transaction-to-Signal transactorAPB3_S2T APB 3.0 Signal-to-Transaction transactorAXI4_S2T AXI4 Signal-to-Transaction transactorAXI4_T2S AXI4 Transaction-to-Signal transactorMxTranslator32 Mx Transaction-to-Signal transactor with source code as an example for creating

new transactors.

2.2.2 Cosimulation kernel libraries

The following kernel libraries are provided:

• Libraries that enable communication between an HDL simulator and SoC Designer Simulator are inthe lib directory of the package.

• Cosimulation configuration front-end libraries are in the etc directory of the installation.

2 Installing and Configuring Cosimulation Software2.2 CoDesign Package components


2.3 Minimum RequirementsThe CoDesign Package is installed automatically with SoC Designer.

For Linux platforms, Cosimulation libraries are built with the g++/gcc Version listed in the SoC DesignerInstallation Guide (ARM DUI 1053).

2.3.1 Cosimulation with Mentor Graphics ModelSim

You can perform Cosimulation of a Verilog system with SoC Designer using transactors.

Requirements:• Mentor Graphics ModelSim 10.2. Must be run in 64-bit mode.• SoC Designer• Platform

— Linux: Red Hat Enterprise 6.6 (64-bit)• All requirements imposed by ModelSim.

Cosimulation with Cadence NCSim

A SoC Designer system can be integrated and simulated with an NCSim Verilog system. Transactorsmust be introduced in the system.

Requirements:• Cadence NCSim 13.10. Must be run in 64-bit mode.• SoC Designer• Platform

— Red Hat Enterprise Linux 6.6 (64-bit)• All requirements imposed by NCSim

Cosimulation with Synopsys VCS

A SoC Designer system can be integrated and simulated along with a VCS Verilog system. Transactorsmust be introduced in the system.

Requirements:• Synopsys VCS-2014.03 SP1. Must be run in 64-bit mode.• SoC Designer• Platform

— Red Hat Enterprise Linux 6.6 (64-bit)• All requirements imposed by VCS

2 Installing and Configuring Cosimulation Software2.3 Minimum Requirements


2.4 Preparing for CosimulationThis section provides a general explanation of how to integrate SoC Designer and an HDL simulator.

See the following sections for more information on each HDL simulator:• 2.5 Preparing for Cosimulation with ModelSim and Verilog on page 2-21.• 2.6 Preparing for Cosimulation with NCSim and Verilog on page 2-23.• 2.7 Preparing for Cosimulation with VCS with Verilog on page 2-25.

2.4.1 Adding transactors to your SoC Designer system

The CoDesign Package provides AHB, AXI, and APB transactors. You must create transactors for otherbus interfaces.

See 3.8 Creating a new transactor on page 3-48 for instructions on creating a new transactor. Note

Verilog components are not visible in the SoC Designer Canvas diagram window. Only ESL librarymodules and transactors are visible.

If you require a transactor that is not supplied by CDP, you must add it to the Component Library of SoCDesigner.

After it is added, the transactor appears in the Component Window of SoC Designer, where you can dragand drop the component into the diagram window to instantiate it. See the SoC Designer InstallationGuide (ARM DUI 0953) for more information on installing models.

2.4.2 Configuring Cosimulation in SoC Designer

In SoC Designer Canvas, select Enable HDL Cosimulation from the Simulation menu to enableCosimulation. Then select Simulation → HDL Cosimulation → HDL Cosimulation Setup.

In the HDL Cosimulation Setup dialog (see the following figure), configure the Cosimulation settings.Choose the language that the top-level netlist file is written in from the HDL Type pull-down menu.

You can modify the HDL simulation command in the HDL Simulation Command field. The defaultcommand string for the HDL type you specified appears in this field when you first configureCosimulation.

Except for VCS, all HDL simulators require a top-level design name in the simulation command. If youcreate a new design, the HDL Simulation Command field includes the top-level design name. You mustreplace this value with the proper top-level design name of your test bench. After completing setup, thisfield does not require modification for other projects.

2 Installing and Configuring Cosimulation Software2.4 Preparing for Cosimulation


Figure 2-1 HDL Cosimulation Setup window for VCS on Linux

The Component/Port area of the HDL Cosimulation Setup dialog shown in this figure lists all the signalports of each component in the currently-opened design diagram.

Signals that have a check in the checkbox are included in the proxy module as a signal port. Add orexclude signals by clicking the checkbox next to a signal name. Change the values in the columnsmarked with an asterisk by double-clicking the signal name.

3.1 Configuring CDP on page 3-35 describes the function and acceptable values for the fields in theHDL Cosimulation Setup window.

Note

For Cosimulation to function properly you must configure the Address and Data Bit Width parametersfor each transactor with the same size as you specify in the HDL Cosimulation Setup dialog.For more information on parameter configuration for the transactors supplied in CDP, see the followingsections:• Appendix A AMBA® 3 AXI4 Transactors on page Appx-A-51• Appendix A AMBA® 3 AXI4 Transactors on page Appx-A-51• Appendix C AMBA® 2 AHBv2 Transactors on page Appx-C-66• Appendix D AMBA® APB Transactors on page Appx-D-79

2.4.3 Generating the Proxy Module

Click OK in the HDL Cosimulation Setup window to generate a proxy module component forCosimulation. SoC Designer creates this module and places it in the directory specified in the LogicSimulation Directory field.



The following table lists the default directory names. This creates a file named maxsim.v in the directorythat contains the proxy module component maxsim.

Table 2-1 Default directory names for each HDL simulator

HDL simulator HDL language of top netlist Default directory

NCSim Verilog NCVlog

ModelSim Verilog MSVlog

VCS Verilog VCS

Note

This generation process can take some time because it invokes an HDL simulator command forcompilation.

2.4.4 Modifying the top-level HDL design

You must instantiate the generated proxy module in your top-level design and make connections betweenthe signals of the proxy module and the signals of user modules in the test bench.

The instance name of the generated proxy module must be identical to the instance name in the Verilogtest bench code. If you regenerate the Verilog file, you must re-compile your test bench.

2.4.5 Modifying RTL memory HDL codes (Optional)

If you require the RTL memory debug feature, you must modify your RTL memory Verilog code to addmx_write and mx_read functions.

Related references3.5 Modifying RTL memory codes for debug support on page 3-44.

2.4.6 Invoking SoC Designer Simulator and a HDL simulator

You must set up your HDL simulator environment before you start SoC Designer.

Ensure that:

• All environment variables for your HDL simulator are properly set.• The simulator command is in the path.• Your licenses are current.

From SoC Designer Canvas, select Simulate System from the Simulation menu or press the F5 key.This launches SoC Designer Simulator and an HDL Simulator. The HDL simulator starts for the RTL,and a new instance of SoC Designer Simulator starts for the ESL system (.mxp) side. The HDL simulatorautomatically loads the top-level design you specified in the HDL Simulator Command field of the HDLCosimulation Setup window.

There are other ways to start Cosimulation, such as, for example, batch-mode Cosimulation. Forinformation on starting Cosimulation see 2.8 Starting SoC Designer Cosimulation on page 2-27.

For information on setting up the simulation environment for transactors that are supplied in CDP, seethe following appendices:• Appendix A AMBA® 3 AXI4 Transactors on page Appx-A-51• Appendix A AMBA® 3 AXI4 Transactors on page Appx-A-51• Appendix C AMBA® 2 AHBv2 Transactors on page Appx-C-66• Appendix D AMBA® APB Transactors on page Appx-D-79



2.4.7 Proceeding with Cosimulation

Now you are ready to proceed with cosimulating your design. SoC Designer Cosimulation for NCSimand VCS is designed to work in a dual-master mode.

To start simulation, click Run or Step in SoC Designer Simulator and the HDL simulator.

Note

For Cosimulation with ModelSim, clicking Run or Step in the SoC Designer Simulator or the HDLsimulator starts simulation.

During Cosimulation, you can use all features available from SoC Designer Simulator and an HDLsimulator for:• Analyzing system simulation.• Debugging of embedded software running on a processor model.• Debugging of user-defined ESL IP models.• Hardware debugging of HDL source code of RTL models.

Related references2.5 Preparing for Cosimulation with ModelSim and Verilog on page 2-21.2.6 Preparing for Cosimulation with NCSim and Verilog on page 2-23.2.7 Preparing for Cosimulation with VCS with Verilog on page 2-25.



2.5 Preparing for Cosimulation with ModelSim and VerilogThis section provides specific information for ModelSim Verilog Cosimulation.

For information on how to prepare for Cosimulation see 2.4 Preparing for Cosimulation on page 2-17.

Follow these steps to perform Cosimulation of ModelSim for Verilog:1. Set up the ModelSim environment and ensure that:

• All environment variables for the ModelSim simulator are properly set.• The command vsim is in the path.• Your licenses are current.

See the ModelSim documentation for information on setting up the simulation environment.2. Add the transactor to your SoC Designer system.

For a design you create, you must:• Add the necessary transactor libraries to the component library configuration file.• Instantiate these libraries in the design.• Add file component library configuration file for the transactor libraries to the SoC Designer

preferences by one of the following:— Selecting File→Preferences→General→Component Library.— Selecting Manage Component Library from the Tools menu.

3. Configure ModelSim Cosimulation in SoC Designer Canvas.4. Generate a proxy module.

Click OK in the HDL Cosimulation Setup window to generate a Verilog proxy module.5. Modify the top-level Verilog design.

2 Installing and Configuring Cosimulation Software2.5 Preparing for Cosimulation with ModelSim and Verilog


tb.v file for ModelSim Verilog

maxsim mx ( .haddrS (HADDR_S), .hburstS (HBURST_S), .hbusreqS (HBUSREQ_S), .hgrantS (HGRANT_S), .hlockS (HLOCK_S), .hprotS (HPROT_S), .hrdataS (HRDATA_S), .hreadyS (HREADY_S), .hrespS (HRESP_S), .hsizeS (HSIZE_S), .htransS (HTRANS_S), .hwdataS (HWDATA_S), .hwriteS (HWRITE_S), .haddrM_D (HADDR_M_D), .hburstM_D (HBURST_M_D), .hmasterM_D (HMASTER_M_D), .hmastlockM_D (HMASTLOCK_M_D), .hprotM_D (HPROT_M_D), .hrdataM_D (HRDATA_M_D), .hreadyM_D (HREADY_M_D), .hreadyoutM_D (HREADYOUT_M_D), .hrespM_D (HRESP_M_D), .hselM_D (HSEL_M_D), .hsizeM_D (HSIZE_M_D), .htransM_D (HTRANS_M_D), .hwdataM_D (HWDATA_M_D), .hwriteM_D (HWRITE_M_D), .haddrM_P (HADDR_M_P), .hburstM_P (HBURST_M_P), .hmasterM_P (HMASTER_M_P), .hmastlockM_P (HMASTLOCK_M_P), .hprotM_P (HPROT_M_P), .hrdataM_P (HRDATA_M_P), .hreadyM_P (HREADY_M_P), .hreadyoutM_P (HREADYOUT_M_P), .hrespM_P (HRESP_M_P), .hselM_P (HSEL_M_P), .hsizeM_P (HSIZE_M_P), .htransM_P (HTRANS_M_P), .hwdataM_P (HWDATA_M_P), .hwriteM_P (HWRITE_M_P), .haddrM_Apb (HADDR_M_Apb), .hburstM_Apb (HBURST_M_Apb), .hmasterM_Apb (HMASTER_M_Apb), .hmastlockM_Apb (HMASTLOCK_M_Apb), .hprotM_Apb (HPROT_M_Apb), .hrdataM_Apb (HRDATA_M_Apb), .hreadyM_Apb (HREADY_M_Apb), .hreadyoutM_Apb (HREADYOUT_M_Apb), .hrespM_Apb (HRESP_M_Apb), .hselM_Apb (HSEL_M_Apb), .hsizeM_Apb (HSIZE_M_Apb), .htransM_Apb (HTRANS_M_Apb), .hwdataM_Apb (HWDATA_M_Apb), .hwriteM_Apb (HWRITE_M_Apb), .irq0 (IRQ), .clk (HCLK) );

6. Compile your top-level Verilog design file and other files if required.7. Start the SoC Designer and ModelSim simulators.

SoC Designer prompts you to load the application binary for the core. Select the application binaryfor the core and click Proceed.

8. Perform Cosimulation.

Use SoC Designer Simulator or ModelSim to control Cosimulation. If you click Run in one of thesesimulators, SoC Designer Simulator and ModelSim begin simulation. If you click Stop in one ofthese simulators, the simulator stops advancing simulation time.

Related references2.4.2 Configuring Cosimulation in SoC Designer on page 2-17.

2 Installing and Configuring Cosimulation Software2.5 Preparing for Cosimulation with ModelSim and Verilog


2.6 Preparing for Cosimulation with NCSim and VerilogThis section provides specific information for NCSim Verilog Cosimulation.

For more information on how to prepare for Cosimulation, see 2.4 Preparing for Cosimulationon page 2-17.

Follow these steps to perform Cosimulation with NCSim for Verilog:1. Set up the NCSim simulator environment by ensuring that:

• All environment variables for the NCSim simulator are properly set.• The command ncsim is in the path.• Your licenses are current.

See the NCSim documentation for information on setting up the simulation environment.2. Add the transactors to your SoC Designer system.

For a design you create, you must:• Add the necessary transactor libraries to the component library configuration file.• Instantiate these libraries in the design.• Add file component library configuration file of the transactor libraries to the SoC Designer


3. Configure NCSim Cosimulation in SoC Designer Canvas.4. Generate a proxy module.


2 Installing and Configuring Cosimulation Software2.6 Preparing for Cosimulation with NCSim and Verilog


tb.v file for NCSim Verilog


6. Compile your top-level Verilog design file and other files if required.7. Start the SoC Designer and the NCSim simulators.


8. Perform Cosimulation

Use NCSim to control Cosimulation. If you click Run in this simulator, SoC Designer and NCSimbegin simulation. If you click Stop in the NCSim simulator, the two simulators stop advancingsimulation time.


2 Installing and Configuring Cosimulation Software2.6 Preparing for Cosimulation with NCSim and Verilog


2.7 Preparing for Cosimulation with VCS with VerilogThis section provides specific information for VCS Verilog Cosimulation.

For more information on how to prepare for Cosimulation, see 2.4 Preparing for Cosimulationon page 2-17.1. Set up your VCS simulator environment.

Ensure that:• All environment variables for the VCS simulator are properly set.• The command vcs is in the path.• The VCS command line has the following flags:-L$(MAXSIM_HOME)/lib/Linux/release -

lQtXml -lQtCore

Without these flags the RTL fails to compile.• You must link against the following libraries when building vsim, so add them to the vcs

command line:

${MAXSIM_HOME}/lib/Linux/release/libQtCore.so

${MAXSIM_HOME}/lib/Linux/release/libQtXml.so• Your licenses are current.

See the VCS documentation for additional information on setting up the simulation environment.2. Add the transactors to your SoC Designer system.

For a design you create, you must:• Add the necessary transactor libraries to the component library configuration file.• Instantiate these libraries in the design.• Add file component library configuration file of the transactor libraries to the SoC Designer


3. Configure VCS Cosimulation in SoC Designer Canvas.4. Generate a proxy module.


2 Installing and Configuring Cosimulation Software2.7 Preparing for Cosimulation with VCS with Verilog


tb.v file for VCS Verilog


6. Compile your top-level Verilog design file and other files if required.7. Start the SoC Designer and VCS simulators.


8. Perform Cosimulation.

Use the VCS simulator to control Cosimulation. If you click Run in this simulator, SoC Designer andVCS begin simulation. If you click Stop in the VCS simulator, the two simulators stop advancingsimulation time.


2 Installing and Configuring Cosimulation Software2.7 Preparing for Cosimulation with VCS with Verilog


2.8 Starting SoC Designer CosimulationYou can start Cosimulation of SoC Designer and an HDL simulator in four different ways.

This section contains the following subsections:• 2.8.1 Starting from SoC Designer Canvas on page 2-27.• 2.8.2 Starting Cosimulation separately on page 2-27.• 2.8.3 Starting Cosimulation in batch mode on page 2-28.• 2.8.4 Starting Cosimulation in slaveable simulator mode on page 2-29.

2.8.1 Starting from SoC Designer Canvas

Procedure1. Enter the following command to start SoC Designer Canvas:

% sdcanvas

2. Open the.mxp system file and press F5 or select Simulate System… from the Simulation menu tostart SoC Designer Simulator.If you have set up your environment for an HDL Simulator before SoC Designer Canvas is started,SoC Designer Simulator automatically starts the specified HDL simulator.

Note

You must set up your environment for an HDL Simulator before starting SoC Designer Canvas.

2.8.2 Starting Cosimulation separately

Procedure1. Use the following command to start SoC Designer Simulator.

% sdsim

2. Select Open from the File menu to open the system file (.mxp). You must then start an HDLsimulator.

Postrequisites

The following sections explain how to start an HDL simulator:• ModelSim and Verilog on page 2-27• NCSim and Verilog on page 2-28• VCS and Verilog on page 2-28

ModelSim and Verilog

1. If you have not compiled the whole test bench, do this before running the vsim command.2. Open ModelSim from the Logic Simulation Directory. Unless you specify otherwise, the directory is

MSVlog.

For Linux, use the following commands (note that the simulator must run in 64-bit mode):

% cd MSVlog% vsim -64 –lib work –pli ${MX_CDP_HOME}\cosimulation\lib\HDLSim\ModelSim\libmxmsvlog_comm.so tb

3. The order of invocation between sdsim and vsim does not matter. If you start ModelSim first, startSoC Designer Simulator as a background job with &.

2 Installing and Configuring Cosimulation Software2.8 Starting SoC Designer Cosimulation


NCSim and Verilog

1. If you have not compiled the whole test bench, do this before running the ncsim command.2. Open NCSim from the Logic Simulation Directory. Unless you specify otherwise, the directory is

NCVlog. Note

The simulator must run in 64-bit mode.

% cd NCVlog% ncsim -64bit –mess worklib.tb:module -gui

VCS and Verilog

1. If you have not compiled the whole test bench, do this before running the vcs command.2. Open VCS after entering the Logic Simulation Directory. Unless you specify otherwise, the directory

is VCS. Note

The simulator must run in 64-bit mode.

% cd VCS% vcs -full64 -RIG simv

2.8.3 Starting Cosimulation in batch mode

Ensure that the Component Library settings are correct and that SoC Designer is properly configured torun Cosimulation.

Invoke SoC Designer Simulator in batch mode by launching an MxScript-based script. All simulatorsterminate automatically when the script completes execution. For information about MxScript, see theMxScript documentation in the SoC Designer installation directory.

In batch mode SoC Designer Simulator writes messages to the sdsim.log file.

The following sections explain how to run SoC Designer Simulator in batch mode:• ModelSim and Verilog on page 2-28• NCSim and Verilog on page 2-29• VCS on page 2-29• Starting batch mode Cosimulation with one command on page 2-29

ModelSim and Verilog

Use one of the following procedures to run Cosimulation of ModelSim Verilog in batch mode:

• Start ModelSim and then SoC Designer Simulator:1. Start ModelSim:

% cd MSVlog% vsim -64 –pli ${MX_CDP_HOME}/cosimulation/lib/HDLSim/ModelSim/libmxmsvlog_comm.so -



c tb \-do “run –all; quit –f” &

2. Start SoC Designer Simulator:

% cd …% sdsim –l sdsim.log –i msvlog.mxscr

• Start SoC Designer Simulator and then ModelSim1. Start SoC Designer Simulator:

% sdsim -l sdsim.log -i msvlog.mxscr&

2. Start ModelSim:

% cd MSVlog% vsim -64 -pli ${MX_CDP_HOME}/cosimulation/lib/HDLSim/ModelSim/libmxmsvlog_comm.so -c tb \-do "run -all; quit -f"

See the ModelSim documentation for information on ModelSim operation in batch mode.

NCSim and Verilog

Delete any mx_{testbench}_{user id} files in the /tmp directory if no other NCSim Cosimulationsession is loading.

Run batch mode simulation by entering the following commands:

% sdsim -l sdsim.log –i ncvlog.mxscr% cd NCVlog% ncsim -64bit –mess –i @run –log ncsim.log worklib.tb:module

VCS

You must have a command input file to run batch mode with VCS. The examples include an input.vcsfile. This file contains a single line with a period (.). You must enter any commands for the VCSsimulator before this line.

Run batch mode simulation by entering the following commands:

% sdsim -l sdsim.log –i vcs.mxscr% cd VCS% simv -full64 -i input.vcs

Starting batch mode Cosimulation with one command

The system command in an MxScript script file provides an alternate method to start batch-modesimulation.

For ModelSim, for example, enter the following line before the runUntil(100000) command:

system(“cd ModelSim;vsim -64 -c -do \'run -all; quit -f\' tb&”);

See the documentation for individual simulators for the required command syntax.

2.8.4 Starting Cosimulation in slaveable simulator mode

Slaveable simulation provides SoC Designer simulation without a graphical user interface.

Note

To use slaveable simulator mode on Linux you must request customized libraries from ARM.

Requirements

For slaveable simulation mode, you require an RTOE system and an executable file.



Running slaveable mode

To run a slaveable mode simulation, complete the following steps:

1. Open a Cosimulation test bench in SoC Designer Canvas.

Select Open from the File menu to open the system file (.mxp) for the test bench.2. Create a Runtime Only Environment (RTOE) (.mxe) system.

The Tools menu supports creating an RTOE system. See the SoC Designer User Guide (ARM DUI0956) for details.

3. Copy the slaveable mode examples.

Copy the slaveable mode examples into your current working directory. The SlaveableEnginedirectory has SoC Designer slaveable mode examples, and each example directory contains amain.cpp and a Makefile/VC++ project file.

4. Modify main.cpp.

Modify the main.cpp file for your current Cosimulation test bench to specify necessaryconfigurations including the RTOE system to open, the application file to load, the component libraryconfiguration file to load, and any other necessary parameters.

5. Include the command for the HDL simulator.

You can start the HDL simulator in GUI mode or batch mode from the slaveable mode executable.

The following table lists commands that must be included in main.cpp for each simulator.

Table 2-2 Simulator commands for slaveable mode

Simulator Commands

ModelSim For Verilog top-level design, use the following commands to start ModelSim from the slaveable mode executable:

system(“cd MSVlog; vsim -64 -pli \

${MX_CDP_HOME}/cosimulation/lib/HDLSim/ModelSim/libmxmsvlog_comm.so \

-c tb -do 'run -all; quit -f' &”);

NCSim To start NCSim from the slaveable mode executable in Linux, use the following commands:

system(“cd NCVlog; ncsim -64bit -mess -i @run -log ncsim.log worklib.tb:module &”);

VCS For Verilog top-level design use the following command in Linux to start VCS from the slaveable mode executable:

system(“cd VCS; simv -full64 -i input.vcs &”);

The input.vcs file contains the CLI commands that VCS executes on simulation. See the VCS simulatordocumentation for information on CLI commands.

6. Create the slaveable mode executable.

Use the Makefile project file to generate the SoC Designer slaveable mode executable.



2.9 Restarting CosimulationThis section explains how to stop and restart your Cosimulation. You can do this at any time duringsimulation.

For restart, you must restart the SoC Designer in addition to the HDL simulator. This takes the SoCDesigner and HDL simulators to time zero simulation state.

For ModelSim and NCSim Cosimulation, the order you restart the simulators in does not matter. ForVCS Cosimulation, you must restart the VCS simulator before you restart the SoC Designer Simulator.

This section contains the following subsections:• 2.9.1 ModelSim on page 2-31.• 2.9.2 NCSim on page 2-31.• 2.9.3 VCS on page 2-32.

2.9.1 ModelSim

Use the following procedure to stop and restart your Cosimulation.

Procedure1. Stop the simulation.

Click Stop in the SoC Designer Simulator. This stops the simulation in SoC Designer Simulator andcauses ModelSim to enter interactive mode.

2. Restart SoC Designer Simulator.Select Restart Simulation from the Control menu in SoC Designer Simulator to reset all thecomponents and the cycle count.

3. Reload the program.Open an application file and click Proceed to load the application to the program memory.

4. Reset ModelSim.Select Simulate→Run→Restart to reset the ModelSim simulator to time zero.

5. Restart Cosimulation.Click Run in SoC Designer Simulator to start the Cosimulation.

2.9.2 NCSim


Procedure1. Stop the SoC Designer Simulator.

Click Stop in SoC Designer Simulator.2. Stop the NCSim simulator.

If the environment variable MXCOSIM_CONTROL is set to 1, NCSim automatically enters interactivemode when you click Stop in SoC Designer Simulator. Otherwise, select Stop from the Simulationmenu in NCSim.

3. Restart SoC Designer Simulator.Select Restart Simulation from the Control menu in SoC Designer Simulator to reset all thecomponents and the cycle count.

4. Reload the program.Open an application file and the click Proceed to load the application to the program memory.

5. Reset NCSim.Select Reset to Start from the Control menu to reset the NCSim simulator to time zero.

6. Start Cosimulation.

2 Installing and Configuring Cosimulation Software2.9 Restarting Cosimulation


Click Run in the SoC Designer Simulator and NCSim simulators.

2.9.3 VCS


Procedure1. Stop the SoC Designer Simulator.

Click Stop in the SoC Designer Simulator.2. Stop the VCS simulator.

Choose Stop from the Sim menu in the VCS Simulator.3. Restart the VCS simulator.

Choose Re-exec from the Sim menu in the VCS Simulator to rerun the simulation from time zero.4. Restart SoC Designer Simulator.

Select Restart Simulation from the Control menu in SoC Designer Simulator to reset all thecomponents and the cycle count.

5. Reload the program.Open an application file and the click Proceed to load the application to the program memory.

6. Start Cosimulation.Click Run in SoC Designer Simulator and click Continue in the VCS simulator to start theCosimulation.

Postrequisites

Note

For only VCS\x92s, the order of restart between the two simulators is important. To restart Cosimulation,VCS must be restarted first as stated above and then SoC Designer Simulator must be restarted.

2 Installing and Configuring Cosimulation Software2.9 Restarting Cosimulation


2.10 Interaction between SoC Designer Simulator and an HDL simulatorDuring Cosimulation, interaction between SoC Designer Simulator and the HDL simulator variesdepending on the simulator that initiates the action.

• If the HDL simulator initiates the action, SoC Designer and the HDL simulator are affected. That is,clicking Run in the HDL simulator also starts SoC Designer Simulator, and clicking Stop orencountering a breakpoint in the HDL simulator also stops SoC Designer Simulator.

• If SoC Designer initiates the action, the action may not affect the HDL simulator.

The following table lists the interaction during Cosimulation with the three HDL simulators.

Table 2-3 Interaction between SoC Designer Simulator and an HDL simulator

SoC Designer ModelSim NCSim VCS

Click Run in SoCDesigner Simulator.

ModelSimsimulation startsautomatically.

NCSim simulation does not start automatically.You must click Run in NCSim to start NCSimsimulation.

VCS simulation does not startautomatically. You must click Runin VCS to start VCS simulation.

SoC DesignerSimulator stopssimulation for anyreason.

ModelSim entersinteractive modeautomatically.

NCSim does not enter interactive modeautomatically.

Clicking Pause in NCSim does not force NCSimto enter interactive mode. After clicking Pause inNCSim, simulation advances in SoC DesignerSimulator for at least one cycle before NCSimenters interactive mode.

VCS does not enter interactivemode automatically. You must clickStop to force VCS to enterinteractive mode.

By default, the behavior of NCSim or VCS Cosimulation is better tuned for source-level debugging. Thatis, an embedded software developer can continue simulation from the HDL simulator or the SoCDesigner Simulator without clicking Continue on the other simulator. However, if you want to switch toNCSim or VCS after continuing debugging from an external software debugger, latency is expected fromthe HDL simulator user interface because these simulators do not automatically enter interactive mode.

If you must frequently use features of NCSim and do not do any source-level debugging of theembedded application, you can configure NCSim to enter interactive mode whenever SoC DesignerSimulator stops. Do this by setting the environment variable MXCOSIM_CONTROL to 1 before starting aCosimulation session.

2 Installing and Configuring Cosimulation Software2.10 Interaction between SoC Designer Simulator and an HDL simulator


Chapter 3CDP HDL Cosimulation Reference

This chapter provides reference information for the SoC Designer CoDesign Package Cosimulationsoftware.

It contains the following sections:• 3.1 Configuring CDP on page 3-35.• 3.2 Generated files for Cosimulation on page 3-39.• 3.3 CDP synchronization model on page 3-42.• 3.4 Combinatorial signals on page 3-43.• 3.5 Modifying RTL memory codes for debug support on page 3-44.• 3.6 Configuring endianness on page 3-46.• 3.7 Controlling Cosimulation through environment variables on page 3-47.• 3.8 Creating a new transactor on page 3-48.• 3.9 Direct HDL signal linking on page 3-50.


3.1 Configuring CDPThis section explains the configuration of CDP software.

3.1.1 HDL Cosimulation setup

List of parameters and configuration settings in the HDL Cosimulation Setup dialog.

To configure Cosimulation, select Enable HDL Cosimulation from the Simulation menu in SoCDesigner Canvas. Then select Simulation → HDL Cosimulation → HDL Cosimulation Setup to openthe HDL Cosimulation Setup dialog (see the following figure).

Figure 3-1 HDL Cosimulation Setup dialog (basic view)

The HDL Cosimulation Setup dialog lets you set the Cosimulation parameters and select the ports to beexported from SoC Designer to the HDL simulator.

To use the advanced options display feature (see the following figure), enable the Display AdvancedOptions checkbox.

3 CDP HDL Cosimulation Reference3.1 Configuring CDP


Figure 3-2 HDL Cosimulation Setup dialog (advanced view)

You can configure the following parameters from the HDL Cosimulation Setup dialog:

HDL TypeUse this drop-down menu to select the HDL simulator to use for Cosimulation. For example, forVCS Cosimulation, select VCS (R).

HDL Simulation CommandUse this field to configure the HDL Simulator command. The default command string appearsin the field when you first configure Cosimulation. If simulators are invoked separately or inbatch mode, changing this field is not required.

For ModelSim, if a series of ModelSim macro commands follow -do, the macro commandsmust be enclosed by single quotation marks. For example:

vsim -64 tb -do 'run –all; quit –f'

Logic simulation directoryUse this field to specify a directory for logic simulation. If you click the OK button, SoCDesigner Canvas creates this directory if it does not exist. The directory can be subordinate tothe directory where the current .mxp file is located, or it can be specified as an absolute path.For the example files, you are not required to change this directory.

Last Sampling PointThis field indicates the time in nanoseconds from a clock rising edge until which any signalchange in the RTL will be communicated to SoC Designer for the current cycle. Normally, thedefault values are appropriate.

Drive DelayDrive Delay is the delay from the rising clock edge to the instant the driven signal value appearsin the HDL Simulator.

Only output signal values (SoC Designer > HDL Simulator) display, in the Port area of thedialog.



Clock GenerationIf your test bench includes a clock generator, the SoC Designer proxy module is clocked by thegenerator. In this case, the Clock Generation field must be set as RTL Test bench. If the testbench does not include a clock generator and the clock must be generated by the SoC Designerproxy module, this field must be set as Proxy Module. The frequency of the clock generated bythe proxy module is 100MHz.

Port AreaThis area displays columns for each port. Check the checkbox next to a signal name to select asignal. Checked signals appear in the port list of the maxsim proxy module.

To configure a signal, right-click or double-click on its name in the Port Area to display the EditParameters dialog. The following figures show the parameters in this dialog.

Figure 3-3 Edit Parameters dialog, input signal



Figure 3-4 Edit Parameters dialog, advanced version, output signal

You can configure the following parameters in this dialog:

BitWidth

specifies the bit-width of the signals exported to Verilog.

Active specifies High or Low as the active level of the signal.Pin name specifies the name of the signals exported to the Verilog simulator. This is the name used in

the Verilog file to refer to the exported signal.DriveDelay

is the delay in nanoseconds or femtoseconds from the rising clock edge to the instant thedriven signal value appear in the HDL Simulator.Values for this column are displayed only for output (SoC Designer to HDL Simulator)signals.

Note

Drive Delay is an advanced option. To edit this option you must do the following:• Click the checkbox in the HDL Cosimulation Setup dialog next to Display Advanced

Options.• Double click a port listed in the HDL Cosimulation Setup dialog to display the Edit

Parameters dialog.

Related tasks2.8.2 Starting Cosimulation separately on page 2-27.

Related references2.8.3 Starting Cosimulation in batch mode on page 2-28.



3.2 Generated files for CosimulationThis section describes the files generated by SoC Designer for the following HDL simulators:

• 3.2.1 ModelSim and Verilog on page 3-39• 3.2.2 NCSim and Verilog on page 3-39• 3.2.3 VCS and Verilog on page 3-40

3.2.1 ModelSim and Verilog

SoC Designer automatically generates the following files required for the ModelSim Simulator interface:

Table 3-1 Generated files for ModelSim Verilog interface

File name Location Description

maxsim.v MSVlog/ Contains the Verilog wrapper component which interfaces SoC Designer to ModelSim.

cosim_config.xml MSVlog/ Internally used in SoC Designer Simulator. This file must never be modified or removed.

The generated maxsim.v file contains the Verilog wrapper used to interface SoC Designer to ModelSim.The maxsim module in this file represents the complete wrapper, and it must be instantiated in the top-level Verilog design. This module represents the SoC Designer side of the system in Verilog.

If you instantiate the maxsim module in your Verilog design, you must connect all the ports of the moduleto signals from your design. The input ports of the module must be driven from your design, while theoutput ports must be read by your design as inputs.

Compile and elaborate your top-level Verilog design files with the ModelSim Verilog compiler fromModelSim.

For example, if the top level module is in the file test.v, use the following commands to compile theVerilog:

% vlib work% vlog -64 -compat maxsim.v% vlog -64 –compat test.v

Note

cosim_config.xml must be located in the starting directory for the HDL simulation. This is especiallyimportant when HDL Simulator is invoked separately from SoC Designer Simulator.

3.2.2 NCSim and Verilog

SoC Designer automatically generates the following files to interface with the NCSim simulator:

Table 3-2 Generated files for NCSim Verilog interface


maxsim.v NCVlog/ Contains the Verilog wrapper component that interfaces SoC Designer to NCSim.

cosim_config.xml NCVlog/ Internally used in SoC Designer Simulator. This file must never be modified or removed.

MxNCVlog_libs/worklib NCVlog/ Work library to store compiled Verilog files.

cds.lib NCVlog/ File where the mappings of logical library name and physical path are defined. This file isnot generated if it already exists.

hdl.var NCVlog/ File where optional configurations can be defined. This file is not generated if it alreadyexists.

3 CDP HDL Cosimulation Reference3.2 Generated files for Cosimulation


The generated maxsim.v file contains the Verilog wrapper used to interface SoC Designer to NCSim.The maxsim module in this file represents the complete wrapper, and you must instantiate this module inthe top-level Verilog design. This module represents the SoC Designer side of the system in Verilog.

When you instantiate the maxsim module in your Verilog design, you must connect all the ports of themodule to signals from your design. The input ports of the module must be driven from your design, andthe output ports must be read by your design as inputs.

Compile and elaborate your top-level Verilog design files with the ncvlog/ncelab compiler from NCSim.

Caution

If you re-generate the Verilog file from the previous step, you must re-compile your top-level Verilogfile. If you do not re-compile your top-level design, the simulator reports an error.

For example, if the top level module is in the file test.v, use the following commands to compile andelaborate the Verilog code:

% ncvlog maxsim.v -mess% ncvlog test.v -mess% ncelab –mess worklib.test –access +rwc –loadvpi \$(MX_CDP_HOME)/Cosimulation/lib/HDLSim/NCSim/libmxncvlog_comm.so:register_vpi_elab.register_vpi_sim

Note


3.2.3 VCS and Verilog

SoC Designer automatically generates the following files to interface with the VCS simulator:

Table 3-3 Generated files for VCS Verilog interface


maxsim.v VCS/ Contains the Verilog wrapper component that interfaces SoC Designer to VCS.

cosim_config.xml VCS/ Internally used in SoC Designer Simulator. This file must never be modified or removed.

mxvcs.tab VCS/ PLI tab file.

The generated maxsim.v file contains the Verilog wrapper used to interface SoC Designer to VCS. Itcontains the following Verilog modules:

maxsimis the Verilog module that represents the complete wrapper. This module must be instantiated inthe top-level Verilog design. This module represent the SoC Designer side of the system inVerilog.

mxvcs.tabis the PLI tab file that lists the PLI functions that can be called from the maxsim module. Thesefunctions are:• mx_vpi_init• mx_vpi_cycle• mx_writeN• mx_readN (where N is 8, 16, 32, 64, or 128)

When you instantiate the maxsim module in your Verilog design, you must connect all the ports of themodule to signals from your design. The input ports of the module must be driven from your design,while the output ports must be read by your design as inputs.



Compile and elaborate your top-level verilog design files with the vcs compiler from VCS.

For example, if the top level module is in the file test.v, use the following command to compile it:

% vcs -full64 -I +vpdupdate +vpi -P mxvcs.tab ${MX_CDP_HOME}/Cosimulation/lib/HDLSim/VCS/libmxvcs_comm.so \ maxsim.v test.v

Note




3.3 CDP synchronization modelSoC Designer and HDL simulators synchronize and transfer data every HDL clock cycle. The term HDLclock cycle represents the clock period as defined on the HDL side.

A clock signal is present in the generated HDL wrapper component (from maxsim.v or maxsim.vhd).The term SoC Designer Simulator cycle represents the simulation cycle for the SoC Designer Simulator.

Synchronization between SoC Designer Simulator and an HDL simulator starts at the rising HDL clockcycle and can happen multiple times per cycle.

The following figure shows the synchronization model used in the SoC Designer and HDL simulatorCosimulation. The complete SoC Designer Simulator cycle is performed by:1. SoC Designer communicate phase.2. Sample signal updates.3. Transfer signals to/from SoC Designer/HDL simulator.4. Repeat steps 2 and 3 until the last sampling point (which is set to 1ns by default, but can be changed

in cosimulation setup).5. SoC Designer update phase.

Figure 3-5 Synchronization between SoC Designer Simulator and an HDL Simulator

3 CDP HDL Cosimulation Reference3.3 CDP synchronization model


3.4 Combinatorial signalsEven though the SoC Designer Simulator is cycle-based, synchronization between RTL simulator andSoC Designer Simulator can take place multiple times in cycle. Therefore, it fully supports combinatorialbehavior of signals.

Related concepts3.3 CDP synchronization model on page 3-42.

3 CDP HDL Cosimulation Reference3.4 Combinatorial signals


3.5 Modifying RTL memory codes for debug supportYou must add calls to the mx_write and mx_read functions for RTL debug support. The followingexample is such a code segment.

This segment shows where the read and a subsequent write, if necessary, are executed. This exampleaccesses memory in bytes. Therefore, you must add mx_write8 and mx_read8 PLI function calls in thisprocess to use RTL memory debug mode in SoC Designer with your RTL memory. (See L005 throughL008 and L037 through L040).

In this RTL memory implementation, Data is a word. A simpler choice is to use mx_write32 andmx_read32 for word-sized accesses. However, the example uses byte-sized accesses for illustrativepurposes and shows that the PLI functions accept different parameters based on the memory size accessas the following table shows.

Table 3-4 Imported table

Memory addressing unit

(RTL memory)

Parameters or Returned VALUE

Address Data

mx_write8 BYTE In: Byte address In: 8 bits

mx_write16 HALF-WORD In: Half-word address In: 16 bits

mx_write32 WORD In: Word address In: 32 bits

mx_write64 DOUBLE-WORD In: Double-word address In: 64 bits

mx_write128 128-BIT In: 128-bit address In: 128 bits

mx_read8 BYTE In: Byte address Out: 8 bits

mx_read16 HALF-WORD In: Half-word address Out: 16 bits

mx_read32 WORD In: Word address Out: 32 bits

mx_read64 DOUBLE-WORD In: Double-word address Out: 64 bits

mx_read128 128-BIT In: 128-bit address Out: 128 bits

Note

64-bit and 128-bit PLI memory accesses are supported only on ModelSim Verilog, NCSim Verilog, andVCS Verilog configurations.

Example code segment for RTL memory debug support----- begin: code segment ----L000: always @(ValidReg or HaddrReg or HCLK)L001: beginL002: if (ValidReg) // Common to read and write operationsL003: beginL004: MemAddr = HaddrReg[MemBits-1 : 2]; // Memory address for this transferL005: Data[7:0] = $mx_read8(MemAddr * 4); // Read word data from addressL006: Data[15:8] = $mx_read8(MemAddr * 4 + 1);L007: Data[23:16] = $mx_read8(MemAddr * 4 + 2);L008: Data[31:24] = $mx_read8(MemAddr * 4 + 3);L009:L010: @(posedge HCLK) // Write-only section performed on the rising clock edgeL011: if (HwriteReg ValidReg)L012: beginL013: case (HsizeReg)L014:L015: `SZ_BYTE : // Byte accessL016: case (HaddrReg[1:0])L017: 2'b00 : Data[7:0] = HWDATA[7:0];L018: 2'b01 : Data[15:8] = HWDATA[15:8];

3 CDP HDL Cosimulation Reference3.5 Modifying RTL memory codes for debug support


L019: 2'b10 : Data[23:16] = HWDATA[23:16];L020: default : Data[31:24] = HWDATA[31:24];L021: endcaseL022:L023: `SZ_HALF : // Halfword accessL024: case (HaddrReg[1])L025: 1'b0 : Data[15:0] = HWDATA[15:0];L026: default : Data[31:16] = HWDATA[31:16];L027: endcaseL028:L029: `SZ_WORD : // Word accessL030: Data = HWDATA;L031:L032: default : // Accesses greater than 32 bit are treated as 32L033: Data = HWDATA;L034:L035: endcaseL036:L037: $mx_write8(MemAddr * 4, Data[7:0]);L038: $mx_write8(MemAddr * 4 + 1, Data[15:8]);L039: $mx_write8(MemAddr * 4 + 2, Data[23:16]);L040: $mx_write8(MemAddr * 4 + 3, Data[31:24]);L041:L042: endL043: endL044: end----- end: code segment ----

3 CDP HDL Cosimulation Reference3.5 Modifying RTL memory codes for debug support


3.6 Configuring endiannessIf you want to run Cosimulation applications in big-endian mode, configure the code and modify theRTL memory code.

Configuring the core

Make sure that the core is operating in big-endian mode and that your application requires big-endianmode.

Modifying RTL memory code

To run Cosimulation in big-endian mode, you must change the RTL memory to operate in big-endianmode.

3 CDP HDL Cosimulation Reference3.6 Configuring endianness


3.7 Controlling Cosimulation through environment variablesThis section describes how to control Cosimulation through the settings of theMXCOSIM_SOCKFILENAME_SUFFIX and MXCOSIM_CONTROL environment variables.

This section contains the following subsections:• 3.7.1 Running multiple sessions of Cosimulation on a single host using

MXCOSIM_SOCKFILENAME_SUFFIX on page 3-47.• 3.7.2 Changing the behavior of NCSim and VCS Cosimulation using MXCOSIM_CONTROL

on page 3-47.

3.7.1 Running multiple sessions of Cosimulation on a single host usingMXCOSIM_SOCKFILENAME_SUFFIX

By default, you can run only one session of Cosimulation of each HDL simulator on a single host. This isbecause CoDesign Package relies on predetermined socket file names being used by a side ofCosimulation for establishing a communications path between the simulators.

You can also use the MXCOSIM_SOCKFILENAME_SUFFIX environment variable to run multiplesessions of Cosimulation of one HDL simulator simultaneously.

Note

Multiple sessions require an appropriate number of licenses for the tools and the models.

To run multiple sessions of the ModelSim and VCS simulators, set the MXCOSIM_SOCKFILENAME_SUFFIXto a different string each time a new session starts. Then, each session uses different socket file namesand does not conflict with other sessions. If you use a script to run multiple sessions of Cosimulation ona single host, set this environment variable before you start SoC Designer Simulator and a HDLsimulator. This feature is especially useful if you run multiple sessions of batch-mode Cosimulation in acluster environment.

You can run multiple Cosimulation sessions with the NCSim simulators without changing the value ofthe MXCOSIM_SOCKFILENAME_SUFFIX environment variable.

3.7.2 Changing the behavior of NCSim and VCS Cosimulation using MXCOSIM_CONTROL

By default, the behavior of NCSim or VCS Cosimulation is tuned for source-level debugging with SoCDesigner. That is, an embedded software developer can continue simulation from SoC DesignerSimulator without clicking Continue in the NCSim or VCS simulator.

However, if you switch to NCSim or VCS after debugging from an external software debugger, latencyis expected from the HDL simulator user interface because these simulators do not automatically enterinteractive mode if SoC Designer stops. If you frequently use NCSim's features and are not requiring anysource-level debugging of the embedded application, you can change this behavior so that NCSim entersinteractive mode automatically every time SoC Designer Simulator stops. Do this by setting theenvironment variable MXCOSIM_CONTROL to 1. See 2.10 Interaction between SoC Designer Simulator andan HDL simulator on page 2-33. For VCS, click Stop to take VCS to an interactive mode.

Note

If you always use the debug features of the HDL simulator, it is better to start and stop the simulationfrom the HDL simulator. Clicking Start in the RTL simulator starts the SoC Designer and HDLsimulators and clicking Stop in the HDL simulator takes the SoC Designer and HDL simulators tointeractive mode.

3 CDP HDL Cosimulation Reference3.7 Controlling Cosimulation through environment variables


3.8 Creating a new transactorSoC Designer operates on transaction-based and signal-based communications. The HDL simulatorssuch as VCS work only on signal-based models. Therefore, a Verilog component can only be directlyconnected to SoC Designer components with signal-based ports.

To connect a Verilog component to a SoC Designer component with transaction-based ports, you requirea transactor component to translate accesses between the transaction and signal ports. The followingfigure shows an example transactor.

Transaction-to-signal translator

To Transaction-based SoC Designer

components

To Signal-based HDL

read()/write()

drive(addr)

drive(rddata)

drive(wrdata)

drive(rd/wr)

read()/write()

drive(addr)

drive(rddata)

drive(wrdata)

drive(rd/wr)

out_addr_SM

out_datain_SS

out_dataout_SM

out_cmd_SM

in_addr_SS

in_dataout_SM

in_datain_SS

in_cmd_SS

Figure 3-6 Example transactor

The transactor translates the transaction values arriving from SoC Designer components to values forsignal ports. You specify these signal ports during HDL Cosimulation setup, see 3.1 Configuring CDPon page 3-35.

The transactor forwards any read or write transactions received from the SoC Designer component to theappropriate signal ports, out_addr_SM, out_dataout_SM, or out_cmd_SM, and forwards the read datafrom out_datain_SS back to the transaction port.

Similarly, the transactor forwards the signals from the in_addr_SS, in_datain_SS and in_cmd_SS signalports to the output transaction port, and drives the in_dataout_SM signal port when the read data isready.

3.8.1 Example Transaction / Signal transactor

Because the transactor semantics depend on the transaction protocol that cannot be inferredautomatically, the transactor component must be manually produced.

The directory MxTranslator32 includes an example of such a transactor. This example can be used as atemplate for developing other transaction/signal transactors.

The MxTranslator32 component translates the transaction-based communication from the DLX core tosignal-based communication required by the Verilog memory. The code for this component is included inthe src/MxTranslator32 directory. This transactor follows the SoC Designer components convention,where the component code is in the MxTranslator.cpp/h files, and the slave ports code is in thecorresponding {port}.cpp or .h files.

Signal ports in the MxTranslator32 component respond as follows:

3 CDP HDL Cosimulation Reference3.8 Creating a new transactor


• The read transaction sets the Read signal port to 1, sets the Address signal port to the value of theaddress, reads the Data signal port, and returns the value.

• For a write transaction, the Address, Value and Write signal ports are set based on the values from thewrite transaction port.

Use the MxTranslator32 as a starting point to develop new transactors. You can also use the ComponentWizard of SoC Designer Canvas, see the SoC Designer User Guide (ARM DUI 0956).

The transactor must have the following types of port:• Transaction ports, master and slave, that connect to SoC Designer components.• Signal ports, master and slave, that are exported to HDL components.

Inside the transactor component, you must ensure that all the transaction read and write commandsfrom the SoC Designer component are translated into calls to the driveSignal and read functions of theHDL signal ports.

Related references3.1 Configuring CDP on page 3-35.

3 CDP HDL Cosimulation Reference3.8 Creating a new transactor


3.9 Direct HDL signal linkingDirect HDL signal linking means that signal ports of a component in SoC Designer are linked directly tosignals of a component in an HDL simulator without using a transactor.

In most cases, for signal ports of a component instantiated in Canvas, you simply configure the signalport for Cosimulation. If you are linking an active-LOW signal to an active-HIGH signal, you canmodify the RTL code to invert the signal, or you can configure the signal port of the SoC Designercomponent to different activity levels in the HDL Cosimulation configuration dialog.

For a signal master port of a SoC Designer component configured for Cosimulation, the signal on theRTL side keeps the value driven until a different value is driven by the SoC Designer component. For asignal slave port of a SoC Designer component configured for Cosimulation, the signal slave port of theSoC Designer component takes the value transferred to it from the Cosimulation kernel only once until adifferent value is driven by RTL.

3.9.1 Signal master ports

If connected through Cosimulation, data from a signal master port of a SoC Designer component is aninput to a component of the design in the HDL simulator.

From the SoC Designer side, you drive data to RTL by calling the driveSignal function on the signalmaster port. When you call the driveSignal function from the SoC Designer component, theCosimulation kernel samples the data and sends the data to the HDL simulator. Even if the driveSignalfunction is called with unchanged data, the Cosimulation kernel drives the signal data to the HDLsimulator.

For signals with bit width larger than one, the most significant bit in the model is mapped to the mostsignificant bit of the connected RTL signal. For signals with bit width larger than 32, the lowest wordmaps to the value parameter and the upper word(s) map to the second parameter (a pointer to a 32-bitarray) in the driveSignal function.

3.9.2 Signal slave ports

If connected through simulation, output data from an HDL simulator is transferred to the signal slaveport of a SoC Designer component.

The Cosimulation kernel calls the driveSignal function of the signal slave port to hand over the outputdata. The driveSignal function is only triggered by the Cosimulation kernel on signal data changes.That is, if the driveSignal function is called, it means that data has arrived from the HDL simulator.

For signals with bit width larger than one, the most significant bit in the connected signal in RTL ismapped to the most significant bit in the model. For signals with bit width larger than 32, the lowestword maps to the value parameter and the upper word(s) map to the second parameter (a pointer to a 32-bit array) in the driveSignal function.

3 CDP HDL Cosimulation Reference3.9 Direct HDL signal linking


Appendix AAMBA® 3 AXI4 Transactors

This appendix describes the AXI4 Cosimulation transactor models.

It contains the following sections:• A.1 About the AXI4 transactors on page Appx-A-52.• A.2 Component port interfaces on page Appx-A-53.• A.3 Model parameters on page Appx-A-54.• A.4 Supported signal bit widths on page Appx-A-55.• A.5 RTL memory debug support on page Appx-A-58.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-A-51Non-Confidential

A.1 About the AXI4 transactorsThis appendix describes the AXI4_S2T and AXI4_T2S transactor models that serve as convertersbetween AXI transactions and AXI hardware signals.

A.1.1 AXI transactor functionality

The AXI4_S2T and AXI4_T2S components have signal ports corresponding to the AXI hardwaresignals.

The AXI4_S2T component contains an AXI transaction master port and the AXI4_T2S componentcontains an AXI transaction slave port. The AXI transaction ports use the CASI AXI4 transactionprotocol. See the AXI4 Protocol Bundle User Guide (ARM DUI 0955) for further information on theAXI4 protocol.

The components do not expose nor display their internal state except for memory in RTL memory debugmode. All transaction information is viewed using monitor and trace probes that must be placed on therespective connections. No statistical transaction information is collected for the SoC Designer profiling.This information is available from the respective bus components.

The AXI4_T2S transactor supports the RTL memory debug feature.

Related referencesA.5 RTL memory debug support on page Appx-A-58.

A AMBA® 3 AXI4 TransactorsA.1 About the AXI4 transactors


A.2 Component port interfacesThe following figure shows the AXI4_S2T and the AXI4_T2S models within SoC Designer with allports.

Figure A-1 AXI4_S2T and AXI4_T2S models

A AMBA® 3 AXI4 TransactorsA.2 Component port interfaces


A.3 Model parametersThe following table lists the parameters of the AXI4_S2T and AXI4_T2S models.

Table A-1 AXI4_S2T and AXI4_T2S model parameters

Parameter Description

Enable Debug Messages When set to true, the model debug messages are displayed as output.

Protocol Variant Select from the following options: ACE, ACE-Lite+DVM, ACE-Lite, AXI4, AXI4-Lite.

A AMBA® 3 AXI4 TransactorsA.3 Model parameters


A.4 Supported signal bit widthsThe following table lists the AXI signals supported by the AXI4 transactors.

The supported bit widths adhere to those designated in the ARM AMBA AXI Protocol Specifications. Thetransactors must not be connected to RTL signals whose respective bit widths do not appear in the table.

Table A-2 Supported signal bit widths

Signal Name AXI Master and Slave Interface Transactors

AWID 4 (see note)

AWADDR 32~64

AWLEN 8

AWSIZE 3

AWBURST 2

AWLOCK 1

AWCACHE 4

AWPROT 3

AWQOS 4

AWREGION 4

AWUSER 1-64

AWSNOOP 3

AWDOMAIN 2

AWBAR 2

AWVALID 1

AWREADY 1

WDATA 32, 64, 128

WSTRB 4

WLAST 1

WVALID 1

WREADY 1

WUSER 32

BID 4 (see note)

BRESP 2

BVALID 1

BREADY 1

BUSER 32

ARID 4 (see note)

ARADDR 32~64

ARLEN 8

A AMBA® 3 AXI4 TransactorsA.4 Supported signal bit widths


Table A-2 Supported signal bit widths (continued)


ARSIZE 3

ARBURST 2

ARLOCK 1

ARCACHE 4

ARPROT 3

ARQOS 4

ARREGION 4

ARSNOOP 4

ARDOMAIN 2

ARBAR 2

ARVALID 1

ARREADY 1

ARUSER 32

RID 4 (see note)

RDATA 32, 64, 128

RRESP 2

RLAST 1

RVALID 1

RREADY 1

RUSER 32

ACVALID 1

ACREADY 1

ACADDR 32

ACSNOOP 4

ACPROT 3

CRVALID 1

CRREADY 1

CRRESP 5

CDVALID 1

CDREADY 1

CDDATA 32, 64

CDLAST 1

RACK 1

WACK 1



Note

SoC Designer HDL Cosimulation setup configures these bit widths as 32 by default. You must changethese bit widths to 4 to comply with the ARM AMBA AXI Protocol Specifications before connectingthese signals to their RTL components.

A.4.1 Configuring bit width for address and data

Based on how you have configured the signal bit widths via the HDL Cosimulation Setup, the signalwidths of the transactor are automatically adjusted to match, therefore there is no need to set address anddata bit width parameters like with the earlier AXIv1 transactors.



A.5 RTL memory debug supportThe AXI4_T2S model supports an RTL memory view window. Right click on the component in SoCDesigner Simulator and select the menu item to show the window. The byte memory contents displayedin the window are synchronized with the RTL memory attached to the transactor.

This enables you to change the actual RTL memory from the memory view window in SoC DesignerSimulator. Memory changes on the RTL side are also reflected in the window.

The AXI4_S2T and AXI4_T2S models contain a memdbg transaction port. This port is required for fullfunctionality of Cosimulation features. In AXI4_T2S, it also implements the memory interface for RTLmemory debug mode. Using this feature is optional. If you decide not to use RTL debug mode, this portcan be hidden but not disabled. The port is automatically hidden for the user once HDL Cosimulationsetup is run for the first time, regardless of whether RTL memory debug view is used or not, so. you canignore this port.

For information on memory debugging in SoC Designer, see the Memory windows section of theDebugging chapter of the SoC Designer User Guide (ARM DUI 0956).

Note

To make this feature available in your design, you must modify your HDL source code.


A AMBA® 3 AXI4 TransactorsA.5 RTL memory debug support


Appendix BAMBA® 3 AXIv2 Transactors

This appendix describes the AXIv2 Cosimulation transactor models.

It contains the following sections:• B.1 About the AXIv2 transactors on page Appx-B-60.• B.2 Component port interfaces on page Appx-B-61.• B.3 Model parameters on page Appx-B-62.• B.4 Supported signal bit widths on page Appx-B-63.• B.5 RTL memory debug support on page Appx-B-65.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-B-59Non-Confidential

B.1 About the AXIv2 transactorsThis appendix describes the AXIv2_S2T and AXIv2_T2S transactor models that serve as convertersbetween AXI transactions and AXI hardware signals.

B.1.1 AXI transactor functionality

The AXIv2_S2T and AXIv2_T2S components have signal ports corresponding to the AXI hardwaresignals.

The AXIv2_S2T component contains an AXI transaction master port and the AXIv2_T2S componentcontains an AXI transaction slave port. The AXI transaction ports use the CASI AXIv2 transactionprotocol. See the AXIv2 Protocol Bundle User Guide (ARM DUI 0998) for further information on theAXIv2 protocol.

The components do not expose nor display their internal state except for memory in RTL memory debugmode. All transaction information is viewed using monitor and trace probes that must be placed on therespective connections. No statistical transaction information is collected for the SoC Designer profiling.This information is available from the respective bus components.

The AXIv2_T2S transactor supports the RTL memory debug feature.

Related referencesB.5 RTL memory debug support on page Appx-B-65.

B AMBA® 3 AXIv2 TransactorsB.1 About the AXIv2 transactors


B.2 Component port interfacesThe following figure shows the AXIv2_S2T and the AXIv2_T2S models within SoC Designer with allports.

Figure B-1 AXIv2_S2T and AXIv2_T2S models

B AMBA® 3 AXIv2 TransactorsB.2 Component port interfaces


B.3 Model parametersThe following table lists the parameter of the AXIv2_S2T and AXIv2_T2S models.

Table B-1 AXIv2_S2T and AXIv2_T2S model parameters

Name Type Description

Enable Debug Messages boolean This parameter specifies whether Debug messages are enabled. This is a run-time parameter.

B AMBA® 3 AXIv2 TransactorsB.3 Model parameters


B.4 Supported signal bit widthsThe following table lists the AXI signals supported by the AXIv2 transactors.

The supported bit widths adhere to those designated in the ARM® AXI Protocol 1.0 Specification. Thetransactors must not be connected to RTL signals whose respective bit widths do not appear in the table.

Table B-2 Supported signal bit widths


AWID 4 (see note)

AWADDR 32~64

AWLEN 4

AWSIZE 3

AWBURST 2

AWLOCK 2

AWCACHE 4

AWPROT 3

AWVALID 1

AWREADY 1

AWUSER (optional signal) 32

WID 4 (see note)

WDATA 32, 64, 128

WSTRB 4

WLAST 1

WVALID 1

WREADY 1

WUSER (optional signal) 32

BID 4 (see note)

BRESP 2

BVALID 1

BREADY 1

BUSER (optional signal) 32

ARID 4 (see note)

ARADDR 32~64

ARLEN 4

ARSIZE 3

ARBURST 2

ARLOCK 2

ARCACHE 4

B AMBA® 3 AXIv2 TransactorsB.4 Supported signal bit widths


Table B-2 Supported signal bit widths (continued)


ARPROT 3

ARVALID 1

ARREADY 1

ARUSER (optional signal) 32

RID 4 (see note)

RDATA 32, 64, 128

RRESP 2

RLAST 1

RVALID 1

RREADY 1

RUSER (optional signal) 32

Note

For AWID, AWID, BID, ARID, and RID signals, SoC Designer HDL Cosimulation setup configures bitwidths as 32 by default. You must change these bit widths to 4 to comply with the ARM AXI Protocol1.0 Specification before connecting these signals to their RTL components.

Note

AWUSER, WUSER, BUSER, ARUSER, and RUSER are optional signals and they do not need to beconnected.

B.4.1 Configuring bit width for address and data

Based on how you have configured the signal bit widths via the HDL Cosimulation Setup, the signalwidths of the transactor are automatically adjusted to match, therefore there is no need to set address anddata bit width parameters like with the earlier AXIv1 transactors.

B AMBA® 3 AXIv2 TransactorsB.4 Supported signal bit widths


B.5 RTL memory debug supportThe AXIv2_T2S model supports an RTL memory view window.

Right-click on the component in SoC Designer Simulator and select the menu item to show the window.The byte memory contents displayed in the window are synchronized with the RTL memory attached tothe transactor.

This enables you to change the actual RTL memory from the memory view window in SoC DesignerSimulator. Memory changes on the RTL side are also reflected in the window.

The AXIv2_S2T and AXIv2_T2S models contain a memdbg transaction port. This port is required forfull functionality of Cosimulation features. In AXIv2_T2S, it also implements the memory interface forRTL memory debug mode. Using this feature is optional. If you decide not to use RTL debug mode, thisport can be hidden but not disabled. The port is automatically hidden for the user once HDLCosimulation setup is run for the first time, regardless of whether RTL memory debug view is used ornot, so. you can ignore this port.

For information on memory debugging in SoC Designer, see the Memory windows section of theDebugging chapter of the SoC Designer User Guide (ARM DUI 0956).

Note



B AMBA® 3 AXIv2 TransactorsB.5 RTL memory debug support


Appendix CAMBA® 2 AHBv2 Transactors

This appendix describes the AHBv2 HDL Cosimulation transactor models.

It contains the following sections:• C.1 About the AHBv2 transactors on page Appx-C-67.• C.2 AHBv2M_T2S transactor features on page Appx-C-69.• C.3 AHBv2M_S2T transactor features on page Appx-C-71.• C.4 AHBv2S_T2S transactor features on page Appx-C-73.• C.5 AHBv2S_S2T transactor features on page Appx-C-75.• C.6 Debugging features on page Appx-C-77.• C.7 Supported signal bit widths on page Appx-C-78.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-C-66Non-Confidential

C.1 About the AHBv2 transactorsThis document describes the following AHBv2 HDL Cosimulation transactor models:

• AHBv2M_T2S• AHBv2M_S2T• AHBv2S_T2S• AHBv2S_S2T• AHBv2LiteM_T2S• AHBv2LiteM_S2T• AHBv2LiteS_T2S• AHBv2LiteS_S2T

The AHB transaction ports use the CASI AHBv2 transaction protocol. See the AHBv2 Protocol BundleUser Guide (ARM DUI1080) for further information on the AHBv2 protocol.

C.1.1 Naming conventions for AHBv2 transactors

An AHBv2 transactor is named as AHBv2[Lite]X1_X22X3, where:

• [Lite] indicates that the transactor supports AHBv2-Lite interfaces.• X1 is M for AHBv2 master interface signals.• X1 is S for AHBv2 slave interface signals.• X2 is T indicates the slave interface is a transaction port and an AHBv2-master SoC Designer

component can be connected to the port.• X2 is S indicates the slave interface consists of a set of signal ports that represent RTL AHB signals.• X3 is T indicates the master interface is a transaction port and an AHBv2-slave SoC Designer

component can be connected to the port.• X3 is S indicates the master interface consists of a set of signal ports that represent RTL AHB signals.• The string X22X3 must be T2S or S2T for a transactor.

For example, AHBv2M_T2S is an AHB bus protocol transactor whose signal ports are equivalent tothose of an AHB master interface.

Note

AHB protocol signals are asymmetric. For example, an AHB master signal interface and an AHB slavesignal interface are not identical.

C.1.2 AHBv2 Transactor Functionality

The following table describes each AHBv2 transactor provided in CDP.

C AMBA® 2 AHBv2 TransactorsC.1 About the AHBv2 transactors


Table C-1 AHBv2 Transactor Functionality

Transactor Name AHB Interfacerepresentedby the signalports

TLM porttype ofTransactor

Usage Example

AHBv2M_T2S Master Slave This transactor connects a TLMmaster port of an AHB SoC Designercomponent that models AHB masterinterface and an AHB RTL master businterface.

Between the ARM926EJ-S SoCDesigner component's TLM AHBmaster port and AHB master businterface of an AHB RTL bus

AHBv2M_S2T Master Master This transactor connects an AHB RTLmaster bus interface and a TLM slaveport of an AHB SoC Designercomponent that models AHB masterinterface.

Between ARM's AHB FRBM master(RTL)'s bus interface and the TLMAHB slave port of SoC DesignerMxAHBv2 component

AHBv2S_T2S Slave Slave This transactor can connects a TLMmaster port of an AHB SoC Designercomponent that models AHB slaveinterface and an AHB RTL slave businterface.

Between an RTL memory's AHBslave bus interface and the TLMAHB master port of MxAHBv2component

AHBv2S_S2T Slave Master This transactor connects an AHB RTLslave bus interface and a TLM slaveport of an AHB SoC Designercomponent that models AHB slaveinterface.

Between an AHB RTL bus's AHBslave bus interface and the TLMAHB slave port of AHBv2_Memcomponent

AHBv2LiteM_T2S Master Slave This transactor connects a TLMmaster port of a SoC Designercomponent's master port that modelsAHB master interface and an AHB-Lite RTL master bus interface.

Between ARM926EJ-S SoCDesigner component's TLM AHBmaster port combination and AHB-Lite master bus interface of a RTLmemory.

AHBv2LiteM_S2T Master Master This transactor connects an AHB-LiteRTL master bus interface and a TLMslave port of an AHB SoC Designercomponent that models AHB masterinterface.

Between ARM's AHB-Lite FRBMmaster (RTL)'s bus interface and theTLM AHB slave port of SoCDesigner MxAHBv2 component(MxAHBv2 must have theAHBLiteM_S2T as its only master)

AHBv2LiteS_T2S Slave Slave This transactor connects a TLMmaster port of an AHB SoC Designercomponent that models AHB slaveinterface and an AHB-Lite RTL slavebus interface.

Between the TLM AHB master portof MxAHBv2 component and anRTL memory's AHB-Lite slave businterface

AHBv2LiteS_S2T Slave Master This transactor connects an AHB-LiteRTL slave bus interface and a TLMslave port of an AHB SoC Designercomponent that models AHB slaveinterface.

Between an AHB-Lite RTL bus'sslave interface and the TLM AHBslave port of AHBv2_Memcomponent

C AMBA® 2 AHBv2 TransactorsC.1 About the AHBv2 transactors


C.2 AHBv2M_T2S transactor featuresThe following figure shows the ports of the AHBv2M_T2S transactor.

Figure C-1 AHBv2M_T2S component

C.2.1 SoC Designer interfaces

The following table describes the interfaces of the AHBv2M_T2S transactor.

Table C-2 AHBv2M_T2S interfaces

Interface Description

Signal ports Signal ports represent the interface for an AMBA AHB master. The hrdata and hwdata bit widths can be set to 32,64, or 128 during the SoC Designer HDL Cosimulation setup process, see C.7 Supported signal bit widthson page Appx-C-78. The reset() phase of the simulation checks that data widths are set correctly.

Transactionports

The ahb_s transaction port implements the MxAHBv2 slave interface. This port must be connected to the master portof a SoC Designer component whose master port models an RTL AHB master interface. For example, ARM926EJ-SSoC Designer component's data ahb master port can be connected to this, but the master port of an MxAHBv2component cannot be connected to it.

The memdbg transaction port implements a memory interface for RTL debug mode. AHBv2M_T2S can supportdirect RTL memory manipulation through this port. Using this feature is optional. If you do not use RTL debug mode,this port is hidden but not disabled. The port is also automatically hidden once HDL Cosimulation setup is run for thefirst time, regardless of whether RTL memory debug view is used. If you use this feature, from the memory view inSoC Designer Simulator, you can view and edit the contents of the RTL memory attached to AHBv2M_T2S.

C.2.2 Model parameters

The following table lists the parameter of the AHBv2M_T2S model.

C AMBA® 2 AHBv2 TransactorsC.2 AHBv2M_T2S transactor features


Table C-3 AHBv2M_T2S parameters

Parameter Type Description

Enable Debug Messages boolean This parameter specifies whether Debug messages are enabled. This is a run-time parameter.

C.2.3 Connecting transactor signals to an HDL module

The transactor signal names reflect the RTL signal names that they connect to. For example, the hrdatasignal port of the AHBv2M_T2S transactor connects to the hrdata output signal of an AHBv2 RTL bussubsystem.

C.2.4 AHB-Lite support

The AHBv2LiteM_T2S model is derived from AHBv2M_T2S and is functionally equivalent except thatit operates under the AHB-Lite protocol. The AHBv2LiteM_T2S therefore does not contain hgrant andhbusreq signals ports since they are not part of the Lite variant of the protocol because multi-masterconfigurations are not supported.

The AHBv2LiteM_T2S model is shown in the following figure.

Figure C-2 AHBv2LiteM_T2S component

C AMBA® 2 AHBv2 TransactorsC.2 AHBv2M_T2S transactor features


C.3 AHBv2M_S2T transactor featuresThe following figure shows the ports of the AHBv2M_S2T transactor.

Figure C-3 AHBv2M_S2T component


The following table describes the interfaces of the AHBv2M_S2T transactor.

Table C-4 AHBv2M_S2T interfaces


Signal ports AHBv2M_S2T signal ports represent the interface for an AMBA AHB master. The hrdata and hwdata bit widthscan be set to 32, 64, or 128 during SoC Designer HDL Cosimulation setup process, see C.7 Supported signal bitwidths on page Appx-C-78. The reset() phase of the simulation checks that data widths are set correctly.

Transactionports

The ahb_m transaction port implements the MxAHBv2 master interface. This port must be connected to a slaveport on MxAHBv2.

The memdbg transaction port is required to support full functionality of Cosimulation features. This port can behidden but not disabled. The port is automatically hidden for the user once HDL Cosimulation setup is run for thefirst time.


The following table lists the parameter of the AHBv2M_S2T model.

Table C-5 AHBv2M_S2T model parameters


Enable Debug Messages boolean Debug messages are enabled if set to “true”. This is a run-time parameter.

C AMBA® 2 AHBv2 TransactorsC.3 AHBv2M_S2T transactor features



The transactor signal names reflect the RTL signal names that they connected to. For example, thehready signal port of the AHBv2M_S2T must be connected to the hready input signal of an AHBv2RTL master.


The AHBv2LiteM_S2T model is derived from AHBv2M_S2T and is functionally equivalent except thatit operates under the AHB-Lite protocol. The AHBv2LiteM_S2T therefore does not contain hgrant andhbusreq signals ports as they are not part of the “Lite” variant of the protocol because multi-masterconfigurations are not supported.

The following figure shows the AHBv2LiteM_S2T model.

Figure C-4 AHBv2LiteM_S2T component

C AMBA® 2 AHBv2 TransactorsC.3 AHBv2M_S2T transactor features


C.4 AHBv2S_T2S transactor featuresThe following figure shows the ports of the AHBv2S_T2S transactor.

Figure C-5 AHBv2S_T2S transactor


The following table describes the interfaces of the AHBv2S_T2S transactor.

Table C-6 AHBv2S_T2S interfaces


Signal ports AHBv2S_T2S signal ports represent the interface for an AMBA AHB slave. The hrdata and hwdata bit widths canbe set to 32, 64, or 128 during SoC Designer HDL Cosimulation setup process, see C.7 Supported signal bit widthson page Appx-C-78. The reset() phase of the simulation checks that data widths are set correctly.

Transactionports

The ahb_s transaction port implements the MxAHBv2 slave interface. This port must be connected to the bus masterport on MxAHBv2.

The memdbg transaction port implements a memory interface for RTL debug mode. AHBv2S_T2S can support directRTL memory manipulation using this port. Using this feature is optional. If you decide not to use RTL debug mode,this port can be hidden but not disabled. The port is automatically hidden for the user once HDL Cosimulation setupis run for the first time, regardless of whether RTL memory debug view is used or not. If this feature is used, you canview and edit the contents of the RTL memory attached to AHBv2S_T2S from the memory view in SoC DesignerSimulator. For complete setup and usage information regarding this feature, see 3.5 Modifying RTL memory codes fordebug support on page 3-44. For information on debugging with memory windows, see the Memory windows sectionof the Debugging chapter of the SoC Designer User Guide (ARM DUI 0956).


The following table lists the parameter of the AHBv2S_T2S model.

C AMBA® 2 AHBv2 TransactorsC.4 AHBv2S_T2S transactor features


Table C-7 AHBv2S_T2S model parameters


Enable Debug Messages boolean Debug messages are enabled if set to true. This is a run-time parameter.


The transactor signal names reflect the RTL signal names that they must be connected to. For example,hreadyout signal port of the AHBv2S_T2S must be connected to hreadyout output signal of an AHBv2RTL slave.


The AHBv2LiteS_T2S model is derived from AHBv2S_T2S and is functionally equivalent except that itoperates under the AHB-Lite protocol. The AHBv2LiteS_T2S therefore does not contain the hmastersignal port as it is not part of the Lite variant of the protocol because multi-master configurations are notsupported.

The AHBv2LiteS_T2S model is shown in the figure below.

Figure C-6 AHBv2LiteS_T2S component

C AMBA® 2 AHBv2 TransactorsC.4 AHBv2S_T2S transactor features


C.5 AHBv2S_S2T transactor featuresThe following figure shows the ports of the AHBv2S_S2T transactor.

Figure C-7 AHBv2S_S2T component


The following table describes the interfaces of the AHBv2S_S2T transactor.

Table C-8 AHBv2S_S2T interfaces


Signal ports AHBv2S_S2T signal ports represent the interface for an AMBA AHB slave. The hrdata and hwdata bit widths canbe set up to 32, 64, or 128 during SoC Designer HDL Cosimulation setup process, see C.7 Supported signal bitwidths on page Appx-C-78. A check is performed during the reset() phase of the simulation to ensure data widthsare set up correctly.

Transactionports

The ahb_m transaction port implements the MxAHBv2 slave interface. This port must be connected to a slave porton AHBv2_Mem.

The memdbg transaction port is required to support full functionality of Cosimulation features. This port can behidden but not disabled. The port is automatically hidden for the user once HDL Cosimulation setup is run for thefirst time. For all intents and purposes, this port can be ignored by the user.


The following table lists the parameter of the AHBv2S_S2T model.

C AMBA® 2 AHBv2 TransactorsC.5 AHBv2S_S2T transactor features


Table C-9 AHBv2S_S2T model parameters


Enable Debug Messages boolean Debug messages are enabled if set to “true”. This is a run-time parameter.


Normally, the transactor signal names reflect the RTL signal names that they must be connected to.However, the hreadyout signal port of the AHBv2S_S2T must be connected to the slave-to-mastermultiplexor of the AHB RTL bus (as must hrdata and hresp). In other words, treat the hreadyout signalas if it were the hreadyout signal of an AHBv2 slave.


The AHBv2LiteS_S2T model is derived from AHBv2S_S2T and is functionally equivalent except that itoperates under the AHB-Lite protocol. The AHBv2LiteS_S2T therefore does not contain the hmastersignal port as it is not part of the “Lite” variant of the protocol because multi-master configurations arenot supported.

The AHBv2LiteS_S2T model is shown in the following figure.

Figure C-8 AHBv2LiteS_S2T component

C AMBA® 2 AHBv2 TransactorsC.5 AHBv2S_S2T transactor features


C.6 Debugging featuresThis section describes RTL memory debug support feature.

C.6.1 RTL memory debug support

The AHBv2M_T2S, AHBv2S_T2S, AHBv2LiteM_T2S, and AHBv2LiteS_T2S models support an RTLmemory view window. This window can be opened by right clicking on the component (in SoC DesignerSimulator) and selecting the menu item to show memory.

The byte memory contents displayed in the window are synchronized with the RTL memory attached tothe transactor. Thus, you can make changes to the actual RTL memory from the memory view window inSoC Designer Simulator. Conversely, memory changes on the RTL side are reflected in the window inaddition. Value changes that occur over the course of simulation appear in red.

For information on debugging with memory windows, see the Memory windows section of theDebugging chapter of the SoC Designer User Guide (ARM DUI 0956).

Note



Related referencesC.6.1 RTL memory debug support on page Appx-C-77.

C AMBA® 2 AHBv2 TransactorsC.6 Debugging features


C.7 Supported signal bit widthsThe following table lists the AHB signals supported by the transactors in this chapter.

The supported bit widths adhere to those designated in the ARM AMBA 2.0 Specification. Do not connectthese transactors to RTL signals whose respective bit widths do not appear in the table.

Table C-10 Supported signal bit widths

Signal name AHB Transactors

AHBv2M_T2S

AHBv2M_S2T

AHBv2S_T2S

AHBv2S_S2T

AHBv2LiteM_T2S

AHBv2LiteM_S2T

AHBv2LiteS_T2S

AHBv2LiteS_S2T

HADDR 32, 64 32, 64 32, 64 32, 64

HBSTRB 4, 8, 16 4, 8, 16 4, 8, 16 4, 8, 16

HDOMAIN 4 4 4 4

HUNALIGN 1 1 1 1

HTRANS 2 2 2 2

HWRITE 1 1 1 1

HSIZE 3 3 3 3

HBURST 3 3 3 3

HPROT 4 4 4 4

HWDATA 32, 64, 128 32, 64, 128 32, 64, 128 32, 64, 128

HSEL N/A 1 N/A 1

HRDATA 32, 64, 128 32, 64, 128 32, 64, 128 32, 64, 128

HREADY 1 1 1 1

HREADYOUT N/A 1 N/A 1

HRESP 2 2 2 2

HBUSREQ 1 N/A N/A N/A

HLOCK 1 N/A 1 1

HGRANT 1 N/A N/A N/A

HMASTER N/A 4 N/A N/A

HMASTLOCK N/A 1 N/A N/A

SIDEBAND0 (see note) 32 32 32 32



Note

These signals are optional. They do not need to be connected.

C AMBA® 2 AHBv2 TransactorsC.7 Supported signal bit widths


Appendix DAMBA® APB Transactors

The appendix describes the APB HDL Cosimulation models.

It contains the following sections:• D.1 About the APB transactors on page Appx-D-80.• D.2 Component port interfaces on page Appx-D-81.• D.3 Model parameters on page Appx-D-83.• D.4 Debugging features on page Appx-D-84.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-D-79Non-Confidential

D.1 About the APB transactorsThis appendix describes the APB HDL Cosimulation transactor models.

These models are the following:

• APB_T2S• APB_S2T• APB3_T2S• APB3_S2T

These models are used in Cosimulation and serve as converters between APB transactions and APBhardware signals.

Note

To determine the APB protocol version, check for the presence of the pready and pslverr signals. Thesesignals are present in version 3.0 of the APB protocol but not in version 2.0. These transactors are APB2.0 interfaces and may not be compatible with AMBA3 components.

D.1.1 APB transactor functionality

The two transactors have signal ports corresponding to the APB hardware signals. In addition, theAPB_S2T component contains an APB transaction master port, and the APB_T2S component containsan APB transaction slave port.

The components do not expose nor display any of their internal state except for memory in RTL memorydebug mode. You view all transaction information using monitor and trace probes on the respectiveconnections. No statistical transaction information is collected for SoC Designer profiling because thisinformation is available through the respective bus components.

D AMBA® APB TransactorsD.1 About the APB transactors


D.2 Component port interfacesThere are two types of models in SoC Designer: APB_S2T and the APB_T2S models and APB3_S2T andthe APB3_T2S models.

The following figure shows the APB_S2T and the APB_T2S models in SoC Designer. All ports arevisible.

Figure D-1 APB_S2T and APB_T2S components

The following figure shows the APB3_S2T and the APB3_T2S models in SoC Designer. All ports arevisible.

Figure D-2 APB_S2T and APB_T2S components

D.2.1 Differences in APB3 transactors

APB3 transactors (APB3_T2S and APB3_S2T) model AMBA APB3 and APB3 transactors (APB3_T2Sand APB3_S2T) model AMBA APB3 differ in their protocols as follows:

APB3_T2SThis transactor has two additional signal ports, as follows:1. pslverr (signal slave)2. pready (signal slave)

The transactor uses these signals to return different status values according as follows:

if (pready == 0) WAITelse if (pslverror == 1) ERRORelse OK

D AMBA® APB TransactorsD.2 Component port interfaces


APB3_T2SThis transactor has two additional signal ports, as follows:1. pslverr (signal master)2. pready (signal master)

The value exerted on these ports depends on the return value of the apb_m transaction masterport as follows:

if (return value == WAIT) pslverr = 0 pready = 0if (return value == ERROR) pslverr = 1 pready = 1if (return value == OK) pslverr = 0 pready = 1

D AMBA® APB TransactorsD.2 Component port interfaces


D.3 Model parametersThe following table lists the parameters of the APB transactor models.

Table D-1 APB transactor model parameters

Parameter Description

Address Width This parameter specifies the width of the address bus. It must match the address bus width of all connectedcomponents. The model only supports the default address width of 32 bits.

Data Width This parameter specifies the width of the data bus. The data width must match the data bus width of allconnected components. The model only supports the default data width of 32 bits.

apb_startN This parameter applies only to the APB_T2S model.

There are six parameters named apb_start with an index of 0-5 appended. The parameters define thestarting address of six non-overlapping, non-contiguous memory regions. The APB slave port registersthese regions with the connected APB master port. The apb_size parameter with matching index specifiesthe size of the region.

apb_sizeN This parameter applies only to the APB_T2S model.

There are six parameters named apb_size with an index 0-5 appended. The parameters define up to sixnon-overlapping, non-contiguous memory regions. The APB slave port registers these sizes with theconnected APB master port. The apb_start parameter with matching index specifies the region's baseaddress.

The size must be in the range of 0x000000FA0 to 0x100000000. A value of 0 disables a memory region.

Usecosim_config.xml

This parameter specifies whether the model uses the address and data bit widths specified in thecosim_config.xml.When this parameter is enabled, the model ignores the values of the Address Widthand Data Width parameters. Only 32 bits is currently supported for the address width and data width.

D AMBA® APB TransactorsD.3 Model parameters


D.4 Debugging featuresThe APB_T2S SoC Designer model supports an RTL memory view window. You open this window byright clicking on the component in SoC Designer Simulator and selecting the menu item to showmemory.

The byte memory contents displayed in the window are synchronized with the RTL memory attached tothe transactor. You can make changes to the actual RTL memory from the memory view window in SoCDesigner Simulator. The window also shows memory changes on the RTL side.

The APB_S2T and APB_T2S models contain a memdbg transaction port. This port provides fullfunctionality of Cosimulation features. In APB_T2S, it also implements the memory interface for RTLmemory debug mode. If you do not use RTL debug mode, you can hide but not disable this port. Theport is also automatically hidden once HDL Cosimulation setup is run for the first time, regardless ofwhether you use RTL memory debug view. For information on memory debugging in SoC Designer, seethe Memory windows section of the SoC Designer User Guide (ARM DUI 0956).

Note



D AMBA® APB TransactorsD.4 Debugging features


Appendix EConverting CDP 3.0 test bench files to CDP 4.0 testbench files

This appendix describes information that applies only to systems running CDP 3.0.

It contains the following section:• E.1 Upgrading to CDP 4.0 on page Appx-E-86.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-E-85Non-Confidential

E.1 Upgrading to CDP 4.0

There has been a major change to the cosimulation synchronization in order to add support forcombinatorial signals. See 3.3 CDP synchronization model on page 3-42 for more information. All theCDP 3.0 systems will continue to use old synchronization until they are upgraded to CDP 4.0 byfollowing these steps:1. Reconfigure your system by selecting Simulation → HDL Cosimulation → HDL Cosimulation

Setup in SoC Designer Canvas.2. Update your system to use the AXIv2 and AHBv2 transactors.3. Click OK to generate a new proxy module file in the logic simulation directory. Use this new proxy

module file instead of the old proxy module.

Figure E-1 Configuring Cosimulation4. You must rebuild the RTL test bench before starting Cosimulation. See Chapter 2 Installing and

Configuring Cosimulation Software on page 2-13 for more information.

Related concepts3.3 CDP synchronization model on page 3-42.

Related referencesChapter 2 Installing and Configuring Cosimulation Software on page 2-13.

E Converting CDP 3.0 test bench files to CDP 4.0 test bench filesE.1 Upgrading to CDP 4.0

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-E-86Non-Confidential

Appendix FTroubleshooting

This appendix provides information about Cosimulation functionality and troubleshooting scenarios.

It contains the following section:• F.1 Troubleshooting situations on page Appx-F-88.

ARM DUI1078A Copyright © 2017 ARM Limited or its affiliates. All rights reserved. Appx-F-87Non-Confidential

F.1 Troubleshooting situations

Using transactors in non-Cosimulation environments

The SoC Designer AHB and AXI transactor components in the SoC Designer CoDesign Package arespecially designed to work in Cosimulation environments with the HDL simulators described in thisdocument. ARM does not guarantee that they exhibit the correct behavior if used in anotherenvironment. These transactors rely on the SoC Designer Cosimulation kernel that enforces a specificordering between the signal-based data transfer of the transactors and the TLM-based data transfer ofSoC Designer components. If SoC Designer Simulator is run without Cosimulation enabled, the kernel isnot present to enforce the specific ordering of data transfers that the transactors expect, and their correctbehavior cannot be guaranteed.

Using the RTL memory debug feature in mixed-mode HDL Cosimulation

If RTL memory debug features are not used, SoC Designer supports mixed-mode HDL Cosimulationwith a capable HDL simulator. However if you want to use RTL memory debug, the mx_write andmx_read PLI function calls from modules written in a different language from the top-level module donot work. The only exception is a configuration running ModelSim with a VHDL top-level module.Lower level modules can be written in Verilog or VHDL and are enabled to make RTL memory debugVPI/FLI calls. To use this specific configuration, the HDL Simulation Command in the HDLCosimulation Options dialog must be modified to include the -pli libmxmsvlog_comm.so argument.

Cosimulation with Specman

Simulation may hang if a Specman script begins to run before SoC Designer and the HDL simulatorhave finished loading. Do not to start simulation until all three tools have completed loading. If you use ascript, you can resolve this issue by inserting timed waits.

When I start Cosimulation, a socket-related error message is printed out andCosimulation does not work

SoC Designer Cosimulation relies on file-based sockets for communication between SoC DesignerSimulator and an HDL simulator. in the following table lists error messages and possible causes.

Table F-1 Socket-related error messages

Error Message Possible Reasons Solution

Error binding thesocket

Cosimulation crashed previously. Remove any socket files (/tmp/mx*) on your system.

More than one session of Cosimulation is running ona single host without properly setting theMXCOSIM_SOCKFILENAME_SUFFIX environmentvariable

Set the environment variableMXCOSIM_SOCKFILENAME_SUFFIX properly to runmultiple sessions of Cosimulation on one host, see3.7 Controlling Cosimulation through environmentvariables on page 3-47.

Error readingsocket

Error writingsocket

Socket files removed or corrupted unintentionally Retry Cosimulation. Make sure the socket files are notremoved unintentionally by other applications or scripts.

More than one session of Cosimulation is running ona single host without properly setting theMXCOSIM_SOCKFILENAME_SUFFIX environmentvariable?

Set the environment variableMXCOSIM_SOCKFILENAME_SUFFIX properly to runmultiple sessions of Cosimulation on one host, see3.7 Controlling Cosimulation through environmentvariables on page 3-47.

Error creating thesocket

System error. Too many software applications areusing too many sockets on the system

Retry later or ask your system administrator for help.

F TroubleshootingF.1 Troubleshooting situations


Cleaning up my IPC shared memory to prevent shared memory errors

In Linux, use the ipcs -m command to display inter-process communication (IPC) shared memoryinformation. in the following example shows an example output from this command.

ipc command output

Shared Memory Segmentskey shmid owner perms bytes nattch status0x000bf5e7 137658370 user 600 32768 20x000bf5f2 137691139 user 600 1048576 20x000bf5f3 137723908 user 600 1048576 20x000b78bd 137756677 user 600 1048576 20x000b7922 137789446 user 600 1048576 1

To remove any stray segments, run ipcrm –m shmid where shmid is the shared memory id obtainedfrom the ipcs command, for example, 137658370.

To view the system settings for shared memory, run ipcs -ml. RTL memory debug mode requires atleast 4096 segments, 1024 kilobytes segment size, and 4096 kilobytes total shared memory. In Linux,shared memory is located in the host's /dev/shm mount. Delete all mxshm_*.username files in this pathto clean up POSIX shared memory on Linux. Your system administrator can help you adjust your systemsettings if necessary.

Cosimulation does not have the same initial functional behavior as RTL simulation

This problem can occur if the RTL test bench depends on a reset period. If the SoC Designer side of theCosimulation contains a core model that does not account for the reset, then the core model issuestransactions that cannot be properly handled by the RTL side under reset. Solve this by reducing the resetperiod in the RTL test bench so that the first transaction from SoC Designer is issued after the reset is off.

Can a simple signal port of a SoC Designer component be exposed to the HDL simulatorside without using a transactor

Yes. For more information, see 3.9 Direct HDL signal linking on page 3-50.

After restarting Cosimulation, clicking the Run button on VCS does not start simulationon SoC Designer Simulator

This is because of the callback limitation of VCS. To restart Cosimulation, you must restart VCS beforeyou start SoC Designer Simulator. See 2.9.3 VCS on page 2-32.

Can I use an inout port of an RTL module as the port between SoC Designer and an RTLsimulator

No. SoC Designer does not support inout ports. From your RTL module, you must separate them out intoinput and output ports and connect them to SoC Designer through Cosimulation.

Why am I getting shared memory error when starting Cosimulation (Windows)?

Check if your disk partition is configured as a FAT32 file system. An NTFS file system is required.FAT32 is not supported because of its file size limitation. Also, more than 4GB of free disk space isrequired. (4GB file is allocated during simulation and released upon termination.)

SoC Designer Simulator and the HDL simulator have started but when I click Run in SoCDesigner, nothing happens

If you use NCSim or VCS as the HDL simulator, you must click Run or Continue in NCSim or VCS,after you click Run in SoC Designer Simulator. This extra click is not necessary in ModelSim.



My SoC Designer top-level system contains a subsystem that has been configured forHDL cosimulation. When I start cosimulation from Canvas, it doesn't invoke an HDLsimulator.

SoC Designer Canvas does not examine a subsystem when a simulation starts. The system cannot invokean HDL simulator because it cannot determine if any of its subsystems are configured for HDL. Youmust separately invoke a SoC Designer simulation and an HDL simulation (see section 2.11, StartingSoC Designer Cosimulation).

ncelab fails and displays the error, "libgcc_s.so.1:version `GCC_3.3' not found".

Ensure that the LD_LIBRARY_PATH environment variable contains the library path for your gcc,preceding the path for the NCSim.

Related concepts3.9 Direct HDL signal linking on page 3-50.

Related tasks2.9.3 VCS on page 2-32.

Related references3.7 Controlling Cosimulation through environment variables on page 3-47.



Documents

SoC Designer CDP v4.1 HDL Cosimulation Guideinfocenter.arm.com/help/...soc_designer_cdp_v41_hdl_cosimulation_g… · SoC Designer CDP v4.1 HDL Cosimulation Guide Preface About this