The ARM7 TDMI is one of the simpler members of the ARM processor family. Wikipedia gives some background and useful links. This page shows:
The ARM7 TDMI is a 32-bit RISC processor architecture intended for embedded systems. One of its distinctive features is support for two instruction sets: the ARM set with 32-bit instructions, and the Thumb set with 16-bit instructions. The former is considered to give faster but larger code, while the latter gives slower but smaller code. The processor can switch between the two instruction sets at run-time, using the BX "branch and exchange" instruction to change from ARM state to Thumb state or vice versa. It is common for an ARM7 TDMI program to consists of a mixture of ARM (32-bit) subprograms and Thumb (16-bit) subprograms. Calling a Thumb subprogram from ARM state, or vice versa, is known as "interworking". Some compilers generate "interworking" code by default, others may need a specific compilation option or directive to do so.
Several different companies produce different devices (chips) which execute the basic ARM7 instruction set. Some devices support Thumb. As could be expected for a pipelined RISC architecture, the basic execution time of each instruction is usually the same in all ARM7 TDMI devices. However, memory access times may differ between devices, both for code and data accesses.
Those devices that have on-chip flash memory for code often use some kind of flash accelerator hardware to speed up the code fetches from the flash, which otherwise would become a bottleneck at high clock frequencies. The accelerator hardware can be a simple wide fetch, for example reading 128 bits of flash contents at a time, or it can include a concurrent wide prefetch, or even cache-like buffers that may make the fetch time and thus the overall execution time history-dependent and hard to predict.
Bound-T/ARM7 at present models only the basic, pipeline, execution time, assuming that memory accesses imply no wait cycles. In this sense, it can be considered a prototype implementation.
Bound-T/ARM7 models all standard ARM7 TDMI instructions both in ARM (32-bit) and Thumb (16-bit) state. The analysis of computation and data flow is based on 32-bit numbers. The interaction (aliasing) of 32-bit memory accesses and accesses to 16-bit or 8-bit parts of memory words is not modelled.
Bound-T/ARM7 models dynamic changes of state from ARM to Thumb and vice versa. The state is changed only by BX (branch and exchange) and SWI (software interrupt) instructions. For BX the new state is defined by the least significant bit of the branch target address. For SWI the new state is ARM. On return from an SWI handler the caller's state is restored.
However, a BX takes the branch target address from a register, so it is in principle a dynamic value. In practice, Bound-T/ARM7 tries to analyse the possible values of the target address. If the BX is used only to change state, the target address is very probably a constant that can be deduced from the analysis, giving an automatic analysis of both the branch and the change of state.
An ARM7 TDMI processor can have coprocessors that have their own registers and can execute their own computations under the control of specific ARM7 instructions dedicated to coprocessor operations. Coprocessors exist for floating-point computations and other kinds of computations.
Bound-T/ARM7 does not model any specific coprocessors, but does model those effects of coprocessor instructions that have an effect on the basic computations in the ARM7 TDMI itself. All results of coprocessor computations are modelled as unknown (opaque) values. For example, the ARM7 instruction that stores coprocessor registers into memory words is modelled as storing unknown values into these memory words.
Bound-T/ARM7 at present models only the basic, pipeline, execution time, assuming that memory accesses imply no wait cycles. No caches, flash-memory buffers, or other dynamic accelerators are modelled at present.
For stack-usage analysis Bound-T models the standard ARM7 stack with register R13 (SP) as the stack pointer.
Bound-T for ARM7 at present models only the basic, pipeline execution time. Thus, its execution-time analysis will be too optimistic for any ARM7 device that has wait states for memory accesses. The stack-usage analysis, on the other hand, is not device-dependent.
Tidorum would welcome your suggestions on specific ARM7 devices for which you need WCET analysis.
Many cross-compilers for the ARM7 exist, both "free" ones and commercially licensed ones. In principle Bound-T is able to analyse machine code from any compiler. However, different compilers create executable files in different formats, and Bound-T is not able to read all possible formats. Moreover, different compilers may generate different kinds of symbolic debugging information, which Bound-T uses to communicate with the user in source-level terms. Finally, each compiler may generate its own idiomatic instruction sequences, some of which need special analysis methods, and has its own set of library subprograms, some of which may not follow the ordinary parameter-passing and stack-handling rules and therefore need special attention in Bound-T. For these reasons, Bound-T often needs to adapt its analysis to the compiler that generated the code to be analysed.
The table below lists the ARM7 cross-compilers that have been tested with Bound-T. However, this does not mean that Bound-T will correctly analyse all code from these compilers, for all source programs. Bound-T can read ARM7 programs in the formats COFF, ELF, Intel Hex, and UBROF (the IAR proprietary format). DWARF debugging information is supported for ELF files.
If your compiler is not listed in this table, please contact Tidorum to ask if your compiler is supported, or can be supported.
| Producer | Compiler |
|---|---|
| GNU | GNU ARM7 C compiler |
| IAR Systems | IAR ARM7 C compiler |
| Keil | Keil/ARM RealView (armcc) |
| Texas Instruments | TMS470 C compiler |
| Document (PDF) | Description |
|---|---|
| ARM7 Application Note | Describes the capabilities of Bound-T for the ARM7TDMI and how to use it. See also the general Bound-T manuals. |
| Intel® Hex as Input to Bound-T | Describes how Bound-T reads and analyses executable programs in the Intel Hex file format. |
Here is a small ARM7 program with some examples of its WCET and stack-usage analysis with Bound-T.