ARM Technical Support Knowledge Articles

Is there any method of at-speed testing for ARM7TDMI?

Applies to: ARM7TDMI

Answer

We don't have any vectors for at-speed testing for production devices. The test chip characterization vectors are the closest we have. There are a number of problems in implementing at-speed vectors for the ARM7TDMI macrocell.

It is not possible to perform at-speed testing using the serial JTAG port. Another method which could be used is to multiplex out signals from the ARM7TDMI macrocell to the pins of your ASIC for parallel access. A problem we would face here in providing such vectors, is allowing for different delays introduced between the macrocell and the pads on the ASIC. Of course, in most cases there would be problems with the number of pins and multiplexers required, and difficulty of routing.

Another problem we would see is that some output delays from the ARM7TDMI are greater than a minimum phase time, such that the outputs may need to be checked beyond the end of the test cycle, in the next vector. This makes it very difficult to build a set of vectors that will work for the many different speeds of ARM7TDMI that we see on the range of processes used for our cores.

Our recommended approach is to produce Test Chips, possibly using skewed manufacturing (split wafer lot), to allow slow/slow and fast/fast silicon to be characterized. If production wafers have characteristics inside the specification for the process, the speed specification must be met.

If you are at the specified maximum frequency, clock skew will be an issue (we measure minimum Tmckl and Tmckh, not Fmax. If your clock speed is Fmax, a non 50/50 clock duty cycle may cause a problem).

One possibility might be to take some code which exercises the critical path of the core and to use this to create a test that is specific to your ASIC. There are some problems with this approach, which is why we don't normally recommend it.

The ARM7TDMI has a number of different critical paths, all of similar length (If there was one path which was always the worst, we would optimize it. So, the exact critical path will depend upon the process and conditions).

More importantly, the most common critical paths are debug mode related. In order to exercise these, it is necessary to have the ability to drive the JTAG interface in a complex way. This would require a lot of dedicated hardware to be built into your chip, purely for the purpose of measuring maximum speed. This is not a good idea.

Even if we confine the test to measuring the maximum clock speed in normal (non-debug) operation, to fully test the ARM, the code running on the ARM may need a way to generate interrupts, aborts etc. under program control. Simple assembly language code by itself is not sufficient to test the ARM. As the non-debug related critical paths are ~10% shorter than the debug related ones, this speed test should never fail on real silicon!

If you wanted to make a speed test which tests the non-debug critical paths, you should run some sets of instructions, as listed below, at speed so that on the tester you can observe that the instructions produce the correct results.

Summary of common non-debug paths

  1. Shifter carry out

    The path is a register specified shift of 1 place that sets the carry flag which the next instruction then tests:

    LDR R2, =&55555555
    LDR R4, =&87654321
    LDR R10, =&1
    EORS R4, R4, R2, ROR R10
    STRCS R4, [R0]

  2. MAS[] generation

    It may be possible for MAS[] to change so slowly that it is not available by the MCLK falling edge. The slowest change comes from an LDM executed whilst in THUMB state.

  3. PENCADD

    The ARM7TDMI PENCADD block calculates from ireg[15:0] the offset value at the start of an STM or LDM. This can affect the maximum clock time. The code to use is simply a load or store multiple of all 16 registers.

  4. nOPC to ICEBreaker Coprocessor to CPB to SEQ

    The Coprocessor pipeline follower in the Embedded ICE logic uses nOPC to directly produce CPA and CPB if it recognizes a coprocessor instruction. CPA and CPB are used by the core logic to determine the instruction sequence and so nMREQ and SEQ are directly affected by these also.

    When ALE and APE are held high, nOPC will change in phase 2 of MCLK. However if ALE is driven high at the start of phase 1 or APE is held low, then nOPC will change during phase 1 and so CPA and CPB will be delayed. So, this path is only valid if ALE or APE are used to delay the Address (which in most designs will not be the case).

    This can cause problems either with nMREQ & SEQ being delayed until after the clock rising edge or with MCLK being too fast.

    This problem occurs in normal operation, rather than in debug state, but relates only to use of the debug comms channel.

Article last edited on: 2008-09-09 15:47:35

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential