Cortex -M3

Revision: r2p0

Integration Manual
Confidential

Copyright © 2005-2008 ARM Limited. All rights reserved.

ARM DII 0113E
 Cortex-M3
Integration Manual

Copyright © 2005-2008 ARM Limited. All rights reserved.

Release Information

The following changes have been made to this book.

Change history

Date Issue Confidentiality Change

15 December 2005 A Confidential First release

10 May 2006 B Confidential First release for r1p0

27 September 2006 C Confidential First release for r1p1

13 June 2007 D Confidential Minor update with no technical changes

27 June 2008 E Confidential First release for r2p0

Proprietary Notice

Words and logos marked with ® or ™ are registered trademarks or trademarks of ARM Limited in the EU and
other countries, except as otherwise stated below in this proprietary notice. Other brands and names
mentioned herein may be the trademarks of their respective owners.

Neither the whole nor any part of the information contained in, or the product described in, this document
may be adapted or reproduced in any material form except with the prior written permission of the copyright
holder.

The product described in this document is subject to continuous developments and improvements. All
particulars of the product and its use contained in this document are given by ARM in good faith. However,
all warranties implied or expressed, including but not limited to implied warranties of merchantability, or
fitness for purpose, are excluded.

This document is intended only to assist the reader in the use of the product. ARM Limited shall not be liable
for any loss or damage arising from the use of any information in this document, or any error or omission in
such information, or any incorrect use of the product.

Where the term ARM is used it means “ARM or any of its subsidiaries as appropriate”.

Confidentiality Status

This document is Confidential. This document may only be used and distributed in accordance with the terms
of the agreement entered into by ARM and the party that ARM delivered this document to.

Product Status

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

ii Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Web Address

http://www.arm.com

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. iii
Confidential
iv Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Contents
Cortex-M3 Integration Manual

Preface
About this book ............................................................................................ xiv
Feedback ..................................................................................................... xix

Chapter 1 Introduction
1.1 About integration ......................................................................................... 1-2
1.2 Integration options ...................................................................................... 1-3
1.3 About the processor .................................................................................... 1-5
1.4 Typical integration design flow .................................................................... 1-7
1.5 Deliverables ................................................................................................ 1-9

Chapter 2 Key Integration Points

2.1 About key integration points ........................................................................ 2-2
2.2 Key Cortex-M3 integration tasks ................................................................. 2-3
2.3 Key CortexM3Integration integration tasks ................................................. 2-5

Chapter 3 Functional Integration Guidelines

3.1 About functional integration ........................................................................ 3-2
3.2 Clocks and resets ....................................................................................... 3-4
3.3 AHB bus interfaces ................................................................................... 3-10
3.4 APB interface ............................................................................................ 3-18
3.5 Miscellaneous signals ............................................................................... 3-19

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. v
Confidential
Contents

3.6 Low power interface ................................................................................. 3-23

3.7 Debug access ........................................................................................... 3-25
3.8 Embedded Trace Macrocell ...................................................................... 3-27
3.9 Trace interface .......................................................................................... 3-30
3.10 HTM interface ........................................................................................... 3-32
3.11 SWJ-DP interface ..................................................................................... 3-33
3.12 SW-DP Interface ....................................................................................... 3-34
3.13 Trace port interface .................................................................................. 3-35

Chapter 4 DFT Guidelines

4.1 About DFT guidelines ................................................................................. 4-2
4.2 Scan chains ................................................................................................ 4-3
4.3 Production test modes ................................................................................ 4-5
4.4 Manufacturing test interface ..................................................................... 4-11

Chapter 5 DFT Verification Considerations

5.1 About DFT verification considerations ........................................................ 5-2
5.2 Checking that INTEST ATPG vectors are replayed ................................... 5-3
5.3 Using the EXTEST wrapper model ............................................................. 5-4

Chapter 6 Design Synthesis

6.1 About synthesis .......................................................................................... 6-2
6.2 Timing models ............................................................................................ 6-3
6.3 Clock tree latency ....................................................................................... 6-5

Chapter 7 Physical Integration Guidelines

7.1 About physical integration .......................................................................... 7-2
7.2 Floorplanning .............................................................................................. 7-3
7.3 Place and route .......................................................................................... 7-6
7.4 Physical integration checks ........................................................................ 7-8

Chapter 8 Post-Layout Verification

8.1 About verification ........................................................................................ 8-2
8.2 Formal equivalence checks ........................................................................ 8-4
8.3 Static Timing Analysis ................................................................................ 8-5

Chapter 9 Sign-Off Guidelines

9.1 About sign-off ............................................................................................. 9-2

Appendix A Example System

A.1 About the Cortex-M3 Example System ...................................................... A-2
A.2 Directory structure ...................................................................................... A-3
A.3 Testbench structure .................................................................................... A-5
A.4 Test overview ............................................................................................. A-8
A.5 Compiling and running scripts .................................................................. A-10

vi Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Contents

A.6 Trace verification scripts ........................................................................... A-12

A.7 Modifying RTL ........................................................................................... A-13
A.8 Modifying Tests ......................................................................................... A-16

Appendix B Revisions

Glossary

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. vii
Confidential
Contents

viii Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
List of Tables
Cortex-M3 Integration Manual

Change history .............................................................................................................. ii

Table 1-1 Integration design flow references ............................................................................ 1-8
Table 2-1 Key Cortex-M3 integration tasks ............................................................................... 2-3
Table 2-2 Key Cortex-M3Integration tasks ................................................................................ 2-5
Table 3-1 Clocks and resets at the CortexM3 level ................................................................... 3-4
Table 3-2 Clocks and resets at the CortexM3Integration level .................................................. 3-5
Table 3-3 Reset modes ............................................................................................................. 3-6
Table 3-4 ICode interface signals ............................................................................................ 3-11
Table 3-5 DCode interface signals .......................................................................................... 3-12
Table 3-6 System bus Interface signals .................................................................................. 3-15
Table 3-7 APB interface signals .............................................................................................. 3-18
Table 3-8 Miscellaneous Interface signals .............................................................................. 3-19
Table 3-9 Low power interface signals .................................................................................... 3-23
Table 3-10 AHB-AP interface signals ........................................................................................ 3-25
Table 3-11 ETM interface signals .............................................................................................. 3-27
Table 3-12 Miscellaneous ETM connections ............................................................................. 3-29
Table 3-13 ITM interface signals with no ETM present ............................................................. 3-30
Table 3-14 ITM interface signals with ETM present .................................................................. 3-30
Table 3-15 HTM interface signals ............................................................................................. 3-32
Table 3-16 Debug interface signals ........................................................................................... 3-33
Table 3-17 SW-DP Interface signals ......................................................................................... 3-34
Table 3-18 Trace port interface signals ..................................................................................... 3-35
Table 4-1 Processor scan test ports .......................................................................................... 4-3

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. ix
Confidential
List of Tables

Table 4-2 Wrapper ports ........................................................................................................... 4-5

Table 4-3 Manufacturing test signal descriptions .................................................................... 4-11
Table 4-4 Test signal configurations ....................................................................................... 4-13
Table 6-1 Summary of synthesis deliverables .......................................................................... 6-3
Table A-1 run_example run options ........................................................................................ A-10
Table A-2 run_example build options ...................................................................................... A-11
Table B-1 Differences between issue D and issue E ................................................................ B-1

x Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
List of Figures
Cortex-M3 Integration Manual

Key to timing diagram conventions ........................................................................... xvii

Figure 1-1 SoC integration examples ......................................................................................... 1-3
Figure 1-2 Macrocell block view ................................................................................................. 1-6
Figure 1-3 Integration design flow .............................................................................................. 1-7
Figure 3-1 CortexM3Integration level interfaces ......................................................................... 3-2
Figure 3-2 CortexM3 level interfaces .......................................................................................... 3-3
Figure 3-3 Cortex-M3 reset signals ............................................................................................ 3-7
Figure 3-4 Power-on reset .......................................................................................................... 3-8
Figure 4-1 Shadow logic ............................................................................................................. 4-4
Figure 4-2 INTEST mode of operation ....................................................................................... 4-6
Figure 4-3 EXTEST mode of operation ...................................................................................... 4-8
Figure 6-1 Synthesis process ..................................................................................................... 6-2
Figure 6-2 HCLK clock latency ................................................................................................... 6-5
Figure 7-1 Physical integration process ..................................................................................... 7-2
Figure 7-2 Correct signal connections ........................................................................................ 7-5
Figure 8-1 Formal equivalence check verification process ......................................................... 8-2
Figure 8-2 STA verification process ........................................................................................... 8-3
Figure 8-3 Dynamic verification process .................................................................................... 8-3
Figure A-1 Example System directory structure ......................................................................... A-3
Figure A-2 Preprocessing scripts flow ........................................................................................ A-7

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. xi
Confidential
List of Figures

xii Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Preface

This preface introduces the Cortex-M3 Integration Manual. It contains the following
sections:
• About this book on page xiv
• Feedback on page xix.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. xiii
Confidential
Preface

About this book

This book is for the Cortex-M3 processor. This manual provides information that you
require to integrate the processor into your System on Chip (SoC) design. It does not
describe how to run specific tools to perform a specific task.

This manual is based on the synthesizable core delivered by ARM. The processor is
split into two levels of hierarchy, CortexM3 and CortexM3Integration. Depending on the
final SoC product, either level of hierarchy can be pre-hardened. Alternatively, if the
SoC is small enough, it might not be necessary to pre-harden the processor. This manual
describes the flow for each of the three possible integration approaches.

Note
In this integration manual, the term processor refers to the CortexM3Integration level of
hierarchy, unless explicit reference is made to other processors.

Product revision status

The rnpn identifier indicates the revision status of the product described in this book,
where:
rn Identifies the major revision of the product.
pn Identifies the minor revision or modification status of the product.

Intended audience

This manual is written for experienced SoC engineers who understand SoC integration
issues and processes, but might have limited experience of the integration of ARM
products.

Using this manual

This manual is organized into the following chapters:

Chapter 1 Introduction
Read this chapter for a top-level description of the processor integration
options, supported integration design flow, tools used, and the
deliverables.

Chapter 2 Key Integration Points

Read this for a description of the key points that you must consider when
you integrate the processor with your SoC design.

xiv Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Preface

Chapter 3 Functional Integration Guidelines

Read this for a description of how to approach functional integration of
the processor with your SoC design.

Chapter 4 DFT Guidelines

Read this for a description of how to approach Design For Test (DFT) of
the processor in your SoC design, and how to use the different test modes
of the processor and replay test patterns at the SoC level.

Chapter 5 DFT Verification Considerations

Read this for a description of how to convert and replay test vectors on
the processor in your SoC design.

Chapter 6 Design Synthesis

Read this for a description of how to synthesize your SoC RTL with the
processor.

Chapter 7 Physical Integration Guidelines

Read this for a description of how to approach physical integration of the
processor with your SoC design, and for information on the place and
route process and checks on the physical layout.

Chapter 8 Post-Layout Verification

Read this for a description of how to verify your design using static
verification by formal equivalence checks and Static Timing Analysis
(STA), and dynamic verification of the processor in your SoC design.

Chapter 9 Sign-Off Guidelines

Read this chapter for a description of how to perform technical sign-off
of the processor in your SoC design.

Appendix A Example System

Read this for a description of the Cortex-M3 Example System.

Appendix B Revisions
Read this for a description of the technical changes between released
issues of this book.

Glossary Read this for definitions of terms used in this manual.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. xv
Confidential
Preface

Conventions

Conventions that this manual can use are described in:

• Typographical
• Timing diagrams
• Signals on page xvii.

Typographical

The typographical conventions are:

italic Highlights important notes, introduces special terminology,

denotes internal cross-references, and citations.

bold Highlights interface elements, such as menu names. Denotes

processor signal names. Also used for terms in descriptive lists,
where appropriate.

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

monospace Denotes a permitted abbreviation for a command or option. You

can enter the underlined text instead of the full command or option
name.

monospace italic Denotes arguments to monospace text where the argument is to be

replaced by a specific value.

monospace bold Denotes language keywords when used outside example code.

< and > Angle brackets enclose replaceable terms for assembler syntax
where they appear in code or code fragments. They appear in
normal font in running text. For example:
MRC p15, 0 <Rd>, <CRn>, <CRm>, <Opcode_2>

Timing diagrams

The figure named Key to timing diagram conventions on page xvii 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 shaded area at that time. The actual level is unimportant and does not affect
normal operation.

xvi Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Preface

Clock

HIGH to LOW

Transient

HIGH/LOW to HIGH

Bus stable

Bus to high impedance

Bus change

High impedance to stable bus

Key to timing diagram conventions

Signals

The signal conventions are:

Signal level The 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.

Lower-case n At the start or end of a signal name denotes an active-LOW signal.

Prefix A Denotes global Advanced eXtensible Interface (AXI) signals.

Prefix AR Denotes AXI read address channel signals.

Prefix AW Denotes AXI write address channel signals.

Prefix B Denotes AXI write response channel signals.

Prefix C Denotes AXI low-power interface signals.

Prefix H Denotes Advanced High-performance Bus (AHB) signals.

Prefix P Denotes Advanced Peripheral Bus (APB) signals.

Prefix R Denotes AXI read data channel signals.

Prefix W Denotes AXI write data channel signals.

Further reading

This section lists publications by ARM and by third parties.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. xvii
Confidential
Preface

See http://infocenter.arm.com for access to ARM documentation.

ARM publications

This book contains information that is specific to this product. See the following
documents for other relevant information:
• ARM AMBA® 3 AHB-Lite Protocol (v1.0) (ARM IHI 0033)
• ARM AMBA Design Kit Technical Reference Manual (ARM DDI 0243)
• ARMv7-M Architecture Reference Manual (ARM DDI 0403)
• ARM CoreSight™ Components Technical Reference Manual (ARM DDI 0314)
• ARM Cortex-M3 Technical Reference Manual (ARM DDI 0337)
• ARM Design Simulation Model Flow Integration Guide (ARM DUI 0219)
• ARM RealView®-ICE User Guide (ARM DUI 0220)
• ARM Design Simulation Model User Guide (ARM DUI 0302).

xviii Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Preface

Feedback
ARM welcomes feedback on this product and its documentation.

Feedback on the 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

if appropriate.

Feedback on this manual

If you have any comments on this manual, send email to [email protected]:

• the title
• the number
• the relevant page number(s) to which your comments apply
• a concise explanation of your comments.

ARM also welcomes general suggestions for additions and improvements.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. xix
Confidential
Preface

xx Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 1
Introduction

This chapter describes the processor and provides an overview of the integration process
of the processor into your SoC design. It contains the following sections:
• About integration on page 1-2
• Integration options on page 1-3
• About the processor on page 1-5
• Typical integration design flow on page 1-7
• Deliverables on page 1-9.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 1-1
Confidential
Introduction

1.1 About integration

Integration is the final major phase in the process for the inclusion of the processor in
your SoC design. Integration involves:
• connection of the processor to all the necessary peripherals and buses
• connection of the required clocks and resets to the processor
• implementation of the chosen test strategies for the processor
• verification of the processor within the SoC design.

For a description of the integration flow, see Typical integration design flow on
page 1-7.

There are various implications for your design, depending on the elements that you
include. You must consider:
• interfaces, especially the treatment of unused signals
• Design For Test (DFT) strategies
• physical integration and layout
• verification.

You might have different elements in your SoC design but the main connections are:

• Advanced High-performance Bus (AHB) bus conforming to the Advanced

Microcontroller Bus Architecture (AMBA)

• Trace Port Interface

• Serial Wire or JTAG interface

• Embedded Trace Macrocell (ETM) interface.

You must also integrate:

• clocks and resets
• power connections
• debug signals
• miscellaneous signals such as interrupts.

1-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Introduction

1.2 Integration options

Figure 1-1 shows the processor hierarchy, with the main interfaces shown.

CortexM3Integration

CortexM3
ETM CM3ETM
INTISR Interrupt interface
INTNMI Interface

Trace
CM3TPIU Trace port
interface
Low power WIC
interface
PPB CM3ROM
interface Table

JTAG and ICode

SWJ-DP AHB-AP AHBLite
Serial Wire interface
or (Debug)
(SW) interface AHBLite DCode
SW-DP
interface interface
AHBLite System
interface

Figure 1-1 SoC integration examples

The components of the Cortex-M3 system are split across two levels of hierarchy:
• CortexM3Integration level
• CortexM3 level.

There are three integration options for the processor:

• If the processor does not have to be pre-hardened you can integrate the Cortex-M3
RTL, CortexM3Integration level into your top-level SoC RTL and perform
synthesis and Place and Route from that level. The processor does not have
registered bus interfaces, and so this is the integration approach that ARM
recommends because it enables the tools to have complete visibility of entire
timing paths. This option is only available to partners. If you do not have a license
for the RTL contact your implementation team. See the Cortex-M3 Technical
Reference Manual for more details of the bus interface timing.

• The CortexM3Integration level can be provided pre-hardened for integration into

your SoC.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 1-3
Confidential
Introduction

• The CortexM3 level can be pre-hardened for use, for example, in a multi-core
system. In this case, the Cortex-M3 processor or processors must be integrated
into the CortexM3Integration level and the top-level SoC. The Cortex-M3
Implementation Guide describes the implementation options for the five
CortexM3Integration level components shown in Figure 1-1 on page 1-3.

