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

Datasheet File OCR Text:

? ARM7TDMI microprocessor core order number c14060 technical manual november 1998 arm.book page i wednesday, november 25, 1998 1:11 pm
ii this document contains proprietary information of lsi logic corporation. the information contained herein is not to be used by or disclosed to third parties without the express written permission of an of?cer of lsi logic corporation. document db14-000058-02, first edition (november 1998) this document describes revision a of lsi logic corporations arm7 tdmi microprocessor and will remain the of?cial reference source for all revisions of this product until rescinded by an update. to receive product literature, call us at 1.800.574.4286 (u.s. and canada); +32.11.300.531 (europe); 408.433.7700 (outside u.s., canada, and europe) and ask for department jds; or visit us at http://www.lsilogic.com. lsi logic corporation reserves the right to make changes to any products herein at any time without notice. lsi logic does not assume any responsibility or liability arising out of the application or use of any product described herein, except as expressly agreed to in writing by lsi logic; nor does the purchase or use of a product from lsi logic convey a license under any patent rights, copyrights, trademark rights, or any other of the intellectual property rights of lsi logic or third parties. copyright ? 1996C1998 by lsi logic corporation. all rights reserved. trademark acknowledgment the lsi logic logo design, coreware, gigablaze, and g10 are registered trademarks and flexstream, and right-first-time are trademarks of lsi logic corporation. arm is a registered trademark, the arm powered logo, and icebreaker are trademarks of advanced risc machines ltd., used under license. all other brand and product names may be trademarks of their respective companies. arm.book page ii wednesday, november 25, 1998 1:11 pm
contents iii contents preface chapter 1 introduction 1.1 introduction 1-1 1.1.1 general information 1-1 1.1.2 lsi logics ARM7TDMI implementation 1-2 1.2 ARM7TDMI architecture 1-2 1.2.1 the thumb concept 1-3 1.2.2 thumb advantages 1-3 1.3 coreware ? program 1-6 chapter 2 signal descriptions 2.1 core logic diagram 2-1 2.2 clock signals 2-3 2.3 interrupt signals 2-3 2.4 bus control interface 2-4 2.5 debug interface 2-7 2.6 boundary scan control interface 2-9 2.7 boundary scan interface 2-11 2.8 processor interface 2-12 2.9 memory interface 2-12 2.10 coprocessor interface 2-15 2.11 test signals 2-16 arm.book page iii wednesday, november 25, 1998 1:11 pm
iv contents chapter 3 programmers model 3.1 processor operating states 3-1 3.2 switching state 3-2 3.2.1 entering thumb state 3-2 3.2.2 entering arm state 3-2 3.3 memory formats 3-2 3.3.1 big endian format 3-2 3.3.2 little endian format 3-3 3.4 instruction length 3-3 3.5 data types 3-4 3.6 operating modes 3-4 3.7 registers 3-4 3.7.1 the arm state register set 3-5 3.7.2 the thumb state register set 3-6 3.7.3 the relationship between arm and thumb state registers 3-7 3.7.4 accessing high registers in thumb state 3-8 3.8 program status registers 3-9 3.8.1 the condition code flags 3-9 3.8.2 reserved bits 3-10 3.8.3 the control bits 3-10 3.9 exceptions 3-11 3.9.1 action on entering an exception 3-11 3.9.2 action on leaving an exception 3-12 3.9.3 exception entry/exit summary 3-13 3.9.4 fast interrupt request (fiq) 3-13 3.9.5 interrupt request (irq) 3-14 3.9.6 abort 3-14 3.9.7 software interrupt (swi) 3-15 3.9.8 unde?ned instruction (udef) 3-16 3.9.9 exception vectors 3-16 3.9.10 exception priorities 3-16 3.10 interrupt latencies 3-17 3.11 reset 3-18 3.12 pipeline architecture 3-18 arm.book page iv wednesday, november 25, 1998 1:11 pm
contents v chapter 4 arm instruction set summary 4.1 instruction set summary 4-1 4.2 format summary 4-3 4.3 instruction condition field 4-4 4.4 instruction set examples 4-5 4.4.1 using the conditional instructions 4-6 4.4.2 pseudo-random binary sequence generator 4-8 4.4.3 multiplication by constant using the barrel shifter 4-8 4.4.4 loading a word from an unknown alignment 4-10 chapter 5 thumb instruction set summary 5.1 instruction set summary 5-1 5.1.1 instruction cycle time 5-3 5.2 format summary 5-3 5.3 instruction set examples 5-4 5.3.1 multiplication by a constant using shifts and adds 5-4 5.3.2 general purpose signed divide 5-5 5.3.3 division by a constant 5-8 chapter 6 memory interface 6.1 overview 6-1 6.2 cycle types 6-2 6.3 address timing 6-4 6.4 data transfer size 6-7 6.5 instruction fetch 6-8 6.6 memory management 6-10 6.7 locked operations 6-10 6.8 stretching access times 6-11 6.9 ARM7TDMI data bus 6-11 6.10 external data bus 6-13 6.10.1 the unidirectional data bus 6-14 6.10.2 bidirectional data bus 6-15 6.10.3 example system: the ARM7TDMI test chip 6-18 arm.book page v wednesday, november 25, 1998 1:11 pm
vi contents chapter 7 coprocessor interface 7.1 overview 7-1 7.2 interface signals 7-1 7.2.1 coprocessor present/absent 7-2 7.2.2 busy (waiting) 7-2 7.2.3 pipeline following 7-3 7.2.4 data transfer cycles 7-3 7.3 register transfer cycle 7-3 7.4 privileged instructions 7-4 7.5 idempotency 7-4 7.6 unde?ned instructions 7-5 chapter 8 debug interface 8.1 overview 8-1 8.2 debug systems 8-2 8.3 debug interface signals 8-4 8.3.1 entry into debug state 8-4 8.4 scan chains and jtag interface 8-7 8.4.1 scan limitations 8-8 8.4.2 the jtag state machine 8-9 8.5 reset 8-11 8.6 pull-up resistors 8-11 8.7 instruction register 8-11 8.8 public instructions 8-12 8.8.1 extest (0b0000) 8-12 8.8.2 scan_n (0b0010) 8-13 8.8.3 intest (0b1100) 8-13 8.8.4 idcode (0b1110) 8-14 8.8.5 bypass (0b1111) 8-14 8.8.6 clamp (0b0101) 8-14 8.8.7 highz (0b0111) 8-15 8.8.8 clampz (0b1001) 8-15 8.8.9 sample/preload (0b0011) 8-16 8.8.10 restart (0b0100) 8-16 arm.book page vi wednesday, november 25, 1998 1:11 pm
contents vii 8.9 test data registers 8-16 8.9.1 bypass register 8-16 8.9.2 ARM7TDMI device identi?cation (id) code register 8-16 8.9.3 instruction register 8-17 8.9.4 scan chain select register 8-18 8.9.5 scan chains 0, 1, and 2 8-19 8.10 ARM7TDMI core clocks 8-24 8.10.1 clock switch during debug 8-24 8.11 determining the core and system state 8-25 8.11.1 determining the cores state 8-25 8.11.2 determining system state 8-27 8.11.3 exit from debug state 8-28 8.12 pc behavior during debug 8-30 8.12.1 breakpoint 8-30 8.12.2 watchpoints 8-30 8.12.3 watchpoint with another exception 8-31 8.12.4 debug request 8-31 8.12.5 system speed access 8-32 8.12.6 summary of return address calculations 8-32 8.13 priorities/exceptions 8-33 8.13.1 breakpoint with prefetch abort 8-33 8.13.2 interrupts 8-33 8.13.3 data aborts 8-34 8.14 scan interface timing 8-34 8.15 debug timing 8-38 chapter 9 embeddedice macrocell 9.1 overview 9-1 9.2 watchpoint registers 9-3 9.2.1 programming and reading watchpoint registers 9-4 9.2.2 using the mask registers 9-5 9.2.3 control registers 9-6 9.3 programming breakpoints 9-8 9.3.1 hardware breakpoints 9-8 9.3.2 software breakpoints 9-9 9.4 programming watchpoints 9-10 arm.book page vii wednesday, november 25, 1998 1:11 pm
viii contents 9.5 debug control register 9-11 9.6 debug status register 9-12 9.7 coupling breakpoints and watchpoints 9-14 9.7.1 chainout signal 9-15 9.7.2 rangeout signal 9-16 9.8 disabling embeddedice macrocell 9-17 9.9 embeddedice macrocell timing 9-17 9.10 programming restriction 9-17 9.11 debug communication channel 9-18 9.11.1 debug communications control registers 9-18 9.11.2 communication through the communications channel 9-19 chapter 10 instruction cycle operations 10.1 introduction 10-2 10.2 branch and branch with link 10-2 10.3 thumb branch with link 10-3 10.4 branch and exchange (bx) 10-4 10.5 data operations 10-5 10.6 multiply and multiply accumulate 10-7 10.7 load register 10-9 10.8 store register 10-10 10.9 load multiple registers 10-10 10.10 store multiple registers 10-12 10.11 data swap 10-13 10.12 software interrupt and exception entry 10-14 10.13 coprocessor data operation 10-15 10.14 coprocessor data transfer (memory to coprocessor) 10-16 10.15 coprocessor data transfer (from coprocessor to memory) 10-18 10.16 coprocessor register transfer (load from coprocessor) 10-20 10.17 coprocessor register transfer (store to coprocessor) 10-21 10.18 unde?ned instructions and coprocessor absent 10-22 10.19 unexecuted instructions 10-23 10.20 instruction speed summary 10-23 arm.book page viii wednesday, november 25, 1998 1:11 pm
contents ix chapter 11 production test 11.1 core testing strategy overview 11-1 11.2 scan test pin de?nitions 11-2 11.3 full-scan production testing 11-2 11.3.1 register file testing 11-3 chapter 12 speci?cations appendix a ARM7TDMI changes customer feedback figures 1.1 processor core diagram 1-4 1.2 ARM7TDMI core diagram 1-5 2.1 ARM7TDMI logic diagram 2-2 3.1 big endian addresses of bytes within words 3-3 3.2 little endian addresses of bytes within words 3-3 3.3 register organization in arm state 3-6 3.4 register organization in thumb state 3-7 3.5 mapping of thumb state registers onto arm state registers 3-8 3.6 program status register format 3-9 3.7 ARM7TDMI pipeline 3-18 3.8 pipeline best case example 3-19 3.9 pipeline branch example 3-20 3.10 pipeline interrupt example 3-21 3.11 pipeline data memory access example 3-22 4.1 arm instruction set formats 4-3 5.1 thumb instruction set formats 5-4 6.1 arm memory cycle timing 6-3 6.2 memory cycle optimization 6-4 6.3 ARM7TDMI depipelined addresses 6-5 6.4 ARM7TDMI pipelined addresses 6-5 6.5 typical system timing 6-6 arm.book page ix wednesday, november 25, 1998 1:11 pm
x contents 6.6 sram compatible address timing 6-7 6.7 decoding byte accesses to memory 6-9 6.8 memory access 6-12 6.9 two cycle memory access 6-13 6.10 ARM7TDMI external bus arrangement 6-13 6.11 bidirectional bus timing 6-14 6.12 unidirectional bus timing 6-14 6.13 external connection of unidirectional buses 6-15 6.14 data write bus cycle 6-16 6.15 ARM7TDMI data bus control circuit 6-18 6.16 the ARM7TDMI test chip data bus circuit 6-19 6.17 data bus control signal timing 6-20 8.1 typical debug system 8-3 8.2 debug state entry 8-5 8.3 ARM7TDMI scan chain arrangement 8-9 8.4 test access port (tap) controller state transitions 8-10 8.5 id register format 8-17 8.6 input scan cell 8-20 8.7 clock switching on entry to debug state 8-24 8.8 debug exit sequence 8-29 8.9 scan general timing 8-34 9.1 embeddedice block diagram 9-2 9.2 embeddedice macrocell block diagram 9-5 9.3 watchpoint control value and mask format 9-6 9.4 debug control register format 9-11 9.5 debug status register format 9-12 9.6 structure of tbit, nmreq, dbgack, dbgrq and intdis bits 9-14 9.7 debug communications control register 9-18 11.1 register file testing scan path 11-3 arm.book page x wednesday, november 25, 1998 1:11 pm
contents xi tables 3.1 mode bit states 3-11 3.2 exception entry/exit 3-13 3.3 exception vectors 3-16 4.1 arm instruction set 4-1 4.2 condition code summary 4-5 5.1 thumb instruction set 5-1 6.1 memory cycle types 6-3 6.2 endian con?guration effect on instruction position 6-9 6.3 output enable control summary 6-17 8.1 public instructions 8-12 8.2 scan chain number allocation 8-19 8.3 ARM7TDMI scan interface timing 8-35 8.4 scan chain 0 signal order 8-36 8.5 ARM7TDMI debug interface timing 8-38 9.1 function and mapping of embeddedice registers 9-3 9.2 ifen signal control 9-12 10.1 branch instruction cycle operations 10-3 10.2 thumb long branch with link 10-4 10.3 branch and exchange instruction cycle operations 10-5 10.4 data operation instruction cycle operations 10-6 10.5 multiply instruction cycle operations 10-7 10.6 multiply accumulate instruction cycle operations 10-7 10.7 multiply long instruction cycle operation 10-8 10.8 multiply accumulate long instruction cycle operation 10-8 10.9 load register instruction cycle operations 10-9 10.10 store register instruction cycle operations 10-10 10.11 load multiple registers instruction cycle operations 10-11 10.12 store multiple registers instruction cycle operations 10-12 10.13 data swap instruction cycle operations 10-14 10.14 software interrupt instruction cycle operations 10-15 10.15 coprocessor data operation instruction cycle operations 10-16 10.16 coprocessor data transfer instruction cycle operations 10-17 arm.book page xi wednesday, november 25, 1998 1:11 pm
xii contents 10.17 coprocessor data transfer instruction cycle operations 10-19 10.18 coprocessor register transfer (load from coprocessor) 10-21 10.19 coprocessor register transfer (store to coprocessor) 10-22 10.20 unde?ned instruction cycle operations 10-23 10.21 unexecuted instruction cycle operations 10-23 10.22 arm instruction speed summary 10-24 11.1 scan test pins 11-2 arm.book page xii wednesday, november 25, 1998 1:11 pm
preface xiii preface this book is the primary reference and technical manual for the ARM7TDMI microprocessor core and contains a complete functional description for the core. the information in this manual applies to all process revisions of the core. speci?c technology-dependent values, such as electrical timing, can be found in the appropriate ARM7TDMI microprocessor core datasheet , which is available from lsi logic. audience this document was prepared for logic designers and applications engineers and is intended to provide an overview of lsi logics flexstream? system and to explain how to use the flexstream software in the initial stages of chip design. this document assumes that you have some familiarity with microprocessors and related support devices. the people who bene?t the most from this book are: engineers and managers who are evaluating the processor for possible use in a system engineers who are designing the processor into a system organization this document has the following chapters and appendixes: chapter 1, introduction chapter 2, signal descriptions chapter 3, programmers model chapter 4, arm instruction set summary arm.book page xiii wednesday, november 25, 1998 1:11 pm
xiv preface chapter 5, thumb instruction set summary chapter 6, memory interface chapter 7, coprocessor interface chapter 8, debug interface chapter 9, embeddedice macrocell chapter 10, instruction cycle operations chapter 11, production test chapter 12, speci?cations , see cw001007 ARM7TDMI microprocessor core datasheet appendix a, ARM7TDMI changes related publications ARM7TDMI data sheet, available from advanced risc machines ltd. as document no. arm ddi 0029e cw001004 ARM7TDMI microprocessor core datasheet , available from lsi logic. cw001007 ARM7TDMI microprocessor core datasheet , available from lsi logic. standard test access port and boundary-scan architecture, ieee standard 1149.1 - 1990. arm architectural reference manual , advanced risc machines ltd and prentice-hall. conventions used in this manual the ?rst time a word or phrase is de?ned in this manual, it is italicized. the word assert means to drive a signal true or active. the word deassert means to drive a signal false or inactive. hexadecimal numbers are indicated by the pre?x 0x for example, 0x32cf. binary numbers are indicated by the pre?x 0b for example, 0b0011.0010.1100.1111. arm.book page xiv wednesday, november 25, 1998 1:11 pm
preface xv signal names are shown in capital letters. active low signals are indicated by the pre?x n for example, nreset. the manual refers to a 32-bit quantity as a word , a 16-bit value as a halfword , and an 8-bit quantity as a byte . document version release date comments advance december 1996 initial release. preliminary january 1998 this document was derived from the arm document ARM7TDMI data sheet . appendix a, ARM7TDMI changes contains a list of the differences between lsi logic and arms documents. final november 1998 arm.book page xv wednesday, november 25, 1998 1:11 pm
xvi preface arm.book page xvi wednesday, november 25, 1998 1:11 pm
ARM7TDMI microprocessor core 1-1 chapter 1 introduction this chapter introduces the core architecture, and shows block, core, and functional diagrams. it contains the following sections: section 1.1, introduction, page 1-1 section 1.2, ARM7TDMI architecture, page 1-2 section 1.3, coreware ? program, page 1-6 1.1 introduction this section introduces the overall core capabilities and highlights the bene?cial features of lsi logics ARM7TDMI core implementation. 1.1.1 general information the ARM7TDMI architecture is a member of the advanced risc machines (arm) family of general purpose 32-bit microprocessors, which offer high performance for very low power consumption and price. the arm ? architecture is based on reduced instruction set computer (risc) principles, and the instruction set and related decode mechanism are much simpler than those of microprogrammed complex instruction set computers. this simplicity results in a high instruction throughput and impressive real time interrupt response from a small and cost effective chip. pipelining is employed so that all parts of the processing and memory systems can operate continuously. typically, while one instruction is being executed, its successor is being decoded, and a third instruction is being fetched from memory. arm.book page 1 wednesday, november 25, 1998 1:11 pm
1-2 introduction the arm memory interface has been designed to allow the performance potential to be realized without incurring high costs in the memory system. speed critical control signals are pipelined to allow system control functions to be implemented in standard low-power logic, and these control signals facilitate the exploitation of the fast local access modes offered by industry-standard dynamic rams. 1.1.2 lsi logics ARM7TDMI implementation the ARM7TDMI microprocessor core described in this manual is lsi logic's proprietary version of the ARM7TDMI microcontroller. lsi logic's implementation represents the world's ?rst synthesizable version of the ARM7TDMI. lsi logic has further optimized this synthesizable version to facilitate implementation of complex system-on- a-chip asics in lsi logic's state-of-the-art asic ?ows. the ARM7TDMI rtl (register-transfer level) version was developed in close conjunction with arm, ltd. ensuring 100% compatibility with the ARM7TDMI speci?cation. lsi logics core has identical functionality and external interfaces making both the hardware and software 100% compatible with the full custom cores presently available from all other ARM7TDMI licensees. lsi logic's rtl has been designed with single phase clocking and simpli?ed register schemes wherever possible. this greatly eases synthesis and timing analysis of the surrounding logic and thereby facilitates the design of high-quality products with a minimum time-to-market. the rtl has been synthesized and taken through place, route, and test insertion resulting in a hardmacro ready for a system-on- a-chip design. full scan test insertion provides high fault coverage while keeping test costs to a minimum. finally, to implement full scan, lsi logic has added eight additional test signals to the core (for a full description of these signals, see chapter 2, signal descriptions. ) 1.2 ARM7TDMI architecture the ARM7TDMI processor employs a unique architectural strategy known as thumb , which makes it ideally suited to high volume applications with memory restrictions, or applications where code density is an issue. arm.book page 2 wednesday, november 25, 1998 1:11 pm
ARM7TDMI architecture 1-3 1.2.1 the thumb concept the key idea behind thumb is that of a super-reduced instruction set. essentially, the ARM7TDMI processor has two instruction sets: standard 32-bit arm set a 16-bit thumb set the thumb sets 16-bit instruction length allows it to approach twice the density of standard arm code while retaining most of the arm processors performance advantage over a traditional 16-bit processor using 16-bit registers. this is possible because thumb code operates on the same 32-bit register set as arm code. thumb code is able to provide up to 65% of the size of arm code, and 160% of the performance of an equivalent arm processor connected to a 16-bit memory system. 1.2.2 thumb advantages thumb instructions operate with the standard arm register con?guration, allowing excellent interoperability between arm and thumb states. each 16-bit thumb instruction has a corresponding 32-bit arm instruction with the same effect on the processor model. the major advantage of a 32-bit (arm) architecture over a 16-bit architecture is its ability to manipulate 32-bit integers with single instructions, and to address a large address space ef?ciently. when processing 32-bit data, a 16-bit architecture will take at least two instructions to perform the same task as a single arm instruction. however, not all the code in a program will process 32-bit data (for example, code that performs character string handling), and some instructions, like branches, do not process any data at all. if a 16-bit architecture only has 16-bit instructions, and a 32-bit architecture only has 32-bit instructions, then overall the 16-bit architecture will have better code density, and better than one half the performance of the 32-bit architecture. clearly 32-bit performance comes at the cost of code density. arm.book page 3 wednesday, november 25, 1998 1:11 pm
1-4 introduction thumb breaks this constraint by implementing a 16-bit instruction length on a 32-bit architecture, making the processing of 32-bit data ef?cient with a compact instruction coding. this provides far better performance than a 16-bit architecture, with better code density than a 32-bit architecture. thumb also has a major advantage over other 32-bit architectures with 16-bit instructions. this is the ability to switch back to full arm code and execute at full speed. thus critical loops for applications such as fast interrupts dsp algorithms can be coded using the full arm instruction set, and linked with thumb code. the overhead of switching from thumb code to arm code is folded into subroutine entry time. various portions of a system can be optimized for speed or for code density by switching between thumb and arm execution as appropriate. figure 1.1 processor core diagram scan chain 0 a[31:0] scan chain 1 d[31:0] nopc nrw all other signals tck tms tdi ntrst tdo extern1 extern0 ntrans nmreq scan chain 2 mas[1:0] din[31:0] dout[31:0] rangeout1 rangeout0 tapsm[3:0] ir[3:0] screg[3:0] processor core embeddedice ta p controller bus splitter arm.book page 4 wednesday, november 25, 1998 1:11 pm
ARM7TDMI architecture 1-5 figure 1.2 ARM7TDMI core diagram nreset nmreq seq abort nirq nfiq nrw lock ncpi cpa cpb nwait mclk nopc ntrans instruction decoder and control logic instruction pipeline and read data register dbe d[31:0] 32-bit alu barrel shifter address register register bank (31 x 32-bit registers) (6 status registers) a[31:0] ale multiplier abe write data register nm[4:0] 32 x 8 nenout nenin tbe scan control breakpt dbgrqi nexec dbgack eclk isync b b u s a l u b u s ape bl[3:0] mas[1:0] tbit highz and thumb instruction decoder b port address incrementer incrementer bus pc bus a port a bus alu bus b bus arm.book page 5 wednesday, november 25, 1998 1:11 pm
1-6 introduction 1.3 coreware ? program an lsi logic core is a fully de?ned, optimized, and reusable block of logic. it supports industry-standard functions and has prede?ned timing and layout. the core is also an encrypted rtl simulation model for a wide range of vhdl and verilog simulators. the coreware library contains an extensive set of complex cores for the communications, consumer, and computer markets. the library consists of high-speed interconnect functions such as the gigablaze ? g10 ? core, mips embedded\microprocessors, mpeg-2 decoders, a pci core, and many more. the library also includes megafunctions or building blocks, which provide useful functions for developing a system on a chip. through the coreware program, you can create a system on a chip uniquely suited to your applications. each core has an associated set of deliverables, including: encrypted rtl simulation models for both verilog and vhdl environments a system veri?cation environment (sve) for rtl-based simulation synthesis and timing shells netlists for full timing simulation complete documentation lsi logic flexstream? design support lsi logic's flexstream design solution provides seamless connectivity between products from leading electronic design automation (eda) vendors and lsi logic's manufacturing environment. standard interfaces for formats and languages such as vhdl, verilog, waveform generation language (wgl), physical design exchange format (pdef), and standard delay format (sdf) allow a wide range of tools to interoperate within the lsi logics flexstream design environment. in addition to design capabilities, full scan automatic test pattern generation (atpg) tools and lsi logic's specialized test solutions can be combined to provide high-fault coverage test programs that assure a fully functional design. arm.book page 6 wednesday, november 25, 1998 1:11 pm
coreware ? program 1-7 because your design requirements are unique, lsi logic is ?exible in working with you to develop your system-on-a-chip coreware design. three different work relationships are available: you provide lsi logic with a detailed speci?cation and lsi logic performs all design work. you design some functions while lsi logic provides you with the cores and megafunctions, and lsi logic completes the integration. you perform the entire design and integration, and lsi logic provides the core and associated deliverables. whatever the work relationship, lsi logic's advanced coreware methodology and asic process technologies consistently produce right-first-time ? silicon. arm.book page 7 wednesday, november 25, 1998 1:11 pm
1-8 introduction arm.book page 8 wednesday, november 25, 1998 1:11 pm
book title 2-1 chapter 2 signal descriptions this chapter describes all ARM7TDMI core interface signals and is divided into the following sections: section 2.1, core logic diagram, page 2-1 section 2.2, clock signals, page 2-3 section 2.3, interrupt signals, page 2-3 section 2.4, bus control interface, page 2-4 section 2.5, debug interface, page 2-7 section 2.6, boundary scan control interface, page 2-9 section 2.7, boundary scan interface, page 2-11 section 2.8, processor interface, page 2-12 section 2.9, memory interface, page 2-12 section 2.10, coprocessor interface, page 2-15 section 2.11, test signals, page 2-16 2.1 core logic diagram figure 2.1 is the core logic diagram and lists the core signal interfaces. arm.book page 1 wednesday, november 25, 1998 1:11 pm
2-2 signal descriptions figure 2.1 ARM7TDMI logic diagram lock a[31:0] abort nopc ncpi cpa cpb coprocessor interface ntrans memory interface d[31:0] tck tms tdi ntrst boundary scan tdo processor interface nrw nmreq seq bl[3:0] mas[1:0] tbit nm[4:0] din[31:0] dout[31:0] tapsm[3:0] ir[3:0] tck1 tck2 ntdoen screg[3:0] abe ale nirq nfiq bus interrupt isync nreset mclk nwait clock dbgrq breakpt dbgack nexec debug control extern1 dbe tbe extern0 nenout nenin eclk dbgen ape highz bigend busen rangeout0 rangeout1 dbgrqi commrx commtx nenouti ecapclk busdis signals signals interface signals interface pclkbs shclk2bs sdoutbs icapclkbs boundary scan shclkbs drivebs rstclkbs sdinbs ecapclkbs nhighz interface control scan_out fullscan ramtest test signals ramscan_out ramscan_in wenctest scan_en scan_in ARM7TDMI arm.book page 2 wednesday, november 25, 1998 1:11 pm
clock signals 2-3 2.2 clock signals eclk external clock output output in normal operation, this is simply mclk (optionally stretched with nwait) exported from the core. when the core is being debugged, this is tclk. this allows external hardware to track when the ARM7TDMI core is clocked. when fullscan is asserted, eclk is held low. mclk memory clock input input this clock times all ARM7TDMI memory accesses and internal operations. the clock has two distinct phases phase 1 in which mclk is low phase 2 in which mclk (and nwait) are high the clock may be stretched inde?nitely in either phase to allow access to slow peripherals or memory. alternatively, the nwait input may be used with a free running mclk to achieve the same effect. nwait not wait input when accessing slow peripherals, ARM7TDMI can be made to wait for an integer number of mclk cycles by driving nwait low. internally, nwait is anded with mclk and must only change when mclk is low. if nwait is not used it must be tied high. 2.3 interrupt signals isync synchronous interrupts input when low indicates that the nirq and nfiq inputs are to be synchronized by the ARM7TDMI core. when high disables this synchronization for inputs that are already synchronous. nfiq not fast interrupt request input this is an interrupt request to the processor which causes it to be interrupted if taken low when the appropriate enable in the processor is active. the signal is level-sensitive and must be held low until a suitable arm.book page 3 wednesday, november 25, 1998 1:11 pm
2-4 signal descriptions response is received from the processor. nfiq may be synchronous or asynchronous, depending on the state of isync. nirq not interrupt request input the same as nfiq, but with lower priority. may be taken low to interrupt the processor when the appropriate enable is active. nirq may be synchronous or asynchronous, depending on the state of isync. 2.4 bus control interface abe address bus enable input this is an input signal which, when low, puts the address bus drivers into a high impedance state. this signal has a similar effect on the following control signals: mas[1:0], nrw, lock, nopc and ntrans. abe must be tied high when there is no system requirement to turn off the address drivers. ale address latch enable input this input is used to control transparent latches on the address outputs. normally the addresses change during phase 2 to the value required during the next cycle, but for direct interfacing to roms they are required to be stable to the end of phase 2. taking ale low until the end of phase 2 will ensure that this happens. this signal has a similar effect on the following control signals: mas[1:0], nrw, lock, nopc and ntrans. if the system does not require address lines to be held in this way, ale must be tied high. the address latch is static, so ale may be held low for long periods to freeze addresses. ape address pipeline enable input when high, this signal enables the address timing pipeline. in this state, the address bus plus mas[1:0], nrw, ntrans, lock and nopc change in phase 2 prior to the memory cycle to which they refer. when ape is low, these signals change in phase 1 of the actual cycle. please refer to chapter 6, "memory interface" for details of this timing. arm.book page 4 wednesday, november 25, 1998 1:11 pm
bus control interface 2-5 bigend big endian con?guration input when this signal is high the processor treats bytes in memory as being in big endian format. when it is low, memory is treated as little endian. busdis bus disable output this signal is high when intest is selected on scan chain 0 or 4 and may be used to disable external logic driving onto the bidirectional data bus during scan testing. this signal changes on the falling edge of tck. busen data bus con?guration input this is a static con?guration signal which determines whether the bidirectional data bus, d[31:0], or the unidirectional data buses, din[31:0] and dout[31:0], are to be used for transfer of data between the processor and memory. refer also to chapter 6, "memory interface" . when busen is low, the bidirectional data bus, d[31:0] is used. in this case, dout[31:0] is driven to value 0x00000000, and any data presented on din[31:0] is ignored. when busen is high, the bidirectional data bus, d[31:0] is ignored and must be left unconnected. input data and instructions are presented on the input data bus, din[31:0], output data appears on dout[31:0]. dbe data bus enable input this is an input signal which, when driven low, puts the data bus d[31:0] into the high impedance state. this is included for test purposes, and should be tied high at all times. ecapclk extest capture clock output this signal removes the need for the external logic in the test chip which was required to enable the internal 3-state bus during scan testing. this need not be brought out as an external pin on the test chip. highz output this signal denotes that the highz instruction has been loaded into the tap controller. see chapter 8, "debug interface" for details. arm.book page 5 wednesday, november 25, 1998 1:11 pm
2-6 signal descriptions nenin not enable input input this signal may be used in conjunction with nenout to control the data bus during write cycles. see chapter 6, "memory interface" . nenout not enable output output during a data write cycle, this signal is driven low during phase 1, and remains low for the entire cycle. this may be used to aid arbitration in shared bus applications. see chapter 6, "memory interface" . nenouti not enable output ice output during a coprocessor register transfer c-cycle from the embeddedice macrocell communications channel coprocessor to the ARM7TDMI core, this signal goes low during phase 1 and stays low for the entire cycle. this may be used to aid arbitration in shared bus systems. nreset not reset input this is a level sensitive input signal which is used to start the processor from a known address. a low level will cause the instruction being executed to terminate abnormally. when nreset becomes high for at least one clock cycle, the processor will restart from address 0. nreset must remain low (and nwait must remain high) for at least two clock cycles. during the low period the processor will perform dummy instruction fetches with the address incrementing from the point where reset was activated. the address will overflow to zero if nreset is held beyond the maximum address limit. tbe test bus enable input when driven low, tbe forces the data bus d[31:0], the address bus a[31:0], plus lock, mas[1:0], nrw, ntrans and nopc to high impedance. this is as if both abe and dbe had both been driven low. however, tbe does not have an associated scan cell and so allows external signals to be driven high impedance during scan testing. under normal operating conditions, tbe should be held high at all times. arm.book page 6 wednesday, november 25, 1998 1:11 pm
debug interface 2-7 2.5 debug interface breakpt breakpoint input this signal allows external hardware to halt the execution of the processor for debug purposes. when high causes the current memory access to be a breakpoint. if the memory access is an instruction fetch, ARM7TDMI will enter debug state if the instruction reaches the execute stage of the ARM7TDMI pipeline. if the memory access is for data, ARM7TDMI will enter debug state after the current instruction completes execution.this allows extension of the internal breakpoints provided by the embeddedice macrocell module. see chapter 6, "mem- ory interface" . commrx communications channel receive output when high, this signal denotes that the communications channel receive buffer is empty. this signal changes on the rising edge of mclk. see section 9.11.1, debug communications control registers, for more information on the debug communications channel. commtx communications channel transmit output when high, this signal denotes that the communications channel transmit buffer is empty. this signal changes on the rising edge of mclk. see section 9.11.1, debug communications control registers, for more information on the debug communications channel. dbgack debug acknowledge output when high indicates ARM7TDMI is in debug state. dbgen debug enable input this input signal allows the debug features of ARM7TDMI to be disabled. this signal should be driven low when debugging is not required. dbgrq debug request input this is a level sensitive input, which when high causes ARM7TDMI to enter debug state after executing the current instruction. this allows external hardware to force ARM7TDMI into the debug state, in addition to the debugging features provided by the embeddedice macrocell. see chapter 9, "embeddedice macrocell" for details. arm.book page 7 wednesday, november 25, 1998 1:11 pm
2-8 signal descriptions dbgrqi internal debug request output this signal represents the debug request signal which is presented to the processor. this is the combination of external dbgrq, as presented to the ARM7TDMI macrocell, and bit 1 of the debug control register. thus there are two conditions where this signal can change. when dbgrq changes, dbgrqi will change after a propagation delay. when bit 1 of the debug control register has been written, this signal will change on the falling edge of tck when the tap controller state machine is in the run-test/idle state. see chapter 9, "embeddedice macrocell" for details. extern0 external input 0 input this is an input to the embeddedice logic in the ARM7TDMI which allows breakpoints and/or watchpoints to be dependent on an external condition. extern1 external input 1 input this is an input to the embeddedice logic in the ARM7TDMI which allows breakpoints and/or watchpoints to be dependent on an external condition. nexec not executed output when high indicates that the instruction in the execution unit is not being executed, because, for example, it has failed its condition code check. rangeout0 embeddedice rangeout0 output this signal indicates that embeddedice watchpoint register 0 has matched the conditions currently present on the address, data and control buses. this signal is independent of the state of the watchpoints enable control bit. rangeout0 changes when eclk is low. rangeout1 embeddedice rangeout1 output this signal is the same as rangeout0 but corresponds to embeddedice watchpoint register 1. arm.book page 8 wednesday, november 25, 1998 1:11 pm
boundary scan control interface 2-9 2.6 boundary scan control interface drivebs boundary scan cell enable output this signal is used to control the multiplexers in the scan cells of an external boundary scan chain. this signal changes in the update-ir state when scan chain 3 is selected and either the intest , extest , clamp or clampz instruction is loaded. when an external boundary scan chain is not connected, this output should be left unconnected. ecapclkbs extest capture clock for boundary scan output 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 is used to capture the macrocell outputs during extest . when an external boundary scan chain is not connected, this output should be left unconnected. icapclkbs intest capture clock output this is a tck2 wide pulse generated when the tap controller state machine is in the capture-dr state, the current instruction is intest and scan chain 3 is selected. this is used to capture the macrocell outputs during intest . when an external boundary scan chain is not connected, this output should be left unconnected. nhighz not highz output this signal is generated by the tap controller when the current instruction is highz . this is used to place the scan cells of that scan chain in the high impedance state. when an external boundary scan chain is not connected, this output should be left unconnected. pclkbs boundary scan update clock output 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 is used by an external boundary scan chain as the update clock. when an external boundary scan chain is not connected, this output should be left unconnected. arm.book page 9 wednesday, november 25, 1998 1:11 pm
2-10 signal descriptions rstclkbs boundary scan reset clock output this signal denotes 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. sdinbs boundary scan serial input data output this signal contains the serial data to be applied to an external scan chain and is valid on the falling edge of tck. sdoutbs boundary scan serial output data input this control signal is provided to ease the connection of an external boundary scan chain. this is the serial data out of the boundary scan chain. it should be setup to the rising edge of tck. when an external boundary scan chain is not connected, this input should be tied low. shclkbs boundary scan shift clock, phase 1 output this control signal is provided to ease the connection of an external boundary scan chain. shclkbs is used to clock the master half of the external scan cells. when in the shift-dr state of the state machine and scan chain 3 is selected, shclkbs 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, this output should be left unconnected. shclk2bs boundary scan shift clock, phase 2 output this control signal is provided to ease the connection of an external boundary scan chain. shclk2bs is used to clock the master half of the external scan cells. when in the shift-dr state of the state machine and scan chain 3 is selected, shclk2bs follows tck2. when not in the shift-dr state or when scan chain 3 is not selected, this clock is low. when an external boundary scan chain is not connected, this output should be left unconnected. arm.book page 10 wednesday, november 25, 1998 1:11 pm
boundary scan interface 2-11 2.7 boundary scan interface ir[3:0] tap controller instruction register output these 4 bits re?ect the current instruction loaded into the tap controller instruction register. the instruction encoding is as described in section 8.8, public instruc- tions . these bits change on the falling edge of tck when the state machine is in the update-ir state. ntdoen not tdo enable output when low, this signal denotes that serial data is being driven out on the tdo output. ntdoen would normally be used as an output enable for a tdo pin in a packaged part. ntrst not test reset input active low reset signal for the boundary scan logic. this pin must be pulsed or driven low to achieve normal device operation, in addition to the normal device reset (nreset). for more information, see chapter 8, "debug interface" . screg[3:0] scan chain register output these 4 bits re?ect the id number of the scan chain currently selected by the tap controller. these bits change on the falling edge of tck when the tap state machine is in the update-dr state. tapsm[3:0] tap controller state machine output this bus re?ects the current state of the tap controller state machine, as shown in section 8.4.2, the jtag state machine . these bits change off the rising edge of tck. tck test clock input the clock used for test operations. tck1 tck, phase 1 output this clock is a buffered version of tck. tck1 is high when tck is high. arm.book page 11 wednesday, november 25, 1998 1:11 pm
2-12 signal descriptions tck2 tck, phase 2 output this clock is a buffered, inverted version of tck. tck2 is high when tck is low. please note that tck2 has a slight overlap with the tck1 signal. tdi test data input input boundary scan logic input. tdo test data output output boundary scan logic output. tms test mode select input boundary scan test mode select signal. 2.8 processor interface nm[4:0] not processor mode output these are output signals which are the inverses of the internal status bits indicating the processor operation mode. tbit thumb mode output when high, this signal denotes that the processor is executing the thumb instruction set. when low, the processor is executing the arm instruction set. this signal changes in phase 2 in the ?rst execute cycle of a bx instruction. 2.9 memory interface a[31:0] addresses output this is the processor address bus. if ale (address latch enable) is high and ape (address pipeline enable) is low, the addresses become valid during phase 2 of the cycle before the one to which they refer and remain so during phase 1 of the referenced cycle. their stable period may be controlled by ale or ape as described in section 2.4, bus control interface. abort memory abort input this is an input which allows the memory system to tell the processor that a requested access is not allowed. arm.book page 12 wednesday, november 25, 1998 1:11 pm
memory interface 2-13 bl[3:0] byte latch control input these signals control when data and instructions are latched from the external data bus. when bl[3] is high, the data on d[31:24] is latched on the falling edge of mclk. when bl[2] is high, the data on d[23:16] is latched and so on. please refer to chapter 6, "memory interface" for details on the use of these signals. d[31:0] data bus bidirectional these are bidirectional signal paths which are used for data transfers between the processor and external memory. during read cycles (when nrw is low), the input data must be valid before the end of phase 2 of the transfer cycle. during write cycles (when nrw is high), the output data will become valid during phase 1 and remain valid throughout phase 2 of the transfer cycle. note: this bus is driven at all times, irrespective of whether busen is high or low. when d[31:0] is not being used to connect to the memory system it must be left unconnected. see chapter 6, "memory interface" . din[31:0] data input bus input this is the input data bus which may be used to transfer instructions and data between the processor and memory. this data input bus is only used when busen is high. the data on this bus is sampled by the processor at the end of phase 2 during read cycles (i.e. when nrw is low). dout[31:0] data output bus output this is the data out bus, used to transfer data from the processor to the memory system. output data only appears on this bus when busen is high. at all other times, this bus is driven to value 0x00000000. when in use, data on this bus changes during phase 1 of store cycles (i.e. when nrw is high) and remains valid throughout phase 2. lock locked operation output when lock is high, the processor is performing a locked memory access, and the memory controller must wait until lock goes low before allowing another device to access the memory. lock changes while mclk is high, and remains high for the duration of the arm.book page 13 wednesday, november 25, 1998 1:11 pm
2-14 signal descriptions locked memory accesses. it is active only during the data swap ( swp ) instruction. the timing of this signal may be modi?ed by the use of ale and ape as described in section 2.4, bus control interface. this signal may also be driven to a high impedance state by driving abe low. mas[1:0] memory access size output these are output signals used by the processor to indicate to the external memory system when a word transfer or a halfword or byte length is required. the signals take the value 0b10 for words, 0b01 for halfwords and 0b00 for bytes. 0b11 is reserved. these values are valid for both read and write cycles. the signals will normally become valid during phase 2 of the cycle before the one in which the transfer will take place. they will remain stable throughout phase 1 of the transfer cycle. the timing of the signals may be modi?ed by the use of ale and ape in a way similar to the a[31:0], please refer to section 2.4, bus control interface. the signals may also be driven to high impedance state by driving abe low. nmreq not memory request output this signal, when low, indicates that the processor requires memory access during the following cycle. the signal becomes valid during phase 1, remaining valid through phase 2 of the cycle preceding that to which it refers. nrw not read/write output when high this signal indicates a processor write cycle; when low, a read cycle. it becomes valid during phase 2 of the cycle before that to which it refers, and remains valid to the end of phase 1 of the referenced cycle. the timing of this signal may be modi?ed by the use of ale and ape in a way similar to the a[31:0] signals, please refer to section 2.4, bus control interface. this signal may also be driven to a high impedance state by driving abe low. ntrans not memory translate output when this signal is low it indicates that the processor is in user mode. it may be used to tell memory management hardware when translation of the addresses should be turned on, or as an indicator of nonuser mode arm.book page 14 wednesday, november 25, 1998 1:11 pm
coprocessor interface 2-15 activity. the timing of this signal may be modi?ed by the use of ale and ape in a way similar to the a[31:0] signals, please refer to section 2.4, bus control inter- face. this signal may also be driven to a high impedance state by driving abe low. seq sequential address output this output signal will become high when the address of the next memory cycle will be related to that of the last memory access. the new address will either be the same as the previous one or four greater in arm state, or two greater in thumb state. the signal becomes valid during phase 1 and remains so through phase 2 of the cycle before the cycle whose address it anticipates. it may be used, in combination with the low-order address lines, to indicate that the next cycle can use a fast memory mode (for example dram page mode) and/or to bypass the address translation sys tem. 2.10 coprocessor interface cpa coprocessor absent input a coprocessor which is capable of performing the operation that ARM7TDMI is requesting (by asserting ncpi) should take cpa low immediately. if cpa is high at the end of phase 1 of the cycle in which ncpi went low, ARM7TDMI will abort the coprocessor handshake and take the unde?ned instruction trap. if cpa is low and remains low, ARM7TDMI will busy-wait until cpb is low and then complete the coprocessor instruction. cpb coprocessor busy input a coprocessor which is capable of performing the operation which ARM7TDMI is requesting (by asserting ncpi), but cannot commit to starting it immediately, should indicate this by driving cpb high. when the coprocessor is ready to start it should take cpb low. ARM7TDMI samples cpb at the end of phase 1 of each cycle in which ncpi is low. arm.book page 15 wednesday, november 25, 1998 1:11 pm
2-16 signal descriptions ncpi not coprocessor instruction output when ARM7TDMI executes a coprocessor instruction, it will take this output low and wait for a response from the coprocessor. the action taken will depend on this response, which the coprocessor signals on the cpa and cpb inputs. nopc not opcode fetch output when low this signal indicates that the processor is fetching an instruction from memory; when high, data (if present) is being transferred. the signal becomes valid during phase 2 of the previous cycle, remaining valid through phase 1 of the referenced cycle. the timing of this signal may be modi?ed by the use of ale and ape in a way similar to the a[31:0] signals, please refer to section 2.4, bus control interface. this signal may also be driven to a high impedance state by driving abe low. 2.11 test signals fullscan master scan mode select input asserting fullscan enables either production test mode or ramtest mode, depending on the value of ramtest. fullscan should remain asserted for the duration of scan testing and must be deasserted during normal operation. ramtest ramtest scan mode select input when fullscan is asserted, asserting ramtest places the core in ramtest mode. ramtest should remain asserted for the duration of the ramtest scan. if fullscan is deasserted, asserting ramtest will have no effect on the core state. ramscan_in ramtest scan chain input input during ramtest mode, ramscan_in is the scan input for the core memory scan chain. ramscan_out ramtest scan chain output output during ramtest mode, ramscan_out is the scan output for the core memory scan chain. arm.book page 16 wednesday, november 25, 1998 1:11 pm
test signals 2-17 scan_en global scan enable input in either production test mode or ramtest mode, asserting scan_en enables serial loading of the scan registers through the scan chain. scan_in full scan chain input input in production test mode, scan_in is the scan input for the core scan chain. scan_out full scan chain output output in production test mode, scan_out is the scan output for the core scan chain. wenctest ramtest write enable input this test signal is used only when fullscan is asserted. wenctest controls core memory writes in the ramtest mode. when fullscan is deasserted, wenctest should also be deasserted. arm.book page 17 wednesday, november 25, 1998 1:11 pm
2-18 signal descriptions arm.book page 18 wednesday, november 25, 1998 1:11 pm
book title 3-1 chapter 3 programmers model this chapter describes the two operating states of the ARM7TDMI. it contains the following sections: section 3.1, processor operating states, page 3-1 section 3.2, switching state,page 3-2 section 3.3, memory formats, page 3-2 section 3.4, instruction length, page 3-3 section 3.5, data types, page 3-4 section 3.6, operating modes, page 3-4 section 3.7, registers, page 3-4 section 3.8, program status registers, page 3-9 section 3.9, exceptions, page 3-11 section 3.10, interrupt latencies, page 3-17 section 3.11, reset, page 3-18 section 3.12, pipeline architecture, page 3-18 3.1 processor operating states from the programmers point of view, the ARM7TDMI can be in one of two states: arm state which executes 32-bit, word-aligned arm instructions. thumb state which operates with 16-bit, halfword-aligned thumb instructions. in this state, the pc uses bit 1 to select between alternate halfwords. note: transition between these two states does not affect the processor mode or the contents of the registers. arm.book page 1 wednesday, november 25, 1998 1:11 pm
3-2 programmers model 3.2 switching state this section describes the method for entering either the thumb or arm state. 3.2.1 entering thumb state entry into thumb state can be achieved by executing a bx instruction with the state bit (bit 0) set in the operand register. transition to thumb state will also occur automatically on return from an exception ( irq , fiq , undef , abort , swi etc.), if the exception was entered with the processor in thumb state. 3.2.2 entering arm state entry into arm state happens: 1. on execution of the bx instruction with the state bit clear in the operand register. 2. on the processor taking an exception ( irq , fiq , reset , undef , abort , swi etc.). in this case, the pc is placed in the exception modes link register, and execution commences at the exceptions vector address. 3.3 memory formats ARM7TDMI views memory as a linear collection of bytes numbered upwards from zero. bytes 0 to 3 hold the ?rst stored word, bytes 4 to 7 the second and so on. ARM7TDMI can treat words in memory as being stored either in big endian or little endian format. 3.3.1 big endian format in big endian format, the most signi?cant byte of a word is stored at the lowest numbered byte and the least signi?cant byte at the highest numbered byte. byte 0 of the memory system is therefore connected to data lines 31 through 24. arm.book page 2 wednesday, november 25, 1998 1:11 pm
instruction length 3-3 figure 3.1 big endian addresses of bytes within words 3.3.2 little endian format in little endian format, the lowest numbered byte in a word is considered the words least signi?cant byte, and the highest numbered byte the most signi?cant. byte 0 of the memory system is therefore connected to data lines 7 through 0. figure 3.2 little endian addresses of bytes within words 3.4 instruction length instructions are either 32 bits long (in arm state) or 16 bits long (in thumb state). note: most signi?cant byte is at lowest address. word is addressed by byte address of most signi?cant byte. higher address lower address 31 24 23 16 15 8 7 0 word address 8 9 10 11 8 45 6 7 4 01 2 3 0 note: most signi?cant byte is at lowest address. word is addressed by byte address of least signi?cant byte. higher address lower address 31 24 23 16 15 8 7 0 word address 11 10 9 8 8 76 5 4 4 32 1 0 0 arm.book page 3 wednesday, november 25, 1998 1:11 pm
3-4 programmers model 3.5 data types ARM7TDMI supports byte (8 bit), halfword (16 bit) and word (32 bit) data types. words must be aligned to 4-byte boundaries and halfwords to 2- byte boundaries. 3.6 operating modes ARM7TDMI supports seven modes of operation: user (usr): the normal arm program execution state fiq (?q): designed to support a data transfer or channel process irq (irq): used for general purpose interrupt handling supervisor (svc): protected mode for the operating system abort mode (abt): entered after a data or instruction prefetch abort system (sys): a privileged user mode for the operating system unde?ned (und): entered when an unde?ned instruction is executed mode changes may be made under software control, or may be brought about by external interrupts or exception processing. most application programs will execute in user mode. the nonuser modesCknown as privileged modes Care entered in order to service interrupts or exceptions, or to access protected resources. 3.7 registers ARM7TDMI has a total of 37 registers (31 general purpose 32-bit registers and six status registers), but these cannot all be seen at once. the processor state and operating mode dictate which registers are available to the programmer. arm.book page 4 wednesday, november 25, 1998 1:11 pm
registers 3-5 3.7.1 the arm state register set in arm state, 16 general registers and one or two status registers are visible at any one time. in privileged (nonuser) modes, mode-speci?c banked registers are visible. figure 3.3 shows which registers are available in each mode: the banked registers are marked with a shaded triangle. the arm state register set contains 16 directly accessible registers: r0 to r15. all of these except r15 are general-purpose registers, and may be used to hold either data or address values. in addition to these, there is a seventeenth register used to store status information 3.7.1.1 register 14 used as the subroutine link register. this receives a copy of r15 when a branch and link (bl) instruction is executed. at all other times it may be treated as a general-purpose register. the corresponding banked registers r14_svc, r14_irq, r14_?q, r14_abt and r14_und are similarly used to hold the return values of r15 when interrupts and exceptions arise, or when branch and link instructions are executed within interrupt or exception routines. 3.7.1.2 register 15 holds the program counter (pc). in arm state, bits [1:0] of r15 are zero and bits [31:2] contain the pc. in thumb state, bit [0] is zero and bits [31:1] contain the pc. 3.7.1.3 register 16 this is the cpsr (current program status register). this contains condition code ?ags and the current mode bits. fiq mode has seven banked registers mapped to r8Cr14 (r8_?qCr14_?q). in arm state, many fiq handlers do not need to save any registers. user, irq, supervisor, abort and unde?ned each have two banked registers mapped to r13 and r14, allowing each of these modes to have a private stack pointer and link registers. arm.book page 5 wednesday, november 25, 1998 1:11 pm
3-6 programmers model figure 3.3 register organization in arm state 3.7.2 the thumb state register set the thumb state register set is a subset of the arm state set. the programmer has direct access to eight general registers, r0-r7, as well as the program counter (pc), a stack pointer register (sp), a link register (lr), and the current program status register (cpsr). there are banked stack pointers, link registers and saved process status registers (spsrs) for each privileged mode. this is shown in figure 3.4 . arm state general registers and program counter r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 (pc) r0 r1 r2 r3 r4 r5 r6 r7 r8_?q r9_?q r10_?q r11_?q r12_?q r13_?q r14_?q r15 (pc) r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_svc r14_svc r15 (pc) r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_abt r14_abt r15 (pc) r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_irq r14_irq r15 (pc) r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_und r14_und r15 (pc) system & user fiq supervisor abort irq unde?ned cpsr cpsr spsr_?q cpsr spsr_svc cpsr spsr_abt cpsr spsr_irq cpsr spsr_und arm state program status registers = banked register. arm.book page 6 wednesday, november 25, 1998 1:11 pm
registers 3-7 figure 3.4 register organization in thumb state 3.7.3 the relationship between arm and thumb state registers the thumb state registers relate to the arm state registers in the following way: thumb state r0Cr7 and arm state r0Cr7 are identical thumb state cpsr and spsrs and arm state cpsr and spsrs are identical thumb state sp maps onto arm state r13 thumb state lr maps onto arm state r14 the thumb state program counter maps onto the arm state program counter (r15) this relationship is shown in figure 3.5 . r0 r1 r2 r3 r4 r5 r6 r7 sp lr pc system & user fiq supervisor abort irq unde?ned cpsr cpsr spsr_?q cpsr spsr_svc cpsr spsr_abt cpsr spsr_irq cpsr spsr_und r0 r1 r2 r3 r4 r5 r6 r7 sp_?q lr_?q pc r0 r1 r2 r3 r4 r5 r6 r7 sp_svc lr_svc pc r0 r1 r2 r3 r4 r5 r6 r7 sp_abt lr_abt pc r0 r1 r2 r3 r4 r5 r6 r7 sp_irq lr_irq pc r0 r1 r2 r3 r4 r5 r6 r7 sp_und lr_und pc thumb state general registers and program counter thumb state program status registers = banked register. arm.book page 7 wednesday, november 25, 1998 1:11 pm
3-8 programmers model figure 3.5 mapping of thumb state registers onto arm state registers 3.7.4 accessing high registers in thumb state in thumb state, registers r8Cr15 (the high registers ) are not part of the standard register set. however, the assembly language programmer has limited access to them, and can use them for fast temporary storage. a value may be transferred from a register in the range r0Cr7 (a low register) to a high register, and from a high register to a low register, using special variants of the mov instruction. high register values can also be compared against or added to low register values with the cmp and add instructions. arm state r0 r1 r2 r3 r5 r6 r7 r8 r9 r10 r11 r12 stack pointer (r13) link register (r14) program counter (r15) r0 r1 r2 r3 r5 r6 r7 stack pointer (sp) link register (lr) program counter (pc) cpsr cpsr spsr spsr r4 r4 low registers high registers thumb state arm.book page 8 wednesday, november 25, 1998 1:11 pm
program status registers 3-9 3.8 program status registers the ARM7TDMI contains a current program status register (cpsr), plus ?ve saved program status registers (spsrs) for use by exception handlers. these registers hold information about the most recently performed alu operation control the enabling and disabling of interrupts set the processor operating mode the arrangement of bits is shown in figure 3.6 . figure 3.6 program status register format 3.8.1 the condition code flags n negative/less than 31 z zero 30 c carry/borrow/extend 29 v over?ow 28 the n, z, c and v bits are the condition code ?ags. these may be changed as a result of arithmetic and logical operations, and may be tested to determine whether an instruction should be executed. in arm state, all instructions may be executed conditionally: see section 4.3, instruction condition field, for details. in thumb state, only the branch instruction is capable of conditional execution. 31 30 29 28 27 8 7 6 5 4 3 2 1 0 n z c v reserved i f t m4 m3 m2 m1 m0 arm.book page 9 wednesday, november 25, 1998 1:11 pm
3-10 programmers model 3.8.2 reserved bits reserved [27:8] bits [27:8] in the program status registers are reserved. when changing a psrs ?ag or control bits, you must ensure that these unused bits are not altered. also, your program should not rely on them containing speci?c values, since in future processors they may read as one or zero. 3.8.3 the control bits the bottom 8 bits of a psr (incorporating i, f, t and m[4:0]) are known collectively as the control bits. these will change when an exception arises. if the processor is operating in a privileged mode, they can also be manipulated by software. the t bit operating state 7 this bit re?ects the processor operating state. when this bit is set, the processor is executing in thumb state, otherwise it is executing in arm state. this is re?ected on the tbit external signal. note that the software must never change the state of the tbit in the cpsr. if this happens, the processor will enter an unpredictable state. i and f interrupt disable bits [6:5] the i and f bits are the interrupt disable bits. when set, these disable the irq and fiq interrupts respectively. m[4:0] the mode bits [4:0] the m4, m3, m2, m1 and m0 bits (m[4:0]) are the mode bits. these determine the processors operating mode, as shown in the following table. not all combinations of the mode bits de?ne a valid processor mode. only those explicitly described should be used. if any illegal value is programmed into the mode bits, m[4:0], then the processor will enter an unrecoverable state. if this occurs, reset should be applied. table 3.1 lists the mode bit states and the accessible state registers for each mode. arm.book page 10 wednesday, november 25, 1998 1:11 pm
exceptions 3-11 3.9 exceptions exceptions arise whenever the normal ?ow of a program has to be halted temporarily, for example to service an interrupt from a peripheral. before an exception can be handled, the current processor state must be preserved so that the original program can resume when the handler routine has ?nished. it is possible for several exceptions to arise at the same time. if this happens, they are dealt with in a ?xed order see section 3.9.10, exception priorities . 3.9.1 action on entering an exception when handling an exception, the ARM7TDMI: 1. preserves the address of the next instruction in the appropriate link register. if the exception has been entered from arm state, then the address of the next instruction is copied into the link register (that is, current pc + 4 or pc + 8 depending on the exception. see table 3.1 mode bit states m[4:0] mode accessible thumb state registers accessible arm state registers 0b10000 user r7..r0, lr, sp, pc, cpsr r14..r0, pc, cpsr 0b10001 fiq r7..r0, lr_?q, sp_?q, pc, cpsr, spsr_?q r7..r0, r14_?q..r8_?q, pc, cpsr, spsr_?q 0b10010 irq r7..r0, lr_irq, sp_irq, pc, cpsr, spsr_irq r12..r0, r14_irq..r13_irq, pc, cpsr, spsr_irq 0b10011 supervisor r7..r0, lr_svc, sp_svc, pc, cpsr, spsr_svc r12..r0, r14_svc..r13_svc, pc, cpsr, spsr_svc 0b10111 abort r7..r0, lr_abt, sp_abt, pc, cpsr, spsr_abt r12..r0, r14_abt..r13_abt, pc, cpsr, spsr_abt 0b11011 unde?ned r7..r0, lr_und, sp_und, pc, cpsr, spsr_und r12..r0, r14_und..r13_und, pc, cpsr 0b11111 system r7..r0, lr, sp, pc, cpsr r14..r0, pc, cpsr arm.book page 11 wednesday, november 25, 1998 1:11 pm
3-12 programmers model table 3.2 exception entry/exit for details). if the exception has been entered from thumb state, then the value written into the link register is the current pc offset by a value such that the program resumes from the correct place on return from the exception. this means that the exception handler need not determine from which state the exception was entered. for example, in the case of a software interrupt ( swi ), movs pc, r14_svc will always return to the next instruction regardless of whether the swi was executed in arm or thumb state. 2. copies the cpsr into the appropriate spsr 3. forces the cpsr mode bits to a value which depends on the exception 4. forces the pc to fetch the next instruction from the relevant exception vector it may also set the interrupt disable ?ags to prevent otherwise unmanageable nestings of exceptions. if the processor is in thumb state when an exception occurs, it will automatically switch into arm state when the pc is loaded with the exception vector address. 3.9.2 action on leaving an exception on completion, the exception handler: 1. moves the link register, minus an offset where appropriate, to the pc. (the offset will vary depending on the type of exception.) 2. copies the spsr back to the cpsr 3. clears the interrupt disable ?ags, if they were set on entry note: an explicit switch back to thumb state is never needed, since restoring the cpsr from the spsr automatically sets the t bit to the value it held immediately prior to the exception. arm.book page 12 wednesday, november 25, 1998 1:11 pm
exceptions 3-13 3.9.3 exception entry/exit summary table 3.2 summarizes the pc value preserved in the relevant r14 register on exception entry, and the recommended instruction for exiting the exception handler. 3.9.4 fast interrupt request (fiq) the fiq (fast interrupt request) exception is designed to support a data transfer or channel process, and in arm state has suf?cient private registers to remove the need for register saving (thus minimizing the overhead of context switching). fiq is externally generated by taking the nfiq input low. this input can except either synchronous or asynchronous transitions, depending on the state of the isync input signal. when isync is low, nfiq and nirq are considered asynchronous, and a cycle delay for synchronization is incurred before the interrupt can affect the processor ?ow. table 3.2 exception entry/exit exception return instruction previous state armthumb r14_xr14_x notes bl mov pc, r14 pc + 4 pc + 2 1 swi movs pc, r14_svc pc + 4 pc + 2 1 udef movs pc, r14_und pc + 4 pc + 2 1 fiq subs pc, r14_?q, #4 pc + 4 pc + 4 2 irq subs pc, r14_irq, #4 pc + 4 pc + 4 2 pabt subs pc, r14_abt, #4 pc + 4 pc + 4 1 dabt subs pc, r14_abt, #8 pc + 8 pc + 8 3 reset na C C 4 1. where pc is the address of the bl/swi/unde?ned instruction fetch which had the prefetch abort. 2. where pc is the address of the instruction which did not get executed since the fiq or irq took priority. 3. where pc is the address of the load or store instruction which generated the data abort. 4. the value saved in r14_svc upon reset is unpredictable. arm.book page 13 wednesday, november 25, 1998 1:11 pm
3-14 programmers model irrespective of whether the exception was entered from arm or thumb state, a fiq handler should leave the interrupt by executing subs pc,r14_fiq,#4 fiq may be disabled by setting the cpsrs f ?ag (but note that this is not possible from user mode). if the f ?ag is clear, ARM7TDMI checks for a low level on the output of the fiq synchronizer at the end of each instruction. 3.9.5 interrupt request (irq) the irq (interrupt request) exception is a normal interrupt caused by a low level on the nirq input. irq has a lower priority than fiq and is masked out when an fiq sequence is entered. it may be disabled at any time by setting the i bit in the cpsr, though this can only be done from a privileged (nonuser) mode. irrespective of whether the exception was entered from arm or thumb state, an irq handler should return from the interrupt by executing subs pc,r14_irq,#4 3.9.6 abort an abort indicates that the current memory access cannot be completed. it can be signalled by the external abort input. ARM7TDMI checks for the abort exception during memory access cycles. there are two types of abort: prefetch abort (pabt) occurs during an instruction prefetch. data abort (dabt) occurs during a data access. if a prefetch abort occurs, the prefetched instruction is marked as invalid, but the exception will not be taken until the instruction reaches the head of the pipeline. if the instruction is not executedfor example because a branch occurs while it is in the pipelinethe abort does not take place. if a data abort occurs, the action taken depends on the instruction type: 1. single data transfer instructions ( ldr , str ) write back modi?ed base registers: the abort handler must be aware of this. arm.book page 14 wednesday, november 25, 1998 1:11 pm
exceptions 3-15 2. the swap instruction ( swp ) is aborted as though it had not been executed. 3. block data transfer instructions ( ldm , stm ) complete. if write back is set, the base is updated. if the instruction would have overwritten the base with data (i.e., it has the base in the transfer list), the overwriting is prevented. all register overwriting is prevented after an abort is indicated, which means in particular that r15 (always the last register to be transferred) is preserved in an aborted ldm instruction. the abort mechanism allows the implementation of a demand paged virtual memory system. in such a system the processor is allowed to generate arbitrary addresses. when the data at an address is unavailable, the memory management unit (mmu) signals an abort. the abort handler must then work out the cause of the abort, make the requested data available, and retry the aborted instruction. the application program needs no knowledge of the amount of memory available to it, nor is its state in any way affected by the abort. after ?xing the reason for the abort, the handler should execute the following irrespective of the state (arm or thumb): this restores both the pc and the cpsr, and retries the aborted instruction. 3.9.7 software interrupt (swi) the software interrupt instruction ( swi ) is used for entering supervisor mode, usually to request a particular supervisor function. a swi handler should return by executing the following irrespective of the state (arm or thumb): mov pc, r14_svc this restores the pc and cpsr, and returns to the instruction following the swi . subs pc,r14_abt,#4 for a prefetch abort subs pc,r14_abt,#8 for a data abort arm.book page 15 wednesday, november 25, 1998 1:11 pm
3-16 programmers model 3.9.8 unde?ned instruction (udef) when ARM7TDMI comes across an instruction which it cannot handle, it takes the unde?ned instruction trap. this mechanism may be used to extend either the thumb or arm instruction set by software emulation. after emulating the failed instruction, the trap handler should execute the following irrespective of the state (arm or thumb): movs pc,r14_und this restores the cpsr and returns to the instruction following the unde?ned instruction. 3.9.9 exception vectors table 3.3 lists the exception vector addresses. 3.9.10 exception priorities when multiple exceptions arise at the same time, a ?xed priority system determines the order in which they are handled: highest priority: 1. reset 2. data abort table 3.3 exception vectors address exception mode on entry 0x00000000 reset supervisor 0x00000004 undefined instruction undefined 0x00000008 software interrupt supervisor 0x0000000c abort (prefetch) abort 0x00000010 abort (data) abort 0x00000014 reserved reserved 0x00000018 irq irq 0x0000001c fiq fiq arm.book page 16 wednesday, november 25, 1998 1:11 pm
interrupt latencies 3-17 3. fiq 4. irq 5. prefetch abort lowest priority: 6. unde?ned instruction, software interrupt. 3.9.10.1 not all exceptions can occur at once unde?ned instruction and software interrupt are mutually exclusive, since they each correspond to particular (nonoverlapping) decodings of the current instruction. if a data abort occurs at the same time as a fiq, and fiqs are enabled (i.e., the cpsrs f ?ag is clear), ARM7TDMI enters the data abort handler and then immediately proceeds to the fiq vector. a normal return from fiq will cause the data abort handler to resume execution. placing data abort at a higher priority than fiq is necessary to ensure that the transfer error does not escape detection. the time for this exception entry should be added to worst-case fiq latency calculations. 3.10 interrupt latencies the worst case latency for fiq, assuming that it is enabled, consists of the longest time the request can take to pass through the synchronizer ( tsyncmax if asynchronous), plus the time for the longest instruction to complete ( tldm , the longest instruction is an ldm which loads all the registers including the pc), plus the time for the data abort entry ( tex c ), plus the time for fiq entry ( t?q ). at the end of this time ARM7TDMI will be executing the instruction at 0x1c. tsyncmax is three processor cycles, tldm is 20 cycles, tex c is three cycles, and t?q is two cycles. the total time is therefore 28 processor cycles. this is just over 1.4 microseconds in a system which uses a continuous 20 mhz processor clock. the maximum irq latency calculation is similar, but must allow for the fact that fiq has higher priority and could delay entry into the irq handling routine for an arbitrary length of time. the minimum latency for fiq or irq consists of the shortest time the request can take through the synchronizer ( tsyncmin ) plus t?q . this is four processor cycles. arm.book page 17 wednesday, november 25, 1998 1:11 pm
3-18 programmers model 3.11 reset when the nreset signal goes low, ARM7TDMI abandons the executing instruction and then continues to fetch instructions from incrementing word addresses. when nreset goes high again, ARM7TDMI: 1. overwrites r14_svc and spsr_svc by copying the current values of the pc and cpsr into them. the value of the saved pc and spsr is not de?ned. 2. forces m[4:0] to 0b10011 (supervisor mode), sets the i and f bits in the cpsr, and clears the cpsrs t bit. 3. forces the pc to fetch the next instruction from address 0x00. 4. execution resumes in arm state. 3.12 pipeline architecture the ARM7TDMI core implements a three-stage pipeline (instruction fetch, decode, and execute) that always executes instructions in the order received and is fully interlocked in hardware. figure 3.7 shows the ARM7TDMI three-stage pipeline. figure 3.7 ARM7TDMI pipeline the execution of a single ARM7TDMI instruction consists of the following pipeline stages: 1. instruction fetch (if) C the core fetches the instruction from memory. 2. decode (d) C the core decodes the instruction and determines which registers are needed for this operation. if necessary, the core decompresses a 16-bit thumb instruction into a 32-bit arm instruction. d x decode execute instruction fetch if arm.book page 18 wednesday, november 25, 1998 1:11 pm
pipeline architecture 3-19 3. execute (x) C the core reads from the necessary register bank, executes all shift and alu operations, and writes results to the appropriate register bank. pipeline operation is identical for both arm and thumb modes of operation. when in thumb mode, the core decompresses each thumb instruction (in the d stage) to provide the equivalent information that a decoded arm instruction would provide. the only pipeline difference between arm and thumb mode is how the core handles the pc register (r15). the core increments pc by four addresses after each arm instruction fetch, or by two addresses for each thumb instruction fetch. figure 3.8 shows the ARM7TDMI pipeline executing code where all instructions operate on data already available in the cpu registers. figure 3.8 pipeline best case example the only bus traf?c in figure 3.8 is from instruction fetches; one memory access for each instruction executed. in this example, the pipeline is working as ef?ciently as possible; there are no wasted slots in the pipeline and the pipeline is never stalled. figure 3.8 is a good example of a smooth and continuous pipeline ?ow. of course, the ARM7TDMI pipeline doesnt always run so smoothly and other events can interrupt the pipeline operation. speci?cally, there are four effects that can disrupt the continuous operation of the pipeline: changes to the pc that cause changes in the program ?ow hardware interrupts that cause changes to the program ?ow multicycle instructions instructions that require data accesses to memory if d x if d x if d x add add mov if d x if d x and orr arm.book page 19 wednesday, november 25, 1998 1:11 pm
3-20 programmers model changes to pc C the pc (r15) can change due to a direct modi?cation, a branch operation, or an exception. when such a change in program ?ow occurs, the core ?ushes the pipeline and directs the ?rst pipeline stage to fetch the instruction pointed to by the new pc value. figure 3.9 shows the ARM7TDMI pipeline executing code in arm mode when a branch instruction occurs. figure 3.9 pipeline branch example following the branch ( bl ) instruction, two instructions are fetched (prefetched) in the branch shadow. since the arm architecture does not allow for branch delay slots, these two instructions are discarded before either reaches the execute stage. after these two discarded instructions, the pipeline ?ow returns to normal operation. the third instruction and all subsequent instructions will fetch, decode, and execute as normal. hardware interrupts C when an interrupt activates, it changes the program ?ow and alters the pipeline execution. the core completes current instruction execution, ?ushes the pipeline, and directs the ?rst stage in the pipeline to fetch a new instruction from the interrupt exception vector address. worst-case interrupt latencies are discussed in section 3.10, interrupt latencies. figure 3.10 shows the ARM7TDMI pipeline operation when the ?ow is interrupted by an interrupt irq. if d x if d if bl +4 +8 if d x if d x next completed instruction +4 if d x +8 linkret adjust arm.book page 20 wednesday, november 25, 1998 1:11 pm
pipeline architecture 3-21 figure 3.10 pipeline interrupt example in figure 3.10 , the interrupt arrival in cycle 1 (irq) causes the core to drain the pipeline, which discards the two prefetched instructions. r15 is then set to the exception vector value (0x18 in this example), which contains a branch instruction to the exception routine. this second branch triggers a second pipeline drain in cycle 4. an equivalent fiq situation could have a lower latency than shown in figure 3.10 , because the fiq vector is the last vector (at address 0x1c.) therefore, the fiq exception routine could start directly after the ?rst branch address, rather than branching again to a different address. multicycle instructions C these instructions reach the if stage of the pipeline and remain there for multiple clock cycles, causing the remaining stages of the pipeline to stall. the mul (multiply) instruction is an example of an instruction that requires multiple cycles to execute. instructions that access data memory C when instructions need to access data memory, they occupy bus bandwidth, which prevents new instructions from being fetched from memory. the pipeline stalls while data memory is accessed and this ultimately leads to wasted execution slots. figure 3.11 shows ARM7TDMI pipeline operation during code execution that includes a data fetch from memory. if d x if d if add mov add if d x if d branch to routine (0x18) +4 if +8 if d x if d exception routine +4 if +8 irq 1234567 linkret adjust arm.book page 21 wednesday, november 25, 1998 1:11 pm
3-22 programmers model figure 3.11 pipeline data memory access example when the ldr instruction executes, it causes the pipeline to stall for two cycles. the core has already fetched the two instructions subsequent to the ldr and they remain in the pipeline. these two instructions are stalled but not discarded, as in a branch or interrupt operation. in the ?rst stall cycle (cycle 4), the core reads data for the ldr from memory. in the second stall cycle (cycle 5), the core writes the data to the internal register ?le. if the example contained an str (store register) instruction rather than ldr , the pipeline would stall for a single cycle for a write to memory. str does not require a register write back. so far, the pipeline operation examples have assumed that nwait is never asserted. if the core asserts nwait in any clock cycle, this stops the core clock, so that all stages of the pipeline (and everything else in the core) stop while nwait remains asserted. nwait clearly has an important effect on execution time and interrupt latency in any real system. if d x if d x if d x add add ldr if d mov 123456 x data writebk if add d arm.book page 22 wednesday, november 25, 1998 1:11 pm
book title 4-1 chapter 4 arm instruction set summary this chapter proviides a summary of the arm instruction set. it contains the following sections: section 4.1, instruction set summary, page 4-1 section 4.2, format summary, page 4-3 section 4.3, instruction condition field, page 4-4 section 4.4, instruction set examples, page 4-5 for detailed information on the arm instruction set, see the arm architectural reference manual . 4.1 instruction set summary the arm instruction set is summarized below. table 4.1 arm instruction set mnemonic instruction action adc add with carry rd : = rn + op2 + carry add add rd : = rn + op2 and and rd : = rn and op2 b branch r15 : = address bic bit clear rd : = rn and not op2 bl branch with link r14 : = r15, r15 := address (sheet 1 of 3) arm.book page 1 wednesday, november 25, 1998 1:11 pm
4-2 arm instruction set summary bx branch and exchange r15 : = rn, t bit : = rn[0] cdp coprocessor data processing (coprocessor-speci?c) cmn compare negative cpsr ?ags : = rn + op2 cmp compare cpsr ?ags : = rn - op2 eor exclusive or rd : = (rn and not op2) or (op2 and not rn) ldc load coprocessor from memory coprocessor load ldm load multiple registers stack manipulation (pop) ldr load register from memory rd : = (address) mcr move cpu register to coprocessor register crn : = rrn {crm} mla multiply accumulate rd : = (rm * rs) + rn mov move register or constant rd : = op2 mrc move from coprocessor register to cpu register rn : = crn {crm} mrs move psr status/?ags to register rn : = psr msr move register to psr status/?ags psr : = rm mul multiply rd : = rm * rs mvn move negative register rd : = 0xffffffff eor op2 orr or rd : = rn or op2 rsb reverse subtract rd : = op2 - rn rsc reverse subtract with carry rd : = op2 - rn - 1 + carry sbc subtract with carry rd : = rn - op2 - 1 + carry stc store coprocessor register to memory address : = crn stm store multiple stack manipulation (push) table 4.1 arm instruction set (cont.) mnemonic instruction action (sheet 2 of 3) arm.book page 2 wednesday, november 25, 1998 1:11 pm
format summary 4-3 4.2 format summary the arm instruction set formats are shown below. figure 4.1 arm instruction set formats str store register to memory

