Carbon Cortex-M3 User manual

Carbon Cortex-M3 Model
User Guide for
SoC Designer Plus
Carbon Model Version 4.0.0
For the ARM Cortex-M3 Processor
Silicon Version: r2p0
The Trusted Path to Accuracy ™
The information contained in this document is confidential information of Carbon Design Systems, Inc.,
and may not be duplicated or disclosed to unauthorized and/or third parties.

Carbon Design Systems, Inc. Confidential
Copyright
Copyright © 2003-2013 Carbon Design Systems, Inc. All rights reserved.
Files, documents or portions thereof presented on the Carbon Design Systems Internet server “Publication”, permits per-
sons to view, copy, and print the Publication subject to the following conditions:
• The Publication are to be kept strictly confidential
• Copies of the Publication will not be distributed
• Copies of the Publication must include the Carbon Design Systems copyright notice
• Carbon Design Systems logos may only be used with Carbon's expressed written permission, including but not lim-
ited to: linking through hyperlinks, electronic display, and print format.
Disclaimer of Warranty
This publication is provided “as is” without warranty of any kind, either expressed or implied, including, but not limited
to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. Carbon Design Sys-
tems assumes no responsibility for errors or omissions in this publication or other documents which are referenced by or
linked to this publication.
References to corporations, their services and products, are provided “as is” without warranty of any kind, either
expressed or implied. In no event shall Carbon Design Systems be liable for any special, incidental, indirect or conse-
quential damages of any kind, or any damages whatsoever, including, without limitation, those resulting from loss of
use, data or profits, whether or not advised of the possibility of damage, and on any theory of liability, arising out of or in
connection with the use or performance of this information.
This publication may include technical or other inaccuracies or typographical errors. Carbon Design Systems may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication and in the publication
itself at any time.
Trademarks
© 2003-2013 Carbon Design Systems, Inc. All rights reserved. Carbon Design Systems, the Carbon Design Systems
logo, Carbon Model Studio, Replay, OnDemand, SoC Designer, Software Before Silicon, SOC-VSP, Swap & Play, VSP,
The Answer to Validation, and The Trusted Path to Accuracy are trademarks or registered trademarks of Carbon Design
Systems, Incorporated in the United States and/or other countries.
ARM, AMBA and RealView are registered trademarks of ARM Limited. AHB, APB and AXI are trademarks of ARM
Limited. “ARM” is used to represent ARM Holdings plc; its operating company ARM Limited; and the regional subsid-
iaries ARM INC.; ARM KK; ARM Korea Ltd.; ARM Taiwan; ARM France SAS; ARM Consulting (Shanghai) Co.
Ltd.; ARM Belgium N.V.; ARM Embedded Technologies Pvt. Ltd.; and ARM Physical IP, Inc.
Microsoft, Windows 2000, and Windows XP are trademarks or registered trademarks of Microsoft Corporation in the
United States and/or other countries.
SystemC is a trademark of the Open SystemC Initiative.
All other trademarks, registered trademarks, and products referenced herein are the property of their respective owners.

Technical Support
If you have questions or problems concerning Carbon software, contact Technical Support.
Phone Support Hours: Monday–Friday
9:00 am–5:00 pm EST
Carbon Design Systems, Inc.
125 Nagog Park
Acton, MA 01720
Voice: [phone]
Asia: [phone]
Fax: [phone]
Email: [email protected]
Web: www.carbondesignsystems.com
Voice mail is available after hours. You may also access our on-line feedback form any time from the Support page of
the Carbon web site.
Document revised August 2013.

Carbon Design Systems, Inc. Confidential

Carbon Design Systems, Inc. Confidential
Contents
Chapter 1.
Using the Model Kit Component in SoC Designer Plus
Cortex-M3 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Fully Functional and Accurate Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
Fully Functional and Approximate Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
Hardware Features not Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
Differences from the ARM RVML Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
Features Additional to the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
Adding and Configuring the SoC Designer Plus Component . . . . . . . . . . . . . . . . . . . . . . . .1-4
Carbon SoC Designer Plus Component Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
Adding the Carbon Model to the Component Library . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
Adding the Component to the SoC Designer Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
Available Component ESL Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
Transaction Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8
Clock Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9
Setting Component Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9
Debug Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Register Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Run To Debug Point Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-19
Memory Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-20
Disassembly View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-20
Available Profiling Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21
Hardware Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21
Software Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21

vi Contents
Carbon Design Systems, Inc. Confidential

Carbon Design Systems, Inc. Confidential
Preface
A Carbon Model component is a library developed from ARM intellectual property (IP)
that is generated through Carbon Model Studio™. The model then can be used within a
virtual platform tool, for example, Carbon SoC Designer Plus.
About This Guide
This guide provides all the information needed to configure and use the Carbon Cortex-
M3 Model in Carbon SoC Designer Plus.
Audience
This guide is intended for experienced hardware and software developers who create com-
ponents for use with Carbon SoC Designer Plus. You should be familiar with the follow-
ing products and technology:
• Carbon SoC Designer Plus
• Hardware design verification
• Verilog or VHDL programming language

viii Preface
Carbon Design Systems, Inc. Confidential
Conventions
This guide uses the following conventions:
Also note the following references:
• References to C code implicitly apply to C++ as well.
• File names ending in .cc, .cpp, or .cxx indicate a C++ source file.
Convention Description Example
courier Commands, functions,
variables, routines, and
code examples that are set
apart from ordinary text.
sparseMem_t SparseMemCreate-
New();
italic New or unusual words or
phrases appearing for the
first time.
Transactors provide the entry and exit
points for data ...
bold Action that the user per-
forms. Click Close to close the dialog.
<text> Values that you fill in, or
that the system automati-
cally supplies.
<platform>/ represents the name of
various platforms.
[ text ] Square brackets [ ] indicate
optional text. $CARBON_HOME/bin/modelstudio
[ <filename> ]
[ text1 | text2 ] The vertical bar | indicates
“OR,” meaning that you
can supply text1 or text 2.
$CARBON_HOME/bin/modelstudio
[<name>.symtab.db |
<name>.ccfg ]

Preface ix
Carbon Design Systems, Inc. Confidential
Further reading
This section lists related publications by Carbon and by third parties.
Carbon SoC Designer Plus Documentation
The following publications provide information that relate directly to SoC Designer Plus:
• Carbon SoC Designer Plus Installation Guide
• Carbon SoC Designer Plus User Guide
• Carbon SoC Designer Plus Standard Model Library Reference Manual
• Carbon SoC Designer Plus AHBv2 Protocol Bundle User Guide
External publications
The following publications provide reference information about ARM® products:
• Cortex-M3 Technical Reference Manual
• AMBA 3 AHB-Lite Overview
• AMBA Specification (Rev 2.0)
• AMBA AHB Transaction Level Modeling Specification
• Architecture Reference Manual
• ARM RealView Model Debugger User Guide
See http://infocenter.arm.com/help/index.jsp for access to ARM documentation.
The following publications provide additional information on simulation:
• IEEE 1666™ SystemC Language Reference Manual, (IEEE Standards Association)
• SPIRIT User Guide, Revision 1.2, SPIRIT Consortium.

xPreface
Carbon Design Systems, Inc. Confidential
Glossary
AMBA Advanced Microcontroller Bus Architecture. The ARM open standard on-chip
bus specification that describes a strategy for the interconnection and manage-
ment of functional blocks that make up a System-on-Chip (SoC).
AHB Advanced High-performance Bus. A bus protocol with a fixed pipeline
between address/control and data phases. It only supports a subset of the func-
tionality provided by the AMBA AXI protocol.
APB Advanced Peripheral Bus. A simpler bus protocol than AXI and AHB. It is
designed for use with ancillary or general-purpose peripherals such as timers,
interrupt controllers, UARTs, and I/O ports.
AXI Advanced eXtensible Interface. A bus protocol that is targeted at high perfor-
mance, high clock frequency system designs and includes a number of fea-
tures that make it very suitable for high speed sub-micron interconnect.
Carbon Model A software object created by the Carbon Model Studio (or Carbon compiler)
from an RTL design. The Carbon Model contains a cycle- and register-accu-
rate model of the hardware design.
Carbon Model
Studio Carbon’s graphical tool for generating, validating, and executing hardware- accurate software models. It creates a Carbon Model, and it also takes a Car-
bon Model as input and generates a Carbon component that can be used in
SoC Designer Plus, Platform Architect, or OSCI SystemC for simulation.
CASI ESL API Simulation Interface, is based on the SystemC communication
library and manages the interconnection of components and communication
between components.
CADI ESL API Debug Interface, enables reading and writing memory and register
values and also provides the interface to external debuggers.
CAPI ESL API Profiling Interface, enables collecting historical data from a compo-
nent and displaying the results in various formats.
Component Building blocks used to create simulated systems. Components are connected
together with unidirectional transaction-level or signal-level connections.
ESL Electronic System Level. A type of design and verification methodology that
models the behavior of an entire system using a high-level language such as C
or C++.
HDL Hardware Description Language. A language for formal description of elec-
tronic circuits, for example, Verilog or VHDL.
RTL Register Transfer Level. A high-level hardware description language (HDL)
for defining digital circuits.
SoC Designer The full name is Carbon SoC Designer Plus. A high-performance, cycle accu-
rate simulation framework which is targeted at System-on-a-Chip hardware
and software debug as well as architectural exploration.
SystemC SystemC is a single, unified design and verification language that enables ver-
ification at the system level, independent of any detailed hardware and soft-
ware implementation, as well as enabling co-verification with RTL design.
Transactor Transaction adaptors. You add transactors to your Carbon component to con-
nect your component directly to transaction level interface ports for your par-
ticular platform.

Carbon Design Systems, Inc. Confidential
Chapter 1
Using the Model Kit Component in
SoC Designer Plus
This chapter describes the functionality of the Model component, and how to use it in
Carbon SoC Designer Plus. It contains the following sections:
•Cortex-M3 Functionality
•Adding and Configuring the SoC Designer Plus Component
•Available Component ESL Ports
•Setting Component Parameters
•Debug Features
•Available Profiling Data
1.1 Cortex-M3 Functionality
The Cortex-M3 processor is a low-power processor that features low gate count, low inter-
rupt latency, and low-cost debug. It is intended for deeply embedded applications that
require fast interrupt response features. The processor implements the ARMv7-M archi-
tecture.
This section provides a summary of the functionality of the model compared to that of the
hardware, and the performance and accuracy of the model. For details of the functionality
of the hardware that the model simulates, see the Cortex-M3 Technical Reference Manual.
•Fully Functional and Accurate Features
•Fully Functional and Approximate Features
•Hardware Features not Implemented
•Differences from the ARM RVML Model
•Features Additional to the Hardware

1-2 Using the Model Kit Component in SoC Designer Plus
Carbon Design Systems, Inc. Confidential
1.1.1 Fully Functional and Accurate Features
The following features of the Cortex-M3 hardware are fully implemented in the Cortex-
M3 model:
• Cortex-M3 Integer Core
• NVIC – Nested Vectored Interrupt Controller
• WIC – Wakeup Interrupt Controller
• AHB-Lite: ICode, DCode, and System Bus Interfaces
• APB v3.0 interface for accessing the external Private Peripheral Bus
• FPB – Flash Patch and Debug
• DWT – Debug Watchpoint and Trace
• MPU – Memory Protection Unit
• BusMatrix (including Unaligned and Bit-Banding)
•ROMTable
1.1.2 Fully Functional and Approximate Features
The following features of the Cortex-M3 hardware are implemented in the Cortex-M3
model, but the exact behavior of the hardware implementation is not accurately repro-
duced because some approximations and optimizations have been made for simulation
performance:
• ROM Table. The ROM Table contains entries for ITM, TPIU, and ETM, even though
these components are not modeled.
• FAULT Handling. All faults are functionally handled, but there may be cycle inaccu-
racies.
Note on Clock-gating.
The Cortex-M3 supports architectural clock-gating only. This is controlled by setting the
CLKGATE_PRESENT parameter to 1in the default.conf configuration file before creating
the Model. See the Cortex-M3 Configuration and Sign-off Guide for more information.
The Carbon Model does not currently support RTL clock-gating.
1.1.3 Hardware Features not Implemented
The following features of the Cortex-M3 hardware are not implemented in the Cortex-M3
model:
• SW/JTAG-DP
•ITM
• ETM
• TPIU
• AHB-AP

Cortex-M3 Functionality 1-3
Carbon Design Systems, Inc. Confidential
• Current Priority Output
• RTL clock-gating
• The following registers are not available to be read / written via debug transactions —
for example, in the SoC Designer Plus Registers window, or by accessing them
directly from RealView Debugger:
– Core register: PRI_ISR, PRIMASK, BASEPRI, FAULTMASK, CONTROL,
CURRPRI
– NVIC register: CprAccess, SoftwareInt
– Debug register: DebugCoreRegisterTransferSelector
– Pipeline register: not supported
– Stats register: not supported
The functionality of these registers, however, does exist and can be accessed by soft-
ware running on the virtual platform.
1.1.4 Differences from the ARM RVML Model
The following differences exist between the Carbon Model and the older ARM® Real-
View® Model Library model.
• The Carbon model uses the AHB-Lite v2 port interface instead of the AHB v1 inter-
face used by the RVML model.
• No software profiling is available.
• When using semihosting you must use the semihost component from Carbon. This
“CarbonSemihost” component is included in the Carbon SoC Designer Plus Standard
Model Library, version 3.0 or greater. The ARM RVML semihost component will not
work with the Carbon Model.
• Differences in component ports:
– The RVML component treats the systickClkIn port like a clock and defines it as a
clock input. Based on the Cortex-M3 Technical Reference Manual, this should not
be a clock, so the Carbon Model treats it like a slave port.
– The following ports are not available in the Carbon Model: WAKEUP,
WAKEUPEN, WICSENSE, and semihostbus.
– The following ports have been added to the Carbon Model: extSemi.
• Differences in component parameters:
– The following parameters are not available in the Carbon Model: CodeSpace
block size, SystemSpace block size, external PPB block size, enable tracing,
enable WIC, SemiHosting parameters, LvlWidth, NumIRQ, profiling ALU/LSU
CPI, Tracing parameters, and use MME parameters.
– The following parameters have been added to the Carbon Model: DNOTITRANS,
Enable PC Tracing, and PC Tracing File.
• Only the Core Events profiling stream is supported; all other streams from the RVML
model are not profiled.

1-4 Using the Model Kit Component in SoC Designer Plus
Carbon Design Systems, Inc. Confidential
1.1.5 Features Additional to the Hardware
The following features that are implemented in the Cortex-M3 model to enhance usability
do not exist in the Cortex-M3 hardware:
• Semihosting Support. Semihosting enables the target application to communicate with
the host operating system. This is used for external time synchronization, file handling
operations, console input/output, and similar functionality.
• Debug and Profiling. For more information about debug and profiling features, refer
to the sections Debug Features and Available Profiling Data, respectively.
• The “run to debug point” feature has been added. This feature forces the debugger to
advance the processor to the debug state instead of having the model get into a non-
debuggable state. See “Run To Debug Point Feature” on page 1-19 for more informa-
tion.
1.2 Adding and Configuring the SoC Designer Plus Component
The following topics briefly describe how to use the component. See the Carbon SoC
Designer Plus User Guide for more information.
•Carbon SoC Designer Plus Component Files
•Adding the Carbon Model to the Component Library
•Adding the Component to the SoC Designer Canvas
1.2.1 Carbon SoC Designer Plus Component Files
The component files are the final output from the Carbon Model Studio compile and are
the input to SoC Designer Plus. There are two versions of the component; an optimized
release version for normal operation, and a debug version.
On Linux, the debug version of the component is compiled without optimizations and
includes debug symbols for use with gdb. The release version is compiled without debug
information and is optimized for performance.
On Windows, the debug version of the component is compiled referencing the debug run-
time libraries so it can be linked with the debug version of SoC Designer Plus. The release
version is compiled referencing the release runtime library. Both release and debug ver-
sions generate debug symbols for use with the Visual C++ debugger on Windows.

Adding and Configuring the SoC Designer Plus Component 1-5
Carbon Design Systems, Inc. Confidential
The provided component files are listed below:
Additionally, this User Guide PDF file and a ReadMe text file are provided with the com-
ponent.
1.2.2 Adding the Carbon Model to the Component Library
The compiled Carbon Model component is provided as a configuration file (.conf). To
make the component available in the Component Window in SoC Designer Canvas, per-
form the following steps:
1. Launch SoC Designer Canvas.
2. From the File menu, select Preferences.
3. Click on Component Library in the list on the left.
4. Under the Additional Component Configuration Files window, click Add.
5. Browse to the location where the SoC Designer Plus model is located and select the
component configuration file:
–maxlib.lib<model_name>.conf (for Linux)
–maxlib.lib<model_name>.windows.conf (for Windows)
6. Click OK.
7. To save the preferences permanently, click the OK & Save button.
The component is now available from the SoC Designer Plus Component Window.
Table 1-1 Carbon SoC Designer Plus Component Files
Platform File Description
Linux maxlib.lib<model_name>.conf
lib<component_name>.mx.so
lib<component_name>.mx_DBG.so
SoC Designer Plus configuration file
SoC Designer Plus component runtime file
SoC Designer Plus component debug file
Windows maxlib.lib<model_name>.windows.conf
lib<component_name>.mx.dll
lib<component_name>.mx_DBG.dll
SoC Designer Plus configuration file
SoC Designer Plus component runtime file
SoC Designer Plus component debug file

1-6 Using the Model Kit Component in SoC Designer Plus
Carbon Design Systems, Inc. Confidential
1.2.3 Adding the Component to the SoC Designer Canvas
Locate the component in the Component Window and drag it out to the Canvas. It will
appear as shown in Figure 1-1.
Figure 1-1 Cortex-M3 Components in SoC Designer Plus
Additional ports are provided depending on the model RTL configuration file,
default.conf, used to create the Model.
1.3 Available Component ESL Ports
Table 1-2 describes the ESL ports that are exposed in SoC Designer Plus. See the Cortex-
M3 Technical Reference Manual for more information.
Table 1-2 ESL Component Ports
ESL Port Description Direction Type
AUXFAULT Auxiliary fault status information. It is the input to
AFSR (Auxiliary Fault Status Register in NVIC),
where value = fault number (0-31).
Input Signal slave
BIGEND This port indicates the endianness; where 1=big
endian and 0=little endian. It changes the BIG-
END component parameter value. Note that this
configuration is only latched during core reset.
Input Signal slave
IRQ This port connects to external interrupt signals. It
can be anywhere from 1 to 240 bits wide based on
the configuration used to create the Model.
The value must indicate the interrupt number
[NumIRQ..0] and the *extValue must indicate
whether the IRQ line is asserted (*extValue=1) or
deasserted (*extValue=0).
Input Signal slave
NMI Non-maskable interrupt input to the NVIC; where
1 is used to assert NMI, and 0 is used to deassert
NMI request.
Input Signal slave