The integration flow is similar in all three cases.

To integrate the CortexM3 level, connect the following interfaces:

• Clocks and resets, see Clocks and resets on page 3-4
• AHB bus interfaces, see AHB bus interfaces on page 3-10
• Miscellaneous signals, see Miscellaneous signals on page 3-19
• Debug interface, see Debug access on page 3-25
• ETM interface, see Embedded Trace Macrocell on page 3-27
• Trace interface, see Trace interface on page 3-30
• Low power interface, see Low power interface on page 3-23.

To integrate the CortexM3Integration level, connect the following interfaces:

• Clocks and resets, see Clocks and resets on page 3-4
• AHB bus interfaces, see AHB bus interfaces on page 3-10
• APB interface, APB interface on page 3-18
• Miscellaneous signals, see Miscellaneous signals on page 3-19
• SWJ-DP interface, see SWJ-DP interface on page 3-33
• SW-DP interface, see SW-DP Interface on page 3-34
• Trace port interface, see Trace port interface on page 3-35.
• Low power interface, see Low power interface on page 3-23.

Note
The supplied CortexM3Integration contains ports that are only used for the ARM
validation flow. The code included by the 'TestBench define must not be included
during the integration flow.

1-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Introduction

1.3 About the processor

The processor is an instantiation of the Cortex-M3 synthesizable processor.

Note
• CortexM3Integration level integration is the normal flow, and therefore that is the
flow described in this manual. Where appropriate, interfaces are described to
support the integration of the CortexM3 level.

• In this integration manual, the term processor refers to the CortexM3Integration

level of hierarchy, unless explicit reference is made to other processors.

The processor comprises:

• A processor core.
• An optional test wrapper. Figure 1-2 on page 1-6 shows the processor with a test
wrapper. Because the Cortex-M3 bus interfaces are not registered, the
recommended approach is that a test wrapper is not included because this is
detrimental to timing performance. If the processor is pre-hardened a test wrapper
is included.
• An optional Wake-up Interrupt Controller (WIC)
• An optional Embedded Trace Macrocell (ETM).
• An optional Memory Protection Unit (MPU).
• An optional Trace Port Interface Unit (TPIU).
• An optional Serial Wire and JTAG Debug Port (SWJ-DP).
• An optional Serial Wire Debug Port (SW-DP).
• Number of interrupts, and interrupt priorities, chosen by the implementation
team.
• Embedded scan chains with a scan test interface.

Note
The number of interrupts and interrupt priorities, and inclusion of ETM, MPU, WIC,
SWJ-DP or SW-DP and TPIU, are determined at the hardening stage by the
implementation team.

For specific information relating to your configuration, see the configuration report file
supplied with the processor.

The processor has passed the following tests:

• equivalence checks that prove the final netlist is logically equivalent to the RTL
• layout versus schematic checks
• design rules check

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 1-5
Confidential
Introduction

• antenna rules check

• static timing checks.

Figure 1-2 shows a macrocell block view.

Macrocell
Input test wrapper chain WSIO

WSOO

Macrocell
inputs
Cortex-M3 processor

WSII

WSOI Output test wrapper chain

Macrocell outputs

Figure 1-2 Macrocell block view

1-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Introduction

1.4 Typical integration design flow

This document assumes that you follow a standard SoC design flow. Figure 1-3 shows
a simplified version of this design flow.

DFT guidelines Start Functional integration

guidelines

ARM deliverable and

installation Verification

Your SoC design

Synthesis

Verification of post-
synthesized netlist

No
LEC passes?

Yes

DFT verification Physical integration

guidelines

SoC ATPG Physical integration

Verification of post-
layout netlist

STA/LEC/ No
ATPG replay
passes
?
Yes
Sign-off

End

Figure 1-3 Integration design flow

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 1-7
Confidential
Introduction

Table 1-1 shows the chapters in this manual that relate to the document inputs shown in
Figure 1-3 on page 1-7.

Table 1-1 Integration design flow references

Input Reference

DFT guidelines See Chapter 4 DFT Guidelines

Functional integration guidelines See Chapter 3 Functional Integration Guidelines

DFT verification See Chapter 5 DFT Verification Considerations

Physical integration guidelines See Chapter 7 Physical Integration Guidelines

1-8 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Introduction

1.5 Deliverables
Before starting you must ensure that the unpacked deliverables are located in the correct
directory structure.

Note
For more information on the processor deliverables and directory structure contact your
implementation team.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 1-9
Confidential
Introduction

1-10 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 2
Key Integration Points

This chapter describes the key integration points you must consider when you integrate
the processor with your SoC design. It contains the following sections:
• About key integration points on page 2-2
• Key Cortex-M3 integration tasks on page 2-3
• Key CortexM3Integration integration tasks on page 2-5.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 2-1
Confidential
Key Integration Points

2.1 About key integration points

This chapter contains a list of the main points to consider when you integrate the
processor with your SoC design. You must read this chapter in conjunction with the rest
of the information in this book, and the information referred to in Further reading on
page xvii.

You can use this chapter to check that you have covered the integration steps described
in the other chapters, but you must complete all the integration steps described in the
later chapters.

2-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Key Integration Points

2.2 Key Cortex-M3 integration tasks

Table 2-1 lists key tasks for Cortex-M3 integration.

Table 2-1 Key Cortex-M3 integration tasks

Key task Description

1. Generate clocks and resets correctly. See Clocks and resets on page 3-4

2. Define the HCLK, FCLK, and DAPCLK signals to include See Clock tree latency on page 6-5
latency for the processor during synthesis.

3. Generate PORESETn, SYSRESETn, and DAPRESETn See Reset on page 3-6

correctly.

4. Separate PORESETn and SYSRESETn to enable warm See Reset on page 3-6
reset of the processor.

5. Separate PORESETn and DAPRESETn to enable See Reset on page 3-6

debugging at reset.

6. Deassert PORESETn, SYSRESETn, and DAPRESETn See Clocks and resets on page 3-4
correctly.

7. During reset, hold resets LOW for at least three cycles. See Clocks and resets on page 3-4

8. Make sure that a tester can control PORESETn and See Clocks and resets on page 3-4
DAPRESETn during production test.

9. Make sure DAPEN can be switched to 1 by the debugger or See Table 3-10 on page 3-25
tie it HIGH to enable debug. The CortexM3Integration module
drives this signal by means of the SWJ-DP.

10. Tie off or connect all device inputs appropriately. See Chapter 3 Functional Integration Guidelines

11. Set BIGEND to suit your system. See Miscellaneous signals on page 3-19

12. Tie off PPBLOCK, IFLUSH, and STKALIGNINIT. See Miscellaneous signals on page 3-19

13. Use the correct pin assignments, during DFT, to avoid ATPG See Table 4-4 on page 4-13
replay failure. If any signals in Table 4-4 on page 4-13 are not
correctly configured the test patterns might not work.

14. Use the EXTEST wrapper model for test of the shadow logic See SoC test shadows and the processor on
if pre-hardening the processor. page 4-3

15. Connect scan signals correctly. See Scan chains on page 4-3

16. Install the Design Simulation Model (DSM) to verify your See the Design Simulation Model User Guide
design.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 2-3
Confidential
Key Integration Points

Table 2-1 Key Cortex-M3 integration tasks (continued)

Key task Description

17. Use STA and formal equivalence checks for post-layout See Chapter 8 Post-Layout Verification
verification.

18. Compile the timing view. See Using the timing models on page 6-3

19. Set up your synthesis and Static Timing Analysis (STA) See Using the timing models on page 6-3 and
environments to use the compiled timing views of the Static Timing Analysis on page 8-5
processor.

20. Connect all power and ground pins correctly during See Power connections on page 7-4
floorplanning.

21. Place the processor, observing all requirements and See Placement on page 7-3
considering all implications.

22. Conform to the processor routing restrictions. See Routing restrictions on page 7-6

2-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Key Integration Points

2.3 Key CortexM3Integration integration tasks

Table 2-2 lists key tasks for Cortex-M3Integration integration.

Table 2-2 Key Cortex-M3Integration tasks

Key task Description

1. Generate clocks and resets correctly. See Clocks and resets on page 3-4

2. Define the HCLK, FCLK, and SWCLKTCK signals to See Clock tree latency on page 6-5
include latency for the processor during synthesis.

3. Generate PORESETn, SYSRESETn, and nTRST correctly. See Reset on page 3-6

4. Separate PORESETn and SYSRESETn to enable warm See Reset on page 3-6
reset of the processor.

5. Separate PORESETn and nTRST to enable debugging at See Reset on page 3-6
reset.

6. Deassert PORESETn, SYSRESETn, and nTRST correctly. See Clocks and resets on page 3-4

7. During reset, hold resets LOW for at least three cycles. See Clocks and resets on page 3-4

8. Make sure that a tester can control PORESETn and nTRST See Clocks and resets on page 3-4
during production test.

9. Tie off or connect all device inputs appropriately. See Chapter 3 Functional Integration Guidelines

10. Set the master define for ETM present or not. In -

