Carbon Cortex-A8 Model User Guide for SoC Designer

Carbon Cortex-A8 Model 

User Guide for SoC Designer 

Carbon Model Version 4.0.0 

For the ARM Cortex-A8 Processor 

Silicon Version: r3p2 

SOFTWARE BEFORE SILICON ® 

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.

Copyright 

Copyright © 2003-2012 Carbon Design Systems, Inc. All rights reserved. 

Files, documents or portions thereof presented on the Carbon Design Systems Internet server “Publication”, permits persons 

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 limited 

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 Systems 

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 consequential 

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-2012 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, VSP, and The 

Answer to Validation 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 subsidiaries 

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. 

Carbon Design Systems, Inc. Confidential

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: +1-978-264-7399 

Asia: +81-3-5524-1288 

Fax: +1-978-264-9990 

Email: support@carbondesignsystems.com 

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 May 2012.


Contents 

Chapter 1. 

Using the Model Kit Component in SoC Designer 

Cortex-A8 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 

Implemented Hardware Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 

Hardware Features not Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 

Features Additional to the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 

Differences from the ARM RVML Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 

Adding and Configuring the SoC Designer Component . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4 

Carbon SoC Designer Component Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4 

Adding the Carbon Model to the Component Library . . . . . . . . . . . . . . . . . . . . . . . . . .1-5 

Adding the Component to the SoC Designer Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5 

Available Component ESL Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 

Setting Component Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 

Debug Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10 

Register Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-11 

Run To Debug Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21 

Memory Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21 

Disassembly View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-22 

Available Profiling Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-23 

Hardware Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-23 

Software Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-25 


vi 

Contents 


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. 

About This Guide 

This guide provides all the information needed to configure and use the Carbon Cortex-A8 

processor Model in Carbon SoC Designer. 

Audience 

This guide is intended for experienced hardware and software developers who create components 

for use with Carbon SoC Designer. You should be familiar with the following 

products and technology: 

• Carbon SoC Designer 

• Hardware design verification 

• Verilog or VHDL programming language 


viii 

Preface 

Conventions 

This guide uses the following conventions: 

Convention Description Example 

courier 

italic 

bold 

 

Commands, functions, 

variables, routines, and 

code examples that are set 

apart from ordinary text. 

New or unusual words or 

phrases appearing for the 

first time. 

Action that the user performs. 

Values that you fill in, or 

that the system automatically 

supplies. 

[ text ] Square brackets [ ] indicate 

optional text. 

[ text1 | text2 ] The vertical bar | indicates 

“OR,” meaning that you 

can supply text1 or text 2. 

sparseMem_t SparseMemCreate- 

New(); 

Transactors provide the entry and exit 

points for data ... 

Click Close to close the dialog. 

/ represents the name of 

various platforms. 

$CARBON_HOME/bin/modelstudio 

[ ] 

$CARBON_HOME/bin/modelstudio 

[.symtab.db | 

.ccfg ] 

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. 


Preface 

ix 

Further reading 

This section lists related publications by Carbon and by third parties. 

Carbon Model Documentation 

The following publications provide information that relate directly to models from Carbon 

Design Systems: 

• Carbon Cortex-A8 Model Generation Guide 

• Carbon Model Installation and Licensing Guide 

Carbon SoC Designer Documentation 

The following publications provide information that relate directly to SoC Designer: 

• Carbon SoC Designer Installation Guide 

• Carbon SoC Designer User Guide 

• Carbon SoC Designer RTOE User Guide 

• Carbon SoC Designer Models Reference 

• Carbon SoC Designer AXIv2 Protocol Bundle User Guide 

External publications 

The following publications provide reference information about ARM® products: 

• ARM Cortex-A8 Technical Reference Manual 

• Cortex-A8 Configuration and Sign-Off Guide 

• AMBA Specification 

• AMBA AXI 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. 


x 

Preface 

Glossary 

AMBA 

AHB 

APB 

AXI 

Carbon Model 

Carbon Model 

Studio 

CASI 

CADI 

CAPI 

Component 

ESL 

HDL 

RTL 

SoC Designer 

SystemC 

Transactor 

Advanced Microcontroller Bus Architecture. The ARM open standard on-chip 

bus specification that describes a strategy for the interconnection and management 

of functional blocks that make up a System-on-Chip (SoC). 

Advanced High-performance Bus. A bus protocol with a fixed pipeline 

between address/control and data phases. It only supports a subset of the functionality 

provided by the AMBA AXI protocol. 

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. 

Advanced eXtensible Interface. A bus protocol that is targeted at high performance, 

high clock frequency system designs and includes a number of features 

that make it very suitable for high speed sub-micron interconnect. 

A software object created by the Carbon Model Studio (or Carbon compiler) 

from an RTL design. The Carbon Model contains a cycle- and register-accurate 

model of the hardware design. 

Carbon’s graphical tool for generating, validating, and executing hardwareaccurate 

software models. It creates a Carbon Model, and it also takes a Carbon 

Model as input and generates a Carbon component that can be used in 

SoC Designer, Platform Architect, or OSCI SystemC for simulation. 

ESL API Simulation Interface, is based on the SystemC communication 

library and manages the interconnection of components and communication 

between components. 

ESL API Debug Interface, enables reading and writing memory and register 

values and also provides the interface to external debuggers. 

ESL API Profiling Interface, enables collecting historical data from a component 

and displaying the results in various formats. 

Building blocks used to create simulated systems. Components are connected 

together with unidirectional transaction-level or signal-level connections. 

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++. 

Hardware Description Language. A language for formal description of electronic 

circuits, for example, Verilog or VHDL. 

Register Transfer Level. A high-level hardware description language (HDL) 

for defining digital circuits. 

The full name is Carbon SoC Designer. A high-performance, cycle accurate 

simulation framework which is targeted at System-on-a-Chip hardware and 

software debug as well as architectural exploration. 

SystemC is a single, unified design and verification language that enables verification 

at the system level, independent of any detailed hardware and software 

implementation, as well as enabling co-verification with RTL design. 

Transaction adaptors. You add transactors to your Carbon component to connect 

your component directly to transaction level interface ports for your particular 

platform. 


Chapter 1 

Using the Model Kit Component in SoC Designer 

This chapter describes the functionality of the Model component, and how to use it in 

Carbon SoC Designer. It contains the following sections: 

• Cortex-A8 Functionality 

• Adding and Configuring the SoC Designer Component 

• Available Component ESL Ports 

• Setting Component Parameters 

• Debug Features 

• Available Profiling Data 

Note: 

If you received the Model from Carbon, see the provided “Carbon Model Installation 

and Licensing Guide” for Model installation and licensing information. 

1.1 Cortex-A8 Functionality 

The Cortex-A8 processor is a high-performance, low-power, cached application processor 

that provides full virtual memory capabilities. The Cortex-A8 processor has: 

• configurable 64-bit or 128-bit high-speed Advanced Microprocessor Bus Architecture 

(AMBA) with AXI for main memory interface supporting multiple outstanding transactions 

• a pipeline for executing ARM integer instructions 

• a NEON pipeline for executing Advanced SIMD and VFP instruction sets 

• Memory Management Unit (MMU) and separate instruction and data Translation 

Look-aside Buffers (TLBs) of 32 entries each 

• Level 1 instruction and data caches of 16KB or 32KB configurable size 

• Level 2 cache of 0KB, 128KB through 1MB configurable size 

• Level 2 cache with parity and Error Correction Code (ECC) configuration option 

• Embedded Trace Macrocell (ETM) support for non-invasive debug 

• static and dynamic power management including Intelligent Energy Management 

(IEM) 


1-2 Using the Model Kit Component in SoC Designer 

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. 

• Implemented Hardware Features 

• Hardware Features not Implemented 

• Features Additional to the Hardware 

1.1.1 Implemented Hardware Features 

The following features of the Cortex-A8 hardware are fully implemented in the Carbon 

model: 

• ARMv7-A integer instruction set 

• Thumb-2 integer instruction set 

• Thumb-2 Execution Environment 

• NEON Media Acceleration instruction set 

• TrustZone Secure Monitor Mode 

• VFPv3 instruction set 

• VMSAv7-A memory architecture 

• L1 instruction and data caches 

• L2 unified cache 

• External AXI memory interface 

See the ARM Cortex-A8 Technical Reference Manual for more information. 

1.1.2 Hardware Features not Implemented 

The following features of the Cortex-A8 hardware are not implemented in the Carbonized 

model: 

• ARMv7 Debug architecture, comprising: 

– Embedded Trace Macrocell interface 

– APBv3 CoreSight compliant debug interface 

– Debug Coprocessor (CP14) registers, interface, and associated instructions 

• Test features, including MBIST and integration test registers 

• Array debug data access operations 

• Parity and error correction are not implemented in the internal RAMs. Timing effects 

of parity errors caused by direct CP15 manipulation are not visible 

• The AXI bus width must be specified in the CortexA8.conf configuration file before 

the Model has been generated, and is therefore not configurable at simulation runtime. 


Cortex-A8 Functionality 1-3 

1.1.3 Features Additional to the Hardware 

The following features that are implemented in the Cortex-A8 model do not exist in the 

Cortex-A8 hardware. These features have been added to the model for enhanced usability. 

• The component supports positive and negative level irq and fiq signal. This is configurable 

using the negLogic parameter (see Table 1-3 on page 1-9). 

• 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 nondebuggable 

state. See “Run To Debug Point” on page 1-21 for more information. 

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 AXI v2 port interface instead of the v1 interface 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 Standard 

Model Library, version 3.0 or greater. The ARM RVML semihost component will not 

