|
I'm using the AD14060 Quad SHARC (four ADSP-21060s). The DSP IDs read
from 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. Regards, > Donald M. Waldron > |
|
|
DSP IDs reversed for AD14060 or VisualDSP?
Started by ●July 10, 2002
Reply by ●July 10, 20022002-07-10
|
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). 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 (sigh)... Regards, Don Waldron > -----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 > from > 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. > > Regards, > > > 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/ > |
|
|
Reply by ●July 10, 20022002-07-10
|
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. |
Reply by ●July 11, 20022002-07-11
|
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. |
Reply by ●July 11, 20022002-07-11
|
[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. |