CortexM3Integration.v there is the following line:
define `ARM_ETM_LICENSE
You must comment this line out if the ETM is not licensed and
leave it in if the ETM is licensed.

11. Set the parameters of CortexM3Integration.v to the required See the Cortex-M3 Configuration and Sign-off
value or override them when instantiating the module. Guide for more information

12. Set BIGEND to suit your system. See Miscellaneous signals on page 3-19

13. Use the EXTEST wrapper model for test of the shadow logic See SoC test shadows and the processor on
if pre-hardening the processor. page 4-3

14. Connect scan signals correctly. See Scan chains on page 4-3

15. Install the Design Simulation Model (DSM) to verify your See the Design Simulation Model User Guide
design.

16. Use STA and formal equivalence checks for post-layout See Chapter 8 Post-Layout Verification
verification.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 2-5
Confidential
Key Integration Points

Table 2-2 Key Cortex-M3Integration tasks (continued)

Key task Description

17. Compile the timing view. See Using the timing models on page 6-3

18. Set up your synthesis and Static Timing Analysis (STA) See Using the timing models on page 6-3 and
environments to use the compiled timing views of the Static Timing Analysis on page 8-5
processor.

19. Connect all power and ground pins correctly during See Power connections on page 7-4
floorplanning.

20. Place the processor, observing all requirements and See Placement on page 7-3
considering all implications.

21. Conform to the processor routing restrictions. See Routing restrictions on page 7-6

2-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 3
Functional Integration Guidelines

This chapter describes the guidelines for functional integration of the processor in your
SoC design. It contains the following sections:
• About functional integration on page 3-2
• Clocks and resets on page 3-4
• AHB bus interfaces on page 3-10
• APB interface on page 3-18
• Miscellaneous signals on page 3-19
• Low power interface on page 3-23
• Debug access on page 3-25
• Embedded Trace Macrocell on page 3-27
• Trace interface on page 3-30
• HTM interface on page 3-32
• SWJ-DP interface on page 3-33
• SW-DP Interface on page 3-34
• Trace port interface on page 3-35.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-1
Confidential
Functional Integration Guidelines

3.1 About functional integration

This chapter contains information that you must consider before or during the
integration of the processor into your SoC design. The chapter only provides
information about functional integration of the processor. For information on physical
integration see Chapter 7 Physical Integration Guidelines.

Figure 3-1 shows the main interfaces of the CortexM3Integration level that you must
integrate into your SoC.

Trace port Trace signals

Clocks Clocks
and
Resets resets

Test Scan signals System control Miscellaneous

signals
Test wrapper Interrupts signals
CortexM3Integration

SWJ-DP ICode interface

interface
DCode interface AHB ports

System interface

Figure 3-1 CortexM3Integration level interfaces

Figure 3-2 on page 3-3 shows the main interfaces of the CortexM3 level that you must
integrate into your SoC.

3-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Trace signals Clocks Clocks

Trace
and
interface ETM Interface Resets resets

System control Miscellaneous

Test Scan signals
Interrupts signals
signals
Test wrapper

CortexM3

ICode interface

DCode interface AHB ports

Debug
AHB-AP System interface
interface

PPB interface APB port

Figure 3-2 CortexM3 level interfaces

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-3
Confidential
Functional Integration Guidelines

3.2 Clocks and resets

This section provides information on how to use the processor clocks and resets in your
SoC design. See Chapter 6 Clocking and Resets in the Cortex-M3 Technical Reference
Manual.

From the deassertion of reset, the core comes out of reset a maximum of four clock
cycles later.

You can stop all of the processor clocks indefinitely without loss of state.

Table 3-1 shows the system clock and reset signals present in the processor at the
CortexM3 level, and how you use these signals in your SoC design.

Table 3-1 Clocks and resets at the CortexM3 level

Name Direction Description Connection information

HCLK Input Main Cortex-M3 clock. Must be synchronous and balanced to

FCLK.

FCLK Input Free running Cortex-M3 clock. Must be synchronous and balanced to
HCLK.

DAPCLK Input AHB-AP clock. Asynchronous to FCLK and HCLK.

PORESETn Input Power-on-reset. Resets entire Cortex-M3 Connect to your reset controller, see
system. Reset on page 3-6.

SYSRESETn Input The SYSRESETn signal resets the Connect to your reset controller.
processor excluding debug logic in the
NVIC, FPB, DWT, and ITM.

DAPRESETn Input AHB-AP reset. Connect to your reset controller.

SYSRESETREQ Output System reset request. Connect to a Watchdog, for example,

to drive SYSRESETn.

3-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-2 shows the system clock and reset signals present in the processor at the
CortexM3Integration level, and how you use these signals in your SoC design.

Table 3-2 Clocks and resets at the CortexM3Integration level

Name Direction Description Connection information

HCLK Input Main Cortex-M3 clock. Must be synchronous and balanced to

FCLK.

FCLK Input Free running Cortex-M3 clock. Must be synchronous and balanced to
HCLK.

SWCLKTCK Input Serial wire clock and JTAG Test clock. Asynchronous to FCLK and HCLK.

PORESETn Input Power-on-reset. Resets entire Cortex-M3 Connect to your reset controller, see
system. Reset on page 3-6.

SYSRESETn Input The SYSRESETn signal resets the processor Connect to your reset controller.
excluding debug logic in the NVIC, FPB,
DWT, and ITM.

nTRST Input JTAG reset. Connect to external debug interface or

reset controller.

SYSRESETREQ Output System reset request. Connect to a Watchdog, for example,

to drive SYSRESETn.

3.2.1 Clock tree latency

You must compensate for the latency of the clock tree in the processor during both the
synthesis stage and the physical integration phases of the SoC.

For compensations applied during synthesis see Chapter 6 Design Synthesis. For
compensations applied during physical integration see Chapter 7 Physical Integration
Guidelines.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-5
Confidential
Functional Integration Guidelines

3.2.2 Clock tree insertion

HCLK and FCLK must be synchronous with the same insertion delay. All other clocks
are asynchronous with respect to these clocks.

3.2.3 Reset

The processor reset inputs are:

SYSRESETn This signal resets the processor excluding debug logic in the
NVIC, FPB, DWT, and ITM.

PORESETn This signal is the power-on reset that initializes the entire
processor.

DAPRESETn This signal is the AHB-AP reset.

nTRST This signal is the SWJ-DP JTAG reset. It only exists at the
CortexM3Integration level.

All of these are active LOW signals that reset logic in the processor. You must take care
when designing the logic to drive these reset signals.

Reset modes

The reset signals present in the processor design enable you to reset different parts of
the design independently. Table 3-3 shows the reset signals, and the combinations and
possible applications that you can use them in.

Table 3-3 Reset modes

Reset mode SYSRESETn nTRST DAPRESETn PORESETn Application

Power-on reset x 0 0 0 Reset at power on, full system reset.

Cold reset.

Processor reset 0 x x 1 Reset of processor core only,

excluding debug logic. Warm reset.

SWJ-DP reset 1 0 1 0 Reset of SWJ-DP and processor

including debug logic

SW-DP reset 1 x 1 0 Reset of SW-DP and processor

including debug logic

AHB-AP reset 1 1 0 1 Reset of AHB-AP logic

3-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Note
PORESETn resets a superset of the SYSRESETn logic.

Power-on reset

Figure 3-3 shows the reset signals for the processor.

ARM Cortex-M3

NVIC CM3Core
SYSRESETREQ
VECTRESET
NVICDBGRESETn NVICRESETn CORERESETn

System components
WATCHDOG
SYSRESETn (BusMatrix, MPU)

System debug
PORESETn Components
(FPB, DWT, ITM)
DAPRESETn AHB-AP

Figure 3-3 Cortex-M3 reset signals

You must apply power-on or cold reset to the processor when power is first applied to
the system. In the case of power-on reset, the de-assertion of the reset signals has to be
synchronous to HCLK. The CortexM3Integration level contains synchronizers for the
resets, but if you are integrating the CortexM3 level then you must ensure that the resets
are synchronously deasserted. Figure 3-4 on page 3-8 shows the application of
power-on reset.

The system must assert DAPRESETn on power-on.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-7
Confidential
Functional Integration Guidelines

HCLK

SYSRESETn

PORESETn

DAPRESETn

Figure 3-4 Power-on reset

It is recommended that you assert the reset signals for at least three HCLK cycles to
ensure correct reset behavior.

System reset

A system or warm reset initializes the majority of the processor, excluding NVIC debug
logic, FPB, DWT, and ITM. System reset is typically used for resetting a system that
has been operating for some time, for example, watchdog reset. A system reset is
achieved using SYSRESETn.

SWJ-DP reset

nTRST reset initializes the state of the SWJ-DP TAP controller. nTRST reset is
typically used by the RealView ICE module for hot-plug connection of a debugger to a
system.

nTRST reset initializes the SWJ-DP controller without affecting the normal operation
of the processor.

Because the nTRST signal is not synchronized within the processor, it must only be
deasserted synchronously to SWCLKTCK. This is typically handled by the RealView
ICE module.

SW-DP reset

PORESETn reset initializes the SW-DP logic.

Normal operation

During normal operation the resets, PORESETn, SYSRESETn and DAPRESETn are
deasserted. If the SWJ-DP or SW-DP ports are not in use, nTRST must be tied to 0 or 1.

3-8 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Scan operation

During scan testing, the reset synchronizers and SYSRESETn are bypassed by the
assertion of the RSTBYPASS input. CGBYPASS is also used to bypass clock gating
cells during scan testing.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-9
Confidential
Functional Integration Guidelines

3.3 AHB bus interfaces

The processor drives the AHB bus interface from the processor core.

The processor has three AHB bus ports:

• ICode port
• DCode port
• System port.

For more information on the ports and signals, see Appendix A Signal Descriptions of
the Cortex-M3 Technical Reference Manual and Chapter 19 AC Characteristics of the
Cortex-M3 Technical Reference Manual.

It is recommended that you understand the AHB bus interface signals, described in the
AMBA AHB Protocol Specification, before connecting any of the signals described here.
Table 3-4 on page 3-11 to Table 3-6 on page 3-15 show the AHB bus present on the
processor, and describe how to connect the signals in your SoC design.

The Cortex-M3 bus interfaces are unregistered. It is important that you understand the
timing of these buses when you integrate the processor into your system. See Chapter
12 Bus Interface of the Cortex-M3 Technical Reference Manual for more details of the
bus timings.

Note
• The Cortex-M3 bus interfaces are not registered. Excessive loads on the bus
outputs, or slow timings on the bus inputs, directly impact the performance of the
processor. You must therefore ensure that the loads and timings on these
interfaces meet those specified by your Cortex-M3 implementor.

• It is strongly recommended that any external arbitration between the ICode and
DCode AHB bus interfaces ensures that DCode has a higher priority than ICode.

3-10 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-4 shows the signals for the ICode Interface.

Table 3-4 ICode interface signals

Name Direction Description Connection information

HADDRI[31:0] Output 32-bit instruction address bus. Connect to address decoders, arbiter,
and slaves through the bus
infrastructure.

HTRANSI[1:0] Output Indicates the type of the current transfer, Connect to the AHB arbiter and
which can be: slaves through the bus infrastructure.
00 = IDLE
10 = NONSEQUENTIAL.

HSIZEI[2:0] Output Indicates the size of the instruction fetch. All Connect to the slaves through the
instruction fetches are 32 bits on Cortex-M3 bus infrastructure.
processor. HSIZEI is always 3'b010.

HBURSTI[2:0] Output Indicates if the transfer is part of a burst. All Connect to the AHB arbiter and
instruction fetches and literal loads are slaves through the bus infrastructure.
performed as SINGLE. HBURSTI is always
3’b000.

HPROTI[3:0] Output Provides information on the access. Always Connect to the slaves through the
indicates cacheable, and bufferable on this bus infrastructure.
bus.
HPROTI[0]:
0 = Instruction fetch
1 = vector fetch.
HPROTI[1]:
0 = Unprivileged
1 = Privileged.
HPROTI[2]:
Always 1 = Bufferable.
HPROTI[3]:
Always 1 = Cacheable.

MEMATTRI[1:0] Output Memory attributes. Always 2b’00 for this

bus. They are non-allocate, non-shareable.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-11
Confidential
Functional Integration Guidelines

Table 3-4 ICode interface signals (continued)

Name Direction Description Connection information

BRCHSTAT[3:0] Output b0000 = No hint Can be used to optimize operation of

b0001 = Conditional branch backwards in memory controllers or prefetchers.
decode
b0010 = Conditional branch in decode
b0011 = Conditional branch in execute
b0100 = Unconditional branch in decode
b0101 = Unconditional branch in execute
b0110 = Reserved
b0111 = Reserved
b1000 = Conditional branch in decode taken
(cycle after IHTRANS)
b1001...b1111 - Reserved.

HRDATAI[31:0] Input Instruction read bus. Connect from the slaves through
AHB infrastructure.

HREADYI Input When HIGH indicates that a transfer has Connect to the slaves through the
completed on the bus. This signal is driven bus infrastructure.
LOW to extend a transfer.

HRESPI[1:0] Input The transfer response status.

b00 = OKAY
b01 = ERROR.

Table 3-5 shows the signals for the DCode interface.

Table 3-5 DCode interface signals

Name Direction Description Connection information

HADDRD[31:0] Output 32-bit instruction address bus. Connect to address decoders, arbiter,
and slaves through the bus
infrastructure.

HTRANSD[1:0] Output Indicates the type of the current transfer, Connect to the AHB arbiter and slaves
which can be: through the bus infrastructure.
b00 = IDLE
b10 = NONSEQUENTIAL
b11 = SEQUENTIAL.

3-12 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-5 DCode interface signals (continued)

Name Direction Description Connection information

HWRITED Output Write not Read. Connect to the slaves through the bus
infrastructure.
HSIZES[2:0] Output Indicates the size of the access. Accesses
can be:
byte, 3'b000
halfword, 3'b001
word, 3'b010.

HBURSTD[2:0] Output Indicates if the transfer is part of a burst. Connect to the AHB arbiter and slaves
through the bus infrastructure.

HMASTERD[1:0] Output Indicates the current DCode bus master: Connect to the AHB arbiter and slaves
• 0 = Core data side accesses through the bus infrastructure.
• 1 = DAP accesses
• 2 = Core instruction side accesses.
These include vector fetches that
are marked as data by
HPROTD[0]. This value cannot
appear on HMASTERD
• 3 = Reserved. This value cannot
appear on HMASTERD.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-13
Confidential
Functional Integration Guidelines

Table 3-5 DCode interface signals (continued)

Name Direction Description Connection information

HPROTD[3:0] Output Provides information on the access. Connect to the slaves through the bus
HPROTD[0]: infrastructure.
Always 1 = Data access
HPROTD[1]:
0 = Unprivileged
1 = Privileged.
HPROTD[2]:
0 = Non-bufferable
1 = Bufferable.
HPROTD[3]:
0 = Non-cacheable
1 = Cacheable.

MEMATTRD[1:0] Output Memory attributes.:

Bit 0 = Allocate
Bit 1 = Shareable.

HWDATAD[31:0] Output Data write bus.

HREADYD Input When HIGH indicates that a transfer has

completed on the bus. This signal is driven
LOW to extend a transfer.
HRESPD[1:0] Input The transfer response status.
b00 = OKAY
b01 = ERROR.

3-14 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-5 DCode interface signals (continued)

Name Direction Description Connection information

HRDATAD[31:0] Input Read Data. Connect from the slaves through

AHB infrastructure.

EXREQD Output Exclusive Request. EXREQD is an Connect to Exclusives Monitor.

address phase control signal that indicates
if the access is because of a LDREX or STREX:
0 = No request
1 = Exclusive request.
You can use EXREQD and EXRESPD to
synchronize primitives and semaphores.

EXRESPD Input Exclusive Response. EXRESPD is a data Connect to Exclusives Monitor or tie
phase response like HRESPD, but is only to 0 if not required.
valid for exclusive accesses and indicates
the success or failure of an exclusive
operation:
0 = Exclusive request accepted
1 = Exclusive request failed.
You can use EXREQD and EXRESPD to
synchronize primitives and semaphores.

Table 3-6 shows the signals for the system bus interface.

Table 3-6 System bus Interface signals

Name Direction Description Connection information

HADDRS[31:0] Output 32-bit address. Connect to address decoders, arbiter, and

slaves through the bus infrastructure.

HTRANSS[1:0] Output Indicates the type of the current transfer, Connect to the AHB arbiter and slaves
which can be: through the bus infrastructure.
b00 = IDLE
b10 = NONSEQUENTIAL
b11 = SEQUENTIAL.

HSIZES[2:0] Output Indicates the size of the access. Accesses Connect to the slaves through the bus
can be: infrastructure.
byte, 3'b000
halfword, 3'b001
word, 3'b010.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-15
Confidential
Functional Integration Guidelines

Table 3-6 System bus Interface signals (continued)

Name Direction Description Connection information

HBURSTS[2:0] Output Indicates if the transfer is part of a burst. Connect to the AHB arbiter and slaves
through the bus infrastructure.

HPROTS[3:0] Output Provides information on the access. Connect to the slaves through the bus
HPROTS[0]: infrastructure.
0 = Instruction
1 = Data access.
HPROTS[1]:
0 = Unprivileged
1 = Privileged.
HPROTS[2]:
0 = Non-bufferable
1 = Bufferable.
HPROTS[3]:
0 = Non-cacheable
1 = Cacheable.

HMASTERS[1:0] Output Indicates the current system bus master: Connect to the AHB arbiter and slaves
• 0 = Core data side accesses through the bus infrastructure.
• 1 = DAP accesses.
• 2 = Core instruction side accesses.
These include vector fetches that
are marked as data by
HPROTS[0].
• 3 = Reserved. This value cannot
appear on HMASTERS

HWDATAS[31:0] Output 32-bit write data bus. Connect to the slaves through the bus
infrastructure.

HWRITES Output Write not Read. Connect to the slaves through the bus
infrastructure.

HMASTLOCKS Output Indicates a transaction that must be Connect to arbiter.

atomic on the bus. This is only used for
bit-band writes, performed as
read-modify-write.

MEMATTRS[1:0] Output Memory Attributes. Connect to the slaves through the bus
Bit 0 = Allocate infrastructure.
Bit 1 = Shareable.

3-16 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-6 System bus Interface signals (continued)

Name Direction Description Connection information

HRDATAS[31:0] Input Read data bus. Connect from the slaves through AHB
infrastructure.

HREADYS Input When HIGH indicates that a transfer has Connect to the slaves through the bus
completed on the bus. This signal is infrastructure.
driven LOW to extend a transfer.

HRESPS[1:0] Input The transfer response status:

b00 = OKAY
b01 = ERROR.

EXREQS Output Exclusive Request. EXREQS is an Connect to Exclusives Monitor.

address phase control signal that
indicates if the access is because of a
LDREX or STREX:
0 = No request
1 = Exclusive request
You can use EXREQS and EXRESPS
to synchronize primitives and
semaphores.

EXRESPS Input Exclusive Response. EXRESPS is a Connect to Exclusives Monitor or tie to

data phase response like HRESPS, but is 0 if not required.
only valid for exclusive accesses and
indicates the success or failure of an
exclusive operation:
0 = Exclusive request accepted
1 = Exclusive request failed.
You can use EXREQS and EXRESPS
to synchronize primitives and
semaphores.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-17
Confidential
Functional Integration Guidelines

3.4 APB interface

Table 3-7 shows the signals for the APB interface. This interface is to the External
Private Peripheral Bus.

Table 3-7 APB interface signals

Signal name Direction Description Connection information

PSEL Output APB device select Indicates that a data transfer is requested.

PENABLE Output APB control signal Strobe to time all accesses. Used to indicate the second cycle
of an APB transfer.

PADDR[19:2] Output APB address bus 18-bit address. Only the bits that are relevant to the External
Private Peripheral Bus are driven.

PADDR31 Output APB master This signal is driven high when the AHB-AP is the
requesting master. It is driven low when the processor is the
requesting master.

PWRITE Output APB transfer direction Write not read.

PWDATA[31:0] Output APB write data bus 32-bit write data bus.

PRDATA[31:0] Input APB read data bus 32-bit read data bus.

PREADY Input APB slave ready This signal is driven LOW if the currently accessed APB
device requires extra wait states to complete the transfer.

PSLVERR Input APB slave error This signal is driven HIGH if the currently accessed APB
device cannot handle the requested transfer.

3-18 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

3.5 Miscellaneous signals

Table 3-8 shows the miscellaneous signals present on the processor, and describes how
you must set the signals in your SoC design. The configuration input signals are
sampled at reset.

Table 3-8 Miscellaneous Interface signals

Name Direction Description Connection information

LOCKUP Output Indicates that the core is locked up. You can connect this signal to
a Watchdog, for example, that
resets the processor using
SYSRESETn. It can also be
connected to the ETM using
one of the EXTIN ports.

CURRPRI[7:0] Output Indicates what priority interrupt, or base boost, -

is being used now. CURRPRI represents the
pre-emption priority, and does not indicate
secondary priority.

HALTED Output In halting mode debug. HALTED remains -

asserted while the core is in debug.

DBGRESTART Input External restart request. Multiprocessor debug Multiprocessing debug

support to connect to CoreSight Embedded support. Connect to a CTI.
Cross Trigger. If multiprocessor debug support
is not required, DBGRESTART must be tied
LOW.

DBGRESTARTED Output Handshake for DBGRESTART.

TXEV Output Event transmitted as a result of SEV instruction. Connected to other processors
This is a single-cycle pulse. You can use it to in a multicore system. In a
implement a more power efficient spin-lock in a multi-core system, TXEV
multi-processor system. from each processor can be
broadcast to the RXEV input
of the other processors.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-19
Confidential
Functional Integration Guidelines

Table 3-8 Miscellaneous Interface signals (continued)

Name Direction Description Connection information

INTERNALSTATE Output Enables observation of internal operation of -

core. OBSERVATION must be implemented to
enable this signal to be used, otherwise it ties to
0.
The components of INTERNALSTATE are
registered before being combined to form
INTERNALSTATE.
INTERNALSTATE comprises:
bit [148] = SysTick interrupt request
bit [147] = FPB BKPT match
bit [146] = FPB literal remap match
bit [145] = FPB instruction remap match
bit [144] = Watchpoint
bit [143] = DAP abort
bits [142:141] = DAP HTRANS
bits [140:109] = Register bank read port B data
bits [108:77] = Register bank read port A data
bits [76:73] = Register bank read port B address
bits [72:69] = Register bank read port A address
bits [68:65] = Register bank write port address
bit [64] = Register bank write port enable
bits [63:32] = Register bank write port data
bits [31:0] = Instruction in execute

BIGEND Input Static endianness setting. This signal is sampled Hardwire to either 0 or 1
at reset, and cannot be changed when reset is depending on the endianness
inactive. of your system.
1 = big-endian
0 = little-endian.

EDBGRQ Input External debug request. Combined debug -

request from ETM and multiprocessor debug
support to connect to CoreSight Embedded
Cross Trigger. If multiprocessor debug support
is not required, EDGGRQ can be connected to
ETMDBGRQ on ETM.

STCLK Input System Tick Clock. Connect to clock logic that

drives required STCLK
frequency.

3-20 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-8 Miscellaneous Interface signals (continued)

Name Direction Description Connection information

STCALIB[25:0] Input System Tick Calibration. Drive value required for

SysTick calibration.

RXEV Input Causes a wake-up from a WFE instructiona. Connect to TXEVs from other
processors in a multi processor
system. Tie to 0 if not required.

TRCENA Output Trace Enable. This signal reflects the setting of Connect to clock gating logic
bit [24] of the Debug Exception and Monitor for TPIU and ETM.
Control Register. This signal can be used to gate
the clock to the TPIU and ETM blocks to reduce
power consumption when trace is disabled.

PPBLOCK[5:0] Input Reserved. Must be tied to 6'b000000.

VECTADDR[9:0] Input Reserved. Must be tied to

10'b0000000000.

VECTADDREN Input Reserved. Must be tied to 1'b0.

INTISR[239:0] Input External interrupt signals. Connect to interrupt logic.

Check with your implementor
for the number of interrupts
supported in your CortexM3
implementation.

INTNMI Input Non-maskable interrupt. Connect to your interrupt

logic.

AUXFAULT[31:0] Input Auxiliary fault status information from the Connect to fault generating
system. logic if required. Result
appears in the Auxiliary Fault
Status Register at address
0xE000ED3C. A one-cycle pulse
of information results in the
information being stored in the
corresponding bit until a
write-clear occurs.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-21
Confidential
Functional Integration Guidelines

Table 3-8 Miscellaneous Interface signals (continued)

Name Direction Description Connection information

DNOTITRANS Input Suppression of parallel ICode and DCode Static tie-off that forces the
transactions. processor to not enable ICode
and DCode AHB transactions
to occur at the same time. This
prevents instruction fetches
occurring on the ICODE AHB
at the same time as a data
transaction is occurring on the
DCODE AHB.
This enables a simple bus
multiplexor to be instantiated
externally to the processor. An
example of a simple bus
multiplexor is included in the
Cortex-M3 release. It is called
CM3CodeMux and is in:
logical/CortexM3Integration/
verilog

IFLUSH Input Instruction flush. Must be tied to 1'b0.

STKALIGNINIT Input Initial stack alignment. Forms reset value of stack

alignment. 0 ensures 4 byte
alignment, and 1 ensures 8
byte alignment. You can alter
Stack alignment after reset
using bit [9] of the
Configuration Control
Register at address 0xE000ED14.

SE Input Scan Enable. Must be tied low in functional

mode.

RSTBYPASS Input Reset bypass when performing scan testing. Must be tied low in functional
mode.

CGBYPASS Input Clock gate bypass when performing scan Must be tied low in functional
testing. mode.
a. Input from OR'ing TXEV signals from other processors in the system. If different processors run at different frequencies then
synchronizers must be used to guarantee that TXEV is synchronous to this processor. TXEV must also be a single-cycle pulse.

3-22 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

3.6 Low power interface

Table 3-9 shows the low power interface signals.

Table 3-9 Low power interface signals

Name Direction Description Connection information

SLEEPING Output Indicates that processor is in sleep mode. You can connect these
signals to a clock and/or
SLEEPDEEP Output Indicates that processor is in deep sleep mode. power controller. See
Chapter 7 Power
SLEEPHOLDACKn Output Acknowledge signal for SLEEPHOLDREQn.
Management of the
GATEHCLK Output HCLK can be gated because the core is asleep Cortex-M3 Technical
without the debugger being active. Reference Manual.

WICENACK Output Active high SLEEPDEEP is WICSLEEP

acknowledgement to the Power Management
Unit (PMU).

WICDSACKn Output Active low indication that accepts

WICDSREQn and means that SLEEPDEEP is
WIC mode sleep.

WAKEUP Output Active high signal to PMU that core must be

made active.

WICMASKISR Output Active high set of signals indicating which

interrupts would cause a wake-up.

WICMASKMON Output Active high signal indicating that debug monitor

would cause a wake-up.

WICMASKNMI Output Active high signal indicating that NMI would

cause a wake-up.

WICMASKRXEV Output Active high signal indicating that RXEV would

cause a wake-up.

WICMASK Output Combination of WICMASK* signals into WIC.

WICSENSE Output Active high set of signals indicating which input

lines the WIC would generate WAKEUP signal
in response to.

WICLOAD Output Causes WIC to be loaded with sensitivity data

given by WICMASK*.

WICCLEAR Output Causes WIC to clear registered sensitivity data.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-23
Confidential
Functional Integration Guidelines

Table 3-9 Low power interface signals (continued)

Name Direction Description Connection information

WICPEND Input Captured interrupt information for NVIC.

SLEEPHOLDREQn Input Request to extend sleep. Can only be asserted

when SLEEPING is HIGH.

WICDSREQn Input Active low request from WIC that SLEEPDEEP

be WIC mode sleep.

WICENREQ Input Make SLEEPDEEP mode WIC mode sleep

request from PMU.

WICDISABLE Input Debugger active signal to disable WIC mode

when a debugger is attached.

WICINT Input Active high interrupt, debug monitor, NMI, and

or RXEV signals.

PWRUPREADY Output Indicate core is powered up and voltage is stable. ARM recommends that you
connect these signals during
ISOLATEn Input Isolate core power domain. synthesis if you use state
retention cells.
RETAINn Input Retain core state during power-down.

PWRUP Input Power up core.

Note
The Cortex-M3 release contains an example PMU called CM3ExamplePMU in
logical/CM3WIC/verilog. You can use this as a starting point to integrate a PMU into
your system if required. If a debugger is connected to the processor, then it cannot be
powered down.

3-24 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

3.7 Debug access

Table 3-10 shows the signals for the AHB-AP interface.

Table 3-10 AHB-AP interface signals

Name Direction Description Connection information

DAPRDATA[31:0] Output The read bus is driven by the selected AHB-AP Connect to DAPRDATA port
during read cycles, when DAPWRITE is of SW-DP or SWJ-DP using
LOW. a slave multiplexor.

DAPREADY Output The AHB-AP uses this signal to extend a DAP Connect to DAPREADY port
transfer. of SW-DP or SWJ-DP using
a slave multiplexor.

DAPSLVERR Output The error response is because: Connect to DAPSLVERR

• Master port produced an error response, port of SW-DP or SWJ-DP
or transfer not initiated because of using a slave multiplexor.
DBGEN preventing a transfer.
• Access to AP register not accepted after
a DAPABORT operation.

DAPCLKEN Input DAP clock enable (clock ration control or Connect to your clock
power saving). controller.
CDBGPWRUPREQ can be
used to control this signal.

DAPEN Input AHB-AP enable. Connect high when enabling

debug accesses.

DAPADDR[31:0] Input DAP address bus. Connect to

DAPADDR[31:0] port of
SW-DP or SWJ-DP.

DAPSEL Input Select signal generated from the DAP decoder Connect to DAP address
to each AP. This signal indicates that the slave decoder.
device is selected, and a data transfer is
required. There is a DAPSEL signal for each
slave. The decoder monitors the address bus
and asserts the relevant DAPSEL.

DAPENABLE Input This signal is used to indicate the second and Connect to DAPENABLE
subsequent cycles of a DAP transfer from DP port of SW-DP or SWJ-DP.
to AHB-AP.

DAPWRITE Input When HIGH indicates a DAP write access Connect to DAPWRITE
from DP to AHB-AP. When LOW indicates a port of SW-DP or SWJ-DP
read access.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-25
Confidential
Functional Integration Guidelines

Table 3-10 AHB-AP interface signals (continued)

Name Direction Description Connection information

DAPWDATA[31:0] Input The write bus is driven by the DP block during Connect to
write cycles, when DAPWRITE is HIGH. DAPWDATA[31:0] port of
SW-DP or SWJ-DP

DAPABORT Input Aborts the current transfer. The AHB-AP Connect to DAPABORT
returns DAPREADY HIGH without affecting port of SW-DP or SWJ-DP
the state of the transfer in progress in the AHB
Master Port.

FIXHMASTERTYPE Input The AHB-AP can issue AHB transactions with Tie off as required
a HMASTER value of either 1 (DAP) or 0
(core data side) depending on how the
AHB-AP is configured using the MasterType
bit in the AHB-AP Control and Status Word
Register. FIXHMASTERTYPE can be used
to prevent this if required. If it is tied to 1'b1
then the HMASTER issued by the AHB-AP is
always 1 (DAP) and it cannot pretend to be the
core. If it is tied to 1'b0 then HMASTER can be
issued as either 0 or 1.

3-26 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

3.8 Embedded Trace Macrocell

If an ETM is not included in your SoC design, the processor ETM interface outputs can
be left floating.

Note
This interface only exists at the CortexM3 level and not the CortexM3Integration level.

Table 3-11 shows the signals as they connect to the ETM.

Table 3-11 ETM interface signals

Name Direction Description Connection information

DWTMATCH[3:0] Input Trigger from DWT. One bit for each of the Connect to ETMTRIGGER[3:0]
four DWT comparators. of the processor.

DWTINOTD[3:0] Input Indicates if the ETM is triggered on an Connect to

instruction or data match. ETMTRIGINOTD[3:0] of the
processor.

ETMIVALID Input Instruction valid. Connect to ETMIVALID of the

processor.

ETMIA[31:1] Input PC of the instruction being executed. Connect to ETMIA[31:1] of the

processor.

ETMICCFAIL Input Condition Code fail. Indicates if the current Connect to ETMICCFAIL of the
instruction has failed or passed its processor.
conditional execution check.

ETMIBRANCH Input Opcode is a branch target. Connect to ETMIBRANCH of

the processor.

ETMIINDBR Input Opcode is an indirect branch target. Connect to ETMIBRANCH of

the processor.

ETMINTSTAT[2:0] Input Interrupt status. Marks interrupt status of Connect to ETMINTSTAT[2:0]

current cycle: of the processor.
b000 - no status
b001 - interrupt entry
b010 - interrupt exit
b011 - interrupt return
b100 - vector fetch and stack push.
ETMINTSTAT entry/return is asserted in
the first cycle of the new interrupt context.
Exit occurs without ETMIVALID.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-27
Confidential
Functional Integration Guidelines

Table 3-11 ETM interface signals (continued)

Name Direction Description Connection information

ETMINTNUM[8:0] Input Marks the interrupt number of the current Connect to ETMINTNUM[8:0]
execution context. of the ETM.

ETMPWRUP Output ETM is enabled. Connect to ETMPWRUP of the

processor.

ETMDVALID Input Data valid. Connect to ETMDVALID of the

ETM.

ETMCANCEL Input Instruction cancelled. Connect to ETMCANCEL of the

ETM.

ETMFINDBR Input Flush is indirect. Marks flush hint Connect to ETMFINDBR of the
destination cannot be inferred from the PC. ETM.

ETMFOLD Input Opcode fold. An IT or NOP opcode has been Connect to ETMFOLD of the
folded in this cycle. PC advances past the ETM.
current 16-bit opcode plus the IT/NOP
instruction of 16 bits. This is reflected in the
ETMIA.

ETMISTALL Input Indicates that the last instruction signalled Connect to ETMISTALL of the
by the core has not yet entered execute. ETM.

ETMFIFOFULL Output ETMFIFOFULL is asserted when the Connect to FIFOFULL of the

ETM FIFO is full, and causes the processor processor, or tie to 0 at the
to stall until the FIFO has drained, to ensure processor if no ETM is present.
that no trace is lost. This functionality can be
enabled using a register in the ETM.

ETMTRIGOUT Output ETM trigger output. Connect to Cortex-M3 TPIU.

ETMDBGRQ Output Debug request. Connect to EDBGRQ in the

processor

COREHALT Input Halt status. Connect to HALTED in the

processor.

ETMPWRUP Output ETM power up. Connect to the processor.

ETMEN Output ETM enable. -

FIFOPEEK Output For validation purposes only. -

Table 3-12 on page 3-29 shows the miscellaneous ETM connections.

3-28 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-12 Miscellaneous ETM connections

Name Direction Description Connection information

NIDEN Input NIDEN must be HIGH to enable the ETM Tie to 1.

to trace instructions.

FIFOFULLEN Input If HIGH, the FIFOFULL functionality can Tie to 1 if FIFOFULL functionality is
be enabled using an ETM register. required. Otherwise, tie to 0 to
permanently disable FIFIFULL
functionality.

ETMEXTIN[1:0] Input General purpose inputs to the ETM from Connect to LOCKUP from the
on-chip resources that can be used to processor, or any other on-chip
generate triggers or to control trace regions. resources. Tie unused bits to 0.

MAXEXTIN[1:0] Input Defines the number of ETMEXTIN Tie off to indicate the number of
signals that are connected. ETMEXTIN signals that are
connected.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-29
Confidential
Functional Integration Guidelines

3.9 Trace interface

Table 3-13 and Table 3-14 show the signals for the ITM interface as they connect to the
TPIU.

Table 3-13 ITM interface signals with no ETM present

Name Direction Description Connection information

ATVALID1S Input ATB valid Connect to ATVALID of the processor

AFREADY1S Input ATB flush Connect to AFREADY of the processor

ATDATA1S[7:0] Input ATB data Connect to ATDATA[7:0] of the processor

ATIDITM1S[6:0] Input ITM ID for TPIU Connect to ATIDITM[6:0] of the processor

ATREADY1S Output ATB ready Connect to ATREADY of the processor

TPIUACTV Output TPIU has data Connect to TPIUACTV of the processor

TPIUBAUD Output Unsynchronized baud indicator from Connect to TPIUBAUD of the processor
TPIU

SyncReq Input Periodic synchronization packet Connect to DSYNC of the processor

trigger for formatted modes.

MaxPortSize[1:0] Input Indicates the number of pins Tie off to indicate the size of the trace port
available for the TracePort mode. available on the device

Table 3-14 ITM interface signals with ETM present

Name Direction Description Connection information

ATVALID1S Input ATB valid Connect to ATVALID of the ETM

ATVALID2S Input ATB valid Connect to ATVALID of the processor

AFREADY1S Input ATB flush Connect to AFREADY of the ETM

AFREADY2S Input ATB flush Connect to AFREADY of the processor

ATDATA1S[7:0] Input ATB data Connect to ATDATA[7:0] of the ETM

ATDATA2S[7:0] Input ATB data Connect to ATDATA[7:0] of the processor

ATID1S[6:0] Input ETM ID for TPIU Connect to ATIDITM[6:0] of the ETM

ATID2S[6:0] Input ITM ID for TPIU Connect to ATIDITM[6:0] of the processor

ATREADY1S Output ATB ready Connect to ATREADY of the ETM

3-30 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

Table 3-14 ITM interface signals with ETM present (continued)

Name Direction Description Connection information

ATREADY2S Output ATB ready Connect to ATREADY of the processor

TPIUACTV Output TPIU has data Connect to TPIUACTV of the processor

TPIUBAUD Output Unsynchronized baud indicator from Connect to TPIUBAUD of the processor
TPIU

SyncReq Input Periodic synchronization packet Connect to DSYNC of the processor

trigger for formatted modes

MaxPortSize[1:0] Input Indicates the number of pins Tie off to indicate the size of the trace port
available for the TracePort mode available on the device

TRIGGER Input Indicates a trigger packet in the trace Connect to ETMTRIGOUT of the ETM if
stream present, or tie to 0 if no ETM is present

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-31
Confidential
Functional Integration Guidelines

3.10 HTM interface

Table 3-15 shows the signals for the HTM interface from the processor.

Table 3-15 HTM interface signals

Name Direction Description Connection information

HTMDHADDR[31:0] Output 32-bit address. Connect to HTM if implemented.

HTMDHTRANS[1:0] Output Indicates the type of the current data Connect to HTM if implemented.
transfer. Can be IDLE,
NONSEQUENTIAL, or SEQUENTIAL.

HTMDHSIZE[1:0] Output Indicates the size of the access. Can be 8, Connect to HTM if implemented.
16, or 32 bits.

HTMDHBURST[2:0] Output Indicates if the transfer is part of a burst. Connect to HTM if implemented.

HTMDHPROT[3:0] Output Provides information on the access. Connect to HTM if implemented.

HTMDHWDATA[31:0] Output 32-bit write data bus. Connect to HTM if implemented.

HTMDHWRITE Output Write not read. Connect to HTM if implemented.

HTMDHRDATA[31:0] Output Read data bus. Connect to HTM if implemented.

HTMDHREADY Output Ready signal. Connect to HTM if implemented.

HTMDHRESP[1:0] Output The transfer response status. Can be Connect to HTM if implemented.
OKAY or ERROR.

3-32 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

3.11 SWJ-DP interface

This section provides information on how to connect the JTAG and Serial Wire interface
signals in your SoC design. This interface is only used if the processor has been
implemented with SWJ-DP.

Table 3-16 shows the SWJ-DP interface signals present on the processor, and describes
how you must set the signals if you intend to use JTAG debug support.

Note
See Table 3-17 on page 3-34 for the Serial Wire interface description for the SWJ-DP.

Table 3-16 lists the debug interface signals.

Table 3-16 Debug interface signals

Name Direction Description Connection information

nTRST Input Debug nTRST See Reset on page 3-6.

TDI Input Debug TDI For more information on how to connect these
signals, see the Debug Port chapter of the
SWDITMS Input Debug TMS CoreSight Components Technical Reference
Manual.
TDO Output Debug TDO

SWDO Output Serial Wire Data Out

SWDOEN Output Serial Wire Output Enable

SWCLKTCK Input Serial Wire Clock/TCK

nTDOEN Output DBGTDO output pad control signal This signal must be used to control the output
enable on the pad for DBGTDO.

3.11.1 Multiplexing JTAG ports

There is no support in RealView-ICE for multiplexing TCK, TMS, TDI, TDO, and
RTCK, between a number of different processors. Therefore multiplexing JTAG ports
is not recommended.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-33
Confidential
Functional Integration Guidelines

3.12 SW-DP Interface

Table 3-17 shows the SW-DP interface signals present on the processor, and describes
how you must set the signals in your SoC design.

Table 3-17 SW-DP Interface signals

Name Direction Description Connection information

SWDO Output Serial Wire Data Out Connect to tristate pad for SWDIO

SWDOEN Output Serial Wire Output Enable Connect to tristate pad for SWDIO

PORESETn Input Serial Wire Reset Connect to reset controller

SWCLKTCK Input Serial Wire Clock Connect to input pad for SWCLKTCK

SWDITMS Input Serial Wire Data In Connect to tristate pad for SWDIO

3-34 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Functional Integration Guidelines

3.13 Trace port interface

Table 3-18 lists the trace port interface signals.

Table 3-18 Trace port interface signals

Name Direction Description Connection information

TRACECLKIN Input Trace Port Clock Connect to your Trace Port Analyzer

TRACECLK Output Trace Clock Connect to your Trace Port Analyzer

TRACEDATA[3:0] Output Output Trace Port Data Bus Connect to your Trace Port Analyzer

TRACESWO Output Serial Wire Viewer data For more information on how to connect this signal,
see Chapter 17, Trace Port Interface Unit of the
Cortex M3 Technical Reference Manual.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 3-35
Confidential
Functional Integration Guidelines

3-36 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 4
DFT Guidelines

This chapter describes the guidelines for Design For Test (DFT) testing of the processor.
It also describes the test view of the processor supplied with the deliverables, and how
you can use this to get increased test coverage of your SoC. This chapter contains the
following sections:
• About DFT guidelines on page 4-2
• Scan chains on page 4-3
• Production test modes on page 4-5
• Manufacturing test interface on page 4-11.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-1
Confidential
DFT Guidelines

4.1 About DFT guidelines

This chapter describes the various issues that relate to DFT that you must consider when
you integrate the processor into your SoC design. The processor design supports scan
and Automatic Test Pattern Generation (ATPG) techniques for production test vectors.

This chapter describes:

• the scan configuration of the processor
• the production test modes of the processor
• the test shadow and how to deal with this
• the test interface on the processor
• at speed tests
• IDDQ tests.

4-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Guidelines

4.2 Scan chains

This section describes:
• Internal scan chains
• SoC test shadows and the processor.

4.2.1 Internal scan chains

The processor design is implemented with scan chains inserted. The implementer
determines the number of scan chains and adds ports to the processor so that you can
access the scan chains.

Table 4-1 shows the mandatory internal scan ports in the processor, that are associated
with scan chains.

Table 4-1 Processor scan test ports

Port Direction Description

RSTBYPASS Input RSTBYPASS bypasses the resets during scan testing, as described in Scan operation on
page 3-9. Use this signal if your test pattern generation tool requires full control of the
reset signals during testing.

CGBYPASS Input CGBYPASS bypasses the clock gating logic during scan testing, as described in Scan
operation on page 3-9. Use this signal if your test pattern generation tool requires full
control of the clock gate enables during testing.

SE Input This signal enables serial shifting of vectors through the scan chains. It also ensures the
clocks are free-running during scan test. This signal must be tied LOW during functional
mode.

SI Input Inputs to scan chains.

SO Output Outputs from scan chains.

There are usually multiple SI and SO pins, for example SI0, SI1, and SI2. The number
of scan in or scan out pins equals the number of scan chains.

4.2.2 SoC test shadows and the processor

When you integrate the processor into your SoC, it is likely that there is logic between
the last register in the processor and the next register in the SoC. This logic is in the test
shadow of the processor and is known as shadow logic. Figure 4-1 on page 4-4 shows
this test shadow. To generate ATPG vectors for your SoC to test this shadow logic, you
must use the processor test wrapper in its EXTEST mode. See EXTEST mode on
page 4-7.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-3
Confidential
DFT Guidelines

Note
• If the processor is not integrated into your SoC as a black box, a test wrapper is
not required.

• The processor has non-registered bus interfaces, so inclusion of a test wrapper

degrades the timing of these interfaces.

SoC

D Q D Q

R Q R Q
CLR Shadow Shadow CLR
logic Macrocell logic

D Q D Q

R Q R Q
CLR CLR

Figure 4-1 Shadow logic

4-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Guidelines

4.3 Production test modes

The processor has an optional test wrapper so that you can integrate the processor into
your SoC design as a black box and maintain the testability of both the processor and
the SoC.

The test wrapper provides the following modes of operation:

• Normal mode
• INTEST mode on page 4-6
• EXTEST mode on page 4-7
• At-speed tests on page 4-9.

Table 4-3 on page 4-11 shows the signal configuration required for the different modes.

Table 4-2 shows the ports that you can use to control the wrapper chain in the processor.
The port names follow the IEEE 1500 wrapper naming convention for CoreTest.

The WSI and WSO ports might be single signals or buses. If they are buses, the width
of a bus equals the number of wrapper scan chains.

Table 4-2 Wrapper ports

Name Direction Description

WCLK Input Name of test wrapper clock port

WSEIN Input Name of test wrapper input scan enable port

WSEOUT Input Name of test wrapper output scan enable port

WINTEST Input Name of test wrapper INTEST port

WEXTEST Input Name of test wrapper EXTEST port

WSAFE Input Name of test wrapper safe port

WSII Input Name of test wrapper scan data in port for input test wrapper chains

WSIO Output Name of test wrapper scan data out port for input test wrapper chains

WSOI input Name of test wrapper scan data in port for output test wrapper chains

WSOO Output Name of test wrapper scan data out port for output test wrapper chains

4.3.1 Normal mode

In normal mode of operation WINTEST is set to 0 and WEXTEST is set to 0, the test
wrapper is transparent, and the inputs and outputs pass through the wrapper unchanged.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-5
Confidential
DFT Guidelines

4.3.2 INTEST mode

In INTEST mode of operation WINTEST is set to 1 and WEXTEST to 0. You can use
the test wrapper to apply ATPG vectors. The wrapper provides inputs to, and outputs
from, the processor, so that you can apply the ATPG vectors, through the wrapper, in
any SoC design. This is known as the INTEST mode of the processor.

In this mode of operation you can:

• Test the logic of the processor core. To test the processor logic of the processor,
you must use the scan vectors supplied.

• Observe the processor core outputs, through the test wrapper, while the processor
inputs are controlled by the test wrapper.
This enables you to test the shadow combinational logic between the scan cells in
the processor, and the test wrapper.
Figure 4-2 shows an example of the shadow combinational logic between the scan
cells in the processor and the test wrapper scan chain.

WINTEST WEXTEST WSIO

Macrocell inputs WCLK WSEIN

Macrocell

WSII Test wrapper

Processor core
Internal macrocell
Combinational logic test shadow
Macrocell
outputs

Scan cell Scan cell Combinational logic

WSOO
WCLK
WINTEST
WEXTEST
WSEOUT

CGBYPASS
SI SO RSTBYPASS WSOI

Figure 4-2 INTEST mode of operation

4-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Guidelines

To use this mode of operation you must set the signals as the INTEST column of
Table 4-4 on page 4-13 shows.

4.3.3 EXTEST mode

In EXTEST mode of operation WINTEST is set to 0 and WEXTEST to 1. You can

generate ATPG vectors, for the rest of your SoC, by use of the test wrapper. The wrapper
provides an EXTEST mode so that you can use the wrapper scan chain to provide
control and observe points and generate ATPG vectors for the rest of your SoC.

In this mode of operation you can test the shadow logic between the processor and the
scan cells present in your SoC design.

Figure 4-3 on page 4-8 shows an example of shadow combinational logic between the
scan cell in the SoC and the input HRDATAD[0] to the processor.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-7
Confidential
DFT Guidelines

SoC

SCANDI Scan cell

Combinational
logic

HRDATAD[0]

Scan cell SCANDO

Macrocell WINTEST WEXTEST WSIO

inputs WCLK WSEIN
Test wrapper

Combinational
logic
WSII

HRDATAD[0]

Macrocell outputs

Processor core with preconfigured instruction

and data cache
WSOO
WCLK
WINTEST
WEXTEST
WSEOUT

Macrocell

SI SO RSTBYPASS CGBYPASS WSOI

Figure 4-3 EXTEST mode of operation

Note
In Figure 4-3 the SCANDI and SCANDO signals represent the SoC level scan chains.

4-8 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Guidelines

In EXTEST mode you can:

• test the shadow logic by applying a scan pattern through SCANDI and capturing
the inputs to the processor using the test wrapper.

• test the logic between the processor outputs, for example HRDATAD[0], and the
scan cell in the SoC by applying a scan pattern through the test wrapper and
capturing the inputs using the SoC logic scan cell.

To use this mode of operation you must set the signals as the EXTEST column of
Table 4-4 on page 4-13 shows.

4.3.4 At-speed tests

To do at-speed tests on the processor you can generate transition delay and path delay
ATPG vectors and apply them at the chip level.

You can apply the at-speed vectors using your Automatic Test Equipment (ATE)
provided that:

• the maximum clock frequency of the processor is within the capabilities of the
ATE

• the launch and capture clocks can be supplied at-speed

• the processor wrapper can be shifted at-speed when clocked by the ATE.

If the ATE cannot supply a high enough clock frequency, because the processor runs
with a high frequency clock provided by an on-chip PLL, then at-speed testing requires
special clock switching logic. This logic must:
1. Load the scan chains from the ATE at a low frequency.
2. Switch the clock source to the PLL for the at speed capture cycle.
3. Switch back to the low frequency ATE clock and unload the scan chains.

Note
WSEI must be held HIGH when the at-speed launch and capture clocks are generated,
that is with SE LOW. This is required to create at-speed transitions on the inputs
supplied from the wrapper to the processor core.

IDDQ test

You can also test the processor with IDDQ ATPG vectors. The processor is a fully static
design and there are no restrictions on the processor, when taking IDDQ measurements,
except for stopping the clock. You must take special care, when clocking the SoC, to

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-9
Confidential
DFT Guidelines

prevent disturbance of the core state during integration of the processor IDDQ vectors
and IDDQ vectors for the remainder of a SoC. You can avoid problems by using one of
these techniques:

IDDQ Technique 1
This technique assumes that you have control over the SoC-level clock
and the processor wrapper clock:
1. Set the processor wrapper to EXTEST mode.
2. Set up the remainder of the SoC, other than the processor, with an
IDDQ vector.
3. Stop the clock to the remainder of the SoC and the processor
wrapper, then apply the processor IDDQ vector.
4. Take the IDDQ measurement with all clocks stopped.
If you do not have control of the clock, then use one of these methods:
• assume that the processor outputs are X when generating IDDQ
vectors for the remainder of the SoC
• gate the outputs to drive known values during IDDQ.

IDDQ Technique 2
Provide a mechanism for driving all the SoC-level and processor-level
scan chains at the same time. You can do this by, for example,
concatenating all SoC-level scan chains into a single chain and driving
this chain at the same time as the processor scan chains.

4-10 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Guidelines

4.4 Manufacturing test interface

This section provides information on the signals used by the processor during
production test.

Note
The wrapper signals in Table 4-3 are only visible when the test wrapper is integrated
with the processor.

Table 4-3 shows a summary of the test signals present on the processor.

Table 4-3 Manufacturing test signal descriptions

Signal Name Direction Description Connection information

SI Input Processor core scan input. During production test, the scan patterns are shifted into
the core through these pins by the tester. Therefore during
production test mode, they must be visible from the top
level of your SoC. For normal mode of operation, these
signals must be set to logic 0.

SO Output Processor core scan During production test, the scan patterns are shifted out of
output. the core through these pins and monitored by the tester.
Therefore during production test mode, they must be
visible from the top level of your SoC.

WSAFE Input Safe operation signal. This signal is not used in the processor. Tie this signal
LOW.

WSII Input Input test wrapper scan During production test, the scan patterns are shifted into
chain input. the test wrapper through this pin by the tester. Therefore
during production test mode, it must be visible from the top
level of your SoC. For normal mode of operation, this
signal must be set to logic 0.

WSIO Output Input test wrapper scan During production test, the scan patterns are shifted out of
chain output. the test wrapper through this pin and monitored by the
tester. Therefore, during production test mode, it must be
visible from the top level of your SoC.

WSOI Input Output test wrapper scan During production test, the scan patterns are shifted into
chain input. the test wrapper through this pin by the tester. Therefore
during production test mode, it must be visible from the top
level of your SoC. For normal mode of operation, this
signal must be set to logic 0.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-11
Confidential
DFT Guidelines

Table 4-3 Manufacturing test signal descriptions (continued)

Signal Name Direction Description Connection information

WSOO Output Output test wrapper scan During production test, the scan patterns are shifted out of
chain output. the test wrapper through this pin and monitored by the
tester. Therefore, during production test mode, it must be
visible from the top level of your SoC.

WINTEST Input Scan chain configuration When INTEST operation is required, set this signal to
select used to describe logic 1. When EXTEST or normal operation is required,
which test mode of set this signal to logic 0.
operation is required.

SE Input Processor core scan This signal is controlled by the tester and therefore, during
enable. production test mode, it must be visible from the top level
of your SoC. When scan testing is not required, set this
signal to logic 0.

WEXTEST Input Scan chain configuration When INTEST or normal operation is required, set this
select used to describe signal to logic 0. When EXTEST operation is required, set
which test mode of this signal to logic 1.
operation is required.

WSEIN Input Independent scan enable When in EXTEST or INTEST mode of operation, the
for test wrapper. tester controls this signal and therefore, during production
test mode, this signal must be visible from the top level of
your SoC. When you do not require EXTEST or INTEST
mode, set this signal to logic 0.

WSEOUT Input Independent scan enable When in EXTEST or INTEST mode of operation, the
for test wrapper. tester controls this signal and therefore, during production
test mode, this signal must be visible from the top level of
your SoC. When you do not require EXTEST or INTEST
mode, set this signal to logic 0.

WCLK Input Clock for wrapper scan Drive this clock when you require INTEST or EXTEST
chain. mode of operation. When you do not require INTEST or
EXTEST mode of operation set this signal to logic 0.

RSTBYPASS Input Reset synchronization RSTBYPASS bypasses the resets. Use this signal to gain
circuit bypass select. full control of the reset signals during testing.

CGBYPASS Input Architectural clock gate CGBYPASS bypasses the clock gating logic. Use this
enable bypass. signal to gain full control of the clocks during testing.

For more information see Table 4-4 on page 4-13.

4-12 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Guidelines

4.4.1 Pin configuration

Table 4-4 shows the pin configuration required on the processor for the various scan test
modes. These pins must be accessible from the top level of your SoC to configure the
test modes.

Note
• The test patterns supplied for the processor must be modified. See About DFT
verification considerations on page 5-2 for more information about this.

• In Table 4-4:
— A dash, -, indicates that the state of these signals does not affect that mode
of operation. You can connect inputs denoted - to 0.
— A T indicates that these signals are controlled or observed by the tester.

Table 4-4 Test signal configurations

Signal name Normal INTEST EXTEST IDDQ

WEXTEST 0 0 1 0

WINTEST 0 1 0 1

SE 0 T 0 T

WSEIN 0 T T T

WSEOUT 0 T T T

SI - T - T

SO - T - T

WSII - T T T

WSIO - T T T

WSOI - T T T

WSOO - T T T

WCLK 0 Clocka Clocka Clocka

RSTBYPASS 0 1 1 1

CGBYPASS 0 1 1 1

a. Drive with a clock balanced to HCLK.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 4-13
Confidential
DFT Guidelines

When you design the DFT strategy for your SoC, you must:
• carefully consider access to the pins
• ensure that, during production test, the processor can be put into the appropriate
test mode.

Failure to do this might make the processor impossible to test. You can make the pins
accessible by, for example:

• Bringing these control pins directly to the pins at the top level of the chip for
control by the tester. If the number of pins in your SoC is limited, then consider
multiplexing these control pins with normal functional pins and make them
available during a manufacturing test mode.

• Having a TEST interface on the SoC pins that can be decoded to provide the
appropriate mode. Selection of this EXTEST mode ties the appropriate pins on
the processor internally.

4-14 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 5
DFT Verification Considerations

This chapter describes the verification considerations for DFT integration of the
processor. It contains the following sections:
• About DFT verification considerations on page 5-2
• Checking that INTEST ATPG vectors are replayed on page 5-3
• Using the EXTEST wrapper model on page 5-4.

Note
The DFT flow for the processor is implementation-defined. For more information on
the DFT solution contact your implementation team.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 5-1
Confidential
DFT Verification Considerations

5.1 About DFT verification considerations

This chapter describes the issues that relate to functional verification of the DFT
integration of the processor. The processor supports scan techniques for production test
vectors.

The processor introduces a test shadow in the SoC, see SoC test shadows and the
processor on page 4-3. To obtain high test coverage of the test shadow, use the EXTEST
wrapper model of the processor when generating ATPG vectors for the SoC logic. For
more information, see Using the EXTEST wrapper model on page 5-4.

This chapter describes:

• How to check that INTEST ATPG scan vectors are run to test the processor.

• How to use the EXTEST wrapper model of the processor when you generate
ATPG vectors of your SoC. Using the model ensures that you obtain very high
fault coverage.

Note
If the supplier of your implementation provides test vectors you can check INTEST
modes, but you can only check the EXTEST mode if you generate ATPG vectors for
your SoC. If you obtain low coverage around the processor, it might indicate that
EXTEST mode has not been set up correctly.

5-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Verification Considerations

5.2 Checking that INTEST ATPG vectors are replayed

The purpose of the INTEST ATPG vectors is to test the processor.

Note
The DFT flow for the processor is implementation-defined. For information on the
INTEST ATPG test vectors and how to replay them contact your implementation team.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 5-3
Confidential
DFT Verification Considerations

5.3 Using the EXTEST wrapper model

SoC test shadows and the processor on page 4-3 describes the problem for test
presented by the test shadow. To overcome this test difficulty use the test view of the
processor called the EXTEST wrapper model. The EXTEST wrapper model enables
you to obtain high fault coverage of the test shadows in your SoC that are introduced
when the processor is integrated.

You must use the EXTEST wrapper model with an ATPG tool, for example Synopsys
TetraMAX, to generate ATPG vectors for your SoC logic.

Note
You must have:
• the netlist for your SoC design
• the Verilog models of the cell library that you are using.

Table 4-4 on page 4-13 describes the pin configuration required during EXTEST mode
for the processor. You must use the information in this table when you integrate the
processor in your SoC to ensure that the test pins are controlled appropriately. To run
ATPG on your SoC design, that includes the processor, you must:
1. Ensure that the pin configurations for EXTEST mode of the processor are set
correctly. See Table 4-4 on page 4-13.
Caution
If the test signals shown in Table 4-4 on page 4-13 are not available at the top level
in your SoC design then you might not be able to generate the ATPG test patterns
using the EXTEST wrapper model.

2. Load the processor EXTEST wrapper and your SoC logic into the ATPG tool and
create the ATPG patterns.
To generate EXTEST test patterns for the SoC using, for example, the Synopsys
TetraMAX tool:
a. Read the cell library Verilog model.
b. Read the other libraries, for example input and output pads.
c. Read the EXTEST wrapper model.
d. Read the netlist for the rest of the top-level SoC that instantiates all the parts
described.
e. Build the model.
f. Use one of these two methods to set input constraints that put the wrapper
in EXTEST mode:
• Use commands such as "add pi constraint ..."

5-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 DFT Verification Considerations

• Load a STIL file that defines load_unload and capture procedures.

g. In addition to application of these constraints you might also have to:
• put the SoC into manufacturing test mode
• bypass the PLL
• bypass reset logic
• run a test setup sequence to reset the boundary scan TAP controller
and make the boundary scan cells transparent.
3. Ensure that the test patterns you create work, by running them against the entire
SoC design.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 5-5
Confidential
DFT Verification Considerations

5-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 6
Design Synthesis

This chapter describes how to synthesize the processor for integration into your design.
It contains the following sections:
• About synthesis on page 6-2
• Timing models on page 6-3
• Clock tree latency on page 6-5.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 6-1
Confidential
Design Synthesis

6.1 About synthesis

This chapter describes the synthesis stages of your SoC design with the processor. The
chapter assumes that you are familiar with synthesis procedures and only describes the
steps required to use the processor timing views. This chapter does not describe any
particular methodology, such as top-down or bottom-up. For more information please
see the appropriate Reference Methodology documentation.

Figure 6-1 shows the synthesis process.

Note
All commands and syntax are for Synopsys synthesis tools and are given in Tool
Command Language (TCL). For other tools you must derive the equivalent commands.

Controls and constraints:

Maximum clock frequency
Timing constraints

Inputs: Outputs:
Synthesis process
Design proven RTL Synthesized netlist .v file

Resources:
CORTEXM3Integration_slow.db
CORTEXM3Integration_fast.db
Target library .db file
EDA tools

Figure 6-1 Synthesis process

6-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Design Synthesis

6.2 Timing models

It is expected that your implementation team have supplied timing views of the
processor in the open Liberty format, .lib files. You can use these with either the
Synopsys synthesis and place and route or other place and route tools. Alternative place
and route tools might require conversion from the .lib format. The timing views are
context independent and contain all the necessary input and output requirements for the
processor.

You must:

• use the equivalent .db files for any other tools that require a timing view of the
processor.

Table 6-1 shows the processor .lib files.

Table 6-1 Summary of synthesis deliverables

Filename Description

CortexM3Integration_fast.lib Liberty .lib fast timing model for best-case process, temperature, and voltage conditions

CortexM3Integration_slow.lib Liberty .lib slow timing model for worst-case process, temperature, and voltage
conditions

6.2.1 Compiling the .lib files

You must use Synopsys Library Compiler to compile .lib files into .db files. For more
information on compilation of the .lib files, see the Synopsys documentation on
Library Compiler.

6.2.2 Using the timing models

To use the supplied processor timing models in your Synopsys environment, you must
alter your dc_shell setup:

1. Add the installation location of the synthesis deliverables to the variable

search_path:
set CortexM3Integration_lib_loc "full path where the CortexM3Integration library files are located"
set search_path [concat $search_path $CortexM3Integration_lib_loc]

2. Add the processor timing files into your link library:

set CortexM3Integration_slow_lib CortexM3Integration_slow.db
set CortexM3Integration_fast_lib CortexM3Integration_fast.db
set link_path [concat * $CortexM3Integration_slow_lib
$CortexM3Integration_fast_lib]

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 6-3
Confidential
Design Synthesis

3. Set the correct library conditions:

set_min_library $CortexM3Integration_slow_lib -min_version
$CortexM3Integration_fast_lib

6-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Design Synthesis

6.3 Clock tree latency

The processor at the CortexM3 level contains clock trees inserted from the HCLK,
FCLK, DAPCLK, and WCLK, if a wrapper is included. The processor at the
CortexM3Integration level contains clock trees inserted from HCLK, FCLK,
SWCLKTCK, TRACECLKIN, and WCLK, if a wrapper is included. The clock trees
for these pins have a significant latency because of this clock tree buffering. Figure 6-2
shows an example buffer tree on the HCLK pin.

SoC

Macrocell
SET INPUT SET SET SET SET OUTPUT
D Q D Q D Q D Q D Q

Q Q Q Q Q
EN EN EN EN EN

HCLK
SET
D Q
HCLK
Clock
PLL Gen Q
EN
Block

REFCLK

Figure 6-2 HCLK clock latency

You must compensate for the latency of the clock tree latency during the synthesis stage
of the SoC. You must ensure that HCLK, FCLK, and WCLK balance with respect to
each other at the edge of the processor. Failure to compensate for the latency can create
many false timing violations and hide real timing violations. This is because the extra
delay through the clock tree gives the input paths more setup time and causes the output
to appear much later in the cycle.

If you do not compensate for the clock tree latency, the maximum achievable
performance of your SoC can be degraded.

Alternatively, you can use the set_clock_latency command to set ideal clocks to
compensate for the latency of the clock tree in the processor at the synthesis stage of the
SoC.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 6-5
Confidential
Design Synthesis

FCLK must be skew balanced with respect to HCLK.

DAPCLK, SWCLKTCK, and TRACECLKIN are asynchronous to HCLK.

For more information about the relationship between HCLK and FCLK see the
Cortex-M3 Technical Reference Manual.

All other SoC logic, referenced to the SoC clock, outside the processor must be
synthesized with a delayed version of HCLK. Apply the minimum and maximum clock
latency values of the processor to this SoC clock. This emulates the processor HCLK
pin at the top of the clock tree as Figure 6-2 on page 6-5 shows.

The values for slowest latency, worst case, and fastest latency, best case, are defined in
the Cortex-M3 Core Configuration and Performance Summary document.

Note
The implementor of the processor produces the Core Configuration and Performance
Summary. This document summarizes the core, memory, test, configurations, the
process and libraries used for the implementation, and the performance numbers
achieved.

You can use Static Timing Analysis (STA) tools to check that the register-to-register
paths, that cross the processor boundary, are correct and meet the performance
requirements for your SoC.

To avoid incurring a performance penalty, you must also balance the depth of the system
clock tree with that of the processor during the Clock Tree Synthesis (CTS) stage of
place and route. See Chapter 7 Physical Integration Guidelines for more information.

The processor wrapper has its own dedicated clock, WCLK. To prevent hold violations
in the wrapper register, you must set the clock uncertainty between HCLK and WCLK
to be equal to the skew between these clocks.

During the synthesis stage, you must create the clocks for the SoC and the processor in
a specific way.

For example commands for integration of the processor at the synthesis stage, see
Creating minimum and maximum latency clock on page 6-7.

6-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Design Synthesis

6.3.1 Creating minimum and maximum latency clock

If you have created buffer trees to balance the clocks, as described in Clock tree latency
on page 6-5, you must:

1. Set the clock tree latency values, for example:

set blockARM_internal_clock_delay_max 1.81; #EXAMPLE ONLY
set blockARM_internal_clock_delay_min 0.70; #EXAMPLE ONLY
...
set total_balanced_clock_delay 2.5; #EXAMPLE ONLY

2. Create the SoC clock, for example:

create_clock CLK -p <period>
create_generated_clock -div 1 -source XCLK -name ARMCLK uMacroCell/HCLK
set_clock_latency XCLK $total_balanced_clock_delay
set_clock_latency ARMCLK -max \
[expr $total_balanced_clock_delay -$blockARM_internal_clock_delay_max ]
set_clock_latency ARMCLK -min \
[expr $total_balanced_clock_delay -$blockARM_internal_clock_delay_min ]

Note
With this method, you must set appropriate clock latencies for minimum and
maximum timing. The default for set_clock_latency uses the same value for
minimum and maximum. However, this can give minimum timing violations,
during synthesis, on paths between the processor and the synthesized logic.

3. Choose the appropriate latency values for maximum and minimum timing. For
example, the processor might have these latency values:
clock latency slowest @ Worst Case = 1.81ns
clock latency fastest @ Worst Case = 1.61ns
<skew = 0.20ns>
clock latency slowest @ Best Case = 0.88ns
clock latency fastest @ Best Case = 0.70ns
<skew = 0.18ns>
In this case, for example, choose the latency for maximum and minimum timing
in the middle of the range, that is 1.71ns at the worst case and 0.70ns at the best
case condition.
If you cannot achieve the timing you require on an input or output, with these
midrange settings, you might choose to move the processor up or down the clock
tree, to relax the critical path.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 6-7
Confidential
Design Synthesis

6-8 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 7
Physical Integration Guidelines

This chapter describes the guidelines for the physical integration of one or more
instances of the processor into a SoC design.

Note
The information in this chapter is based on a typical physical integration flow. Specific
aspects might vary depending on how the processor is hardened, for instance how it is
floorplanned and its pin locations.

It contains the following sections:

• About physical integration on page 7-2
• Floorplanning on page 7-3
• Place and route on page 7-6
• Physical integration checks on page 7-8.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 7-1
Confidential
Physical Integration Guidelines

7.1 About physical integration

You must perform a number of different checks and tasks during the physical
integration stage of the design flow. Figure 7-1 shows the physical integration process.
Physical integration involves several steps:
• floorplanning
• place and route
• physical integration checks.

Figure 7-1 shows the physical integration process.

Controls and constraints:

Timing constraints
Floorplan guidelines
Pad ordering

Outputs:
Physical Post-layout netlist .v file
Inputs: Place and
Floorplanning integration Macro abstract for size
Post-synthesis netlist .v file route, extract
checks and pin positions
Extracted parasitics

Resources:
Technology library
Technology file
Technology
mapping files
Macro and RAM files
Scripts

Figure 7-1 Physical integration process

Note
These tasks are mentioned to highlight the issues, related to the processor, that you must
consider during physical integration. It is not an exhaustive list of tasks, and you must
have an in-depth knowledge of place and route to complete physical integration.

7-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Physical Integration Guidelines

7.2 Floorplanning
This section provides information on physical layout of the processor and
manufacturing considerations for:
• Placement
• Orientation
• Power connections on page 7-4
• Signal connections on page 7-5.

7.2.1 Placement

You must consider where to place the processor, that is, in the corner or the centre of the
SoC, and the implications of your choice, for example:

• Access to the pads of the SoC around the processor might be difficult because of
routing restrictions. See Routing restrictions on page 7-6.

• You might require routing channels around the edge of the processor, with soft
blockages.

• When you allocate interfaces, you must take care of pads blocked by the
processor because the timing for these blocked pads might be severely affected.
If possible, allocate these pads to interfaces that are not speed-critical.

Note
You must ensure that the placement of the processor snaps to the grid. Failure to do this
results in off-grid routing problems when you make connections to the processor pins.

7.2.2 Orientation

You must integrate the processor so that the orientation suits the preferred routing
direction. You must consider either 0°, 180°, or mirror placements from the natural
orientation of this block. This prevents problems in routing to pins in the non-preferred
routing direction.

Note
It is possible to rotate the processor by 90 degrees. If you do this the connections to
some of the pins on the processor might be in the non-preferred routing direction. This
can lead to routing congestion in these areas.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 7-3
Confidential
Physical Integration Guidelines

7.2.3 Power connections

You must connect all power lines, VSS and VDD, to the processor in a width at least the
size of the VSS and VDD pins. Ideally, continue this structure outside the processor in
the SoC. You can alter the width and pitch of routes, to match the grid area of the
standard cell, as long as an appropriate amount of power reaches each processor
boundary. See the Cortex-M3 Core Configuration and Performance Summary
document to determine on which layers the processor power pins are available.

Note
The processor has been analyzed under the assumption that there are ideal voltage and
current sources at all processor power pins. You must ensure that sufficient voltage and
current is supplied to all the processor power pins.

7-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Physical Integration Guidelines

7.2.4 Signal connections

The processor pins must not be obscured by the corner of the SoC. That is, the pins must
be adjacent, and close, to a standard cell region. The speed of the AHB interfaces on the
processor can degrade if you do not place it optimally with respect to the standard cell
region. Figure 7-2 shows the correct way to place the signals.

I/O pads

SoC logic

Macrocell signals

Macrocell

I/O pads

Figure 7-2 Correct signal connections

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 7-5
Confidential
Physical Integration Guidelines

7.3 Place and route

When you have a floorplan for your SoC design you can start place and route. This
section describes:
• Clock tree latency
• Routing restrictions
• Antennas on page 7-7.

7.3.1 Clock tree latency

The processor has an internal clock tree, as described in Clock tree latency on page 6-5,
with an associated latency, or insertion delay. This delay must be modeled so that, at the
system level, clock-tree insertion tools correctly determine where to place the processor
in the clock-tree.

Because this information is not present in the Synopsys Liberty, .lib, view of the
processor, the information must be attached, as a property, to the clock ports of the cell.
You must make sure the information is attached before clock-tree insertion. You can do
this with Synopsys Astro, for example, like this:
dbDefineSyncPort "CortexM3Integration" '(("HCLK" "invertRise" (100 150)))

Here, all cells of type CortexM3Integration, that is cell master, have an insertion delay
added to port HCLK. The minimum insertion delay is 100ps, the maximum insertion
delay is 150ps, that is the skew between flops is 50ps.

This dbDefineSyncPort command also instructs Astro to treat this port as a termination
point for the clock tree.

Note
To get the correct values to use in the dbDefineSyncPort command, see the Cortex-M3
Core Configuration and Performance Summary document.

7.3.2 Routing restrictions

Routing over the processor might impact performance because of the capacitive effects
of adjacent metal layer wiring. Therefore, certain routing restrictions apply to the
processor that depend on the process you use. These restrictions depend on the number
of metal layers within the processor and the number of layers available in your choice
of process.

7-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Physical Integration Guidelines

Power and signal pins are accessible on multiple layers for flexibility of integration with
the processor in your SoC. It is recommended that you give careful consideration to the
metal layers that you use to route supplies and signals, to maintain good quality results
and routability.

7.3.3 Antennas

The processor is verified and passes antenna checks for the target manufacturing
process. Diffusion diodes reduce the possibility of antenna creation during routing at the
next level of hierarchy. These diodes exist on each signal port of the processor, as close
as possible to the port. However, this does not guarantee that your integration does not
create new antennas at the integration level.

Antenna repair

You must fix antennas at the SoC level.

Antenna checks

After stream-out of the SoC that contains the processor, you might still see antenna rule
violations. These rule violations appear in transistor level DRC on the boundary of the
processor even when your design is antenna clean in the place and route tool.

The antenna rule violations appear because of the lack of design information in black
box GDSII, footprint, views. It is not possible for the transistor-based DRC tool to see
any of the diode protection data in the processor when working with these footprint
views.

In the absence of data on the internal protection diodes, it is recommended that you
perform a trial merge with the foundry to check whether or not these rule violations
exist in the post-merged SoC design.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 7-7
Confidential
Physical Integration Guidelines

7.4 Physical integration checks

This section describes the checks that you must perform as part of the physical
integration process:
• Layout Versus Schematic
• Design Rule Check
• Antenna checks

7.4.1 Layout Versus Schematic

Layout Versus Schematic (LVS) verifies the connectivity of the layout with that of the
schematic. You can run LVS at either:
• the gate or cell level
• the transistor level.

Because the processor is obscured, you must verify that the intended connections to the
processor are correct. To do this perform these checks in this order:
1. Cell-level LVS
2. Transistor-level LVS.

7.4.2 Design Rule Check

The Design Rule Check (DRC) verifies that the SoC design can be manufactured in
accordance with the physical design rules from the foundry.

To perform DRC correctly, you must use the information supplied in the abstracts for
the processor.

7.4.3 Antenna checks

Antenna checks verify that the metal layers conform to a particular manufacturing
check. These checks are occasionally included with the DRC.

To ensure that there are no antenna rule violations that involve the processor, you must
use the preventative measures mentioned in Antennas on page 7-7.

7-8 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 8
Post-Layout Verification

This chapter describes what you must do for post-synthesis and post-layout netlist
timing and functional verification of your SoC design. It contains the following
sections:
• About verification on page 8-2
• Formal equivalence checks on page 8-4
• Static Timing Analysis on page 8-5

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 8-1
Confidential
Post-Layout Verification

8.1 About verification

The two types of verification are static verification and dynamic verification. Static
verification includes formal equivalence checks and Static Timing Analysis (STA).
Dynamic verification usually involves simulation of a back annotated, post-layout
netlist.

Note
This chapter does not describe any dynamic verification of the RTL.

You are recommended to perform these verification steps:

• use formal equivalence check to prove that the SoC RTL and post-synthesis netlist
are logically equivalent

• use formal equivalence checks to prove that the post-synthesis netlist and
post-layout netlist are logically equivalent

• use STA to prove that the post-layout netlist meets the timing goals for your SoC

• perform netlist simulations on a back annotated post-layout netlist.

Figure 8-1 shows the formal equivalence check verification process.

Controls and constraints:

Mapping rules

Inputs:
RTL Outputs:
LEC
Post-synthesis netlist Reports
Post-layout netlist

Resources:
Verilog models of target cell library
Technology tools
Macrocell Verilog stub file

Figure 8-1 Formal equivalence check verification process

Figure 8-2 on page 8-3 shows the STA verification process.

8-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Post-Layout Verification

Controls and constraints:

Timing constraints

Inputs: Outputs:
Post-layout netlist STA Reports
Parasitics SDF

Resources:
Library files (including macrocell timing views)
Technology tools

Figure 8-2 STA verification process

Figure 8-3 shows the dynamic verification process.

Controls and constraints:

None

Inputs:
Dynamic Outputs:
Post-layout netlist
simulations Simulaton logs
SDF

Resources:
DSM
Library files (including macrocell simulation views)
Technology tools

Figure 8-3 Dynamic verification process

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 8-3
Confidential
Post-Layout Verification

8.2 Formal equivalence checks

To equivalence check SoC netlists that include the processor, at either the post-synthesis
or the post-layout stages, you must instruct the tool that performs the formal
equivalence checks to obscure the processor. This must happen in all the stages that
follow when you perform:

• an RTL to post-synthesis netlist comparison of your SoC design

• a post-synthesis to post-layout netlist comparison of your SoC design

• a post-layout to Engineering Change Order (ECO) of your post-layout netlist

comparison of your SoC design.

8.2.1 Using the processor Verilog stub file

To successfully obscure the processor, you must read in the Verilog stub file for the
processor. This file enables the formal equivalence check to:

• turn the processor outputs into extra SoC inputs, that can be set to any value when
they drive SoC logic

• turn the processor inputs into extra SoC outputs, that makes them part of the
equivalence check.

Obscuring the processor during the formal equivalence check process is a valid method
if the processor netlist has also passed logical equivalence checks.

8-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Post-Layout Verification

8.3 Static Timing Analysis

This section provides information on how to perform STA on your post-layout SoC
design with the processor.

Note
• The commands in this section are in TCL and assume that:
— you use PrimeTime for STA
— the .lib files are already compiled to .db files.

• This section only gives guidelines for how to set up the tool to use the processor
timing model for STA. You must use the guidelines in the relevant parts of your
STA scripts.

To perform STA you must:

1. Ensure that the compiled .lib files of the processor are in your Synopsys path.
These entries must be present in your PrimeTime setup path:
set CortexM3Integration_lib_loc "full path where the CortexM3Integration library files are located"
set CortexM3Integration_slow_lib CortexM3Integration_slow.db
set CortexM3Integration_fast_lib CortexM3Integration_fast.db
set search_path [concat $search_path $CortexM3Integration_lib_loc]
set link_path [concat * $CortexM3Integration_slow_lib $CortexM3Integration_fast_lib]

2. Establish a maximum to minimum relationship:

set_min_library $CortexM3Integration_slow_lib -min_version
$CortexM3Integration_fast_lib

3. Set the operating conditions, for example:

#
# The timing models of the CortexM3Integration hardened macrocell
# does not have specific named operating conditions, so a
# symbolic operating condition name will be created for
# these libraries using the create_operating_conditions command
#
create_operating_condition \
-name fast \
-library CortexM3Integration_fast.db:CortexM3Integration_fast \
-process 1.00 \
-temperature -40.0 \
-voltage 1.32
create_operating_condition \
-name slow \
-library CortexM3Integration_slow.db:CortexM3Integration_slow \
-process 1.00 \
-temperature 125.00 \

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 8-5
Confidential
Post-Layout Verification

-voltage 1.08
#
# Now set the operating condition using the symbolic names
#
set_operating_condition -analysis_type bc_wc \
-min fast \
-min_library $CortexM3Integration_fast_lib:CortexM3Integration_fast \
-max slow \
-max_library $CortexM3Integration_slow_lib:CortexM3Integration_slow

4. Deal with the clocks. You must create the clocks for your SoC and ensure that
they are declared as propagated. Because this is a post layout netlist STA, there is
nothing specific that you must do for the clock latency in the processor. This is
taken care of in the processor timing models.

8-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Chapter 9
Sign-Off Guidelines

This chapter describes the recommendations for sign-off checks for an SoC design
including the processor. It contains the following section:
• About sign-off on page 9-2.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. 9-1
Confidential
Sign-Off Guidelines

9.1 About sign-off

This section summarizes specific sign-off issues related to a design that incorporates the
processor:
• Functional verification
• DFT verification
• Timing sign off
• Physical verification.

Note
ARM strongly recommends that you do all of these sign-off checks.

9.1.1 Functional verification

Before sign off it is recommended that you ensure that all the configuration signals in
your design are connected correctly and that the clocks are correctly configured. See
Chapter 3 Functional Integration Guidelines and the relevant technical reference
manuals for both the processor core and associated support devices.

9.1.2 DFT verification

ARM recommends that you prove the test functionality of the processor in your design.
It might be impractical to simulate the entire set of serial test patterns for your SoC, but
it is recommended that you prove all of the patterns in the various production test modes
described in Production test modes on page 4-5.

9.1.3 Timing sign off

ARM recommends that you use STA, with the supplied timing models, as your primary
method of timing sign off. You can add dynamic simulation, using back-annotated SDF,
to improve confidence in timing verification.

9.1.4 Physical verification

ARM recommends that you perform physical verification. For example, ensure that:
• the processor satisfies the requirements for IR drops
• all processor inputs and outputs are free of antenna rule violations
• all LVS and DRC checks are free of errors.

9-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Appendix A
Example System

This appendix describes the Cortex-M3 Example System. It contains the following
sections:
• About the Cortex-M3 Example System on page A-2
• Directory structure on page A-3
• Testbench structure on page A-5
• Test overview on page A-8
• Compiling and running scripts on page A-10
• Trace verification scripts on page A-12
• Modifying RTL on page A-13
• Modifying Tests on page A-16.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-1
Confidential
Example System

A.1 About the Cortex-M3 Example System

The Cortex-M3 Example System provides a platform to demonstrate the running of
simple tests in addition to testing of JTAG/SWD behavior and trace validation. The
trace validation uses CSCompare and EtmCompare script to verify correct output from the
trace port. This can be ported to a user's SoC testbench for SoC-level verification of the
JTAG/SWD and traceport connectivity.

The system includes an example of:

• A system that contains the Cortex-M3 processor and ETM macrocell.

• A testbench that contains components used to verify the operation of the system.

• Scripts used to build the Verilog, compile the tests, run the tests, and check the
testlog files.

• Tests to help verify correct operation of the ETM and debug connectivity. For
more information see Test overview on page A-8.

Note
Before you begin using the example system, you must read any README files that are
supplied with the example system deliverables.

A-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

A.2 Directory structure

Figure A-1 shows the directory structure of the example system.

example/

tbench
coresight
doc
logical
SWJIM
armBST
shared

logical
bin
tests
bin
src
Software
bin
Etm
modules

Figure A-1 Example System directory structure

The directories contain the following:

Verilog RTL source

example/tbench contains the HDL files for the testbench
components for the example system
example/coresight/logical/armBST contains the Boundary Scan
Trickbox (BST). It also contains the Model Manager required to
use the BST.
example/coresight/logical/SWJIM contains the HDL files for the
Serial Wire JTAG Interface Manager.
The rest of the required RTL files are used as required from the
logical directory, which is in parallel to the example directory.

Test programs example/Software contains the source files for the test programs.

Simulation The example directory is the directory from which all tests and
simulations are performed.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-3
Confidential
Example System

Verification scripts example/bin contains all the scripts used by the example system.
These include the scripts for analyzing simulation logs.

Additional documentation
example/coresight/doc contains additional documentation for the
example system.

A-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

A.3 Testbench structure

The Example System is a basic one that has a RAM on the System bus, and memory on
the I-Code and D-Code buses. There is also an optional APB bus that requires elements
from the AMBA Design Kit (ADK). The CM3ExampleConfig.vh file controls the
configuration of the testbench. The details and memory map are described in the
testbench top level, tbench/example_tbench.v

A.3.1 System testbench

The testbench comprises:

• Memory-models for program and data storage. See External memory.

• A memory-mapped Trickbox. See Trickbox.

• A controller for the JTAG/SW interface. See Serial Wire and JTAG Interface
Master. This is equivalent to a RealView ICE in a hardware system.

External memory

The testbench implements a memory model with dynamic allocation. On startup, it

loads the file rom.hex that contains the program to be run in the system.

Trickbox

The trickbox is a memory mapped peripheral that carries out useful functions in a
simulation environment. These functions include simulation termination, UART
emulation, timers, and markers.

Serial Wire and JTAG Interface Master

The Serial Wire and JTAG Interface Master (SWJIM) controls the Serial Wire/JTAG
interface in the testbench, similar to the way a RealView ICE device does in a hardware
system. In the tests provided, it controls the Cortex-M3 processor during debug. All
these accesses are performed through the DAP, which controls the Debug-APB
interface.

The SWJIM reads a series of files that contain instructions and control information for
the SWJIM. The commands that you scan into the JTAG or Serial Wire port must be
included in the source code of the test. The BST_START assembler macro indicates the
start of the SWJIM instructions in the test. The SWJIM includes an instantiation of the
BST that generates the JTAG or Serial Wire sequences when the DAP is accessed in
such mode. A script called bintobst is provided. This script first extracts the armBST
module instructions from the assembled binary image of the test. It then uses a program

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-5
Confidential
Example System

called parse_bsi.pl to process the high-level commands into a form that the SWJIM can
accept. A third script, called DAPbsi.pl, converts some normal SWJIM accesses into the
type used by the DAP.

The SWJIM reads three files that contains instructions from a source file written in the
DAP Macro Language. The source file is pre-processed by a set of scripts prior to test
simulation:

• The DAPbsi.pl script takes the source file as an input and generates three files:
— A <testname>.bsi file for the armBST module with the JTAG stimuli for the
test. This file is linked into the test run directory with the name JTAGbsi by
the compiling and running script ikvalidate.
— A SWIM<testname>.bsi file that contains Serial Wire stimuli and must be
translated by the SWIMconvert.pl script.
— A SWJIMCtl<testname>.bsi file that contains control and mode information,
and must be translated by the SWJIMCtlconvert.pl script.

• The SWIMconvert.pl script takes the SWIM<testname>.bsi file as an input and

generates a file called SWIM<testname>.hex that contains hexadecimal instructions
for the Serial Wire stream generator of the SWJIM. This file is linked into the test
run directory with the name SWIM.hex by the compiling and running script
run_example.

• The SWJIMCtlconvert.pl script takes the SWJIMCtl<testname>.bsi file as an input

and generates a file called SWJIMCtl<testname>.hex that contains hexadecimal
instructions for the execution control of the SWJIM. This file is linked into the
test run directory called SWJIIMCtl.hex by the compiling and running script
run_example.

Figure A-2 on page A-7 shows the complete flow of source preprocessing.

A-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

<testname>

DAPbsi.pl

SWIM<testname>.bsi SWJIMCtl<testname>.bsi

SWIMconvert.pl SWJIMCtlconvert.pl

SWIM<testname>.hex SWJIM<testname>.hex <testname>.bsi

Figure A-2 Preprocessing scripts flow

TPIUMonitor

The TPIUMonitor module simulates the operation of a Trace Port Analyzer (TPA). It
captures the data coming from the trace port and stores it to a log file, log.tpiu.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-7
Confidential
Example System

A.4 Test overview

The following sections describe the tests:
• Dhrystone (dhry)
• my_dhry
• test_mla
• test_apb1
• CM3_J_CM3Trace1 and CM3_S_CM3Trace1.

A.4.1 Dhrystone (dhry)

This test is slightly changed from the version delivered as an example in RVDS tools.
In particular, a call to scanf in dhry_1.c was removed and hard coded to 4 dhrystone
loops. This has warnings suppressed during compile because it generates a lot of
warnings that do not require attention.

A.4.2 my_dhry

This test is a version of dhrystone that has small additions to display the number of
clocks for each loop. It also has some other miscellaneous interrupts, exceptions, ITM
accesses, and other test cases added. This also has warnings suppressed because it is
based on Dhrystone.

A.4.3 test_mla

This is a simple test that runs some multiply-accumulate cases. It provides examples of
using the embedded assembler and accessing explicit addresses in C. It is a good
starting point for new tests.

A.4.4 test_apb1

This only runs correctly if you install the AhbToApb bridge and some example APB
peripherals from the AMBA Design Kit (ADK).

A.4.5 CM3_J_CM3Trace1 and CM3_S_CM3Trace1

These tests perform the following:

1. Check SWJ-DP DPACC registers

2. PWRUP request and acknowledge handshaking

3. Read all APs ID registers (including defaults)

A-8 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

4. Read and Write Code bus memory, address:00000200

5. Read the CPU ID Base Register

6. Read the Debug Halting and Status Register (DHCSR)

7. Write 0xA05F0003 to the DHCSR to halt the processor

8. Do some accesses while the processor is halted

9. Configure the ETM, TPIU and ITM module

10. Start Trace

11. Restart the processor

12. Do some ITM accesses (processor code)

13. Signal the debugger, SWIJM, to stop trace (processor code)

14. Flush ETM and TPIU and terminate test.

These tests use DAP macro language to drive the debugger.

CM3_J_CM3Trace1 is a JTAG test. CM3_S_CM3Trace1 is the equivalent SWD test.

The source file for these tests is Software/CM3_J_CM3Trace1.cdapml. This is a simple

format that combines a C test, which is run by the processor, and a DAP macro language
test, which controls the JTAG interface by means of the SWJIM.

The C part of these tests is taken from my_dhry.c.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-9
Confidential
Example System

A.5 Compiling and running scripts

Use the run_example perl script to:
• build the executable image of the test being run, if applicable
• launch the simulation.

In the default configuration, the output of the simulation is logged to the screen and
messages are echoed to the console during the simulation. In this case:

• if the test passes, the following message prints is printed:

** TEST PASSED OK **

• if the test fails, diagnostic messages precede the message:

** TEST FAILED **

Use the run_example script as follows:

Run_example <options> <testname>

where <options> can be:

• simulation options
• run options, see Table A-1
• build options, see Table A-2 on page A-11.

and <testname> is the name of the test that has failed or that you want to run.

Table A-1 lists the build options for the run_example script.

Table A-1 run_example run options

Option Description

-I Specifies that the simulation is run interactively.

-v Specifies that the test is run in batch mode, that is, non-interactively.

-etm Specifies that the ETM trace is to be checked.

-cdapml Run with SWJIM using cdapml instead of c file.

A-10 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

Table A-2 lists the build options for the run_example script.

Table A-2 run_example build options

Option Description

-build Compiles the verilog for the simulator

-<simulator> Simulator to be used. Choose from mti, vcs or, nc

You must have the ARM compiler, armcc, and your verilog simulator, NC-Verilog, VCS
or ModelSim, available in your path before calling the run_example script. As an
example, you can build and run the test_mla test interactively using Modelsim with the
following command:
run_example -build –mti -I test_mla

To load a DAP Macro Language test using the SWJIM along with loading a c file, and
to check the ETM trace outputs using VCS non-interactively, you can use:
run_example -build -vcs –v -etm -cdapml CM3_S_CM3Trace1

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-11
Confidential
Example System

A.6 Trace verification scripts

If the -etm flag is passed to run_example, then the following trace verification scripts are
automatically run:
CSCompare -extracttpiu -basetpiu 0x00040000

EtmCompare

At the end of the verilog simulation run, a message is printed indicating that the test
went as expected:
TUBE: "** TEST PASSED OK **"

This confirms that there were no errors during simulation.

The ETM Comparison stage runs the following commands:

1. CSCompare - This splits the TPIU output into separate streams for each trace
source. At the end you should see a message:
Comparison successful
** PASSED **

2. EtmCompare - This validates the CM3 ETM stream. At the end, you should see a
message:
** ETM PASSED OK **

EtmCompare and CSCompare are complex comparison scripts for which there is very
limited support available. The purpose of the tests CM3_[JS]_CM3Trace1 is to enable an
SoC integrator to verify that their Debug and Trace pins are properly connected.

These scripts do not compare ITM results. CSCompare does generate a log file with the
contents of the ITM trace stream, but no further analysis of the ITM trace stream is
made.

A-12 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

A.7 Modifying RTL

After using the example system provided, you can port it to test your own system.

Modifying the RTL is described in:

• Memory
• SWJIM
• Trickbox
• Trace loggers on page A-15.

A.7.1 Memory

The example system testbench includes a behavioral memory model. At the start of
simulation this model reads in the rom.hex file, produced during test program
compilation. If you use a different type of memory model, you must ensure that your
memory system is capable of automatically loading rom.hex at start up.

You must generate a mechanism to load the memories of your SoC and incorporate that
into the Makefile in the Software directory. You must also modify the scatterfile,
cm_code_on_codebus.scat, with information about your memory map. If you have strong
memory size constraints, you might have to use the microlib. This is described in more
detail in Software/README.

A.7.2 SWJIM

The SWJIM controls the Test Access Port in the DAP using the Serial Wire/JTAG port
during simulation. Some of the tests include a section of SWJIM code used to access
the DAP. These tests use a cdapml file as their source instead of only a file. If you have
debug included in your Cortex-M3 implementation, you must include the SWJIM in
your SoC testbench to be able to drive the debug interface. You must connect the
SWJIM to the JTAG or SWD pins of your SoC.

For more information on the SWJIM see Serial Wire and JTAG Interface Master on
page A-5.

A.7.3 Trickbox

The Trickbox provides several services for the simulation environment. These include
simulation termination, UART emulation, and some simulation timers and markers.

The Trickbox works by monitoring accesses to particular locations in normal RAM.

When a write to one of these locations is detected, the appropriate action is taken. These
features have software support in various places in the software.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-13
Confidential
Example System

The trickbox is partially portable to your SoC testbench. Because the Trickbox operates
primarily by monitoring accesses to the memory map you probably must modify the
address of some of the features. You must also change explicit references to the new
address in clib.c and your C test sources. You must also change references to the
Trigger address in your DAP macro language sources.

KILLSIM

If the processor writes to location 0xCC00CC00, then the Trickbox detects this write and
will print a message:
@@@@@ KillSim Received: Stop Simulation in 100 clocks (TrickboxTimer: xxxxxxxx)

and then finish the simulation after 100 HCLK clocks.

This is portable to your SoC testbench.

UART

If the processor writes a byte to location 0x4444_00AC, then the Trickbox detects this
write as an UpdateUART action and writes the byte to the Verilog console and to the
logfile UART.out. This mechanism, along with code in clib.c, enables printf() calls in
the C language tests to appear on the screen.

This is portable to your SoC testbench.

SendSignal

If the processor writes to location 0x4444_00B4, then the Trickbox detects this write and
pulses a signal in the Trickbox called SendSignal. This is useful to find a particular
action in a test in waves. By including calls to SendSignal() in your test and then looking
for pulses on <signalname> in your waves, you can locate particular parts of your test.
test_mla and my_dhry both use this feature.

This is portable to your SoC testbench.

Timer

A timer is implemented in the Trickbox. It can be started and read from C code. If the
processor writes or reads location 0x2000_0000, then the Trickbox detects this access and
will pulse a <signalname>. This is useful to find a particular action in a test in waves.
By including calls to SendSignal() in your test and then looking for pulses on
<signalname> in your waves, you can locate particular parts of your test. test_mla and
my_dhry both use this feature.

A-14 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Example System

The code is portable to your SoC testbench. However, it is not required to verify Debug
or Trace functionality on your SoC.

Trigger

The trigger is used to signal from C code to the debugger that the interesting part of a
test is completed and it is time to turn off trace, flush the ETM and TPIU, and terminate
the simulation. The trigger is at location 0x200F_FFF0.

This is portable to your SoC testbench.

Other Trickbox features

The Trickbox also allows a test to assert an NMI (UpdateNMI) or other interrupt
(UpdateISR). These are dependent on the ability to drive real signals and so these
features might not be portable to your SoC testbench.

These features are not needed to verify Debug or Trace functionality on your SoC.

A.7.4 Trace loggers

Various loggers collect data required to verify trace results with CSCompare and
EtmCompare. These must all be ported to your SoC testbench to run trace tests on your
SoC testbench.

The CM3_ApbLogger logs all CM3 private peripheral bus accesses and reports them in
log.apb. This information is used to detect the programming of the CM3ETM and
CM3TPIU.

The CM3_AtbLogger is instantiated twice to monitor both CM3 ETM and ITM trace
buses. The log files are called log_CM3etm.atb and log_CM3itm.atb.

The ecslogger generates the log.ecs file which is a trace of Cortex-M3 core activity.

The TPIUMonitor module stores all the trace data produced by the TPIU trace port to a
file called log.tpiu. If you intend to use a physical trace port, use the TPIU monitor to
capture trace to verify your trace port implementation.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. A-15
Confidential
Example System

A.8 Modifying Tests

The test programs supplied with the Example System are designed to be used as a
starting point that is easily portable to systems with different configurations. You can
reuse these tests, modified as necessary.

A-16 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Appendix B
Revisions

This appendix describes the technical changes between released issues of this book.

Table B-1 Differences between issue D and issue E

Change Location

APB output to PPB interface removed Figure 1-1 on page 1-3

Wake-up Interrupt Controller (WIC) added

Low power interface added to bulleted lists in description of Integration options on page 1-3
integration options

WIC added to bulleted list and second note About the processor on page 1-5

Expanded description of DAPEN as key integration task Table 2-1 on page 2-3

Removal of IFLUSH, VECTADDREN, and VECTADDR

from key integration tasks description.

Removal of DAPEN from key integration tasks description

Key Cortex-M3Integration tasks updated Table 2-2 on page 2-5

PPB interface output to ABP port removed Figure 3-1 on page 3-2

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. B-1
Confidential
Revisions

Table B-1 Differences between issue D and issue E (continued)

Change Location

Removal of SLEEPING and SLEEPDEEP signals from Table 3-1 on page 3-4 and Table 3-2 on page 3-5
table of clocks and resets at the CortexM3 level.

Update of the combinations and applications of the reset Table 3-3 on page 3-6
signals

Correction to PORESETn signal connection Figure 3-3 on page 3-7

Correction to SW-DP subsection SW-DP reset on page 3-8

Addition to description of HPROTI[3:0] signal Table 3-4 on page 3-11

BRCHSTAT[2:0] changed to BRCHSTAT[3:0]

Expansion of description of HPROTD[3:0] Table 3-5 on page 3-12

Expansion of description of HPROTS[3:0] Table 3-6 on page 3-15

Connection information for PADDR[19:2] changed from Table 3-7 on page 3-18
17-bits to 18-bits

Addition of PREADY and PSLVER signals to APB

interface signals

Addition of the following signals to the list of miscellaneous Table 3-8 on page 3-19
signals:
• DBGRESTART
• DBGRESTARTED
• STKALIGNINIT.

Update to description of EDBGRQ

Update to description and connection information of

PPBLOCK[5:0]

Update of connection information for DNOTITRANS

Removal of SLEEPDEEP and SLEEPING from table of

miscellaneous interface signals

Expansion of connection information for AUXFAULT[31:0]

in table of miscellaneous interface signals

Addition of new section to describe the low power interface Low power interface signals on page 3-23

Addition of new section to describe the low power interface Low power interface on page 3-23

B-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Revisions

Table B-1 Differences between issue D and issue E (continued)

Change Location

Addition of the following signals to the list of ETM interface Table 3-11 on page 3-27
signals:
• ETMTRIGOUT
• ETMDBGRQ
• COREHALT
• ETMPWRUP
• ETMEN
• FIFOPEEK.

ATIDITM1S[6:0] and ATIDITM2S[6:0] renamed to Table 3-14 on page 3-30

ATID1S[6:0] and ATID2S[6:0]

nTRST replaced by PORESETn in list of SW-DP interface Table 3-17 on page 3-34
signals

WSE replaced by WSEIN and WSEOUT in example of Figure 4-2 on page 4-6 and Figure 4-3 on page 4-8
shadow combinational logic

Synopsys tools changed to EDA tools in Synthesis process Figure 6-1 on page 6-2
graphic.

Removal of note below Synthesis process graphic About synthesis on page 6-2

Update of bulleted information in Timing models section Timing models on page 6-3

Replacement of post layout floorplan by macroabstract for Figure 7-1 on page 7-2
size and pin positions in Physical integration process graphic

Macrocell signals extended in signal connections graphic Figure 7-2 on page 7-5

Removal of document reference, and removal of Antenna Routing restrictions on page 7-6
restrictions subsection from Routing restrictions section

Removal of the Dynamic verification section Static Timing Analysis on page 8-5

Addition of new appendix to describe the Example System Appendix A Example System

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. B-3
Confidential
Revisions

B-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
Glossary

This glossary describes some of the terms used in ARM manuals. Where terms can have
several meanings, the meaning presented here is intended.

Abort A mechanism that indicates to a core that it must halt execution of an attempted illegal
memory access. An abort can be caused by the external or internal memory system as a
result of attempting to access invalid instruction or data memory. An abort is classified
as either a Prefetch or Data Abort, and an internal or External Abort.

See also Data Abort, External Abort and Prefetch Abort.

Advanced High-performance Bus (AHB)
The AMBA Advanced High-performance Bus system connects embedded processors
such as an ARM core to high-performance peripherals, DMA controllers, on-chip
memory, and interfaces. It is a high-speed, high-bandwidth bus that supports
multi-master bus management to maximize system performance.

See also Advanced Microcontroller Bus Architecture and AHB-Lite.

Advanced Microcontroller Bus Architecture (AMBA)
AMBA is the ARM open standard for multi-master on-chip buses, capable of running
with multiple masters and slaves. It is an on-chip bus specification that details a strategy
for the interconnection and management of functional blocks that make up a
System-on-Chip (SoC). It aids in the development of embedded processors with one or

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. Glossary-1
Confidential
Glossary

more CPUs or signal processors and multiple peripherals. AMBA complements a

reusable design methodology by defining a common backbone for SoC modules. AHB
conforms to this standard.
AHB See Advanced High-performance Bus.
AHB-Lite AHB-Lite is a subset of the full AHB specification. It is intended for use in designs
where only a single AHB master is used. This can be a simple single AHB master
system or a multi-layer AHB system where there is only one AHB master on a layer.
Aligned Aligned data items are stored so that their address is divisible by the highest power of
two that divides their size. Aligned words and halfwords have addresses that are
divisible by four and two respectively. The terms word-aligned and halfword-aligned
therefore stipulate addresses that are divisible by four and two respectively. Other
related terms are defined similarly.
AMBA See Advanced Microcontroller Bus Architecture.
Architecture The organization of hardware or software that characterizes a processor and its attached
components, and enables devices with similar characteristics to be grouped together
when describing their behavior, for example, Harvard architecture, instruction set
architecture, ARMv6 architecture.
ARM instruction A word that specifies an operation for an ARM processor to perform. ARM instructions
must be word-aligned.
ATPG See Automatic Test Pattern Generation.
Automatic Test Pattern Generation (ATPG)
The process of automatically generating manufacturing test vectors for an ASIC design,
using a specialized software tool.
Byte An 8-bit data item.
Cold reset Also known as power-on reset. Starting the processor by turning power-on. Turning
power off and then back on again clears main memory and many internal settings. Some
program failures can lock up the processor and require a cold reset to enable the system
to be used again. In other cases, only a warm reset is required.

See also Warm reset.

Core A core is that part of a processor that contains the ALU, the datapath, the
general-purpose registers, the Program Counter, and the instruction decode and control
circuitry.
Core reset See Warm reset.

Glossary-2 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Glossary

Data Abort An indication from a memory system to a core that it must halt execution of an
attempted illegal memory access. A Data Abort is attempting to access invalid data
memory.

See also Abort, External Abort, and Prefetch Abort.

Debugger A debugging system that includes a program, used to detect, locate, and correct software
faults, together with custom hardware that supports software debugging.
Design Simulation Model (DSM)
A functional simulation model of the device that is derived from the Register Transfer
Level (RTL) but which does not reveal its internal structure. The DSM does not model
any features added during synthesis such as internal scan chains.
DSM See Design Simulation Model.
EmbeddedICE logic An on-chip logic block that provides TAP-based debug support for ARM processor
cores. It is accessed through the TAP controller on the ARM core using the JTAG
interface.
Embedded Trace Macrocell (ETM)
A hardware macrocell that, when connected to a processor core, outputs instruction and
data trace information on a trace port. The ETM provides processor driven trace through
a trace port compliant to the ATB protocol.
Endianness Byte ordering. The scheme that determines the order in which successive bytes of a data
word are stored in memory. An aspect of the system’s memory mapping.
ETM See Embedded Trace Macrocell.
Exception A fault or error event that is considered serious enough to require that program
execution is interrupted. Examples include attempting to perform an invalid memory
access, external interrupts, and undefined instructions. When an exception occurs,
normal program flow is interrupted and execution is resumed at the corresponding
exception vector. This contains the first instruction of the interrupt handler to deal with
the exception.
Exception vector See Interrupt vector.
External Abort An indication from an external memory system to a core that it must halt execution of
an attempted illegal memory access. An External Abort is caused by the external
memory system as a result of attempting to access invalid memory.

See also Abort, Data Abort and Prefetch Abort.

Halfword A 16-bit data item.
Host A computer that provides data and other services to another computer. Especially, a
computer providing debugging services to a target being debugged.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. Glossary-3
Confidential
Glossary

Internal scan chain A series of registers connected together to form a path through a device, used during
production testing to import test patterns into internal nodes of the device and export the
resulting values.
Joint Test Action Group (JTAG)
The name of the organization that developed standard IEEE 1149.1. This standard
defines a boundary-scan architecture used for in-circuit testing of integrated circuit
devices. It is commonly known by the initials JTAG.
JTAG See Joint Test Action Group.
Macrocell A complex logic block with a defined interface and behavior. A typical VLSI system
comprises several macrocells (such as a processor, an ETM, and a memory block) plus
application-specific logic.
Memory Protection Unit (MPU)
Hardware that controls access permissions to blocks of memory. Unlike an MMU, an
MPU does not translate virtual addresses to physical addresses.
Microprocessor See Processor.
MPU See Memory Protection Unit.
Power-on reset See Cold reset.
Processor A processor is the circuitry in a computer system required to process data using the
computer instructions. It is an abbreviation of microprocessor. A clock source, power
supplies, and main memory are also required to create a minimum complete working
computer system.
Read Reads are defined as memory operations that have the semantics of a load. That is, the
ARM instructions LDM, LDRD, LDR, LDRT, LDRSH, LDRH, LDRSB, LDRB,
LDRBT, LDREX, RFE, STREX, SWP, and SWPB, and the Thumb instructions LDM,
LDR, LDRSH, LDRH, LDRSB, LDRB, and POP.
RealView ICE A system for debugging embedded processor cores using a JTAG interface.
Region A partition of instruction or data memory space.
Reserved A field in a control register or instruction format is reserved if the field is to be defined
by the implementation, or produces Unpredictable results if the contents of the field are
not zero. These fields are reserved for use in future extensions of the architecture or are
implementation-specific. All reserved bits not used by the implementation must be
written as 0 and read as 0.

Glossary-4 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential
 Glossary

Scan chain A scan chain is made up of serially-connected devices that implement boundary scan
technology using a standard JTAG TAP interface. Each device contains at least one TAP
controller containing shift registers that form the chain connected between TDI and
TDO, through which test data is shifted. Processors can contain several shift registers
to enable you to access selected parts of the device.
SCREG The currently selected scan chain number in an ARM TAP controller.
SDF See Standard Delay Format.
Standard Delay Format (SDF)
The format of a file that contains timing information to the level of individual bits of
buses and is used in SDF back-annotation. An SDF file can be generated in a number
of ways, but most commonly from a delay calculator.
TAP See Test access port.
Test Access Port (TAP)
The collection of four mandatory and one optional terminals that form the input/output
and control interface to a JTAG boundary-scan architecture. The mandatory terminals
are TDI, TDO, TMS, and TCK. The optional terminal is TRST. This signal is
mandatory in ARM cores because it is used to reset the debug logic.
Thumb instruction A halfword that specifies an operation for an ARM processor in Thumb state to
perform. Thumb instructions must be halfword-aligned.
Thumb state A processor that is executing Thumb (16-bit) halfword aligned instructions is operating
in Thumb state.
TPA See Trace Port Analyzer.
Trace hardware A term for a device that contains an Embedded Trace Macrocell.
Undefined Indicates an instruction that generates an Undefined instruction trap. See the ARM
Architecture Reference Manual for more details on ARM exceptions.
UNP See Unpredictable.
Unpredictable For reads, the data returned when reading from this location is unpredictable. It can have
any value. For writes, writing to this location causes unpredictable behavior, or an
unpredictable change in device configuration. Unpredictable instructions must not halt
or hang the processor, or any part of the system.
Warm reset Also known as a core reset. Initializes the majority of the processor excluding the debug
controller and debug logic. This type of reset is useful if you are using the debugging
features of a processor.

ARM DII 0113E Copyright © 2005-2008 ARM Limited. All rights reserved. Glossary-5
Confidential
Glossary

Watchpoint A watchpoint is a mechanism provided by debuggers to halt program execution when

the data contained by a particular memory address is changed. Watchpoints are inserted
by the programmer to enable inspection of register contents, memory locations, and
variable values when memory is written to test that the program is operating correctly.
Watchpoints are removed after the program is successfully tested. See also Breakpoint.
Word A 32-bit data item.
Write Writes are defined as operations that have the semantics of a store. That is, the ARM
instructions SRS, STM, STRD, STRT, STRH, STRB, STRBT, STREX, SWP, and
SWPB, and the Thumb instructions STM, STR, STRH, STRB, and PUSH.

Glossary-6 Copyright © 2005-2008 ARM Limited. All rights reserved. ARM DII 0113E
Confidential