Available Component ESL Ports 1-7
Carbon Design Systems, Inc. Confidential
RST This port is the core input reset. *extValue indi-
cates the type of reset:
*extValue=1 indicates a PORESET
*extValue=0 indicates a SYSRESET.
value is the signal value on the reset line. Note
value is active high (instead of active low reset
used in the hardware). Also note the reset request
is ignored if *extValue is NULL.
Input Signal slave
RXEV Causes a wakeup from a WFE instruction. Input Signal slave
SLEEPHOLDREQ Request to extend sleep mode. Input Signal slave
VECTADDR Reserved Input Signal slave
VECTADDREN Reserved Input Signal slave
WICENREQ Make SLEEPDEEP mode WIC mode sleep
request from PMU. Input Signal slave
systickClkIn System Tick Clock. See “Clock Ports” on
page 1-9 for more information. Input Signal slave
clk-in Input Clock port. This port must be explicitly con-
nected to a clock master. Input Clock Generator
ETMINTNUM The interrupt number of the current execution
context. Output Signal master
ETMINTSTAT Interrupt status of the current cycle:
000 - no status
001 - interrupt entry
010 - interrupt exit
011 - interrupt return
100 - vector fetch and stack push
Output Signal master
SLEEPDEEP Indication of core going into SLEEPDEEP mode;
where 1 is used when going into SLEEPDEEP,
and 0 is used when the core is waken up.
Output Signal master
SLEEPHOLDACK Acknowledges signal for SLEEPHOLDREQ that
the core will be held in sleep mode. Output Signal master
SLEEPING Indication that the core is going into SLEEP mode
(because of WFE/WFI). The value 1 is used when
the core goes into SLEEP mode, and 0 when the
core is waken up.
Output Signal master
TXEV Event transmitted as a result of SEV instruction. Output Signal master
WICENACK Active high SLEEPDEEP is WICSLEEP
acknowledgement to PMU. Output Signal master
extSemi Semihosting can be enabled by connecting this
port to the SoC Designer Plus semihost compo-
nent, contained in the Carbon SoC Designer Plus
Standard Model Library (v3.0 or greater).
Output Transaction mas-
ter
Table 1-2 ESL Component Ports (Continued)
ESL Port Description Direction Type

1-8 Using the Model Kit Component in SoC Designer Plus
Carbon Design Systems, Inc. Confidential
All pins that are not listed in this table have been either tied or disconnected for perfor-
mance reasons.
Note: Some ESL component port values can be set using a component parameter. This
includes the BIGEND port. In those cases, the parameter value will be used when-
ever the ESL port is not connected. If the port is connected, the connection value
takes precedence over the parameter value.
1.3.1 Transaction Ports
1.3.1.1 AHB-Lite Transaction Master Ports
The mem_I, mem_D, and mem_S transaction master ports implement the AMBA AHB-
Lite interface for the ICode, DCode, and System bus, respectively. These transaction mas-
ter ports should be connected to AHBv2 slaves using either an MxAHBv2 bus component
(where one side is an AHB Lite Master and the other side is an AHB Lite Slave) or a
PL301 in between. See the SoC Designer Plus AHBv2 Protocol Bundle User Guide for
more information.
There are a few AHBv2 sideband signals defined specifically for the Cortex-M3. See the
AHBv2 Protocol Bundle User Guide for details on AHB Cortex-M3 extension signals.
1.3.1.2 ext_ppb Bus Master Port
The ext_ppb bus master port implements the APB v3.0 interface on the Cortex-M3 for
accessing peripherals mapped in the external Private Peripheral Bus (PPB) region. Data
accesses to an address mapped to the external PPB space (0xE0040000 to 0xE00FFFFF)
goes through this port, except for accesses to the ROM Table that is internal to the Cortex-
M3 model.
Note: Address range seen by the ext_ppb port is from 0x40000 to 0xFEFFF (as opposed
to 0xE00FFFFF to 0xE00FEFFF), i.e., the upper 12 bits are unused. Conse-
quently, when defining the address map for peripheral components in the external
peripheral space, the upper 12 bits of base address should be set to zero.
ext_ppb Private Peripheral Bus Interface. This bus master
port implements the APB (v3.0) interface on the
Cortex-M3 for accessing peripherals mapped in
the external Private Peripheral Bus (PPB) region.
Output APB Transaction
master
mem_D DCode Interface. See “AHB-Lite Transaction
Master Ports” on page 1-8 for more information. Output AHB-Lite Trans-
action master
mem_I ICode Interface. See “AHB-Lite Transaction
Master Ports” on page 1-8 for more information. Output AHB-Lite Trans-
action master
mem_S System Bus Interface. See “AHB-Lite Transac-
tion Master Ports” on page 1-8 for more infor-
mation.
Output AHB-Lite Trans-
action master
Table 1-2 ESL Component Ports (Continued)
ESL Port Description Direction Type

