Greetings,
I have a piece of software fielded that violates the ADSP-2106x SHARC
User's Manual stament in 3.5.1.1 "The last three instructions of a
loop cannot be any branch; ... otherwise the loop may not execute
correctly."
We execute some code during boot-up and have yet to experience a
problem (thousands of bootups, at cold and hot temperatures). While
I'm in the process of changing the software to conform to the User's
Manual, I'm attempting to determine the risk to fielded SW.
Here's a code snippet run at bootup (no interrupts enabled):
lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
pm(i12, m13) = r4; /* *mem_ptr=expected */
r1 = pm(i12, m13); /* actual =*mem_ptr */
comp(r4, r1); /* if (expected != actual)*/
if ne jump fail_test(LA); /* jump to fail_test */
data_bus_loop: /* else */
r4 = LSHIFT r4 BY 1; /* expected << 1 */
/* end loop */
Does anyone have insight as to why this would be susceptible to the
loop not executing correctly?
If the SW operated correctly for eons, could I expect it to continue
to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
at 32MHz.
Thank You!
Don Waldron
ADSP-2106x jumps in hardware loops
Started by ●November 29, 2005
Reply by ●November 29, 20052005-11-29
Hi Don,
I have run into circumstances where this did cause a problem.
But I could never figure out what the exact contributing factor was.
It worked sometimes, edit some code elsewhere, then this code area
with a jump xxx(LA) as the statement before the do exit, and it would
crash. Undo the change elsewhere, and it would pass. Don't know why.
Put in the triple nops, and then make the same change I did to the
elsewhere code, and no crash.
So I, unfortunately, kept the triple nop there, wasted space.
If it works now, don't change it, but if you change code elsewhere,
you may want to consider changing it.
You know how hard it is to track down these loop issues with incorrect
ending are. mindless.
I can't give you an explanation of exactly why "sometimes it feels
like a nut, and sometimes it don't", but ....
Good luck,
John Henry
--- In adsp@adsp..., "donaldmwaldron" <donald.m.waldron@b...>
wrote:
>
> Greetings,
>
> I have a piece of software fielded that violates the ADSP-2106x SHARC
> User's Manual stament in 3.5.1.1 "The last three instructions of a
> loop cannot be any branch; ... otherwise the loop may not execute
> correctly."
>
> We execute some code during boot-up and have yet to experience a
> problem (thousands of bootups, at cold and hot temperatures). While
> I'm in the process of changing the software to conform to the User's
> Manual, I'm attempting to determine the risk to fielded SW.
>
> Here's a code snippet run at bootup (no interrupts enabled):
>
> lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
> pm(i12, m13) = r4; /* *mem_ptr=expected */
> r1 = pm(i12, m13); /* actual =*mem_ptr */
> comp(r4, r1); /* if (expected != actual)*/
> if ne jump fail_test(LA); /* jump to fail_test */
> data_bus_loop: /* else */
> r4 = LSHIFT r4 BY 1; /* expected << 1 */
> /* end loop */
>
> Does anyone have insight as to why this would be susceptible to the
> loop not executing correctly?
>
> If the SW operated correctly for eons, could I expect it to continue
> to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
> at 32MHz.
>
> Thank You!
>
> Don Waldron
>
I have run into circumstances where this did cause a problem.
But I could never figure out what the exact contributing factor was.
It worked sometimes, edit some code elsewhere, then this code area
with a jump xxx(LA) as the statement before the do exit, and it would
crash. Undo the change elsewhere, and it would pass. Don't know why.
Put in the triple nops, and then make the same change I did to the
elsewhere code, and no crash.
So I, unfortunately, kept the triple nop there, wasted space.
If it works now, don't change it, but if you change code elsewhere,
you may want to consider changing it.
You know how hard it is to track down these loop issues with incorrect
ending are. mindless.
I can't give you an explanation of exactly why "sometimes it feels
like a nut, and sometimes it don't", but ....
Good luck,
John Henry
--- In adsp@adsp..., "donaldmwaldron" <donald.m.waldron@b...>
wrote:
>
> Greetings,
>
> I have a piece of software fielded that violates the ADSP-2106x SHARC
> User's Manual stament in 3.5.1.1 "The last three instructions of a
> loop cannot be any branch; ... otherwise the loop may not execute
> correctly."
>
> We execute some code during boot-up and have yet to experience a
> problem (thousands of bootups, at cold and hot temperatures). While
> I'm in the process of changing the software to conform to the User's
> Manual, I'm attempting to determine the risk to fielded SW.
>
> Here's a code snippet run at bootup (no interrupts enabled):
>
> lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
> pm(i12, m13) = r4; /* *mem_ptr=expected */
> r1 = pm(i12, m13); /* actual =*mem_ptr */
> comp(r4, r1); /* if (expected != actual)*/
> if ne jump fail_test(LA); /* jump to fail_test */
> data_bus_loop: /* else */
> r4 = LSHIFT r4 BY 1; /* expected << 1 */
> /* end loop */
>
> Does anyone have insight as to why this would be susceptible to the
> loop not executing correctly?
>
> If the SW operated correctly for eons, could I expect it to continue
> to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
> at 32MHz.
>
> Thank You!
>
> Don Waldron
>
Reply by ●November 29, 20052005-11-29
First, the Jump goes to a failure condition, so the jump probably
doesn't occur often. When the condition is not true the Jump is
essentially NOPed out.
Second, while I have never tried it, the LA modifier may allow an
exemption to the statement that you are quoting.
Page 3-26 of the 2126x Core Manual gives an exemption to some classes
of the CALL instruction, but not to the JUMP (LA) instruction. --- In adsp@adsp..., "donaldmwaldron" <donald.m.waldron@b...>
wrote:
>
> Greetings,
>
> I have a piece of software fielded that violates the ADSP-2106x SHARC
> User's Manual stament in 3.5.1.1 "The last three instructions of a
> loop cannot be any branch; ... otherwise the loop may not execute
> correctly."
>
> We execute some code during boot-up and have yet to experience a
> problem (thousands of bootups, at cold and hot temperatures). While
> I'm in the process of changing the software to conform to the User's
> Manual, I'm attempting to determine the risk to fielded SW.
>
> Here's a code snippet run at bootup (no interrupts enabled):
>
> lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
> pm(i12, m13) = r4; /* *mem_ptr=expected */
> r1 = pm(i12, m13); /* actual =*mem_ptr */
> comp(r4, r1); /* if (expected != actual)*/
> if ne jump fail_test(LA); /* jump to fail_test */
> data_bus_loop: /* else */
> r4 = LSHIFT r4 BY 1; /* expected << 1 */
> /* end loop */
>
> Does anyone have insight as to why this would be susceptible to the
> loop not executing correctly?
>
> If the SW operated correctly for eons, could I expect it to continue
> to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
> at 32MHz.
>
> Thank You!
>
> Don Waldron
>
doesn't occur often. When the condition is not true the Jump is
essentially NOPed out.
Second, while I have never tried it, the LA modifier may allow an
exemption to the statement that you are quoting.
Page 3-26 of the 2126x Core Manual gives an exemption to some classes
of the CALL instruction, but not to the JUMP (LA) instruction. --- In adsp@adsp..., "donaldmwaldron" <donald.m.waldron@b...>
wrote:
>
> Greetings,
>
> I have a piece of software fielded that violates the ADSP-2106x SHARC
> User's Manual stament in 3.5.1.1 "The last three instructions of a
> loop cannot be any branch; ... otherwise the loop may not execute
> correctly."
>
> We execute some code during boot-up and have yet to experience a
> problem (thousands of bootups, at cold and hot temperatures). While
> I'm in the process of changing the software to conform to the User's
> Manual, I'm attempting to determine the risk to fielded SW.
>
> Here's a code snippet run at bootup (no interrupts enabled):
>
> lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
> pm(i12, m13) = r4; /* *mem_ptr=expected */
> r1 = pm(i12, m13); /* actual =*mem_ptr */
> comp(r4, r1); /* if (expected != actual)*/
> if ne jump fail_test(LA); /* jump to fail_test */
> data_bus_loop: /* else */
> r4 = LSHIFT r4 BY 1; /* expected << 1 */
> /* end loop */
>
> Does anyone have insight as to why this would be susceptible to the
> loop not executing correctly?
>
> If the SW operated correctly for eons, could I expect it to continue
> to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
> at 32MHz.
>
> Thank You!
>
> Don Waldron
>
Reply by ●November 29, 20052005-11-29
IRRC, the problem with the loop not executing correctly is that it will
execute
fewer times than it is supposed to. Due to pipe-lining, I think it decrements
the loop counter a few instructions before the end of the loop. If there is a
jump in there, it can foul up that process and you end up decrementing the loop
counter more than once. At least that is my understanding.
Of if it is a non-counter-based loop, perhaps the termination condition gets
checked early with a similar problem? I'm less sure of that one.
At any rate, in your case, I don't think you will have a problem. The presence
of a conditional jump shouldn't be a problem--it is only if the jump is
actually executed that a problem could arise. And because the jump leaves the
loop and never returns, there shouldn't be any issues with double-decrementing
the loop counter, etc.. (If there were, you wouldn't care since the loop was
aborted anyway.) I would be much more concerned if that instruction was a call
that returned back to the loop.
Let me qualify all this by saying it is my understanding of chip, etc. so take
it for what it is worth. Since you are concerned with field issues, I would
also try to talk to ADI directly. In the past, I've had excellent results
asking their DSP tech support for very specific information about anomalies,
etc..
--- donaldmwaldron <donald.m.waldron@dona...> wrote:
> Greetings,
>
> I have a piece of software fielded that violates the ADSP-2106x SHARC
> User's Manual stament in 3.5.1.1 "The last three instructions of a
> loop cannot be any branch; ... otherwise the loop may not execute
> correctly."
>
> We execute some code during boot-up and have yet to experience a
> problem (thousands of bootups, at cold and hot temperatures). While
> I'm in the process of changing the software to conform to the User's
> Manual, I'm attempting to determine the risk to fielded SW.
>
> Here's a code snippet run at bootup (no interrupts enabled):
>
> lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
> pm(i12, m13) = r4; /* *mem_ptr=expected */
> r1 = pm(i12, m13); /* actual =*mem_ptr */
> comp(r4, r1); /* if (expected != actual)*/
> if ne jump fail_test(LA); /* jump to fail_test */
> data_bus_loop: /* else */
> r4 = LSHIFT r4 BY 1; /* expected << 1 */
> /* end loop */
>
> Does anyone have insight as to why this would be susceptible to the
> loop not executing correctly?
>
> If the SW operated correctly for eons, could I expect it to continue
> to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
> at 32MHz.
>
> Thank You!
>
> Don Waldron
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
fewer times than it is supposed to. Due to pipe-lining, I think it decrements
the loop counter a few instructions before the end of the loop. If there is a
jump in there, it can foul up that process and you end up decrementing the loop
counter more than once. At least that is my understanding.
Of if it is a non-counter-based loop, perhaps the termination condition gets
checked early with a similar problem? I'm less sure of that one.
At any rate, in your case, I don't think you will have a problem. The presence
of a conditional jump shouldn't be a problem--it is only if the jump is
actually executed that a problem could arise. And because the jump leaves the
loop and never returns, there shouldn't be any issues with double-decrementing
the loop counter, etc.. (If there were, you wouldn't care since the loop was
aborted anyway.) I would be much more concerned if that instruction was a call
that returned back to the loop.
Let me qualify all this by saying it is my understanding of chip, etc. so take
it for what it is worth. Since you are concerned with field issues, I would
also try to talk to ADI directly. In the past, I've had excellent results
asking their DSP tech support for very specific information about anomalies,
etc..
--- donaldmwaldron <donald.m.waldron@dona...> wrote:
> Greetings,
>
> I have a piece of software fielded that violates the ADSP-2106x SHARC
> User's Manual stament in 3.5.1.1 "The last three instructions of a
> loop cannot be any branch; ... otherwise the loop may not execute
> correctly."
>
> We execute some code during boot-up and have yet to experience a
> problem (thousands of bootups, at cold and hot temperatures). While
> I'm in the process of changing the software to conform to the User's
> Manual, I'm attempting to determine the risk to fielded SW.
>
> Here's a code snippet run at bootup (no interrupts enabled):
>
> lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++) */
> pm(i12, m13) = r4; /* *mem_ptr=expected */
> r1 = pm(i12, m13); /* actual =*mem_ptr */
> comp(r4, r1); /* if (expected != actual)*/
> if ne jump fail_test(LA); /* jump to fail_test */
> data_bus_loop: /* else */
> r4 = LSHIFT r4 BY 1; /* expected << 1 */
> /* end loop */
>
> Does anyone have insight as to why this would be susceptible to the
> loop not executing correctly?
>
> If the SW operated correctly for eons, could I expect it to continue
> to operate correctly? I'm using an AD14060 (Quad-ADSP-21060) clocked
> at 32MHz.
>
> Thank You!
>
> Don Waldron
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
Reply by ●November 30, 20052005-11-30
From my experience (ADSP-21065, ADSP-21364):
A problem will occur if:
1. The conditional jump is taken.
2. The loop stack is already popped because the last iteration of the
loop is executed.
In this case the loop stack will be popped twice if the loop stack is
not already empty after the first (which one may suspect at boot time
code...).
So long,
Friedrich
_______________________________________
ASK Industries GmbH
Friedrich Burgwedel
Senior Engineer R&D Software Electronics
_______________________________________
> -----Original Message-----
> From: adsp@adsp... [mailto:adsp@adsp...] On
> Behalf Of Jon Harris
> Sent: Tuesday, November 29, 2005 11:19 PM
> To: donaldmwaldron; adsp@adsp...
> Subject: Re: [adsp] ADSP-2106x jumps in hardware loops > IRRC, the problem with the loop not executing correctly is
> that it will execute fewer times than it is supposed to. Due
> to pipe-lining, I think it decrements the loop counter a few
> instructions before the end of the loop. If there is a jump
> in there, it can foul up that process and you end up
> decrementing the loop counter more than once. At least that
> is my understanding.
>
> Of if it is a non-counter-based loop, perhaps the termination
> condition gets checked early with a similar problem? I'm
> less sure of that one.
>
> At any rate, in your case, I don't think you will have a
> problem. The presence of a conditional jump shouldn't be a
> problem--it is only if the jump is actually executed that a
> problem could arise. And because the jump leaves the loop
> and never returns, there shouldn't be any issues with
> double-decrementing the loop counter, etc.. (If there were,
> you wouldn't care since the loop was aborted anyway.) I
> would be much more concerned if that instruction was a call
> that returned back to the loop.
>
> Let me qualify all this by saying it is my understanding of
> chip, etc. so take it for what it is worth. Since you are
> concerned with field issues, I would also try to talk to ADI
> directly. In the past, I've had excellent results asking
> their DSP tech support for very specific information about
> anomalies, etc..
>
> --- donaldmwaldron <donald.m.waldron@dona...> wrote:
>
> > Greetings,
> >
> > I have a piece of software fielded that violates the ADSP-2106x
SHARC
> > User's Manual stament in 3.5.1.1 "The last three instructions of a
> > loop cannot be any branch; ... otherwise the loop may not execute
> > correctly."
> >
> > We execute some code during boot-up and have yet to experience a
> > problem (thousands of bootups, at cold and hot temperatures). While
> > I'm in the process of changing the software to conform to the User's
> > Manual, I'm attempting to determine the risk to fielded SW.
> >
> > Here's a code snippet run at bootup (no interrupts enabled):
> >
> > lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++)
*/
> > pm(i12, m13) = r4; /* *mem_ptr=expected
*/
> > r1 = pm(i12, m13); /* actual =*mem_ptr
*/
> > comp(r4, r1); /* if (expected !=
actual)*/
> > if ne jump fail_test(LA); /* jump to fail_test
*/
> > data_bus_loop: /* else
*/
> > r4 = LSHIFT r4 BY 1; /* expected << 1
*/
> > /* end loop
*/
> >
> > Does anyone have insight as to why this would be susceptible to the
> > loop not executing correctly?
> >
> > If the SW operated correctly for eons, could I expect it to continue
> > to operate correctly? I'm using an AD14060 (Quad-ADSP-21060)
clocked
> > at 32MHz.
> >
> > Thank You!
> >
> > Don Waldron
>
A problem will occur if:
1. The conditional jump is taken.
2. The loop stack is already popped because the last iteration of the
loop is executed.
In this case the loop stack will be popped twice if the loop stack is
not already empty after the first (which one may suspect at boot time
code...).
So long,
Friedrich
_______________________________________
ASK Industries GmbH
Friedrich Burgwedel
Senior Engineer R&D Software Electronics
_______________________________________
> -----Original Message-----
> From: adsp@adsp... [mailto:adsp@adsp...] On
> Behalf Of Jon Harris
> Sent: Tuesday, November 29, 2005 11:19 PM
> To: donaldmwaldron; adsp@adsp...
> Subject: Re: [adsp] ADSP-2106x jumps in hardware loops > IRRC, the problem with the loop not executing correctly is
> that it will execute fewer times than it is supposed to. Due
> to pipe-lining, I think it decrements the loop counter a few
> instructions before the end of the loop. If there is a jump
> in there, it can foul up that process and you end up
> decrementing the loop counter more than once. At least that
> is my understanding.
>
> Of if it is a non-counter-based loop, perhaps the termination
> condition gets checked early with a similar problem? I'm
> less sure of that one.
>
> At any rate, in your case, I don't think you will have a
> problem. The presence of a conditional jump shouldn't be a
> problem--it is only if the jump is actually executed that a
> problem could arise. And because the jump leaves the loop
> and never returns, there shouldn't be any issues with
> double-decrementing the loop counter, etc.. (If there were,
> you wouldn't care since the loop was aborted anyway.) I
> would be much more concerned if that instruction was a call
> that returned back to the loop.
>
> Let me qualify all this by saying it is my understanding of
> chip, etc. so take it for what it is worth. Since you are
> concerned with field issues, I would also try to talk to ADI
> directly. In the past, I've had excellent results asking
> their DSP tech support for very specific information about
> anomalies, etc..
>
> --- donaldmwaldron <donald.m.waldron@dona...> wrote:
>
> > Greetings,
> >
> > I have a piece of software fielded that violates the ADSP-2106x
SHARC
> > User's Manual stament in 3.5.1.1 "The last three instructions of a
> > loop cannot be any branch; ... otherwise the loop may not execute
> > correctly."
> >
> > We execute some code during boot-up and have yet to experience a
> > problem (thousands of bootups, at cold and hot temperatures). While
> > I'm in the process of changing the software to conform to the User's
> > Manual, I'm attempting to determine the risk to fielded SW.
> >
> > Here's a code snippet run at bootup (no interrupts enabled):
> >
> > lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++)
*/
> > pm(i12, m13) = r4; /* *mem_ptr=expected
*/
> > r1 = pm(i12, m13); /* actual =*mem_ptr
*/
> > comp(r4, r1); /* if (expected !=
actual)*/
> > if ne jump fail_test(LA); /* jump to fail_test
*/
> > data_bus_loop: /* else
*/
> > r4 = LSHIFT r4 BY 1; /* expected << 1
*/
> > /* end loop
*/
> >
> > Does anyone have insight as to why this would be susceptible to the
> > loop not executing correctly?
> >
> > If the SW operated correctly for eons, could I expect it to continue
> > to operate correctly? I'm using an AD14060 (Quad-ADSP-21060)
clocked
> > at 32MHz.
> >
> > Thank You!
> >
> > Don Waldron
>
Reply by ●November 30, 20052005-11-30
Good addition, Friedrich. I forgot about the loop stack issue. That could
potentially be a problem if the stack wasn't empty, e.g. in a nested loop.
--- "Burgwedel Friedrich (Ask De)" <BurgwedelF@Burg...> wrote:
> From my experience (ADSP-21065, ADSP-21364):
>
> A problem will occur if:
> 1. The conditional jump is taken.
> 2. The loop stack is already popped because the last iteration of the
> loop is executed.
> In this case the loop stack will be popped twice if the loop stack is
> not already empty after the first (which one may suspect at boot time
> code...).
>
> So long,
> Friedrich
>
> _______________________________________
>
> ASK Industries GmbH
>
> Friedrich Burgwedel
> Senior Engineer R&D Software Electronics
> _______________________________________ >
> > -----Original Message-----
> > From: adsp@adsp... [mailto:adsp@adsp...] On
> > Behalf Of Jon Harris
> > Sent: Tuesday, November 29, 2005 11:19 PM
> > To: donaldmwaldron; adsp@adsp...
> > Subject: Re: [adsp] ADSP-2106x jumps in hardware loops
> >
> >
> > IRRC, the problem with the loop not executing correctly is
> > that it will execute fewer times than it is supposed to. Due
> > to pipe-lining, I think it decrements the loop counter a few
> > instructions before the end of the loop. If there is a jump
> > in there, it can foul up that process and you end up
> > decrementing the loop counter more than once. At least that
> > is my understanding.
> >
> > Of if it is a non-counter-based loop, perhaps the termination
> > condition gets checked early with a similar problem? I'm
> > less sure of that one.
> >
> > At any rate, in your case, I don't think you will have a
> > problem. The presence of a conditional jump shouldn't be a
> > problem--it is only if the jump is actually executed that a
> > problem could arise. And because the jump leaves the loop
> > and never returns, there shouldn't be any issues with
> > double-decrementing the loop counter, etc.. (If there were,
> > you wouldn't care since the loop was aborted anyway.) I
> > would be much more concerned if that instruction was a call
> > that returned back to the loop.
> >
> > Let me qualify all this by saying it is my understanding of
> > chip, etc. so take it for what it is worth. Since you are
> > concerned with field issues, I would also try to talk to ADI
> > directly. In the past, I've had excellent results asking
> > their DSP tech support for very specific information about
> > anomalies, etc..
> >
> > --- donaldmwaldron <donald.m.waldron@dona...> wrote:
> >
> > > Greetings,
> > >
> > > I have a piece of software fielded that violates the ADSP-2106x
> SHARC
> > > User's Manual stament in 3.5.1.1 "The last three instructions of a
> > > loop cannot be any branch; ... otherwise the loop may not execute
> > > correctly."
> > >
> > > We execute some code during boot-up and have yet to experience a
> > > problem (thousands of bootups, at cold and hot temperatures). While
> > > I'm in the process of changing the software to conform to the User's
> > > Manual, I'm attempting to determine the risk to fielded SW.
> > >
> > > Here's a code snippet run at bootup (no interrupts enabled):
> > >
> > > lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++)
> */
> > > pm(i12, m13) = r4; /* *mem_ptr=expected
> */
> > > r1 = pm(i12, m13); /* actual =*mem_ptr
> */
> > > comp(r4, r1); /* if (expected !=
> actual)*/
> > > if ne jump fail_test(LA); /* jump to fail_test
> */
> > > data_bus_loop: /* else
> */
> > > r4 = LSHIFT r4 BY 1; /* expected << 1
> */
> > > /* end loop
> */
> > >
> > > Does anyone have insight as to why this would be susceptible to the
> > > loop not executing correctly?
> > >
> > > If the SW operated correctly for eons, could I expect it to continue
> > > to operate correctly? I'm using an AD14060 (Quad-ADSP-21060)
> clocked
> > > at 32MHz.
> > >
> > > Thank You!
> > >
> > > Don Waldron
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
potentially be a problem if the stack wasn't empty, e.g. in a nested loop.
--- "Burgwedel Friedrich (Ask De)" <BurgwedelF@Burg...> wrote:
> From my experience (ADSP-21065, ADSP-21364):
>
> A problem will occur if:
> 1. The conditional jump is taken.
> 2. The loop stack is already popped because the last iteration of the
> loop is executed.
> In this case the loop stack will be popped twice if the loop stack is
> not already empty after the first (which one may suspect at boot time
> code...).
>
> So long,
> Friedrich
>
> _______________________________________
>
> ASK Industries GmbH
>
> Friedrich Burgwedel
> Senior Engineer R&D Software Electronics
> _______________________________________ >
> > -----Original Message-----
> > From: adsp@adsp... [mailto:adsp@adsp...] On
> > Behalf Of Jon Harris
> > Sent: Tuesday, November 29, 2005 11:19 PM
> > To: donaldmwaldron; adsp@adsp...
> > Subject: Re: [adsp] ADSP-2106x jumps in hardware loops
> >
> >
> > IRRC, the problem with the loop not executing correctly is
> > that it will execute fewer times than it is supposed to. Due
> > to pipe-lining, I think it decrements the loop counter a few
> > instructions before the end of the loop. If there is a jump
> > in there, it can foul up that process and you end up
> > decrementing the loop counter more than once. At least that
> > is my understanding.
> >
> > Of if it is a non-counter-based loop, perhaps the termination
> > condition gets checked early with a similar problem? I'm
> > less sure of that one.
> >
> > At any rate, in your case, I don't think you will have a
> > problem. The presence of a conditional jump shouldn't be a
> > problem--it is only if the jump is actually executed that a
> > problem could arise. And because the jump leaves the loop
> > and never returns, there shouldn't be any issues with
> > double-decrementing the loop counter, etc.. (If there were,
> > you wouldn't care since the loop was aborted anyway.) I
> > would be much more concerned if that instruction was a call
> > that returned back to the loop.
> >
> > Let me qualify all this by saying it is my understanding of
> > chip, etc. so take it for what it is worth. Since you are
> > concerned with field issues, I would also try to talk to ADI
> > directly. In the past, I've had excellent results asking
> > their DSP tech support for very specific information about
> > anomalies, etc..
> >
> > --- donaldmwaldron <donald.m.waldron@dona...> wrote:
> >
> > > Greetings,
> > >
> > > I have a piece of software fielded that violates the ADSP-2106x
> SHARC
> > > User's Manual stament in 3.5.1.1 "The last three instructions of a
> > > loop cannot be any branch; ... otherwise the loop may not execute
> > > correctly."
> > >
> > > We execute some code during boot-up and have yet to experience a
> > > problem (thousands of bootups, at cold and hot temperatures). While
> > > I'm in the process of changing the software to conform to the User's
> > > Manual, I'm attempting to determine the risk to fielded SW.
> > >
> > > Here's a code snippet run at bootup (no interrupts enabled):
> > >
> > > lcntr2, do(data_bus_loop) until lce; /* for (i= ; i < 32; i++)
> */
> > > pm(i12, m13) = r4; /* *mem_ptr=expected
> */
> > > r1 = pm(i12, m13); /* actual =*mem_ptr
> */
> > > comp(r4, r1); /* if (expected !=
> actual)*/
> > > if ne jump fail_test(LA); /* jump to fail_test
> */
> > > data_bus_loop: /* else
> */
> > > r4 = LSHIFT r4 BY 1; /* expected << 1
> */
> > > /* end loop
> */
> > >
> > > Does anyone have insight as to why this would be susceptible to the
> > > loop not executing correctly?
> > >
> > > If the SW operated correctly for eons, could I expect it to continue
> > > to operate correctly? I'm using an AD14060 (Quad-ADSP-21060)
> clocked
> > > at 32MHz.
> > >
> > > Thank You!
> > >
> > > Don Waldron
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