work with the Carbon Model. Additionally, only a single core is currently supported 

for semihosting. 

• Differences in component ports: 

– The following ports are not available in the Carbon Model: CPEXIST, 

L1RSTDISABLE, L2RSTDISABLE, SILICONID, NEON_RESET, RESET, axiclk, 

and semihostbus. 

– The following ports have been added to the Carbon Model: extSemi. 



1.2 Adding and Configuring the SoC Designer Component 

The following topics briefly describe how to use the component. See the Carbon SoC 

Designer User Guide for more information. 

• Carbon SoC Designer Component Files 

• Adding the Carbon Model to the Component Library 

• Adding the Component to the SoC Designer Canvas 

1.2.1 Carbon SoC Designer Component Files 

The component files are the final output from the Carbon Model Studio compile and are 

the input to SoC Designer. 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 runtime 

libraries so it can be linked with the debug version of SoC Designer. The release version 

is compiled referencing the release runtime library. Both release and debug versions 

generate debug symbols for use with the Visual C++ debugger on Windows. 

The provided component files are listed below: 

Table 1-1 Carbon SoC Designer Component Files 

Platform File Description 

Linux 

Windows 

maxlib.lib.conf 

lib.mx.so 

lib.mx_DBG.so 

maxlib.lib.windows.conf 

lib.mx.dll 

lib.mx_DBG.dll 

SoC Designer configuration file 

SoC Designer component runtime file 

SoC Designer component debug file 

SoC Designer configuration file 

SoC Designer component runtime file 

SoC Designer component debug file 

Additionally, this User Guide PDF file, the Carbon Model Installation and Licensing 

Guide, and a ReadMe text file are provided with the component. 

Note: 

If you generated these files from a Carbon Model Kit, they are located in 

/data/SoCDesigner. If you installed them from a model package from 

Carbon Design Systems, they are located where you instructed the installer to 

place them. 


Adding and Configuring the SoC Designer Component 1-5 

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, perform 

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 model is located and select the component 

configuration file: 

– maxlib.lib.conf (for Linux) 

– maxlib.lib.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 Component Window. 

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-A8 Components in SoC Designer 

The figure shows the component with one Master AXI port. 



1.3 Available Component ESL Ports 

Table 1-2 describes the ESL ports that are exposed in SoC Designer. Some ports may or 

may not appear depending on the settings that you enabled in the configuration file (for 

example, CORTEXA8.conf). See the ARM Cortex-A8 Technical Reference Manual for 

more information. 

Table 1-2 ESL Component Ports 

ESL Port Description Direction Type 

CFGEND0 

CFGNMFI 

CFGTE 

CLKSTOPREQ 

CP15SDISABLE 

FIQ 1 

IRQ 1 

SECMONOUTEN 

VINITHI 

Endianness configuration. Controls the state of EE bit in 

the CP15 Control Register at reset: 

0 = EE bit is LOW 

1 = EE bit is HIGH 

Configures fast interrupts to be nonmaskable at reset: 

0 = clears the NMFI bit in the CP15 c1 Control Register 

1 = sets the NMFI bit in the CP15 c1 Control Register 

Controls the state of TE bit in the CP15 Control Register 

at reset: 

0 = TE bit is LOW 

1 = TE bit is HIGH 

Clock stop request: 

0 = do not stop the internal clocks 

1 = cause the processor to stop the internal clocks, go into 

low active power mode, and to assert the CLKSTOPACK 

output 

Disables write access to certain TrustZone registers in the 

CP15 system control coprocessor. 

Active-LOW asynchronous fast interrupt request: 

0 = activate fast interrupt 

1 = do not activate fast interrupt 

Active-LOW asynchronous interrupt request: 

0 = activate interrupt 

1 = do not activate interrupt 

Security monitor output enable at reset: 

0 = disables SECMONOUT[86:0] 

1 = enables SECMONOUT[86:0]. 

Controls the start location of the exception vectors at 

reset: 

0 = starts exception vectors at address 0x00000000 

1 = starts exception vectors at address 0xFFFF0000 

Input 

Input 

Input 

Input 

Input 

Input 

Input 

Input 

Input 

Signal slave 

Signal slave 

Signal slave 

Signal slave 

Signal slave 

Signal slave 

Signal slave 

Signal slave 

Signal slave 

clk_in Input clock. Input Clock slave 


Available Component ESL Ports 1-7 

CLKSTOPACK 

DMAEXTERRIRQ 

DMAIRQ 

DMASIRQ 

PMUIRQ 

SECMONOUT 

STANDBYWFI 

Clock stop acknowledge. Asserted high when CLKSTO- 

PREQ is asserted and the core has drained and entered 

low active power mode: 

0 = the internal clocks are not stopped 

1 = the internal clocks are stopped 

Active-LOW PLE interrupt on error for all transfers: 

0 = interrupt active 

1 = interrupt not active 