Setting Component Parameters 1-9
Carbon Design Systems, Inc. Confidential
1.3.2 Clock Ports
clk_in is the clock port used to clock the core. The systickClkIn port can be used to clock
the system tick timer. Note that the CLKSOURCE bit in the Systick control and status reg-
ister of the NVIC has to be set to ‘1’ if the internal core clock is used to clock the system
tick timer, or ‘0’ if an external clock source is used. The reset value of CLKSOURCE bit
is ‘0’.
1.4 Setting Component Parameters
You can change the settings of all the component parameters in SoC Designer Canvas, and
of some of the parameters in SoC Designer Simulator. To modify the Carbon component’s
parameters:
1. In the Canvas, right-click on the Carbon component and select Component Informa-
tion. You can also double-click the component. The Edit Parameters dialog box
appears.
Figure 1-2 Component Parameters Dialog Box
The list of available parameters will be slightly different depending on the settings that
you enabled in the configuration file (default.conf) when creating the component.
2. In the Parameters window, double-click the Value field of the parameter that you
want to modify.

1-10 Using the Model Kit Component in SoC Designer Plus
Carbon Design Systems, Inc. Confidential
3. If it is a text field, type a new value in the Value field. If a menu choice is offered,
select the desired option. The parameters are described in Table 1-3.
Table 1-3 Component Parameters
Name Description Allowed
Values Default Value Runtime1
Align Waveforms When set to true, waveforms dumped
from the Carbon component are aligned
with the SoC Designer Plus simulation
time. The reset sequence, however, is not
included in the dumped data.
When set to false, the reset sequence is
dumped to the waveform data, however,
the Carbon component time is not
aligned with the SoC Designer Plus time.
true, false true No
BIGEND When set to true, configures the proces-
sor in big endian mode. Otherwise it
works in little endian mode (default).
true, false false Yes
Carbon DB Path Sets the directory path to the Carbon
database file. Not Used empty No
DNOTITRANS When set to true, it disallows transac-
tions on the I and D interfaces at the
same time.
true, false false Yes
Dump Waveforms Determines whether SoC Designer Plus
dumps waveforms for this component. true, false false Yes
Enable Debug
Messages Determines whether debug messages are logged for the component. true, false false Yes
Enable PC Tracing Enables dumping a PC trace to disk con-
taining decode PCs and actual branch
PCs. See “Software Profiling” on
page 1-21 for more information.
true, false false No
ext_ppb Enable
Debug Messages Determines whether debug messages are logged for the ext_ppb port. true, false false Yes
ext_ppb PReady
Default High The transfer is extended if PREADY is held low during an access phase. true, false true Yes
mem_D Align Data Determines whether halfword and byte
transactions will align data to the trans-
action size for this port. By default, data
is not aligned.
true, false false No
mem_D Big Endian Determines whether AHB data is treated
as big endian for this port. By default,
data is not sent as big endian.
true, false false No
mem_D Enable
Debug Messages Determines whether debug messages are logged for the mem_D port. true, false false Yes