I'm using the AD14060 Quad SHARC (four ADSP-21060s). The DSP IDs read
the SYSYTAT registers are reversed from what is expected; In VisualDSP++
2.0, DSP_A reports an ID of 4, DSP_B's ID is 3, DSP_C's ID is 2 and DSP_D's
ID is 1. This leads to the LDF file having the incorrect MPMEMORY offsets.
Our HW has unique interrupts wired to each DSP, so it is necessary to know
what DSP is what. While I continue on this quest to determine what DSP is
what, I thought I'd query this group to see if anyone else has experience
with multiprocessing and the DSP IDs.
> Donald M. Waldron
DSP IDs reversed for AD14060 or VisualDSP?
I found my problem. I'm using the Summit ICE, which requires setting up
target JTAG session using the JTAG ICE Configurator. The ICE Configurator
needs to be set with the order DSP_D, DSP_C, DSP_B, DSP_A (which is reverse
from what I had).
Logically, I thought I should start with DSP_A, but this caused DSP_D's code
loaded on DSP_A, etc. and caused VisualDSP++ to indicate DSP_D was DSP_A,
etc. Reversing the order in the JTAG ICE Configurator fixes the problem.
However, when I load code in VisualDSP++, DSP_D is now listed first, which
isn't a big deal; just looks funny.
I only wish this was documented in the Summit ICE Instruction Manual
> -----Original Message-----
> From: Waldron, Donald M [SMTP:]
> Sent: Wednesday, July 10, 2002 7:49 AM
> To: '
> Subject: [adsp] DSP IDs reversed for AD14060 or VisualDSP?
> I'm using the AD14060 Quad SHARC (four ADSP-21060s). The DSP IDs read
> the SYSYTAT registers are reversed from what is expected; In VisualDSP++
> 2.0, DSP_A reports an ID of 4, DSP_B's ID is 3, DSP_C's ID is 2 and
> ID is 1. This leads to the LDF file having the incorrect MPMEMORY
> Our HW has unique interrupts wired to each DSP, so it is necessary to know
> what DSP is what. While I continue on this quest to determine what DSP is
> what, I thought I'd query this group to see if anyone else has experience
> with multiprocessing and the DSP IDs.
> > Donald M. Waldron
> Note: If you do a simple "reply" with your email client, only the author
> of this message will receive your answer. You need to do a "reply all" if
> you want your answer to be distributed to the entire group.
> About this discussion group:
> To Join: Send an email to
> To Post: Send an email to
> To Leave: Send an email to
> Archives: http://groups.yahoo.com/group/adsp
> Other Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/
On Wed, 2002-07-10 at 10:15, Waldron, Donald M wrote:|
> I found my problem. I'm using the Summit ICE, which requires setting up a
> target JTAG session using the JTAG ICE Configurator. The ICE Configurator
> needs to be set with the order DSP_D, DSP_C, DSP_B, DSP_A (which is reverse
> from what I had).
I use the Summit and Apex (USB) with a dual-21065L custom target, and
the CPU ID's are backwards from the JTAG chain order, just like your
system. This is a property of your target, not the debugger tools. The
Configurator lets me name each target whatever I want, so I name them
after the function they perform.
On Thu, 2002-07-11 at 05:42, Waldron, Donald M wrote:|
> This is OK if all DSPs are equal, but we have unique interrupts into each of
> our DSPs, and need to know which is which. I was confused by the
> Configurator which expects the last DSP (in our case, with ID=4) first in
> the list. This results in DSP_D (ID=4) being listed first in VisualDSP++
> (which is OK, just not as expected)when downloading to the target (in our
> case, an ADI AD14060 Quad SHARC device).
But understand that this is a target hardware problem, not a tools
problem. The problem is that the JTAG chain on the target board has one
order, but the ID strap pins on the CPU's are configured to a different
order. There's no requirement that these two numbering schemes have
*anything* to do with each other. That's up to the board designer.
There's no way for the configurator to know what mapping, if any, exists
between the CPU ID values and the order of the JTAG chain. For a given
chain of 4 CPU's, there are 4*3*2*1$ possible choices of CPU ID lists.
Note that the Configurator (and consequently, the debugger) only knows
about the JTAG chain. It knows nothing of CPU ID's. OTOH, the ELF
multiprocessor tools for creating ROM boot images know only about CPU
ID's, and know nothing of JTAG chains. That's because the ROM boot
mechanism can only read the ID's, and has no access to information about
the JTAG chain.
[Please reply on the list.]|
On Thu, 2002-07-11 at 08:11, Waldron, Donald M wrote:
> Thanks for your input. Can I safely say the problem resides within the
> Analog Device AD14060 Quad SHARC device? This device has the CPU IDs wired
> internally, with a JTAG interface for all 4 CPUs.
Ah, I hadn't realized you were talking about a chip and not a board.
Yeah, it sure sounds like that's what they did. When you select this
part in the Configurator, does it then prename all the DSP's? This looks
like a case where the Configurator, with chip-level knowledge, can be
"primed" with a knowledge of the relationship between the JTAG order and
the CPU ID's, and would know to name the internal CPU's to match
conventions used by the other tools.