Lpc2000

I should explain what I mean by enforcement logic.

What the synchronization logic really does is deliberately distort 
your triggering UNLESS you stick to the 1/6 rule.

It is like a policeman that says we don't care if you break the speed 
limit and if the speed limit is too low, as we have speed detectors 
that will trigger lasers to destroy your car if you go over the 
limit.

The combination of three edge triggered D flip-flops with a logic 
gate that requires the input to the final flip-flop to be different 
to what was latched on the prior triggering clock edge to the same 
flip-flop means that you must stick to the 1/6 rule to ensure the 
output from the logic reflects the TCK input.

John Heenan


--- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
>
> 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
> >
>