Lpc2000

I have closely examined JTAG synchronisation logic diagrams for 
synthesized cores on the official ARM web site

Reading logic diagrams is a skill I first learnt at university in 
Ireland in the seventies from an enthusiastic and fresh lecturer from 
England whose career was sadly cut short following his death in a car 
accident in France.

The synchronisation logic ENFORCES the following.
1. An enforcement of maximum possible TCK frequency of 1/6 of the 
internal clock frequency.
2. An enforcement that internal clock must be applied to the logic 
when the core is in a debug state and the core is not been clocked 
itself. 
3. An enforcement that RTCK, which can be used to trigger CLK, is a 
maximum possible of 1/6 the internal clock

So I acknowledge
1. Use of RTCK cannot raise throughput during the non debug state
2. During debug state the 1/6 rule applies 

However I will not acknowledge that the entire set of enforcements is 
strictly necessary. 

So far I have not been able to find out why ARM insists on 
enforcement of the 1/6 rule for synthesized cored. My guess is that 
the rules are grossly conservative and not due for any inherent 
property of synthesized cores as opposed to 'hard' cores.

I have included some quotes from ARM from links below. I have doubts 
whether the quotes make complete sense given the enforcement nature 
of the logic. However I have no wish to spend time debating this.

Also the enforcement nature of the logic lends supports that problems 
reaching 1/6 MCLK are due to problems external to the part, such 
using cabling and termination that is inappropriate for the speed.

Informative links are 
http://www.arm.com/support/faqdev/4170.html
(How does the JTAG synchronisation logic work? / How does adaptive 
clocking work?)

and

http://www.arm.com/support/faqdev/1321.html
(What is the maximum TCK frequency that I can set up with Multi-ICE?)

The Multi-ICE debugger is the 'official' JTAG debugger of ARM. The 
information is relevant to other debuggers.

Multi-ICE can generate a maximum TCK frequency of 10MHz

For hard macrocells ARM states:
"You should normally be able to work with TCK faster than 1MHz".

For synthesizable cores ARM states:
"The three sampling flip-flops set the theoretical maximum TCK 
frequency, which is one sixth of the core clock frequency (one eighth 
in ARM11)..." 
and 
"The real maximum TCK frequency will be lower than this and will 
depend on the core clock frequency, the delays on the JTAG signals 
and the setup time of Multi-ICE and the ASIC."

Also
"If your target provides RTCK, you can also configure Multi-ICE in 
adaptive clocking mode. Multi-ICE will automatically work at a TCK 
frequency close to the maximum possible one."


John Heenan


--- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
>
> --- In lpc2000@yahoogroups.com, <sig5534@h...> wrote:
> >
> > > > You can't get anywhere near that on ARM7TDMI-S parts which we 
> are 
> > > > dicussing,
> >  
> > Correct.  The maximum speed I can use with the JTAGjet is 4MHz on 
> these LPC parts.
> > BTW, I was incorrect before, the JTAGjet goes to 30MHz when I 
> checked it again.
> 
> There has been no information provivded or pointed to that puts the 
> limiting factor on the ARM7TDMI-S part itself. 
> 
> Adaptive RTCK use overcomes the 1/6 rule when the core is not in a 
> debug state. In a debug state there is no clock relevant to JTAG to 
> synchronise to.  Yes I am aware of the 'switch to system speed and 
> back to debug' issue.
> 
> There are lots of reasons why speed becomes maxed out. Not the 
least 
> of which is wiring. 
> 
> It would be nice to know what the limiting factor is to investigate 
> if it can be overcome and so use the more capable debug tools to 
> their full capacity. 
> 
> John Heenan
> 
> > >> Try this link.  http://www.arm.com/support/faqip/3732.html.  
> Extracting
> > >> the relevent details, "If the RTCK output is not used, it is 
> required
> > >> that TCK is running at a maximum of 1/6th the system clock 
> frequency if
> > >> only 1 JTAG synchroniser is implemented in the system."  
> > 
> > I use both the Adaptive clocking (RTCK) and fixed freq on my 
> JTAGjet.  It does both equally well.
> > 
> > >> For example using proper speed cabling 
> > >> and including simple RC filters to reduce signal crossover at 
> > >> high speeds near part pins.
> > > No, you're completely wrong here.  The factors are part of the 
> JTAG
> > > design on the part, as the above link shows.
> > 
> > Correct.  I have actually tried attaching caps on the JTAG header 
> pins and nothing I did made any difference on the 4MHz speed 
> limitation.
> 
> I am sorry but I don't regard this as conclusive.
> 
> John Heenan
>