Lpc2000

On Thursday 06 October 2005 15:38, John Heenan wrote:
> Second the JTAG hardware embedded in ARM7TDMI-S parts is not part of
> the core hardware. It monitors the buses and bus signals and is
> clocked independently of the core with the JTAG TCK.
>
> Third the core hardware is hard hardware. Whether the ARM core is
> labelled with S or not for synthesised has nothing to do with the
> speed at which the independent JTAG hardware can be clocked at. While
> I acknowledge non synthesised designed cores have less risk attached
> to them in terms of using proven hardware designs, there is no
> inherent reason why synthesised cores cannot have their JTAGS clocked
> at well over 1Mhz.

This is not actually true. The ICEBreaker is part of the core.

Non-S parts have independent clocking for the ICEBreaker and the JTAG speed is 
basically as fast as the JTAG/ICEBreaker circuit on the chip will handle (ie 
limited by transmission effects, slew rates etc).

S parts use the MCLK to deglitch the JTAG lines. The maximum speed is 1/6 the 
MCLK speed.

This is clearly documented in one of the docs on www.arm.com.

This introduces some interesting quirkiness for devices that start on a slow 
clock and then switch to a faster clock later.


As for the other points being made: My 2c...

The JTAG or USB speeds are not the only important issue when it codes to 
debugging speed. One very important factor is where the core-handling logic 
is. For example, if the JTAGger is just a "dumb" JTAG probe then a lot of low 
level JTAG transactions need to be passed over the USB link to do anything 
useful. If the JTAG probe instead has ARM core smarts built in, then  the 
traffic can be much higher level. eg. "We hit a break and here is the 
register set". The top-end units (bdi200 and friends) implement the whole lot 
in the debugger.

A slow but smart JTAGger will knock the pants off a fast but dumb one any day.