Active-LOW PLE interrupt on completion for nonsecure 

transfers: 



Active-LOW PLE interrupt on completion for secure 

transfers: 



Active-LOW PMU interrupt signal: 

0 = PMU interrupt active 

1 = PMU interrupt not active 

Security monitor output. See the Cortex-A8 TRM for a 

detailed list of pins and their descriptions. 

Standby mode flag generated by WFI operation: 

0 = processor not in standby mode 

1 = processor in standby mode 

Output 

Output 

Output 

Output 

Output 

Output 

Output 

Signal master 

Signal master 

Signal master 

Signal master 

Signal master 

Signal master 

Signal master 

axiport AXI Master port. Output AXI Transaction 

master 

extSemi 

Table 1-2 ESL Component Ports (Continued) 

ESL Port Description Direction Type 

Semihosting can be enabled by connecting this port to the 

SoC Designer semihost component contained in the Carbon 

SoC Designer Standard Model Library (v3.0 or 

greater). 

Output 

Transaction 

master 

1. For these interrupt ports, the active high/low setting is controlled by the negLogic component parameter. 

The default is active high. 

All pins that are not listed in this table have been either tied or disconnected for performance 

reasons. 

Note: 

Some ESL component port values can be set using a component parameter. This 

includes the CFGEND0, CFGNMFI, CFGTE, CP15SDISABLE, SEC- 

MONOUTEN, and VINITHI ports. In those cases, the parameter value will be 

used whenever the ESL port is not connected. If the port is connected, the connection 

value takes precedence over the parameter value. 



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 Edit Parameters.... 

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 (for example, CORTEXA8.conf). 

2. In the Parameters window, double-click the Value field of the parameter that you 

want to modify. 

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. 


Setting Component Parameters 1-9 

Table 1-3 Component Parameters 

Name 

Description 

Allowed 

Values 

Default Value Runtime 1 

Align Waveforms 

axiport Enable Debug 

Messages 

Carbon DB Path 

cfgend0 

cfgnmfi 

cfgte 

cp15disable 

cpexist 

Dump Waveforms 

Enable Debug 

Messages 

Enable PC Tracing 

negLogic 

PC Tracing File 

When set to true, waveforms dumped 

by the Carbon component are aligned 

with the SoC Designer 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 SoC Designer 

time. 

Whether debug messages are logged 

for the AXI port. 

Sets the directory path to the Carbon 

database file. 

Endianness configuration. Controls 

the initial state at reset of the EE bit in 

the CP15 control register. 

Configures fast interrupts to be nonmaskable. 

Controls the initial state at reset of the 

TE bit in the CP15 control register. 

Disables write access to certain Trust- 

Zone CP15 registers. 

Enables access programming of coprocessors 

0-13. 

Whether SoC Designer dumps waveforms 

for this component. 

Whether debug messages are logged 

for the component. 

Enables dumping a PC trace to disk 

containing decode PCs and actual 

branch PCs. See “Software Profiling” 

on page 1-25. 

Sets IRQ/FIQ assertion to use negative 

logic. Default of false means 

0=off and 1=on. True means 0=on 

and 1=off. 

The file to write the PC trace information. 

The file is written in binary 

format. The C++ file 

pctracedump.cpp can be used to 

decode the data. 

true, false true No 

true, false false Yes 

Not Used empty No 





0 – 0x3fff 3072 (0x0c00) Yes 



true, false false No 

true, false true Yes 

Valid file 

name 

CortexA8PC.dat 

No 



Table 1-3 Component Parameters (Continued) 

Name 

Description 

Allowed 

Values 

Default Value Runtime 1 

secmonouten Enable the security monitor output. true, false false Yes 

siliconid 

Defines the reset value of the CP15 0 – 0xffffffff 0x41000000 Yes 

Silicon ID register. 

vinithi 

Control of the location of the exception 

vectors at reset. 

0, 1 0 Yes 

Waveform File 2 Name of the waveform file. string carbon_CORTEX 

A8.vcd 

Waveform Timescale 

Sets the timescale to be used in the 

waveform. 

Many values 

in drop-down 

No 

1 ns No 

1. Yes means the parameter can be dynamically changed during simulation, No means it can be changed only 

when building the system, Reset means it can be changed during simulation, but its new value will be taken 

into account only at the next reset. 

2. When enabled, SoC Designer writes accumulated waveforms to the waveform file in the following situations: 

when the waveform buffer fills, when validation is paused and when validation finishes, and at the 

end of each validation run. 

1.5 Debug Features 

The Cortex-A8 model has a debug interface (CADI) that allows the user to view, manipulate, 

and control the registers and memory, and display disassembly for programs running 

on the model in the SoC Designer Simulator or any debugger that supports CADI. A view 

can be accessed in SoC Designer by right clicking on the model and choosing the appropriate 

menu entry. 

The following topics are discussed in this section: 

