View ARM9TDMI_6965286.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a ARM9TDMI ? (rev 3) technical reference manual
ii copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a ARM9TDMI technical reference manual copyright ? 2000 arm limited. all rights reserved. release information proprietary notice words and logos marked with ? or ? are registered trademarks or trad emarks owned by arm limited, except as otherwise stated below in this proprietary notice. other brands and names me ntioned herein may be the trademarks of their respective owners. neither the whole nor any part of the information cont ained in, or the product de scribed in, this document may be adapted or reproduced in any material form ex cept with the prior written permission of the copyright holder. the product described in this document is subject to continuous developmen ts 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 limit ed to implied warrantie s of merchantability, or fitness for purpose, are excluded. this document is intended only to a ssist the reader in the use of the pr oduct. 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 in correct use of the product. where the term arm is used it means ?arm or any of its subsidiaries as appropriate?. confidentiality status this document is non-confidential. the right to use, copy and disclose this document may be subject to license restrictions in acco rdance with the terms of th e agreement entered into by arm and the party that arm delivered this document to. product status the information in this do cument is final, that is for a developed product. web address http://www.arm.com change history date issue confidentiality change march 2000 a non-confidential first release
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. iii contents ARM9TDMI technical reference manual preface about this manual ............... .............. .............. .............. .............. .............. .... xii feedback ..................................................................................................... xvi chapter 1 introduction 1.1 about the ARM9TDMI ................................................................................. 1-2 1.2 processor block diagram ........................ ..................................................... 1-3 chapter 2 programmer?s model 2.1 about the programmer?s model ................................................................... 2-2 2.2 pipeline implementation and interlocks ........... .............. .............. .............. .. 2-4 chapter 3 ARM9TDMI processor core memory interface 3.1 about the memory interface ................... ..................................................... 3-2 3.2 instruction interface ..................................................................................... 3-5 3.3 endian effects for instruction fetches .......................................................... 3-7 3.4 data interface .............................................................................................. 3-8 3.5 unidirectional/bidirectional mode interfac e ............. .............. .............. ...... 3-11 3.6 endian effects for data transfers ......... ...................................................... 3-12 3.7 ARM9TDMI reset behavior ........................................................................ 3-13
contents iv copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a chapter 4 ARM9TDMI coprocessor interface 4.1 about the coprocessor interface ........... ...................................................... 4-2 4.2 ldc/stc .................................................................................................... 4-3 4.3 mcr/mrc .................................................................................................. 4-9 4.4 interlocked mcr ....................................................................................... 4-11 4.5 cdp .......................................................................................................... 4-13 4.6 privileged instructions ............................................................................... 4-15 4.7 busy-waiting and interrupts ...................................................................... 4-17 4.8 coprocessor 15 mcrs ............................................................................. 4-19 chapter 5 debug support 5.1 about debug .......... .............. .............. .............. .............. .............. ............ ... 5-2 5.2 debug systems ...... .............. .............. .............. .............. .............. ............ ... 5-3 5.3 debug interface signals .............................................................................. 5-5 5.4 scan chains and jtag interface .......... .................................................... 5-11 5.5 the jtag state machine .......................................................................... 5-12 5.6 test data registers .................................................................................... 5-18 5.7 ARM9TDMI core clocks ............................................................................ 5-24 5.8 clock switching during debug ............ .............. .............. ............ ............... 5-25 5.9 clock switching during test ....................................................................... 5-26 5.10 determining the core state and system st ate .............. .............. ............... 5-27 5.11 exit from debug state ................................................................................ 5-30 5.12 the behavior of the progr am counter during debug .... .............. ............... 5-33 5.13 embeddedice macrocell ..... .............. .............. .............. ............ ............... 5-36 5.14 vector catching ......................................................................................... 5-45 5.15 single stepping ......................................................................................... 5-46 5.16 debug communications channel .............................................................. 5-47 chapter 6 test issues 6.1 about testing ............................................................................................... 6-2 6.2 scan chain 0 bit order ................................................................................. 6-3 chapter 7 instruction cycle summary and interlocks 7.1 instruction cycle times ....... .............. .............. .............. .............. .............. ... 7-2 7.2 interlocks .................................................................................................... 7-5 chapter 8 ARM9TDMI ac characteristics 8.1 ARM9TDMI timing diagrams ...................................................................... 8-2 8.2 ARM9TDMI timing parameters ............. .................................................... 8-14 appendix a ARM9TDMI signal descriptions a.1 instruction memory interface signals .... ...................................................... a-2 a.2 data memory interface signals ............. ...................................................... a-3 a.3 coprocessor interface signal s .................................................................... a-5 a.4 jtag and tap controller signals ............................................................... a-6 a.5 debug signals ............................................................................................. a-8
contents arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. v a.6 miscellaneous signals ......... .............. .............. .............. .............. .............. a-10
contents vi copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. vii list of tables ARM9TDMI technical reference manual change history ............. .............. .............. .............. .............. ........... ........... ............ ...... ii table 2-1 ARM9TDMI implementation option ........................................................................... 2-2 table 3-1 inmreq and iseq encoding .................................................................................... 3-5 table 3-2 endian effect on instruction position ...... ................................................................... 3-7 table 3-3 dnmreq and dseq encoding ................................................................................. 3-8 table 3-4 dmas[1:0] encoding ................................................................................................. 3- 9 table 3-5 endian effects for 16-bit data fetches ..... ................................................................. 3-12 table 3-6 endian effects for 8-bit data fetches ....... ................................................................. 3-12 table 4-1 handshake signals ........... .............. .............. .............. .............. .............. ........... ........ 4-7 table 5-1 public instructions ............................. ...................................................................... 5-13 table 5-2 id code register ...................................................................................................... . 5-19 table 5-3 scan chain number allocation ................................................................................. 5-20 table 5-4 ARM9TDMI embeddedice macrocell register map .............. .............. .............. ...... 5-36 table 5-5 watchpoint control register for data comp arison bit functions ....... ............ .............. 5-39 table 5-6 watchpoint control register for instructio n comparison bit functions .............. ......... 5-41 table 6-1 scan chain 0 bit order ............................................................................................... 6-3 table 7-1 symbols used in tables .......................... ................................................................... 7- 2 table 7-2 instruction cycle bus times ............. .............. .............. .............. .............. .............. ..... 7- 2 table 7-3 data bus instruction times ......................................................................................... 7- 4 table 8-1 ARM9TDMI timing paramete rs ................................................................................ 8-14 table a-1 instruction memory interfac e signals ......................................................................... a-2 table a-2 data memory interface signals .................. ................................................................ a-3 table a-3 coprocessor interface signals ................... ................................................................ a-5
list of tables viii copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a table a-4 jtag and tap controller signals .............................................................................. a-6 table a-5 debug signals ......................................................................................................... .. a-8 table a-6 miscellaneous signals .......... .............. .............. .............. .............. ............ ........... .... a-1 0
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. ix list of figures ARM9TDMI technical reference manual key to timing diagram conventions ................... ......................................................... xiii figure 1-1 ARM9TDMI processor block diagram ....................................................................... 1-3 figure 2-1 ARM9TDMI processor core instruction pipe line ........................................................ 2-4 figure 3-1 ARM9TDMI clock stalling using nwait ..................................................................... 3-4 figure 3-2 instruction fetch timing ............................................................................................. . 3-6 figure 3-3 data access timings ................................................................................................ 3 -10 figure 3-4 ARM9TDMI reset behavior ...................................................................................... 3-14 figure 4-1 ARM9TDMI ldc / stc cycle ti ming ............... .............. .............. .............. .............. .. 4-4 figure 4-2 ARM9TDMI coprocessor clo cking ............................................................................. 4-5 figure 4-3 ARM9TDMI mcr / mrc transfer timing ......... .......................................................... 4-9 figure 4-4 ARM9TDMI interlocked mcr .................................................................................. 4-12 figure 4-5 ARM9TDMI late cancelled cdp .............................................................................. 4-14 figure 4-6 ARM9TDMI privileged instructions ............ .............................................................. 4-15 figure 4-7 ARM9TDMI busy waiting and interrupts ....... ........................................................... 4-18 figure 4-8 ARM9TDMI coprocessor 15 mcrs .............. ........................................................... 4-19 figure 5-1 typical debug system ............................................................................................... 5 -3 figure 5-2 breakpoint timing .............................. ...................................................................... .. 5-6 figure 5-3 watchpoint entry with data processing instru ction .......... .............. .............. .............. 5-8 figure 5-4 watchpoint entry with branch .............. .............. .............. .............. .............. .............. 5-9 figure 5-5 test access port (tap) controller state tr ansitions .................................................. 5-12 figure 5-6 clock switching on entry to debug state .... .............. .............. .............. .............. ...... 5-25 figure 5-7 debug exit sequence ....... .............. .............. .............. .............. .............. .............. ... 5-3 1 figure 5-8 debug state entry .......... .............. .............. .............. .............. ........... ........... ............ 5-32
list of figures x copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 5-9 ARM9TDMI embeddedice ma crocell overview .... .............. .............. .............. ....... 5-38 figure 5-10 watchpoint control register for data comp arison .................................................... 5-39 figure 5-11 watchpoint control regist er for instruction comparison ........................................... 5-41 figure 5-12 debug control register ............................................................................................ 5 -42 figure 5-13 debug status register .............................................................................................. 5-43 figure 5-14 vector catch register ............................................................................................... 5-44 figure 5-15 debug comms control register ................................................................................ 5-47 figure 7-1 single load interlock timing ...................... ................................................................. 7 -5 figure 7-2 two cycle load interlock ..... .............. .............. .............. .............. ........... ........... ......... 7-6 figure 7-3 ldm interlock ..................................... ................................................................... .... 7-7 figure 7-4 ldm dependent interlock ..... .............. .............. .............. .............. .............. ............ ... 7-8 figure 8-1 ARM9TDMI instruction me mory interface output timing ........................................... 8-2 figure 8-2 ARM9TDMI instruction address bus enable .. ........................................................... 8-2 figure 8-3 ARM9TDMI instruction memo ry interface input timing ............................................. 8-3 figure 8-4 ARM9TDMI data memory interface output ti ming ..................................................... 8-4 figure 8-5 ARM9TDMI data address bus timing ........................................................................ 8-5 figure 8-6 ARM9TDMI data abort and dnmreq timing ........................................................ 8-5 figure 8-7 ARM9TDMI data data bus timing .............................................................................. 8-5 figure 8-8 ARM9TDMI data bus enable .................................................................................... 8-6 figure 8-9 ARM9TDMI miscellaneous signal timing .... .............................................................. 8-6 figure 8-10 ARM9TDMI coprocessor interface signal timi ng ....................................................... 8-7 figure 8-11 ARM9TDMI jtag output signals .............................................................................. 8-8 figure 8-12 ARM9TDMI external boundary scan chain out put signals ...... .............. .............. ...... 8-9 figure 8-13 ARM9TDMI sdoutbs to tdo relationship .. ........................................................... 8-9 figure 8-14 ARM9TDMI ntrst to rstc lkbs relationship .... .............. .............. .............. ....... 8-10 figure 8-15 ARM9TDMI jtag input signal timing ..................................................................... 8-10 figure 8-16 ARM9TDMI gclk related debug output timings .................................................... 8-11 figure 8-17 ARM9TDMI tck related debug output timings ...................................................... 8-12 figure 8-18 ARM9TDMI ntrst to dbgrqi relationship .......................................................... 8-12 figure 8-19 ARM9TDMI edbgrq to dbgrqi relationsh ip ...................................................... 8-12 figure 8-20 ARM9TDMI dbgen to output effects ..................................................................... 8-13
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. xi preface this preface introduces the ARM9TDMI (revision 3) technical reference manual . it contains the following sections: ? about this manual on page xii ? feedback on page xvi.
preface xii copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a about this manual this is the technical reference manual (trm) for the ARM9TDMI microprocessor. the ARM9TDMI includes the following features: ? the option, selectable using the unien signal, of using two unidirectional buses dd[31:0] and ddin[31:0] , instead of a single bidirectional data bus. this is described in unidirectional/bidirectional mode interface on page 3-11. ? the value returned by the jtag tap controller idcode instruction is the value present on the new tapid[31:0] input bus. this allows the id code to be easily changed for each chip design. intended audience this manual is written for experienced hardware and software engineers who might or might not have experience of arm products. conventions conventions that this manual can use are described in: ? typographical ? timing diagrams on page xiii ? signals on page xiii ? numbering on page xiv. typographical the typographical conventions are: italic highlights important notes, introduces special terminology, denotes internal cross-references, and citations. bold highlights interface elements, su ch as menu names. denotes signal names. also used for te rms in descriptive lists, where appropriate. monospace denotes text that you can enter at the keyboard, such as commands, file and program names, and source code. mono space denotes a permitted abbreviation for a command or option. you can enter the underlined text instead of the full command or option name.
preface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. xiii monospace italic denotes arguments to monospace text where the argument is to be replaced by a specific value. monospace bold denotes language keywords when used outside example code. < and > angle brackets enclose replaceable terms for assembler syntax where they appear in code or c ode fragments. they appear in normal font in running text. for example: ? mrc p15, 0 , , , ? the opcode_2 value selects which register is accessed. timing diagrams the figure named key to timing diagram conventions explains the components used in timing diagrams. variations, when they occu r, have clear labels. you must not assume any timing information that is not explicit in the diagrams. shaded bus and signal areas are undefined, so the bus or signal can assume any value within the shaded area at that time. the actual level is unimportant and does not affect normal operation. key to timing di agram conventions signals the signal conventions are: signal level the level of an asserted signal depends on whether the signal is active-high or active-low. asserted means high for active-high signals and low for active-low signals. lower-case n denotes an active-low signal. &orfn +,*+wr/2: 7udqvlhqw +,*+/2:wr+,*+ %xvvwdeoh %xvwrkljklpshgdqfh %xvfkdqjh +ljklpshgdqfhwrvwdeohexv
preface xiv copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a prefix a denotes global advanced extensible interface (axi) signals. prefix ar denotes axi read address channel signals. prefix aw denotes axi write address channel signals. prefix b denotes axi write response channel signals. prefix c denotes axi low-power interface signals. prefix h denotes advanced high-performance bus (ahb) signals. prefix p denotes advanced peripheral bus (apb) signals. prefix r denotes axi read data channel signals. prefix w denotes axi write data channel signals. numbering the numbering convention is: ' this is a verilog method of abbreviating constant numbers. for example: ? 'h7b4 is an unsized hexadecimal value. ? 'o7654 is an unsized octal value. ? 8'd9 is an eight-bit wide decimal value of 9. ? 8'h3f is an eight-bit wide hexadecimal value of 0x3f . this is equivalent to b00111111. ? 8'b1111 is an eight-bit wide binary value of b00001111. further reading this section lists publications by arm limited, and by third parties. arm limited periodically provides updates and corrections to its documentation. see http://www.arm.com for current errata sheets, ad denda, and the frequently asked questions list. arm publications this manual contains information that is specific to the ARM9TDMI microprocessor. see the following documents for other relevant information: ? arm architecture reference manual (arm ddi 0100) ? arm7tdmi data sheet (arm ddi 0029).
preface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. xv 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 xvi copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a feedback arm limited welcomes feedback on th e ARM9TDMI microprocessor and its documentation. feedback on this product if you have any comments or suggestions about this product, contact your supplier giving: ? the product name ? a concise explanati on of your comments. feedback on this manual if you have any comments on this manual, send email to errata@arm.com giving: ? the title ? the number ? the relevant page number(s) to which your comments apply ? a concise explanati on of your comments. arm limited also welcomes general suggestions for additions and improvements.
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 1-1 chapter 1 introduction this chapter introduces the ARM9TDMI (revision 3) and shows its processor block diagram under the headings: ? about the ARM9TDMI on page 1-2 ? processor block diagram on page 1-3.
introduction 1-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 1.1 about the ARM9TDMI the ARM9TDMI is a member of the arm fa mily of general-pur pose microprocessors. the ARM9TDMI is targeted at embedded control ap plications where high performance, low die size and low power are all important. the ARM9TDMI supports both the 32-bit arm and 16-bit thumb instruction sets, allowing the user to trade off between high performance and high code density. the ARM9TDMI supports the arm debug architecture and includes logic to assist in both hardware and software debug. the ARM9TDMI supports both bidirectional and unidirectional connection to external memory systems. the ARM9TDMI also includes support for coprocessors. the ARM9TDMI processor core is implemented using a five-stage pipeline consisting of fetch, decode, execute, memory and write stages. the device has a harvard architecture, and the simple bus interface eases connection to either a cached or sram-based memory system. a simple handshake protocol is provided for coprocessor support.
introduction arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 1-3 1.2 processor block diagram figure 1-1 shows the ARM9TDMI processor block diagram. figure 1-1 ARM9TDMI processor block diagram
introduction 1-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 2-1 chapter 2 programmer?s model this chapter describes the programmer?s model for the ARM9TDMI under the headings: ? about the programmer?s model on page 2-2 ? pipeline implementation and interlocks on page 2-4.
programmer?s model 2-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 2.1 about the programmer?s model the ARM9TDMI processor core implements arm architecture v4t, and so 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 arm v4t architecture specifies a sma ll number of implementation options. the options selected in the ARM9TDMI implemen tation are listed in the table below. for comparison, the options selected for the arm7tdmi implementa tion are also shown: the ARM9TDMI is code compatible with the arm7tdmi, with two exceptions: ? the ARM9TDMI implements the base restored data abort model, which significantly simplifies the software data abort handler. ? the ARM9TDMI fully implements the in struction set extension spaces added to the arm (32-bit) instruction set in architecture v4 and v4t. these differences are explained in more detail below. 2.1.1 data abort model the ARM9TDMI implements the base restored data abort model, which differs from the base updated data abort model implemented by arm7tdmi. the difference in the data abort model aff ects 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 regist er is always restored by the processor hardware to the value the register contained before the instruction was executed. this removes the need for the data abort handler to ?unwind? any base register update which may have been specified by the aborted instruction. the base restored data abort model signifi cantly simplifies the software data abort handler. table 2-1 ARM9TDMI im plementation option processor core arm architecture data abort model value stored by direct str, strt, stm of pc arm7tdmi v4t base updated address of inst + 12 ARM9TDMI v4t base restored address of inst + 12
programmer?s model arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 2-3 2.1.2 instruction set extension spaces all arm processors implemen t the undefined instruction space as one of the entry mechanisms for the undefined instruction ex ception. that is, arm instructions with opcode[27:25] = 0b011 and opcode[4] = 1 are undefined on all arm processors including the ARM9TDMI and arm7tdmi. arm architecture v4 and v4t also introduced 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 undefine d (they cause an undefined instruction exception). the ARM9TDMI fully implements all the instruction set extension spaces defined in arm architecture v4t as undefi ned instructions, allowing emulation of future instruction set additions.
programmer?s model 2-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 2.2 pipeline implementation and interlocks the ARM9TDMI implementation uses a five-sta ge pipeline design. these five stages are: ? instruction fetch (f) ? instruction decode (d) ? execute (e) ? data memory access (m) ? register write (w). arm implementations are fully interlocked, so that software will function identically across different implementations without concern for pipeline effects. interlocks do affect instruction execution times. for example, the foll owing sequence suffers a single cycle penalty due to a load-use interlock on register r0: ldr r0, [r7] add r5, r0, r1 for more details, see chapter 7 instruction cycle summary and interlocks . figure 2-1 shows the timing of the pipeline, and the principal activity in each stage. figure 2-1 ARM9TDMI processor core instruction pipeline
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-1 chapter 3 ARM9TDMI processor core memory interface this chapter describes the memory interf ace of the ARM9TDMI processor core. the processor core has a harvard memory arch itecture, and so the memory interface is separated into the instruction interface and the data interface. the information in this chapter is broken down as follows: ? about the memory interface on page 3-2 ? instruction interface on page 3-5 ? endian effects for instruction fetches on page 3-7 ? data interface on page 3-8 ? unidirectional/bidirectional mode interface on page 3-11 ? endian effects for data transfers on page 3-12 ? ARM9TDMI reset behavior on page 3-13.
ARM9TDMI processor core memory interface 3-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 3.1 about the memory interface the ARM9TDMI has a harvard bus architectur e with separate instruction and data interfaces. this allows concur rent instruction and data accesses, and greatly reduces the cpi of the processor. for optimal performan ce, single cycle memory accesses for both interfaces are required, althou gh the core can be wait-stated for non-sequential accesses, or slower memory systems. for each interface there are different types of memory access: for both instruction and data interfaces, th e ARM9TDMI process core uses pipelined addressing. the address and control signals are generated the cycle before the data transfer takes place, giving any decode logi c as much advance notice as possible. all memory accesses are generated from gclk . ? non-sequential ? sequential ? internal ? coprocessor transfer (f or the data interface). these accesses are determined by inmreq and iseq for the instruction interface, and by dnmreq and dseq for the data interface. the ARM9TDMI can operate in both big-endian and little-endian memory configurations, and this is selected by the bigend input. the endian configuration affects both interfaces, so car e must be taken in designi ng the memory interface logic to allow correct operation of the processor core. for system purposes, it is normally necessary to provide some mechanism whereby the data interface can access instruction memory . there are two main reasons for this: ? the use of in-line data for literal pools is very common. this data will be fetched via the data interface but wi ll normally be contained in the instruction memory space. ? to enable debug via the jtag interface it must be possible to download code into the instruction memory. this code has to be written to memory via the data data bus as the instruction data bus is unidirectional. this means in this instance it is essential for the data interface to ha ve access to the instruction memory. a typical implementation of an arm9td mi-based cached processor has harvard caches and a unified memory structure bey ond the caches, thereby giving the data interface access to the instruction memory sp ace. the arm940t is an example of such a system. however, for an sram-based syst em this technique cannot be used, and an alternative method must be employed.
ARM9TDMI processor core memory interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-3 it is not as critical for th e instruction interface to have access to the data memory area unless the processor needs to execute code from data memory. 3.1.1 actions of the ARM9TDMI in debug state once the ARM9TDMI is in debu g state, both memory inte rfaces will indicate internal cycles. this allows the rest of the memory system to ignore the ARM9TDMI and function as normal. since the rest of the system continues operation, the ARM9TDMI will ignore aborts and interrupts. the bigend signal should not be changed by the system while in debug state. if it changes, not only will there be a synchroni zation problem, but the programmer?s view of the ARM9TDMI will change without the knowledge of the debugger. the nreset signal must also be held stable during de bug. if the system applies reset to the ARM9TDMI ( nreset is driven low), the state of the ARM9TDMI will change without the knowledge of the debugger. when instructions are executed in de bug state, the ARM9TDMI will change asynchronously to the memory system outputs (except for inmreq , iseq , dnmreq , and dseq which change synchronously from gclk ). for example, every time a new instruction is scanned into the pipeline, the instruction address bus will change. if the instruction is a load or store operation, th e data address bus will change as the instruction executes. although this is asynchronous, it should not affect the system, because both interfaces will be indicating internal cycles. care must be taken with the design of the memory controller to ensure that this does not become a problem. 3.1.2 wait states for memory accesses which require more than one cycle, the processor can be halted by using nwait . this signal halts the processor, including both the instruction and data interfaces. the nwait signal should be driven low by the end of phase 2 to stall the processor (it is inverted and ored with gclk to stretch the internal processor clock). the nwait signal must only change during phase 2 of gclk . for debug purposes the internal core clock is exported on the eclk signal. this timing is shown below in figure 3-1 on page 3-4. alternatively, wait states may be inse rted by stretching either phase of gclk before it is applied to the processor. ARM9TDMI does not contain any dynamic logic which relies on regular clocking to maintain its state. therefore there is no limit on the maximum period for which gclk may be stretched, in eith er phase, or the time for which nwait may be held low.
ARM9TDMI processor core memory interface 3-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a the system designer must ta ke care when adding wait st ates because the interface is pipelined. when a wait state is asserted, the current data and instruction transfers are suspended. however, the address buses and control signals will have already changed to indicate the next transfer. it is therefore necessary to latch the address and control signals of each interface when using wait states. figure 3-1 ARM9TDMI clock stalling using nwait
ARM9TDMI processor core memory interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-5 3.2 instruction interface whenever an instruction enters the execute stage of the pipeline, a new opcode is fetched from the instruction bus. the arm9 tdmi processor core may be connected to a variety of cache/sram systems, and it is optimized for single cycle access systems. however, in order to ease the system design , it is possible to connect the ARM9TDMI to memory which takes two (or more) cycles for a non-sequential (n) access, and one cycle for a sequential (s) access. although this increases the effective cpi, it considerably eases the memory design. the ARM9TDMI indicates that an instruction fetch will take place by driving inmreq low. the instruction address bus, ia[31:1] will contain the address for the fetch, and the iseq signal will indicate whether the fetch is sequential or non-sequential to the previous access. all these signals become valid towards the end of phase 2 of the cycle that precedes the instruction fetch. if itbit is low, and thus ARM9TDMI is performing word reads, then ia[1] should be ignored. the timing is shown in figure 3-2 on page 3-6. the full encoding of inmreq and iseq is as follows: note the 1,1 case does not occur in this impl ementation but may be used in the future. instruction fetches may be marked as aborted. the iabort signal is an input to the processor with the same timing as the inst ruction data. if, and when, the instruction reaches the execute stage of the pipeline, the prefetch abort vector is taken. the timing for this is shown in figure 3-2 on page 3-6. if the memory control logic does not make use of the iabort signal, it must be tied low. internal cycles occur when the processor is stalled, either waiting for an interlock to resolve, or completing a multi-cycle instruction. table 3-1 inmreq and iseq encoding inmreq iseq cycle type 0 0 non-sequential 0 1 sequential 1 0 internal 1 1 reserved for future use
ARM9TDMI processor core memory interface 3-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a note a sequential cycle can occur imme diately after an internal cycle. figure 3-2 shows the cycle timing for an n fo llowed by an s cycle, where there is a prefetch abort on the s cycle: figure 3-2 instruction fetch timing
ARM9TDMI processor core memory interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-7 3.3 endian effects for instruction fetches the ARM9TDMI will perform 32-bit or 16-bit instruction fetches depending on whether the processor is in arm or th umb state. the processor state may be determined externally by the value of the itbit signal. when this signal is low, the processor is in arm state, and 32-bit instru ctions are fetched. when it is high, the processor is in thumb state and 16-bit instructions are fetched. when the processor is in arm state, its endian configuration does not affect the instruction fetches, as all 32 bits of id[31:0] are read. however, in thumb state the processor will read either from the upper half of the instruction data bus, id[31:16] , or from the lower half, id[15:0] . this is determined by the endian configuration of the memory system, which is indicated by the bigend signal, and the state of ia[1] . table 3-2 shows which half of the data bus is sampled in the different configurations: when a 16-bit instruction is fetched, the ARM9TDMI ignores the unused half of the data bus. table 3-2 endian effect on instruction position little bigend = 0 big bigend = 1 ia[1] = 0 id[15:0] id[31:16] ia[1] = 1 id[31:16] id[15:0]
ARM9TDMI processor core memory interface 3-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 3.4 data interface data transfers take place in the memory stage of the pipeline. the operation of the data interface is very similar to the instruction interface. the interface is pipelined with the address and control signals, becoming valid in phase 2 of the cycle before the transfer. there are four types of data cycle, and these are indicated by dnmreq and dseq . the timing for these signals is shown in figure 3-3 on page 3-10. the full encoding for these signals is given in table 3-3: for internal cycles, data memory accesses ar e not required in this instance, the data interface outputs will retain the state of the previous transfer. dnrw indicates the direction of the transfer, low for reads and high for writes. the signal becomes valid at approximately th e same time as the data address bus. ? for reads, ddin[31:0] must be driven with valid data for the falling edge of gclk at the end of phase 2. ? for writes by the processor, data will become valid in phase 1, and remain valid throughout phase 2. both reads and writes are illustrated in figure 3-3 on page 3-10. see about the coprocessor interface on page 4-2 for further information on using ddin[31:0] and dd[31:0] in unidirectional mode or connecting together to form a bidirectional bus. data transfers may be marked as aborted. the dabort signal is an input to the processor with the same timing as the data. upon completion of the current instruction in the memory stage of the pipeline, the data abort vector is taken. if the memory control logic does not make use of the dabort signal, it must be tied low, but with the exception that data can be transfer red to and from the ARM9TDMI core. table 3-3 dnmreq and dseq encoding dnmreq dseq cycle type 0 0 non-sequential 0 1 sequential 10internal 1 1 coprocessor transfer
ARM9TDMI processor core memory interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-9 the size of the transfer is indicated by dmas[1:0] . these signals become valid at approximately the same time as the data ad dress bus. the encoding is given below in table 3-4: for coprocessor transfers, access to memory is not required, but there will be a transfer of data between the ARM9TDMI and coprocessor using the data buses, dd[31:0] and ddin[31:0] . dnrw indicates the directi on of the transfer and dmas[1:0] indicates word transfers, as all coprocessor transf ers are word sized. the dmore signal is active during load and store multiple instructions and only ever goes high when dnmreq is low. this signal effectively gives the same information as dseq , but a cycle ahead. this informatio n is provided to allow external logic more time to decode sequential cycles. figure 3-3 on page 3-10 shows a load multiple of four words followed by an mcr, followed by an aborted store. note the following: ? the dmore signal is active in the first thr ee cycles of the load multiple to indicate that a sequential word will be loaded in the following cycle. ? from the behavior of inmreq during the ldm, it can be seen that an instruction fetch takes place when the instruction enters the execute stage of the pipeline, but that thereafter the instruction pipeline is stalled until the ldm completes. table 3-4 dmas[1:0] encoding dmas[1:0] transfer size 00 byte 01 half word 10 word 11 reserved
ARM9TDMI processor core memory interface 3-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 3-3 data access timings
ARM9TDMI processor core memory interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-11 3.5 unidirectional/bidir ectional mode interface the ARM9TDMI supports connection to external memory systems using either a bidirectional data data bus or two unidirectional buses. this is controlled by the unien input. if unien is low, dd[31:0] is a tristate output bus used to transfer write data. it is only driven when the ARM9TDMI is perfor ming a write to memory. by wiring dd[31:0] to the input ddin[31:0] bus (externally to the ARM9TDMI), a bidirectional data data bus can be formed. if unien is high, then dd[31:0] , and all other ARM9TDMI outputs, are permanently driven. dd[31:0] then forms a unidirectional write data data bus. in this mode, the tristate enable pins iabe , dabe , ddbe , tbe , and the tap instruction nhighz , have no effect. therefore al l outputs are always driven. all timing diagrams in this manual, except where tristate timing is shown explicitly, assume unien is high.
ARM9TDMI processor core memory interface 3-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 3.6 endian effects for data transfers the ARM9TDMI supports 32- bit, 16-bit and 8-bit data memory access sizes. the endian configuration of the processor, set by bigend , affects only non-word transfers (16-bit and 8-bit transfers). for data writes by the processor, the write da ta is duplicated on the data bus. so for a 16-bit data store, one copy of the data appears on the upper half of the data bus, dd[31:16] , and the same data appears on the lower half, dd[15:0] . for 8-bit writes four copies are output, one on each byte lane, dd[31:24] , dd[23:16] , dd[15:8] and dd[7:0] . this considerably eases the memory co ntrol logic design and helps overcome any endian effects. for data reads, the processor w ill read a specific part of the data bus. this is determined by the endian configuration, th e size of the transfer, and bits 1 and 0 of the data address bus. table 3-5 shows which bits of the data bus are read for 16-bit reads, and table 3-6 shows which bits are r ead for 8-bit reads. for simplicity of design, 32 bits of data can be read from memory and the processor will ignore any unwanted bits. table 3-5 endian effects for 16-bit data fetches da[1:0] little (bigend = 0) big (bigend = 1) 00 ddin[15:0] ddin[31:16] 10 ddin[31:16] ddin[15:0] table 3-6 endian effects for 8-bit data fetches da[1:0] little (bigend = 0) big (bigend = 1) 00 ddin[7:0] ddin[31:24] 01 ddin[15:8] ddin[23:16] 10 ddin[23:16] ddin[15:8] 11 ddin[31:24] ddin[7:0]
ARM9TDMI processor core memory interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 3-13 3.7 ARM9TDMI reset behavior when nreset is driven low, the currently executing instruction terminates abnormally. if gclk is high, inmreq , iseq , dnmreq , dseq and dmore will asynchronously change to indicate an internal cycle. if gclk is low, they will not change until after the gclk goes high. when nreset is driven high, the ARM9TDMI st arts requesting memory again once the signal has been synchronized, and the firs t memory access will start two cycles later. the nreset signal is sampled on the falling edge of gclk . the behavior of the memory interfaces coming out of reset is shown in figure 3-4 on page 3-14.
ARM9TDMI processor core memory interface 3-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 3-4 ARM9TDMI reset behavior
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-1 chapter 4 ARM9TDMI coprocessor interface this chapter describes the ARM9TDMI coproc essor interface, and details the following operations: ? about the coprocessor interface on page 4-2 ? ldc/stc on page 4-3 ? mcr/mrc on page 4-9 ? interlocked mcr on page 4-11 ? cdp on page 4-13 ? privileged instructions on page 4-15 ? busy-waiting and interrupts on page 4-17 ? coprocessor 15 mcrs on page 4-19.
ARM9TDMI coprocessor interface 4-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 4.1 about the coprocessor interface the ARM9TDMI supports the connection of coprocessors. all types of arm coprocessor instructions are supported. copr ocessors determine the instructions they need to execute using a pipeline follower in the coprocessor. as each instruction arrives from memory, it enters both the arm pipeline and the coprocessor pipeline. typically, a coprocessor operates one clock phase behind the ARM9TDMI pipeline. the coprocessor determines when an instruction is being fetched by the ARM9TDMI, so that the instruction can be loaded into the coprocessor, and the pipeline follower advanced. note a cached ARM9TDMI core typically has an external coprocessor interface block, the main purpose of which is to latch the instruction data bus, id , one of the data buses, dd[31:0] or ddin[31:0] , and relevant ARM9TDMI control signals before exporting them to the copro cessors. for a description of all the interface signal s referred to in this chapter, refer to coprocessor interface signals on page a-5. there are three classes of coprocessor instructions: ?ldc/stc ? mcr/mrc ?cdp. the following sections give examples of how a coprocessor should execute these instruction classes.
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-3 4.2 ldc/stc the number of words transferred is determ ined by how the coprocessor drives the chsd[1:0] and chse[1:0] buses. in the example, four words of data are transferred. figure 4-1 on page 4-4 shows the ARM9TDMI ldc/stc cycle timing.
ARM9TDMI coprocessor interface 4-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 4-1 ARM9TDMI ldc / stc cycle timing
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-5 as with all other instructions, the arm9 tdmi processor core performs the main decode off the rising edge of the clock during the decode stage. from this, the core commits to executing the instruction, and so performs an instruction fetch. the coprocessor instruction pipe line keeps in step with the ARM9TDMI by monitoring inmreq . at the falling edge of gclk , if nwait is high, and inmreq is low, an instruction fetch is taking place, and id[31:0] will contain the fetched instruction on the next falling edge of the clock, when nwait is high. this means that: ? the last instruction fetched should enter the decode stage of the coprocessor pipeline ? the instruction in the decode stage of the coprocessor pipeline should enter its execute stage ? the fetched instruction should be latched. in all other cases, the ARM9TDMI pipeline is stalled, and the coprocessor pipeline should not advance. figure 4-2 shows the timing for these signa ls, and indicates when the coprocessor pipeline should advance its state. in this timing diagram, coproc clock shows a processed version of gclk with inmreq and nwait . this is one method of generating a clock to reflect the advance of the ARM9TDMI pipeline. figure 4-2 ARM9TDMI coprocessor clocking during the execute stage, the condition codes are combined w ith the flags to determine whether the instruction really executes or not . the output pass is asserted (high) if the instruction in the execute st age of the coprocessor pipeline: ? is a coprocessor instruction
ARM9TDMI coprocessor interface 4-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a ? has passed its condition codes. if a coprocessor instruction busy-waits, pass is asserted on every cycle until the coprocessor instruction is executed. if an interrupt occurs during busy-waiting, pass is driven low, and the coprocessor will stop execution of the copr ocessor instruction. a further output, latecancel , is used to cancel a copro cessor instruction when the instruction preceding it caused a data abort. this is valid on the rising edge of gclk on the cycle that follows the first execute cycl e of the coprocessor instructions. this is the only cycle in which latecancel can be asserted. on the falling edge of the clock, the ARM9TDMI processor core examines the coprocessor handshake signals chsd[1:0] or chse[1:0] : ? if a new instruction is entering the execu te stage in the next cycle, it examines chsd[1:0] . ? if the currently executing coprocessor inst ruction requires anot her execute cycle, it examines chse[1:0] . the handshake signals encode one of four states: absent if there is no coprocessor attached that can execute the coprocessor instruction, the handshake signals i ndicate the absent state. in this case, the ARM9TDMI processor core takes the undefined instruction trap. wa i t if there is a coprocessor attached that can handle the instruction, but not immediately, the coprocessor handsha ke signals are driven to indicate that the ARM9TDMI processor core should 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 chse[1:0] to be driven to another state, or for an interrupt to occur. if chse[1:0] changes to absent , the undefined instruction trap will be taken. if chse[1:0] changes to go or last, the instruction will proceed as described below. if an interrupt o ccurs, the ARM9TDMI processor core is forced out of the busy-wait state. this is indicated to the coprocessor by the pass signal going low. the instruction will be restarted at a later date and so the coprocessor must not commit to the instruction (it must not change any of the coprocessor?s state) until it has seen pass high, when the handshake signals indicate the go or last condition. go the go state indicates that the copr ocessor can execute the instruction immediately, and that it requires an other cycle of execution. both the ARM9TDMI processor core and the co processor must also consider the state of the pass signal before actually committing to the instruction.
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-7 for an ldc or stc instruction, the coprocessor instruction drives the handshake signals with go when two or more words still need to be transferred. when only one further word is to be transferred, the coprocessor drives the handshake sign als with last. in phase 2 of the execute stage, the ARM9TDMI processo r core outputs the address for the ldc/stc. also in this phase, dnmreq is driven low, indicating to the memory system that a memory acces s is required at the data end of the device. the timing for the data on dd[31:0] for an ldc and dd[31:0] for an stc is shown in figure 4-1 on page 4-4. last an ldc or stc can be used for more th an one item of data. if this is the case, possibly after busy waiting, th e coprocessor drives the coprocessor handshake signals with a number of go states, and in the penultimate cycle last (last indicatin g that the next transfer is the final one). if there was only one transfer, the sequence would be [wait,[wait,...]],last. for both mrc and stc instructions, the ddin[31:0] bus is owned by the coprocessor, and can hence be driven by the coprocessor fr om the cycle after the relevant instruction enters the execute stage of the coprocessor pi peline, until the next instruction enters the execute stage of the coprocessor pipeline. th is is the case even if the instruction is subject to a latecancel or the pass signal is not asserted. for efficient coprocessor design, an unmodified version of gclk should be applied to the execution stage of the coprocessor. this will allow the coprocessor to continue executing an instruction even when th e ARM9TDMI pipeline is stalled. 4.2.1 coprocessor handshake encoding table 4-1 shows how the handshake signals chsd[1:0] and chse[1:0] are encoded. if a coprocessor is not attached to the ARM9TDMI, the handshake signals must be driven with ?10? absent, otherwise th e ARM9TDMI processor will hang if a coprocessor enters the pipeline. table 4-1 handshake signals chsd/e[1:0] absent 10 wa i t 0 0 go 01 last 11
ARM9TDMI coprocessor interface 4-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a if multiple coprocessors are to be attached to the interface, the handshaking signals can be combined by anding bit 1, and oring b it 0. in the case of two coprocessors which have handshaking signals chsd1 , chse1 and chsd2 , chse2 respectively: chsd[1] <= chsd1[1] and chsd2[1] chsd[0] <= chsd1[0] or chsd2[0] chse[1] <= chse1[1] and chse2[1] chse[0] <= chse1[0] or chse2[0]
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-9 4.3 mcr/mrc these cycles look very similar to stc/ldc. an example, with a busy-wait state, is shown in figure 4-3: figure 4-3 ARM9TDMI mcr / mrc transfer timing first inmreq is driven low to denote that the instruction on id is entering the decode stage of the pi peline. this causes the coprocesso r to decode the new instruction and drive chsd[1:0] as required. in the next cycle inmreq is driven low to denote that the instruction has now been issued to the execute stage. if the condition codes pass,
ARM9TDMI coprocessor interface 4-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a and hence the instruction is to be executed, the pass signal is driven high and the chsd[1:0] handshake bus is examined (it is ignored in all other cases). for any successive execute cycles the chse[1:0] handshake bus is examined. when the last condition is observed, the instruction is committed. in the case of an mcr , the dd[31:0] bus is driven with the regi ster data. in the case of an mrc , ddin[31:0] is sampled at the end of the ARM9TDMI memo ry stage and written to the destination register during the next cycle.
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-11 4.4 interlocked mcr if the data for an mcr operation is not available inside the ARM9TDMI pipeline during its first decode cycle, the ARM9TDMI pipeline will interlock for one or more cycles until the data is available. an example of th is is where the register being transferred is the destination from a preceding ldr instructio n. in this situation the mcr instruction will enter the decode stage of the coproce ssor pipeline, and remain there for a number of cycles before entering the execute stag e. figure 4-4 on page 4-12 gives an example of an interlocked mcr.
ARM9TDMI coprocessor interface 4-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 4-4 ARM9TDMI interlocked mcr
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-13 4.5 cdp cdp signals normally execute in a single cycle. like all the previous cycles, inmreq is driven low to signal when an instruction is entering th e decode and then the execute stage of the pipeline: ? if the instruction really is to be executed, the pass signal is be driven high during phase 2 of execute ? if the coprocessor can execute the instruction immediately it drives chsd[1:0] with last ? if the instruction requires a busy-w ait cycle, the coprocessor drives chsd[1:0] with wait and then chse[1:0] with last. figure 4-5 on page 4-14 shows a cdp which is cancelled due to the previous instruction causing a data abort. the cdp instruction ente rs the execute stage of the pipeline and is signalled to execute by pass . in the following phase latecancel is asserted. this causes the coprocessor to terminate execution of the cdp instruction and for it to cause no state changes to the coprocessor.
ARM9TDMI coprocessor interface 4-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 4-5 ARM9TDMI late cancelled cdp
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-15 4.6 privileged instructions the coprocessor may restrict cer tain instructions for use in privileged modes only. to do this, the coprocessor will have to track the intrans output. figure 4-6 shows how intrans changes after a mode change. figure 4-6 ARM9TDMI privileged instructions
ARM9TDMI coprocessor interface 4-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a the first two chsd responses are ignored by the ARM9TDMI because it is only the final chsd response, as the instruction moves fr om decode into execute, that counts. this allows the coprocessor to change its response as intrans / inm[4:0] changes.
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-17 4.7 busy-waiting and interrupts the coprocessor is permitted to stall, or busy-wait, th e processor during the execution of a coprocessor instruction if , for example, it is still bu sy with an earlier coprocessor instruction. to do so, the coprocessor asso ciated with the decode stage instruction drives wa i t onto chsd[1:0] . when the instruction concerned enters the execute stage of the pipeline the coprocessor may drive wa i t onto chse[1:0] for as many cycles as necessary to keep the instruction in the busy-wait loop. for interrupt latency reasons the coprocesso r may be interrupted while busy-waiting, thus causing the instruction to be abandoned. abandoning execution is done through pass . the coprocessor must monitor the stage of pass during every busy-wait cycle. if it is high, the instruction should still be executed. if it is low, the instruction should be abandoned. figure 4-7 on page 4-18 shows a busy-waited coprocessor instruction being abandoned due to an interrupt:
ARM9TDMI coprocessor interface 4-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 4-7 ARM9TDMI busy waiting and interrupts
ARM9TDMI coprocessor interface arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 4-19 4.8 coprocessor 15 mcrs coprocessor 15 is typically reserved for use as a system control coprocessor. for an mcr to coprocessor 15, it is possible to transf er the coprocessor data to the coprocessor on the ia and da buses. to do this the coprocessor should drive go on the coprocessor handshake signals for a number of cycles. fo r each cycle that the coprocessor responded with go on the handshake signals the coprocessor data will be driven onto ia and da as shown in figure 4-8. figure 4-8 ARM9TDMI coprocessor 15 mcrs
ARM9TDMI coprocessor interface 4-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-1 chapter 5 debug support this chapter describes the debug sup port for the ARM9TDMI, including the embeddedice macrocell: ? about debug on page 5-2 ? debug systems on page 5-3 ? debug interface signals on page 5-5 ? scan chains and jtag interface on page 5-11 ? the jtag state machine on page 5-12 ? test data registers on page 5-18 ? ARM9TDMI core clocks on page 5-24 ? clock switching during debug on page 5-25 ? clock switching during test on page 5-26 ? determining the core state and system state on page 5-27 ? exit from debug state on page 5-30 ? the behavior of the program counter during debug on page 5-33 ? embeddedice macrocell on page 5-36 ? vector catching on page 5-45 ? single stepping on page 5-46 ? debug communications channel on page 5-47.
debug support 5-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.1 about debug the ARM9TDMI debug interface is based on ieee std. 1 149.1- 1990, standard test access port and boundary-scan architecture. refer to this standard for an explanation of the terms used in this chapter and for a description of the ta p controller states. the ARM9TDMI contains hardware extens ions for advanced debugging features. these are intended to ease th e user?s 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 ARM9TDMI is said to be in debug state. at this point, the internal state of the core and the external state of the system may be examined. once examination is complete, the core and sy stem state may be restored and program execution resumed. the ARM9TDMI is forced into debug state ei ther by a request on one of the external debug interface signals, or by an internal functional uni t known as the embeddedice macrocell. once in debug state, the core isolates itself from the memory system. the core can then be examined while all ot her system activity co ntinues as normal. the internal state of the ARM9TDMI is ex amined via a jtag-style serial interface, which allows instructions to be serially inserted into the pipeline of the core without using the external data bus. thus, when in debug state, a store-multiple (stm) could be inserted into the instruction pipeline, and this would export the contents of the ARM9TDMI registers. this data can be serial ly shifted out without affecting the rest of the system.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-3 5.2 debug systems the ARM9TDMI forms one component of a debug system that interfaces from the high-level debugging performed by the user to the low-level interface supported by the ARM9TDMI. a typical system is shown in figure 5-1. figure 5-1 typical debug system such a system typically has three parts: ? the debug host ? the protocol converter ? the ARM9TDMI on page 5-4. these are described in the following paragraphs. 5.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 the user to issue high-level commands such as ?set breakpoint at location xx?, or ?examine the contents of memory from 0x0 to 0x100?. 5.2.2 the protocol converter the debug host is connected to the arm9td mi development system via an interface (an rs232, for example). the messages broadcast over this connection must be converted to the interface signals of the arm9 tdmi. this function is performed by the protocol converter, for example, multi-ice. 'hexj krvw 3urwrfro frqyhuwhu +rvwfrpsxwhuuxqqlqjdupvgru$': iruh[dpsoh0xowl,&( -7$* 'hyhorsphqwv\vwhp frqwdlqlqj$507'0, 'hexj wdujhw
debug support 5-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.2.3 the ARM9TDMI the ARM9TDMI, with hardware extensions to ease debugging, is the lowest level of the system. the debug extensions allow th e user to stall the core from program execution, examine its internal state and th e state of the memory system, and then resume program execution. the debug host and the protocol converter are system dependent. the rest of this chapter describes the ARM9TDMI hardware debug extensions.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-5 5.3 debug interface signals there are four primary external signals associated with the debug interface: ? iebkpt , dewpt , and edbgrq , with which the system asks the ARM9TDMI to enter debug state ? dbgack , which the ARM9TDMI uses to flag back to the system when it is in debug state. 5.3.1 entry into debug state on breakpoint any instruction being fetched for 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 phase1. this minimizes the setup time, giving the embeddedice macrocell an entire phase in which to perform the co mparison. this is shown in figure 5-2 on page 5-6. external logic, such as ad ditional breakpoint comparators, may be built to extend the functionality of the embeddedice macrocell. their output should be applied to the iebkpt input. this signal is simply ored with the internally generated breakpoint signal before being applied to the ARM9TDMI 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 sequen ce occurs during the execute cycle of the breakpointed instruction. the latched breakpoint signal forces the processor to start the debug sequence.
debug support 5-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 5-2 breakpoint timing 5.3.2 breakpoints and exceptions a breakpointed instruction may have a prefet ch abort associated with it. if so, the prefetch abort takes priority a nd the breakpoint is ignored. (if there is a prefetch abort, instruction data may be invalid, the breakpoint may have been data-dependent, and as the data may be incorrect, the breakpoint may have been triggered incorrectly.) swi and undefined instructions are treated in the same wa y as any other instruction which may have a breakpoint set on it. therefor e, 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 breakpoi nted instruction is discarded. once the interrupt has been serviced, the execution flow is returned to the original program.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-7 this means that the instruction which was previously breakpointed is fetched again, and if the breakpoint is still set, the processor enters debug st ate once it reaches the execute stage of the pipeline. once the processor has entered debug state, it is important that further interrupts do not affect the instructions executed. for this r eason, 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. 5.3.3 watchpoints entry into debug state following a watchpoi nted memory access is imprecise. this is necessary because of the nature of the pipeline and the timing of the watchpoint signal. after a watchpointed access, the next instruct ion 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 de layed for one cycle while the instruction completes. the timing of debug entry following a watchpointed load in this case is shown in figure 5-3 on page 5-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. once the debugging session is complete, normal continuation would involve a return to instruction 5, the next instruction in the code sequence which has not yet been executed. the instruction following the instruction which generated the watchpoint could have modified the program counter (pc) . if this has happened, it will not be possible to determine the instruction which caused the watchpoint. a timing diagram showing debug entry after a watchpoint where the next instruction is a branch is shown in figure 5-4 on page 5-9. however, it is alwa ys possible to restart the processor. once the processor has entered debug state, the ARM9TDMI core may be interrogated to determine its state. in the case of a watchp oint, 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 in struction sub pc, pc, #20 is scanned in and the processor restarted, execution flow would re turn to the next instruction in the code sequence.
debug support 5-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 5-3 watchpoint entry with data processing instruction
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-9 figure 5-4 watchpoint entry with branch
debug support 5-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.3.4 watchpoints and exceptions if there is an abort with the data access as well as a watchpoint, the watchpoint condition is latched, the exception entry sequence performed, and then the processor enters debug state. if there is an interr upt pending, again the ARM9TDMI allows the exception entry sequence to occur and then enters debug state. 5.3.5 debug request a debug request can take place through the em beddedice macrocell or by asserting the edbgrq signal. the request is synchronized and passed to the processor. debug request takes priority over any pending interr upt. following synchronization, the core will enter debug state when the instruction at the execution stage of the pipeline has completely finished executing (once memory and write stages of the pipeline have completed). while waiting for the instruction to finish executing, no more instructions will be issued to the execute stage of the pipeline. 5.3.6 actions of the ARM9TDMI in debug state once the ARM9TDMI is in debug state, both memory interfaces will indicate internal cycles. this allows the rest of the memo ry system to ignore the ARM9TDMI and function as normal. since the rest of the system continues operation, the ARM9TDMI will ignore aborts and interrupts. the bigend signal should not be changed by the system while in debug state. if it changes, not only will there be a synchronization problem, but the programmer?s view of the ARM9TDMI will change without the knowledge of the debugger. the nreset signal must also be held stable during debug. if the system applies reset to the ARM9TDMI ( nreset is driven low), the state of the ARM9TDMI will change without the knowledge of the debugger. when instructions are executed in de bug state, the ARM9TDMI will change asynchronously to the memory system outputs (except for inmreq , iseq , dnmreq , and dseq which change synchronously from gclk). for example, every time a new instruction is scanned into the pipeline, the instruction address bus will change. if the instruction is a load or stor e operation, the data address bus will change as the instruction executes. although this is asynchronous, it should not affect the system, because both interfaces will be indica ting internal cycles. care must be taken with the design of the memory controller to ensure that this does not become a problem.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-11 5.4 scan chains and jtag interface there are three scan chains inside the ARM9TDMI. 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 fourth scan chain. th is is intended to be used for an external boundary scan chain around the pads of a packaged device. th e signals provided for this scan chain are described on scan chain 3 on page 5-22. the three scan chains of th e ARM9TDMI are referred to as scan chain 0, 1 and 2. note the ARM9TDMI tap controller supports 32 scan chains. scan chains 0 to 15 have been reserved for use by arm. any extens ion scan chains should be implemented in the remaining space. the screg[4:0] signals indicate which scan chain is being accessed.
debug support 5-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.5 the jtag state machine the process of serial test and debug is best explained in conjunction with the jtag state machine. figure 5-5 shows the state trans itions that occur in the tap controller. the state numbers are also shown on the diagram. th ese are output from the ARM9TDMI on the tapsm[3:0] bits. figure 5-5 test access port (tap ) controller state transitions
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-13 5.5.1 reset the jtag interface includes a state-machine c ontroller (the tap co ntroller). in order to force the tap controller in to the correct state after powe r-up of the device, a reset pulse must be applied to the ntrst signal. if the jtag interface is to be used, ntrst must be driven low, and then high again. if the boundary scan interface is not to be used, the ntrst input may be tied permanently low. note a clock on tck is not needed 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 . 5.5.2 pullup resistors the ieee 1149.1 standard effectively requires tdi and tms to have internal pullup resistors. in order to minimi ze static current draw, these re sistors are not fitted to the ARM9TDMI. accordingly, the four in puts to the test interface (the tdo , tdi and tms signals plus tck ) must all be driven to valid logi c levels to achieve normal circuit operation. 5.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 duri ng the capture-ir controller state is 0001. 5.5.4 public instructions the following public instructions are supported: table 5-1 public instructions instruction binary code extest 0000 scan_n 0010 intest 1100
debug support 5-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 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 te st mode by the extest instruction. the extest instruction connects th e selected scan chain between tdi and tdo . when the instruction register is loaded with the extest inst ruction, all the scan cells are placed in their test mode of operation. in the capture-dr state, i nputs 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 prev iously captured test data is shifted out of the scan chain via tdo , while new test data is shifted in via the tdi input. this data is applied immediately to the system logic and system pins. scan_n (0010) this instruction connects the scan path select register between tdi and tdo . during the capture-dr state, the fixed va lue 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. idcode 1110 bypass 1111 clamp 0101 highz 0111 clampz 1001 sample/preload 0011 restart 0100 table 5-1 public instructions (continued) instruction binary code
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-15 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 inst ruction. the intest instruction connects the se lected 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 via the tdo pin, while new test data is shifted in via 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 regi ster 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, which should be tied to a constant value being 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 (s ystem) 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 via the tdo pin, while data is shifted in via the tdi pin into the id register. in the update-dr state, the id register is unaffected. bypass (1111) the bypass instruction connects a 1-bit shif t register (the bypass register) between tdi and tdo .
debug support 5-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a when the bypass instruction is loaded into the instruction register, all the scan cells are placed in their normal (syste m) 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 via tdi and out via tdo after a delay of one tck cycle. the first bit shifted out will be a zero. the bypass register is not aff ected 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 th e instruction register, the state of all the output signals is defined by the values previo usly loaded into the currently-loaded scan chain. note this instruction should 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 via tdi and out via tdo after a delay of one tck cycle. the first bit shifted out will be a zero. the bypass register is not aff ected in the update-dr state. highz (0111) this instruction connects a 1-bit shift register (the bypass register) between tdi and tdo . when the highz instruction is loaded into the instruction register, all ARM9TDMI outputs are driven to the high impedance stat e and the external highz signal is driven high. this is as if the signal tbe had been driven low.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-17 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 via tdi and out via tdo after a delay of one tck cycle. the first bit shifted out will be a zero. the bypass register is not affected in the update-dr state. clampz (1001) this instruction connects a 1-bit shift re gister (the bypass register) between tdi and tdo . when the clampz instruction is loaded into the instruction regist er and scan chain 0 is selected, all the 3-state out puts (as described above) are placed in their inactive state, but the data supplied to the outputs is derive d from the scan cells. the purpose of this instruction is to ensure that, during producti on 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 via tdi and out via tdo after a delay of one tck cycle. the first bit shifted out will be 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 select ed scan chain are placed in the normal mode of operation. in the capture-dr state, a sn apshot of the signals of the boundary scan is taken on the rising edge of tck . normal system opera tion is unaffected. in the shift-dr state, the sampled test data is shifted out of the boundary scan via the tdo pin, while new data is shifted in via the tdi pin to preload the boundary scan parallel input latch. note that this data is not applied to the system logic or system pins while the sample/preload instruction is active. this instruction should be used to preload the boundary scan register with known data prior to selecting intest or extest instructions. restart (0100) this instruction is used to restart the pr ocessor on exit from debug state. the restart instruction connects the by pass register between tdi and tdo and the tap controller behaves as if the bypass instructi on had been loaded. the processor will resynchronize back to the memory system once the run-test/ idle state is entered.
debug support 5-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.6 test data registers the following test data registers may be connected between tdi and tdo : ? bypass register ? ARM9TDMI device identification (id) code register ? instruction register on page 5-19 ? scan chain select register on page 5-19 ? scan chains 0, 1, 2, and 3 on page 5-20. these are described below. 5.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. 5.6.2 ARM9TDMI 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 arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-19 the ieee format of the id register is as shown in figure 5-2 on page 5-6: 5.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 0b0001 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). du ring the update-ir state, the value in the instruction register becomes the current instruction. on reset, idcode becomes the current instruction. 5.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 se lect register is selected as the serial path between tdi and tdo . during the capture-dr state, the value 0b10000 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). during the update-dr state, th e value in the register sel ects a scan chain to become the currently active scan chain. all further in structions such as intest then apply to that scan chain. table 5-2 id code register bits contents 31?28 version number 27?12 part number 11?1 manufacturer identity 01
debug support 5-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a the currently selected s can 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. the tap controller may be used to driv e external scan chains in addition to those within the ARM9TDMI macrocell. the extern al 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 5-3. an external scan chain may take any other number. the se rial 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 will be 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, a multiplexor must be built externally to apply the desired scan chain output to sdoutbs . the multiplexor can be controlled by decoding screg[4:0] . 5.6.5 scan chains 0, 1, 2, and 3 these allow serial access to the core logi c, and to the embeddedice macrocell for programming purposes. each scan cell is fairly simple and can perform two basic functions, capture and shift. scan chain 0 purpose primarily for inter-device testing (extest), and testing the core (intest). scan chain 0 is select ed via the scan_n instruction. table 5-3 scan chain number allocation scan chain number function 0 macrocell scan test 1debug 2 embeddedice macr ocell programming 3 external boundary scan 4?15 reserved 16?31 unassigned
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-21 length 184 bits. 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?s 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, thus applying known stimuli to the inputs. ? during run-test/idle, the core is cl ocked. normally, the tap controller should only spend one cycle in run-test/idle. the whole operation may then be repeated. extest allows inter-device testing, useful for verifying the connections between devices in the design. the tap controller mu st be placed in exte st mode after scan chain 0 has been selected. ? during capture-dr, the current inputs to the core?s 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, thus applying known values on the core?s outputs. ? during run-test/idle, the core is not clocked. the operation may then be repeated. scan chain 1 purpose primarily for debugging, although it can be used for extest on the data data bus dd[31:0] and the instruction data bus id[31:0] . scan chain 1 is selected vi a the scan_n tap controller instruction. length 67 bits. this scan chain is 67 bits long, 32 bits for data values, 32 bits for instruction data, and three additional bits, sysspeed, dden and an used bit. the three bits serve four different purposes: ? under normal intest test conditions, the dden signal can be captured and examined. ? during extest test conditions, a known value can be scanned into dden to be driven into the rest of the syst em. if a logic 1 is scanned into dden , the data data bus dd[31:0] will drive out the values stored in its scan cells. if a logic 0 is scanned into dden , dd[31:0] will capture the current input values.
debug support 5-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a ? while debugging, the value placed in the sysspeed contro l bit determines whether the ARM9TDMI synchronizes b ack to system speed before executing the instruction. ? after the ARM9TDMI has entered debug state, the first time sysspeed is captured and scanned out, its value tells th e debugger whether the core has entered debug state due to a breakpoint (sysspeed low), or a watchpoint (sysspeed high). scan chain 2 purpose allows access to the embeddedice macrocell 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. to access this serial register, scan chain 2 must first be selected via the scan_n tap controller instruction. the tap controll er 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 macrocell register to be accessed. during update-dr, this register is either read or written depending on the value of bit 37 (0 = read). scan chain 3 purpose allows the ARM9TDMI to contro l an external boundary scan chain. length user-defined. scan chain 3 is provided so that an optional external boundary scan chain may be controlled via the ARM9TDMI. typically this would be used for a scan chain around the pad ring of a packaged device. the foll owing control signals are provided and are generated only when scan chain 3 has been selected. these outputs are inactive at all other times. driveoutbs this is used to switch the scan cells from system mode to test mode. this signal is asserted whenever either the intest, extest, clamp or clampz instruction is selected.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-23 pclkbs this is the update clock, generated in the update-dr state. typically the value scanned into th e chain will be 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 respect ively. 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 th e state machine is not in the shift-dr state, both these clocks are low. in addition to these control outputs, sdin output and sdoutbs input are also provided. when an external scan chain is in use, sdoutbs should be connected to the serial data output and sdin should be connected to the serial data input.
debug support 5-24 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.7 ARM9TDMI core clocks the ARM9TDMI has two clocks, the memory clock gclk , and an internally tck generated clock, dclk . during normal operation, the core is clocked by gclk , and internal logic holds dclk low. when the ARM9TDMI is in the debug state, the core is clocked by dclk under control of the tap state machine, and gclk may 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 in which the clocks switch are during debugging and during testing.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-25 5.8 clock switching during debug when the ARM9TDMI enters debu g state, it must switch from gclk to dclk . this is handled automatically by logic in the ARM9TDMI. 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 . figure 5-6 clock switching on entry to debug state the ARM9TDMI 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 . this must be done in the following sequence. the final instruction of the debug sequence must be shifted into the instructio n data bus scan chain, and clocked in by asserting dclk . at this point, restart must be clocked into the tap controller register. the ARM9TDMI will now automati cally resynchronize back to gclk when the tap controller enters the run-test/idle mode and start fetching instructions from memory at gclk speed. for more information, refer to exit from debug state on page 5-30.
debug support 5-26 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.9 clock switching during test when under serial test conditions, when test patterns are being applied to the core through the jtag inte rface, the ARM9TDMI 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. the tap controller can now be used to perform serial testing on the ARM9TDMI . if scan chain 0 an d intest are selected, dclk is generated while the state m achine is in run-test/idle state. during extest, dclk is not generated. on exit from test, restart must be selected as the tap controller instruction. when this is done, gclk can be allowed to resume. after intest testing, care should be taken to ensure that the core is in a sensib le state before switchin g back. the safest way to do this is to either select restart and then cause a system reset, or to insert mov pc,#0 into the instruction pipeline before switching back.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-27 5.10 determining the cor e state and system state when the ARM9TDMI is in debug state, the core state and system state may be examined. this is done by forcing load and store multiples into the pipeline. before the core state and system state can be examined, the debugger must first determine whether the processor was in t humb or arm state when it entered debug. this is achieved by examining bit 4 of the embeddedice macrocell debug status register. if this is high, the core was in thumb state when it entered debug. if it is low, the core is in arm state. 5.10.1 determining the core state if the processor has entered debug state from thumb state, the simplest course of action is for the debugger to force the core back into arm state. once this is done, the debugger can always execute the same sequence of instructions to determine the processor state. to force the processor into arm state, th e following sequence of thumb instructions should 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 the stores is for illustration only?any register could be used. since all thumb instructions are only 16 bits long, the simplest course of action when shifting them into scan chain 1 is to repeat the instruction twice on the instruction data bus bits. for example, the encoding for bx r0 is 0x4700. thus, if 0x47004700 is shifted into the 32 bits of the instruction data bus of scan chain 1, the debugger does not have to track from which half of the bus the processor expects to read instructions. from this point on, the processor state can be determined by the sequences of arm instructions described below. once the processor is in arm state, typica lly the first instruction executed would be: stm r0, {r0-r15} this causes the contents of th e registers to be made visible on the data data bus. these values can then be sampled and shifted out.
debug support 5-28 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a after determining the values in the current bank of registers, it may be desirable to access banked registers. this can only be done by changing mode. normally, a mode change may only occur if the core is already in a privileged mode. however, while in debug state, a mode change from any mode into any other mode may occur. note that the debugger must restore the original mode before exiting debug state. for example, assume that the debugger has b een asked to return th e state of the user mode and fiq mode registers, and debug state was entered in supervisor mode. the instruction sequence could 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 since between each core cloc k, 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?s state since the arm9td mi is fully static. however, this same method cannot be used for determining the state of the rest of the system. while in debug state, only the following instructions may be inserted into the instruction pipeline for execution: ? all data processing operations ? all load, store, load multiple and store multiple instructions ? msr and mrs. 5.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, the ARM9TDMI must be forced to synchronize back to system speed. the 33rd bit of scan chain 1, sysspeed, controls this. a legal debug instruction may be placed in the instruction data bus of scan chain 1 with bit 33 (the sysspeed bit) low. this instruction will then be 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.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-29 after the system speed instructions have been scanned into the instruction data bus and clocked into the pipeline, the restart instruction must be loaded into the tap controller. this will cause the ARM9TDMI automatically to resynchronize back to gclk when the tap controller enters ru n-test/idle state, and execute the instruction at system speed. debug stat e will be reentered once the instruction completes execution, when the processor will switch itself back to the internally generated dclk . when the instruction has completed, dbgack will be high. at this point intest can be selected in th e tap controller, and debugging can resume. to determine whether a system speed inst ruction 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 may be stalled indefinitely by nwait . therefore, the only wa y to determine whether the memory access has completed is to exam ine the syscomp bit. when this bit is high the instruction has completed. by the use of system speed load multiples and debug store multiples, the state of the system memory can be passed to the debug host. 5.10.3 instructions which ma y have the sysspeed bit set the only valid instructions on which to set this bit 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 5-30 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.11 exit from debug state leaving debug state involves restoring the internal state of the ARM9TDMI, causing a branch to the next instruction to be executed, and synchronizing back to gclk . after restoring the internal state, a branch instruction must be loaded into the pipeline. for details on calculating the branch, see debug interface signals on page 5-5. bit 33 of scan chain 1 is used to for ce the ARM9TDMI to resynchronize back to gclk . the penultimate instruction in the debug sequence is a branch to the instruction at which 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 to be scanned in is a nop (such as mov r0, r0 ), with bit 33 set high. the core is then clocked to load this instruction into the pipeline. now, the restart instruction is selected in the tap controller. when the state machine enters the run-test/idle stat e, the scan chain will revert back to system mode and clock resynchronization to gclk will occur within the ARM9TDMI. normal operation will then resume, with instructions being fetched from memory. the delay, until the state machine is in run-test/idle state, allows conditions to be set up in other devices in a multiprocessor system without taking immediate effect. then, when run-test/idle state is entere d, all the processors resume operation simultaneously. the function of dbgack is to tell the rest of the system when the ARM9TDMI is in debug state. this can be used to inhibit peri pherals such as watchdog timers that have real time characteristics. also, with a small amount of external logic, dbgack can be used to mask out all memory accesses caused by the debugging process, so that the same number of memory accesses are seen independen t of debug entry. this, however, is only possible if debugging is performed through breakpoints. it is not possible to precisely mask memory accesses due to debu gging if watchpoints are used. for example, when the ARM9TDMI enters debug state after a breakpoint, the instruction pipeline contains the breakpointed instruction plus two other instructions which have been prefetched. on entry to debug state the pipeline is flushed. so, on exit from debug state, the pipeline must be refill ed to its previous stat e. therefore, because of the debugging process, more memory accesses occur than would normally be expected. through the use of dbgack , together with a small am ount of external logic it is possible for a peripheral that simply counts the number of instruction fetches to return the same answer after a program has run both with and without debugging. it can be seen in figure 5-8 on page 5-32 that two instructions are fetched after that which breakpoints. figure 5-7 on page 5-31, shows dbgack normally masks the first three instruction fetches out of the debug state, corresponding to the breakpoint instruction, and the two instru ctions prefetched after it. si nce under some circumstances
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-31 dbgack may remain high for more than three instruction fetches, if precise instruction access counting is re quired, some external logic must generate a modified dbgack that always falls after three instruction fetches. note when a system speed access occurs, dbgack remains high throughout the system speed memory accesses. it then falls af ter the system speed memory accesses are completed, and finally rises again as the processor re-enters de bug state. therefore dbgack masks all system speed memory accesses. figure 5-7 debug exit sequence
debug support 5-32 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 5-8 debug state entry
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-33 5.12 the behavior of the progr am counter during debug to force the ARM9TDMI to branch back to the place at which program flow was interrupted by debug, the debugger must keep track of what happens to the pc. there are six cases: ? breakpoint ? watchpoint ? watchpoint with another exception on page 5-34 ? watchpoint and breakpoint on page 5-34 ? debug request on page 5-34 ? system speed accesses on page 5-35. in each case the same equation is used to determine where to resume execution. these are explained below. 5.12.1 breakpoint entry to debug state from a breakpointed inst ruction 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 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 the 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 br anch could be replaced with a subtract with the pc as the destination. for example, sub pc, pc, #28 for arm code. 5.12.2 watchpoint returning to the program execution after entering debug state from a watchpoint is done in the same way as the procedure described in breakpoint above. debug entry adds four addresses to the pc, and every instruction a dds one address. since the instruction after that which caused the watchpoint has executed, instruction execution will resume at the one after that.
debug support 5-34 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.12.3 watchpoint with another exception if a watchpoint access simultaneously causes a data abort, the ARM9TDMI will enter 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 inte rrupt, or any other exception, occurs during a watchpointed memory access. the ARM9TDMI will enter debug state in the mode of the exception, and so the de bugger must check to see whether this happened. the debugger can deduce whether an excepti on 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, the user should be given the choice of whether to service the exception before debugging. for example, suppose an abort occurred on a watchpoint access, and ten instructions had been executed to determine this. the following sequence could be used to return program execution: 0 eafffff1; b -15 addresses (twos complement) 1 e1a00000; nop (mov r0, r0), sysspeed bit is set this will force a branch back to the abort ve ctor, causing the instruct ions at that location to be refetched and executed. note that afte r the abort service routine, the instruction that caused the abort and watchpoint will be re-executed. this will cause the watchpoint to be generated and hence the arm9 tdmi will enter debug state again. 5.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 should be performed as for breakpoint on page 5-33 to determine where to resume. in this case, it will be at the breakpoint instruction, since this has not been executed. 5.12.5 debug request entry into debug state via 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 in which the user has invoked a debug request, and decides to retu rn to program execution immediately: 0 eafffffb; b -5 addresses (2s complement) 1 e1a00000; nop (mov r0, r0), sysspeed bit is set
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-35 this restores the pc, and restarts th e program from the next instruction. 5.12.6 system speed accesses if a system speed access is performed duri ng debug state, the value of the pc is increased by five addresses. since 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 enters abort mode before re turning to debug state. this is similar to an aborted watchpoint. however, the problem is much harder to fix because the abort was not caused by an instru ction in the main progr am, 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 hence the abort address. in this case, the value of the pc is invalid, but the debugger will know the address of the location that was being accessed. thus the de bugger can be written to help the abort handler fix the memory system. 5.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 instructio ns executed (including the final branch), and s is the number of system speed instructions executed.
debug support 5-36 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.13 embeddedice macrocell the embeddedice macrocell is integral to the ARM9TDMI processor core. it has two hardware breakpoint/watchpoint units each of which may be conf igured to monitor either the instruction memory interface or th e data memory interface. each watchpoint unit has a value and mask register, with an address, data and control field. because the ARM9TDMI processor core has a harvard architecture, the user must specify whether the watchpoint registers exam ine 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 inst ruction 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. therefor e, 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 should be driven by the result of the comparison. figure 5-9 on page 5-38 gives an overview of the operation of the embeddedice macrocell. the ARM9TDMI embeddedice macrocell ha s logic that allows single stepping through code. this reduces the work required by an external debugger, and removes the need to flush the instruction cache. there is al so hardware to allow efficient trapping of accesses to the exception vectors. these bloc ks of logic free the two general-purpose hardware breakpoint/watchpoint units fo r use by the programmer at all times. the general arrangement of the embeddedi ce macrocell is shown in figure 5-9 on page 5-38. 5.13.1 register map the embeddedice macrocell register map is shown below: table 5-4 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
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-37 01000 32 watchpoint 0 address value 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 5-4 ARM9TDMI embeddedice macrocell register map (continued) address width function
debug support 5-38 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 5-9 ARM9TDMI embeddedice macrocell overview for example, if a watchpoint is requested on a particular memory location but the data value is irrelevant, the data mask register can be programmed to 0xffffffff, (all bits set to 1), to make the entire data bus value ignored. 5.13.2 using the mask registers for each value register there is an associated mask register in th e 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.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-39 5.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 br eakpoint comparators examine th e data address, data and control signals. in this case, the format of the re gister is as shown in figure 5-10. note bit 8 and bit 3 cannot be masked. figure 5-10 watchpoint control register for data comparison the bits have the following functions: (1$%/( 5$1*( &+$,1 (;7(51 'q75$16 '0$6>@ 'q5: '0$6>@ table 5-5 watchpoint control register for data comparison bit functions bit function dnrw compares against the data not read/write signal from the core in order to detect the direction of th e data data bus activity. nrw is 0 for a read, and 1 for a write. dmas[1:0] compares against the dmas[1:0] signal from the core in order to detect the size of the data data bus activity. dntrans compares against the data not tran slate signal from the core in order to determine between a user mode ( dntrans = 0) data transfer, and a privileged mode ( dntrans = 1) transfer.
debug support 5-40 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a if bit 3 of the control register is programmed to 0, the comparators will 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 5-11 on page 5-41. extern is an external input into the embeddedice macrocell that allows the watchpoint to be dependent upon some external condition. the extern input for watchpoint 0 is labelled extern0 , and the extern input for watchpoint 1 is labelled extern1 . chain can be connected to chain output of another watchpoint in order to implement, for example, debugger re quests 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 latc h. the address/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. range can be connected to the range output of another watchpoint register. in the ARM9TDMI embeddedice ma crocell, the address comparator output from watchpoint 1 is connected to the range input of watchpoint 0. this allows two watchpoints to be coupled fo r detecting conditions that occur simultaneously, for example, for range-checking. enable if a watchpoint match occurs, the in ternal watchpoint signal will only be asserted when the enable bit is set. this bit only exists in the value register, it cannot be masked. table 5-5 watchpoint control register for data comparison bit functions bit function
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-41 figure 5-11 watchpoint control re gister for instruction comparison table 5-6 watchpoint control register for instruction comparison bit functions bit function itbit compares against the thumb state signa l from the core to determine between a thumb ( itbit = 1) instruction fetch or an arm ( itbit = 0) fetch. intrans compares against 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) fetch. extern is an external input into the embeddedice macrocel l that allows the watchpoint to be dependent upon some external condition. the extern input for watchpoint 0 is labelled extern0 , and the extern input for watchpoint 1 is labelled extern1 . (1$%/( 5$1*( &+$,1 (;7(51 ,q75$16 ,7%,7 ; ;
debug support 5-42 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.13.4 debug control register the ARM9TDMI debug control register is four bits wide and is shown in figure 5-12. figure 5-12 debug control register bit 3 controls the single-step hardware, and this is explained in more detail in single stepping on page 5-46. 5.13.5 debug status register the debug status register is five bits wide. it is a read only register and any writes will be ignored. if it is accessed for a read (wit h the read/write bit low) , the status bits are read. chain can be connected to chain output of another watchpoint in order to implement, for example, debugger requests of the form ?breakpoint on address yyy only when in process xxx?. in the ARM9TDMI embedde dice macrocell, the chainout output of watchpoint 1 is connected to the chain input of watchpoint 0. the chainout output is derived from a latc h. the address/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. range can be connected to th e range output of another wa tchpoint register. in the ARM9TDMI embeddedice macroc ell, the rangeout output of watchpoint 1 is connected to the range input of watchpoint 0. this allows two watchpoints to be coupled fo r detecting conditi ons that occur simultaneously, for example, for range-checking. enable if a watchpoint match occurs, the internal breakpoint signal will only be asserted when the enable bit is set. this bit only exists in the value register, it cannot be masked. table 5-6 watchpoint control register for instruction comparison bit functions (continued) bit function 6lqjohvwhs '%*54 '%*$&. ,17',6
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-43 figure 5-13 debug status register the function of each bit in this register is as follows: bit 1 and 0 allow the values on the synchronized versions of dbgrq and dbgack to be read. bit 2 allows the state of the core interrupt enable signal ( ifen ) to be read. since the capture clock for the scan chain may be as ynchronous to the processor clock, the dbgack output from the core is synchronized before being used to generate the ifen status bit. bit 3 allows the state of the syscomp bit from the core (synchronized to tck ) to be read. this allows the de bugger to determine that a memory access from the debug state has completed. bit 4 allows itbit to be read. this enables the debugger to determine what state the processor is in, and hen ce which instructions to execute. 5.13.6 vector catch register the ARM9TDMI embeddedice macrocell cont rols logic to enab le accesses to the exception vectors to be trapped in an efficien t manner. this is controlled by the vector catch register, as shown in figure 5-14 on page 5-44. the functionality is described in vector catching on page 5-45. 6<6&203 '%*54 '%*$&. ,)(1 ,7%,7
debug support 5-44 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 5-14 vector catch register ),4 ,54 5hvhuyhg 'b$eruw 3b$eruw 8qghi 5hvhw 6:,
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-45 5.14 vector catching the ARM9TDMI embeddedice macr ocell 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 regist er 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 fetches an instruction from location 0x8. the vector catch hardware detects this access and forces the internal breakpoint signal high into the ARM9TDMI control logic. this, in tu rn, forces the ARM9TDMI to enter debug state. the behavior of the hardware is independ ent of the watchpoint comparators, leaving them free for general use. the vector catch regi ster 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 5-46 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 5.15 single stepping the ARM9TDMI embeddedice m acrocell contains logic that allows efficient single stepping through code. this leaves the m acrocell watchpoint comparators free for general use. this function is enabled by setting bit 3 of the debug control register. the state of this bit should only be altered while the processo r is in debug state. if the processor exits debug state and this bit is high, the proces sor fetches an instruction, executes it, and then immediately reenters 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 arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-47 5.16 debug communications channel the ARM9TDMI embeddedice macrocell co ntains a communication channel for passing information between the target and th e 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 and a 6-bit wide comms control register for synchronized handshaking between the processor and the asynchronous debugger. these registers are located in fixed locati ons in the embeddedice register map (as shown in figure 5-9 on page 5-38) and ar e accessed from the processor via mcr and mrc instructions to coprocessor 14. 5.16.1 debug comms channel registers the debug comms control register is read only, and allows synchronized handshaking between the processor and the debugger. figure 5-15 debug comms control register the function of each register bit is described below: bits 31:28 contain a fixed pattern that denote s the embeddedice macrocell version number, in this case 0010. bits 27:2 unused. bit 1 denotes from the processor?s point of view, whether the comms data write register is free. if, from the processor?s point of view, the comms data write register is free (w=0), new data may be written. if it is not free (w=1), the processor must poll until w=0. if, from the debugger?s point of view, w=1, some new data has been written which may then be scanned out. bit 0 denotes whether there is some new data in the comms data read register. if, from the processor?s point of view, r=1, there is some new data which may be read via an mrc instruction. if, from the debugger?s point of view, r=0, the comms data read register is free and new data may be placed there through the scan chain. if r=1, this denotes that data previously placed there through the s can chain has not been collected by the processor, and so th e debugger must wait. 5 8qxvhg :
debug support 5-48 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a from the debugger?s point of view, the regi sters are accessed via the scan chain in the usual way. from the processor, these regi sters are accessed via co processor register transfer instructions. the following instructions should be used: mrc p14, 0, rd, c0, c0, 0 returns the debug comms control register into rd. mcr p14, 0, rn, c1, c0, 0 writes the value in rn to the comms data write register. mrc p14, 0, rd, c1, c0, 0 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 in order to access the debug comms channel. 5.16.2 communications via the comms channel there are two methods of communicating via the comms channel, transmitting and receiving. the following descri ptions detail their usage. sending a message to the debugger when the processor wishes to send a message to the debugger, it must check the comms data write register is free for use by finding out whether the w bit of the debug comms control register is clear. it reads the debug comms control regi ster to check stat us of the w bit. ? if the w bit is set, previously written data has not been read by the debugger. the processor must continue to poll the cont rol 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 is 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.
debug support arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 5-49 the debugger sees a synchronized version of both the r and w bit when it polls the debug comms control register through the jt ag 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 may begin again. as an alternative to polling, the debug comms channel can be interrupt driven by connecting the ARM9TDMI 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. when the comms data read register is free, data is written there via 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 an mclk synchronized version. if the r bit is set, there is data waiting to be co llected. this data can be read via an mrc instruction to coprocessor 14. the action of this load clears the r bit in the debug comms control register. when th e debugger polls this register and sees that the r bit is clear, the data has been taken, and the process may now be repeated. note it is not possible to read embeddedice registers through serialized vectors applied through scan chain 0.
debug support 5-50 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 6-1 chapter 6 test issues this chapter examines the test issues fo r the ARM9TDMI and lists the scan chain 0 bit order under the headings: ? about testing on page 6-2 ? scan chain 0 bit order on page 6-3.
test issues 6-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 6.1 about testing the ARM9TDMI processor core supports parallel and serial test methodologies. the parallel test patterns are de rived from assembler arm code programs written to achieve a high fault coverage. the ARM9TDMI processor core has a fu lly jtag-compatible scan chain which intersects all the inputs and outputs. this allows the test patterns to be serialized and injected to the processor via the jtag interface. both the parallel and serial test patterns are supplied to ARM9TDMI processor core licensees. the scan chain also supports extest, allowing the connections between the ARM9TDMI processor core and other jtag-compatible peripherals to be tested.
test issues arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 6-3 6.2 scan chain 0 bit order table 6-1 scan chain 0 bit order number signal direction 1 id[0] input 2 id[1] input 3:31 id[2:30] input 32 id[31] input 33 sysspeed internal 34 unused internal 35 dden output 36 dd[31] bidirectional 37 dd[30] bidirectional 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
test issues 6-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 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 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 table 6-1 scan chain 0 bit order (continued) number signal direction
test issues arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 6-5 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 unien input 169 iseq output 170 inm[4] output 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 6-1 scan chain 0 bit order (continued) number signal direction
test issues 6-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 7-1 chapter 7 instruction cycle summary and interlocks this chapter gives the instruction cycle times and shows the timing diagrams for interlock timing: ? instruction cycle times on page 7-2 ? interlocks on page 7-5.
instruction cycle summary and interlocks 7-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 7.1 instruction cycle times table 7-1 describes the symbols used in tables. table 7-2 summarizes the ARM9TDMI instruction cycle counts and bus activity when executing the arm instruction set. table 7-1 symbols used in tables symbol meaning b the number of busy-wait stat es during coprocessor accesses m in the range 1 to 4, depend ing on early termination (see multiplier cycle counts on page 7-4) n the number of words transfe rred in an ldm/stm/ldc/stc c coprocessor register transfer (c-cycle) i internal cycle (i-cycle) n non-sequential cycle (n-cycle) s sequential cycle (s-cycle) table 7-2 instruction cycle bus times instruction cycles instruction bus data bus comment data op 1 1s 1i normal case, pc not destination data op 2 1s+1i 2i with register cont rolled shift, pc not destination data op 3 2s + 1n 3i pc destination register data op 4 2s + 1n + 1i 4i with register controlled shift, pc destination register ldr 1 1s 1n normal case, not loading pc ldr 2 1s+1i 1n+1i not loading pc an d following instruction uses loaded word (1 cycle load-use interlock) ldr 3 1s+2i 1n+2i loaded byte, half-word, or unaligned word used by following instruction (2 cycle load-use interlock) ldr 5 2s+2i+1n 1n+4i pc is destination register
instruction cycle summary and interlocks arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 7-3 str 1 1s 1n all cases ldm 2 1s+1i 1s+1i loading 1 register, not the pc 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 in struction uses transferred data mrc b+3 1s+(b+2)i (b+2)i+1c mrc to the pc mrs 1 1s 1t all cases msr 1 1s 1t if only flags are updated (mask_f) msr 3 1s + 2i 3i if any bits other than just the flags are updated (all masks other than_f) 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 7-2 instruction cycle bus times (continued) instruction cycles instruction bus data bus comment
instruction cycle summary and interlocks 7-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a table 7-3 shows the instruction cycle time s from the perspective of the data bus: 7.1.1 multiplier cycle counts the number of cycles that a multiply instruction takes to complete depends on which instruction it is, and on the value of the multiplier-operand. the multiplier-operand is the contents of the register sp ecified by bits [8:11] 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 zero or one 2 if bits [31:16] of the multiplier operand are all zero or one 3 if bits [31:24] of the multiplier operand are all zero or all one 4 otherwise. ? for arm umull, umlal, m is: 1 if bits [31:8] of the multiplier operand are all zero 2 if bits [31:16] of the multiplier operand are all zero 3 if bits [31:24] of the multiplier operand are all zero 4 otherwise. table 7-3 data bus instruction times instruction cycle time ldr 1n str 1n ldm,stm 1n+(n-1)s swp 1n+1s ldc, stc 1n+(n-1)s mcr,mrc 1c
instruction cycle summary and interlocks arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 7-5 7.2 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 inte rface of the ARM9TDMI. four examples of this are given below. 7.2.1 example 1 in this first 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. therefore, the add instruction has to delay entering the exec ute stage of the pipeline by one cycle. the behavior on the instruction memo ry interface is shown in figure 7-1. figure 7-1 single load interlock timing 7.2.2 example 2 in this second example, the fo llowing code sequence is executed: ldrb r0, [r1,#1] add r2, r0, r1
instruction cycle summary and interlocks 7-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a now, because a rotation must occur on the load ed data, there is a s econd interlock cycle. the behavior on the instruction memo ry interface is sh own in figure 7-2. figure 7-2 two cycle load interlock 7.2.3 example 3 in this third 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 interface are shown in figure 7-3 on page 7-7.
instruction cycle summary and interlocks arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 7-7 figure 7-3 ldm interlock 7.2.4 example 4 in the fourth example, the foll owing code sequence is executed: ldm r12,{r1-r3} add r4, r3, r1
instruction cycle summary and interlocks 7-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 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. beca use the add is dependent on r3, there must be a further cycle of interlock while r3 is loaded. the behavior on the instruction and data memory interface is shown in figure 7-4. figure 7-4 ldm dependent interlock
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-1 chapter 8 ARM9TDMI ac characteristics this chapter gives the timing diagrams and timing parameters for the ARM9TDMI: ? ARM9TDMI timing diagrams on page 8-2 ? ARM9TDMI timing parameters on page 8-14.
ARM9TDMI ac characteristics 8-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 8.1 ARM9TDMI timing diagrams figure 8-1 ARM9TDMI instruction memory interface output timing figure 8-2 ARM9TDMI instru ction address bus enable
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-3 figure 8-3 ARM9TDMI instruction memory interface input timing
ARM9TDMI ac characteristics 8-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 8-4 ARM9TDMI data memo ry interface output timing
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-5 figure 8-5 ARM9TDMI data address bus timing figure 8-6 ARM9TDMI data abort and dnmreq timing figure 8-7 ARM9TDMI data data bus timing
ARM9TDMI ac characteristics 8-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 8-8 ARM9TDMI data bus enable figure 8-9 ARM9TDMI misce llaneous signal timing
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-7 figure 8-10 ARM9TDMI coproces sor interface signal timing
ARM9TDMI ac characteristics 8-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 8-11 ARM9TDMI jtag output signals
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-9 figure 8-12 ARM9TDMI external boun dary scan chain output signals figure 8-13 ARM9TDMI sdoutbs to tdo relationship
ARM9TDMI ac characteristics 8-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 8-14 ARM9TDMI ntrst to rstclkbs relationship figure 8-15 ARM9TDMI jtag input signal timing
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-11 figure 8-16 ARM9TDMI gclk related debug output timings
ARM9TDMI ac characteristics 8-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a figure 8-17 ARM9TDMI tck related debug output timings figure 8-18 ARM9TDMI ntrst to dbgrqi relationship figure 8-19 ARM9TDMI edbgrq to dbgrqi relationship
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-13 figure 8-20 ARM9TDMI dbgen to output effects
ARM9TDMI ac characteristics 8-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a 8.2 ARM9TDMI timing parameters table 8-1 ARM9TDMI timing parameters timing parameter description t bigh bigend hold time from gclk falling t bigs bigend setup time to gclk falling t brst delay from ntrst falling to rstclkbs rising t brtd rstclkbs rising from tck falling t brth rstclkbs falling from tck rising t capf ecapclkbs / icapclkbs / pclkbs falling from tck rising t caph input hold time to tck falling (extest capture) t capr ecapclkbs / icapclkbs / pclkbs rising from tck falling t caps input setup time to tck falling (extest capture) t chsh chsd[1:0 ]/c hse[1:0] hold time from gclk falling t chss chsd[1:0] / chse[1:0] setup time to gclk falling t comd commtx / commrx output delay t comh commtx / commrx output hold time t dabe delay from dabe rising to da[31:0] / dntrans / dnm[4:0] / dmas[1:0] / dnrw / dlock driven valid t dabh dabort hold time from gclk falling t dabs dabort setup time to gclk falling t dabtd dnmreq delay from dabort t dabz delay from dabe falling to da[31:0] / dntrans / dnm[4:0] / dmas[1:0] / dnrw / dlock high impedance t dad da[31:0] delay from gclk rising t dah da[31:0] hold time from gclk rising t dbqh edbgrq input hold time from gclk falling t dbqs edbgrq input setup time to gclk falling
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-15 t dckd dbgack output delay t dckh dbgack output hold time t ddbe delay from ddbe rising to dd[31:0] (output) driven valid t ddbz delay from ddbe falling to dd[31:0] (output) high impedance t ddend dden delay from gclk falling t ddenh dden hold time from gclk falling t ddh dd[31:0] (input) hold time from gclk falling t ddod dd[31:0] (output) delay from gclk falling t ddoh dd[31:0] (output) hold time from gclk falling t dds dd[31:0] (input) setup time to gclk falling t dgid dbgrqi output delay from tck falling t dgih dbgrqi output hold time from tck falling t dih tdi and tms hold time from tck rising t dis tdi and tms setup time to tck rising t dlkd dlock delay from gclk rising t dlkh dlock hold time from gclk rising t dmqd dnmreq delay from gclk rising t dmqh dnmreq hold time from gclk rising t dmrd dmore delay from gclk rising t dmrh dmore hold time from gclk rising t dmsd dmas[1:0] delay from gclk rising t dmsh dmas[1:0] hold time from gclk rising t dnmd dnm[4:0] delay from gclk rising t dnmh dnm[4:0] hold time from gclk rising table 8-1 ARM9TDMI timing parameters (continued) timing parameter description
ARM9TDMI ac characteristics 8-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a t dqen dbgrqi falling delay from dbgen falling t dqir ntrst falling to dbgrqi falling delay t drbsd driveoutbs delay from tck falling t drbsh driveoutbs hold time from tck falling t drwd dnrw delay from gclk rising t drwh dnrw hold time from gclk rising t dsqd dseq delay from gclk rising t dsqh dseq hold time from gclk rising t dtrsd dntrans delay from gclk rising t dtrsh dntrans hold time from gclk rising t dwph dewpt hold time from gclk rising t dwps dewpt setup time to gclk rising t edqd dbgrqi output delay from edbgrq changing t edqh dbgrqi output hold time from edbgrq changing t exth extern0/extern1 input hold time from gclk falling t exts extern0/extern1 input set up time to gclk falling t gclkh minimum gclk high period t gclkl minimum gclk low period t gekf gclk falling to eclk falling delay t gekr gclk rising to eclk rising delay t hivh hivecs hold time from gclk rising t hivs hivecs setup time to gclk rising t iabe delay from iabe rising to ia[31:1] / inm[4:0] / intrans driven valid t iabh iabort hold time from gclk falling table 8-1 ARM9TDMI timing parameters (continued) timing parameter description
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-17 t iabs iabort setup time to gclk falling t iabz delay from iabe falling to ia[31:1] / inm[4:0] / intrans high impedance t iad ia[31:1] delay from gclk rising t iah ia[31:1] hold time from gclk rising t ibkh iebkpt hold time from gclk rising t ibks iebkpt setup time to gclk rising t idh id[31:0] hold time from gclk falling t ids id[31:0] setup time to gclk falling t imqd inmreq delay from gclk rising t imqh inmreq hold time from gclk rising t inmd inm[4:0] delay from gclk rising t inmh inm[4:0] hold time from gclk rising t inth interrupt (nfiq / nirq ) hold time from gclk falling t ints interrupt ( nfiq / nirq ) setup time to gclk falling t inxd instrexec output delay t inxh instrexec output hold time t irsd ireg[3:0] / screg[4:0] output delay from tck falling t irsh ireg[3:0] / screg[4:0] hold time from tck falling t isqd iseq delay from gclk rising t isqh iseq hold time from gclk rising t isyh isync hold time from gclk falling t isys isync setup time to gclk falling t itbd itbit delay from gclk rising t itbh itbit hold time from gclk rising table 8-1 ARM9TDMI timing parameters (continued) timing parameter description
ARM9TDMI ac characteristics 8-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a t itrsd intrans delay from gclk rising t itrsh intrans hold time from gclk rising t ltcd latecancel delay from gclk falling t ltch latecancel hold time from gclk falling t nwh nwait hold time from gclk rising t nws nwait setup time to gclk falling t pasd pass output delay from gclk rising t pash pass hold time from gclk rising t rg0d rangeout0 output delay t rg0h rangeout0 output hold time t rg1d rangeout1 output delay t rg1h rangeout1 output hold time t rgen rangeout0 / rangeout1 falling delay from dbgen falling t rsth nreset hold time from gclk rising t rsts nreset setup time to gclk rising t sdnd sdin output delay from tck falling t sdnh sdin hold time from tck falling t shkf shclk1bs / shclk2bs falling from tck changing t shkr shclk1bs / shclk2bs rising from tck changing t tapidh tapid[31:0] hold time to tck falling t tapids tapid[31:0] setup time to tck falling t tbe delay from tbe rising, to outputs driven valid t tbz delay from tbe falling, to out puts high impedance t tckf tck1 / tck2 falling from tck changing table 8-1 ARM9TDMI timing parameters (continued) timing parameter description
ARM9TDMI ac characteristics arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. 8-19 t tckh minimum tck high period t tckl minimum tck low period t tckr tck1 / tck2 rising from tck changing t tdod tdo output delay from tck falling t tdoh tdo hold time from tck falling t tdsd tdo delay from sdoutbs changing t tdsh tdo hold time from sdoutbs changing t tekf tck falling to eclk falling delay t tekr tck rising to eclk rising delay t toed ntdoen output delay from tck falling t toeh ntdoen hold time from tck falling t tpmd tapsm[3:0] output delay from tck falling t tpmh tapsm[3:0] hold time from tck falling t unis unien input setup time to gclk falling t unih unien input hold time to gclk falling table 8-1 ARM9TDMI timing parameters (continued) timing parameter description
ARM9TDMI ac characteristics 8-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. a-1 appendix a ARM9TDMI signal descriptions this chapter lists and desc ribes the ARM9TDMI signals: ? instruction memory interface signals on page a-2 ? data memory interface signals on page a-3 ? coprocessor interface signals on page a-5 ? jtag and tap controller signals on page a-6 ? debug signals on page a-8 ? miscellaneous signals on page a-10.
ARM9TDMI signal descriptions a-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a a.1 instruction memory interface signals table a-1 instruction memory interface signals name direction description ia[31:1] output instruction address bus. this is the proc essor instruction address bus. it changes when gclk is high. iabe input instruction address bus enable. this is an i nput which, when low, it puts the instruction address bus, ia[31:1] , drivers into a high impedance state. this signal has the same effect on intrans and inm[4:0] . if unien is high this signal is ignored. iabort input instruction abort. this is an input which allo ws the memory system to tell the processor that the requested instruction memo ry access is not allowed. id[31:0] input instruction data bus. this input bus should be driven with the requ ested instruction data before the end of phase 2 of gclk . inm[4:0] output instruction mode. these signals indicate the current mode of th e processor and are in the same form as the mode bits in the cpsr. inmreq output not instruction memory request. if low at the end of gclk phase 2, the processor requires an instruction memory access during the following cycle. intrans output not memory translate. when low, the processor is in user mode. when high, the processor is in a privileged mode. iseq output instruction sequential a ddress. if high at the end of gclk phase 2, any instruction memory access during the foll owing cycle is sequential from the last instruction memory access. itbit output instruction thumb bit. when high, the processor is in thumb state. when low, the processor is in arm state.
ARM9TDMI signal descriptions arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. a-3 a.2 data memory interface signals table a-2 data memory interface signals name direction description da[31:0] output data address bus. this is the proc essor data address bu s. it changes when gclk is high. dabe input data address bus enable. when low, this input puts the data address bus, da[31:0] , drivers into a high impedance state. this signal has the same effect on dntrans , dlock , dmas[1:0] , dnrw , and dnm[4:0] . if unien is high this signal is ignored. dabort input data abort. this input allows the memory system to tell the processor that the requested data memory access is not allowed. dd[31:0] output data output bus. this output bus is used to transfer write data between the processor and external memory. the output data will become valid during phase 1 and remain valid through gclk phase 2. if unien is low, this is a tristate output bu s and is only driven during write cycles. if unien is high, this bus is always driven. ddbe input data data bus enab le. this is an input which, wh en low, puts the data data bus dd[31:0] into a high impedance state. if unien is high this signal is ignored. dden output data data bus output enabled. this signal indicates when the processor is performing a write transfer on the data data bus, dd[31:0] . ddin[31:0] input data input bus. this input is used to tr ansfer load data between external memory and the processor. it should be driven wi th the requested data by the end of gclk phase 2. dlock output data lock. if high at the end of gclk phase 2, any data memory access in the following cycle is locked, and the memory controller must wait until dlock goes low before allowing another device to access memory. dmas[1:0] output data memory access size. these outputs encode the size of a data memory access in the following cycle. a word access is encode d as 10 (binary), a halfword access as 01, and a byte access as 00. the encoding 11 is reserved. dmore output data more. if high at the end of gclk phase 2, the data memory access in the following cycle will be di rectly followed by a sequential data memory access. dnm[4:0] output data mode. the processor mode within which the data memory access should be performed. note that the data memory access mode may differ from the current processor mode.
ARM9TDMI signal descriptions a-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a dnmreq output not data memory request. if low at the end of gclk phase 2, the processor requires a data memory access in the following cycle. dnrw output data not read, write. if low at the end of phase 2, any data memory access in the following cycle is a read. if high, it is a write. dntrans output data not memory translate. if low, the next data memory acce ss is to be performed as a user mode access, if high the data memory access is to performed as a privileged mode access. note that the data memory access mode may differ from the current processor mode. dseq output data sequential address. if high at the end of phase 2, any data memory access in the next cycle is sequential from the current data memory access. table a-2 data memory interface signals (continued) name direction description
ARM9TDMI signal descriptions arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. a-5 a.3 coprocessor in terface signals for further information on the coprocessor interface refer to chapter 4 ARM9TDMI coprocessor interface . table a-3 coprocessor interface signals name direction description chsd[1:0] input coprocessor handshake decode. the handsha ke signals from the decode stage of the coprocessors pipeline follower. note, if no coprocessor is present in the system, chsd[1] should be tied high, and chsd[0] should be tied low. chse[1:0] input coprocessor handshake execute. the hands hake signals from the execute stage of the coprocessors pipeline follower. note, if no coprocessor is present in the system, chse[1] should be tied high, and chse[0] should be tied low. latecancel output coprocessor late cancel. if high during the first memory cycle of a coprocessor instruction?s execution, the coprocessor should cancel th e instruction without having updated its state. pass output coprocessor pass . this signal indicates that there is a coprocessor instruction in the execute stage of the pipeline , and it should be executed.
ARM9TDMI signal descriptions a-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a a.4 jtag and tap controller signals table a-4 jtag and tap controller signals name direction description driveoutbs output boundary scan cell enable. this signal is used to control the multiplexers in the scan cells of an external boundary scan chain. th is signal changes in the update-ir state when scan chain 3 is selected and either the intest, extest, clamp or clampz instruction is loaded. when an external boundary scan chain is not connected, this output should be left unconnected. ecapclkbs output extest capture clock fo r 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 is used to capture the chip level inputs during extest. when an external bounda ry scan chain is not connected, this output should be left unconnected. icapclkbs output intest capture clock. this is a tck2 wide pulse generated wh en the tap controller state machine is in the capture-dr state, the current instruction is intest and scan chain 3 is selected. th is signal is used to capture the chip level outputs during intest. when an external boundary scan chain is not connected, this out put should be left unconnected. ir[3:0] output tap controller instruction register. thes e four bits reflect the current instruction loaded into the tap controller instruction re gister. 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 cloc k. when an external boundary scan chain is not connected, this output should be left unconnected. rstclkbs output boundary scan reset clock. this signal de notes that either the tap controller state machine is in the reset state, or that ntrst has been asserted. this may be used to reset external boundary scan cells. screg[4:0] output scan chain register. these four bits reflect the id number of the scan chain currently selected by the tap controller. thes e 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 sh ould be set up to the rising edge of tck . when an external boundary scan chain is not conne cted, this input should be tied low.
ARM9TDMI signal descriptions arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. a-7 shclk1bs output boundary scan shift clock phase 1. this control signal is provided to ease the connection of an external boundary scan chain. shclk1bs is used to clock the master half of the external scan cells. when the state machine is in shift-dr state, 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. when an external boundary scan chain is not connected, th is output must be left unconnected. shclk2bs output boundary scan shift clock phase 2. this control signal is provided to ease the connection of an external boundary scan chain. shclk2bs is used to clock the slave half of the external scan cells. when the state machine is in shift-dr state, 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. when an external boundary scan chain is not connected, th is output must be left unconnected. tapid[31:0] input tap identification. the value on this bus will be captured when using the idcode instruction on the tap controller state machine. 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 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. ck2 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, the jtag serial input. tdo output test data output, the jtag serial output. ntdoen output not tdo enable. when low, this signal denotes that serial data is being driven out on the tdo output. the ntdoen signal would normally be us ed as an output enable for a tdo pin in a packaged part. tms input test mode select. tms selects to which state the tap controller state machine should change. ntrst input not test reset. active-low reset signal fo r the boundary scan logic. this pin must be pulsed or driven low after power up to ac hieve normal device ope ration, in addition to the normal de vice reset ( nreset ). table a-4 jtag and tap cont roller signals (continued) name direction description
ARM9TDMI signal descriptions a-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a a.5 debug signals table a-5 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 ARM9TDMI. commtx output communications channel transmit. when high, this signal denotes that the comms channel transmit buffer is empty and the ar m9tdmi can write new data to the comms channel. dbgack output debug acknowledge. when high, this si gnal indicates the ARM9TDMI is in debug state. dbgen input debug enable. this input signal allows th e debug features of the ARM9TDMI to be disabled. this signal should be low onl y when debugging wi ll not be required. dbgrqi output internal debug request. this signal re presents the debug request signal which is presented to the processor core. this is a combination of edbgrq , as presented to the ARM9TDMI, and bit 1 of the debug control register. dewpt input data watchpoint. this is an input which allows external ha rdware to halt execution of the processor for debug purposes. if high at th e end of phase 1 foll owing a data memory request cycle, it will cause the ARM9TDMI to enter debug state. edbgrq input external debug request. when driven high, this causes the processor to enter debug state after execution of the current instruction completes. extern0 input external input 0. this is an input to wa tchpoint unit 0 of the em beddedice macrocell in the processor which allows br eakpoints/watchpoints to be dependent on an external condition. extern1 input external input 1. this is an input to wa tchpoint unit 1 of the em beddedice macrocell in the processor which allows br eakpoints/watchpoints to be dependent on an external condition. iebkpt input instruction breakpoint. this is an input wh ich allows a external hardware to halt the execution of the processor for debug purpos es. if high at the end of phase 1 following an instruction memory request cycle, it ca uses the ARM9TDMI to enter debug state if the relevant instruction reaches the ex ecute stage of the processor pipeline. instrexec output instruction executed . indicates that in the previous cy cle the instruction in the execute stage of the pipeline passed its condition codes, and was executed.
ARM9TDMI signal descriptions arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. a-9 rangeout0 output embeddedice rangeout 0. this signal indicates that the embeddedice macrocell watchpoint unit 0 has ma tched the conditions currently present on the address, data and control buses. this signal is independent of the state of the watchpoint?s enable control bit. rangeout1 output embeddedice rangeout 1. this signal indicates that the embeddedice macrocell watchpoint unit 1 has ma tched the conditions currently present on the address, data and control buses. this signal is independent of the state of the watchpoint?s enable control bit. tbe input test bus enable. when driven low, tbe forces the following signals to high impedance: dd[31:0] da[31:0] dlock dmas[1:0] dnm[4:0] dnrw dntrans dmore dnmreq dseq ia[31:0] inm[4:0] intrans inmreq iseq itbit latecancel pass. under normal operating conditions, tbe should be held high at all times. if unien is high, this signal is ignored. table a-5 debug signals (continued) name direction description
ARM9TDMI signal descriptions a-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a a.6 miscellaneous signals table a-6 miscellaneous signals name direction description bigend input big-endian configuration. when this input is high, the ARM9TDMI processor treats bytes in memory as being in big-endian format. when it is low, memory is treated as little-endian. eclk output external clock. the clock by which the ARM9TDMI is currentl y being clocked. this clock will reflect any wait states applied by nwait , and once debug state has been entered by the debug clock. nfiq input not fast in terrupt request. this input causes the core to be interrupted if taken low, and if the appropriate enable in the processor is active. the signal is level-sensit ive and must be held low until a suitable response is received from the processor. the nfiq signal may be synchronous or asynchronous, depending on the state of isync. gclk input clock. this clock times all ARM9TDMI memory accesses (both data and instru ction), and internal operations. the clock has two dist inct phases?phase 1 in which gclk is low and phase 2 inwhich gclk is high. the clock may be stretched indefinitely in either phase to allow access to slow peripherals or memory. alternatively, nwait may be used with a free running gclk to stretch phase 2. hivecs input high vectors configuration. when low, the ARM9TDMI except ion vectors start at address 0x00000000 (hexadecimal). when high, the ARM9TDMI exception vectors start at address 0xffff0000 . nirq input not interrupt request. as nfiq , but with lower priority. may be taken low to interrupt the processor when theappropriate enable is active. the nirq signal may be synchronous or asynchronous,depending on the state of isync. isync input synchronous interrupts. when low, this input indicates that the nirq and nfiq inputs are to be synchronized by the processor. when high it disables this synchronization for input s that are already synchronous. nreset input not reset. this is a level-sensitiv e input signal which is used to star t the processor from a known address. the ARM9TDMI processor asynchronously enters reset when nreset goes low.
ARM9TDMI signal descriptions arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. a-11 nwait input not wait. when a memory request cannot be processed in a single cycle, the ARM9TDMI can be made to wait for a number of gclk cycles by driving nwait low. internally, the inverse of nwait is ored with gclk , and must only change when gclk is high. if nwait is not used, it must be tied high. unien input unidirectional enable. when high, all ARM9TDMI outputs are perman ently driven, (the state of iabe, dabe, ddbe and tbe is ignored). the ddin[31:0] and dd[31:0] buses form a unidirectional data bus. when low, outputs can go tristate and the dd[31:0] bus is only driven during write cycles. if dd[31:0] and ddin[31:0] are wired together, they fo rm a bidirecti onal data bus. table a-6 miscellaneou s signals (continued) name direction description
ARM9TDMI signal descriptions a-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a
arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. index-1 index a about testing 6-2 arm instruction set 1-2 arm7tdmi code compatibility 2-2 b bidirectional data data bus 3-11 bigend 3-12 boundary scan chain controlling external 5-22 boundary scan interface 5-13 breakpoints 5-5 exceptions 5-6 instruction boundary 5-6 prefetch abort 5-6 timing 5-6 busy-wait 4-6, 4-17 abandoned 4-17 interrupted 4-17 c clocks core 5-24 dclk 5-24 gclk 5-24 internally tck generated clock 5-24 memory clock 5-24 switching 5-24 switching during debug 5-25 switching during test 5-26 system reset 5-26 conventions numerical xiv signal naming xiii timing diagram xiii typographical xii coprocessor interface block 4-2 coprocessor handshake signals 4-6 encoding 4-7 states 4-6 coprocessor instructions busy-wait 4-6 cdp 4-13 coprocessor 15 mcrs 4-19 during busy-wait 4-17 during interrupts 4-17 interlocked mcr 4-11 ldc/stc 4-3 mcr/mrc 4-9 privileged instructions 4-15 privileged modes 4-15 types supported 4-2 core state determining 5-27 d data abort handler 2-2 model 2-2 data interface accessing instruction memory 3-2
index index-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a data transfers 3-8 data transfer 3-8 aborted 3-8 access timings 3-9 coprocessor transfers 3-9 cycle encoding 3-8 data abort vector 3-8 data cycle 3-8 direction 3-8 endian configuration 3-12 endian effects 3-12 memory access sizes 3-12 size 3-9 size encoding 3-9 16-bit 3-12 32-bit 3-12 8-bit 3-12 dbgack 5-30 debug clock switching 5-25 communications channel 5-47 debug scan chain 5-21 entered from arm state 5-27 entered from thumb state 5-27 hardware extensions 5-2, 5-4 instruction register 5-13 public instructions 5-13 pullup resistors 5-13 reset 5-13 scan chains 5-20 speed 5-28 state-machine controller 5-13 debug host 5-3 debug interface signals 5-5 standard 5-2 tap controller states 5-2 debug request 5-10 debug state 5-2, 5-28 actions of ARM9TDMI 3-3, 5-10 breakpoints 5-5 exiting 5-30 watchpoints 5-7 debug system 5-3 e embeddedice 5-5, 5-36 accessing hardware registers 5-22 control registers 5-39 debug control register 5-42 debug status register 5-42 functionality 5-36 hardware 5-36 register map 5-36 single stepping 5-46 vector catch register 5-43 vector catching 5-45 embeddedice macrocell 5-1, 5-2, 5-10 embeddedice watchpoint units debugging 5-11 programming 5-11 testing 5-11 endian effects data transfer 3-12 instruction fetches 3-7 external scan chains 5-20 f five-stage pipeline 2-4 h halting data interface 3-3 instruction interface 3-3 processor 3-3 i implementation options 2-2 instruction cycle counts and bus activity 7-2 data bus instruction times 7-4 multiplier cycle counts 7-4 times 7-2 instruction fetch aborted 3-5 endian effects 3-7 in arm state 3-7 in thumb state 3-7 prefetch abort vector 3-5 timing 3-5 16-bit 3-7 32-bit 3-7 instruction interface accessing data memory 3-3 instruction address bus 3-5 instruction fetch timing 3-5 instruction set arm 1-2 thumb 1-2 instruction set extens ion spaces 2-3 interlocks 2-4, 7-5 ldm dependent timing 7-8 ldm timing 7-6 single load timing 7-5 two cycle load timing 7-6 j jtag interface 5-11, 5-13, 5-26 jtag state machine 5-12 l latecancel 4-6 m memory accesses 3-2 coprocessor transfer 3-2 internal 3-2 non-sequential 3-2 sequential 3-2 memory configurations big-endian 3-2 little-endian 3-2 selecting 3-2 memory interface accesses 3-2 addressing 3-2 data interface 3-1 instruction interface 3-1 performance 3-2 reset behavior 3-13
index arm ddi 0180a copyright ? 2000 arm limited. all rights reserved. index-3 n nreset 3-13 numerical conventions xiv nwait 3-3 p pass 4-5 pc return address calculations 5-35 pipeline 2-4 arm 4-2 coprocessor 4-2 interlock 4-11 interlocks 7-5 pipeline follower 4-2 timing 2-4 processor halting 3-3 processor core diagram 1-3 implementation 1-2 processor state determining 5-27 programmer?s model 2-1 protocol converter 5-3 public instructions within debug bypass 5-15 clamp 5-16 clampz 5-17 extest 5-14 highz 5-16 idcode 5-15 intest 5-15 scan_n 5-14 r reset memory interface 3-13 s scan chains 5-11, 5-20 external 5-20 scan chain 0 5-20 scan chain 0 bit order 6-1, 6-3 scan chain 1 5-21 scan chain 2 5-22 scan chain 3 5-22 serial test and debug 5-12 signal naming conventions xiii signals coprocessor interface a-5 data memory interface a-3 debug a-8 instruction memory interface a-2 jtag and tap controller a-6 miscellaneous a-10 single stepping 5-46 sysspeed bit 5-29 system speed instructions 5-29 system state determining 5-28 scan chain 1 5-28 t tap controller 5-11, 5-12, 5-20 tap state machine 5-24 test clock switching 5-26 system reset 5-26 test data registers 5-18 ARM9TDMI device id code register 5-18 bypass register 5-18 instruction register 5-19 scan chain select register 5-19 scan chains 5-20 testing 6-1 extest 6-2 parallel and serial 6-2 scan chain 0 bit order 6-3 test patterns 6-2 thumb instruction set 1-2 timing diagrams 8-2 parameters 8-14 timing diagram conventions xiii typographical conventions xii u unidirectional write data data bus 3-11 v vector catching 5-45 w wait states 3-3 watchpoints 5-7 exceptions 5-10 timing 5-7
index index-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0180a

▲Up To Search▲

Price & Availability of ARM9TDMI

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