: = rd sub subtract rd : = rn - op2 swi software interrupt os call swp swap register with memory rd : = [rn], [rn] : = rm teq test bit wise equality cpsr ?ags : = rn eor op2 tst test bits cpsr ?ags : = rn and op2 table 4.1 arm instruction set (cont.) mnemonic instruction action (sheet 3 of 3) 3 1 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543 0 cond 0 0 1 opcode s rn rd operand 2 data processing/psr transfer cond 000000as rd rn rs 1001 rm multiply cond 00001uas rdhigh rdlow rn 1001 rm multiply long cond 00010b00 rn rd 00001001 rm single data swap cond 000100101111111111110001 rn br anch and exchange cond 0 0 0 p u 0 w l rn rd 00001sh1 rm halfword data transfer: register offset cond 0 0 0 p u 1 w l rn rd offset 1 s h 1 offset halfword data transfer: immediate offset cond 0 1 i p u b w l rn rd offset single data transfer cond 0 1 1 1 unde?ned cond 1 0 0 p u s w l rn register list block data transfer cond 101l offset branch cond 1 1 0 p u n w l rn crd cp# offset coprocessor data transfer arm.book page 3 wednesday, november 25, 1998 1:11 pm
4-4 arm instruction set summary note: some instruction codes are not de?ned but do not cause the unde?ned instruction trap to be taken, for instance a multiply instruction with bit 6 changed to a 1. these instructions should not be used, as their action may change in future arm implementations. 4.3 instruction condition field in arm state, all instructions are conditionally executed according to the state of the cpsr condition codes and the instructions condition ?eld. this ?eld (bits 31:28) determines the circumstances under which an instruction is to be executed. if the state of the c, n, z and v ?ags ful?ls the conditions encoded by the ?eld, the instruction is executed, otherwise it is ignored. there are sixteen possible conditions, each represented by a two character suf?x that can be appended to the instructions mnemonic. for example, a branch ( b in assembly language) becomes beq for branch if equal, which means the branch will only be taken if the z ?ag is set. in practice, ?fteen different conditions may be used: these are listed in table 4.2 . the sixteenth (0b1111) is reserved, and must not be used. cond 1110 cpopc crn crd cp# cp 0 crm coprocessor data operation cond 1110cpopcl crn rd cp# cp 1 crm coprocessor register transfer cond 1111 ignored by processor software interrupt 3 1 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543 0 arm.book page 4 wednesday, november 25, 1998 1:11 pm
instruction set examples 4-5 in the absence of a suf?x, the condition ?eld of most instructions is set to always (suf?x al). this means the instruction will always be executed regardless of the cpsr condition codes. 4.4 instruction set examples the following examples show ways in which the basic core instructions can combine to give ef?cient code. none of these methods saves a great deal of execution time (although they may save some), mostly they just save code. table 4.2 condition code summary code suf?x flags meaning 0b0000 eq z set equal 0b0001 ne z clear not equal 0b0010 cs c set unsigned higher or same 0b0011 cc c clear unsigned lower 0b0100 mi n set negative 0b0101 pl n clear positive or zero 0b0110 vs v set over?ow 0b0111 vc v clear no over?ow 0b1000 hi c set and z clear unsigned higher 0b1001 ls c clear or z set unsigned lower or same 0b1010 ge n equals v greater or equal 0b1011 lt n not equal to v less than 0b1100 gt z clear and (n equals v) greater than 0b1101 le z set or (n not equal to v) less than or equal 0b1110 al (ignored) always arm.book page 5 wednesday, november 25, 1998 1:11 pm
4-6 arm instruction set summary 4.4.1 using the conditional instructions 4.4.1.1 using conditionals for logical or cmp rn,#p ; if rn = p or rm = q then goto ; label. beq label cmp rm,#q beq label this can be replaced by cmp rn,#p cmpne rm,#q ; if condition not satisfied try ; other test. beq label 4.4.1.2 absolute value teq rn,#0 ; test sign rsbmi rn,rn,#0 ; and 2's complement if necessary. 4.4.1.3 multiplication by 4, 5 or 6 (run time) mov rc,ra,lsl#2; multiply by 4, cmp rb,#5 ; test value, addcs rc,rc,ra ; complete multiply by 5, addhi rc,rc,ra ; complete multiply by 6. 4.4.1.4 combining discrete and range tests teq rc,#127 ; discrete test, cmpne rc,# -1 ; range test movls rc,#. ; if rc<= or rc=ascii(127) ; then rc:=. 4.4.1.5 division and remainder a short general purpose divide routine follows. ; enter with numbers ; in ra and rb. ; mov rcnt,#1 ; bit to control the ; division. div1 cmp rb,#0x80000000 ; move rb until ; greater than ra. arm.book page 6 wednesday, november 25, 1998 1:11 pm
instruction set examples 4-7 cmpcc rb,ra movcc rb,rb,asl#1 movcc rcnt,rcnt,asl#1 bcc div1 mov rc,#0 div2 cmp ra,rb ; test for possible ; subtraction. subcs ra,ra,rb ; subtract if ok, addcs rc,rc,rcnt ; put relevant bit ; into result movs rcnt,rcnt,lsr#1 ; shift control bit movne rb,rb,lsr#1 ; halve unless ; finished. bne div2 ; ; divide result in rc, ; remainder in ra. 4.4.1.6 over?ow detection in the ARM7TDMI over?ow in unsigned multiply with a 32-bit result umull rd,rt,rm,rn ;3 to 6 cycles teq rt,#0 ;+ 1 cycle and a register bne overflow over?ow in signed multiply with a 32-bit result smull rd,rt,rm,rn ;3 to 6 cycles teq rt,rd asr#31 ;+ 1 cycle and a register bne overflow over?ow in unsigned multiply accumulate with a 32-bit result umlal rd,rt,rm,rn ;4 to 7 cycles teq rt,#0 ;+ 1 cycle and a register bne overflow over?ow in signed multiply accumulate with a 32-bit result smlal rd,rt,rm,rn ;4 to 7 cycles teq rt,rd, asr#31 ;+ 1 cycle and a register bne overflow over?ow in unsigned multiply accumulate with a 64-bit result umull rl,rh,rm,rn ;3 to 6 cycles adds rl,rl,ra1 ;lower accumulate adc rh,rh,ra2 ;upper accumulate bcs overflow ;1 cycle and 2 registers arm.book page 7 wednesday, november 25, 1998 1:11 pm
4-8 arm instruction set summary over?ow in signed multiply accumulate with a 64-bit result smull rl,rh,rm,rn ;3 to 6 cycles adds rl,rl,ra1 ;lower accumulate adc rh,rh,ra2 ;upper accumulate bvs overflow ;1 cycle and 2 registers note: over?ow checking is not applicable to unsigned and signed multiplies with a 64-bit result, since over?ow does not occur in such calculations. 4.4.2 pseudo-random binary sequence generator it is often necessary to generate (pseudo-) random numbers and the most ef?cient algorithms are based on shift generators with exclusive-or feedback rather like a cyclic redundancy check generator. unfortunately the sequence of a 32-bit generator needs more than one feedback tap to be maximal length (i.e. 2^32 - 1 cycles before repetition), so this example uses a 33-bit register with taps at bits 33 and 20. the basic algorithm is newbit: = bit 33 eor bit 20, shift left the 33-bit number and put in newbit at the bottom; this operation is performed for all the new bits needed (i.e. 32 bits). the entire operation can be done in 5 s cycles: ; enter with seed in ra (32 bits), rb (1 bit in rb lsb), uses rc. ; tst rb,rb,lsr#1 ; top bit into carry movs rc,ra,rrx ; 33-bit rotate right adc rb,rb,rb ; carry into lsb of rb eor rc,rc,ra,lsl#12 ; (involved!) eor ra,rc,rc,lsr#20 ; (similarly involved!) ; new seed in ra, rb as before 4.4.3 multiplication by constant using the barrel shifter multiplication by 2^n (1, 2, 4, 8, 16, 32..) mov ra, rb, lsl #n multiplication by 2^n + 1 (3, 5, 9, 17..) add ra,ra,ra,lsl #n multiplication by 2^n - 1 (3, 7, 15..) rsb ra,ra,ra,lsl #n arm.book page 8 wednesday, november 25, 1998 1:11 pm
instruction set examples 4-9 multiplication by 6 add ra,ra,ra,lsl #1; multiply by 3 mov ra,ra,lsl#1 ; and then by 2 multiply by 10 and add in extra number add ra,ra,ra,lsl#2; multiply by 5 add ra,rc,ra,lsl#1; multiply by 2 and add in next digit general recursive method for rb : = ra * c, c a constant: C if c even, say c = 2^n * d, d odd: d=1: mov rb,ra,lsl #n d<>1: {rb := ra*d} mov rb,rb,lsl #n C if c mod 4 = 1, say c = 2^n * d + 1, d odd, n > 1: d=1: add rb,ra,ra,lsl #n d<>1: {rb := ra*d} add rb,ra,rb,lsl #n C if c mod 4 = 3, say c = 2^n * d - 1, d odd, n > 1: d=1: rsb rb,ra,ra,lsl #n d<>1: {rb := ra*d} rsb rb,ra,rb,lsl #n this is not quite optimal, but close. for example, a multiply by 45 is done by: rsb rb,ra,ra,lsl#2 ; multiply by 3 rsb rb,ra,rb,lsl#2 ; multiply by 4 * 3 - 1 = 11 add rb,ra,rb,lsl# 2 ; multiply by 4 * 11 + 1 = 45 rather than by: add rb,ra,ra,lsl#3 ; multiply by 9 add rb,rb,rb,lsl#2 ; multiply by 5 * 9 = 45 arm.book page 9 wednesday, november 25, 1998 1:11 pm
4-10 arm instruction set summary 4.4.4 loading a word from an unknown alignment ; enter with address in ra (32 bits) ; uses rb, rc; result in rd. ; note d must be less than c e.g. 0,1 ; bic rb,ra,#3 ; get word aligned address ldmia rb,{rd,rc} ; get 64 bits containing answer and rb,ra,#3 ; correction factor in bytes movs rb,rb,lsl#3 ; ...now in bits and test if aligned movne rd,rd,lsr rb ; produce bottom of result word ; (if not aligned) rsbne rb,rb,#32 ; get other shift amount orrne rd,rd,rc,lsl rb ; combine two halves to get result arm.book page 10 wednesday, november 25, 1998 1:11 pm
book title 5-1 chapter 5 thumb instruction set summary this chapter describes the thumb instruction set. it contains the following sections: section 5.1, instruction set summary, page 5-1 section 5.2, format summary, page 5-3 section 5.3, instruction set examples, page 5-4 for detailed information on the thumb instruction set, see the arm architectural reference manual . 5.1 instruction set summary the following table summarizes the thumb instruction set. table 5.1 thumb instruction set mnemonic instruction equivalent arm instructions low register operand high register operand condition codes set adc add with carry adc 44 add add add 444 1 and logical and and 44 asr arithmetic shift right mov 44 b unconditional branch b 4 b xx conditional branch b 4 (sheet 1 of 3) arm.book page 1 wednesday, november 25, 1998 1:11 pm
5-2 thumb instruction set summary bic bit clear bic 44 bl branch and link bl bx branch and exchange bx 44 cmn compare negative cmn 44 cmp compare cmp 444 eor exclusive or eor 44 ldmia load multiple ldm 4 ldr load word ldr 4 ldrb load byte ldr 4 ldrh load halfword ldr 4 ldrsb load register signed byte ldr 4 ldrsh load register halfword ldr 4 lsl logical shift left mov 44 lsr logical shift right mov 44 mov move register mov 444 2 mul multiply mul 44 mvn move negative register mvn 44 neg negate rsb 44 orr logical or orr 44 pop pop registers ldm 4 push push registers ldm 4 ror rotate right mov 44 sbc subtract with carry sbc 44 table 5.1 thumb instruction set (cont.) mnemonic instruction equivalent arm instructions low register operand high register operand condition codes set (sheet 2 of 3) arm.book page 2 wednesday, november 25, 1998 1:11 pm
format summary 5-3 5.1.1 instruction cycle time all thumb instructions have an equivalent arm instruction as shown in the table above. the instruction cycle times for the thumb instructions are identical to that of the equivalent arm instruction. for more information on instruction cycle time, refer to chapter 10, instruction cycle operations. 5.2 format summary the thumb instruction set formats are shown in the following ?gure. stmia store multiple stm 4 str store word str 4 strb store byte str 4 strh store halfword str 4 sub subtract sub 44 swi software interrupt swi tst test bits tst 44 1. the condition codes are unaffected by the format 5, 12 and 13 versions of this instruction. 2. the condition codes are unaffected by the format 5 version of this instruction. table 5.1 thumb instruction set (cont.) mnemonic instruction equivalent arm instructions low register operand high register operand condition codes set (sheet 3 of 3) arm.book page 3 wednesday, november 25, 1998 1:11 pm
5-4 thumb instruction set summary figure 5.1 thumb instruction set formats 5.3 instruction set examples the following examples show ways in which the thumb instructions may be used to generate small and ef?cient code. each example also shows the arm equivalent so these may be compared. 5.3.1 multiplication by a constant using shifts and adds the following shows code to multiply by various constants using one, two or three thumb instructions along side the arm equivalents. for other constants it is generally better to use the built-in mul instruction rather than using a sequence of four or more instructions. 15 14 13 12 11 10 9 8 7 6 5 3 2 0 1 0 0 0 op offset5 rs rd move shifted register 2 0 0 0 1 1 1 op rn/offset3 rs rd add/subtract 3 0 0 1 op rd offset8 move/compare/add/subtract/immediate 4 0 1 0 0 0 0 op rs rd alu operations 5 0 1 0 0 0 1 op h1 h2 rs/hs rd/hd hi register operations/branch exchange 6 0 1 0 0 1 rd word8 pc relative load 7 0 1 0 1 l s 0 ro rb rd load/store with register offset 8 0 1 0 1 h s 1 ro rb rd load/store sign-extended byte/halfword 9 0 1 1 b l offset5 rb rd load/store with immediate offset 10 1 0 0 0 l offset5 rb rd load/store halfword 11 1 0 0 1 l rd work8 sp-relative load/store 12 1 0 1 0 sp rd work8 load address 13 1 0 1 1 0 0 0 0 s sword7 add offset to stack pointer 14 1 0 1 1 l 1 0 r rlist push/pop registers 15 1 1 0 0 l rb rlist multiple load/store 16 1 1 0 1 cond soffset8 conditional branch 17 1 1 0 1 1 1 1 1 value8 software interrupt 18 1 1 1 0 0 offset11 unconditional branch 19 1 1 1 1 h offset long branch with link arm.book page 4 wednesday, november 25, 1998 1:11 pm
instruction set examples 5-5 thumb arm multiplication by 2^n (1, 2, 4, 8, ...) lsl ra, rb, lsl #n mov ra, rb, lsl #n multiplication by 2^n + 1 (3, 5, 9, 17, ...) lsl rt, rb, #n add ra, rb, rb, lsl #n add ra, rt, rb multiplication by 2^n - 1 (3, 7, 15, ...) lsl rt, rb, #n rsb ra, rb, rb, lsl #n sub ra, rt, rb multiplication by - 2^n ( - 2, - 4, - 8, ...) lsl ra, rb, #n mov ra, rb, lsl #n mvn ra, ra rsb ra, ra, #0 multiplication by - 2^n - 1( - 3, - 7, - 15, ...) lsl rt, rb, #n sub ra, rb, rb, lsl #n sub ra, rb, rt multiplication by any c = {2^n + 1, 2^n - 1, - 2^n or - 2^n - 1} * 2^n effectively this is any of the multiplications in 2 to 5 followed by a ?nal shift. this allows the following additional constants to be multiplied. 6, 10, 12, 14, 18, 20, 24, 28, 30, 34, 36, 40, 48, 56, 60, 62 ..... (2..5) (2..5) lsl ra, ra, #n mov ra, ra, lsl #n 5.3.2 general purpose signed divide this example shows a general purpose signed divide and remainder routine in both thumb and arm code. arm.book page 5 wednesday, november 25, 1998 1:11 pm
5-6 thumb instruction set summary 5.3.2.1 thumb code signed_divide ; signed divide of r1 by r0: returns quotient in r0, ; remainder in r1 ; get abs value of r0 into r3 asr r2, r0, #31 ; get 0 or -1 in r2 depending ; on sign of r0 eor r0, r2 ; eor with -1 (0xffffffff) if ; negative sub r3, r0, r2 ; and add 1 (sub -1) to get ; abs value ; sub always sets flag so go & report division by 0 if ; necessary ; beq divide_by_zero ; get abs value of r1 by xoring with 0xffffffff and adding 1 ; if negative asr r0, r1, #31 ; get 0 or -1 in r3 depending ; on sign of r1 eor r1, r0 ; eor with -1 (0xffffffff) if ; negative sub r1, r0 ; and add 1 (sub -1) to get ; abs value ; save signs (0 or - 1 in r0 & r2) for later use in ; determining sign of quotient & remainder. push {r0, r2} ; justification, shift 1 bit at a time until divisor (r0 ; value) is just <= than dividend (r1 value). to do this ; shift dividend right by 1 and stop as soon as shifted ; value becomes >. lsr r0, r1, #1 mov r2, r3 b %ft0 just_llsl r2, #1 0 cmp r2, r0 bls just_l mov r0, #0 ; set accumulator to 0 b %ft0 ; branch into division loop div_l lsr r2, #1 0 cmp r1, r2 ; test subtract bcc %ft0 sub r1, r2 ; if successful do a real arm.book page 6 wednesday, november 25, 1998 1:11 pm
instruction set examples 5-7 ; subtract 0 adc r0, r0 ; shift result and add 1 if ; subtract succeeded cmp r2, r3 ; terminate when r2 == r3 (we ; have just bne div_l ; tested subtracting the ; 'ones' value) ; now fixup the signs of the quotient (r0) and ; remainder (r1) pop {r2, r3} ; get dividend/divisor signs ; back eor r3, r2 ; result sign eor r0, r3 ; negate if result sign = - 1 sub r0, r3 eor r1, r2 ; negate remainder if dividend ; sign = - 1 sub r1, r2 mov pc, lr 5.3.2.2 arm code signed_divide ; effectively zero a4 as top bit will be shifted out later ands a4, a1, #&80000000 rsbmi a1, a1, #0 eors ip, a4, a2, asr #32 ; ip bit 31 = sign of result ; ip bit 30 = sign of a2 rsbcs a2, a2, #0 ; central part is identical code to udiv ; (without mov a4, #0 which comes for free as part of signed ; entry sequence) movs a3, a1 beq divide_by_zero just_l ; justification stage shifts 1 bit at a time cmp a3, a2, lsr #1 movls a3, a3, lsl #1 ; nb: lsl #1 is always ok if ls succeeds blo s_loop arm.book page 7 wednesday, november 25, 1998 1:11 pm
5-8 thumb instruction set summary div_l cmp a2, a3 adc a4, a4, a4 subcs a2, a2, a3 teq a3, a1 movne a3, a3, lsr #1 bne s_loop2 mov a1, a4 movs ip, ip, asl #1 rsbcs a1, a1, #0 rsbmi a2, a2, #0 mov pc, lr 5.3.3 division by a constant division by a constant can often be performed by a short ?xed sequence of shifts, adds and subtracts. for an explanation of the algorithm see the arm cookbook (arm duyi-0005b), section entitled division by a constant . here is an example of a divide by 10 routine based on the algorithm in the arm cookbook in both thumb and arm code. 5.3.3.1 thumb code udiv10 ; takes argument in a1 ; returns quotient in a1, remainder in a2 mov a2, a1 lsr a3, a1, #2 sub a1, a3 lsr a3, a1, #4 add a1, a3 lsr a3, a1, #8 add a1, a3 lsr a3, a1, #16 add a1, a3 lsr a1, #3 asl a3, a1, #2 add a3, a1 asl a3, #1 sub a2, a3 cmp a2, #10 blt %ft0 arm.book page 8 wednesday, november 25, 1998 1:11 pm
instruction set examples 5-9 add a1, #1 sub a2, #10 0 mov pc, lr 5.3.3.2 arm code udiv10 ; takes argument in a1 ; returns quotient in a1, remainder in a2 sub a2, a1, #10 sub a1, a1, a1, lsr #2 add a1, a1, a1, lsr #4 add a1, a1, a1, lsr #8 add a1, a1, a1, lsr #16 mov a1, a1, lsr #3 add a3, a1, a1, asl #2 subs a2, a2, a3, asl #1 addpl a1, a1, #1 addmi a2, a2, #10 mov pc, lr arm.book page 9 wednesday, november 25, 1998 1:11 pm
5-10 thumb instruction set summary arm.book page 10 wednesday, november 25, 1998 1:11 pm
book title 6-1 chapter 6 memory interface this chapter describes the ARM7TDMI memory interface. it contains the following sections: section 6.1, overview, page 6-1 section 6.2, cycle types, page 6-2 section 6.3, address timing, page 6-4 section 6.4, data transfer size, page 6-7 section 6.5, instruction fetch, page 6-8 section 6.6, memory management, page 6-10 section 6.7, locked operations, page 6-10 section 6.8, stretching access times, page 6-11 section 6.9, ARM7TDMI data bus, page 6-11 section 6.10, external data bus, page 6-13 6.1 overview ARM7TDMIs memory interface consists of the following basic elements: 32-bit address bus this speci?es to memory the location to be used for the transfer. 32-bit data bus instructions and data are transferred across this bus. data may be word, halfword, or byte wide in size. a bidirectional data bus, d[31:0], and separate unidirectional data buses, din[31:0] and dout[31:0]. arm.book page 1 wednesday, november 25, 1998 1:11 pm
6-2 memory interface most of the text in this chapter describes the bus behavior assuming that the bidirectional bus is in use. however, the behavior applies equally to the unidirectional buses. control signals these specify, for example, the size of the data to be transferred, and the direction of the transfer together with providing privileged information. this collection of signals allow the core to be simply interfaced to dram, sram and rom. to fully exploit page mode access to dram, information is provided on whether or not the memory accesses are sequential. in general, interfacing to static memories is much simpler than interfacing to dynamic memory. 6.2 cycle types all memory transfer cycles can be placed in one of four categories: 1. nonsequential cycle. the core requests a transfer to or from an address which is unrelated to the address used in the preceding cycle. 2. sequential cycle. the core requests a transfer to or from an address which is either the same as the address in the preceding cycle, or is one word or halfword after the preceding address. 3. internal cycle. the core does not require a transfer, as it is performing an internal function and no useful prefetching can be performed at the same time. 4. coprocessor register transfer. the core wishes to use the data bus to communicate with a coprocessor, but does not require any action by the memory system. these four classes are distinguishable to the memory system by inspection of the nmreq and seq control lines, see table 6.1 . these control lines are generated during phase 1 of the cycle before the cycle whose characteristics they forecast, and this pipelining of the control information gives the memory system suf?cient time to decide whether or not it can use a page mode access. arm.book page 2 wednesday, november 25, 1998 1:11 pm
cycle types 6-3 figure 6.1 shows the pipelining of the control signals, and suggests how the dram address strobes (nras and ncas) might be timed to use page mode for s-cycles. note that the n-cycle is longer than the other cycles. this is to allow for the dram precharge and row access time, and is not a core requirement. figure 6.1 arm memory cycle timing when an s-cycle follows an n-cycle, the address will always be one word or halfword greater than the address used in the n-cycle. this address (marked a in the above diagram) should be checked to ensure that it is not the last in the dram page before the memory system commits to the s-cycle. if it is at the page end, the s-cycle cannot be performed in page mode and the memory system will have to perform a full access. table 6.1 memory cycle types nmreq seq cycle type 0 0 nonsequential (n-cycle) 0 1 sequential (s-cycle) 1 0 internal (i-cycle) 1 1 coprocessor register transfer (c-cycle) mclk a[31:0] nmreq seq ncas i-cycle s-cycle c-cycle n-cycle nras d[31:0] a a + 4 a + 8 arm.book page 3 wednesday, november 25, 1998 1:11 pm
6-4 memory interface the processor clock must be stretched to match the full access. when an s-cycle follows an i-cycle, the address will be the same as that used in the i-cycle. this fact may be used to start the dram access during the preceding cycle, which enables the s-cycle to run at page mode speed while performing a full dram access. this is shown in figure 6.2 . figure 6.2 memory cycle optimization . 6.3 address timing ARM7TDMIs address bus can operate in one of two con?gurations pipelined or depipelinedthis is controlled by the ape input signal. these con?gurations make it easy to design both sram and dram based systems with the ARM7TDMI core. it is a requirement of srams and roms that the address be held stable throughout the memory cycle. in a system containing sram and rom only, ape may be tied permanently low, producing the desired address timing. this is shown in figure 6.3 . note: ape effects the timing of the address bus a[31:0], plus nrw, mas[1:0], lock, nopc and ntrans. mclk a[31:0] nmreq seq ncas i-cycle s-cycle nras d[31:0] arm.book page 4 wednesday, november 25, 1998 1:11 pm
address timing 6-5 figure 6.3 ARM7TDMI depipelined addresses in a dram based system, it is desirable to obtain the address from the core as early as possible. when ape is high, the core's address becomes valid in the mclk high phase before the memory cycle to which it refers. this timing allows longer for address decoding and the generation of dram control signals. figure 6.4 shows the effect on the timing when ape is high. figure 6.4 ARM7TDMI pipelined addresses many systems will contain a mixture of dram and sram/rom. to cater to the different address timing requirements, ape may be safely changed during the low phase of mclk. typically, ape would be held at one level during a burst of sequential accesses to one type of memory. when a nonsequential access occurs, the timing of most systems enforces a wait state to allow for address decoding. as a result of the address decode, ape can be driven to the correct value for the particular bank of memory being accessed. the value of ape can be held until the memory control signals denote another nonsequential access. mclk ape nmreq seq a[31:0] d[31:0] mclk ape nmreq seq a[31:0] d[31:0] arm.book page 5 wednesday, november 25, 1998 1:11 pm
6-6 memory interface by way of an example, figure 6.5 , shows a combination of accesses to a mixed dram/sram system. here, the sram has zero wait states, and the dram has a 2:1 n-cycle/s-cycle ratio. a single wait state is inserted for address decode when a nonsequential access occurs. typical, externally generated dram control signals are also shown. figure 6.5 typical system timing previous arm processors included the ale signal, and this is retained for backwards compatibility. this signal also allows the address timing to be modi?ed to achieve the same results as ape, but in an asynchronous manner. to obtain clean mclk low timing of the address bus by this mechanism, ale must be driven high with the falling edge of mclk, and low with the rising edge of mclk. ale can simply be the inverse of mclk but the delay from mclk to ale must be carefully controlled so that the tald timing constraint is achieved. figure 6.6 shows how ale can be used to achieve sram compatible address timing. refer to cw001007 ARM7TDMI microprocessor core datasheet for details of the exact timing constraints. mclk nmreq seq a[31:0] nrw nwait ape d[31:0] dbe sram cycles decode dram cycles decode sram cycles n n a a + 4 a + 8 b b + 4 b + 8 c c + 4 c + 8 nras ncas arm.book page 6 wednesday, november 25, 1998 1:11 pm
data transfer size 6-7 figure 6.6 sram compatible address timing note: if ale is to be used to change address timing, then ape must be tied high. similarly, if ape is to be used, ale must be tied high. 6.4 data transfer size in an ARM7TDMI core system, words, halfwords or bytes may be transferred between the processor and the memory. the size of the transaction taking place is determined by the mas[1:0 ] pins. these are encoded as follows: mas[1:0] 00 byte 01 halfword 10 word 11 reserved the processor always produces a byte address, but instructions are either words (4 bytes) or halfwords (2 bytes), and data can be any size. note that when word instructions are fetched from memory, a[1:0] are unde?ned and when halfword instructions are fetched, a[0] is unde?ned. the mas[1:0] outputs share the same timing as the address bus and thus can be modi?ed by the use of ale and ape as described in section 6.3, address timing. when a data read of byte or halfword size is performed (e.g., ldrb ), the memory system may safely ignore the fact that the request is for a subword sized quantity and present the whole word. the core will always mclk ape nmreq seq a[31:0] d[31:0] ale arm.book page 7 wednesday, november 25, 1998 1:11 pm
6-8 memory interface correctly extract the addressed byte or halfword from the data. the memory system may also choose just to supply the addressed byte or halfword. this may be desirable in order to save power or to simplify the decode logic. when a byte or halfword write occurs (e.g., strh ), the core will broadcast the byte or halfword across the whole of the bus. the memory system must then decode a[1:0] to enable writing only to the addressed byte or halfword. one way of implementing the byte decode in a dram system is to separate the 32-bit wide block of dram into four byte wide banks, and generate the column address strobes independently as shown in figure 6.7 . when the processor is con?gured for little endian operation, byte 0 of the memory system should be connected to data lines 7 through 0 (d[7:0]) and strobed by ncas0. ncas1 drives the bank connected to data lines 15 though 8, and so on. this has the added advantage of reducing the load on each column strobe driver, which improves the precision of this time-critical signal. in the big endian case, byte 0 of the memory system should be connected to data lines 31 through 24 . 6.5 instruction fetch ARM7TDMI will perform 32- or 16-bit instruction fetches depending on whether the processor is in arm or thumb state. the processor state may be determined externally by the value of the tbit signal. when this is low, the processor is in arm state and 32-bit instructions are fetched. when tbit is high, the processor is in thumb state and 16-bit instructions are fetched. the size of the data being fetched is also indicated on the mas[1:0] bits, as described in section 6.4, data transfer size. when the processor is in arm state, 32-bit instructions are fetched on d[31:0]. when the processor is in thumb state, 16-bit instructions are fetched from either the upper, d[31:16], or the lower d[15:0] half of the bus. this is determined by the endian con?guration of the memory arm.book page 8 wednesday, november 25, 1998 1:11 pm
instruction fetch 6-9 system, as con?gured by the bigend input, and the state of a[1]. table 6.2 shows which half of the data bus is sampled in the different con?gurations. when a 16-bit instruction is fetched, the core ignores the unused half of the data bus. table 6.2 describes instructions fetched from the bidirectional data bus (i.e. busen is low). when the unidirectional data buses are in use (i.e. busen is high), data will be fetched from the corresponding half of the din[31:0] bus. figure 6.7 decoding byte accesses to memory table 6.2 endian con?guration effect on instruction position little endian bigend = 0 big endian bigend = 1 a[1] = 0 d[15:0] d[31:16] a[1] = 1 d[31:16] d[15:0] a0 a1 mas0 mas1 mas0 mas1 mclk cas g dq quad latch ncas3 ncas2 ncas1 ncas0 arm.book page 9 wednesday, november 25, 1998 1:11 pm
6-10 memory interface 6.6 memory management the core address bus may be processed by an address translation unit before being presented to the memory, and the core is capable of running a virtual memory system. the abort input to the processor may be used by the memory manager to inform the core of page faults. various other signals enable different page protection levels to be supported: nrw can be used by the memory manager to protect pages from being written to. ntrans indicates whether the processor is in user or a privileged mode, and may be used to protect system pages from the user, or to support completely separate mappings for the system and the user. address translation will normally only be necessary on an n-cycle, and this fact may be exploited to reduce power consumption in the memory manager and avoid the translation delay at other times. the times when translation is necessary can be deduced by keeping track of the cycle types that the processor uses. 6.7 locked operations the arm instruction set includes a data swap ( swp ) instruction that allows the contents of a memory location to be swapped with the contents of a processor register. this instruction is implemented as an uninterruptable pair of accesses; the ?rst access reads the contents of the memory, and the second writes the register data to the memory. these accesses must be treated as a contiguous operation by the memory controller to prevent another device from changing the affected memory location before the swap is completed. the core drives the lock signal high for the duration of the swap operation to warn the memory controller not to give the memory to another device. arm.book page 10 wednesday, november 25, 1998 1:11 pm
stretching access times 6-11 6.8 stretching access times all memory timing is de?ned by mclk, and long access times can be accommodated by stretching this clock. it is usual to stretch the low period of mclk, as this allows the memory manager to abort the operation if the access is eventually unsuccessful. either mclk can be stretched before it is applied to the core, or the nwait input can be used together with a free-running mclk. taking nwait low has the same effect as stretching the low period of mclk, and nwait must only change when mclk is low. the core does not contain any dynamic logic which relies upon regular clocking to maintain its internal state. therefore there is no limit upon the maximum period for which mclk may be stretched, or nwait held low. 6.9 ARM7TDMI data bus to ease the connection of the core to subword sized memory systems, input data and instructions may be latched on a byte by byte basis. this is achieved by use of the bl[3:0] input signals where bl[3] controls the latching of the data present on d[31:24] of the data bus and so on. in a memory system containing word wide memory only, bl[3:0] may be tied high. for subword wide memory systems, bl[3:0] are used to latch the data as it is read out of memory. for example, a word access to halfword wide memory must take place in two memory cycles. in the ?rst cycle, the data for d[15:0] is obtained from the memory and latched into the processor on the falling edge of mclk when bl[1:0] are both high. in the second cycle, the data for d[31:16] is latched into the processor on the falling edge of mclk when bl[3:2] are both high. a memory access like this is shown in figure 6.8 . here, a word access is performed from halfword wide memory in two cycles. in the ?rst, the data read is applied to the lower half of the bus, in the second cycle the read data is applied to the upper half of the bus. since two memory cycles were required, nwait is used to stretch the internal processor clock. however, nwait does not effect the operation of the data latches. in this way, data may be extracted from memory word, halfword or byte arm.book page 11 wednesday, november 25, 1998 1:11 pm
6-12 memory interface at a time, and the memory may have as many wait states as required. in any multicycle memory access, nwait is held low until the ?nal quantum of data is latched. in this example, bl[3:0] were driven to value 0x3 in the ?rst cycle so that only the latches on d[15:0] were opened. in fact, bl[3:0] could have been driven to value 0xf and all the latches opened. since in the second cycle, the latches on d[31:16] were written with the correct data, this would not have effected the processor's operation. note: bl[3:0] should all be high during store cycles. figure 6.8 memory access as a further example, a halfword load from 2-wait state byte-wide memory is shown in figure 6.9 . here, each memory access takes two cycles. in the ?rst, access, bl[3:0] are driven to value 0xf. the correct data is latched from d[7:0] while unknown data is latched from d[31:8]. in the second access, the byte for d[15:8] is latched and so the halfword on d[15:0] has been correctly read from the memory. the fact that internally d[31:16] are unknown does not matter because internally the processor will extract only the halfword it is interested in. mclk ape nmreq seq a[31:0] bl[3:0] nwait d[15:0] d[31:16] 0x3 0xc arm.book page 12 wednesday, november 25, 1998 1:11 pm
external data bus 6-13 figure 6.9 two cycle memory access 6.10 external data bus the core has a bidirectional data bus, d[31:0]. however, since some asic design methodologies prohibit the use of bidirectional buses, unidirectional data in, din[31:0], and data out, dout[31:0], buses are also provided. the logical arrangement of these buses is shown in figure 6.10. figure 6.10 ARM7TDMI external bus arrangement mclk ape nmreq seq a[31:0] bl[3:0] nwait d[7:0] d[15:8] 0xf 0x2 embeddedice ARM7TDMI g din[31:0] d[31:0] dout[31:0] macrocell arm.book page 13 wednesday, november 25, 1998 1:11 pm
6-14 memory interface when the bidirectional data bus is being used, the unidirectional buses must be disabled by driving busen low. the timing of the bus for three cycles, load-store-load, is shown in figure 6.11 . figure 6.11 bidirectional bus timing figure 6.12 unidirectional bus timing 6.10.1 the unidirectional data bus when the unidirectional data buses are being used, (i.e. when busen is high), the bidirectional bus, d[31:0], must be left unconnected. when busen is high, all instructions and input data are presented on the input data bus, din[31:0]. the timing of this data is similar to that of the bidirectional bus when in input mode. the setup and hold of the data must occur on the falling edge of mclk. for the exact timing requirements refer to cw001007 ARM7TDMI microprocessor core datasheet . in this con?guration, all output data is presented on dout[31:0]. the value on this bus only changes when the processor performs a store cycle. again, the timing of the data is similar to that of the bidirectional data bus. the value on dout[31:0] changes on the falling edge of mclk. read cycle store cycle read cycle mclk d[31:0] read cycle store cycle read cycle mclk din[31:0] dout[31:0] d[31:0] d1 d2 d1 d2 dout dout arm.book page 14 wednesday, november 25, 1998 1:11 pm
external data bus 6-15 the bus timing of a read-write-read cycle combination is shown in figure 6.12 . when busen is low, the buffer between din[31:0] and d[31:0] is disabled. any data presented on din[31:0] is ignored. also, when busen is low, the value on dout[31:0] is forced to 0x00000000. typically, the unidirectional buses would be used internally in asic embedded applications. externally, most systems still require a bidirectional data bus to interface to external memory. figure 6.13 , shows how the unidirectional buses may be joined up at the pads of an asic to connect to an external bidirectional bus. figure 6.13 external connection of unidirectional buses 6.10.2 bidirectional data bus the core has a bidirectional data bus, d[31:0]. most of the time, the core reads from memory and so this bus is con?gured to input. during write cycles however, the core must output data. during phase 2 of the previous cycle, the signal nrw is driven high to indicate a write cycle. during the actual cycle, nenout is driven low to indicate that the core is driving d[31:0] as an output. figure 6.14 shows this bus timing (dbe has been tied high in this example). figure 6.15 shows the circuit which exists in the core for controlling exactly when the external bus is driven out. nenout dout[31:0] din[31:0] pa d xdata[31:0] ARM7TDMI arm.book page 15 wednesday, november 25, 1998 1:11 pm
6-16 memory interface figure 6.14 data write bus cycle the core macrocell has an additional bus control signal, nenin , which allows the external system to manually 3-state the bus. in the simplest systems, nenin can be tied low and nenout can be ignored. however, in many applications when the external data bus is a shared resource, greater control may be required. in this situation, nenin can be used to delay when the external bus is driven. note that for backwards compatibility, dbe is also included. at the macrocell level, dbe and nenin have almost identical functionality and in most applications one can be tied off. section 6.10.3, example system: the ARM7TDMI test chip, describes how the core may be interfaced to an external data bus, using the ARM7TDMI test chip as an example. the core has another output control signal called tbe. this signal is normally only used during test and must be tied high when not in use. when driven low, tbe forces all 3-state outputs to high impedance. it is as if both dbe and abe have been driven low, causing the data bus, the address bus, and all other signals normally controlled by abe to become high impedance. note, however, that there is no scan cell on tbe. thus, tbe is completely independent of scan data and may be used to put the outputs into a high impedance state while scan testing takes place. table 6.3 lists the 3-state control of the core outputs. only signals with a 4 in the abe, dbe or tbe column can be driven to the high impedance state. memory cycle mclk a[31:0] nrw nenout d[31:0] arm.book page 16 wednesday, november 25, 1998 1:11 pm
external data bus 6-17 table 6.3 output enable control summary ARM7TDMI output abe dbe tbe a[31:0] 44 d[31:0] 4 nrw 44 lock 44 mas[1:0] 44 nopc 44 ntrans 44 dbgack eclk ncpi nenout nexec nm[4:0] tbit nmreq sdoutbs sdoutdata seq dout[31:0] arm.book page 17 wednesday, november 25, 1998 1:11 pm
6-18 memory interface figure 6.15 ARM7TDMI data bus control circuit 6.10.3 example system: the ARM7TDMI test chip connecting the core data bus, d[31:0], to an external shared bus requires some simple additional logic. this will vary from application to application. as an example, the following describes how the core macrocell was connected to the bidirectional data bus pads of the ARM7TDMI test chip. in this application, care must be taken to prevent bus clash on d[31:0] when the data bus drive changes direction. the timing of nenin, and the pad control signals must be arranged so that when the core starts to drive out, the pad drive onto d[31:0] switches off before the core starts to drive. similarly, when the bus switches back to input, the core must stop driving before the pad switches on. all this can be achieved using a simple nonoverlapping clock generator. the actual circuit implemented in the ARM7TDMI test chip is shown in figure 6.16 . note that at the core level, tbe and dbe are tied high (inactive). this is because in a packaged part, there is no need to ever scan cell scan cell scan cell dbe nenout nenin tbe d[31:0] core control arm.book page 18 wednesday, november 25, 1998 1:11 pm
external data bus 6-19 manually force the internal buses into a high impedance state. note also that at the pad level, the signal edbe is factored into the bus control logic. this allows the external memory controller to arbitrate the bus and asynchronously disable ARM7TDMI test chip if required. figure 6.16 the ARM7TDMI test chip data bus circuit figure 6.17 shows how the various control signals interact. under normal conditions, when the data bus is con?gured as input, nenout is high, nen1 is low, and nen2/nenin is high. thus the pads drive xd[31:0] onto d[31:0]. when a write cycle occurs, nrw is driven high to indicate a write during phase 2 of the previous cycle, (ie, with the address). during phase 1 of the actual cycle, nenout is driven low to indicate that the core is about to drive the bus. the falling edge of this signal makes nen1 go high, which disables the input half pad from driving d[31:0]. this in turn makes nen2 go low, which enables the output half of the pad so that the core is now driving the external data bus, xd[31:0]. nen2 is then buffered and driven back into the core on nenin, so that ?nally the core srl srl srl pad xd[31:0] edbe nen1 nen2 v dd d[31:0] tbe nenin nenout dbe v dd ARM7TDMI core ARM7TDMI test chip arm.book page 19 wednesday, november 25, 1998 1:11 pm
6-20 memory interface macrocell drives d[31:0]. the delay between all the signals ensures that there is no clash on the data bus as it changes direction from input to output. figure 6.17 data bus control signal timing when the bus changes direction at the end of the cycle, the various control signals switch the other way. again, the nonoverlap ensures that there is never a bus clash. this time, nenout is driven high to denote that the core no longer needs to drive the bus and the cores output is immediately switched off. this causes nen2 to disable the output half of the pad which in turn causes nen1 to switch on the input half. thus, the bus is back to its original input con?guration. note that the data out time of the core is not directly determined by nenout and nenin, and so delaying exactly when the bus is driven will not affect the propagation delay. please refer to cw001007 ARM7TDMI microprocessor core datasheet for timing details. nenout nen1 nen2/nenin d[31:0] arm.book page 20 wednesday, november 25, 1998 1:11 pm
book title 7-1 chapter 7 coprocessor interface this chapter describes the ARM7TDMI coprocessor interface and contains the following sections: section 7.1, overview, page 7-1 section 7.2, interface signals, page 7-1 section 7.3, register transfer cycle, page 7-3 section 7.4, privileged instructions, page 7-4 section 7.5, idempotency, page 7-4 section 7.6, unde?ned instructions, page 7-5 7.1 overview the functionality of the core instruction set may be extended by the addition of up to 16 external coprocessors. when the coprocessor is not present, instructions intended for it will trap, and suitable software may be installed to emulate its functions. adding the coprocessor will then increase the system performance in a software compatible way. note that some coprocessor numbers have already been assigned. contact arm ltd. for up-to-date information. 7.2 interface signals three dedicated signals control the coprocessor interface, ncpi, cpa and cpb. the cpa and cpb inputs should be driven high except when they are being used for handshaking. arm.book page 1 wednesday, november 25, 1998 1:11 pm
7-2 coprocessor interface 7.2.1 coprocessor present/absent the core takes ncpi low whenever it starts to execute a coprocessor (or unde?ned) instruction. (this will not happen if the instruction fails to be executed because of the condition codes.) each coprocessor will have a copy of the instruction, and can inspect the cp# ?eld to see which coprocessor it is for. every coprocessor in a system must have a unique number and if that number matches the contents of the cp# ?eld the coprocessor should drive the cpa (coprocessor absent) line low. if no coprocessor has a number which matches the cp# ?eld, cpa and cpb will remain high, and the core will take the unde?ned instruction trap. otherwise the core observes the cpa line going low, and waits until the coprocessor is not busy. 7.2.2 busy (waiting) if cpa goes low, the core will watch the cpb (coprocessor busy) line. only the coprocessor which is driving cpa low is allowed to drive cpb low, and it should do so when it is ready to complete the instruction. the core will busy-wait while cpb is high, unless an enabled interrupt occurs, in which case it will break off from the coprocessor handshake to process the interrupt. when the core returns from processing the interrupt to retry the coprocessor instruction. when cpb goes low, the instruction continues to completion. this will involve data transfers taking place between the coprocessor and either the core or memory, except in the case of coprocessor data operations which complete immediately when the coprocessor ceases to be busy. all three interface signals are sampled by both the core and the coprocessor(s) on the rising edge of mclk. if all three are low, the instruction is committed to execution, and if transfers are involved they will start on the next cycle. if ncpi has gone high after being low, and before the instruction is committed, the core has broken off from the busy-wait state to service an interrupt. the instruction may be restarted later, but other coprocessor instructions may come sooner, and the instruction should be discarded. arm.book page 2 wednesday, november 25, 1998 1:11 pm
register transfer cycle 7-3 7.2.3 pipeline following in order to respond correctly when a coprocessor instruction arises, each coprocessor must have a copy of the instruction. all core instructions are fetched from memory using the main data bus, and coprocessors are connected to this bus, so they can keep copies of all instructions as they go into the core pipeline. the nopc signal indicates when an instruction fetch is taking place, and mclk gives the timing of the transfer, so these may be used together to load an instruction pipeline within the coprocessor. 7.2.4 data transfer cycles once the coprocessor has gone not busy in a data transfer instruction, it must supply or accept data at the core bus rate (de?ned by mclk). it can deduce the direction of transfer by inspection of the l bit in the instruction, but must only drive the bus when permitted to by dbe being high. the coprocessor is responsible for determining the number of words to be transferred; the core will continue to increment the address by one word per transfer until the coprocessor tells it to stop. the termination condition is indicated by the coprocessor driving cpa and cpb high. there is no limit, in principle, to the number of words which one coprocessor data transfer can move, but by convention no coprocessor should allow more than 16 words in one instruction. more than this would worsen the worst case core interrupt latency, as the instruction is not interruptible once the transfers have commenced. at 16 words, this instruction is comparable with a block transfer of 16 registers, and therefore does not affect the worst case latency. 7.3 register transfer cycle the coprocessor register transfer cycle is the one case when the core requires the data bus without requiring the memory to be active. the memory system is informed that the bus is required by the core taking both nmreq and seq high. when the bus is free, dbe should be taken high to allow the core or the coprocessor to drive the bus, and an mclk cycle times the transfer. arm.book page 3 wednesday, november 25, 1998 1:11 pm
7-4 coprocessor interface 7.4 privileged instructions the coprocessor may restrict certain instructions for use in privileged modes only. to do this, the coprocessor will have to track the ntrans output. as an example of the use of this facility, consider the case of a ?oating- point coprocessor (fpu) in a multitasking system. the operating system could save all the ?oating-point registers on every task switch, but this is inef?cient in a typical system where only one or two tasks will use ?oating-point operations. instead, there could be a privileged instruction which turns the fpu on or off. when a task switch happens, the operating system can turn the fpu off without saving its registers. if the new task attempts an fpu operation, the fpu will appear to be absent, causing an unde?ned instruction trap. the operating system will then realize that the new task requires the fpu, so it will re-enable it and save fpu registers. the task can then use the fpu as normal. if, however, the new task never attempts an fpu operation (as will be the case for most tasks), the state saving overhead will have been avoided. 7.5 idempotency a consequence of the implementation of the coprocessor interface, with the interruptible busy-wait state, is that all instructions may be interrupted at any point up to the time when the coprocessor goes not busy. if so interrupted, the instruction will normally be restarted from the beginning after the interrupt has been processed. it is therefore essential that any action taken by the coprocessor before it goes not busy must be idempotent, i.e., must be repeatable with identical results. for example, consider a fix operation in a ?oating point coprocessor which returns the integer result to a core register. the coprocessor must stay busy while it performs the ?oating-point to ?xed-point conversion, as the core will expect to receive the integer value on the cycle immediately following that where it goes not busy. the coprocessor must therefore preserve the original ?oating point value and not corrupt it during the conversion, because it will be required again if an interrupt arises during the busy period. arm.book page 4 wednesday, november 25, 1998 1:11 pm
unde?ned instructions 7-5 the coprocessor data operation class of instruction is not generally subject to idempotency considerations, as the processing activity can take place after the coprocessor goes not busy. there is no need for the core to be held up until the result is generated, because the result is con?ned to stay within the coprocessor. 7.6 unde?ned instructions unde?ned instructions are treated by the core as coprocessor instructions. all coprocessors must be absent (ie cpa and cpb must be high) when an unde?ned instruction is presented. ARM7TDMI will then take the unde?ned instruction trap. note that the coprocessor need only look at bit 27 of the instruction to differentiate unde?ned instructions (which all have a 0 in bit 27) from coprocessor instructions (which all have a 1 in bit 27). note that when in thumb state, coprocessor instructions are not supported but unde?ned instructions are. thus, all coprocessors must monitor the state of the tbit output from the core. when the core is in thumb state, coprocessors must appear absent (i.e., they must drive cpa and cpb high) and the instructions seen on the data bus must be ignored. in this way, coprocessors will not erroneously execute thumb instructions, and all unde?ned instructions will be handled correctly. arm.book page 5 wednesday, november 25, 1998 1:11 pm
7-6 coprocessor interface arm.book page 6 wednesday, november 25, 1998 1:11 pm
book title 8-1 chapter 8 debug interface this chapter describes the ARM7TDMI core advanced debug interface. it contains the following sections: section 8.1, overview, page 8-1 section 8.2, debug systems, page 8-2 section 8.3, debug interface signals, page 8-4 section 8.4, scan chains and jtag interface, page 8-7 section 8.5, reset, page 8-11 section 8.6, pull-up resistors, page 8-11 section 8.7, instruction register, page 8-11 section 8.8, public instructions, page 8-12 section 8.9, test data registers, page 8-16 section 8.10, ARM7TDMI core clocks, page 8-24 section 8.11, determining the core and system state, page 8-25 section 8.12, pc behavior during debug, page 8-30 section 8.13, priorities/exceptions, page 8-33 section 8.14, scan interface timing, page 8-34 section 8.15, debug timing, page 8-38 8.1 overview the core debug interface is based on the ieee std. 1149.1 - 1990, standard test access port and boundary-scan architecture . please refer to this standard for an explanation of the terms used in this chapter and for a description of the tap controller states. arm.book page 1 wednesday, november 25, 1998 1:11 pm
8-2 debug interface the core contains hardware extensions for advanced debugging features. these are intended to ease the users development of application software, operating systems, and the hardware itself. the debug extensions allow the core to be stopped either on a given instruction fetch (breakpoint) or data access (watchpoint), or asynchronously by a debug request. when this happens, the core is said to be in debug state . at this point, the cores internal state and the systems external state may be examined. once examination is complete, the core and system state may be restored and program execution resumed. the core is forced into debug state either by a request on one of the external debug interface signals, or by an internal functional unit known as the embeddedice macrocell. once in debug state, the core isolates itself from the memory system. the core can then be examined while all other system activity continues as normal. the cores internal state is examined using a jtag-style serial interface, which allows instructions to be serially inserted into the cores pipeline 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 dump the contents of the cores registers. this data can be serially shifted out without affecting the rest of the system. 8.2 debug systems the ARM7TDMI core 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 core. such a system typically has three parts: 1. the debug host this is a computer, for example a pc, running a software debugger such as armsd. 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. arm.book page 2 wednesday, november 25, 1998 1:11 pm
debug systems 8-3 2. the protocol converter the debug host will be connected to the core development system through an interface (an rs232, for example). the messages broadcast over this connection must be converted to the interface signals of the core, and this function is performed by the protocol converter. 3. ARM7TDMI core the core, with hardware extensions to ease debugging, is the lowest level of the system. the debug extensions allow the user to stall the core from program execution, examine its internal state and the state of the memory system, and then resume program execution. figure 8.1 typical debug system the anatomy of the core is shown in figure 8.3 . the major blocks are: ARM7TDMI C this is the cpu core, with hardware support for debug. embeddedice macrocell C this is a set of registers and comparators used to generate debug exceptions (e.g., breakpoints). this unit is described in chapter 9, "embeddedice macrocell" . tap controller C this controls the action of the scan chains using a jtag serial interface. the debug host and the protocol converter are system dependent. the rest of this chapter describes the cores hardware debug extensions. host computer running armsd protocol converter development system containing ARM7TDMI debug host debug target arm.book page 3 wednesday, november 25, 1998 1:11 pm
8-4 debug interface 8.3 debug interface signals there are three primary external signals associated with the debug interface: breakpt and dbgrq with which the system requests that the core enter debug state. dbgack which the core uses to ?ag back to the system that it is in debug state. 8.3.1 entry into debug state the core is forced into debug state after a breakpoint, watchpoint or debug request has occurred. conditions under which a breakpoint or watchpoint occur can be programmed using the embeddedice macrocell. alternatively, external logic can monitor the address and data bus, and ?ag breakpoints and watchpoints using the breakpt pin. the timing is the same for externally generated breakpoints and watchpoints. data must always be valid around the falling edge of mclk. if this data is an instruction which generates a breakpoint, the breakpt signal must be high on the next rising edge of mclk. similarly, if the data is for a load or store, this can be marked as a watchpoint by asserting breakpt on the next rising edge of mclk. when a breakpoint or watchpoint is generated, there may be a delay before the core enters debug state. when it does, the dbgack signal is asserted in the high phase of mclk. the timing for an externally generated breakpoint is shown in figure 8.2 . arm.book page 4 wednesday, november 25, 1998 1:11 pm
debug interface signals 8-5 figure 8.2 debug state entry 8.3.1.1 entry into debug state on breakpoint after an instruction has generated a breakpoint, the core does not enter debug state immediately. instructions are marked as being a breakpoint as they enter the core's instruction pipeline. thus the core only enters debug state when (and if) the instruction reaches the pipelines execute stage. a breakpoint instruction may not cause the core to enter debug state for one of two reasons: a branch precedes the breakpoint instruction. when the branch is executed, the instruction pipeline is ?ushed and the breakpoint is cancelled. an exception has occurred. again, the instruction pipeline is ?ushed and the breakpoint is cancelled. however, the normal way to exit from an exception is to branch back to the instruction that would have executed next. this involves re?lling the pipeline, and so the breakpoint can be re?agged. when a breakpoint conditional instruction reaches the execute stage of the pipeline, the breakpoint is always taken and the core enters debug state, regardless of whether the condition was met. mclk a[31:0] d[31:0] breakpt dbgack nmreq seq internal cycles memory cycles arm.book page 5 wednesday, november 25, 1998 1:11 pm
8-6 debug interface breakpoint instructions do not get executed: instead, the core enters debug state. thus, when the internal state is examined, the state before the breakpoint instruction is seen. once examination is complete, the breakpoint should be removed and program execution restarted from the previous breakpoint instruction. 8.3.1.2 entry into debug state on watchpoint watchpoints occur on data accesses. a watchpoint is always taken, but the core may not enter debug state immediately. in all cases, the current instruction will complete. if this is a multiword load or store ( ldm or stm ), many cycles may elapse before the watchpoint is taken. watchpoints can be thought of as being similar to data aborts. the difference is if a data abort occurs, although the instruction completes, all subsequent changes to the cores state are prevented. this allows the cause of the abort to be cured by the abort handler, and the instruction re-executed. this is not so in the case of a watchpoint. here, the instruction completes and all changes to the cores state occur (i.e., load data is written into the destination registers, and base write back occurs). thus the instruction does not need to be restarted. watchpoints are always taken. if an exception is pending when a watchpoint occurs, the core enters debug state in the mode of that exception. 8.3.1.3 entry into debug state on debug request ARM7TDMI may also be forced into debug state on debug request. this can be done either through embeddedice macrocell programming (see chapter 9, "embeddedice macrocell" ), or by the assertion of the dbgrq signal. this signal is an asynchronous input and is thus synchronized by logic inside the core before it takes effect. following synchronization, the core will normally enter debug state at the end of the current instruction. however, if the current instruction is a busy- waiting access to a coprocessor, the instruction terminates and the core enters debug state immediately (this is similar to the action of nirq and nfiq). arm.book page 6 wednesday, november 25, 1998 1:11 pm
scan chains and jtag interface 8-7 8.3.1.4 action of ARM7TDMI in debug state once the core is in debug state, nmreq and seq are forced to indicate internal cycles. this allows the rest of the memory system to ignore the core and function as normal. since the rest of the system continues operation, the core must be forced to ignore aborts and interrupts. the bigend signal should not be changed by the system during debug. if it changes, not only will there be a synchronization problem, but the programmers view of the core will change without the debuggers knowledge. nreset must also be held stable during debug. if the system applies reset to the core (ie. nreset is driven low) then the cores state will change without the debuggers knowledge. the bl[3:0] signals must remain high while the core is clocked by dclk in debug state to ensure all of the data in the scan cells is correctly latched by the internal logic. when instructions are executed in debug state, the core outputs (except nmreq and seq) will change asynchronously to the memory system. for example, every time a new instruction is scanned into the pipeline, the address bus will change. although this is asynchronous it should not affect the system, since nmreq and seq are forced to indicate internal cycles regardless of what the rest of ARM7TDMI is doing. the memory controller must be designed to ensure that this asynchronous behavior does not affect the rest of the system. 8.4 scan chains and jtag interface there are three jtag-style scan chains inside the core. these allow testing, debugging and embeddedice macrocell programming. the scan chains are controlled from a jtag-style tap (test access port) controller. for further details of the jtag speci?cation, please refer to ieee standard 1149.1 - 1990 standard test access port and boundary- scan architecture . in addition, support is provided for an optional fourth scan chain. this is intended to be used for an external boundary scan chain around the pads of a packaged device. the control signals provided for this scan chain are described later. note: the scan cells are not fully jtag compliant. the following sections describe the limitations on their use. arm.book page 7 wednesday, november 25, 1998 1:11 pm
8-8 debug interface 8.4.1 scan limitations the three scan paths are referred to as scan chain 0, 1 and 2: these are shown in figure 8.3 ARM7TDMI scan chain arrangement . 8.4.1.1 scan chain 0 scan chain 0 allows access to the entire periphery of the core, including the data bus. the scan chain functions allow interdevice testing (extest) and serial testing of the core (intest). the order of the scan chain (from sdinbs to sdoutbs) is: data bus bits [0:31], the control signals, followed by the address bus bits [31:0]. 8.4.1.2 scan chain 1 scan chain 1 is a subset of the signals that are accessible through scan chain 0. access to the cores data bus d[31:0], and the breakpt signal is available serially. there are 33 bits in this scan chain, the order being (from serial data in to out): data bus bits 0 through 31, followed by breakpt. 8.4.1.3 scan chain 2 this scan chain simply allows access to the embeddedice macrocell registers. refer to chapter 9, "embeddedice macrocell" for more detail. arm.book page 8 wednesday, november 25, 1998 1:11 pm
scan chains and jtag interface 8-9 figure 8.3 ARM7TDMI scan chain arrangement . 8.4.2 the jtag state machine the process of serial test and debug is best explained in conjunction with the jtag state machine. figure 8.4 shows the state transitions that occur in the tap controller. the state numbers are also shown on the diagram. these are output from the core on the tapsm[3:0] bits. ? ? scan chain 1 scan chain 0 scan chain 2 ARM7TDMI processor ARM7TDMI tap controller embeddedice macrocell arm.book page 9 wednesday, november 25, 1998 1:11 pm
8-10 debug interface figure 8.4 test access port (tap) controller state transitions tms = 0 tms = 0 tms = 1 tms = 0 tms = 1 tms = 1 tms = 0 shift-ir tms = 0 exit1-ir tms = 1 pause-ir tms = 0 exit2-ir tms = 1 update-ir tms = 1 tms = 0 tms = 0 tms = 1 tms = 1 tms = 0 pause-dr exit2-dr update-dr tms = 0 tms = 1 tms = 0 tms = 0 tms = 0 tms = 1 tms = 1 tms = 0 tms = 1 tms = 1 tms = 1 tms = 1 tms = 1 tms = 0 tms = 0 0xa 0x9 0xb 0x8 0xd 0x5 0x0 0x3 test-logic reset 0xf run-test/ idle 0xc select- dr-scan 0x7 select- ir-scan 0x4 capture-dr 0x6 shift-dr 0x2 exit1-dr 0x1 capture-ir 0xe arm.book page 10 wednesday, november 25, 1998 1:11 pm
reset 8-11 8.5 reset the boundary scan interface includes a state machine controller (the tap controller). in order to force the tap controller into the correct state after power up of the device, a reset pulse must be applied to the ntrst signal. if the boundary scan 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 should be driven by the same signal as nreset. note that a clock on tck is not necessary to reset the device. the action of reset is as follows: 1. system mode is selected (i.e., 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 will be clocked out of tdo. 8.6 pull-up resistors the ieee 1149.1 standard effectively requires that tdi and tms should have internal pull-up resistors. in order to minimize static current draw, these resistors are not ?tted to the core. accordingly, the 4 inputs to the test interface (the above tdo, tdi, tms, and tck) must all be driven to good logic levels to achieve normal circuit operation. 8.7 instruction register the instruction register is 4 bits in length. there is no parity bit. the ?xed value loaded into the instruction register during the capture-ir controller state is 0b0001. arm.book page 11 wednesday, november 25, 1998 1:11 pm
8-12 debug interface 8.8 public instructions table 8.1 lists the public instructions supported by the core. : 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. 8.8.1 extest (0b0000) the selected scan chain is placed in test mode by the extest instruction. the extest instruction connects the selected scan chain between tdi and tdo. when the instruction register is loaded with the extest instruction, all the scan cells are placed in their test mode of operation. table 8.1 public instructions instruction code extest 0b0000 scan_n 0b0010 intest 0b1100 idcode 0b1110 bypass 0b1111 clamp 0b0101 highz 0b0111 clampz 0b1001 sample/preload 0b0011 restart 0b0100 arm.book page 12 wednesday, november 25, 1998 1:11 pm
public instructions 8-13 in the capture-dr state, inputs from the system logic and outputs from the output scan cells to the system are captured by the scan cells. in the shift-dr state, the previously captured test data is shifted out of the scan chain using tdo, while new test data is shifted in using the tdi input. this data is applied immediately to the system logic and system pins. 8.8.2 scan_n (0b0010) this instruction connects the scan path select register between tdi and tdo. during the capture-dr state, the ?xed value 0b1000 is loaded into the register. during the shift-dr state, the id number of the desired scan path is shifted into the scan path select register. in the update-dr state, the scan register of the selected scan chain is connected between tdi and tdo, and remains connected until a subsequent scan_n instruction is issued. on reset, scan chain 3 is selected by default. the scan path select register is 4 bits long in this implementation, although no ?nite length is speci?ed. 8.8.3 intest (0b1100) the selected scan chain is placed in test mode by the intest instruction. the intest instruction connects the selected scan chain between tdi and tdo. when the instruction register is loaded with the intest instruction, all the scan cells are placed in their test mode of operation. in the capture-dr state, the value of the data applied from the core logic to the output scan cells, and the value of the data applied from the system logic to the input scan cells is captured. in the shift-dr state, the previously captured test data is shifted out of the scan chain using the tdo signal, while new test data is shifted in through the tdi signal. single-step operation is possible using the intest instruction. arm.book page 13 wednesday, november 25, 1998 1:11 pm
8-14 debug interface 8.8.4 idcode (0b1110) the idcode instruction connects the device identi?cation register (or id register) between tdi and tdo. the id register is a 32-bit register that allows the manufacturer, part number and version of a component to be determined through the tap. see section 8.9.2, ARM7TDMI device identi?cation (id) code register, for the details of the id register format. when the instruction register is loaded with the idcode instruction, all the scan cells are placed in their normal (system) mode of operation. in the capture-dr state, the device identi?cation code is captured by the id register. in the shift-dr state, the previously captured device identi?cation code is shifted out of the id register through the tdo signal, while data is shifted in using the tdi signal into the id register. in the update-dr state, the id register is unaffected. 8.8.5 bypass (0b1111) the bypass instruction connects a 1 bit shift register (the bypass register) between tdi and tdo. when the bypass instruction is loaded into the instruction register, all the scan cells are placed in their normal (system) mode of operation. this instruction has no effect on the system pins. in the capture-dr state, a logic 0 is captured by the bypass register. in the shift-dr state, test data is shifted into the bypass register using tdi and out using tdo after a delay of one tck cycle. note that the ?rst bit shifted out will be a zero. the bypass register is not affected in the update-dr state. note that all unused instruction codes default to the bypass instruction. 8.8.6 clamp (0b0101) this instruction connects a 1 bit shift register (the bypass register) between tdi and tdo. when the clamp instruction is loaded into the instruction register, the state of all the output signals is de?ned by the values previously loaded into the currently loaded scan chain. note: this instruction should only be used when scan chain 0 is the currently selected scan chain. arm.book page 14 wednesday, november 25, 1998 1:11 pm
public instructions 8-15 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 using tdi and out using tdo after a delay of one tck cycle. note that the ?rst bit shifted out will be a zero. the bypass register is not affected in the update-dr state. 8.8.7 highz (0b0111) 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, the address bus, a[31:0], the data bus, d[31:0], plus nrw, nopc, lock, mas[1:0] and ntrans are all driven to the high impedance state and the external highz signal is driven high. this is as if the signal tbe had been driven low. in the capture-dr state, a logic 0 is captured by the bypass register. in the shift-dr state, test data is shifted into the bypass register using tdi and out using tdo after a delay of one tck cycle. note that the ?rst bit shifted out will be a zero. the bypass register is not affected in the update-dr state. 8.8.8 clampz (0b1001) this instruction connects a 1-bit shift register (the bypass register) between tdi and tdo. when the clampz instruction is loaded into the instruction register, all the 3-state outputs (as described above) are placed in their inactive state, but the data supplied to the outputs is derived from the scan cells. the purpose of this instruction is to ensure that, during production test, each output can be disabled when its data value is either a logic 0 or a 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 using tdi and out using tdo after a delay of one tck cycle. note that the ?rst bit shifted out will be a zero. the bypass register is not affected in the update-dr state. arm.book page 15 wednesday, november 25, 1998 1:11 pm
8-16 debug interface 8.8.9 sample/preload (0b0011) this instruction is included for production test only, and should never be used. 8.8.10 restart (0b0100) this instruction is used to restart the processor on exit from debug state. the restart instruction connects the bypass register between tdi and tdo and the tap controller behaves as if the bypass instruction had been loaded. the processor will resynchronize back to the memory system once the run-test/idle state is entered. 8.9 test data registers there are 6 test data registers which may be connected between tdi and tdo. they are: bypass register, id code register, scan chain select register, scan chain 0, 1, or 2. these are now described in detail. 8.9.1 bypass register purpose C bypasses the device during scan testing by providing a path between tdi and tdo. length C one bit. operating mode C 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 the capture-dr state. 8.9.2 ARM7TDMI device identi?cation (id) code register purpose C reads the 32-bit device identi?cation code. no programmable supplementary identi?cation code is provided. arm.book page 16 wednesday, november 25, 1998 1:11 pm
test data registers 8-17 length C 32 bits. the format of the id register is as follows: figure 8.5 id register format please contact your supplier for the correct device identi?cation code. for the cw001004 the value returned by this register is 0b0001.1111.0000.1111.0000.1111.0000.1111. for the cw001007 this register is not implemented in the core, and will read back all zeroes, indicating that no valid id is present. if you wish to implement an id this must be done through interaction with the jtag states signals accessible externally to the core. operating mode: C 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 device identi?cation code is loaded into the id register from its parallel inputs during the capture-dr state. 8.9.3 instruction register purpose C changes the current tap instruction. length C four bits. operating mode C when in the 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 (lsb ?rst), while a new instruction is shifted in (lsb ?rst). during the update-ir state, the value in the instruction register becomes the current instruction. on reset, idcode becomes the current instruction. 31 28 27 12 11 1 0 version part number manufacturer identity 1 arm.book page 17 wednesday, november 25, 1998 1:11 pm
8-18 debug interface 8.9.4 scan chain select register purpose C changes the current active scan chain. length C four bits. operating mode C after scan_n has been selected as the current instruction, when in the shift-dr state, the scan chain select register is selected as the serial path between tdi and tdo. during the capture-dr state, the value 0b1000 is loaded into this register. this is shifted out during shift-dr (lsb ?rst), while a new value is shifted in (lsb ?rst). during the update-dr state, the value in the register selects a scan chain to become the currently active scan chain. all further instructions such as intest then apply to that scan chain. the currently selected scan chain only changes when a scan_n instruction is executed, or a reset occurs. on reset, scan chain 3 is selected as the active scan chain. the number of the currently selected scan chain is re?ected on the screg[3:0] outputs. the tap controller may be used to drive external scan chains in addition to those within the ARM7TDMI macrocell. the external scan chain must be assigned a number and control signals for it can be derived from screg[3:0], ir[3:0], tapsm[3:0], tck1 and tck2. the list of scan chain numbers allocated by ARM7TDMI are shown in table 8.2 . an external scan chain may take any other number.the serial data stream to be applied to the external scan chain is made present on sdinbs, the serial data back from the scan chain must be presented to the tap controller on the sdoutbs input. the scan chain present between sdinbs 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[3:0]. arm.book page 18 wednesday, november 25, 1998 1:11 pm
test data registers 8-19 8.9.5 scan chains 0, 1, and 2 these allow serial access to the core logic, and to embeddedice macrocell for programming purposes. they are described in detail below. 8.9.5.1 scan chain 0 and 1 purpose C allows access to the processor core for test and debug. length C scan chain 0 is 105 bits, scan chain 1 is 33 bits. each scan chain cell is fairly simple, and consists of a serial register and a multiplexer. the scan cells perform two basic functions, capture and shift. for input cells, the capture stage involves copying the value of the system input to the core into the serial register. during shift, this value is output serially. the value applied to the core from an input cell is either the system input or the contents of the serial register, and this is controlled by the multiplexer. table 8.2 scan chain number allocation scan chain number function 0 macrocell scan test 1 debug 2 embeddedice macrocell programming 3 external boundary scan 4 reserved 8 reserved arm.book page 19 wednesday, november 25, 1998 1:11 pm
8-20 debug interface figure 8.6 input scan cell for output cells, capture involves placing the value of a cores output into the serial register. during shift, this value is serially output as before. the value applied to the system from an output cell is either the core output, or the contents of the serial register. all the control signals for the scan cells are generated internally by the tap controller. the action of the tap controller is determined by the current instruction, and the state of the tap state machine. this is described below. there are three basic modes of operation of the scan chains, intest, extest and system, and these are selected by the various tap controller instructions. in system mode, the scan cells are idle. system data is applied to inputs, and core outputs are applied to the system. in intest mode, the core is internally tested. the data serially scanned in is applied to the core, and the resulting outputs are captured in the output cells and scanned out. in extest mode, data is scanned onto the core's outputs and applied to the external system. system input data is captured in the input cells and then shifted out. note: the scan cells are not fully jtag compliant in that they do not have an update stage. therefore, while data is being moved around the scan chain, the contents of the scan cell is not isolated from the output. thus the output from the scan cell to the core or to the external system could change on every scan clock. shift register latch system data in shift clock data to serial data in serial data out capture clock core arm.book page 20 wednesday, november 25, 1998 1:11 pm
test data registers 8-21 this does not affect the core since its internal state does not change until it is clocked. however, the rest of the system needs to be aware that every output could change asynchronously as data is moved around the scan chain. external logic must ensure that this does not harm the rest of the system. 8.9.5.2 scan chain 0 scan chain 0 is intended primarily for interdevice testing (extest), and testing the core (intest). scan chain 0 is selected using the scan_n instruction: see section 8.8.2, scan_n (0b0010). intest allows serial testing of the core. the tap controller must be placed in intest mode after scan chain 0 has been selected. during capture-dr, the current outputs from the cores 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 clocked. normally, the tap controller should only spend 1 cycle in run-test/idle. the whole operation may then be repeated. for details of the cores clocks during test and debug, see section 8.10, ARM7TDMI core clocks . extest allows interdevice testing, useful for verifying the connections between devices on a circuit board. the tap controller must be placed in extest mode after scan chain 0 has been selected. during capture-dr, the current inputs to the core'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 cores outputs. during update-dr, the value shifted into the data bus d[31:0] scan cells appears on the outputs. for all other outputs, the value appears as the data is shifted round. note, during run-test/idle, the core is not clocked. the operation may then be repeated. table 8.4 lists the scan chain 0 bit order. arm.book page 21 wednesday, november 25, 1998 1:11 pm
8-22 debug interface 8.9.5.3 scan chain 1 the primary use for scan chain 1 is for debugging, although it can be used for extest on the data bus. scan chain 1 is selected using the scan_n tap controller instruction. debugging is similar to intest, and the procedure described above for scan chain 0 should be followed. note that this scan chain is 33 bits longC32 bits for the data value, plus the scan cell on the breakpt core input. this 33rd bit serves four purposes: 1. under normal intest test conditions, it allows a known value to be scanned into the breakpt input. 2. during extest test conditions, the value applied to the breakpt input from the system can be captured. 3. while debugging, the value placed in the 33rd bit determines whether the core synchronizes back to system speed before executing the instruction. see section 8.12.5, system speed access for further details. 4. after the core has entered debug state, the ?rst time this bit is captured and scanned out, its value tells the debugger whether the core entered debug state due to a breakpoint (bit 33 low), or a watchpoint (bit 33 high). 8.9.5.4 scan chain 2 purpose C allows embeddedice macrocell's registers to be accessed. the order of the scan chain, from tdi to tdo is: read/write, register address bits 4 to 0, followed by data value bits 31 to 0. see figure 9.2 . length C 38 bits. to access this serial register, scan chain 2 must ?rst be selected using the scan_n tap controller instruction. the tap controller must then be placed in intest mode. no action is taken during capture-dr. during shift-dr, a data value is shifted into the serial register. bits 32 to 36 specify the address of the embeddedice macrocell register to be accessed. during update-dr, this register is either read or written depending on the value of bit 37 (0 = read). refer to chapter 9, "embeddedice macrocell," for further details. arm.book page 22 wednesday, november 25, 1998 1:11 pm
test data registers 8-23 8.9.5.5 scan chain 3 purpose C allows ARM7TDMI to control an external boundary scan chain. length C user-de?ned length. scan chain 3 is provided so that an optional external boundary scan chain may be controlled through the core. typically this would be used for a scan chain around the pad ring of a packaged device. the following control signals are provided which are generated only when scan chain 3 has been selected. these outputs are inactive at all other times. in addition to these control outputs, sdinbs 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 sdinbs should be connected to the serial data input. drivebs this would be 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. pclkbs this is an update clock, generated in the update-dr state. typically the value scanned into a chain would be transferred to the cell output on the rising edge of this signal. icapclkbs, ecapclkbs these are capture clocks used to sample data into the scan cells during intest and extest respectively. these clocks are generated in the capture-dr state. shclkbs, shclk2bs these are nonoverlapping clocks generated in the shift-dr state used to clock the master and slave element of the scan cells respectively. when the state machine is not in the shift-dr state, both these clocks are low. nhighz this signal may be used to drive the outputs of the scan cells to the high impedance state. this signal is driven low when the highz instruction is loaded into the instruction register, and high at all other times. arm.book page 23 wednesday, november 25, 1998 1:11 pm
8-24 debug interface 8.10 ARM7TDMI core clocks the core has two clocks, the memory clock, mclk, and an internally tck generated clock, dclk. during normal operation, the core is clocked by mclk, and internal logic holds dclk low. when the core is in the debug state, the core is clocked by dclk under control of the tap state machine, and mclk may free run. the selected clock is output on the signal eclk for use by the external system. note that when the cpu core is being debugged and is running from dclk, nwait has no effect. 8.10.1 clock switch during debug when the core enters debug state, it must switch from mclk to dclk. this is handled automatically by logic in the core. on entry to debug state, the core asserts dbgack in the high phase of mclk. the switch between the two clocks occurs on the next falling edge of mclk. this is shown in figure 8.7 . figure 8.7 clock switching on entry to debug state the core is forced to use dclk as the primary clock until debugging is complete. on exit from debug, the core must be allowed to synchronize back to mclk. this must be done in the following sequence. the ?nal instruction of the debug sequence must be shifted into the data bus scan chain and clocked in by asserting dclk. at this point, bypass must be clocked into the tap instruction register. the core will now automatically resynchronize back to mclk and start fetching instructions from memory at mclk speed. please refer also to section 8.11.3, exit from debug state . mclk dbgack dclk eclk multiplexer switching point arm.book page 24 wednesday, november 25, 1998 1:11 pm
determining the core and system state 8-25 8.11 determining the core and system state when the core is in debug state, the core and systems state may be examined. this is done by forcing load and store multiples into the instruction pipeline. before the core and system state can be examined, the debugger must ?rst determine whether the processor was in thumb or arm state when it entered debug. this is achieved by examining bit 4 of embeddedices debug status register. if this is high, the core was in thumb state when it entered debug. 8.11.1 determining the cores 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's state. to force the processor into arm state, the following sequence of thumb instructions should be executed on the core: str r0, [r0] ; save r0 before use mov r0, pc ; copy pc into r0 str r0, [r0] ; now save the pc in r0 bx pc ; jump into arm state mov r8, r8 ; nop mov r8, r8 ; nop note: 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. for example, the encoding for bx r0 is 0x4700. thus if 0x47004700 is shifted into scan chain 1, the debugger does not have to keep track of which half of the bus the processor expects to read the data from. from this point on, the processor's state can be determined by the sequences of arm instructions described below. once the processor is in arm state, typically the ?rst instruction executed would be: stm r0, {r0-r15} arm.book page 25 wednesday, november 25, 1998 1:11 pm
8-26 debug interface this causes the contents of the registers to be made visible on the data bus. these values can then be sampled and shifted out. note: the above use of r0 as the base register for the stm instruction is for illustration only, any register could be used. after determining the values in the current bank of registers, it may be desirable to access the 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 had been asked to return the state of the user mode and fiq mode registers, and debug state was entered in supervisor mode. the instruction sequence could be: stm r0, {r0-r15} ; save current registers mrs r0, cpsr str r0, r0 ; save cpsr to determine current mode bic r0, 0x1f ; clear mode bits orr r0, 0x10 ; select user mode msr cpsr, r0 ; enter user mode stm r0, {r13,r14} ; save register not visible before orr r0, 0x01 ; select fiq mode msr cpsr, r0 ; enter fiq mode stm 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 clock, 33 scan clocks occur in order to shift in an instruction, or shift out data. executing instructions more slowly than usual is ?ne for accessing the cores state since ARM7TDMI 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 legally be scanned into the instruction pipeline for execution: all data processing operations, except teqp all load, store, load multiple and store multiple instructions msr and mrs arm.book page 26 wednesday, november 25, 1998 1:11 pm
determining the core and system state 8-27 8.11.2 determining system state in order to meet the dynamic timing requirements of the memory system, any attempt to access system state must occur synchronously to it. thus, the core must be forced to synchronize back to system speed. this is controlled by the 33rd bit of scan chain 1. any instruction may be placed in scan chain 1 with bit 33 (the breakpt bit) low. this instruction will then be executed at debug speed. to execute an instruction at system speed, the instruction prior to it must be scanned into scan chain 1 with bit 33 set high. after the system speed instruction has been scanned into the data bus and clocked into the pipeline, the bypass instruction must be loaded into the tap controller. this will cause the core to automatically synchronize back to mclk (the system clock), execute the instruction at system speed, and then re-enter debug state and switch itself back to the internally generated dclk. when the instruction has completed, dbgack will be high and the core will have switched back to dclk. at this point, intest can be selected in the tap controller, and debugging can resume. in order to determine that a system speed instruction has completed, the debugger must look at both dbgack and nmreq. in order to access memory, the core drives nmreq low after it has synchronized back to system speed. this transition is used by the memory controller to arbitrate whether the core can have the bus in the next cycle. if the bus is not available, the core may have its clock stalled inde?nitely. therefore, the only way to tell that the memory access has completed, is to examine the state of both nmreq and dbgack. when both are high, the access has completed. usually, the debugger would be using embeddedice macrocell to control debugging, and by reading embeddedices status register, the state of nmreq and dbgack can be determined. refer to chapter 9, "embeddedice macrocell," for more details. by the use of system speed load multiples and debug speed store multiples, the state of the systems memory can be fed back to the debug host. arm.book page 27 wednesday, november 25, 1998 1:11 pm
8-28 debug interface there are restrictions on which instructions may have the 33rd bit set. the only valid instructions on which to set this bit are loads, stores, load multiple and store multiple. see also section 8.11.3, exit from debug state . when the core returns to debug state after a system speed access, bit 33 of scan chain 1 is set high. this gives the debugger information about why the core entered debug state the ?rst time this scan chain is read. 8.11.3 exit from debug state leaving debug state involves restoring the cores internal state, causing a branch to the next instruction to be executed, and synchronizing back to mclk. after restoring internal state, a branch instruction must be loaded into the pipeline. see section 8.12, pc behavior during debug, for details on calculating the branch. bit 33 of scan chain 1 is used to force the core to resynchronize back to mclk. the second to last instruction of the debug sequence is scanned in with bit 33 set high. the ?nal instruction of the debug sequence is the branch, and this is scanned in with bit 33 low. the core is then clocked to load the branch into the pipeline. now, the restart instruction is selected in the tap controller. when the state machine enters the run- test/idle state, the scan chain will revert back to system mode and clock resynchronization to mclk will occur within the core. the core will then resume normal operation, fetching instructions from memory. this delay, until the state machine is in the run-test/idle state, allows conditions to be setup in other devices in a multiprocessor system without taking immediate effect. then, when the run-test/idle state is entered, all the processors resume operation simultaneously. the function of dbgack is to tell the rest of the system when the core is in debug state. this can be used to inhibit peripherals such as watchdog timers which have real-time characteristics. also, dbgack can be used to mask out memory accesses which are caused by the debugging process. for example, when the core enters debug state after a breakpoint, the instruction pipeline contains the breakpoint instruction plus two other instructions which have been prefetched. on entry to debug state, the pipeline is ?ushed. therefore, on exit from debug state, the pipeline must be re?lled to its previous state. thus, because of the debugging process, more memory accesses occur than would normally arm.book page 28 wednesday, november 25, 1998 1:11 pm
determining the core and system state 8-29 be expected. any system peripheral which may be sensitive to the number of memory accesses can be inhibited through the use of dbgack. for example, imagine a ?ctitious peripheral that simply counts the number of memory cycles. this device should return the same answer after a program has been run both with and without debugging. figure 8.8 shows the behavior of the core on exit from the debug state. figure 8.8 debug exit sequence it can be seen from figure 8.2 that the ?nal memory access occurs in the cycle after dbgack goes high, and this is the point at which the cycle counter should be disabled. figure 8.8 shows that the ?rst memory access that the cycle counter has not seen before occurs in the cycle after dbgack goes low, and so this is the point at which the counter should be re-enabled. note that when a system speed access from debug state occurs, the core temporarily drops out of debug state, and so dbgack can go low. if there are peripherals which are sensitive to the number of memory accesses, they must be led to believe that the core is still in debug state. by programming the embeddedice macrocell control register, the value on dbgack can be forced to be high. see chapter 9, "embeddedice macrocell," for more details. ns s ab ab + 4 ab + 8 internal cycles eclk nmreq seq a[31:0] d[31:0] dbgack arm.book page 29 wednesday, november 25, 1998 1:11 pm
8-30 debug interface 8.12 pc behavior during debug in order that the core may be forced to branch back to the place at which program ?ow was interrupted by debug, the debugger must keep track of what happens to the pc. there are ?ve cases: breakpoint, watchpoint, watchpoint when another exception occurs, debug request, and system speed access. 8.12.1 breakpoint entry to the debug state from a breakpoint advances the pc by four addresses, or 16 bytes. each instruction executed in debug state advances the pc by one address, or 4 bytes. the normal way to exit from debug state after a breakpoint is to remove the breakpoint, and branch back to the previous breakpoint address. for example, if the core entered debug state from a breakpoint set on a given address and two debug speed instructions were executed, a branch of - 7 addresses must occur (4 for debug entry, + 2 for the instructions ,+1forthe ?nal branch). the following sequence shows the data scanned into scan chain 1. this is msb ?rst, and so the ?rst digit is the value placed in the breakpt bit, followed by the instruction data. 0 e0802000 ; add r2, r0, r0 1 e1826001 ; orr r6, r2, r1 0 eafffff9 ; b -7 (2s complement) note that once in debug state, a minimum of two instructions must be executed before the branch, although these may both be nops ( mov r0 , r0 ). for small branches, the ?nal branch could be replaced with a subtract with the pc as the destination ( sub pc , pc , #28 in the above example). 8.12.2 watchpoints returning to program execution after entering debug state from a watchpoint is done in the same way as described above. debug entry adds four addresses to the pc, and every instruction adds one address. the difference is that since the instruction that caused the watchpoint has executed, the program returns to the next instruction. arm.book page 30 wednesday, november 25, 1998 1:11 pm
pc behavior during debug 8-31 8.12.3 watchpoint with another exception if a watchpoint access simultaneously causes a data abort, the core 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 interrupt, or any other exception, occurs during a watchpoint memory access. the core will enter debug state in the exception mode, and so the debugger must check to see whether this happened. the debugger can deduce whether an exception occurred by looking at the current and previous mode (in the cpsr and spsr), and the value of the pc. if an exception did take place, the user should be given the choice of whether to service the exception before debugging. exiting debug state if an exception occurred is slightly different from the other cases. here, entry to debug state causes the pc to be incremented by three addresses rather than four, and this must be taken into account in the return branch calculation. for example, suppose that an abort occurred on a watchpoint access and 10 instructions had been executed to determine this. the following sequence could be used to return to program execution. 0 e1a00000 ; mov r0, r0 1 e1a00000 ; mov r0, r0 0 eafffff0 ; b -16 this will force a branch back to the abort vector, causing the instruction at that location to be refetched and executed. note that after the abort service routine, the instruction which caused the abort and watchpoint will be re-executed. this will cause the watchpoint to be generated and hence the core will enter debug state again. 8.12.4 debug request entry into debug state using a debug request is similar to a breakpoint. however, unlike a breakpoint, the last instruction will have completed execution and so must not be refetched on exit from debug state. therefore, it can be thought that entry to debug state adds three addresses to the pc, and every instruction executed in debug state adds one. arm.book page 31 wednesday, november 25, 1998 1:11 pm
8-32 debug interface for example, suppose that the user has invoked a debug request, and decides to return to program execution straight away. the following sequence could be used: 0 e1a00000 ; mov r0, r0 1 e1a00000 ; mov r0, r0 0 eafffffa ; b -6 this restores the pc, and restarts the program from the next instruction. 8.12.5 system speed access if a system speed access is performed during debug state, the value of the pc is increased by three 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 core enters abort mode before returning to debug state. this is similar to an aborted watchpoint except that the problem is much harder to ?x, because the abort was not caused by an instruction in the main program, and the pc does not point to the instruction which caused the abort. an abort handler usually looks at the pc to determine the instruction which caused the abort, and hence the abort address. in this case, the value of the pc is invalid, but the debugger should know what location was being accessed. thus the debugger can be written to help the abort handler ?x the memory system. 8.12.6 summary of return address calculations the calculation of the branch return address can be summarized as follows: for normal breakpoint and watchpoint, the branch is: - (4 + n + 3s) for entry through debug request (dbgrq), or watchpoint with exception, the branch is: - (3 + n + 3s) where n is the number of debug speed instructions executed (including the ?nal branch), and s is the number of system speed instructions executed. arm.book page 32 wednesday, november 25, 1998 1:11 pm
priorities/exceptions 8-33 8.13 priorities/exceptions because the normal program ?ow is broken when a breakpoint or a debug request occurs, debug can be thought of as being another type of exception. some of the interaction with other exceptions has been described above. this section summarizes the priorities. 8.13.1 breakpoint with prefetch abort when a breakpoint instruction fetch causes a prefetch abort, the abort is taken and the breakpoint is disregarded. normally, prefetch aborts occur when, for example, an access is made to a virtual address which does not physically exist, and the returned data is therefore invalid. in such a case the operating systems normal action will be to swap in the page of memory and return to the previously invalid address. this time, when the instruction is fetched, and providing the breakpoint is activated (it may be data dependent), the core will enter debug state. thus the prefetch abort takes higher priority than the breakpoint. 8.13.2 interrupts when the core enters debug state, interrupts are automatically disabled. if interrupts are disabled during debug, the core will never be forced into an interrupt mode. interrupts only have this effect on watchpoint accesses. they are ignored at all times on breakpoints. if an interrupt was pending during the instruction prior to entering debug state, the core will enter debug state in the mode of the interrupt. thus, on entry to debug state, the debugger cannot assume that the core will be in the expected mode of the users program. it must check the pc, the cpsr and the spsr to fully determine the reason for the exception. thus, debug takes higher priority than the interrupt, although the core remembers that an interrupt has occurred. arm.book page 33 wednesday, november 25, 1998 1:11 pm
8-34 debug interface 8.13.3 data aborts as described above, when a data abort occurs on a watchpoint access, the core enters debug state in abort mode. thus the watchpoint has higher priority than the abort, although, as in the case of interrupt, the core remembers that the abort happened. 8.14 scan interface timing please be aware that all core ac timing values are technology dependent. to locate the values for your implementation, please refer to the appropriate ARM7TDMI microprocessor core datasheet , available from lsi logic. figure 8.9 scan general timing t bscl t bsch t bsis t bsih t bsod t bsoh t bsss t bssh t bsdd t bsdh t bsdd t bsdh tck tms tdi tdo data in data out arm.book page 34 wednesday, november 25, 1998 1:11 pm
scan interface timing 8-35 1. for correct data latching, the i/o signals (from the core and the pads) must be setup and held with respect to the rising edge of tck in the capture-dr state of the intest and extest instructions. 2. assumes that the data outputs are loaded with the ac test loads (see ac parameter speci?cation). table 8.3 ARM7TDMI scan interface timing symbol parameter notes tbscl tck low period tbsch tck high period tbsis tdi,tms setup to [tcr] tbsih tdi,tms hold from [tcr] tbsoh tdo hold time 2 tbsod tck falling edge to tdo valid 2 tbsss i/o signal setup to [tcr] 1 tbssh i/o signal hold from [tcr] 1 tbsdh data output hold time 2 tbsdd tck falling edge to data output valid 2 tbsr reset period tbse output enable time 2 tbsz output disable time 2 arm.book page 35 wednesday, november 25, 1998 1:11 pm
8-36 debug interface table 8.4 scan chain 0 signal order no. signal type 1 no. signal type 1 1 d[0] i/o 25 d[24] i/o 2 d[1] i/o 26 d[25] i/o 3 d[2] i/o 27 d[26] i/o 4 d[3] i/o 28 d[27] i/o 5 d[4] i/o 29 d[28] i/o 6 d[5] i/o 30 d[29] i/o 7 d[6] i/o 31 d[30] i/o 8 d[7] i/o 32 d[31] i/o 9 d[8] i/o 33 breakpt i 10 d[9] i/o 34 nenin i 11 d[10] i/o 35 nenout o 12 d[11] i/o 36 lock o 13 d[12] i/o 37 bigend i 14 d[13] i/o 38 dbe i 15 d[14] i/o 39 mas[0] o 16 d[15] i/o 40 mas[1] o 17 d[16] i/o 41 bl[0] i 18 d[17] i/o 42 bl[1] i 19 d[18] i/o 43 bl[2] i 20 d[19] i/o 44 bl[3] i 21 d[20] i/o 45 dctl 2 o 22 d[21] i/o 46 nrw o 23 d[22] i/o 47 dbgack o 24 d[23] i/o 48 cgendbgack o (sheet 1 of 3) arm.book page 36 wednesday, november 25, 1998 1:11 pm
scan interface timing 8-37 49 nfiq i 72 tbit o 50 nirq i 73 nwait i 51 nreset i 74 a[31] o 52 isync i 75 a[30] o 53 dbgrq i 76 a[29] o 54 abort i 77 a[28] o 55 cpa i 78 a[27] o 56 nopc o 79 a[26] o 57 ifen i 80 a[25] o 58 ncpi o 81 a[24] o 59 nmreq o 82 a[23] o 60 seq o 83 a[22] o 61 ntrans o 84 a[21] o 62 cpb i 85 a[20] o 63 nm[4] o 86 a[19] o 64 nm[3] o 87 a[18] o 65 nm[2] o 88 a[17] o 66 nm[1] o 89 a[16] o 67 nm[0] o 90 a[15] o 68 nexec o 91 a[14] o 69 ale i 92 a[13] o 70 abe i 93 a[12] o 71 ape i 94 a[11] o table 8.4 scan chain 0 signal order (cont.) no. signal type 1 no. signal type 1 (sheet 2 of 3) arm.book page 37 wednesday, november 25, 1998 1:11 pm
8-38 debug interface 8.15 debug timing please be aware that all core ac timing values are technology dependent. to locate the values for your implementation, please refer to the appropriate ARM7TDMI microprocessor core datasheet , available from lsi logic. 95 a[10] o 101 a[4] o 96 a[9] o 102 a[3] o 97 a[8] o 103 a[2] o 98 a[7] o 104 a[1] o 99 a[6] o 105 a[0] o 100 a[5] o C C C 1. i - input, o - output, i/o - input/output 2. dctl is not described in this manual. dctl is an output from the processor used to control the unidirectional data out latch, dout [31:0]. dctl is not visible from the periphery of ARM7TDMI. table 8.4 scan chain 0 signal order (cont.) no. signal type 1 no. signal type 1 (sheet 3 of 3) table 8.5 ARM7TDMI debug interface timing symbol parameter ttdbgd tck falling to dbgack, dbgrqi changing ttpfd tckf to tap outputs ttpfh tap outputs hold time from tckf ttprd tckr to tap outputs ttprh tap outputs hold time from tckr ttckr tck to tck1, tck2 rising ttckf tck to tck1, tck2 falling (sheet 1 of 2) arm.book page 38 wednesday, november 25, 1998 1:11 pm
debug timing 8-39 tecapd tck to ecapclk changing tdckf dclk induced: tckf to various outputs valid tdckfh dclk induced: various outputs hold from tckf tdckr dclk induced: tckr to various outputs valid tdckrh dclk induced: various outputs hold from tckr ttrstd ntrstf to tap outputs valid ttrsts ntrstr setup to tckr tsdtd sdoutbs to tdo valid tclkbs tck to boundary scan clocks tshbsr tck to shclkbs, shclk2bs rising tshbsf tck to shclkbs, shclk2bs falling table 8.5 ARM7TDMI debug interface timing (cont.) symbol parameter (sheet 2 of 2) arm.book page 39 wednesday, november 25, 1998 1:11 pm
8-40 debug interface arm.book page 40 wednesday, november 25, 1998 1:11 pm
book title 9-1 chapter 9 embeddedice macrocell this chapter describes the ARM7TDMI embeddedice macrocell. this chapter contains the following sections: section 9.1, overview, page 9-1 section 9.2, watchpoint registers, page 9-3 section 9.3, programming breakpoints, page 9-8 section 9.4, programming watchpoints, page 9-10 section 9.5, debug control register, page 9-11 section 9.6, debug status register, page 9-12 section 9.7, coupling breakpoints and watchpoints, page 9-14 section 9.8, disabling embeddedice macrocell, page 9-17 section 9.9, embeddedice macrocell timing, page 9-17 section 9.10, programming restriction, page 9-17 section 9.11, debug communication channel, page 9-18 9.1 overview the ARM7TDMI embeddedice macrocell provides integrated on-chip debug support for the ARM7TDMI core. embeddedice macrocell is programmed in a serial fashion using the tap controller. it consists of two real-time watchpoint units, together with a control and status register. one or both of the watchpoint units can be programmed to halt the execution of instructions by the core through its breakpt signal. execution is halted when a match occurs between the values programmed into embeddedice macrocell and the values arm.book page 1 wednesday, november 25, 1998 1:11 pm
9-2 embeddedice macrocell currently appearing on the address bus, data bus and various control signals. any bit can be masked so that its value does not affect the comparison. figure 9.1 shows the relationship between the core, embeddedice macrocell and the tap controller. note: only those signals that are pertinent to embeddedice macrocell are shown. figure 9.1 embeddedice block diagram mas[1:0] a[31:0] d[31:0] nopc nrw ntrans dbgacki breakpti dbgrqi ifen eclk nmreq extern1 extern0 breakpt dbgrq dbgack tck dbgen ta p embeddedice processor tms tdi tdo sdin sdout ntrst tbit rangeout0 rangeout1 core arm.book page 2 wednesday, november 25, 1998 1:11 pm
watchpoint registers 9-3 either watchpoint unit can be con?gured to be a watchpoint (monitoring data accesses) or a breakpoint (monitoring instruction fetches). watchpoints and breakpoints can be made to be data dependent. two independent registers, debug control and debug status, provide overall control of the embeddedice macrocell operation. 9.2 watchpoint registers the two watchpoint units, known as watchpoint 0 and watchpoint 1, each contain three pairs of registers: 1. address value and address mask 2. data value and data mask 3. control value and control mask each register is independently programmable, and has its own address: see table 9.1 . table 9.1 function and mapping of embeddedice registers address width function 0b00000 3 debug control 0b00001 5 debug status 0b00100 6 debug communications control register 0b00101 32 debug communications data register 0b01000 32 watchpoint 0 address value 0b01001 32 watchpoint 0 address mask 0b01010 32 watchpoint 0 data value 0b01011 32 watchpoint 0 data mask (sheet 1 of 2) arm.book page 3 wednesday, november 25, 1998 1:11 pm
9-4 embeddedice macrocell 9.2.1 programming and reading watchpoint registers a register is programmed by scanning data into the embeddedice macrocell scan chain (scan chain 2). the scan chain consists of a 38-bit shift register comprising a 32-bit data ?eld, a 5-bit address ?eld and a read/write bit. this is shown in figure 9.2 . 0b01100 9 watchpoint 0 control value 0b01101 8 watchpoint 0 control mask 0b10000 32 watchpoint 1address value 0b10001 32 watchpoint 1 address mask 0b10010 32 watchpoint 1 data value 0b10011 32 watchpoint 1 data mask 0b10100 9 watchpoint 1 control value 0b10101 8 watchpoint 1 control mask table 9.1 function and mapping of embeddedice registers (cont.) address width function (sheet 2 of 2) arm.book page 4 wednesday, november 25, 1998 1:11 pm
watchpoint registers 9-5 figure 9.2 embeddedice macrocell block diagram the data to be written is scanned into the 32-bit data ?eld, the address of the register into the 5-bit address ?eld an d a 1 into the read/write bit. a register is read by scanning its address into the address ?eld and a 0 into the read/write bit. the 32-bit data ?eld is ignored. the register addresses are shown in table 9.1 . note: a read or write actually takes place when the tap controller enters the update-dr state. 9.2.2 using the mask registers for each value register in a register pair, there is a mask register of the same format. setting a bit to 1 in the mask register causes the comparator to disregard the corresponding bit in the value register. address data address decoder update r/w tdi tdo a[31:0] d[31:0] + watchpoint breakpoint 0 31 0 4 control scan chain register registers and comparators comparator value mask 32 arm.book page 5 wednesday, november 25, 1998 1:11 pm
9-6 embeddedice macrocell for example, if a watchpoint is required 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 ?eld ignored. note: the mask is an xnor mask rather than a conventional and mask: when a mask bit is set to 1, the comparator for that bit position will always match, irrespective of the value register or the input value. setting the mask bit to 0 means that the comparator will only match if the input value matches the value programmed into the value register. 9.2.3 control registers the control value and control mask registers are mapped identically in the lower eight bits, as shown below. figure 9.3 watchpoint control value and mask format bit 8 of the control value register is the enable bit, which cannot be masked. the bits have the following functions: enable 8 if a watchpoint match occurs, the breakpt signal will only be asserted when the enable bit is set. this bit only exists in the value register: it cannot be masked. range 7 can be connected to the range output of another watchpoint register. in the embeddedice macrocell, the rangeout output of watchpoint 1 is connected to the range input of watchpoint 0. this allows the two watchpoints to be coupled for detecting conditions that occur simultaneously, e.g., for range checking. 876543210 enable range chain extern ntrans nopc mas[1] mas[0] nrw arm.book page 6 wednesday, november 25, 1998 1:11 pm
watchpoint registers 9-7 chain 6 can be connected to the 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 embeddedice macrocell, the chainout output of watchpoint 1 is connected to the chain input of watchpoint 0. the chainout output is derived from a latch; the address/control ?eld comparator drives the write enable for the latch and the input to the latch is the value of the data ?eld comparator. the chainout latch is cleared when the control value register is written or when ntrst is low. extern 5 an external input to embeddedice macrocell which 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. ntrans 4 compares against the not translate signal from the core in order to distinguish between user mode (ntrans = 0) and nonuser mode (ntrans = 1) accesses. nopc 3 used to detect whether the current cycle is an instruction fetch (nopc = 0) or a data access (nopc = 1). mas[1:0] [2:1] compares against the mas[1:0] signal from the core in order to detect the size of bus activity. the encoding is shown in the following table. bit 1 bit 0 data size 0 0 byte 0 1 halfword 10word 1 1 (reserved) arm.book page 7 wednesday, november 25, 1998 1:11 pm
9-8 embeddedice macrocell nrw 0 compares against the not read/write signal from the core in order to detect the direction of bus activity. nrw is zero for a read cycle and one for a write cycle. for each of the bits 8:0 in the control value register, there is a corresponding bit in the control mask register. this removes the dependency on particular signals. 9.3 programming breakpoints breakpoints can be classi?ed as hardware breakpoints or software breakpoints. hardware breakpoints C monitor the address value and can be set in any code, even in code that is in rom or code that is selfmodifying. software breakpoints C monitor a particular bit pattern being fetched from any address. one embeddedice macrocell watchpoint can thus be used to support any number of software breakpoints. software breakpoints can normally only be set in ram because an instruction has to be replaced by the special bit pattern chosen to cause a software breakpoint. 9.3.1 hardware breakpoints to make a watchpoint unit cause hardware breakpoints (i.e., on instruction fetches): 1. program its address value register with the address of the instruction that will generate the breakpoint. 2. for a breakpoint in arm state, program bits [1:0] of the address mask register to 1. for a breakpoint in thumb state, program bit 0 of the address mask to 1. in both cases the remaining bits are set to 0. 3. program the data value register only if you require a data dependent breakpoint: i.e., only if the actual instruction code fetched must be matched as well as the address. if the data value is not required, program the data mask register to 0xffffffff (all bits to1), otherwise program it to 0x00000000. arm.book page 8 wednesday, november 25, 1998 1:11 pm
programming breakpoints 9-9 4. program the control value register with nopc = 0. 5. program the control mask register with nopc = 0, all other bits to 1. 6. if you need to make the distinction between user and nonuser mode instruction fetches, program the ntrans value and mask bits as in steps 4 and 5 above. 7. if required, program the extern, range and chain value and mask bits in the same way as in steps 4 and 5 above. 9.3.2 software breakpoints to make a watchpoint unit cause software breakpoints (i.e., on instruction fetches of a particular bit pattern): 1. program its address mask register to 0xffffffff (all bits set to 1) so that the address is disregarded. 2. program the data value register with the particular bit pattern that has been chosen to represent a software breakpoint. 3. if a thumb software breakpoint is being programmed, the 16-bit pattern must be repeated in both halves of the data value register. for example, if the bit pattern is 0xdfff, then 0xdfffdfff must be programmed. when a 16-bit instruction is fetched, embeddedice macrocell only compares the valid half of the data bus against the contents of the data value register. in this way, a single watchpoint register can be used to catch software breakpoints on both the upper and lower halves of the data bus. 4. program the data mask register to 0x00000000. 5. program the control value register with nopc = 0. 6. program the control mask register with nopc = 0, all other bits to 1. 7. if you wish to make the distinction between user and nonuser mode instruction fetches, program the ntrans bit in the control value and control mask registers accordingly. 8. if required, program the extern, range and chain bits in the same way as in steps 5 and 6 above. note: the address value register need not be programmed. arm.book page 9 wednesday, november 25, 1998 1:11 pm
9-10 embeddedice macrocell 9.3.2.1 setting the breakpoint to set the software breakpoint: 1. read the instruction at the desired address and store it away. 2. write the special bit pattern representing a software breakpoint at the address. 9.3.2.2 clearing the breakpoint to clear the software breakpoint, restore the instruction to the address. 9.4 programming watchpoints to make a watchpoint unit cause watchpoints (i.e., on data accesses): 1. program its address value register with the address of the data access to be watchpointed. 2. program the address mask register to 0x00000000. 3. program the data value register only if you require a data dependent watchpoint; i.e. only if the actual data value read or written must be matched as well as the address. if the data value is irrelevant, program the data mask register to 0xffffffff (all bits set to 1) otherwise program it to 0x00000000. 4. program the control value register with nopc = 1, nrw = 0 for a read or nrw = 1 for a write, mas[1:0] with the value corresponding to the appropriate data size. 5. program the control mask register with nopc = 0, nrw = 0, mas[1:0] = 0, all other bits to 1. note that nrw or mas[1:0] may be set to 1 if both reads and writes or data size accesses are to generate watchpoints respectively. 6. if you wish to make the distinction between user and nonuser mode data accesses, program the ntrans bit in the control value and control mask registers accordingly. 7. if required, program the extern, range and chain bits in the same way as steps 4 and 5 above. arm.book page 10 wednesday, november 25, 1998 1:11 pm
debug control register 9-11 note: the above are just examples of how to program the watchpoint register to generate breakpoints and watchpoints; many other ways of programming the registers are possible. for instance, simple range breakpoints can be provided by setting one or more of the address mask bits. 9.5 debug control register the debug control register is 3 bits wide. if the register is accessed for a write (with the read/write bit high), the control bits are written. if the register is accessed for a read (with the read/write bit low), the control bits are read. the layout of the debug control register follows in figure 9.4 figure 9.4 debug control register format as shown in figure 9.6 , the value stored in bit 1 of the control register is synchronized and then ored with the external dbgrq before being applied to the processor. the output of this or gate is the signal dbgrqi which is brought out externally from the macrocell. the synchronization between control bit 1 and dbgrqi is to assist in multiprocessor environments. the synchronization latch only opens when the tap controller state machine is in the run-test/idle state. this allows an enter debug condition to be setup in all the processors in the system while they are still running. once the condition is setup in all the processors, it can then be applied to them simultaneously by entering the run-test/idle state. in the case of dbgack, the value of dbgack from the core is ored with the value held in bit 0 to generate the external value of dbgack seen at the periphery of the core. this allows the debug system to signal to the rest of the system that the core is still being debugged even when system speed accesses are being performed (in which case the internal dbgack signal from the core will be low). 210 intdis dbgrq dbgack arm.book page 11 wednesday, november 25, 1998 1:11 pm
9-12 embeddedice macrocell if bit 2 (intdis) is asserted, the interrupt enable signal (ifen) of the core is forced low. thus all interrupts (nirq and nfiq) are disabled during debugging (dbgack = 1) or if the intdis bit is asserted. the ifen signal is driven according to the following table : 9.6 debug status register the debug status register is 5 bits wide. if it is accessed for a write (with the read/write bit set high), the status bits are written. if it is accessed for a read (with the read/write bit low), the status bits are read. figure 9.5 debug status register format the function of each bit in this register is as follows: tbit 4 allows tbit to be read. this enables the debugger to determine what state the processor is in, and hence which instructions to execute. nmreq 3 allows the state of the nmreq signal from the core (synchronized to tck) to be read. this allows the debugger to determine that a memory access from the debug state has completed. table 9.2 ifen signal control dbgack intdis ifen 001 1x0 x10 43210 tbit nmreq ifen dbgrq dbgack arm.book page 12 wednesday, november 25, 1998 1:11 pm
debug status register 9-13 ifen 2 allows the state of the core interrupt enable signal (ifen) to be read. since the capture clock for the scan chain may be asynchronous to the processor clock, the dbgack output from the core is synchronized before being used to generate the ifen status bit. dbgrq 1 allows the value on the synchronized version of dbgrq to be read. dbgack 0 allows the value on the synchronized version of dbgack to be read. the structure of the debug status register bits is shown in figure 9.6 . arm.book page 13 wednesday, november 25, 1998 1:11 pm
9-14 embeddedice macrocell figure 9.6 structure of tbit, nmreq, dbgack, dbgrq and intdis bits 9.7 coupling breakpoints and watchpoints watchpoint units 1 and 0 can be coupled together using the chain and range inputs. the use of chain enables watchpoint 0 to be triggered only if watchpoint 1 has previously matched. the use of range enables simple range checking to be performed by combining the outputs of both watchpoints. dbgrq dbgrq dbgack dbgack bit 1 bit 1 debug control register debug status register (from ARM7TDMI input) (to arm7 output) (to core and (from core) + bit 0 + bit 2 bit 2 + ifen (to core) dbgack (from core) synch bit 0 synch + bit 3 synch nmreq (from core) bit 4 synch tbit (from core) synch ARM7TDMI output) arm.book page 14 wednesday, november 25, 1998 1:11 pm
coupling breakpoints and watchpoints 9-15 for the next few examples, let: a v [31:0] be the value in the address value register a m [31:0] be the value in the address mask register a[31:0] be the address bus from the core d v [31:0] be the value in the data value register d m [31:0] be the value in the data mask register d[31:0] be the data bus from the core c v [8:0] be the value in the control value register c m [7:0] be the value in the control mask register c[9:0] be the combined control bus from the core, other watchpoint registers and the extern signal. 9.7.1 chainout signal the chainout signal is then derived as follows: when (({a v [31:0], c v [4:0]} xnor {a[31:0], c[4:0]}) or {a m [31:0],c m [4:0]} == 0xfffffffff) chainout = ((({d v [31:0], c v [6:4]} xnor {d[31:0],c[7:5]}) or {d m [31:0], c m [7:5]}) == 0x7ffffffff) the chainout output of watchpoint register 1 provides the chain input to watchpoint 0. this allows for quite complicated con?gurations of breakpoints and watchpoints. take, for example, the request by a debugger to breakpoint on the instruction at location yyy when running process xxx in a multiprocess system. if the current process id is stored in memory, the above function can be implemented with a watchpoint and breakpoint chained together. the watchpoint address is set to a known memory location containing the current process id, the watchpoint data is set to the required process id and the enable bit is set to off. arm.book page 15 wednesday, november 25, 1998 1:11 pm
9-16 embeddedice macrocell the address comparator output of the watchpoint is used to drive the write enable for the chainout latch, the input to the latch being the output of the data comparator from the same watchpoint. the output of the latch drives the chain input of the breakpoint comparator. the address yyy is stored in the breakpoint register and when the chain input is asserted, and the breakpoint address matches, the breakpoint triggers correctly. 9.7.2 rangeout signal the rangeout signal is then derived as follows: rangeout = ((({av[31:0], cv[4:0]} xnor {a[31:0], c[4:0]}) or {am[31:0], cm[4:0]}) == 0xfffffffff) and ((({dv[31:0],cv[7:5]} xnor {d[31:0],c[7:5]}) or {dm[31:0],cm[7:5]}) == 0x7ffffffff) the rangeout output of watchpoint register 1 provides the range input to watchpoint register 0. this allows two breakpoints to be coupled together to form range breakpoints. note that selectable ranges are restricted to being powers of 2. this is best illustrated by an example. example C if a breakpoint is to occur when the address is in the ?rst 256 bytes of memory, but not in the ?rst 32 bytes, the watchpoint registers should be programmed as follows: 1. watchpoint 1 is programmed with an address value of 0x00000000 and an address mask of 0x0000001f. the enable bit is cleared. all other watchpoint 1 registers are programmed as normal for a breakpoint. an address within the ?rst 32 bytes will cause the range output to go high but the breakpoint will not be triggered. 2. watchpoint 0 is programmed with an address value of 0x00000000 and an address mask of 0x000000ff. the enable bit is set and the range bit programmed to match a 0. all other watchpoint 0 registers are programmed as normal for a breakpoint. if watchpoint 0 matches but watchpoint 1 does not (i.e., the range input to watchpoint 0 is 0), the breakpoint will be triggered. arm.book page 16 wednesday, november 25, 1998 1:11 pm
disabling embeddedice macrocell 9-17 9.8 disabling embeddedice macrocell embeddedice macrocell may be disabled by wiring the dbgen input low. when dbgen is low, breakpt and dbgrq to the core are forced low, dbgack from the core is also forced low and the ifen input to the core is forced high, enabling interrupts to be detected by the core. when dbgen is low, embeddedice macrocell is also put into a low power mode. 9.9 embeddedice macrocell timing the extern1 and extern0 inputs are sampled by embeddedice macrocell on the falling edge of eclk. suf?cient setup and hold time must therefore be allowed for these signals. 9.10 programming restriction the embeddedice macrocell watchpoint units should only be programmed when the clock to the core is stopped. this can be achieved by putting the core into the debug state. the reason for this restriction is that if the core continues to run at eclk rates when embeddedice macrocell is being programmed at tck rates, it is possible for the breakpt signal to be asserted asynchronously to the core. this restriction does not apply if mclk and tck are driven from the same clock, or if it is known that the breakpoint or watchpoint condition can only occur some time after embeddedice macrocell has been programmed. note: this restriction does not apply in any event to the debug control or status registers. arm.book page 17 wednesday, november 25, 1998 1:11 pm
9-18 embeddedice macrocell 9.11 debug communication channel the embeddedice macrocell contains a communication channel for passing information between the target and the host debugger. this is implemented as coprocessor 14. the communications channel consists of a 32-bit wide communications data read register, a 32-bit wide communications data write register and a 6-bit wide communications control register for synchronized handshaking between the processor and the asynchronous debugger. these registers live in ?xed locations in embeddedice macrocells memory map (as shown in table 9.1 ) and are accessed from the processor using the mcr and mrc instructions to coprocessor 14. 9.11.1 debug communications control registers the debug communications control register is read only and allows synchronized handshaking between the processor and the debugger. figure 9.7 debug communications control register the function of each register bit is described below: 0001 [31:28] w1 denotes whether the communications data write register is free or not. if the communications data write register is free (w = 0) then new data may be written. if it is not free (w = 1), then the processor must poll until w = 0. from the debuggers point of view, if w = 1 then some new data has been written which may then be scanned out. r0 denotes whether there is some new data in the communications data read register. if r = 1, then there is some new data which may be read using an mrc instruction. if r = 0 then the communications data read 31 28 27 2 1 0 0001 . . . w r arm.book page 18 wednesday, november 25, 1998 1:11 pm
debug communication channel 9-19 register is free and new data may be placed there through the scan chain. if r = 1, then this denotes that data previously placed there through the scan chain has not been collected by the processor and so the debugger must wait. from the debuggers point of view, the registers are accessed using the scan chain in the usual way. from the processor, these registers are accessed using coprocessor register transfer instructions. the following instructions should be used: mrc p14, 0, rd, c0, c0, 0 returns the debug communications control register into rd mcr p14, 0, rn, c1, c0, 0 writes the value in rn to the communications data write register mrc p14, 0, rd, c1, c0, 0 returns the debug data read register into rd since the thumb instruction set does not contain coprocessor instructions, it is recommended that these are accessed using swi instructions when in thumb state. 9.11.2 communication through the communications channel communication between the debugger and the processor occurs as follows. when the processor wishes to send a message to embeddedice macrocell, it ?rst checks that the communications data write register is free for use. this is done by reading the debug communications control register to check that the w bit is clear. if it is clear then the communications data write register is empty and a message is written by a register transfer to the coprocessor. the action of this data transfer automatically sets the w bit. if on reading the w bit it is found to be set, then this implys that previously written data has not been picked up by the debugger and thus the processor must poll until the w bit is clear. as the data transfer occurs from the processor to the communications data write register, the w bit is set in the debug communications control register. when the debugger polls this register it sees a arm.book page 19 wednesday, november 25, 1998 1:11 pm
9-20 embeddedice macrocell synchronized version of both the r and w bit. when the debugger sees that the w bit is set it can read the communications data write register and scan the data out. the action of reading this data register clears the w bit of the debug communications control register. at this point, the communications process may begin again. message transfer from the debugger to the processor is carried out in a similar fashion. here, the debugger polls the r bit of the debug communications control register. if the r bit is low then the data read register is free and so data can be placed there for the processor to read. if the r bit is set, then previously deposited data has not yet been collected and so the debugger must wait. when the communications data read register is free, data is written there using the scan chain. the action of this write sets the r bit in the debug communications control register. when the processor polls this register, it sees an mclk synchronized version. if the r bit is set then this denotes that there is data waiting to be collected, and this can be read using a cprt load. the action of this load clears the r bit in the debug communications control register. when the debugger polls this register and sees that the r bit is clear, this denotes that the data has been taken and the process may now be repeated. arm.book page 20 wednesday, november 25, 1998 1:11 pm
book title 10-1 chapter 10 instruction cycle operations this chapter describes the ARM7TDMI core instruction cycle operations. it contains the following sections: section 10.1, introduction, page 10-2 section 10.2, branch and branch with link, page 10-2 section 10.3, thumb branch with link, page 10-3 section 10.4, branch and exchange (bx), page 10-4 section 10.5, data operations, page 10-5 section 10.6, multiply and multiply accumulate, page 10-7 section 10.7, load register, page 10-9 section 10.8, store register, page 10-10 section 10.9, load multiple registers, page 10-10 section 10.10, store multiple registers, page 10-12 section 10.11, data swap, page 10-13 section 10.12, software interrupt and exception entry, page 10-14 section 10.13, coprocessor data operation, page 10-15 section 10.14, coprocessor data transfer (memory to coprocessor), page 10-16 section 10.15, coprocessor data transfer (from coprocessor to memory), page 10-18 section 10.16, coprocessor register transfer (load from coprocessor), page 10-20 section 10.17, coprocessor register transfer (store to coprocessor), page 10-21 arm.book page 1 wednesday, november 25, 1998 1:11 pm
10-2 instruction cycle operations section 10.18, unde?ned instructions and coprocessor absent, page 10-22 section 10.19, unexecuted instructions, page 10-23 section 10.20, instruction speed summary, page 10-23 10.1 introduction in the following tables nmreq and seq (which are pipelined up to one cycle ahead of the cycle to which they apply) are shown in the cycle in which they appear, so they predict the type of the next cycle. the address, mas[1:0], nrw, nopc, ntrans and tbit (which appear up to half a cycle ahead) are shown in the cycle to which they apply. the address is incremented for prefetching of instructions in most cases. since the instruction width is 4 bytes in arm state and 2 bytes in thumb state, the increment will vary accordingly. hence the letter l is used to indicate instruction length (4 bytes in arm state and 2 bytes in thumb state). similarly, the letter i indicates the width of the instruction fetch (i = 2 in arm state and i = 1 in thumb state) representing word and halfword accesses respectively. 10.2 branch and branch with link a branch instruction calculates the branch destination in the ?rst cycle, while performing a prefetch from the current pc. this prefetch is done in all cases, since by the time the decision to take the branch has been reached it is already too late to prevent the prefetch. during the second cycle a fetch is performed from the branch destination, and the return address is stored in register 14 if the link bit is set. the third cycle performs a fetch from the destination + l, re?lling the instruction pipeline, and if the branch with link r14 is modi?ed (4 is subtracted from it) to simplify return from sub pc,r14,#4 to mov pc,r14 . this makes the stm..{r14} ldm..{pc} type of subroutine work correctly. the cycle timings are shown below in table 10.1 . arm.book page 2 wednesday, november 25, 1998 1:11 pm
thumb branch with link 10-3 10.3 thumb branch with link a thumb branch with link operation consists of two consecutive thumb instructions. the ?rst instruction acts like a simple data operation, taking a single cycle to add the pc to the upper part of the offset, storing the result in register 14 (lr). the second instruction acts in a similar fashion to the arm branch with link instruction, thus its ?rst cycle calculates the ?nal branch destination while performing a prefetch from the current pc. the second cycle of the second instruction performs a fetch from the branch destination and the return address is stored in r14. the third cycle of the second instruction performs a fetch from the destination + 2, re?lling the instruction pipeline and r14 is modi?ed (2 subtracted from it) to simplify the return to mov pc, r14 . this makes the push {..,lr} ; pop {..,pc} type of subroutine work correctly. the cycle timings of the complete operation are shown in table 10.2 . table 10.1 branch instruction cycle operations 1 1. this table applies to branches in arm and thumb state, and to branch with link in arm state only. cycle address mas[1:0] 2 2. i = 2 in arm state and i = 1 in thumb state. nrw data nmreq seq nopc 1pc+2l 3 3. pc is the address of the branch instruction. i 0 (pc + 2l) 0 0 0 2 alu 4 4. alu is an address calculated by the core. i 0 (alu) 5 5. (alu) are the contents of that address. 010 3 alu + l i 0 (alu + l) 0 1 0 alu+2l arm.book page 3 wednesday, november 25, 1998 1:11 pm
10-4 instruction cycle operations 10.4 branch and exchange (bx) a branch and exchange operation takes 3 cycles and is similar to a branch. in the ?rst cycle, the branch destination and the new core state are extracted from the register source, while performing a prefetch from the current pc. this prefetch is performed in all cases, since by the time the decision to take the branch has been reached, it is already too late to prevent the prefetch. during the second cycle, a fetch is performed from the branch destination using the new instruction width, depending on the state that has been selected. the third cycle performs a fetch from the destination + 2 or + 4 depending on the new speci?ed state, re?lling the instruction pipeline. the cycle timings are shown in table 10.3 . table 10.2 thumb long branch with link cycle address mas[1:0] nrw data nmreq seq nopc 1pc+4 1 1. pc is the address of the ?rst instruction of the operation. 1 0 (pc + 4) 0 1 0 2pc+6 1 1 0 (pc + 6) 0 0 0 3 alu 1 0 (alu) 0 1 0 4 alu + 2 1 0 (alu + 2) 0 1 0 alu + 4 arm.book page 4 wednesday, november 25, 1998 1:11 pm
data operations 10-5 10.5 data operations a data operation executes in a single datapath cycle except where the shift is determined by the contents of a register. a register is read onto the a bus, and a second register or the immediate ?eld onto the b bus. the alu combines the a bus source and the shifted b bus source according to the operation speci?ed in the instruction, and the result (when required) is written to the destination register. (compares and tests do not produce results, only the alu status ?ags are affected.) an instruction prefetch occurs at the same time as the above operation, and the program counter is incremented. when the shift length is speci?ed by a register, an additional datapath cycle occurs before the above operation to copy the bottom 8 bits of that register into a holding latch in the barrel shifter. the instruction prefetch will occur during this ?rst cycle, and the operation cycle will be internal (i.e., will not request memory). this internal cycle can be merged with the following sequential access by the memory manager as the address remains stable through both cycles. table 10.3 branch and exchange instruction cycle operations cycle address 1 mas [1:0] 2 nrw data nmreq seq nopc tbit 3 1 pc + 2w i 0 (pc + 2w) 0 0 0 t 2 alu i 0 (alu) 0 1 0 t 3 alu + w i 0 (alu + w) 0 1 0 t alu+2w 1. w and w represent the instruction width before and after the bx respectively. in arm state the width equals 4 bytes and in thumb state the width equals 2 bytes. for example, when changing from arm to thumb state, w would equal 4 and w would equal 2. 2. i and i represent the memory access size before and after the bx respectively. in arm state, the mas[1:0] is 2 and in thumb state mas[1:0] is 1. when changing from thumb to arm state, i would equal 1 and i would equal 2. 3. t and t represent the state of the tbit before and after the bx respectively. in arm state tbit is 0 and in thumb state tbit is 1. when changing from arm to thumb state, t would equal 0 and t would equal 1. arm.book page 5 wednesday, november 25, 1998 1:11 pm
10-6 instruction cycle operations the pc may be one or more of the register operands. when it is the destination, external bus activity may be affected. if the result is written to the pc, the contents of the instruction pipeline are invalidated, and the address for the next instruction prefetch is taken from the alu rather than the address incrementer. the instruction pipeline is re?lled before any further execution takes place, and during this time exceptions are locked out. psr transfer operations exhibit the same timing characteristics as the data operations except that the pc is never used as a source or destination register. the cycle timings are shown below table 10.4 . table 10.4 data operation instruction cycle operations cycle address mas[1:0] 1 nrw data nmreq seq nopc normal 1 pc + 2l i 0 (pc + 2l) 0 1 0 pc + 3l dest = pc 1 pc + 2l i 0 (pc + 2l) 0 0 0 2 alu i 0 (alu) 0 1 0 3 alu + l i 0 (alu + l) 0 1 0 alu + 2l shift(rs) 1 pc + 2l i 0 (pc + 2l) 1 0 0 2pc+3li 0C 0 11 pc + 3l shift(rs) dest = pc 2 1 pc+8 2 0 (pc+8) 1 0 0 2pc+122 0C 0 01 3 alu 2 0 (alu) 0 1 0 4 alu + 4 2 0 (alu + 4) 0 1 0 alu + 8 1. i = 2 in arm state and i = 1 in thumb state 2. shifted register with destination equals pc is not possible in thumb state. arm.book page 6 wednesday, november 25, 1998 1:11 pm
multiply and multiply accumulate 10-7 10.6 multiply and multiply accumulate the multiply instructions make use of special hardware which implements integer multiplication with early termination. all cycles except the ?rst are internal. the cycle timings are shown in the following four tables, where m is the number of cycles required by the multiplication algorithm; see section 10.20, instruction speed summary, for more information. table 10.5 multiply instruction cycle operations cycle address nrw mas[1:0] 1 1. i = 2 in arm state and i = 1 in thumb state. data nmreq seq nopc 1 pc + 2l 0 i (pc + 2l) 1 0 0 2pc+3l0i C 101 ?pc+3l0i C101 mpc+3l0i C 101 m+1 pc+3l 0 i C 0 1 1 pc + 3l table 10.6 multiply accumulate instruction cycle operations cycle address nrw mas[1:0] 1 1. i = 2 in arm state and i = 1 in thumb state. data nmreq seq nopc 1 pc + 8 0 2 (pc + 8) 1 0 0 2pc+802 C101 ?pc+1202 C101 mpc+1202 C 101 m+1 pc+12 0 2 C 1 0 1 m+2 pc+12 0 2 C 0 1 1 pc + 12 arm.book page 7 wednesday, november 25, 1998 1:11 pm
10-8 instruction cycle operations table 10.7 multiply long instruction cycle operation cycle address nrw mas[1:0] 1 1. i = 2 in arm state and i = 1 in thumb state. data nmreq seq nopc 1 pc + 2l 0 i (pc + 2l) 1 0 0 2pc+3l0i C 1 01 ?pc+3l0i C 1 01 mpc+3l0i C 1 0 1 m+1 pc+3l 0 i C 1 0 1 m+2 pc+3l 0 i C 0 1 1 pc + 3l table 10.8 multiply accumulate 1 long instruction cycle operation 1. multiply accumulate is not possible in thumb state. cycle address nrw mas[1:0] 2 2. i = 2 in arm state and i = 1 in thumb state. data nmreq seq nopc 1 pc + 8 0 2 (pc + 8) 1 0 0 2pc+802 C101 ?pc+1202 C101 mpc+1202 C101 m+1pc+1202 C101 m+2pc+1202 C101 m+3pc+1202 C011 pc + 12 arm.book page 8 wednesday, november 25, 1998 1:11 pm
load register 10-9 10.7 load register the ?rst cycle of a load register instruction performs the address calculation. the data is fetched from memory during the second cycle, and the base register modi?cation is performed during this cycle (if required). during the third cycle the data is transferred to the destination register, and external memory is unused. this third cycle may normally be merged with the following prefetch to form one memory n-cycle. the cycle timings are shown below in table 10.9 . either the base or the destination (or both) may be the pc, and the prefetch sequence will be changed if the pc is affected by the instruction. the data fetch may abort, and in this case the destination modi?cation is prevented table 10.9 load register instruction cycle operations cycle address mas[1:0] 1 1. i = 2 in arm state and i = 1 in thumb state. nrw data nmreq seq nopc ntrans normal 1 pc + 2l i 0 (pc + 2l) 0 0 0 c 2 2. c represents current mode-dependent value. 2 alu b/h/w 3 3. b, h and w are byte, halfword and word as de?ned in section 9.5, debug control register. 0 (alu) 1 0 1 d 4 4. d will either be 0 if the t bit has been speci?ed in the instruction (eg. ldrt), or c at all other times. 3 pc + 3l i 0 C 0 1 1 c pc + 3l dest = pc 5 5. destination equals pc is not possible in thumb state. 1 pc + 2 0 (pc + 8) 0 0 0 c 2 alu 0 pc 1 0 1 d 3 pc + 12 2 0 C 0 0 1 c 4 pc 2 0 (pc) 0 1 0 c 5 pc + 4 2 0 (pc + 4) 0 1 0 c pc + 8 arm.book page 9 wednesday, november 25, 1998 1:11 pm
10-10 instruction cycle operations 10.8 store register the ?rst cycle of a store register is similar to the ?rst cycle of load register. during the second cycle the base modi?cation is performed, and at the same time the data is written to memory. there is no third cycle. 10.9 load multiple registers the ?rst cycle of ldm is used to calculate the address of the ?rst word to be transferred, while performing a prefetch from memory. the second cycle fetches the ?rst word, and performs the base modi?cation. during the third cycle, the ?rst word is moved to the appropriate destination register while the second word is fetched from memory, and the modi?ed base is latched internally in case it is needed to patch up after an abort. the third cycle is repeated for subsequent fetches until the last data word has been accessed, then the ?nal (internal) cycle moves the last word to its destination register. the cycle timings are shown in table 10.11 . the last cycle may be merged with the next instruction prefetch to form a single memory n-cycle. if an abort occurs, the instruction continues to completion, but all register writing after the abort is prevented. the ?nal cycle is altered to restore the modi?ed base register (which may have been overwritten by the load activity before the abort occurred). when the pc is in the list of registers to be loaded the current instruction pipeline must be invalidated. table 10.10 store register instruction cycle operations cycle address mas[1:0] 1 nrw data nmreq seq nopc ntrans 1 pc + 2l i 0 (pc + 2l) 0 0 0 c 2 2 alu b/h/w 3 1rd0 01d 4 pc+3l 1. i = 2 in arm state and i = 1 in thumb state. 2. c represents current mode dependent value. 3. b, h, and w are byte, halfword and word as de?ned in section 9.5, debug control register. 4. d will either be 0 if the t bit has been speci?ed in the instruction (e.g., sdrt), or c at all other times. arm.book page 10 wednesday, november 25, 1998 1:11 pm
load multiple registers 10-11 note: the pc is always the last register to be loaded, so an abort at any point will prevent the pc from being overwritten. ldm with destination = pc cannot be executed in thumb state. however pop{rlist,pc} equates to an ldm with destination = pc. table 10.11 load multiple registers instruction cycle operations cycle address mas[1:0] 1 nrw data nmreq seq nopc 1 register 1 pc + 2l i 0 (pc + 2l) 0 0 0 2 alu 2 0 (alu) 1 0 1 3 pc+3l i 0 C 0 1 1 pc+3l 1 register dest = pc 1 pc + 2l i 0 (pc + 2l) 0 0 0 2 alu 2 0 pc 1 0 1 3 pc+3l i 0 C 0 0 1 4 pc i 0 (pc) 0 1 0 5 pc + l i 0 (pc + l) 0 1 0 pc+2l n registers (n > 1) 1 pc + 2l i 0 (pc + 2l) 0 0 0 2 alu 2 0 (alu) 0 1 1 ? alu + ? 2 0 (alu + ?) 0 1 1 n alu + ? 2 0 (alu + ?) 0 1 1 n + 1 alu + ? 2 0 (alu + ?) 1 0 1 n+2 pc+3l i 0 C 0 1 1 pc+3l (sheet 1 of 2) arm.book page 11 wednesday, november 25, 1998 1:11 pm
10-12 instruction cycle operations 10.10 store multiple registers store multiple registers proceeds very much as load multiple, without the ?nal cycle. the restart problem is much more straightforward here, as there is no wholesale overwriting of registers. the cycle timings are shown in table 10.12 , below. . n registers (n > 1) incl pc 1 pc + 2l i 0 (pc + 2l) 0 0 0 2 alu 2 0 (alu) 0 1 1 ? alu + ? 2 0 (alu + ?) 0 1 1 n alu + ? 2 0 (alu + ?) 0 1 1 n + 1 alu + ? 2 0 pc 1 0 1 n+2 pc+3l i 0 C 0 0 1 n + 3 pc i 0 (pc) 0 1 0 n + 4 pc + l i 0 (pc + l) 0 1 0 pc+2l 1. i = 2 in arm state and i = 1 in thumb state. table 10.11 load multiple registers instruction cycle operations (cont.) cycle address mas[1:0] 1 nrw data nmreq seq nopc (sheet 2 of 2) table 10.12 store multiple registers instruction cycle operations cycle address mas[1:0] 1 nrw data nmreq seq nopc 1 register 1 pc + 2l i 0 (pc + 2l) 0 0 0 2 alu 2 1 ra 0 0 1 pc + 3l (sheet 1 of 2) arm.book page 12 wednesday, november 25, 1998 1:11 pm
data swap 10-13 10.11 data swap this is similar to the load and store register instructions, but the actual swap takes place in cycles 2 and 3. in the second cycle, the data is fetched from external memory. in the third cycle, the contents of the source register are written out to the external memory. the data read in cycle 2 is written into the destination register during the fourth cycle. the cycle timings are shown below in table 10.13 . the lock output of the core is driven high for the duration of the swap operation (cycles 2 and 3) to indicate that both cycles should be allowed to complete without interruption. the data swapped may be a byte or word quantity (b/w). the swap operation may be aborted in either the read or write cycle, and in both cases the destination register will not be affected. n registers (n > 1) 1 pc + 8 i 0 (pc + 2l) 0 0 0 2 alu 2 1 ra 0 1 1 ? alu+? 2 1 r? 0 1 1 n alu+? 2 1 r? 0 1 1 n+1 alu+? 2 1 r? 0 0 1 pc + 12 1. i = 2 in arm state and i = 1 in thumb state. table 10.12 store multiple registers instruction cycle operations (cont.) cycle address mas[1:0] 1 nrw data nmreq seq nopc (sheet 2 of 2) arm.book page 13 wednesday, november 25, 1998 1:11 pm
10-14 instruction cycle operations . 10.12 software interrupt and exception entry exceptions (and software interrupts) force the pc to a particular value and re?ll the instruction pipeline from there. during the ?rst cycle the forced address is constructed, and a mode change may take place. the return address is moved to r14 and the cpsr to spsr_svc . during the second cycle the return address is modi?ed to facilitate return, though this modi?cation is less useful than in the case of branch with link. the third cycle is required only to complete the re?lling of the instruction pipeline. the cycle timings are shown below in table 10.14 . table 10.13 data swap instruction cycle operations 1 1. data swap cannot be executed in thumb state. cycle address mas[1:0] nrw data nmreq seq nopc lock 1 pc + 8 2 0 (pc + 8) 0 0 0 0 2 rn b/w 2 2. b and w are byte and word as de?ned in section 9.5, debug control register. 0 (rn) 0 0 1 1 3 rn b/w 1 rm 1 0 1 1 4 pc + 12 2 0 C 0 1 1 0 pc + 12 arm.book page 14 wednesday, november 25, 1998 1:11 pm
coprocessor data operation 10-15 10.13 coprocessor data operation this operation cannot occur in thumb state. a coprocessor data operation is a request from the core for the coprocessor to initiate some action. the action need not be completed for some time, but the coprocessor must commit to doing it before driving cpb low. if the coprocessor can never do the requested task, it should leave cpa and cpb high. if it can do the task, but cant commit right now, it should drive cpa low but leave cpb high until it can commit. the core will busy-wait until cpb goes low. the cycle timings are shown in table 10.15 . table 10.14 software interrupt instruction cycle operations cycle address mas [1:0] 1 1. i = 2 in arm state and i = 1 in thumb state. nrw data nmreq seq nopc ntrans mode tbit 1pc+2l 2 2. pc is for software interrupts is the address of the swi instruction. for exceptions is the address of the instruction following the last one to be executed before entering the exception.for prefetch aborts is the address of the aborting instruction. for data aborts is the address of the instruction following the one which attempted the aborted data transfer. i 0 (pc + 2l) 0 0 0 c 3 3. c represents the current mode dependent value. old mode t 4 4. t represents the current state dependent value. 2xn 5 5. xn is the appropriate trap address. 2 0 (xn) 0 1 0 1 exception mode 0 3 xn + 4 2 0 (xn + 4) 0 1 0 1 exception mode 0 xn + 8 arm.book page 15 wednesday, november 25, 1998 1:11 pm
10-16 instruction cycle operations 10.14 coprocessor data transfer (memory to coprocessor) this operation cannot occur in thumb state.here the coprocessor should commit to the transfer only when it is ready to accept the data. when cpb goes low, the core will produce addresses and expect the coprocessor to take the data at sequential cycle rates. the coprocessor is responsible for determining the number of words to be transferred, and indicates the last transfer cycle by driving cpa and cpb high. the core spends the ?rst cycle (and any busy-wait cycles) generating the transfer address, and performs the write-back of the address base during the transfer cycles. the cycle timings are shown in table 10.16 . table 10.15 coprocessor data operation instruction cycle operations 1 cycle address nrw mas[1:0] data nmreq seq nopc ncpi cpa cpb ready 1 pc + 8 0 2 (pc + 8) 0 0 0 0 0 0 pc + 12 not ready 1 pc+8 0 2 (pc+8) 1 0 0 0 0 1 2pc+802 C 1 01 001 ?pc+802 C 1 01001 npc+802 C 0 01 000 pc + 12 1. this operation cannot occur in thumb state. arm.book page 16 wednesday, november 25, 1998 1:11 pm
coprocessor data transfer (memory to coprocessor) 10-17 table 10.16 coprocessor data transfer instruction cycle operations 1 cycle address mas [1:0] nrw data nmreq seq nopc ncpi cpa cpb 1 register ready 1 pc+8 2 0 (pc+8) 0 0 0 0 0 0 2 (alu) 2 0 (alu) 0 0 1 1 1 1 pc+12 1 register not ready 1 pc+8 2 0 (pc+8) 1 0 0 0 0 1 2 pc+8 2 0 C 1 0 1 0 0 1 ? pc+8 2 0 C 1 0 1 0 0 1 n pc+8 2 0 C 0 0 1 0 0 0 n + 1 alu 2 0 (alu) 0 0 1 1 1 1 pc+12 m registers (m > 1) ready 1 pc+8 2 0 (pc+8) 0 0 0 0 0 0 2 alu 2 0 (alu) 0 1 1 1 0 0 ? alu + ? 2 0 (alu + ?) 0 1 1 1 0 0 n alu + ? 2 0 (alu + ?) 0 1 1 1 0 0 n + 1 alu + ? 2 0 (alu + ?) 0 0 1 1 1 1 pc+12 (sheet 1 of 2) arm.book page 17 wednesday, november 25, 1998 1:11 pm
10-18 instruction cycle operations 10.15 coprocessor data transfer (from coprocessor to memory) this operation cannot occur in thumb state. the core controls these instructions exactly as for memory to coprocessor transfers, with the one exception that the nrw line is inverted during the transfer cycle. the cycle timings are show in table 10.17 . m registers (m > 1) not ready 1 pc+8 2 0 (pc+8) 1 0 0 0 0 1 2 pc+8 2 20 C 1 0 1 0 0 1 ? pc+8 2 0 C 1 0 1 0 0 1 n pc+8 2 0 C 0 0 1 0 0 0 n + 1 alu 2 0 (alu) 0 1 1 1 0 0 ? alu + ? 0 (alu + ?) 0 1 1 1 0 0 n+ m 2 alu + ? 2 0 (alu + ?) 0 1 1 1 0 0 n+m +1 alu + ? 2 2 (alu + ?) 0 0 1 1 1 1 pc+12 1. this operation cannot occur in thumb state. 2. m is number of registers being transferred, n is the number of cycles. table 10.16 coprocessor data transfer instruction cycle operations 1 (cont.) cycle address mas [1:0] nrw data nmreq seq nopc ncpi cpa cpb (sheet 2 of 2) arm.book page 18 wednesday, november 25, 1998 1:11 pm
coprocessor data transfer (from coprocessor to memory) 10-19 table 10.17 coprocessor data transfer instruction cycle operations 1 cycle address mas [1:0] nrw data nmreq seq nopc ncpi cpa cpb 1 register ready 1 pc+8 2 0 (pc+8) 0 0 0 0 0 0 2 alu 2 0 (alu) 0 0 1 1 1 1 pc + 12 1 register not ready 1 pc+8 2 0 (pc+8) 1 0 0 0 0 1 2pc+820C 1 01001 ?pc+820C 1 01001 npc+820C 0 01000 n + 1 alu 2 0 (alu) 0 0 1 1 1 1 pc + 12 m registers (m > 1) ready 1 pc+8 2 0 (pc+8) 0 0 0 0 0 0 2 alu 2 0 (alu) 0 1 1 1 0 0 ? alu+? 2 0 (alu+?) 0 1 1 1 0 0 n alu+? 2 0 (alu+?) 0 1 1 1 0 0 n+1 alu+? 2 0 (alu+?) 0 0 1 1 1 1 pc + 12 (sheet 1 of 2) arm.book page 19 wednesday, november 25, 1998 1:11 pm
10-20 instruction cycle operations 10.16 coprocessor register transfer (load from coprocessor) this operation cannot occur in thumb state. here the busy-wait cycles are much as above, but the transfer is limited to one data word, and the core puts the word into the destination register in the third cycle. the third cycle may be merged with the following prefetch cycle into one memory n-cycle as with all the register load instructions. the cycle timings are shown in table 10.18 . m registers (m > 1) not ready 1 pc+8 2 0 (pc+8) 1 0 0 0 0 1 2pc+820C 1 01001 ?pc+820C 1 01001 npc+820C 0 01000 n + 1 alu 2 0 (alu) 0 1 1 1 0 0 ? alu+? 0 (alu+?) 0 1 1 1 0 0 n + m alu + ? 2 0 (alu + ?) 0 1 1 1 0 0 n + m + 1 alu + ? 2 0 (alu + ?) 0 0 1 1 1 1 pc + 12 1. this operation cannot occur in thumb state. table 10.17 coprocessor data transfer instruction cycle operations 1 (cont.) cycle address mas [1:0] nrw data nmreq seq nopc ncpi cpa cpb (sheet 2 of 2) arm.book page 20 wednesday, november 25, 1998 1:11 pm
coprocessor register transfer (store to coprocessor) 10-21 10.17 coprocessor register transfer (store to coprocessor) this operation cannot occur in thumb state. this is the same operation as the load from coprocessor, except that the last cycle is omitted. the cycle timings are shown in table 10.19 . table 10.18 coprocessor register transfer (load from coprocessor) 1 1. this operation cannot occur in thumb state. cycle address mas[1:0] nrw data nmreq seq nopc ncpi cpa cpb ready 1 pc + 8 2 0 (pc +8) 1 1 0 0 0 0 2 pc + 12 2 0 cpdata 1 0 1 1 1 1 3 pc+12 2 0 C 0 1 1 1 C C pc+12 not ready 1 pc+8 2 0 (pc+8) 1 0 0 0 0 1 2 pc+8 2 0 C 1 0 1 0 0 1 ? pc+8 2 0 C 1 0 1 0 0 1 n pc+8 2 0 C 1 1 1 0 0 0 n + 1 pc + 12 2 0 cpdata 1 0 1 1 1 1 n+2 pc+12 2 0 C 0 1 1 1 C C pc+12 arm.book page 21 wednesday, november 25, 1998 1:11 pm
10-22 instruction cycle operations 10.18 unde?ned instructions and coprocessor absent this operation cannot occur in thumb state. when a coprocessor detects a coprocessor instruction which it cannot perform, and this must include all unde?ned instructions, it must not drive cpa or cpb low. these will remain high, causing the unde?ned instruction trap to be taken. cycle timings are shown in table 10.20 . table 10.19 coprocessor register transfer (store to coprocessor) 1 1. this operation cannot occur in thumb state. cycle address mas[1:0] nrw data nmreq seq nopc ncpi cpa cpb ready 1 pc + 8 2 0 (pc + 8) 1 1 0 0 0 0 2 pc+12 2 1 rd 0 0 1 1 1 1 pc+12 not ready 1 pc + 8 2 0 (pc + 8) 1 0 0 0 0 1 2 pc+8 2 0 C 1 0 1 0 0 1 ? pc+8 2 0 C 1 0 1 0 0 1 n pc+8 2 0 C 1 1 1 0 0 0 n+1 pc+12 2 1 rd 0 0 1 1 1 1 pc+12 arm.book page 22 wednesday, november 25, 1998 1:11 pm
unexecuted instructions 10-23 10.19 unexecuted instructions any instruction whose condition code is not met will fail to execute. it will add one cycle to the execution time of the code segment in which it is embedded (see table 10.21 ). 10.20 instruction speed summary due to the pipelined architecture of the cpu, instructions overlap considerably. in a typical cycle one instruction may be using the data path while the next is being decoded and the one after that is being fetched. for this reason the following table presents the incremental table 10.20 unde?ned instruction cycle operations 1 1. coprocessor instructions cannot occur in thumb state. cycle address mas [1:0] nrw data nmreq seq nopc ncpi cpa cpb ntrans mode tbit 1 pc + 2l i 2 2. i = 2 in arm state and i = 1 in thumb state. 0 (pc + 2l) 100011c 3 3. c represents the current mode-dependent value. old t 4 4. t represents the current state-dependent value. 2 pc + 2l i 0 C 0 0 0 1 1 1 c old t 3 xn 2 0 (xn) 0 1 0 1 1 1 1 00100 0 4 xn + 4 2 0 (xn +4) 0 1 0 1 1 1 1 00100 0 xn + 8 table 10.21 unexecuted instruction cycle operations cycle address mas [1:0] 1 1. i = 2 in arm state and i = 1 in thumb state. nrw data nmreq seq nopc 1 pc + 2l i 0 (pc + 2l) 0 1 0 pc + 3l arm.book page 23 wednesday, november 25, 1998 1:11 pm
10-24 instruction cycle operations number of cycles required by an instruction, rather than the total number of cycles for which the instruction uses part of the processor. elapsed time (in cycles) for a routine may be calculated from these ?gures which are shown in table 10.22 . these ?gures assume that the instruction is actually executed. unexecuted instructions take one cycle. n the number of words transferred m =1 bits [32:8] of the multiplier operand are all zero or one. 2 bits[32:16] of the multiplier operand are all zero or one. 3 bits[31:24] of the multiplier operand are all zero or all one. 4 otherwise. b the number of cycles spent in the coprocessor busy-wait loop. if the condition is not met all the instructions take one s-cycle. the cycle types n (nonsequential), s (sequential), i (internal), and c (coprocessor register transfer) are de?ned in chapter 6, "memory interface." table 10.22 arm instruction speed summary instruction cycle count additional data processing 1s + 1i for shift(rs) + 1s + 1n if r15 written msr, mrs 1s ldr 1s + 1n + 1i + 1s + 1n if r15 loaded str 2n ldm ns + 1n + 1i + 1s + 1n if r15 loaded stm (n - 1)s + 2n swp 1s + 2n + 1i b,bl 2s + 1n swi, trap 2s + 1n mul 1s + mi mla 1s + (m + 1)i (sheet 1 of 2) arm.book page 24 wednesday, november 25, 1998 1:11 pm
instruction speed summary 10-25 mull 1s + (m + 1)i mlal 1s + (m + 2)i cdp 1s + bi ldc,stc (n - 1)s+2n+bi mcr 1n + bi + 1c mrc 1s + (b + 1)i + 1c table 10.22 arm instruction speed summary (cont.) instruction cycle count additional (sheet 2 of 2) arm.book page 25 wednesday, november 25, 1998 1:11 pm
10-26 instruction cycle operations arm.book page 26 wednesday, november 25, 1998 1:11 pm
book title 11-1 chapter 11 production test this chapter describes the ARM7TDMI core production test interface, and contains the following sections: section 11.1, core testing strategy overview, page 11-1 section 11.2, scan test pin de?nitions, page 11-2 section 11.3, full-scan production testing, page 11-2 11.1 core testing strategy overview the core implements a full scan methodology for production testing. in addition to the two existing core functional debug scan chains, an additional scan chain spans the entire core and can use the scan_en and mclk signals in any of the functional clock domains. this new scan chain is 1709 cells long and encompasses both positive and negative edge driven devices. to allow either return to zero (rt0) or return to one (rt1) scan clocks, data lock-up latches have been inserted on the test inputs between ?ip-?ops with complimentary clock polarity. for production testing of the register ?le (internal three-port memory), the core uses the production scan chain to serially load rambist data into the internal ram ports. during scan mode, control of wenctest, the write enable signal, is always available at the core periphery. to minimize vector overhead during serial rambist pattern loading, the core leaves the production scan chain segment surrounding the internal memory isolated and accessible during the ram test mode. arm.book page 1 wednesday, november 25, 1998 1:11 pm
11-2 production test 11.2 scan test pin de?nitions table 11.1 lists the core signals associated with production scan testing. for more information on any of the signals listed, please see chapter 2, signal descriptions. 11.3 full-scan production testing although the production scan chain uses a single scan clock (mclk), both nreset and ntrst can affect ?ip-?op state and have been added so that atpg can detect additional faults. mclk may be either return to one (rt1) or return to zero (rt0) for the core scan testing. using a two-stage pattern generation method in mentor fastscan, the overall fault coverage for the core is 98.2%. the ?rst stage utilizes conventional atpg simulation and the second stage applies a sequential ram test to further increase the fault coverage. table 11.1 scan test pins pin name pin de?nition atpg patterns register file patterns normal operation fullscan master scan mode select 1 1 0 ramtest ramtest scan mode select 0 1 0 scan_en global scan enable scan_en scan_en 0 scan_in full scan chain input scan_in x x scan_out full scan chain output scan_out x C ramscan_in ramtest scan chain input x scan_in x ramscan_out ramtest scan chain output x scan_out C wenctest ramtest write enable x write enable x mclk global scan clock scan clock scan clock C ntrst jtag asynchronous reset scan clock scan clock 0 nreset reset scan clock scan clock 1 arm.book page 2 wednesday, november 25, 1998 1:11 pm
full-scan production testing 11-3 11.3.1 register file testing the core implements the register ?le as a three port (two read, one write) ram. to completely test the entire register ?le, the core is designed to allow testing of both the ram and the ram control logic. ram control logic test C this is possible by substituting the register ?le netlist for a ram test model. this netlist model enables the atpg tool to understand the ram control logic and produce atpg vectors that propagate ram faults, which allows coverage of the circuit elements directly connected to the ram. ram test C this is accomplished by multiplexing the register ?le ports to the nearest scan elements, which allows for controllable ram inputs and observable ram outputs. to control ram inputs and observe ram outputs, the core serially loads and unloads data through the newly formed truncated scan path. the ram scan chain ends are always available at the core periphery. the register ?le write enable control line is also multiplexed with wenctest to allow external control during ram testing. this arrangement is shown in figure 11.1 . figure 11.1 register file testing scan path control observe register file ramtest ramscan_in ramscan_out write enable wenctest scan_in scan_out arm.book page 3 wednesday, november 25, 1998 1:11 pm
11-4 production test serial test patterns are generated directly from the memory rambist pattern. a test wrapper (for vhdl or verilog) is provided with the core that performs the necessary data manipulation and generates the strobes needed to drive the ramtest circuitry. test duration is minimized by simultaneous pattern loading and response unloading. the parallel rambist patterns contain 270 patterns giving a simulation duration of approximately 22,000 vectors. arm.book page 4 wednesday, november 25, 1998 1:11 pm
book title 12-1 chapter 12 speci?cations the maximum mclk operating frequency and other ac timing values are dependent upon the technology used to implement the core. all ac timing parameters are listed in the cw00100x ARM7TDMI microprocessor core datasheet , available from lsi logic. for example, the cw001004 datasheet includes ac timing for the core implemented in lsi logics g10 technology. arm.book page 1 wednesday, november 25, 1998 1:11 pm
12-2 speci?cations arm.book page 2 wednesday, november 25, 1998 1:11 pm
a-1 appendix a ARM7TDMI changes this appendix describes the differences between this manual and the ARM7TDMI data sheet (arm document number arm ddi 0029e), but does not describe any layout changes. the purpose of this appendix is to enable a reader familiar with the arm document to identify areas where lsi logics ARM7TDMI microprocessor core differs from the common arm implementation. the preface and front material have been changed. chapter 1, introduction includes a new section that provides an overview of the lsi logic ARM7TDMI microprocessor core. the logic diagram in chapter 1 has moved to chapter 2 and now also includes eight new production test signals. chapter 2 includes descriptions of new pins added for production test. any information about transistor sizes is technology-dependent and has been removed. the signal descriptions of tck1 and tck2 have changed to re?ect that the lsi logic ARM7TDMI core implementation uses edge-sensitive logic rather than level-sensitive logic. detailed information on the arm and thumb instruction sets has been removed from chapter 4, arm instruction set summary and chapter 5, thumb instruction set summary . see the arm architecture reference manual for a complete description of all instructions. section 3.12, pipeline architecture, was added to describe the operation of the core pipeline. chapter 8 does not include the section, clock switch during test, as this test mode is not required for the lsi logic implementation. arm.book page 1 wednesday, november 25, 1998 1:11 pm
a-2 ARM7TDMI changes chapter 11 has been added to describe the lsi logic production test implementation. arm.book page 2 wednesday, november 25, 1998 1:11 pm
customer feedback we would appreciate your feedback on this document. please copy the following page, add your comments, and fax it to us at the number shown. if appropriate, please also fax copies of any marked-up pages from this document. impor tant: please include your name, phone number, fax number, and company address so that we may contact you directly for clari?cation or additional information. thank you for your help in improving the quality of our documents. arm.book page 3 wednesday, november 25, 1998 1:11 pm
customer feedback readers comments fax your comments to: lsi logic corporation technical publications m/s e-198 fax: 408.433.4333 please tell us how you rate this document: ARM7TDMI microprocessor core technical manual. place a check mark in the appropriate blank for each category. what could we do to improve this document? if you found errors in this document, please specify the error and page number. if appropriate, please fax a marked-up copy of the page(s). please complete the information below so that we may contact you directly for clari?cation or additional information. excellent good average fair poor completeness of information ____ ____ ____ ____ ____ clarity of information ____ ____ ____ ____ ____ ease of ?nding information ____ ____ ____ ____ ____ technical content ____ ____ ____ ____ ____ usefulness of examples and illustrations ____ ____ ____ ____ ____ overall manual ____ ____ ____ ____ ____ name date telephone title company name street city, state, zip department mail stop fax arm.book page 4 wednesday, november 25, 1998 1:11 pm
u.s. distributors by state h. h. hamilton hallmark w. e. wyle electronics alabama huntsville h. h. tel: 205.837.8700 w. e. tel: 800.964.9953 alaska h. h. tel: 800.332.8638 arizona phoenix h. h. tel: 602.736.7000 w. e. tel: 800.528.4040 tucson h. h. tel: 520.742.0515 arkansas h. h. tel: 800.327.9989 california irvine h. h. tel: 714.789.4100 w. e. tel: 800.626.9953 los angeles h. h. tel: 818.594.0404 w. e. tel: 800.288.9953 sacramento h. h. tel: 916.632.4500 w. e. tel: 800.627.9953 san diego h. h. tel: 619.571.7540 w. e. tel: 800.829.9953 san jose h. h. tel: 408.435.3500 santa clara w. e. tel: 800.866.9953 woodland hills h. h. tel: 818.594.0404 colorado denver h. h. tel: 303.790.1662 w. e. tel: 800.933.9953 connecticut chesire h. h. tel: 203.271.5700 wallingford w. e. tel: 800.605.9953 delaware north/south h. h. tel: 800.526.4812 tel: 800.638.5988 florida fort lauderdale h. h. tel: 305.484.5482 w. e. tel: 800.568.9953 orlando h. h. tel: 407.657.3300 w. e. tel: 407.740.7450 tampa w. e. tel: 800.395.9953 st. petersburg h. h. tel: 813.507.5000 georgia atlanta h. h. tel: 770.623.4400 w. e. tel: 800.876.9953 hawaii h. h. tel: 800.851.2282 idaho h. h. tel: 801.266.2022 illinois north/south h. h. tel: 847.797.7300 tel: 314.291.5350 chicago w. e. tel: 800.853.9953 indiana indianapolis h. h. tel: 317.575.3500 w. e. tel: 888.358.9953 iowa cedar rapids h. h. tel: 319.393.0033 kansas kansas city h. h. tel: 913.663.7900 kentucky central/northern/ western h. h. tel: 800.984.9503 tel: 800.767.0329 tel: 800.829.0146 louisiana north/south h. h. tel: 800.231.0253 tel: 800.231.5575 maine h. h. tel: 800.272.9255 maryland baltimore h. h. tel: 410.720.3400 w. e. tel: 800.863.9953 massachusetts boston h. h. tel: 978.532.9808 w. e. tel: 800.444.9953 michigan detroit h. h. tel: 313.416.5800 w. e. tel: 888.318.9953 grandville h. h. tel: 616.531.0345 minnesota minneapolis h. h. tel: 612.881.2600 w. e. tel: 800.860.9953 mississippi h. h. tel: 800.633.2918 missouri st. louis h. h. tel: 314.291.5350 montana h. h. tel: 800.526.1741 nebraska h. h. tel: 800.332.4375 nevada las vegas h. h. tel: 800.528.8471 w. e. tel: 702.765.7117 new hampshire h. h. tel: 800.272.9255 new jersey north/south h. h. tel: 201.515.1641 tel: 609.222.6400 oradell w. e. tel: 201.261.3200 pine brook w. e. tel: 800.862.9953 new mexico albuquerque h. h. tel: 505.293.5119 new york long island h. h. tel: 516.434.7400 w. e. tel: 800.861.9953 rochester h. h. tel: 716.475.9130 w. e. tel: 800.319.9953 syracuse h. h. tel: 315.453.4000 north carolina raleigh h. h. tel: 919.872.0712 w. e. tel: 800.560.9953 north dakota h. h. tel: 800.829.0116 ohio cleveland h. h. tel: 216.498.1100 w. e. tel: 800.763.9953 dayton h. h. tel: 614.888.3313 w. e. tel: 800.763.9953 oklahoma tulsa h. h. tel: 918.459.6000 oregon portland h. h. tel: 503.526.6200 w. e. tel: 800.879.9953 pennsylvania pittsburgh h. h. tel: 412.281.4150 philadelphia h. h. tel: 800.526.4812 w. e. tel: 800.871.9953 rhode island h. h. 800.272.9255 south carolina h. h. tel: 919.872.0712 south dakota h. h. tel: 800.829.0116 tennessee east/west h. h. tel: 800.241.8182 tel: 800.633.2918 texas austin h. h. tel: 512.219.3700 w. e. tel: 800.365.9953 dallas h. h. tel: 214.553.4300 w. e. tel: 800.955.9953 el paso h. h. tel: 800.526.9238 houston h. h. tel: 713.781.6100 w. e. tel: 800.888.9953 rio grande valley h. h. tel: 210.412.2047 utah draper w. e. tel: 800.414.4144 salt lake city h. h. tel: 801.365.3800 w. e. tel: 800.477.9953 vermont h. h. tel: 800.272.9255 virginia h. h. tel: 800.638.5988 washington seattle h. h. tel: 206.882.7000 w. e. tel: 800.248.9953 wisconsin milwaukee h. h. tel: 414.513.1500 w. e. tel: 800.867.9953 wyoming h. h. tel: 800.332.9326 arm.book page 5 wednesday, november 25, 1998 1:11 pm
sales of?ces and design resource centers lsi logic corporation corporate headquarters tel: 408.433.8000 fax: 408.433.8989 north america california irvine tel: 714.553.5600 fax: 714.474.8101 san diego tel: 619.613.8300 fax: 619.613.8350 wireless design center tel: 619.350.5560 fax: 619.350.0171 silicon valley tel: 408.433.8000 fax: 408.954.3353 colorado boulder tel: 303.447.3800 fax: 303.541.0641 florida boca raton tel: 561.989.3236 fax: 561.989.3237 illinois schaumburg tel: 847.995.1600 fax: 847.995.1622 kentucky bowling green tel: 502.793.0010 fax: 502.793.0040 maryland bethesda tel: 301.897.5800 fax: 301.897.8389 massachusetts waltham tel: 781.890.0180 fax: 781.890.6158 minnesota minneapolis tel: 612.921.8300 fax: 612.921.8399 new jersey edison tel: 732.549.4500 fax: 732.549.4802 new york new york tel: 716.223.8820 fax: 716.223.8822 north carolina raleigh tel: 919.785.4520 fax: 919.783.8909 oregon beaverton tel: 503.645.0589 fax: 503.645.6612 texas austin tel: 512.388.7294 fax: 512.388.4171 dallas tel: 972.509.0350 fax: 972.509.0349 houston tel: 281.379.7800 fax: 281.379.7818 washington issaquah tel: 425.837.1733 fax: 425.837.1734 canada ontario ottawa tel: 613.592.1263 fax: 613.592.3253 toronto tel: 416.620.7400 fax: 416.620.5005 quebec montreal tel: 514.694.2417 fax: 514.694.2699 international australia new south wales reptechnic pty ltd tel: 612.9953.9844 fax: 612.9953.9683 china beijing lsi logic international services inc tel: 86.10.6804.2534.40 fax: 86.10.6804.2521 denmark ballerup lsi logic development centre tel: 45.44.86.55.55 fax: 45.44.86.55.56 france paris lsi logic s.a. immeuble europa tel: 33.1.34.63.13.13 fax: 33.1.34.63.13.19 germany munich lsi logic gmbh tel: 49.89.4.58.33.0 fax: 49.89.4.58.33.108 stuttgart tel: 49.711.13.96.90 fax: 49.711.86.61.428 hong kong hong kong avt industrial ltd tel: 852.2428.0008 fax: 852.2401.2105 india bangalore logicad india private ltd tel: 91.80.526.2500 fax: 91.80.338.6591 israel ramat hasharon lsi logic tel: 972.3.5.480480 fax: 972.3.5.403747 netanya vlsi development centre tel: 972.9.657190 fax: 972.9.657194 italy milano lsi logic s.p.a. tel: 39.039.687371 fax: 39.039.6057867 japan tokyo lsi logic k.k. tel: 81.3.5463.7821 fax: 81.3.5463.7820 osaka tel: 81.6.947.5281 fax: 81.6.947.5287 korea seoul lsi logic corporation of korea ltd tel: 82.2.528.3400 fax: 82.2.528.2250 the netherlands eindhoven lsi logic europe ltd tel: 31.40.265.3580 fax: 31.40.296.2109 singapore singapore lsi logic pte ltd tel: 65.334.9061 fax: 65.334.4749 sweden stockholm lsi logic ab tel: 46.8.444.15.00 fax: 46.8.750.66.47 switzerland brugg/biel lsi logic sulzer ag tel: 41.32.536363 fax: 41.32.536367 taiwan taipei lsi logic asia-paci?c tel: 886.2.2718.7828 fax: 886.2.2718.8869 avnet-mercuries corporation, ltd tel: 886.2.2503.1111 fax: 886.2.2503.1449 jeilin technology corporation, ltd tel: 886.2.2248.4828 fax: 886.2.2242.4397 lumax international corporation, ltd tel: 886.2.2788.3656 fax: 886.2.2788.3568 united kingdom bracknell lsi logic europe ltd tel: 44.1344.426544 fax: 44.1344.481039 sales of?ces with design resource centers arm.book page 6 wednesday, november 25, 1998 1:11 pm

▲Up To Search▲

Price & Availability of ARM7TDMI

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