• Register Information 

• Run To Debug Point 

• Memory Information 

• Disassembly View 


Debug Features 1-11 

1.5.1 Register Information 

Figure 1-3 shows the Register view of the Cortex-A8 model in SoC Designer Simulator. 

Figure 1-3 Cortex-A8 Registers View 

The Cortex-A8 model has many sets of registers that are accessible via the debug interface. 

Registers are grouped into sets according to functional area. 

• Core Registers 

• VFP/Neon Registers 

• ID Registers 

• Control Registers 

• Cache Registers 

• PLE Registers 

• Perf Registers 

• TLB Registers 

• VA to PA Registers 

• Normal World Registers 

• Secure World Registers 

• Debug Registers 

See the ARM Cortex-A8 Technical Reference Manual for detailed descriptions of these 

registers. 

Note that certain CoProcessor 15 registers will cause the UNDEFINED exception to be 

taken when invalid data is written. If this exception is triggered during a debug write 

access, the program counter may jump to the undefined exception handler the next time 

that cycles are executed. 



1.5.1.1 Core Registers 

The Core group contains the ARM architectural registers. 

Table 1-4 Core Registers 

Name Description Type 

R0 R0 register read-write 1 













R13 R13/Stack Pointer register read-write 1 

R14 R14/Link Register read-write 1 

R15 Program Counter register read-write 1 

CPSR Current Program Status register read-write 1 

R8_USR R8 USR register read-write 1 







R13_IRQ R13 IRQ register read-write 1 

R14_IRQ R14 IRQ register read-write 1 

SPSR_IRQ Saved Program Status Register IRQ register read-write 1 

R8_FIQ R8 FIQ register read-write 1 




Table 1-4 Core Registers (Continued) 







SPSR_FIQ Saved Program Status Register FIQ register read-write 1 

R13_SVC R13 SVC register read-write 1 

R14_SVC R14 SVC register read-write 1 

SPSR_SVC Saved Program Status Register SVC register read-write 1 

R13_ABT R13 ABT register read-write 1 

R14_ABT R14 ABT register read-write 1 

SPSR_ABT Saved Program Status Register ABT register read-write 1 

R13_UND R13 UND register read-write 1 

R14_UND R14 UND register read-write 1 

SPSR_UND Saved Program Status Register UND register read-write 1 

R13_MON R13 MON register read-write 1 

R14_MON R14 MON register read-write 1 

SPSR_MON Saved Program Status Register MON register read-write 1 

ExtendedTargetFeatures Used internally for TrustZone support read-only 

PC_MEMSPACE Used internally for TrustZone support read-only 

1. Writable at debug point only. 

1.5.1.2 VFP/Neon Registers 

The VFP/NEON group contains the registers for the NEON and VFP coprocessors. The 

NEON and VFP coprocessor share the same register bank. You can reference the NEON 

and VFP register bank using three explicitly aliased views. See the “NEON and VFP Programmers 

Model” chapter in the Cortex-A8 TRM for more information. 

Table 1-5 VFP/Neon Registers 


FPSCR Floating-point Status and Control register read-write 

S0 - S31 Thirty-two 32-bit single-word registers used by VFP. read-write 

D0 - D31 

Thirty-two 64-bit double-word registers used by both 

VFP and NEON. 

read-write 



Table 1-5 VFP/Neon Registers (Continued) 


Q0 - Q15 Sixteen 128-bit quad-word registers used by NEON. read-write 

FPSID Floating-Point System ID register read-only 

MVFR0 Media and VFP Feature Register 0 read-only 

MVFR1 Media and VFP Feature Register 1 read-only 

FPEXC Floating-Point Exception register read-write 

1.5.1.3 ID Registers 

The ID group contains registers that describe the processor capabilities. 

Table 1-6 ID Registers 


CP15_CACHE_TYPE Cache Type register read-only 

CP15_ID Main ID register read-only 

CP15_ID_AFR0 Auxiliary Feature 0 register (always returns 0) read-only 

CP15_ID_DFR0 Debug Feature 0 register read-only 

CP15_ID_ISAR0 Instruction Set Attribute 0 register read-only 





CP15_ID_ISAR5 Instruction Set Attribute 5 register (always returns 0) read-only 



CP15_ID_MMFR0 Memory Model Feature 0 register read-only 




CP15_ID_PFR0 Processor Feature 0 register read-only 

CP15_ID_PFR1 Processor Feature 1 register read-only 

CP15_MULTIPROCESSOR_ID Multiprocessor ID register read-only 

CP15_SILICON_ID Silicon ID register read-only 

CP15_TCM_TYPE TCM Type register read-only 

CP15_TLB_TYPE TLB Type register read-only 



1.5.1.4 Control Registers 

The Control group contains registers that dynamically configure the processor. 

Table 1-7 Control Registers 


CP15_AUXILIARY_CONTROL Auxiliary Control register read-only 

CP15_CID Context ID register read-write 

CP15_CONTROL Control register read-write 

CP15_COPROCESSOR_ACCESS_ 

CONTROL 

Coprocessor Access Control register. Only available 

if Neon and FPU processors are present. 

read-only 

CP15_DACR Domain Access Control register read-write 

CP15_DATA_AUX_FAULT Data Auxiliary Fault Status register read-only 

CP15_DFAR Data Fault Address register read-write 

CP15_DFSR Data Fault Status register read-write 

CP15_IFAR Instruction Fault Address register read-write 

CP15_IFSR Instruction Fault Status register read-write 

CP15_INSTR_AUX_FAULT Instruction Auxiliary Fault Status register read-only 

CP15_INTERRUPT_STATUS Interrupt Status register read-only 

CP15_MONITOR_VECTOR_BASE Monitor Vector Base Address register read-write 

CP15_NORM_MEM_REMAP Normal Memory Remap register read-write 

CP15_NS_ACCESS_CONTROL Nonsecure Access Control register read-only 

CP15_PID FCSE PID register read-write 

CP15_PRIM_REGION_REMAP Primary Region Remap register read-write 

CP15_PRIVILEGED_ID Privileged only Thread and Process ID register read-write 

CP15_SECURE_CONFIGURATION Secure Configuration register read-write 

CP15_SECURE_DEBUG_ENABLE Secure Debug Enable register read-write 

CP15_TTBC TTB Control register read-write 

CP15_TTBR0 TTB Register 0 read-write 

CP15_TTBR1 TTB Register 1 read-write 

CP15_USER_RO_ID User read-only Thread and Process ID register read-write 

CP15_USER_RW_ID User read/write Thread and Process ID register read-write 

CP15_VECTOR_BASE Monitor Vector Base Address register read-write 



1.5.1.5 Cache Registers 

The Cache group contains registers to access cache information. 

Table 1-8 Cache Registers 


CP15_CACHE_LEVEL_ID Cache Level ID register read-only 

CP15_CACHE_SIZE_ID Cache Size ID register read-only 

CP15_CACHE_SIZE_SELECT Cache Size Selection register read-only 

CP15_L2_CACHE_AUX_CTRL L2 Cache Auxiliary Control register read-write 

CP15_L2_CACHE_DATA_LCK L2 Cache Lockdown register read-write 

1.5.1.6 PLE Registers 

The PLE group contains the PreLoad Engine control and configuration registers. 

Table 1-9 PLE Registers 


CP15_CHANNELS_ACCESSIBI PLE User Accessibility register 

read-write 

LITY 

CP15_CHANNELS_INTERRUPT PLE Channel Interrupting register 

read-only 

ING 

CP15_CHANNELS_PRESENT PLE Channel Present register read-only 

CP15_CHANNELS_RUNNING PLE Channel Running register read-only 

CP15_CHANNEL_CONTEXTID PLE Channel Context ID register read-write 

CP15_CHANNEL_CONTROL PLE Channel Control register read-write 

CP15_CHANNEL_INTERNAL PLE Internal Start Address register 

read-write 

STARTADDRESS 

CP15_CHANNEL_INTERNAL PLE Internal End Address register 

read-write 

ENDADDRESS 

CP15_CHANNEL_NUMBER PLE Channel Number register read-write 

CP15_CHANNEL_STATUS PLE Channel Status register read-only 



1.5.1.7 Perf Registers 

The Perf group contains performance related registers. 

Table 1-10 Perf Registers 


CP15_COUNT_ENA_CLR Count Enable Clear register read-write 

CP15_COUNT_ENA_SET Count Enable Set register read-write 

CP15_CYCLE_COUNT Cycle Count register read-write 

CP15_Counter_Select Event Counter Selection register read-write 

CP15_EVENT_SELECT Event Selection register read-write 

CP15_INTERRUPT_ENABLE_CLR Interrupt Enable Clear register read-write 

CP15_INTERRUPT_ENABLE_SET Interrupt Enable Set register read-write 

CP15_Overflow_Status Overflow Flag Status register read-write 

CP15_PERF_MON_COUNT Performance Monitor Count register read-write 

CP15_PERF_MON_CTRL Performance Monitor Control register read-write 

CP15_USER_ENABLE User Enable register read-write 

1.5.1.8 TLB Registers 

The TLB group contains performance related registers. 

Table 1-11 TLB Registers 


CP15_DATA_TLB_LCK Data TLB Lockdown register read-write 

CP15_INSTR_TLB_LCK Instruction TLB Lockdown register read-write 

1.5.1.9 VA to PA Registers 

The VA to PA group contains registers to perform virtual to physical address translations. 

Table 1-12 VA to PA Registers 


CP15_PA Physical Address register read-write 



1.5.1.10 Normal World Registers 

The Normal World group contains control register that are only accessible in non-secure 

mode. 

Table 1-13 Normal World Registers 


CP15_N_CID CP15 Context ID Non-secure register read-write 

CP15_N_CONTROL CP15 Control Non-secure register read-only 

CP15_N_AUXILIARY_ CP15 Auxiliary Control Non-secure register read-write 

CONTROL 

CP15_N_DACR CP15 Domain Access Control Non-secure register read-write 

CP15_N_DATA_AUX_ 

FAULT 

CP15 Data Auxiliary Fault Status Non-secure register 

read-write 

CP15_N_DFAR CP15 Data Fault Address Non-secure register read-write 

CP15_N_DFSR CP15 Data Fault Status Non-secure register read-write 

CP15_N_IFAR CP15 Instruction Fault Address Non-secure register read-write 

CP15_N_IFSR CP15 Instruction Fault Status Non-secure register read-write 

CP15_N_INSTR_AUX_ 

FAULT 

CP15_N_NORM_MEM_ 

REMAP 

CP15 Instruction Auxiliary Fault Status Non-secure 

register 

CP15 Normal Memory Remap Non-secure register 

read-write 

read-write 

CP15_N_PA CP15 Physical Address Non-secure register read-write 

CP15_N_PID CP15 FCSE PID Non-secure register read-write 

CP15_N_PRIM_REGION_ 

REMAP 

CP15 Primary Region Remap Non-secure register read-write 

CP15_N_PRIVILEGED_ 

ID 

CP15 Privileged only Thread and Process ID Nonsecure 

register 

read-write 

CP15_N_TTBC CP15 TTB Control Non-secure register read-write 

CP15_N_TTBR0 CP15 TTB Non-secure Register 0 read-write 

CP15_N_TTBR1 CP15 TTB Non-secure Register 1 read-write 

CP15_N_USER_RO_ID CP15 User read-only Thread and Process ID Nonsecure 

read-write 

register 

CP15_N_USER_RW_ID CP15 User read/write Thread and Process ID Nonsecure 

read-write 

register 

CP15_N_VECTOR_BASE CP15 Monitor Vector Base Address Non-secure 

register 

read-write 



1.5.1.11 Secure World Registers 

The Secure group contains control registers that are only accessible in secure mode. 

Table 1-14 Secure World Registers 


CP15_S_CID CP15 Context ID Secure register read-write 

CP15_S_CONTROL CP15 Control Secure register read-only 

CP15_S_AUXILIARY_ CP15 Auxiliary Control Secure register read-write 

CONTROL 

CP15_S_DACR CP15 Domain Access Control Secure register read-write 

CP15_S_DATA_AUX_ CP15 Data Auxiliary Fault Status Secure register read-write 

FAULT 

CP15_S_DFAR CP15 Data Fault Address Secure register read-write 

CP15_S_DFSR CP15 Data Fault Status Secure register read-write 

CP15_S_IFAR CP15 Instruction Fault Address Secure register read-write 

CP15_S_IFSR CP15 Instruction Fault Status Secure register read-write 

CP15_S_INSTR_AUX_ 

FAULT 

CP15_S_NORM_MEM_ 

REMAP 

CP15 Instruction Auxiliary Fault Status Secure 

register 

CP15 Normal Memory Remap Secure register 

read-write 

read-write 

CP15_S_PA CP15 Physical Address Secure register read-write 

CP15_S_PID CP15 FCSE PID Secure register read-write 

CP15_S_PRIM_REGION_ CP15 Primary Region Remap Secure register read-write 

REMAP 

CP15_S_PRIVILEGED_ID CP15 Privileged only Thread and Process ID read-write 

Secure register 

CP15_S_TTBC CP15 TTB Control Secure register read-write 

CP15_S_TTBR0 CP15 TTB Secure Register 0 read-write 

CP15_S_TTBR1 CP15 TTB Secure Register 1 read-write 

CP15_S_USER_RO_ID CP15 User read-only Thread and Process ID read-write 


CP15_S_USER_RW_ID CP15 User read/write Thread and Process ID read-write 


CP15_S_VECTOR_BASE CP15 Monitor Vector Base Address Secure register 

read-write 



1.5.1.12 Debug Registers 

The Debug group provides access to the current debug state. 

Table 1-15 Debug Registers 


CP14_DIDR Debug ID Register read-only 

CP14_DBGROMADDR Debug ROM Address Register read-only 

CP14_DBGSELFADDR Debug Self Address Offset Register read-only 

CP14_DSCR Debug Status and Control register read-only 

CP14_DTRRX Data Transfer Register - Receive read-only 

CP14_DTRTX Data Transfer Register - Transmit write-only 

THUMB2EE_CONFIG ThumbEE Configuration Register read-write 1 

THUMB2EE_HANDLER_BASE ThumbEE Handler Base Register read-write 1 

CP14_JAZELLE_ID Jazelle Identity Register read-only 

CP14_JAZELLE_OS_CONTROL Jazelle OS Control Register read-only 

CP14_JAZELLE_CONFIGURATION Jazelle Main Configuration Register read-only 

1. Read/Write in Privileged modes. 



1.5.2 Run To Debug Point 

The “run to debug point” feature enhances model debugging. The Cortex-A8 processor is 

a dual issue out of order completion machine. This means that while the processor is running 

it does not present a coherent programmer’s view state; instructions in the pipeline 

may be in different execution states. 

This feature forces the processor into a coherent state called “run to debug point”. When 

debugging with the ARM RealView Development Suite (RVDS), the model is brought to 

the debug point automatically whenever a software breakpoint is hit (including single 

stepping). However, if a hardware breakpoint is reached, or the system is advanced by 

cycles within SoC Designer, the model can get to a non-debuggable state. In this event, the 

run to debug point will advance the processor to the debug state. It does this by stalling the 

instruction within the decode stage and allowing all earlier instructions to complete. Once 

that has been accomplished, the model will cause the system to stop simulating. 

The run to debug point is available as a context menu item (Run to Debuggable Point) for 

the component within SoC Designer Simulator. It is also available in the disassembler 

view. 

1.5.3 Memory Information 

Figure 1-4 shows a Memory view of Cortex-A8 model. 

Figure 1-4 Cortex-A8 Memory View 

The display only provides a virtual memory view from the core’s perspective. However, 

the “axiport” space shows the physical memory view from the perspective of the axi interface. 



1.5.4 Disassembly View 

Figure 1-5 shows the disassembly view of a program running on the Cortex-A8 model in 

SoC Designer Simulator. To display the disassembly view in the SoC Designer Simulator, 

right-click on the Cortex-A8 model and select View Disassembly… from the context 

menu. 

Figure 1-5 Cortex-A8 Disassembly Window 

All CADI windows support breakpoints – when double-clicking on the proper location a 

red dot will indicate that a breakpoint is currently active. To remove the breakpoints simply 

double-click on the same location again. 

The instruction step button has a minimum granularity of one cycle. The Cortex-A8 can 

dual-issue many instruction pairs, which will result in the instruction step button completing 

two instructions instead of one. 

Breakpoints also have a minimum granularity of one cycle. When a breakpoint is placed 

on an instruction, program execution will always stop one cycle before that instruction 

completes. If the instruction was dual-issued into the younger pipe, this will mean that the 

program counter is pointing to the instruction before that which triggered the breakpoint. 


Available Profiling Data 1-23 

1.6 Available Profiling Data 

Profiling data is enabled, and can be viewed using the Profiling Manager, which is accessible 

via the Debug menu in the SoC Designer Simulator. Both hardware and software 

based profiling is available. 

1.6.1 Hardware Profiling 

Hardware profiling is broken down into six streams per processor core. They are the 

L1 events, L2 events, TLB events, Core events, Branch events, and Interface events. The 

buckets supported by each of these streams are shown in Table 1-16: 

Table 1-16 Cortex-A8 Profiling Events 

Stream Buckets X axis Y axis 

L1 Events ICache refill Cycle L1 events 

DCache refill 

DCache access 

Data read 

Data write 

L1 miss (0x49) 

L1 miss (0x4A) 

L1 page color 

L1 neon hit 

L1 neon access 

L1 cache access 

L2 Events L2 store merge Cycle L2 events 

L2 buffer 

L2 access 

L2 cache miss 

L2 neon access 

L2 neon hit 

TLB Events ITLB refill Cycle TLB 

DTLB refill 

Core Events SW increment Cycle Core events 

Instr exec 

CID write 



Table 1-16 Cortex-A8 Profiling Events (Continued) 

Stream Buckets X axis Y axis 

Core Events Unalign access Cycle Core events 

Buffer full 

Replay 

Unaligned replay 

Op issue 

No avail inst issue 

Inst issue 

Stall MRC 

Stall 

Non-idle 

Branch Events Exp taken Cycle Branch events 

Exp return 

PC change 

Imm branch 

Proc return 

Branch mispred 

Branch pred 

Ret stk mispred 

Brnch dir mispred 

Brnch pred not-taken 

Brnch pred taken 

Interface Events AXI data read Cycle Interface events 

AXI data write 

PMUEXTIN[0] 

PMUEXTIN[1] 

PMUEXTIN[1 or 0] 


Available Profiling Data 1-25 

An example of debug information for a software stream is shown below. 

Figure 1-6 Software Stream Debug Information 

1.6.2 Software Profiling 

Software-based profiling is provided by SoC Designer. Profiling information is also available 

in the SoC Designer Profiler. See the user guide for SoC Designer or SoC Designer 

Profiler for more information.

Carbon Cortex-A8 Model User Guide for SoC Designer

Create successful ePaper yourself

Delete template?

Save as template?