>> I googled for some time, but couldn't find hard number what restrictions for
>> the JTAG/SWD frequency apply.
I was the source of the original (CLK/6) in the documetation - it is a
simplification that makes it easier for people to get correct without much
reading and technical understanding.
The deeply technical answer is this:
There are 3 parts:
(A) From a *LOGIC* point of view
======================
*OLDER* - arm chips (ARM9) have a clock synchronization scheme that runs off
the CPU clock frequency.
Example:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/DDI0201D_arm946es_r1p1_trm.pdf
<http://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/DDI0201D_arm946es_r1p1_trm.pdf>
Specific: Section 9.1.3 - Page 9-3, Figure 9.1
Look at the “TCK Synchronizer” element.
If you do not use the RTCK signal or it is not available you (not present) then
you must operate the TCK at 1/6 of the SAMPLE clock. If the CPU changes clock
frequency dynamically (i.e.: low power mode) so must the JTAG clock, the RTCK
signal helps but at the cost of an expensive pin on the chip. Other designs
use the same basic sampling scheme. Remember: Non-mission mode pins like RTCK
and other JTAG pins cost real money.
There is another way to solve the problem Do not sample the TCK - instead,
Part (1) operate the JTAG logic using TCK instead, it is just a shift register
after all. Part (2) [important] you change the structure of the circuit and
the protocol. You must have some type of “cross-clock-domain” busy-wait scheme.
For example - when new commands or data is received, a “busy bit” is set. The
debug logic begins to work, eventually the “busy bit” goes false. Part (3)
Effectively during this time you must provide a means to *stall* the next
operation.
A simple solution is the means to *poll* the busy signal - the arm dap JTAG and
SWD protocols have a “busy” response.
(B) From a MULTIPLE tap point of view
===========================
Some designs have more then one JTAG tap - tap (A) might have a polling scheme
(ARM DAP), but that does not mean TAP (B) or (C) has a scheme, in fact they may
have clock synchronizers. Thus, while tap (A) could run super fast (100MHZ) and
supports a polling scheme you might be limited by the other taps in your
system. Sometimes there is other hidden test logic used in the silicon-foundary
to test the chip that is speed limited you will never learn the details of this
test logic.
(C) From an Electrical Engineer - Signal Quality point of view
===========================================
A high frequency clock signal (10 to 20mhz) - across a ribbon cable, 2 board
connectors, and 2 cable connectors and a ribbon cable gets pretty noisy and
nasty.
At some point - signal quality often sets another limit
===========
I don’t have a specific answer to your question but I know (C) signal quality
tends to limit things the most.
-Duane.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
