View ARM920T-14_8042274.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c arm920t (rev 1) technical reference manual
ii copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c arm920t technical reference manual copyright ? 2000, 2001 arm limited. all rights reserved. release information proprietary notice words and logos marked with ? or ? are registered trademarks or trademarks owned by arm limited, except as otherwise stated below in this proprietary notice. other brands and names mentioned herein may be the trademarks of their respective owners. neither the whole nor any part of the information contained in, or the product described in, this document may be adapted or reproduced in any material form except with the prior written permission of the copyright holder. the product described in this document is subject to continuous developments and improvements. all particulars of the product and its use contained in this document are given by arm in good faith. however, all warranties implied or expressed, including but not limited to implied warranties of merchantability, or fitness for purpose, are excluded. this document is intended only to assist the reader in the use of the product. arm limited shall not be liable for any loss or damage arising from the use of any information in this document, or any error or omission in such information, or any incorrect use of the product. figure 9-5 on page 9-12 reprinted with permission ieee std 1149.1-1990, ieee standard test access port and boundary-scan architecture copyright 2000, by ieee. the ieee disclaims any responsibility or liability resulting from the placement and use in the described manner confidentiality status this document is open access. this document has no restriction on distribution. product status the information in this document is final (information on a developed product). web address http://www.arm.com change history date issue change 31st january 2000 a first release 5th september 2000 b second release 18th april 2001 c third release
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. iii contents arm920t technical reference manual preface about this document .................................................................................... xvi further reading ............................................................................................. xx feedback ..................................................................................................... xxi chapter 1 introduction 1.1 about the arm920t ................................................................................... 1-2 1.2 processor functional block diagram ............................................................ 1-3 chapter 2 programmer?s model 2.1 about the programmer?s model ................................................................... 2-2 2.2 about the arm9tdmi programmer?s model ............................................... 2-3 2.3 cp15 register map summary ...................................................................... 2-5 chapter 3 memory management unit 3.1 about the mmu ........................................................................................... 3-2 3.2 mmu program accessible registers ............................................................. 3-4 3.3 address translation ..................................................................................... 3-6 3.4 mmu faults and cpu aborts ..................................................................... 3-21 3.5 fault address and fault status registers .................................................... 3-22 3.6 domain access control .............................................................................. 3-23 3.7 fault checking sequence .......................................................................... 3-25
contents iv copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.8 external aborts ......................................................................................... 3-28 3.9 interaction of the mmu and caches .......................................................... 3-29 chapter 4 caches, write buffer, and physical address tag (pa tag) ram 4.1 about the caches and write buffer .............................................................. 4-2 4.2 icache ........................................................................................................ 4-4 4.3 dcache and write buffer ............................................................................. 4-9 4.4 cache coherence ..................................................................................... 4-17 4.5 cache cleaning when lockdown is in use ................................................. 4-20 4.6 implementation notes ............................................................................... 4-21 4.7 physical address tag ram ..................................................................... 4-22 4.8 drain write buffer ...................................................................................... 4-23 4.9 wait for interrupt ....................................................................................... 4-24 chapter 5 clock modes 5.1 about arm920t clocking ........................................................................... 5-2 5.2 fastbus mode ............................................................................................ 5-3 5.3 synchronous mode ..................................................................................... 5-4 5.4 asynchronous mode ................................................................................... 5-6 chapter 6 bus interface unit 6.1 about the arm920t bus interface ............................................................. 6-2 6.2 unidirectional amba asb interface ............................................................ 6-3 6.3 fully-compliant amba asb interface ......................................................... 6-5 6.4 amba ahb interface ................................................................................ 6-21 6.5 level 2 cache support and performance analysis .................................... 6-23 chapter 7 coprocessor interface 7.1 about the arm920t coprocessor interface ................................................ 7-2 7.2 ldc/stc .................................................................................................... 7-5 7.3 mcr/mrc .................................................................................................. 7-9 7.4 interlocked mcr ....................................................................................... 7-11 7.5 cdp .......................................................................................................... 7-13 7.6 privileged instructions ............................................................................... 7-15 7.7 busy-waiting and interrupts ...................................................................... 7-17 chapter 8 trace interface port 8.1 about the etm interface ............................................................................. 8-2 chapter 9 debug support 9.1 about debug ............................................................................................... 9-2 9.2 debug systems ........................................................................................... 9-3 9.3 debug interface signals .............................................................................. 9-5 9.4 scan chains and jtag interface .............................................................. 9-11 9.5 the jtag state machine .......................................................................... 9-12 9.6 test data registers .................................................................................... 9-19
contents arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. v 9.7 arm920t core clocks ............................................................................... 9-42 9.8 clock switching during debug ................................................................... 9-43 9.9 clock switching during test ........................................................................ 9-44 9.10 determining the core state and system state ............................................ 9-45 9.11 exit from debug state ................................................................................ 9-48 9.12 the behavior of the program counter during debug .................................. 9-51 9.13 embeddedice macrocell .......................................................................... 9-54 9.14 vector catching ......................................................................................... 9-62 9.15 single-stepping ......................................................................................... 9-63 9.16 debug communications channel ............................................................... 9-64 chapter 10 trackingice 10.1 about trackingice .................................................................................... 10-2 10.2 timing requirements ................................................................................. 10-3 10.3 trackingice outputs ................................................................................. 10-4 chapter 11 amba test interface 11.1 about the amba test interface .................................................................. 11-2 11.2 entering and exiting amba test ............................................................... 11-3 11.3 functional test ........................................................................................... 11-4 11.4 burst operations ...................................................................................... 11-11 11.5 pa tag ram test ................................................................................... 11-12 11.6 cache test ............................................................................................... 11-15 11.7 mmu test ................................................................................................. 11-19 chapter 12 instruction cycle summary and interlocks 12.1 about the instruction cycle summary ........................................................ 12-2 12.2 instruction cycle times ............................................................................... 12-3 12.3 interlocks ................................................................................................... 12-6 chapter 13 ac characteristics 13.1 arm920t timing diagrams ........................................................................ 13-2 13.2 arm920t timing parameters .................................................................. 13-16 13.3 timing definitions for the arm920t trace interface port ....................... 13-26 appendix a signal descriptions a.1 amba signals .............................................................................................. a-2 a.2 coprocessor interface signals ..................................................................... a-5 a.3 jtag and tap controller signals ................................................................ a-7 a.4 debug signals ........................................................................................... a-10 a.5 miscellaneous signals ............................................................................... a-12 a.6 arm920t trace interface port signals ..................................................... a-13 appendix b cp15 test registers b.1 about the test registers ............................................................................... b-2 b.2 test state register ....................................................................................... b-3
contents vi copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c b.3 cache test registers and operations ........................................................... b-8 b.4 mmu test registers and operations ........................................................... b-18 b.5 strongarm backwards compatibility operations ...................................... b-30 glossary
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. vii list of tables arm920t technical reference manual change history .............................................................................................................. i i table 2-1 arm9tdmi implementation options ......................................................................... 2-3 table 2-2 cp15 register map .................................................................................................... 2-5 table 2-3 address types in arm920t ...................................................................................... 2-6 table 2-4 cp15 abbreviations ................................................................................................... 2-6 table 2-5 register 0, id code ................................................................................................... 2-8 table 2-6 cache type register format ...................................................................................... 2-10 table 2-7 cache size encoding (m=0) .................................................................................... 2-11 table 2-8 cache associativity encoding (m=0) ....................................................................... 2-11 table 2-9 line length encoding ............................................................................................... 2- 12 table 2-10 control register 1 bit functions ................................................................................ 2-12 table 2-11 clocking modes ....................................................................................................... 2-14 table 2-12 register 2, translation table base ............................................................................ 2-14 table 2-13 register 3, domain access control .......................................................................... 2-15 table 2-14 fault status register ................................................................................................ . 2-16 table 2-15 function descriptions register 7 .............................................................................. 2-17 table 2-16 cache operations register 7 .................................................................................... 2-18 table 2-17 tlb operations register 8 ........................................................................................ 2-1 9 table 2-18 accessing the cache lockdown register 9 ............................................................... 2-22 table 2-19 accessing the tlb lockdown register 10 ................................................................ 2-23 table 3-1 cp15 register functions ............................................................................................. 3 -4 table 3-2 level one descriptor bits ........................................................................................... 3 -9 table 3-3 interpreting level one descriptor bits [1:0] ............................................................... 3-10
list of tables viii copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c table 3-4 section descriptor bits ............................................................................................ 3- 11 table 3-5 coarse page table descriptor bits ........................................................................... 3-12 table 3-6 fine page table descriptor bits ................................................................................ 3-13 table 3-7 level two descriptor bits ......................................................................................... 3-1 6 table 3-8 interpreting page table entry bits [1:0] .................................................................... 3-16 table 3-9 priority encoding of fault status ............................................................................... 3-22 table 3-10 interpreting access control bits in domain access control register ......................... 3-23 table 3-11 interpreting access permission (ap) bits ................................................................ 3-24 table 4-1 dcache and write buffer configuration ................................................................... 4-11 table 5-1 clock selection for external memory accesses ......................................................... 5-4 table 6-1 relationship between bidirectional and unidirectional asb interface ....................... 6-3 table 6-2 arm920t input/output timing ................................................................................... 6-4 table 6-3 amba asb transfer types ......................................................................................... 6-6 table 6-4 burst transfers ....................................................................................................... ... 6-7 table 6-5 use of writeout signal ......................................................................................... 6-8 table 6-6 noncached ldr and fetch ...................................................................................... 6-12 table 6-7 data eviction of 4 or 8 words .................................................................................. 6-18 table 6-8 arm920t supported bus access types .................................................................. 6-23 table 7-1 handshake encoding ................................................................................................ 7-8 table 9-1 public instructions ................................................................................................... 9-14 table 9-2 id code register ...................................................................................................... 9-20 table 9-3 scan chain number allocation ................................................................................. 9-23 table 9-4 scan chain 0 bit order ............................................................................................. 9- 24 table 9-5 scan chain 1 bit function ......................................................................................... 9-2 8 table 9-6 scan chain 2 bit function ......................................................................................... 9-2 9 table 9-7 scan chain 15 format and access modes ............................................................... 9-32 table 9-8 scan chain 15 physical access mode bit format ..................................................... 9-33 table 9-9 physical access mapping to cp15 registers ........................................................... 9-33 table 9-10 scan chain 15 interpreted access mode bit format ................................................. 9-34 table 9-11 interpreted access mapping to cp15 registers ....................................................... 9-35 table 9-12 interpreted access mapping to the mmu ................................................................ 9-36 table 9-13 interpreted access mapping to the caches ............................................................. 9-36 table 9-14 scan chain 4 format ................................................................................................ 9 -39 table 9-15 arm9tdmi embeddedice macrocell register map ............................................... 9-54 table 9-16 watchpoint control register, data comparison bit functions .................................... 9-57 table 9-17 watchpoint control register for instruction comparison bit functions ....................... 9-59 table 9-18 debug status register bit functions ......................................................................... 9-60 table 9-19 debug comms control register bit functions ............................................................ 9-65 table 10-1 arm920t in trackingice mode ............................................................................. 10-4 table 11-1 amba test modes ................................................................................................... 11 -3 table 11-2 amba functional test locations ............................................................................... 11-4 table 11-3 construction of a920inputs location ....................................................................... 11-5 table 11-4 construction of a920status1 location ..................................................................... 11-6 table 11-5 construction of a920status2 location ..................................................................... 11-7 table 11-6 burst locations ...................................................................................................... 11-11 table 11-7 pa tag ram locations ........................................................................................ 11-12 table 11-8 construction of data pattern write data ................................................................. 11-12
list of tables arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. ix table 11-9 cache test locations .............................................................................................. 11 -15 table 11-10 cam write data ...................................................................................................... 11-15 table 11-11 cam match write data ........................................................................................... 11-1 6 table 11-12 cam match read data ........................................................................................... 11-16 table 11-13 invalidate by va write data .................................................................................... 11-1 6 table 11-14 lockdown victim and base data ............................................................................ 11-17 table 11-15 mmu test locations ................................................................................................ 1 1-19 table 11-16 invalidate by va data ............................................................................................ 11 -19 table 11-17 match write data .................................................................................................... 11-20 table 11-18 cam data ............................................................................................................ .. 11-20 table 11-19 cam data size_c encoding .................................................................................. 11-20 table 11-20 ram1 data ........................................................................................................... . 11-21 table 11-21 ram1 data access permission bits ....................................................................... 11-21 table 11-22 ram2 data ........................................................................................................... . 11-22 table 11-23 ram2 data size_r2 encoding .............................................................................. 11-22 table 12-1 symbols used in tables ........................................................................................... 12- 3 table 12-2 instruction cycle bus times ...................................................................................... 12- 3 table 12-3 data bus instruction times ....................................................................................... 12- 4 table 13-1 arm920t timing parameters ................................................................................ 13-16 table 13-2 arm920t trace interface port timing definitions ................................................. 13-26 table a-1 amba signals .......................................................................................................... .. a-2 table a-2 coprocessor interface signals ................................................................................... a-5 table a-3 jtag and tap controller signals .............................................................................. a-7 table a-4 debug signals ......................................................................................................... a-10 table a-5 miscellaneous signals ............................................................................................. a-1 2 table a-6 trace signals ......................................................................................................... .. a-13 table b-1 test state register ................................................................................................... .. b-3 table b-2 clocking mode selection ........................................................................................... b-5 table b-3 register 7 operations ................................................................................................ b-8 table b-4 register 9 operations ................................................................................................ b-8 table b-5 register 15 operations .............................................................................................. b -9 table b-6 cp15 mcr and mrc instructions ............................................................................. b-9 table b-7 register 7, 9, and 15 operations ............................................................................. b-10 table b-8 write cache victim and lockdown operations .......................................................... b-14 table b-9 ttb register operations ........................................................................................... b-1 8 table b-10 dac register operations .......................................................................................... b-1 9 table b-11 fsr register operations .......................................................................................... b-1 9 table b-12 far register operations .......................................................................................... b-2 0 table b-13 register 8 operations .............................................................................................. b -20 table b-14 register 10 operations ............................................................................................ b- 20 table b-15 cam, ram1, and ram2 register 15 operations ..................................................... b-20 table b-16 register 2, 3, 5, 6, 8, 10, and 15 operations ........................................................... b-21 table b-17 cam memory region size ........................................................................................ b-24 table b-18 access permission bit setting .................................................................................. b-25 table b-19 miss and fault encoding .......................................................................................... b-2 5 table b-20 ram2 memory region size ...................................................................................... b-26 table b-21 write tlb lockdown operations .............................................................................. b-27
list of tables x copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. xi list of figures arm920t technical reference manual figure p-1 key to timing diagram conventions ............................................................................ xix figure 1-1 arm920t functional block diagram .......................................................................... 1-3 figure 2-1 cp15 mrc and mcr bit pattern ............................................................................... 2-7 figure 2-2 cache type register format ........................................................................................ 2- 9 figure 2-3 dsize and isize field format ....................................................................................... 2 -9 figure 2-4 register 7 mva format ............................................................................................ 2-1 9 figure 2-5 register 7 index format ........................................................................................... 2- 19 figure 2-6 register 8 mva format ............................................................................................ 2-2 0 figure 2-7 register 9 ........................................................................................................... ..... 2-22 figure 2-8 register 10 .......................................................................................................... .... 2-23 figure 2-9 register 13 .......................................................................................................... .... 2-24 figure 2-10 address mapping using cp15 register 13 ............................................................. 2-25 figure 3-1 translation table base register .................................................................................. 3-6 figure 3-2 translating page tables ............................................................................................. 3-7 figure 3-3 accessing translation table level one descriptors ..................................................... 3-8 figure 3-4 level one descriptor ................................................................................................. . 3-9 figure 3-5 section descriptor ................................................................................................... 3-10 figure 3-6 coarse page table descriptor .................................................................................. 3-11 figure 3-7 fine page table descriptor ....................................................................................... 3-1 2 figure 3-8 section translation .................................................................................................. . 3-14 figure 3-9 level two descriptor ................................................................................................ 3-15 figure 3-10 large page translation from a coarse page table .................................................... 3-17 figure 3-11 small page translation from a coarse page table .................................................... 3-18
list of figures xii copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 3-12 tiny page translation from a fine page table ........................................................... 3-19 figure 3-13 domain access control register format ................................................................... 3-23 figure 3-14 sequence for checking faults .................................................................................. 3-25 figure 4-1 addressing the 16kb icache .................................................................................... 4-5 figure 5-1 arm920t clocking .................................................................................................... 5-2 figure 5-2 synchronous mode fclk to bclk zero phase delay .............................................. 5-5 figure 5-3 synchronous mode fclk to bclk one phase delay ............................................... 5-5 figure 5-4 asynchronous mode fclk to bclk zero cycle delay .............................................. 5-6 figure 5-5 asynchronous mode fclk to bclk one cycle delay ............................................... 5-7 figure 6-1 output buffer for bidirectional signals ....................................................................... 6-5 figure 6-2 output buffer for unidirectional signals ..................................................................... 6-6 figure 6-3 instruction fetch after reset ..................................................................................... 6- 11 figure 6-4 example ldr from address 0x108 ......................................................................... 6-12 figure 6-5 example ldm of 5 words from 0x108 ..................................................................... 6-13 figure 6-6 example nonbuffered str ..................................................................................... 6-14 figure 6-7 example nonbuffered stm ..................................................................................... 6-15 figure 6-8 example linefill from 0x100 ..................................................................................... 6-16 figure 6-9 example 4-word data eviction ................................................................................. 6-17 figure 6-10 example swap operation ........................................................................................ 6-19 figure 7-1 arm920t coprocessor clocking ............................................................................... 7-3 figure 7-2 arm920t ldc/stc cycle timing ............................................................................. 7-5 figure 7-3 arm920t mcr/mrc transfer timing ....................................................................... 7-9 figure 7-4 arm920t interlocked mcr .................................................................................... 7-12 figure 7-5 arm920t late canceled cdp ................................................................................. 7-14 figure 7-6 arm920t privileged instructions ............................................................................ 7-15 figure 7-7 arm920t busy waiting and interrupts .................................................................... 7-18 figure 9-1 typical debug system ............................................................................................... 9 -3 figure 9-2 breakpoint timing .................................................................................................... .. 9-5 figure 9-3 watchpoint entry with data processing instruction .................................................... 9-8 figure 9-4 watchpoint entry with branch ................................................................................... 9-9 figure 9-5 test access port (tap) controller state transitions ................................................. 9-12 figure 9-6 external scan chain multiplexor .............................................................................. 9-22 figure 9-7 write back physical address format ........................................................................ 9-40 figure 9-8 clock switching on entry to debug state ................................................................. 9-43 figure 9-9 debug exit sequence .............................................................................................. 9-4 9 figure 9-10 debug state entry ................................................................................................... 9-50 figure 9-11 arm9tdmi embeddedice macrocell overview ..................................................... 9-56 figure 9-12 watchpoint control register for data comparison .................................................... 9-57 figure 9-13 watchpoint control register for instruction comparison ........................................... 9-58 figure 9-14 debug control register ............................................................................................ 9 -60 figure 9-15 debug status register .............................................................................................. 9-60 figure 9-16 vector catch register ............................................................................................... 9-61 figure 9-17 debug comms control register ................................................................................ 9-64 figure 10-1 using trackingice .................................................................................................. 10-2 figure 11-1 amba functional test state machine ....................................................................... 11-9 figure 11-2 write data format .................................................................................................. 11-13 figure 12-1 single load interlock timing ..................................................................................... 12 -6
list of figures arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. xiii figure 12-2 two cycle load interlock .......................................................................................... 1 2-7 figure 12-3 ldm interlock ....................................................................................................... ... 12-8 figure 12-4 ldm dependent interlock ...................................................................................... 12-10 figure 13-1 arm920t fclk timed coprocessor interface ......................................................... 13-2 figure 13-2 arm920t bclk timed coprocessor interface ........................................................ 13-3 figure 13-3 arm920t fclk related signal timing ..................................................................... 13-4 figure 13-4 arm920t bclk related signal timing ..................................................................... 13-5 figure 13-5 arm920t sdoutbs to tdo relationship .............................................................. 13-5 figure 13-6 arm920t ntrst to other signals relationship ....................................................... 13-6 figure 13-7 arm920t jtag output signal timing ...................................................................... 13-7 figure 13-8 arm920t jtag input signal timing ........................................................................ 13-8 figure 13-9 arm920t fclk related debug output timing ......................................................... 13-8 figure 13-10 arm920t bclk related debug output timing ......................................................... 13-9 figure 13-11 arm920t tck related debug output timing ......................................................... 13-10 figure 13-12 arm920t edbgrq to dbgrqi relationship ....................................................... 13-10 figure 13-13 arm920t dbgen to output relationship .............................................................. 13-11 figure 13-14 arm920t bclk related trace interface port timing ............................................ 13-11 figure 13-15 arm920t fclk related trace interface port timing ............................................. 13-12 figure 13-16 arm920t bnres timing ....................................................................................... 13-12 figure 13-17 arm920t asb slave transfer timing ..................................................................... 13-13 figure 13-18 arm920t asb master transfer timing .................................................................. 13-14 figure 13-19 arm920t asb master transfer timing .................................................................. 13-15 figure b-1 cp15 mrc and mcr bit pattern ............................................................................... b-2 figure b-2 rd format, cam read .............................................................................................. b-1 2 figure b-3 rd format, cam write .............................................................................................. b- 12 figure b-4 rd format, ram read .............................................................................................. b-1 2 figure b-5 rd format, ram write .............................................................................................. b- 13 figure b-6 rd format, cam match ram read .......................................................................... b-13 figure b-7 data format, cam read ........................................................................................... b-13 figure b-8 data format, ram read ........................................................................................... b-13 figure b-9 data format, cam match ram read ....................................................................... b-14 figure b-10 rd format, write i or d cache victim and lockdown base ......................................... b-15 figure b-11 rd format, write i or d cache victim ........................................................................ b-15 figure b-12 rd format, cam write and data format, cam read .................................................. b-24 figure b-13 rd format, ram1 write ............................................................................................ b- 24 figure b-14 data format, ram1 read ......................................................................................... b-25 figure b-15 rd format, ram2 write and data format, ram2 read .............................................. b-26 figure b-16 rd format, write i or d tlb lockdown ..................................................................... b-27
list of figures xiv copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. xv preface this preface introduces the arm920t processor and its reference documentation. it contains the following sections: about this document on page xvi further reading on page xx feedback on page xxi.
preface xvi copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c about this document this document is the technical reference manual for the arm920t processor. intended audience this document has been written for hardware and software engineers who want to design or develop products based upon the arm920t processor. it assumes no prior knowledge of arm products. using this manual this document is organized into the following chapters: chapter 1 introduction read this chapter for an introduction to the arm920t. chapter 2 programmer?s model read this chapter for a description of the programmer ? s model for the arm920t. chapter 3 memory management unit read this chapter for a description of the memory management unit and the memory interface, including descriptions of the instruction and data interfaces. chapter 4 caches, write buffer, and physical address tag (pa tag) ram read this chapter for descriptions of cache, write buffer, and pa tag ram operation. chapter 5 clock modes read this chapter for a description of the processor clock modes. chapter 6 bus interface unit read this chapter for a description of the bus interface unit and the amba asb and ahb interface. chapter 7 coprocessor interface read this chapter for a description of the arm920t coprocessor interface.
preface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. xvii chapter 8 trace interface port read this chapter for a description of the trace interface port of the arm920t. chapter 9 debug support read this chapter for a description of the debug interface. chapter 10 trackingice read this chapter for a description of how the arm920t uses trackingice mode. chapter 11 amba test interface read this chapter for a description of the amba test interface. chapter 12 instruction cycle summary and interlocks read this chapter for details of instruction cycle times. this chapter contains timing diagrams for interlock timing. chapter 13 ac characteristics read this chapter for a description of the timing parameters used in the arm920t. appendix a signal descriptions read this chapter for a detailed description of the signals used in the arm920t. appendix b cp15 test registers read this chapter for a detailed description of the cp15 test register used in the arm920t.
preface xviii copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c typographical conventions the following typographical conventions are used in this book: bold highlights arm processor signal names, and interface elements, such as menu names and buttons. also used for terms in descriptive lists, where appropriate. italic highlights special terminology, cross-references, and citations. typewriter denotes text that can be entered at the keyboard, such as commands, file and program names, and source code. type writer denotes a permitted abbreviation for a command or option. the underlined text may be entered instead of the full command or option name. typewriter italic denotes arguments to commands or functions, where the argument is to be replaced by a specific value. typewriter bold denotes language keywords when used outside example code.
preface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. xix timing diagram conventions this manual contains a number of timing diagrams. figure p-1 explains the components used in these diagrams. any variations are clearly labeled when they occur. therefore, you must not attach any additional meaning unless specifically stated. figure p-1 key to timing diagram conventions 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 bus stable high to low transient bus to high impedance bus change high/low to high high impedance to stable bus
preface xx copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c further reading this section lists publications by arm limited, and by third parties. if you would like further information on arm products, or if you have questions not answered by this document, please contact info@arm.com or visit our web site at http://www.arm.com . arm publications this document contains information that is specific to the arm920t processor. refer to the following documents for other relevant information: arm architecture reference manual (arm ddi 0100) arm9tdmi data sheet (arm ddi 0029). other publications this section lists relevant documents published by third parties. ieee std. 1149.1- 1990, standard test access port and boundary-scan architecture .
preface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. xxi feedback arm limited welcomes feedback both on the arm920t processor, and on the documentation. feedback on the arm920t if you have any comments or suggestions about this product, please contact your supplier giving: the product name a concise explanation of your comments. feedback on the arm920t technical reference manual if you have any comments about this document, please send email to errata@arm.com giving: the document title the document number the page number(s) to which your comments refer a concise explanation of your comments. general suggestions for additions and improvements are also welcome.
preface xxii copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 1-1 chapter 1 introduction this chapter introduces the arm920t processor. it contains the following sections: about the arm920t on page 1-2 processor functional block diagram on page 1-3.
introduction 1-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 1.1 about the arm920t the arm920t processor is a member of the arm9tdmi family of general-purpose microprocessors, which includes: arm9tdmi (core) arm940t (core plus cache and protection unit) arm920t (core plus cache and mmu). the arm9tdmi processor core is a harvard architecture device implemented using a five-stage pipeline consisting of fetch, decode, execute, memory, and write stages. it can be provided as a standalone core that can be embedded into more complex devices. the standalone core has a simple bus interface that allows you to design your own caches and memory systems around it. the arm9tdmi family of microprocessors supports both the 32-bit arm and 16-bit thumb instruction sets, allowing you to trade off between high performance and high code density. the arm920t processor is a harvard cache architecture processor that is targeted at multiprogrammer applications where full memory management, high performance, and low power are all-important. the separate instruction and data caches in this design are 16kb each in size, with an 8-word line length. the arm920t processor implements an enhanced arm architecture v4 mmu to provide translation and access permission checks for instruction and data addresses. the arm920t processor supports the arm debug architecture and includes logic to assist in both hardware and software debug. the arm920t processor also includes support for coprocessors, exporting the instruction and data buses along with simple handshaking signals. the arm920t interface to the rest of the system is over unified address and data buses. this interface enables implementation of either an advanced microcontroller bus architecture (amba) advanced system bus (asb) or advanced high-performance bus (ahb) bus scheme either as a fully-compliant amba bus master, or as a slave for production test. the arm920t processor also has a tracking ice mode which allows an approach similar to a conventional ice mode of operation. the arm920t processor supports the addition of an embedded trace macrocell (etm) for real-time tracing of instructions and data.
introduction arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 1-3 1.2 processor functional block diagram figure 1-1 shows the functional block diagram of the arm920t processor. figure 1-1 arm920t functional block diagram the blocks shown in figure 1-1 are described as follows: the arm9tdmi core is described in the arm9tdmi technical reference manual . register 13 and coprocessor 15 are described in chapter 2 programmer?s model . the instruction and data mmus are described in chapter 3 memory management unit . the instruction and data caches, the write buffer, and the write-back pa tag ram are described in chapter 4 caches, write buffer, and physical address tag (pa tag) ram . external coprocessor interface arm9tdmi processor core (integral embeddedice) write buffer id[31:0] imva[31:0] wbpa[31:0] dpa[31:0] ipa[31:0] asb write back pa tag ram cp15 r13 iva[31:0] dva[31:0] jtag dd[31:0] instruction cache instruction mmu data mmu data cache r13 dindex[5:0] trace interface port amba bus interface dmva[31:0]
introduction 1-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the amba bus interface is described in chapter 6 bus interface unit . the external coprocessor interface is described in chapter 7 coprocessor interface . the trace interface port is described in chapter 8 trace interface port .
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-1 chapter 2 programmer ? s model this chapter describes the arm920t registers and provides details required when programming the microprocessor. it contains the following sections: about the programmer ? s model on page 2-2 about the arm9tdmi programmer ? s model on page 2-3 cp15 register map summary on page 2-5.
programmer?s model 2-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 2.1 about the programmer ? s model the arm920t processor incorporates the arm9tdmi integer core, which implements the arm architecture v4t. it executes the arm and thumb instruction sets, and includes embeddedice jtag software debug features. the programmer ? s model of the arm920t processor consists of the programmer ? s model of the arm9tdmi core (see about the arm9tdmi programmer ? s model on page 2-3) with the following additions and modifications: the arm920t processor incorporates two coprocessors: ? cp14, which allows software access to the debug communications channel. you can access the registers defined in cp14 using mcr and mrc instructions. these are described in debug communications channel on page 9-64. ? the system control coprocessor, cp15, which provides additional registers that are used to configure and control the caches, mmu, protection system, the clocking mode, and other system options of the arm920t, such as big or little-endian operation. you can access the registers defined in cp15 using mcr and mrc instructions. these are described in cp15 register map summary on page 2-5. the arm920t processor also features an external coprocessor interface that allows the attachment of a closely-coupled coprocessor on the same chip, for example, a floating-point unit. you can access registers and operations provided by any coprocessors attached to the external coprocessor interface using appropriate coprocessor instructions. memory accesses for instruction fetches and data loads and stores can be cached or buffered. cache and write buffer configuration and operation is described in detail in chapter 4 caches, write buffer, and physical address tag (pa tag) ram . the mmu page tables that reside in main memory describe the virtual to physical address mapping, access permissions, and cache and write buffer configuration. these are created by the operating system software and accessed automatically by the arm920t mmu hardware whenever an access causes a tlb miss. the arm920t has a trace interface port that allows the use of trace hardware and tools for real-time tracing of instructions and data.
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-3 2.2 about the arm9tdmi programmer ? s model the arm9tdmi processor core implements arm architecture v4t, and executes the arm 32-bit instruction set and the compressed thumb 16-bit instruction set. the programmer ? s model is fully described in the arm architecture reference manual . the arm9tdmi technical reference manual gives implementation details, including instruction execution cycle times. armv4t specifies a small number of implementation options. the options selected in the arm9tdmi implementation are listed in table 2-1. for comparison, the options selected for the arm7tdmi implementation are also shown. the arm9tdmi is code-compatible with the arm7tdmi, with two exceptions: the arm9tdmi core implements the base restored data abort model. this significantly simplifies the software data abort handler. the arm9tdmi fully implements the instruction set extension spaces added to the arm (32-bit) instruction set in armv4 and armv4t. these differences are explained in more detail in the following sections: data abort model on page 2-3 instruction set extension spaces on page 2-4. 2.2.1 data abort model the base restored data abort model differs from the base updated data abort model implemented by arm7tdmi. the difference in the data abort models affects only a very small section of operating system code, the data abort handler. it does not affect user code. with the base restored data abort model, when a data abort exception occurs during the execution of a memory access instruction, the base register is always restored by the processor hardware to the value the register contained before the instruction was executed. this removes the requirement for the data abort handler to unwind any base register update that might have been specified by the aborted instruction. table 2-1 arm9tdmi implementation options processor core architecture data abort model value stored by direct str, strt, and stm of pc arm7tdmi armv4t base updated address of instruction + 12 arm9tdmi armv4t base restored address of instruction + 12
programmer ? s model 2-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 2.2.2 instruction set extension spaces all arm processors implement the undefined instruction space as one of the entry mechanisms for the undefined instruction exception. that is, arm instructions with opcode[27:25] = 0b011 and opcode[4] = 0b1 are undefined on all arm processors including the arm9tdmi and arm7tdmi. armv4 and armv4t also introduce a number of instruction set extension spaces to the arm instruction set. these are: arithmetic instruction extension space control instruction extension space coprocessor instruction extension space load/store instruction extension space. instructions in these spaces are undefined, and cause an undefined instruction exception. the arm9tdmi core fully implements all the instruction set extension spaces defined in armv4t as undefined instructions, allowing emulation of future instruction set additions.
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-5 2.3 cp15 register map summary cp15 defines 16 registers. the register map for cp15 is shown in table 2-2. table 2-2 cp15 register map register read write 0 id code a a. register location 0 provides access to more than one register. the register accessed depends on the value of the opcode_2 field. see the register description for details. unpredictable 0 cache type a unpredictable 1 control control 2 translation table base translation table base 3 domain access control domain access control 4 unpredictable unpredictable 5 fault status b b. separate registers for instruction and data. see the register description for details. fault status b 6 fault address fault address 7 unpredictable cache operations 8 unpredictable tlb operations 9 cache lockdown b cache lockdown b 10 tlb lockdown b tlb lockdown b 11 unpredictable unpredictable 12 unpredictable unpredictable 13 fcse pid fcse pid 14 unpredictable unpredictable 15 test configuration test configuration
programmer ? s model 2-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 2.3.1 addresses in arm920t three distinct types of address exist in an arm920t system: virtual address (va) modified virtual address (mva) physical address (pa). below is an example of the address manipulation when the arm9tdmi core requests an instruction (see figure 2-10 on page 2-25). 1. the instruction va (iva) is issued by the arm9tdmi core. 2. this is translated by the procid to the instruction mva (imva). it is the imva that the instruction cache (icache) and mmu see. 3. if the protection check carried out by the immu on the imva does not abort, and the imva tag is in the icache, the instruction data is returned to the arm9tdmi core. 4. if the icache misses (the imva tag is not in the icache), then the immu performs a translation to produce the instruction pa (ipa). this address is given to the amba bus interface to perform an external access. 2.3.2 accessing cp15 registers the terms and abbreviations shown in table 2-4 are used throughout this section. table 2-3 address types in arm920t domain arm9tdmi caches and tlbs amba bus address virtual (va) modified virtual (mva) physical (pa) table 2-4 cp15 abbreviations term abbreviation description unpredictable unp for reads, the data returned when reading from this location is unpredictable. it can have any value. for writes, writing to this location causes unpredictable behavior, or an unpredictable change in device configuration. should be zero sbz when writing to this location, all bits of this field should be 0.
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-7 in all cases, reading from, or writing any data values to any cp15 registers, including those fields specified as unpredictable or should be zero , does not cause any permanent damage. all cp15 register bits that are defined and contain state, are set to zero by bnres except the v bit in register 1, which takes the value of macrocell input vinithi when bnres is asserted. you can only access cp15 registers with mrc and mcr instructions in a privileged mode. the instruction bit pattern of the mcr and mrc instructions is shown in figure 2-1. the assembler for these instructions is: mcr/mrc{cond} p15,opcode_1,rd,crn,crm,opcode_2 figure 2-1 cp15 mrc and mcr bit pattern instructions cdp , ldc , and stc , together with unprivileged mrc and mcr instructions to cp15, cause the undefined instruction trap to be taken. the crn field of mrc and mcr instructions specifies the coprocessor register to access. the crm field and opcode_2 fields specify a particular action when addressing registers. the l bit distinguishes between an mrc (l=1) and an mcr (l=0). note attempting to read from a nonreadable register, or to write to a nonwritable register causes unpredictable results. the opcode_1 , opcode_2 , and crm fields should be zero, except when the values specified are used to select the desired operations, in all instructions that access cp15. using other values results in unpredictable behavior. 313029282726252423222120191817161514131211109876543210 1110 1111 1 crm opcode_2 rd crn l opcode_1 cond
programmer ? s model 2-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 2.3.3 register 0, id code register this is a read-only register that returns a 32-bit device id code. you can access the id code register by reading cp15 register 0 with the opcode_2 field set to any value other than 1 (the crm field should be zero when reading). for example: mrc p15,0,rd,c0,c0,0 ; returns id register the contents of the id code are shown in table 2-5. 2.3.4 register 0, cache type register this is a read-only register that contains information about the size and architecture of the caches, allowing operating systems to establish how to perform such operations as cache cleaning and lockdown. all armv4t and later cached processors contain this register, allowing rtos vendors to produce future-proof versions of their operating systems. you can access the cache type register by reading cp15 register 0 with the opcode_2 field set to 1. for example: mrc p15,0,rd,c0,c0,1 ; returns cache details table 2-5 register 0, id code register bits function value 31:24 implementer 0x41 23:20 specification revision 0x1 19:16 architecture (armv4t) 0x2 15:4 part number 0x920 3:0 layout revision revision
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-9 the format of the cache type register is shown in figure 2-2. figure 2-2 cache type register format ctype the ctype field determines the cache type. s bit specifies whether the cache is a unified cache or separate instruction and data caches. dsize specifies the size, line length, and associativity of the data cache. isize specifies the size, line length, and associativity of the instruction cache. the dsize and isize fields in the cache type register have the same format. this is shown in figure 2-3. figure 2-3 dsize and isize field format size the size field determines the cache size in conjunction with the m bit. assoc the assoc field determines the cache associativity in conjunction with the m bit. m bit the multiplier bit. determines the cache size and cache associativity values in conjunction with the size and assoc fields. len the len field determines the line length of the cache. 31 30 29 28 25 24 23 12 11 0 000 ctype s dsize isize 11109876543210 000 size assoc m len 23 22 21 20 19 18 17 16 15 14 13 12
programmer ? s model 2-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the register values for the arm920t cache type register are listed in table 2-6. bits [28:25] indicate which major cache class the implementation falls into. 0x6 means that the cache provides: cache-clean-step operation cache-flush-step operation lockdown facilities. table 2-6 cache type register format function register bits value reserved 31:29 0b000 ctype 28:25 0b0110 s 24 0b1 = harvard cache dsize reserved 23:21 0b000 size 20:18 0b101 = 16kb assoc 17:15 0b110 = 64-way m 14 0b0 len 13:12 0b10 = 8 words per line (32 bytes) isize reserved 11:9 0b000 size 8:6 0b101 = 16kb assoc 5:3 0b110 = 64-way m2 0b0 len 1:0 0b10 = 8 words per line (32 bytes)
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-11 the size of the cache is determined by the size field and the m bit. the m bit is 0 for the data and instruction caches. bits [20:18] for the data cache (dcache) and bits [8:6] for the instruction cache (icache) are the size field. table 2-7 shows the cache size encoding. the associativity of the cache is determined by the assoc field and the m bit. the m bit is 0 for the data and instruction caches. bits [17:15] for the dcache and bits [5:3] for the icache are the assoc field. table 2-8 shows the cache associativity encoding. table 2-7 cache size encoding (m=0) size field cache size 0b000 512b 0b001 1kb 0b010 2kb 0b011 4kb 0b100 8kb 0b101 16kb 0b110 32kb 0b111 64kb table 2-8 cache associativity encoding (m=0) assoc field associativity 0b000 direct mapped 0b001 2-way 0b010 4-way 0b011 8-way 0b100 16-way 0b101 32-way 0b110 64-way 0b111 128-way
programmer ? s model 2-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the line length of the cache is determined by the len field. bits [13:12] for the dcache and bits [1:0] for the icache are the len field. table 2-9 shows the line length encoding. 2.3.5 register 1, control register this register contains the control bits of the arm920t. all reserved bits must either be written with 0 or 1, as indicated, or written using read-modify-write. the reserved bits have an unpredictable value when read. use the following instructions to read and write this register: mrc p15, 0, rd, c1, c0, 0 ; read control register mcr p15, 0, rd, c1, c0, 0 ; write control register all defined control bits are set to 0 on reset, except the v bit. the v bit is set to 0 at reset if the vinithi pin is low, or 1 if the vinithi pin is high. the functions of the control bits are shown in table 2-10. table 2-9 line length encoding len field cache line length 00 2 words (8 bytes) 01 4 words (16 bytes) 10 8 words (32 bytes) 11 16 words (64 bytes) table 2-10 control register 1 bit functions register bits name function value 31 ia bit asynchronous clock select see table 2-11 on page 2-14. 30 nf bit notfastbus select see table 2-11 on page 2-14. 29:15 - reserved read = unpredictable. write = should be zero. 14 rr bit round robin replacement 0 = random replacement. 1 = round-robin replacement. 13 v bit base location of exception registers 0 = low addresses = 0x00000000 . 1 = high addresses = 0xffff0000 .
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-13 12 i bit icache enable 0 = icache disabled. 1 = icache enabled. 11:10 - reserved read = 00. write = 00. 9 r bit rom protection this bit modifies the mmu protection system. see domain access control on page 3-23. 8 s bit system protection this bit modifies the mmu protection system. see domain access control on page 3-23. 7 b bit endianness 0 = little-endian operation. 1 = big-endian operation. 6:3 - reserved read = 1111. write = 1111. 2 c bit dcache enable 0 = dcache disabled. 1 = dcache enabled. 1 a bit alignment fault enable data address alignment fault checking. 0 = fault checking disabled. 1 = fault checking enabled. 0 m bit mmu enable 0 = mmu disabled. 1 = mmu enabled. table 2-10 control register 1 bit functions (continued) register bits name function value
programmer ? s model 2-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c register 1 bits [31:30] select the clocking mode of the arm920t, as shown in table 2-11. enabling the mmu you must take care with the address mapping of the code sequence used to enable the mmu (see enabling the mmu on page 3-29). see enabling and disabling the icache on page 4-6 and enabling and disabling the dcache and write buffer on page 4-10 for the restrictions and the effects of having caches enabled with the mmu disabled. 2.3.6 register 2, translation table base (ttb) register this is the translation table base (ttb) register, for the currently active first-level translation table. the contents of register 2 are shown in table 2-12. reading from register 2 returns the pointer to the currently active first-level translation table in bits [31:14]. writing to register 2 updates the pointer to the first-level translation table from bits [31:14] of the written value. bits [13:0] should be zero when written, and are unpredictable when read. table 2-11 clocking modes clocking mode ia nf fastbus mode 0 0 synchronous 0 1 reserved 1 0 asynchronous 1 1 table 2-12 register 2, translation table base register bits function 31:14 pointer to first-level translation table base. read/write. 13:0 reserved: read = unpredictable. write = should be zero.
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-15 you can use the following instructions to access the ttb: mrc p15, 0, rd, c2, c0, 0 ; read ttb register mcr p15, 0, rd, c2, c0, 0 ; write ttb register 2.3.7 register 3, domain access control register register 3 is the read and write domain access control register, consisting of 16 2-bit fields. each of these 2-bit fields defines the access permissions for the domains shown in table 2-13. table 2-13 register 3, domain access control register bits domain 31:30 d15 29:28 d14 27:26 d13 25:24 d12 23:22 d11 21:20 d10 19:18 d9 17:16 d8 15:14 d7 13:12 d6 11:10 d5 9:8 d4 7:6 d3 5:4 d2 3:2 d1 1:0 d0
programmer ? s model 2-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the encoding of the two bit domain access permission field is given in domain access control on page 3-23. you can use the following instructions to access the domain access control register: mrc p15, 0, rd, c3, c0, 0 ; read domain 15:0 access permissions mcr p15, 0, rd, c3, c0, 0 ; write domain 15:0 access permissions 2.3.8 register 4, reserved you must not access (read or write) this register because it causes unpredictable behavior. 2.3.9 register 5, fault status registers register 5 is the fault status register (fsr). the fsr contains the source of the last data fault, indicating the domain and type of access being attempted when the data abort occurred. table 2-14 shows bit allocations for the fsr. the fault type encoding is shown in fault address and fault status registers on page 3-22. the data fsr is defined in armv4t. additionally, a pipelined prefetch fsr is available, for debug purposes only. the pipeline matches that of the arm9tdmi. you can use the following instructions to access the data and prefetch fsr: mrc p15, 0, rd, c5, c0, 0 ;read data fsr value mcr p15, 0, rd, c5, c0, 0 ;write data fsr value mrc p15, 0, rd, c5, c0, 1 ;read prefetch fsr value mcr p15, 0, rd, c5, c0, 1 ;write prefetch fsr value table 2-14 fault status register bit description 31:9 unp when read sbz for write 80 when read sbz for write 7:4 domain being accessed when fault occurred (d15 - d0) 3:0 fault type
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-17 the ability to write to the fsr is useful for a debugger to restore the value of the fsr. you must write to the register using the read-modify-write method. bits[31:8] should be zero. 2.3.10 register 6, fault address register register 6 is the fault address register (far). this contains the mva of the access being attempted when the last fault occurred. the far is only updated for data faults, not for prefetch faults. (you can find the address for a prefetch fault in r14.) you can use the following instructions to access the far: mrc p15, 0, rd, c6, c0, 0 ;read far data mcr p15, 0, rd, c6, c0, 0 ;write far data the ability to write to the far is provided to allow a debugger to restore a previous state. 2.3.11 register 7, cache operations register register 7 is a write-only register used to manage the icache and dcache. the cache operations provided by register 7 are described in table 2-15. table 2-15 function descriptions register 7 function description invalidate cache invalidates all cache data, including any dirty data. a use with caution. a. dirty data is data that has been modified in the cache but not yet written to main memory. invalidate single entry using mva invalidates a single cache line, discarding any dirty data. a use with caution. clean d single entry using either index or mva writes the specified cache line to main memory, if the line is marked valid and dirty, and marks the line as not dirty. a the valid bit is unchanged. clean and invalidate d entry using either index or mva writes the specified cache line to main memory, if the line is marked valid and dirty. a the line is marked not valid. prefetch cache line performs an icache lookup of the specified mva. if the cache misses, and the region is cachable, a linefill is performed.
programmer ? s model 2-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the function of each cache operation is selected by the opcode_2 and crm fields in the mcr instruction used to write cp15 register 7. writing other opcode_2 or crm values is unpredictable. reading from cp15 register 7 is unpredictable. table 2-16 shows instructions that you can use to perform cache operations with register 7. table 2-16 cache operations register 7 function data instruction invalidate icache and dcache sbz mcr p15,0,rd,c7,c7,0 invalidate icache sbz mcr p15,0,rd,c7,c5,0 invalidate icache single entry (using mva) mva format mcr p15,0,rd,c7,c5,1 prefetch icache line (using mva) mva format mcr p15,0,rd,c7,c13,1 invalidate dcache sbz mcr p15,0,rd,c7,c6,0 invalidate dcache single entry (using mva) mva format mcr p15,0,rd,c7,c6,1 clean dcache single entry (using mva) mva format mcr p15,0,rd,c7,c10,1 clean and invalidate dcache entry (using mva) mva format mcr p15,0,rd,c7,c14,1 clean dcache single entry (using index) index format mcr p15,0,rd,c7,c10,2 clean and invalidate dcache entry (using index) index format mcr p15,0,rd,c7,c14,2 drain write buffer a a. stops execution until the write buffer has drained. sbz mcr p15,0,rd,c7,c10,4 wait for interrupt b b. stops execution in a low power state until an interrupt occurs. sbz mcr p15,0,rd,c7,c0,4
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-19 the operations that you can carry out on a single cache line identify the line using the data passed in the mcr instruction. the data is interpreted using one of the formats shown in figure 2-4 or figure 2-5. figure 2-4 register 7 mva format figure 2-5 register 7 index format the use of register 7 is described in chapter 4 caches, write buffer, and physical address tag (pa tag) ram . 2.3.12 register 8, tlb operations register register 8 is a write-only register used to manage the translation lookaside buffers (tlbs), the instruction tlb, and the data tlb. five tlb operations are defined and you can select the function to be performed with the opcode_2 and crm fields in the mcr instruction used to write cp15 register 8. writing other opcode_2 or crm values is unpredictable. reading from cp15 register 8 is unpredictable. table 2-17 shows instructions that you can use to perform tlb operations using register 8. 31 54 0 modified virtual address sbz 31 26 25 8 7 5 4 0 index sbz sbz seg table 2-17 tlb operations register 8 function data instruction invalidate tlb(s) sbz mcr p15,0,rd,c8,c7,0 invalidate i tlb sbz mcr p15,0,rd,c8,c5,0
programmer ? s model 2-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c note these functions invalidate all the unpreserved entries in the tlb. invalidate tlb single entry functions invalidate any tlb entry corresponding to the mva given in rd, regardless of its preserved state. see register 10, tlb lockdown register on page 2-22. figure 2-6 shows the mva format used for operations on single entry tlb lines using register 8. figure 2-6 register 8 mva format 2.3.13 register 9, cache lockdown register register 9 is the cache lockdown register. the cache lockdown register is 0x0 on reset. the cache lockdown register allows software to control which cache line in the icache or dcache respectively is loaded for a linefill and to prevent lines in the icache or dcache from being evicted during a linefill, locking them into the cache. there is a register for each of the icache and dcache. the value of opcode_2 determines which cache register to access: opcode_2 = 0x0 accesses the dcache register opcode_2 = 0x1 accesses the icache register. the opcode_1 and crm fields should be zero. reading cp15 register 9 returns the value of the cache lockdown register, which is the base pointer for all cache segments. invalidate i tlb single entry (using mva) mva format mcr p15,0,rd,c8,c5,1 invalidate d tlb sbz mcr p15,0,rd,c8,c6,0 invalidate d tlb single entry (using mva) mva format mcr p15,0,rd,c8,c6,1 table 2-17 tlb operations register 8 (continued) function data instruction 31 10 9 0 modified virtual address sbz
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-21 note only bits [31:26] are returned. bits [25:0] are unpredictable. writing cp15 register 9 updates the cache lockdown register, both the base and the current victim pointer for all cache segments. bits [25:0] should be zero. the victim counter specifies the cache line to be used as the victim for the next linefill. this is incremented using either a random or round-robin replacement policy, determined by the state of the rr bit in register 1. the victim counter generates values in the range (base to 63). this locks lines with index values in the range (0 to base-1). if base = 0, there are no locked lines. writing to cp15 register 9 updates the base pointer and the current victim pointer. the next linefill uses, and then increments, the victim pointer. the victim pointer continues incrementing on linefills, and wraps around to the base pointer. for example, setting the base pointer to 0x3 prevents the victim pointer from selecting entries 0x0 to 0x2 , locking them into the cache. example 2-1 shows how you can load a cache line into icache line 0 and lock it down. example 2-1 load a cache line into icache line 0 and lock it down mcr to cp15 register 9, opcode_2 = 0x1, victim=base=0x0 mcr i prefetch. assuming the icache misses, a linefill occurs to line 0. mcr to cp15 register 9, opcode_2 = 0x1, victim=base=0x1 more icache linefills now occur into lines 1-63. example 2-2 shows how you can load a cache line into dcache line 0 and lock it down. example 2-2 load a cache line into dcache line 0 and lock it down mcr to cp15 register 9, opcode_2 = 0x0, victim=base=0x0 data load (ldr/ldm). assuming the dcache misses, a linefill occurs to line 0. mcr to cp15 register 9, opcode_2 = 0x0, victim=base=0x1 more dcache linefills now occur into lines 1-63.
programmer ? s model 2-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c note writing cp15 register 9, with the crm field set to b0001 , updates the current victim pointer only for the specified segment. bits [31:26] specify the victim. bits [7:5] specify the segment (for a 16kb cache). all other bits should be zero. this encoding is intended for debug use. you are not recommended to use this encoding. figure 2-7 shows the format of bits in register 9. figure 2-7 register 9 table 2-18 shows the instructions you can use to access the cache lockdown register. 2.3.14 register 10, tlb lockdown register register 10 is the tlb lockdown register. the tlb lockdown register is 0x0 on reset. there is a tlb lockdown register for each of the tlbs, the value of opcode_2 determines which tlb register to access: opcode_2 = 0x0 accesses the d tlb register opcode_2 = 0x1 accesses the i tlb register. reading cp15 register 10 returns the value of the tlb lockdown counter base register, the current victim number, and the preserve bit (p bit). bits [19:1] are unpredictable when read. writing cp15 register 10 updates the tlb lockdown counter base register, the current victim pointer, and the state of the preserve bit. bits [19:1] should be zero when written. 31 26 25 0 index unp/sbz table 2-18 accessing the cache lockdown register 9 function data instruction read dcache lockdown base base mrc p15,0,rd,c9,c0,0 write dcache victim and lockdown base victim=base mcr p15,0,rd,c9,c0,0 read icache lockdown base base mrc p15,0,rd,c9,c0,1 write icache victim and lockdown base victim=base mcr p15,0,rd,c9,c0,1
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-23 table 2-19 shows the instructions you can use to access the tlb lockdown register. figure 2-8 shows the format of bits in register 10. figure 2-8 register 10 the entries in the tlbs are replaced using a round-robin replacement policy. this is implemented using a victim counter that counts from entry 0 up to 63, and then wraps back round to the base value and continues counting, wrapping around to the base value from 63 each time. there are two mechanisms available for ensuring entries are not removed from the tlb: locking an entry down prevents it from being selected for overwriting during a table walk. you can do this by programming the base value to which the victim counter reloads. for example, if the bottom 3 entries (0 ? 2) are to be locked down, you must program the base counter to 3. you can preserve an entry during an invalidate all instruction. you can do this by ensuring the p bit is set when the entry is loaded into the tlb. examples that show how you can load a single entry into the i and d tlbs at location 0, make it immune to invalidate all , and lock it down are shown in example 2-3 on page 2-24 and example 2-4 on page 2-24. table 2-19 accessing the tlb lockdown register 10 function data instruction read d tlb lockdown tlb lockdown mrc p15,0,rd,c10,c0,0 write d tlb lockdown tlb lockdown mcr p15,0,rd,c10,c0,0 read i tlb lockdown tlb lockdown mrc p15,0,rd,c10,c0,1 write i tlb lockdown tlb lockdown mcr p15,0,rd,c10,c0,1 31 26 25 20 19 1 0 base sbz/unp p victim
programmer ? s model 2-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c example 2-3 load a single entry into i tlb location 0, make it immune to invalidate all and lock it down mcr to cp15 register 10, opcode_2 = 0x1, base value = 0, current victim = 0, p = 1 mcr i prefetch. assuming an i tlb miss occurs, then entry 0 is loaded. mcr to cp15 register 10, opcode_2 = 0x1, base value = 1, current victim = 1, p = 0 example 2-4 load a single entry into d tlb location 0, make it immune to invalidate all and lock it down mcr to cp15 register 10, opcode_2 = 0x0, base value = 0, current victim = 0, p = 1 data load (ldr/ldm) or store (str/stm). assuming a d tlb miss occurs, then entry 0 is loaded. mcr to cp15 register 10, opcode_2 = 0x0, base value = 1, current victim = 1, p = 0 2.3.15 registers 11, 12, and 14, reserved accessing (reading or writing) any of these registers causes unpredictable behavior. 2.3.16 register 13, fcse pid register register 13 is the fast context switch extension (fcse) process identifier (pid) register. the fcse pid register is 0x0 on reset. reading from cp15 register 13 returns the value of the fcse pid. writing cp15 register 13 updates the fcse pid to the value in bits [31:25]. bits [24:0] should be zero. register 13 bit assignments are shown in figure 2-9. figure 2-9 register 13 31 25 24 0 fcse pid sbz
programmer ? s model arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 2-25 you can access register 13 using the following instructions: mrc p15, 0, rd, c13, c0, 0 ;read fcse pid mcr p15, 0, rd, c13, c0, 0 ;write fcse pid using the fcse process identifier (fcse pid) addresses issued by the arm9tdmi core in the range 0 to 32mb are translated by cp15 register 13, the fcse pid register. address a becomes a + ( fcse_pid x 32mb). it is this translated address that is seen by both the caches and mmu. see processor functional block diagram on page 1-3. addresses above 32mb undergo no translation. this is shown in figure 2-10 on page 2-25. the fcse_pid is a 7-bit field, enabling 128 x 32mb processes to be mapped. note if fcse_pid is zero, as it is on reset, then there is a flat mapping between the arm9tdmi and the caches and mmu. figure 2-10 address mapping using cp15 register 13 0 1 2 127 c13 virtual address (va) issued by arm9tdmi modified virtual address (mva) input to caches and mmu 0 4gb 0 32mb 4gb 32mb 64mb
programmer ? s model 2-26 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c changing the fcse pid, performing a fast context switch to do a fast context switch, write to cp15 register 13. the contents of the caches and tlbs do not have to be flushed after a fast context switch because they still hold valid address tags. the two instructions after the mcr to write the fcse_pid are fetched with the old fcse_pid value: {fcse_pid = 0} mov r0, #1:shl:25 ; fetched with fcse_pid = 0 mcr p15,0,r0,c13,c0,0 ; fetched with fcse_pid = 0 a1 ; fetched with fcse_pid = 0 a2 ; fetched with fcse_pid = 0 a3 ; fetched with fcse_pid = 1 2.3.17 register 15, test configuration register register 15 is used for test purposes. accessing (reading or writing) this register causes the arm920t to have unpredictable behavior.
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-1 chapter 3 memory management unit this chapter describes the memory management unit (mmu). it contains the following sections: about the mmu on page 3-2 mmu program accessible registers on page 3-4 address translation on page 3-6 mmu faults and cpu aborts on page 3-21 fault address and fault status registers on page 3-22 domain access control on page 3-23 fault checking sequence on page 3-25 external aborts on page 3-28 interaction of the mmu and caches on page 3-29.
memory management unit 3-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.1 about the mmu arm920t processor implements an enhanced arm architecture v4 mmu to provide translation and access permission checks for the instruction and data address ports of the arm9tdmi core. the mmu is controlled from a single set of two-level page tables stored in main memory, that are enabled by the m bit in cp15 register 1, providing a single address translation and protection scheme. you can independently lock and flush the instruction and data tlbs in the mmu. the mmu features are: standard armv4 mmu mapping sizes, domains, and access protection scheme mapping sizes are 1mb (sections), 64kb (large pages), 4kb (small pages), and 1kb (tiny pages) access permissions for sections access permissions for large pages and small pages can be specified separately for each quarter of the page (these quarters are called subpages) 16 domains implemented in hardware 64 entry instruction tlb and 64 entry data tlb hardware page table walks round-robin replacement algorithm (also called cyclic) invalidate whole tlb, using cp15 register 8 invalidate tlb entry, selected by mva, using cp15 register 8 independent lockdown of instruction tlb and data tlb, using cp15 register 10. 3.1.1 access permissions and domains for large and small pages, access permissions are defined for each subpage (1kb for small pages, 16kb for large pages). sections and tiny pages have a single set of access permissions. all regions of memory have an associated domain. a domain is the primary access control mechanism for a region of memory. it defines the conditions necessary for an access to proceed. the domain determines if: the access permissions are used to qualify the access the access is unconditionally allowed to proceed the access is unconditionally aborted.
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-3 in the latter two cases, the access permission attributes are ignored. there are 16 domains. these are configured using the domain access control register. 3.1.2 translated entries each tlb caches 64 translated entries. during cpu memory accesses, the tlb provides the protection information to the access control logic. if the tlb contains a translated entry for the mva, the access control logic determines if access is permitted: if access is permitted and an off-chip access is required, the mmu outputs the appropriate physical address corresponding to the mva if access is permitted and an off-chip access is not required, the cache services the access if access is not permitted, the mmu signals the cpu core to abort. if a tlb misses (it does not contain an entry for the va) the translation table walk hardware is invoked to retrieve the translation information from a translation table in physical memory. when retrieved, the translation information is written into the tlb, possibly overwriting an existing value. the entry to be written is chosen by cycling sequentially through the tlb locations. to enable use of tlb locking features, you can specify the location to write using cp15 register 10, tlb lockdown. when the mmu is turned off, as happens on reset, no address mapping occurs and all regions are marked as noncachable and nonbufferable. see about the caches and write buffer on page 4-2.
memory management unit 3-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.2 mmu program accessible registers table 3-1 lists the cp15 registers that are used in conjunction with page table descriptors stored in memory to determine the operation of the mmu. table 3-1 cp15 register functions register number bits register description control register 1 m, a, s, r contains bits to enable the mmu (m bit), enable data address alignment checks (a bit), and to control the access protection scheme (s bit and r bit). translation table base register 2 31:14 holds the physical address of the base of the translation table maintained in main memory. this base address must be on a 16kb boundary and is common to both tlbs. domain access control register 3 31:0 comprises 16 2-bit fields. each field defines the access control attributes for one of 16 domains (d15 ? d0). fault status register 5 (i and d) 7:0 indicates the cause of a data or prefetch abort, and the domain number of the aborted access, when an abort occurs. bits 7:4 specify which of the 16 domains (d15 ? d0) was being accessed when a fault occurred. bits 3:0 indicate the type of access being attempted. the value of all other bits is unpredictable. the encoding of these bits is shown in table 3-9 on page 3-22. fault address register 6 (d) 31:0 holds the mva associated with the access that caused the data abort. see table 3-9 on page 3-22 for details of the address stored for each type of fault. you can use arm9tdmi register 14 to determine the mva associated with a prefetch abort. tlb operations register 8 31:0 you can write to this register to make the mmu perform tlb maintenance operations. these are either invalidating all the (unpreserved) entries in the tlb, or invalidating a specific entry. tlb lockdown register 10 (i and d) 31:20 and 0 allows specific page table entries to be locked into the tlb and the tlb victim index to be read or written: opcode 2 = 0x0 accesses the d tlb lockdown register opcode 2 = 0x1 accesses the i tlb lockdown register. locking entries in the tlb guarantees that accesses to the locked page or section can proceed without incurring the time penalty of a tlb miss. this allows the execution latency for time-critical pieces of code such as interrupt handlers to be minimized.
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-5 all the cp15 mmu registers, except register 8, contain state. you can read them using mrc instructions, and write them using mcr instructions. registers 5 and 6 are also written by the mmu during a data abort. writing to register 8 causes the mmu to perform a tlb operation, to manipulate tlb entries. this register cannot be read. the instruction tlb (i tlb) and data tlb (d tlb) both have a copy of register 10. the opcode_2 field in the cp15 instruction is used to determine the one accessed. cp15 is described in chapter 2 programmer ? s model , with details of register formats and the coprocessor instructions you can use to access them.
memory management unit 3-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.3 address translation the mmu translates vas generated by the cpu core, and by cp15 register 13, into physical addresses to access external memory. it also derives and checks the access permission, using a tlb. the mmu table walking hardware is used to add entries to the tlb. the translation information, that comprises both the address translation data and the access permission data, resides in a translation table located in physical memory. the mmu provides the logic for you to traverse this translation table and load entries into the tlb. there are one or two stages in the hardware table walking, and permission checking, process. the number of stages depends on whether the address is marked as a section-mapped access or a page-mapped access. there are three sizes of page-mapped accesses and one size of section-mapped access. the page-mapped accesses are for: large pages small pages tiny pages. the translation process always starts out in the same way, with a level one fetch. a section-mapped access requires only a level one fetch, but a page-mapped access requires a subsequent level two fetch. 3.3.1 translation table base the hardware translation process is initiated when the tlb does not contain a translation for the requested mva. the translation table base (ttb) register points to the base address of a table in physical memory that contains section or page descriptors, or both. the 14 low-order bits of the ttb register are set to zero on a read, and the table must reside on a 16kb boundary. figure 3-1 shows the format of the ttb register. figure 3-1 translation table base register the translation table has up to 4096 x 32-bit entries, each describing 1mb of virtual memory. this allows up to 4gb of virtual memory to be addressed. figure 3-2 on page 3-7 shows the table walk process. 31 14 13 0 translation table base
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-7 figure 3-2 translating page tables translation table 4096 entries ttb base indexed by modified virtual address bits [31:20] level one fetch section 1mb indexed by modified virtual address bits [19:0] section base coarse page table 256 entries fine page table 1024 entries indexed by modified virtual address bits [19:12] indexed by modified virtual address bits [19:10] coarse page table base fine page table base level two fetch large page 64 kb small page 4kb tiny page 1kb large page base indexed by modified virtual address bits [15:0] indexed by modified virtual address bits [11:0] indexed by modified virtual address bits [9:0] 00 01 10 11 invalid 00 10 01 11 00 10 01 11 1 kb subpage 1 kb subpage 1 kb subpage 1 kb subpage 16 kb subpage 16 kb subpage 16 kb subpage 16 kb subpage small page base tiny page base invalid invalid invalid
memory management unit 3-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.3.2 level one fetch bits [31:14] of the ttb register are concatenated with bits [31:20] of the mva to produce a 30-bit address as shown in figure 3-3. figure 3-3 accessing translation table level one descriptors this address selects a 4-byte translation table entry. this is a level one descriptor for either a section or a page table. 3.3.3 level one descriptor the level one descriptor returned is either a section descriptor, a coarse page table descriptor, or a fine page table descriptor, or is invalid. figure 3-4 on page 3-9 shows the format of a level one descriptor. 31 20 19 0 table index 31 14 13 0 translation base 31 14 13 2 1 0 00 table index translation base 31 0 level one descriptor modified virtual address translation table base
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-9 figure 3-4 level one descriptor a section descriptor provides the base address of a 1mb block of memory. the page table descriptors provide the base address of a page table that contains level two descriptors. there are two sizes of page table: coarse page tables have 256 entries, splitting the 1mb that the table describes into 4kb blocks fine page tables have 1024 entries, splitting the 1mb that the table describes into 1kb blocks. level one descriptor bit assignments are shown in table 3-2. 31 2019 12111098 543210 00 coarse page table base address domain 1 0 1 section base address ap domain 1 c b 1 0 fine page table base address domain 1 1 1 fault coarse page table section fine page table table 3-2 level one descriptor bits bits description section coarse fine 31:20 31:10 31:12 these bits form the corresponding bits of the physical address 19:12 - - should be zero 11:10 - - access permission bits. domain access control on page 3-23 and fault checking sequence on page 3-25 show how to interpret the access permission bits 9 9 11:9 should be zero 8:5 8:5 8:5 domain control bits
memory management unit 3-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the two least significant bits of the level one descriptor indicate the descriptor type as shown in table 3-3. 3.3.4 section descriptor a section descriptor provides the base address of a 1mb block of memory. figure 3-5 shows the format of a section descriptor. figure 3-5 section descriptor 4 4 4 must be 1 3:2 - - these bits, c and b, indicate whether the area of memory mapped by this page is treated as write-back cachable, write-through cachable, noncached buffered, or noncached nonbuffered - 3:2 3:2 should be zero 1:0 1:0 1:0 these bits indicate the page size and validity and are interpreted as shown in table 3-3 table 3-3 interpreting level one descriptor bits [1:0] value meaning description 0 0 invalid generates a section translation fault 0 1 coarse page table indicates that this is a coarse page table descriptor 1 0 section indicates that this is a section descriptor 1 1 fine page table indicates that this is a fine page table descriptor table 3-2 level one descriptor bits (continued) bits description section coarse fine sbz 31 2019 12111098 543210 section base address ap domain 1 c b 1 0 sbz
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-11 section descriptor bit assignments are described in table 3-4. 3.3.5 coarse page table descriptor a coarse page table descriptor provides the base address of a page table that contains level two descriptors for either large page or small page accesses. coarse page tables have 256 entries, splitting the 1mb that the table describes into 4kb blocks. figure 3-6 shows the format of a coarse page table descriptor. figure 3-6 coarse page table descriptor note if a coarse page table descriptor is returned from the level one fetch, a level two fetch is initiated. table 3-4 section descriptor bits bits description 31:20 form the corresponding bits of the physical address for a section 19:12 always written as 0 11:10 (ap) specify the access permissions for this section 9 always written as 0 8:5 specify one of the 16 possible domains (held in the domain access control register) that contain the primary access controls 4 should be written as 1, for backward compatibility 3:2 these bits (c and b) indicate whether the area of memory mapped by this section is treated as write-back cachable, write-through cachable, noncached buffered, or noncached nonbuffered 1:0 these bits must be 10 to indicate a section descriptor 31 1098 543210 coarse page table base address domain 1 0 1 sbz sbz
memory management unit 3-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c coarse page table descriptor bit assignments are described in table 3-5. 3.3.6 fine page table descriptor a fine page table descriptor provides the base address of a page table that contains level two descriptors for large page, small page, or tiny page accesses. fine page tables have 1024 entries, splitting the 1mb that the table describes into 1kb blocks. figure 3-7 shows the format of a fine page table descriptor. figure 3-7 fine page table descriptor note if a fine page table descriptor is returned from the level one fetch, a level two fetch is initiated. table 3-5 coarse page table descriptor bits bits description 31:10 these bits form the base for referencing the level two descriptor (the coarse page table index for the entry is derived from the mva) 9 always written as 0 8:5 these bits specify one of the 16 possible domains (held in the domain access control registers) that contain the primary access controls 4 always written as 1 3:2 always written as 0 1:0 these bits must be 01 to indicate a coarse page table descriptor 31 1211 98 543210 fine page table base address domain 1 1 1 sbz sbz
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-13 fine page table descriptor bit assignments are described in table 3-6. 3.3.7 translating section references figure 3-8 on page 3-14 shows the complete section translation sequence. table 3-6 fine page table descriptor bits bits description 31:12 these bits form the base for referencing the level two descriptor (the fine page table index for the entry is derived from the mva) 11:9 always written as 0 8:5 these bits specify one of the 16 possible domains (held in the domain access control registers) that contain the primary access controls 4 always written as 1 3:2 always written as 0 1:0 these bits must be 11 to indicate a fine page table descriptor
memory management unit 3-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 3-8 section translation note you must check access permissions contained in the level one descriptor before generating the physical address. 3.3.8 level two descriptor if the level one fetch returns either a coarse page table descriptor or a fine page table descriptor, this provides the base address of the page table to be used. the page table is then accessed and a level two descriptor is returned. figure 3-9 on page 3-15 shows the format of level two descriptors. 31 14 13 0 translation base 31 14 13 2 1 0 00 table index translation base modified virtual address translation table base 31 20 19 0 table index section index 31 20 19 0 section index section base address section level one descriptor physical address 31 20 19 0 section base address ap domain cb1 0 21 3 4 5 8 9 10 11 12 1
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-15 figure 3-9 level two descriptor a level two descriptor defines a tiny, a small, or a large page descriptor, or is invalid: a large page descriptor provides the base address of a 64kb block of memory a small page descriptor provides the base address of a 4kb block of memory a tiny page descriptor provides the base address of a 1kb block of memory. coarse page tables provide base addresses for either small or large pages. large page descriptors must be repeated in 16 consecutive entries. small page descriptors must be repeated in each consecutive entry. fine page tables provide base addresses for large, small, or tiny pages. large page descriptors must be repeated in 64 consecutive entries. small page descriptors must be repeated in four consecutive entries and tiny page descriptors must be repeated in each consecutive entry. 31 12111098 543210 00 large page base address 0 1 small page base address c b 1 0 tiny page base address 1 1 fault large page small page tiny page 76 16 15 b c cb ap0 ap0 ap ap1 ap2 ap3 ap1 ap2 ap3
memory management unit 3-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c level two descriptor bit assignments are described in table 3-7. the two least significant bits of the level two descriptor indicate the descriptor type as shown in table 3-8. note tiny pages do not support subpage permissions and therefore only have one set of access permission bits. table 3-7 level two descriptor bits bits description large small tiny 31:16 31:12 31:10 these bits form the corresponding bits of the physical address 15:12 - 9:6 should be zero 11:4 11:4 5:4 access permission bits. domain access control on page 3-23 and fault checking sequence on page 3-25 show how to interpret the access permission bits 3:2 3:2 3:2 these bits, c and b, indicate whether the area of memory mapped by this page is treated as write-back cachable, write-through cachable, noncached buffered, or noncached nonbuffered 1:0 1:0 1:0 these bits indicate the page size and validity and are interpreted as shown in table 3-8 table 3-8 interpreting page table entry bits [1:0] value meaning description 0 0 invalid generates a page translation fault 0 1 large page indicates that this is a 64kb page 1 0 small page indicates that this is a 4kb page 1 1 tiny page indicates that this is a 1kb page
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-17 3.3.9 translating large page references figure 3-10 shows the complete translation sequence for a 64kb large page. figure 3-10 large page translation from a coarse page table because the upper four bits of the page index and low-order four bits of the coarse page table index overlap, each coarse page table entry for a large page must be duplicated 16 times (in consecutive memory locations) in the coarse page table. 31 14 13 0 translation base 31 14 13 2 1 0 00 table index translation base modified virtual address translation table base 31 20 19 0 table index page index level one descriptor physical address 31 0 coarse page table base address domain 11 21 3 4 5 8 9 10 l2 table index 16 15 12 11 31 16 15 0 page index page base address level two descriptor 31 0 coarse page table base address l2 table index 0 21 9 10 31 16 15 0 ap3 page base address 0 0 ap2 ap1 ap0 1 0 cb 1 2 3 4 5 6 7 8 9 10 11 12
memory management unit 3-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c if a large page descriptor is included in a fine page table, the high-order six bits of the page index and low-order six bits of the fine page table index overlap. each fine page table entry for a large page must therefore be duplicated 64 times. 3.3.10 translating small page references figure 3-11 shows the complete translation sequence for a 4kb small page. figure 3-11 small page translation from a coarse page table 31 14 13 0 translation base 31 14 13 2 1 0 00 table index translation base modified virtual address translation table base 31 20 19 0 table index page index level one descriptor physical address 31 0 coarse page table base address domain 11 21 3 4 5 8 9 10 level 2 table index 12 11 31 0 page index page base address level two descriptor 31 0 coarse page table base address l2 table index 0 21 9 10 31 0 ap3 page base address 0 0 ap2 ap1 ap0 0 1 cb 1 2 3 4 5 6 7 8 9 10 11 12 11 12
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-19 if a small page descriptor is included in a fine page table, the upper two bits of the page index and low-order two bits of the fine page table index overlap. each fine page table entry for a small page must therefore be duplicated four times. 3.3.11 translating tiny page references figure 3-12 shows the complete translation sequence for a 1kb tiny page. figure 3-12 tiny page translation from a fine page table 31 14 13 0 translation base 31 14 13 2 1 0 00 table index translation base modified virtual address translation table base 31 20 19 0 table index page index level one descriptor physical address 31 0 fine page table base address domain 11 21 3 4 5 8 9 11 level 2 table index 10 9 31 0 page index page base address level two descriptor 31 0 fine page table base address l2 table index 0 21 31 0 page base address 1 0 ap 1 1 cb 1 2 3 4 5 6 9 10 12 11 12 9 10
memory management unit 3-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c page translation involves one additional step beyond that of a section translation. the level one descriptor is the fine page table descriptor and this is used to point to the level one descriptor. note the domain specified in the level one description and access permissions specified in the level one description together determine whether the access has permissions to proceed. see section domain access control on page 3-23 for details. 3.3.12 subpages you can define access permissions for subpages of small and large pages. if, during a page walk, a small or large page has a non-identical subpage permission, only the subpage being accessed is written into the tlb. for example, a 16kb (large page) subpage entry is written into the tlb if the subpage permission differs, and a 64kb entry is put in the tlb if the subpage permissions are identical. when you use subpage permissions, and the page entry then has to be invalidated, you must invalidate all four subpages separately.
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-21 3.4 mmu faults and cpu aborts the mmu generates an abort on the following types of faults: alignment faults (data accesses only) translation faults domain faults permission faults. in addition, an external abort can be raised by the external system. this can happen only for access types that have the core synchronized to the external system: noncachable loads nonbufferable writes. alignment fault checking is enabled by the a bit in cp15 register 1. alignment fault checking is not affected by whether or not the mmu is enabled. translation, domain, and permission faults are only generated when the mmu is enabled. the access control mechanisms of the mmu detect the conditions that produce these faults. if a fault is detected as a result of a memory access, the mmu aborts the access and signals the fault condition to the cpu core. the mmu retains status and address information about faults generated by the data accesses in the fault status register and fault address register (see fault address and fault status registers on page 3-22). the mmu does not retain status about faults generated by instruction fetches. an access violation for a given memory access inhibits any corresponding external access, with an abort returned to the cpu core.
memory management unit 3-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.5 fault address and fault status registers on a data abort, the mmu places an encoded 4-bit value, fs[3:0], along with the 4-bit encoded domain number, in the data fsr. similarly, on a prefetch abort, in the prefetch fsr, intended for debug purposes only. in addition, the mva associated with the data abort is latched into the far. if an access violation simultaneously generates more than one source of abort, they are encoded in the priority given in table 3-9. the far is not updated by faults caused by instruction prefetches. 3.5.1 fault status table 3-9 describes the various access permissions and controls supported by the data mmu and details how these are interpreted to generate faults. note for data fsr only, alignment faults can write either b0001 or b0011 into fs[3:0]. invalid values in domains 3:0 can occur because the fault is raised before a valid domain field has been read from a page table descriptor. any abort masked by the priority encoding can be regenerated by fixing the primary abort and restarting the instruction. for instruction fsr only, the same priority applies as for the data fsr, except that alignment faults cannot occur, and external aborts apply only to noncachable reads. table 3-9 priority encoding of fault status priority source size status domain far highest alignment - b00x1 invalid mva of access causing abort translation section page b0101 b0111 invalid valid mva of access causing abort domain section page b1001 b1011 valid valid mva of access causing abort permission section page b1101 b1111 valid valid mva of access causing abort lowest external abort on noncachable nonbufferable access or noncachable bufferable read section page b1000 b1010 valid valid mva of access causing abort
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-23 3.6 domain access control mmu accesses are primarily controlled through the use of domains. there are 16 domains and each has a 2-bit field to define access to it. two types of user are supported, clients and managers. the domains are defined in the domain access control register. figure 3-13 shows how the 32 bits of the register are allocated to define the 16 2-bit domains. figure 3-13 domain access control register format table 3-10 defines how the bits within each domain are interpreted to specify the access permissions. 313029282726252423222120191817161514131211109876543210 1514131211109876543210 table 3-10 interpreting access control bits in domain access control register value meaning description 00 no access any access generates a domain fault 01 client accesses are checked against the access permission bits in the section or page descriptor 10 reserved reserved. currently behaves like the no access mode 11 manager accesses are not checked against the access permission bits so a permission fault cannot be generated
memory management unit 3-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c table 3-11 shows how to interpret the access permission (ap) bits and how their interpretation is dependent on the s and r bits (control register bits 8 and 9). table 3-11 interpreting access permission (ap) bits ap s r supervisor permissions user permissions description 00 0 0 no access no access any access generates a permission fault 00 1 0 read-only no access only supervisor read permitted 00 0 1 read-only read-only any write generates a permission fault 00 1 1 reserved - - 01 x x read/write no access access allowed only in supervisor mode 10 x x read/write read-only writes in user mode cause permission fault 11 x x read/write read/write all access types permitted in both modes xx 1 1 reserved - -
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-25 3.7 fault checking sequence the sequence the mmu uses to check for access faults is different for sections and pages. the sequence for both types of access is shown in figure 3-14. figure 3-14 sequence for checking faults modified virtual address check address alignment misaligned alignment fault get level one descriptor invalid section translation fault section page get page table entry check domain status section page invalid page translation fault no access (00) reserved (10) page domain fault section domain fault no access (00) reserved (10) client (01) client (01) manager (11) check access permissions check access permissions physical address violation page permission fault violation section permission fault
memory management unit 3-26 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the conditions that generate each of the faults are described in: alignment fault on page 3-26 translation fault on page 3-26 domain fault on page 3-26 permission fault on page 3-27. 3.7.1 alignment fault if alignment fault is enabled (a bit in cp15 register 1 set), the mmu generates an alignment fault on any data word access, if the address is not word-aligned, or on any halfword access, if the address is not halfword-aligned, irrespective of whether the mmu is enabled or not. an alignment fault is not generated on any instruction fetch, nor on any byte access. note if the access generates an alignment fault, the access sequence aborts without reference to more permission checks. 3.7.2 translation fault there are two types of translation fault: section a section translation fault is generated if the level one descriptor is marked as invalid. this happens if bits [1:0] of the descriptor are both 0. page a page translation fault is generated if the level one descriptor is marked as invalid. this happens if bits [1:0] of the descriptor are both 0. 3.7.3 domain fault there are two types of domain fault: section the level one descriptor holds the 4-bit domain field, which selects one of the 16 2-bit domains in the domain access control register. the two bits of the specified domain are then checked for access permissions as described in table 3-11 on page 3-24. the domain is checked when the level one descriptor is returned. page the level one descriptor holds the 4-bit domain field, which selects one of the 16 2-bit domains in the domain access control register. the two bits of the specified domain are then checked for access permissions as described in table 3-11 on page 3-24. the domain is checked when the level one descriptor is returned.
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-27 if the specified access is either no access (00) or reserved (10) then either a section domain fault or page domain fault occurs. 3.7.4 permission fault if the 2-bit domain field returns 01 (client) then access permissions are checked as follows: section if the level one descriptor defines a section-mapped access, the ap bits of the descriptor define whether or not the access is allowed, according to table 3-11 on page 3-24. their interpretation is dependent on the setting of the s and r bits (control register bits 8 and 9). if the access is not allowed, a section permission fault is generated. large page or small page if the level one descriptor defines a page-mapped access and the level two descriptor is for a large or small page, four access permission fields (ap3-ap0) are specified, each corresponding to one quarter of the page. for small pages ap3 is selected by the top 1kb of the page and ap0 is selected by the bottom 1kb of the page. for large pages, ap3 is selected by the top 16kb of the page and ap0 is selected by the bottom 16kb of the page. the selected ap bits are then interpreted in exactly the same way as for a section (see table 3-11 on page 3-24). the only difference is that the fault generated is a page permission fault. tiny page if the level one descriptor defines a page-mapped access and the level two descriptor is for a tiny page, the ap bits of the level one descriptor define whether or not the access is allowed in the same way as for a section. the fault generated is a page permission fault.
memory management unit 3-28 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3.8 external aborts in addition to the mmu-generated aborts, the arm920t can be externally aborted by the amba bus. this can be used to flag an error on an external memory access. however, not all accesses can be aborted in this way and the bus interface unit (biu) ignores external aborts that cannot be handled. the following accesses can be aborted: noncached reads unbuffered writes read-lock-write sequence, to noncachable memory. in the case of a read-lock-write ( swp ) sequence, if the read aborts the write is always attempted.
memory management unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 3-29 3.9 interaction of the mmu and caches the mmu is enabled and disabled using bit 0 of the cp15 control register as described in: enabling the mmu on page 3-29 disabling the mmu on page 3-29. 3.9.1 enabling the mmu to enable the mmu: 1. program the ttb and domain access control registers. 2. program level 1 and level 2 page tables as required. 3. enable the mmu by setting bit 0 in the control register. you must take care if the translated address differs from the untranslated address because several instructions following the enabling of the mmu might have been prefetched with the mmu off (using physical = va - flat translation). in this case, enabling the mmu can be considered as a branch with delayed execution. a similar situation occurs when the mmu is disabled. consider the following code sequence: mrc p15,0,r1,c1,c0,0 ; read control register orr r1, #0x1 mcr p15,0,r1,c1,c0,0 ; enable mmus fetch flat fetch flat fetch translated you can enable the icache and dcache simultaneously with the mmu using a single mcr instruction. 3.9.2 disabling the mmu to disable the mmu, clear bit 0 in the control register. the data cache must be disabled prior to, or at the same time as, the mmu is disabled by clearing bit 2 of the control register. see enabling the mmu regarding prefetch effects. note if the mmu is enabled, then disabled and subsequently re-enabled, the contents of the tlbs are preserved. if these are now invalid, you must invalidate the tlbs before re-enabling the mmu. see register 8, tlb operations register on page 2-19.
memory management unit 3-30 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-1 chapter 4 caches, write buffer, and physical address tag (pa tag) ram this chapter describes the instruction cache (icache), data cache (dcache), write buffer, and physical address (pa) tag ram. it contains the following sections: about the caches and write buffer on page 4-2 icache on page 4-4 dcache and write buffer on page 4-9 cache coherence on page 4-17 cache cleaning when lockdown is in use on page 4-20 implementation notes on page 4-21 physical address tag ram on page 4-22 drain write buffer on page 4-23 wait for interrupt on page 4-24.
caches, write buffer, and physical address tag (pa tag) ram 4-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.1 about the caches and write buffer the arm920t level-one memory system includes an instruction cache (icache), a data cache (dcache), a write buffer, and a physical address (pa) tag ram to reduce the effect of main memory bandwidth and latency on performance. the arm920t processor implements separate 16kb instruction and 16kb data caches (icache and dcache). the caches have the following features: virtually-addressed 64-way associative cache. 8 words per line (32 bytes per line) with one valid bit and two dirty bits per line, allowing half-line write-backs. write-through and write-back cache operation (write-back caches are also known as copy-back caches), selected per memory region by the c and b bits in the mmu translation tables (for data cache only). pseudo-random or round-robin replacement, selectable using the rr bit in cp15 register 1. low-power cam-ram implementation. caches independently lockable with granularity of 1 / 64 th of cache, which is 64 words (256 bytes). to avoid a tlb miss during write-back data eviction, and to reduce interrupt latency, the physical address corresponding to each data cache entry is stored in the pa tag ram for use during cache line write-backs, in addition to the va tag stored in the cache cams. this means that the mmu is not involved in cache write-back operations, removing the possibility of tlb misses related to the write-back address. cache maintenance operations to provide efficient cleaning of the entire data cache, and to provide efficient cleaning and invalidation of small regions of virtual memory. the latter allows icache coherency to be efficiently maintained when small code changes occur, for example self-modifying code and changes to exception vectors.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-3 the write buffer: has a 16-word data buffer has a 4-address address buffer can be drained under software control, using a cp15 mcr instruction (see drain write buffer on page 4-23). the arm920t can be drained under software control and put into a low-power state until an interrupt occurs, using a cp15 mcr instruction (see wait for interrupt on page 4-24).
caches, write buffer, and physical address tag (pa tag) ram 4-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.2 icache the arm920t includes a 16kb icache. the icache has 512 lines of 32 bytes (8 words), arranged as a 64-way set-associative cache and uses mvas, translated by cp15 register 13 (see address translation on page 3-6), from the arm9tdmi core. the icache implements allocate-on-read-miss. random or round-robin replacement can be selected under software control using the rr bit (cp15 register 1, bit 14). random replacement is selected at reset. instructions can also be locked in the icache so that they cannot be overwritten by a linefill. this operates with a granularity of 1 / 64 th of the cache, which is 64 words (256 bytes). all instruction accesses are subject to mmu permission and translation checks. instruction fetches that are aborted by the mmu do not cause linefills or instruction fetches to appear on the amba asb interface. note for clarity, the i bit (bit 12 in cp15 register 1) is called the icr bit throughout the following text. the c bit from the mmu translation table descriptor corresponding to the address being accessed is called the ctt bit . 4.2.1 icache organization the icache is organized as eight segments, each containing 64 lines, and each line containing eight words. the position of the line within the segment is a number from 0 to 63. this is called the index . a line in the cache can be uniquely identified by its segment and index. the index is independent of the mva. the segment is selected by bits [7:5] of the mva. bits [4:2] of the mva specify the word within a cache line that is accessed. for halfword operations, bit [1] of the mva specifies the halfword that is accessed within the word. for byte operations, bits [1:0] specify the byte within the word that is accessed. bits [31:8] of the mva of each cache line are called the tag. the mva tag is stored in the cache, along with the 8-words of data, when the line is loaded by a linefill. cache lookups compare bits [31:8] of the mva of the access with the stored tag to determine whether the access is a hit or miss. the cache is therefore said to be virtually addressed. the logical model of the 16kb icache is shown in figure 4-1 on page 4-5.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-5 figure 4-1 addressing the 16kb icache 31 tag 87 54 210 word byte seg tag w0 w7 cam ram decoder 07 32 rdata[31:0] cache line/index seg 0 select 2kb ram = 64 line s x 8 words 63 0 seg 0 7 6 5 4 3 2 1 modified virtual address 7 0
caches, write buffer, and physical address tag (pa tag) ram 4-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.2.2 enabling and disabling the icache on reset, the icache entries are all invalidated and the icache is disabled. you can enable the icache by writing 1 to the icr bit, and disable it by writing 0 to the icr bit. when the icache is disabled, the cache contents are ignored and all instruction fetches appear on the amba asb interface as separate nonsequential accesses. the icache is usually used with the mmu enabled. in this case the ctt in the relevant mmu translation table descriptor indicates whether an area of memory is cachable. if the cache is disabled after having been enabled, all cache contents are ignored. all instruction fetches appear on the amba asb interface as separate nonsequential accesses and the cache is not updated. if the cache is subsequently re-enabled its contents are unchanged. if the contents are no longer coherent with main memory, you must invalidate the icache before you re-enable it (see register 7, cache operations register on page 2-17). if the cache is enabled with the mmu disabled, all instruction fetches are treated as cachable. no protection checks are made, and the physical address is flat-mapped to the modified virtual address. you can enable the mmu and icache simultaneously by writing a 1 to the m bit, and a 1 to the icr bit in cp15 register 1, with a single mcr instruction. note arm920t implements a nonsequential access on the amba asb interface as an a-tran cycle followed by an s-tran cycle. it does not produce n-tran cycles. a linefill appears as an a-tran cycle followed by an s-tran cycle. 4.2.3 icache operation if the icache is disabled, each instruction fetch results in a separate nonsequential memory access on the amba asb interface, giving very low bus and memory performance. therefore, you must enable the icache as soon as possible after reset. if the icache is enabled, an icache lookup is performed for each instruction fetch regardless of the setting of the ctt bit in the relevant mmu translation table descriptor: if the required instruction is found in the cache, the lookup is called a cache hit. if the instruction fetch is a cache hit and ctt=1, indicating a cachable region of memory, then the instruction is returned from the cache to the arm9tdmi cpu core.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-7 if the required instruction is not found in the cache, the lookup is called a cache miss. if it is a cache miss and ctt=1, then an eight-word linefill is performed, possibly replacing another entry. the entry to be replaced, called the victim, is chosen from the entries that are not locked, using either a random or round-robin replacement policy.if ctt=0, indicating a noncachable region of memory, then a single nonsequential memory access appears on the amba asb interface. note if ctt=0, indicating a noncachable region of memory, then the cache lookup results in a cache miss. the only way that it can result in a cache hit is if software has changed the value of the ctt bit in the mmu translation table descriptor without invalidating the cache contents. this is a programming error. the behavior in this case is architecturally unpredictable and varies between implementations. 4.2.4 icache replacement algorithm the icache and dcache replacement algorithm is selected by the rr bit in the cp15 control register (cp15 register 1, bit 14). random replacement is selected at reset. setting the rr bit to 1 selects round-robin replacement. round-robin replacement means that entries are replaced sequentially in each cache segment. 4.2.5 icache lockdown you can lock instructions into the icache, causing the icache to guarantee a hit, and provide optimum and predictable execution time. if you enable the icache, an icache lookup is performed for each instruction fetch. if the icache misses and the ctt=1 then an eight-word linefill is performed. the entry to be replaced is selected by the victim pointer. you can lock instructions into the icache by controlling the victim pointer, and forcing prefetches to the icache. you lock instructions in the icache by first ensuring the code to be locked is not already in the cache. you can ensure this by invalidating either the whole icache or specific lines: mcr p15, 0, rd, c7, c5, 0 ; invalidate icache mcr p15, 0, rd, c7, c5, 1 ; invalidate icache line using mva you can then use a short software routine to load the instructions into the icache. the software routine must either be noncachable, or already in the icache but not in an icache line about to be overwritten. you must enable the mmu to ensure that any tlb misses that occur while loading the instructions cause a page table walk. the software routine operates by writing to cp15 register 9 to force the victim pointer to a specific icache line and by using the prefetch icache line operation to force the icache to perform a lookup. this misses, assuming the code has been invalidated, and an 8-word linefill is performed loading the cache line into the entry specified by the victim pointer.
caches, write buffer, and physical address tag (pa tag) ram 4-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c when all the instructions have been loaded, they are then locked by writing to cp15 register 9 to set the victim pointer base to be one higher than the last entry written. all further linefills now occur in the range victim base to 63.an example icache lockdown routine is shown in example 4-1. the example assumes that the number of cache lines to be loaded is not known. the address does not have to be cache line or word-aligned but this is recommended to ensure future compatibility. note the prefetch icache line operation uses mva format, because address aliasing is not performed on the address in rd. it is advisable for the associated tlb entry to be locked into the tlb to avoid page table walks during execution of the locked code. example 4-1 icache lockdown routine adrl r0,start_address ; address pointer adrl r1,end_address mov r2,#lockdown_base<<26 ; victim pointer mcr p15,0,r2,c9,c0,1 ; write icache victim and lockdown base loop mcr p15,0,r0,c7,c13,1 ; prefetch icache line add r0,r0,#32 ; increment address pointer to next icache line ;; do we need to increment the victim pointer? ;; test for segment 0, and if so, increment the victim pointer ;; and write the icache victim and lockdown base. andr3,r0,#0xe0 ; extract the segment bits from the address cmp r3,#0x0 ; test for segment 0 addeq r2,r2,#0x1<<26 ; if segment 0, increment victim pointer mcreq p15,0,r2,c9,c0,1 ; and write icache victim and lockdown base ;; have we linefilled enough code? ;; test for the address pointer being less than or equal to the ;; end_address and if so, loop and perform another linefill cmp r0,r1 ; test for less than or equal to end_address ble loop ; if not, loop ;; have we exited with r3 pointing to segment 0? ;; if so, the icache victim and lockdown base has already been set to one ;; higher than the last entry written. ;; if not, increment the victim pointer and write the icache victim and ;; lockdown base. cmp r3,#0x0 ; test for segments 1 to 7 addne r2,r2,#0x1<<26 ; if address is segment 1 to 7, mcrne p15,0,r2,c9,c0,1 ; write icache victim and lockdown base
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-9 4.3 dcache and write buffer the arm920t processor includes a 16kb dcache and a write buffer to reduce the effect of main memory bandwidth and latency on data access performance. the dcache has 512 lines of 32 bytes (8-words), arranged as a 64-way set-associative cache and uses mvas translated by cp15 register 13 (see address translation on page 3-6) from the arm9tdmi cpu core. the write buffer can hold up to 16 words of data and four separate addresses. the operations of the dcache and the write buffer are closely connected. the dcache supports write-through and write-back memory regions, controlled by the c and b bits in each section and page descriptor within the mmu translation tables. for clarity, these bits are called ctt and btt in the following text. for details see dcache and write buffer operation on page 4-10. each dcache line has two dirty bits, one for the first four words of the line, the other for the last four words, and a single virtual tag address and valid bit for the entire 8-word line. the physical address from which each line is loaded is stored in the pa tag ram and is used when writing modified lines back to memory. when a store hits in the dcache, if the memory region is write-back, the associated dirty bit is set marking the appropriate half-line as being modified. if the cache line is replaced due to a linefill, or if the line is the target of a dcache clean operation, the dirty bits are used to decide whether the whole, half, or none of the line is written back to memory. the line is written back to the same physical address from which it was loaded, regardless of any changes to the mmu translation tables. the dcache implements allocate-on-read-miss. random or round-robin replacement can be selected under software control by the rr bit (cp15 register 1, bit 14). random replacement is selected at reset. a linefill always loads a complete 8-word line. data can also be locked in the dcache so that it cannot be overwritten by a linefill. this operates with a granularity of 1 / 64 th of the cache, which is 64 words (256 bytes). all data accesses are subject to mmu permission and translation checks. data accesses that are aborted by the mmu do not cause linefills or data accesses to appear on the amba asb interface. for clarity, the c bit (bit 2 in cp15 register 1) is called the ccr bit throughout the following text.
caches, write buffer, and physical address tag (pa tag) ram 4-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.3.1 enabling and disabling the dcache and write buffer on reset, the dcache entries are invalidated and the dcache is disabled, and the write buffer contents are discarded. there is no explicit write buffer enable bit implemented in arm920t. the write buffer is used in the following ways: you can enable the dcache by writing 1 to the ccr bit, and disable it by writing 0 to the ccr bit. you must only enable the dcache when the mmu is enabled. this is because the mmu translation tables define the cache and write buffer configuration for each memory region. if the dcache is disabled after having been enabled, the cache contents are ignored and all data accesses appear on the amba asb interface as separate nonsequential accesses and the cache is not updated. if the cache is subsequently re-enabled its contents are unchanged. depending on the software system design, you might have to clean the cache after it is disabled, and invalidate it before you re-enable it. see cache coherence on page 4-17. you can enable or disable the mmu and dcache simultaneously with a single mcr that changes the m bit and the c bit in the control register (cp15 register 1). 4.3.2 dcache and write buffer operation the dcache and write buffer configuration of each memory region is controlled by the ctt and btt bits in each section and page descriptor in the mmu translation tables. you can modify the configuration using the dcache enable bit in the cp15 control register. this is called ccr. if the dcache is enabled, a dcache lookup is performed for each data access initiated by the arm9tdmi cpu core, regardless of the value of the ctt bit in the relevant mmu translation table descriptor. if the required data is found, the lookup is called a cache hit . if the required data is not found, the lookup is called a cache miss . in this context a data access means any type of load (read), store (write), or swap instruction, including ldr , ldrb , ldrh , ldm , ldc , str , strb , strh , stc , swp , and swpb . accesses appear on the amba asb interface in program order but the arm9tdmi cpu core can continue executing at full speed, reading instructions and data from the caches, and writing to the dcache and write buffer, while buffered writes are being written to memory through the amba asb interface.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-11 table 4-1 describes the dcache and write buffer behavior for each type of memory configuration. ctt and ccr means the bitwise boolean and of ctt with ccr. table 4-1 dcache and write buffer configuration ctt and ccr btt dcache, write buffer, and memory access behavior 0 a 0 noncached, nonbuffered (ncnb). reads and writes are not cached. they always perform accesses on the amba asb interface. writes are not buffered. the cpu halts until the write is completed on the amba asb interface. reads and writes can be externally aborted. cache hits never occur under normal operation. b 0 1 noncached, buffered (ncb). reads and writes are not cached, and always perform accesses on the amba asb interface. writes are placed in the write buffer and appear on the amba asb interface. the cpu continues execution as soon as the write is placed in the write buffer. reads can be externally aborted. writes cannot be externally aborted.cache hits never occur under normal operation. b 1 0 cached write-through mode (wt). reads that hit in the cache read the data from the cache and do not perform an access on the amba asb interface. reads that miss in the cache cause a linefill. writes that hit in the cache update the cache. all writes are placed in the write buffer and appear on the amba asb interface. the cpu continues execution as soon as the write is placed in the write buffer. reads and writes cannot be externally aborted.
caches, write buffer, and physical address tag (pa tag) ram 4-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c a linefill performs an 8-word burst read from the amba asb interface and places it as a new entry in the cache, possibly replacing another line at the same location within the cache. the location that is replaced, called the victim, is chosen from the entries that are not locked using either a random or round-robin replacement policy. if the cache line being replaced is marked as dirty, indicating that it has been modified and that main memory has not been updated to reflect the change, a cache writeback occurs. depending on whether one or both halves of the cache line are dirty, the write-back performs a 4 or 8-word sequential burst write access on the amba asb interface. the write-back data is placed in the write buffer, and then the linefill data is read from the amba asb interface. the cpu can then continue while the write-back data is written to memory over the amba asb interface. load multiple ( ldm ) instructions accessing ncnb or ncb regions perform sequential bursts on the amba asb interface. store multiple ( stm ) instructions accessing ncnb regions also perform sequential bursts on the amba asb interface. 1 1 cached write-back mode (wb). reads that hit in the cache read the data from the cache and do not perform an amba asb interface access. reads that miss in the cache cause a linefill. writes that hit in the cache update the cache and mark the appropriate half of the cache line as dirty, and do not cause an amba asb interface access. writes that miss in the cache are placed in the write buffer and appear on the amba asb interface. the cpu continues execution as soon as the write is placed in the write buffer. cache write-backs are buffered. reads, writes, and write-backs cannot be externally aborted. a. if the control register c bit (ccr) is zero, it disables all lookups in the cache, while if the translation table descriptor c bit (ctt) is zero, it only stops new data being loaded into the cache. with ccr = 1 and ctt = 0 the cache is still searched on every access to check whether the cache contains an entry for the data. b. it is an operating system software error if a cache hit occurs when reading from, or writing to, a region of memory marked as ncnb or ncb. the only way this can occur is if the operating system changes the value of the c and b bits in a page table descriptor, while the cache contains data from the area of virtual memory controlled by that descriptor. the cache and memory system behavior resulting from changing the page table descriptor in this way is unpredictable. if the operating system has to change the c and b bits of a page table descriptor, it must ensure that the caches do not contain any data controlled by that descriptor. in some circumstances, the operating system might have to clean and flush the caches to ensure this. table 4-1 dcache and write buffer configuration (continued) ctt and ccr btt dcache, write buffer, and memory access behavior
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-13 the sequential burst is split into two bursts if it crosses a 1kb boundary. this is because the smallest mmu protection and mapping size is 1kb, so the memory regions on each side of the 1kb boundary can have different properties. this means that sequential accesses generated by arm920t do not cross a 1kb boundary. this can be exploited to simplify memory interface design. for example, a simple page-mode dram controller can perform a page-mode access for each sequential access, provided the dram page size is 1kb or larger. see also cache coherence on page 4-17. 4.3.3 dcache organization the dcache is organized as eight segments, each containing 64 lines, and each line containing eight words. the position of the line within the segment is a number from 0 to 63. this is called the index. a line in the cache can be uniquely identified by its segment and index. the index is independent of the mva. the segment is selected by bits [7:5] of the mva. bits [4:2] of the mva specify which word within a cache line is accessed. for halfword operations, bit [1] of the mva specifies which halfword is accessed within the word. for byte operations, bits [1:0] specify which byte within the word is accessed. bits [31:8] of the mva of each cache line are called the tag. the mva tag is stored in the cache, along with the eight words of data, when the line is loaded by a linefill. cache lookups compare bits [31:8] of the mva of the access with the stored tag to determine whether the access is a hit or miss. the cache is therefore said to be virtually addressed. the dcache logical model is the same as for the icache. see addressing the 16kb icache on page 4-5. 4.3.4 dcache replacement algorithm the dcache and icache replacement algorithm is selected by the rr bit in the cp15 control register (cp15 register 1, bit 14). random replacement is selected at reset. setting the rr bit to 1 selects round-robin replacement. round-robin replacement means that entries are replaced sequentially in each segment.
caches, write buffer, and physical address tag (pa tag) ram 4-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.3.5 swap instructions swap instruction ( swp or swpb ) behavior is dependent on whether the memory region is cachable or noncachable. swap instructions to cachable regions of memory are useful for implementing semaphores or other synchronization primitives in multithreaded uniprocessor software systems. swap instructions to noncachable memory regions are useful for synchronization between two bus masters in a multi-master bus system. this can be two processors, or one processor and a dma controller. when a swap instruction accesses a cachable region of memory (write-through or write-back), the dcache and write buffer behavior is the same as having a load followed by a store according to the normal rules described. the blok pin is not asserted during the execution of the instruction. it is guaranteed that no interrupt can occur between the load and store portions of the swap. when a swap instruction accesses a noncachable (ncb or ncnb) region of memory, the write buffer is drained, and a single word or byte is read from the amba asb interface. the write portion of the swap is then treated as nonbufferable, regardless of the value of btt, and the processor is stalled until the write is completed on the amba asb interface. the blok pin is asserted to indicate that you can treat the read and write as an atomic operation on the bus. like all other data accesses, a swap to a noncachable region that hits in the cache indicates a programming error. 4.3.6 dcache lockdown you can lock data into the dcache, causing the dcache to guarantee a hit, and provide optimum and predictable execution time. if you enable the dcache, a dcache lookup is performed for each load. if the dcache misses and the ctt=1 then an eight-word linefill is performed. the entry to be replaced is selected by the victim pointer. you can lock data into the dcache by controlling the victim pointer, and forcing loads to the dcache. you lock data in the dcache by first ensuring the data to be locked is not already in the cache. you can ensure this by cleaning and invalidating either the whole dcache or specific lines. example 4-2 on page 4-15 shows dcache invalidate and clean operations that you can perform to do this.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-15 example 4-2 dcache invalidate and clean operations mcr p15, 0, rd, c7, c6, 0 ; invalidate dcache mcr p15, 0, rd, c7, c6, 1 ; invalidate dcache single entry using mva mcr p15, 0, rd, c7, c10, 1 ; clean dcache single entry using mva mcr p15, 0, rd, c7, c14, 1 ; clean and invalidate dcache single entry using mva mcr p15, 0, rd, c7, c10, 2 ; clean dcache single entry using index mcr p15, 0, rd, c7, c14, 2 ; clean and invalidate dcache single entry using index you can then use a short software routine to load the data into the dcache. you can locate the software routine in a cachable region of memory providing it does not contain any loads or stores. you must enable the mmu.the software routine operates by writing to cp15 register 9 to force the victim pointer to a specific dcache line and by using an ldr or ldm to force the dcache to perform a lookup. this misses, assuming the data was previously invalidated, and an eight-word linefill is performed loading the cache line into the entry specified by the victim pointer. when all the data has been loaded, it is then locked by writing to cp15 register 9 to set the victim pointer base to be one higher than the last entry written. all further linefills now occur in the range victim base to 63.an example dcache lockdown routine is shown in example 4-3 on page 4-16. the example assumes that the number of cache lines to be loaded is not known. the address does not have to be cache line or word-aligned, although it is preferable for future compatibility. note the ldr or ldm uses va format, because address aliasing is performed on the address.it is advisable for the associated tlb entry to be locked into the tlb to avoid page table walks during accesses of the locked data.
caches, write buffer, and physical address tag (pa tag) ram 4-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c example 4-3 dcache lockdown routine adrl r0,start_address ; address pointer adrl r1,end_address mov r2,#lockdown_base<<26 ; victim pointer mcr p15,0,r2,c9,c0,0 ; write dcache victim and lockdown base loop ldr r3,[r0],#32 ; load dcache line, increment to next dcache line ;; do we need to increment the victim pointer? ;; test for segment 0, and if so, increment the victim pointer and ;; write the icache victim and lockdown base. andr3,r0,#0xe0 ; extract the segment bits from the address cmp r3,#0x0 ; test for segment 0 addeq r2,r2,#0x1<<26 ; if segment 0, increment victim pointer mcreq p15,0,r2,c9,c0,0 ; and write dcache victim and lockdown base ;; have we linefilled enough code? ;; test for the address pointer being less than or equal to the end_address ;; and if so, loop and perform another linefill cmp r0,r1 ; test for less than or equal to end_address, ble loop ; if not, loop ;; have we exited with r3 pointing to segment 0? ;; if so, the icache victim and lockdown base has already been set to one ;; higher than the last entry written. ;; if not, increment the victim pointer and write the icache victim and ;; lockdown base. cmp r3,#0x0 ; test for segments 1 to 7 addne r2,r2,#0x1<<26 ; if address is segment 1 to 7, mcrne p15,0,r2,c9,c0,0 ; write dcache victim and lockdown base
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-17 4.4 cache coherence the icache and dcache contain copies of information normally held in main memory. if these copies of memory information get out of step with each other because one is updated and the other is not updated, they are said to have become incoherent. if the dcache contains a line that has been modified by a store or swap instruction, and the main memory has not been updated, the cache line is said to be dirty. clean operations force the cache to write dirty lines back to main memory. the icache then has to be made coherent with a changed area of memory after any changes to the instructions that appear at an mva, and before the new instructions are executed. on the arm920t, software is responsible for maintaining coherence between main memory, the icache, and the dcache. register 7, cache operations register on page 2-17 describes facilities for invalidating the entire icache or individual icache lines, and for cleaning and/or invalidating dcache lines, or for invalidating the entire dcache. to clean the entire dcache efficiently, software must loop through each cache entry using the clean d single entry (using index) operation or the clean and invalidate d entry (using index) operation. you must perform this using a two-level nested loop going though each index value for each segment. see dcache organization on page 4-13. example 4-4 shows an example loop for two alternative dcache cleaning operations. example 4-4 dcache cleaning loop for seg = 0 to 7 for index = 0 to 63 rd = {seg,index} mcr p15,0,rd,c7,c10,2 ; clean dcache single ; entry (using index) or mcr p15,0,rd,c7,c14,2 ; clean and invalidate ; dcache single entry ; (using index) next index next seg
caches, write buffer, and physical address tag (pa tag) ram 4-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c dcache, icache, and memory coherence is generally achieved by: cleaning the dcache to ensure memory is up to date with all changes invalidating the icache to ensure that the icache is forced to re-fetch instructions from memory. software can minimize the performance penalties of cleaning and invalidating caches by: cleaning only small portions of the dcache when only a small area of memory has to be made coherent, for example, when updating an exception vector entry. use clean dcache single entry (using mva) or clean and invalidate dcache single entry (using mva) . invalidating only small portions of the icache when only a small number of instructions are modified, for example, when updating an exception vector entry. use invalidate icache single entry (using mva) . not invalidating the icache in situations where it is known that the modified area of memory cannot be in the cache, for example, when mapping a new page into the currently running process. situations that necessitate cache cleaning and invalidating include: writing instructions to a cachable area of memory using str or stm instructions, for example: ? self-modifying code ? jit compilation ? copying code from another location ? downloading code using the embeddedice jtag debug features ? updating an exception vector entry. another bus master, such as a dma controller, modifying a cachable area main memory. turning the mmu on or off. changing the virtual-to-physical mappings, or ctt, or btt, or protection information, in the mmu page tables. the dcache must be cleaned, and both caches invalidated, before the cache and write buffer configuration of an area of memory is changed by modifying ctt or btt in the mmu translation table descriptor. this is not necessary if it is known that the caches cannot contain any entries from the area of memory whose translation table descriptor is being modified. turning the icache or dcache on, if its contents are no longer coherent.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-19 changing the fcse pid in cp15 register 13 does not change the contents of the cache or memory, and does not affect the mapping between cache entries and physical memory locations. it only changes the mapping between arm9tdmi addresses and cache entries. this means that changing the fcse pid does not lead to any coherency issues. no cache cleaning or cache invalidation is required when the fcse pid is changed. the software design must also consider that the pipelined design of the arm9tdmi core means that it fetches three instructions ahead of the current execution point. so, for example, the three instructions following an mcr that invalidates the icache, have already been read from the icache before it is invalidated.
caches, write buffer, and physical address tag (pa tag) ram 4-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.5 cache cleaning when lockdown is in use the clean dcache single entry (using index) and clean and invalidate dcache entry (using index) operations can leave the victim pointer set to the index value used by the operation. in some circumstances, if dcache locking is in use, this can leave the victim pointer in the locked region, leading to locked data being evicted from the cache. you can move the victim pointer outside the locked region by implementing the cache loop, enclosed by the reading and writing of the base and victim pointer: mrc p15, 0, rd, c9, c0, 0 ; read d cache base into rd index clean or index clean and invalidate loops mcr p15, 0, rd, c9, c0, 0 ; write d cache base and victim from rd clean dcache single entry (using mva) and clean and invalidate dcache entry (using mva) operations do not move the victim pointer, so you do not have to reposition the victim pointer after using these operations.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-21 4.6 implementation notes this section describes the behavior of the arm920t implementation in areas that are architecturally unpredictable. for portability to other arm implementations, software must not depend on this behavior. a read from a noncachable (ncb or ncnb) region that unexpectedly hits in the cache still reads the required data from the amba asb interface. the contents of the cache are ignored, and the cache contents are not modified. this includes the read portion of a swap ( swp or swpb ) instruction. a write to a noncachable (ncb or ncnb) region that unexpectedly hits in the cache updates the cache and still causes an access on the amba asb interface. this includes the write portion of a swap instruction. there are two test interfaces to both the dcache and icache: debug interface amba test interface.
caches, write buffer, and physical address tag (pa tag) ram 4-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.7 physical address tag ram the arm920t implements a physical address (pa) tag ram in order to perform write-backs from the dcache. a write-back occurs when dirty data, that is about to be overwritten by linefill data, comes from a memory region that is marked as a write-back region. this data is written back to main memory to maintain memory coherency. note dirty data is data that has been modified in the cache, but not updated in main memory. when a line is written into the data cache, the pa tag is written into the pa tag ram. if this line has to be written back to main memory, the pa tag ram is read and the physical address is used by the amba asb interface to perform the write-back. the pa tag ram array for a 16kb dcache comprises eight segments x 64 rows per segment x 26 bits per row. there are two test interfaces to the pa tag ram: debug interface, see scan chain 4 - debug access to the pa tag ram on page 9-39 amba test interface, see pa tag ram test on page 11-12.
caches, write buffer, and physical address tag (pa tag) arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 4-23 4.8 drain write buffer you can drain the write buffer under software control, so that further instructions are not executed until the write buffer is drained, using the following methods: store to nonbufferable memory load from noncachable memory mcr drain write buffer: mcr p15,0,rd,c7,c10,4 the write buffer is also drained before performing the following less controllable activities, which you must consider as implementation-defined: fetch from noncachable memory dcache linefill icache linefill.
caches, write buffer, and physical address tag (pa tag) ram 4-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 4.9 wait for interrupt you can place the arm920t into a low power state by executing the cp15 mcr wait for interrupt: mcr p15,0,rd,c7,c0,4 execution of this mcr causes the write buffer to drain and the arm920t is put into a state where it will resume execution of code after either an interrupt or a debug request. when the interrupt occurs the mcr instruction completes and the fiq or irq handler is entered as normal. the return link in r14_fiq or r14_irq contains the address of the mcr instruction plus 8, so that the normal instruction used for interrupt return returns to the instruction following the mcr: subs pc,r14,#4
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 5-1 chapter 5 clock modes this chapter describes the different clocking modes available on the arm920t processor. it contains the following sections: about arm920t clocking on page 5-2 fastbus mode on page 5-3 synchronous mode on page 5-4 asynchronous mode on page 5-6.
clock modes 5-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 5.1 about arm920t clocking the arm920t processor has two functional clock inputs, bclk and fclk . internally, the arm920t is clocked by gclk . this can be seen on the cpclk output as shown in figure 5-1. gclk can be sourced from either bclk or fclk depending on the clocking mode, selected using nf bit and ia bit in cp15 register 1 (see register 1, control register on page 2-12), and external memory access. the three clocking modes are: fastbus mode on page 5-3 synchronous mode on page 5-4 asynchronous mode on page 5-6. the arm920t is a static design and you can stop both clocks indefinitely without loss of state. figure 5-1 shows that some of the arm920t macrocell signals have timing specified with relation to gclk . this can be either fclk or bclk depending on the clocking mode. figure 5-1 arm920t clocking nf ia , gclk cpclk arm920t i/o rest of arm920t amba bus interface asb bclk fclk
clock modes arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 5-3 5.2 fastbus mode in fastbus mode gclk is sourced from bclk . the fclk input is ignored. this means that bclk is used to control the amba asb interface and the internal arm920t processor core. on reset, the arm920t is put into fastbus mode and operates using bclk . a typical use for fastbus mode is to execute startup code while configuring a pll under software control to produce fclk at a higher frequency. when the pll has stabilized and locked, you can switch the arm920t to synchronous or asynchronous clocking using fclk for normal operation.
clock modes 5-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 5.3 synchronous mode in this mode of operation gclk is sourced from bclk or fclk . there are three restrictions that apply to bclk and fclk: fclk must have a higher frequency than bclk fclk must be an integer multiple of the bclk frequency fclk must be high whenever there is a bclk transition. bclk is used to control the amba asb interface, and fclk is used to control the internal arm920t processor core. when an external memory access is required the core either continues to clock using fclk or is switched to bclk , as shown in table 5-1. this is the same as for asynchronous mode. the penalty in switching from fclk to bclk and from bclk to fclk is symmetric, from zero to one phase of the clock to which the core is re-synchronizing. that is, switching from fclk to bclk has a penalty of between zero and one bclk phase, and switching back from bclk to fclk has a penalty of between zero and one fclk phase. figure 5-2 on page 5-5 shows an example zero bclk phase delay when switching from fclk to bclk in synchronous mode. table 5-1 clock selection for external memory accesses external memory access operation gclk = buffered write fclk nonbuffered write bclk page walk, cachable read (linefill), noncachable read bclk
clock modes arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 5-5 figure 5-2 synchronous mode fclk to bclk zero phase delay figure 5-3 shows an example one bclk phase delay when switching from fclk to bclk in synchronous mode. figure 5-3 synchronous mode fclk to bclk one phase delay bclk fclk fnb cpclk bclk fclk fnb cpclk
clock modes 5-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 5.4 asynchronous mode in this mode of operation gclk is sourced from bclk or fclk . fclk and bclk can be completely asynchronous to one another, with the one restriction that fclk must have a higher frequency than bclk . bclk is used to control the amba asb interface, and fclk is used to control the internal arm920t processor core. when an external memory access is required the core either continues to clock using fclk or is switched to bclk . this is the same as for synchronous mode.the penalty in switching from fclk to bclk and from bclk to fclk is symmetric, from zero to one cycle of the clock to which the core is re-synchronizing. that is, switching from fclk to bclk has a penalty of between zero and one bclk cycle, and switching back from bclk to fclk has a penalty of between zero and one fclk cycle. figure 5-4 shows an example zero bclk cycle delay when switching from fclk to bclk in asynchronous mode. figure 5-4 asynchronous mode fclk to bclk zero cycle delay figure 5-5 on page 5-7 shows an example one bclk cycle delay when switching from fclk to bclk in asynchronous mode. bclk fclk fnb cpclk
clock modes arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 5-7 figure 5-5 asynchronous mode fclk to bclk one cycle delay bclk fclk fnb cpclk
clock modes 5-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-1 chapter 6 bus interface unit this chapter describes the arm920t bus interface. it contains the following sections: about the arm920t bus interface on page 6-2 unidirectional amba asb interface on page 6-3 fully-compliant amba asb interface on page 6-5 amba ahb interface on page 6-21 level 2 cache support and performance analysis on page 6-23.
bus interface unit 6-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 6.1 about the arm920t bus interface the amba specification (rev 2.0) defines two high-performance system buses: the advanced high-performance bus (ahb) the advanced system bus (asb). the arm920t processor has been designed with a unidirectional asb interface, plus the necessary extra control signals to enable efficient implementation of both the ahb and asb interface. with no additional logic, you can use the unidirectional asb interface in single master systems where the arm920t is the master. with the addition of tristate drivers, the arm920t implements a full asb interface, either as an asb bus master, or as a slave for production test. with the addition of a synthesizable wrapper, the arm920t implements a full ahb interface, either as an ahb bus master, or as a slave for production test. the wrapper introduces no speed penalties, no performance penalties on reads, no performance penalties on buffered writes, and minimal performance penalty on nonbuffered writes. the mcr drain write buffer requires an additional instruction to operate in a predictable manner. see amba ahb interface on page 6-21 for details. in this section the following abbreviations are used: ncnb noncachable and nonbufferable ncb noncachable and bufferable nc noncachable wt cachable and write-through wb cachable and write-back.
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-3 6.2 unidirectional amba asb interface the amba specification (rev 2.0) defines the advanced microcontroller bus architecture (amba) asb interface for use with multiple masters. this requires that only the granted master controls and drives the bus system. the unidirectional amba asb interface on the arm920t supplies the constituent signals to make a bidirectional interface, that is input, output, and output enable. these signals are shown in table 6-1. table 6-1 relationship between bidirectional and unidirectional asb interface asb signal arm920t input arm920t output arm920t output enable agntx agnt -- areqx - areq - bclk bclk -- bnres bnres -- dselx dsel -- ba[31:12] - aout[31:12] enba ba[11:2] ain[11:2] aout[31:0] enba ba[1:0] - aout[1:0] enba blok - lok enba bprot[1:0] - prot[1:0] enba bsize[1:0] - size[1:0] enba bwrite writein writeout enba bd[31:0] din[31:0] dout[31:0] enbd btran[1:0] - tran[1:0] enbtran berror errorin errorout ensr blast lastin lastout ensr bwait waitin waitout ensr
bus interface unit 6-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c an asb bus cycle is defined from falling-edge to falling-edge transition of bclk . the low part is referred to as phase 1, the high part as phase 2. the timing is shown in table 6-2, and is for reference only. it is assumed that the arm920t macrocell is used in either an amba asb or amba ahb system. the timing for tran[1:0] is slightly different, so that if the arm920t loses the gnt signal, tran[1:0] is changed to indicate a-tran in the same phase 1. under these circumstances however, the arm920t does not drive btran[1:0] in the subsequent phase 2. table 6-2 arm920t input/output timing arm920t input timing arm920t output timing -- areq change phase 2 agnt setup to rising bclk -- dsel setup to falling bclk -- ain[11:2] setup to falling bclk aout[31:0] change phase 2 -- lok change phase 2 -- bprot[1:0] change phase 2 -- size[1:0] change phase 2 writein setup to falling bclk writeout change phase 2 din[31:0] setup to falling bclk dout[31:0] change phase 1 -- tran[1:0] change phase 2 (1) errorin setup to rising bclk errorout fixed to 0 lastin setup to rising bclk lastout fixed to 0 wa i t i n setup to rising bclk waitout change phase 1
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-5 6.3 fully-compliant amba asb interface amba specification (rev 2.0) , defines the amba asb interface for use with multiple masters. connecting the unidirectional arm920t signals as indicated in connecting the arm920t to an amba asb interface implements a fully-compliant interface, either as an asb bus master, or slave for production test. for details of how the amba asb interface operates, refer to the amba specification (rev 2.0) . 6.3.1 connecting the arm920t to an amba asb interface for bidirectional signals, ba[11:2] , bwrite , bd[31:0] , berror , bwait , and blast , the macrocell outputs must be tristate buffered, using the output enable specified in table 6-1 on page 6-3. the arm920t macrocell outputs are continuously driven and intended to drive the signals to the edge of the macrocell from where they can be buffered for additional routing and tristate behavior. the drive strength chosen for tristate drivers must be governed by the asb load. figure 6-1 shows the required output buffer for bidirectional signals. figure 6-1 output buffer for bidirectional signals for output signals, ba[31:12] , ba[1:0] , blok , bprot[1:0] , bsize[1:0] , and btran[1:0] , the macrocell outputs must be tristate buffered, using the output enable specified in table 6-1 on page 6-3. the drive strength chosen for tristate drivers must be governed by the asb load. figure 6-2 on page 6-6 shows the output buffer required for unidirectional signals. arm920t input arm920t output arm920t output enable asb signal
bus interface unit 6-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 6-2 output buffer for unidirectional signals you can connect the input signals, agntx , bclk , bnres , and dselx directly to the arm920t. the signals are appropriately buffered when the signal reaches the edge of the macrocell so additional buffering is not required. the output signal areq must be buffered with no tristate control, and is dependent on the load within the asb system. 6.3.2 transfer types the amba asb specification describes three transfer types that are encoded in btran[1:0] . table 6-3 shows these transfer types. the arm920t does not use n-tran cycles, instead it uses an a-tran cycle followed by a s-tran cycle for nonsequential transfers. this eases amba decoder design considerably, particularly for high-speed designs. arm920t output arm920t output enable asb signal table 6-3 amba asb transfer types btran[1:0] transfer type description 00 address-only (a-tran) used when no data movement is required. the three main uses for address-only transfers are: for idle cycles for bus handover cycles for speculative address decoding without committing to a data transfer. 01 - reserved. 10 nonsequential (n-tran) used for single transfers or the first transfer of a burst. the address of the transfer is unrelated to the previous bus access. 11 sequential (s-tran) used for successive transfers in burst. the address of a sequential transfer is always related to the previous transfer.
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-7 the output signals astb , burst[1:0] , and ncmahb have been added to the arm920t bus interface. they are necessary to support the amba ahb wrapper, but can also be used to provide optimized accesses in an amba asb system: astb this signal distinguishes between an idle cycle and the a-tran cycle of a nonsequential transfer. it is asserted with the same timing as aout[31:0] , changing in phase 2. usually a memory controller only commits to a transfer when it sees the s-tran cycle, perhaps only decoding the address during the a-tran cycle. astb is asserted in the preceding a-tran cycle, indicating that the current a-tran is followed by an s-tran, providing agnt is high on the next rising edge of bclk . burst[1:0] this signal gives an indication of the length of a sequential burst, as shown in table 6-4. for linefills, burst[1:0] indicates 8 words. for cache line evictions, burst[1:0] indicates either 4 or 8 words. for all other transfers, burst[1:0] indicates no burst or undefined burst length. the meaning of the burst[1:0] encoding is clarified when considered whether the transfer is a read or write. in this way you can distinguish between bufferable and nonbufferable str / stm and table walks, as shown in table 6-5 on page 6-8. table 6-4 burst transfers burst[1:0] transfer 00 no burst or undefined burst length 01 4-word burst 10 8-word burst 11 no burst or undefined burst length
bus interface unit 6-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the burst[1:0] signals change in phase 2 and are asserted in the phase when astb is asserted. burst[1:0] then remains unchanged until the next transfer. ncmahb this signal indicates for noncached load multiples whether more words are requested as part of the current burst transfer. when high this indicates more words are requested. when low, on the last s-tran of the burst, this indicates that the current transfer is the last word of the burst. it is asserted in phase 2 and is only valid if agnt remains asserted throughout the transfer. the following timing diagrams show the types of transfer that can be initiated by the arm920t rev1: instruction fetch after reset on page 6-11 example ldr from address 0x108 on page 6-12 example ldm of 5 words from 0x108 on page 6-13 example nonbuffered str on page 6-14 example nonbuffered stm on page 6-15 example linefill from 0x100 on page 6-16 example 4-word data eviction on page 6-17 example swap operation on page 6-19. table 6-5 use of writeout signal burst[1:0] writeout arm920t bus access type 00 read nc ldr / ldm /fetch noncachable read 00 write ncnb str / stm nonbufferable write 01 read - - 01 write write-back of 4 words bufferable write 10 read linefill of 8 words cachable read 10 write write-back of 8 words bufferable write 11 read table walk cachable read 11 write ncb/wt/wb miss str / stm bufferable write
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-9 where the areq and agnt signals and the responses from the asb slave are not shown in these diagrams, it is assumed that agnt is asserted and the asb slave response is done. different slave responses and bus master handover are covered in the amba specification (rev 2.0) . it is assumed that you are using the arm920t macrocell within a multi-master asb system, so unidirectional asb timing diagrams are not provided. 6.3.3 instruction fetch after reset the general operation of the amba asb during reset is described in the amba specification (rev 2.0) . the reset signal, bnres , is active low, and can be asserted asynchronously to guarantee the bus is in a safe state. during reset, the following actions occur on the bus: the arbiter grants the default bus master. the default bus master must: ? drive btran to indicate an address-only transfer ? drive blok low to allow arbitration ? drive ba , bwrite , bsize , and bprot to any value ? tristate bd . all other bus masters must tristate shared bus signals, ba , bd , bwrite , btran , bsize , bprot , and blok . the decoder must: ? deassert all slave select signals, dselx ? provide the appropriate transfer response. all slaves must tristate shared bus signals. yo u m u s t h o l d bnres low for a minimum of five bclk cycles to ensure complete reset of the arm920t processor. you must deassert bnres during the bclk low phase.
bus interface unit 6-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 6-3 on page 6-11 shows the default bus master during reset to be the tic controller. after reset, the arm920t processor is made the default bus master, so there is a handover phase when ba , bwrite , bsize , bprot , and blok are not driven, but btran is driven with address-only. the arm920t processor continues as the default bus master without requesting the bus, so it must: drive btran to indicate an address-only transfer drive blok low to allow arbitration drive ba , bwrite , bsize , and bprot to any value tristate bd . the arm920t processor then requests use of the bus and, because it is already granted the bus, starts the first address-only cycle that is not an idle cycle, indicated by astb . the first instruction fetch continues from then.
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-11 figure 6-3 instruction fetch after reset 00 10 bclk bwrite ba[31:0] bd[31:0] bprot[1:0] btran[1:0] burst[1:0] astb ncmahb a-tran a-tran a-tran a-tran a-tran a-tran a-tran a-tran s-tran a-tran 0x0 bnres word 0 bus handover agntarm agnttic areqarm 0x4 a-tran a-tran a-tran s-tran word 1
bus interface unit 6-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 6.3.4 noncached ldrs and noncached fetches the only difference between these noncached ldr s and noncached fetches is the bprot[1:0] information, as shown in table 6-6. the address is word-aligned for an ldr and fetch. an example ldr is shown in figure 6-4. figure 6-4 example ldr from address 0x108 table 6-6 noncached ldr and fetch bprot[0] transfer 0opcode fetch 1 data access 00 = no burst or undefined burst length 11 or 01 for ldr 10 or 00 for fetch bclk ba[31:0] bd[31:0] 0x108 word 1 btran[1:0] bwrite a-tran a-tran s-tran bprot[1:0] burst[1:0] astb ncmahb
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-13 6.3.5 noncached ldm for a noncached ldm the burst[1:0] information is always 00 = no burst or undefined burst length, though the ncmahb signal gives one cycle advance warning of the end of the burst transfer if agnt remains asserted throughout the burst transfer. the address is word-aligned. an example ldm is shown in figure 6-5. figure 6-5 example ldm of 5 words from 0x108 bclk bwrite ba[31:0] bd[31:0] bprot[1:0] 0x104 btran[1:0] 0x108 0x10c 0x108 4 5 s-tran s-tran s-tran s-tran a-tran a-tran s-tran 11 or 01 for data access, 10 or 00 for opcode fetch burst[1:0] 00 = no burst or undefined burst length astb ncmahb 0x110 3 2 1
bus interface unit 6-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 6.3.6 buffered and nonbuffered str for a buffered or nonbuffered str the burst[1:0] information is: 11 buffered str , no burst or undefined burst length. 00 nonbuffered str , no burst or undefined burst length. the address is word-aligned. an example str is shown in figure 6-6. figure 6-6 example nonbuffered str bclk bwrite ba[31:0] bd[31:0] bprot[1:0] btran[1:0] 1 0x108 s-tran a-tran a-tran 11 or 01 burst[1:0] 00 = no burst or undefined burst length astb ncmahb
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-15 6.3.7 buffered and nonbuffered stm for a buffered or nonbuffered stm the burst[1:0] information is: 11 buffered stm , no burst or undefined burst length. 00 nonbuffered stm , no burst or undefined burst length. the address is word-aligned. an example nonbuffered stm is shown in figure 6-7. figure 6-7 example nonbuffered stm bclk bwrite ba[31:0] bd[31:0] bprot[1:0] 0x10c btran[1:0] 12 3 0x110 0x114 0x118 0x108 4 5 s-tran s-tran s-tran s-tran a-tran a-tran s-tran 11 or 01 burst[1:0] 00 = no burst or undefined burst length astb ncmahb
bus interface unit 6-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 6.3.8 cached ldr, cached ldm, and cached fetch a cached ldr or ldm , and a cached fetch, are equivalent to a linefill operation. the burst[1:0] information is always 10 = 8 words. the address is word-aligned and increases from the lowest address. the lowest five bits always increase from 0x00 to 0x1c . an example linefill is shown in figure 6-8. figure 6-8 example linefill from 0x100 bclk bwrite ba[31:0] bd[31:0] bprot[1:0] 0x104 btran[1:0] 12 3 0x108 0x10c 0x100 4 5 s-tran s-tran s-tran s-tran a-tran a-tran s-tran 11 or 01 for data access, 10 or 00 for opcode fetch burst[1:0] 10 = 8 words astb ncmahb 0x110 0x114 0x118 0x11c 67 8 s-tran s-tran s-tran
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-17 6.3.9 dirty data eviction, write-back of 4 or 8 words dirty data can be evicted from a cache line as either the first four words, the last four words, or all eight words of the cache line. the address is word-aligned and increases from the lowest address. bprot[1:0] is always 11, indicating privileged data access. figure 6-9 shows an example four-word dirty data eviction of the second half of a cache line. figure 6-9 example 4-word data eviction bclk bwrite ba[31:0] bd[31:0] bprot[1:0] 0x114 btran[1:0] 12 3 0x118 0x11c 0x110 4 s-tran s-tran s-tran a-tran a-tran s-tran 11 burst[1:0] 01 = 4 words astb ncmahb
bus interface unit 6-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the allowable combinations are listed in table 6-7. 6.3.10 swap the swap operation is implemented as a single read transfer followed by a single write transfer. the blok signal is asserted so that the write transfer is locked to the preceding read transfer. this must be used by the arbiter to ensure that no other bus master is given access to the bus between the read and write transfers. an example swap operation is shown in figure 6-10 on page 6-19. table 6-7 data eviction of 4 or 8 words data evicted burst[1:0] lowest 5 bits of the address first 4 words 01 0x00 to 0x0c last 4 words 01 0x10 to 0x1c all 8 words 10 0x00 to 0x1c
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-19 figure 6-10 example swap operation bclk bwrite ba[31:0] bd[31:0] bprot[1:0] btran[1:0] write a-tran a-tran a-tran a-tran a-tran s-tran 11 or 01 burst[1:0] 00 = no burst or undefined burst length ncmahb a-tran s-tran read areq agnt blok astb
bus interface unit 6-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 6.3.11 page walk a page walk is identical to a noncached ldr on the asb. that is, a single word read. the burst[1:0] encoding is always 11. for a page walk caused by an opcode fetch, bprot[1:0] = 10. for a page walk caused by a data operation, bprot[1:0] = 11. the page walk is always privileged. 6.3.12 amba asb slave transfers you can test the arm920t processor as an individual module within an amba system, responding only to transfers from the amba asb. in this mode of operation the arm920t processor is never granted the asb as a bus master, and responds as an asb slave, detecting the assertion of dsel . this is described in detail in the amba specification (rev 2.0) .
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-21 6.4 amba ahb interface the amba specification (rev 2.0) defines the amba ahb interface for use with multiple masters. with the addition of a synthesizable wrapper, the arm920t implements a full ahb interface, either as an ahb bus master, or as a slave for production test. this is delivered as synthesizable rtl, with synthesis scripts. contact arm for details of how to obtain this information. the interface uses astb , burst[1:0] , and ncmahb signals in addition to the unidirectional asb signals. this allows an efficient implementation that has: no speed penalty no cycle penalties for read transfers no cycle penalties for buffered write transfers one cycle penalty for every nonbuffered write transfer swaps incur one cycle penalty on the read transfer and one cycle penalty on the write transfer the mcr drain write buffer instruction, mcr p15, 0, rd, c7, c10, 4 , drains the write buffer to the ahb wrapper. in the case of the mcr drain write buffer the write transfers appear as buffered, so the arm920t processor continues execution before the last write transfer is completed on the ahb. an example of how this might be a problem is if the last str to the write buffer was to clear an interrupt source prior to enabling interrupts to the arm9tdmi, then the following sequence might result in an interrupt being returned to the arm9tdmi before the interrupt is cleared: buffered str to clear interrupt mcr drain write buffer enable interrupts. there are three solutions: 1. for a non write-sensitive address. issue the str twice. the first str completes before the second str enters the ahb wrapper, guaranteeing the interrupt is cleared before the interrupts are enabled: buffered str to clear interrupt buffered str to clear interrupt mcr drain write buffer enable interrupts.
bus interface unit 6-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 2. for a write-sensitive address. issue any other buffered str to a non write-sensitive address. this must be to a ncb or wt region to ensure the str is committed to the write buffer: buffered str to clear interrupt buffered str to a non write-sensitive address mcr drain write buffer enable interrupts. 3. issue a read on the ahb before enabling the interrupts. this must be from a noncachable region to ensure the read appears on the ahb: buffered str to clear interrupt mcr drain write buffer non-cachable ldr or fetch enable interrupts.
bus interface unit arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 6-23 6.5 level 2 cache support and performance analysis the burst[1:0] encoding, used with writeout and prot[1:0] , or bwrite and bprot[1:0] , is intended to provide the information necessary to implement an efficient ahb wrapper. however, it also provides enough information for a level 2 cache to be implemented outside the arm920t macrocell. contact arm for details. encodings for the range of accesses supported by the arm920t processor are listed in table 6-8. by monitoring the amba asb bus transfers, qualified by the arm920t agnt and slave responses berror , blast , and bwait , you can implement a performance monitor outside the arm920t macrocell. this might give the type of information table 6-8 arm920t supported bus access types burst[1:0] writeout prot[0] arm920t bus access 00 read 0 noncachable fetch 00 read 1 noncachable ldr or ldm 00 write 0 - 00 write 1 nonbuffered str or stm 01 read 0 - 01 read 1 - 01 write 0 - 01 write 1 write-back of 4 words 10 read 0 instruction linefill of 8 words 10 read 1 data linefill of 8 words 10 write 0 - 10 write 1 write-back of 8 words 11 read 0 instruction table walk 11 read 1 data table walk 11 write 0 - 11 write 1 buffered str or stm
bus interface unit 6-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c shown in example 6-1 on page 6-24 after running a program. the performance monitor can be made accessible as a memory mapped peripheral or using jtag on the arm920t external scan chain. example 6-1 typical output data from a performance monitor i tlb page table walks : 1 d tlb page table walks : 1 4 word writebacks : 10 8 word writebacks : 5 i cache linefills : 48 d cache linefills : 28 nc loads : 2 nc fetches : 38 ncnb stores : 2 ncb, wt or wb miss stores : 13 bclk cycles : 1594
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-1 chapter 7 coprocessor interface this chapter describes the arm920t coprocessor interface. it contains the following sections: about the arm920t coprocessor interface on page 7-2 ldc/stc on page 7-5 mcr/mrc on page 7-9 interlocked mcr on page 7-11 cdp on page 7-13 privileged instructions on page 7-15 busy-waiting and interrupts on page 7-17.
coprocessor interface 7-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 7.1 about the arm920t coprocessor interface the arm920t processor supports the connection of on-chip coprocessors through an external coprocessor interface. all types of coprocessor instruction are supported. the arm920t coprocessor interface allows you to attach specially designed coprocessor hardware to the arm920t. example uses include: attachment of accelerators for floating-point math, dsp, 3-d graphics, encryption, or decryption the arm instruction set supports the connection of 16 coprocessors, numbered 0 to 15, to an arm processor. 7.1.1 internal coprocessors the arm920t processor contains two internal coprocessors: cp14 for debug control cp15 for memory system control and test control. this means that coprocessors attached externally to the arm920t processor cannot be assigned coprocessor numbers 15 or 14. other coprocessor numbers have been allocated by arm for internal usage. contact arm for a full list of reserved coprocessor numbers. the register map of cp15 is described in cp15 register map summary on page 2-5. the functionality of cp14 is described in debug communications channel on page 9-64. 7.1.2 external coprocessors coprocessors determine the instructions they have to execute by using a pipeline follower in the coprocessor. as each instruction arrives from memory, it enters both the arm pipeline and the coprocessor pipeline. to avoid a critical path for the instruction being latched by the coprocessor, the coprocessor pipeline must operate one clock phase behind the arm920t pipeline. the arm920t then informs the coprocessor when instructions move from decode into execute, and whether the instruction has to be executed. to enable coprocessors to continue doing coprocessor data operations while the arm920t pipeline is stalled (for instance waiting for a cache linefill to occur), the coprocessor must monitor a clock cpclk , and a clock stall signal ncpwait . if ncpwait is low on the rising edge of cpclk , the arm920t pipeline is stalled and the coprocessor pipeline must not advance.
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-3 figure 7-1 indicates the timing for these signals and when the coprocessor pipeline must advance its state. in this diagram, coproc clock shows the result of oring cpclk with the inverse of ncpwait . this is one technique for generating a clock that reflects the arm9tdmi pipeline advancing. figure 7-1 arm920t coprocessor clocking coprocessor instructions there are three classes of coprocessor instructions: ldc or stc load coprocessor register from memory or store coprocessor register to memory. mcr or mrc register transfer between coprocessor and arm processor core. cdp coprocessor data operation. examples of how a coprocessor must execute these instruction classes are given in: ldc/stc on page 7-5 mcr/mrc on page 7-9 interlocked mcr on page 7-11 cdp on page 7-13. cpclk coproc clock ncpwait coprocessor pipeline
coprocessor interface 7-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 7.1.3 enabling and disabling the external coprocessor interface buses the arm920t macrocell has the cpen input, coprocessor enable. when tied low, the cpid and cpdout buses are held stable. when tied high, the cpid and cpdout buses are enabled. this is meant as a power saving feature and is intended to be used statically within an embedded system.
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-5 7.2 ldc/stc the cycle timing for ldc / stc operations are shown in figure 7-2. figure 7-2 arm920t ldc/stc cycle timing a a+4 a+8 a+c da[31:0] (arm920t internal) go go last ignored go cpclk ncpmreq cpid[27:0] chsde[1:0] chsex[1:0] cpdout[31:0] ldc/mcr cppass cplatecancel ldc cpdin[31:0] stc/mrc dnmreq (arm920t internal) dmore (arm920t internal) decode execute (go) execute (go) execute (go) execute (last) memory write decode execute (go) execute (go) execute (go) execute (last) memory write coprocessor pipeline arm processor pipeline
coprocessor interface 7-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c in figure 7-2 on page 7-5, four words of data are transferred. the number of words transferred is determined by how the coprocessor drives the chsde[1:0] and chsex[1:0] buses. as with all other instructions, the arm920t processor core performs the main instruction decode off the rising edge of the clock during the decode stage. from this, the arm9tdmi cpu core commits to executing the instruction, and so performs an instruction fetch. the coprocessor instruction pipeline keeps in step with the arm920t by monitoring cpmreq , a latched copy of the arm9tdmi instruction memory request signal inmreq . whenever ncpmreq is low, an instruction fetch is occurring and cpid is updated with the fetched instruction in the next cycle. this means that the instruction currently on cpid enters the decode stage of the coprocessor pipeline, and that the instruction in the decode stage of the coprocessor pipeline enters its execute stage. during the execute stage, the condition codes are combined with the flags to determine whether the instruction can be executed or not. the output cppass is asserted (high) if the instruction in the execute stage of the coprocessor pipeline: is a coprocessor instruction has passed its condition codes. if a coprocessor instruction busy-waits, cppass is asserted on every cycle until the coprocessor instruction is executed. if an interrupt occurs during busy-waiting, cppass is driven low, and the coprocessor stops execution of the coprocessor instruction. another output, cplatecancel , is used to cancel a coprocessor instruction when the instruction preceding it caused a data abort. this is valid on the rising edge of cpclk on the cycle after the first execute cycle of the coprocessor instructions. cplatecancel is only asserted during the first memory cycle of the execution of coprocessor instructions. on the falling edge of the clock, the arm920t processor core examines the coprocessor handshake signals chsde[1:0] or chsex[1:0] : if a new instruction is entering the execute stage in the next cycle, it examines chsde[1:0] if the coprocessor instruction currently in execute requires another execute cycle, it examines chsex[1:0] .
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-7 the handshake signals encode one of four states: absent if there is no coprocessor attached that can execute the coprocessor instruction, the handshake signals indicate the absent state. in this case, the arm9tdmi processor core takes the undefined instruction exception. wa i t if there is a coprocessor attached that can execute the instruction but not immediately, the coprocessor handshake signals must be driven to indicate that the arm9tdmi processor core must stall until the coprocessor can catch up. this is known as the busy-wait condition. in this case, the arm9tdmi processor core loops in an idle state, waiting for chsex[1:0] to be driven to another state, or for an interrupt to occur. if chsex[1:0] changes to absent, the undefined instruction exception is taken. if chsex[1:0] changes to go or last, the instruction proceeds as described below. if an interrupt occurs, the arm9tdmi processor core is forced out of the busy-wait state. this is indicated to the coprocessor by the cppass signal going low. the instruction is restarted at a later date. therefore the coprocessor must not commit to the instruction (change any of the coprocessor states) until it has seen cppass go high, and the handshake signals indicate the go or last condition. go the go state indicates that the coprocessor can execute the instruction immediately, and that it requires another cycle of execution. both the arm9tdmi processor core and the coprocessor must also consider the state of the cppass signal before actually committing to the instruction. for an ldc or stc instruction, the coprocessor instruction must drive the handshake signals with go when two or more words still have to be transferred. when only one more word is required, the coprocessor must drive the handshake signals with the last condition. in phase 2 of the execute stage, the arm9tdmi processor core outputs the address for the ldc / stc . also in this phase, dnmreq is driven low, indicating to the memory system that a memory access is required at the data end of the device. the timing for the data on cpdout[31:0] for an ldc , and cpdin[31:0] for an stc , is as shown in figure 7-2 on page 7-5. last an ldc or stc can be used for more than one item of data. if this is the case, possibly after busy waiting, the coprocessor must drive the coprocessor handshake signals with a number of go states and, in the penultimate cycle, with last. the last indicating that the next transfer is the final one. if there is only one transfer, the sequence is [wait,[wait,...]],last.
coprocessor interface 7-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 7.2.1 coprocessor handshake encoding table 7-1 shows how the handshake signals chsde[1:0] and chsex[1:0] are encoded. if you do not attach a coprocessor to the arm920t, then the handshake signals must be driven with absent. if you attach multiple coprocessors to the interface, the handshaking signals can be combined by anding bit 1, and oring bit 0. in the case of two coprocessors that have handshaking signals chsde1 , chsex1 and chsde2 , chsex2 respectively: chsde[1] <= chsde1[1] and chsde2[1] chsde[0] <= chsde1[0] or chsde2[0] chsex[1] <= chsex1[1] and chsex2[1] chsex[0] <= chsex1[0] or chsex2[0] . consequently, if the coprocessor does not recognize a coprocessor instruction, it must drive chsde[1:0] and chsex[1:0] with absent. table 7-1 handshake encoding state [1:0] absent 10 wa i t 0 0 go 01 last 11
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-9 7.3 mcr/mrc mcr / mrc cycles look very similar to stc / ldc . an example with a busy-wait state is shown in figure 7-3. figure 7-3 arm920t mcr/mrc transfer timing last ignored wait cpclk ncpmreq cpid[31:0] chsde[1:0] chsex[1:0] cpdout[31:0] ldc/mcr cppass cplatecancel mcr/ mrc cpdin[31:0] stc/mrc decode execute (wait) execute (last) memory write decode execute (wait) execute (last) memory write coprocessor pipeline arm processor pipeline
coprocessor interface 7-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c in figure 7-3 on page 7-9, first ncpmreq is driven low to denote that the instruction on cpid is entering the decode stage of the pipeline. the coprocessor decodes the new instruction and drives chsde[1:0] as required. in the next cycle ncpmreq is driven low to denote that the instruction has now been issued to the execute stage. if the condition codes pass, and the instruction is to be executed, the cppass signal is driven high and the chsde[1:0] handshake bus is examined (it is ignored in all other cases). for any successive execute cycles the chsex[1:0] handshake bus is examined. when the last condition is observed, the instruction is committed. in the case of an mcr , the cpdout[31:0] bus is driven with the register data. in the case of an mrc , cpdin[31:0] is sampled at the end of the arm920t memory stage and written to the destination register during the next cycle. for an mcr or mrc , with no busy-wait states, the coprocessor drives chsde[1:0] with last. this commits the instruction for execution in the next cycle. the value on chsex[1:0] is ignored.
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-11 7.4 interlocked mcr if the data for an mcr operation is not available inside the arm9tdmi pipeline during its first decode cycle, the arm920t pipeline interlocks for one or more cycles until the data is available. an example of this is where the register being transferred is the destination from a preceding ldr instruction. in this situation the mcr instruction enters the decode stage of the coprocessor pipeline, and remains there for a number of cycles before entering the execute stage. figure 7-4 on page 7-12 gives an example of an interlocked mcr . in this example the mcr busy-waits the arm9tdmi. when the instruction enters the decode stage of the coprocessor pipeline, the coprocessor drives chsde[1:0] with wait. due to an interlock in the arm9tdmi, the instruction remains in decode for an extra cycle. this is signaled to the coprocessor by ncpmreq going high, holding the instruction in the decode stage of the coprocessor pipeline follower. the coprocessor signals wait to the arm9tdmi during its second decode cycle. the interlock in the arm9tdmi resolves, ncpmreq goes low, and the instruction moves from decode into execute.
coprocessor interface 7-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 7-4 arm920t interlocked mcr last ignored wait/ ignored cpclk ncpmreq cpid[31:0] chsde[1:0] chsex[1:0] cpdout[31:0] ldc/mcr cppass cplatecancel mcr/ mrc cpdin[31:0] stc/mrc decode decode execute (wait) execute (last) memory decode (interlock) decode execute (wait) memory write coprocessor pipeline arm processor pipeline wait execute (last) write
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-13 7.5 cdp cdp s normally execute in a single cycle. like all other instructions, ncpmreq is driven low to signal when an instruction is entering the decode and then the execute stage of the pipeline: if the instruction is to be executed, the cppass signal is driven high during phase 2 of the execute stage if the coprocessor can execute the instruction immediately it drives chsde[1:0] with last if the instruction requires a busy-wait cycle, the coprocessor drives chsde[1:0] with wait and then chsex[1:0] with last. figure 7-5 on page 7-14 shows a cdp that is canceled due to the previous instruction causing a data abort. the cdp instruction enters the execute stage of the pipeline, and is signaled to execute by cppass . in the following phase cplatecancel is asserted. this causes the coprocessor to terminate execution of the cdp instruction, and for it to cause no state changes to the coprocessor.
coprocessor interface 7-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 7-5 arm920t late canceled cdp ignored last cpclk ncpmreq cpid[31:0] chsde[1:0] chsex[1:0] cppass cplatecancel cprt dabort (arm920t internal) decode execute memory (latecancelled) decode execute cdp: coprocessor pipeline cdp: arm processor pipeline execute memory exception entry start exception continues ldr with data abort
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-15 7.6 privileged instructions the coprocessor can restrict certain instructions for use in priv ileged modes only. to do this, the coprocessor must track the ncptrans output. figure 7-6 shows how ncptrans changes after a mode change. figure 7-6 arm920t privileged instructions ignored ignored cpclk ncpmreq cpid[31:0] chsde[1:0] chsex[1:0] cppass cplatecancel cprt decode decode decode execute memory decode decode decode memory write cdp: coprocessor pipeline cdp: arm processor pipeline ignored execute write ncptrans old mode new mode last execute execute (cycle 2) execute (cycle 3) write mode change memory *
coprocessor interface 7-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c in figure 7-6 on page 7-15 the mode change (marked with an asterisk) occurs as follows: for mode changes that do not use an msr . the mode changes after the first execute cycle. for mode changes that use an msr . the mode changes after the second execute cycle. note the first two chsde[1:0] responses are ignored by the arm920t because it is only the final chsde[1:0] response, as the instruction moves from decode into execute, that is relevant. this allows the coprocessor to change its response as ncptrans changes.
coprocessor interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 7-17 7.7 busy-waiting and interrupts the coprocessor is permitted to stall (or busy-wait ) the processor during the execution of a coprocessor instruction if, for example, it is still busy with an earlier coprocessor instruction. to do so, the coprocessor associated with the decode stage instruction must drive wait in chsde[1:0] . when the instruction concerned enters the execute stage of the pipeline, the coprocessor can drive wait onto chsex[1:0] for as many cycles as required to keep the instruction in the busy-wait loop. for interrupt latency reasons the coprocessor can be interrupted while busy-waiting, causing the instruction to be abandoned. abandoning execution is achieved through cppass . the coprocessor must monitor the state of cppass during every busy-wait cycle. if it is high, the instruction must still be executed. if it is low, the instruction must be abandoned. figure 7-7 on page 7-18 shows a busy-waited coprocessor instruction being abandoned due to an interrupt.
coprocessor interface 7-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 7-7 arm920t busy waiting and interrupts wait wait wait cpclk ncpmreq cpid[31:0] chsde[1:0] chsex[1:0] cpdout[31:0] ldc/mcr cppass cplatecancel cpinstr cpdin[31:0] stc/mrc decode execute (wait) execute (wait) execute (wait) execute (wait) decode execute (wait) execute (wait) execute (wait) execute interrupted coprocessor pipeline arm processor pipeline wait ignored exception entry abandoned
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 8-1 chapter 8 trace interface port this chapter gives a brief description of the embedded trace macrocell (etm) support for the arm920t processor. it contains the following section: about the etm interface on page 8-2.
trace interface port 8-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 8.1 about the etm interface the arm920t trace interface port enables simple connection of an etm9 to an arm920t rev 1. this interface does not exist on arm920t rev 0. the arm9 embedded trace macrocell (etm9) provides instruction and data trace for the arm9tdmi family of processors. the interface is made up as follows: etmpwrdown input to the arm920t etmclock output to the etm9 etmnwait output to the etm9 etm outputs to the etm9. when etmpwrdown is high, the etmclock output and the etm outputs are held stable. when etmpwrdown is low, the etmclock and etm outputs are enabled. this enables system power to be reduced when the etm9 is not used. when the etm9 is incorporated within a system, the arm debug tools control etmpwrdown , automatically setting the signal low at the start of a debug session. if the etm9 is not incorporated within a system, then etmpwrdown must be tied high. the etmclock output to the etm9 is used by the etm9 to sample the etm outputs on the rising edge of etmclock , when etmnwait is high. etmnwait is the nwait input signal to the arm9tdmi, so this allows cycle-accurate tracing using etmclock . the etmclock signal is never stretched. the etm outputs are registered so that they can be sampled on the rising edge of etmclock . the etm timing is shown in timing definitions for the arm920t trace interface port on page 13-26 and signal descriptions in arm920t trace interface port signals on page a-13. the etm9 (rev0/0a) technical reference manual contains details of how to integrate an etm9 with an arm920t rev 1, including the pin correlation.
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-1 chapter 9 debug support this chapter describes the debug support for the arm920t, including the embeddedice macrocell. it contains the following sections: about debug on page 9-2 debug systems on page 9-3 debug interface signals on page 9-5 scan chains and jtag interface on page 9-11 the jtag state machine on page 9-12 test data registers on page 9-19 arm920t core clocks on page 9-42 clock switching during debug on page 9-43 clock switching during test on page 9-44 determining the core state and system state on page 9-45 exit from debug state on page 9-48 the behavior of the program counter during debug on page 9-51 embeddedice macrocell on page 9-54 vector catching on page 9-62 single-stepping on page 9-63 debug communications channel on page 9-64.
debug support 9-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.1 about debug debug support is implemented using the arm9tdmi cpu core embedded within the arm920t. throughout this chapter therefore, arm9tdmi refers to this core. the arm920t debug interface is based on ieee std. 1149.1- 1990, standard test access port and boundary-scan architecture . see this standard for an explanation of the terms used in this chapter and for a description of the tap controller states. the arm920t contains hardware extensions for advanced debugging features. these are intended to ease the development of application software, operating systems, and the hardware itself. the debug extensions allow the core to be stopped by one of the following: a given instruction fetch (breakpoint) a data access (watchpoint) asynchronously by a debug request. when this happens, the arm920t is said to be in debug state . at this point, you can examine the internal state of the core and the external state of the system. when examination is complete, you can restore the core and system state and resume program execution. the arm920t is forced into debug state either by a request on one of the external debug interface signals, or by an internal functional unit known as the embeddedice macrocell. when in debug state, the core isolates itself from the memory system. you can then examine the core can while all other system activity continues as normal. you can examine the internal state of the arm920t using a jtag-style serial interface. this allows instructions to be serially inserted into the pipeline of the core without using the external data bus. therefore, when in debug state, you can insert a store-multiple ( stm ) into the instruction pipeline to export the contents of the arm9tdmi registers. this data can be serially shifted out without affecting the rest of the system.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-3 9.2 debug systems the arm920t forms one component of a debug system that interfaces from the high-level debugging performed by you, to the low-level interface supported by the arm920t. a typical system is shown in figure 9-1. figure 9-1 typical debug system this typical system has three parts: the debug host on page 9-3 the protocol converter on page 9-4 the arm920t processor on page 9-4. 9.2.1 the debug host the debug host is a computer, for example a personal computer, running a software debugger such as armsd, for example, or adw. the debug host allows you to issue high-level commands such as set breakpoint at location xx , or examine the contents of memory from 0x0 to 0x100 . host computer running armsd or adw debug host protocol converter debug host debug target for example, multi-ice development system containing arm920t
debug support 9-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.2.2 the protocol converter the debug host is connected to the arm920t development system using an interface (an rs232, for example). the messages broadcast over this connection must be converted to the interface signals of the arm920t. this function is performed by a protocol converter, for example, multi-ice. 9.2.3 the arm920t processor the arm920t processor, with hardware debug extensions, is the lowest level of the system. the debug extensions allow you to: stall the core from program execution examine its internal state and the state of the memory system resume program execution. the debug host and the protocol converter are system-dependent.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-5 9.3 debug interface signals there are four primary external signals associated with the debug interface: iebkpt , dewpt , and edbgrq . the system can use these to ask the arm920t to enter debug state. dbgack . the arm920t uses this signal to flag back to the system when it is in debug state. 9.3.1 entry into debug state on breakpoint any instruction being fetched from memory is latched at the end of phase 2. to apply a breakpoint to that instruction, the breakpoint signal must be asserted by the end of the following phase 1. this minimizes the setup time, giving the embeddedice macrocell an entire phase to perform the comparison. this is shown in figure 9-2. figure 9-2 breakpoint timing gclk ia[31:0] iebkpt dbgack w1 d1 e1 edebug2 edebug1 ddebug id[31:0] 1 i 4 2 3 w2 wi m1 w1 f1 f2 d2 e2 m2 w2 fi di ei mi wi
debug support 9-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c you can build external logic, such as additional breakpoint comparators, to extend the functionality of the embeddedice macrocell. you must apply the external logic output to the iebkpt input. this signal is ored with the internally generated breakpoint signal before being applied to the arm920t core control logic. a breakpointed instruction is allowed to enter the execute stage of the pipeline, but any state change as a result of the instruction is prevented. all writes from previous instructions complete as normal. the decode cycle of the debug entry sequence occurs during the execute cycle of the breakpointed instruction. the latched breakpoint signal forces the processor to start the debug sequence. 9.3.2 breakpoints and exceptions a breakpointed instruction might have a prefetch abort associated with it. if so, the prefetch abort takes priority and the breakpoint is ignored. (if there is a prefetch abort, instruction data might be invalid, the breakpoint might have been data-dependent, and as the data might be incorrect, the breakpoint might have been triggered incorrectly.) swi and undefined instructions are treated in the same way as any other instruction that might have a breakpoint set on it. therefore, the breakpoint takes priority over the swi or undefined instruction. on an instruction boundary, if there is a breakpointed instruction and an interrupt ( irq or fiq ), the interrupt is taken and the breakpointed instruction is discarded. when the interrupt has been serviced, the execution flow is returned to the original program. this means that the instruction that has been breakpointed is fetched again, and if the breakpoint is still set, the processor enters debug state when it reaches the execute stage of the pipeline. when the processor has entered debug state, it is important that additional interrupts do not affect the instructions executed. for this reason, as soon as the processor enters debug state, interrupts are disabled, although the state of the i and f bits in the program status register (psr) are not affected. 9.3.3 watchpoints entry into debug state following a watchpointed memory access is imprecise. this is necessary because of the nature of the pipeline and the timing of the watchpoint signal.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-7 after a watchpointed access, the next instruction in the processor pipeline is always allowed to complete execution. where this instruction is a single-cycle data-processing instruction, entry into debug state is delayed for one cycle while the instruction completes. the timing of debug entry following a watchpointed load in this case is shown in figure 9-3 on page 9-8. note although instruction 5 enters the execute state, it is not executed, and there is no state update as a result of this instruction. when the debugging session is complete, normal continuation involves a return to instruction 5, the next instruction in the code sequence to be executed. the instruction following the instruction that generated the watchpoint might have modified the program counter (pc). if this happens, it is not possible to determine the instruction that caused the watchpoint. a timing diagram showing debug entry after a watchpoint where the next instruction is a branch is shown in figure 9-4 on page 9-9. however, you can always restart the processor. when the processor has entered debug state, the arm920t core can be interrogated to determine its state. in the case of a watchpoint, the pc contains a value that is five instructions on from the address of the next instruction to be executed. therefore, if on entry to debug state, in arm state, the instruction sub pc, pc, #20 is scanned in and the processor restarted, execution flow returns to the next instruction in the code sequence.
debug support 9-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 9-3 watchpoint entry with data processing instruction dd[31:0] gclk inmreq id[31:0] da[31:0] 12 ldr dp 5 6 7 8 ddin[31:0] watchpoint dbgack e1 f1 d1 w1 m1 d2 f2 m2 e2 eldr fldr dldr wldr mldr ddp fdp mdp edp e5 f5 d5 w5 m5 w2 wdp ddebug edebug2 edebug1 wldr w1 w2 w5 wdp w6
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-9 figure 9-4 watchpoint entry with branch 9.3.4 watchpoints and exceptions if there is an abort in the data access together with a watchpoint, the watchpoint condition is latched, the exception entry sequence performed, and then the processor enters debug state. if there is an interrupt pending, again the arm920t processor allows the exception entry sequence to occur and then enters debug state. dd[31:0] gclk inmreq ia[31:1] da[31:0] a+4 t t+8 ddin[31:0] watchpoint dbgack eldr fldr dldr wldr mldr db fb mb eb ft et dt ddebug wb edebug1 a a+8 t+4 t+c id[31:0] ldr b x x t t+1 t+2 t+3 edebug2
debug support 9-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.3.5 debug request a debug request can take place through the embeddedice macrocell or by asserting the edbgrq signal. the request is synchronized and passed to the processor. debug request takes priority over any pending interrupt. following synchronization, the core enters debug state when the instruction at the execute stage of the pipeline has completely finished executing (when memory and write stages of the pipeline have completed). while waiting for the instruction to finish executing, no more instructions are issued to the execute stage of the pipeline. 9.3.6 actions of the arm920t in debug state when the arm920t is in debug state, both memory interfaces indicate internal cycles. this allows the rest of the memory system to ignore the arm9tdmi core and function as normal. because the rest of the system continues operation, the arm9tdmi core ignores aborts and interrupts. the bigend signal must not be changed by the system while in debug state. if it changes there might be a synchronization problem, and the arm920t (as seen by the programmer) changes without the knowledge of the debugger. the bnres signal must also be held stable during debug. if the system applies reset to the arm920t ( bnres is driven low), the state of the arm920t changes without the knowledge of the debugger. when instructions are executed in debug state, the arm9tdmi core changes asynchronously to the memory system outputs (except for inmreq , iseq , dnmreq , and dseq that change synchronously from gclk ). for example, every time a new instruction is scanned into the pipeline, the instruction address bus changes. if the instruction is a load or store operation, the data address bus changes as the instruction executes. although this is asynchronous, it does not affect the system, because both interfaces indicate internal cycles. you must take care when designing the memory controller to ensure that this does not become a problem.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-11 9.4 scan chains and jtag interface there are six scan chains inside the arm920t processor. these allow testing, debugging, and programming of the embeddedice macrocell watchpoint units. the scan chains are controlled by a jtag-style test access port (tap) controller. in addition, support is provided for an optional seventh scan chain. this is intended to be used for an external boundary scan chain around the pads of a packaged device. the signals provided for this scan chain are described in scan chain 3 on page 9-30. the six scan chains of the arm920t processor are called scan chain 0, 1, 2, 3, 4, and 15. note the arm920t tap controller supports 32 scan chains. scan chains 0 to 15 have been reserved for use by arm. any extension scan chains must be implemented in the remaining space. the screg[4:0] signals indicate the scan chain being accessed.
debug support 9-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.5 the jtag state machine the process of serial test and debug is best explained in conjunction with the jtag state machine. figure 9-5 shows the state transitions that occur in the tap controller. the state numbers are also shown on the diagram. these are output from the arm920t on the tapsm[3:0] bits. figure 9-5 test access port (tap) controller state transitions 1 1. from ieee std 1149.1-1990. copyright 1999ieee. all rights reserved. select-dr-scan 0x7 capture-dr 0x6 shift-dr 0x2 exit1-dr 0x1 pause-dr 0x3 exit2-dr 0x0 update-dr 0x5 run-test/idle 0xc test-logic-reset 0xf tms=0 tms=0 tms=1 tms=0 tms=1 tms=1 select-ir-scan 0x4 capture-ir 0xe shift-ir 0xa exit1-ir 0x9 pause-ir 0xb exit2-ir 0x8 update-ir 0xd tms=0 tms=0 tms=1 tms=0 tms=1 tms=1 tms=0 tms=0 tms=0 tms=0 tms=1 tms=0 tms=1 tms=0 tms=1 tms=1 tms=0 tms=1 tms=1 tms=1 tms=0 tms=1 tms=0 tms=1 tms=1 tms=0
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-13 9.5.1 reset the jtag interface includes a state-machine controller, the tap controller. to force the tap controller into the correct state after power-up of the device, a reset pulse must be applied to the ntrst signal, or the jtag state machine must be cycled through the test logic reset state. before the jtag interface can be used, ntrst must be driven low, and then high again. if you do not intend using the boundary scan interface, you can tie the ntrst input permanently low. note a clock on tck is not required to reset the device. the action of reset is as follows: 1. system mode is selected. the boundary scan chain cells do not intercept any of the signals passing between the external system and the core. 2. the idcode instruction is selected. if the tap controller is put into the shift-dr state and tck is pulsed, the contents of the id register are clocked out of tdo . 9.5.2 pullup resistors the ieee 1149.1 standard effectively requires tdi and tms to have internal pullup resistors. in order to minimize static current draw, these resistors are not fitted to the arm9tdmi core. accordingly, the four inputs to the test interface (the tdo , tdi , and tms signals, plus tck ) must all be driven to valid logic levels to achieve normal circuit operation. 9.5.3 instruction register the instruction register is four bits in length. there is no parity bit. the fixed value loaded into the instruction register during the capture-ir controller state is 0001.
debug support 9-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.5.4 public instructions table 9-1 shows the public instructions that are supported. in the descriptions that follow, tdi and tms are sampled on the rising edge of tck and all output transitions on tdo occur as a result of the falling edge of tck . extest (0000) the selected scan chain is placed in test mode by the extest instruction. the extest instruction connects the selected scan chain between tdi and tdo . when the instruction register is loaded with the extest instruction, all the scan cells are placed in their test mode of operation. in the capture-dr state, inputs from the system logic and outputs from the output scan cells to the system are captured by the scan cells. in the shift-dr state, the previously captured test data is shifted out of the scan chain on tdo , while new test data is shifted in on the tdi input. this data is applied immediately to the system logic and system pins. table 9-1 public instructions instruction binary code extest 0000 scan_n 0010 intest 1100 idcode 1110 bypass 1111 clamp 0101 highz 0111 clampz 1001 sample/preload 0011 restart 0100
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-15 scan_n (0010) this instruction connects the scan path select register between tdi and tdo . during the capture-dr state, the fixed value 10000 is loaded into the register. during the shift-dr state, the id number of the desired scan path is shifted into the scan path select register. in the update-dr state, the scan register of the selected scan chain is connected between tdi and tdo , and remains connected until a subsequent scan_n instruction is issued. on reset, scan chain 3 is selected by default. the scan path select register is five bits long in this implementation, although no finite length is specified. intest (1100) the selected scan chain is placed in test mode by the intest instruction. the intest instruction connects the selected scan chain between tdi and tdo . when the instruction register is loaded with the intest instruction, all the scan cells are placed in their test mode of operation. in the capture-dr state, the value of the data applied from the core logic to the output scan cells, and the value of the data applied from the system logic to the input scan cells is captured. in the shift-dr state, the previously captured test data is shifted out of the scan chain on the tdo pin, while new test data is shifted in on the tdi pin. idcode (1110) the idcode instruction connects the device identification register (or id register) between tdi and tdo . the id register is a 32-bit register that allows the manufacturer, part number, and version of a component to be determined through the tap. the id register is loaded from the tapid[31:0] input bus. this must be tied to a constant value that represents the unique jtag idcode for the device. when the instruction register is loaded with the idcode instruction, all the scan cells are placed in their normal (system) mode of operation. in the capture-dr state, the device identification code is captured by the id register. in the shift-dr state, the previously captured device identification code is shifted out of the id register on the tdo pin, while data is shifted in on the tdi pin into the id register. in the update-dr state, the id register is unaffected.
debug support 9-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c bypass (1111) the bypass instruction connects a 1-bit shift register (the bypass register) between tdi and tdo . when the bypass instruction is loaded into the instruction register, all the scan cells are placed in their normal (system) mode of operation. this instruction has no effect on the system pins. in the capture-dr state, a logic 0 is captured by the bypass register. in the shift-dr state, test data is shifted into the bypass register on tdi and out on tdo after a delay of one tck cycle. the first bit shifted out is a zero. the bypass register is not affected in the update-dr state. note all unused instruction codes default to the bypass instruction. clamp (0101) this instruction connects a 1-bit shift register (the bypass register) between tdi and tdo . when the clamp instruction is loaded into the instruction register, the state of all the output signals is defined by the values previously loaded into the currently-loaded scan chain. note this instruction must only be used when scan chain 0 is the currently selected scan chain. in the capture-dr state, a logic 0 is captured by the bypass register. in the shift-dr state, test data is shifted into the bypass register on tdi and out on tdo after a delay of one tck cycle. the first bit shifted out is a zero. the bypass register is not affected in the update-dr state. highz (0111) this instruction connects a 1-bit shift register (the bypass register) between tdi and tdo .
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-17 when the highz instruction is loaded into the instruction register and scan chain 0 is selected, all arm920t outputs are driven to the high impedance state and the external highz signal is driven high. this is as if the signal tbe had been driven low. in the capture-dr state, a logic 0 is captured by the bypass register. in the shift-dr state, test data is shifted into the bypass register on tdi and out on tdo after a delay of one tck cycle. the first bit shifted out is a zero. the bypass register is not affected in the update-dr state. clampz (1001) this instruction connects a 1-bit shift register (the bypass register) between tdi and tdo . when the clampz instruction is loaded into the instruction register and scan chain 0 is selected, all the 3-state outputs (as described above) are placed in their inactive state, but the data supplied to the outputs is derived from the scan cells. the purpose of this instruction is to ensure that, during production test, each output can be disabled when its data value is either a logic 0 or logic 1. in the capture-dr state, a logic 0 is captured by the bypass register. in the shift-dr state, test data is shifted into the bypass register on tdi and out on tdo after a delay of one tck cycle. the first bit shifted out is a zero. the bypass register is not affected in the update-dr state. sample/preload (0011) when the instruction register is loaded with the sample/preload instruction, all the scan cells of the selected scan chain are placed in the normal mode of operation. in the capture-dr state, a snapshot of the signals of the boundary scan is taken on the rising edge of tck . normal system operation is unaffected. in the shift-dr state, the sampled test data is shifted out of the boundary scan on the tdo pin, while new data is shifted in on the tdi pin to preload the boundary scan parallel input latch. this data is not applied to the system logic or system pins while the sample/preload instruction is active. this instruction must be used to preload the boundary scan register with known data prior to selecting intest or extest instructions.
debug support 9-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c restart (0100) this instruction is used to restart the processor on exit from debug state. the restart instruction connects the bypass register between tdi and tdo and the tap controller behaves as if the bypass instruction is loaded. the processor resynchronizes back to the memory system when the run-test/idle state is entered.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-19 9.6 test data registers you can connect the following test data registers between tdi and tdo : bypass register on page 9-19 arm920t device identification (id) code register on page 9-19 instruction register on page 9-20 scan chain select register on page 9-20 scan chains 0, 1, 2, and 3 on page 9-23 scan chain 6 on page 9-31 scan chains 4 and 15, the arm920t memory system on page 9-31. 9.6.1 bypass register purpose bypasses the device during scan testing by providing a path between tdi and tdo . length 1 bit. operating mode when the bypass instruction is the current instruction in the instruction register, serial data is transferred from tdi to tdo in the shift-dr state with a delay of one tck cycle. there is no parallel output from the bypass register. a logic 0 is loaded from the parallel input of the bypass register in capture-dr state. 9.6.2 arm920t device identification (id) code register purpose reads the 32-bit device identification code. no programmable supplementary identification code is provided. length 32 bits. operating mode when the idcode instruction is current, the id register is selected as the serial path between tdi and tdo . there is no parallel output from the id register. the 32-bit identification code is loaded into the register from the parallel inputs of the tapid[31:0] input bus during the capture-dr state.
debug support 9-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the ieee format of the id register is shown in table 9-2. the tapid[31:0] pins allow you to set this value when the macrocell is instantiated in a design. 9.6.3 instruction register purpose changes the current tap instruction. length 4 bits. operating mode when in shift-ir state, the instruction register is selected as the serial path between tdi and tdo . during the capture-ir state, the value b0001 is loaded into this register. this is shifted out during shift-ir (least significant bit first), while a new instruction is shifted in (least significant bit first). during the update-ir state, the value in the instruction register becomes the current instruction. on reset, idcode becomes the current instruction. 9.6.4 scan chain select register purpose changes the current active scan chain. length 5 bits. operating mode after scan_n has been selected as the current instruction, when in shift-dr state, the scan chain select register is selected as the serial path between tdi and tdo . during the capture-dr state, the value b10000 is loaded into this register. this is shifted out during shift-dr, least significant bit first, while a new value is shifted in, least significant bit first. table 9-2 id code register bits function value 31:28 specification revision 0x1 27:12 product code 0x0920 11:1 manufacturer default = 0b11110000111 0 ieee standard specified 0b1
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-21 during the update-dr state, the value in the register selects a scan chain to become the currently active scan chain. all additional instructions such as intest then apply to that scan chain. the currently selected scan chain only changes when a scan_n instruction is executed, or a reset occurs. on reset, scan chain 3 is selected as the active scan chain. the number of the currently selected scan chain is reflected on the screg[4:0] output bus. you can use the tap controller to drive external scan chains in addition to those within the arm920t macrocell. the external scan chain must be assigned a number and control signals for it, and can be derived from screg[4:0] , ir[3:0] , tapsm[3:0] , tck1 , and tck2 . the list of scan chain numbers allocated by arm are shown in table 9-3 on page 9-23. an external scan chain can take any other number. the serial data stream applied to the external scan chain is made present on sdin . the serial data back from the scan chain must be presented to the tap controller on the sdoutbs input. the scan chain present between sdin and sdoutbs is connected between tdi and tdo whenever scan chain 3 is selected, or when any of the unassigned scan chain numbers is selected. if there is more than one external scan chain, you must build a multiplexor externally to apply the desired scan chain output to sdoutbs . you can control the multiplexor by decoding screg[4:0] . the structure is shown in figure 9-6 on page 9-22.
debug support 9-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 9-6 external scan chain multiplexor tap controller tap controller tdi tms tck sdoutbs armtdo screg screg arm920t etm9 tdo tdo tdo 6 !6 01 2415 3, 5-14, 16-31 3!3 screg scan chain 3 sdoutbs sdin sdin
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-23 scan chain number allocations are shown in table 9-3. 9.6.5 scan chains 0, 1, 2, and 3 these scan chains allow serial access to the core logic, and to the embeddedice macrocell for programming purposes. each scan cell can perform two basic functions: capture shift. scan chain 0 purpose primarily for inter-device testing (extest), and testing the arm9tdmi core (intest). scan chain 0 is selected using the scan_n instruction. length 184 bits. table 9-3 scan chain number allocation scan chain number function 0 arm9tdmi macrocell scan test 1debug 2 embeddedice programming 3 external boundary scan 4 physical address tag ram 5reserved 6 etm9 7:14 reserved 15 coprocessor 15 16:31 unassigned
debug support 9-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c intest allows serial testing of the core. the tap controller must be placed in the intest mode after scan chain 0 has been selected: during capture-dr, the current outputs from the core logic are captured in the output cells. during shift-dr, this captured data is shifted out while a new serial test pattern is scanned in, applying known stimuli to the inputs. during run-test/idle, the core is clocked. normally, the tap controller only spends one cycle in run-test/idle. the whole operation can then be repeated. extest allows inter-device testing, useful for verifying the connections between devices in the design. the tap controller must be placed in extest mode after scan chain 0 has been selected: during capture-dr, the current inputs to the core logic from the system are captured in the input cells. during shift-dr, this captured data is shifted out while a new serial test pattern is scanned in, applying known values on the core outputs. during run-test/idle, the core is not clocked. the operation can then be repeated. the bit order of scan chain 0 is shown in table 9-4. table 9-4 scan chain 0 bit order no. signal direction 1 id[0] input 2 id[1] input 3:31 id[2:30] input 32 id[31] input 33 sysspeed internal 34 wptandbkpt internal 35 dden output 36 dd[31] bidirectional 37 dd[30] bidirectional
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-25 38:66 dd[29:1] bidirectional 67 dd[0] bidirectional 68 da[31] output 69 da[30] output 70:98 da[29:1] output 99 da[0] output 100 ia[31] output 101 ia[30] output 102:129 ia[29:2] output 130 ia[1] output 131 iebkpt input 132 dewpt input 133 edbgrq input 134 extern0 input 135 extern1 input 136 commrx output 137 commtx output 138 dbgack output 139 rangeout0 output 140 rangeout1 output 141 dbgrqi output 142 ddbe input 143 inmreq output 144 dnmreq output 145 dnrw output table 9-4 scan chain 0 bit order (continued) no. signal direction
debug support 9-26 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 146 dmas[1] output 147 dmas[0] output 148 pass output 149 latecancel output 150 itbit output 151 intrans output 152 dntrans output 153 nreset input 154 nwait input 155 iabort input 156 iabe input 157 dabort input 158 dabe input 159 nfiq input 160 nirq input 161 isync input 162 bigend input 163 hivecs input 164 chsd[1] input 165 chsd[0] input 166 chse[1] input 167 chse[0] input 168 reserved - 169 iseq output 170 inm[4] output table 9-4 scan chain 0 bit order (continued) no. signal direction
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-27 171 inm[3] output 172 inm[2] output 173 inm[1] output 174 inm[0] output 175 dnm[4] output 176 dnm[3] output 177 dnm[2] output 178 dnm[1] output 179 dnm[0] output 180 dseq output 181 dmore output 182 dlock output 183 eclk output 184 instrexec output table 9-4 scan chain 0 bit order (continued) no. signal direction
debug support 9-28 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c scan chain 1 purpose primarily for debugging. scan chain 1 is selected using the scan_n tap controller instruction. length 67 bits. the bit functions of scan chain 1 are shown in table 9-5. this scan chain is 67 bits long, 32 bits for data values, 32 bits for instruction data, and three control bits, sysspeed, wptandbkpt, and dden . the three control bits serve four different purposes: under normal intest test conditions, the dden signal can be captured and examined. during extest conditions, a known value can be scanned into dden to be driven into the rest of the system. if a logic 1 is scanned into dden , the data data bus dd[31:0] drives out the values stored in its scan cells. if a logic 0 is scanned into dden , dd[31:0] captures the current input values. while debugging, the value placed in the sysspeed control bit determines whether the arm920t synchronizes back to system speed before executing the instruction. after the arm920t has entered debug state, the first time sysspeed is captured and scanned out, its value tells the debugger whether the core has entered debug state due to a breakpoint (sysspeed low), or a watchpoint (sysspeed high). you can have a watchpoint and breakpoint condition occur simultaneously. when a watchpoint condition occurs, the wptandbkpt bit must be examined by the debugger to determine whether the instruction currently in the execute stage of the pipeline is breakpointed. if so, wptandbkpt is high, otherwise it is low. table 9-5 scan chain 1 bit function bit function 67:36 data values dd[0:31] 35:33 control bits dden , wptandbkpt, and sysspeed 32:1 instruction data id[31:0]
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-29 scan chain 2 purpose allows access to the embeddedice hardware registers. the order of the scan chain from tdi to tdo is: read/write register address bits 4 to 0 data values bits 31 to 0. length 38 bits. table 9-6 shows the bit functions of scan chain 2. to access this serial register, scan chain 2 must first be selected using the scan_n tap controller instruction. the tap controller must then be placed in intest mode: no action is taken during capture-dr. during shift-dr, a data value is shifted into the serial register. bits 32 to 36 specify the address of the embeddedice hardware register to be accessed. during update-dr, this register is either read or written depending on the value of bit 37 (0 = read). table 9-6 scan chain 2 bit function bit function 37 read = 0 write = 1 36:32 embeddedice address register 31:0 data values
debug support 9-30 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c scan chain 3 purpose allows the arm920t to control an external boundary scan chain. length user-defined. scan chain 3 is provided so that you can control an optional external boundary scan chain using the arm920t. typically this is used for a scan chain around the pad ring of a packaged device. the following control signals are provided, and are generated only when scan chain 3 is selected. these outputs are inactive at all other times: driveoutbs this switches the scan cells from system mode to test mode. this signal is asserted whenever the intest, extest, clamp, or clampz instruction is selected. pclkbs this is the update clock, generated in the update-dr state. typically the value scanned into the chain is transferred to the cell output on the rising edge of this signal. icapclkbs, ecapclkbs these are the capture clocks used to sample data into the scan cells during intest and extest respectively. these clocks are generated in the capture-dr state. shclk1bs, shclk2bs these are non-overlapping clocks generated in the shift-dr state that are used to clock the master and slave element of the scan cells respectively. when the state machine is not in the shift-dr state, both these clocks are low. nhighz you can use this signal to drive the outputs of the scan cells to the high impedance state. this signal is driven low when the highz instruction is loaded into the instruction register, and high at all other times. in addition to these control outputs, sdin output and sdoutbs input are also provided. when an external scan chain is in use, sdoutbs must be connected to the serial data output and sdin must be connected to the serial data input.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-31 9.6.6 scan chain 6 purpose you use scan chain 6 to program the registers in the etm9. length the chain length is 40 bits, comprising: a 32-bit data field a 7-bit address field a read/write bit. to write an etm9 register: the data to be written is placed in the data field the register address is in the address field the read/write bit is set to 1. to read an etm9 register: the data field is ignored the register address is in the address field the read/write bit is set to 0. the etm9 registers are read or written when the tap controller enters the update-dr state. for more details of the etm9 registers, see the etm9 (rev1) technical reference manual . 9.6.7 scan chains 4 and 15, the arm920t memory system on entry to debug state, the debugger must extract and save the state of cp15. it is advisable that the caches and mmus are then switched off to prevent any debug accesses to memory altering their state. at this point, the debugger can non-invasively determine the state of the memory system. when in debug state, the debugger can see the state of the arm920t memory system. this includes: cp15 caches mmu pa tag ram. scan chains 4 and 15 are reserved for this use.
debug support 9-32 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c scan chain 15 this scan chain is 40 bits long. the format of the scan chain is dependent on the access mode used. the formats for both modes for scan chain 15 are shown in table 9-7. with scan chain 15 selected, tdi is connected to bit 39 and tdo is connected to bit 0. an access using this scan chain allows all of the cp15 registers to be read and written, the cache cam and ram to be read, and the tlb cam and ram to be read. there are two access modes available using scan chain 15. these are: physical access mode interpreted access mode on page 9-34. physical access mode you can do a physical access mode operation using scan chain 15 as follows: 1. in shift-dr, shift in the read/write bit, register address and register value for writing, shown in table 9-8 on page 9-33. 2. move through update-dr. for a write, the register is updated here. 3. for reading, return to shift-dr through capture-dr and shift out the register value. table 9-7 scan chain 15 format and access modes scan chain bit interpreted access mode physical access mode function read/write function read/write 39 0 write nr/w write 38:33 000000 write register address write 32:1 instruction word write register value read/write 0 0 write 1 write
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-33 table 9-8 shows the bit format for scan chain 15 physical access mode operations. the mapping of the 6-bit register address field to the cp15 registers for physical access mode is shown in table 9-9. table 9-8 scan chain 15 physical access mode bit format scan chain bit function read/ write 39 nr/w write 38:33 register address write 32:1 register value read/ write 0 1 write table 9-9 physical access mapping to cp15 registers address register [38] [37:34] [33] number name type 0 0x0 0 c0 id register read 0 0x0 1 c0 cache type read 0 0x1 0 c1 control read/write 0 0x9 0 c9 data cache lockdown read 0 0x9 1 c9 instruction cache lockdown read 0 0xd 0 c13 process id read/write 0 0xf 0 c15.state test state read/write 1 0xd 1 c15.c.i.ind instruction cache index read 1 0xe 1 c15.c.d.ind data cache index read 1 0x1 1 c15.c.i instruction cache read/write 1 0x2 1 c15.c.d data cache read/write 1 0x5 0 c15.m.i instruction mmu read 1 0x6 0 c15.m.d data mmu read
debug support 9-34 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c interpreted access mode you can do an interpreted access mode operation using scan chain 15 as follows: 1. a physical access read-modify-write to c15 (test state) must be done in order to set bit 0, cp15 interpret. 2. the required mcr / mrc instruction word is shifted in to scan chain 15. 3. a system-speed ldr (read) or str (write) is performed on the arm9tdmi. 4. cp15 responds to this ldr / str by executing the coprocessor instruction in its scan chain. 5. in the case of a ldr , the data is returned to the arm9tdmi and can be captured onto scan chain 1 by performing an str . 6. in the case of an str , the interpreted mcr completes with the data that is issued from the arm9tdmi. 7. a physical access read-modify-write to c15 (test state) must be done in order to clear cp15 interpret, bit 0. table 9-10 shows the bit format for scan chain 15 interpreted access mode operations. the mapping of the 32-bit instruction word field to the remaining cp15 registers supported for interpreted access mode is shown in table 9-11 on page 9-35, table 9-12 on page 9-36, and table 9-13 on page 9-36. this supported subset is used for cache and mmu debug operations. using interpreted accesses for other cp15 register operations produces unpredictable behavior. the construction of a cp15 instruction word from arm assembler is shown in figure 2-1 on page 2-7. for the mcr , rd has been replaced by r0, because the register being used as the source data is governed by the str . for the mrc , rd has been replaced by r0, because the register being used as the destination is governed by the ldr . table 9-10 scan chain 15 interpreted access mode bit format scan chain bit function read/ write 39 0 write 38:33 000000 write 32:1 instruction word write 0 0 write
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-35 the mapping of the 32-bit instruction word field to the remaining cp15 registers for interpreted access mode is shown in table 9-11. the construction of a cp15 instruction word from arm assembler is shown in cp15 register map summary on page 2-5. table 9-11 interpreted access mapping to cp15 registers arm920t instruction function rd ra cp15 instruction str rd,[ra] write i ttb ttb - mcr p15,5,r0,c15,c1,2 ldr rd,[ra] read i ttb ttb - mrc p15,5,r0,c15,c1,2 str rd,[ra] write d ttb ttb - mcr p15,5,r0,c15,c2,2 ldr rd,[ra] read d ttb ttb - mrc p15,0,r0,c2,c2,2 str rd,[ra] write i dac dac - mcr p15,5,r0,c15,c1,3 ldr rd,[ra] read i dac dac - mrc p15,5,r0,c15,c1,3 str rd,[ra] write d dac dac - mcr p15,5,r0,c15,c2,3 ldr rd,[ra] read d dac dac - mrc p15,0,r0,c3,c0,0 str rd,[ra] write i fsr fsr - mcr p15,0,r0,c5,c0,1 ldr rd,[ra] read i fsr fsr - mrc p15,0,r0,c5,c0,1 str rd,[ra] write d fsr fsr - mcr p15,0,r0,c5,c0,0 ldr rd,[ra] read d fsr fsr - mrc p15,0,r0,c5,c0,0 str rd,[ra] write i far far - mcr p15,0,r0,c6,c0,1 ldr rd,[ra] read i far far - mrc p15,0,r0,c6,c0,1 str rd,[ra] write d far far - mcr p15,0,r0,c6,c0,0 ldr rd,[ra] read d far far - mrc p15,0,r0,c6,c0,0 str rd,[ra] icache invalidate all - - mcr p15,0,r0,c7,c5,0 str rd,[ra] icache invalidate entry - tag, seg mcr p15,0,r0,c7,c5,1 str rd,[ra] dcache invalidate all - - mcr p15,0,r0,c7,c6,0 str rd,[ra] dcache invalidate entry - tag ,seg mcr p15,0,r0,c7,c6,1 str rd,[ra] write icache victim - victim, seg mcr p15,0,r0,c9,c1,1 str rd,[ra] write dcache victim - victim, seg mcr p15,0,r0,c9,c1,0
debug support 9-36 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c str rd,[ra] write icache victim and lockdown base - victim mcr p15,0,r0,c9,c0,1 str rd,[ra] write dcache victim and lockdown base - victim mcr p15,0,r0,c9,c0,0 str rd,[ra] write i tlb lockdown base,victim - mcr p15,0,r0,c10,c0,1 ldr rd,[ra] read i tlb lockdown base,victim - mrc p15,0,r0,c10,c0,1 str rd,[ra] write d tlb lockdown base,victim - mcr p15,0,r0,c10,c0,0 ldr rd,[ra] read d tlb lockdown base,victim - mrc p15,0,r0,c10,c0,0 table 9-12 interpreted access mapping to the mmu arm920t instruction function rd/rlist ra cp15 instruction ldr rd,[ra] or ldmia ra,[rlist] i cam read mva tag, size, v, p - mcr p15,4,r0,c15,c5,4 ldr rd,[ra] or ldmia ra,[rlist] i ram1 read protection - mcr p15,4,r0,c15,c9,4 ldr rd,[ra]or ldmia ra,[rlist] i ram2 read pa tag, size - mcr p15,4,r0,c15,c1,5 ldr rd,[ra]or ldmia ra,[rlist] d cam read mva tag, size, v, p - mcr p15,4,r0,c15,c6,4 ldr rd,[ra]or ldmia ra,[rlist] d ram1 read protection - mcr p15,4,r0,c15,c10,4 ldr rd,[ra]or ldmia ra,[rlist] d ram2 read pa tag, size - mcr p15,4,r0,c15,c2,5 table 9-13 interpreted access mapping to the caches arm920t instruction function rd/rlist ra cp15 instruction ldr rd,[ra] or ldmia ra,[rlist] i cam read tag, seg, dirty seg mcr p15,2,r0,c15,c5,2 ldr rd,[ra] or ldmia ra,[rlist] i ram read data seg, word mcr p15,2,r0,c15,c9,2 ldr rd,[ra]or ldmia ra,[rlist] d cam read tag, seg ,dirty seg mcr p15,2,r0,c15,c6,2 ldr rd,[ra] or ldmia ra,[rlist] d ram read data seg, word mcr p15,2,r0,c15,c10,2 table 9-11 interpreted access mapping to cp15 registers (continued) arm920t instruction function rd ra cp15 instruction
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-37 debug access to the mmu this is achieved through scan chain 1 and 15, using the physical access and interpreted access modes. the following steps explain how to read the data tlb 1. physical access: read-modify-write cp15, register 1, to turn off both the caches and mmu. 2. physical access: read-modify-write cp15, register 15, to set mmu test and cp15 interpret mode. 3. interpreted access: ldr rd,[ra]. mcr = read d tlb lockdown. this will read the base and victim to rd. 4. physical access: read-modify-write cp15 register 15 to clear cp 15 interpret mode. 5. str of rd loaded in step (3). capture on scan chain 1 and shift out. 6. physical access: read-modify-write cp15 register 15 to set cp15 interpret mode. 7. interpreted access: str rd,[ra]. mcr = write d tlb lockdown, where rd = base[read in (3)], victim[=0]. 8. interpreted access: 8 word ldm, ldmia ra,[rlist]. mcr = d cam read. the cam read will increment the victim pointer on every access, so this will read entries 0-7. 9. physical access: read-modify-write cp15 register 15 to clear cp 15 interpret mode. 10. 8 word stm of the values loaded in step (6). capture these on scan chain 1 and shift out. these 8 values are the cam tag for entries 0-7. 11. physical access: read-modify-write cp15 register 15 to set cp15 interpret mode. 12. repeat steps (8) to (11) eight times to read entries 0-63. 13. interpreted access: str rd,[ra]. mcr = write d tlb lockdown, where rd = base[read in step (3)], victim[=0]. 14. interpreted access: ldr rd,[ra]. mcr = d ram1 read. the ram1 read will increment the victim pointer on every access as mmu test in cp15, register 15, test state register has been set. 15. interpreted access: ldr rd,[ra]. mcr = d ram2 read. this uses a pipelined version of the last ram1 read.
debug support 9-38 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 16. physical access: read-modify-write cp15 register 15 to clear cp 15 interpret mode. 17. 2 word stm of the values loaded in steps (10) and (11). capture these on scan chain 1 and shift out. these 2 values are ram1 and ram2 from entry 0. 18. physical access: read-modify-write cp15 register 15 to set cp15 interpret mode. 19. repeat steps (14) to (18) 64 times to read ram1 and ram2 entries 0-63. 20. interpreted access: str rd,[ra]. mcr = write d tlb lockdown, where rd = base[read in step (3)], victim[read in step (3)]. 21. physical access: read-modify-write cp15, register 15, to clear mmu test and cp15 interpret mode. 22. physical access: read-modify-write cp15, register 1, to turn on (restore state of) both the caches and mmu. debug access to the caches this is achieved through scan chain 1 and 15, using the physical access and interpreted access modes. the following steps explain how to read the dcache. they assume you are trying to read the contents of segment 2 of the dcache. 1. physical access: read-modify-write cp15, register 1, to turn off both the caches and mmu. 2. physical access: read-modify-write cp15, register 15, to set cp15 interpret mode. 3. interpreted access: ldr rd,[ra]. mcr = d cam read, where ra = seg2. this will cause the current victim for segment 2 to be read into c15.c.d.ind. 4. physical access: read c15.c.d.ind which contains the victim of segment 2. 5. interpreted access: str rd,[ra]. mcr = write dcache victim, where ra = victim0, seg2. this sets the victim counter to 0 for segment 2, and configures the counter to increment after a cam read or write. the base remains unchanged. 6. interpreted access: 8 word ldm, ldmia ra,[rlist]. mcr = d ram read, where ra = seg2, word0. the ldmia will increment the word part of the address and move across the cache line from word0 to word7. 7. interpreted access: ldr rd,[ra]. mcr = d cam read, where ra = seg2. 8. physical access: read-modify-write cp15, register 15, to clear cp15 interpret mode.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-39 9. 9 word stm of the values loaded in (6) and (7). capture these on scan chain 1 and shift out. these 9 values are the cam tag and ram cache line data for segment 2, index 0. 10. physical access: read-modify-write cp15, register 15, to set cp15 interpret mode. 11. increment the victim (+1) and repeat steps (5) to (10) 64 times. this approach avoids using the auto increment capability of the victim counter. if the auto increment capability is used, the victim counter will loop back to the base value when it reaches 63, so either the victim must start at 0, or the base must be read, set to 0, then restored after reading the memory.by starting the victim at 0, repeat steps (6) to (10) 64 times. 12. interpreted access: str rd,[ra]. mcr = write dcache victim, where ra = victim, seg2. the victim value should be the value read and saved in step (5). 13. repeat steps (3) to (12) for each segment. 14. physical access: read-modify-write cp15, register 15, to clear cp15 interpret mode. 15. physical access: read-modify-write cp15, register 1, to turn on (restore state of) both the caches and mmu. scan chain 4 - debug access to the pa tag ram this scan chain is 49 bits long, as shown in table 9-14. table 9-14 scan chain 4 format scan chain bit function read/ write 48 pa tag sel tck write 47 ram enable write 46 odd not even write 45:40 scan index [5:0] write 39:33 scan seg [6:0] write 32 pa tag sync tck read 31:0 wbpa read
debug support 9-40 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c with scan chain 4 selected, tdi is connected to bit 48 and tdo is connected to bit 0. an access using this scan chain allows the physical address tag ram to be read. figure 9-7 shows the construction of write back physical addresses. figure 9-7 write back physical address format note although scan seg [6:0] is provided, only bits [2:0] are used in arm920t to address segments 0-7. bits [6:3] are defined for forwards compatibility. to read an entry in the pa tag ram, you must execute the following sequence: 1. write: pa tag sel tck = 1 ram enable = 0. this synchronizes the pa tag ram to tck , the test clock. 2. read pa tag sync tck until it is 1. this confirms that the pa tag ram is synchronized to tck. 3. write: pa tag sel tck = 1 ram enable = 1 odd not even scan index bits [5:0] scan seg bits [2:0]. 31 6543 0 pa tag 0000 scan seg[0] odd not even
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-41 4. go through the update-dr state of the arm920t tap controller three times. the most efficient way of doing this, after doing the write in step 3 is to go through the following sequence. this avoids rewriting the values in step 3 on each iteration: a. exit1-dr b. update-dr c. select-dr-scan d. capture-dr e. repeat (a) to (d) x 2 f. shift-dr. the pa tag ram requires three clock cycles to perform the read. its clock is cycled in update-dr, and therefore this state must be passed through three times. 5. read the write back physical address (wbpa). 6. write: pa tag sel tck = 0 ram enable = 0. resynchronize the pa tag ram to the system clock. 7. read pa tag sync tck until it is 0. this confirms that resynchronization has occurred. you must repeat this sequence of steps (1 to 7) for the eight segments, corresponding to the eight dcache segments, and the 64 entries per segment, corresponding to the 64 entries in each dcache segment.
debug support 9-42 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.7 arm920t core clocks the arm9tdmi core has two clocks: the memory clock gclk an internally tck generated clock, dclk . during normal operation, the core is clocked by gclk , and internal logic holds dclk low. when the arm920t is in the debug state, the core is clocked by dclk under control of the tap state machine, and gclk can free run. the selected clock is output on the eclk signal for use by the external system. note when the core is being debugged and is running from dclk , nwait has no effect. the two cases where the clocks switch are: during debugging during testing.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-43 9.8 clock switching during debug when the arm9tdmi core enters debug state, it must switch from gclk to dclk . this is handled automatically by logic in the arm9tdmi core. on entry to debug state, the arm9tdmi asserts dbgack in the high phase of gclk . the switch between the two clocks occurs on the next falling edge of gclk as shown in figure 9-8. figure 9-8 clock switching on entry to debug state the arm9tdmi core is forced to use dclk as the primary clock until debugging is complete. on exit from debug, the core must be allowed to synchronize back to gclk . you must do this in the following sequence: 1. shift the final instruction of the debug sequence into the instruction data bus scan chain, and clock it in by asserting dclk . at this point, clock restart into the tap controller register. 2. the arm9tdmi core now automatically resynchronizes back to gclk when the tap controller enters the run-test/idle mode and starts fetching instructions from memory at gclk speed. for more information, see exit from debug state on page 9-48. gclk dbgack eclk dclk
debug support 9-44 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.9 clock switching during test under serial test conditions, when test patterns are being applied to the core through the jtag interface, the arm9tdmi cpu core must be clocked using dclk . entry into test is less automatic than debug and some care must be taken. on the way into test, gclk must be held low. you can now use the tap controller to perform serial testing on the arm9tdmi core. if scan chain 0 and intest are selected, dclk is generated while the state machine is in run-test/idle state. during extest, dclk is not generated. on exit from test, you must select restart as the tap controller instruction. when this is done, you can allow gclk to resume. after intest testing, you must take care to ensure that the core is in a sensible state before switching back. the safest way to do this is either: select restart and then cause a system reset insert mov pc,#0 into the instruction pipeline before switching back.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-45 9.10 determining the core state and system state when the arm9tdmi core is in debug state, you can examine the core state and system state. you can do this by forcing load and store multiples into the pipeline. before you can examine the core state and system state, the debugger must first determine whether the processor entered debug from thumb state or arm state. you can do this by examining bit 4 of the embeddedice macrocell debug status register. if this is high, the core is in thumb state. if it is low, the core is in arm state. 9.10.1 determining the core state if the processor has entered debug state from thumb state, it is easiest for the debugger to force the core back into arm state. when this is done, the debugger can execute the same sequence of instructions to determine the processor state. to force the processor into arm state, the following sequence of thumb instructions can be executed on the core: str r0, [r1] ; save r0 before use mov r0, pc ; copy pc into r0 str r0, [r1] ; save the pc in r0 bx pc ; jump into arm state mov r8, r8 ; nop (no operation) mov r8, r8 ; nop the above use of r1 as the base register for stores is for illustration only. you can use any register. because all thumb instructions are only 16 bits long, you can duplicate the instruction in the instruction data bus bits, when shifting them into scan chain 1. for example, the encoding for bx r0 is 0x4700 . therefore, if 0x47004700 is shifted into the 32 bits of the instruction data bus of scan chain 1, the debugger does not have to remember the half of the bus that the processor expects to read instructions from. from this point, you can determine the processor state by the following series of steps of arm instructions. when the processor is in arm state, typically the first instruction executed is: stm r0, {r0-r15} this causes the contents of the registers to be made visible on the data data bus. these values can then be sampled and shifted out.
debug support 9-46 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c after determining the values in the current bank of registers, you might want to access the banked registers. this can only be done by changing mode. normally, a mode change can only occur if the core is already in a privileged mode. however, while in debug state, a mode change can occur from any mode into any other mode. note the debugger must restore the original mode before exiting debug state. for example, assume that the debugger has been asked to return the state of the user mode and fiq mode registers, and debug state has been entered in supervisor mode. the instruction sequence might be: stmia r0, {r0-r15} ; save current registers mrs r0, cpsr str r0, [r0] ; save cpsr to determine current mode bic r0, r0, #0x1f ; clear mode bits orr r0, r0, #0x10 ; select user mode msr cpsr, r0 ; enter user mode stmia r0, {r13-r14} ; save registers not previously visible orr r0, r0, #0x01 ; select fiq mode msr cpsr, r0 ; enter fiq mode stmia r0, {r8-r14} ; save banked fiq registers all these instructions are said to execute at debug speed . debug speed is much slower than system speed because, between each core clock, 67 scan clocks occur in order to shift in an instruction or shift out data. executing instructions more slowly than usual is fine for accessing the core state because the arm920t is fully static. however, you cannot use this same method for determining the state of the rest of the system. while in debug state, only the following instructions can be inserted into the instruction pipeline for execution: all data processing operations all load, store, load multiple, and store multiple instructions msr and mrs .
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-47 9.10.2 determining system state to meet the dynamic timing requirements of the memory system, any attempt to access system state must occur synchronously. therefore, you must force the arm9tdmi core to synchronize back to system speed. the 33rd bit of scan chain 1, sysspeed, controls this. you can place a legal debug instruction in the instruction data bus of scan chain 1 with bit 33 (the sysspeed bit) low. this instruction is then executed at debug speed. to execute an instruction at system speed, a nop (such as mov r0, r0 ) must be scanned in as the next instruction with bit 33 set high. after the system speed instructions have been scanned into the instruction data bus and clocked into the pipeline, you must load the restart instruction into the tap controller. this causes the arm9tdmi automatically to resynchronize back to gclk when the tap controller enters run-test/idle state, and execute the instruction at system speed. debug state is re-entered after the instruction completes execution, when the processor switches itself back to the internally generated dclk . when the instruction has completed, dbgack is high. at this point intest can be selected in the tap controller, and debugging can resume. to determine whether a system speed instruction has completed, the debugger must look at syscomp (bit 3 of the debug status register). to access memory, the arm9tdmi must access memory through the data data bus interface, as this access can be stalled indefinitely by nwait . therefore, the only way to determine whether the memory access has completed is to examine the syscomp bit. when this bit is high the instruction has completed. the state of the system memory can be passed to the debug host by using system speed load multiples and debug store multiples. 9.10.3 instructions that can have the sysspeed bit set the only valid instructions to set this bit for are: loads stores load multiple store multiple. when the arm9tdmi returns to debug state after a system speed access, the sysspeed bit is set high.
debug support 9-48 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.11 exit from debug state leaving debug state involves restoring the internal state of the arm9tdmi core, causing a branch to the next instruction to be executed, and synchronizing back to gclk . after restoring the internal state, you must load a branch instruction into the pipeline. for details on calculating the branch, see the behavior of the program counter during debug on page 9-51. use bit 33 of scan chain 1 to force the arm9tdmi core to resynchronize back to gclk . the penultimate instruction in the debug sequence is a branch to the instruction where execution is to resume. this is scanned in with bit 33 set low. the core is then clocked to load the branch into the pipeline. the final instruction that you must scan in is a nop (such as mov r0, r0 ), with bit 33 set high. you must the clock the core to load this instruction into the pipeline. now, select the restart instruction in the tap controller. when the state machine enters the run-test/idle state, the scan chain reverts back to system mode and clock resynchronization to gclk occurs within the arm9tdmi. normal operation resumes, with instructions being fetched from memory. the delay, until the state machine is in run-test/idle state, allows you to set up conditions in other devices in a multiprocessor system without taking immediate effect. then, when run-test/idle state is entered, all the processors resume operation simultaneously. the function of dbgack is to tell the rest of the system when the arm9tdmi core is in debug state. you can use this to inhibit peripherals such as watchdog timers that have real-time characteristics. also, you can use dbgack to mask out memory accesses that are caused by the debugging process. for example, when the arm9tdmi core enters debug state after a breakpoint, the instruction pipeline contains the breakpointed instruction plus two other instructions that have been prefetched. on entry to debug state, the pipeline is flushed. so, on exit from debug state, the pipeline must be refilled to its previous state. therefore, because of the debugging process, more memory accesses occur than are normally expected. you can inhibit any system peripheral that might be sensitive to the number of memory accesses by using dbgack . note dbgack can only be used in this way using breakpoints. it does not mask the correct number of memory accesses after a watchpoint. for example, consider a peripheral that merely counts the number of instruction fetches. this device must return the same answer after a program has run both with and without debugging. figure 9-9 on page 9-49 shows the behavior of the arm9tdmi core on exit from debug state.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-49 figure 9-9 debug exit sequence figure 9-10 on page 9-50 shows that two instructions are fetched after the instruction that breakpoints. figure 9-10 on page 9-50 shows that dbgack masks the first three instruction fetches out of the debug state, corresponding to the breakpoint instruction, and the two instructions prefetched after it. note when a system speed access occurs, dbgack remains high, masking any memory access. iab iab+4 iab+8 id[31:0] eclk inmreq iseq ia[31:1] dbgack nss internal cycles
debug support 9-50 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 9-10 debug state entry gclk id[31:0] inmreq iseq ia[31:1] dbgack memory cycles internal cycles iebkpt 1 2 3
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-51 9.12 the behavior of the program counter during debug to force the arm9tdmi core to branch back to the place where program flow is interrupted by debug, the debugger must keep track of what happens to the pc. there are six cases: breakpoint on page 9-51 watchpoint on page 9-51 watchpoint with another exception on page 9-52 watchpoint and breakpoint on page 9-52 debug request on page 9-52 system speed accesses on page 9-53. in each case the same equation is used to determine where to resume execution. 9.12.1 breakpoint entry to debug state from a breakpointed instruction advances the pc by 16 bytes in arm state, or 8 bytes in thumb state. each instruction executed in debug state advances the pc by one address. the normal way to exit from debug state after a breakpoint is to remove the breakpoint, and branch back to the previously breakpointed address. for example, if the arm9tdmi core entered debug state from a breakpoint set on a given address and two debug speed instructions were executed, a branch of 7 addresses must occur (four for debug entry, plus two for the instructions, plus one for the final branch). the following sequence shows arm instructions scanned into scan chain 1. this is most significant bit (msb) first, so the first digit represents the value to be scanned into the sysspeed bit, followed by the instruction. 0 eafffff9 ; b -7 addresses (twos complement) 1 e1a00000 ; nop (mov r0, r0), sysspeed bit is set for small branches, the final branch can be replaced with a subtract, with the pc as the destination. for example, sub pc, pc, #28 for arm code. 9.12.2 watchpoint you can return to program execution after entering debug state from a watchpoint in the same way as the procedure described in breakpoint above. debug entry adds four addresses to the pc, and every instruction adds one address. because the instruction after the one that caused the watchpoint has executed, execution resumes at the following instruction.
debug support 9-52 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.12.3 watchpoint with another exception if a watchpoint access simultaneously causes a data abort, the arm9tdmi core enters debug state in abort mode. entry into debug is held off until the core has changed into abort mode, and fetched the instruction from the abort vector. a similar sequence is followed when an interrupt, or any other exception, occurs during a watchpointed memory access. the arm9tdmi core enters debug state in the mode of the exception, and so the debugger must check to see whether this happened. the debugger can deduce whether an exception occurred by looking at the current and previous mode, (in the cpsr and spsr), and the value of the pc. if an exception did take place, you must have the choice to service the exception before debugging or not. for example, suppose an abort occurred on a watchpoint access, and ten instructions had been executed to determine this. you can use the following sequence to return to program execution: 0 eafffff1 ; b -15 addresses (twos complement) 1 e1a00000 ; nop (mov r0, r0), sysspeed bit is set this forces a branch back to the abort vector, causing the instructions at that location to be refetched and executed. after the abort service routine, the instruction that caused the abort and watchpoint is re-executed. this causes the watchpoint to be generated and the arm9tdmi enters debug state again. 9.12.4 watchpoint and breakpoint it is possible to have a watchpoint and breakpoint condition occurring simultaneously. this can happen when an instruction causes a watchpoint, and the following instruction has been breakpointed. the same calculation must be performed as for breakpoint on page 9-51 to determine where to resume. in this case, it is at the breakpoint instruction, because this has not been executed. 9.12.5 debug request entry into debug state as a result of a debug request is similar to a breakpoint and, as for breakpoint entry to debug state, adds four addresses to the pc, and every instruction executed in debug state adds one. for example, the following sequence handles a situation where a debug request has been invoked, followed by a decision to return to program execution immediately: 0 eafffffb ; b -5 addresses (twos complement) 1 e1a00000 ; nop (mov r0, r0), sysspeed bit is set this restores the pc, and restarts the program from the next instruction.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-53 9.12.6 system speed accesses if a system speed access is performed during debug state, the value of the pc is increased by five addresses. because system speed instructions access the memory system, it is possible for aborts to take place. if an abort occurs during a system speed memory access, the arm9tdmi core enters abort mode before returning to debug state. this is similar to an aborted watchpoint. however, the problem is much harder to fix because the abort is not caused by an instruction in the main program, and the pc does not point to the instruction that caused the abort. an abort handler usually looks at the pc to determine the instruction that caused the abort, and therefore the abort address. in this case, the value of the pc is invalid, but the debugger knows the address of the location being accessed. therefore the debugger can be written to help the abort handler fix the memory system. 9.12.7 summary of return address calculations the calculation of the branch return address can be summarized as: -(4 + n +5s) where n is the number of debug speed instructions executed (including the final branch), and s is the number of system speed instructions executed.
debug support 9-54 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.13 embeddedice macrocell the embeddedice macrocell is integral to the arm9tdmi processor core. it has two hardware breakpoint or watchpoint units. you can configure each of them to monitor the instruction memory interface or the data memory interface. each watchpoint unit has a value and mask register, with an address field, a data field, and a control field. because the arm9tdmi processor core has a harvard architecture, you must specify whether the watchpoint registers examine the instruction or the data interface. this is specified by bit 3: when bit 3 is set, the data interface is examined when bit 3 is clear, the instruction interface is examined. there can be no don ? t care case for this bit because the comparators cannot compare the values on both buses simultaneously. therefore, bit 3 of the control mask register is always clear and cannot be programmed high. bit 3 also determines whether the internal breakpoint or watchpoint signal must be driven by the result of the comparison. figure 9-11 on page 9-56 gives an overview of the operation of the embeddedice macrocell. the arm9tdmi embeddedice macrocell has logic that allows single stepping through code. this reduces the work required by an external debugger, and removes the requirement to flush the instruction cache. there is also hardware to allow efficient trapping of accesses to the exception vectors. these blocks of logic free the two general-purpose hardware breakpoint or watchpoint units for use by the programmer at all times. 9.13.1 register map the embeddedice macrocell register map is shown in table 9-15. table 9-15 arm9tdmi embeddedice macrocell register map address width function 00000 4 debug control 00001 5 debug status 00010 8 vector catch control 00100 6 debug comms control 00101 32 debug comms data 01000 32 watchpoint 0 address value
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-55 the general arrangement of the embeddedice macrocell is shown in figure 9-11 on page 9-56. 01001 32 watchpoint 0 address mask 01010 32 watchpoint 0 data value 01011 32 watchpoint 0 data mask 01100 9 watchpoint 0 control value 01101 8 watchpoint 0 control mask 10000 32 watchpoint 1 address value 10001 32 watchpoint 1 address mask 10010 32 watchpoint 1 data value 10011 32 watchpoint 1 data mask 10100 9 watchpoint 1 control value 10101 8 watchpoint 1 control mask table 9-15 arm9tdmi embeddedice macrocell register map (continued) address width function
debug support 9-56 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 9-11 arm9tdmi embeddedice macrocell overview as an example, if a watchpoint is requested on a particular memory location but the data value is irrelevant, you can program the data mask register to 0xffff_ffff , all bits set to 1. this ensures that the entire data bus value is ignored. 9.13.2 using the mask registers for each value register there is an associated mask register in the same format. setting a bit to 1 in the mask register causes the corresponding bit in the value register to be ignored in any comparison. 9.13.3 control registers the format of the control registers depends on how bit 3 is programmed. if bit 3 is programmed to be 1, the breakpoint comparators examine the data address, and data and control signals. in this case, the format of the register is as shown in figure 9-12 on page 9-57. 0 31 0 4 rangeout enable 5 breakpoint scan chain register tdi tdo update value mask comparator ia[31:0] registers address data control address data control address data control address decoder 32 r/w da[31:0] id[31:0] dd[31:0] i control d control address data
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-57 figure 9-12 watchpoint control register for data comparison note bit 8 and bit 3 cannot be masked. the functions of the watchpoint control register for data comparison bits are shown in table 9-16. 76543210 enable range chain extern dntrans 1 dmas[1] dnrw dmas[0] 8 table 9-16 watchpoint control register, data comparison bit functions bit name function 8 enable if a watchpoint match occurs, the internal watchpoint signal is only asserted when the enable bit is set. this bit only exists in the value register. it cannot be masked. 7 range you can connect this bit to the range output of another watchpoint register. in the arm9tdmi embeddedice macrocell, the address comparator output of watchpoint 1 is connected to the range input of watchpoint 0. this allows you to couple two watchpoints for detecting conditions that occur simultaneously, for example, for range-checking. 6 chain you can connect this bit to chain output of another watchpoint to implement, for example, debugger requests of the form breakpoint on address yyy only when in process xxx . in the arm9tdmi embeddedice macrocell, the chainout output of watchpoint 1 is connected to the chain input of watchpoint 0. the chainout output is derived from a latch. the address and control field comparator drives the write enable for the latch and the input to the latch is the value of the data field comparator. the chainout latch is cleared when the control value register is written or when ntrst is low. 5 extern this is an external input into the embeddedice macrocell that allows the watchpoint to be dependent on some external condition. the extern input for watchpoint 0 is labeled extern0 , and the extern input for watchpoint 1 is labeled extern1 .
debug support 9-58 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c if bit 3 of the control register is programmed to 0, the comparators examine the instruction address, instruction data, and instruction control buses. in this case bits [1:0] of the mask register must be set to don ? t care (programmed to 11). the format of the register in this case is as shown in figure 9-13. figure 9-13 watchpoint control register for instruction comparison 4 dntrans this bit is compared with the data not translate signal from the core in order to determine between a user mode (dntrans = 0) data transfer, and a privileged mode ( dntrans = 1) transfer. 2:1 dmas[1:0] these bits are compared with the dmas[1:0] signal from the core in order to detect the size of the data data bus activity. 0 dnrw this bit is compared with the data not read/write signal from the core in order to detect the direction of the data data bus activity. nrw is 0 for a read, and 1 for a write. table 9-16 watchpoint control register, data comparison bit functions (continued) bit name function 76543210 enable range chain extern intrans 0 x x itbit 8
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-59 the functions of the watchpoint control register for instruction comparison bits are shown in table 9-17. table 9-17 watchpoint control register for instruction comparison bit functions bit name function 8 enable if a watchpoint match occurs, the internal breakpoint signal is only asserted when the enable bit is set. this bit only exists in the value register, it cannot be masked. 7 range you can connect this bit to the range output of another watchpoint register. in the arm9tdmi embeddedice macrocell, the address comparator output of watchpoint 1 is connected to the range input of watchpoint 0. this allows you to couple two watchpoints for detecting conditions that occur simultaneously, for example, for range-checking. 6 chain you can connect this bit to chain output of another watchpoint to implement, for example, debugger requests of the form breakpoint on address yyy only when in process xxx . in the arm9tdmi embeddedice macrocell, the chainout output of watchpoint 1 is connected to the chain input of watchpoint 0. the chainout output is derived from a latch. the address or control field comparator drives the write enable for the latch, and the input to the latch is the value of the data field comparator. the chainout latch is cleared when the control value register is written, or when ntrst is low. 5 extern this is an external input into the arm9tdmi embeddedice macrocell that allows the watchpoint to be dependent on some external condition. the extern input for watchpoint 0 is labeled extern0 , and the extern input for watchpoint 1 is labeled extern1 . 4 intrans this bit is compared with the not translate signal from the core in order to determine between a user mode ( intrans = 0) instruction fetch, and a privileged mode ( intrans = 1) instruction fetch. 1 itbit this bit is compared with the thumb state signal from the core to determine between a thumb ( itbit = 1) instruction fetch or an arm ( itbit = 0) instruction fetch.
debug support 9-60 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.13.4 debug control register the arm9tdmi debug control register is four bits wide and is shown in figure 9-14. figure 9-14 debug control register bit 3 controls the single-step hardware. this is explained in more detail in figure 9-17 on page 9-64. 9.13.5 debug status register the debug status register is five bits wide. if this register is accessed for a write (with the read/write bit set high), the status bits are written. if it is accessed for a read (with the read/write bit low), the status bits are read. figure 9-15 debug status register the function of the bits in the debug status register are shown in table 9-18. 3210 single step intdis dbgrq dbgack 76543210 8 itbit syscomp ifen dbgrq dbgack 4 3 2 1 0 table 9-18 debug status register bit functions bits function 4allows itbit to be read. this enables the debugger to determine what state the processor is in, and therefore determine the instructions to execute. 3 allows the state of the syscomp bit from the core (synchronized to tck ) to be read. this allows the debugger to determine that a memory access from the debug state has completed.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-61 9.13.6 vector catch register the arm9tdmi embeddedice macrocell controls logic to enable accesses to the exception vectors to be trapped in an efficient manner. this is controlled by the vector catch register, as shown in figure 9-16. the functionality is described in vector catching on page 9-62. figure 9-16 vector catch register 2 allows the state of the core interrupt enable signal, ifen , to be read. because the capture clock for the scan chain might be asynchronous to the processor clock, the dbgack output from the core is synchronized before being used to generate the ifen status bit. 1:0 allow the values on the synchronized versions of dbgrq and dbgack to be read. table 9-18 debug status register bit functions (continued) bits function 76543210 fiq irq reserved d_abort p_abort swi undefined reset
debug support 9-62 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.14 vector catching the arm9tdmi embeddedice macrocell contains logic that allows efficient trapping of fetches from the vectors during exceptions. this is controlled by the vector catch register. if one of the bits in this register is set high and the corresponding exception occurs, the processor enters debug state as if a breakpoint has been set on an instruction fetch from the relevant exception vector. for example, if the processor executes a swi instruction while bit 2 of the vector catch register is set, the arm9tdmi core fetches an instruction from location 0x8 . the vector catch hardware detects this access and forces the arm9tdmi cpu core to enter debug state. the behavior of the hardware is independent of the watchpoint comparators, leaving them free for general use. the vector catch register is sensitive only to fetches from the vectors during exception entry. therefore, if code branches to an address within the vectors during normal operation, and the corresponding bit in the vector catch register is set, the processor is not forced to enter debug state.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-63 9.15 single-stepping the arm9tdmi embeddedice macrocell contains logic that allows efficient single-stepping through code. this leaves the macrocell watchpoint comparators free for general use. this function is enabled by setting bit 3 of the debug control register. you must only alter the state of this bit while the processor is in debug state. if the processor exits debug state and this bit is high, the processor fetches an instruction, executes it, and then immediately re-enters debug state. this happens independently of the watchpoint comparators. if a system-speed data access is performed while in debug state, the debugger must ensure that the control bit is clear first.
debug support 9-64 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.16 debug communications channel the arm9tdmi embeddedice macrocell contains a communication channel for passing information between the target and the host debugger. this is implemented as coprocessor 14. the communications channel consists of: a 32-bit wide comms data read register a 32-bit wide comms data write register a 6-bit wide comms control register for synchronized handshaking between the processor and the asynchronous debugger. these registers are in fixed locations in the embeddedice register map, as shown in figure 9-11 on page 9-56. you can access the registers from the processor using mcr and mrc instructions to coprocessor 14. 9.16.1 debug comms channel register the debug comms control register is read-only, and allows synchronized handshaking between the processor and the debugger. the format of the debug comms control register is shown in figure 9-17. figure 9-17 debug comms control register 31 30 29 28 27 210 r 0 w 0 01
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-65 the function of each register bit is described in table 9-19. from the perspective of the debugger, the registers are accessed using the scan chain in the usual way. from the processor, these registers are accessed using coprocessor register transfer instructions. you can use the following instructions: mrc p14, 0, rd, c0, c0 ; returns the debug comms control register into rd. mcr p14, 0, rn, c1, c0 ; writes the value in rn to the comms data write register. mrc p14, 0, rd, c1, c0 ; returns the debug data read register into rd. note the thumb instruction set does not support coprocessors so the arm9tdmi must be operated in arm state to access the debug comms channel. table 9-19 debug comms control register bit functions bits function 31:28 contain a fixed pattern that denotes the embeddedice macrocell version number, in this case 0b0010. 27:2 unused. 1 denotes, as seen by the processor, whether the comms data write register is free. if, as seen by the processor, the comms data write register is free (w=0), new data can be written. if it is not free (w=1), the processor must poll until w=0. if, as seen by the debugger, w=1, some new data has been written that can then be scanned out. 0 denotes whether there is some new data in the comms data read register. if, as seen by the processor, r=1, there is some new data that can be read using an mrc instruction. if, as seen by the debugger, r=0, the comms data read register is free and new data can be placed there through the scan chain. if r=1, this denotes that data previously placed there through the scan chain has not been collected by the processor, and so the debugger must wait.
debug support 9-66 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 9.16.2 communications using the comms channel there are two methods of communicating using the comms channel: transmitting receiving. sending a message to the debugger and receiving a message from the debugger detail their usage. sending a message to the debugger when the processor wishes to send a message to the debugger, it must check that the comms data write register is free for use by finding out if the w bit of the debug comms control register is clear: if the w bit is set, previously written data has not been read by the debugger. the processor must continue to poll the control register until the w bit is clear. if w bit is clear, the comms data write register is clear. when the w bit is clear, a message can be written by a register transfer to coprocessor 14. as the data transfer occurs from the processor to the comms data write register, the w bit is set in the debug comms control register. the debugger sees a synchronized version of both the r and w bit when it polls the debug comms control register through the jtag interface. when the debugger sees the w bit is set, it can read the comms data write register and scan the data out. the action of reading this data register clears the debug comms control register w bit. at this point, the communications process can begin again. as an alternative to polling, the debug comms channel can be interrupt driven by connecting the arm920t commrx and commtx signals to the systems interrupt controller. receiving a message from the debugger message transfer from the debugger to the processor is similar to sending a message to the debugger. in this case, the debugger polls the r bit of the debug comms control register: if the r bit is low, the comms data read register is free, and data can be placed there for the processor to read if the r bit is set, previously deposited data has not yet been collected, so the debugger must wait.
debug support arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 9-67 when the comms data read register is free, data can be written using the jtag interface. the action of this write sets the r bit in the debug comms control register. when the processor polls this register, it sees a gclk synchronized version. if the r bit is set, there is data waiting to be collected. you can read this data read using an mrc instruction to coprocessor 14. the action of this load clears the r bit in the debug comms control register. when the debugger polls this register and sees that the r bit is clear, the data has been taken, and the process can now be repeated.
debug support 9-68 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 10-1 chapter 10 trackingice this chapter describes how the arm920t processor uses trackingice mode. it contains the following sections: about trackingice on page 10-2 timing requirements on page 10-3 trackingice outputs on page 10-4.
trackingice 10-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 10.1 about trackingice when in trackingice mode, several arm920t outputs track the inputs to the arm9tdmi processor core embedded within the arm920t processor. you can then connect an arm9tdmi test chip to the outputs. this precisely tracks the arm9tdmi processor core inside the arm920t, enabling all outputs of the arm9tdmi core to be observed. figure 10-1 shows how a tracking arm9tdmi processor is attached to an arm920t processor. figure 10-1 using trackingice the tracking arm9tdmi processor operates one clock phase behind the actual arm9tdmi core (on the inverted clock). all required inputs to the arm9tdmi core are latched inside the arm920t processor and are then brought out on various outputs. you can attach the tracking arm9tdmi processor to these outputs. 0 1 arm920t 1 track arm9tdmi arm9tdmi
trackingice arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 10-3 10.2 timing requirements to enable the arm9tdmi processor core to be tracked correctly, all inputs must be synchronous to the arm9tdmi processor clock. these inputs include tck , that in tracking mode is latched on the falling edge of gclk before it is driven onto the arm920t tracking outputs. all other tck relative signals, tdi , tms , and sdoutbs, are latched on rising gclk before they are driven onto the arm920t tracking outputs.
trackingice 10-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 10.3 trackingice outputs table 10-1 shows the arm920t outputs that are re-used when the arm920t processor is in trackingice mode. table 10-1 arm920t in trackingice mode arm920t output attach to tracking arm9tdmi input ir[3:2] chse[1:0] ir[1:0] chsd[1:0] screg[4] nirq screg[3] nfiq screg[2] dabort screg[1] iabort tapsm[3] extern1 tapsm[2] extern0 tapsm[1] dewpt tapsm[0 ] i ebk pt icapclkbs hivecs ecapclkbs edbggq pclkbs nwait rstclkbs nreset shclk1bs tdi shclk2bs tms tck1 gclk tck2 tck sdin sdoutbs
trackingice arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 10-5 the remaining input connections to the arm9tdmi core are: id bus attaches to the cpid bus dd bus attaches to the cpdout bus bigend input attaches to the bigendout . these can still be attached to a coprocessor when the arm920t processor is in tracking mode. the only difference in behavior is that cpdout mirrors the arm920t dd bus on every cycle, not only for coprocessor data transfers. the following conditions apply: the isync and ntrst inputs must be common between the arm920t and the tracking arm9tdmi processor. iabe and dabe of the tracking arm9tdmi processor must be high so that the address outputs can be observed. ddbe of the tracking arm9tdmi processor must be low to prevent a drive clash on the bidirectional dd bus. it is not necessary for the tracking arm9tdmi to drive the dd bus because cpdout is driven with the data from all memory access cycles.
trackingice 10-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-1 chapter 11 amba test interface this chapter examines the arm920t amba test interface. it contains the following sections: about the amba test interface on page 11-2 entering and exiting amba test on page 11-3 functional test on page 11-4 burst operations on page 11-11 pa tag ram test on page 11-12 cache test on page 11-15 mmu test on page 11-19.
amba test interface 11-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 11.1 about the amba test interface you can use the arm920t processor as an amba revision d compliant asb slave for amba testing. the address space of the arm920t slave state machine (ssm) is from to , word-aligned. the base address is specific to the implementation of the amba decoder. in this chapter is assumed to be 0x0 . operation of the ssm is address mapped. this chapter explains the address mapping of ain for arm920t amba test.
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-3 11.2 entering and exiting amba test six test modes exist: functional test pa tag ram test instruction mmu test data mmu test instruction cache test data cache test. the address of the state location is 0x0 . a write to this location changes the test mode, as shown in table 11-1. an example tif file is shown in example 11-1. example 11-1 example tif (test input file) ; address state location a 00000000 ; enter functional test mode w 00000001 ; address state location a 00000000 ; exit test mode w 00000000 e zzzzzzzz table 11-1 amba test modes test mode write data exit test 0x0 functional test 0x1 pa tag ram tes t 0x2 instruction mmu test 0x3 data mmu test 0x4 instruction cache test 0x5 data cache test 0x6
amba test interface 11-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 11.3 functional test in amba functional test mode, the ssm disconnects the functional arm920t from its inputs and disables its output drivers. the ssm provides locations that can be accessed by the tester. there are 9 locations that can be accessed in functional test mode: 3 write locations 6 read locations. these are bit-mapped to ain[10:2] as shown in table 11-2. note tapid[31:0] and etm , the arm920t trace interface port, are not accessible in this test mode table 11-2 amba functional test locations ain bit location read/ write data 10 cpdin write 31:0 9 a920inputs write 31:0 8 din write 31:0 7 dout read 31:0 6 cpdout read 31:0 5 cpid read 31:0 4 a920status1 read 21:0 3 a920status2 read 31:0 2 aout read 31:0
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-5 the a920inputs location, shown in table 11-12 on page 11-16, is constructed as shown in table 11-3. table 11-3 construction of a920inputs location a920 inputs bit signal 31 agnt 30 waitin 29 errorin 28 lastin 27 bnres 26 fclk 25:20 0 19 vinithi 18 nfiq 17 nirq 16 isync 15:14 chsde[1:0] 13:12 chsex[1:0] 11 track 10 iebkpt 9 dewpt 8 edbgrq 7 extern0 6 extern1 5 tck 4 tdi 3 tms
amba test interface 11-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the a920status1 location, shown in table 11-2 on page 11-4, is constructed as shown in table 11-4. 2 ntrst 1 sdoutbs 0 dbgen table 11-4 construction of a920status1 location a920status1 bits signal 21 writeout 20:19 size 18:17 prot[1:0] 16:15 burst[1:0] 14 areq 13 lok 12 tran 11 enba 10 enbd 9 fclkout 8 cpclk 7 ncpwait 6 ncpmreq 5 cppass 4 cplatecancel 3 cptbit table 11-3 construction of a920inputs location (continued) a920 inputs bit signal
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-7 the a920status2 location, shown in table 11-2 on page 11-4, is constructed as shown in table 11-5. 2 ncptrans 1 bigendout 0 instrexec table 11-5 construction of a920status2 location a920status2 bits signal 31 driveoutbs 30 dbgack 29 eclk 28:25 ir[3:0] 24 rangeout0 23 rangeout1 22:18 screg[4:0] 17:14 tapsm[3:0 ] 13 tdo 12 ntdoen 11 sdin 10 shclk1bs 9 shclk2bs 8 icapclkbs 7 ecapclkbs 6 pclkbs 5 tck1 table 11-4 construction of a920status1 location (continued) a920status1 bits signal
amba test interface 11-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c you can update and examine the inputs and outputs of the arm920t on a per-cycle basis by writing to the input locations and reading from the output locations. the functional arm920t is clocked after every sequence of writes. this means that for every cycle, at least one location must be written to (usually a920inputs ), but no locations have to be read. a typical amba test iterates the sequence: address locations to be written and read write input locations read output locations turnaround vector. when the locations have been addressed, they are sequenced through in the order shown in figure 11-1 on page 11-9. 4 tck2 3 rstclkbs 2 commrx 1 commtx 0 dbgrqi table 11-5 construction of a920status2 location (continued) a920status2 bits signal
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-9 figure 11-1 amba functional test state machine 11.3.1 creating an arm920t amba functional test the steps required to write a tif (test input format) file are: 1. run an assembler program on a model of the arm920t. you must run the program in fastbus mode (see fastbus mode on page 5-3). you must also run tck synchronously to bclk , and at least a factor of two slower. 2. on each rising edge of bclk you must record the values of errorin , wa i t i n , and lastin . on each falling edge of bclk , you must record the values of all other inputs and outputs. this binary string of values is called a vector. the amba functional test header is: ; entering amba functional test mode a 00000000 w 00000001 ; addressing all locations a 000007fc write cpdin 100000000 idle 000000000 write a920 inputs 010000000 write din 001000000 read dout 000100000 read cpdout 000010000 read cpid 000001000 read a920status1 000000100 read a920status2 000000010 read aout 000000001
amba test interface 11-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 3. repeat the following sequence for n in the range 1 to : ; writing cpdin of vector n-1 w ; writing arm920t inputs of vector n w ; writing din of vector n-1 w ; clocking arm920t ; reading dout of vector n r ffffffff ; reading cpid of vector n r ffffffff ; reading cpdout of vector n r ffffffff ; reading arm920t status location 1 of vector n-1 r 003ffcff ; reading arm920t status location 2 of vector n-1 r 003ffcff ; reading aout of vector n r ffffffff the amba functional test footer is: ; arm920t exiting amba functional test mode a 00000000 w 00000000 a zzzzzzzz e zzzzzzzz for each write and read, is an 8-character hexadecimal value. for the buses cpdin , din , dout , cpid , cpdout, and aout this is the vector value. for the arm920t inputs location the data is constructed as shown in table 11-3 on page 11-5. for the a920status1 and a920status2 locations, the read data is constructed as shown in table 11-4 on page 11-6 and table 11-5 on page 11-7. vector number zero does not exist in the vector file, so on the first iteration you must write cpdin as zero and you must give both status locations a mask value of zero. for more information see the amba specification (rev 2.0) . note if dout has the same value on two or more successive vectors, the mask value for the second and subsequent reads must be zero. it is recommended that you mask out fclkout and cpclk in each status1 read.
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-11 11.4 burst operations in all test modes other than functional test, the ssm provides locations for burst reads and writes of certain lengths. these are shown in table 11-6. to construct the address of a location for a burst access, you must add the address of the burst size to the address of the location. for example: address of pa tag ram read location = 0x18 address of burst-64 location = 0x180 address of burst of 64 pa tag ram reads = 0x18 + 0x180 = 0x198 . for each of the six test modes (see table 11-1 on page 11-3) there is a table summarizing for each location: its address whether it is for reading or writing whether burst accesses are supported to that location the alignment of read and write data. table 11-6 burst locations burst size address 1 0x000 2 0x040 4 0x080 8 0x0c0 16 0x100 32 0x140 64 0x180 128 0x1c0
amba test interface 11-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 11.5 pa tag ram test pa tag ram test mode allows you to test reading and writing the memory array. the memory array comprises eight segments out of a possible 128. each segment comprises 64 lines. each line is 26 bits wide. before either a read or write can be executed, the segment and index locations must be written, defining the array entry. if this has been done, writing is achieved as a two-step process and reading as a one-step process. 1. you must write a data pattern to a test location provided by the ssm. 2. the data pattern is written into the ram array and the index is incremented. depending on the write location used the data pattern is either incremented or inverted. for a burst access, the second step is repeated. there are five write locations and one read location. these are shown in table 11-7. when writing the data pattern, the write data is constructed as shown in table 11-8. table 11-7 pa tag ram locations location address read/ write burst data index 0x04 write no 5:0 segment 0x08 write no 6:0 data pattern 0x0c write no 25:0 ram write, invert data pattern and increment index 0x10 write yes - ram write, increment data pattern and increment index 0x14 write yes - ram read and increment index 0x18 read yes 31:6 table 11-8 construction of data pattern write data data pattern bits write data bits 25:21 28:24 20:14 22:16 13:7 14:8 6:0 6:0
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-13 for example: data pattern = 0x03ffffff write data = 0x1f7f7f7f . figure 11-2 shows the write data format. figure 11-2 write data format an example sequence to test lines 5 to 8 of memory segment 1 comprises: 1. enter pa tag test mode. 2. write index = 5. 3. write segment = 1. 4. write data pattern = 0. 5. burst-4 ram write and increment both data pattern and index. 6. write index = 5. 7. burst-4 ram read and increment index. 8. exit test mode. the tif file equivalent of the above sequence is: ; patagram testmode a 00000000 w 00000002 ; load index counter 5 a 00000004 w 00000005 ; load segment number 1 a 00000008 w 00000001 ; load data pattern 0 a 0000000c w 00000000 ; ramwrite, increment data pattern and index, burst of 4 ; 0x14 + 0x80 = 0x94 a 00000094 31 29 28 24 23 22 16 15 14 8 7 6 0 0 data [13:7] data [6:0] 0 0 data [20:14] data [25:21] 0 0 0
amba test interface 11-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c w 00000000 ; ramwrite w 00000000 ; ramwrite w 00000000 ; ramwrite w 00000000 ; load index counter 5. segment is unchanged at 1. a 00000004 w 00000005 ; ramread, increment index, burst of 4 ; 0x18 + 0x80 = 0x98 a 00000098 r 00000000 ffffffc0 ; ramread r 00000040 ffffffc0 ; ramread r 00000080 ffffffc0 ; ramread r 000000c0 ffffffc0 a zzzzzzzz ; exit test mode a 00000000 w 00000000 ; exiting test mode e zzzzzzzz.
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-15 11.6 cache test cache test mode allows you to perform the following functions: read and write cam and ram cam matches dirty all entries write the lockdown pointer invalidate either the whole cache or a single entry by va. cache test locations that you can access are shown in table 11-9. see chapter 2 programmer ? s model and appendix b cp15 test registers for more details of the registers used for cache test. cam write data is organized as shown in table 11-10. table 11-9 cache test locations location address read/write burst data cam 0x04 read/write yes 31:0 ram 0x08 read/write yes 31:0 cam match, ram read 0x0c write then read no 31:0 invalidate all 0x10 write no - dirty all 0x14 write no - lockdown victim and base 0x18 write no 31:2 invalidate by va 0x1c write no 31:5 table 11-10 cam write data cam data read value write value 31:5 [31:8] mva tag [31:8] mva tag [7:6] = segment [2:1] [7:5] = segment [2:0] [5] = 0 4 valid valid 3 dirty even dirty even
amba test interface 11-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c cam match write data is organized as shown in table 11-11. cam match read data is organized as shown in table 11-12. invalidate by va write data is organized as shown in table 11-13. 2 dirty odd dirty odd 1 write back write back 0 lfsr[6] 0 table 11-11 cam match write data match write data value 31:8 mva tag 7:5 segment 4:2 word 1:0 sbz table 11-12 cam match read data match read data value 31 cache miss 30 cache hit 29:0 ram read data [29:0] table 11-13 invalidate by va write data invalidate by va data value 31:8 va tag 7:5 segment 4:0 sbz table 11-10 cam write data (continued) cam data read value write value
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-17 lockdown victim and base data organization is shown in table 11-14. 11.6.1 behavior of the cache index pointer in amba cache test writing the lockdown pointer in amba cache test mode specifies the segment, index, and word that are used for all subsequent cam and ram operations. the index increments after cam reads or writes and ram reads or writes, but the segment and word do not change. 11.6.2 ram read or write to read or write the ram in cache segment n, carry out the following sequence: 1. write lockdown victim and base with: lockdown value = 0 segment = n word = 0. 2. burst 64 ram read/write: data = ram data. 3. repeat steps 1 and 2 seven times, incrementing the word value each time, from 0 to 7. table 11-14 lockdown victim and base data data value 31:26 index 25:8 sbz 7:5 segment 4:2 word 1:0 sbz
amba test interface 11-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 11.6.3 cam read or write to read or write the cam in cache segment n, carry out the following sequence: 1. write lockdown victim and base with: lockdown value = 0 segment = n. 2. burst 64 cam read or write: tag, segment, valid, dirty even, dirty odd, write back = cam data. 11.6.4 cam match, ram read to match on a va and read out the corresponding ram entry, carry out the following sequence: 1. address the match location. 2. write va comprising: va tag segment word. 3. read: cache hit cache miss ram data.
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-19 11.7 mmu test mmu test allows you to test the following: read and write cam, ram1, ram2, dac, and lockdown pointer invalidate either a whole tlb or a single entry selected by va cam match and ram1 read. table 11-15 shows the mmu test locations. see chapter 2 programmer ? s model and appendix b cp15 test registers for more details of the registers used for mmu test. the data format for the dac and lockdown locations are described in register 3, domain access control register on page 2-15 and register 10, tlb lockdown register on page 2-22. invalidate by va data is organized as shown in table 11-16. table 11-15 mmu test locations location address read/write burst data invalidate by va 0x04 write no 31:10 cam match, ram1 read 0x08 write then read no 31:0 cam 0x24 read/write yes 31:0 ram1 0x28 read/write yes 31:0 ram2 0x2c read/write yes 31:0 ram1, ram2 0x30 read/write yes 31:0 dac 0x34 read/write no 31:0 lockdown 0x38 read/write no 31:20, 1 invalidate all 0x3c write no - table 11-16 invalidate by va data invalidate by va data value 31:10 va tag 9:0 sbz
amba test interface 11-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c match write data is organized as shown in table 11-17. cam data is organized as shown in table 11-18. cam data size encoding is shown in table 11-19. table 11-17 match write data match write data value 31:10 va tag 9:0 sbz table 11-18 cam data cam data value 31:10 va tag 9:6 size_c (see table 11-19) 5 valid 4 preserved 3:0 sbz table 11-19 cam data size_c encoding size encoding [3:0] 1mb 0b1111 64kb 0b0111 16kb 0b0011 4kb 0b0001 1kb 0b0000
amba test interface arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 11-21 ram1 data is organized as shown in table 11-20. for ram1 reads, bits [24:22] are only valid for a match operation. the encoding of ram1 data access permission bits is shown in table 11-21. table 11-20 ram1 data ram 1 data value 31:25 sbz 24 protection fault 23 domain fault 22 mmu miss 21:6 domain, d15:d0 5 not cachable 4 not bufferable 3:0 access permission bits [3:0] table 11-21 ram1 data access permission bits access permission bits [3:0] decoded as ap [1:0] 0b0001 0b00 0b0010 0b01 0b0100 0b10 0b1000 0b11
amba test interface 11-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c ram2 data is organized as shown in table 11-22. the encoding of ram2 data size bits is shown in table 11-23. 11.7.1 behavior of the tlb index pointer in amba mmu test auto-increment is enabled for cam and ram1 reads and writes. 11.7.2 indexing the ram2 array the index pointer to the ram2 array is a pipelined version of the cam and ram1 index pointer. this means that to read from index n in the ram2 array, you must first perform an access to index n in either the cam or ram1. because of this, the composite location ram1, ram2 at address 0x30 , and the burst-128 location at address 0x1c0 are supported. table 11-22 ram2 data ram 2 data value 31:10 physical address tag 9:6 size_r2 5:0 sbz table 11-23 ram2 data size_r2 encoding size_r2 encoding [3:0] 1mb 0b1111 64kb 0b0111 16kb 0b0011 4kb 0b0000 1kb 0b0001
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 12-1 chapter 12 instruction cycle summary and interlocks this chapter gives the instruction cycle times and shows the timing diagrams for interlock timing. it contains the following sections: about the instruction cycle summary on page 12-2 instruction cycle times on page 12-3 interlocks on page 12-6.
instruction cycle summary and interlocks 12-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 12.1 about the instruction cycle summary all signals quoted in this chapter are arm9tdmi signals, and are internal to the arm920t. in all cases it is assumed that all accesses are from cached regions of memory. if an instruction causes an external access, either when prefetching instructions or when accessing data, the instruction takes more cycles to complete execution. the additional number of cycles is dependent on the system implementation.
instruction cycle summary and interlocks arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 12-3 12.2 instruction cycle times table 12-1 shows a key to the symbols used in tables in this section. table 12-2 summarizes the arm920t instruction cycle counts and bus activity when executing the arm instruction set. table 12-1 symbols used in tables symbol meaning b the number of busy-wait states during coprocessor accesses m is in the range 0 to 3, depending on early termination (see multiplier cycle counts on page 12-5) n the number of words transferred in an ldm / stm / ldc / stc c coprocessor register transfer (c-cycle) i internal cycle (i-cycle) n nonsequential cycle (n-cycle) s sequential cycle (s-cycle) table 12-2 instruction cycle bus times instruction cycles instruction bus data bus comment data op 1 1s 1i normal case data op 2 1s+1i 2i with register controlled shift ldr 1 1s 1n normal case, not loading pc ldr 2 1s+1i 1n+1i not loading pc and following instruction uses loaded word (1 cycle load-use interlock) ldr 3 1s+2i 1n+2i loaded byte, halfword, or unaligned word used by following instruction (2 cycle load-use interlock) ldr 5 2s+2i+1n 1n+4i pc is destination register str 1 1s 1n all cases ldm 2 1s+1i 1s+1i loading 1 register, not the pc
instruction cycle summary and interlocks 12-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c table 12-3 shows the instruction cycle times from the perspective of the data bus. ldm n 1s+(n-1)i 1n+(n-1)s loading n registers, n > 1, not loading the pc ldm n+4 2s+1n+(n+1)i 1n+(n-1)s+4i loading n registers including the pc, n > 0 stm 2 1s+1i 1n+1i storing 1 register stm n 1s+(n-1)i 1n+(n-1)s storing n registers, n > 1 swp 2 1s+1i 2n normal case swp 3 1s+2i 2n+1i loaded byte used by following instruction b,bl,bx 3 2s+1n 3i all cases swi , undefined 3 2s+1n 3i all cases cdp b+1 1s+bi (1+b)i all cases ldc,stc b+n 1s+(b+n-1)i bi+1n+(n-1)s all cases mcr b+1 1s+bi bi+1c all cases mrc b+1 1s+bi bi+1c normal case mrc b+2 1s+(b+1)i (b+i)i+1c following instruction uses transferred data mul, mla 2+m 1s+(1+m)i (2+m)i all cases smull,umull, smlal,umlal 3+m 1s+(2+m)i (3+m)i all cases table 12-2 instruction cycle bus times (continued) instruction cycles instruction bus data bus comment table 12-3 data bus instruction times instruction cycle time ldr 1n str 1n ldm,stm 1n+(n-1)s
instruction cycle summary and interlocks arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 12-5 12.2.1 multiplier cycle counts the number of cycles that a multiply instruction takes to complete depends on the instruction, and on the value of the multiplier-operand. the multiplier-operand is the contents of the register specified by bits [11:8] of the arm multiply instructions, or bits [2:0] of the thumb multiply instructions: for arm mul , mla , smull , smlal , and thumb mul , m is: 1 if bits [31:8] of the multiplier operand are all 0 or all 1 2 if bits [31:16] of the multiplier operand are all 0 or all 1 3 if bits [31:24] of the multiplier operand are all 0 or all 1 4 otherwise. for arm umull , umlal , m is: 1 if bits [31:8] of the multiplier operand are all 0 2 if bits [31:16] of the multiplier operand are all 0 3 if bits [31:24] of the multiplier operand are all 0 4 otherwise. swp 1n+1s ldc,stc 1n+(n-1)s mcr,mrc 1c table 12-3 data bus instruction times (continued) instruction cycle time
instruction cycle summary and interlocks 12-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 12.3 interlocks pipeline interlocks occur when the data required for an instruction is not available due to the incomplete execution of an earlier instruction. when an interlock occurs, instruction fetches stop on the instruction memory interface of the arm920t. four examples are given in: example 12-1 example 12-2 on page 12-7 example 12-3 on page 12-7 example 12-4 on page 12-9. example 12-1 single load interlock in this example, the following code sequence is executed: ldr r0, [r1] add r2, r0, r1 the add instruction cannot start until the data is returned from the load. the add instruction therefore, has to delay entering the execute stage of the pipeline by one cycle. the behavior on the instruction memory interface is shown in figure 12-1. figure 12-1 single load interlock timing gclk inmreq ia[31:1] dldr eldr id[31:0] a+4 mldr wldr fldr dadd dadd eadd madd wadd fadd ldr add a+10 a+14 a+c a+8
instruction cycle summary and interlocks arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 12-7 example 12-2 two cycle load interlock in this example, the following code sequence is executed: ldrb r0, [r1,#1] add r2, r0, r1 now, because a rotation must occur on the loaded data, there is a second interlock cycle. the behavior on the instruction memory interface is shown in figure 12-2. figure 12-2 two cycle load interlock example 12-3 ldm interlock in this example, the following code sequence is executed: ldm r12,{r1-r3} add r2, r2, r1 the ldm takes three cycles to execute in the memory stage of the pipeline. the add is therefore delayed until the ldm begins its final memory fetch. the behavior of both the instruction and data memory interfaces is shown in figure 12-3. gclk inmreq ia[31:1] dldrb eldrb id[31:0] a+4 mldrb wldrb fldrb dadd dadd eadd madd wadd fadd ldrb add a+10 a+14 a+c a+8 dadd
instruction cycle summary and interlocks 12-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 12-3 ldm interlock gclk inmreq ia[31:1] dldmb eldmb id[31:0] ia+4 mldmb wldmb fldmb dadd dadd eadd madd wadd fadd ldm add ia+10 ia+14 ia+c ia+8 dadd dnmreq da[31:0] da+4 da+8 da dd[31:0] mldmb mldmb r1 r2 r3
instruction cycle summary and interlocks arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 12-9 example 12-4 ldm dependent interlock in this example, the following code sequence is executed: ldm r12,{r1-r3} add r4, r3, r1 the code is the same code as in example 3, but in this instance the add instruction uses r3. due to the nature of load multiples, the lowest register specified is transferred first, and the highest specified register last. because the add is dependent on r3, there must be another cycle of interlock while r3 is loaded. the behavior on the instruction and data memory interface is shown in figure 12-4 on page 12-10.
instruction cycle summary and interlocks 12-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 12-4 ldm dependent interlock gclk inmreq ia[31:1] dldmb eldmb id[31:0] ia+4 mldmb wldmb fldmb dadd dadd dadd eadd madd fadd ldm add ia+10 ia+14 ia+c ia+8 dadd dnmreq da[31:0] da+4 da+8 da dd[31:0] mldmb mldmb r1 r2 r3 wadd
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-1 chapter 13 ac characteristics this chapter gives the timing diagrams and timing parameters for the arm920t processor. it contains the following sections: arm920t timing diagrams on page 13-2 arm920t timing parameters on page 13-16 timing definitions for the arm920t trace interface port on page 13-26.
ac characteristics 13-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 13.1 arm920t timing diagrams the amba bus interface of the arm920t conforms to the amba specification (rev 2.0) . see this document for the relevant timing diagrams. figure 13-1 shows the signal parameters for the fclk timed coprocessor interface. figure 13-1 arm920t fclk timed coprocessor interface fclk cpclk cpid[31:0] cpdout[31:0] cpnmreq ncptrans cptbit cplatecancel cppass ncpwait chsde[1:0] chsex[1:0] cpdin[31:0] t fcpkr fcpkf t fcpidd t fcpmreqd t fcand t fcanh t fpash t fpasd t fnwtd t fnwth t fcdns t fchsdh t fcdnh t t fclkh t fclkl fcpdoutd t fcpidh t fcpdouth t ftransd t fcptbitd t fcpmreqh t ftransh t fcptbith t fchseh t fchsds t fchses t
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-3 figure 13-2 shows the signal parameters for the bclk timed coprocessor interface. figure 13-2 arm920t bclk timed coprocessor interface bclk cpclk cpid[31:0] cpdout[31:0] cpnmreq ncptrans cptbit cplatecancel cppass ncpwait chsde[1:0] chsex[1:0] cpdin[31:0] t bcpkf bcpkr t bcand t bcanh t bpasd t bpash t bnwtd t bnwth t bcdns t bcdnh t bcpidd t bcpmreqd t bchsdh t t clkh t clkl bcpdoutd t bcpidh t bcpdouth t btransd t bcptbitd t bcpmreqh t btransh t bcptbith t bchseh t bchsds t bchses t
ac characteristics 13-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 13-3 shows the arm920t fclk related signal timing. figure 13-3 arm920t fclk related signal timing fclk eclk bigendout nfiq nirq fints fclkout fekr t fekf t ffkr t ffkf t finth t t fbigd t fbigh t
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-5 figure 13-4 shows the arm920t bclk related signal timing. figure 13-4 arm920t bclk related signal timing figure 13-5 shows the sdoutbs to tdo signal relationship. figure 13-5 arm920t sdoutbs to tdo relationship bclk eclk bigendout nfiq nirq bekr t bekf t bbigd t bbigh t binth t bints t tdo sdoutbs tdsd t tdsh t
ac characteristics 13-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 13-6 shows the relationship between ntrst and the following signals: commrx commtx dbgack dbgrqi driveoutbs ir[3:0] rangeout0 rangeout1 rstclkbs screg[3:0] sdin tapsm[3:0] tdo ntdoen . figure 13-6 arm920t ntrst to other signals relationship figure 13-7 on page 13-7 shows the jtag output signal timing parameters. signals ntrst brst t
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-7 figure 13-7 arm920t jtag output signal timing tck tck1 tck2 ir[3:0] screg[3:0] rstclkbs sdin tapsm[3:0] ecapclkbs icapclkbs pclkbs ntdoen tdo shclk2bs shclk1bs tckf t tckr t tckf t tckr t capf t capr t irsd t irsh t brtd t brth t toed t toeh t tdod t tdoh t sdnd t sdnh t tpmd t tpmh t shkf t shkr t shkf t shkr t tckh t tckl t brtd t brth t
ac characteristics 13-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 13-8 shows the jtag input signal timing parameters. figure 13-8 arm920t jtag input signal timing figure 13-9 on page 13-8 shows the fclk related debug output timing parameters. figure 13-9 arm920t fclk related debug output timing tck tdi tms dih t dis t fclk commtx commrx dbgack extern0 extern1 edbgrq rangeout0 rangeout1 fcomd t fcomh t fdckd t fdckh t frg0d t frg0h t frg1d t frg1h t fexth t fexts t fdbqh t fdbqs t
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-9 figure 13-10 shows the bclk related debug output timing parameters. figure 13-10 arm920t bclk related debug output timing bclk commtx commrx dbgack extern0 extern1 edbgrq rangeout0 rangeout1 bcomd t bcomh t bdckd t bdckh t brg0d t brg0h t brg1d t brg1h t bexts t bdbqh t bdbqs t bexth t
ac characteristics 13-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 13-11 shows the tck related debug output timing parameters. figure 13-11 arm920t tck related debug output timing figure 13-12 shows the edbgrq to dbgrqi relationship. figure 13-12 arm920t edbgrq to dbgrqi relationship tck eclk dbgrqi tekf t dgid t dgih t tekr t dbgrqi edbgrq edqd t edqh t
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-11 figure 13-13 shows the dbgen to output relationship. figure 13-13 arm920t dbgen to output relationship figure 13-14 shows the bclk related trace interface port timing parameters. figure 13-14 arm920t bclk related trace interface port timing rangeout0 rangeout1 dbgen rgen t bclk etmclock etm betmckf t betmckr t betmd t betmh t
ac characteristics 13-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 13-15 shows the fclk related trace interface port timing parameters. figure 13-15 arm920t fclk related trace interface port timing figure 13-16 shows the bnres timing. figure 13-16 arm920t bnres timing you can assert bnres low asynchronously during either bclk phase, but you must de-assert it during the bclk low phase. you must keep bnres asserted for a minimum of five bclk cycles to ensure a complete reset of the arm920t. fclk etmclock etm fetmckf t fetmckr t fetmd t fetmh t bclk bnres ihnres t zero t zero t isnres t 5 cycles minimum
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-13 figure 13-17 shows the arm920t asb slave transfer timing parameters. figure 13-17 arm920t asb slave transfer timing bclk dsel dout[31:0] isdsel t ihdsel t ain[11:2] writein din[31:0] enbd waitout enba isa t iha t iswr t ihwr t ihd t isd t ohd t ohenbd t ohwait t ohenba t ovenba t ovwait t ovenbd t ovd t clktstl t clktsth t
ac characteristics 13-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure 13-18 and figure 13-19 on page 13-15 show the arm920t asb master transfer timing parameters. figure 13-18 arm920t asb master transfer timing ovd t ohd t bclk areq writeout lok size[1:0] enba aout prot[1:0] enbd dout[31:0] ovareq t ohareq t oha t ova t ovwrite t ovprot t lok ovlok t ohlok t ovsize t ovenba t ovenba t ohwrite t ohprot t ohsize t ohenba t ovenbd t ohenbd t ihd t din[31:0] ohenba t isd t clkh t clkl t
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-15 figure 13-19 arm920t asb master transfer timing ihwait t iswait t ihlast t islast t iherr t iserr t bclk areq agnt enbtran ncmahb errorin tran[1:0] astb waitin lastin ovareq t ohareq t ihagnt t isagnt t ohtr t ovtr t ovbst t burst[1:0] oventr t ohentr t ohbst t ovastb t ohastb t ncmahbd t ncmahbh t ovtra t oventr t ohentr t clkh t clkl t
ac characteristics 13-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 13.2 arm920t timing parameters table 13-1 shows the arm920t timing parameters. table 13-1 arm920t timing parameters timing parameter description no arcs for cpen a no arcs for errorout b no arcs for isync a no arcs for lastout b no arcs for track a no arcs for vinithi a t bbigd bigendout output delay from bclk falling t bbigh bigendout output hold from bclk falling t bcand cplatecancel output delay from bclk falling t bcanh cplatecancel output hold from bclk falling t bcdnh cpdin[31:0] input hold from bclk falling t bcdns cpdin[31:0] input setup to bclk falling t bchsdh chsde[1:0] input hold from bclk falling t bchsds chsde[1:0] input setup to bclk falling t bchseh chsex[1:0] input hold from bclk falling t bchses chsex[1:0] input setup to bclk falling t bcomd commtx / commrx output delay from bclk rising t bcomh commtx / commrx output hold from bclk rising t bcpdoutd cpdout[31:0] output delay from bclk falling t bcpdouth cpdout[31:0] output hold from bclk falling t bcpidd cpid[31:0] output delay from bclk falling t bcpidh cpid[31:0] output hold from bclk falling
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-17 t bcpkf cpclk falling output delay from bclk falling t bcpkr cpclk rising output delay from bclk rising t bcpmreqd ncpmreq output delay from bclk falling. t bcpmreqh ncpmreq output hold from bclk falling t bcptbitd cptbit output delay from bclk falling. t bcptbith cptbit output hold from bclk falling t bdbqh edbgrq input hold from bclk falling t bdbqs edbgrq input setup to bclk falling t bdckd dbgack output delay from bclk rising t bdckh dbgack output hold from bclk rising t bdwph dewpt input hold from bclk rising c t bdwps dewpt input setup to bclk rising c t bekf eclk falling output delay from bclk falling t bekr eclk rising output delay from bclk rising t bexth extern0 / extern1 input hold from bclk falling t bexts extern0 / extern1 input setup to bclk falling t bibkh iebkpt hold after bclk rising c t bibks iebkpt input setup to bclk rising c t binth nfiq/nirq input hold from bclk falling t bints nfiq/nirq input setup to bclk falling t binxd instrexec output delay from bclk falling c t binxh instrexec output hold from bclk falling c t bnwtd ncpwait output delay from bclk rising t bnwth ncpwait output hold from bclk rising table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics 13-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c t bpasd cppass output delay from bclk rising t bpash cppass output hold from bclk rising t brg0d rangeout0 output delay from bclk falling t brg0h rangeout0 output hold from bclk falling t brg1d rangeout1 output delay from bclk falling t brg1h rangeout1 output hold from bclk falling t brst commrx/commtx/dbgack/dbgrqi/driveoutbs/ ir[3:0]/rangeout0/rangeout1/rstclkbs/ screg[3:0]/sdin/ tapsm[3:0]/tdo/ntdoen output delay from ntrst falling t brtd rstclkbs output delay from tck t brth rstclkbs hold time from tck t btransd ncptrans output delay from bclk falling t btransh ncptrans output hold from bclk falling t capf ecapclkbs / icapclkbs / pclkbs falling output delay from tck rising t capr ecapclkbs / icapclkbs / pclkbs rising output delay from tck rising t clkh bclk minimum width high phase t clkl bclk minimum width low phase t clktsth bclk minimum width high phase in amba test mode t clktstl bclk minimum width low phase in amba test mode t debugd commrx/commtx/dbgack/dbgrqi/rangeout0/ rangeout1 output delay from tck when in debug state c t debugh commrx/commtx/dbgack/dbgrqi/rangeout0/ rangeout1 output hold from tck when in debug state c t dgid dbgrqi output delay from tck falling table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-19 t dgih dbgrqi output hold from tck falling t dih tdi / tms input hold from tck rising t dis tdi/tms input setup to tck rising t drbsd driveoutbs output delay from tck falling c t drbsh driveoutbs output hold from tck falling c t edqd dbgrqi output delay from edbgrq rising or falling t edqh dbgrqi output hold from edbgrq rising or falling t fbigd bigendout output delay from fclk falling t fbigh bigendout output hold from fclk falling t fcand cplatecancel output delay from fclk falling t fcanh cplatecancel output hold from fclk falling t fcdnh cpdin[31:0] input hold from fclk falling t fcdns cpdin[31:0] input setup to fclk falling t fchsdh chsde[1:0] input hold to fclk falling t fchsds chsde[1:0] input setup to fclk falling t fchseh chsex[1:0] input hold to fclk falling t fchses chsex[1:0] input setup to fclk falling t fclkh fclk minimum width high phase t fclkl fclk minimum width low phase t fcomd commtx/rx output delay from fclk rising t fcomh commtx/rx output hold from fclk rising t fcpdoutd cpout[31:0] output delay from fclk falling t fcpdouth cpout[31:0] output hold from fclk falling t fcpidd cpid[31:0] output delay from fclk falling table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics 13-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c t fcpidh cpid[31:0] output hold from fclk falling t fcpkf cpclk falling output delay from fclk falling t fcpkr cpclk rising output delay from fclk rising t fcpmreqd ncpmreq output delay from fclk falling t fcpmreqh ncpmreq output hold time from fclk falling t fcptbitd cptbit output delay from fclk falling t fcptbith cptbit output hold time from fclk falling t fdbqh edbgrq input hold from fclk falling t fdbqs edbgrq input setup to fclk falling t fdckd dbgack output delay from fclk rising t fdckh dbgack output hold from fclk rising t fdwph dewpt input hold from fclk rising c t fdwps dewpt input setup to fclk rising c t fekf eclk falling output delay from fclk falling t fekr eclk rising output delay from fclk rising t fexth extern0/1 output hold after fclk falling t fexts extern0/1 input setup to fclk falling t ffkf fclkout falling output delay from fclk falling t ffkr fclkout rising output delay from fclk rising t fibkh iebkpt input hold from fclk rising c t fibks iebkpt input setup to fclk rising c t finth nfiq/nirq input hold from fclk falling t fints nfiq/nirq input setup to fclk falling t finxd instrexec output delay from fclk falling c table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-21 t finxh instrexec output hold from fclk falling c t fnwtd ncpwait output delay from fclk rising t fnwth ncpwait output hold from fclk rising t fpasd cppass output delay from fclk rising t fpash cppass output hold from fclk rising t frg0d rangeout0 output delay from fclk falling t frg0h rangeout0 output hold from fclk falling t frg1d rangeout1 output delay from fclk falling t frg1h rangeout1 output hold from fclk falling t ftransd ncptrans output delay from fclk falling t ftransh ncptrans output hold time from fclk falling t iha ain[11:2] input hold from bclk rising t ihagnt agnt input hold from bclk falling t ihd din[31:0] input hold from bclk falling t ihdsel dsel input hold from bclk rising t iherr errorin input hold from bclk rising t ihlast lastin input hold from bclk rising t ihnres bnres input rising hold from bclk falling t ihwait waitin input hold from bclk rising t ihwr writein input hold from bclk rising t irsd ireg[3:0] / screg[3:0] output delay from tck falling t irsh ireg[3:0] / screg[3:0] output hold from tck falling t isa ain[11:2] input setup to bclk falling t isagnt agnt input setup to bclk rising table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics 13-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c t isd din[31:0] input setup to bclk falling t isdsel dsel input setup to bclk falling t iserr errorin input setup to bclk rising t islast lastin input setup to bclk rising t isnres bnres input rising setup to bclk rising t iswait waitin input setup to bclk rising t iswr writein input setup to bclk rising t ncmahbd ncmahb output delay from bclk rising t ncmahbh ncmahb output hold from bclk rising t oha aout[31:0] output hold from bclk rising t ohareq areq output hold from bclk rising t ohastb astb output hold from bclk rising t ohbst burst[1:0] output hold from bclk rising t ohd dout[31:0] output hold from bclk falling t ohenba enba output hold from bclk rising or falling t ohenbd enbd output hold from bclk falling t ohensr ensr output hold from bclk rising or falling t ohentr enbtran output hold from bclk rising or falling t ohlok lok output hold from bclk rising t ohprot prot[1:0] output hold from bclk rising t ohsize size[1:0] output hold from bclk rising t ohtr tran[1:0] output hold from bclk rising t ohwait wa i t o u t output hold from bclk falling t ohwrite writeout output hold from bclk rising table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-23 t ova aout[31:0] output delay from bclk rising t ovareq areq output delay from bclk rising t ovastb astb output delay from bclk rising t ovbst burst[1:0] output delay from bclk rising t ovd dout[31:0] output delay from bclk falling t ovenba enba output delay from bclk rising or falling t ovenbd enbd output delay from bclk falling t ovensr ensr output delay from bclk rising or falling t oventr enbtran output delay from bclk rising or falling t ovlok lok output delay from bclk rising t ovprot prot[1:0] output delay from bclk rising t ovsize size[1:0] output delay from bclk rising t ovtr tran[1:0] output delay from bclk rising t ovtra tran[1:0] output delay from agnt rising or falling t ovwait wa i to u t output delay from bclk falling t ovwrite writeout output delay from bclk rising t rgen rangeout0/rangeout1 falling output delay from dbgen falling t sdnd sdin output delay from tck falling t sdnh sdin output hold from tck falling t shkf shclk1bs falling output delay from tck falling d t shkf shclk2bs falling output delay from tck rising d t shkr shclk1bs rising output delay from tck rising d t shkr shclk2bs rising output delay from tck falling d t tckf tck1 falling output delay from tck falling e table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics 13-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c t tckf tck2 falling output delay from tck rising e t tckh tck minimum width high phase t tckl tck minimum width low phase t tckr tck1 rising output delay from tck rising e t tckr tck2 rising output delay from tck falling e t tdod tdo output delay from tck falling t tdoh tdo output hold from tck falling t tdsd tdo output delay from sdoutbs rising or falling t tdsh tdo output hold from sdoutbs rising or falling t tekf eclk falling output delay from tck falling t tekr eclk rising output delay from tck rising t ticd commrx/commtx/dbgack/dbgrqi/driveoutbs/ ecapclkbs/eclk/fclkout/icapclkbs/ir[3:0]/ rangeout0/rangeout1/rstclkbs/screg[3:0]/sdin/ shclk1bs/shclk2bs/tapsm[3:0]/tck1/tck2/tdo/ ntdoen generic output delay from bclk during amba test c t tich commrx/commtx/dbgack/dbgrqi/driveoutbs/ ecapclkbs/eclk/fclkout/icapclkbs/ir[3:0]/ rangeout0/rangeout1/rstclkbs/screg[3:0]/sdin/ shclk1bs/shclk2bs/tapsm[3:0]/tck1/tck2/tdo/ ntdoen generic output hold from bclk during amba test c t toed ntdoen output delay from tck falling t toeh ntdoen output hold from tck falling t tpmd tapsm[3:0 ] output delay from tck falling t tpmh tapsm[3:0 ] output hold from tck falling t zero bnres falling setup to bclk falling f t zero bnres falling hold from bclk falling f table 13-1 arm920t timing parameters (continued) timing parameter description
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-25 a. it is assumed that this signal is static. b. permanently driven to 0. c. this timing parameter is not shown in any diagram in this chapter. d. tshkr is greater than tshkf to ensure non-overlapping shclk1bs and shclk2bs . e. ttckr is greater than ttckf to ensure non-overlapping tck1 and tck2 . f. this parameter is always zero because the timing arcs refer to asynchronous assertion.
ac characteristics 13-26 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c 13.3 timing definitions for the arm920t trace interface port table 13-2 shows the timing parameters of signals used with the arm920t trace interface port. table 13-2 arm920t trace interface port timing definitions timing parameter description no arcs for etmpwrdown - t betmbigendd etmbigend output delay from bclk rising t betmbigendh etmbigend output hold from bclk rising t betmchsdd etmchsd[1:0] output delay from bclk rising t betmchsdh etmchsd[1:0] hold from bclk rising t betmchsed etmchse[1:0] output delay from bclk rising t betmchseh etmchse[1:0] hold from bclk rising t betmckf etmclock falling output delay from bclk falling t betmckr etmclock rising output delay from bclk rising t betmdabortd etmdabort output delay from bclk rising t betmdaborth etmdabort output hold from bclk rising t betmdad etmda[31:0] output delay from bclk rising t betmdah etmda[31:0] output hold from bclk rising t betmdbgackd etmdbgack output delay from bclk rising t betmdbgackh etmdbgack output hold from bclk rising t betmddd etmdd[31:0] output delay from bclk rising t betmddh etmdd[31:0] output hold from bclk rising t betmdmasd etmdmas[1:0] output delay from bclk rising t betmdmash etmdmas[1:0] output hold from bclk rising t betmdmored etmdmore output delay from bclk rising t betmdmoreh etmdmore output hold from bclk rising
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-27 t betmdnmreqd etmdnmreq output delay from bclk rising t betmdnmreqh etmdnmreq output hold from bclk rising t betmdnrwd etmdnrw output delay from bclk rising t betmdnrwh etmdnrw output hold from bclk rising t betmdseqd etmdseq output delay from bclk rising t betmdseqh etmdseq output hold from bclk rising t betmhivecsd etmhivecs output delay from bclk rising t betmhivecsh etmhivecs output hold from bclk rising t betmiabortd etmiabort output delay from bclk rising t betmiaborth etmiabort output hold from bclk rising t betmiad etmia[31:1] output delay from bclk rising t betmiah etmia[31:1] output hold from bclk rising t betmid15to8d etmid15to8[15:8] output delay from bclk rising t betmid15to8h etmid15to8[15:8] output hold from bclk rising t betmid31to24d etmid31to24[31:24] output delay from bclk rising t betmid31to24h etmid31to24[31:24] output hold from bclk rising t betminmreqd etminmreq output delay from bclk rising t betminmreqh etminmreq output hold from bclk rising t betminstrexecd etminstrexec output delay from bclk rising t betminstrexech etminstrexec output hold from bclk rising t betmiseqd etmiseq output delay from bclk rising t betmiseqh etmiseq output hold from bclk rising t betmitbitd etmitbit output delay from bclk rising t betmitbith etmitbit output hold from bclk rising table 13-2 arm920t trace interface port timing definitions (continued) timing parameter description
ac characteristics 13-28 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c t betmlatecanceld etmlatecancel output delay from bclk rising t betmlatecancelh etmlatecancel output hold from bclk rising t betmnwaitd etmnwait output delay from bclk rising t betmnwaith etmnwait output hold from bclk rising t betmpassd etmpass output delay from bclk rising t betmpassh etmpass output hold from bclk rising t betmrngoutd etmrngout[1:0] output delay from bclk rising t betmrngouth etmrngout[1:0] hold from bclk rising t fetmbigendd etmbigend output delay from fclk rising t fetmbigendh etmbigend output hold from fclk rising t fetmchsdd etmchsd[1:0] output delay from fclk rising t fetmchsdh etmchsd[1:0] output hold from fclk rising t fetmchsed etmchse[1:0] output delay from fclk rising t fetmchseh etmchse[1:0] output hold from fclk rising t fetmckf fetmclock falling output delay from fclk falling t fetmckr fetmclock rising output delay from fclk rising t fetmdabortd etmdabort output delay from fclk rising t fetmdaborth etmdabort output hold from fclk rising t fetmdad etmda[31:0] output delay from fclk rising t fetmdah etmda[31:0] output hold from fclk rising t fetmdbgackd etmdbgack output delay from fclk rising t fetmdbgackh etmdbgack output hold from fclk rising t fetmddd etmdd[31:0] output delay from fclk rising t fetmddh etmdd[31:0] output hold from fclk rising table 13-2 arm920t trace interface port timing definitions (continued) timing parameter description
ac characteristics arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. 13-29 t fetmdmasd etmdmas[1:0] output delay from fclk rising t fetmdmash etmdmas[1:0] output hold from fclk rising t fetmdmored etmdmore output delay from fclk rising t fetmdmoreh etmdmore output hold from fclk rising t fetmdnmreqd etmdnmreq output delay from fclk rising t fetmdnmreqh etmdnmreq output hold from fclk rising t fetmdnrwd etmdnrw output delay from fclk rising t fetmdnrwh etmdnrw output hold from fclk rising t fetmdseqd etmdseq output delay from fclk rising t fetmdseqh etmdseq output hold from fclk rising t fetmhivecsd etmhivecs output delay from fclk rising t fetmhivecsh etmhivecs output hold from fclk rising t fetmiabortd etmiabort output delay from fclk rising t fetmiaborth etmiabort output hold from fclk rising t fetmiad etmia[31:1] output delay from fclk rising t fetmiah etmia[31:1] output hold from fclk rising t fetmid15to8d etmid15to8[15:8] output delay from fclk rising t fetmid15to8h etmid15to8[15:8] output hold from fclk rising t fetmid31to24d etmid31to24[31:24] output delay from fclk rising t fetmid31to24h etmid31to24[31:24] output hold from fclk rising t fetminmreqd etminmreq output delay from fclk rising t fetminmreqh etminmreq output hold from fclk rising t fetminstrexecd etminstrexec output delay from fclk rising t fetminstrexech etminstrexec output hold from fclk rising table 13-2 arm920t trace interface port timing definitions (continued) timing parameter description
ac characteristics 13-30 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c t fetmiseqd etmiseq output delay from fclk rising t fetmiseqh etmiseq output hold from fclk rising t fetmitbitd etmitbit output delay from fclk rising t fetmitbith etmitbit output hold from fclk rising t fetmlatecanceld etmlatecancel output delay from fclk rising t fetmlatecancelh etmlatecancel output hold from fclk rising t fetmnwaitd etmnwait output delay from fclk rising t fetmnwaith etmnwait output hold from fclk rising t fetmpassd etmpass output delay from fclk rising t fetmpassh etmpass output hold from fclk rising t fetmrngoutd etmrngout[1:0] output delay from fclk rising t fetmrngouth etmrngout[1:0] output hold from fclk rising table 13-2 arm920t trace interface port timing definitions (continued) timing parameter description
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-1 appendix a signal descriptions this appendix describes the arm920t signals. it contains the following sections: amba signals on page a-2 coprocessor interface signals on page a-5 jtag and tap controller signals on page a-7 debug signals on page a-10 miscellaneous signals on page a-12 arm920t trace interface port signals on page a-13.
signal descriptions a-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c a.1 amba signals table a-1 shows the arm920t amba signals. table a-1 amba signals name direction description agnt input bus grant. a signal from the bus arbiter to a bus master that indicates that the bus master is granted the bus when waitin is low. ain[11:2] input address input bus. used for addressing the arm920t processor as a slave during amba test. aout[31:0] output address output bus. the processor address bus, that is driven by the active bus master. areq output bus request. a signal from the bus master to the bus arbiter that indicates that the arm920t processor requires the bus. astb output indicates a non-idle a-tran cycle. bclk input bus clock. this clock times all bus transfers. both the low phase and high phase of bclk control transfers on the bus. bnres input arm920t processor reset. you can assert bnres low asynchronously during either bclk phase, but you must de-assert it during the bclk low phase. you must keep bnres asserted for a minimum of five bclk cycles to ensure a complete reset of the arm920t processor. burst[1:0] output burst access. these signals indicate the length of a burst transfer. the encoding is: 00 =no burst or undefined burst length 01= current access is part of a burst of 4-word transfers 10 = current access is part of a burst of 8-word transfers 11 = no burst or undefined burst length. din[31:0] input data input bus. dout[31:0] output data output bus. dsel input slave select. this signal is used during test within the amba system and allows the arm920t processor to be selected and to have test vectors applied to it. enba output tristate enable for aout , writeout , lok , prot , and size onto an amba address bus and amba request signals. enbd output tristate enable for dout onto an amba data bus. enbtran output tristate enable for tran onto amba btran .
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-3 ensr output tristate enable for errorout , lastout, and wa i to u t onto amba response signals. errorin input error response. a transfer error is indicated by the selected bus slave using the errorin signal. when errorin is high, a transfer error has occurred. when errorin is low, the transfer is successful. this signal is also used in combination with the lastin signal to indicate a bus retract operation. errorout output amba error response of the arm920t slave during amba test. lastin input last response. this signal is driven by the selected bus slave to indicate if the current transfer must be the last of a burst sequence. when lastin is high, the decoder must allow sufficient time for address decoding. when lastin is low, the next transfer can continue a burst sequence. lastout output amba last response of the arm920t slave during amba test. lok output locked transfers. when high, this signal indicates that the current transfer, and the next transfer, are to be indivisible, and that no other bus master must be given access to the bus. this signal is used by the bus arbiter. asserted in the same cycle as astb is asserted. ncmahb output noncached more indication for noncached load multiples. when high, this indicates that more words are to be requested as part of the burst transfer. when low, on the last s-tran of the burst, this indicates that the current transfer is the last word of the burst. it is only valid if agnt remains asserted throughout the transfer. prot[1:0] output protection control.these signals provide additional information about a bus access and are primarily intended for use by a bus decoder when acting as a basic protection unit. the signals indicate if the transfer is an opcode fetch or data access. they also indicate if the transfer is a privileged mode or user mode as follows: prot[0] 0 = opcode fetch, 1 = data access prot[1] 0 = user access, 1 = supervisor access size[1:0] output transfer size. these signals indicate the size of the transfer: 10 = word access 01 = half word access 00= byte access 11 = reserved. table a-1 amba signals (continued) name direction description
signal descriptions a-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c a.1.1 amba bus specification the arm920t processor has a unidirectional amba-compatible bus interface. see the amba specification (rev 2.0) for full details. tran[1:0] output transfer type. these signals indicate the type of the next transaction: 00 = an address-only transfer 01 = a nonsequential transfer 11 = a sequential transfer 01 reserved. wa i t i n input wait response. this signal is driven by the selected bus slave to indicate if the current transfer can complete. if waitin is high, another bus cycle is required. if waitin is low, the transfer completes in the current bus cycle. wa i to u t output amba wait response of the arm920t slave during amba test. writein input transfer direction.when high, this signal indicates a write transfer. when low, a read transfer. writeout output transfer direction.when high, this signal indicates a write transfer. when low, a read transfer. table a-1 amba signals (continued) name direction description
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-5 a.2 coprocessor interface signals table a-2 shows the arm920t coprocessor interface signals. table a-2 coprocessor interface signals name direction description chsde[1:0] input coprocessor handshake decode. the handshake signals from the decode stage of the coprocessor pipeline follower. chsex[1:0] input coprocessor handshake execute. the handshake signals from the execute stage of the coprocessor pipeline follower. cpclk output coprocessor clock. this clock controls the operation of the coprocessor interface. cpdout[31:0] output coprocessor data out. the coprocessor data bus for transferring mcr and ldc data to the coprocessor. cpdin[31:0] input coprocessor data in. the coprocessor data bus for transferring mrc and stc data from the coprocessor to the arm920t processor. cpen input coprocessor data out enable. when tied low, the cpid and cpdout buses are held stable. when tied high, the cpid and cpdout buses are enabled. it is expected that this pin is used statically. cpid[31:0] output coprocessor instruction data. this is the coprocessor instruction data bus used for transferring instructions to the pipeline follower in the coprocessor. cplatecancel output coprocessor late cancel. when a coprocessor instruction is being executed, if this signal is high during the first memory cycle, the coprocessor instruction must be canceled without having updated the coprocessor state. ncpmreq output not coprocessor memory request. when low on a rising cpclk edge and ncpwait low, the instruction on cpid enters the decode stage of the coprocessor pipeline follower. the second instruction previously in the decode stage of the pipeline follower enters its execute stage. cppass output coprocessor pass. this signal indicates that there is a coprocessor instruction in the execute stage of the pipeline, and it must be executed.
signal descriptions a-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c for more information on the coprocessor interface see chapter 7 coprocessor interface . cptbit output coprocessor thumb bit. if high, the coprocessor interface is in thumb state. ncptrans output not coprocessor translate. when low, the coprocessor interface is in a nonprivileged mode. when high, the coprocessor interface is in a privileged mode. the coprocessor samples this signal on every cycle when determining the coprocessor response. ncpwait output not coprocessor wait. the coprocessor clock cpclk is qualified by ncpwait to allow the arm920t processor to control the transfer of data on the coprocessor interface. ncpwait changes while cpclk is high. table a-2 coprocessor interface signals (continued) name direction description
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-7 a.3 jtag and tap controller signals table a-3 shows the arm920t jtag and tap controller signals. table a-3 jtag and tap controller signals name direction description driveoutbs output boundary scan cell enable. this signal controls the multiplexors in the scan cells of an external boundary scan chain. this signal changes in the update-ir state when scan chain 3 is selected, and either the intest, extest, clamp, or clampz instruction is loaded. if you do not connect an external boundary scan chain, you must leave this output unconnected. ecapclkbs output extest capture clock for boundary scan. this is a tck2 wide pulse generated when the tap controller state machine is in the capture-dr state, the current instruction is extest, and scan chain 3 is selected. this signal captures the chip-level inputs during extest. if you do not connect an external boundary scan chain, you must leave this output unconnected. icapclkbs output intest capture clock. this is a tck2 wide pulse generated when the tap controller state machine is in the capture-dr state, the current instruction is intest, and scan chain 3 is selected. this signal captures the chip-level outputs during intest. if you do not connect an external boundary scan chain, you must leave this output unconnected. ir[3:0] output tap controller instruction register. these four bits reflect the current instruction loaded into the tap controller instruction register. the bits change on the falling edge of tck when the state machine is in the update-ir state. pclkbs output boundary scan update clock. this is a tck2 wide pulse generated when the tap controller state machine is in the update-dr state, and scan chain 3 is selected. this signal is used by an external boundary scan chain as the update clock. if you do not connect an external boundary scan chain, you must leave this output unconnected. rstclkbs output boundary scan reset clock. this signal denotes that either the tap controller state machine is in the reset state, or that ntrst has been asserted. you can use this to reset external boundary scan cells. screg[4:0] output scan chain register. these five bits reflect the id number of the scan chain currently selected by the tap controller. these bits change on the falling edge of tck when the tap state machine is in the update-dr state. sdin output boundary scan serial input data. this signal contains the serial data to be applied to an external scan chain, and is valid around the falling edge of tck . sdoutbs input boundary scan serial output data. this is the serial data out of the boundary scan chain (or other external scan chain). it must be set up to the rising edge of tck . if you do not connect an external boundary scan chain, you must tie this input low.
signal descriptions a-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c shclk1bs output boundary scan shift clock phase 1. this control signal eases the connection of an external boundary scan chain. shclk1bs clocks the master half of the external scan cells. when in the shift-dr state of the state machine and scan chain 3 is selected, shclk1bs follows tck1 . when not in the shift-dr state, or when scan chain 3 is not selected, this clock is low. if you do not connect an external boundary scan chain, you must leave this output unconnected. shclk2bs output boundary scan shift clock phase 2. this control signal eases the connection of an external boundary scan chain. shclk2bs clocks the slave half of the external scan cells. when in the shift-dr state of the state machine and scan chain 3 is selected, shclk2bs follows tck2 . when not in the shift-dr state, or when scan chain 3 is not selected, this clock is low. if you do not connect an external boundary scan chain, you must leave this output unconnected. tapid[31:0] input this is the arm920t device identification (id) code test data register, accessible from the scan chains. you must tie this to an appropriate value when you instantiate the device: 31:28 functionality revision 27:12 product code 11:1 manufacturer identity 0 ieee specified = 1. tapsm[3:0] output tap controller state machine. this bus reflects the current state of the tap controller state machine. these bits change off the rising edge of tck . tck input test clock. the jtag clock (the test clock). tck1 output tck , phase 1. tck1 is high when tck is high, although there is a slight phase lag due to the internal clock non-overlap. tck2 output tck , phase 2. tck2 is high when tck is low, although there is a slight phase lag due to the internal clock non-overlap. tdi input test data input. jtag serial input. tdo output test data output. jtag serial output. table a-3 jtag and tap controller signals (continued) name direction description
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-9 ntdoen output not tdo enable. when high, this signal denotes that serial data is being driven out on the tdo output. ntdoen is normally used as an output enable for a tdo pin in a packaged part. tms input test mode select. tms selects the state that the tap controller state machine must change to. ntrst input not test reset. active low reset signal for the boundary scan logic. this pin must be pulsed or driven low to achieve normal device operation, in addition to the normal device reset ( bnres ). table a-3 jtag and tap controller signals (continued) name direction description
signal descriptions a-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c a.4 debug signals table a-4 shows the arm920t debug signals. table a-4 debug signals name direction description commrx output communications channel receive. when high, this signal denotes that the comms channel receive buffer contains data waiting to be read by the processor core. commtx output communications channel transmit. when high, this signal denotes that the comms channel transmit buffer is empty. dbgack output debug acknowledge. when high, this signal indicates the arm is in debug state. dbgen input debug enable. this input signal allows the debug features of the arm920t processor to be disabled. this signal must be low only when debugging is not required. dbgrqi output internal debug request. this signal represents the debug request signal that is presented to the processor core. this is a combination of edbgrq , as presented to the arm920t processor, and bit 1 of the debug control register. dewpt input external watchpoint. this signal allows external data watchpoints to be implemented. eclk output external clock output. edbgrq input external debug request. when driven high, this causes the processor to enter debug state when execution of the current instruction has completed. extern0 input external input 0. this is an input to watchpoint unit 0 of the embeddedice logic in the processor, and allows breakpoints or watchpoints to be dependent on an external condition. extern1 input external input 1. this is an input to watchpoint unit 1 of the embeddedice logic in the processor, and allows breakpoints or watchpoints to be dependent on an external condition. iebkpt input external breakpoint. this signal allows an external instruction breakpoints to be implemented. instrexec output instruction executed. indicates that in the previous cycle, the instruction in the execute stage of the pipeline passed its condition codes, and has been executed.
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-11 rangeout0 output embeddedice rangeout 0. this signal indicates that the embeddedice watchpoint unit 0 has matched the conditions currently present on the address, data, and control buses. this signal is independent of the state of the watchpoint unit enable control bit. rangeout1 output embeddedice rangeout 1. this signal indicates that the embeddedice watchpoint unit 1 has matched the conditions currently present on the address, data, and control buses. this signal is independent of the state of the watchpoint unit enable control bit. track input enable trackingice mode. driving this signal high places the arm920t processor into tracking mode for debugging purposes. table a-4 debug signals (continued) name direction description
signal descriptions a-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c a.5 miscellaneous signals table a-5 shows the arm920t miscellaneous signals. table a-5 miscellaneous signals name direction description bigendout output big-endian output. when high, the arm920t processor is operating in big-endian configuration. when low, it is in little-endian configuration. fclkout output buffered version of fclk input. fclk input fast clock. the fast clock input is used when the arm920t processor is in the synchronous or asynchronous clocking mode. vinithi input determines the state of cp15 register 1 v-bit in reset. when high, v-bit is 1 coming out of reset. when low, v-bit is 0 coming out of reset. isync input synchronous interrupts. when high, interrupts must be applied synchronously. nfiq input not fast interrupt request. this is the not fast interrupt request ( nfiq) signal. nirq input not interrupt request. this is the not interrupt request ( nirq) signal.
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-13 a.6 arm920t trace interface port signals table a-6 shows the arm920t trace interface port signals table a-6 trace signals name direction etmbigend output the signal driving the arm9tdmi core bigend / bigendian input. when high, the processor treats bytes in memory as big-endian format. when low, memory is treated as little-endian. this is a static configuration signal. etmchsd[1:0] output the coprocessor handshake decode bus driven into the arm9tdmi core. etmchse[1:0] output the coprocessor handshake execute bus driven into the arm9tdmi core. etmclock output this clock times all operations in the etm9. all outputs change from the rising edge and all inputs are sampled on the rising edge. the clock can be stretched in either phase. etmda[31:0] output the processor data mva bus driven by the arm9tdmi core. etmdabort output the data abort signal driven into the arm9tdmi core. the dabort signal is used to tell the processor that the requested data memory access is not allowed. etmdbgack output the debug acknowledge signal driven by the arm9tdmi core. when high this signal indicates that the arm9tdmi core is in debug state. etmdd[31:0] output the dd bus driven within the arm920t processor. etmdmas[1:0] output the data memory access size bus driven by the arm9tdmi core. these encode the size of a data memory access in the following cycle. etmdmore output the data control signal driven by the arm9tdmi core. if high at the end of the cycle then the data memory access is directly followed by a sequential data memory access.
signal descriptions a-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c etmdnmreq output the data memory request signal driven by the arm9tdmi core. if low at the end of a cycle then the processor requires a data memory access in the following cycle. etmdnrw output the data read/write signal driven by the arm9tdmi core. if low at the end of a cycle then any data memory access in the following cycle is a read. if high, then it is a write. etmdseq output the data sequential address signal driven by the arm9tdmi core. if high at the end of the cycle then any data memory access in the following cycle is sequential from the last data memory access. etmhivecs output the signal driving the arm9tdmi core hivecs input. when low the arm exception vectors start at address 0x0000 0000 . when high, the arm exception vectors start at address 0xffff 0000 . this is a static configuration signal. etmia[31:1] output the instruction mva bus driven by the arm9tdmi core. etmiabort output the instruction abort signal driven into the arm9tdmi core. etmid15to8[15:8] output a section from the id input bus driven into the arm9tdmi core. etmid31to24[31:24] output a section from the id input bus driven into the arm9tdmi core. etminmreq output the inmreq signal driven by the arm9tdmi core. if low at the end of the cycle then the processor requires an instruction memory access during the following cycle. etminstrexec output the instrexec pipeline status signal driven by the arm9tdmi core. the instruction executed signal indicates that the instruction in the execute stage of the pipeline follower of the etm9 has been executed. table a-6 trace signals (continued) name direction
signal descriptions arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. a-15 etmiseq output the iseq signal driven by the arm9tdmi core. if high at the end of the cycle then any instruction memory access during the following cycle is sequential from the last instruction memory access. etmitbit output the itbit signal driven by the arm9tdmi core. when high, denotes that the arm is in thumb state. when low, the processor is in arm state. this signal is valid with the address. etmlatecancel output the coprocessor late cancel signal driven by the arm9tdmi core. if high during the first memory cycle of a coprocessor instruction, then the coprocessor must cancel the instruction without changing any internal state. this signal is only asserted in cycles where the previous instruction accessed memory and a data abort occurred. etmpass output the pass coprocessor signal driven by the arm9tdmi core. this signal indicates that the instruction in the execute stage of the pipeline follower of the etm9 is executed. etmpwrdown input when high, indicates that the etm9 can be powered down. the arm920t processor uses this to stop the etmclock output. when this happens all other etm outputs are held stable. etmrngout[1:0] output the rangeout[1:0] embeddedice signals driven by the arm. the embeddedice rangeout signals indicate that the corresponding watchpoint unit has matched the conditions currently present on the address, control and data buses. these signals are independent of the state of the enable control bit of the watchpoint unit. etmnwait output you can stall the etm9 by driving etmnwait low. it must be held high at all other times. etmnwait is the nwait signal driven into the arm9tdmi core. table a-6 trace signals (continued) name direction
signal descriptions a-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-1 appendix b cp15 test registers this appendix describes the arm920t cp15 test registers. it contains the following sections: about the test registers on page b-2 test state register on page b-3 cache test registers and operations on page b-8 mmu test registers and operations on page b-18. strongarm backwards compatibility operations on page b-30.
cp15 test registers b-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c b.1 about the test registers the arm920t coprocessor 15 (cp15), register 15 (c15) is used to provide additional device-specific test operations. you can use it to access and control the following: test state register on page b-3 cache test registers and operations on page b-8 mmu test registers and operations on page b-18 strongarm backwards compatibility operations on page b-30. you must only use these operations for test. the arm architecture reference manual describes this register as implementation defined. the format of the cp15 test operations is: mcr/mrc p15,opcode_1,rd,c15,crm,opcode_2 figure b-1 cp15 mrc and mcr bit pattern the l bit distinguishes between an mcr (l = 1) and an mrc (l = 0). 313029282726252423222120191817161514131211109876543210 1110 1111 1 crm opcode_2 rd crn l opcode_1 cond
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-3 b.2 test state register the test state register is used to modify the behavior of the arm920t from the default behavior. at reset, all bits of the test state register are cleared to 0. you can write bits [12:1] by: mcr p15,0,rd,c15,c0,0 you can read bits [12:0] by: mrc p15,0,rd,c15,c0,0 you can only write bit 0 using scan chain 15 (cp15), selecting the test state register. you can also access bits[12:1] using the same scan chain, but it is recommended that you only read and write these using mcr and mrc instructions. the functions of bits in the test state register are listed in table b-1. table b-1 test state register bit function or name description 12 disable dcache streaming 0 = enable dcache streaming 1 = disable dcache streaming 11 disable icache streaming 0 = enable icache streaming 1 = disable icache streaming 10 disable dcache linefill 0 = enable dcache linefills 1 = disable dcache linefills 9 disable icache linefill 0 = enable icache linefills 1 = disable icache linefills 8 disable cp15, c1, bits[31:30] 0 = enable r1 1 = disable r1 7 ia, strongarm asynchronous select 00 = fastbus mode 01 = synchronous mode 10 = reserved 11 = asynchronousmode 6 nf, strongarm notfastbus select 5 d force noncachable 0 = normal operation 1 = force noncachable behavior in the dcache 4 i force noncachable 0 = normal operation 1 = force noncachable behavior in the icache
cp15 test registers b-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c mrc (reading) return bits [12:0], with bits [31:13] being unpredictable. mcr (writing) update bits [12:1]. bits [31:13] and [0] should be zero. b.2.1 bit 12, disable dcache streaming when set, this bit prevents the dcache from streaming data words to the arm9tdmi while the linefill is performed to the cache. the linefill still occurs, but the data word is returned to the arm9tdmi at the end of the linefill. b.2.2 bit 11, disable icache streaming when set, this bit prevents the icache from streaming instructions to the arm9tdmi while the linefill is performed to the cache. the linefill still occurs, but the instruction is returned to the arm9tdmi at the end of the linefill. b.2.3 bit 10, disable dcache linefill when set, this bit prevents the dcache from performing a linefill on a dcache miss. instead, a single word read is performed from the amba asb interface. the memory region mapping is unchanged. this mode of operation is required for debug, so that the memory image, as seen by the arm9tdmi, can be read in a non-invasive manner. cache hits from a cachable region read the data word from the cache, and cache misses from a cachable region do not cause a linefill, but read a single data word from memory.you must use the control bit disable dcache linefill instead of d force noncachable , because d force noncachable does not read from the cache on a cache hit. 3 mmu test 0 = disable auto-increment 1 = enable auto-increment 2 i miss abort 0 = enable itlb hardware page table walks 1 = disable itlb hardware page table walks 1 d miss abort 0 = enable dtlb hardware page table walks 1 = disable dtlb hardware page table walks 0 cp15 interpret mode 0 = disable cp15 interpret mode 1 = enable cp15 interpret mode table b-1 test state register (continued) bit function or name description
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-5 b.2.4 bit 9, disable icache linefill when set, this bit prevents the icache from performing a linefill on an icache miss. instead, a single word read is performed from the amba asb interface. the memory region mapping is unchanged. this mode of operation is required for debug so that the memory image, as seen by the arm9tdmi, can be read in a non-invasive manner. cache hits from a cachable region read the instruction from the cache, and cache misses from a cachable region do not cause a linefill, but read a single instruction from memory.you must use the control bit disable icache linefill instead of i force noncachable , because i force noncachable does not read from the cache on a cache hit. b.2.5 bits [8:6], disable cp15 register 1, ia and nf these 3 bits allow clock switching code compatibility with the sa110 and sa1100 (strongarm). the strongarm implements the following mcr instructions: mcr p15,0,rd,c15,c1,2 ; enable clock switching mcr p15,0,rd,c15,c2,2 ; disable clock switching these are equivalent to selecting asynchronous and fastbus clocking modes respectively. if either of the two strongarm mcr instructions are executed then disable r1 , bit 8, is set. this prevents the iacr and nfcr, bit[31:30] in cp15 register 1, from being used to control clock switching. this is necessary to maintain backwards compatibility with non-armv4t compliant devices, that do not use cp15 register 1 to select the clock mode. the following applies: ia ? = (iacr and not disable r1) or ia_c15 nf ? = (nfcr and not disable r1) or nf_c15 table b-2 shows the clocking mode selection. table b-2 clocking mode selection clocking mode ia ? nf ? fastbus 0 0 synchronous 0 1 reserved 1 0 asynchronous 1 1
cp15 test registers b-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c b.2.6 bit 5, d force noncachable the cachable behavior for a memory region is determined by the and of the dcache enable in cp15 register 1 and the cachable bit of the mmu page table entry: c = ccr and ctt setting the d force noncachable bit effectively forces the c=0. this means all memory accesses are treated as single memory accesses on the amba asb interface. a write that hits in the cache updates the cache. a read that hits in the cache is ignored, and the data read from the amba asb interface does not update the cache. b.2.7 bit 4, i force noncachable the cachable behavior for a memory region is determined by the and of the icache enable in cp15 register 1 and the cachable bit of the mmu page table entry: c = icr and ctt setting the i force noncachable bit effectively forces the c=0. this means all memory accesses are treated as single memory accesses on the amba asb interface. a read that hits in the cache is ignored, and the instruction from the amba asb interface does not update the cache. b.2.8 bit 3, mmu test setting the mmu test bit enables auto-increment of the tlb index pointer in both mmus on cam and ram1 reads and writes. if this bit is not set, the tlb index pointer only increments on ram1 writes. b.2.9 bit 2, i miss abort when itlb page table walks are disabled, the itlb miss causes an instruction abort and indicates a translation fault in the ifsr. the instruction abort handler then has to use a cp15 mcr instruction to write a page table entry to the instruction tlb.it is a requirement that the icache and mmu is enabled when you disable hardware page table walks, otherwise the behavior is unpredictable. b.2.10 bit 1, d miss abort when dtlb page table walks are disabled, the dtlb miss causes a data abort and indicates a translation fault in the dfsr. the data abort handler then has to use a cp15 mcr instruction to write a page table entry to the data tlb.it is a requirement that the dcache and mmu is enabled when you disable hardware page table walks, otherwise the behavior is unpredictable.
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-7 b.2.11 bit 0, cp15 interpret mode this bit is only writable using scan chain 15, selecting register c15.state. this accesses the whole test state register. therefore this bit must be written using read-modify-write. interpreted mode allows interpreted accesses to take place within the arm920t memory system. to do this, the required mcr or mrc instruction word must be shifted into scan chain 15. a system speed ldr (read) or str (write) can then be performed on the arm9tdmi. cp15 will interpret the ldr or str by executing the mcr or mrc instruction held in scan chain 15. in the case of an ldr , the data is returned to the arm9tdmi. in the case of a str, the interpreted mcr or mrc completes with the data from the arm9tdmi. you can exit interpreted mode by performing a read-modify-write to scan chain 15, register c15.state to reset bit 0 to 0.
cp15 test registers b-8 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c b.3 cache test registers and operations the icache and dcache are maintained using mcr and mrc instructions to cp15 registers 7 and 9, defined by the arm v4t programmer ? s model. additional operations are available using mcr and mrc to cp15 register 15. these operations are combined with those using registers 7 and 9 to enable testing of the caches entirely in software. a modified subset of these mcr and mrc instructions is available in amba test for production test. see chapter 11 amba test interface . all mcr and mrc instructions to cp15 are available through the debug scan chains in cp15 interpret mode. this mode of access is intended to be used with a subset of the available cp15 mcr and mrc instructions, such that using other than the minimal subset will cause unpredictable behavior. see chapter 9 debug support . the register 7 operations are all write-only. they are listed in table b-3. the register 9 operations are read and write. they are listed in table b-4. table b-3 register 7 operations cache function i and d, or i, or d invalidate cache i or d invalidate single entry using mva d clean single entry using mva or index d clean and invalidate single entry using mva or index i prefetch cache line using mva table b-4 register 9 operations cache function i or d read lockdown base (applies to all cache segments). i or d write victim and lockdown base (applies to all cache segments). i or d write victim for specified segment. this is provided for debug only and is not specified by armv4t.
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-9 the register 15 operations are listed in table b-5. the harvard architecture allows you to combine all of these operations to operate on both the icache and dcache in parallel. note for the cam match, ram read operation the respective mmu does not perform a lookup and a cache miss does not cause a linefill. these register 15 operations are all issued as mcr . in these, rd defines the address for the operation. therefore, the data is either supplied from, or latched into, the cp15.c.i or cp15.c.d in cp15. these 32 bit registers are accessed with the cp15 mcr and mrc instructions shown in table b-6. again, the harvard architecture allows the data to be written to both cp15.c. in parallel. table b-5 register 15 operations cache function rd data i and d, or i, or d set dirty all entries sbz - i and d, or i, or d cam read to c15.c. seg tag, dirty, index i and d, or i, or d cam write tag, seg, dirty - i and d, or i, or d ram read to c15.c. seg, word data i and d, or i, or d ram write from c15.c. seg, word - i and d, or i, or d cam match ram read to reg c15.c. tag, seg, word hit or miss, data table b-6 cp15 mcr and mrc instructions cache function i and d, or i, or d write to register cp15.c. i or d read from register cp15.c.
cp15 test registers b-10 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c table b-7 summarizes c7, c9, and c15 operations. table b-7 register 7, 9, and 15 operations function rd instruction invalidate icache and dcache sbz mcr p15,0,rd,c7,c7,0 invalidate icache sbz mcr p15,0,rd,c7,c5,0 invalidate icache single entry (using mva) mva format mcr p15,0,rd,c7,c5,1 prefetch icache line (using mva) mva format mcr p15,0,rd,c7,c13,1 invalidate dcache sbz mcr p15,0,rd,c7,c6,0 invalidate dcache single entry (using mva) mva format mcr p15,0,rd,c7,c6,1 clean dcache single entry (using mva) mva format mcr p15,0,rd,c7,c10,1 clean and invalidate dcache entry (using mva) mva format mcr p15,0,rd,c7,c14,1 clean dcache single entry (using index) index format mcr p15,0,rd,c7,c10,2 clean and invalidate dcache entry (using index) index format mcr p15,0,rd,c7,c14,2 drain write buffer a sbz mcr p15,0,rd,c7,c10,4 wait for interrupt b sbz mcr p15,0,rd,c7,c0,4 read dcache lockdown base base mrc p15,0,rd,c9,c0,0 write dcache victim and lockdown base victim=base mcr p15,0,rd,c9,c0,0 write dcache victim victim, seg mcr p15,0,rd,c9,c1,0 read icache lockdown base base mrc p15,0,rd,c9,c0,1 write icache victim and lockdown base victim=base mcr p15,0,rd,c9,c0,1 write icache victim victim, seg mcr p15,0,rd,c9,c1,1 i set dirty all entries sbz mcr p15,2,rd,c15,c1,0 d set dirty all entries sbz mcr p15,2,rd,c15,c2,0 i and d set dirty all entries sbz mcr p15,2,rd,c15,c3,0
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-11 i cam read to c15.c.i seg mcr p15,2,rd,ci5,c5,2 d cam read to c15.c.d seg mcr p15,2,rd,c15,c6,2 i cam read to c15.c.i and d cam read to c15.c.d seg mcr p15,2,rd,c15,c7,2 i cam write tag, seg, dirty mcr p15,2,rd,c15,c5,6 d cam write tag, seg, dirty mcr p15,2,rd,c15,c6,6 i and d cam write tag, seg, dirty mcr p15,2,rd,c15,c7,6 i ram read to c15.c.i seg, word mcr p15,2,rd,c15,c9,2 d ram read to c15.c.d seg, word mcr p15,2,rd,c15,c10,2 i ram read to c15.c.i and d ram read to c15.c.d seg, word mcr p15,2,rd,c15,c11,2 i ram write from c15.c.i seg, word mcr p15,2,rd,c15,c9,6 d ram write from c15.c.d seg, word mcr p15,2,rd,c15,c10,6 i ram write from c15.c.i and d ram write from c15.c.d seg, word mcr p15,2,rd,c15,c11,6 i cam match, ram read to c15.c.i tag, seg, word mcr p15,2,rd,c15,c5,5 d cam match, ram read to c15.c.d tag, seg, word mcr p15,2,rd,c15,c6,5 i cam match, ram read to c15.c.i and d cam match, ram read to c15.c.d tag, seg, word mcr p15,2,rd,c15,c7,5 write to c15.c.i data mcr p15,3,rd,c15,c1,0 write to c15.c.d data mcr p15,3,rd,c15,c2,0 write to c15.c.i and write to c15.c.d data mcr p15,3,rd,c15,c3,0 read from c15.c.i data read mrc p15,3,rd,c15,c1,0 read from c15.c.d data read mrc p15,3,rd,c15,c2,0 a. stops execution until the write buffer has drained. b. stops execution in a low power state until an interrupt occurs. table b-7 register 7, 9, and 15 operations (continued) function rd instruction
cp15 test registers b-12 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the cam read format for rd is shown in figure b-2. figure b-2 rd format, cam read the cam write format for rd is shown in figure b-3. figure b-3 rd format, cam write in figure b-3, bit labels have the following meanings: v valid de dirty even (words [3:0]) do dirty odd (words [7:4]) wb writeback. the ram read format for rd is shown in figure b-4. figure b-4 rd format, ram read 31 87 54 0 sbz seg sbz 31 87 54 0 mva tag seg sbz 321 v de do wb 31 87 54 0 sbz seg sbz 21 word
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-13 the ram write format for rd is shown in figure b-5. figure b-5 rd format, ram write the cam match, ram read format for rd is shown in figure b-6. figure b-6 rd format, cam match ram read the cam read format for data is shown in figure b-7. figure b-7 data format, cam read in amba cache test mode, the lfsr for the cache is restricted to increment only on a cam read. the ram read format for data is shown in figure b-8. figure b-8 data format, ram read 31 87 54 0 sbz seg sbz 21 word 31 87 54 0 mva tag seg sbz 21 word 31 8 7 54 0 mva tag seg [2:1] lfsr[6] 321 v de do wb 6 0 31 0 ram data word [31:0]
cp15 test registers b-14 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the cam match, ram read format for data is shown in figure b-9. figure b-9 data format, cam match ram read b.3.1 addressing the cam and ram for the cam read or write, and ram read or write operations you must specify the segment, index, and word (for the ram operations). see addressing the 16kb icache on page 4-5. the cam and ram operations use the value in the victim pointer for that segment, so you must ensure that the value is written in the victim pointer before any cam or ram operation. if the mcr write victim and lockdown base is used, then the victim pointer is incremented after every cam read or write, and every ram read or write. if the mcr write victim is used, then the victim pointer is only incremented after every cam read or write. this enables efficient reading or writing of the cam and ram for an entire segment. the write cache victim and lockdown operations are listed in table b-8. 31 30 29 0 miss ram data word [29:0] hit table b-8 write cache victim and lockdown operations operation instruction write dcache victim and lockdown base mcr p15,0,rd,c9,c0,0 write dcache victim mcr p15,0,rd,c9,c1,0 write icache victim and lockdown base mcr p15,0,rd,c9,c0,1 write icache victim mcr p15,0,rd,c9,c1,1
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-15 the write i or d cache victim and lockdown base format for rd is shown in figure b-10. figure b-10 rd format, write i or d cache victim and lockdown base the write i or d cache victim format for rd is shown in figure b-11. figure b-11 rd format, write i or d cache victim there are two other cache test registers that are only accessible using debug scan chain 15. these are c15.c..ind. these registers are written with the current victim of the addressed segment whenever an mcr cam read is executed. this is intended for use in debug to establish the value of the current victim pointer of each segment before reading the values of the cam and ram, so that the value can be restored afterwards. see chapter 9 debug support . example b-1 shows sample code for performing software test of the d cache. it contains typical operations with c15.c.d. example b-1 dcache test operations tag_lsb equ 0x8 seg_lsb equ 0x5 vld_lsb equ 0x4 ; valid bit de_lsb equ 0x3 ; dirty even bit do_lsb equ 0x2 ; dirty odd bit wb_lsb equ 0x1 ; write back bit word_lsb equ 0x2 lock_lsb equ 0x1a ; load dcache victim and lockdown base with 32 mov r0,#32 :shl: lock_lsb mcr p15,0,r0,c9,c0,0 31 26 25 0 sbz index 31 26 25 8 7 5 4 0 sbz seg sbz index
cp15 test registers b-16 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c ; do dcache cam write to seg 7, index 32 ldr r1,=0x123456 ; cam tag mov r0,r1,lsl #tag_lsb orr r0,r0,#7 :shl: seg_lsb ; segment orr r0,r0,#1 :shl: vld_lsb ; valid bit orr r0,r0,#1 :shl: de_lsb ; dirty even bit orr r0,r0,#1 :shl: do_lsb ; dirty odd bit orr r0,r0,#1 :shl: wb_lsb ; writeback bit mcr p15,2,r0,c15,c6,6 ; cam write ; reload dcache lock-down pointer because it will have incremented mov r0,#32 :shl: lock_lsb mcr p15,0,r0,c9,c0,0 ; do dcache ram write to seg 7, index 32, word 6 ldr r0,=0x89abcdef ; ram data mcr p15,3,r0,c15,c2,0 ; write ram data to ; c15.c.d mov r0,#7 :shl: seg_lsb ; segment orr r0,r0,#6 :shl: word_lsb ; word mcr p15,2,r0,c15,c10,6 ; ram write from c15.c.d ; clear c15.c.d to prove that data comes back from dcache mov r0,#0 mcr p15,3,r0,c15,c2,0 ; write c15.c.d ; do a cam match, ram read to c15.c.d ldr r1,=0x123456 mov r0,r1,lsl #tag_lsb ; tag orr r0,r0,#7 :shl: seg_lsb ; segment orr r0,r0,#6 :shl: word_lsb ; word mcr p15,2,r0,c15,c6,5 ; cam match, ram read ; read c15.c.d and compare with expected data. ; note that the top 2 bits of the ram data returned from the cam match ; give the hit and miss information [31:30] = [miss,hit] mrc p15,3,r0,c15,c2,0 ; read c15.c.d ; check the cam match for a hit mov r2,#0xc0000000 ; mask bits [31:30] andr2,r2,r0 mov r3,#0x80000000 ; hit cmp r2,r3 bne fail
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-17 ; check the ram data mov r0,r0,lsl #2 ; remove bits [31:30] ldr r1,=0x89abcdef ; expected data mov r1,r1,lsl #2 ; remove bits [31:30] cmp r0,r1 bne fail test_pass fail test_fail end b.3.2 testing the lfsr there is an 8-bit lfsr in both the dcache and icache that is used to provide the pseudo-random sequence to increment the segment victim counters in random mode. this is the default setting of the rr bit in cp15 register 1, bit 14. the lfsr is tested in a controlled manner in amba cache test mode. in this mode the lfsr is reset to its seed value by performing an mcr invalidate all , and is incremented once by performing a cam read. for each cam read, bit 6 of bits[7:0] is sampled onto bit 0 of the cam read data. the by-product of this is that lfsr[6] is sampled for any cam read, but the lfsr is clocked freely when not in amba cache test mode. see chapter 11 amba test interface .
cp15 test registers b-18 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c b.4 mmu test registers and operations the itlb and dtlb are maintained using mcr and mrc instructions to cp15 registers 2, 3, 5, 6, 8, and 10, defined by the arm v4t programmer ? s model. additional operations are available using mcr and mrc instructions to cp15 register 15. these operations are combined with those using registers 2, 3, 5, 6, 8, and 10 to enable testing of the tlbs entirely in software. a modified subset of these mcr and mrc instructions are available in amba test for production test. see chapter 11 amba test interface . all mcr and mrc instructions to cp15 are available through the debug scan chains in cp15 interpret mode. this mode of access is intended to be used with a subset of the available cp15 mcr and mrc instructions, so that using other than the minimal subset causes unpredictable behavior. see scan chains 4 and 15, the arm920t memory system on page 9-31. the register 2 operations are read and write. they are extended by the register 15 operations to allow individual control of the separate i and d translation table base (ttb) registers, and are listed in table b-9. table b-9 ttb register operations register tlb function c2 i and d write i and d ttb registers c2 d read d ttb register c15 i write i ttb register c15 d write d ttb register c15 i read i ttb register
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-19 the register 3 operations are read and write. they are extended by the register 15 operations to allow individual control of the separate i and d domain access control (dac) registers, and are listed in table b-10. the register 5 operations are read and write, but the ability to access the i fsr is not architecturally defined in armv4t and is only intended for debug, when testing the tlb miss mechanism using aborts rather than hardware page table walks. register 5 operations are listed in table b-11. the register 15 duplication remains from arm920t rev 0. table b-10 dac register operations register tlb function c3 i and d write i and d dac registers c3 d read d dac register c15 i write i dac register c15 d write d dac register c15 i read i dac register table b-11 fsr register operations reg tlb function c5 i or d write fault status register (fsr) c5 i or d read fsr c15 i write i fsr c15 i read i fsr
cp15 test registers b-20 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c the register 6 operations are read and write. the i tlb is identical to the d tlb, but the i far is not architecturally defined, so the ability to access the i far is for testability only and the mcr and mrc instructions are described by the armv4t as being unpredictable. register 6 operations are listed in table b-12. the register 8 operations are all write-only. they are listed in table b-13. the register 10 operations are read and write. they are listed in table b-14. the register 15 operations that operate on the cam, ram1, and ram2 are listed in table b-15. table b-12 far register operations reg tlb function c6 i or d write fault address register (far) c6 i or d read far table b-13 register 8 operations reg tlb function c8 i and d, or i, or d invalidate tlb c8 i or d invalidate single entry using mva table b-14 register 10 operations reg tlb function c10 i or d read victim, lockdown base and preserve bit c10 i or d write victim, lockdown base and preserve bit table b-15 cam, ram1, and ram2 register 15 operations tlb function rd data i or d cam read to c15.m. sbz tag, size, v, p i and d, or i, or d cam write tag, size, v, p i or d ram1 read to c15.m. sbz protection
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-21 while the arm920t memory system is a harvard architecture, the tlbs are accessed using cdata. this means the write operations can be combined to operate on both the i tlb and d tlb in parallel. note setting the cp15 register 15 test status register mmu test bit (bit 3) enables auto-increment of the tlb index pointer in both mmus on cam and ram1 reads and writes. if this bit is not set, the tlb index pointer only increments on ram1 writes. for the cam match, ram1 read operation a tlb miss does not cause a page walk. these register 15 operations are all issued as mcr , which means that the read and match operations have to be latched into the cp15.m.i or cp15.m.d in cp15. these are 32 bit registers that are read with the following cp15 mrc instruction: read from register cp15.m. table b-16 summarizes c2, c3, c5, c6, c8, c10, and c15 operations. i and d, or i, or d ram1 write protection i or d ram2 read to c15.m. sbz pa tag, size i and d, or i, or d ram2 write pa tag, size pa tag, size i or d cam match ram1 read to c15.m. mva fault, miss, protection table b-16 register 2, 3, 5, 6, 8, 10, and 15 operations function rd instruction read ttb register ttb mrc p15,0,rd,c2,c0,0 write ttb register ttb mcr p15,0,rd,c2,c0,0 read domain 15:0 access control dac mrc p15,0,rd,c3,c0,0 write domain 15:0 access control dac mcr p15,0,rd,c3,c0,0 table b-15 cam, ram1, and ram2 register 15 operations (continued) tlb function rd data
cp15 test registers b-22 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c read data fsr value fsr mrc p15,0,rd,c5,c0,0 write data fsr value fsr mcr p15,0,rd,c5,c0,0 read prefetch fsr value a fsr mrc p15,0,rd,c5,c0,1 write prefetch fsr value a fsr mcr p15,0,rd,c5,c0,1 read d far far mrc p15,0,rd,c6,c0,0 write d far far mcr p15,0,rd,c6,c0,0 read i far a far mrc p15,0,rd,c6,c0,1 write i far a far mcr p15,0,rd,c6,c0,1 invalidate tlb(s) sbz mcr p15,0,rd,c8,c7,0 invalidate i tlb sbz mcr p15,0,rd,c8,c5,0 invalidate i tlb single entry (using mva) mva format mcr p15,0,rd,c8,c5,1 invalidate d tlb sbz mcr p15,0,rd,c8,c6,0 invalidate d tlb single entry (using mva) mva format mcr p15,0,rd,c8,c6,1 read d tlb lockdown tlb lockdown mrc p15,0,rd,c10,c0,0 write d tlb lockdown tlb lockdown mcr p15,0,rd,c10,c0,0 read i tlb lockdown tlb lockdown mrc p15,0,rd,c10,c0,1 write i tlb lockdown tlb lockdown mcr p15,0,rd,c10,c0,1 read i ttb ttb mrc p15,5,rd,c15,c1,2 write i ttb ttb mcr p15,5,rd,c15,c1,2 write d ttb ttb mcr p15,5,rd,c15,c2,2 read i dac dac mrc p15,5,rd,c15,c1,3 write i dac dac mcr p15,5,rd,c15,c1,3 write d dac dac mcr p15,5,rd,c15,c2,3 table b-16 register 2, 3, 5, 6, 8, 10, and 15 operations (continued) function rd instruction
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-23 read prefetch fsr value fsr mrc p15,5,rd,c15,c1,5 write prefetch fsr value fsr mcr p15,5,rd,c15,c1,5 d cam read to c15.m.d sbz mcr p15,4,rd,c15,c6,4 i cam read to c15.m.i sbz mcr p15,4,rd,c15,c5,4 d cam write tag, size, v, p mcr p15,4,rd,c15,c6,0 i cam write tag, size, v, p mcr p15,4,rd,c15,c5,0 d and i cam write tag, size, v, p mcr p15,4,rd,c15,c7,0 d ram1 read to c15.m.d sbz mcr p15,4,rd,c15,c10,4 i ram 1 read to c15.m.i sbz mcr p15,4,rd,c15,c9,4 d ram1 write protection mcr p15,4,rd,c15,c10,0 i ram 1 write protection mcr p15,4,rd,c15,c9,0 d and i ram1 write protection mcr p15,4,rd,c15,c11,0 d ram2 read to c15.m.d sbz mcr p15,4,rd,c15,c2,5 i ram2 read to c15.m.i sbz mcr p15,4,rd,c15,c1,5 d ram2 write pa tag, size mcr p15,4,rd,c15,c2,1 i ram2 write pa tag, size mcr p15,4,rd,c15,c1,1 d and i ram2 write pa tag, size mcr p15,4,rd,c15,c3,1 d cam match, ram1 read to c15.m.d mva mcr p15,4,rd,c15,c14,4 i cam match, ram1 read to c15.m.i mva mcr p15,4,rd,c15,c13,4 read c15.m.d data mrc p15,4,rd,c15,c2,6 read c15.m.i data mrc p15,4,rd,c15,c1,6 a. these mcr and mrc instructions are not architecturally defined in armv4t, and are only intended for testability. their behavior is described by armv4t as being unpredictable. table b-16 register 2, 3, 5, 6, 8, 10, and 15 operations (continued) function rd instruction
cp15 test registers b-24 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure b-12 shows the format of rd for cam writes and data for cam reads. figure b-12 rd format, cam write and data format, cam read in figure b-12, v is the valid bit, p is the preserve bit, and size_c sets the memory region size. the allowed values of size_c are shown in table b-17. figure b-13 shows the format of rd for ram1 writes. figure b-13 rd format, ram1 write in figure b-13, ap[3:0] determines the setting of the access permission bits for a memory region. the allowed values are listed in table b-18 on page b-25. 31 9 10 54 0 mva tag size_c 3 p 6 v sbz table b-17 cam memory region size size_c[3:0] memory region size 0b1111 1mb 0b0111 64kb 0b0011 16kb 0b0001 4kb 0b0000 1kb 31 2221 6543 0 ap sbz domain [d15:d0] (one hot encoding) nb nc d15 d0
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-25 figure b-14 shows the data format for ram1 reads. figure b-14 data format, ram1 read in figure b-14, bits [24:22] are only valid for a match operation. in this case the values listed in table b-19 apply. table b-18 access permission bit setting ap[3:0] access permission bits 0b1000 0b11 0b0100 0b10 0b0010 0b01 0b0001 0b00 31 2221 6543 0 ap sbz domain [d15:d0] (one hot encoding) nb nc 23 24 25 prot fault tlb miss domain fault d15 d0 table b-19 miss and fault encoding prot fault domain fault tlb miss function 0 0 0 hit, ok 0 1 0 hit, domain fault 1 0 0 hit, protection fault 1 1 0 hit, protection and domain fault - - 1 tlb miss
cp15 test registers b-26 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c figure b-15 shows the rd format for ram2 writes, and the data format for ram2 reads. figure b-15 rd format, ram2 write and data format, ram2 read in figure b-15, size_r2 sets the memory region size. the allowed values of size_r2 are shown in table b-20. note the encoding for size_r2 is different from size_c. b.4.1 addressing the cam, ram1, and ram2 for the cam read or write, ram1 read or write, and ram2 read or write operations, you must specify the index. the cam and ram1 operations use the value in the victim pointer, so you must write this before any cam or ram1 operation. ram2 uses a pipelined version of the victim pointer used for the cam or ram1 operation. this means that to read from index n in the ram2 array, you must first perform an access to index n in either the cam or ram1. 31 9 10 50 pa tag size_r2 6 sbz table b-20 ram2 memory region size size_r2[3:0] memory region size 0b1111 1mb 0b0111 64kb 0b0011 16kb 0b0000 4kb 0b0001 1kb
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-27 the write tlb lockdown operations are listed in table b-21. the write i or d tlb lockdown format for rd is shown in figure b-16. figure b-16 rd format, write i or d tlb lockdown example b-2 shows sample code for performing software test of the dmmu. it contains typical operations with c15.m.d. example b-2 dmmu test operations lock_base_lsb equ 0x1a lock_vict_lsb equ 0x14 p_state_lsb equ 0x0 p_entry_lsb equ 0x4 vatag_lsb equ 0xa vasize_lsb equ 0x6 valid_lsb equ 0x5 domain8_lsb equ 0xe domain_lsb equ 0x6 ncache_lsb equ 0x5 nbuff_lsb equ 0x4 access_lsb equ 0x0 patag_lsb equ 0xa pasize_lsb equ 0x7 ; write the dac so that when doing a ram1 read ; bits [24:23] (p-fault, d-fault) can be defined mov r0,#0 mcr p15,0,r0,c3,c0,0 table b-21 write tlb lockdown operations operation instruction write d tlb lockdown mcr p15,0,rd,c10,c0,0 write i tlb lockdown mcr p15,0,rd,c10,c0,1 31 26 25 20 19 1 0 base victim p sbz
cp15 test registers b-28 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c ; load the dmmu lock-down pointer to index 25 mov r0,#25 :shl: lock_base_lsb ; base orr r0,r0,#25 :shl: lock_vict_lsb ; victim orr r0,r0,#0 :shl: p_state_lsb ; preserve mcr p15,0,r0,c10,c0,0 ; cam write to index 25 ldr r0,=0xaaaaa mov r0,r0,lsl #vatag_lsb ; mva tag orr r0,r0,#1 :shl: vasize_lsb ; size_c orr r0,r0,#1 :shl: valid_lsb ; valid orr r0,r0,#1 :shl: p_entry_lsb ; preserve mcr p15,4,r0,c15,c6,0 ; ram2 write to index 25 ; the ram2 location pointed to for reads and writes ; is whichever cam and ram1 location was last read or written. ldr r0,=0x55555 mov r0,r0,lsl #patag_lsb ; patag orr r0,r0,#3 :shl: pasize_lsb ; size_r2 mcr p15,4,r0,c15,c2,1 ; as cp15 register 15, test status register, mmu test (bit 3) is not set, ; the victim pointer will only increment after the ram1 write. ; so ram1 write to index 25 (victim increments to 26 after the write) mov r0,#0 orr r0,r0,#0 :shl: domain8_lsb ; upper 8 domains orr r0,r0,#1 :shl: domain_lsb ; lower 8 domains orr r0,r0,#1 :shl: ncache_lsb ; nc orr r0,r0,#1 :shl: nbuff_lsb ; nb orr r0,r0,#8 :shl: access_lsb mcr p15,4,r0,c15,c10,0 ; load the dmmu lock-down pointer to index 25 mov r0,#25 :shl: lock_base lsb ; base orr r0,r0,#25 :shl: lock_vict_lsb ; victim orr r0,r0,#0 :shl: p_state_lsb ; preserve mcr p15,0,r0,c10,c0,0 ; ram1 read to c15.m.d mcr p15,4,r0,c15,c10,4 ; read c15.m.d to r1 mrc p15,4,r1,c15,c2,6 ; ram2 read to c15.m.d mcr p15,4,r0,c15,c2,5 ; read c15.m.d to r3
cp15 test registers arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. b-29 mrc p15,4,r3,c15,c2,6 ; cam match, ram1 read to c15.m.d ldr r0,=0xaaaaa mov r0,r0,lsl #vatag_lsb mcr p15,4,r0,c15,c14,4 ; read c15.m.d to r2 mrc p15,4,r2,c15,c2,6 ; compare match value to read value and ram2 read value to write value ldr r4,=0x55555 ; expected ram2 pa tag mov r4,r4,lsl #patag_lsb orr r4,r4,#3 :shl: pasize_lsb cmp r1,r2 ; compare ram1 read with ; cam match, ram1 read cmpeq r3,r4 ; compare ram2 read with ; expected ram2 bne fail test_pass fail test_fail end
cp15 test registers b-30 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c b.5 strongarm backwards compatibility operations the following mcr instructions are supported to provide clock switching and mcr wait for interrupt compatibility with sa110 and sa1100 (strongarm). mcr p15,0,rd,c15,c1,2 ; enable clock switching this is equivalent to asynchronous clocking mode. mcr p15,0,rd,c15,c2,2 ; disable clock switching this is equivalent to fastbus clocking mode. mcr p15,0,rd,c15,c8,2 ; wait for interrupt this is equivalent to mcr p15,0,rd,c7,c0,4. these three mcr instructions must not be used and are deprecated in arm architectures after v4t.
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. glossary-1 glossary this glossary describes some of the terms used in this manual. where terms can have several meanings, the meaning presented here is intended. abort a mechanism that indicates to a core that it should halt execution of an attempted illegal memory access. an abort can be caused by the external or internal memory system as a result of attempting to access invalid instruction or data memory. an abort is classified as either a prefetch abort, a data abort, or an external abort. see also data abort , external abort and prefetch abort . abort model an abort model is the defined behavior of an arm processor in response to a data abort exception. different abort models behave differently with regard to load and store instructions that specify base register writeback. alu see arithmetic logic unit . application specific integrated circuit an integrated circuit that has been designed to perform a specific application function. it can be custom-built or mass-produced. arithmetic logic unit the part of a processor core that performs arithmetic and logic operations. arm state a processor that is executing arm (32-bit) word-aligned instructions is operating in arm state.
glossary glossary-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c asic see application specific integrated circuit . banked registers those physical registers whose use is defined by the current processor mode. the banked registers are r8 to r14. base register a register specified by a load or store instruction that is used to hold the base value for the instruction ? s address calculation. big-endian byte ordering scheme in which bytes of decreasing significance in a data word are stored at increasing addresses in memory. see also little-endian and endianness . breakpoint a breakpoint is a mechanism provided by debuggers to identify an instruction at which program execution is to be halted. breakpoints are inserted by the programmer to allow inspection of register contents, memory locations, variable values at fixed points in the program execution to test that the program is operating correctly. breakpoints are removed after the program is successfully tested. see also watchpoint . byte an 8-bit data item. cache a block of on-chip or off-chip fast access memory locations, situated between the processor and main memory, used for storing and retreiving copies of often used instructions and/or data. this is done to greatly reduce the average speed of memory accesses and so to increase processor performance. cache contention when the number of frequently-used memory cache lines that use a particular cache set exceeds the set-associativity of the cache. in this case, main memory activity increases and performance decreases. cache hit a memory access that can be processed at high speed because the instruction or data that it addresses is already held in the cache. cache line index the number associated with each cache line in a cache set. within each cache set, the cache lines are numbered from 0 to (set associativity) -1. cache lockdown to fix a line in cache memory so that it cannot be overwritten. cache lockdown allows critical instructions and/or data to be loaded into the cache so that the cache lines containing them will not subsequently be reallocated. this ensures that all subsequent accesses to the instructions/data concerned are cache hits, and therefore complete as quickly as possible. cache miss a memory access that cannot be processed at high speed because the instruction/data it addresses is not in the cache and a main memory access is required. cam see content addressable memory . central processing unit the part of a processor that contains the alu, the registers, and the instruction decode logic and control circuitry. also commonly known as the processor core.
glossary arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. glossary-3 clock gating gating a clock signal for a macrocell with a control signal (such as pwrdown ) and using the modified clock that results to control the operating state of the macrocell. condition field a 4-bit field in an instruction that is used to specify a codition under which the instruction can execute. content addressable memory memory that is identified by its contents. content addressable memory is used in cam-ram architecture caches to store the tags for cache entries. coprocessor a processor that supplements the main cpu. it carries out additional functions that the main cpu cannot perform. usually used for floating-point math calculations, signal processing, or memory management. cpu see central processing unit . data abort an indication from a memory system to a core that it should halt execution of an attempted illegal memory access. a data abort is attempting to access invalid data memory. see also abort , external abort and prefetch abort . data cache see dcache . dcache a block of on-chip fast access memory locations, situated between the processor and main memory, used for storing and retreiving copies of often used data. this is done to greatly reduce the average speed of memory accesses and so to increase processor performance. debugger a debugging system that includes a program, used to detect, locate, and correct software faults, together with custom hardware that supports software debugging. domain a collection of sections, large pages and small pages of memory, which can have their access permissions switched rapidly by writing to the domain access control register (cp15 register 3). double word a 64-bit data item. the contents are taken as being an unsigned integer unless otherwise stated. embeddedice the additional jtag-based hardware provided by debuggable arm processors to aid debugging. endianness byte ordering. the scheme that determines the order in which successive bytes of a data word are stored in memory. see also little-endian and big-endian . exception vector one of a number of fixed addresses in low memory, or in high memory if high vectors are configured, that contains the first instruction of the corresponding interrupt service routine.
glossary glossary-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c external abort an indication from an external memory system to a core that it should halt execution of an attempted illegal memory access. an external abort is caused by the external memory system as a result of attempting to access invalid memory. see also abort , data abort and prefetch abort halfword a 16-bit data item. icache a block of on-chip fast access memory locations, situated between the processor and main memory, used for storing and retreiving copies of often used instructions. this is done to greatly reduce the average speed of memory accesses and so to increase processor performance. instruction cache see icache . joint test action group the name of the organization that developed standard ieee 1149.1. this standard defines a boundary-scan architecture used for in-circuit testing of integrated circuit devices. it is commonly known by the initials jtag. jtag see joint test action group . little-endian byte ordering scheme in which bytes of increasing significance in a data word are stored at increasing addresses in memory. see also big-endian and endianness . macrocell a complex logic block with a defined interface and behavior. a typical vlsi system will comprise several macrocells (such as an arm9e-s, an etm9, and a memory block) plus application-specific logic. prefetch abort an indication from a memory system to a core that it should halt execution of an attempted illegal memory access. a prefetch abort can be caused by the external or internal memory system as a result of attempting to access invalid instruction memory. see also data abort , external abort and abort processor a contraction of microprocessor. a processor includes the cpu or core, plus additional components such as memory, and interfaces. these are combined as a single macrocell, that can be fabricated on an integrated circuit. region a partition of instruction or data memory space. register a temporary storage location used to hold binary data until it is ready to be used. sbo see should be one . sbz see should be zero . screg the currently selected scan chain number in an arm tap controller. should be one should be written as 1 (or all 1s for bit fields) by software. writing a 0 will produce unpredictable results.
glossary arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. glossary-5 should be zero should be written as 0 (or all 0s for bit fields) by software. writing a 1 will produce unpredictable results. tag bits the index or key field of a cam entry. ta p see test access port . test access port the collection of four mandatory and one optional terminals that form the input/output and control interface to a jtag boundary-scan architecture. the mandatory terminals are tdi , tdo , tms , and tck . the optional terminal is trst . thumb state a processor that is executing thumb (16-bit) half-word aligned instructions is operating in thumb state undefined an instruction that generates an undefined instruction exception. unpredictable for reads, the data returned when reading from this location is unpredictable. it can have any value. for writes, writing to this location causes unpredictable behavior, or an unpredictable change in device configuration. unpredictable instructions must not halt or hang the processor, or any part of the system. watchpoint a watchpoint is a mechanism provided by debuggers to halt program execution when the data contained by a particular memory address is changed. watchpoints are inserted by the programmer to allow inspection of register contents, memory locations, and variable values when memory is written to test that the program is operating correctly. watchpoints are removed after the program is successfully tested. see also breakpoint . word a 32-bit data item.
glossary glossary-6 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c
arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. index-1 index the items in this index are listed in alphabetical order. the references given are to page numbers. a absent 7-7 access permission 3-2 bits 3-24 address 2-6 translation 3-6 ahb interface 6-21 alignment faults 3-21 amba signals a-2 amba test burst operations 11-11 cache test mode 11-15 entering and exiting 11-3 functional test mode 11-4 interface 11-2 mmu test mode 11-19 modes 11-3 pa tag ram test mode 11-12 arm7tdmi code compatibility 2-3 arm9tdmi 1-2 implementation options 2-3 arm920t 1-2 bus interface 6-2 clocking 5-2 connecting to asb interface 6-5 arm940t 1-2 asb 6-3, 6-5 interface, fully compliant 6-5 slave transfers 6-20 b base restored data abort model 2-3 base updated data abort model 2-3 bidirectional signals 6-5 block diagram, functional 1-3 breakpoint 9-5, 9-51 and exception 9-6 timing 9-5 buffer 6-5 buffered stm 6-15 buffered str 6-14 burst transfers 6-7 bus interface 6-2 busy-wait abandoned 7-17 interrupted 7-17 bypass register 9-19 c cache associativity encoding 2-11 cleaning 4-20 coherence 4-17 lockdown register 2-20 operations register 2-17 size encoding 2-11 test mode, amba 11-15 test register b-8 type register 2-8 cached fetch 6-16 ldm 6-16 ldr 6-16
index index-2 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c cdp 7-13 clock switching 9-43, b-5, b-30 clocking modes 2-14 clocks dclk 9-42 gclk 9-42 internally tck generated clock 9-42 memory clock 9-42 coarse page table descriptor 3-11 code compatibility 2-3 coherence, cache 4-17 comms channel 9-66 control register 2-12 coprocessor clocking 7-3 external 7-2 handshake encoding 7-8 instructions 7-3 coprocessor instructions privileged modes 7-15 coprocessor interface 7-2 signals a-5 cpu aborts 3-21 cp14 2-2, 7-2 cp15 2-2, 7-2 accessing registers 2-6 debug access 9-33 interpreted access 9-34 mrc and mcr bit pattern 2-7 register map 2-5 test registers b-2 d data abort model 2-3 dcache enabling and disabling 4-10 operation 4-10 organization 4-4, 4-13 replacement algorithm 4-13 debug comms control register 9-64 communications 9-66 communications channel 9-64 control register 9-60 debug scan chain 9-28 entered from arm state 9-45 debug (continued) entered from thumb state 9-45 hardware extensions 9-2 instruction register 9-13 interface standard 9-2 request 9-10, 9-52 scan chains 9-23 signals a-10 speed 9-46 state 9-10 status register 9-60 system 9-3 debug state actions of arm920t 9-10 breakpoint and exception 9-6 entry on breakpoint 9-5 entry on debug request 9-10 entry on watchpoint 9-6 exit from 9-48 watchpoint and exception 9-9 descriptor coarse page table 3-11 fine page table 3-12 level one 3-8 level two 3-14 section 3-10 device id code register 9-19 dirty data eviction 6-17 domain 3-2 access control 3-23 access control register 2-15 faults 3-21, 3-26 e embeddedice 9-54 accessing hardware registers 9-29 control registers 9-56 macrocell 9-1 mask registers 9-56 register map 9-54 single stepping 9-63 embeddedice watchpoint units debugging 9-11 programming 9-11 testing 9-11 etm interface 8-2 extension space 2-4 external aborts 3-28 coprocessors 7-2 scan chains 9-21 f far 2-17, 3-22 fast context switch 2-26 fastbus mode 5-3 fault address register 2-17, 3-22 checking 3-25 domain 3-26 permission 3-27 status register 2-16, 3-22 translation 3-26 fine page table descriptor 3-12 fsr 2-16, 3-22 functional block diagram 1-3 functional test 11-4 g go 7-7 h handshake signals 7-7 harvard architecture 1-2 i icache operation 4-6 replacement algorithm 4-7 id code register 2-8 implementation options 2-3 instruction cycle counts and bus activity 12-3 data bus instruction times 12-4 instruction set extension spaces 2-4 interlocked mcr 7-11
index arm ddi 0151c copyright ? 2000, 2001 arm limited. all rights reserved. index-3 interlocks 12-6 ldm dependent timing 12-9 ldm timing 12-7 single load timing 12-6 two cycle load timing 12-7 j jtag and tap controller signals a-7 interface 9-11 state machine 9-12 l large page references, translating 3-17 last 7-7 ldc 7-5 level one descriptor 3-8 descriptor, accessing 3-8 fetch 3-8 level two cache support 6-23 level two| descriptor 3-14 lfsr testing b-17 line length encoding 2-12 m mcr 7-9 interlocked 7-11 memory management unit 3-2 miscellaneous signals a-12 mmu 3-2 enabling 2-14 enabling and disabling 3-29 fault checking 3-25 faults 3-21 registers 3-4 mmu test mode 11-19 registers b-18 modified virtual address 2-6 mrc 7-9 mva 2-6 n nonbuffered stm 6-15 nonbuffered str 6-14 noncached fetches 6-12 noncached ldm 6-13 noncached ldrs 6-12 o options, implementation 2-3 p pa 2-6 pa tag ram 4-22 debug access 9-39 page tables 3-7 page walk 6-20 pc behavior during debug 9-51 return calculation in debug 9-53 performance analysis 6-23 permission faults 3-21, 3-27 physical address 2-6 tag ram 4-22 pipeline interlocks 12-6 privileged instructions 7-15 process id register 2-24 processor state, determining 9-45 r register bypass 9-19 cache lockdown 2-20 cache operations 2-17 cache test b-8 cache type 2-8 control 2-12 device id code 9-19 domain access control 2-15 fault address 2-17, 3-22 register(continued) fault status 2-16, 3-22 id code 2-8 map, cp15 2-5 mmu test b-18 process id 2-24 scan chain select 9-20 tap instruction 9-20 test b-2 test configuration 2-26 test state b-3 tlb lockdown 2-22 translation lookaside buffer 2-19 translation table base 2-14, 3-6 reset, test 9-13 s scan chain 9-11, 9-23 controlling external 9-30 external 9-21 multiplexor, external 9-22 number allocation 9-23 select register 9-20 scan chain 0 9-23 scan chain 1 9-28 scan chain 15 9-31, 9-32 scan chain 2 9-29 scan chain 3 9-30 scan chain 4 9-31, 9-39 scan chain 6 9-31 section descriptor 3-10 references, translating 3-13 serial test and debug 9-12 signals amba a-2 coprocessor interface a-5 debug a-10 handshake 7-7 jtag and tap controller a-7 miscellaneous a-12 trace interface port a-13 single stepping 9-63 slave transfers 6-20 small page references, translating 3-18 stc 7-5 strongarm b-30
index index-4 copyright ? 2000, 2001 arm limited. all rights reserved. arm ddi 0151c subpages 3-20 swap 6-18 swap instructions 4-14 synchronous mode 5-4 syspeed bit 9-47 system speed access 9-53 instructions 9-47 t tap controller 9-12 tap instruction register 9-20 test configuration register 2-26 data registers 9-19 interface, amba 11-2 registers b-2 reset 9-13 state register b-3 timing diagrams 13-2 parameters 13-16 tiny page references, translating 3-19 tlb lockdown register 2-22 tlb operations register 2-19 trace interface port signals a-13 trackingice 10-2 outputs 10-4 transfer types, asb 6-6 translating page tables 3-7 translation faults 3-21, 3-26 translation lookaside buffer lockdown register 2-22 translation lookaside buffer operations register 2-19 translation table base 3-6 register 2-14 ttb 3-6 register 2-14 u unidirectional signals 6-6 v va 2-6 vector catch register 9-61 vector catching 9-62 virtual address 2-6 w wait 7-7 watchpoint 9-9, 9-51 and breakpoint 9-52 and exception 9-52 control register 9-57, 9-59 timing 9-7 write buffer enabling and disabling 4-10 operation 4-10 write-back 6-17

▲Up To Search▲

Price & Availability of ARM920T-14

	To Download ARM920T-14 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .