DIT0034H Cortex m7 r1p2 Iim

Arm Cortex -M7 Processor
® ®
Revision: r1p2
Integration and Implementation Manual

Confidential
Copyright © 2014-2016, 2018 Arm Limited. All rights reserved.

ARM DIT 0034H (ID111518)
Arm Cortex-M7 Processor
Integration and Implementation Manual
Copyright © 2014-2016, 2018 Arm Limited. All rights reserved.

Release Information
The following changes have been made to this book.
Change History
Date Issue Confidentiality Change
28 April 2014 A Confidential First release for r0p0
05 December 2014 B Confidential First release for r0p2
19 March 2015 C Confidential First release for r1p0
07 July 2015 D Confidential First release for r1p1
27 January 2016 E Confidential Second release for r1p1
22 August 2016 F Confidential Third release for r1p1
17 November 2016 G Confidential Fourth release for r1p1
15 November 2018 H Confidential First release for r1p2
Proprietary Notice
This document is protected by copyright and other related rights and the practice or implementation of the information
contained in this document may be protected by one or more patents or pending patent applications. No part of this
document may be reproduced in any form by any means without the express prior written permission of Arm. No
license, express or implied, by estoppel or otherwise to any intellectual property rights is granted by this document
unless specifically stated.
Your access to the information in this document is conditional upon your acceptance that you will not use or permit
others to use the information for the purposes of determining whether implementations infringe any third party patents.
THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS
FOR A PARTICULAR PURPOSE WITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, Arm makes
no representation with respect to, and has undertaken no analysis to identify or understand the scope and content of,
third party patents, copyrights, trade secrets, or other rights.
This document may include technical inaccuracies or typographical errors.
TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES,
INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR
CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,
ARISING OUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or
disclosure of this document complies fully with any relevant export laws and regulations to assure that this document
or any portion thereof is not exported, directly or indirectly, in violation of such export laws. Use of the word “partner”
in reference to Arm’s customers is not intended to create or refer to any partnership relationship with any other company.
Arm may make changes to this document at any time and without notice.
If any of the provisions contained in these terms conflict with any of the provisions of any signed written agreement
covering this document with Arm, then the signed written agreement prevails over and supersedes the conflicting
provisions of these terms. This document may be translated into other languages for convenience, and you agree that if
there is any conflict between the English version of this document and any translation, the terms of the English version
of the Agreement shall prevail.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. ii
ID111518 Confidential
Words and logos marked with ® or ™ are registered trademarks or trademarks of Arm Limited or its affiliates in the EU
and/or elsewhere. All rights reserved. Other brands and names mentioned in this document may be the trademarks of
their respective owners. Please follow Arm’s trademark usage guidelines at
http://www.arm.com/about/trademark-usage-guidelines.php
Copyright © 2014-2015, 2018 Arm Limited or its affiliates. All rights reserved.
Arm Limited. Company 02557590 registered in England.
110 Fulbourn Road, Cambridge, England CB1 9NJ.
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.
Web Address
http://www.arm.com
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. iii
Contents
Arm Cortex-M7 Processor Integration and
Implementation Manual
Preface
About this book ........................................................................................................... ix
Feedback .................................................................................................................. xiv
Chapter 1 Introduction
1.1 About the processor ................................................................................................. 1-2
1.2 About implementation and integration ..................................................................... 1-4
1.3 About sign-off ........................................................................................................... 1-8
1.4 Reference data ........................................................................................................ 1-9
Chapter 2 Configuration Guidelines

2.1 About configuration guidelines ................................................................................. 2-2
2.2 Configuration options ............................................................................................... 2-3
Chapter 3 Key Integration Points

3.1 About key integration points .................................................................................... 3-2
3.2 Key integration tasks ............................................................................................... 3-3
Chapter 4 Functional Integration Guidelines

4.1 About functional integration ..................................................................................... 4-3
4.2 Speculative accesses .............................................................................................. 4-4
4.3 Clocking and resets ................................................................................................. 4-6
4.4 TCM interface ........................................................................................................ 4-10
4.5 AXI master interface .............................................................................................. 4-11
4.6 AHB peripheral interface ........................................................................................ 4-17
4.7 AHB slave interface ............................................................................................... 4-20
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. iv
Contents
4.8 AHB debug interface .............................................................................................. 4-25

4.9 External Private Peripheral Bus ............................................................................. 4-30
4.10 ITM interface .......................................................................................................... 4-31
4.11 ETM instruction trace interface .............................................................................. 4-32
4.12 ETM data trace interface ....................................................................................... 4-33
4.13 Debug signals ........................................................................................................ 4-34
4.14 Interrupt interface ................................................................................................... 4-36
4.15 Miscellaneous signals ............................................................................................ 4-37
4.16 FPU exception signals ........................................................................................... 4-38
4.17 Configuration ......................................................................................................... 4-39
4.18 Events and errors .................................................................................................. 4-42
4.19 Power control and sleep interface ......................................................................... 4-44
4.20 SysTick signals ...................................................................................................... 4-46
4.21 Dual-redundant core comparison interface ............................................................ 4-48
4.22 Test interfaces ....................................................................................................... 4-49
4.23 CoreSight system integration ................................................................................. 4-50
Chapter 5 TCM Integration

5.1 About TCM integration ............................................................................................. 5-2
5.2 TCM interface .......................................................................................................... 5-4
5.3 Supported TCM RAM integration flow ..................................................................... 5-8
5.4 TCM organization and configuration ........................................................................ 5-9
5.5 TCM interface protocol .......................................................................................... 5-10
5.6 Integrating TCM RAM blocks ................................................................................. 5-14
5.7 TCM RAM integration testbench ............................................................................ 5-16
Chapter 6 DFT Integration Guidelines

6.1 About DFT integration .............................................................................................. 6-2
6.2 ATPG Test Interface ................................................................................................ 6-3
6.3 MBIST Information format files ................................................................................ 6-5
6.4 MBIST Interface ....................................................................................................... 6-7
Chapter 7 Key Implementation Points

7.1 About key implementation points ............................................................................. 7-2
7.2 Key implementation tasks ........................................................................................ 7-3
7.3 Other considerations for implementation ................................................................. 7-4
Chapter 8 Cache RAM Integration

8.1 About cache RAM integration .................................................................................. 8-2
8.2 Resource requirements for memory integration ...................................................... 8-3
8.3 Controls and constraints for memory integration ..................................................... 8-4
8.4 Blocks for memory integration ................................................................................. 8-5
8.5 Flow for memory integration .................................................................................... 8-8
8.6 Confirming memory integration .............................................................................. 8-16
8.7 Outputs from memory integration .......................................................................... 8-17
8.8 Solving memory integration problems ................................................................... 8-18
8.9 Reference data for memory integration ................................................................. 8-19
Chapter 9 Floorplan Guidelines

9.1 About floorplanning .................................................................................................. 9-2
9.2 Resource requirements for floorplans ...................................................................... 9-3
9.3 Controls and constraints for floorplans .................................................................... 9-4
9.4 Inputs for floorplans ................................................................................................. 9-5
9.5 Considerations for floorplans ................................................................................... 9-6
9.6 Reference data for floorplans .................................................................................. 9-8
Chapter 10 Netlist Dynamic Verification

10.1 Netlist dynamic verification .................................................................................... 10-2
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. v
Contents
Chapter 11 Sign-off
11.1 About sign-off ......................................................................................................... 11-2
11.2 Obligations for sign-off ........................................................................................... 11-3
11.3 Criteria for sign-off ................................................................................................. 11-4
11.4 Steps for sign-off .................................................................................................... 11-5
11.5 Completion of sign-off ............................................................................................ 11-6
Chapter 12 Integration Kit

12.1 About the IK ........................................................................................................... 12-2
12.2 Cortex-M7 processor IK flow ................................................................................. 12-4
12.3 Test overview ......................................................................................................... 12-5
12.4 Configuring the testbench ...................................................................................... 12-7
12.5 Configuring the IK RTL .......................................................................................... 12-9
12.6 Configuring and compiling tests ........................................................................... 12-11
12.7 Running the testbench ......................................................................................... 12-16
12.8 Measure power consumption ............................................................................... 12-19
12.9 Debugging failing tests ........................................................................................ 12-21
12.10 Modifying the IK RTL for your SoC ...................................................................... 12-23
12.11 IK components ..................................................................................................... 12-28
12.12 About GPIO Integration ....................................................................................... 12-31
12.13 Debug driver ........................................................................................................ 12-35
12.14 Modifying IK tests ................................................................................................ 12-37
Chapter 13 Low-power Integration

13.1 About low-power integration .................................................................................. 13-2
13.2 Processor operation in sleep mode ....................................................................... 13-3
13.3 System requirements for low-power states ............................................................ 13-4
13.4 Sleep-hold interface ............................................................................................... 13-5
13.5 Supported sleep modes ......................................................................................... 13-6
Chapter 14 Power Intent

14.1 About Cortex-M7 processor power intent .............................................................. 14-2
14.2 Communications to an external power management unit ...................................... 14-4
14.3 ETM power control ................................................................................................. 14-5
14.4 Power intent retention sequence ........................................................................... 14-6
14.5 Power intent specification ...................................................................................... 14-7
14.6 Rendering UPF constraints .................................................................................... 14-8
14.7 Power states and clamping values ........................................................................ 14-9
Chapter 15 DSM Generation

15.1 About DSM generation .......................................................................................... 15-2
15.2 Prerequisites .......................................................................................................... 15-3
15.3 Building and testing a DSM model ......................................................................... 15-5
15.4 DSM generation script command line options ....................................................... 15-6
15.5 Command line examples ....................................................................................... 15-7
15.6 If DSM generation fails .......................................................................................... 15-8
15.7 Generation directory structure ............................................................................... 15-9
15.8 Deliverable directory structure ............................................................................. 15-10
Appendix A GPIO Programmers Model

A.1 About the GPIO programmers model ...................................................................... A-2
Appendix B CoreSight SoC

B.1 Location of the Cortex-M7 processor CoreSight SoC-400 support files .................. B-2
B.2 Comparing captured trace to the trace reference file .............................................. B-3
Appendix C AXI4 to AHB-Lite Bridge

C.1 About the AAB ......................................................................................................... C-2
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. vi
Contents
C.2 AAB behavior ........................................................................................................... C-4

C.3 Configuration options ............................................................................................... C-9
C.4 Interface assertions .............................................................................................. C-10
C.5 AAB interfaces ....................................................................................................... C-11
C.6 Clocking and resets ............................................................................................... C-16
Appendix D Cortex-M7 Debug Access Port

D.1 About the Debug Access Port .................................................................................. D-2
D.2 Functional description .............................................................................................. D-4
D.3 DAP register summary ............................................................................................. D-5
D.4 DAP register descriptions ........................................................................................ D-7
D.5 Debug Access Port signals .................................................................................... D-22
Appendix E Signal Timing Constraints

E.1 About signal timing constraints ................................................................................ E-3
E.2 Clock enable and reset signal constraints ............................................................... E-4
E.3 Configuration and initialization signal timing constraints ......................................... E-5
E.4 ITCM interface timing constraints ............................................................................ E-6
E.5 D0TCM and D1TCM interface timing constraints .................................................... E-7
E.6 AXI master interface timing constraints ................................................................... E-8
E.7 AHB peripheral interface timing constraints ........................................................... E-10
E.8 AHB slave interface timing constraints .................................................................. E-11
E.9 AHB debug interface timing constraints ................................................................. E-12
E.10 External private peripheral bus timing constraints ................................................. E-13
E.11 Sleep control interface timing constraints .............................................................. E-14
E.12 WIC interface timing constraints ............................................................................ E-15
E.13 ITM interface timing constraints ............................................................................. E-16
E.14 ETM instruction trace interface timing constraints ................................................. E-17
E.15 ETM data trace interface timing constraints .......................................................... E-18
E.16 Trace synchronization interface timing constraints ................................................ E-19
E.17 Interrupts and events signal timing constraints ...................................................... E-20
E.18 Debug signals timing constraints ........................................................................... E-21
E.19 Cross trigger interface timing constraints .............................................................. E-22
E.20 Miscellaneous signals timing constraints ............................................................... E-23
E.21 FPU signal timing constraints ................................................................................ E-24
E.22 MBIST interface timing constraints ........................................................................ E-25
E.23 Dual-redundant core comparison interface timing constraints ............................... E-26
E.24 DFT interface timing constraints ............................................................................ E-27
Appendix F Tarmac Tracing

F.1 About tarmac trace .................................................................................................. F-2
F.2 Setting up the resource requirements for tarmac trace ........................................... F-3
F.3 Running simulation .................................................................................................. F-4
F.4 Tarmac variables ..................................................................................................... F-5
F.5 Controlling tarmac generation .................................................................................. F-6
Appendix G CORTEXM7INTEGRATIONMCU
G.1 About CORTEXM7INTEGRATIONMCU .................................................................. G-2
G.2 Configuring the CORTEXM7INTEGRATIONMCU level .......................................... G-3
G.3 CORTEXM7INTEGRATIONMCU port list ............................................................... G-4
Appendix H IP-XACT
H.1 About IP-XACT for Cortex-M7 processor ................................................................ H-2
H.2 Location of the IP-XACT description file .................................................................. H-3
H.3 Generating the IP-XACT description ....................................................................... H-4
H.4 Using the IP-XACT description ................................................................................ H-5
Appendix I Revisions
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. vii
Preface
This preface introduces the Cortex®-M7 Processor Integration and Implementation Manual
(IIM). It contains the following sections:
• About this book on page ix.
• Feedback on page xiv.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. viii
Preface
About this book

This book is for the Cortex-M7 processor.
Implementation obligations
This book is designed to help you implement an Arm® product. The extent to which the
deliverables can be modified or disclosed is governed by the contract between Arm and the
Licensee. There might be validation requirements which, if applicable, are detailed in the
contract between Arm and the Licensee and which, if present, must be complied with prior to
the distribution of any devices incorporating the technology described in this document.
Reproduction of this document is only permitted in accordance with the licenses granted to the
Licensee.
Arm assumes no liability for your overall system design and performance. Verification
procedures defined by Arm are only intended to verify the correct implementation of the
technology licensed by Arm, and are not intended to test the functionality or performance of the
overall system. You or the Licensee are responsible for performing system level tests.
You are responsible for applications that are used in conjunction with the Arm technology
described in this document, and to minimize risks, adequate design and operating safeguards
must be provided for by you. Publishing information by Arm in this book of information
regarding third party products or services is not an express or implied approval or endorsement
of the use thereof.
Product revision status
The rmpn identifier indicates the revision status of the product described in this book, for
example, r1p2, where:
rm Identifies the major revision of the product, for example, r1.
pn Identifies the minor revision or modification status of the product, for example,
p2.
Intended audience
This book is written for experienced hardware and System-on-Chip (SoC) engineers who might
or might not have experience with Arm products. Such engineers typically have experience of
writing Verilog and of performing synthesis, but might have limited experience of integrating
and implementing Arm products.
Using this book
This book is organized into the following chapters:
Chapter 1 Introduction
Read this for an overview of the process of integrating and implementing the
Cortex-M7 processor.
Chapter 2 Configuration Guidelines

Read this for a description of the configuration options that you must be aware of
before implementing the Cortex-M7 processor into your System-on-Chip (SoC)
design.
Chapter 3 Key Integration Points

Read this for a description of the key integration points you must consider when
you integrate the Cortex-M7 processor into your SoC design.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. ix
Preface
Chapter 4 Functional Integration Guidelines

Read this for a description of the guidelines for functional integration of the
processor in your SoC design.
Chapter 5 TCM Integration

Read this for a description of how to integrate Tightly-Coupled Memory (TCM)
blocks with your Cortex-M7 processor.
Chapter 6 DFT Integration Guidelines

Read this for a description of the Design For Test (DFT) features of the processor.
Chapter 7 Key Implementation Points

Read this for a description of the key points that you must consider when you
implement the Cortex-M7 processor.
Chapter 8 Cache RAM Integration

Read this for a description of how to integrate cache RAM blocks inside your
Chapter 9 Floorplan Guidelines

Read this for a description of the floorplan used as a starting point for your design.
Chapter 10 Netlist Dynamic Verification

Read this for a description of how to use test vectors to verify the functionality of
your implementation of the processor.
Chapter 11 Sign-off
Read this for a description of the sign-off criteria for your implementation.
Chapter 12 Integration Kit

Read this for a description of the integration kit.
Chapter 13 Low-power Integration

Read this for a description of how to use the low-power features of the Cortex-M7
processor in your system.
Chapter 14 Power Intent

Read this for a description of how to use the optional power gating features of the
Chapter 15 DSM Generation

Read this for a description of the Design Simulation Model (DSM).
Appendix A GPIO Programmers Model

Read this for a description of the General Purpose Input/Output (GPIO)
programmers model.
Appendix B CoreSight SoC

Read this for a description of the CoreSight SoC.
Appendix C AXI4 to AHB-Lite Bridge

Read this for a description of the AHB bridge.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. x
Preface
Appendix D Cortex-M7 Debug Access Port

Read this for a description of the Cortex-M7 processor Debug Access Port
(DAP).
Appendix E Signal Timing Constraints

Read this for a description of the signal timing constraints that must be applied
when you implement the Cortex-M7 processor.
Appendix F Tarmac Tracing

Read this for a description of how to generate a tarmac trace file during a
simulation that traces program execution of a Cortex-M7 processor.
Appendix G CORTEXM7INTEGRATIONMCU
Read this for a description of the CORTEXM7INTEGRATIONMCU.
Appendix H IP-XACT
Read this for a description of how you can configure an IP-XACT description of
the processor.
Appendix I Revisions
Read this for a list of the technical changes between released issues of this book.
Glossary
The Arm® Glossary is a list of terms used in Arm documentation, together with definitions for
those terms. The Arm® Glossary does not contain terms that are industry standard unless the
Arm meaning differs from the generally accepted meaning.
See Arm® Glossary, http://infocenter.arm.com/help/topic/com.arm.doc.aeg0014-/index.html.
Conventions
This book uses the conventions that are described in:

• Typographical conventions.
• Timing diagrams on page xii.
• Signals on page xii.
Typographical conventions
The following table describes the typographical conventions:
Typographical conventions
Style Purpose
italic Introduces special terminology, denotes cross-references, and citations.
bold Highlights interface elements, such as menu names. Denotes 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.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. xi
Preface
Typographical conventions (continued)
Style Purpose
monospace bold Denotes language keywords when used outside example code.
<and> Encloses replaceable terms for assembler syntax where they appear in code or code fragments. For example:
MRC p15, 0 <Rd>, <CRn>, <CRm>, <Opcode_2>
SMALL CAPITALS Used in body text for a few terms that have specific technical meanings, that are defined in the Arm® Glossary.
For example, IMPLEMENTATION DEFINED, IMPLEMENTATION SPECIFIC, UNKNOWN, and UNPREDICTABLE.
Timing diagrams
The figure Key to timing diagram conventions 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.
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
Timing diagrams sometimes show single-bit signals as HIGH and LOW at the same time and
they look similar to the bus change shown in Key to timing diagram conventions. If a timing
diagram shows a single-bit signal in this way then its value does not affect the accompanying
description.
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.
Additional reading
This section lists publications by Arm and by third parties.
See Infocenter, http://infocenter.arm.com, for access to Arm documentation.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. xii
Preface
See on Arm, www.arm.com/cmsis, for embedded software development resources including the
Cortex® Microcontroller Software Interface Standard (CMSIS).
Arm publications
This book contains information that is specific to this product. See the following documents for
other relevant information:
• Arm® Cortex®-M7 Processor Technical Reference Manual (Arm DDI 0439).
• Arm® CoreSight™ ETM-M7 Technical Reference Manual (Arm DDI 0494).
• Arm® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2 (Arm IHI 0031).
• Arm® Embedded Trace Macrocell Architecture Specification (Arm IHI 0014).
• Arm® AMBA® 3 AHB-Lite Protocol (v1.0) Specification (Arm IHI 0033).
• Arm® AMBA® AXI and ACE Protocol Specification AXI3, AXI4, and AXI4-Lite, ACE and
ACE-Lite (Arm IHI 0022).
• Arm® AMBA® 3 APB Protocol Specification (Arm IHI 0024).
• Arm® AMBA® 4 ATB Protocol Specification (Arm IHI 0032).
• Arm® CoreSight™ Architecture Specification (v2.0) (Arm IHI 0029).
• Arm® CoreSight™ SoC-400 Technical Reference Manual (Arm DDI 0480).
• Arm® CoreSight™ SoC-400 User Guide (Arm DUI 0563).
• Arm® CoreSight™ Components Technical Reference Manual (Arm DDI 0314).
• Arm®v7-M Architecture Reference Manual (Arm DDI 0403).
• Arm® Cortex®-M7 MCU Release Note (AT610-DC-06003).
• Arm® Cortex®-M7 Processor Safety Manual (Arm 100125).
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. xiii
Preface
Feedback
Arm welcomes feedback on this product and its documentation.
Feedback on this product
If you have any comments or suggestions about this product, contact your supplier and give:
• The product name.
• The product revision or version.
• An explanation with as much information as you can provide. Include symptoms and
diagnostic procedures if appropriate.
Feedback on content
If you have comments on content then send an e-mail to [email protected]. Give:

• The title.
• The number, ARM DIT 0034H.
• The page numbers to which your comments apply.
• A concise explanation of your comments.
Arm also welcomes general suggestions for additions and improvements.
Note
Arm tests the PDF only in Adobe Acrobat and Acrobat Reader, and cannot guarantee the quality
of the represented document when used with any other PDF reader.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. xiv
Chapter 1
Introduction
This chapter provides an overview of the process of integrating and implementing the
Cortex-M7 processor. It contains the following sections:
• About the processor on page 1-2.
• About implementation and integration on page 1-4.
• About sign-off on page 1-8.
• Reference data on page 1-9.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. 1-1
Introduction
1.1 About the processor

The Cortex-M7 processor is a high performance, low gate count, highly configurable and energy
efficient processor that is intended for microcontroller and embedded applications that require
an efficient mix of control capability and signal processing instructions.
The Cortex-M7 processor top-level module name is CORTEXM7INTEGRATIONCS located in the

CORTEXM7INTEGRATIONCS.v file in the logical/cortexm7_integration/verilog directory.
Note
The CORTEXM7INTEGRATIONCS module is also referred to as the processor or Cortex-M7 processor
in this book.
This document explains how to integrate and implement the CORTEXM7INTEGRATIONCS module into
your system. The CORTEXM7INTEGRATIONCS module contains the following main blocks:
• The CORTEXM7 processor core.
• An optional ETM-M7. The ETM-M7 is licensed and delivered separately from the processor.
See Arm® CoreSight™ ETM-M7 Technical Reference Manual.
• An optional Wake-up Interrupt Controller (WIC).
• An optional Cross Trigger Interface (CTI).
• The Cortex-M7 processor ROM table that identifies the components in

CORTEXM7INTEGRATIONCS.
Figure 1-1 shows a block diagram of the CORTEXM7INTEGRATIONCS including the main interfaces.
Debugger Cross trigger
CORTEXM7INTEGRATIONCS
AHBD
CORTEXM7 processor core CTI‡

WIC‡
Interrupts Cache RAMs‡

Peripherals AHBP
D0TCM ETM-M7‡
Tightly-Coupled
D1TCM
Memory
ITCM FPU‡
DMA AHBS
MBIST
Processor ROM table
External Instruction Data

‡
Optional component. Resets
PPB trace trace
Clocks AXI Instrumentation

master trace
Figure 1-1 CORTEXM7INTEGRATIONCS block diagram
Introduction
The CORTEXM7INTEGRATIONCS is confgurable by setting parameters in the

CORTEXM7INTEGRATIONCS_CONFIG.v file, see Table 2-1 on page 2-3.
Note
• You must not modify CORTEXM7INTEGRATIONCS.v, CORTEXM7.v, or any other file unless
directed to do so.
• You must not instantiate the CORTEXM7 module directly in your system.
Figure 1-2 shows an example system integration of the CORTEXM7INTEGRATIONCS module, with a
minimal debug and trace implementation.
ITCM D1TCM D0TCM

DMA controller RAM RAM RAM
AHBS ITCM D1TCM D0TCM
AXIM AHBP Instrumentation Instruction

trace trace EPPB AHBD
AXI interconnect AHB interconnect Trace Port System ROM

DAP DP
Interface Unit table
SRAM DRAM
controller controller Peripheral GPIO
Trace port interface Debugger
Figure 1-2 Example system integration of CORTEXM7INTEGRATIONCS
Included in the Cortex-M7 processor deliverables is an example integration of the processor in

a minimal debug system, called the CORTEXM7INTEGRATIONMCU, see Appendix G
CORTEXM7INTEGRATIONMCU. This module is used in the integration kit, see Chapter 12
Integration Kit.
Introduction
1.2 About implementation and integration

The flow that you use to integrate the processor into your SoC depends on your preferred usage
model. You can first implement the processor on its own and then integrate it into your system.
Alternatively you can integrate the processor first before implementing your system and the
processor together.
Figure 1-3 shows the recommended implementation and integration flow, assuming that you
first implement the Cortex-M7 processor and then integrate the implemented processor into
your system.
Start
Configure
deliverables
Verify
configuration
Integrate RAM
Verify RAM
integration
Generate DSM Implement from

(optional) RTL to netlist
Integrate into SoC
Verify SoC
integration
Sign-off
End
Figure 1-3 Implementation and integration flow
Figure 1-4 on page 1-5 shows the integration and implementation flow when you first integrate
the Cortex-M7 processor into your system and then implement your system.
Introduction
Start
Configure
deliverables
Verify
configuration
Integrate RAM
Verify RAM
integration
Integrate into SoC

Generate DSM
(optional)
Verify SoC
integration
Implement from
RTL to netlist
Sign-off
End
Figure 1-4 Integration and implementation flow
1.2.1 Integration
Integration is the process of including the processor in your SoC design.
Integration involves:
• Connecting the required clocks and resets to the processor.
• Connecting the processor to all the necessary peripherals and buses.
• Connecting the processor to the DFT logic in your SoC design.
• Tying off configuration and any unused input signals.
• Verifying the processor within your SoC design.
Although you might have additional elements in your design, the main connections are the:
• AHB-Lite peripheral master interface.
• AHB-Lite slave DMA interface.
• AHB-Lite slave debug interface.
• AXI master interface.
• Tightly-coupled memory interfaces.
• APB peripheral master interface.
• ATB trace master interfaces.
1.2.2 Implementation
Figure 1-5 on page 1-6 shows the top-level inputs, resources, outputs, and controls and
constraints for implementation.
Introduction
Controls and constraints:

Contractual requirements
RTL configuration
Performance requirements
Inputs: Outputs:
RTL Models
Implementation
Hand-instantiated clock gating and clock domain crossing cell models Post-layout netlist
RAMs Reports and logs
Resources:
EDA tools
Testbenches
Scripts
Documentation
Figure 1-5 Implementation process
For an overview of the implementation process, see:

• Implementation resources.
• Implementation controls and constraints.
• Implementation inputs.
• Implementation outputs.
• Implementation flow on page 1-7.
For information on the deliverables, see Reference data on page 1-9.
Implementation resources
This book assumes that you have suitable EDA tools and computer resources for
implementation. See the Arm® Cortex®-M7 MCU Release Note for a list of deliverables and any
specific tool revisions required for implementation.
Implementation controls and constraints
Figure 1-5 shows the general controls and constraints that apply to the implementation. You
must implement the device in accordance with your contract, see Implementation obligations on
page ix.
Implementation inputs
The Arm® Cortex®-M7 MCU Release Note describes the deliverables that are inputs to the
implementation flow. These deliverables include:
• RTL code.
• Implementation scripts.
• Documentation.
Implementation outputs
The outputs from the implementation flow are:
• Logs and reports:

— Synthesis logs and reports.
— Post-layout Static Timing Analysis (STA) logs and reports.
Introduction
— Logs and reports showing logical equivalence of post-layout netlist with

implemented RTL.
• Components:
— Post-layout netlist.
— Standard Delay Format (SDF).
• Test:
— Automatic Test Pattern Generation (ATPG) vectors.
1.2.3 Implementation flow
Figure 1-6 shows the implementation flow.
Start
Configure RTL
Instantiate special purpose cells

for clock gating and CDC
Perform logical synthesis
Perform floorplanning
Perform physical synthesis
Perform CTS and routing
Perform STA
Perform RTL-to-placed-gates
Optional - Replay test vectors
equivalence checking
Optional - Extract timing model
Production test
Sign-off
Complete
Figure 1-6 Implementation flow
Note
For information on contractual obligations to complete sign-off as part of the complete flow, see
Chapter 11 Sign-off and the Cortex®-M7 Implementation Reference Methodology
documentation.
Introduction
1.3 About sign-off

In addition to your normal sign-off checks, you must satisfy certain verification criteria before
you sign off the design, see Chapter 11 Sign-off for more information.
Introduction
1.4 Reference data

Before starting, you must ensure the unpacked deliverables are located in the correct directory
structure. Figure 1-7 shows the directory structure when you unpack the deliverables.
ARM_Cortex-M7-<version>-<quality>_ReleaseNote.pdf
CoreSight_ETM-M7-<version>-<quality>_ReleaseNote.pdf
cortexm7/
documentation/
implementation_<foundry>_<process>/
logical/
cm7aab/ cm7tpiu/
verilog/ verilog/
cm7biu/ cortexm7/
verilog/ verilog/
cm7cti/ cortexm7_integration/
verilog/ dsm/
cm7core/ mbist_info_files/
verilog/ verilog/
cm7dap/ ipxact/
verilog/ †
csetmm7/
cm7dcu/ verilog/
verilog/ models/
cm7dwt/ cells/
verilog/ generic/
cm7fpb/ rams/
verilog/ generic/
‡cm7fpu/ shared/
verilog/ tools/
cm7icu/ bin/
verilog/ ipxact/
cm7itm/ busdefs/
verilog/ tarmac/
cm7lsu/ testbench/
verilog/ execution_tb/
cm7miu/ verilog/
verilog/ example_sys/
cm7mpu/ tests/
verilog/ pre_compiled
cm7nvic/ CMSIS/
verilog/
Device/
cm7ppb/
integration_cssoc/
verilog/
shared/
cm7stb/
tarmac/
verilog/
ram_integration_tb/
cm7tcu
vector_replay_tb/
verilog/
†
When ETM is included.
‡ When FPU is included.
Figure 1-7 Release directory structure
Chapter 2
Configuration Guidelines
This chapter describes the guidelines for RTL configuration. You can configure the RTL to
tailor your implementation to the specific requirements of the target application. It contains the
following sections:
• About configuration guidelines on page 2-2.
• Configuration options on page 2-3.
2.1 About configuration guidelines

Caution
For successful configuration of the RTL you must:
• Set up the configurable options.
• Integrate the cache memory, see Chapter 8 Cache RAM Integration.
• Integrate the TCMs, see Chapter 5 TCM Integration.
Failure to complete all the necessary configuration can result in malfunction.
2.2 Configuration options

Parameters control all of the configuration options. You must either alter the default values of
the parameters in the configuration file, or override these parameters using instantiation.
The configuration method you choose depends on the integration and implementation flow that
you use. If you are implementing the processor on its own then Arm recommends that
configuration is performed using the CORTEXM7INTEGRATIONCS_CONFIG.v file in the
logical/cortexm7_integration/verilog directory. If you are implementing the processor in a
system then Arm recommends that you set the configuration parameters in the instantiation of
the processor.
Table 2-1 shows a summary of the Cortex-M7 processor configuration options.
Table 2-1 Cortex-M7 processor configuration options summary
Default Supported
Parameter Description
value values
FPU 1 0, 1, 2 Specifies whether FPU is present. The options are:

0 No FPU hardware.
1 Single-precision FPU.
2 Single- and double-precision FPU.
ICACHE 1 0, 1 Specifies whether instruction cache is implemented. The options are:

0 No instruction cache implemented.
1 Instruction cache implemented.
DCACHE 1 0, 1 Specifies whether data cache is implementeda. The options are:

0 No data cache implemented.
1 Data cache implemented.
CACHEECC 1 0, 1 Specifies whether caches support RAMs with ECC. The options are:
0 No ECC support.
1 Support for ECC for both instruction cache and data cache.
MPU 8 0, 8, 16 Specifies the number of Memory Protection Unit (MPU) regions implemented. The
options are:
0 No MPU. Default memory map applies.
8 8 region MPU.
16 16 region MPU.
IRQNUM 32 1-240 Specifies the number of implemented user interrupts. The options are:
1 IRQ[0].
2 IRQ[1:0].
...
240 IRQ[239:0].
IRQLVL 3 3-8 Specifies the number of bits of interrupt priority implemented in the NVIC. For
example a value of 3 results in 8 levels of priority, and a value of 8 results in 256 levels.
See Arm®v7-M Architecture Reference Manual.
DBGLVL 0 0, 1 Specifies the level of debug support. The options are:

0 Minimal debug. All debug units are present but the debug capability
is reduced to two Data Watchpoint and Trace (DWT) comparators
and four Flash Patch and Breakpoint (FPB) comparators.
1 Full debug with four DWT comparators and eight FPB comparators.
Full support for halting and monitor mode debug is always supported.
Table 2-1 Cortex-M7 processor configuration options summary (continued)
Default Supported
value values
TRC 1 0, 1 Specifies the level of trace support. The options are:

0 No Instrumentation Trace Macrocell (ITM) or Data Watchpoint and
Trace (DWT).
1 ITM and DWT trace.
Note
This parameter does not affect the number of DWT comparators.
ETM 1 0, 1, 2 Specifies the ETM support included in the processor. The options are:
0 No ETM support.
1 ETM instruction trace interface only supported.
2 ETM with instruction and data trace interfacesb supported.
LOCKSTEP 0 0, 1 Specifies whether the implementation is a dual-redundant core and uses lock-step. The
options are:
0 No dual-redundant core.
1 Dual-redundant core.
Note
When LOCKSTEP is 1, all flip-flops in both processor cores are initialized during reset.
CTI 0 0, 1 Specifies the CTI support included in the processor. The options are:
0 No CTI support.
1 CTI supported.
Note
Arm strongly recommends that you set the CTI parameter to 1.This provides the
highest compatibility with debug tools and maximum flexibility in your SoC debug
implementation.
RAR 0 0, 1, 2 Specifies whether all registers are reset. The options are:
0 Not all flip-flops are reset. Only flip-flops that must be initialized are
reset.
1 Resets all flip-flops, excluding those in the ETM (if implemented).
2 Resets all flip-flops, including those in the ETM (if implemented).
Note
Setting this parameter increases the size of the registers that are not reset by default,
and therefore also increases the overall area of the implementation.
DW 0 0, 1 Specifies the use of DesignWare. The options are:

0 No DesignWare instantiated, this works for all synthesis tools.
1 Synopsis DesignWare instantiated.
WIC 1 0, 1 Specifies whether or not the WIC interface is implemented. The options are:
0 No WIC interface support.
1 WIC interface supported.
Table 2-1 Cortex-M7 processor configuration options summary (continued)
Default Supported
value values
WICLINES 35 IRQNUM+3 Makes the WIC sensitive to a configurable number of interrupts or a configurable
number of events.
The range of this parameter is 4-243. Three WIC lines are always used by the RXEV,
NMI, and EDBGRQ signals. The remaining WIC lines are used by the IRQ signals.
The minimum width of the IRQ signal is 1. See the IRQNUM parameter. The options are:
4 RXEV, NMI, EDBGRQ and IRQ[0].
5 RXEV, NMI, EDBGRQ and IRQ[1:0].
...
243 RXEV, NMI, EDBGRQ and IRQ[239:0].
Note
If you exclude the WIC interface, this parameter has no effect. See the WIC parameter
description in this table.
ICACHESIZE 16 0, 4, 8, 16, 32, 64 DSM I-cache size in KBytes. This parameter is only used for DSM generation and has
no effect on RTL simulation or implementation, see Chapter 15 DSM Generation for
details.
DCACHESIZE 16 0, 4, 8, 16, 32, 64 DSM D-cache Size in KBytes. This parameter is only used for DSM generation and
has no effect on RTL simulation or implementation, see Chapter 15 DSM Generation
for details.
a. The transaction capability and usage of the AXIM depends on whether the processor is configured with D-cache, see AXIM transaction
issuing capability on page 4-11 for more information.
b. Use this parameter value when you want to support data trace. You must implement a full CoreSight subsystem to route and capture this
trace data.
Chapter 3
Key Integration Points
This chapter describes the key integration points you must consider when you integrate the
Cortex-M7 processor in your SoC design. It contains the following sections:
• About key integration points on page 3-2.
• Key integration tasks on page 3-3.
3.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 Additional reading on page xii.
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.
3.2 Key integration tasks

Table 3-1 lists the key tasks for integration.
Table 3-1 Key integration tasks
Key task Description
1. Connect the CLKIN, CLKEN, FCLKEN, and HCLKEN See Clocking and resets on page 4-6
clock and clock enable signals.
2. Connect the nPORESET, and nSYSRESET resets. See Clocking and resets on page 4-6
3. Tie off or connect the following interface inputs See Chapter 4 Functional Integration Guidelines
appropriately:
• AXI master interface.
• AHB peripheral interface.
• AHB slave interface.
• AHB debug interface.
• Interrupt interface.
• FPU signals.
• Events and error signals.
• External peripheral bus interface.
• ATB trace interfaces.
• Power control and sleep interface.
• Debug signals.
• Configuration signals.
4. Carry out TCM integration. See Chapter 5 TCM Integration
5. Verify your design using the integration kit. See Chapter 12 Integration Kit
6. CoreSight system integration. See Appendix B CoreSight SoC and Appendix G

CORTEXM7INTEGRATIONMCU
Chapter 4
Functional Integration Guidelines
This chapter describes the functional integration requirements of the macrocell in your SoC
design. It contains the following sections:
• About functional integration on page 4-3.
• Speculative accesses on page 4-4.
• Clocking and resets on page 4-6.
• TCM interface on page 4-10.
• AXI master interface on page 4-11.
• AHB peripheral interface on page 4-17.
• AHB slave interface on page 4-20.
• AHB debug interface on page 4-25.
• External Private Peripheral Bus on page 4-30.
• ITM interface on page 4-31.
• ETM instruction trace interface on page 4-32.
• ETM data trace interface on page 4-33.
• Debug signals on page 4-34.
• Interrupt interface on page 4-36.
• Miscellaneous signals on page 4-37.
• FPU exception signals on page 4-38.
• Configuration on page 4-39.
• Events and errors on page 4-42.
• Power control and sleep interface on page 4-44.
• SysTick signals on page 4-46.
• Dual-redundant core comparison interface on page 4-48.
• Test interfaces on page 4-49.

• CoreSight system integration on page 4-50.
4.1 About functional integration

This chapter contains information that you must consider before or during the integration of the
processor into your SoC design.
4.2 Speculative accesses

The Cortex-M7 processor performs speculative accesses to increase performance. Although
speculative accesses are permitted by the Armv7-M architecture, system designers should not
assume that the scope of the speculation is fixed or definitively specified.
The following list describes several examples where speculative accesses can occur:
Note
This is not a comprehensive list of cases where speculative accesses can occur.
• Speculative instruction fetches can be initiated to any Normal, executable memory

address. This can occur regardless of whether the fetched instruction gets executed or, in
rare cases, whether the memory address contains any valid program instruction.
• Speculative data reads can be initiated to any Normal, read/write, or read-only memory
address. In some rare cases, this can occur regardless of whether there is any instruction
that causes the data read.
• Speculative cache linefills can be initiated to any Cacheable memory address, and in rare
cases, regardless of whether there is any instruction that causes the cache linefill.
• Speculative reads that target a TCM region, in rare cases, can be initiated on any of the
three TCM interfaces, regardless of which TCM interface the memory region is mapped
to.
The following list describes the situations where a speculative access does not occur:
• Speculative instruction fetches are never made to memory addresses in an Execute Never
region.
• Speculative data reads are never made to memory addresses marked as non-accessible in
the MPU.
• Speculative cache linefills are never made to Non-cacheable memory addresses.
• Speculative data reads and speculative cache linefills are never made to Device or
Strongly-ordered memory addresses.
• Speculative reads are never made on the AHBP interface.
• Speculative writes are never made.
Note
Memory regions mapped to the TCM are always treated as Normal Memory and therefore are
always subject to speculation.
4.2.1 Considerations for system design
The system designer must ensure that the system is robust enough to handle speculative
accesses, and ensure that all executable and Normal type memory regions are safe to access.
Preventing speculative accesses
Speculative accesses do not cause any processor faults. The processor is aware whether an
access is speculative, and ignores any error response signalled by the system due to the
speculative access. However, the system where the processor is integrated in cannot distinguish
between speculative accesses from non-speculative accesses. Therefore, the system designer is
required to ensure that the system is robust enough to handle speculative accesses, regardless of
whether they are initiated to unexpected memory addresses.
Alternatively, if there are memory regions where no speculative accesses should be initiated to,
Arm recommends that you set those regions to have all of the following attributes with the
MPU:
• Device or Strongly-ordered.
• Execute Never.
Note
Memory regions mapped to the TCM are always treated as Normal Memory and therefore are
always subject to speculation.
Preventing accesses
The system must ensure that all executable and Normal type memory regions are safe to access.
This implies that all accesses should eventually complete.
Note
• The processor does not cancel non-speculative accesses and therefore waits for the access
to complete.
• The processor cannot guarantee that speculative accesses will get cancelled and therefore
may wait for the access to complete.
For any addresses that are not considered safe to access, Arm recommends that you either ensure
that the system returns an abort, or prevent accesses by setting those regions to have all of the
following attributes with the MPU:
• Device or Strongly-ordered.
• Non-accessible.
• Execute Never.
4.3 Clocking and resets

This section describes how to:
• Use the processor clocks in your SoC design.
• Connect and use the Cortex-M7 processor resets.
• Reset different parts of the design independently.
The processor has one input clock signal, CLKIN, and this is split into four internal clocks that
can be individually gated to reduce power consumption. The WIC is clocked directly by the
CLKIN signal.
Table 4-1 describes the internal clock signals.
Table 4-1 Cortex-M7 processor internal clocks
Clock gate
Clock Description
control signal
fclk This is the clock for a small part of the logic that must be kept running when the processor is in FCLKEN
the fastest wake-up low-power sleep mode. It clocks the SysTick and NVIC logic. When using the
WIC to wake-up the processor, you can gate fclk.
clk This is the main clock for the processor and most of the logic uses this clock. You can use CLKEN
SLEEPING to determine when it is safe to gate this clock.
hclk This clocks the TCU, AHBS interface, and the TCM interfaces. This clock must be running when HCLKEN
clk is running. It must also be running when clk is gated if you require the AHBS to access the
TCMs. You must not gate hclk unless GATEHCLK is HIGH.
etmclk This clocks the ETM. The ETM has an internal clock gate that turns off the majority of the ETM ETMCLKEN
logic when possible. ETMCLKEN must be HIGH at all times unless the processor core and ETM
are powered down. The CLKEN signal must also be HIGH to program the ETM. When ETM
programming is complete, CLKEN can be LOW.
Table 4-2 shows the clock and clock enable signals.
Table 4-2 Clock and clock enable signals
Signal name Direction Description Connection information
CLKIN Input Processor clock that all CLKIN must always be running, unless the processor is
internal clocks are derived powered down.
from
FCLKEN Input Controls the fclk clock gate If you use the NVIC to wake-up the processor, you must
ensure this signal is HIGH in sleep mode. If clock gating is
not required, tie HIGH.
CLKEN Input Controls the clk clock gate This signal can only be LOW if SLEEPING is HIGH. If
clock gating is not required, tie HIGH.
HCLKEN Input Controls the hclk clock gate This signal can only be LOW if GATEHCLK is HIGH. If
clock gating is not required, tie HIGH.
ETMCLKEN Input Controls the etmclk clock This signal must be LOW only when the ETM is powered
gate down. If your design does not gate the power to the ETM,
then this signal must be tied HIGH.
STCLKEN Input Enable signal for the If software configures the SysTick timer to use the external
SysTick logic reference clock, then the SysTick timer decrements on each
internal fclk clock rising edge when STCLKEN is HIGH.
Table 4-2 Clock and clock enable signals (continued)
CLK1EN Input Clock enables for the If you do not require the redundant core, tie these inputs
redundant core LOW.
FCLK1EN
HCLK1EN
Table 4-3 shows the reset signals.
Table 4-3 Reset signals
nPORESET Input Powerup reset. Resets entire processor. Must be asserted on power up.
Assert the reset for at least six CLKIN
cycles. The reset can be asserted or
deasserted asynchronously to CLKIN.
nSYSRESET Input The nSYSRESET signal resets the processor, nSYSRESET can be asserted without
except the debug logic, AHBD interface, CTI and nPORESET. It is not necessary to assert
ETM. nSYSRESET on power up.
Assert the reset for at least six CLKIN
cycles. The reset can be asserted or
deasserted asynchronously to CLKIN.
SYSRESETREQ Output Request to assert nSYSRESET. Connect to nSYSRESET control logic.
nDBGETMRESET Input Reset for the ETM only. Assert the reset on ETM power up. Assert
the reset for at least six CLKIN cycles.
The reset can be asserted or deasserted
asynchronously to CLKIN.
CPUWAIT Input When this signal is HIGH out of reset, it forces the If you do not require this functionality, tie
processor into a quiescent state that delays its this signal LOW.
boot-up sequence and instruction execution until
this signal is driven LOW. This allows the TCMs
to be loaded by the system before the processor
preforms any TCM accesses. The processor
AHBS interface functions while CPUWAIT is
asserted and services transactions initiated by the
system to load the TCMs. Therefore, external
hardware on the TCM interface is not required for
boot-time initialization.
Note
Debugger accesses continue to be performed
when this signal is asserted.
4.3.1 Clock gating combinations
Table 4-4 shows the legal clock gating combinations.
Table 4-4 Clock gating combinations
FCLKEN HIGH CLKEN HIGH HCLKEN HIGH ETMCLKEN HIGH
FCLKEN LOWa - Invalid AHBS active Not debugging

during WIC sleepa
CLKEN LOW Core sleepingb - AHBS active

while core sleepingb
HCLKEN LOW Core and TCU Invalid -

sleepingc
ETMCLKEN LOW ETM powered down -
a. WIC sleep, SLEEPDEEP HIGH.

b. SLEEPING is HIGH.
c. SLEEPING and GATEHCLK are HIGH.
4.3.2 Reset modes
The reset signals present in the processor design enable you to reset different parts of the design
independently.
Table 4-5 shows the reset modes, and the combinations and possible applications that you can
use them in.
Table 4-5 Reset modes
Reset mode nSYSRESET nPORESET Application
Powerup reset X 0 Reset on power up, full system reset.

Known as Cold reset.
Processor reset 0 1 Processor core reset only, excluding

debug logic. Known as Warm or Soft
reset.
Note
nPORESET resets a superset of the nSYSRESET logic.
Powerup reset
Arm recommends that you assert the reset signals for at least six CLKIN cycles to ensure
correct reset behavior. When reset is asserted CLKEN, FCLKEN, HCLKEN and
ETMCLKEN must be HIGH.
Processor reset
A processor or Soft reset initializes the majority of the processor, excluding NVIC debug logic,
AHBD interface, ETM, CTI, FPB, DWT, and ITM. This reset is typically used for resetting a
processor that has been operating for some time, for example, watchdog reset. A processor reset
is achieved using nSYSRESET.
Normal operation
During normal operation nPORESET and nSYSRESET must be deasserted.
Scan operation
During scan testing, the reset synchronizers, clock gating cells, and nSYSRESET are bypassed
by the assertion of the DFTRSTDISABLE input, see ATPG Test Interface on page 6-3 for more
details.
4.4 TCM interface

For a description of the TCM interface signals see TCM interface on page 5-4.
Note
For more information on speculative accesses, see Speculative accesses on page 4-4.
4.5 AXI master interface

The AXI master interface (AXIM) is a 64-bit wide AXI4 master interface for slow on-chip or
off-chip memory, and slow devices, see the Arm® AMBA® AXI and ACE Protocol Specification
AXI3, AXI4, and AXI4-Lite, ACE and ACE-Lite and the AXIM interface section in the Arm®
Cortex®-M7 Processor Technical Reference Manual for more details.
Note
For more information on speculative accesses, see Speculative accesses on page 4-4.
4.5.1 AXIM transaction issuing capability
The transaction issuing capability of the interface is different depending on whether the
processor is configured with a D-cache.
A processor with D-cache has a high performance AXIM. A high performance AXIM is
intended to be integrated into a native AXI system with high memory bandwidth with support
for multiple outstanding transactions.
Table 4-6 shows the transaction issuing capability of a high performance AXIM.
Table 4-6 High performance AXIM attributes and transactions
Attribute Value Comments
Write issuing capability 39 Write issuing capability consisting of:

• 15 writes to DEV/SO memory.
• 24 writes to Normal memory which can be evictions, write bursts or single writes.
A maximum of 17 of these can be to cacheable memory and a maximum of 10 to
non-cacheable or shareable memory.
Read issuing capability 7 Read issuing capability consisting of:

• 2 data linefills.
• 4 non-cacheable data reads.
• 1 instruction fetch or instruction linefill
Write ID capability 4 Write ID capability consisting of:

• 1 reserved for DEV/SO memory.
• 1 reserved for Normal, cacheable and non-shareable memory.
• 1 reserved for Normal, non-cacheable or shareable memory
• 1 reserved for cache line evictions, Normal, cacheable, WB memory.
Read ID capability 4 -
Write interleave capability 1 -
Combined issuing capability 40 Combined issuing capability consisting of:

• 39 outstanding writes.
• 1 instruction fetch.
A processor without D-cache has an area optimized AXIM. An area optimized AXIM is:
• Intended to be integrated into a low-cost AXI system or bridged to AHB.
• Suitable for connection to an inherently low-bandwidth memory system. This can be

off-chip memory, for example.
Table 4-7 shows the transaction issuing capability of an area optimized AXIM
Table 4-7 Area optimized AXIM attributes and transactions
Attribute Value Comment
Write issuing capability 25 Write issuing capability consisting of:

15 writes to DEV/SO memory
10 writes to Normal memory
Read issuing capability 5 Read issuing capability consisting of:

• 4 data read.
• 1 instruction fetch or instruction
linefill.
Read ID capability 2 -
Write ID capability 2 Write ID capability consisting of:

• 1 reserved for DEV/SO memory.
• 1 reserved for Normal memory.
Write interleave capability 1 -
Combined issuing capability 26 Combined issuing capability consisting of

• 25 outstanding writes.
• 1 instruction fetch.
4.5.2 Interface clocking
The AXIM supports semi-synchronous operation that requires CLKIN and the AXI
interconnect clock to have a 1:N clock ratio with synchronous rising edges provided by a clock
enable signal. In this case the external AXI interconnect logic uses ACLK.
The AXIM clock enable signal ACLKEN allows ACLK to have a lower frequency than
CLKIN and slows the interface timing to match the ACLK frequency. When ACLKEN is
HIGH, the Cortex-M7 AXIM output signals can change and the Cortex-M7 AXIM input signals
are sampled. ACLKEN must be generated by logic that is clocked by CLKIN and must be
HIGH for only one CLKIN cycle per transfer, that is the cycle before the rising edge of ACLK.
ACLK must be synchronous to CLKIN and so must either be the same, or an integer division
of the CLKIN frequency. The rising edge of ACLK must occur at the same time as a rising edge
of CLKIN.
Note
To operate the AXIM semi-synchronously, you must use special purpose cells from your
technology library, see Special purpose cells in the Cortex-M7 processor on page 7-5 for details.
Figure 4-1 on page 4-13 shows the relationship between CLKIN and ACLK when
semi-synchronous operation is used. The top diagram shows the relationship when ACLK is
CLKIN/2. The bottom diagram shows the relationship when ACLK is CLKIN/3.
CLKIN
ACLK ACLK = CLKIN/2
ACLKEN
CLKIN
ACLK ACLK = CLKIN/3
ACLKEN
Figure 4-1 AXIM and AXI interconnect clock timing
4.5.3 Interface signals
The AXIM has several signals that are extensions to the AXI4 protocol. Usage of these signals
is optional.
Table 4-8 shows the signals for the AXI master port, and describes how to set these signals in
your SoC design.
Note
Arm strongly recommends that you implement a default slave that covers all the unimplemented
address ranges in the AXIM memory map and that it provides a DECERR response. This is
recommended even if you are not using the AXIM interface in your system.
Table 4-8 AXI master port signals
ACLKEN Input Clock enable for the AXI master port This supports semi-synchronous operation of
the interface relative to CLKIN. Connect to the
clock generation logic, or tie HIGH if not used.
ARADDR[31:0] Output Read address Connect to the slaves through the bus
infrastructure.
ARBURST[1:0] Output Read burst type
ARID[2:0] Output Read address ID
ARINNER[3:0] Output Read inner memory attributes. This signal is an extension to the AXI protocol
This signal indicates the internal L1 cache and is optional. Leave this signal unconnected
attributes of a transaction and has the same if your system does not require it.
encoding as ARCACHE. You can use it as a
hint for an L2 cache controller to optimize
allocation or caching policy.
ARLEN[2:0] Output Read burst length Connect to the slaves through the bus
infrastructure.
ARLOCK Output Read lock type
Table 4-8 AXI master port signals (continued)
ARMASTER Output Read access master: This signal is an extension to the AXI protocol
LOW Processor. and is optional. Leave this signal unconnected
HIGH Debugger. if your system does not require it.
Note
Debugger accesses are always D-side accesses
with ARPROT[2] LOW.
ARPROT[2:0] Output Read protection type Connect to the slaves through the bus
infrastructure.
ARREADY Input Read address ready
ARSHARE Output Read shareability attribute: This signal is an extension to the AXI protocol
LOW Non-shareable. and is optional. Leave this signal unconnected
HIGH Shareable. if your system does not require it.
ARSIZE[1:0] Output Read burst size Connect to the slaves through the bus
infrastructure.
ARVALID Output Read address valid
AWADDR[31:0] Output Write address
AWBURST[1:0] Output Write burst type
AWID[1:0] Output Write address ID This can be connected to both the AXI3 and
AXI4 interconnects.
AWINNER[3:0] Output Write inner memory attributes. This signal is an extension to the AXI protocol
This signal indicates the internal L1 cache and is optional. Leave this signal unconnected
attributes of a transaction and has the same if your system does not require it.
encoding as AWCACHE. You can use it as a
hint for an L2 cache controller to optimize
allocation or caching policy.
AWLEN[2:0] Output Write burst length Connect to the slaves through the bus
infrastructure.
AWLOCK Output Write lock type
AWMASTER Output Write access master: This signal is an extension to the AXI protocol
LOW Processor. and is optional. Leave this signal unconnected
HIGH Debugger. if your system does not require it.
Note
Debugger accesses are always D-side accesses
with AWPROT[2] LOW.
AWPROT[2:0] Output Write protection type Connect to the slaves through the bus
infrastructure.
AWREADY Input Write address ready
AWSIZE[1:0] Output Write burst size
AWSHARE Output Write shareability attribute: This signal is an extension to the AXI protocol
LOW Non-shareable. and is optional. Leave this signal unconnected
HIGH Shareable. if your system does not require it.
AWSPARSE Output Indicates that a transaction can use sparse This signal is an extension to the AXI protocol
writing strobes. and is optional. Leave this signal unconnected
This signal is only required for bridging to if your system does not require it.
AHB. An AXI4 to AHB-Lite bridge is provided See Appendix C for details on how to use this
in the Cortex-M7 processor deliverables, see signal.
Appendix C AXI4 to AHB-Lite Bridge for more
details.
AxCACHE[3:0] Output Write outer memory attributes 0000 Strongly-Ordered

0001 Device
0011 Normal non-cacheable
0110 Normal Write-Through cacheable
0111 Normal Write-Back cacheable, allocate
on read
1111 Normal Write-Back cacheable, allocate
on read and write
1010 Debug Write-Through read, no-allocate
(HPROTD[3:2] = 10)
1011 Debug Write-Back read, no-allocate
(HPROTD[3:2] = 11)
0110 Debug Write-Through write, no-allocate
(HPROTD[3:2] = 10)
0111 Debug Write-Back write, no-allocate
(HPROTD[3:2] = 11)
AWVALID Output Write address valid Connect to the slaves through the bus
infrastructure.
BID[1:0] Input Write response ID
BREADY Output Write response ready
BRESP[1:0] Input Write response
BVALID Input Write response valid
RDATA[63:0] Input Read data
RID[2:0] Input Read ID tag
RLAST Input Read last
RREADY Output Read ready
RRESP[1:0] Input Read response
RVALID Input Read valid
WDATA[63:0] Output Write data
WLAST Output Write last
WREADY Input Write ready
WSTRB[7:0] Output Write strobes
WVALID Output Write valid
WID[1:0] Output Write ID tag Used to connect to AXI3 interconnect or

slaves. Can be ignored for AXI4 interconnect
or slaves.
Note
• The AXI3 early write response behavior is not supported. The AXIM requires that the
slave does not return a write response on the B-channel until it has received the write
address.
• AXIM honors the endianness configuration of the processor for loads and stores.
4.6 AHB peripheral interface

The AHB peripheral interface (AHBP) is an AHB-Lite master interface, see the Arm® AMBA®
3 AHB-Lite Protocol (v1.0) Specification for more details. It supports low-latency D-side
transactions and is intended to be used with fast on-chip peripherals.
Instruction execution and vector fetches are not supported on the AHBP. See the AHB
peripheral interface section in the Arm® Cortex®-M7 Processor Technical Reference Manual for
more details of the memory types supported by the AHBP interface.
The AHBP has several signals that are extensions to the AHB-Lite protocol. These signal
extensions are optional.
The AHBP supports exclusive access using the AHB-Lite extension signals EXREQP and
EXRESPP, see the AHBP semaphores section in the Arm® Cortex®-M7 Processor Technical
Reference Manual for more details.
Table 4-9 shows the signals for the AHB peripheral interface.
Note
• This interface is only fully synchronous to the processor clock, it does not provide a
semi-synchronous or asynchronous capability.
• Arm strongly recommends that you implement a default slave to cover all unimplemented
address ranges on the AHBP interface and that it provides an ERROR response. This is
recommended even if you are not using the AHBP interface in your system.
Table 4-9 AHB peripheral interface signals
HADDRP[31:0] Output Address bus Connect to address decoders,

arbiter, and slaves through the
bus infrastructure.
HBURSTP[2:0] Output HBURSTP is always SINGLE Connect to the AHB arbiter and
slaves through the bus
infrastructure.
HPROTP[3:0] Output Protection control signal Connect to the slaves through

the bus infrastructure.
HSIZEP[2:0] Output Indicates size of data Connect to the slaves through

HTRANSP[1:0] Output Indicates the type of the current transfer on the peripheral port Connect to the AHB arbiter and
slaves through the bus
infrastructure.
HWRITEP Output Indicates type of transfer, read or write Connect to the slaves through
Table 4-9 AHB peripheral interface signals (continued)
HMASTERP Output Indicates which master is currently performing a transfer, the This signal is an extension to
processor or debugger: the AHB-Lite protocol and is
LOW Processor. optional.
HIGH Debugger. You can factor this master
information into your system
and peripherals if you want to
prevent debugger accesses to
some or all memories and
peripherals.
HRDATAP[31:0] Input Read data Connect to the slaves through

HWDATAP[31:0] Output Write data
HREADYP Input Indicates that a transfer has finished on the input bus
HRESPP Input Indicates response from peripheral:

LOW OKAY.
HIGH ERROR.
EXREQP Output Exclusive request. Address phase control signal that indicates This signal is an extension to
whether an access is because of a LDREX or STREX instruction: the AHB-Lite protocol and is
LOW Non-exclusive (standard) transaction. optional.
HIGH Exclusive transaction. To support exclusive transfers
This signal is not required to be qualified with HTRANSP. on the AHBP interface, connect
this signal to the Exclusives
Monitor, otherwise leave it
unconnected.
EXRESPP Input Exclusive response. Data phase signal sampled when This signal is an extension to
HREADYP is HIGH. It indicates whether the exclusive the AHB-Lite protocol and is
access request was granted or not: optional.
LOW Exclusive access granted. To support exclusive transfers
HIGH Exclusive access failed. on the AHBP interface, connect
If an exclusive monitor is implemented on the AHBP interface, this signal to the Exclusives
your system must drive EXRESPP, see Table 4-10. Monitor, otherwise tie it HIGH.
Table 4-10 EXRESPP with an implemented exclusive monitor
Transaction properties
Required EXRESPP
EXREQP Load/Store
LOW - X.
Not an exclusive access and so the EXRESPP signal has no
effect.
HIGH Load LOW if a system monitor is implemented that covers the access
address. Otherwise HIGH.
HIGH Store HIGH if a system monitor is implemented that covers the

access address and the exclusive check fails. Otherwise LOW.
Note
• Your software must avoid exclusive accesses to shared regions of memory unless you
have implemented a global exclusive monitor that covers the region in question. The
processor treats such accesses as an error condition and takes a BusFault exception if a
load is performed with EXREQP HIGH and receives EXRESPP HIGH.
• EXRESPP is ignored if an ERROR response is returned on HRESPP.
• The Cortex-M7 processor uses EXREQP and EXRESPP differently to the Cortex-M3
and Cortex-M4 processors. Therefore, system hardware and software might both require
to be updated when implementing a Cortex-M7 system.
• AHBP honors the endianness configuration of the processor for loads and stores.
4.7 AHB slave interface

The AHB slave interface (AHBS) is an AHB-Lite slave interface that provides system access to
TCMs, see the Arm® AMBA® 3 AHB-Lite Protocol (v1.0) Specification for more details.
This interface is driven by the internally generated hclk signal. A master that is connected to
this interface can use either:
• an externally generated clock signal that is gated in the same way as hclk, see Clocking
and resets on page 4-6 for details,
or
• a clock signal that is a superset of this clock, that means a clock that is active when hclk
is active and that can also be active when hclk is not active.
The AHBS-Lite master connected to this interface must not issue transactions to the AHBS
interface when either HCLKEN or AHBSRDY is LOW. See Clocking and resets on page 4-6
for more information on clock gating, and Chapter 13 Low-power Integration for information
on how to use the AHBS in low-power modes.
The memory map presented on the AHBS is consistent with the memory map presented to
software running on the processor.
Note
• This interface is only fully synchronous to the processor clock, it does not provide a
semi-synchronous or asynchronous capability.
• The TCM enable bits defined in the ITCMCR and DTCMCR do not affect AHBS
accesses and only affect software visibility of the TCMs. See the Instruction and Data
Tightly-Coupled Memory Control Registers section in the Arm® Cortex®-M7 Processor
Technical Reference Manual.
Table 4-11 shows the AHBS memory map. Accesses to addresses outside the ranges shown
returns an ERROR response on the HRESPS signal.
Table 4-11 AHBS memory map
Start address End address HADDRS[2] TCM accessed TCM index
0x00000000 0x00000000 + <ITCM size>a - ITCM HADDRS[n:3]b
0x20000000 0x20000000 + <DTCM size>c 0 D0TCM HADDRS[n:3]b
0x20000000 0x20000000 + <DTCM size>c 1 D1TCM HADDRS[n:3]b

a. The ITCM size is configured by the CFGITCMSZ[3:0] tie-off.
b. The value of n depends on the configured TCM size.
c. The DTCM size is configured by the CFGDTCMSZ[3:0] tie-off.
The processor combines every two consecutive AHBS write transfers to ITCM into one 64-bit
write when they are part of the same incrementing word-size burst.
Table 4-12 shows the signals for the AHB slave interface.
Table 4-12 AHB slave interface signals
HTRANSS[1:0] Input Indicates the type of the current transfer. All transfer types are Connect masters through the
supported. bus infrastructure.
HREADYS Input When HIGH indicates that a transfer has completed on the bus.
This signal is driven LOW to extend a transfer.
HSELS Input When HIGH indicates that this interface has been selected.
HBURSTS[2:0] Input Indicates if the transfer is part of a burst. All burst types are
supported.
Any incrementing write burst to the ITCM that is word sized is
optimized so that two consecutive even and odd word beats are
combined into one 64-bit double-word aligned write into the
Store Queue. Therefore, only one 64-bit write to the ITCM
occurs for every two AHBS transfers that meet the burst
requirement.
HADDRS[31:0] Input 32-bit address.
HWRITES Input Write not Read.
HSIZES[2:0] Input Indicates the size of the access. Accesses can be:
0b000 Byte.
0b001 Halfword.
0b010 Word.
Note
Other HSIZES values are illegal for a 32-bit wide data bus.
HWDATAS[31:0 Input 32-bit write data bus.

]
HPROTS[3:0] Input Protection control signal.

HPROTS[0] Data or instruction access. Not used.
HPROTS[1] Privileged access. *TCMPRIV signal value.
HPROTS[2] Bufferable. Not used.
HPROTS[3] Cacheable. Not used.
HREADYOUTS Output Indicates that a transfer is complete.
HRDATAS[31:0] Output Read data bus.
Table 4-12 AHB slave interface signals (continued)
HRESPS Output The transfer response status: Connect masters through the
LOW OKAY. bus infrastructure.
HIGH ERROR.
Note
An ERROR response is returned when either:
• A read or write transaction address is outside the valid
range.
or
• A read transaction is aborted because the xTCMERR
signal on the TCM interface is asserted.
WABORTS Output This signal is an extension to the AHB-Lite protocol. It

indicates to the AHBS that an asynchronous write abort has
occurred. This is caused by the assertion of the xTCMERR
signal for a write on the TCM interface that originated from the
AHBS:
LOW No abort.
HIGH Abort.
This signal is always valid and can be asserted for consecutive
cycles if back-to-back TCM interface write aborts occur.
AHBSRDY Output This signal is an extension to the AHB-Lite protocol. It

indicates when the AHBS is ready to accept transactions:
LOW Not ready.
HIGH Ready.
AHBSPRI Input This is an address phase signal and is an extension to the If implemented, connect to
AHB-Lite protocol. It indicates that the AHBS access has your AHBS priority boost
priority over a software access. This signal has no affect unless logic. If not required then tie
enabled by the AHBSCR.CTL field. See the Arm® Cortex®-M7 LOW.
Processor Technical Reference Manual:
LOW Software access takes priority over AHBS
access.
HIGH The AHBS access has priority over a software
access.
4.7.1 AHBS interface byte lane assignments
Table 4-13 shows the byte lanes the interface uses during the data phase on HRDATA or
HWDATA, and the mapping to bytes in the source or destination processor register, Rd, for all
transfer sizes and each endianness configuration.
Table 4-13 AHBS interface byte lane assignments
Address phase Corresponding data phase
Processor
HSIZE [1:0] HADDR [1:0] HxDATA[31:24] HxDATA[23:16] HxDATA[15:8] HxDATA[7:0]
endianness
0b00 0b00 - - - - Rd[7:0]
0b00 0b01 - - - Rd[7:0] -
0b00 0b10 - - Rd[7:0] - -
0b00 0b11 - Rd[7:0] - - -
0b01 0b00 Little-endian - - Rd[15:8] Rd[7:0]
0b01 0b00 Big-endian - - Rd[7:0] Rd[15:8]
0b01 0b10 Little-endian Rd[15:8] Rd[7:0] - -
0b01 0b10 Big-endian Rd[7:0] Rd[15:8] - -
0b10 0b00 Little-endian Rd[31:24] Rd[23:16] Rd[15:8] Rd[7:0]
0b10 0b00 Big-endian Rd[7:0] Rd[15:8] Rd[23:16] Rd[31:24]
Note
AHBS honors the endianness configuration of the processor for loads and stores.
4.7.2 AHBS interface availability and low-power states
The following conditions are required for the AHBS interface to accept AHBS transactions:
• All resets are deasserted.
• hclk is running, see Clocking and resets on page 4-6.
The AHBS interface sub-system and TCMs are in a separate clock domain to the rest of the
processor but in the same reset and power domains. This means that TCM data transfers can be
performed without the fclk or clk running, and while the processor is in any of its sleep modes.
The processor exports the GATEHCLK signal to indicate to the system when it is safe to gate
hclk and the clock to the TCMs. This signal is only HIGH when the processor is sleeping and
there are no AHBS interface accesses in-flight within the processor.
When the processor is awake, GATEHCLK is LOW and the system must continue to drive
hclk to the processor and clock the TCMs.
Note
If AHBS interface transfers are not being performed, it is possible to gate the clock to the rest
of the AHBS interface system to conserve power.
When the processor is asleep, GATEHCLK goes HIGH when the last AHBS interface transfer
has been completed to the TCMs. At this time hclk and the clock to the TCMs can be gated
safely. If the processor wakes up, hclk must resume in the normal way. See Clocking and resets
on page 4-6 and Power control and sleep interface on page 4-44 for more details on sleep modes
and their clocking requirements.
Additionally, the system must ensure that hclk is running from the cycle on which the address
phase for the first AHBS interface transfer is presented on this bus, until GATEHCLK is
subsequently asserted.
Note
• The processor does not combinatorially deassert GATEHCLK based on the current value
of HTRANS on the AHBS interface. The system must ensure that hclk is active on this
cycle to enable the processor to sample the transaction correctly.
• Do not use SLEEPHOLDREQn/SLEEPHOLDACKn handshake to delay resumption

of hclk when the AHBS interface transactions are being performed.
The AHBSRDY signal enables a slave to decline or delay an address phase. When the
AHBSRDY signal is LOW, the AHBS interface is unable to accept transactions in the following
cases:
• The processor is in reset. The processor implements an internal reset synchronizer, that
implies it might come out of reset later than other external system agents in the same reset
domain.
• The system domain is powered down.
Any AHB transactions performed when AHBSRDY is LOW are considered system errors. Arm
recommends the following:
• All agents check that AHBSRDY is HIGH before initiating transactions to the AHBS
interface.
• The system waits until all outstanding AHBS interface transactions are complete before
preparing for entry into deep sleep or powerdown states. Subsequent transactions must not
be performed until the processor has left the low-power state. For more details on deep
sleep, see Power control and sleep interface on page 4-44.
If the system cannot guarantee that transactions are not performed when AHBSRDY is LOW,
Arm recommends that some external hardware is added to detect this condition and flag errors
appropriately. For example, a sticky bit could be implemented that is set when HTRANSS[1] is
HIGH and AHBSRDY is LOW. Software must poll this bit at suitable intervals to check for any
transactions that might have been dropped and clear the bit after re-issuing them.
4.8 AHB debug interface

The AHB debug slave interface, AHBD, implements the AMBA3 AHB-Lite protocol and is a
32-bit port.
It is designed for integration with a CoreSight AHB-AP to provide debugger access to:
• All processor control and debug resources.
• A view of memory that is consistent with software data side accesses.
AHB debug accesses are always little-endian. Data swizzling is implemented in the processor
to interface to big-endian memory transparently to a debugger.
The instruction cache is not accessible to a debugger so the debugger accesses to cacheable
executable regions of memory might not be coherent with the instructions visible to the
processor instruction side. This can cause:
• Debugger reads to return more up-to-date values if the instruction cache is stale. For
example, if self-modifying code has been executed and the debugger access takes place
before the appropriate cache maintenance operations were executed to update the
instruction side view of memory.
• Debugger writes do not automatically invalidate the instruction cache, and so the data in
the instruction cache might be stale. This might happen when the debugger is
downloading code to a device that has caches enabled. In this case, the debugger is
required to perform the following operations to ensure the instruction side observes the
updated code:
— Data cache clean by address for all addresses written. This can be skipped if the data
cache is disabled, not configured, or if the AHB debug accesses are performed as
Non-cacheable.
— Instruction cache invalidate by address for all addresses written or alternatively an
instruction cache invalidate-all. This can be skipped if the instruction cache is
disabled or not configured.
Note
These operations might not be required if code is downloaded immediately out of reset and the
caches do not contain valid data. Vector catch on reset can ensure the processor enters halt mode
before any instructions, including those to enable the cache, have been executed.
Debugger accesses depend on the processor control state programmed when the access is
handled:
• Access to the TCMs or the AXI master interface is controlled by the TCM enable in the
ITCMCR and DTCMCR.
• Access to the AHB peripheral or the AXI master interface is controlled by the AHB
peripheral enable in the AHBPCR.
This means that the debugger might not map AHB debug accesses onto the required interface.
The mapping of debugger accesses is identical to software accesses.
Note
AHB debug accesses:
• To the System region of the memory map do not have any dependencies on processor state
and are always mapped correctly. This includes accesses to the PPB and EPPB.
• Are not affected by MPU protection checks. This allows a debugger to gain access to the
entire memory map independently of the current software protection settings.
Table 4-14 shows the signals for the AHB debug interface.
Table 4-14 AHB debug interface signals
HTRANSD[1:0] Input Indicates the type of current transfer: Connect to a DAP AHB-AP
0b00 IDLE.
0b10 NONSEQUENTIAL.
0b11 SEQUENTIAL.
HBURSTD[2:0] Input Indicates whether the transfer is part of a burst. Bursts

can be:
0b000 SINGLE, fetch or debug access.
0b001 INCR, data load or store.
Fixed burst lengths are never used.
HADDRD[31:0] Input 32-bit instruction address bus.
HWRITED Input Write not Read.
HSIZED[2:0] Input Indicates the size of the access. Accesses can be:
0b000 Byte.
0b001 Halfword.
0b010 Word.
HWDATAD[31:0] Input Data write bus.
HPROTD[3:0] Input Provides information on the access, see Debugger

access attributes for more information.
HREADYD Output When HIGH indicates that a transfer has completed on

the bus. This signal is driven LOW to extend a transfer.
HRDATAD[31:0] Output Read Data.
HRESPD Output The transfer response status:

LOW OKAY.
HIGH ERROR.
4.8.1 Debugger access attributes
The attributes that perform a debugger access are derived from the HPROTD value of the
transaction. The system uses attributes differently depending on the interface that the AHB
debug access is mapped to. Table 4-15 on page 4-27 shows how to use the HPROTD attributes
for all interfaces. This does not include AXI master interface and the internal PPB registers.
Table 4-15 HPROTD attributes
Interface Description
TCM HPROTD[0] ignored.

HPROTD[1] mapped to *TCMPRIV.HPROTD[3:2] ignored.
TCMs are implicitly Normal memory.
*TCMMASTER indicates that the TCM access is initiated by the debugger.
AHB HPROTD[0] ignored. All debugger accesses are performed with HPROTP[0] is 1.
peripheral HPROTD[3:1] reflected on HPROTP[3:1].
HMASTERP indicates that the AHB peripheral access is initiated by the debugger.
PPB HPROTD[0] ignored.

HPROTD[1] used for register-specific privilege checks.
HPROTD[3:2] ignored.
User AHB debug accesses to privileged registers returns HRESP = ERROR.
EPPB HPROTD[0] ignored.

HPROTD[1] used for register-specific privilege checks.
HPROTD[3:2] ignored.
User AHB debug accesses to privileged registers returns HRESP = ERROR.
The HPROTD attributes are mapped to the AXIM interface in the following manner:
• Privilege level on HPROTD[1] is reflected onto A*PROT[0].
• HPROTD[0] is ignored and all accesses are performed with A*PROT[2] = 0b0.
• A*MASTER is 0b1 to indicate a debugger access.
• HPROTD[3:2] are mapped onto A*CACHE and the A*INNER and A*SHARE
sideband signals as shown in Table 4-16 on page 4-28.
Note
Table 4-16 on page 4-28 shows the situation when a D-cache is configured and enabled.
In other cases, the access is handled as if the result of the D-cache lookup is always a miss.
Table 4-16 HPROTD[3:2] to AXIM attribute mapping
Access type HPROT[3:2] Description
Read 0b00 Treated as Strongly-ordered memory. Cache is bypassed. An AXI master read is performed with:
ARCACHE 0b0000.
ARINNER 0b0000.
ARSHARE 0b1.
0b01 Treated as Device memory. Cache is bypassed. An AXI master read is performed with:
ARCACHE 0b0001.
ARINNER 0b0001.
ARSHARE 0b1.
0b10 Treated as Normal, Write-through, no-allocate memory. Cache lookup is performed. Hits return
data from the cache. Misses perform an AXI master read with:
ARCACHE 0b1010 (WT, no allocate).
ARINNER 0b1010.
ARSHARE 0b0.
0b11 Treated as Normal, Write-back, no-allocate memory. Cache lookup is performed. Hits return data
from the cache. Misses perform an AXI master read with:
ARCACHE 0b1011 (WB, no allocate).
ARINNER 0b1011.
ARSHARE 0b0.
Write 0b00 Treated as Strongly-ordered memory. Cache is bypassed. An AXI master write is performed with:
AWCACHE 0b0000.
AWINNER 0b0000.
AWSHARE 0b1.
Write 0b01 Treated as Device memory. Cache is bypassed. An AXI master write is performed with:
AWCACHE 0b0001.
AWINNER 0b0001.
AWSHARE 0b1.
0b10 Treat as either:

Normal, Write-through, no allocate (WT).
Normal, Write-back, no allocate (WB) depending on whether the data is dirty in the cache:
• A cache lookup is performed.
• A hit on dirty data writes only into the cache.
• A hit in clean data write into the cache and on AXI master (WT).
• A miss writes on AXI master (WT).
AXI master writes are performed with:
AWCACHE 0b0110, Write-through, no allocate.
AWINNER 0b0110.
AWSHARE 0b0.
0b11 Treated as Normal, Write-back, no-allocate memory.Cache lookup is performed. Hits write data
into the cache alone. Misses perform an AXI master write with:
AWCACHE 0b0111, Write-back, no allocate.
AWINNER 0b0111.
AWSHARE 0b0.
The debugger ensures that the HPROTD attributes for an access to the AXIM region are
consistent with the active memory attributes of the processor as visible to software. Failure to
do this, could cause:
• AHBD reads to return stale read data.

For example, a non-cacheable AHBD read does not perform a cache lookup and might
therefore not return up-to-date data if the address remains in the cache and is dirty.
• AHBD writes not visible to executing software for a potentially indefinite period of time.
For example, a non-cacheable AHBD write does not perform a cache lookup and does not
update a cached location that remains in the cache indefinitely because it is never evicted.
Software therefore continues to see stale data.
• AHBD writes to be lost.

For example, a non-cacheable AHBD write does not update the cache that might contain
a valid and dirty line that is subsequently evicted, thereby overwriting the debugger
access.
In typical devices, it is expected that DEV/SO regions are software-context independent and can
therefore be reliably accessed accordingly by a debugger. For such devices, the debugger is
strongly advised to:
• Perform all accesses to DEV/SO with HPROTD[3:2] = 0b00.
• Perform all other accesses with HPROTD[3:2] = 0b10.
This scheme guarantees the following situation:

• Reads return an up-to-date value – because a cache lookup is performed.
• Writes are visible to the processor – because the cache is updated if it contains the data.
This scheme guarantees that writes to Normal memory are always propagated to L2.
Any implemented system caches must also consider debugger accesses and might adopt a
similar scheme to the one implemented in the processor. This ensures that in the typical case,
debugger accesses and software accesses are handled consistently with respect to each other.
If the D-cache is enabled and the debugger is unable to reliably determine the software attributes
of a given address, it must:
• Halt the processor.
• Clean and invalidate the D-cache.
• Perform the access.
Note
If no MPU is configured, the attributes are defined by the default memory map and can therefore
be reliably determined by a debugger.
4.9 External Private Peripheral Bus

The External Private Peripheral Bus (EPPB) is an APB master interface, see the Arm® AMBA®
3 APB Protocol Specification. The EPPB enables integration of the CoreSight:
• Debug and trace components.
• ROM tables.
The EPPB provides data accesses to the memory region 0xE0040000-0xE00FFFFF. Instruction
accesses to this region are permanently disabled.
The EPPB is not intended for general peripheral usage and has both higher latency and lower
average throughput than the AHBP peripheral interface.
The interface supports:

• Little-endian accesses. The endianness configuration of the processor is ignored.
• Privileged accesses. An Unprivileged access takes a BusFault exception.
• Word sized accesses. Attempts to perform other sized accesses are UNPREDICTABLE.
• Aligned accesses. Unaligned accesses are UNPREDICTABLE.
Arm recommends that all non-debug peripherals are integrated on the AHBP interface or the
AXI master interface.
The EPPB performs debugger-initiated transactions while the processor is in Soft reset.
Table 4-17 shows the signals for the APB interface. Only the address bits necessary to decode
the EPPB space are supported on this interface.
Note
Arm strongly recommends that you implement a default slave that deals with all the
unimplemented address ranges in the EPPB memory map and that it asserts PSLVERR. This
applies even if you are not using the EPPB interface in your system.
Table 4-17 APB interface signals
PSEL Output APB device select Indicates that a data transfer is requested.
PENABLE Output APB control signal Strobe to time all accesses. Indicates the second cycle of an
APB transfer.
PWRITE Output APB transfer direction Write not read.
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 DAP is the requesting
master. It is driven LOW when the processor is the
requesting master.
PWDATA[31:0] Output APB write data bus 32-bit write 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.
PRDATA[31:0] Input APB read data bus 32-bit read data bus.
4.10 ITM interface

Table 4-18 shows the signals for the ITM interface. See the Arm® AMBA® 4 ATB Protocol
Specification for more information.
Table 4-18 ITM interface signals
ATVALID Output ATB valid If the TRC parameter is set to 1, connect to

your CoreSight trace infrastructure, for
AFREADY Output ATB flush example a CM7TPIU. Tie all input signals
LOW if this interface is not used.
ATDATA[7:0] Output ATB data
ATID[6:0] Output ITM ID
ATREADY Input ATB ready
AFVALID Input ATB valid
DSYNC Output DWT synchronization

request. Periodic
formatter protocol
synchronization request
for low-cost TPIUs
such as the CM7TPIU.
If the CM7TPIU is used
then this signal must be
connected to its
SYNCREQ input.
Note
• The CoreSight lock mechanism in the DWT, ITM and FPB has been removed.
• This is already an optional feature in the ARMv7M architecture and is being made
optional in the general CoreSight architecture to aid simplification.
• As a result of this change, the Lock Access Registers and Lock Status Registers in these
components are RAZ/WI.
4.11 ETM instruction trace interface

Table 4-19 shows the signals for the ETM instruction trace interface. See the Arm® AMBA® 4
ATB Protocol Specification for more information.
Table 4-19 ETM instruction trace interface signals
AFREADYMI Output CoreSight trace system ATB interface FIFO flush If the ETM configuration parameter value
finished is 1 or 2, connect to your CoreSight trace
infrastructure.
AFVALIDMI Input ATB interface FIFO flush request
If the ETM parameter value is 1, then you
ATDATAMI[7:0 Output ATB interface data can connect this interface to a CM7TPIU.
] If the ETM parameter value is 0, the ETM
interface is not used and you must tie all
ATIDMI[6:0] Output ATB interface trace source ID input signals LOW and leave the outputs
unconnected.
ATREADYMI Input ATDATA can be accepted
ATVALIDMI Output ATB interface data valid
SYNCREQI Input Trace synchronization request from instruction trace

sink
TRIGGER Output ETM event output bit 0. Can be connected to a

CM7TPIU trigger input.
4.12 ETM data trace interface

Table 4-20 shows the signals for the ETM data trace interface. See the Arm® AMBA® 4 ATB
Protocol Specification for more information.
Table 4-20 ETM data trace interface signals
AFREADYMD Output CoreSight trace system ATB interface If the ETM configuration parameter is set to 2,
FIFO flush finished connect this to your CoreSight trace
infrastructure. If this interface is not used then you
AFVALIDMD Input ATB interface FIFO flush request must tie all input signals LOW.
ATBYTESMD[2:0] Output Size of transfer on ATDATAMD[63:0]
signal
ATDATAMD[63:0] Output ATB interface data
ATIDMD[6:0] Output ATB interface trace source ID
ATREADYMD Input ATDATA can be accepted
ATVALIDMD Output ATB interface data valid
SYNCREQD Input Trace synchronization request from data

trace sink
4.13 Debug signals

Table 4-21 shows the debug signals.
Table 4-21 Debug signals
HALTED Output In halting mode debug. HALTED remains Connect to ETM if present.
asserted while the processor 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.
EDBGRQ Input External debug request. This signal can be Either tie LOW or connect
asserted by a debug agent in the system to to your external debug
request that the processor enters Debug state. request logic.
DBGEN Input Invasive debug enable. If DBGEN is Either tie HIGH or connect
deasserted then all debug features cannot be to a debug access controller
used. If DBGEN is asserted then debug if required.
features can be used but other enables such as
C_DEBUGEN must still be set to permit
debug events such as halt to occur.
NIDEN Input Non-invasive debug enable. When LOW, Either tie HIGH or connect
disables all trace and non-invasive debug to debug authentication
features. module.
IADDR[31:3] Output Instruction fetch address, 64-bit aligned. Connect to code memory
Use for code protection logic to drive the debug event protection
IADBGPROT input signal. logic.
IADBGPROT Input Debug protection mask. When asserted, this Connect to code memory
signal masks internal debug events to prevent debug event protection
their occurrence. Debug events such as logic. This logic must
breakpoints, watchpoints, and trace are decode IADDR[31:3] and
masked: return IADBGPROT in the
LOW IADDR[31:3] address not same clock cycle.
protected. If you are not using this
HIGH IADDR[31:3] address feature, tie IADBGPROT
protected for mask debug LOW.
events.
CTICHIN[3:0] Input CTI channel input Either connect to

CTICHOUT of system
level CTI or CTM, or tie all
LOW.
CTICHOUT[3:0] Output CTI channel output Either connect to CTICHIN

of system CTI or CTM, or
leave unconnected.
CTIIRQ[1:0] Output CTI interrupt (active HIGH) Either connect to two of

IRQ[239:0] bits or leave
unconnected.
You might have a requirement to use CTI signals, for example when multiple processors are
present in your SoC. In this case, you must use the Arm CoreSight SoC-400 product. This
applies both to systems containing multiple Cortex-M7 processors, and to systems
implementing processors of different types.
4.14 Interrupt interface

Table 4-22 shows the interrupt interface signals present on the processor, and describes how you
must set the signals in your SoC design.
Table 4-22 Interrupt interface
IRQ[239:0] Input External interrupt signals. The implemented bits of Connect to interrupt logic.
this signal are configured by the IRQNUM parameter, The number of functional
see Configuration options on page 2-3. interrupt signals depends on
your implementation. Tie
any bits that are not
implemented LOW.
NMI Input Non-Maskable Interrupt. Connect to your interrupt

logic.
Note
The Cortex-M7 processor does not implement synchronizers for the IRQ and NMI inputs. If
you want to use asynchronous interrupts, you must implement external synchronizers to reduce
the possibility of metastability issues.
4.15 Miscellaneous signals

Table 4-23 shows the miscellaneous signals present on the processor, and describes how you
must connect these signals in your SoC design. The configuration input signals are sampled at
reset.
Table 4-23 Miscellaneous interface signals
ECOREVNUM[35:0] Input ECO revision number. The ECO revision Tie all bits LOW. This signal must be
field mappings are: brought up to the top level on your SoC
[35:32] ETM. design to prevent synthesis tools optimizing
[31:28] CTI. out the logic this signal drives. Arm provides
instructions on how to tie this signal in the
[27:24] Processor ROM table.
event of an ECO change.
[23:20] ITM.
[19:16] PPB ROM table.
[15:12] SCS.
[11:8] DWT.
[7:4] FPB.
[3:0] CPUID revision.
TRCENA Output Trace Enable. This signal reflects the setting Connect to clock gating logic for the ETM
of Debug Exception and Monitor Control and Cortex-M7 TPIU.
Register bit[24]. This signal can be used with
system-level debug power control signals to
gate the power to the ETM and control
ETMCLKEN, to gate its clock.
TSVALUEB[63:0] Input Global timestamp value. Connect to a natural binary count value if
global timestamping is required. You must
tie all bits LOW if not used.
TSCLKCHANGE Input Timestamp clock ratio change. Pulse HIGH for one clock cycle if either the
processor clock period or the timestamp
clock period changes. Tie LOW if
TSVALUEB is not used, or if TSVALUEB
is generated from clk.
CTLPPBLOCK[3:0] Input When HIGH, disables PPB writes to These signals can be changed dynamically. If
ITCMCR, DTCMCR, AHBPCR or VTOR you want the registers unlocked, tie all bits
registers. Bit mappings are: LOW, otherwise drive with external logic.
[0] ITCMCR.
[1] DTCMCR.
[2] AHBPCR.
[3] VTOR.
4.16 FPU exception signals

Table 4-24 shows the FPU signals. The FPU signals indicate mathematical errors that cause
floating-point exceptions. Using the FPU signals to indicate floating-point exceptions permits
such exceptions to be diagnosed independently from software. For example, in safety-critical
systems, exceptions can be routed directly to an on-chip safety controller.
Table 4-24 FPU signals
FPIXC Output Masked floating-point inexact exception Cumulative exception flags from the Floating
Point Status and Control Register (FPSCR).
FPIDC Output Masked floating-point input denormal exception These signals indicate when a floating-point
exception has occurred.
FPOFC Output Masked floating-point overflow exception
FPUFC Output Masked floating-point underflow exception
FPDZC Output Masked floating-point divide-by-zero exception
FPIOC Output Invalid operation
4.17 Configuration
Table 4-25 shows the configuration signals present on the processor, and describes how you
must set the signals in your SoC design. These signals can only be changed at Powerup reset or
Soft reset, see Reset modes on page 4-8. They are intended to be static configuration signals that
are fixed for a given integration of the processor.
Table 4-25 Configuration signals
CPUWAIT Input When HIGH out of reset, this signal forces the Tie these signals in accordance with
processor into a quiescent state where its boot-up your requirements or processor
sequence and instruction execution is delayed until configuration
this signal is driven LOW. During this time, no
memory accesses are performed by the processor.
Note
Debugger accesses continue to be performed when
this signal is asserted.
INITTCMEN[1:0] Input TCM enable initialization out of reset:

Bit[0] LOW: ITCM is disabled.
HIGH: ITCM is enabled.
Bit[1] LOW: DTCM is disabled.
HIGH: DTCM is enabled.
Note
When a TCM is enabled the
corresponding CFG*TCMSZ
signal must not be set to 0b0000.
INITRETRYEN[1:0] Input TCM retry enables out of reset:

Bit[0] LOW: ITCM retry is disabled.
HIGH: ITCM retry is enabled.
Bit[1] LOW: DTCM retry is disabled.
HIGH: DTCM retry is enabled.
INITRMWEN[1:0] Input TCM RMW initialization out of reset:

Bit[0] LOW: RMW functionality
disabled for ITCM.
HIGH: RMW functionality
enabled for ITCM.
Bit[1] LOW: RMW functionality
disabled for DTCM.
HIGH: RMW functionality
enabled for DTCM.
Table 4-25 Configuration signals (continued)
INITAHBPEN Input AHB peripheral interface enable initialization out Tie these signals in accordance with
of reset: your requirements or processor
LOW AHB peripheral interface configuration
disabled.
HIGH AHB peripheral interface enabled.
Note
When INITAHBPEN is HIGH,
signal CFGAHBPSZ must not be
set to 0b000.
INITVTOR[31:7] Input Vector table offset register out of reset.
CFGBIGEND Input Static endianness setting. This signal is sampled at

reset, and cannot be changed when reset is
inactive:
LOW Little-endian.
HIGH Big-endian.
This signal affects all data-side memory interfaces
identically except for the PPB region that is always
little-endian. Instruction fetches are always
performed as little-endian.
CFGITCMSZ[3:0] Input Indicates the ITCM size. Tie off to the required memory size, see
Table 4-26
CFGDTCMSZ[3:0] Input Indicates the DTCM size.
CFGAHBPSZ[2:0] Input Indicates the AHB peripheral interface region size. Tie off to the required size of the AHB
peripheral interface region, see
Table 4-27 on page 4-41
Table 4-26 shows the encodings for the ITCM and DTCM size configuration pins,
CFGITCMSZ[3:0] and CFGDTCMSZ[3:0].
Note
• Do not use TCM size encodings 0b0001 and 0b0010. These encodings are reserved.
• The RAM connected to each DTCM interface must be half the size configured by the
CFGDTCMSZ input.
Table 4-26 TCM size encodings
TCM size CFGITCMSZ[3:0] CFGDTCMSZ[3:0]
0KB, no TCM 0b0000 0b0000
4KB 0b0011 0b0011
8KB 0b0100 0b0100
16KB 0b0101 0b0101
32KB 0b0110 0b0110
64KB 0b0111 0b0111
Table 4-26 TCM size encodings (continued)
TCM size CFGITCMSZ[3:0] CFGDTCMSZ[3:0]
128KB 0b1000 0b1000
256KB 0b1001 0b1001
512KB 0b1010 0b1010
1MB 0b1011 0b1011
2MB 0b1100 0b1100
4MB 0b1101 0b1101
8MB 0b1110 0b1110
16MB 0b1111 0b1111
Table 4-27 AHB peripheral interface region size
AHBP region size CFGAHBPSZ[2:0]
0MB 0b000
64MB 0b001
128MB 0b010
256MB 0b011
512MB 0b100
Reserved 0b101-0b111
4.18 Events and errors

Table 4-28 shows the event and error signals present on the processor.
Table 4-28 Events and errors
TXEV Output Event transmitted as a result of SEV Connect to other processors in a multiprocessor
instruction. This is a single-cycle pulse. system. In a multiprocessor system, TXEV from each
You can use it to implement a more power processor can be broadcast to the RXEV input of the
efficient spin-lock in a multiprocessor other processors. Leave unconnected if not required.
system.
RXEV Input When HIGH this signal sets the Event You must construct the input to this signal as the
register in the processor that is defined in logical-OR of all non-interrupt event generating
the Arm v7-M architecture. This causes a sources of interest in your system.
WFE instruction to complete. It also wakes For example, the TXEV output of other Arm
up the processor, if it is sleeping, because it processors, or a single cycle completion signal from
executed a WFE instruction. peripherals not already connected to any interrupt
lines. You must add synchronization logic if this signal
is driven from a different clock domain. Tie this input
LOW if there are no non-interrupt event generating
sources in your system.
LOCKUP Output When HIGH, indicates that the processor is You can connect this signal to your own logic, for
in the architected Lockup state, because of example a watchdog device, that can reset the
an unrecoverable exception. See the processor using nSYSRESET.
Arm®v7-M Architecture Reference Manual If your system executes instructions from a
for more information. programmable memory, for example flash, after power
up, you must consider how that memory is
programmed. The processor might enter Lockup state
very quickly if the memory is uninitialized.
If nSYSRESET is asserted immediately, there might
not be enough time to connect a debugger to halt the
processor and leave Lockup state.
Arm recommends that your watchdog logic includes a
software-programmable enable bit that gates the
assertion of nSYSRESET because of LOCKUP.
If you require entry into Lockup state to reset the
system, your code must enable the functionality in your
watchdog unit.
ICERR[21:0] Output Instruction cache error bank signaling. Cache ECC error information signals. Consult the
functional safety documentation for more details.
DCERR[21:0] Output Data cache error bank signaling. Typically, these signals can be left unconnected.
ICDET[3:0] Output Instuction cache error detection signaling.
DCDET[3:0] Output Data cache error detection signaling.
4.18.1 Error reporting for the instruction and data cache
On cache reads subject to errors, information about all detected errors is reported to the system
on the Error Reporting Buses. If there are multiple errors detected on one read, some of the
information about all but one of the errors will be lost. The information appears on the buses
one cycle after the hardware detects the error and is asserted for one cycle.
There are separate buses for the instruction cache and data cache. ICDET and ICERR are for the
instruction cache. DCDET and DCERR are for the data cache.
The xCDET Error Reporting Bus indicates what types of errors have been detected. If multiple
errors of a particular type are found during one read, only one of the errors can be reported on
this bus. The bit allocation of xCDET is shown in the following table:
Table 4-29 ICDET and DCDET bit allocation
Bits Function
[3] Fatal error on data RAM read.
[2] Correctable error on data RAM read.
[1] Fatal error on tag RAM read.
[0] Correctable error on tag RAM read.
The xCERR Error Reporting Bus reports information about the current status of the instruction
cache Error Bank Registers, which of these Error Bank Registers have been allocated to this
cycle, and information about any allocation that has occurred. The bit allocation of xCERR is
shown in the following table.
Table 4-30 ICERR and DCERR bit allocation
Bits Function
[21] Indicates whether xEBR1 is locked.

0 Not locked
1 Locked
[20] Indicates whether xEBR1 is valid

0 Not valid
1 Valid
[19] Indicates whether xEBR0 is locked.

0 Not locked
1 Locked. No hardware allocation.
[18] Indicates whether xEBR0 is valid.

0 Not valid
1 Valid
[17:2] Data to be allocated. Corresponds to bits [17:2] of data to be written to Error Bank Register.
Only valid when xCERR[1:0] is not 0b00.
[1:0] Allocation status.

0b00 No allocation.
0b10 Allocation into xEBR0.
0b11 Allocation into xEBR1.
0b01 Attempted allocation but both entries are locked. Will not allocate.
4.19 Power control and sleep interface

The power control and sleep interface controls the low-power modes of the processor. For
details on how to use this interface, see Chapter 13 Low-power Integration and Chapter 14
Power Intent.
Table 4-31 shows the power control and sleep interface signals.
Table 4-31 Power control and sleep interface signals
SLEEPING Output When HIGH indicates that the processor and ETM are Connect to your power
ready to enter a low-power state. management unit
When LOW, indicates that the processor is running or
wants to leave sleep mode.
If SLEEPHOLDACKn is LOW, then the processor
does not perform any fetches until
SLEEPHOLDREQn is driven HIGH.
SLEEPDEEP Output Indicates that the processor and ETM are ready to enter
a low-power state and the wake-up time is not critical.
Only active when SLEEPING is HIGH.
GATEHCLK Output Indicates that hclk can be gated because the processor is Connect to your clock gating
asleep without the debugger being active. control logic or leave unconnected
if clock gating is not implemented
in your system
SLEEPHOLDACKn Output Acknowledge signal for SLEEPHOLDREQn. If this Connect to your power
signal is LOW, irrespective of the SLEEPING signal management unit
value, the processor does not advance in execution and
does not perform any memory operations.
SLEEPHOLDREQn Input Request to extend the processor sleeping state regardless

of wake-up events. If the processor acknowledges this
request driving SLEEPHOLDACKn LOW, this
guarantees the processor remains idle even on receipt of
a wake-up event.
ETMPWRUPREQ Output ETM powerup request combined with TRCENA.
WICSENSE[242:0] Output Active HIGH signal. These indicate which input events Connect to low-power control
cause the WIC to generate the WAKEUP signal. logic, or leave unconnected if the
The usable width of this signal is determined by the WIC is not present
WICLINES configuration parameter. Therefore only the
WICSENSE[WICLINES-1:0] bits are implemented and
the remaining bits are driven LOW.
The mapping to input events is:
WICSENSE[242:3] IRQ[239:0].
WICSENSE[2] EDBGRQ.
WICSENSE[1] NMI.
WICSENSE[0] RXEV.
Table 4-31 Power control and sleep interface signals (continued)
WICENREQ Input Active HIGH request for deep sleep to be WIC-based Connect to low-power control
deep sleep. This is driven from the power management logic, or tie LOW if the WIC is not
unit. present
WICENACK Output Active HIGH acknowledge signal for WICENREQ. Connect to low-power control
logic, or leave unconnected if the
WAKEUP Output Active HIGH signal to the power management unit that WIC is not present
indicates a wake-up event has occurred and the
processor system domain requires its clocks and power
restored.
4.20 SysTick signals

The ARMv7-M system timer, SysTick, is a system-agnostic timer implementation for operating
system use.
Software can configure the SysTick timer to select clk as its clock source, or an alternative clock
source.
In the Cortex-M7 processor, the alternative clock source is based on fclk gated by STCLKEN.
If you want to use an asynchronous clock to generate STCLKEN, you must use a synchronizer
circuit. Figure 4-2 shows an example asynchronous clock generating STCLKEN.
If integration is performed without an alternative clock source, tie STCLKEN LOW and tie
STCALIB[25] HIGH.
Table 4-32 shows the CFGSTCALIB[25:0] values required for the software developer using
the SysTick calibration register in the Cortex-M7 NVIC memory map.
Table 4-32 SysTick signals
Name Direction Description Connection information
STCALIB[25] Input NOREF Tie HIGH if STCLKEN has been tied off.
Indicates that no alternative reference clock
source has been integrated.
STCALIB[24] Input SKEW Tie this LOW if the system timer clock, the
external reference clock, or fclk as indicated by
STCALIB[25], can guarantee an exact multiple
of 10ms. Otherwise, tie this signal HIGH.
STCALIB[23:0] Input TENMS For an example, apply the value 0x07A11F if no

Provides an integer value to compute a 10ms reference is implemented, and fclk is 50MHz.
(100Hz) delay from either the reference clock,
or fclk if the reference clock is not implemented.
STCLKEN Input System clock enable signal. SysTick clock enable signal. If software
configures the SysTick timer to use the external
reference clock, then it decrements on each fclk
rising edge for which STCLKEN is HIGH.
Figure 4-2 shows an example asynchronous clock generating STCLKEN.
STCLKEN
D Q D Q D Q D Q
(32,768 enables
per second)
fclk
32,768 Hz
clock source
Figure 4-2 Asynchronous SysTick clock example
For an implementation where no alternative reference clock is provided, and the frequency of
fclk is not computable in hardware, tie:
• STCLKEN LOW.
• CFGSTCALIB[25] HIGH.
• CFGSTCALIB[24:0] LOW.
4.21 Dual-redundant core comparison interface

The dual-redundant core comparison interface is intended for systems implementing functional
safety.
Table 4-33 shows the signals for the dual-redundant core comparison interface.
Table 4-33 Dual-redundant core comparison interface signals
DCCMINP[7:0] Input Dual-redundant core comparison control input If you are implementing dual-redundant cores,
you must connect to your comparison control
DCCMOUT[7:0] Output Dual-redundant core comparison status output logic.
DCCMINP2[7:0] Input Dual-redundant core comparison control input If this interface is not used, tie the inputs LOW
and leave the outputs unconnected.
DCCMOUT2[7:0] Output Dual-redundant core comparison status output
4.22 Test interfaces

See Chapter 6 DFT Integration Guidelines for a description of the DFT and MBIST signals.
4.23 CoreSight system integration

The Cortex-M7 processor optionally includes the Cortex-M7 CTI, and CoreSight ETM-M7 that
are CoreSight compliant devices. It also contains an Instrumentation Trace Macrocell (ITM),
Debug and Watchpoint Trace (DWT), and Flash Patch and Breakpoint (FPB) that can be used
as part of a CoreSight compliant debug and trace system. Read sections CoreSight ROM tables
and Debugger connection and CoreSight discovery if you intend integrating the processor into
a CoreSight compliant debug system.
4.23.1 CoreSight ROM tables
The Cortex-M7 processor includes an internal CoreSight-compliant ROM table,

cortexm7_integration/verilog/cm7_cs_apb_rom_table.v, and debug resources, to enable you to
build CoreSight-compliant debug systems.
The cm7_cs_apb_rom_table.v file is an example APB four-entry CoreSight ROM table that uses
parameters to define its content. If you use this component as a system level ROM table you
must ensure the instantiation of the module uses your own JEP-106 manufacturer ID value and
a part number that uniquely identifies your system.
Arm recommends that you build a CoreSight-compliant system to enable debug tools to identify
the various system components correctly. See the Arm® CoreSight™ Architecture Specification
(v2.0) for more information.
The Cortex-M7 processor ROM table provides pointers to the memory-mapped debug and trace
resources inside the processor. See the Arm® Cortex®-M7 Processor Technical Reference
Manual for more information about the Cortex-M7 processor ROM table and its functionality.
This ROM table is fixed in the processor memory map at address 0xE00FE000 and is not
modifiable.
If you are using the processor as part of a debug system, you must include one, or more,
additional ROM tables within your system to enable a debugger to locate the debug and trace
components inside the processor. Arm recommends that:
• You include a system level ROM table that includes your own JEP-106 ID and part
number values, to enable debuggers to identify your system.
• An external ROM table includes an entry that points to the Cortex-M7 processor ROM at
address 0xE00FE000.
The example low-area debug and trace integration, CORTEXM7INTEGRATIONMCU, contains a system
ROM table. See Appendix G CORTEXM7INTEGRATIONMCU. The Integration Kit includes a
test you can use to verify the ROM table structure in the system. See Chapter 12 Integration Kit
for more information.
4.23.2 Debugger connection and CoreSight discovery
The CoreSight Discovery mechanism allows a compliant debugger to locate and identify all
CoreSight compliant debug components within your system by traversing the ROM tables and
reading each component's ID registers.
When you build your system, you must consider the conditions that require a debugger to
connect to your system and how it might attempt the discovery process.
To be successful, the debugger must have sufficient time to connect to your system without
being reset. If the debugger attempts the discovery process, accesses to the ROM tables and
CoreSight components must also complete successfully.
You must consider how your EPPB bus infrastructure and CoreSight components are reset, and
how your reset controller and any watchdog components interact. You might find it useful to
use the CPUWAIT signal in conjunction with the various reset signals to allow you to reset
your bus infrastructure without allowing the processor to begin executing code immediately.
Until CPUWAIT is deasserted, the processor is effectively being held in reset while allowing
debug slave port. See Table 4-25 on page 4-39.
Chapter 5
TCM Integration
This chapter describes the Cortex-M7 processor TCM interfaces, and how to integrate your
TCM RAMs with the processor. It contains the following sections:
• About TCM integration on page 5-2.
• TCM interface on page 5-4.
• Supported TCM RAM integration flow on page 5-8.
• TCM organization and configuration on page 5-9.
• TCM interface protocol on page 5-10.
• Integrating TCM RAM blocks on page 5-14.
• TCM RAM integration testbench on page 5-16.
TCM Integration
5.1 About TCM integration

The Cortex-M7 processor has two Tightly-Coupled Memory regions, ITCM and DTCM.
Accesses to these regions cause transactions on the corresponding TCM interfaces ITCM,
D0TCM or D1TCM. For more information, see the TCM Interfaces section in the Arm®
Cortex®-M7 Processor Technical Reference Manual.
The interfaces allow you to integrate:

• A simple block of RAM directly.
• A TCM controller that connects to more complex RAM, for example to provide ECC
support.
Note
• The processor might make speculative reads to the TCMs, and if so, does not use the data
returned for these transactions. System designers must not assume that the scope of this
speculation is fixed, or that it can be definitively specified. This behavior might result in
reads to uninitialized memory locations, or repeated reads. Any error or retry indicated for
these reads are ignored.
• A physical RAM must connect to only one TCM interface and must not be shared between
TCM interfaces.
• The processor contains internal arbitration logic that allows data-side accesses, loads and
stores, and instruction fetches to both ITCM and DTCM. Therefore, from a functional
perspective data and code can be stored in either TCM. However for best performance,
place code in the ITCM and data in the DTCM.
5.1.1 Unused TCM interfaces
If you are not using a particular interface, you must tie the associated inputs off.
If you are not using ITCM memory, tie the following macrocell inputs LOW:
• ITCMRDATA[63:0].
• ITCMERR.
• ITCMRETRY.
• ITCMWAIT.
• ITCMMBISTOUT[7:0].
If you are not using DTCM memory, tie all the following macrocell inputs LOW:
• D0TCMRDATA[31:0].
• D0TCMERR.
• D0TCMRETRY.
• D0TCMWAIT.
• D0TCMMBISTOUT[6:0].
• D1TCMRDATA[31:0].
• D1TCMERR.
• D1TCMRETRY.
• D1TCMWAIT.
• D1TCMMBISTOUT[6:0].
TCM Integration
5.1.2 Simple RAM integration
If you are integrating a simple block of RAM onto a TCM interface, ensure your library RAM
satisfies the following requirements:
• All timings must be synchronous to the rising clock edge.
• Chip select, RAM enable, and control are required.
• RAM outputs must not be tristated.
• Byte-write or bit-write enable control is required. If byte-write or bit-write RAM blocks

are not available in your technology library, you must use blocks of byte-wide RAM. This
might increase the overall RAM area.
Integration of RAM onto a TCM interface is described in Integrating TCM RAM blocks on
page 5-14. When you have integrated the RAM, you can use the TCM RAM integration
testbench to test it. See TCM RAM integration testbench on page 5-16 for more information
about using the testbench.
5.1.3 Other TCM integration
If you are integrating anything other than a simple RAM block onto a TCM interface, you must
read TCM interface protocol on page 5-10 to understand the protocol and timing of the TCM
interface signals.
In such cases the TCM RAM integration testbench is not sufficient for testing your system.
TCM Integration
5.2 TCM interface

This section describes the ITCM and DTCM interfaces. The TCM interfaces support the
implementation of external ECC, by providing a retry signal *TCMRETRY. It contains the
following sections:
• ITCM interface.
• DTCM interfaces on page 5-5.
5.2.1 ITCM interface
Table 5-1 shows the signals for the ITCM interface.
Table 5-1 ITCM interface signals
Signal name Direction Phase Description Connection information
ITCMADDR[23:3] Output Address Transfer address for both reads and Connect to ITCM RAMs.
writes. All ITCM accesses are 64-bit
aligned. Bits[2:0] of the address are
permanently 0.
ITCMCS Output Address ITCM RAM select/
ITCMPRIV Output Address Privilege level of access:

LOW User.
HIGH Privileged.
ITCMWR Output Address RAM write enable:

LOW Read access request.
HIGH Write access request.
Valid when ITCMCS is HIGH.
ITCMBYTEWR[7:0] Output Address Byte write strobes. Bit[n] is for

bits[8n+7:8n] of data. Valid when
ITCMCS is HIGH.
ITCMWDATA[63:0] Output Address Write data. Valid on a byte-wise basis

as defined on ITCMBYTEWR.
Memory must ignore otherwise.
ITCMMASTER[3:0] Output Address Encodes the requestor of the current Can be used to optimize operation
access: of memory controllers or
0b0000 Instruction fetch. prefetchers.
0b0001 Data access.
0b0010 Vector fetch on
automated exception
entry.
0b0011 AHB slave access.
0b0100 Debugger access.
0b0101 MBIST access.
0b1001 Software data access
from store queue.
0b1011 AHB slave access from
store queue.
0b1100 Debugger access from
store queue.
TCM Integration
Table 5-1 ITCM interface signals (continued)
Signal name Direction Phase Description Connection information
ITCMMBISTIN[7:0] Output Address MBIST sideband signals to access ECC If ECC is implemented in ITCM
RAM write data. then multiplex this signal with the
output of the ECC generation
logic. This signal must then be
used when an MBIST write
transaction is indicated by the
ITCMMASTER signal.
ITCMRDATA[63:0] Input Response Read data. All data bytes are valid on Connect to ITCM RAMs.
the last cycle of a read response phase.
Ignored by processor on all other
cycles.
ITCMWAIT Input Response Wait signal to extend the current If the memory requires response
response phase: phase wait states then you must
LOW Complete phase. implement control logic to assert
HIGH Extend phase. this signal. If wait states are not
required then this signal must be
tied LOW. See TCM interface
protocol on page 5-10.
ITCMERR Input Response Abort indication: You can decode ITCMMADDR,

LOW No abort. ITCMMASTER, and
HIGH Abort. ITCMPRIV to detect privilege
violations. Tie LOW if abort logic
Can be used for privilege checks for
is not implemented in your system.
example.
ITCMMBISTOUT[7:0] Input Response MBIST sideband signals to access ECC If ECC is implemented in your
RAM read data. ITCM, connect this directly to the
ITCM RAM ECC read value. If
ECC is not implemented, tie these
bits LOW.
ITCMRETRY Input Retry Request to retry access whose read Connect to ECC checking logic. If
response phase completed on the ECC is not implemented, tie this
previous cycle. A typical use is to signal LOW.
request a read transaction to be retried
when an ECC error is detected.
5.2.2 DTCM interfaces
The processor supports two DTCM interfaces, D0TCM and D1TCM. Table 5-2 on page 5-6
shows the signals for both DTCM interfaces.
TCM Integration
Table 5-2 DTCM interfaces
Connection
Signal namea Direction Phase Description
information
D*TCMADDR[23:3] Output Address Transfer address for both reads and writes. Connect to DTCM RAMs.
All DTCM accesses are 32-bit aligned.
Bits[1:0] of the address are permanently set
to 0. Bit[2] selects which DTCM interface a
transaction uses, 0 for D0TCM and 1 for
D1TCM.
D*TCMCS Output Address RAM chip select.
D*TCMPRIV Output Address Privilege level of access:

LOW User.
HIGH Privileged.
D*TCMWR Output Address RAM write enable:

Valid when D*TCMCS is HIGH.
D*TCMBYTEWR[3:0] Output Address Byte write strobes Bit[n] is for bits[8n+7:8n]

of data.
Valid when D*TCMCS is HIGH.
D*TCMWDATA[31:0] Output Address Write data. Valid on a byte-wise basis as

defined on ITCMBYTEWR. Memory must
ignore otherwise.
D*TCMMASTER[3:0] Output Address Encodes the requestor of the current access: Can be used to optimize
0b0000 Instruction fetch. operation of memory
0b0001 Data access. controllers or prefetchers.
0b0010 Vector fetch on automated
exception entry.
0b1001 Software data access from
store queue.
0b1011 AHB slave access from store
queue.
0b1100 Debugger access from store
queue.
D*TCMMBISTIN[6:0] Output Address MBIST sideband signals to access RAM If ECC is implemented in
write data. DTCM then multiplex this
signal with the output of the
ECC generation logic. This
signal must then be used
when an MBIST write
transaction is indicated by
the DTCMMASTER
signal.
D*TCMRDATA[31:0] Input Response Read data. Connect to DTCM RAMs.
TCM Integration
Table 5-2 DTCM interfaces (continued)
Connection
Signal namea Direction Phase Description
information
D*TCMWAIT Input Response Wait signal to extend the current data phase: If the memory requires
LOW Complete phase. response phase wait states
HIGH Extend phase. then you must implement
control logic to assert this
signal. If wait states are not
required then this signal
must be tied LOW. See
TCM interface protocol on
page 5-10.
D*TCMERR Input Response Abort indication for access: You can decode
LOW No abort. DTCMADDR,
HIGH Abort. DTCMMASTER, and
DTCMPRIV to detect
Can be used for privilege checks for
privilege violations. Tie
example.
LOW if abort logic is not
implemented in your
system.
D*TCMMBISTOUT[6:0] Input Response MBIST sideband signals to access ECC If ECC is implemented in
RAM read data. your DTCM, connect this
directly to the DTCM RAM
ECC read value. If ECC is
not implemented, tie these
bits LOW.
D*TCMRETRY Input Retry Request to retry access whose read response Connect to ECC checking
phase completed on the previous cycle. A logic. If ECC is not
typical use is to request a read transaction to implemented, tie this signal
be retried when an ECC error is detected. LOW.
a. Where * is 0 for the D0TCM interface and 1 for the D1TCM interface.
TCM Integration
5.3 Supported TCM RAM integration flow

Figure 5-1 shows the supported TCM RAM integration and validation flow. This enables you
to:
• Identify the TCM organization required, see TCM organization and configuration on
page 5-9.
• Integrate your library RAMs, see Integrating TCM RAM blocks on page 5-14.
• Test if TCM integration is successful, see TCM RAM integration testbench on page 5-16.
Start
Identify TCM RAM organization
Integrate and validate

TCM RAM organization
No TestBench
passes?
Yes
End*
* Proceed with RAM

Validation and Synthesis
Figure 5-1 TCM validation flow
TCM Integration
5.4 TCM organization and configuration

There are two TCM memory regions ITCM and DTCM. You can configure the size of each
from 4KB to 16MB in powers of two increments.
The DTCM memory is split into two RAMs each with its own interface, D0TCM and D1TCM.
This means that two different transactions can be carried out on the DTCM interfaces at the
same time.
The ITCM interface has a 64-bit data width and each DTCM interface has a 32-bit data width.
The DTCM RAMs must use identical configurations. This means they must be the same size
and have the same wait state behavior. This is a requirement for MBIST testing of the RAM
blocks. In functional mode, external logic can assert D*TCMWAIT signals independently of
each other.
When integrating the Cortex-M7 processor into your SoC, you must also set the associated INI*
and CFG* inputs appropriately for your TCM configuration, see Configuration on page 4-39.
TCM Integration
5.5 TCM interface protocol

The TCM interfaces have the following behavior:
• Read transactions consist of an address phase, a response phase and a retry phase.
• Write transactions consist of a write address phase and a response phase.
• The *TCMCS output is always valid and is only asserted during an address phase.
• The *TCMADDR, *TCMWR, *TCMBYTEWR, *TCMMASTER and *TCMPRIV

outputs are only valid during an address phase.
• The *TCMWDATA outputs are only valid during the address phase of a write
transaction. Only the *TCMWDATA byte lanes indicated by the *TCMBYTEWR
output are valid.
• Each interface has a TCMWAIT input that can extend any response phase. This has the
effect of waiting any pipelined address phase.
• The system can assert *TCMWAIT at any time and this input can be used to extend the
address phase or the response phase.
Note
The system must not have a combinatorial path to *TCMWAIT from the address phase
signals, *TCMCS, *TCMADDR, *TCMPRIV, *TCMWR, *TCMBYTEWR,
*TCMWDATA, *TCMMASTER, and *TCMMBISTIN.
• Read data for a read transaction must be returned to the processor on the last cycle of the
response phase.
• Write data is presented to the interface on the write address phase.
• The system can cause the processor to abort a read or write transaction using the
appropriate *TCMERR input that is valid on the last cycle of the response phase. For
example, the system could use the address phase *TCMPRIV value to detect a privilege
violation and abort the transaction.
• The response phase on a write transaction is only used by the system to return an abort
indication using the *TCMERR input. Write data is only valid on a write address.
• The processor can abandon an access when TCMWAIT is HIGH. This means the address
phase signals cannot be guaranteed constant when the current response phase is waited.
Therefore a memory must only commit accesses when its TCMWAIT signal is LOW.
This applies to read and write addresses and write data.
Note
This does not preclude a memory controller speculatively prefetching from a waited read
address.
• The *TCMRETRY signal is sampled by the processor in the retry phase. This phase
cannot be extended and is always the cycle immediately following a completed read
response phase. The *TCMRETRY value is only used by the processor when the
associated TCMCR register RETEN bit is 1. The *TCMRETRY value is ignored by the
processor if the associated *TCMERR value is HIGH in the previous cycle.
TCM Integration
Note
The retry phase only applies to reads.
• The *TCMMBISTIN and *TCMMBISTOUT signals are only used during MBIST
transactions in systems that implement ECC in the TCM RAMs.
• The *TCMMBISTIN outputs are only valid in the address phase of MBIST write
transactions.
• The *TCMMBISTOUT inputs are only valid in the last cycle of the response phase of
MBIST read transactions.
Note
The *TCMMASTER output can be decoded to detect MBIST transactions.
5.5.1 TCM signals and timing
Figure 5-2 shows cycle timing of two reads followed by a write.
Cycle Cycle Cycle Cycle Cycle Cycle

0 1 2 3 4 5
HCLK
*TCMCS
*TCMADDR
*TCMMASTER A0 A1 A2
*TCMPRIV
*TCMWR
*TCMBYTEWR[n]
*TCMWAIT
*TCMRDATA D0 D1
*TCMRERR E0 E1
*TCMWDATA D2
*TCMRETRY R0
Where *TCMBYTEWR[n] is ITCMBYTEWR[7:0], D0TCMBYTEWR[3:0], or D1TCMBYTEWR[3:0]
Figure 5-2 TCM write with two reads
The cycle timings that Figure 5-2 shows are:
Cycle 0 Processor presents read to A0.
Cycle 1 Read to A0 accepted by memory. Memory cannot present D0 so asserts wait.
Cycle 2 Processor samples wait. Response phase for D0 and address phase to A1 are
therefore extended Memory presents D0, E0 and deasserts wait.
TCM Integration
Cycle 3 Processor samples read data D0, error value E0 and presents write of D2 to A2.
Memory presents R0.
Cycle 4 Processor samples wait. Response phase for D1 and write address phase to A2 are
therefore extended. Memory presents D1 and deasserts wait. Processor samples
retry value R0.
Cycle 5 Processor samples read data D1 and error value E1. Memory commits write to
address A2 with data D2.
Figure 5-3 shows cycle timing of a retry phase for a waited read.
Cycle Cycle Cycle Cycle Cycle Cycle

0 1 2 3 4 5
HCLK
*TCMCS
*TCMADDR
*TCMMASTER A0 A1 A2
*TCMPRIV
*TCMWR
*TCMBYTEWR[n]
*TCMWAIT
*TCMRDATA D0
*TCMRERR E0
*TCMWDATA
*TCMRETRY R0
Where *TCMBYTEWR[n] is ITCMBYTEWR[7:0], D0TCMBYTEWR[3:0], or D1TCMBYTEWR[3:0]
Figure 5-3 TCM retry phase for a waited read
The cycle timings that Figure 5-3 shows are:
Cycle 0 Processor presents read to A0.
Cycle 1 Memory accepts read to A0 and asserts the *TCMWAIT signal. The processor
presents a read of A1.
Cycle 2 Memory presents D0, deasserts error and deasserts wait. In parallel with the
processor setup time for D0, memory performs an integrity check of D0.
Cycle 3 Processor samples read data D0, error value E0 and presents read of A2.
Memory accepts read to A1 and asserts the *TCMWAIT signal.
Memory asserts retry, requesting a load retry to A0 because an integrity check
failed, for example an ECC error.
Cycle 4 Processor samples retry request R0 and begins to prepare the retry of A0.
Processor abandons request for A2 and does not present any transaction to the
memory.
TCM Integration
The memory must continue to interface to the processor as normal despite the
retry request.
In particular, it must not make assumptions about the accesses that the processor
is to perform. For example, the processor might not re-present A0 if the original
instruction requesting the access was speculative and not subsequently
committed.
Cycle 5 Processor samples wait. This means the response phase for A1 is extended. The
processor can present the retry of A0 or present another transaction for as long the
wait signal is asserted. It can also drop read data D1 when it is returned.
5.5.2 Using TCM wait states
The TCM interfaces are optimized for direct connection to zero wait-state SRAM. To avoid
impacting operating frequency however, you can insert wait states when integrating with larger
memories. To meet RAM timing, it might be necessary to:
• Increase the length of the RAM data cycle to accommodate RAM access time.
Extending the RAM data cycle requires an extension of all interface read response phases.
This can be done directly with *TCMWAIT.
• Increase the length of the RAM address cycle to accommodate RAM address or write data
setup time. Typically RAM setup time is less critical than RAM access time so this might
not be necessary.
Extending the RAM address cycle requires an extension of both interface read and write
address phases. This is not possible with *TCMWAIT because only response phases can
be directly extended. In this case the system must register all address phase signals,
including write data, when *TCMWAIT is LOW and use these to drive the RAM while
driving *TCMWAIT HIGH from the next cycle until the address cycle is complete.
Divide down the clock to the RAM from the processor CLKIN if either address or data cycle
timing is extended.
The processor must sample all TCM interface input signals safely and meet timing at full
processor frequency to avoid metastability issues that transitions can cause too close to the
processor clock edge. To meet this requirement, the system can AND all RAM read data outputs
with an inverted *TCMWAIT signal using a CDC-safe AND gate.
The use of wait-states has a negative impact on performance and must only be used if absolutely
necessary. It might be better for overall performance if some small blocks of zero wait-state
memory are available for critical code while having larger memory blocks with wait states for
non-critical code.
TCM Integration
5.6 Integrating TCM RAM blocks

This section describes how to integrate your external TCM RAM blocks. Integration of the
TCM RAM blocks is performed outside of the macrocell. Arm provides a testbench to help
check the TCM integration.
Note
If there are no TCM RAM blocks in your design, you must tie all TCM inputs to the processor
LOW. See About TCM integration on page 5-2.
5.6.1 Integration
TCM RAM integration takes place outside of the macrocell. The following is a guide to aid your
integration process:
1. Instantiate the RAMs above the top-level Cortex-M7 module, CORTEXM7INTEGRATIONCS, and
connect them appropriately following the guidelines set out in TCM organization and
configuration on page 5-9.
2. All TCM control signals are active HIGH. If your RAM blocks have active LOW control
inputs, you must invert the outputs from the macrocell before connecting them to the
RAMs.
3. Tie off unused error data inputs to the macrocell, see TCM interface on page 5-4.
4. Tie off the TCM configuration inputs to:

Configure the ITCM and DTCM sizes, see Table 4-26 on page 4-40.
5. Check that the TCM RAM integration is correct by running the TCM RAM integration
testbench on page 5-16.
5.6.2 Integrating TCM RAMs
The following shows an example instance of a 64KB ITCM constructed using bit-writable
RAM:
SRAM8192x32 u_itcm_lower
(
.CLK (HCLK),
.A (ITCMADDR[15:3]),
.Q (ITCMRDATAN[31:0]),
.D (ITCMWDATA[31:0]),
.CEN (ITCMCS),
.WEN ({
{8{ITCMBYTEWR[3]}},
{8{ITCMBYTEWR[2]}},
{8{ITCMBYTEWR[1]}},
{8{ITCMBYTEWR[0]}}
})
);
SRAM8192x32 u_itcm_upper
(
.CLK (HCLK),
.A (ITCMADDR[15:3]),
.Q (ITCMRDATA[63:32]),
.D (ITCMWDATA[63:32]),
.CEN (ITCMCS),
.WEN ({
{8{ITCMBYTEWR[7]}},
TCM Integration
{8{ITCMBYTEWR[6]}},
{8{ITCMBYTEWR[5]}},
{8{ITCMBYTEWR[4]}}
})
);
assign CFGITCMSZ = 4'h7;
The following example shows a 64KB DTCM.

SRAM8192x32 u_d0tcm
(
.CLK (HCLK),
.A (D0TCMADDR[15:3]),
.Q (D0TCMRDATA[31:0]),
.D (D0TCMWDATA[31:0]),
.CEN (D0TCMCS),
.WEN ({
{8{D0TCMBYTEWR[3]}},
{8{D0TCMBYTEWR[0]}}
})
);
SRAM8192x32 u_d1tcm
(
.CLK (HCLK),
.A (D1TCMADDR[15:3]),
.Q (D1TCMRDATA[31:0]),
.D (D1TCMRDATA[31:0]),
.CEN (D1TCMCS),
.WEN ({
{8{D1TCMBYTEWR[0]}}
})
);
assign CFGDTCMSZ = 4'h7;
TCM Integration
5.7 TCM RAM integration testbench

The TCM RAM integration testbench checks that you have performed TCM RAM integration
correctly. Stimulus is generated, and results are checked, by a dummy CORTEXM7 processor
module provided with the testbench. The steps to run the testbench are:
1. Complete TCM RAM integration.
2. Run the TCM RAM integration testbench. You must run the TCM RAM integration
testbench from the logical/testbench/ram_integration_tb/CORTEXM7TCM/tbench directory.
cd <path>/logical/testbench/ram_integration_tb/CORTEXM7TCM/tbench
3. Edit the CORTEXM7_tcm_ram_testbench.vc file to point to the directories that contain your
TCM RAM and TCM integration modules.
4. Open the CORTEXM7_tcm_ram_testbench.v file and replace the TCM Level module
instantiation with an instantiation of your TCM RAM integration module.
5. If you are not using TCM ECC, comment out the line containing +define+TEST_TCM_ECC in
the CORTEXM7_tcm_ram_testbench.vc file.
6. If you are not using zero wait state TCMs then you must set the TEST_ITCM_RAM_WS and
TEST_DTCM_RAM_WS macros in the CORTEXM7_tcm_ram_testbench.vc file to your required
number of wait states.
7. Compile and run the TCM RAM integration testbench using one of:
• a ModelSim simulator:
% vlib work
% vlog +nospecify -f CORTEXM7_tcm_ram_testbench.vc CORTEXM7_tcm_ram_testbench.v
% vsim +notimingchecks +TCMecc -c CORTEXM7_tcm_ram_testbench -do "run -all"
• a VCS simulator:
% vcs +vcs+lic+wait +nospecify +v2k -cc gcc -CFLAGS "-O3 -I${VCS_HOME}/include" -Mupdate -f \
CORTEXM7_tcm_ram_testbench.vc CORTEXM7_tcm_ram_testbench.v
% simv +TCMecc +vcs+lic+wait +vcs+flush+log
• an IUS simulator:
% irun -access +rc -licqueue -exit +TCMecc +nospecify +notimingchecks -f CORTEXM7_tcm_ram_testbench.vc \
CORTEXM7_tcm_ram_testbench.v
If your TCM RAM integration has been successful, the simulation completes with a
message similar to:
Summary
=======
TCM Configuration
-------------------
ITCM size = 64kB
DTCM size = 64kB
ITCM error code scheme: ECC
DTCM error code scheme: ECC
TCM Integration Tests
-----------------------
ITCM_RAM word test passed; bit test passed
DTCM_D0RAM word test passed; bit test passed
RAM integration passed. Test completed with no errors

If your TCM RAM integration is unsuccessful, the simulation completes and reports
which RAMs failed integration. For example, if the ITCM RAM test failed, you might get
the following summary:
TCM Integration
Summary
=======
TCM Configuration
-------------------
ITCM size = 64kB
DTCM size = 64kB
ITCM error code scheme: ECC
DTCM error code scheme: ECC
TCM Integration Tests
-----------------------
ITCM_RAM word test passed; bit test passed
DTCM_D0RAM word test FAILED; bit test FAILED
!!! RAM integration FAILED. Test completed with errors !!!
The simulation also reports expected and actual RAM read data for RAMs that fail. Use
this information to assist you in debugging errors.
For information on how the tests are performed, and guidance on debugging, see TCM RAM
integration tests.
5.7.1 TCM RAM integration testbench limitations
The TCM RAM integration testbench is not able to test any of your system implementation
specific logic that you might have integrated with the TCM interfaces. This means you must
develop your own tests to test the integration of this logic. Arm recommends that you consider
modifying the integration kit to do this. See Chapter 12 Integration Kit for more information.
The following are not covered by the testbench:
• *TCMPRIV, *TCMERR, *TCMWAIT, *TCMRETRY and *TCMMASTER ports.
• Any ECC logic integrated with the TCM interfaces.
5.7.2 TCM RAM integration tests
This section describes the two tests, word test and bit test, that are performed for each Data
RAM. If there are any integration errors, one or both of these tests fails. The status of each of
the tests is reported in the testbench summary.
Word test This test:

• Writes unique data to each RAM location.
• Reads back each location.
• Checks that the data read back matches the expected values.
This test checks that the instantiated RAM is the correct size, and that the address
connections are correct. All RAM enables are driven HIGH throughout this test.
All write enables and byte write enables are driven HIGH during writes and LOW
during reads. This means that the test does not detect shorts between these signals,
only open circuits. If the read data is X, this indicates that one or more RAM
signals are either open circuit or wrongly connected.
Bit test This test walks a 1 across the RAM width, checking that all data in and data out
connections are correct. This is done in two passes:
• The first pass drives all enables HIGH, to test data in and data out
connectivity.
• The second pass only asserts the enable for the portion that is being written
to or read from. Therefore, this test detects shorts between enables. A
failure pattern is driven to the RAM portions not being written to. The read
address is driven to 0 during this test.
TCM Integration
The write address is driven to twice the RAM size. This addresses location
0 if the RAM is the correct size. However, if the RAM is too large, the read
and write addresses differ and the test fails, indicating the RAM size
inconsistency.
Chapter 6
DFT Integration Guidelines
This chapter describes the DFT integration guidelines for SoC integration. It contains the
following sections:
• About DFT integration on page 6-2.
• ATPG Test Interface on page 6-3.
• MBIST Information format files on page 6-5.
• MBIST Interface on page 6-7.
6.1 About DFT integration

This chapter describes the issues that relate to DFT that you must consider when you integrate
the processor into your SoC design. The processor supports scan and Automatic Test Pattern
Generation (ATPG) techniques for production test vectors, and Memory Built-In Self Test
(MBIST). The macrocell also uses scan compression to reduce the test pattern volume and test
time and uses a scan wrapper to isolate the macrocell and provide testability of the shadow logic
outside the macrocell.
This chapter describes:

• Test interface on the macrocell.
• Production test modes of the macrocell.
• Scan configuration of the macrocell.
• MBIST interfaces.
• Types of tests supported.
When you design the DFT strategy for your SoC, you must:
• Consider access to the processor signals for control and observation during test.
• Ensure that, during production test, you can control the processor for all required test
modes.
Failure to do this might make the processor impossible to test. There are two cases for
controlling the processor signals:
• The dynamic signals that must be controlled on a cycle-by-cycle basis must be either:
— Brought directly to the top-level of the chip for control by the tester.
— Multiplexed with normal functional signals and made available during the
manufacturing test modes using a test mode controller.
This case also applies to all output signals that are compared during test modes.
• The control signals that are static during a test can be driven by an SoC test controller or
directly connected to a top-level SoC pin.
6.2 ATPG Test Interface

This section describes the ATPG test signals, scan test ports, and how to use them.
6.2.1 Scan test ports
Table 6-1 describes the scan test ports.
Table 6-1 Scan test ports
DFTSE Input Scan enable. Disables internal clock gating. These signals must be LOW
during functional mode
DFTRSTDISABLE Input Synchronized resets disabled.
DFTRAMHOLD Input RAM hold data enable.
DFTSE
The scan enable signal, DFTSE, activates the clock enables of the architectural clock gates to
ensure that all scan cells receive valid clocks during shift mode.
Arm expects implementers to also use this signal as the primary scan enable signal to:
• Control whether a register is in shift or capture mode.
• Enable the overrides to all RTL clock gates and any clock gates that synthesis adds.
Because the scan enable signal only controls the scan function that is in the implementation
model, it must be disabled during formal equivalence checking between the gate-level model
and the RTL. Formal equivalence checking cannot check the scan chain shift path or the
override on the clock gates inserted during implementation.
DFTRSTDISABLE
The reset logic in the RTL enables asynchronous assertion and deassertion. The reset
synchronization structure is controlled by the top-level input DFTRSTDISABLE to allow for
safely shifting scan chains and for testing the functional deassertion of reset. See Figure 6-1.
DFTRSTDISABLE To asynchronous
Reset synchronizer resettable flip-flops
VDD
D Q D Q D Q
SI SI SI
R R R
Reset
Reset repeater
Figure 6-1 Reset logic
It is intended that this input be controlled during ATPG in a similar way to the scan enable
signal, DFTSE. This signal must eventually be driven LOW during capture to obtain full test
coverage of the asynchronous reset inputs to the flip-flops downstream from the synchronizers.
If this signal is disabled during capture for a single pattern set, it can make reset problems easier
to diagnose on the tester. The reset pins must be controlled like clock signals for the ATPG tool
to pick up coverage on the reset inputs to the synchronizers themselves. The
DFTRSTDISABLE signal must not change state during capture. This can result in failing
patterns because of race conditions in the reset logic.
Note
Arm recommends that you do not connect the DFTSE and DFTRSTDISABLE inputs together
because it prevents the tester from generating patterns with the resets blocked during the capture
cycles.
The ATPG tool might require special commands to test this structure. See the ATPG tool
documentation or EDA support for information about the commands and syntax to use.
ATPG delay tests that are created with an inactive DFTRSTDISABLE might propagate
at-speed reset assertions that are multicycled in the implementation flow. Only the deassertion
of reset can be tested at-speed. If your ATPG tool does not read in SDF annotation during ATPG
generation, you might have to avoid the potential for patterns that include internal at-speed reset
assertions. To prevent at-speed reset assertions, the reset synchronizer flops must be properly
constrained to inactive reset states during at-speed pattern generation if DFTRSTDISABLE is
inactive.
DFTRAMHOLD
The DFTRAMHOLD signal disables the write enables to the RAMs, so it effectively holds the
data in the RAMs. Figure 6-2 shows the logic function.
DFTRAMHOLD signal
Write enable signal to RAM
Functional Write enable signal
Figure 6-2 DFTRAMHOLD logic
This capability is useful in the following scenarios:

• To maintain the value in the RAMs during tests such as IDDQ.
• Testing shadow logic of the RAMs by testing through the RAMs.
ATPG tools prefer the data in the RAMs to be static during shift. In this scenario, the tester
sets DFTRAMHOLD and DFTSE HIGH during shift, and then LOW during capture.
Use of DFTRAMHOLD significantly improves test coverage and test pattern reduction when
implementations do not include embedded scan inside their RAM macros.
6.3 MBIST Information format files

An MBIST information format (MBIF) file is a human-readable and machine-readable
description of the MBIST interface and the logical MBIST memory array attributes for a
specific configuration of the processor. See Memory arrays on page 6-11 for information about
the MBIST memory array attributes. MBIF files are EDA-tool agnostic and can be used to help
automate MBIST controller generation.
You can generate the MBIF file for your processor memory configuration using the
create_mbist_info_files.pl script in the logical/cortexm7_integration/mbist_info_files
directory. To generate an MBIF file, type the following command in the mbist_info_files
directory.
create_mbist_info_files.pl -outdir <outdir> -ITCM <ITCM size> -DTCM <DTCM size> -ICache
<ICache size> -DCache <DCache size> -Cacheecc <Cacheecc> -TCMecc <TCMecc> -ITCMws
<ITCMws> -DTCMws <DTCMws>
where:
• <outdir> is an optional output directory in which the MBIF file is generated. The current
directory is the default.
• <ITCM size> is the ITCM size in KBytes. Valid values are: 0, 4, 8, 16, 32, 64, 128, 256,
512, 1024, 2048, 4096, 8192, 16384.
• <DTCM size> is the DTCM size in KBytes. Valid values are: 0, 4, 8, 16, 32, 64, 128, 256,
512, 1024, 2048, 4096, 8192, 16384.
• <ICache size> is the ICache size in KBytes. Valid values are: 0, 4, 8, 16, 32, 64.
• <DCache size> is the DCache size in KBytes. Valid values are: 0, 4, 8, 16, 32, 64.
• <Cacheecc> is cache ECC present:

— 0 = cache ECC not present.
— 1 = cache ECC present.
• <TCMecc> is TCM ECC present:

— 0 = TCM ECC not present.
— 1 = TCM ECC present.
• <ITCMws> is the number of ITCM wait states. The value must be greater than or equal to 0.
• <DTCMws> is the number of DTCM wait states. The value must be greater than or equal to 0.
Note
All command line options must be present, except for -outdir.
The create_mbist_info_files.pl script generates an MBIF file named

CORTEXM7INTEGRATIONCS_<options>.mbif
Where <options> are the values of the non-zero command line options used to generate the file.
For example, an MBIF file named CORTEXM7INTEGRATIONCS_cacheecc_ICache32k_DCache32k.mbif

is generated when the following command line options are used:
create_mbist_info_files.pl -ITCM 0 -DTCM 0 -ICache 32 -DCache 32 -Cacheecc 1 -TCMecc 0
-ITCMws 0 -DTCMws 0
Note
If your TCM ECC syndrome widths are greater than the default values, you must change the
TCM memory array width values in the generated MBIF file accordingly.
6.4 MBIST Interface

This section describes the:
• MBIST Interface signals on page 6-8.
• Memory arrays on page 6-11.
• MBIST array cycle timing on page 6-18.
• MBIST interface timing on page 6-19.
• MBIST ALL mode on page 6-23.
6.4.1 MBIST Interface signals
Table 6-2 shows the signals for the MBIST interface.
Table 6-2 MBIST interface signals
MBISTREQ Input MBIST mode request. Connect to external MBIST

controller
MBISTACK Output MBIST mode acknowledge.
MBISTADDR[20:0] Input Logical address for transfer.
MBISTINDATA[77:0] Input Write data in.
MBISTOUTDATA[77:0] Output Read data out.
MBISTWRITEEN Input Write enable.
MBISTREADEN Input Read enable.
MBISTARRAY[4:0] Input Memory array selector.
MBISTBE[9:0] Input Byte or bit write enable.
MBISTCFG[3:0] Input MBIST ALL Mode configuration:

[0] Enables ITCM MBIST ALL mode.
[1] Enables DTCM MBIST ALL mode.
[2] Enables I-Cache MBIST ALL mode.
[3] Enables D-Cache MBIST ALL mode.
nMBISTRESET Input MBIST reset.

Resets all logic and is equivalent to nPORESET.
Assert this signal for at least six CLKIN cycles.
MBISTIMPERR[2:0] Output MBIST error signal used during online MBIST:

[0] Processor attempted to access memory
that is currently selected by
MBISTARRAY.
Note
Bit[0] is only used in the software
assisted online test use case. It must be
ignored in the software transparent use
case.
[1] Response phase error signal value,

*TCMERR, of TCM under test. This
bit is LOW when a TCM is not
selected by MBISTARRAY.
[2] Indicates that the memory selected by
the MBISTARRAY signal does not
exist in the processor implementation.
MBISTREQ
The MBISTREQ signal requests the Cortex-M7 processor logic enables and configures itself
to run MBIST testing through the MBIST interface. MBISTREQ must remain asserted
throughout the entire MBIST test. When MBISTREQ is LOW the processor is in functional
mode.
Note
Unless online MBIST is used, MBISTREQ must be driven LOW when the processor is in
functional mode. See the Arm® Cortex®-M7 Processor Safety Manual for more information
about online MBIST.
MBISTACK
After asserting MBISTREQ, the MBISTACK signal indicates that the MBIST pipeline of the
processor is in MBIST mode. There must be a minimum of four core clock cycles after
MBISTACK is asserted before any read or write array operations can be delivered to the
MBIST interface.
MBISTADDR[20:0]
The MBISTADDR signal provides a right-justified logical address to be supplied to the array
under test. Table 6-5 on page 6-14 shows the MBISTADDR bit assignments for various RTL
configuration parameters.
MBISTINDATA and MBISTOUTDATA
The MBISTINDATA signal provides incoming write data to the array under test. The
MBISTOUTDATA bus provides the returning read data after pipeline depth core clock cycles.
Table 6-13 on page 6-18 shows the pipeline depth for each logical array.
MBISTWRITEEN and MBISTREADEN
These signals are provided as separate controls for the write and read RAM operations:
• When MBISTWRITEEN is asserted, a write operation occurs and the read data for that
transaction is not guaranteed to have predictable results.
• When MBISTREADEN is asserted, a read operation occurs, and the write data for that
transaction is ignored.
No operation occurs if both signals are LOW, and it is illegal for both signals to be HIGH.
MBISTARRAY[4:0]
The MBISTARRAY signal selects the logical array for access by the interface. A logical array
can consist of one or more physical RAMs. The MBISTARRAY signal must not change state
when valid MBIST transactions are in the MBIST pipeline. There must be four clock cycles
after changing its value before sending the first MBIST transaction into the pipeline. See
Table 6-5 on page 6-14.
Note
You must use only valid MBISTARRAY encodings listed in Table 6-5 on page 6-14. Behavior
is UNPREDICTABLE when reserved encodings are used.
MBISTBE[9:0]
The MBISTBE signal allows the MBIST controller to independently control bit and byte write
enables for the array under test. For information about MBISTBE signal positions and mapping
to the MBISTINDATA signal, see Table 6-5 on page 6-14.
MBISTCFG[3:0]
The MBISTCFG signal allows MBIST ALL mode to be enabled on the memories individually.
Bits 0-3 individually enable MBIST ALL mode for the ITCM, DTCM, instruction cache and
data cache memories respectively. When a MBISTCFG bit is HIGH, MBIST ALL mode is
enabled for the memory associated with that bit. When it is LOW normal MBIST ALL mode is
disabled for the associated memory.
All MBISTCFG bits must be set LOW when production MBIST testing is not being carried out.
For more information on the MBIST modes, see MBIST ALL mode on page 6-23.
nMBISTRESET
This active-LOW signal overrides the system resets when the MBISTREQ is HIGH. To move
the processor into MBIST mode nMBISTRESET must be asserted for a minimum of two clock
cycles.
MBISTIMPERR[2:0]
The MBISTIMPERR signal is a Cortex-M7 processor specific extension to the Arm MBIST
interface protocol. It is for use during online MBIST testing and must be ignored during
production MBIST testing. The MBISTIMPERR signal is only valid when MBISTACK is
asserted.
The meaning of each MBISTIMPERR bit is as follows:
MBISTIMPERR[0]
Indicates that a processor attempted to access a memory that is currently
selected by MBISTARRAY. This bit is intended to be used when a
memory is tested for a long period of time and the memory is disabled by
software first, known as software assisted testing. Therefore, no software
accesses to the memory under test are expected. This bit must be ignored
for short burst MBIST testing in which a memory is automatically locked
by MBSITREQ, known as software transparent testing. The meaning of
this bit is as follows:
LOW No contention.
HIGH Contention occurred.
MBISTIMPERR[1]
TCM response phase error signal xTCMERR from a memory currently
selected by MBISTARRAY. Only the xTCMERR signal value in the
response phase is used, otherwise MBISTIMPERR[1] is LOW. This bit
is LOW when a TCM is not selected by MBISTARRAY. When the
DTCM is targeted, the value is the logical OR of the D1TCMERR and
D0TCMERR signals. When the ITCM is targeted, the value is
ITCMERR:
LOW xTCMERR is LOW.
HIGH xTCMERR is HIGH.
MBISTIMPERR[2]
Indicates that the memory selected by MBISTARRAY does not exist in
the processor configuration. The MBISTACK signal is still asserted if an
invalid memory is selected. The MBISTIMPERR[2] signal is asserted
for the conditions given in Table 6-3.
Table 6-3 MBISTIMPERR[2] conditions
MBISTARRAY[4:0] Primary memory accessed MBISTIMPERR[2] asserted when
000xx ITCM CFGITCMSZ = 0
001xx DTCM CFGDTCMSZ = 0
01xxx D-cache DCACHE parameter = 0
10xxx I-cache ICACHE parameter = 0
11xxx Reserved -
It is possible for more than one error to be indicated at a time. This signal can change every clock
cycle, even if a transaction lasts for more than one clock cycle.
6.4.2 Memory arrays
This section describes the TCM, instruction and data cache arrays. It contains the following
sections:
• TCM arrays.
• Data cache arrays on page 6-15.
• Instruction cache arrays on page 6-17.
TCM arrays
This section describes the ITCM and DTCM arrays. Because D0TCM and D1TCM are the same
size and have the same number of wait states, they are both tested in parallel. The address and
control signal values from the MBIST controller are duplicated on both DTCM interfaces.
Separate data and byte enable values are provided for each DTCM interface.
D0TCM and D1TCM data are mapped to the lower and upper 32 bits of the MBIST interface
data signals respectively.
Table 6-13 on page 6-18 shows the internal pipeline depth, RAM cycles and total cycles for an
MBIST access. The RAM cycles are for a zero wait state RAM and if wait states are required
you must ensure the total cycles increases accordingly.
The external TCM interfaces can support wait states. If your implementation requires this the
MBIST controller must make longer transactions to accommodate this. See Multicycle RAM
MBIST operations on page 6-22 for the timing of transactions to memories that require wait
states.
The TCM interface error and retry signals are ignored during production MBIST testing.
You can implement ECC in the TCMs using external ECC logic and ECC RAMs. The TCM
interfaces include MBIST in and out data signals for use in ECC RAM implementations,
Table 6-4 on page 6-13 shows these signals and how they are mapped. TCM MBIST connections
to ECC RAM on page 6-12 shows an example of how to connect the ECC logic and RAM to a
TCM interface.
Cortex-M7 Processor
xTCM DATA
RAM
xTCMADDR A
xTCMWDATA WD
xTCMRDATA RD
xTCM ECC
RAM
ECC Logic A
0
WD
xTCMMBISTIN 1
xTCMMBISTOUT RD
==
xTCMMASTER MBIST
Figure 6-3 TCM MBIST connections to ECC RAM
If the TCM ECC RAMs are wider than these TCM MBIST data signals, the in and out data
signals from an MBIST controller can be made wider and the additional bits pipelined externally
to and from the TCM ECC RAMs, to match the internal Cortex-M7 processor MBIST pipeline
depth for TCM accesses.
Figure 6-4 on page 6-13 shows an example of how this can be done for the ITCM interface if a
9-bit wide ECC RAM is implemented. Therefore, two additional bits must be added to the
MBIST controller data signals and these bits must be pipelined externally to the Cortex-M7
processor to connect to the ECC RAM.
Cortex-M7 Processor
MBIST Controller
OUTDATA[79:0] MBISTINDATA[77:0]
INDATA[79:0] MBISTOUTDATA[77:0] ITCM ECC RAM
ITCMMBISTINDATA[7:0] WD[9:0]
ITCMMBISTOUTDATA[7:0] RD[9:0]
[79:78] Q D [9:8]
[79:78] D Q [9:8]
Figure 6-4 Example ITCM MBIST ECC data extension
Table 6-4 shows the TCM logical arrays.
Table 6-4 TCM logical arrays
Data Mapping Data Mapping

MBISTARRAY
Memory
Encoding
MBIST Data TCM Data MBISTBEa MBISTINDATA
ITCM 0b00000 MBISTINDATA[63:0] ITCMWDATA[63:0] [0] [7:0]

MBISTOUTDATA[63:0] ITCMRDATA[63:0]
[1] [15:8]
[2] [23:16]
[3] [31:24]
[4] [39:32]
[5] [47:40]
[6] [55:48]
[7] [63:56]
MBISTINDATA[71:64] ITCMMBISTOUT[7:0] - -
MBISTOUTDATA[71:64] ITCMMBISTIN[7:0]
Table 6-4 TCM logical arrays (continued)
Data Mapping Data Mapping

MBISTARRAY
Memory
Encoding
MBIST Data TCM Data MBISTBEa MBISTINDATA
D0TCM 0b00100 MBISTINDATA[31:0] D0TCMWDATA[31:0] [0] [7:0]

and MBISTOUTDATA[31:0] D0TCMRDATA[31:0]
[1] [15:8]
D1TCM
[2] [23:16]
[3] [31:24]
MBISTINDATA[63:32] D1TCMWDATA[31:0] [4] [39:32]

MBISTOUTDATA[63:32] D1TCMRDATA[31:0]
[5] [47:40]
[6] [55:48]
[7] [63:56]
MBISTINDATA[70:64] D0TCMMBISTOUT[6:0] - -
MBISTOUTDATA[70:64] D0TCMMBISTIN[6:0]
MBISTINDATA[77:71] D1TCMMBISTOUT[6:0] - -
MBISTOUTDATA[77:71] D1TCMMBISTIN[6:0]
a. MBISTBE[9:8] are unused when the selected target array is either the ITCM or the DTCM.
The MBISTADDR signal has a one-to-one mapping to the address signals, xTCMADDR, on
the TCM interfaces.
Table 6-5 shows TCM sizes and address mapping.
Table 6-5 TCM arrays locations and address mapping
MBISTADDR
Total test
TCM sizea
locationsb
ITCM D1TCM and D0TCM
4KB 512 [8:0] [8:0]
8KB 1024 [9:0] [9:0]
16KB 2048 [10:0] [10:0]
32KB 4096 [11:0] [11:0]
64KB 8192 [12:0] [12:0]
128KB 16384 [13:0] [13:0]
256KB 32768 [14:0] [14:0]
512KB 65536 [15:0] [15:0]
1MB 131072 [16:0] [16:0]
2MB 262144 [17:0] [17:0]
Table 6-5 TCM arrays locations and address mapping (continued)
MBISTADDR
Total test
TCM sizea
locationsb
ITCM D1TCM and D0TCM
4MB 524288 [18:0] [18:0]
8MB 1048576 [19:0] [19:0]
16MB 2097152 [20:0] [20:0]
a. Size of each memory type, ITCM or DTCM. The D0TCM

and D1TCM are each half the DTCM size.
b. Number of test locations for each memory type, ITCM or
DTCM.
Note
The same address is output on both DTCM interfaces.
Data cache arrays
This section describes the structure of the data caches with or without ECC and how the signals
of the MBISTINDATA and MBISTOUTDATA signals are used on the these arrays.
Data cache data memory

The data memory is constructed from eight RAM banks, 0-7. Each bank is 32 bits
wide without ECC and 39 bits wide with ECC. Each bank has four byte enables
for the data field and one for the ECC field, if present. Two banks are tested in
parallel with a common address value shown by the address index column and
separate data and ECC values. Even banks are mapped to data bits[31:0] and odd
banks mapped to the data bits[63:32]. Even and odd bank ECC values are mapped
to data bits[70:64] and [77:71] respectively. A pair of banks are combined into
one MBIST array and each is selected by the MBISTARRAY signal. This means
the data memory is divided into four MBIST arrays.
Data cache tag memory

The tag memory is constructed from four logical RAM banks, 0 to 3, and is
between 22 and 33 bits wide depending on cache size and ECC configuration.
Each bank is tested individually and therefore each has a separate
MBISTARRAY encoding, see Table 6-6 on page 6-16.
Table 6-6 shows data cache data tag array mapping.
Table 6-6 Data cache data tag array mapping
MBIST{IN/OUT}DATA to RAM data mapping
Memory Cache size ECC Data
MBIST RAM MBIST RAM
Data cache tag RAM 4KB [70:64] [32:26] [25:0] [25:0]
8KB [31:25] [25:1] [24:0]
16KB [30:24] [25:2] [23:0]
32KB [29:23] [25:3] [22:0]
64KB [28:22] [25:4] [21:0]
Table 6-7 shows data cache data array mapping.
Table 6-7 Data cache data array mapping
MBIST{IN/OUT}DATA to RAM data mapping
Odd banks Even banks

Memory Cache size
ECC Data ECC Data
MBIST RAM MBIST RAM MBIST RAM MBIST RAM
Data cache data RAM 4KB [77:71] [38:32] [64:32] [31:0] [70:64] [38:32] [31:0] [31:0]
8KB
16KB
32KB
64KB
Table 6-8 shows data cache arrays RAM bank mapping.
Table 6-8 Data cache arrays RAM bank mapping
Memory MBISTARRAY encoding RAM bank
Data cache tag RAM 0b01000 0
0b01001 1
0b01010 2
0b01011 3
Data cache data RAM 0b01100 1, 0
0b01101 3, 2
0b01110 5, 4
0b01111 7, 6
Table 6-9 shows data arrays byte enable mapping.
Table 6-9 Data cache arrays byte enable mapping
Memory MBISTBE MBISTINDATA
Data cache tag RAM - -
Data cache data RAM [0] [7:0]
[1] [15:8]
[2] [23:16]
[3] [31:24]
[4] [39:32]
[5] [47:40]
[6] [55:48]
[7] [63:56]
[8] [70:64]
[9] [77:71]
Table 6-10 shows data cache arrays address mapping, test locations.
Table 6-10 Data cache arrays address mapping, test locations
Total test
Memory Cache Size MBISTADDR
locations
Data cache tag RAM 4KB 128 [4:0]
8KB 256 [5:0]
16KB 512 [6:0]
32KB 1024 [7:0]
64KB 2048 [8:0]
Data cache data RAM 4KB 512 [6:0]
8KB 1024 [7:0]
16KB 2048 [8:0]
32KB 4096 [9:0]
64KB 8192 [10:0]
Instruction cache arrays
The instruction cache contain two logical RAM banks for the data memory and two logical
RAM banks for the tag memory. The data banks are 64 bits without ECC or 72 bits with ECC.
The instruction cache memories do not have byte enables. The tag banks are 18 bit without ECC
or 29 bits wide with ECC.
Table 6-11 shows instruction cache data logical array mapping. No MBISTBE enable bits
required.
Table 6-11 Instruction cache arrays
MBIST{IN/OUT}DATA to RAM data mapping MBISTADDR

Total
Memory Cache Size Test ECC Data Index
locations
MBIST RAM MBIST RAM
Instruction cache tag RAM 4KB 128 [28:22] [28:22] [21:0] [21:0] [5:0]
8KB 256 [28:22] [27:21] [21:1] [20:0] [6:0]
16KB 512 [28:22] [26:20] [21:2] [19:0] [7:0]
32KB 1024 [28:22] [25:19] [21:3] [18:0] [8:0]
64KB 2048 [28:22] [24:18] [21:4] [17:0] [9:0]
Instruction cache data RAM 4KB 512 [71:64] [71:64] [63:0] [63:0] [7:0]
8KB 1024 [8:0]
16KB 2048 [9:0]
32KB 4096 [10:0]
64KB 8192 [11:0]
Table 6-12 shows instruction cache arrays RAM bank mapping.
Table 6-12 Instruction cache arrays RAM Bank Mapping
Memory MBISTARRAY RAM Bank
Instruction cache tag RAM 0b10000 0
0b10001 1
Instruction cache data RAM 0b10100 0
0b10101 1
6.4.3 MBIST array cycle timing
Table 6-13 shows MBIST array cycle timing for TCM arrays and data and instruction cache
arrays.
Table 6-13 MBIST array cycle timing
Memory Pipeline Depth RAM Cycles Total Cycles
ITCM 2 1a 3a
D0TCM
D1TCM
Table 6-13 MBIST array cycle timing (continued)
Memory Pipeline Depth RAM Cycles Total Cycles
Instruction cache tag RAM 3 1 4
Instruction cache data RAM
Data cache tag RAM
Data cache data RAM
a. This is for zero wait states.
6.4.4 Other signals used during production MBIST testing
All input signals are not required to be controlled during production MBIST testing, except for
the MBIST interface signals and some additional signals listed in Table 6-14. During MBIST
testing, the TCMWAIT input for the target TCM must be LOW at the start of each TCM access.
If a TCM requires wait states, the TCMWAIT signal for the target TCM must be asserted
during the data phase as normal. For MBIST ALL mode testing, the TCMWAIT signal does
not have to be LOW at the start of a TCM access when the TCM is not the target array.
Table 6-14 Other signals used during MBIST testing
Port name Direction Function Comment
CLKIN Input Processor clock MBIST controller must be connected to

this clock
CLKEN Clock enables Must be driven HIGH during the entire

MBIST test
FCLKEN
HCLKEN
nPORESET Powerup reset
nSYSRESET System reset
DFTSE DFT control signals Must be driven LOW during MBIST

testing
DFTRSTDISABLE
DFTRAMHOLD
6.4.5 MBIST interface timing
This section describes the steps required for entering and exiting production MBIST mode
before any MBIST operations can be processed by the Cortex-M7 processor. It also describes
the MBIST interface timings. It contains the following:
• Production MBIST mode entry and exit on page 6-20.
• Single-cycle RAM MBIST operation on page 6-21.
• Multicycle RAM MBIST operations on page 6-22.
Production MBIST mode entry and exit
The following steps are required before any MBIST operations can be processed by the
Cortex-M7 processor during production testing. It is assumed that the core clock is stable and
operating at the required test frequency:
1. Assert the MBISTREQ signal and keep it asserted for the duration of the MBIST testing.
2. Drive the MBISTWRITEEN and MBISTREADEN signals LOW. Arm recommends

that you drive the remaining interface signals to non-X to prevent pessimistic Verilog
simulation failures.
3. Assert the nMBISTRESET signal for at least six clock cycles, and then deassert it.
4. The MBISTACK signal is asserted by the processor to indicate MBIST mode is active.
This signal remains asserted until after the MBISTREQ signal has been deasserted.
5. When the MBISTACK signal is asserted, the MBISTARRAY[4:0] and

MBISTCFG[3:0] signals must be driven to the values required for the appropriate RAM
or RAMs to be tested.
6. After at least four clock cycles, the MBIST controller can begin delivering MBIST
operations to the processor.
7. There must always be at least four clock cycles after changing the value of
MBISTARRAY or MBISTCFG before delivering operations targeted for RAMs under
the new configuration. These signals must not be changed while there are still active
operations in the MBIST pipeline.
8. When all required testing is complete, deassert the MBISTREQ signal.
9. If required, perform a Powerup reset as described in Clocking and resets on page 4-6 to
begin executing functional code on the processor. The MBISTREQ and
nMBISTRESET signals must be deasserted and the MBISTCFG bits must be driven
LOW during functional operation.
Figure 6-5 shows the timing diagram for MBIST mode entry and exit.
MBIST MBIST Done /

>6 cycles <8 cycles 4 cycles test exec 4 cycles 2 cycles Processor Reset3
CLKIN
nMBISTRESET1
MBISTREQ
MBISTACK
MBISTCFG2
MBISTARRAY
MBISTREADEN,
Operations
MBISTWRITEEN
MBISTADDR,
MBISTBE, Operations
MBISTINDATA
Figure 6-5 Production MBIST mode entry and exit timing
In Figure 6-5 on page 6-20:
1. Only assert nMBISTRESET during production MBIST testing and deassert it during
on-line MBIST testing.
2. All MBISTCFG bits must be driven LOW during functional mode and during on-line
MBIST testing.
3. To enter functional mode after MBIST testing, assert nPORESET to reset the processor.
Although Figure 6-5 on page 6-20 shows don’t care (X) values on the MBIST interface inputs
when moving into MBIST mode, Arm recommends that they are driven to known values to
prevent X pollution during simulation.
Note
The MBIST entry and exit sequence for online MBIST is different to that shown in Figure 6-5
on page 6-20 for production MBIST. Online MBIST imposes additional restrictions on the use
of the MBIST interface, reset and clock signals. See the Arm® Cortex®-M7 Processor Safety
Manual for more information.
Single-cycle RAM MBIST operation
Figure 6-6 shows a data flow timing example for read and write MBIST operations for a
single-cycle RAM, with a 2-cycle pipeline depth. It shows the MBIST interface signals, and the
RAM signals at the boundary of the RAM integration level of the design. MBIST read and write
operations can be delivered on every processor clock cycle.
A no-op, both MBISTREADEN and MBISTWRITEEN held LOW, is not required, but is
shown here for completeness.
Cycle number 1 2 3
CLKIN
MBISTREADEN
MBISTWRITEEN
MBISTADDR,
MBISTBE, Rd0 Wd1 No-op
MBISTINDATA
Ram chip_select
Ram write
Ram address,
Ram byte_write, Rd0 Wd1 No-op
Ram data_in
Ram data_out Rd0
MBISTOUTDATA Rd0
3 cycles for read data
Figure 6-6 Example single-cycle MBIST operation
Multicycle RAM MBIST operations
Only the TCMs must be accessed using multicycle operations if they require wait states. Each
operation must be extended by the MBIST controller by a clock cycle per wait state required by
a TCM.
Note
For MBIST transactions, xTCMWAIT input signals:
• Must not be asserted in the address phase.
• Must not be asserted in the response phase for zero wait state TCMs.
• Must be asserted appropriately in the response phase for non-zero wait state TCMs. For
example, 1 cycle for 1 wait state TCMs.
Figure 6-7 shows a data flow timing example for read and write MBIST operations for an array
with a 2-wait-state RAM, and a 2-cycle pipeline depth. This means the MBIST controller can
only send an MBIST operation to the MBIST interface once every three cycles. The
MBISTREADEN or MBISTWRITEEN signal for the operation can only remain asserted for
the first of the three cycles and must stay LOW for the remaining cycles. However, the
MBISTADDR, MBISTBE, and MBISTINDATA signals must all remain constant during
these additional cycles.
Cycle number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
CLKIN
MBISTREADEN
MBISTWRITEEN
MBISTADDR,
MBISTBE, Rd0 Wd1 No-op Rd2
MBISTINDATA
Ram chip_select
Ram wait
Ram write
Ram address,
Ram byte_write, Rd0 Wd1 No-op Rd2
Ram data_in
Ram data_out Rd0 Rd2
MBISTOUTDATA Rd0 Rd2
5 cycles for read data
Figure 6-7 Example multicycle MBIST operation
6.4.6 MBIST ALL mode
An MBIST controller usually tests each RAM in sequence. However, this does not emulate the
power footprint of the RAMs during functional mode when multiple RAMs have parallel
accesses. Also, life testing or burn-in testing must simultaneously exercise most of the logic
without damaging the device. To satisfy these requirements, operate the MBIST interface in the
MBIST ALL mode by setting MBISTCFG[3:0].
MBISTCFG bits 0-3 enable MBIST ALL mode for the ITCM, DTCM, instruction cache or
data cache memory respectively. Enabling MBIST ALL mode for a memory type enables all
logical arrays that are part of that type.
The MBIST ALL mode performs simultaneous read and write accesses to multiple arrays.
Table 6-15 shows how MBIST ALL mode affects read and write operations.
Table 6-15 Affect of MBIST ALL mode on read and write operations
MBISTWRITEEN MBISTREADEN ALL mode Action
LOW HIGH Disabled Reads from targeted array only
HIGH LOW Writes to targeted array only
LOW HIGH Enabled Reads from all memories enabled by the

MBISTCFG signal and the target array
but outputs data only from the target array
HIGH LOW Write to all memories enabled by the

MBISTCFG signal and the target array
Chapter 7
Key Implementation Points
This chapter describes the key implementation points that you must consider when you
implement the processor. It contains the following sections:
• About key implementation points on page 7-2.
• Key implementation tasks on page 7-3.
• Other considerations for implementation on page 7-4.
Note
This chapter mentions implementation steps that are described in more detail in the Reference
Methodology documents from your EDA tool vendor. See Additional reading on page xii.
7.1 About key implementation points

This chapter lists the main points to consider when you implement the Cortex-M7 processor.
Read this chapter with the rest of the information in this guide and your Cortex-M7 processor
reference methodology documentation.
You can use this chapter to check that you have covered the implementation steps described in
the other chapters.
7.2 Key implementation tasks

Table 7-1 lists the key tasks for implementation.
Table 7-1 Key implementation tasks
Key task Description
1. Select level of hierarchy to implement. This can be either: See About configuration guidelines on page 2-2 and
a. The processor top-level, CORTEXM7INTEGRATIONCS. Configuration options on page 2-3
b. A higher level in your SoC that includes the
2. Configure the processor parameters. See Configuration options on page 2-3
3. Select appropriate library cells for clock gating and See Other considerations for implementation on
Clock-Domain Crossing (CDC) purposes. page 7-4
4. Determine optimum floorplan. See Considerations for floorplans on page 9-6
5. Perform synthesis and scan insertion. See the reference methodology documents from your
EDA tool vendor for information on equivalence
6. Create layout. checking tools
7. Perform LVS and DRC checks.
8. Perform timing verification.
9. Perform characterization.
10. Run ATPG. See Chapter 6 DFT Integration Guidelines and the
reference methodology documents from your EDA
tool vendor
11. Perform netlist dynamic verification. See Chapter 10 Netlist Dynamic Verification.
12. Perform functional verification using logical equivalence See the reference methodology documents from your
checking tools. Optionally, you can also replay test EDA tool vendor
vectors.
13. Perform sign-off in accordance with the agreed criteria See Chapter 11 Sign-off
and your sign-off obligations.
14. Sign-off your implementation.
Note
The outputs from the tasks in Table 7-1 must produce complete and verified deliverables as
described in Obligations for sign-off on page 11-3.
7.3 Other considerations for implementation

This section provides details of the special purpose modules that you must provide
technology-specific versions of, depending on which optional components you are using.
Technology-independent models of these modules are provided in the
logical/models/cells/generic directory.
Note
• You can use these files for RTL simulation.
• You must copy the files that you require for your implementation into a new directory for
the technology that you are using.
• You must use these files as part of the validated processor RTL during logical equivalence
checking as part of the sign-off procedure.
• You must not use these files for synthesis.
• You must implement an equivalent module that instantiates cells with the required
properties from your cell library for synthesis. You must also ensure that the cells you
instantiate are maintained throughout the implementation flow and are not resynthesized
to alternative cells.
• You must implement the modules using cells from your technology library that have the
characteristics described in the comments in the technology independent versions.
• Example modules containing cell instantiations required for implementation are provided
with the Reference Methodology. See the Reference Methodology release note for the
location of these files.
• To make it easier for LEC tools to check equivalence between the technology independent
and technology specific versions of the special purpose cells, Arm recommends that you
use the same instance name with the _reg suffix for your flip-flops as the Verilog reg nets
that infer flip-flops in the generic modules.
7.3.1 Architectural clock gating
The Cortex-M7 processor contains some clock gating cells to reduce the dynamic power
dissipation by gating the clock to groups of registers within the design. These clock gates are
called architectural clock gates to distinguish them from the clock gates that might be inferred
by the synthesis tools during the implementation process. The architectural clock gating cells
must be provided as modules named cm7cell_clkgate.
Architectural clock gating is optional because correct operation of the processor is not
dependent on it. If architectural clock gating is not required, then you must provide an
implementation of the cm7cell_clkgate module that directly connects the clock input and output
ports together. The other ports are unused in this case.
If architectural clock gating is required, the cm7cell_clkgate module must directly instantiate a
positive-edge clock gating cell from your target library. Correctly connect the clock input and
outputs, clock enable and scan-enable signals.
Note
For simulation and logical-equivalence checking
purposes,logical/models/cells/generic/cm7cell_clkgate.v provides a configurable version of
the cm7clk_gate module. cm7cell_clkgate.v is used to abstract the high-level clock gating
function
for the primary clocks in the macrocell. A functional clock enable <clk_enable_i> is:
1. Combined with a scan enable and global disable signal to provide the gating term.
2. Latched prior to gating with the main clock.
Do not use cm7cell_clkgate.v for synthesis.
7.3.2 Special purpose cells in the Cortex-M7 processor
The Cortex-M7 processor contains modules to safely synchronize asynchronous signals and
semi-synchronous AXI interface signals. Table 7-2 lists these modules and describes their
behavior.
Table 7-2 Special purpose cells used for synchronizing signals
Module Description
cm7cell_sync Discrete synchronizer cell. Resets to 0. This is a double flip-flop that synchronizes the asynchronous signals
to the receiving clock domain. You must implement this with flip-flops designed to minimize the time
required to resolve metastable outputs when the input setup or hold constraints are violated.
cm7cell_semi_sync_flop This a single flip-flop with an enable that samples semi-synchronous AXI input signals that are generated
from a divided version of CLKIN. In some cases this module is used as a launch flip-flop between
asynchronous clock domains. Therefore, you must implement this with a flip-flop guaranteed not have
glitches on its output signals when the input setup time is met.
cm7cell_cdc_and This is a logical AND function for gating AXI input signals. It prevents glitches being captured by AXI
interface logic that might be running at a higher clock frequency than the external AXI components.
You can replace the cm7cell_cdc_and module with a manually instantiated AND gate if there are CDC
concerns. For example, if a signal from a slower clock domain is AND gated with the clock-enable.
If the clock-enable is LOW, there is no guarantee that the other signal does not glitch when sampled by a
flop in the CORTEXM7 module.
If this AND gate is directly connected to the flop input, there is no problem. However, if there is other logic
outside of CORTEXM7 module, it might be possible for the synthesis tool to re-arrange the logic in a way that
enables the glitch to propagate into the flop input, which could cause metastability issues.
It is a requirement that if the clock enable input is LOW, that the output must be LOW, even if the other input
glitches.
Only if you are implementing a dual-redundant core configuration using the r1p1 deliverables
and upwards can modify:
• The logic that delays all inputs into the redundant copy of the logic. Arm provides
example delay logic in:
cortexm7/logical/models/cells/generic/cm7cell_dcreg.v
• The logic that compares the outputs of the functional logic to the redundant logic. Arm
provides example comparator logic in:
cortexm7/logical/models/cells/generic/cm7cell_dccm.v
cortexm7/logical/models/cells/generic/cm7cell_dcctl.v
Contact Arm if you require more information about any of these modules and how to modify
them.
7.3.3 Special purpose cells in optional components
Additional components are provided in the deliverables that you might optionally use in your
system. Some of these components have clock domain crossing paths that require similar special
purpose modules to those used in the processor. You are only required to implement technology-
specific versions of these modules if you are using the optional components.
CM7DAP
The cells that are described in the following table are required only if the CM7DAP component is
used.
Table 7-3 Special purpose cells used with CM7DAP
Module Description
cm7_dap_sw_cdc_capt_reset Note
The cm7_dap_sw_cdc_reset module is not intended for use in synthesis. Arm recommends that an
equivalent module directly instantiating cells from your library that meet the following requirements
is used instead.
The cm7_dap_sw_cdc_reset module is instantiated where a CDC signal is sampled. The register output
might become metastable when the input signal was not stable at a clock edge but must resolve this
condition at the next clock edge when the input is stable.
The reset state of this register must be 1 for correct operation.
The implementation of this module must ensure that this requirement is met.
cm7_dap_sw_cdc_capt_sync Note
The cm7_dap_sw_cdc_capt_sync module is not intended for use in synthesis. Arm recommends that an
is used instead.
The cm7_dap_sw_cdc_capt_sync module is instantiated where a CDC-safe synchronizer is required, that

is, where the input is from a different clock domain. The signal is sampled using a series of two
registers to minimize the chance of metastability being introduced if the input changes around the time
it is sampled.
The reset state of these registers must be 1 for correct operation.
The implementation of this module must ensure that these requirements are met.
cm7_dap_cdc_and Note
The cm7_dap_cdc_and module is not intended for use in synthesis. Arm recommends that an equivalent
module directly instantiating cells from your library that meet the following requirements is used
instead.
The cm7_dap_cdc_and module is instantiated where an AND gate mask is required on a CDC interface.
In this case, you must ensure that the output of the mask does not glitch when the mask input is LOW.
Table 7-3 Special purpose cells used with CM7DAP (continued)
Module Description
cm7_dap_cdc_mux Note
The cm7_dap_cdc_mux module is not intended for use in synthesis. Arm recommends that an equivalent
instead.
The cm7_dap_cdc_mux module is instantiated where a multiplexer gate mask is required on a CDC
interface. In this case, you must ensure that the output of the multiplexer does not glitch when the
selected input is stable.
cm7_dap_cdc_send_addr Note
The cm7_dap_cdc_send_addr module is not intended for use in synthesis. Arm recommends that an
is used instead.
The cm7_dap_cdc_send_addr module is instantiated where 4-bit CDC-safe send (launch) register is
required, that is, where the output of the register is used in a different clock domain. In this case, you
must ensure that the output of the register does not glitch when the register enable signal, REGEN, is
LOW.
REGRESETn is only asserted in the Reset All Registers (RAR) configuration. In the non-RAR
configuration, you can leave this input unconnected and instantiate registers without an asynchronous
reset.
cm7_dap_cdc_send_reset Note
The cm7_dap_cdc_send_reset module is not intended for use in synthesis. Arm recommends that an
is used instead.
The cm7_dap_cdc_send_reset module is instantiated where a CDC-safe send (launch) register is

required, that is, where the output of the register is used in a different clock domain. In this case, you
must ensure that the output of the register does not glitch when the register enable signal, REGEN, is
LOW, or when the output does not logically change on a clock edge.
Table 7-3 Special purpose cells used with CM7DAP (continued)
Module Description
cm7_dap_cdc_capt_sync Note
The cm7_dap_cdc_capt_sync module is not intended for use in synthesis. Arm recommends that an
is used instead.
The cm7_dap_cdc_capt_sync module is instantiated where a CDC-safe synchronizer is required, that is,
where the input is from a different clock domain. The signal is sampled using a series of two registers
to minimize the chance of metastability being introduced if the input changes around the time it is
sampled.
cm7_dap_cdc_send Note
The cm7_dap_cdc_send module is not intended for use in synthesis. Arm recommends that an equivalent
instead.
The cm7_dap_cdc_send module is instantiated where a CDC-safe send (launch) register is required, that
is, where the output of the register is used in a different clock domain. In this case, you must ensure
that the output of the register does not glitch when the register enable signal, REGEN, is LOW.
REGRESETn is only asserted in the RAR configuration. In the non-RAR configuration, you can
leave this input unconnected and instantiate registers without an asynchronous reset.
cm7_dap_cdc_send_data Note
This module is not intended for use in synthesis. Arm recommends that an equivalent module directly
instantiating cells from your library that meet the following requirements is used instead.
This module is instantiated where 32-bit CDC-safe send (launch) register is required, that is, where the
output of the register is used in a different clock domain. In this case, you must ensure that the register
output does not glitch when the register enable signal, REGEN, is LOW.
REGRESETn is only asserted in the RAR configuration. In the non-RAR configuration, you can
leave this input unconnected and instantiate registers without an asynchronous reset.
CM7TPIU
Wherever an unsafe asynchronous input to CM7TPIU is present, a technology-specific version of

the clock domain crossing synchronizer, cm7_cdc_capt_sync module, should be implemented.
This module only comes in a single-bit, non-enabled form to simplify flows as much as possible.
cm7_IK_pmu
If you are adapting the IK power management unit for use in your system, then you must
implement technology-specific versions of the following modules:
Table 7-4 Power management unit modules
Module Description
cm7_pmu_cdc_send_reset Note
This module is not intended for use in synthesis. Arm recommends that an
equivalent module directly instantiating cells from your library that meet
the following requirements is used instead.
This module is instantiated where a CDC-safe synchronizer is required, that

is. where the input is from a different clock domain. The signal is sampled
using a series of two registers to minimize the chance of metastability being
introduced if the input changes around the time it is sampled.
The implementation of this module must ensure that these requirements are
met.
cm7_pmu_sync_reset Note

The implementation of this module must ensure that this requirement is
met.
cm7_pmu_sync_set Note

The implementation of this module must ensure that this requirement is
met.
Miscellaneous modules
The following table lists miscellaneous modules:
Table 7-5 Miscellaneous modules
Module Description
cm7_cdc_connect Note
Do not modify the cm7_cdc_connect module. The module does not
implement any synchronization registers. It is for validation purposes
only and has no functional effect.
All signals passing between modules in different clock remains

should pass through the cm7_cdc_connect module. It injects Z values
on to the outputs when the value is unsafe, to enable unsafe use to be
detected.
cm7_rst_send_set Note
The cm7_rst_send_set module is not intended for use in synthesis.
Arm recommends that an equivalent module directly instantiating
cells from your library that meet the following requirements is used
instead.
The cm7_rst_send_set module is instantiated where a glitch-free send

(launch) register is required, that is, where the output of the register
is used to drive an asynchronous reset signal.
cm7_rst_sync Note
Do not modify the cm7_cdc_connect module. The cm7_rst_sync
module is not intended for use in synthesis. Arm recommends that an
equivalent module directly instantiating cells from your library that
meet the following requirements is used instead.
The cm7_rst_sync module is instantiated where a reset synchronizer is

required. This module produces a synchronously asserted and
deasserted reset in response to a synchronous reset request.
cm7cell_sync Discrete synchronizer cell. Resets to 0.
DS02_multp_24 These modules do not need to be replaced with hand-instantiated

equivalents.
DS02_multp_32
These are functional multiplier blocks that can be synthesized.
Chapter 8
Cache RAM Integration
This chapter describes the cache RAM organization and how to integrate your cache RAMs into
the processor. It contains the following sections:
• About cache RAM integration on page 8-2.
• Resource requirements for memory integration on page 8-3.
• Controls and constraints for memory integration on page 8-4.
• Blocks for memory integration on page 8-5.
• Flow for memory integration on page 8-8.
• Confirming memory integration on page 8-16.
• Outputs from memory integration on page 8-17.
• Solving memory integration problems on page 8-18.
• Reference data for memory integration on page 8-19.
8.1 About cache RAM integration

Caution
For successful configuration of the RTL you must:
• Set up any configurable options, see Configuration options on page 2-3.
• Integrate the memory.
Failure to complete all the necessary configuration can result in malfunction.
The processor can include the following memory modules:

• Instruction cache data RAM.
• Instruction cache tag RAM.
• Data cache data RAM.
• Data cache tag RAM.
Each cache can be between 4KB and 64KB in size, or not be present.
Figure 8-1 shows the cache memory integration process.

Access timing
Setup and hold times
Total cache memory size
Cache memory block size and width
Control and addressing
Organization
Clocking
Clock gating
Power
Outputs:
Inputs: Memory
Configured RTL
RTL Integration
Reports and logs
Resources:
RAM models, standard cell libraries
HDL Simulators
Cache memory integration testbench
Figure 8-1 Cache RAM integration process
8.2 Resource requirements for memory integration

To perform memory integration you require a RAM generator that can generate RAMs that meet
the constraints listed in Controls and constraints for memory integration on page 8-4. You also
require the supplied cache memory integration testbench to validate your memory integration,
see Confirming memory integration on page 8-16.
8.3 Controls and constraints for memory integration

Configuration options on page 2-3 includes the parameters that control the cache configuration
in the memory integration.
You must ensure your library RAM satisfies the following requirements:
• All timings must be synchronous to the rising clock edge.
• Single-cycle access.
• Chip select, RAM enable, control required.
• RAM outputs must always be valid.
• RAM outputs must not be tristate.
• Byte-write, or bit-write, control is required for some RAM blocks. If byte-write or

bit-write RAM blocks are not available, you must use blocks of narrower RAM. This
increases the overall RAM area.
Table 8-1 shows the RAM timing requirements.
Table 8-1 Cache RAM timing requirements
Setup time as a Access time as a

RAM type
percentage of clock cycle percentage of clock cycle
Data 45 55
Tag 45 35
8.4 Blocks for memory integration

All cache RAM blocks are instantiated within a single file, cm7top_cache_rams.v. The release
includes the following RAM instantiation examples:
• Generic version that can be set to to any size with or without ECC:
logical/models/rams/generic/cm7top_cache_rams.v
• 32KB caches with ECC in a specific technology, see the release note for more
information:
logical/models/rams/tsmc_40lp_L1_32I_32D_ECC/cm7top_cache_rams.v
Use the most appropriate example as a guide when instantiating your own RAMs, taking special
care if you are implementing ECC:
• If you enable ECC, you must increase the data and tag RAM widths to accommodate the
ECC bits.
If you are not implementing ECC then the implementation tools reduce the RAM control signal
widths accordingly. This means that you never have to tie any unused bits to zero based on the
error scheme in use.
See Reference data for memory integration on page 8-19 for more information about the cache
RAM signals for the different implementation options.
Note
• Within the example cortexm7_caches_rams0 modules, all the RAM instances are grouped
into instruction and data side components. Each group is divided into data RAM, tag
RAM subgroups. The tag RAM incorporates the valid bits.
• The example cortexm7_caches_rams0 modules are provided for simulation purposes only.
You must not use them directly in the synthesis of your design.
Table 8-2 shows the cache RAM naming convention.
Table 8-2 Cache RAM instantiations
Instance name Description
u_ddata0_bank0 Data cache data RAM
u_dtag_bank0 Data cache tag RAM
u_idata_bank0 Instruction cache data RAM
u_itag_bank0 Instruction cache tag RAM
Table 8-3 shows the recommended cache RAM size, type, and instances required for the cache
RAM modules without ECC bits, for each supported cache size.
Table 8-3 Cache RAM modules RAM size and type without ECC
Write enable type Cache sizes

RAM block Instances
Bit Byte Word 4KB 8KB 16KB 32KB 64KB
Instruction cache data RAM No No No 256x64 512x64 1024x64 2048x64 4096x64 2 (0, 1)a
Instruction cache tag RAM No No No 64x22 128x21 256x20 512x19 1024x18 2 (0,1)
Data cache data RAM No Yes No 128x32 256x32 512x32 1024x32 2048x32 8 (0-7)
Data cache tag RAM No No No 32x26 64x25 128x24 256x23 512x22 4 (0-3)
a. You can use eight banks of half-width RAMs for the instruction cache.
Table 8-4 shows the recommended cache RAM size, type, and instances required for cache
RAM modules with ECC bits, for each supported cache size.
Table 8-4 Cache RAM modules RAM size and type with ECC
Write enable type Cache sizes

RAM block Instances
Bit Byte Word 4KB 8KB 16KB 32KB 64KB
Instruction cache data RAM No No No 256x72 512x72 1024x72 2048x72 4096x72 2 (0,1) a
Instruction cache tag RAM No No No 64x29 128x28 256x27 512x26 1024x25 2 (0,1)
Data cache data RAM No Yesb No 128x39 256x39 512x39 1024x39 2048x39 8 (0-7)
Data cache tag RAM No No No 32x33 64x32 128x31 256x30 512x29 4 (0-3)
a. You can use eight banks of half-width RAMs for the instruction cache.
b. The functionality required is for five write enables, of which the bottom four are full byte enables, and the top one is the remaining 7
bits [38:32]. If the SRAM compiler does not support this functionality (39 bits wide with five Byte write enables including the top
partial byte), then the same functionality can be built from bit-writable SRAM.
Note
• The Cortex-M7 processor logic provides a write enable signal to each RAM, and
byte-write or bit-write enables for RAM blocks that require byte or bit writes. You can
ignore the write enable signal if your RAM only requires the byte-write or bit-write enable
inputs.
• If you instantiate a larger RAM than required, for example if your RAM generator cannot
produce a RAM of the required size, Arm recommends you tie off the redundant upper
address bits to zero.
• To maximize power savings, Arm recommends you use 64 bit or 72 bit wide data RAMs
for the instruction cache. This is because only double word accesses are made on this
interface, and means there is no advantage implementing dual banks for each cache way.
A single RAM uses less power than two RAMs of half the size.
In the ideal case, you can produce a single block of compiled RAM for each RAM instance. This
might not be possible if:
• Your RAM does not have the required byte-write control. In this case you must construct
the RAM out of four blocks of byte-wide RAM, see Producing byte-write memory from
word-write RAM on page 8-14. You can also construct a byte or word write RAM using
a bit write RAM and connecting the write enable signal appropriately.
• Your compiler cannot produce a single RAM block that is the required size, or a single
RAM block might not meet the timing requirements. In this case, you must produce the
RAM out of two or more blocks of smaller RAM, see Producing a large memory from
smaller RAM blocks on page 8-14.
8.5 Flow for memory integration

The supported cache RAM integration flow shown in Figure 8-2 enables you to:
• Identify the RAM organization required for your chosen cache configuration, see Blocks
for memory integration on page 8-5.
• Integrate your library RAM, see Integrating cache RAM blocks.
• Test that cache RAM integration has been successful, see Confirming memory integration
on page 8-16.
Cache RAM integration

Start
Identify the Cache RAM

organization to be used
Integrate and validate your

chosen Cache RAM
organization
No TestBench
passes?
Yes Proceed with RAM

Validation and Synthesis
Complete
Figure 8-2 Cache RAM Integration flow
8.5.1 Integrating cache RAM blocks
To integrate your cache RAM:
1. Go to the logical/models/rams directory:

cd logical/models/rams
2. Create a directory where you can integrate your RAMs, and go to this directory. For
example:
mkdir <my_rams_dir>
cd <my_rams_dir>
3. Blocks for memory integration on page 8-5 shows the RAM sizes required for each cache
size configuration. Use this information to identify the RAM blocks that you require, then
generate them using your library RAM generator.
4. Copy the simulation models for your cache RAM modules into the directory you created
in step 2. These are the cache RAM modules that you instantiate in cm7top_cache_rams.v.
5. Copy an example module from logical/models/rams/generic. For example:

cp ../generic/cm7top_cache_rams.v.
6. Integrate your cache RAM blocks, with the organization described in Blocks for memory
integration on page 8-5. Replace the bit_ram and byte_ram instances with your own RAM
blocks.
7. All RAM control signals are driven as active HIGH. If your RAM blocks have
active-LOW control inputs, you must invert the relevant control signal before connecting
it to the RAM.
8. Edit the cm7top_cache_rams.v file and ensure that the instruction cache size tie-off,
ram_icu_cache_size, and data cache size tie-off, ram_dcu_cache_size are set to your
requirements. Table 8-5 shows the correct instruction and cache size tie-off encodings.
Table 8-5 Instruction and data cache size encodings
Cache size ram_icu_cache_size ram_dcu_cache_size
4KB 0b0000 0b0000
8KB 0b0001 0b0001
16KB 0b0011 0b0011
32KB 0b0111 0b0111
64KB 0b1111 0b1111
9. Go to the logical/testbench/ram_integration_tb/CORTEXM7/tbench directory and modify

the CORTEXM7_cache_ram_testbench.vc file to point to your cache RAM integration
directory <my_rams_dir> instead of the generic directory.
8.5.2 Implementing cache RAMs
The following subsections describe the possible implementations of the cache RAMs:
• Implementing instruction cache data and tag RAMs on page 8-10.
• Implementing data cache data and tag RAMs on page 8-11.
When integrating your cache RAMs you must connect the data read, data write, and write enable
ports correctly. See Reference data for memory integration on page 8-19 for more information.
Implementing instruction cache data and tag RAMs
The instruction cache data RAM:
• Supports 64 bits of data and 8 bits of ECC information. These are bits[71:64] when ECC
is enabled. These bits are not present when ECC is not enabled and therefore do not
require to be tied to zero.
• Has two RAM banks. Each bank is split into two halves of 36 bits.
The instruction cache data RAMs are not required to be bit-writable or byte-writable, so they
can be implemented differently. The following code example shows how to do this for bank 0
and bank 1:
// I Data RAM
SRAMSPHSE_SVT_2048X36M8WM0 u_idata_bank0_lower
(.CLK (clk),
.A (icu_ram_data_addr0_i[10:0]),
.Q (ram_icu_data_rdata0_o[35:0]),
.D (icu_ram_data_wdata0_i[35:0]),
.CEN (~icu_ram_data_en_i[0]),
.WEN (~icu_ram_data_wr_i),
);
SRAMSPHSE_SVT_2048X36M8WM0 u_idata_bank0_upper
(.CLK (clk),
SRAMSPHSE_SVT_2048X36M8WM0 u_idata_bank1_lower
(.CLK (clk),
SRAMSPHSE_SVT_2048X36M8WM0 u_idata_bank1_upper
(.CLK (clk),
The instruction cache tag RAM supports 22 bits of data and 7 bits of ECC information. These
are bits[28:22] when ECC is enabled. These bits are not present when ECC is not enabled and
therefore do not require to be tied to zero. The following example shows an instance for Way 0
with ECC. The example uses a 32KB data RAM. This requires you to tie the lowest 3 bits of tag
read data to zero. For more information, see Tying off unused tag RAM bits on page 8-13.
// I tag RAM
SRAMSPHSE_SVT_512X26M4WM0 u_itag_bank0
(.CLK (clk),
.A (icu_ram_tag_addr_i[8:0]),
.Q (ram_icu_tag_rdata0_o[28:3]),
.D (icu_ram_tag_wdata_i[28:3]),
.CEN (~icu_ram_tag_en_i[0]),
.WEN (~icu_ram_tag_wr_i),
SRAMSPHSE_SVT_512X26M4WM0 u_itag_bank1
(.CLK (clk),
.A (icu_ram_tag_addr_i[8:0]),
.Q (ram_icu_tag_rdata1_o[28:3]),
.D (icu_ram_tag_wdata_i[28:3]),
.CEN (~icu_ram_tag_en_i[1]),
.WEN (~icu_ram_tag_wr_i),
Implementing data cache data and tag RAMs
The data cache data RAM:

• Supports 32 bits of data and 7 bits of ECC information.
• Has two RAM segments, each with four RAM blocks.
• Contains 5 data byte strobes, strb0-4. The most significant bit, strb4, controls only 7 bits
that correspond to the ECC values. strb4 is not present when ECC is not enabled and
therefore the bits that it controls do not require to be tied to zero.
The following code example shows the even and odd bank RAM instances of the data cache data
RAM. This example is for a 32KB data cache and uses bit-writeable RAM:
// Even banks 0-3
SRAMSPHSE_SVT_1024X39M4WM1 u_ddata0_bank0
(.CLK (clk),
.A (dcu_ram_data0_addr0_i[9:0]),
.Q (ram_dcu_data0_rdata0_o[38:0]),
.D (dcu_ram_data0_wdata0_i[38:0]),
.CEN (~dcu_ram_data0_en_i[0]),
.WEN ({{7{~dcu_ram_data0_strb0_i[4]}},
{8{~dcu_ram_data0_strb0_i[3]}},
{8{~dcu_ram_data0_strb0_i[0]}}}),
.GWEN (~dcu_ram_data0_wr_i),
);
(.CLK (clk),
);
(.CLK (clk),
);
(.CLK (clk),
);
// Odd banks 0-3
(.CLK (clk),
);
(.CLK (clk),
);
(.CLK (clk),
);
(.CLK (clk),
);
Data cache tag RAM supports 26 bits of data and 7 bits of ECC information. These are
bits[32:26] when ECC is enabled. These bits are not present when ECC is not enabled and
therefore do not require to be tied to zero.
The following code example shows the Way 0 RAM instance for the data cache tag RAM. This
example uses a 32KB data cache, that requires you to tie the lower 3 bits of tag read data to zero.
For more information, see Tying off unused tag RAM bits.
// D tag RAM
SRAM256X23 u_dtag_bank0
(.CLK (clk),
.A (dcu_ram_tag_addr_i[7:0]),
.Q (ram_dcu_tag_rdata0_o[25:3]),
.D (dcu_ram_tag_wdata_i[25:3]),
.CEN (~dcu_ram_tag_en_i[0]),
.WEN (~dcu_ram_tag_wr_i)
);
SRAMSPHSE_SVT_256X30M4WM0 u_dtag_bank0
(.CLK (clk),
.WEN (~dcu_ram_tag_wr_i),
);
(.CLK (clk),
);
(.CLK (clk),
);
(.CLK (clk),
);
8.5.3 Tying off unused tag RAM bits
When you implement larger cache configurations, the width of the tag RAM decreases, see
Table 8-3 on page 8-6 and Table 8-4 on page 8-6. You must tie the unused data bits to zero,
tying these off at the LSB end.
The following code example shows the low 3 bits of one tag RAM data bus that are tied off:
assign ram_dcu_tag_rdata0_o[2:0]=3'b000;
8.5.4 Producing byte-write memory from word-write RAM
The data cache data RAM, u_ddata_bank0 for example, requires byte-write RAM. If you do not
have memories with byte-write control, you can construct these blocks using bit RAM or four
byte-wide RAM blocks. Figure 8-3 shows an example of how you can organize data cache
RAM modules.
The rules for connecting four RAM blocks are:
• Each byte-wide RAM has the same address and chip select controls as the word-wide
RAM.
• The word write-enable signal is left unconnected.
• One bit of the byte-write control signal connects to the write-enable pin of each of the
byte-wide RAM blocks. For example, bit[0] connects to the RAM representing byte 0.
• The connection of the data input and data output signals is:
— Data input and output bits[7:0] connect to pins[7:0] of the byte 0 RAM.
clk
dcu_ram_data0_en_i[0]
dcu_ram_data0_strb_i[3:0]
dcu_ram_data0_addr0_i[10:0]
[3] [2] [1] [0]
CLK CEN WE ADDR CLK CEN WE ADDR CLK CEN WE ADDR CLK CEN WE ADDR
[10:0] [10:0] [10:0] [10:0]
u_ddata_bank0_3 u_ddata_bank0_2 u_ddata_bank0_1 u_ddata_bank0_0

2k x 8 2k x 8 2k x 8 2k x 8
DO[7:0] DI[7:0] DO[7:0] DI[7:0] DO[7:0] DI[7:0] DO[7:0] DI[7:0]
[31:24] [31:24] [23:16] [23:16] [15:8] [15:8] [7:0] [7:0]

dcu_ram_data0_wdata0_i[31:0]
ram_dcu_data0_rdata0_o[31:0]
Figure 8-3 Byte-write memory organization
8.5.5 Producing a large memory from smaller RAM blocks
You might have to create a large memory out of smaller RAM blocks, for one of the following
reasons:
• Your RAM compiler cannot produce a RAM of the required size.
• A single large RAM is too slow for your performance requirements.
• A single large RAM does not fit into your floorplan.
The rules for producing a memory out of smaller RAM blocks are:
• The number of RAM blocks must be a power of two, for example 2, 4, or 8 blocks.
• If the address width of the required memory size is n bits, and the number of RAM blocks
is b, the width of the address port of the smaller RAM blocks is m bits, where:
m = (n-log2b)
For example, if you create a RAM from two smaller RAM blocks, and the required
address width for that memory size is 11 bits (n = 11), then the address width, m, of the
two smaller RAM blocks is 10 bits.
• You must apply address bits[m-1:0] to all the RAM blocks.
• You must ensure that only the addressed RAM is enabled, by AND gating a decode of the
[n-1:m] address bits with the RAM enable to create separate block enables.
In the example in Figure 8-4, address bits[9:0] are applied to the two RAM blocks, and a
1-bit decode of address bit[10] is AND gated with the RAM enable to generate the chip
enable for each RAM block.
The following Verilog shows the chip enables for this example:
assign bank0_0_cen = ~dc_dataram_addr0_i[10] & dc_dataram_en_i;
assign bank0_1_cen = dc_dataram_addr0_i[10] & dc_dataram_en_i;
The approach is exactly the same for any memory that must be constructed from smaller RAM
blocks.
Figure 8-4 shows the creation of a 2048x32 data cache data RAM from two smaller 1Kx32
RAM blocks.
clk
dcu_ram_data0_en_i[0]
dcu_ram_data0_addr0_i[10:0]
[9:0] [10] [9:0] [10]
dcu_ram_data0_wr_i
dcu_ram_data0_strb0[7:0]
ADDR[9:0] ADDR[9:0]
CLK CLK
1Kx32 CEN 1Kx32 CEN
u_ddata_bank0_1 WE u_ddata_bank0_0 WE
BW[7:0] BW[7:0]
DI[31:0] DO[31:0] DI[31:0] DO[31:0]
dcu_ram_data0_wdata0_i[31:0]
0
dcu_ram_data0_rdata0_ram[31:0]
1
[10]
Figure 8-4 Organizing large memory from smaller RAM blocks
8.6 Confirming memory integration

The release includes a testbench you must use to check that your cache RAM blocks are
correctly integrated.
Before running the testbench you must complete all steps in Integrating cache RAM blocks on
page 8-8.
To run the cache RAM integration testbench:
1. Go to the logical/testbench/ram_integration_tb/CORTEXM7/tbench directory where the

RAM integration testbench is run:
cd logical/testbench/ram_integration_tb/CORTEXM7/tbench
2. Edit the CORTEXM7_cache_ram_testbench.vc file:

• Change the following line to point to the directory where you performed RAM
integration:
-y ../../../../logical/models/rams/generic
• Change the following line if the library where your RAM models are stored is in a
separate directory:
//-y /<path>/ram_models
3. Compile and run the testbench using either one of the following:
• an IUS Verilog simulator:
% irun -access +rc -licqueue -exit +nospecify +notimingchecks -f CORTEXM7_cache_ram_testbench.vc \
CORTEXM7_cache_ram_testbench.v
• a VCS simulator:
% vcs +vcs+lic+wait +nospecify +v2k -cc gcc -CFLAGS "-O3 -I${VCS_HOME}/include" -Mupdate -f \
CORTEXM7_cache_ram_testbench.vc CORTEXM7_cache_ram_testbench.v
% simv +vcs+lic+wait +vcs+flush+log
• a ModelSim simulator:
% vlib work
% vlog +nospecify -f CORTEXM7_cache_ram_testbench.vc CORTEXM7_cache_ram_testbench.v
% vsim +notimingchecks -c CORTEXM7_cache_ram_testbench -do ”run -all”
You can ignore the warning of too few port connections. This is because the instantiation
only lists the ports required for the testbench functionality.
After you have started the testbench the test runs to completion without any more input.
At the end of the test run, the testbench produces a test pass or a test fail summary, see
Outputs from memory integration on page 8-17.
8.7 Outputs from memory integration

The main output from memory integration is the configured RTL. Testing your memory
integration generates the reports described in this section.
If your cache RAM integration succeeds, the simulation completes with a summary report
similar to the following:
Summary
=======
Cache Configuration
-------------------
DCACHE size = 16kB
ICACHE size = 16kB
DCACHE error code scheme: ECC

ICACHE error code scheme: ECC
Cache Integration Tests

-----------------------
DCACHE_DATA_EVEN word test passed; bit test passed
DCACHE_DATA_ODD word test passed; bit test passed
DCACHE_TAG word test passed; bit test passed
ICACHE_DATA word test passed; bit test passed
ICACHE_TAG word test passed; bit test passed
If your cache RAM integration fails, the simulation completes, and generates a report
identifying any cache RAM block that failed integration. For example, if the data cache data
RAM failed, simulation might produce the following summary:
Summary
=======
Cache Configuration
-------------------
DCACHE size = 32kB ICACHE size = 32kB
DCACHE error code scheme: ECC

ICACHE error code scheme: ECC
Cache Integration Tests

-----------------------
DCACHE_DATA_EVEN word test passed; bit test FAILED

DCACHE_DATA_ODD word test passed; bit test passed
DCACHE_TAG word test passed; bit test passed
ICACHE_DATA word test passed; bit test passed
ICACHE_TAG word test passed; bit test passed
!!! RAM integration FAILED. Test completed with errors !!!
To help you debug any errors, the simulation also reports expected and actual cache RAM read
data for failed RAM integration.
Note
If there are any errors, you can debug your RAM integration by using the default directory
settings in step 2 in Confirming memory integration on page 8-16. This simulates the example
Arm RAM blocks for you to use as a reference.
8.8 Solving memory integration problems

If the outputs from running the cache RAM integration testbench indicate a failure, you have
not integrated the memory correctly. If you cannot identify the reason for the failure contact
Arm for more information.
8.9 Reference data for memory integration

The following subsections provide reference data for memory integration:
• Instruction cache tag and data RAM signal structures.
• Data cache tag and data RAM signal structures on page 8-20.
8.9.1 Instruction cache tag and data RAM signal structures
Figure 8-5 shows the signal structures for integrating with and without ECC:
• Instruction cache tag RAMs.
• Instruction cache data RAMs.
Instruction cache tag RAM signals:
Instruction cache tag RAM enable 1 0 icu_ram_tag_en
0 0
Way 1 Way 0
Instruction cache tag RAM read and write data ram_icu_tag_rdata*
icu_ram _tag_wdata
28 22 21 20 4 3 2 1 0
Address tag
Valid Tag bit used for 32KB =4KB

7-bit ECC, when included given cache size 16KB 8KB
Instruction cache tag RAM address for
icu_ram_tag_addr
read data, and write data 9 0
Instruction cache tag write access icu_ram_tag_wr
Instruction cache data RAM signals:
Instruction cache data RAM enable icu_ram_data_en

1 0
0 0
Bank 1 Bank 0
Data RAM read and write data icu_ram_data_rdata*

icu_ram_data_wdata*
71 64 63 0
Data
8-bit ECC, when included
Data RAM address for read data, and write data icu_ram_data_addr*
11 0
Write access icu_ram_data_wr
* at the end of a cache name represents a value from 0-1, the RAM bank or way number
Figure 8-5 Instruction cache tag and data RAM signal structure
8.9.2 Data cache tag and data RAM signal structures
Figure 8-6 shows the signal structures for integrating with and without ECC:
• Data cache tag RAMs.
• Data cache data RAMs.
Data cache tag RAM signals:

Data cache tag RAM bank enables 3 2 1 0 dcu_ram_tag_en
Bank 3 Bank 0
Bank 2 Bank 1
Data cache tag RAM read and write data ram_dcu_tag_rdata*
dcu_ram_tag_wdata
32 26 25 24 23 22 21 20 4 3 2 1 0
Address tag
Valid Tag bit used for 32KB =4KB

Dirty given cache size 16KB 8KB
Outer cache attributes
Data cache tag RAM address for 8 0 dcu_ram_tag_addr
read data and write data
Data cache tag RAM write access dcu_ram_tag_wr
Data cache data RAM signals:
Data cache data RAM bank enables 3 2 1 0 dcu_ram_data<n>_en
Bank 3 Bank 0
Bank 2 Bank 1
Data cache data RAM byte-lane strobe enables 4 3 2 1 0 dcu_ram_data<n>_strb*
0 0 0 0 0
ECC data, when included Data byte 0

Data byte 3 Data byte 1
Data byte 2
dcu_ram_data<n>_wdata*
Data cache data RAM read and write data ram_dcu_data<n>_rdata*
38 32 31 0
Data

Data cache tag RAM address for 10 0 dcu_ram_data<n>_addr*
read data and write data
Data cache data RAM write access dcu_ram_data<n>_wr

Where:
* represents a value from 0-3, the RAM bank number
<n> represents a value 0 or 1, the data cache data RAM segment number
Figure 8-6 Cache RAM signal structure
Chapter 9
Floorplan Guidelines
This chapter describes the floorplan used as a starting point for your design. It contains the
following sections:
• About floorplanning on page 9-2.
• Resource requirements for floorplans on page 9-3.
• Controls and constraints for floorplans on page 9-4.
• Inputs for floorplans on page 9-5.
• Considerations for floorplans on page 9-6.
• Reference data for floorplans on page 9-8.
9.1 About floorplanning

The processor is a tightly tuned design with a high density of paths in the critical range of the
design. A good floorplan of the processor is crucial to ensure that the performance of the
macrocell is not degraded.
Figure 9-1 is a process diagram that shows the top-level inputs, resources, outputs, and controls
and constraints for floorplanning.

Pin placement
Area
Aspect ratio
Power distribution
Process requirements
Inputs:
Outputs:
Example floorplans
Floorplanning Floorplan
Block placement guidelines
Reports and logs
Memory abstracts
Resources:
Floorplanning tool
Figure 9-1 Floorplan process
9.2 Resource requirements for floorplans

This guide assumes that you have suitable EDA tools and compute resources for floorplanning.
9.3 Controls and constraints for floorplans

The following are controls and constraints that can influence floorplanning:
• Pin placement.
• Area.
• Aspect ratio.
• Power distribution.
• Process and library requirements.
9.4 Inputs for floorplans

Inputs are specific to your floorplanning tool, and can include the following:
• Example floorplans.
• Block placement guidelines.
• Memory abstracts.
9.5 Considerations for floorplans

Your floorplan is strongly influenced by the size of the RAM blocks used, and the position of
the pins on these RAM blocks. You must take care in the placement of the RAM blocks because
they occupy a large area of the floorplan and require significant routing resource. The placement
of the memories also affects the optimum standard cell placement.
For optimum performance you can:
• Partition the memories so that all related instruction memories are in one corner of the
floorplan and all related data memories are in the adjacent corner.
• Modify the floorplan to make the standard cell placeable area as close to a 1:1 aspect ratio
as possible. To achieve the best timing you must experiment with different aspect ratios.
Figure 9-2 on page 9-7 shows an example macrocell floorplan and also gives some guidelines
on where to place the interfaces for the macrocell. For information about the interfaces and the
interface signals see Chapter 4 Functional Integration Guidelines.
Note
• The aspect ratios shown for memories are arbitrary and might not be achievable using
your memory compiler.
• It might be necessary to adjust the floorplan if your technology prevents you from routing
over the RAM blocks.
• It is not expected that you have to perform hierarchical floorplanning of the processor.
CLKIN
AHBS AHBP AXIM
and
I/O I/O I/O
resets
MBIST Debug
TCM AHBD
and Interrupts and
I/O I/O
DFT I/O trace I/O
Standard cell placeable area
DTAG DTAG DTAG DTAG

ITAG ITAG RAM RAM RAM RAM
RAM RAM
DDATA DDATA DDATA DDATA

RAM RAM RAM RAM
IDATA IDATA IDATA IDATA
RAM RAM RAM RAM
DDATA DDATA DDATA DDATA

RAM RAM RAM RAM
Figure 9-2 Macrocell floorplan
Figure 9-2 shows guidelines rather than recommendations. For detailed pin placement
information see the floorplan scripts provided with the reference implementation flow.
Standard cell placement does not occur during floorplanning. Use your synthesis tool to place
the standard cells using a flat, physically unconstrained, placement methodology.
If ECC logic is implemented, Arm recommends that the pins for the ITCM and DTCM are on
the same or adjacent sides of the macrocell, because both TCMs go through the ECC logic.
The Prefetch Unit must be placed as close to the instruction caches. The Instruction Decoders
are contained in the Data Processing Unit and it is expected that the placement tool locates these
close to the instruction caches. Therefore, the expected location of the u_cm7_dpu module is on
the instruction cache side.
Example floorplanning scripts are provided in the reference implementation flow. For EDA tool
support, contact your EDA tool vendor.
9.6 Reference data for floorplans

The following subsections provide reference data for floorplanning:
• RAM inputs.
• Instruction and data cache RAM blocks.
• TAG RAM blocks.
9.6.1 RAM inputs
The RAM blocks that are most critical to floorplan are:

• Larger RAM blocks with a larger address setup.
• RAM blocks that are far away from the standard cell area.
9.6.2 Instruction and data cache RAM blocks
You must ensure that the instruction RAM and data RAM blocks are grouped together and
placed symmetrically at the bottom of the floorplan.
9.6.3 TAG RAM blocks
It is best to locate the TAG RAM blocks close to their respective instruction or data cache RAM
blocks. Although the address setup and data out time on the TAG RAM blocks is small
compared to the data memories, the output is required earlier.
Chapter 10
Netlist Dynamic Verification
This chapter describes how to test the functionality of your implementation of the processor. It
contains the following sections:
• Netlist dynamic verification on page 10-2.
Netlist Dynamic Verification
10.1 Netlist dynamic verification

You must use static equivalence checking tools to verify your post-synthesis and post-layout
netlists. This is described in the Reference Methodology documentation from Arm.
Note
Arm requires you to use equivalence tools to verify your netlist. Equivalence checking provides
a complete method for verifying your netlist and does not require the extensive simulation
compute resources that other methods require.
In addition, you can use the integration kit to perform dynamic verification, by simulating your
netlist. See Chapter 12 Integration Kit for more information.
Chapter 11
Sign-off
In addition to your normal ASIC flow sign-off checks, you must satisfy certain verification
criteria before you sign off your design. This chapter describes the sign-off criteria. It contains
the following sections:
• About sign-off on page 11-2.
• Obligations for sign-off on page 11-3.
• Criteria for sign-off on page 11-4.
• Steps for sign-off on page 11-5.
• Completion of sign-off on page 11-6.
Sign-off
11.1 About sign-off

Figure 11-1 is a process diagram that shows the top-level inputs, resources, outputs, and controls
and constraints for sign-off.

Contractual requirements
Partner sign-off requirements
Inputs:
Validation reports and logs
Outputs:
Logical Verification reports and logs Sign-off
Signed off macrocell
Timing Verification reports and logs
Dynamic Verification reports and logs
Resources:
Signatories
Figure 11-1 Sign-off process
Sign-off
11.2 Obligations for sign-off

Signatories must approve the sign-off of the design in accordance with:
• The terms of the contract with Arm.
• Any other partner sign-off requirements.
For more information see Implementation obligations on page ix.
Sign-off
11.3 Criteria for sign-off

The following sections describe the two types of requirement for sign-off:
• Mandatory for sign-off.
• Recommended for sign-off.
11.3.1 Mandatory for sign-off
All Arm partners must fulfill the terms of their contract with Arm to complete sign-off.
In most cases, you must complete the following implementation stages successfully for sign-off:
• Logical Equivalence Check. See the Reference Methodology documents supplied by your
EDA tool vendor.
• Reports and logs from each of these stages are required for sign-off.
• A certain minimum set of deliverable outputs is required at the end of the implementation.
See Completion of sign-off on page 11-6.
Note
You can change the timing constraints to suit your design provided it still meets all the
mandatory criteria for sign-off.
11.3.2 Recommended for sign-off
Table 11-1 shows the recommended stages for sign-off.
Table 11-1 Recommended stages for sign-off
Sign-off stage Notes
Design Rule Check (DRC) See the Reference Methodology documents supplied by your EDA
tool vendor
Layout Versus Schematic (LVS)
Characterization
Timing verification through Static Timing Analysis (STA)
Gate-level simulation in the IK with a back-annotated netlist -

running at your target clock frequency
Sign-off
11.4 Steps for sign-off

To sign off the processor you must meet the criteria as they are described in each of the
following stages in the design flow:
1. RTL integration.
2. Post-synthesis and place-and-route.
3. Post place-and-route timing.
Note
You must also ensure you meet any additional verification or usage criteria that might be
identified in the legal agreement between your company and Arm.
11.4.1 RTL integration
You must verify the RTL deliverables before you begin the synthesis stage by running the
supplied integration kit on the configured RTL. Running these tests demonstrates that the RTL
has been successfully installed and configured.
11.4.2 Post-synthesis and place-and-route
You must verify the functionality of the final place-and-routed netlist before you sign off the
macrocell. This verification requires you to prove logical equivalence between the validated
processor RTL and the final place-and-routed netlist, using formal verification tools. See the
Reference Methodology documents supplied by your EDA tool vendor.
11.4.3 Post place-and-route timing
You must verify the timing of the post-layout netlist before you sign off the netlist using STA.
Arm also recommends that you run:
• all of the functional vectors appropriate to your configured build
• back-annotated timing, as a final check.
Sign-off
11.5 Completion of sign-off

For successful completion of sign-off, you must have completed and verified Arm related
deliverables from the implementation process. These include:
• GDS II output.
• Test vectors.
• Extracted timing model.
• Simulation model.
• All required reports and logs.
Chapter 12
Integration Kit
This chapter describes the Cortex-M7 processor Integration Kit (IK). It contains the following
sections:
• About the IK on page 12-2.
• Cortex-M7 processor IK flow on page 12-4.
• Test overview on page 12-5.
• Configuring the testbench on page 12-7.
• Configuring the IK RTL on page 12-9.
• Configuring and compiling tests on page 12-11.
• Running the testbench on page 12-16.
• Measure power consumption on page 12-19.
• Debugging failing tests on page 12-21.
• Modifying the IK RTL for your SoC on page 12-23.
• IK components on page 12-28.
• About GPIO Integration on page 12-31.
• Debug driver on page 12-35.
• Modifying IK tests on page 12-37.
Integration Kit
12.1 About the IK

The Cortex-M7 processor Integration Kit (IK) is provided as a reference to enable easy
integration of the Cortex-M7 processor into your system, and contains tests to check that you
have performed this integration correctly.
The Cortex-M7 processor IK instantiates the supplied CORTEXM7INTEGRATIONMCU module and is

used in an example system in the Cortex-M7 processor IK. The CORTEXM7INTEGRATIONMCU is an
example integration of the processor with a low area debug and trace components. See
Appendix G CORTEXM7INTEGRATIONMCU.
The IK RTL supports configuration options. See Configuring the IK RTL on page 12-9 for more
information.
Note
The IK RTL does not support the LOCKSTEP or CPUWAIT options. The ARM_CM7IK_INITAHBPEN option
must always be enabled because the GPIO is connected to the AHB bus.
You can modify it to suit your requirements, see Modifying the IK RTL for your SoC on
page 12-23, Modifying IK tests on page 12-37 and IK limitations on page 12-3 for more
information.
The IK tests work with all valid configuration options of the Cortex-M7 processor, Cortex-M7
DAP and optional CoreSight ETM-M7. However, ETM data trace is not supported.
The IK supports RTL, DSM, and netlist simulation.
Note
The IK also supports Unified Power Format (UPF) power aware simulation. See Running with
UPF on page 12-17 and Chapter 14 Power Intent for more information.
The tests supplied with the IK are written in C and are compliant with the Cortex
Microcontroller Software Interface Standard (CMSIS) to aid code portability. The test code is
designed to be easily modifiable to work in your own system.
The IK is based on a simple example microcontroller, CM7IKMCU, that instantiates the IK

subsystem, cm7_ik_sys, that in turn instantiates the CORTEXM7INTEGRATIONMCU level, ROM, RAM,
a Power Management Unit (PMU), a system level ROM table, a reset controller, and some
General Purpose Input Output (GPIO). A second instantiation of the Cortex-M7 processor
subsystem, the Debug Driver, generates debug stimulus in the testbench if the configuration
includes debug.
Figure 12-1 on page 12-3 shows a high level view of the IK, where the example microcontroller
CM7IKMCU is the device under test. Figure 12-3 on page 12-23 shows a more detailed block
diagram of the CM7IKMCU and the IK testbench. Figure 12-9 on page 12-36 shows a more detailed
block diagram of the debug driver, cm7_ik_debug_driver, that provides Serial Wire (SW) or
JTAG stimulus in the IK testbench.
Integration Kit
tbench
CM7IKMCU (u_mcu) cm7_ik_debug_driver (u_dbg_drv)

DEBUG (Serial Wire or JTAG)
cm7_ik_sys (u_sys) CORTEXM7INTEGRATIONMCU
CORTEXM7INTEGRATIONMCU GPIO (Test Control) (u_cortexm7integrationmcu)
(u_cortexm7integrationmcu)
Figure 12-1 Cortex-M7 processor IK overview
12.1.1 IK limitations
The Cortex-M7 processor IK is designed to be a simple, representative example of a basic

microcontroller. As such, the IK has some known limitations and is not a replacement for other
testing. See Chapter 11 Sign-off for details of your sign-off obligations.
The IK tests do not exhaustively test the Cortex-M7 processor I/O because not all I/O pins have
an effect that is visible to program code, and some pins are tied to static values within the
CM7IKMCU example system. This means that you must not use the passing of all IK tests as the
only sign-off criteria for successful processor integration.
IK limitations include the following:
• Some implementation parameters do not have a program-visible effect, so cannot be

tested in the IK. For example RAR.
• Some tests are timing sensitive to test the effect of implementation parameters such as WIC
and WICLINES.
• Some tests require the presence of at least four external interrupt pins.
• Some pins are tied-off to static values, for example the debug authentication signals,
DBGEN and NIDEN are tied HIGH in the cm7_ik_sys module.
• Accessing the ITCM and DTCM memories using the AHBS bus is not utilized in the
integration kit.
• Signal CPUWAIT that can halt the processor after leaving reset, is not used.
• The IK is designed to test a single processor subsystem such as a microcontroller. The IK

does not support testing at the CORTEXM7INTEGRATIONCS level of hierarchy.
• The integration kit does not support the processor in lockstep mode. As a result, signals
CLK1EN, FCLK1EN, HCLK1EN, DCCINP, and DCCINP2 are tied off. Output
signals DCCOUT and DCCOUT2 are not monitored.
• The DFT signals DFTSE, DFTRSTDISABLE, and DFTRAMHOLD are tied off. See
ATPG Test Interface on page 6-3.
• The Memory MBIST signals are tied off or unused, see MBIST Interface on page 6-7.
• Signal IADBGPROT that indicates a protected instruction is tied off.
Integration Kit
12.2 Cortex-M7 processor IK flow

The Cortex-M7 processor IK is intended as a platform that enables you to develop a SoC
incorporating the Cortex-M7 processor. Figure 12-2 shows the Cortex-M7 processor IK flow.
Start
Configure the IK testbench

environment
Configure IK RTL
Debug
Configure and compile tests
Run IK tests
†
All tests No
pass?
Yes
Use the example subsystems to
build your own SoC
Check subsystem
Modify IK tests to be compatible
and test program
with your SoC modifications
Run IK tests
SoC
integration
No
verified
completely
?
Yes
If required, re-run tests on your

SDF back-annotated netlist
Complete
† Depending on the configuration you choose, some tests might skip
Figure 12-2 Cortex-M7 processor IK flow
Integration Kit
12.3 Test overview

Table 12-1 shows the IK test programs in the testbench/execution_tb/tests directory.
Table 12-1 IK test programs
Test program Description
hello_world The processor reads the CPUID register and writes to the GPIO registers to print a simple message. This must be
the first test run. You can run this test without compiling it, as both the source code and binary executable versions
are supplied. If you want to use the pre-compiled binary executable you must copy it from the pre_compiled
directory to the test directory before use.
config_check This test verifies that the processor configuration matches the expected configuration values set in the IKConfig.h
file. This must be the second test run.
dhrystone This test runs the Dhrystone benchmarking program. The default number of iterations is five. You can change the
number of iterations by editing the ITERATIONS value in the Makefile. You can run this test without compiling it, as
both the source code and binary executable versions are supplied. To use the pre-compiled binary executable, copy
it from the pre_compiled directory to the test directory before use.
Note
The pre-compiled binary of the dhrystone test supplied is only for processor configurations that include the FPU.
If your processor configuration does not include the FPU you must configure the Makefile as described in Test
program compilation using the Arm compiler on page 12-15 and compile the dhrystone test yourself.
romtable This test checks that it is possible for a debugger to autodetect the Cortex-M7 processor. The test uses the DAP to
locate the architecturally-defined ROM table to locate the processor. If you have included system-level ROM
tables, the content of these is displayed, but not checked.
Note
You must set the JEPID and PARTNUM fields correctly in your system ROM table, otherwise this test fails. Modify the
ROM table ID default parameter values at the CORTEXM7INTEGRATIONMCU level appropriately and set the IK expected
values in the IKConfig.h file to match.
See Configuring the CORTEXM7INTEGRATIONMCU level on page G-3, and the IK system ROM table
configuration options in Table 12-9 on page 12-14. For more information on ROM table SoC specific IDs, see
CoreSight ROM tables on page 4-50.
debug The test checks the pins LOCKUP, EDBGRQ, HALTED, DBGRESTART, and DBGRESTARTED.
itm_trace This test generates trace using the ITM and the Trace Port. Checking is limited to validating the protocol of the
generated trace.
etm_i_trace If the ETM is implemented, this test generates instruction trace using the ITM, ETM and the Trace Port. Checking
is limited to validating the protocol of the generated trace.
vtor This test demonstrates relocating the vector table in the system region.
sleep This test exercises the sleep modes of the processor, and the SLEEPING and SLEEPDEEP pins.
The test uses an interrupt to wake the processor, and if the processor includes debug, the test also wakes the
processor from sleep through the DAP. You can extend this test to verify state retention if that is implemented.
Note
• The sleep test is not supported for power aware simulation if the UPF file does not include state retention.
• The sleep test is not supported for power gated netlist simulation if state retention flip-flops are not used.
Integration Kit
Table 12-1 IK test programs (continued)
Test program Description
mpu This test sets up a number of MPU regions and demonstrates the generation of faults from the MPU.
Note
• This test is only useful for implementations that are configured to include the MPU.
• If you run this test on an implementation that is not configured to include the MPU, the test passes without
performing useful work.
interrupt This test exercises NMI, IRQ, TXEV, and RXEV. The connection of up to 32 interrupts are tested.
maxpwr This tests the power consumption of the processor at sustained maximum power. You can run this test without
compiling it, as both the source code and binary executable versions are supplied. To use the pre-compiled binary
executable, copy it from the pre_compiled directory to the test directory before use. The maxpwr test pre-compile
binary is configured for operation with an FPU. If the FPU is not present you must recompile the test before use.
reset This test checks the SYSRESETREQ output and that accesses to the AHB default slave cause a fault.
tcm This tests the memory error response of the TCMs.
wfi This test measures minimum power when the processor is awaiting an interrupt. You can run this test without
compiling it, as both the source code and binary executable versions are supplied. To use the pre-compiled binary
executable, copy it from the pre_compiled directory to the test directory before use.
Integration Kit
12.4 Configuring the testbench

The testbench instantiates the CM7IKMCU level of the IK. See Testbench structure on page 12-23
for more information. The testbench supports simulation of Verilog RTL source.
Table 12-2 shows the Verilog command files in the logical/testbench/execution_tb/verilog/

directory.
Table 12-2 Verilog command files
File Description
tbench.vc Used for all simulations.

Defines paths to testbench components and controls VCD generation.
ovl.vc Used for OVL assertions.

Defines the path to your Accellera OVL library installation.
The ovl.vc file is set up with the AHB-Lite protocol checker disabled. If you have the AHB-Lite protocol
checker and want to use it in a simulation then you must modify the ovl.vc file to uncomment the line that
defines the ARM_CM7IK_AHBLitePC_ON macro, and set the path where the AHB-Lite protocol checker is installed.
Note
The AHB-Lite protocol checker is provided in the Cortex-M System Design Kit.
dsm.vc Used for DSM simulations.

Defines the paths to the DSM testbench Verilog files.
rtl.vc Used for RTL simulations.

Defines the paths to the processor Verilog files.
This file assumes that the CoreSight ETM-M7 is present in your Cortex-M7 processor configuration. If your
configuration does not include the ETM then you can modify the rtl.vc file to comment out the lines relating
to the ETM.
You can edit the logical/testbench/execution_tb/make.cfg file to configure the execution

testbench. The configuration options allow you to enable or disable the following:
• Tarmac trace.
• OVL assertions.
• 64-bit simulation.
• Using the simulation GUI.
• Verdi capture (MTI simulator only).
• UPF simulation.
• Netlist simulation.
• Netlist simulation with SDF.
• Simulation with a DSM model.
• Coverage (VCS simulator only).
Note
• If you change any parameters or anything that affects the processor or testbench, you must
run make clean before running a test.
• If you enable Open Verification Library (OVL) assertions you must edit the ovl.vc file
and add paths to your OVL libraries.
• If you are using a 32-bit machine to run the execution testbench you must not enable
64-bit simulation.
Integration Kit
12.4.1 Netlist considerations
To simulate a netlist, you must modify the netlist.vc file as described in Configuring the
testbench on page 12-7. The following defines also affect netlist simulations:
• The Verilog define ARM_CM7IK_SDF, in the file

logical/testbench/execution_tb/verilog/netlist.vc, determines if delays specified by
SDF are included in netlist simulations. Ensure this define is included if you want SDF
annotation from netlist simulation. Ensure this define is not included if you want do not
want SDF annotation from netlist simulation.
• The Verilog define ARM_CM7IK_NETLIST_SDF, in tbench.v, points to the SDF file from
synthesis flow.
• The Verilog define ARM_CM7IK_NETLIST_SCOPE, in tbench.v, points to the netlist instance.
The Verilog define ARM_INPUT_DELAY in file cm7_ik_defs.v sets the input delay in the
CORTEXM7INTEGRATIONCS_input_delay.v wrapper. An input delay of 1ns is applied to the input
ports of the netlist. The Verilog wrapper, CORTEXM7INTEGRATIONCS_input_delay.v is located in the
testbench/execution_tb/verilog directory.
Before running a netlist simulation, you must ensure that you have either:
• Synthesized using the Reset All Registers (RAR) option.
• Alternatively, either ensure that all registers are initialized by depositing a value on
flip-flop outputs, or modify your gate-level library so that flip-flops are initialized at the
start of the simulation.
12.4.2 State retention power gating considerations
To run a UPF RTL simulation you must define ARM_SRPG_ON in

logical/testbench/execution_tb/verilog/rtl.vc.
Note
You must ensure that ARM_SRPG_ON is not defined if you do not use UPF in RTL simulations.
Integration Kit
12.5 Configuring the IK RTL

This section describes how you can configure the IK RTL.
12.5.1 Configuring the IK
The IK uses Verilog defines to control the generation of logic outside of the
CORTEXM7INTEGRATIONMCU level and to capture system-specific values for parameters.
Note
Before running any tests, you must configure the system ROM table SoC-specific ID values
correctly for your JEPID, PARTNUM and revision in the CORTEXM7INTEGRATIONMCU.v file. See
Configuring the CORTEXM7INTEGRATIONMCU level on page G-3 and CoreSight system
integration on page 4-50. You must also set these values in the IK ROM table configuration test
defines, see Table 12-9 on page 12-14.
Table 12-3 lists the defines in logical/testbench/execution_tb/verilog/cm7_ik_defs.v. You

must modify the values to match your configuration of the CORTEXM7INTEGRATIONMCU level.
Table 12-3 IK defines
Define Description
ARM_CM7IK_BASEADDR Specifies the location of the ROM table base address for the Cortex-M7 DAP.
Changing this define does not modify the location of the system level ROM table in the system.
You must only modify this define if you are also modifying the CM7IKMCU memory map.
ARM_CM7IK_CFGBIGEND Specifies the endianness of the Cortex-M7 processor in CM7IKMCU and in the debug driver.
Note
If you are compiling tests using an Arm compiler, edit the COMPILE_BE variable in the Makefile to
match.
ARM_CM7IK_CFGITCMSZ Specifies the ITCM size. Default size of 1MB.
ARM_CM7IK_CFGDTCMSZ Specifies the DTCM size. Default size of 1MB.
ARM_CM7IK_CFGAHBPSZ Specifies the AHBP region size. Default size of 512MB.
ARM_CM7IK_CFGSTCALIB Specifies the SysTick calibration.
ARM_CM7IK_INITRMWEN Specifies RMW enable initialization out of reset.
ARM_CM7IK_INITTCMEN Specifies TCM enable initialization out of reset.
ARM_CM7IK_INITRETRYEN Specifies TCM retry enables out of reset.
ARM_CM7IK_INITAHBPEN Specifies AHB peripheral enable initialization out of reset.
ARM_CM7IK_CFGJTAGnSW Specifies whether the DAP is configured as JTAG or SW.
ARM_CM7IK_INSTANCEID Specifies the Instance ID for the DAP.
ARM_CM7IK_INITVTOR Specifies the vector table initialization value.
ARM_CM7IK_ITCMWAIT Specifies how to extend the current response phase for the ITCM.
ARM_CM7IK_DTCMWAIT Specifies how to extend the current response phase for the DTCM.
Integration Kit
Note
• The IK requires these defines to be set appropriately so that the GPIO, memories and the
Cortex-M7 DAP are correctly configured to support the CORTEXM7INTEGRATIONMCU level.
The instantiation of the CORTEXM7INTEGRATIONMCU level in
logical/testbench/execution_tb/verilog/example_sys/verilog/cm7_ik_sys.v uses these
defines. They are also used elsewhere in the IK to configure other IK logic.
• The IK requires that the AHB Peripheral Enable is always set because the IK GPIOs are
connected to this port.
If you build a system that includes debug, and you include a CoreSight system level ROM table,
you must pass your own JEP-106 ID, part number and revision values into the instantiation of
cm7_cs_apb_rom_table. See CoreSight system integration on page 4-50, IK system ROM table
configuration options in Table 12-9 on page 12-14 and Configuring the
CORTEXM7INTEGRATIONMCU level on page G-3.
Integration Kit
12.6 Configuring and compiling tests

This section describes how to configure and compile the test programs before running a
testbench simulation.
The tests have been developed and tested using Arm Development Studio 5 (DS-5) compiler
running under Linux.
Note
See the Arm® Cortex®-M7 MCU Release Note for the Arm compiler versions that have been
tested with the deliverables.
You might have to modify:

• The tests if you want to use an alternative compiler.
• The Makefile, or use an alternative system, if you want to use a different OS.
12.6.1 IK test configuration
The IK tests check the configuration of the Verilog RTL on which they are running, against the
expected values defined in the IKConfig.h header file. IKConfig.h contains a number of
EXPECTED_* defines having a variable part that is the same as the RTL configuration option. You
must ensure that the configuration options match the configuration of your RTL, see
Configuration options on page 2-3 for more information.
Note
If you use Keil MDK-Arm to build your tests, you can use the Configuration Wizard to update
the values in IKConfig.h.
IK Processor configuration options
Table 12-4 shows the IK processor configuration options.
Table 12-4 IK processor configuration options
Name Description
EXPECTED_BIGEND Expected value of BE parameter. See Table 4-25 on page 4-39.

Note
• The Cortex-M7 processor is in little-endian configuration. You must compile the IK tests
as little-endian.
• If you are compiling tests using an Arm compiler, edit the COMPILE_BE variable in the
Makefile in the tests directory to match.
EXPECTED_DBGLVL Expected value of DBG parameter. See Table 2-1 on page 2-3.
EXPECTED_MPU Expected value of MPU parameter. See Table 2-1 on page 2-3.
This applies to the Cortex-M7 processor and the Cortex-M7 DAP.
EXPECTED_IRQNUM Expected value of IRQNUM parameter. See Table 2-1 on page 2-3.
EXPECTED_IRQLVL Expected value of IRQLVL parameter. See Table 2-1 on page 2-3.
Integration Kit
Table 12-4 IK processor configuration options (continued)
Name Description
EXPECTED_SYST Expected SysTick extension parameter. The options are:

0 Absent.
1 Present.
Note
The SysTick feature is always present in the Cortex-M7 processor, so set this option to 1.
EXPECTED_WIC Expected value of WIC parameter. See Table 2-1 on page 2-3.
EXPECTED_WICLINES Expected value of WICLINES parameter. See Table 2-1 on page 2-3.
EXPECTED_ICACHE Expected value of ICACHE parameter. See Table 2-1 on page 2-3.
EXPECTED_DCACHE Expected value of DCACHE parameter. See Table 2-1 on page 2-3.
EXPECTED_CACHEECC Expected value of CACHEECC parameter. See Table 2-1 on page 2-3.
EXPECTED_ICACHE_SIZE Expected value of ICACHE_SIZE parameter. See Table 8-3 on page 8-6.
EXPECTED_DCACHE_SIZE Expected value of DCACHE_SIZE parameter. See Table 8-3 on page 8-6.
EXPECTED_FPU Expected value of FPU parameter. See Table 2-1 on page 2-3.
Note
If you are compiling tests using an Arm compiler, edit the COMPILE_FPU variable in the Makefile in
the tests directory to match.
EXPECTED_ITCMSZ Expected Instruction Tightly Coupled Memory size parameter. See Table 4-26 on page 4-40.
EXPECTED_DTCMSZ Expected Data Tightly Coupled Memory size parameter. See Table 4-26 on page 4-40.
EXPECTED_INITVTOR Expected default initialization vector. See the Arm®v7-M Architecture Reference Manual for more
information about the Vector Table Offset Register (VTOR).
EXPECTED_INITRETRYEN Expected initial value for TCM retry enable. See Table 4-26 on page 4-40.
EXPECTED_INITRMWEN Expected initial value for TCM Read Modify Write enable. See Table 4-26 on page 4-40.
EXPECTED_AHBPSZ Expected address range of the AHB bus:

0 AHBP disabled.
1 64 MB.
2 128 MB.
3 256 MB.
4 512 MB.
EXPECTED_TRC Expected internal trace support. See Table 2-1 on page 2-3.
EXPECTED_CSI Expected CoreSight integration level must always be set to 1.
EXPECTED_CTI Expected Cross Trigger Interface. See Table 2-1 on page 2-3.
Integration Kit
IK processor tie-off options
Table 12-5 shows the IK processor tie-off options.
Table 12-5 IK processor tie-off options
Name Description
EXPECTED_STCALIB The expected value of CFGSTCALIB[25:0].

Ensure this configuration option matches the tied-off value of the corresponding signal.
See SysTick signals on page 4-46 for information about how to determine this value for your design.
IK DAP configuration options
Table 12-6 shows the IK DAP configuration options.
Table 12-6 IK DAP configuration options
Name Description
EXPECTED_BASEADDR The expected value of the CM7DAP CoreSight Component pointer.

See CoreSight ROM tables on page 4-50 for information about how to determine this value for your
design.
EXPECTED_JTAGnSW Expected value of JTAGnSW parameter.
EXPECTED_SWMD Expected value of SWMD parameter.
EXPECTED_TREVISION Expected value of the TREVISION field of the TARGETID parameter.
EXPECTED_TPARTNO Expected value of the TPARTNO field of the TARGETID parameter.
EXPECTED_TDESIGNER Expected value of the TDESIGNER field of the TARGETID parameter.
EXPECTED_HALTEV Expected Halt Event Support must always be set to 1.
IK DAP tie-off options
Table 12-7 shows the IK DAP tie-off options.
Table 12-7 IK DAP tie-off options
Name Description
EXPECTED_INSTANCEID Expected value of INSTANCEID[3:0].

See Table D-23 on page D-23.
Integration Kit
IK CoreSight ETM-M7 configuration options
Table 12-8 shows the IK CoreSight ETM-M7 configuration options. If you have not licensed
the CoreSight ETM-M7, or do not include it in your configuration, you must set the ETM
parameter to 0 in your RTL and in IKConfig.h.
Table 12-8 IK CoreSight ETM-M7 configuration options
Name Description
EXPECTED_ETM Expected value of the ETM parameter
IK system ROM table
Table 12-9 shows the IK system ROM table configuration options.
Table 12-9 IK system ROM table configuration options
Name Description
EXPECTED_CUST_JEPID Expected value of cm7_cs_apb_rom_table JEPID parameter. This value is your own JEDEC JEP-106
identity code value.
See CoreSight ROM tables on page 4-50.
EXPECTED_CUST_JEPCONT Expected value of cm7_cs_apb_rom_table JEPCONTINUATION parameter. This value is your own
JEDEC JEP-106 continuation code value.
EXPECTED_CUST_PART Expected value of cm7_cs_apb_rom_table PARTNUMBER parameter. This value is the part number
value that enables you to identify your system.
EXPECTED_CUST_REV Expected value of cm7_cs_apb_rom_table REVISION parameter. This value identifies the revision of
your system, as defined by your part number value.
IK system ROM table tie-off options
Table 12-10 shows the IK system ROM table tie-off options.
Table 12-10 IK system ROM table tie-off options
Name Description
EXPECTED_CUST_REVAND Expected value of cm7_cs_apb_rom_table ECOREVNUM[3:0]. Ensure that this configuration

option matches the tied-off value of the corresponding signal.
IK ECO and revision tie-off options
Table 12-11 shows the IK processor tie-off options.
Table 12-11 IK ECO and revision tie-off options
Name Description
EXPECTED_ECOREVNUM Expected value of ECOREVNUM[51:0]
Integration Kit
12.6.2 Test program compilation using the Arm compiler
This section describes how to compile the test programs with the Arm compiler under Linux
using the make command. You might have to modify the Makefile in the
testbench/execution_tb/tests directory to suit your environment, for example:
• The name of the Arm compiler.
• The name of the linker.
• Compiler and linker options.
• Test configuration options.
• Support for Big or Little Endian. Set COMPILE_BE to match your processor endianness
configuration.
• Support for FPU. Set COMPILE_FPU to match your processor FPU configuration.
Test programs are compiled into the tests directory. The make command compiles:
• Binary .elf files for use with a debugger.
• Binary .bin files for memory initialization.
• ASCII .inc files that other C program files might include.
• ASCII .rcf (Arm ROM Code) files for use with Arm ROM models.
• ASCII .disass files contain the program in Arm assembly code.
• ASCII .map file links the instructions to the source subroutine.
To compile a test:
1. Change to the testbench/execution_tb/tests directory.
2. Use the Makefile in testbench/execution_tb/tests to compile the test programs. The

command can be either:
make <test_program> For individual tests.
make all For all tests.
where:
<test_program> Selects an individual test program to compile. See Table 12-1 on
page 12-5 for a list of available tests.
all Compiles all the test programs into the current directory.
For example, to compile the test hello_world.c, type:
make hello_world
Note
• The Arm Compiler must be on your path.
• If no individual test program is selected and the option all is not used with the make
command, the default is to compile all the tests listed in Table 12-1 on page 12-5.
• To remove the compiled tests and prepare for a fresh compilation, type:
make clean
Integration Kit
12.7 Running the testbench

The Makefile in the execution_tb directory runs the simulation. Type the following command
from within the execution_tb directory to run one simulation:
make run SIM=<simulator> TESTNAME=<test> [PLUSARGS=”<plusargs_list>”]
To run all the tests type:
make all SIM=<simulator>
where:
• <simulator> is one of:

— mti if you compiled the testbench using Mentor Questasim.
— vcs if you compiled the testbench using Synopsys VCS.
— ius if you compiled the testbench using Cadence IUS.
• <test> is the name of the test you compiled, see Table 12-1 on page 12-5.
• <plusargs_list> is a list of simulation plusargs. For example -gui starts the simulator in
the simulation GUI.
Note
— The square braces around the PLUSARGS option indicates that it is optional. You do
not type the square braces in the command. If you do not want to specify any
PLUSARGS then do not use this option.
— The list of PLUSARGS must be enclosed within double quotes, otherwise the Makefile
does not interpret them all as plusargs.
12.7.1 Running with a netlist
To run simulations with the CORTEXM7INTEGRATIONCS.v replaced with a netlist, ensure that:
• Set the NETLIST parameter in make.cfg.
• The file logical/testbench/execution_tb/verilog/netlist.vc points to the netlist at the

required level.
• The instantiation of the netlist in the IK does not take parameters. The parameters passed
to the netlist instance are removed with define ARM_CM7IK_NETLIST.
Note
The debug driver block also instantiates the netlist.
• The file logical/testbench/execution_tb/verilog/netlist.vc points to the appropriate

technology libraries for netlist simulation.
• The rest of the IK matches the configuration of the netlist. See Configuring the testbench
on page 12-7.
If the netlist is run with SDF annotation, ensure that the appropriate Verilog defines are correctly
set. See Netlist considerations on page 12-8.
Integration Kit
Note
A netlist generated with the processor parameter RAR set to 0 has the potential to propagate X's
from uninitialized registers. This is caused by X-pessimism in gate-level simulation. When
simulating with RAR set to 0, initialize all registers either by depositing a 0 or 1 value on the
register outputs, or by modifying the flip-flop models in your gate-level library to initialize the
models at the start of simulation.
12.7.2 Running with UPF
To simulate the RTL or netlist with a Cortex-M7 processor constraints UPF file:
1. Render the Cortex-M7 processor constraints UPF file, using the

RenderCortexM7_integration_upf.pl script with the following options:
./RenderCortexM7_integration_upf.pl -etm 1 -icache 1 -dcache 1
See Rendering UPF constraints on page 14-8 for more details on the
RenderCortexM7_integration_upf.pl options.
2. Change to the execution testbench directory:

cd logical/testbench/execution_tb
3. Configure the testbench to use UPF. In the make.cfg file, set:

UPF :=yes
4. Compile the testbench and run tests as required. For example:

make run SIM=mti TESTNAME=sleep
Note
The sleep test is only supported if you use a UPF file that uses state retention. If state retention
is not used, the sleep test fails.
12.7.3 Running with a DSM model
If you use the Verilog PLI interface, adjust the verilog/dsm.vc file to point to the location of the
CORTEXM7INTEGRATIONCS_DSM.v file.
If you use the System Verilog DPI interface, adjust the verilog/dsm_sv.vc file to point to the
location of the CORTEXM7INTEGRATIONCS_DSM.sv file.
Make the following adjustment to the execution_tb/make.cfg file.
1. Set DSM to yes.
2. Set DSM_SV to yes if using the SystemVerilog DPI.
3. Set TARMAC to yes if you require tarmac trace output.
4. Set SIM_64BIT to yes if you have a 64bit DSM model.
5. Set the DSM_MODEL_PATH to point to the location on the DSM model.
6. Run a test in the normal way, for example:

make run SIM=mti TESTNAME=hello_world
Integration Kit
12.7.4 VCD generation
The IK can generate a VCD file while running a simulation. To enable this, ensure that:
• Verilog defines ARM_CM7IK_VCD in logical/testbench/execution_tb/verilog/tbench.vc.
• Verilog defines ARM_CM7IK_VCD_START and ARM_CM7IK_VCD_STOP in

logical/testbench/execution_tb/verilog/tbench.vc.
• Verilog define ARM_CM7IK_VCD_FILE in logical/testbench/execution_tb/verilog/tbench.v.
12.7.5 Simulation logs
When a test program passes in simulation, the following message appears in the simulation log:
** TEST PASSED OK **
When a test program fails in simulation, the following message appears in the simulation log:
** TEST FAILED **
When a test program does not complete within the time limit specified by
ARM_CM7IK_TIMEOUT_CYCLES, the runaway simulation timer terminates the test and the following
message appears in the simulation log:
** TEST KILLED **
When a test program tries to test a nonexistent feature of the Cortex-M7 processor, it passes but
prints the following message in the simulation log:
** TEST SKIPPED **
The simulation log files are generated in testbench/execution_tb/logs.
Integration Kit
12.8 Measure power consumption

Three IK tests support power measurement:
• dhrystone.
• maxpwr.
• wfi.
You can measure the power consumption of your Cortex-M7 processor implementation as
follows:
1. Copy the test binary files from the logical/testbench/execution_tb/tests/pre_compiled

directory to the tests directory, one level above. Alternatively, compile the required test,
see Configuring and compiling tests on page 12-11.
2. Simulate the RTL design with tarmac generation enabled, see Running the testbench on
page 12-16.
3. Analyze the tarmac file to locate the time to start and end power measurement, see
Locating VCD start and end points on page 12-20.
4. Run a netlist simulation to generate a VCD activity file between the power measurement
points, see Running with a netlist on page 12-16 and VCD generation on page 12-18.
5. Use the VCD file together with other data from the physical implementation flow to
measure the power consumption.
Integration Kit
12.8.1 Locating VCD start and end points
You can find the measurement points for the dhrystone test as follows:
• grep the tarmac file for MUL.
• Use the timestamps of the last two MUL instructions as the start and end points respectively.
You can find the measurement points for the maxpwr test as follows:
• grep the tarmac file for SEV.
• Use the last two SEV instructions as the start and end points.
You can find the measurement points for the wfi test as follows:
• grep the tarmac file for WFI.
• Set the start point to the time of the WFI instruction plus 100ns, equivalent to ten
instructions.
• Set the end point to the start point plus 100ns, equivalent to ten instructions.
Integration Kit
12.9 Debugging failing tests

This section describes what you can do to help diagnose problems when a test or tests fail or do
not complete on hardware or testbench simulations.
If the tests are running on the simulation testbench, you can debug the tests interactively using
the functions available in your chosen simulator.
If the tests are running on hardware and a debugger is available, you can use the features
provided by the debugger to identify where the test fails.
All tests must pass, regardless of the configuration of the processor. If some tests are failing or
being killed by the runaway simulation timer, debug the tests to determine the cause of the
problem.
Arm recommends the following debug strategy:
Prioritize the failures

The simplest test is hello_world. If this test is among your failing tests, start
debugging it first.
The config_check test is more complex, but it is the only test that checks the
configuration of the Verilog RTL matches the expected values set in IKConfig.h.
If this test is failing, you must resolve the issues, because other tests assume that
the EXPECTED_* values in IKConfig.h are correct.
Check log files for errors or warnings

The test itself might indicate the cause of the failure, for example, a mismatch in
expected and actual values for a parameter.
Check configuration
Check that the EXPECTED_* values in IKConfig.h match the configuration of the
processor.
Enable message printing

By default, tests print progress and status messages to the simulation log using the
simple character output device in the top-level testbench. You can disable this by
commenting out the definition of CM7IKMCU_PRINTF in IKConfig.h before compiling
the tests. You might want to do this to reduce the runtime of the tests.
If a test is failing, enable message printing by defining CM7IKMCU_PRINTF, for
example by uncommenting it in IKConfig.h, and recompile and rerun the test to
help determine the reason for failure.
You can also enable message printing from the debug driver module by defining
DEBUGDRIVER_PRINTF in IKConfig.h and recompiling the debug driver image. This
can help you to debug an issue with a test that uses the debug driver, for example
config_check, and debug.
Run on an unmodified version of the IK to view the output that the tests produce.
Add your own debug messages

If message printing is enabled, you can insert additional calls to printf() into the
code to help determine where the test is failing.
Compare executed instructions against the test code

If tarmac is used, RTL simulations produce two log files,
<test_name>_tarmac0.log and <test_name>_tarmac1.log, of instructions executed
on the processor in CM7IKMCU and Debug Driver respectively. These can debug test
Integration Kit
failures by comparing the executed instructions with the assembly language of the
test code. You can use the *.disass files generated when the code is compiled to
assist in debug. The tarmac files are placed in the logs directory and the name of
the tests is appended to the front of the file name.
Note
See your compiler documentation if you are not using Arm Compiler to compile your tests.
Integration Kit
12.10 Modifying the IK RTL for your SoC

This section describes the testbench structure and the IK level, CM7IKMCU, memory map. Read
this section if you want to modify the IK RTL for your own SoC requirements.
12.10.1 Testbench structure
Figure 12-3 shows the testbench structure and its instantiated IK components.
tbench
CM7IKMCU
cm7_ik_sys
Power
WIC
Management CORTEXM7INTEGRATIONMCU
interface Interrupts
Unit
and JTAG/SW
miscellaneous interface
signals
64bit AXI Master Interface 32bit AHBP Interface
Debug
TCMs AXI to AHB-Lite Bridge AHB-Lite Interconnect
driver
GPIO2
AHB-Lite Interconnect
GPIO1
Reset
controller
GPIO0
RAM ROM
Powerup reset Runaway simulation

Clock generator
generator timer
Figure 12-3 Integration kit
The IK contains these levels:

• CORTEXM7INTEGRATIONMCU.
• cm7_ik_sys level on page 12-24.
• CM7IKMCU level on page 12-24.
• tbench level on page 12-25.
The testbench/ path in Figure 1-7 on page 1-9 shows the supplied IK directory structure.
This level instantiates the CORTEXM7INTEGRATIONCS, the Cortex-M7 DAP, the Cortex-M7 TPIU,
the system level ROM table, and an APB interconnect. See Appendix G
CORTEXM7INTEGRATIONMCU for more information on the CORTEXM7INTEGRATIONMCU and
About the processor on page 1-2 for more information on CORTEXM7INTEGRATIONCS.
The system level ROM table enables a debugger to uniquely identify the Cortex-M7 processor
based system, and enables debug components, such as the optional CoreSight ETM-M7, to be
discovered automatically. See CoreSight ROM tables on page 4-50.
Integration Kit
This example system ROM table has two entries:

• A pointer to the CoreSight ROM table.
• A pointer to the Cortex-M7 TPIU.
You must modify the instantiation of the module to use your own JEP-106 manufacturer ID
value and a part number that identifies your system. See IK system ROM table on page 12-14.
cm7_ik_sys level
This section describes the cm7_ik_sys level and its components. The cm7_ik_sys level contains:
• CORTEXM7INTEGRATIONMCU level.
• AXI to AHB-Lite Bridge.
• GPIO on page 12-28.
• AHB default slave on page 12-29.
• ROM controller on page 12-28.
• ROM on page 12-28.
• SRAM controller on page 12-28.
• SRAM on page 12-28.
• AHB bus interconnect on page 12-28.
• TCM RAM on page 12-30.
• Miscellaneous logic used for integration test purposes.
The cm7_ik_sys level allocates specific functions to the following GPIO signals:
General Purpose Input Output 0

This GPIO has all 32 I/O pins routed to the testbench level. These signals:
• Indicate test completion and pass or fail status.
• Display messages using a simple character output device.
• Drive the SW or JTAG interface to the DAP using the debug driver block
in the testbench.
See About GPIO Integration on page 12-31.

This GPIO drives signals in the example CM7IKMCU, for test purposes only. It drives
power management unit signals and other processor signals.

This GPIO drives signals in the example CM7IKMCU, for test purposes only. It acts
as a source of interrupts for the WIC and processor. All GPIO interrupts drive
IRQ[0] of the processor.
CM7IKMCU level
The CM7IKMCU level is a simple example MCU and contains:

• cm7_ik_sys level.
• Power management unit on page 12-29.
• Reset controller on page 12-30.
Integration Kit
tbench level
The tbench level is the top-level testbench and contains:

• CM7IKMCU level on page 12-24.
• Debug driver on page 12-30.
• Modules specific to tbench level:
Clock generator
This generates clocks for the CM7IKMCU level.
Powerup reset generator
This generates Powerup reset.
Runaway simulation timer
This is used in simulation to end tests that have not completed within a
specified cycle limit.
12.10.2 CM7IKMCU memory map
Figure 12-4 shows the CM7IKMCU memory map.
0xFFFFFFFF
AHB default slave
0xE0100000
PPB ROM table
0xE00FF000
Processor ROM table
0xE00FE000
System ROM table
0xE00FD000
Private Peripheral Bus
0xE0043000
CTI
0xE0042000
ETM
0xE0041000
TPIU
0xE0040000
Private Peripheral Bus
0xE0000000
AHB default slave
0x40001800
GPIO 2
0x40001000
GPIO 1
0x40000800
GPIO 0
0x40000000
AHB default slave
0x20100000
Memory SRAM or D0TCM/D1TCM
0x20000000
AHB default slave
0x00100000
Memory ROM or ITCM
0x00000000
Figure 12-4 CM7IKMCU memory map
Integration Kit
The CM7IKMCU memory map is characterized by the following:
• CM7IKMCU instantiates 2MB of physical memory. It is split into two blocks of 1MB:
— The first 1MB, typically flash in an MCU, is read-only memory that holds the code.
This 1MB maps to ITCM if it is enabled.
— The second 1MB, typically SRAM, is where the stack and heap are located. If
DTCM is enabled, this block is replaced by D0TCM and D1TCM, each with default
size of 1MB.
• There are three GPIOs, each allocated 2KB of space. The GPIOs are always connected to
the AHBP port in the IK.
• The Private Peripheral Bus (PPB) space of the Cortex-M7 processor is 1MB. The
following peripherals are available in this region:
— Cortex-M7 TPIU occupies 4KB starting at 0xE0040000.
— ETM occupies 4KB starting at 0xE0041000.
— CTI occupies 4KB starting at 0xE0042000.
— System level ROM table occupies 4KB starting at 0xE00FD000.
— Processor ROM table occupies 4KB starting at 0xE00FE000.
— PPB ROM table occupies 4KB starting at 0xE00FF000.
If any of these peripherals do not exist, the region maps to the APB default slave.
Note
The Processor and PPB ROM tables are always present but the other peripherals are
optional.
• All remaining memory regions are mapped to the AHB default slave, including the
reserved space. Any access to the default slave results in a fault.
12.10.3 Low-power implementation
To implement the low-power features supported by the Cortex-M7 processor deliverables might
require the files used by the integration kit to be modified. For information about how to use the
low-power modes, see Chapter 13 Low-power Integration and Chapter 14 Power Intent.
The following files are used by the integration kit to implement the low power features of the
example system:
• cm7_ik_pmu.v. The Power Management Unit (PMU), see Power management unit on
page 12-29.
• CORTEXM7INTEGRATIONCS_constraints.upf. Cortex-M7 processor

implementation-dependent constraints UPF file that is rendered using the
RenderCORTEXM7_integration_upf.pl script, see Rendering UPF constraints on page 14-8.
Do not modify this file.
• CORTEXM7INTEGRATIONCS_configuration_example.upf. Example Cortex-M7 processor UPF

configuration file. An implementation-specific configuration of the power intent that
defines the power control signals, see Power intent specification on page 14-7.
• testbench.upf. Top-level UPF file that loads the other UPF files in this list and connects
the power control signals to the Cortex-M7 processor, see Power intent specification on
page 14-7.
Integration Kit
• CM7IKMCU.v, cm7_ik_sys.v and CORTEXM7INTEGRATIONMCU.v. Example system structural files

that connect the PMU to the level above the Cortex-M7 processor, see Testbench structure
on page 12-23 The CM7IKMCU.v file also contains power domain supply voltage control
code required for power aware simulation.
You can modify all of these files to suit your requirements except for the
CORTEXM7INTEGRATIONCS_constraints.upf file. For example, if the ETM is not used in your
Cortex-M7 processor configuration, Arm recommends that you modify these files accordingly.
Integration Kit
12.11 IK components
This section describes the components supplied with the IK and instantiated by the
CORTEXM7INTEGRATIONMCU.v or cm7_ik_sys.v levels.
Note
You can use these simple example components in your system and modify them to suit your
requirements. In both cases, you are responsible for verifying the correct operation of the
components in your system.
12.11.1 GPIO
The GPIO module, logical/testbench/execution_tb/verilog/example_sys/cm7_ik_ahb_gpio.v

is an example general purpose I/O device. You can configure the GPIO pins individually as
inputs or outputs.
You can configure the GPIO to generate an interrupt when specific input values change. See
Appendix A GPIO Programmers Model.
12.11.2 ROM controller
The ROM controller,

logical/testbench/execution_tb/verilog/example_sys/cm7_ik_ahb_rom_bridge.v, is an example
AHB Read Only Memory bridge that guarantees zero wait-state responses to all AHB accesses.
12.11.3 ROM
The ROM model, logical/testbench/execution_tb/verilog/example_sys/cm7_ik_rom.v, is an

example behavioral Verilog model that supports image preloading from a file. The IK test code
image is loaded here.
Note
• cm7_ik_rom.v can be replaced with a real ROM model.
• The Makefile flow generates .rcf format data suitable for Arm models.
12.11.4 SRAM controller
The SRAM controller model,

logical/testbench/execution_tb/verilog/example_sys/cm7_ik_ahb_sram_bridge_64.v, is an
example AHB SRAM controller that guarantees zero wait-state responses to all AHB accesses
by supporting write data buffer forwarding.
12.11.5 SRAM
The SRAM model, logical/testbench/execution_tb/verilog/example_sys/cm7_ik_sram.v, is a

synchronous SRAM.
12.11.6 AHB bus interconnect
The logical/testbench/execution_tb/verilog/example_sys/cm7_ik_ahb_interconnect.v is an
example module implementing AHB address decoding and multiplexing. There are two
instances of the AHB interconnect. One connects the AHB-Lite bus from the AXI to AHB-Lite
bridge to the ROM and RAM. The other connects the AHBP bus to GPIO0, GPIO1 and GPIO2.
Integration Kit
12.11.7 AHB default slave
The AHB default slave,

logical/testbench/execution_tb/verilog/example_sys/cm7_ik_ahb_def_slv.v, handles accesses
to unused address locations in the system. The AHB default slave responds with an error each
time it is accessed. You can configure the AHB default slave as a 32-bit or a 64-bit slave. In the
IK the AHB 64-bit memory bus and the 32-bit AHB peripheral bus are connected to AHB
default slaves.
12.11.8 Power management unit
The PMU, logical/testbench/execution_tb/verilog/example_sys/cm7_ik_pmu.v, is an example

system power controller that:
• Controls the following power domains:

— The ETM power domain.
— The processor, CORTEXM7.
— The FPU in the processor.
— The cache memories.
• Interfaces with the WIC, to ensure that powerdown and wake-up behaviors are transparent
to software.
• Generates clocks for use by the processor, WIC and the memory system compatible with
the clocking, power-domain and sleeping requirements.
• Interfaces with the reset controller to meet the power control reset requirements.
• Interfaces with the processor to manage extended sleep and ensure clean power down.
Table 12-12 describes the primary outputs for an example power management unit.
Table 12-12 Example power management unit outputs
PMU signal Description
CLKEN Main processor clock enable
FCLKEN FCLK clock enable
HCLKEN HCLK clock enable
ETMCLKEN ETM clock enable
WICENREQ Request for WIC-based deep sleep
CDBGPWRUPACK Powered up ready for debug, synchronous to FCLK
SLEEPHOLDREQn Request processor to extend sleep state and ignore wakeup events
nISOLATEETM Isolation control for ETM
nPWRUPETM Powerdown control for ETM primary supply
nISOLATERAM Isolation control for cache RAMs
nRETNRAM State retain control for cache RAMs
nPWRUPRAM Powerdown control for cache RAM primary supply
nPWRUPRetnRAM Powerdown control for cache RAM retention supply
nISOLATECORTEXM7 Isolation control for the core
Integration Kit
Table 12-12 Example power management unit outputs (continued)
PMU signal Description
nRETNCORTEXM7 State retain control for the core
nPWRUPCORTEXM7 Powerdown control for the core primary supply
nPWRUPRetnCORTEXM7 Powerdown control for the core retention supply
nISOLATECORTEXM7_INT Isolation control for CORTEXM7_INT
nPWRUPCORTEXM7_INT Powerdown control for CORTEXM7_INT primary supply
Figure 14-1 on page 14-2 shows the Cortex-M7 processor power domains.
12.11.9 Debug driver
The Debug driver module, logical/testbench/execution_tb/verilog/cm7_ik_debug_driver.v, is

provided to run tests on a Cortex-M7 processor-based subsystem that is used in the IK to provide
SW or JTAG debug stimulus to CM7IKMCU. See Debug driver.
12.11.10 Reset controller
The Reset controller, logical/testbench/execution_tb/verilog/example_sys/cm7_ik_rst_ctl.v,

is an example module that controls the various reset signals in accordance with the requirements
described in Reset modes on page 4-8.
12.11.11 TCM RAM
Byte-writable TCM RAM,

logical/testbench/execution_tb/verilog/example_sys/cm7_ik_tcm_ram.v, provides options to
reset the full RAM or load from a file.
Integration Kit
12.12 About GPIO Integration

The integration kit instantiates three GPIOs internally, that is, GPIO 0, 1, and 2. For more
information about GPIO, see Appendix A GPIO Programmers Model.
Figure 12-5 shows the connection of the GPIO interrupt lines.
INT
GPIO 0
INT IRQ[0]
GPIO 1
INT
GPIO 2
External CM7IKMCU
Figure 12-5 GPIO interrupt line connections
Figure 12-6 on page 12-32 shows the GPIO 0 connections.
Note
IRQ[0] is the logical OR of the INT outputs from the three GPIOs. This enables the integration
kit interrupt tests to work even when the processor is configured to have only one external
interrupt.
Integration Kit
EXTGPIO[31] 31
EXTGPIO[30] 30
EXTGPIO[29] 29
Debug EXTGPIO[28] 28
driver EXTGPIO[27] 27
EXTGPIO[26] 26
EXTGPIO[25] 25
EXTGPIO[24] 24
EXTGPIO[23] 23
EXTGPIO[22] 22
EXTGPIO[21] 21
EXTGPIO[20] 20
EXTGPIO[19] 19
EXTGPIO[18] 18
EXTGPIO[17] 17
EXTGPIO[16] 16
charstrobe EXTGPIO[15] GPIO 0
15
EXTGPIO[14] 14
EXTGPIO[13] 13
EXTGPIO[12] 12
chardata EXTGPIO[11] 11
EXTGPIO[10] 10
EXTGPIO[9] 9
EXTGPIO[8] 8
EXTGPIO[7] 7
EXTGPIO[6] 6
EXTGPIO[5] 5
EXTGPIO[4] 4
EXTGPIO[3] 3
EXTGPIO[2] 2
TESTPASS EXTGPIO[1] 1
TESTCOMPLETE EXTGPIO[0] 0
External CMQIKMCU
Figure 12-6 GPIO 0 connections
Figure 12-7 shows the GPIO 1 connections.
31 sys_nmi_gpio NMI
30 sys_loopout_gpio
29 sys_loopin_gpio
28
27
26 DBGRESTART
25 DBGRESTARTED
24 EDBGRQ
23 Miscellaneous
GPIO 1 22 logic TSVALUEB
21 HALTED block
20 LOCKUP
19 SLEEPDEEP
18 SLEEPING
17 SLEEPHOLDACKn
16
15 TXEV
14 sys_rxev_gpio RXEV
13 sys_delayed_rxev
External CMQKMCU
Figure 12-8 on page 12-33 shows the GPIO 2 connections.
Integration Kit
Miscellaneous
GPIO 2 31:1 sys_irq_gpio[31:1] logic IRQ[31:1]
block
External CMQIKMCU
The GPIO bit assignments used in the integration kit are described in:
• GPIO 0 bit assignments
• GPIO 1 bit assignments
• GPIO 2 bit assignments on page 12-34.
12.12.1 GPIO 0 bit assignments
GPIO 0 is connected to the external GPIO pins EXTGPIO[31:0]. GPIO 0 provides the I/O
capabilities of the example MCU, with its signals routed to the top level of the MCU.
The EXTGPIO signals are used in the integration kit testbench to indicate test completion and
pass or fail status. They also provide a simple character output device and control the debug
driver block.
Table 12-13 shows the GPIO 0 bit assignments in the integration kit.
Table 12-13 GPIO 0 bit assignments
Bit Receive input from Send output to Connection information
[31] EXTGPIO[31] - Running signal from Debug Driver
[30] EXTGPIO[30] - Error signal from Debug Driver
[29] - EXTGPIO[29] Function Strobe to Debug Driver
[28:24] - EXTGPIO[28:24] Function Select to Debug Driver
[23:16] - - Not used
[15] - EXTGPIO[15] Connected to charstrobe in the top-level testbench
[14:8] - EXTGPIO[14:8] Connected to chardata in the top-level testbench
[7:2] - - Not used
[1] - EXTGPIO[1] TESTPASS in the top-level testbench
[0] - EXTGPIO[0] TESTCOMPLETE in the top-level testbench
GPIO 1 is used internally to the example MCU to drive and monitor processor signals for testing
purposes only.
These signals can drive, or can be driven by, other blocks in your SoC.
Integration Kit
Table 12-14 shows the GPIO 1 bit assignments.
[31] - NMI Drives the NMI pin of the Cortex-M7 processor, after a delay
[30] - Miscellaneous logic block Drives GPIOIN[29], after a delay
[29] Miscellaneous logic block - Delayed version of GPIOOUT[30]
[28:27] - - Not used
[26] - DBGRESTART Drives the DBGRESTART pin of the Cortex-M7 processor
[25] DBGRESTARTED - Connects to the DBGRESTARTED pin of the Cortex-M7

processor
[24] - EDBGRQ Drives the EDBGRQ pin of the Cortex-M7 processor
[23:22] - - Not used
[21] HALTED - Connects to the HALTED pin of the Cortex-M7 processor
[20] LOCKUP - Connects to the LOCKUP pin of the Cortex-M7 processor
[19] SLEEPDEEP - Connects to the SLEEPDEEP pin of the Cortex-M7 processor
[18] SLEEPING - Connects to the SLEEPING pin of the Cortex-M7 processor
[17] SLEEPHOLDACKn - Connects to the SLEEPHOLDACKn pin of the Cortex-M7

processor
[16] - - Not used
[15] TXEV - Connects to the TXEV pin of the Cortex-M7 processor
[14] - RXEV Drives the RXEV pin of the Cortex-M7 processor
[13] Miscellaneous logic block - Delayed version of the RXEV pin of the Cortex-M7 processor
[12:0] - - Not used
GPIO 2 is used internally to the example MCU to drive IRQ[31:1] for testing purposes only.
These signals can be driven by other blocks in your SoC.
Table 12-15 shows the GPIO 2 bit assignments.
[31:1] - Miscellaneous logic block Drives the corresponding IRQ pin of the Cortex-M7 processor, after
a delay. For example, bit[31] drives IRQ[31].
[0] - - Not used.
Integration Kit
12.13 Debug driver

The debug driver block is a testbench component that controls the Cortex-M7 DAP using the
JTAG or Serial Wire pins of the processor. The debug driver contains an instantiation of the
CORTEXM7INTEGRATIONMCU level, memories, and a GPIO. You can control the debug driver block
using the pins EXTGPIO[31:24] of MCU to initiate one of several predetermined operations.
This arrangement enables testing of the integration kit even when the processor in the MCU is
sleeping.
The debug driver always executes the binary file debugdriver.bin, regardless of the test run on
MCU. The debugdriver.bin binary must be built from the supplied source code. See Test
program compilation using the Arm compiler on page 12-15 for information on how to compile
and build the integration kit tests.
Table 12-16 lists the software source files used by the debug driver.
Table 12-16 Debug driver source files
File Location Description
core_cm7.h tests/CMSIS/Include/ CMSIS file that defines the peripherals for the
core_cmFunc.h tests/CMSIS/Include/ CMSIS file that provides helper functions that

access processor registers.
debugdriver.h tests/ CMSIS device specific file that defines the

peripherals for the cm7_ik_debugdriver block.
system_cm7ikdebugdriver.h tests/Device/ARM/cm7ikdebugdriver/Source/ARM/ CMSIS device vendor Header file that provides

device specific configuration for the
cm7_ik_debugdriver block.
system_cm7ikdebugdriver.c tests/Device/ARM/cm7ikdebugdriver/Source/ARM/ CMSIS device vendor C file that provides device

specific configuration for the cm7_ik_debugdriver
block.
boot_cm7ikdebugdriver.c tests/Device/ARM/cm7ikdebugdriver/Source/ARM/ This file provides the stack and heap

initialization, vector table, default handlers and
_sys_exit function used by cm7_ik_debugdriver.
retarget_cm7ikdebugdriver.c tests/ This file implements the functions necessary to

retarget the C-library printf() function output to
the cm7_ik_debugdriver GPIO pins.
debugdriver.h tests/ This header file contains various defines used by

the debug driver block, including the GPIO pin
allocations.
debugdriver.c tests/ This is the main source code file for the debug
driver block. It includes the routines for
communicating with MCU through the GPIO and
the routines to drive the MCU Serial Wire or
JTAG interface.
debugdriver_functions.h tests/ This header file contains a C enum representing the

functions that the debug driver makes available to
MCU.
Figure 12-9 on page 12-36 shows the debug driver.
Integration Kit
cm7_ik_debug_driver
31 RUNNING
30 ERROR
CORTEXM7INTEGRATIONMCU 29 FUNCTIONSTROBE GPIO
28 FUNCTIONSELECT[4] interface
27 FUNCTIONSELECT[3] to
26 FUNCTIONSELECT[2] MCU
25 FUNCTIONSELECT[1]
64bit AXI Master Interface 32bit AHBP Interface 24 FUNCTIONSELECT[0]
GPIO
TCMs AXI to AHB-Lite Bridge AHB-Lite Interconnect 22 SWDIOTMS

21
20 JTAG or
19 TDO Serial Wire
18 TDI interfaces
AHB-Lite Interconnect
17 SWCLKTCK
16 nTRST
RAM ROM
Figure 12-9 Debug driver
Note
• The timing wrapper in the debug driver is the same as that used in the MCU level.
• If any of the pins at the implementation level are modified, they must be suitably
connected in the debug driver to preserve the intended behavior.
Integration Kit
12.14 Modifying IK tests

The supplied test programs rely on the IK GPIO to report test status, generate interrupts, and
monitor status signals. To run the test programs in a custom environment, modify the code to:
• Report test passed or failed.
• Use available peripherals to generate external interrupts.
• Define appropriate exception handlers for the system.
Test programs are supplied as C source code with the IK. The header of each source code file
describes the test requirements of that code. You might have to modify these test programs to
work in your SoC validation environment.
As supplied, the code uses some components external to the processor, to self-check some of the
interface signals and to check the functionality of processor. You must adapt the integration test
programs to make use of the external components in your design for these tests. Omit one or
more of the tests if your SoC validation environment:
• Does not use a particular interface.
• Does not support self-checking of one or more of the interface signals.
The tests supplied with the IK are written in C and are compliant with the Cortex
Microcontroller Software Interface Standard (CMSIS). The CMSIS enables end users to write
code that is portable across all Arm Cortex-M based microcontrollers.
The IK includes a minimal subset of the CMSIS for the Cortex-M7 processor that is sufficient
to support the supplied tests. See http://www.arm.com/cmsis for the full version of the CMSIS.
See the CMSIS documentation for information about how to provide your customer with the
latest CMSIS library, and how to provide headers tailored to your Cortex-M7 processor-based
device.
Table 12-17 shows the files in the testbench/execution_tb/tests and

testbench/execution_tb/tests/CMSIS directories that constitute the CMSIS.
Table 12-17 CMSIS files
Filename Location Supplied by Description
boot_cm7ikmcu.c tests/Device/ARM/cm7ikmcu/Source/ARM Arm This file provides the stack and heap initialization,
vector table and default exception handlers.
boot_cm7ikmcu.c is provided as an example of a boot
file written entirely in C. The CMSIS provides
assembler example startup files that you can modify
and use instead of boot_cm7ikmcu.c.
core_cm7.h tests/CMSIS/Include Arm Defines the core peripherals for the Cortex-M7
processor.
core_cmFunc.h tests/CMSIS/Include Arm Defines the Cortex-M Core Register access

functions.
core_cminstr.h tests/CMSIS/Include Arm Defines the Cortex-M Core instructions. That is, it
defines functions that provide access to instructions
that are not part of the C-language.
Integration Kit
Table 12-17 CMSIS files (continued)
Filename Location Supplied by Description
cm7ikmcu.h tests/Device/ARM/cm7ikmcu/Include Device Device specific file that defines the peripherals for
vendor the CM7IKMCU example microcontroller device
system_cm7ikmcu.h tests/Device/ARM/cm7ikmcu/Include Device Header file that provides device specific

vendor configuration for the CM7IKMCU example
microcontroller device
system_cm7ikmcu.c tests/Device/ARM/cm7ikmcu/Include Device C file that provides device specific configuration

vendor for the CM7IKMCU example microcontroller device
Table 12-18 shows the test support files in the testbench/execution_tb/tests directory.
Table 12-18 Test support files
Filename Description
config_check.c This test verifies that the processor configuration matches the expected configuration values set in the
IKConfig.h file.
debug.c This test checks DAP accesses and the pins LOCKUP, EDBGRQ, HALTED, DBGRESTART, and
DBGRESTARTED.
debugdriver_functions.h This header file contains a C enum representing the functions that the debug driver makes available to
CM7PIKMCU.
debugdriver.c This is the main source code file for the debug driver block. It includes the routines for communicating
with CM7PIKMCU through the GPIO and the routines to drive the CM7PIKMCU SW or JTAG interface.
debugdriver.h This header file contains various defines used by the debug driver block, including the GPIO pin
allocations.
dhrystone_1.c Dhrystone benchmark source code.
dhrystone_2.c Dhrystone procedures and functions used by dhrystone_l.c.
dhrystone.h This header file contains global definitions.
etm_itrace.c If ETM is implemented this test generates trace using the ITM, ETM and the Trace Port. Checking is
limited to validating the protocol of the generated trace.
hello_world.c This file provides some tests that the processor reads and checks its CPUID register and writes to the
GPIO registers to print a simple message.
IKConfig.h This file includes some defines that you must edit to match the implemented configuration of the IK.
IKtests.c This file provides the functions the IK tests use to initialize the GPIOs and to communicate with the
debug driver and sys_exit() function that updates the TESTPASS and TESTCOMPLETE signals
when test code completes.
IKtests.h This header file describes and defines the allocation of GPIO pins used by the CM7IKMCU in the IK. It
also declares the function prototypes the IK tests use to communicate with the debug driver.
interrupt.c This test exercises NMI, IRQ, TXEV, and RXEV.
itm_trace.c This test generates trace using the ITM and the Trace Port. Checking is limited to validating the
protocol of the generated trace.
Makefile This test enables you to build the IK tests using the Arm Compiler toolchain.
maxpwr.c This test executes instructions that exercise the Cortex-M7 processor and maximize power
consumption. Run this test on your netlist to get power values.
Integration Kit
Table 12-18 Test support files (continued)
Filename Description
mpu.c This test sets up a number of MPU regions and demonstrates the generation of faults from the MPU.
Note
• This test is only useful for implementations that are configured to include the MPU.
• If you run this test on an implementation that is not configured to include the MPU, the test
passes without performing useful work.
reset.c This tests the AHB fault response from the default slave and the SYSRESETREQ pin.
retarget_cm7ikmcu.c This implements the functions necessary to retarget the C-library printf() function output to the
CM7IKMCU GPIO pins.
retarget_cm7ikdebugdriver.c This implements the functions necessary to retarget the C-library printf() function output to the
CM7IKDEBUGDRIVER GPIO pins.
romtable.c This test checks that it is possible for a debugger to autodetect the Cortex-M7 processor. The test uses
the DAP to locate the architecturally-defined ROM table to locate the processor. If you have included
system level ROM tables, the content of these is displayed, but not checked.
sleep.c This tests that the processor:

• Enters sleep mode when SLEEPING and SLEEPDEEP outputs are asserted using the
CM7PIKMCU GPIO pins.
• Wakes from deep sleep mode by a debugger using the Debug Halting Control and Status
Register (DHCSR).
Note
• The sleep test is not supported for power aware simulation if the UPF file does not include state
retention.
• The sleep test is not supported for power gated netlist simulation if state retention flip-flops are
not used.
tcm.c This tests the memory error response of the TCMs.
vtor.c This relocates the vector table and tests that when an interrupt is triggered it enters the correct relocated
vector handler region.
wfi.c This test measures the minimum power when the processor is awaiting an interrupt.
Chapter 13
Low-power Integration
This chapter describes how to use the low-power features of the Cortex-M7 processor in your
system.
• About low-power integration on page 13-2.
• Processor operation in sleep mode on page 13-3.
• System requirements for low-power states on page 13-4.
• Sleep-hold interface on page 13-5.
• Supported sleep modes on page 13-6.
13.1 About low-power integration

This chapter describes:
• Clock control.
• Sleep signals.
• How to implement the supported sleep modes.
For more information on these signals, see Clocking and resets on page 4-6, and Power control
and sleep interface on page 4-44.
For an example of how to implement power gating in your processor, see Chapter 14 Power
Intent.
For details of the architecturally defined low-power features of the processor, see the
Low-power modes section in the Arm® Cortex®-M7 Processor Technical Reference Manual.
13.2 Processor operation in sleep mode

Sleep is a concept that applies only to software executing on the processor. When the processor
is in any of the supported sleep modes, it makes the following guarantees with respect to
software execution:
• The main execution pipeline is quiescent and no instruction fetches or software data
accesses are initiated.
• There are no outstanding software transactions on any of the master interfaces and all
software accesses committed prior to sleep mode entry have completed. This includes all
instruction and data linefills on AXIM.
• There are no outstanding software writes in any of the internal buffers. Therefore, the
external TCM memories and cache RAMs contain the latest software updates.
Note
For WBRA or WBWA regions, the cache RAMs can contain dirty data and therefore L2
might not be up to date.
AHBS and AHBD accesses are independent of software execution and are therefore orthogonal
to the processor being in sleep mode. This means that the processor can enter sleep mode while
AHBS and AHBD accesses are ongoing and can remain in sleep mode while they are handled.
This has the following implications:
• AHBS and AHBD accesses can cause transactions on the master interfaces while the
processor is in sleep mode.
• AHBS and AHBD accesses can cause the internal processor state to be updated while the
processor is in sleep mode.
Therefore, the system is responsible for appropriate management of these interfaces when
attempting to put a sleeping processor into a low-power state.
13.3 System requirements for low-power states

A low-power state is defined in this section as a state with one or more processor clock signals
gated, see Clocking and resets on page 4-6. Also, power to one or more of the processor power
domains can be removed.
Implementing low-power states when the processor is in sleep mode imposes the following
requirements on your system:
• Meeting the clocking requirements of the processor and associated system logic. These
requirements depend on the sleep mode and are described in Supported sleep modes on
page 13-6.
• Appropriately managing AHBS accesses. The processor has a separate internally-gated

hclk signal controlled by the HCLKEN signal used for AHBS transfers. This allows the
AHBS to be independent of sleep mode, but because the hclk signal is derived from the
CLKIN signal, this might impose additional system-defined constraints on the use of the
AHBS while in deeper levels of sleep. These issues are described in Supported sleep
modes on page 13-6.
• Ensuring that no AHBD accesses occur when in a low-power state. This requirement is
true for all sleep modes and must be honored for correct operation because the processor
has no support for managing these accesses when in a low-power state.
The Arm® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2 specifies that
an external debugger must, when physically connected to a device, request the system to
turn on all power and clocks that are required to create and maintain a functional debug
connection to the entire system. For Cortex-M7 processor-based systems, this requires the
processor and all associated system logic to be fully powered up and clocked.
The CoreSight DAP provides the CDBGPWRUPREQ and CDBGPWRUPACK, and
CSYSPWRUPREQ and CSYSPWRUPACK signals to implement this handshake
between the debugger and the system PMU. For more details, see the Arm® Debug
Interface Architecture Specification ADIv5.0 to ADIv5.2.
• Negotiate the race condition on entry into a low-power state, where the processor can
wake-up between the cycle that the system commits to entering this state and the cycle
where the internal clk signal is gated by CLKEN. Any schemes in which clk is not
instantaneously gated are subject to this race condition and must resolve it for correct
operation. To aid this, the SLEEPHOLDREQn or SLEEPHOLDACKn handshake is
supported to ensure that the processor is kept in sleep even in the presence of a wake-up
condition. For more information on this handshake, see Sleep-hold interface on
page 13-5.
13.4 Sleep-hold interface

The Cortex-M7 processor implements the same SLEEPHOLDREQn or SLEEPHOLDACKn
interface as Cortex-M4.
This interface is provided to help the system resolve the race condition between the following
two events:
• The system commits to entering a low-power state.
• An event outside the system’s direct control causes the processor to wake-up.
Failure to correctly negotiate this race condition might result in the processor resuming
execution before the system enters a low-power state, thereby causing a loss of data or
corruption of program flow. The protocol for this handshake is defined as:
• SLEEPHOLDREQn assertion is only recognized when SLEEPING is HIGH.

Therefore, Arm recommends that SLEEPHOLDREQn is driven LOW only when
SLEEPING is HIGH.
• SLEEPHOLDREQn must remain asserted at least until either SLEEPHOLDACKn is

asserted, or SLEEPING goes LOW.
• When SLEEPHOLDACKn is asserted, SLEEPHOLDREQn must remain asserted

until entry into the low-power state is safely complete and for the entire duration of the
low-power state. The processor guarantees that SLEEPHOLDACKn remains asserted
and the processor remains in sleep state until SLEEPHOLDREQn is deasserted.
• On detection of a wake-up event, the system must wait until all required clocks and power
have been safely restored before deasserting SLEEPHOLDREQn. Detection of a
wake-up event depends on the sleep mode used, see Supported sleep modes on page 13-6.
Note
The AHBS operates independently of the sleep-hold interface. The processor can continue to
perform AHBS transactions regardless of the state of SLEEPHOLDACKn as long as hclk is
running.
13.5 Supported sleep modes

The supported sleep modes are:
• Standard sleep.
• Deep sleep.
• WIC sleep.
Different sleep modes allow the system to make different trade-offs between power saving and
wake-up latency to support a wide range of usage models.
Note
• The system could implement multiple distinct low-power states within a given sleep
mode. This is entirely system defined and invisible to the processor as long as the
requirements for the relevant sleep mode are met.
• The CLKIN signal must run in all three sleep modes.
• The figures in this section do not show the additional logic required to exit sleep mode for
a DAP powerup request.
13.5.1 Standard sleep
In this mode, the WIC is inactive and it is the NVIC that is responsible for monitoring incoming
interrupts and waking up the processor.
The internal clk signal can be gated by driving CLKEN LOW, but the internal fclk signal must
remain active by driving FCLKEN HIGH as shown in Figure 13-1.
AHBS transactions can be performed without having to enable the internal clk signal.
This mode is designed for quick entry or return operation and the system is typically expected
to:
• Not use the sleep-hold interface.
• The SLEEPING signal can be used to generate the CLKEN signal directly. When the
sleep-hold interface is not used, the system must guarantee that CLKEN is driven HIGH
on the cycle when SLEEPING is deasserted.
SLEEPING
Cortex-M7 CLKEN
FCLKEN 1
CLKIN FREECLK
Figure 13-1 Example standard sleep clock control
13.5.2 Deep sleep
The processor regards deep sleep mode to be identical to standard sleep mode.
This mode allows deeper levels of sleep that are entirely system defined. For example, deep
sleep can be used to shut down a system PLL, and for switching to a low frequency clock, to
achieve greater power savings at the expense of wake-up latency.
The system is expected to typically:
• Use the sleep hold interface because it might not be possible to enable the internal clk
signal immediately when SLEEPING is deasserted.
• Stop performing AHBS transactions and disable the internal hclk signal by driving
HCLKEN LOW. This is not a requirement and AHBS transactions can be supported in
deep sleep as long as hclk is enabled.
Figure 13-2 is an example of deep sleep clock control.
SLEEPING
SLEEPDEEP
Cortex-M7 CLKEN LOCK

Clock
PLLCLKIN
generator
FCLKEN 1
1 FREECLK
CLKIN 0
Figure 13-2 Example deep sleep clock control
13.5.3 WIC sleep
WIC sleep mode enables you to use the wake-up features in the processor after the processor
core is powered down in WIC sleep mode. In WIC sleep mode the WIC is active and is
responsible for registering pending exceptions and detecting wake-up conditions. Therefore, the
NVIC can be inactive and both the internal clk and fclk signals can be gated by driving the
CLKEN and FCLKEN signals LOW as shown in Figure 13-4 on page 13-8.
In this case, SLEEPDEEP must be enabled in the SCR and the system must request that the
NVIC handshakes with the WIC to off-load all prioritization information about exceptions
before entering sleep mode. This is performed using the WICENREQ and WICENACK
handshake signals, see Figure 13-3 for more details. The WICENREQ and WICENACK
handshake is normally performed sometime before the processor enters WIC sleep.
CLKIN
WICENREQ
WICENACK
Figure 13-3 WICENREQ and WICENACK handshake signals
The fclk and clk signals can be gated. The hclk signal can also be gated if no AHBS transactions
are performed while in WIC sleep.
Software-transparent powerdown is only supported in WIC sleep and through the use of
retention registers in the processor.
Note
If the processor core is powered down, AHBS transactions cannot be handled, see Chapter 14
Power Intent for more details.
An example of WIC sleep clock control is shown in Figure 13-4. The HCLKEN signal is not
shown as it can be either driven HIGH or LOW depending on system requirements. See
Communications to an external power management unit on page 14-4 for an example of a
power down sequence.
SLEEPING
WICENACK
WAKEUP
Cortex-M7 CLKEN LOCK

Clock
PLLCLKIN
generator
FCLKEN
1 FREECLK
CLKIN 0
Figure 13-4 Example WIC sleep clock control
Chapter 14
Power Intent
This chapter describes a fully-featured power intent design for the Cortex-M7 processor. It
describes how the logic and RAM modules can be divided into different power domains to
implement additional power saving for the Cortex-M7 processor.
This chapter contains the following sections:

• About Cortex-M7 processor power intent on page 14-2.
• Communications to an external power management unit on page 14-4.
• ETM power control on page 14-5.
• Power intent retention sequence on page 14-6.
• Power intent specification on page 14-7.
• Rendering UPF constraints on page 14-8.
• Power states and clamping values on page 14-9.
Power Intent
14.1 About Cortex-M7 processor power intent

This section describes the example power intent specification provided in the
logical/cortexm7_integration/power_intent/upf directory. This is an example of a
fully-featured power-gated design but you can use a simpler design for your Cortex-M7
processor implementation. For example, you can combine power domains together but you must
use valid power states as described in Power states on page 14-9.
The integration kit provides an example of how you can implement power gating control in your
system, including an example PMU and a sleep test, see Chapter 12 Integration Kit for details.
14.1.1 Power domains
The Cortex-M7 processor can be partitioned into several power domains as shown in
Figure 14-1.
Debugger Cross trigger
PDCORTEXM7_INT
CORTEXM7
WIC CTI
PDCORTEXM7
cm7top_sys
Interrupts
Peripherals AHBP
D0TCM ETM-M7
Tightly-Coupled
D1TCM I-Cache/D-Cache PDETM
Memory
ITCM RAM modules
PDRAM
DMA AHBS
MBIST
Cortex-M7
Processor
ROM table
AXI External Instrumentation Instruction Data

Clocks Resets
master PPB trace trace trace
Figure 14-1 Cortex-M7 processor power domains
Power Intent
The five power domains used in this example are described in Table 14-1.
Table 14-1 Power domain description
Power Domain Description
PDCORTEXM7_INT This includes the WIC and clock gates.
PDCORTEXM7 This includes all logic in the CORTEXM7 module, also referred to as the processor core, including
the FPU and NVIC, except the cache RAM modules.
PDRAM This contains the cache RAM modules only.

Note
• No other RAM modules exist within Cortex-M7.
• The cache controller logic is not included in this domain and is part of the PDCORTEXM7
domain.
PDETM This contains the ETM.
Note
The CTI, Processor ROM table and APB interconnect in the PDCORTEXM7_INT domain can
be placed in the PDCORTEXM7 domain.
Power Intent
14.2 Communications to an external power management unit

For the Cortex-M7 processor to communicate with an external PMU there must be a WIC
present. Figure 14-2 shows an example powerdown and powerup timing sequence for the
Cortex-M7 processor. This assumes that WICENREQ and WICENACK signals are both
asserted before the sequence starts, and remain asserted, see WICENREQ and WICENACK
handshake signals on page 13-7.
The Cortex-M7 processor is partitioned so that the cache RAM modules and processor core
logic can be put into retention individually.
The processor core retention process starts when it is put in a sleep or deep sleep mode indicated
by SLEEPING or SLEEPDEEP signals being asserted as shown in Figure 14-2.
The processor core including the cache RAM modules can leave retention by exiting sleep mode
or deep sleep mode. In this situation the cache RAM modules must leave before the processor
core logic.
CLKIN
2) Core enters deep sleep
SLEEPING
SLEEPDEEP
11) PMU deasserts SLEEPHOLDREQn when the
processor power supply reaches its operating voltage
SLEEPHOLDREQn
SLEEPHOLDACKn
CLKEN, FCLKEN
6) Unmasked interrupt arrives

IRQ[ ], EDBGRQ,
NMI, RXEV
7) WIC notifies PMU by asserting WAKEUP 13) Processor powered up
and WAKEUP deasserted
WAKEUP
1) NVIC loads WIC with mask before entering deep sleep 12) Core sees incoming
IRQ/NMI/RXEV and
clears the WIC
WICSENSE[ ]
The signals below demonstrate the core powerdown and powerup sequence
9) PMU drives state restoration
3) PMU isolates core power domain 10) PMU takes core out of isolation
ISOLATEn 4) PMU drives core state retention
RETAINn
PWRUP
5) PMU powers down core

8) PMU powers up core
Figure 14-2 Example powerdown and powerup timing sequence
Power Intent
14.3 ETM power control

You must only power up the ETM power domain, PDETM when the processor core is powered
up, otherwise the PDETM must be powered down.
Power up the ETM when the CDBGPWRUPREQ signal from the DAP is asserted. This occurs
when an external debugger is connected. You can add an external control register to allow
system software to control the power to the ETM.
When the ETM is powered up it must not be powered down unless the ETMPWRUPREQ
signal is LOW. This signal is controlled by the ETM TRCPDCR.PU bit and the debugger or
system software must clear this bit at the end of a trace session.
If system software is required to program the ETM, the software can determine if the ETM is
powered up by reading the ETM TRCPDSR.POWER bit. When the ETM is powered up, this
bit always reads as 1. When the ETM is powered down, the ETM APB data output signal must
be clamped LOW and its ready signal clamped HIGH. The POWER bit read value is 0 when the
ETM is powered down. To power up the ETM, the software must first request that the ETM
powers up using a system-specific external register, then it must check that the POWER bit is 1
before programming the ETM.
Reset the ETM using the nDBGETMRESET signal as part of the ETM powerup sequence.
Power Intent
14.4 Power intent retention sequence

After the Cortex-M7 processor is put into sleep mode or deep sleep mode, the PMU can begin
to power down the selected power domain.
To power down a region with retention:

1. Assert the isolation control signal to set all outputs in a safe condition.
2. Assert the state retention save condition that can retain the current value of the registers.
3. Assert the power gating control signal to power down the block.
To restore power and retain state on a region with retention:

1. Deassert the power gating control signal to power back up the block.
2. Assert the state retention restore condition to restore the values on the registers.
3. Deassert the isolation control signal to restore all the outputs.
Note
If you have implemented RAM retention without implementing retention in the processor logic,
the processor must be reset when it is powered up. In this case you must consider how to prevent
writes to the RAM during reset.
Power Intent
14.5 Power intent specification

The Unified Power Format (UPF) files are provided in the
logical/cortexm7_integration/power_intent/upf directory contains two files:
• CORTEXM7INTEGRATIONCS_constraints_unconfigured.upf. An unconfigured constraints UPF

file.
• CORTEXM7INTEGRATIONCS_configuration_example.upf. An example configuration file that

describes power domains, isolation and retention strategies.
The constraint UPF file CORTEXM7INTEGRATIONCS_constraints_unconfigured.upf specifies the

constraints for all configurations. Therefore you must render this file to generate a constraints
file that is specific for your configuration of the processor. See Rendering UPF constraints on
page 14-8.
The CORTEXM7INTEGRATIONCS_configuration_example.upf file is provided as an example power

intent file that you must change according to your Cortex-M7 processor implementation.
You can use both your configured constraints UPF file and your modified configuration file
together with the delivered RTL to validate the power intent specification of your SoC. This is
done either by:
• Statically using rule checking tools.
• Dynamically using power-aware simulation tools. See Running with UPF on page 12-17
for information on how to run a power-aware simulation in the Integration Kit. This uses
the testbench.upf file in directory logical/cortexm7_integration/power_intent/upf.
Note
The UPF files are IEEE 1801-2009 compliant.
Power Intent
14.6 Rendering UPF constraints

This section describes how to render the Cortex-M7 processor constraints UPF file using the
RenderCORTEXM7_integration_upf.pl script:
1. Locate the CORTEXM7INTEGRATIONCS_constraints_unconfigured.upf file and the

RenderCORTEXM7_integration_upf.pl script in the directory
logical/cortexm7_integration/power_intent/upf.
2. Render the CORTEXM7INTEGRATIONCS_constraints.upf file using the

RenderCORTEXM7_integration_upf.pl script with appropriate command line options for
your processor configuration. See Table 14-2.
Table 14-2 Render script command line options
Option Description
-etm Configuration for ETM:

0 ETM not present.
1 ETM is present.
-icache Specifies whether instruction cache is implemented. The options are:

0 No instruction cache implemented.
1 Instruction cache implemented.
-dcache Specifies whether data cache is implemented. The options are:

0 No data cache implemented.
1 Data cache implemented.
-uncfgFile Specifies the name of the unconfigured constraints file. The default is
CORTEXM7INTEGRATIONCS_constraints_unconfigured.upf.
-cfgFile Specifies the name of a configured constraints file. The default is

CORTEXM7INTEGRATIONCS_constraints.upf.
-help Configuration help message.
3. Locate the generated UPF constraints file for your configuration in

logical/cortexm7_integration/power_intent/upf/CORTEXM7_constraints.upf.
Power Intent
14.7 Power states and clamping values

The Cortex-M7 processor provides mechanisms and support to control both dynamic and static
power dissipation. In addition, the IK provides an example system PMU that can control the
power domains of the processor, see Power management unit on page 12-29.
The following sections describe Cortex-M7 processor power intent in more detail:
• Power states.
• Power domain clamping values on page 14-10.
14.7.1 Power states
The power domains can be controlled to give different combinations of powered up and
powered down domains. However, only some powered up and powered down domain
combinations are valid and supported.
Table 14-3 shows the valid power states of the Cortex-M7 processor. It shows that:
• The PDCORTEXM7 domain can never power up unless the PDRAM domain is powered
up.
• The PDETM domain can never power up unless the PDCORTEXM7 domain is powered
up.
These restrictions mean that clamps between these domains are only required in one direction.
Note
All transitions between power states must remain within the legal states shown in Table 14-3.
For example, when transitioning from Run mode with trace to Shutdown mode, the safest
sequence for domain powerdown is PDETM, PDCORTEXM7 and then PDRAM.
Table 14-3 Supported power states
State PDCORTEXM7_INT PDCORTEXM7 PDRAM PDETM
Run mode with trace On On On On
Run mode without trace On On On Off
Software transparent powerdown (with only RAMs on)a On Ret On Off
Software transparent powerdown (with everything off)a On Ret Ret Off
Dormant mode (with RAMs in retention)b On Off Ret Off
Dormant mode (with RAMs on)b On Off On Off
TOP on onlyc On Off Off Off
Shutdown modeb Off Off Off Off
a. Software transparent powerdown requires a WIC, see WIC sleep on page 13-7.
b. To support restoration of the processor state from either the D-cache or L2 memory you must implement an external register that is not
reset by nSYSRESET. This register must have a flag to indicate to software that the processor was in either dormant or shutdown mode
and that the state can be restored from memory.
c. This state is an optional power transition state that has no functional purpose.
Power Intent
Table 14-4 shows the Cortex-M7 processor power domains states and their behaviors.
Table 14-4 Power state description
Power state Description
Off Block is power gated
Ret Logic or RAM retention power onlya
On Block is active
a. ETM does not support Ret mode.
There are specific requirements that you must meet to power up and power down each power
domain within the processor. Not adhering to these requirements can lead to unpredictable
results. See the Low-power Modes section in Arm® Cortex®-M7 Processor Technical Reference
Manual.
14.7.2 Power domain clamping values
This section describes the output signals of the power domains that must be clamped to the
required benign values. All the outputs, other than those described in Table 14-6 to Table 14-7
on page 14-11, must be clamped LOW.
Table 14-5 shows the output signals that must be clamped HIGH for the PDCORTEXM7_INT
power domain.
Table 14-5 Outputs clamped to HIGH for PDCORTEXM7_INT
Power domain Output signal
PDCORTEXM7_INT AFREADY
AFREADYMD
AFREADYMI
GATEHCLK
HREADYOUTS
SLEEPDEEP
SLEEPING
Table 14-6 shows the output signals that must be clamped to HIGH for the PDCORTEXM7
power domain.
Table 14-6 Outputs clamped to HIGH for PDCORTEXM7
PDCORTEXM7 u_cortexm7/AFREADY
u_cortexm7/GATEHCLK
u_cortexm7/HREADYOUTS
u_cortexm7/SLEEPDEEP
u_cortexm7/SLEEPING
Power Intent
Table 14-7 shows the output signals that must be clamped to HIGH for the PDETM power
domain.
Table 14-7 Outputs clamped to HIGH for PDETM
PDETM gen_etm1/u_csetmm7/AFREADYMD
gen_etm1/u_csetmm7/AFREADYMI
gen_etm1/u_csetmm7/PREADYDBG
Chapter 15
DSM Generation
This chapter describes how to generate a Design Simulation Model (DSM). It contains the
following sections:
• About DSM generation on page 15-2.
• Prerequisites on page 15-3.
• Building and testing a DSM model on page 15-5.
• DSM generation script command line options on page 15-6.
• Command line examples on page 15-7.
• If DSM generation fails on page 15-8.
• Generation directory structure on page 15-9.
• Deliverable directory structure on page 15-10.
DSM Generation
15.1 About DSM generation

A DSM is a two-state, obfuscated, cycle accurate, simulation model. A DSM is derived directly
from the RTL and fully matches the cycle timing and behavior of the RTL. The programmers
model signals are exported to a wrapper below the top-level but no other internal signals are
visible within the model. DSMs support the major Verilog and SystemVerilog simulators,
Mentor QuestaSim, Synopsys VCS and Cadence IUS. The DSM generation flow uses the
Verilator open-source Verilog simulator that converts the Verilog RTL to C. A testbench and
simulation script is also provided with a DSM so that you can test the installation of a model.
Simulation speed, when using a DSM with the SystemVerilog DPI interface, is similar to the
RTL. But it might be slower when using the Verilog PLI interface depending on the simulator
selected.
You can optionally generate a DSM of your configured Cortex-M7 processor for in-house use
or to provide to your customers.
A script is provided to allow you to generate and test your Cortex-M7 DSM. Generation of both
32-bit and 64-bit Linux DSMs is supported.
The DSM generation script uses the integration kit to validate the model.
DSM Generation
15.2 Prerequisites
The DSM generation flow requires the following prerequisites:
• A computer with at least 8G of memory.

Download and build the Verilator simulator, see the Arm® Cortex®-M7 MCU Release Note
for the Verilator version supported:
$ cd <temporary directory>
$ wget http://www.veripool.org/ftp/verilator-<version>.tgz
$ tar zxf verilator-<version>.tgz
$ cd verilator-<version>
$ ./configure --prefix=$HOME
$ make -j4
$ make install
This puts the required verilator binaries and included files into the following directories:
~/bin/
and
~/share directories
• Make sure that the 32-bit Google protocol buffers, that are required for tarmac trace, are
installed on your system. See Appendix F Tarmac Tracing for more details.
The cm7_tarmac_decode binary included in the Cortex-M7 processor deliverables requires
external shared libraries to execute, in particular, the Google protocol buffers runtime,
libprotobuf.so and other standard libraries including:
— libz.so
— libpthread.so
— libm.so
— libstdc++.so
Note
You require 32-bit versions of these libraries. They are usually installed as compatibility
libraries on 64-bit Linux distributions.
If your system does not have the protocol buffers library, you can download and install it.
See the Arm® Cortex®-M7 MCU Release Note for the version of protocol buffers
supported:
$ wget http://protobuf.googlecode.com/files/protobuf-<version>.tar.gz
You can use sha1sum to confirm the checksum of the download:
$ sha1sum protobuf-<version>.tar.gz <version checksum>
$ tar xzf protobuf-<version>.tar.gz
$ cd protobuf-<version>
$ ./configure --with-zlib --prefix=<prefix> CXX='g++ -m32'
$ make install
Then add <prefix>/lib to your LD_LIBRARY_PATH environment variable.
Building the protocol buffer library as required for the tarmac flow depends on the zlib
library and header files. In Red Hat Linux distributions, these are provided as part of the
zlib-devel package.
DSM Generation
• See the Arm® Cortex®-M7 MCU Release Note for details of the GCC, Python and Perl
versions required by the DSM generation flow.
• The DSM models have been tested with the simulator versions supported by the
Cortex-M7 processor deliverables, as described in the Arm® Cortex®-M7 MCU Release
Note.
DSM Generation
15.3 Building and testing a DSM model

To generate, test, and package a DSM model of your Cortex-M7 processor configuration:
1. Configure Cortex-M7 processor as described in Chapter 2 Configuration Guidelines,

including cache memory integration, see Chapter 8 Cache RAM Integration for more
details.
Note
Make sure you set the ICACHESIZE and DCACHESIZE parameters correctly in the
CORTEXM7INTEGRATIONCS_CONFIG.v file in the logical/cortexm7_integration/verilog
directory.
Check that these parameter values are consistent with the ram_icu_cache_size and
ram_dcu_cache_size tie-off values in your implementation of the cm7top_cache_rams
module, see Integrating cache RAM blocks on page 8-8.
2. Run the integration kit test programs on the RTL and check they pass, as described in
Chapter 12 Integration Kit.
3. Build and test the DSM model using the generation script BuildCORTEXM7_DSM.pl, for
example:
$ cd logical/cortexm7_integration/dsm
$ ./BuildCORTEXM7_DSM.pl -vendor=<your company name> -config=<name of your

configuration>
The command line options used in the example generates a DSM using the Cortex-M7
processor configuration specified in
logical/cortexm7_integration/verilog/CORTEXM7INTEGRATIONCS_CONFIG.v, named
CORTEXM7INTEGRATIONCS_<name of your configuration>.
It is tested with all six simulators and C-language interface combinations. The final model
is then packaged into a tar file in the release directory.
4. Review the DSM deliverable readme file CORTEXM7INTEGRATIONCS_DSM_<name of your

configuration>_README.txt in the dsm/logs/<config>_<32|64>bit_unlic directory.
Check that:
• The configuration parameters are as expected.
• All the required simulator and C-language interface combinations have been tested
and all tests have passed.
DSM Generation
15.4 DSM generation script command line options

The build options are controlled with the BuildCORTEXM7_DSM.pl script command line options
described in Table 15-1. You must run the script without modification.
You must specify a vendor name and a configuration name, see Table 15-1.
Table 15-1 DSM script command line options
Command line options Description Notes
vendor=<your company name> Specifies a vendor name to generate a -

DSM model
config=<config name> Specifies your configuration name, for A configuration name must be specified to
example I64D32, for a 64KB I-cache and a generate a DSM model
32KB D-cache
15.4.1 Simulation options
The simulators that validate your model are shown in Table 15-2.
Table 15-2 DSM simulation options
-sim=mti A mentor MTI simulator using Verilog PLI • Simulations run faster using DPI.
• If no -sim option is specified, all simulation
-sim=vcs A synopsys VCS simulator using Verilog options are tested.
PLI
• A PLI model can be used with Verilog and
-sim=ius A cadence IUS simulator using Verilog PLI SystemVerilog simulators.
• DPI models can only be used with
-sim=mti-sv A mentor MTI simulator using SystemVerilog simulators.
SystemVerilog DPI • You must validate your DSM on all simulators
A synopsys VCS simulator using that you want to support.
-sim=vcs-sv
SystemVerilog DPI
-sim=ius-sv A cadence IUS simulator using

SystemVerilog DPI
15.4.2 Operating system architecture
The operating system architectures are shown in Table 15-3.
Table 15-3 DSM operating system architectures
-osarch=64 64-bit Linux • Default is 64-bit.

• A 32-bit DSM can be used with a 32-bit simulator running on 64-bit Linux.
-osarch=32 32-bit Linux
• A 32-bit DSM cannot be used with a 64-bit simulator.
• A 64-bit DSM can only be used with a 64-bit simulator running on 64-bit Linux.
• A 32-bit DSM can be generated on 64-bit Linux.
• 32-bit DSMs simulate faster than 64-bit DSMs.
DSM Generation
15.5 Command line examples
Example 15-1 64-bit Linux
./BuildCORTEXM7_DSM.pl -vendor=<your company name> -config=CONF1 –sim=mti-sv –sim=vcs-sv
Generates a DSM for your Cortex-M7 processor configuration specified in

logical/cortexm7_integration/verilog/CORTEXM7INTEGRATIONCS_CONFIG.v that supports the
default OS architecture, 64-bit Linux.
It is tested with the MTI and VCS SystemVerilog simulators using the DPI interface.
Example 15-2 32-bit Linux
./BuildCORTEXM7_DSM.pl -vendor=<your company name> -config=CONF2 –osarch=32
Generates a DSM for your Cortex-M7 processor configuration specified in

logical/cortexm7_integration/verilog/CORTEXM7INTEGRATIONCS_CONFIG.v that supports the
32-bit Linux architecture.
It is tested with all six simulators and C-language interface combinations.
DSM Generation
15.6 If DSM generation fails

Possible causes and solutions for the failure of DSM model generation are:
• Model not generated.

If the message
-I- BuildCORTEXM7_DSM.pl: DSM generation complete
is not displayed, the DSM model has not been generated.
Possible solutions:
— Check that the machine you are using has at least 8G of memory.
— If you are using a job submission system, increase the run time limits of the job.
• config_check test fails.

Check that the processor configuration parameter settings in
logical/cortexm7_integration/verilog/CORTEXM7INTEGRATIONCS_CONFIG.v
match the IK configuration settings in
logical/testbench/execution_tb/tests/IKConfig.h
• Simulation fails:
— If you are using a job submission system, check your job run time limits are
sufficient.
— Check the simulation and compile log files that are stored in
logical/cortexm7_integration/dsm/logs
— If the simulation fails to complete, view the log files for the last simulator option
located in logical/testbench/execution_tb/logs
— Check that all the IK tests have passed on the RTL.
DSM Generation
15.7 Generation directory structure

The DSM generation script and associated files are stored in the directory structure shown in
Figure 15-1.
The log files from the DSM generation processes are stored in the logs directory.
The final DSM deliverable files are in a tar file stored in the release directory.
The BuildCORTEXM7_DSM.pl script creates the directory structure shown in Figure 15-1.
cortexm7_integration/
dsm/ Contains the DSM generation script
build/ Temporary files generated during the build

release/ Contains the final tar file
release_test/ Extracted tar files, used for testing
logs/
<config>_<32|64>bit_unlic/ DSM generation log files
sim_logs/ Separate sub-directories for mti, vcs, ius, and vector replay
Figure 15-1 Generation directory structure
DSM Generation
15.8 Deliverable directory structure

The BuildCORTEXM7_DSM.pl script packages the DSM into a tar file ready for release that has the
structure shown in Figure 15-2.
cortexm7/
simulation_models/
linux_<32|64>bit_unlic/
CORTEXM7INTEGRATIONCS_DSM_<RTL revision>/
DSM/
CORTEXM7INTEGRATIONCS_DSM.v
CORTEXM7INTEGRATIONCS_DSM.a
CORTEXM7INTEGRATIONCS_DSM.so
CORTEXM7INTEGRATIONCS_DSM.sv
CORTEXM7INTEGRATIONCS_DSM.tab
CORTEXM7INTEGRATIONCS_DSM_<config>.so
cm7_tarmac_decode
testing_<config>/
CORTEXM7INTEGRATIONCS_DSM_TESTBENCH.sh
CORTEXM7INTEGRATIONCS_DSM_TESTBENCH.sh
docs/
CORTEXM7INTEGRATIONCS_DSM_<config>_README.txt
ARM_Tarmac_Specification_v2.pdf
DUI0302C_design_simulation_model_ug.pdf
Figure 15-2 Deliverable directory structure
Appendix A
GPIO Programmers Model
This appendix describes the GPIO programmers model. It contains the following section:
• About the GPIO programmers model on page A-2.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. A-1
A.1 About the GPIO programmers model

The GPIO is a general purpose I/O device. It has the following properties:
• Three registers.
• 32 input or output lines with programmable direction.
• Word and halfword read and write access.
• Address-masked byte write to facilitate quick bit set and clear operations.
• Address-masked byte read to facilitate quick bit test operations.
• Maskable interrupt generation based on input value change.
This section describes the GPIO programmers model. It contains the following sections:
• Data Register - GPIODATA.
• Direction Register - GPIODIR on page A-4.
• Interrupt Enable Register - GPIOIE on page A-4.
Table A-1 lists the GPIO registers.
Table A-1 GPIO registers
Address offset Name Type Description
0x00000000-0x000003FF GPIODATA Read/ Reads current value of GPIOIN pins, or sets value driven onto
Write GPIOUT pins.
0x00000400 GPIODIR Read/ Configures the direction of the I/O. The value is driven on GPIOEN.
Write Setting a bit defines that bit as an output.
0x00000410 GPIOIE Read/ Configures the interrupt on input change feature.

Write
See Table 12-14 on page 12-34 for details of the connections to GPIOIN and GPIOOUT.
A.1.1 Data Register - GPIODATA
Use this register to read the value of the GPIOIN pins when the corresponding GPIODIR is 0.
Use this register to drive the value onto the GPIOOUT pins when the corresponding GPIODIR
is 1.
Note
Reading GPIODATA when GPIOEN is 1 returns the value seen on the GPIOIN pin.
The register address, access type, and reset state are:

Address GPIO_BASE to GPIO_BASE + 0x000003FF.
Access Read/write.
Reset state 0x00000000.
Byte accesses to the Data Register use the bits HADDRS[9:2] as a mask. This enables you to
perform various bit set and bit clear operations efficiently because it avoids the requirement for
a read-modify-write to the GPIODATA register.
Bit set example
To set bit[9] of GPIO 0 Data Register, perform a byte write access to address 0x40000009 with
HWDATAS set to 0x200 and HSIZES set to 0b000.
The mask extracted from the address is 0x02 and applied to the second byte of the GPIO 0 Data
Register.
This sets bit[9] but preserves all other bits.
Bit clear example
To clear bit[9] of GPIO 0 Data Register, perform a byte write access to address 0x40000009 with
HWDATAS set to 0x0 and HSIZES set to 0b000.
Register.
This clears bit[9] but preserves all other bits.
Bit read example
To read bit[9] of GPIO 0 Data Register, perform a byte read access to address 0x40000009 with
HSIZES set to 0b000.
register.
HRDATAS contains the value of bit[9], all other bits are zeroes.
Figure A-1 shows the structure of the GPIO Data Register.
Signals from
D Q GPIOINT
other GPIO pins
GPIOEN[n]
GPIOIE[n]
GPIOIN[n] D Q
Mask HRDATAS[n]
GPIO External to GPIO

pin [n]
HWDATAS[n] Mask D Q GPIOOUT[n] EXTGPIOOUT[n]
EN EXTGPIOEN[n]
EXTGPIOIN[n]
HADDRS Data
HSEL register write
HWRITES enable
HTRANS
GPIOEN[n]
Figure A-1 GPIO Data Register
The external signals EXTGPIOOUT, EXTGPIOIN, and EXTGPIOEN map to GPIOOUT,

GPIOIN, and GPIOEN respectively.
You can use the GPIOINT output pin of the GPIO as an interrupt source.
A.1.2 Direction Register - GPIODIR
Use this register to configure the direction of the Data Register as either input or output. This
connects to the GPIOEN pin and is used as a tristate enable. Set bits in this register to 0b1 when
you want to use the bit as an output.

Address GPIO_BASE + 0x00000400.
Access Read/write.
A.1.3 Interrupt Enable Register - GPIOIE
Use this register to enable input signal changes on GPIOIN to trigger an interrupt through the
GPIOINT output.
You can set GPIOIE[n] to enable changes on GPIOIN[n] to pulse the GPIOINT pin.

Address GPIO_BASE + 0x00000410.
Access Read/write.
Appendix B
CoreSight SoC
This appendix describes the location of the CoreSight SoC-400 configuration files for the
Cortex-M7 processor, and describes the CoreSight SoC-400 trace comparison tools. It contains
• Location of the Cortex-M7 processor CoreSight SoC-400 support files on page B-2.
• Comparing captured trace to the trace reference file on page B-3.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. B-1
CoreSight SoC
B.1 Location of the Cortex-M7 processor CoreSight SoC-400 support files

The Cortex-M7 processor deliverables provide a header file for use with the CoreSight SoC-400
product, as described in Table B-1.
Table B-1 Location of CoreSight SoC-400 header file
Filename Description Location
cssoc_Cortex-M7.h Header file containing the description of the Cortex-M7 processor logcial/testbench/integration_cssoc
CoreSight components and associated function calls to support the
integration of a Cortex-M7 processor in a CoreSight system
In addition, a trace comparison tool is provided to compare the trace output with a trace
reference file. The location of this tool and the reference files are listed in Table B-2.
Table B-2 Location of ETM trace comparison tool
Filename Description Location
csetmm7_ik_compare Trace comparison tool (rhe5 Linux executable) to compare logical/testbench/shared/tools/bin

a trace stream from the Cortex-M7 processor with a trace
reference trace
cssoc_Cortex-M7_trace_i.ref A CoreSight SoC-400 Cortex-M7 trace reference file for logical/testbench/integration_cssoc

the ETM configured for instruction trace only. The
configuration parameter ETM is set to 1, see Table 2-1 on
page 2-3. Use this reference file with the
csetmm7_ik_compare tool to check for correct instruction
only trace generation in your system when using the
CoreSight SoC trace test.
cssoc_Cortex-M7_trace_id.ref A CoreSight SoC-400 Cortex-M7 trace reference file for logical/testbench/integration_cssoc

the ETM configured for instruction and data trace. The
configuration parameter ETM is set to 2, see Table 2-1 on
page 2-3. Use this reference file with the
csetmm7_ik_compare tool to check for correct instruction and
data trace generation in your system when using the
CoreSight SoC trace test.
CoreSight SoC
B.2 Comparing captured trace to the trace reference file

Trace generated by the CoreSight SoC-400 tests must be post-processed to check that the data
captured at each trace sink matches the reference data that the trace source is expected to
generate.
A trace comparison tool (csetmm7_ik_compare) is provided to check your trace log file. The trace
comparison tool:
• Reads in the ATB trace log file, that contains ETMv4 trace data that has been captured in
a trace sink, such as a TPIU.
• Decodes the trace to basic ETMv4 trace elements such as atoms and addresses.
• Checks it is ETMv4 compliant.
• Compares this with a reference file if supplied.
Figure B-1 shows the trace comparison processing flow.
Reference
ATB log
log
Decode trace to Parse reference

elements log
compare
Figure B-1 Trace comparison processing
The trace comparison flow supports verification of a predefined sequence of program

instructions. For information about the instruction sequence and reference files, see Location of
the Cortex-M7 processor CoreSight SoC-400 support files on page B-2. If you do not supply a
reference file for comparison, you can use the csetmm7_ik_compare tool to decode any Cortex-M7
ETM trace data.
See the Arm® CoreSight™ SoC-400 User Guide for information of the trace test and trace
post-processing, including additional tools to capture and extract ATB logs from your
simulation.
To compare captured trace to a trace reference file, run the command:
csetmm7_ik_compare -atb <log_file> -atid <id> [-data_trace] -ref <ref file> -output
<output file>
where:
• <log_file> is the ATB log file. Multiple files can be specified.
• <id> is the trace id of the Cortex-M7 ETM trace stream.
• <ref file> is the file name of the golden reference file.
• <output file> is the file name for the decoded trace items output.
To list all the available options:, run the command:
CoreSight SoC
csetmm7_ik_compare -h
For example, to perform ETM Instruction trace only comparison run the command:
csetmm7_ik_compare -atb log_ID2.atb -atid 2 -ref cssoc_Cortex-M7_trace_i.ref
For example, to perform ETM Instruction and Data trace comparison run the command:
csetmm7_ik_compare -atb log_ID2.atb -atb log_ID3.atb -atid 2 -ref

cssoc_Cortex-M7_trace_id.ref
Example B-1 shows the output from csetmm7_ik_compare for instruction only trace.
Example B-1 Output from csetmm7_ik_compare, instruction only trace
csetmm7_ik_compare
------------------
Opening atb file : log_ID2.atb
Opening ref file : cssoc_Cortex-M7_trace_i.ref
atb_logger1 : 0 : End of file : 10
reference : 0 : End of file : 7
WARN : comparison
---------------------------------------------------------
Warning : : 100 : Expected conditional elements in the trace
Warning : : 100 : Expected conditional result elements in the trace
** OK **
Example output, Instruction and Data trace:
csetmm7_ik_compare
------------------
Opening ref file : cssoc_Cortex-M7_trace_id.ref
reference : 0 : End of file : 27
WARN : comparison
---------------------------------------------------------
Warning : : 100 : Expected conditional elements in the trace
Warning : : 100 : Expected conditional result elements in the trace
** OK **
Note
The two warnings in Example B-1 are expected. They occur because of the ETM being
programmed to trace conditional instructions, but none are being generated in the trace
sequence.
Appendix C
AXI4 to AHB-Lite Bridge
This appendix describes the AXI4 to AHB-Lite Bridge (AAB) and how to connect it. It contains
• About the AAB on page C-2.
• AAB behavior on page C-4.
• Configuration options on page C-9.
• Interface assertions on page C-10.
• AAB interfaces on page C-11.
• Clocking and resets on page C-16.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. C-1
C.1 About the AAB

The AAB converts AXI4 protocol to AHB-Lite protocol and has an AXI4 slave interface and
an AHB-Lite master interface. For information about how AXI4 transactions to AHB-Lite are
bridged by the AAB, see Table C-1 on page C-4.
AXI4 slave interface

This connects to either the AXI4 master interface of the Cortex-M7
processor or to an AXI interconnect. See AXI4 Slave interface signals and
timing constraints on page C-12 for more information.
AHB-Lite master interface

This connects to either an AHB-Lite Peripheral or an AHB-Lite
interconnect. See AHB-Lite master interface signals and timing
constraints on page C-14 for more information.
Figure C-1 shows an example of the AAB connected to the Cortex-M7 processor, an AXI
interconnect or an AHB interconnect, a Flash, an SRAM, and a peripheral.
Processor Processor
AXI interconnect AAB
AAB AAB AAB AHB-Lite interconnect
Flash SRAM Peripheral Flash SRAM Peripheral
Figure C-1 Example AAB system diagrams
C.1.1 AAB features
The main AAB features are:
• Full support of the AXI4 protocol.
• Efficient conversion of the AXI4 transactions to AHB-Lite.
• Conversion of sparse write transactions to AHB-Lite.
• Read acceptance capability is two transactions.
• Write acceptance capability is two transactions.
• Combined acceptance capability is four transactions.
• 64-bit or 32-bit data width, configurable by a parameter.
• 16-bit ID widths.
• 16-bit USER sideband signals.
• Zero latency conversion to AHB-Lite.
• Two entry FIFOs for buffering read data and write response channels.
• Processor performance improved by prioritizing read transactions over write transactions,

when AXI read and write address channels are valid in the same cycle. Also read
transactions might interrupt sparse write transactions. Write transactions are guaranteed
to be accepted every 1 in 8 transactions when back to back read transactions occur.
• Support of exclusive accesses on the AHB-Lite interface using the EXREQ and
EXRESP signals.
Note
If your design has multiple masters that perform exclusives through a shared AAB, the global
exclusive monitor must resolve exclusives in the AXI domain before the AAB.
C.2 AAB behavior

This section describes the behavior of the AAB and how AXI4 transactions are converted to
AHB-Lite.
C.2.1 Burst conversions
Table C-1 shows the mapping of AXI4 burst types to AHB-Lite burst types.
Table C-1 AXI4 burst type to AHB-Lite burst type mapping
AxBURST Number of transfers in AXI4 transaction HBURST Notes
FIXED 1-16 SINGLE This is a series of singles, and the number

depends on the AxLEN value
INCR 1 SINGLE -
4 INCR4 -
8 INCR8 -
16 INCR16 -
2, 3, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 17-256 INCR Undefined length
WRAP 2 SINGLE Two transfers
4 WRAP4 -
8 WRAP8 -
16 WRAP16 -
C.2.2 1KB boundary crossing
The AHB-Lite protocol requires that bursts do not cross 1KB boundaries. AXI4 transactions can
cross a 1KB boundary, therefore the AAB detects this and converts these bursts as follows:
• Transactions that are normally converted to INCR4, INCR8 and INCR16 bursts are
converted to a series of SINGLE AHB-Lite bursts.
• Transactions that are normally converted to undefined length INCR bursts are unchanged
except that HTRANS is set to NONSEQ on the first address after a IKB boundary has
been crossed.
Note
To simplify the logic, the conversion to SINGLE bursts can occur for bursts that are close to a
1KB boundary but do not actually cross it. Transactions that the Cortex-M7 processor can
generate do not cause this pessimistic boundary crossing behavior.
C.2.3 Protection Control
Table C-2 shows how the AAB converts the protection control from AXI4 to AHB-Lite.
Table C-2 Protection control mapping
Description AXI4 AHB-Lite
Modifiable/Cacheable AxCACHE[1] HPROT[3]
Bufferable AxCACHE[0] HPROT[2]
Privileged AxPROT[0] HPROT[1]
Data/Instruction access AxPROT[2] HPROT[0]a
a. HPROT[0] is the inverted value of AxPROT[2].
C.2.4 Exclusive Accesses
The AAB AHB-Lite interface supports exclusive accesses using the EXREQ and EXRESP
signals. EXREQ is an address phase signal and EXRESP is a data phase signal. EXREQ is
asserted on every AHB-Lite transfer that is associated with an AXI4 transaction with AxLOCK
asserted. From more information about the EXREQ and EXRESP signals, see Table C-6 on
page C-15.
Table C-3 shows the mapping of the EXRESP signal to the AXI4 RRESP and BRESP signals.
Table C-3 Mapping exclusive response
EXRESP xRESP Description
HIGH OKAY Indicates exclusive access has failed
LOW EXOKAY Indicates exclusive access has been successful
For an exclusive read the EXRESP signal must be:
LOW If a system monitor is implemented that covers the access address.
HIGH If a system monitor is not implemented that covers the access address.
For an exclusive write the EXRESP signal must be:
LOW If a system monitor is implemented that covers the access address and the
exclusive check passes.
HIGH If a system monitor is implemented that covers the access address and the
exclusive check fails, or a system monitor is not implemented that covers the
access address.
If EXRESP is HIGH on any beat of an exclusive write transaction this value is held and can
generate the BRESP value.
If HRESP is HIGH, indicating a access error, this value overrides the EXRESP value, causing
SLVERR to be returned to the master on the appropriate AXI4 xRESP signal.
Note
• AXI4 exclusive write transactions must not have sparse write strobes. If this occurs the
transactions are converted to AHB-Lite as normal and a SLVERR is returned on the
B-Channel.
• The AWSPARSE signal, see Sparse write strobes, is ignored when AWLOCK is
asserted.
• AXI4 does not support locked transactions, therefore locked AHB-Lite transactions
cannot be generated. This means the HMASTLOCK signal is always driven LOW.
C.2.5 Sparse write strobes
The AAB has the AWSPARSE signal to support efficient conversion of write transactions
containing sparse write strobes. This signal is an extension to the Arm AMBA AXI and ACE
protocol. You must use a bit in the AWUSER signal to ensure that the AWSPARSE signal
passes through AXI interconnects.
A master must assert the AWSPARSE signal if a write transaction contains sparse write strobes
or if it is unaligned. This causes the HBURST mappings that Table C-1 on page C-4 shows to
be overridden to undefined length INCR. The AAB decodes the WSTRB signal to generate the
least number of AHB-Lite transfers possible that correspond to the strobe bits set. If the write
strobe bits set match the size of the AXI4 transaction, then only one AHB-Lite transfer is
generated for the AXI4 beat.
Normally, for a sparse write, each AHB-Lite transfer has an HTRANS value of NONSEQ.
When the current and the previous beat of an AXI4 transaction do not have sparse write strobes
and AWBURST is INCR, then HTRANS for the current beat is SEQ. This means that if a
transaction is marked as sparse pessimistically, and the WSTRB values are not sparse, the
transaction is converted to a sequential burst of the same length on the AHB-Lite interface with
little or no impact on performance.
Note
If the AWSPARSE signal is not asserted for a write transaction that has a beat with a sparse
WSTRB value, or the write transaction is unaligned, then the BRESP value returned to the
master is SLVERR. The transaction is converted to AHB-Lite protocol, as shown in Table C-1
on page C-4, but might corrupt the memory locations that are accessed.
Figure C-2 on page C-7 is an example of sparse write strobe timing.
T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
CLK
AWADDR[31:0] 0x100
AWBURST[1:0] 0b01
AWLEN[7:0] 0x03
AWPROT[2:0] 0b000
AWSPARSE
AWVALID
AWREADY
WSTRB[3:0] 0b1111 0b1011 0b0110
WDATA[31:0] 1 2 3 4
WLAST
WVALID
WREADY
BREADY
BVALID
BRESP[1:0] 0b00
HTRANS[1:0] 0b10 0b11 0b10 0b00
HBURST[2:0] 0b001 0b000
HADDR[31:0] 0x100 0x104 0x108 0x10B 0x10D 0x10E 0x000
HWRITE
HSIZE[2:0] 0b010 0b001 0b000
HWDATA[31:0] 1 2 3 4
HPROT[3:0] 0b0001 0b0000
HREADY
HRESP
Figure C-2 Sparse write strobe timing example
In Figure C-2, at time:
T3 The AAB samples the arrival of a new write transaction.
T4 WSTRB[2] goes LOW so the AAB splits the word transfer into:
• A halfword transfer (HSIZE = 0b001) to address 0x108.
• A byte transfer (HSIZE = 0b000) to address 0x10B, at time T5.
T6 WSTRB changes to 0b0110, so only data bits[23:8] are valid. Therefore, to

maintain the alignment requirements of AHB-Lite, the AAB performs:
• A byte transfer (HSIZE = 0b000) to address 0x10D.
• A byte transfer (HSIZE = 0b000) to address 0x10E, at time T7.
T8 The AAB returns a single write response, to complete the AXI transaction.
C.2.6 Address alignment
The AHB-Lite protocol does not support unaligned transfers. This means, for read transactions,
an unaligned ARADDR value is automatically aligned by the AAB to the ARSIZE value before
it is output on the AHB-Lite interface. The same address alignment is performed for unaligned
write transactions when the AWSPARSE signal not asserted. This system error might corrupt
the memory locations accessed and the AAB indicates the system error by returning a SLVERR
value on the BRESP signal. If the AWSPARSE signal is asserted for an unaligned write
transaction then the AHB-Lite addresses is correctly aligned by the AAB logic as described in
Sparse write strobes on page C-6.
C.2.7 User sideband signals
The AAB supports four AXI4 sideband signals and three AHB-Lite sideband signals, and each
is 16 bits wide. Table C-4 shows how these signals are mapped between the interfaces.
Table C-4 User sideband signals mapping
AXI4 AHB-Lite
Phase Comment
Signal Direction Signal Direction
ARUSER Input HAUSER Output Address Read transfers. The same value is output on each transfer
associated with and AXI4 transaction.
AWUSER Write transfers. The same value is output on each transfer

associated with an AXI4 transaction.
WUSER Input HWUSER Output Data Only valid on write transfers. The value might be different on
each transfer except for sparse writes where the same value is to
be output for transfers associated with the same AXI4 beat.
RUSER Output HRUSER Input Only valid on read transfers. The value might be different on each
transfer.
Note
There is no AXI4 BUSER output from the AAB because there is no single phase in the
AHB-Lite protocol that can be reliably mapped to the AXI4 B-channel.
C.3 Configuration options

There is only one configuration option on the AAB. This controls the width of the AXI4 and
AHB-Lite data signals, WDATA, RDATA, HWDATA and HRDATA, and the AXI4 write
strobe signal, WSTRB.
The width is controlled by decoding the value of the DW_64 parameter:

1 64-bit data width and 8-bit wide write strobe.
0 32-bit data width and 4-bit wide write strobe.
For information about the AXI4 and AHB-Lite interfaces and their signals, see Table C-5 on
page C-12 and Table C-6 on page C-15.
C.4 Interface assertions

The AAB includes internal and interface OVL assertions that can be enabled during simulation.
To enable these checkers, except the AXI4 interface checker, define the ARM_ASSERT_ON Verilog
macro. To also enable the AXI4 interface checker, define the ARM_CM7AAB_AXIOVL_ON Verilog
macro.
C.5 AAB interfaces

This section describes the AAB interface signals, timing constraints, and how to connect the
AAB in your system. It contains the following:
• Clocking and resets on page C-16.
• AXI4 Slave interface signals and timing constraints on page C-12.
• AHB-Lite master interface signals and timing constraints on page C-14.
C.5.1 AXI4 Slave interface signals and timing constraints
The AXI4 Slave interface does not use the following signals:
• AxQOS.
• AxREGION.
• CSYSREQ.
• CSYSACK.
• CACTIVE.
• AxSIZE[2].
• BUSER.
Table C-5 shows the AXI4 slave interface signals and timing constraints. The timing
information gives the propagation delay allocation for the external logic as a percentage of the
clock cycle. You must connect the slave interface signals to either the Cortex-M7 processor AXI
master interface or to an AXI interconnect unless Table C-5 shows specific connection
information for the signal.
Table C-5 AXI4 slave interface signals
Signal name Direction Timing Description Connection information
AWVALID Input 10% See the Arm® AMBA® AXI -

and ACE Protocol
AWADDR[31:0] Input 10% Specification AXI3, AXI4,
AWBURST[1:0] Input 10% and AXI4-Lite, ACE and
ACE-Lite
AWID[15:0] Input 10% Unused AWID bits must be tied LOW.
AWLEN[7:0] Input 10% -
AWSIZE[1:0] Input 10%
AWLOCK Input 10%
AWPROT[2:0] Input 10%
AWREADY Output 30%
AWCACHE[3:0] Input 10%
Table C-5 AXI4 slave interface signals (continued)
AWSPARSE Input 10% AXI4 extension signal, If the AAB is:

indicates that a • Directly connected to the Cortex-M7 processor
transaction might use then connect to the AWSPARSE signal.
sparse write strobes, see • Connected to an AXI interconnect then connect
Sparse write strobes on to an AWUSER bit. The Cortex-M7 processor
page C-6 AWSPARSE signal must also be connected to
the same AWUSER bit on the interconnect slave
interface.
Note
AXI interconnect upsizers or downsizers might
optimize bufferable write transactions. This can cause
aligned writes to be converted to unaligned sparse
writes. In this case, you can either:
• Set the bypass merge bit in the GPV if you are
using NIC-400 or NIC-301.
• Assert AWSPARSE when AWCACHE[1] and
AWBURST[0] signals are HIGH.
The transaction types that Cortex-M7 processor
generates do not have this issue.
AWUSER[15:0] Input 10% See the Arm® AMBA® AXI Unused AWUSER bits must be tied LOW.
and ACE Protocol
ARVALID Input 10% Specification AXI3, AXI4, -
ARADDR[31:0] Input 10% and AXI4-Lite, ACE and

ACE-Lite
ARBURST[1:0] Input 10%
ARID[15:0] Input 10% Unused ARID bits must be tied LOW.
ARLEN[7:0] Input 10% -
ARSIZE[1:0] Input 10%
ARLOCK Input 10%
ARPROT[2:0] Input 10%
ARREADY Output 30%
ARCACHE[3:0] Input 10%
ARUSER[15:0] Input 10% Unused ARUSER bits must be tied LOW.
WVALID Input 10% -
WLAST Input 10%
WSTRB[SW:0]a Input 10%
WDATA[DW-1:0] Input 10%

b
WREADY Output 30%
WUSER[15:0] Input 10% Unused WUSER bits must be tied LOW.
Table C-5 AXI4 slave interface signals (continued)
RVALID Output 30% See the Arm® AMBA® AXI -

and ACE Protocol
RID[15:0] Output 10% Specification AXI3, AXI4, Unused RID bits must be left unconnected.
RLAST Output 10% and AXI4-Lite, ACE and -

ACE-Lite
RDATA[DW-1:0]b Output 10%
RRESP[1:0] Output 10%
RREADY Input 60%
RUSER[15:0] Output 10% Unused RUSER bits must be left unconnected.
BVALID Output 30% -
BID[15:0] Output 10% Unused BID bits must be left unconnected.
BRESP[1:0] Output 10% -
BREADY Input 60%
a. The write strobe signal width is either 4 bits or 8 bits wide and is determined by the DW_64 parameter, see Configuration options on page C-9.
b. The data bus signal width is either 32 bits or 64 bits wide and is determined by the DW_64 parameter, see Configuration options on page C-9.
C.5.2 AHB-Lite master interface signals and timing constraints
Table C-6 on page C-15 shows the AHB-Lite master interface signals, timing constraints, and
connection. The timing information gives the propagation delay allocation for the external logic
as a percentage of the clock cycle. You must connect the master interface signals to either an
AHB-Lite interconnect or to an AHB-Lite slave, unless Table C-6 on page C-15 shows specific
connection information for the signal. If you are connecting the AAB directly to a slave
peripheral:
• The output signal HREADYOUT from the slave peripheral must be connected to the
HREADY input signal of the AAB.
• The input signal HSEL must be tied HIGH.
Table C-6 AHB-Lite master interface signals
HTRANS[1:0] Output 50% See the Arm® AMBA® 3 AHB-Lite Protocol -

(v1.0) Specification
HBURST[2:0] Output 50%
HADDR[31:0] Output 50%
HWRITE Output 50%
HSIZE[2:0] Output 50% HSIZE[2] is driven LOW by the

AAB and so can be unconnected.
HWDATA[DW-1:0]a Output 50% -
HPROT[3:0] Output 50%
HREADY Input 50% If the AAB:

• Connects to an AHB-Lite
interconnect, then connect
to its HREADY output.
• Connects directly to an
AHB-Lite slave peripheral,
then connect to its
HREADYOUT output.
HRDATA[DW-1:0]a Input 50% -
HMASTLOCK Output 50% The AAB drives HMASTLOCK

LOW because locked transfers are
not supported by AXI4.
HRESP Input 50% -
EXREQb Output 50% This is an address phase signal that indicates Connect to an exclusive monitor if
whether a transfer is part of an exclusive implemented. If an exclusive
transaction, and is never HIGH during IDLE monitor is not implemented then
transfers: this signal can be left unconnected.
LOW Non-exclusive transaction. EXREQ is not required to be
HIGH Exclusive transaction. qualified with HTRANS. See
Exclusive Accesses on page C-5.
EXRESPb Input 50% This is an data phase signal. It indicates Connect to an exclusive monitor if
whether the exclusive request was granted implemented. If an exclusive
or failed. It is only valid when EXREQ is monitor is not implemented then
HIGH in the address phase: this signal must be tied HIGH.
LOW Exclusive access granted.
HIGH Exclusive access failed.
HAUSERc Output 50% This is an address phase signal Unused bits must be left
unconnected.
HWUSERc Output 50% This is a data phase signal that is only valid
for write transfers
HRUSERc Input 50% This is a data phase signal that is only valid Unused bits must be tied LOW.
for read transfers when HREADY is HIGH
a. The data bus signal width is either 32 bits or 64 bits wide and is determined by the DW_64 parameter, see Configuration options on page C-9.
b. Exclusive access signals are extensions to the AHB-Lite protocol. See Exclusive Accesses on page C-5.
c. User sideband signals are extensions to the AHB-Lite protocol. See User sideband signals on page C-8.
C.6 Clocking and resets

The AAB has a single input clock signal and a single reset signal.
Table C-7 shows the internal clock signal.
Table C-7 Internal clock signal
Clock Direction Description
CLK Input Main clock for the AAB
Table C-8 shows the AAB reset signal.
Table C-8 AAB reset signal
Clock Direction Description
nSYSRESET Input Deassert the reset synchronously to CLK.

Assert the reset at powerup and when the
master it is connected to resets.
Assert the reset for at least two CLK cycles.
Appendix D
Cortex-M7 Debug Access Port
This appendix describes the Debug Access Port (DAP) for the Cortex-M7 processor. It contains
• About the Debug Access Port on page D-2.
• Functional description on page D-4.
• DAP register summary on page D-5.
• DAP register descriptions on page D-7.
• Debug Access Port signals on page D-22.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. D-1
D.1 About the Debug Access Port

The Cortex-M7 DAP (CM7DAP) is an optional component that provides an interface to allow
off-chip debug tools to access the Cortex-M7 processor. It is an implementation of the Arm®
Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2.
The key features of the CM7DAP are:
• Supports JTAG and Serial Wire Debug (SWD) Data Link protocols. Protocol is selected
by a signal at reset, see Functional description on page D-4.
• Supports SWD multidrop as an implementation option, see Configuration options on

page D-3.
• Includes an AHB-AP, intended to be directly connected to the Cortex-M7 processor

AHBD slave port.
• Implements the Minimal Debug Port programmers model, see the Arm® Debug Interface
Architecture Specification ADIv5.0 to ADIv5.2.
Note
The CM7DAP is a low gate-count DAP implementation. If you require a full DAP implementation,
Arm recommends using the DAP provided in the CoreSight SoC-400 product. See Arm®
CoreSight™ SoC-400 Technical Reference Manual.
Figure D-1 shows the CM7DAP interface.
SWCLKTCK
Clock DPRESETn
and SLVADDR[31:0]
DCLK SLVWDATA[31:0]
resets
APRESETn SLVTRANS[1:0]
SLVPROT[3:0]
nTRST SLVWRITE AHB-AP
TDI SLVSIZE[1:0]
JTAG-DP
TDO SLVRDATA[31:0]
nTDOEN SLVREADY
SLVRESP
SWDITMS CM7DAP
SWDO
Serial Wire-DP
SWDOEN CDBGPWRUPREQ
SWDETECT Power management
CDBGPWRUPACK
CFGJTAGnSW HALTED Halted

BASEADDR[31:0]
Configuration TARGETID[31:0] DEVICEEN AP Enable
INSTANCEID[3:0]
ECOREVNUM[7:0] DFTSE Design For Test Group
Figure D-1 CM7DAP interface
D.1.1 Configuration options
Table D-1 shows the configuration options for the CM7DAP that can be set at implementation time.
Table D-1 Configuration options for the CM7DAP
SWMD Serial wire multidrop support:

0 Multidrop not supported.
1 Multidrop logic present.
RAR Reset all registers:

0 Only required registers are reset.
>0 All registers are reset.
D.2 Functional description

Figure D-2 shows the main functional blocks in the CM7DAP.
CM7DAP
JTAG port To Cortex-M7

JTAG-DP
AHBD Port
SWCLKTCK
AHB-AP DCLK
CFGJTAGnSW
SW-DP DEVICEEN
Serial wire port
Figure D-2 CM7DAP block diagram
The Debug Port (DP)s and Access Port (AP) are compliant with ADIv5.2 architecture. An
overview of each is as follows:
JTAG-DP The JTAG-DP implements the JTAG Debug Interface and is compliant with DP
architecture version 1.
SW-DP The SW-DP implements the Serial Wire Debug Interface. The DP protocol and
architecture compliance depends on the SWMD parameter value, see Configuration
options on page D-3.
When the SWMD parameter:
• Is set to 0, it is compliant with DP architecture version 1 and Serial Wire
protocol version 1.
• Is set to 1, it is compliant with DP architecture version 2 and Serial Wire
protocol version 2 that enables the SW-DP to share a debugger connection
with other SW-DPs.
AHB-AP The AHB-AP is an AHB-Lite master interface that is intended to be directly

connected to the Cortex-M7 processor AHBD port. It is compliant with the
MEM-AP definition and performs 8-bit to 32-bit accesses.
The DP supports the JTAG and Serial Write debug data link protocols but the protocol used is
selected statically from reset using the CFGJTAGnSW configuration signal. Therefore, it is
not possible to dynamically switch between protocols. See Signal list on page D-23.
D.3 DAP register summary

This section shows the following DAP component register summaries:
• AHB-AP register summary.
• Debug port register summary.
D.3.1 AHB-AP register summary
Table D-2 shows the AHB-AP register summary.
Table D-2 AHB-AP register summary
Offset Type Reset value Name
0x00 RW 0x03000000 AHB-AP Control/Status Word register, CSW, 0x00 on page D-7
0x04 RW - AHB-AP Transfer Address Register, TAR, 0x04 on page D-9
0x08 - - Reserved, RAZ/SBZP
0x0C RW - AHB-AP Data Read/Write register, DRW, 0x0C on page D-9
0x10 RW - AHB-AP Banked Data registers, BD0-BD03, 0x10-0x1C on page D-10
0x14 RW -
0x18 RW -
0x1C RW -
0x20-0xF3 - - Reserved, RAZ/SBZP
0xF4 RO 0x00000000 AHB-AP Configuration register, CFG, 0xF4 on page D-10
0xF8 RO IMPLEMENTATION DEFINED AHB-AP Debug Base Address register, ROM, 0xF8 on page D-10
0xFC RO 0x04770041 AHB-AP Identification Register, IDR, 0xFC on page D-11
D.3.2 Debug port register summary
Table D-3 shows the CM7DAP DP register summary, and summarizes which registers are
implemented in the JTAG-DP and which are implemented in the SW-DP.
Table D-3 Debug port register summary
JTAG-D
Name SW-DP Description
P
ABORT Yes Yes AP Abort register. See AP Abort register, ABORT on page D-11.
IDCODE Yes No ID Code register. See Identification Code register, IDCODE on page D-12.
DPIDR Yes Yes Debug Port Identification register. See Debug Port Identification Register, DPIDR on
page D-13.
CTRL/STAT Yes Yes Control/Status register. See Control/Status register, CTRL/STAT on page D-14.
SELECT Yes Yes AP Select register. See AP Select register, SELECT on page D-16.
RDBUFF Yes Yes Read Buffer register. See Read Buffer register, RDBUFF on page D-17.
EVENTSTAT No Yes Event Status register. See Event Status register, EVENTSTAT on page D-18.
Table D-3 Debug port register summary (continued)
JTAG-D
Name SW-DP Description
P
DLCR No Yes Data Link Control Register. See Data Link Control Register, DLCR (SW-DP only) on
page D-19.
TARGETID No Yes Target Identification register. See Target Identification register, TARGETID (SW-DP only)
on page D-19.
DLPIDR No Yes Data Link Protocol Identification Register. See Data Link Protocol Identification Register,
DLPIDR (SW-DP only) on page D-20.
RESEND No Yes Read Resend register. See Read Resend register, RESEND (SW-DP only) on page D-21.
IR Yes No Instruction Register. See Arm® Debug Interface Architecture Specification ADIv5.0 to
ADIv5.2 for more information.
BYPASS Yes No Bypass register. See Arm® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2
DPACC Yes No DP Access register. See Arm® Debug Interface Architecture Specification ADIv5.0 to
ADIv5.2 for more information.
APACC Yes No AP Access register. Arm® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2
JTAG-DP register summary
Table D-4 shows all implemented registers accessible through the JTAG interface. All other
Instruction Register (IR) instructions are implemented as BYPASS. An external TAP controller
must be implemented in accordance with the Arm® Debug Interface Architecture Specification,
ADIv5.0 to ADIv5.2, if more IR registers are required, for example, JTAG TAP boundary scan.
See DP register descriptions on page D-21.
Table D-4 JTAG-DP register summary
IR instruction value JTAG-DP register DR scan width Description
0b1000 ABORT 35 JTAG-DP Abort register, ABORT
0b1010 DPACC 35 JTAG DP/AP Access registers, DPACC/APACC
0b1011 APACC 35
0b1110 IDCODE 32 JTAG Device ID Code register, IDCODE
0b1111 BYPASS 1 JTAG Bypass register, BYPASS
D.4 DAP register descriptions

This section describes the following DAP component registers and their bit assignments:
• AHB-AP register descriptions.
• Debug port registers on page D-11.
D.4.1 AHB-AP register descriptions
This section describes the programmable AHB-AP registers. It contains the following registers:
• AHB-AP Control/Status Word register, CSW, 0x00.
• AHB-AP Transfer Address Register, TAR, 0x04 on page D-9.
• AHB-AP Data Read/Write register, DRW, 0x0C on page D-9.
• AHB-AP Banked Data registers, BD0-BD03, 0x10-0x1C on page D-10.
• AHB-AP Debug Base Address register, ROM, 0xF8 on page D-10.
• AHB-AP Configuration register, CFG, 0xF4 on page D-10
• AHB-AP Identification Register, IDR, 0xFC on page D-11.
AHB-AP Control/Status Word register, CSW, 0x00
Purpose Configures and controls transfers through the AHB interface.
Attributes See DAP register summary on page D-5.
Figure D-3 shows the AHB-AP CSW register bit assignments.
31 30 29 28 27 24 23 22 12 11 8 7 6 5 4 3 2 0
Prot Reserved Mode Size
Reserved TrInProg
DbgStatus
DbgSwEnable SPIDEN AddrInc
Reserved
Figure D-3 AHB-AP CSW register bit assignments
Table D-5 shows the AHB-AP CSW register bit assignments.
Table D-5 AHB-AP Control/Status Word register bit assignments
Bits Type Name Function
[31] RO DbgSwEnable Not implemented in CM7DAP. Treat as RAZ/SBZP.
[30:28] - - Reserved, Treat as RAZ/SBZP.
[27:24] RW Prot Specifies the protection signal encoding to be output on SLVPROT[3:0]. This is the protection
attribute for AHB transfers.
The reset value is 0b0011.
Table D-6 on page D-9 describes the Prot field bits.
Note
All Prot field bits are RW except bit[24], that is RO.
[23] RO SPIDEN Not implemented in CM7DAP. Treat as RAZ/SBZP.
[22:12] - - Reserved. Treat as RAZ/SBZP.
Table D-5 AHB-AP Control/Status Word register bit assignments (continued)
[11:8] RO Mode Not implemented in CM7DAP. Treat as RAZ/SBZP.
[7] RO TrInProg Not implemented in CM7DAP. Treat as RAZ/SBZP.
[6] RO DbgStatus Indicates the status of the DEVICEEN port. If DbgStatus is LOW, no AHB transfers are carried
out.
0 AHB transfers not permitted.
1 AHB transfers permitted.
[5:4] RW AddrInc Auto address increment and packing mode on RW data access. Only increments if the current
transaction completes without an error response and the transaction is not aborted.
Auto address incrementing and packed transfers are not performed on access to Banked Data
registers, 0x10-0x1C. The status of these bits is ignored in these cases.
Incrementing and wrapping is performed within a 1KB address boundary, for example, for word
incrementing from 0x1400-0x17FC. If the start is at 0x14A0, then the counter increments to 0x17FC,
wraps to 0x1400, then continues incrementing to 0x149C.
0b00 Auto increment OFF.
0b01 Increment, single.
Single transfer from corresponding byte lane.
0b10 Reserved, SBZ. No transfer.
0b11 Reserved, SBZ. No transfer.
Size of address increment is defined by the Size field, bits[2:0].
Note
Bit[5] is RO and RAZ.
[3] RW - Reserved, SBZ.

The reset value is 0.
[2:0] RW Size Size of the data access to perform:

0b000 8 bits.
0b001 16 bits.
0b010 32 bits.
0b011-0b111 Reserved, SBZ.
Note
Bit[2] is RO and RAZ.
Prot field bit descriptions
Table D-6 describes Prot field bits.
Table D-6 Prot field bit descriptions
Bit Description
27 Cacheable:
0 Non-cacheable.
1 Cacheable.
26 Bufferable:
0 Non-bufferable.
1 Bufferable.
25 Privileged:
0 Non-privileged.
1 Privileged.
24 Data/Instruction access:
1 Data access. This bit is RO.
AHB-AP Transfer Address Register, TAR, 0x04
Purpose: Holds the memory address to be accessed.
Table D-7 shows the AHB-AP Transfer Address Register bit assignments.
Table D-7 AHB-AP Transfer Address Register bit assignments
[31:0] RW Address Address of the current transfer

Note
This register is not reset
AHB-AP Data Read/Write register, DRW, 0x0C
Purpose Maps an AP access directly to one or more memory accesses. The AP access does
not complete until the memory access, or accesses, complete.
Table D-8 shows the AHB-AP Data Read/Write register bit assignments.
Table D-8 AHB-AP Data Read/Write register bit assignments
[31:0] RW Data Write mode Data value to write for the current transfer.
Read mode Data value that is read from the current transfer.
AHB-AP Banked Data registers, BD0-BD03, 0x10-0x1C
Purpose BD0-BD3 provide a mechanism for directly mapping through DAP accesses to
AHB transfers without having to rewrite the TAR within a four-location
boundary. BD0 is RW from TA. BD1 is RW from TA+4.
Table D-9 shows the Banked Data register bit assignments.
Table D-9 Banked Data register bit assignments
[31:0] RW Data If dapcaddr[7:4] = 0x0001, it is accessing AHB-AP registers in the range 0x10-0x1C, and the
derived haddr[31:0] is:
Write mode Data value to write for the current transfer to external address TAR[31:4] +
dapcaddr[3:2] + 0b00.
Read mode Data value that is read from the current transfer from external address TAR[31:4]
+ dapcaddr[3:2] + 0b00.
Auto address incrementing is not performed on DAP accesses to BD0-BD3.
Banked transfers are only supported for word transfers. Non-word banked transfers are reserved
and UNPREDICTABLE. Transfer size is currently ignored for banked transfers.
AHB-AP Debug Base Address register, ROM, 0xF8
Purpose Provides an index into the connected memory-mapped resource. This index value
points to a ROM table that describes the connected debug components.
Table D-10 shows the AHB-AP Debug Base Address register bit assignments.
Table D-10 AHB-AP Debug Base Address register bit assignments
[31:0] RO Debug AHB ROM Address Base address of a ROM table. Bit[1] is always 1, bits[31:12] are set to the tie-off
value on the static input port BASEADDR[31:12]. Bits[11:2] are set to 0x000 and
bit[0] is set to BASEADDR[0].
The ROM provides a lookup table that points to debug components.
AHB-AP Configuration register, CFG, 0xF4
Purpose Describes the features that are configured in the AHB-AP implementation.
Table D-11 shows the AHB-AP Configuration register bit assignments.
Table D-11 AHB-AP Configuration register bit assignments
Bits Type Name Value Function
[31:3] - Reserved 0x00000000 -
Table D-11 AHB-AP Configuration register bit assignments (continued)
[2] RO LD 0x0 Large data. Data not larger than 32-bits supported.
[1] RO LA 0x0 Long address. Physical addresses of 32-bits, or less supported.
[0] RO BE 0x0 Big-endian. Little-endian supported.
AHB-AP Identification Register, IDR, 0xFC
Purpose Specifies the AHB-AP identification values.
Figure D-4 shows the AHB-AP Identification Register bit assignments.
31 28 27 24 23 17 16 13 12 8 7 4 3 0
JEDEC
Revision JEDEC code Class Reserved Variant Type
bank
Figure D-4 AHB-AP Identification Register bit assignments
Table D-12 shows the AHB-AP Identification Register bit assignments.
Table D-12 AHB-AP Identification Register bit assignments
[31:28] RO Revision 0x0 r0p0
[27:24] RO JEDEC bank 0x4 Designed by Arm
[23:17] RO JEDEC code 0x3B Designed by Arm
[16:13] RO Class 0x8 Is a Mem AP
[12:8] - Reserved 0x00 -
[7:4] RO Variant 0x4 Cortex-M7 AP
[3:0] RO Type 0x1 AHB-AP
D.4.2 Debug port registers
This section describes the DP registers.
AP Abort register, ABORT
Purpose Forces an AP transaction abort.
Attributes The ABORT register is:
• A write-only register.
• Accessed in a DATA LINK DEFINED manner:

— JTAG-DP access is through its own scan-chain. See Figure D-5 on page D-12.
— SW-DP is accessed by a write to offset 0x0 of the DP register map.
• Always accessible, completes all accesses on the first attempt, and returns an OK response
if a valid transaction is received.
Figure D-5 shows the JTAG-DP ABORT bit assignments.
31 0
Reserved, SBZ
DAPABORT
Figure D-5 JTAG-DP ABORT bit assignments
Figure D-6 shows the SW-DP ABORT bit assignments.
31 5 4 3 2 1 0
Reserved, SBZ
ORUNERRCLR
WDERRCLR
STKERRCLR
STKCMPCLR
DAPABORT
Figure D-6 SW-DP ABORT bit assignments
Table D-13 shows the SW-DP ABORT bit assignments.
Table D-13 SW-DP ABORT bit assignments
Bits Function Description
[31:5] - Reserved, SBZ.
[4] ORUNERRCLRa Setting this bit to 1 sets the STICKYORUN overrun error flagb to 0.
[3] WDERRCLRa Setting this bit to 1 sets the WDATAERR write data error flagb to 0.
[2] STKERRCLRa Setting this bit to 1 sets the STICKYERR sticky error flagb to 0.
[1] STKCMPCLRa Reserved, SBZ. The DP is a MINDP implementation, therefore this bit is not implemented.
[0] DAPABORT Setting this bit to 1 generates a DAP abort, that aborts the current AP transaction.
Note
Perform this only if the debugger has received WAIT responses over an extended period.
a. Implemented on SW-DP only. On a JTAG-DP this bit is Reserved, SBZ.

b. In the Control/Status Register, see Control/Status register, CTRL/STAT on page D-14.
Identification Code register, IDCODE
Purpose Provides identification information about the JTAG-DP. The IDCODE register is
always accessible.
Attributes The IDCODE register is:
• A read-only register.
• Accessed through its own scan chain when the IR contains 0b1110.
Figure D-7 on page D-13 shows the Identification Code register bit assignments.
31 28 27 12 11 1 0
PARTNO
JTAG-DP Version 0 1 0 0 0 1 1 1 0 1 1 1
Part number
MANUFACTURER
(ARM)
Figure D-7 Identification Code register bit assignments
Table D-14 shows the Identification Code register bit assignments.
Table D-14 Identification Code register bit assignments
[31:28] Version CM7DAP JTAG-DP revision code exclusive OR-gated with ECOREVNUM[7:4] signal:
0x0 r0p0.
[27:12] PARTNO Part Number for the CM7DAP JTAG-DP, 0xBA02.
[11:1] MANUFACTURER JEDEC Manufacturer ID, an 11-bit JEDEC code that identifies the designer of the device. See
JEDEC Manufacturer ID. Figure D-7 shows the Arm value for this field as 0x23B. This value must
not be changed.
[0] - Always 1.
JEDEC Manufacturer ID
This code is also described as the JEP-106 manufacturer identification code, and can be
subdivided into two fields, as Table D-15 shows. JEDEC codes are assigned by the JEDEC
Solid State Technology Association, see JEP106M, Standard Manufactures Identification
Code.
Table D-15 JEDEC JEP-106 manufacturer ID code, with Arm values
JEP-106 field Bitsa Arm registered value
Continuation code 4 bits, [11:8] 0b0100, 0x4
Identity code 7 bits, [7:1] 0b0111011, 0x3B
a. Field width, in bits, and the corresponding bits in the

Identification Code Register.
Debug Port Identification Register, DPIDR
Purpose Provides identification information about the JTAG-DP and SW-DP.
Attributes The DPIDR register is:
• Accessed by a read at offset 0x0 of the DP register map.
Figure D-8 on page D-14 shows the Debug Port Identification register bit assignments.
31 28 27 20 19 17 16 15 12 11 10 9 8 7 6 5 4 3 2 1 0
REVISION PARTNO RES0 VERSION 0 1 0 0 0 1 1 1 0 1 1 1
Reserved
MIN DESIGNER
(Value shown is the ARM value)
Figure D-8 Debug Port Identification register bit assignments
Table D-16 shows Debug Port Identification register the bit assignments.
Table D-16 Debug Port Identification register bit assignments
[31:28] REVISION CM7DAP DP revision code exclusive OR-gated with the ECOREVNUM[7:4] signal:
JTAG-DP 0x0, r0p0.
SW-DP 0x0, r0p0.
[27:20] PARTNO Part Number for this debug port, 0xBD.
[19:17] - Reserved, RAZ.
[16] MIN Reads as 1, indicating that the Minimal Debug Port (MINDP) architecture is implemented.
Transaction counter, Pushed-verify, and Pushed-find operations are not implemented.
[15:12] VERSION DP architecture version:
0x1 DPv1 - JTAG-DP and SW-DP when SWMD parameter set to 0.
0x2 DPv2 - SW-DP when SWMD parameter set to 1.
[11:1] MANUFACTURER JEDEC Manufacturer ID, an 11-bit JEDEC code that identifies the designer of the device. See
JEDEC Manufacturer ID on page D-13. Figure D-7 on page D-13 shows the Arm value for this field
as 0x23B. This value must not be changed.
[0] - Always 1.
Control/Status register, CTRL/STAT
Purpose Provides control of the DP and its status information.
Attributes The CTRL/STAT register is:

• A read/write register. Some fields are RO, meaning they ignore writes, see
the field descriptions for more information.
• JTAG-DP. At address 0x4 when the IR contains DPACC, when
SELECT.DPBANKSEL is 0x0.
• SW-DP. At address 0b01 when APnDP bit is 0 and the CTRL/STAT bit in
the Select register is set to 0.
Figure D-9 on page D-15 shows the Control/Status register bit assignments.
31 30 29 28 27 26 25 24 23 12 11 8 7 6 5 4 3 2 1 0
JTAG-DP 0 0
0 0 TRNCNT MASKLANE
SW-DP
CSYSPWRUPACK SW-DP only, WDATAERR

CSYSPWRUPREQ RAZ/SBZP for JTAG-DP READOK
CDBGPWRUPACK STICKYERR
CDBGPWRUPREQ STICKYCMP
CDBGRSTACK
TRNMODE
CDBGRSTREQ
STICKYORUN
RAZ/SBZP
ORUNDETECT
Figure D-9 Control/Status register bit assignments
Table D-17 shows the Control/Status register bit assignments.
Table D-17 Control/Status register bit assignments
Bits Access Function Description
[31] RO CSYSPWRUPACK System powerup acknowledge.
[30] RW CSYSPWRUPREQ System powerup request.

[29] RO CDBGPWRUPACK Debug powerup acknowledge.
[28] RW CDBGPWRUPREQ Debug powerup request.

[27] RO CDBGRSTACK Debug reset acknowledge.
[26] RW CDBGRSTREQ Debug reset request.

[25:24] - - Reserved, RAZ/SBZP.
[23:12] RAZ/ TRNCNT The CM7DAP is a MINDP implementation, therefore this field is reserved.
SBZP
[11:8] RAZ/ MASKLANE The CM7DAP is a MINDP implementation, therefore this field is reserved.
SBZP
[7] ROa WDATAERRb This bit is set to 1 if a Write Data Error occurs. It is set if:
• There is a parity or framing error on the data phase of a write.
• A write that the debug port accepted is then discarded without being submitted
to the access port.
This bit can only be set to 0 by writing 1 to ABORT.WDERRCLR. XYQ.
The reset value after a Powerup reset is 0.
[6] ROa READOKb This bit is set to 1 if the response to a previous access port or RDBUFF was OK. It is
set to 0 if the response was not OK.
This flag always indicates the response to the last access port read access.
The reset value after a Powerup reset is 0.
Table D-17 Control/Status register bit assignments (continued)
Bits Access Function Description
[5] ROa STICKYERR This bit is set to 1 if an error is returned by an access port transaction. To set this bit to
0:
JTAG-DP Write 1 to this bit of this register.
SW-DP Write 1 to ABORT.STKERRCLR.
After a Powerup reset this bit is LOW.
[4] RAZ STICKYCMP The CM7DAP is a MINDP implementation, therefore this field is reserved.
[3:2] RAZ/ TRNMODE The CM7DAP is a MINDP implementation, therefore this field is reserved.
SBZP
[1] ROa STICKYORUN If overrun detection is enabled, this bit is set to 1 when an overrun occurs. To set this
bit to 0:
JTAG-DP Write 1 to this bit of this register.
SW-DP Write 1 to ABORT.ORUNERRCLR.
After a Powerup reset the reset value is 0. See bit[0] of this register.
[0] RW ORUNDETECT This bit is set to 1 to enable overrun detection.

a. RO on SW-DP. On a JTAG-DP, this bit can be read normally. Writing a 1 to this bit sets the bit to 0.
b. Implemented on SW-DP only. On a JTAG-DP this bit is Reserved, RAZ.
AP Select register, SELECT
Purpose The SELECT register:

• Selects an Access Port (AP) and the active register banks within that
AP.
• Selects the DP address bank.
Attributes The SELECT register is:

• A read/write register.
• JTAG-DP. At address 0x8 when the IR contains DPACC, and is a
RW register.
• SW-DP. At address 0b10 on write operations when the APnDP bit is
0.
Figure D-10 shows the AP Select register bit assignments.
31 24 23 8 7 4 3 0
JTAG-DP Reserved
APSEL
SW-DP RAZ/SBZ
APBANKSEL
DPBANKSEL
Figure D-10 AP Select register bit assignments
Table D-18 shows the AP Select register bit assignments.
Table D-18 AP Select register bit assignments
[31:24] APSEL Selects the current access port:

0x00 Selects the AHB-AP.
0x01-0x1F AP 0x01-0x1F do not exist, and if selected, AP read transactions return zero and
AP writes are ignored.
The reset value is UNPREDICTABLE.a
[23:8] Reserved. SBZ/RAZa Reserved. SBZ/RAZa.
[7:4] APBANKSEL Selects the active 4-word register window on the current access port.
The reset value is UNPREDICTABLE.a
[3:0] DPBANKSEL Selects the register that appears at DP register 0x4.

JTAG-DP:
0x0 CTRL/STAT, RW.
All other values are reserved. Writing a reserved value to this field is UNPREDICTABLE.
SW-DP, SWMD parameter 0:

0x0 CTRL/STAT, RW.
0x1 DLCR, RW.
SW-DP, SWMD parameter 1:

0x0 CTRL/STAT, RW.
0x1 DLCR, RW.
0x2 TARGETID, RO.
0x3 DLPIDR, RO.
0x4 EVENTSTAT, RO.
a. On a SW-DP the register is write-only, therefore you cannot read the field value.
Read Buffer register, RDBUFF
Purpose Captures data from the AP, presented as the result of a previous read.
Attributes The RDBUFF register is:

• A 32-bit read-only buffer.
• JTAG-DP. Accessed at address 0xC when the IR contains DPACC.
• SW-DP. Accessed at address 0b11 on read operations when the APnDP bit
is 0.
• Has DATA LINK DEFINED behavior:
— JTAG-DP, see Read Buffer implementation and use on a JTAG-DP.
— SW-DP, see Read Buffer implementation and use on a SW-DP on
page D-18.
Read Buffer implementation and use on a JTAG-DP
On a JTAG-DP, the read buffer is RAZ/WI.
The read buffer is architecturally defined to provide a debug port read operation that does not
have any side effects. This means that a debugger can insert a debug port read of the read buffer
at the end of a sequence of operations, to return the final read result and ACK values.
Read Buffer implementation and use on a SW-DP
On a SW-DP, performing a read of the read buffer captures data from the access port, presented
as the result of a previous read, without initiating a new access port transaction. This means that
reading the read buffer returns the result of the last access port read access, without generating
a new AP access.
After you read the read buffer, its contents are no longer valid. The result of a second read of the
read buffer is UNPREDICTABLE.
If you require the value from an access port register read, that read must be followed by one of:
• A second access port register read. You can read the CSW if you want to ensure that this
second read has no side effects.
• A read of the DP Read Buffer.
This second access, to the access port or the debug port depending on which option you use,
stalls until the result of the original access port read is available.
Event Status register, EVENTSTAT
Purpose Signals to the debugger that the Cortex-M7 processor is halted.
Attributes The EVENTSTAT register is:

• Accessed by a read at offset 0x4 of the DP register map when
SELECT.DPBANKSEL is set to 0x4.
Figure D-11 shows the Event Status register bit assignments.
31 1 0
Reserved
EA
Figure D-11 Event Status register bit assignments
Table D-19 shows the Event Status register bit assignments.
Table D-19 Event Status register bit assignments
[31:1] - Reserved, RAZ.
[0] EA Event status flag. Indicates that the Cortex-M7 processor

is halted:
0 Processor is halted.
1 Processor is not halted.
Data Link Control Register, DLCR (SW-DP only)
Purpose Controls the operating mode of the Data Link.
Attributes The DLCR register is:

• A read/write register.
• Accessed by a read or write at offset 0x4 of the DP address map when
Figure D-12 shows the Data Link Control Register bit assignments.
31 10 9 8 7 6 5 3 2 0
SW-DP SBZ/
SBZ/RAZ
only RAZ
TURNROUND
WIREMODE
Implementation-defined, see text
PRESCALER
Figure D-12 Data Link Control Register bit assignments
Table D-20 shows the Data Link Control Register bit assignments.
Table D-20 Data Link Control Register bit assignments
[31:10] - Reserved, SBZ/RAZ.
[9:8] TURNROUND Turnaround tristate period. Only 0b00 is supported by this field, other write values are treated as a
protocol error.
[7:6] WIREMODE This field is fixed to 0b01.

[5:3] - Reserved, SBZ/RAZ.
[2:0] PRESCALER Reserved, SBZ/RAZ.
Target Identification register, TARGETID (SW-DP only)
Purpose Provides information about the target when the host is connected to a single
device.
Attributes The TARGETID register is:

Figure D-13 on page D-20 shows the Target Identification register bit assignments.
31 28 27 12 11 1 0
TPARTNO TDESIGNER
TREVISION Reserved, RAO
Figure D-13 Target Identification register bit assignments
Table D-21 shows the Target Identification register bit assignments.
Table D-21 Target Identification register bit assignments
[31:28] TREVISION Target revision.
[27:12] TPARTNO Configuration dependent.

This value is assigned by the designer of the part and must be unique to that part.
[11:1] TDESIGNER IMPLEMENTATION DEFINED. This field identifies the designer of the part. The value is based
on the code assigned to the designer by JEDEC standard JEP-106, as used in IEEE 1149.1.
[0] - Reserved, RAO.
Data Link Protocol Identification Register, DLPIDR (SW-DP only)
Purpose Provides protocol version information.
Attributes The DLPIDR is:

Figure D-14 shows the Data Link Protocol Identification Register bit assignments.
31 28 27 4 3 0
Target Protocol
Reserved
Instance Version
Figure D-14 Data Link Protocol Identification Register bit assignments
Table D-22 shows the Data Link Protocol Identification Register bit assignments.
Table D-22 Data Link Protocol Identification Register bit assignments
[31:28] Target Instance Configuration dependent.

This field defines a unique instance number for this device within the system. This value must be
unique for all devices that are connected together in a multidrop system with identical values in the
TREVISION fields in the TARGETID register. The value of this field reflects the value of the
instanceid[3:0] input.
[27:4] - Reserved.
[3:0] Protocol Version Defines the serial wire protocol version. This value is 0x1, that indicates SW protocol version 2.
Read Resend register, RESEND (SW-DP only)
Purpose Enables the read data to be recovered from a corrupted debugger transfer without
repeating the original AP transfer.
Attributes The RESEND register is:

• Accessed by a read at offset 0x8 in the DP register map.
Performing a read to the RESEND register does not capture new data from the AP, it returns the
value that was returned by the last AP read or DP RDBUFF read.
Reading the RESEND register enables the read data to be recovered from a corrupted SW-DP
transfer without having to re-issue the original read request, or generate a new access to the
connected debug memory system.
The RESEND register can be accessed multiple times, it always returns the same value until a
new access is made to an AP register or the DP RDBUFF register.
DP register descriptions
For more information about the DP registers, their features, and how to access them. See Arm®
Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2 (Arm IHI 0031).
D.5 Debug Access Port signals

The section describes the DAP signals. It contains the following subsection:
• Signal list on page D-23.
D.5.1 Signal list
Table D-23 shows the CM7DAP signals.
Table D-23 CM7DAP signals
Name Type Clock domain Description
SWCLKTCK Input - SW and JTAG DP clock.
DPRESETn Input SWCLKTCK DP synchronous reset active LOW.
DCLK Input - AP clock.
APRESETn Input DCLK AP synchronous reset active LOW.
nTRST Input SWCLKTCK JTAG test logic reset signal.
TDI Input SWCLKTCK JTAG data in.
TDO Output SWCLKTCK JTAG data out.
nTDOEN Output SWCLKTCK JTAG TDO output enable.
SWDITMS Input SWCLKTCK SW data input and JTAG TMS.
SWDO Output SWCLKTCK SWdata output.
SWDOEN Output SWCLKTCK SW data output enable.
SWDETECT Output SWCLKTCK SW line reset detect.
HALTED Input DCLK Processor halted.
CDBGPWRUPREQ Output None Debug powerup request.
CDBGPWRUPACK Input None Debug powerup acknowledge.
DEVICEEN Input DCLK Debug enabled by system.
SLVADDR[31:0] Output DCLK AHB address.
SLVWDATA[31:0] Output DCLK AHB write data.
SLVTRANS[1:0] Output DCLK AHB transfer valid.
SLVPROT[3:0] Output DCLK AHB transaction protection.
SLVWRITE Output DCLK AHB write/not read.
SLVSIZE[1:0] Output DCLK AHB access size.
SLVRDATA[31:0] Input DCLK AHB read data.
SLVREADY Input DCLK AHB ready.
SLVRESP Input DCLK AHB response.
CFGJTAGnSW Input SWCLKTCK Configuration signal to select the DP protocol. This is

a static signal that can only be changed when
DPRESETn is LOW:
HIGH if JTAG selected.
LOW if SWD selected.
BASEADDR[31:0] Input DCLK AP ROM table base.
TARGETID[31:0] Input None Target ID for SW multidrop selectiona.
Table D-23 CM7DAP signals (continued)
Name Type Clock domain Description
INSTANCEID[3:0] Input None DLPIDR[31:28] for SW multidrop.a
ECOREVNUM[7:0] Input None [7:4] DP Revision.a

[3:0] AP Revision.a
DFTSE Input SWCLKTCK and DCLK Scan enable. Used by technology-specific clock
domain crossing modules.
a. This is a static signal that must not be changed after reset.
Note
All unused inputs must be tied LOW.
Miscellaneous DAP signals
Table D-24 lists the DAP signals.
Table D-24 Miscellaneous DAP signals
Name Direction Description Connection information
HALTED Input Processor Halted. Connect to Cortex-M7 processor HALTED output.
DEVICEEN Input Enable debugger Tie this signal HIGH not to use debug authentication to authenticate
access to system debugger access to devices on the SLV bus.
through SLV interface. Tie this signal LOW to permanently disable debugger access.
Connect this signal to your own logic, such as that connected to the
Cortex-M7 processor DBGEN, to dynamically enable and disable
debugger access.
INSTANCEID[3:0] Input Configuration for If you implement a Serial Wire CM7DAP with multi-drop, this signal
Serial Wire Multi-drop configures the Target Instance field in the Data Link Protocol
target selection. Identification Register. You must tie this to a value chosen to ensure
that all Serial Wire multi-drop devices connected to the same
interface are uniquely identifiable. See the description of the Target
Selection Register in the Arm Debug Interface v5 Architecture
Specification Supplement.
If you do not implement a Serial Wire CM7DAP with multi-drop, tie
this input to 0b0000.
SWDETECT Output Serial Wire protocol HIGH for one cycle of SWCLKTCK when a Serial Wire CM7DAP
detected. is implemented, and a Serial Wire line reset sequence is attempted
while the CM7DAP is not in dormant state.
Optionally, connect to your own logic. For example, to disable a
JTAG test device when a Serial Wire CM7DAP is implemented
without multi-drop. See Figure D-15 on page D-25.
Figure D-15 on page D-25 shows an example of how you might use the SWDETECT signal to
disable a JTAG TAP controller when a Serial Wire line reset sequence is observed.
JTAG TAP
Debugger Controller
nTRST nTRST
TDI TDI
TDO TDO
nTDOEN
SWCLK/TCK TCK
SWDIO/TMS TMS
D Q
DPRESETn Cortex-M7 DAP
SWDETECT
SWCLKTCK
SWDITMS
SWDO
SWDOEN
Figure D-15 Example SWDETECT logic
Appendix E
Signal Timing Constraints
This appendix describes the timing constraints on the processor signals. It contains the
following sections:
• Clock enable and reset signal constraints on page E-4.
• About signal timing constraints on page E-3.
• Configuration and initialization signal timing constraints on page E-5.
• ITCM interface timing constraints on page E-6.
• D0TCM and D1TCM interface timing constraints on page E-7.
• AXI master interface timing constraints on page E-8.
• AHB peripheral interface timing constraints on page E-10.
• AHB slave interface timing constraints on page E-11.
• AHB debug interface timing constraints on page E-12.
• External private peripheral bus timing constraints on page E-13.
• Sleep control interface timing constraints on page E-14.
• WIC interface timing constraints on page E-15.
• ITM interface timing constraints on page E-16.
• ETM instruction trace interface timing constraints on page E-17
• ETM data trace interface timing constraints on page E-18.
• Trace synchronization interface timing constraints on page E-19.
• Interrupts and events signal timing constraints on page E-20.
• Debug signals timing constraints on page E-21.
• Cross trigger interface timing constraints on page E-22.
• Miscellaneous signals timing constraints on page E-23.
• FPU signal timing constraints on page E-24.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. E-1
• MBIST interface timing constraints on page E-25.

• Dual-redundant core comparison interface timing constraints on page E-26.
• DFT interface timing constraints on page E-27.
E.1 About signal timing constraints

The timing constraints for signals are classified according to the percentage of the clock period
that is available for external logic:
• For inputs, this is the delay between the last register and the input port.
• For outputs, this is the delay between the output port and the first register.
E.2 Clock enable and reset signal constraints

Table E-1 shows the clock enable and reset signal timing constraints.
Table E-1 Clock enable and reset signal constraints
Signal Timing constraint Direction
CLKEN 20% Input
FCLKEN
HCLKEN
CLK1EN
FCLK1EN
HCLK1EN
STCLKEN
ETMCLKEN
nSYSRESET
SYSRESETREQ 60% Output
nPORESET 20% Input
nDBGETMRESET
CPUWAIT 50%
E.3 Configuration and initialization signal timing constraints

Table E-2 shows the configuration and initialization signal timing constraints.
Table E-2 Configuration and initialization signal timing constraints
Signal name Timing constraint Direction
INITTCMEN[1:0] 50% Input
INITRETRYEN[1:0]
INITRMWEN[1:0]
INITAHBPEN
INITVTOR[31:7]
CFGBIGENDa
CFGITCMSZ[3:0]a
CFGDTCMSZ[3:0]a
CFGAHBPSZ[2:0]a
CFGSTCALIB[25:0]a
a. Requires a multicycle constraint of a four cycle setup and a

three cycle hold.
E.4 ITCM interface timing constraints

Table E-3 shows the ITCM interface timing constraints.
Table E-3 ITCM interface timing constraints
ITCMADDR[23:3] 40% Output
ITCMCS
ITCMPRIV 50%
ITCMWR 40%
ITCMBYTEWR[7:0]
ITCMWDATA[63:0]
ITCMMASTER[3:0] 50%
ITCMMBISTIN[7:0]
ITCMRDATA[63:0] 70% Input
ITCMWAIT 50%
ITCMERR 70%
ITCMMBISTOUT[7:0]
ITCMRETRY 50%
E.5 D0TCM and D1TCM interface timing constraints

Table E-4 shows the D0TCM and D1TCM interface timing constraints.
Table E-4 D0TCM and D1TCM interface timing constraints
Signal namea Timing constraint Direction
D*TCMADDR[23:3] 40% Output
D*TCMCS
D*TCMPRIV 50%
D*TCMWR 40%
D*TCMBYTEWR[3:0]
D*TCMWDATA[31:0]
D*TCMMASTER[3:0] 50%
D*TCMMBISTIN[6:0]
D*TCMRDATA[31:0] 70% Input
D*TCMWAIT 50%
D*TCMERR 70%
D*TCMMBISTOUT[6:0]
D*TCMRETRY 50%
a. Where * is 0 for the D0TCM interface and 1 for the D1TCM

interface.
E.6 AXI master interface timing constraints

Table E-5 shows the AXI master interface timing constraints.
Table E-5 AXI master interface timing constraints
ACLKEN 20% Input
ARADDR[31:0] 70% Output
ARBURST[1:0]
ARCACHE[3:0]
ARID[2:0]
ARINNER[3:0]
ARLEN[2:0]
ARLOCK
ARMASTER
ARPROT[2:0]
ARREADY Input
ARSHARE Output
ARSIZE[1:0]
ARVALID
AWADDR[31:0]
AWBURST[1:0]
AWCACHE[3:0]
AWID[1:0]
AWINNER[3:0]
AWLEN[2:0]
AWLOCK
AWMASTER
AWPROT[2:0]
AWREADY Input
AWSIZE[1:0] Output
AWSHARE
AWSPARSE
AWVALID
BID[1:0] Input
BREADY Output
Table E-5 AXI master interface timing constraints (continued)
BRESP[1:0] 70% Input
BVALID
RDATA[63:0]
RID[2:0]
RLAST
RREADY Output
RRESP[1:0] Input
RVALID
WDATA[63:0] Output
WID[1:0]
WLAST
WREADY Input
WSTRB[7:0] Output
WVALID
E.7 AHB peripheral interface timing constraints

Table E-6 shows the AHB peripheral interface timing constraints.
Table E-6 AHB peripheral interface timing constraints
HTRANSP[1:0] 70% Output
HBURSTP[2:0]
HADDRP[31:0]
HWRITEP
HSIZEP[2:0]
HWDATAP[31:0]
HPROTP[3:0]
HREADYP Input
HRDATAP[31:0]
HRESPP
HMASTERP Output
EXREQP
EXRESPP Input
E.8 AHB slave interface timing constraints

Table E-7 shows the AHB slave interface timing constraints.
Table E-7 AHB slave interface timing constraints
Name Timing constraint Direction
HTRANSS[1:0] 60% Input
HREADYS
HSELS
HBURSTS[2:0]
HADDRS[31:0]
HWRITES
HSIZES[2:0]
HWDATAS[31:0]
HPROTS[3:0]
AHBSPRI
HREADYOUTS Output
HRDATAS[31:0]
HRESPS
WABORTS
AHBSRDY
E.9 AHB debug interface timing constraints

Table E-8 shows the AHB debug interface timing constraints.
Table E-8 AHB debug interface timing constraints
HTRANSD[1:0] 60% Input
HBURSTD[2:0]
HADDRD[31:0]
HWRITED
HSIZED[2:0]
HWDATAD[31:0]
HPROTD[3:0]
HREADYD Output
HRDATAD[31:0]
HRESPD
E.10 External private peripheral bus timing constraints

Table E-9 shows the external private peripheral bus timing constraints.
Table E-9 External private peripheral bus timing constraints
PSEL 50% Output
PENABLE
PWRITE
PADDR[19:2]
PADDR31
PWDATA[31:0]
PREADY Input
PSLVERR
PRDATA[31:0]
E.11 Sleep control interface timing constraints

Table E-10 shows the sleep control interface timing constraints.
Table E-10 Sleep control interface timing constraints
SLEEPING 70% Output
SLEEPDEEP
GATEHCLK 50%
SLEEPHOLDACKn
SLEEPHOLDREQn Input
ETMPWRUPREQ Output
E.12 WIC interface timing constraints

Table E-11 shows the WIC interface timing constraints.
Table E-11 WIC interface timing constraints
WICENACK 50% Output
WAKEUP
WICSENSE[242:0]
WICENREQ Input
E.13 ITM interface timing constraints

Table E-12 shows the ITM interface timing constraints.
Table E-12 ITM interface timing constraints
ATVALID 70% Output
AFREADY
ATDATA[7:0]
ATID[6:0]
ATREADY Input
AFVALID
E.14 ETM instruction trace interface timing constraints

Table E-13 shows the ETM instruction trace interface timing constraints.
Table E-13 ETM instruction trace interface timing constraints
ATVALIDMI 70% Output
AFREADYMI
ATDATAMI[7:0
]
ATIDMI[6:0]
ATREADYMI Input
AFVALIDMI
E.15 ETM data trace interface timing constraints

Table E-14 shows the ETM data trace interface timing constraints.
Table E-14 ETM data trace interface timing constraints
ATVALIDMD 70% Output
AFREADYMD
ATDATAMD[63:0
]
ATIDMD[6:0]
ATBYTESD[2:0]
ATREADYMD Input
AFVALIDMD
E.16 Trace synchronization interface timing constraints

Table E-15 shows the trace synchronization interface timing constraints.
Table E-15 Trace synchronization interface timing constraints
SYNCREQI 50% Input
SYNCREQD
DSYNC 60% Output
TRIGGER
E.17 Interrupts and events signal timing constraints

Table E-16 shows the Interrupts and events signal timing constraints.
Table E-16 Interrupts and events signal timing constraints
TXEV 50% Output
RXEV Input
IRQ[239:0]
NMI
ICERR[21:0] Output
DCERR[21:0]
ICDET[3:0]
DCDET[3:0]
E.18 Debug signals timing constraints

Table E-17 shows the debug signals timing constraints.
Table E-17 Debug signals timing constraints
HALTED 50% Output
DBGRESTART Input
DBGRESTARTED Output
EDBGRQ Input
DBGEN
NIDEN
IADDR[31:3] 70% Output
IADBGPROT 50% Input
E.19 Cross trigger interface timing constraints

Table E-18 shows the cross trigger interface timing constraints.
Table E-18 Cross trigger interface timing constraints
CTICHIN[3:0] 50% Input
CTICHOUT[3:0] Output
CTIRQ[1:0]
E.20 Miscellaneous signals timing constraints

Table E-19 shows the miscellaneous signals timing constraints.
Table E-19 Miscellaneous signals timing constraints
LOCKUP 50% Output
TRCENA 70%
TSVALUEB[63:0] 50% Input
TSCLKCHANGE
ECOREVNUM[35:0]a 10%
CTLPPBLOCK[3:0] 20%
a. Requires a multicycle timing constraint of a four cycle setup

and a three cycle hold.
E.21 FPU signal timing constraints

Table E-20 shows the FPU signal timing constraints.
Table E-20 FPU signal timing constraints
FPIXC 50% Output
FPIDC
FPOFC
FPUFC
FPDZC
FPIOC
E.22 MBIST interface timing constraints

Table E-21 shows the MBIST interface timing constraints.
Table E-21 MBIST interface timing constraints
nMBISTRESET 70% Input
MBISTREQ Input
MBISTACK Output
MBISTIMPERR[2:0] Output
MBISTCFG[3:0] Input
MBISTADDR[20:0]
MBISTARRAY[4:0]
MBISTREADEN
MBISTWRITEEN
MBISTBE[9:0]
MBISTINDATA[77:0]
MBISTOUTDATA[77:0 Output
]
E.23 Dual-redundant core comparison interface timing constraints

Table E-22 shows the dual-redundant core comparison interface timing constraints.
Table E-22 Dual-redundant core comparison interface timing constraints
DCCMINP[7:0] 50% Input
DCCMOUT[7:0] Output
DCCMINP2[7:0] Input
DCCMOUT2[7:0] Output
E.24 DFT interface timing constraints

Table E-23 shows the DFT interface timing constraints.
Table E-23 DFT interface timing constraints
DFTSEa 10% Input
DFTRSTDISABLEa
DFTRAMHOLDa
a. Requires a multicycle timing constraint of a two cycle

setup and a one cycle hold.
Appendix F
Tarmac Tracing
This appendix describes how to control generation of a tarmac trace file during a simulation that
traces program execution of a Cortex-M7 processor. It contains the following sections:
• About tarmac trace on page F-2.
• Setting up the resource requirements for tarmac trace on page F-3.
• Running simulation on page F-4.
• Tarmac variables on page F-5.
• Controlling tarmac generation on page F-6.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. F-1
Tarmac Tracing
F.1 About tarmac trace

A tarmac trace file is a trace of the Cortex-M7 processor program execution captured during
simulation. The output file is a normal text file that you can view in a text editor.
In addition to the RTL, the tarmac trace flow uses:
• A simulator capture module library, cm7_tarmac_dpi.so. The capture module has 32-bit
and 64-bit versions to match the simulator you use. The output of the capture module can
be saved for later processing or passed directly to the decoder process using a Unix pipe.
• A decoder process that produces the tarmac trace file from the capture module raw stream,
cm7_tarmac_decode. The decoder process is 32-bit that you can use with 32-bit or 64-bit
simulators.
These binaries have been tested on RHE5 and RHE6 Linux distributions. The signal collection
mechanism relies on the SystemVerilog DPI feature, so tarmac requires support for this feature
in your simulator.
For details of the tarmac trace file format, see the Arm®_Tarmac_Specification_v2.pdf document
in cortexm7/logical/testbench/execution_tb.
Tarmac Tracing
F.2 Setting up the resource requirements for tarmac trace

Arm supplies tests and an execution testbench as a deliverable resource. This testbench can be
configured to create a tarmac trace log, see Chapter 12 Integration Kit.
If you want to enable tarmac trace you must first install the protocol buffers. Protocol buffers
are available to download from Google, under a free software, open-source license.
Follow the installation instructions that are provided with the protocol buffers. For the correct
version of the protocol buffers see the Arm® Cortex®-M7 MCU Release Note.
After installing the protocol buffers make sure that the path to the installed libraries is present
on your LD_LIBRARY_PATH environment variable.
Note
• You must install 32-bit protocol buffers, even if you intend to use a 64-bit simulator.
• Installing protocol buffers might require the assistance of your system administrator.
Tarmac Tracing
F.3 Running simulation

The Integration Kit testbench can be used as a reference to demonstrate the tarmac flow. When
integrating the tarmac flow into your own simulations ensure to:
1. Add logical/testbench/shared/tarmac/verilog directory to the include paths. Within this

directory, include the file cm7_tarmac.sv in the design compilation. See
logical/testbench/execution_tb/verilog/rtl.vc.
2. Define the CM7_TARMAC and CM7_TARMAC_DPI Verilog macros.
3. The simulator loads either the 32-bit or the 64-bit cm7_tarmac_dpi.so file. Use:
a. The 32-bit library for 32-bit simulations.
b. The 64-bit library for 64-bit simulations.
The libraries are found in logical/testbench/shared/tarmac/lib or
logical/testbench/shared/tarmac/lib64.
4. The option for simulation or compilation depends on the simulator tool you use:
• For ModelSim use the simulation command:
-sv_lib logical/testbench/shared/tarmac/lib<64>/cm7_tarmac_dpi.so
• For VCS use the compilation command:
-sverilog logical/testbench/shared/tarmac/lib<64>/cm7_tarmac_dpi.so
• For IUS use the with the compilation command:
-sv logical/testbench/shared/tarmac/lib<64>/cm7_tarmac_dpi.so
5. To make the tarmac decoder available to the simulator module, add

logical/testbench/shared/tarmac/bin to your shell PATH environment variable.
6. The tarmac files generated are, by default named, cm7_tarmac.<path>.log where <path> is
a sanitized version of the hierarchical path of the Cortex-M7 processor in your design.
Tarmac Tracing
F.4 Tarmac variables

Tarmac generation is controlled using environment variables whose names are
CM7_TARMAC_<VAR>, and whose values hold a colon-separated list of pattern=value pairs:
• Pattern is a string (accepting wildcards) to be matched against the instance hierarchical

path (by default the pattern is * if not present), where the first matching pattern is taken
as the value for that instance.
• Value must have the characters =, :, and \ escaped by \, and can itself contain the value
of another variable, <VAR2>, by using the syntax @VAR2@.
— dump.@[email protected] always matches and contains the value of the <PATH> variable in its
value.
— *u_cpu0*=dump.0.evs:*u_cpu1*=dump.1.evs has separate values for u_cpu0 and
u_cpu1.
The tarmac trace flow uses several built-in variables. However, you can create other variables
for your own use within these variable values. For example, to create the variable CPUID, set the
environment variable CM7_TARMAC_CPUID to the value you require.
Example F-1
To set the command that executes to decode the raw stream, set the following environment
variables. This example shows the default values:
• CM7_TARMAC_EXEC: @DECODER@ -f @FILENAME@
• CM7_TARMAC_DECODER: cm7_tarmac_decode
• CM7_TARMAC_FILENAME: cm7_tarmac.@[email protected]
The PATH environment variable is built-in and has a value corresponding to the sanitized
hierarchical path of the processor instance.
Tarmac Tracing
F.5 Controlling tarmac generation

The tarmac environment variable CM7_TARMAC_ENABLE controls whether the raw stream is
processed for a particular processor. The value can be always, never, or a range A-B where A is
the start time and B is the stop time. For example:
• To disable tracing for all Cortex-M7 processor instances, set CM7_TARMAC_ENABLE to never.
• To enable tracing always for u_cpu0, but disable tracing for all other Cortex-M7 processor
instances, set CM7_TARMAC_ENABLE to *u_cpu0*=always:never.
• To trace between a simulation time of 1000 and 10000, set CM7_TARMAC_ENABLE to

1000-10000.
Time units are the same as those in the tarmac trace.
The raw stream from the capture module is post-processed by the tarmac variable EXEC. The raw
stream can be captured to a file for deferred processing using the tarmac variable DUMP that has
the value of a filename. The decoder can process this file by running:
cm7_tarmac_decode -i <dump file> -f tarmac.log
The default is to post-process immediately. However, you can disable the default by setting EXEC
to an empty value for that Cortex-M7 processor instance.
Use tarmac variables to set the time unit and scale for simulation to ensure that the tarmac trace
file contains the correct timing information. The environment variable CM7_TARMAC_TIME_UNIT
contains one of the following values: s, ms, us, ns, ps, fs, clk, tic. The variable TIME_SCALE is a
scale factor and can use scientific notation in the form aE-b. For example:
• CM7_TARMAC_TIME_UNIT=ns.
• CM7_TARMAC_TIME_SCALE=5E-1.
Sets the timestamp to be 0.5 times the simulation time in nanoseconds.
Appendix G
This appendix describes the CORTEXM7INTEGRATIONMCU module. It contains the following sections.
• About CORTEXM7INTEGRATIONMCU on page G-2.
• Configuring the CORTEXM7INTEGRATIONMCU level on page G-3.
• CORTEXM7INTEGRATIONMCU port list on page G-4.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. G-1
G.1 About CORTEXM7INTEGRATIONMCU

The CORTEXM7INTEGRATIONMCU is an example integration of the processor with the low area debug
and trace components. It is used in the IK and you can adapt it for your own requirements. If
you require a fully featured debug and trace implementation, Arm recommends using the
CoreSight SoC-400 product, see Arm® CoreSight™ SoC-400 Technical Reference Manual.
The CORTEXM7INTEGRATIONMCU contains:

• The CORTEXM7INTEGRATIONCS, see About the processor on page 1-2.
• The Cortex-M7 Debug Access Port (DAP), see Appendix D Cortex-M7 Debug Access
Port.
• The Cortex-M7 Trace Port Interface Unit (TPIU).
• A CoreSight system ROM table that identifies the CoreSight components in
CORTEXM7INTEGRATIONMCU.
Figure G-1 shows a block diagram of the CORTEXM7INTEGRATIONMCU module.
Debugger Cross-Trigger Interface
Cortex-M7 Debug
Access Port (CM7DAP)
Interrupts D0TCM
Peripherals AHBP Tightly-Coupled
D1TCM
DMA AHBS Memory
ITCM
MBIST
Instruction Instrumentation
trace trace
System ROM
table Cortex-M7 Trace Port
Interface Unit Data trace
(CM7TPIU) interface*
Clocks Resets AXI EPPB Trace port

master interface
* ETM data trace is not supported by
Figure G-1 CORTEXM7INTEGRATIONMCU block diagram
Note
You are permitted to modify only the CORTEXM7INTEGRATIONMCU.v file. Do not modify any other
files unless this document instructs you to do so, or it is specified in your contract.
G.2 Configuring the CORTEXM7INTEGRATIONMCU level

Most of the configuration options for this module are specified in the
CORTEXM7INTEGRATIONCS_CONFIG.v file. See Configuration options on page 2-3. The remaining
options are configured by parameters in the module itself.
To configure the CORTEXM7INTEGRATIONMCU either set the parameters on the instantiation of this
module in your system or modify the default values of the parameters in the
CORTEXM7INTEGRATIONCS_CONFIG.v and CORTEXM7INTEGRATIONMCU.v files.
Table G-1 shows the additional module specific options to configure the
Table G-1 CORTEXM7INTEGRATIONMCU additional configuration options
Default Supported
value values
SWMD 0 0,1 Controls whether SWD is multidrop capable:

0 Multidrop not supported.
1 Multidrop supported.
BASEADDR 0xE00FD003 - Configures the ROM table base address read from the DAP
during debug sessions.
JEPID 0 - This 7-bit value is your JEDEC JEP-106 identity code value. It is used in
the System ROM table PID1 and PID2 registers.
JEPCONT 0 - This 4-bit value is your JEDEC JEP-106 continuation code value. It is
used in the System ROM table PID4 register.
TARGETID 0x00000001 - This is a unique identifier for your SoC design. See the Arm® Debug
Interface Architecture Specification ADIv5.0 to ADIv5.2 for details. It is
used by the CM7DAP and has the bit assignments:
[31:28] TREVISION.
[27:12] TPARTNO.
[11:1] TDESIGNER.
[0] 1.
PARTNUM 0 - This 12-bit value is a part number that identifies your system. It is used
in the System ROM table PID0 and PID1 registers.
Note
The CORTEXM7INTEGRATIONMCU module does not support ETM data trace. Therefore the ETM
parameter value of 2 must not be used, only values 0 or 1 are supported.
You must set the JEPID, JEPCONT, PARTNUM and TARGETID parameter values to uniquely identify
your SoC design. See the Arm® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2
for details.
G.3 CORTEXM7INTEGRATIONMCU port list

Table G-2 shows the clock and reset signals for the CORTEXM7INTEGRATIONMCU.
Table G-2 Clock and reset signals
SIgnal name Direction Description
CLKIN Input Free running clock
CLKEN Input Clock enable for clk clock gate
FCLKEN Input Clock enable for fclk clock gate
HCLKEN Input Clock enable for hclk clock gate
CLK1EN Input Clock enable for dual-redundant core
FCLK1EN Input Clock enable for dual-redundant core
HCLK1EN Input Clock enable for dual-redundant core
ETMCLKEN Input Clock enable for ETM clock
STCLKEN Input Clock enable for SysTick clock generation
nSYSRESET Input Soft reset. Non-debug logic only
SYSRESETREQ Output Request for system reset, nSYSRESET
nPORESET Input Powerup reset for the entire processor
nDBGETMRESET Input Soft reset for the ETM only
CPUWAIT Input Stall the processor out of reset
SWCLKTCK Input SW/JTAG DP clock
TRACECLKIN Input TPIU trace port clock
TRESETn Input TPIU trace port reset
Table G-3 shows the static configuration pins for the CORTEXM7INTEGRATIONMCU.
Table G-3 Static configuration pins
Signal name Direction Description
CFGBIGEND Input D-side endianess configuration
CFGITCMSZ[3:0] Input ITCM size
CFGDTCMSZ[3:0] Input DTCM size
CFGAHBPSZ[2:0] Input AHBP region size
CFGSTCALIB[25:0] Input SysTick calibration
Table G-4 shows the reset configuration pins for the CORTEXM7INTEGRATIONMCU.
Table G-4 Reset configuration pins
INITTCMEN[1:0] Input TCM enables out of reset
INITRMWEN[1:0] Input TCM RMW enables out of reset
INITRETRYEN[1:0] Input TCM Retry enables out of reset
INITAHBPEN Input AHBP enable out of reset
INITVTOR[31:7] Input Vector table offset register out of reset
Table G-5 shows the ITCM signals for the CORTEXM7INTEGRATIONMCU.
Table G-5 ITCM signals
ITCMCS Output Chip select/RAM enable.
ITCMADDR[23:3] Output Transfer address for both reads and writes. All ITCM accesses are 64-bit aligned. Bits[2:0]
of the address are permanently 0.
ITCMWR Output RAM write enable:

Valid when ITCMCS is HIGH.
ITCMBYTEWR[7:0] Output Byte write strobes. Bit[n] is for bits[8n+7:8n] of data. Valid when ITCMCS is HIGH.
ITCMPRIV Output Privilege level of access:

LOW User access.
HIGH Privileged access.
ITCMMASTER[3:0] Output Encodes the requestor of the current access:

0b0000 Instruction fetch.
0b0001 Data access.
0b0010 Vector fetch on automated exception entry.
0b1001 Software data access from store queue.
0b1011 AHB slave access from store queue.
0b1100 Debugger access from store queue.
ITCMWDATA[63:0] Output Write data. Valid on a byte-wise basis as defined on ITCMBYTEWR. Memory must
ignore otherwise.
ITCMMBISTIN[7:0] Output MBIST sideband signals to access ECC RAM write data.
ITCMWAIT Input Wait signal to extend the current response phase:

LOW Complete phase.
HIGH Extend phase.
Table G-5 ITCM signals (continued)
ITCMERR Input Abort indication:

LOW No abort.
HIGH Abort.
Can be used for privilege checks for example.
ITCMRDATA[63:0] Input Read data. All data bytes are valid on the last cycle of a read response phase. Ignored by
processor on all other cycles.
ITCMRETRY Input Request to retry access whose read response phase completed on the previous cycle. A
typical use is to request a read transaction to be retried when an ECC error is detected.
ITCMMBISTOUT[7:0] Input MBIST sideband signals to access ECC RAM read data.
Table G-6 shows the DTCM signals for the CORTEXM7INTEGRATIONMCU.
Table G-6 DTCM signals
D0TCMCS Output RAM chip select.
D0TCMADDR[23:3] Output Transfer address for both reads and writes. All DTCM accesses are 32-bit aligned.
Bits[1:0] of the address are permanently set to 0. Bit[2] selects which DTCM interface a
transaction uses, 0 for D0TCM.
D0TCMWR Output RAM write enable:

Valid when D0TCMCS is HIGH.
D0TCMBYTEWR[3:0] Output Byte write strobes. Valid when D0TCMCS is HIGH.
D0TCMPRIV Output Privilege level of access.
D0TCMMASTER[3:0] Output Encodes the requestor of the current access:

0b0001 Data access.
D0TCMWDATA[31:0] Output Write data. Valid on a byte-wise basis as defined on ITCMBYTEWR. Memory must
ignore otherwise.
D0TCMMBISTIN[6:0] Output MBIST sideband signals to access RAM write data.
D0TCMWAIT Input Wait signal to extend the current data phase:

LOW Complete phase.
HIGH Extend phase.
Table G-6 DTCM signals (continued)
D0TCMERR Input Abort indication for access:

LOW No abort.
HIGH Abort.
D0TCMRDATA[31:0] Input Read data.
D0TCMRETRY Input Request to retry access whose read response phase completed on the previous cycle. A
D0TCMMBISTOUT[6:0] Input MBIST sideband signals to access ECC RAM read data.
D1TCMCS Output RAM chip select.
D1TCMADDR[23:3] Output Transfer address for both reads and writes. All DTCM accesses are 32-bit aligned.
Bits[1:0] of the address are permanently set to 0. Bit[2] selects which DTCM interface a
transaction uses, 1 for D1TCM.
D1TCMWR Output RAM write enable:

Valid when D1TCMCS is HIGH.
D1TCMBYTEWR[3:0] Output Byte write strobes. Valid when D1TCMCS is HIGH.
D1TCMPRIV Output Privilege level of access.
D1TCMMASTER[3:0] Output Encodes the requestor of the current access:

0b0001 Data access.
D1TCMWDATA[31:0] Output Write data. Valid on a byte-wise basis as defined on ITCMBYTEWR. Memory must
ignore otherwise.
D1TCMMBISTIN[6:0] Output MBIST sideband signals to access RAM write data.
D1TCMWAIT Input Wait signal to extend the current data phase:

LOW Complete phase.
HIGH Extend phase.
D1TCMERR Input Abort indication for access:

LOW No abort.
HIGH Abort.
Table G-6 DTCM signals (continued)
D1TCMRDATA[31:0] Input Read data.
D1TCMRETRY Input Request to retry access whose read response phase completed on the previous cycle. A
D1TCMMBISTOUT[6:0] Input MBIST sideband signals to access ECC RAM read data.
Table G-7 shows the AXIM, AMBA4 AXI signals for the CORTEXM7INTEGRATIONMCU.
Table G-7 AXIM, AMBA4 AXI, signals
ACLKEN Input Clock enable for the AXI master port
ARVALID Output See the Arm® AMBA® AXI and ACE Protocol Specification
AXI3, AXI4, and AXI4-Lite, ACE and ACE-Lite
ARADDR[31:0] Output
ARID[2:0] Output
ARBURST[1:0] Output
ARLEN[2:0] Output
ARSIZE[1:0] Output
ARLOCK Output
ARCACHE[3:0] Output
ARPROT[2:0] Output
ARMASTER Output
ARINNER[3:0] Output
ARSHARE Output
ARREADY Input
AWVALID Output
AWADDR[31:0] Output
AWID[1:0] Output
AWBURST[1:0] Output
AWLEN[2:0] Output
AWSIZE[1:0] Output
AWLOCK Output
AWCACHE[3:0] Output
AWPROT[2:0] Output
AWMASTER Output
AWINNER[3:0] Output
Table G-7 AXIM, AMBA4 AXI, signals (continued)
AWSHARE Output See the Arm® AMBA® AXI and ACE Protocol Specification
AXI3, AXI4, and AXI4-Lite, ACE and ACE-Lite
AWSPARSE Output
AWREADY Input
RREADY Output
RVALID Input
RID[2:0] Input
RLAST Input
RDATA[63:0] Input
RRESP[1:0] Input
WVALID Output
WID[1:0] Output
WDATA[63:0] Output
WSTRB[7:0] Output
WLAST Output
WREADY Input
BREADY Output
BVALID Input
BID[1:0] Input
BRESP[1:0] Input
Table G-8 shows the AHBP, AMBA 3 AHB-Lite signals for the CORTEXM7INTEGRATIONMCU.
Table G-8 AHBP, AMBA 3 AHB-Lite signals
HTRANSP[1:0] Output Indicates the type of the current transfer on the peripheral port.
HWRITEP Output Indicates type of transfer, read or write.
HSIZEP[2:0] Output Indicates size of data.
HBURSTP[2:0] Output HBURSTP is always SINGLE.
HPROTP[3:0] Output Protection control signal.
HMASTERP Output Indicates which master is currently performing a transfer, the processor or DAP:
LOW Processor.
HIGH DAP.
HADDRP[31:0] Output Address bus.
Table G-8 AHBP, AMBA 3 AHB-Lite signals (continued)
HWDATAP[31:0] Output Write data.
EXREQP Output Exclusive request.
HREADYP Input Indicates that a transfer has finished on the input bus.
Table G-9 shows the AHBS, AMBA3 AHB-Lite signals for the CORTEXM7INTEGRATIONMCU.
Table G-9 AHBS, AMBA3 AHB-Lite signals
HREADYOUTS Output Indicates that a transfer is complete.
HRESPS Output The transfer response status:

0b00 OKAY.
0b01 ERROR.
HRDATAS[31:0] Output Read data bus.
AHBSRDY Output Indicates when the AHBS is ready to accept transactions:

LOW Not ready.
HIGH Ready.
WABORTS Output Indicates asynchronous abort signaled on TCM interface for write access:
LOW No abort.
HIGH Abort.
This signal is always valid and can be asserted for consecutive cycles in the case of back-to-back
TCM interface aborts.
AHBSPRI Input Indicates that the AHBS or software access takes priority:
LOW Software access takes priority over AHBS access.
HIGH AHBS access takes priority over software access.
HREADYS Input Indicates whether a transfer has completed on the bus or to extend transfer on the bus:
HIGH Transfer completed.
LOW Extend a transfer.
HSELS Input When HIGH indicates that this interface has been selected.
HTRANSS[1:0] Input Indicates the type of the current transfer. All transfer types are supported.
HWRITES Input Write not Read.
HSIZES[2:0] Input Indicates the size of the access. Accesses can be:
0b000 Byte.
0b001 Halfword.
0b010 Word.
HBURSTS[2:0] Input Indicates if the transfer is part of a burst. All burst types are supported.
Any Incr type write burst that is word sized is optimized so that two beats are combined into
one 64-bit double-word aligned write into the Store Queue.
Table G-9 AHBS, AMBA3 AHB-Lite signals (continued)
HPROTS[3:0] Input Protection control signal.
HADDRS[31:0] Input 32-bit address.
HWDATAS[31:0] Input 32-bit write data bus.
Table G-10 shows the EPPB, AMBA3 APB signals for the CORTEXM7INTEGRATIONMCU.
Table G-10 EPPB, AMBA3 APB signals
PENABLE Output Strobe to time all accesses. Indicates the second cycle of an APB transfer.
PSEL Output Indicates that a data transfer is requested.
PADDR[19:2] Output 18-bit address. Only the bits that are relevant to the External Private Peripheral Bus are driven.
PADDR31 Output This signal is driven HIGH when the DAP is the requesting master. It is driven LOW when the
processor is the requesting master.
PWRITE Output Write not read.
PWDATA[31:0] Output 32-bit write data bus.
PREADY Input This signal is driven LOW if the currently accessed APB device requires extra wait states to
complete the transfer.
PSLVERR Input This signal is driven HIGH if the currently accessed APB device cannot handle the requested
transfer.
PRDATA[31:0] Input 32-bit read data bus.
Table G-11 shows the timestamp signals for the CORTEXM7INTEGRATIONMCU.
Table G-11 Timestamp signals
TSVALUEB[63:0] Input Global timestamp value
TSCLKCHANGE Input Timestamp clock ratio change
Table G-12 shows the debug signals for the CORTEXM7INTEGRATIONMCU.
Table G-12 Debug signals
HALTED Output Processor is in halt debug state
DBGRESTARTED Output Part of DBGRESTART handshake
DBGEN Input Invasive debug enable
Table G-12 Debug signals (continued)
NIDEN Input Non-invasive debug enable
EDBGRQ Input External debug request
DBGRESTART Input Request to leave halt state
Table G-13 shows the debug protection signals for the CORTEXM7INTEGRATIONMCU.
Table G-13 Debug protection signals
IADDR[31:3] Output Instruction DW address
IADBGPROT Input Protection status
Table G-14 shows the interrupt signals for the CORTEXM7INTEGRATIONMCU.
Table G-14 Interrupt signals
IRQ[239:0] Input External interrupt signals. The implemented bits of this signal is configured by the IRQNUM
parameter, see Configuration options on page 2-3.
NMI Input Non Maskable Interrupt.
Table G-15 shows the power control and sleep signals for the CORTEXM7INTEGRATIONMCU.
Table G-15 Power control and sleep signals
SLEEPING Output Processor is in sleep state
SLEEPDEEP Output Sleep is deep sleep
GATEHCLK Output Safe to turn off hclk
SLEEPHOLDACKn Output Sleep hold request
SLEEPHOLDREQn Input Sleep hold acknowledge
WAKEUP Output WIC request to wake-up
WICSENSE[242:0] Output IRQ, NMI, and RXEV sensitivity
WICENREQ Input Request to enable WIC
WICENACK Output Acknowledgement that WIC is enabled
ETMPWRUPREQ Output ETM powerup request combined with TRCENA
Table G-16 shows the event and error signals for the CORTEXM7INTEGRATIONMCU.
Table G-16 Event and error signals
LOCKUP Output Core is in Lockup state
TXEV Output Event out
ICERR[21:0] Output I-cache error bank information
DCERR[21:0] Output D-cache error bank information
ICDET[3:0] Output I-cache error detection information
DCDET[3:0] Output D-cache error detection information
RXEV Input Event in
Table G-17 shows the Floating Point Unit (FPU) exception flag signals for the
Table G-17 FPU exception flag signals
FPIXC Output Inexact
FPIDC Output Input denormal
FPOFC Output Overflow
FPUFC Output Underflow
FPDZC Output Divide-by-zero
FPIOC Output Invalid operation
Table G-18 shows the Cross Trigger Interface (CTI) signals for the CORTEXM7INTEGRATIONMCU.
Table G-18 CTI signals
CTICHIN[3:0] Input CTI Channel In
CTICHOUT[3:0] Output CTI Channel Out
CTIIRQ[1:0] Output CTI IRQ Request
Table G-19 shows the miscellaneous signals for the CORTEXM7INTEGRATIONMCU.
Table G-19 Miscellaneous signals
ECOREVNUM[51:0] Input ECO revision number. Tie-off all bits to zero. This must be a
top-level signal on your SoC design to prevent synthesis tools
optimizing out the logic driven by this signal. The ECO
revision field mappings are:
[51:48] MCU ROM table.
[47:44] TPIU.
[43:36] DAP.
[35:32] ETM.
[31:28] Reserved.
[27:24] Processor ROM table.
[23:20] ITM.
[19:16] PPB ROM table.
[15:12] SCS.
[11:8] DWT.
[7:4] FPB.
[3:0] CPUID revision.
CTLPPBLOCK[3:0] Input When HIGH, disables PPB writes to ITCMCR, DTCMCR,

AHBPCR or VTOR registers. Bit mappings are:
[0] ITCMCR.
[1] DTCMCR.
[2] AHBPCR.
[3] VTOR.
Table G-20 MBIST interface signals
MBISTREQ Input MBIST mode request. Connect to external MBIST

controller
MBISTACK Output MBIST mode acknowledge.
MBISTADDR[20:0] Input Logical address for transfer.
MBISTINDATA[77:0] Input Write data in.
MBISTOUTDATA[77:0] Output Read data out.
MBISTWRITEEN Input Write enable.
MBISTREADEN Input Read enable.
MBISTARRAY[4:0] Input Memory array selector.
MBISTBE[9:0] Input Byte or bit write enable.
Table G-20 MBIST interface signals (continued)
MBISTCFG[3:0] Input MBIST ALL Mode configuration:

[0] Enables ITCM MBIST ALL mode.
[1] Enables DTCM MBIST ALL mode.
[2] Enables I-Cache MBIST ALL mode.
[3] Enables D-Cache MBIST ALL mode.
nMBISTRESET Input MBIST reset.

Resets all logic and is equivalent to nPORESET. Assert
this signal for at least six CLKIN cycles.
MBISTIMPERR[2:0] Output MBIST error signal used during online MBIST:

[0] Processor attempted to access memory
that is currently selected by
MBISTARRAY.
Note
Bit[0] is only used in the software assisted
online test use case. It must be ignored in
the software transparent use case.
[1] Response phase error signal value,

*TCMERR, of TCM under test. This bit
is LOW when a TCM is not selected by
MBISTARRAY.
[2] Indicates that the memory selected by the
MBISTARRAY signal does not exist in
the processor implementation.
Appendix H
IP-XACT
This appendix describes the location and configuration of the IP-XACT files. It contains the
following sections:
• About IP-XACT for Cortex-M7 processor on page H-2.
• Location of the IP-XACT description file on page H-3.
• Generating the IP-XACT description on page H-4.
• Using the IP-XACT description on page H-5.
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. H-1
IP-XACT
H.1 About IP-XACT for Cortex-M7 processor

IP-XACT for Cortex-M7 processor is an XML description file of the CORTEXM7INTEGRATIONCS
module. This file describes the component interfaces, ports, and memory structures, including
registers, within IP-XACT v1.4.
Because it is supplied in an unconfigured state, you must process the XML description file to
remove information, as appropriate, to match your required configuration, see Generating the
IP-XACT description on page H-4.
For more information about IP-XACT, see http://www.accellera.org.
IP-XACT
H.2 Location of the IP-XACT description file

Table H-1 shows the IP-XACT description file and hierarchy level, the Verilog module, it is
associated with.
Table H-1 IP-XACT files
Verilog module IP-XACT description Description
verilog/CORTEXM7INTEGRATIONCS.v ipxact/CORTEXM7INTEGRATIONCS.xml The Cortex-M7 processor integration level

containing the processor, CTI, and ETM. The
.xml file is in the
logical/cortexm7_integration/ directory.
The .xml file supplied represents the configurable, but unconfigured, descriptions of the named
levels of hierarchy.
Note
There is no IP-XACT description for the CORTEXM7INTEGRATIONMCU level of hierarchy.
IP-XACT
H.3 Generating the IP-XACT description

This section describes how you can generate an IP-XACT description based on your chosen
configuration of the IP.
To generate an IP-XACT description, you must run the Build_Component script on an

unconfigured, source IP-XACT file, and supply the Verilog configuration parameters described
in Configuration options on page 2-3.
Note
• The Build_Component script uses the IPXACT_lib.pm module. The script requires Perl
utilities and Perl XML libraries.
• For more information about the script, type Build_Component -h.
The filename of the generated IP-XACT file is the source IP-XACT filename with a uniquifier
appended. You can supply a specific string to use as the uniquifier. If you do not supply a string,
Build_Component generates a string based on your configuration.
You must run the Build_Component script from the logical/shared/tools/bin directory:
cd <path>/logical/shared/tools/bin
You can run the script with or without a configuration file:
• With a configuration file:

Run Build_Component, supplying the name of the IP-XACT file and the configuration file.
Example:
./Build_Component ../../../cortexm7_integration/ipxact/ \
CORTEXM7INTEGRATIONCS.xml[uniquifier] -config <config_file>
The configuration file must be in the format:
parameter_name=parameter_value
• Without a configuration file:

Run Build_Component, supplying the name of the IP-XACT file. The script prompts for
configuration parameters to be typed in.
Example:
./Build_Component ../../../cortexm7_integration/ipxact/CORTEXM7INTEGRATIONCS.xml
You can save the parameters you typed in when the script prompts you.
The Build_Component script generates the configured IP-XACT file in the same directory as the
unconfigured source IP-XACT file.
IP-XACT
H.4 Using the IP-XACT description

You can use the generated IP-XACT descriptions with IP-XACT aware EDA tools for RTL
stitching. The IP-XACT descriptions reference bus definition files to describe the module
interfaces. Copies of the Arm bus definition files are in the ipxact/busdefs directory.
Figure H-1 shows the structure of the IP-XACT busdefs directory.
ipxact/
busdefs/
amba.com/
AMBA3/
AHBLiteInitiator/
AHBLiteTarget/
APB/
ATB/
AMBA4/
AXI4/
arm.com/
CoreSight/
Authentication/
Channel/
EVENT/
WTimestamp/
Cores/
CortexM7_TCM/
generic/
DFTInterface/
InterruptInterface/
RESET/
MBISTInterface/
Staticcfg/
clock/
interrupt/
Figure H-1 IP-XACT busdefs directory structure
Appendix I
Revisions
This appendix describes the technical changes between released issues of this book
Table I-1 Issue A
Change Location Affects
First release - -
Table I-2 Differences between Issue A and Issue B
Extensive changes throughout - r0p2
Added Low-power Integration chapter Chapter 13 Low-power Integration
Added DSM Generation chapter Chapter 15 DSM Generation
ARM DIT 0034H Copyright © 2014-2016, 2018 Arm Limited. All rights reserved. I-1
Revisions
Table I-3 Differences between Issue B and Issue C
EXRESPP signal connection information in AHB peripheral Table 4-9 on page 4-17 r1p0
interface signals table updated
Note relating to signals EXREQP, EXRESPP and HRESPP added AHB peripheral interface on page 4-17
Introduction to, and content of, AHBS memory map table updated Table 4-11 on page 4-20
Paragraph after AHBS memory map table added Table 4-11 on page 4-20
HBURSTS[2:0] signal description in AHB slave interface signals Table 4-12 on page 4-21
table updated
ATDATAMD signal bit range in ETM data trace interface signals Table 4-20 on page 4-33
table updated
SYNCREQD signal description in ETM data trace interface signals Table 4-20 on page 4-33
table updated
Added CTLPPBLOCK[3:0] signal to Miscellaneous interface Table 4-23 on page 4-37

signals table
First paragraph in section updated Configuration on page 4-39
Changed clk to fclk SysTick signals on page 4-46
Introduction to section updated About TCM integration on page 5-2
First paragraph in section updated TCM interface on page 5-4
Added step to numbered sequence TCM RAM integration testbench on page 5-16
MBISTIMPERR bit range updated Table 6-2 on page 6-8
Added MBISTIMPERR[2] description MBISTIMPERR[2:0] on page 6-10
Added note Production MBIST mode entry and exit on

page 6-20
Added note to sleep program description Table 12-1 on page 12-5
First bullet list updated Configuring the testbench on page 12-7
Added note to section introduction Running the testbench on page 12-16
Added note to end of numbered sequence Running with UPF on page 12-17
Added note to description of file sleep.c in test support files table Table 12-18 on page 12-38
Figure title updated Figure 14-2 on page 14-4
Deliverable directory structure updated Deliverable directory structure on page 15-10
Added footnote to protection control mapping table Table C-2 on page C-5
Added footnote to EXRESP signal in AHB-Lite master interface Table C-6 on page C-15
signals table
nSYSRESET description updated Table C-8 on page C-16
CM7DAP signals table updated Table D-23 on page D-23
Added CTLPPBLOCK signal to miscellaneous signals timing Table E-19 on page E-23
constraints table
Revisions
Table I-3 Differences between Issue B and Issue C (continued)
MBISTIMPERR signal bit range updated Table E-21 on page E-25 r1p0
Added CTLPPBLOCK[3:0] signal to miscellaneous signals table Table G-19 on page G-14
Section updated Generating the IP-XACT description on

page H-4
Table I-4 Differences between Issue C and Issue D
Added AXIM transaction issuing capability, interface clocking, AXIM transaction issuing capability on All revisions
and interface signal descriptions page 4-11
Interface clocking on page 4-12
Interface signals on page 4-13
Updated the TCMBYTEWR signal waveform in the TCM Figure 5-2 on page 5-11
write with two reads figure
Updated the TCMBYTEWR signal waveform in the TCM retry Figure 5-3 on page 5-12
phase for a waited read figure
Clarified the EXPECTED_CSI option setting Table 12-4 on page 12-11
Clarified the EXPECTED_HALTEV option setting Table 12-6 on page 12-13
Updated the first sentence about running a DSM model Running with a DSM model on page 12-17
Updated the signal ITCMBYTEWR[7:0] description Table G-5 on page G-5
Table I-5 Differences between Issue D and Issue E
Updated note to clarify that the interface does not have AHB peripheral interface on page 4-17 All revisions
semi-synchronous or asynchronous capability. AHB slave interface on page 4-20
Added a note that states the interface honors the endianness Interface signals on page 4-13 All revisions
configuration of the processor for loads and stores. AHB peripheral interface on page 4-17
AHBS interface byte lane assignments on page 4-23
Removed incorrect statement about instruction fetches. AHBS interface byte lane assignments on page 4-23 All revisions
Corrected description of Cortex-M7 SysTick including the SysTick signals on page 4-46 All revisions
STCLKEN signal.
Clarified the use of external synchronizers on the IRQ and Interrupt interface on page 4-36 All revisions
NMI inputs to reduce the possibility of metastability issues.
Synchronizers are not implemented on the processor for the
IRQ and NMI inputs.
Clarified how the DTCM wait-states can operate in functional TCM organization and configuration on page 5-9 All revisions
mode.
Revisions
Table I-6 Differences between issue E and issue F
Changed description of TSCLKCHANGE Table 4-23 on page 4-37 All revisions
Table I-7 Differences between Issue Fand Issue G
ITM name corrected Table 2-1 on page 2-3 All revisions
ITM name updated Reset modes on page 4-8 All revisions
AWSHARE description updated Table 4-8 on page 4-13 All revisions
AWID[1:0] connection information changed Table 4-8 on page 4-13 All revisions
AWCACHE removed. AxCACHE general information and Table 4-8 on page 4-13 All revisions
bit description added
AHBSPRI description updated Table 4-12 on page 4-21 All revisions
Table updated Table 4-18 on page 4-31 All revisions
Note added ITM interface on page 4-31 All revisions
New Cache error bank and detection section added Error reporting for the instruction and data cache on r1p1
page 4-42
Information about cells to modify for DCLS added Special purpose cells in the Cortex-M7 processor on All revisions
page 7-5
New sections added CM7DAP on page 7-6 r1p1

CM7TPIU on page 7-8
Miscellaneous modules on page 7-10
Table updated Table 8-3 on page 8-6 All revisions
Table updated and note added Table 8-4 on page 8-6 All revisions
Cortex-M7 Trace Port Interface Unit Appendix removed - r1p1
SWDETECT description added. Table D-23 on page D-24 All revisions
Table updated Table G-4 on page G-5 All revisions
Table I-8 Differences between Issue G and Issue H
New sections added Speculative accesses on page 4-4 All revisions
Updated direction column in AHB debug interface signals AHB debug interface signals on page 4-26 All revisions
table.
Updated description of EPPB interface. HPROTD attributes on page 4-27 All revisions
Updated TCM interface protocol section. TCM interface protocol on page 5-10 All revisions
Updated note in Multicycle RAM MBIST operations section. Multicycle RAM MBIST operations on page 6-22 All revisions
Added note to Architectural clock gating section. Architectural clock gating on page 7-4 All revisions
Revisions
Table I-8 Differences between Issue G and Issue H (continued)
Updated Special purpose cells used for synchronizing signals Special purpose cells used for synchronizing signals All revisions
table. on page 7-5
Updated Special purpose cells in optional components Special purpose cells in optional components on All revisions
section. page 7-6
Added note to AAB features section. AAB features on page C-2 All revisions
Updated IP-XACT busdefs directory structure diagram. Using the IP-XACT description on page H-5 All revisions
Updated write enable type in Cache RAM modules RAM size Blocks for memory integration on page 8-5 All revisions
and type without ECC table, and Cache RAM modules RAM
size and type with ECC table.

DIT0034H Cortex m7 r1p2 Iim

Uploaded by

Copyright:

Available Formats

DIT0034H Cortex m7 r1p2 Iim

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DIT0034H Cortex m7 r1p2 Iim

Uploaded by

Copyright:

Available Formats

Arm Cortex -M7 Processor

Integration and Implementation Manual

Copyright © 2014-2016, 2018 Arm Limited. All rights reserved.

Copyright © 2014-2016, 2018 Arm Limited. All rights reserved.

The following changes have been made to this book.

Date Issue Confidentiality Change

28 April 2014 A Confidential First release for r0p0

05 December 2014 B Confidential First release for r0p2

19 March 2015 C Confidential First release for r1p0

07 July 2015 D Confidential First release for r1p1

27 January 2016 E Confidential Second release for r1p1

22 August 2016 F Confidential Third release for r1p1

17 November 2016 G Confidential Fourth release for r1p1

15 November 2018 H Confidential First release for r1p2

THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO

This document may include technical inaccuracies or typographical errors.

Arm Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.

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

Chapter 2 Configuration Guidelines

Chapter 3 Key Integration Points

Chapter 4 Functional Integration Guidelines

4.8 AHB debug interface .............................................................................................. 4-25

Chapter 5 TCM Integration

Chapter 6 DFT Integration Guidelines

Chapter 7 Key Implementation Points

Chapter 8 Cache RAM Integration

Chapter 9 Floorplan Guidelines

Chapter 10 Netlist Dynamic Verification

Chapter 12 Integration Kit

Chapter 13 Low-power Integration

Chapter 14 Power Intent

Chapter 15 DSM Generation

Appendix A GPIO Programmers Model

Appendix B CoreSight SoC

Appendix C AXI4 to AHB-Lite Bridge

C.2 AAB behavior ........................................................................................................... C-4

Appendix D Cortex-M7 Debug Access Port

Appendix E Signal Timing Constraints

Appendix F Tarmac Tracing

About this book

Product revision status

Using this book

This book is organized into the following chapters:

Chapter 2 Configuration Guidelines

Chapter 3 Key Integration Points

Chapter 4 Functional Integration Guidelines

Chapter 5 TCM Integration

Chapter 6 DFT Integration Guidelines

Chapter 7 Key Implementation Points

Chapter 8 Cache RAM Integration

Chapter 9 Floorplan Guidelines

Chapter 10 Netlist Dynamic Verification

Chapter 12 Integration Kit

Chapter 13 Low-power Integration

Chapter 14 Power Intent

Chapter 15 DSM Generation

Appendix A GPIO Programmers Model

Appendix B CoreSight SoC