An update, I received this reply from Analog Devices DSP support:
Thank you for contacting Analog Devices DSP Support. We were able to replicate
your problem on the ADSP-21161 EZ-KIT Lite. Please note that the status stack
(ASTAT and mode1 register) should get popped only after executing the two
instructions that are followed by the delayed branch instruction. That means if
instructions RTI(db); dm(test1) = r14; dm(test2) = r15 are executed, status
stack should be popped only after executing the instruction dm(test2) = r15.
The behavior that you/we are seeing in case of alternate register set (SRRFH) is
perfectly fine. But in case of SIMD enable bit (PEYEN), you/we have observed
that status stack is getting popped immediately after executing rti instruction.
As there is an effect latency of one cycle, you/we have observed that both
implicit and explicit part of the instruction is executed only for dm(test2) =
r15 and not for dm(test1) = r14. We need to confirm this behavior from the
design team before documenting this. We shall keep you posted on this.
"Jon Harris" <goldentully@hotmail.com> wrote in message
news:2hi37dFdbdiiU1@uni-berlin.de...
> "Jon Harris" <goldentully@hotmail.com> wrote in message
> news:2hh6p7Fd0kbfU1@uni-berlin.de...
> > Andor <an2or@mailcircuit.com> wrote in message
> > news:ce45f9ed.0405242316.a96ccef@posting.google.com...
> >
> > I have code for both 21065L and 21161. The problem was originally noticed
on
>
> OK, I just tested this and have a definitive answer. The upshot is that
changes
> to the alternate register bits in MODE1 do not take place on the second
> instruction after RTI (DB), but changes to the SIMD bit does. This sounds
like
> an anomaly to me--either one or the other is wrong.
>
> Here is my test (in a mix of pseudo code and assembler):
<snip>
>
> Conclusion: the effect latency for MODE1 is not consistent among various bits
in
> the case of an automatic pop of STS in an RTI(DB) instruction. The SIMD bit
> takes affect before the alternate register select bits.
Reply by Jaime Andres Aranguren Cardona●May 27, 20042004-05-27
an2or@mailcircuit.com (Andor) wrote in message news:<ce45f9ed.0405261402.1e68d3cc@posting.google.com>...
> Jon Harris wrote:
> ...
> > OK, I just tested this and have a definitive answer.
>
> Thanks for the update.
>
> Jon, as far as I can see you are not a member of the ADSP e-mail
> group. This would be the perfect place to post this information, and
> we sure can use every experienced hand available :).
>
> http://groups.yahoo.com/group/adsp
I agree that joining that group is very useful for asking and
answering questions regarding ADI's chips and tools. However, I think
that a good practice is to crosspost to comp.dsp too, because that way
your questions and answers can be viewed by a broader audience.
Regards,
JaaC
>
> Regards,
> Andor
Reply by Jon Harris●May 27, 20042004-05-27
OK, I sent the information to ADI DSP support and also signed up for ADSP group.
I'm not sure how much time I'll have to spend in that group, but I'll give it a
try.
-Jon
"Andor" <an2or@mailcircuit.com> wrote in message
news:ce45f9ed.0405261402.1e68d3cc@posting.google.com...
> Jon Harris wrote:
> ...
> > OK, I just tested this and have a definitive answer.
>
> Thanks for the update.
>
> Jon, as far as I can see you are not a member of the ADSP e-mail
> group. This would be the perfect place to post this information, and
> we sure can use every experienced hand available :).
>
> http://groups.yahoo.com/group/adsp
>
> Regards,
> Andor
Reply by Andor●May 26, 20042004-05-26
Jon Harris wrote:
...
> OK, I just tested this and have a definitive answer.
Thanks for the update.
Jon, as far as I can see you are not a member of the ADSP e-mail
group. This would be the perfect place to post this information, and
we sure can use every experienced hand available :).
http://groups.yahoo.com/group/adsp
Regards,
Andor
Reply by Ron Huizen●May 26, 20042004-05-26
Jon,
In response to your earlier question of how to report an anomaly, send a
message to dsp.support@analog.com with the details, including your test
code. This will get the process started.
The more people report their problems, the better. It won't even be
considered to be fixed in new silicon if they don't know about it, and even
if it never gets fixed, at least if it's documented people shouldn't get
burned (as badly) by it. All silicon has anomalies, some companies do
better than others at making them available to the users. ADI does a decent
job, posting them all on their web site.
While some people are shocked to learn all products (including DSPs) have
problems, good engineers understand that everything has problems, and
knowing about them is a heck of a lot better than not.
Ron
-----------
Ron Huizen
BittWare
"Jon Harris" <goldentully@hotmail.com> wrote in message
news:2hi37dFdbdiiU1@uni-berlin.de...
> "Jon Harris" <goldentully@hotmail.com> wrote in message
> news:2hh6p7Fd0kbfU1@uni-berlin.de...
> > Andor <an2or@mailcircuit.com> wrote in message
> > news:ce45f9ed.0405242316.a96ccef@posting.google.com...
> >
> > I have code for both 21065L and 21161. The problem was originally
noticed on
> > the 21161 in conjunction with SIMD mode. I then went back to look at
the
> 21065L
> > code which is a bit different. The strange thing was that it looked
like it
> > should have had a similar problem with register and DAG select but
didn't!
> >
> > > > > I would think
> > > > > that the automatic pop of the status stack at the RTI has the same
> > > > > latency as the "pop sts" instruction, or a direct write to the
mode1
> > > > > register, namely one instruction cycle.
> > > > >
> > > > > This would be consistent with you finding that the second
instruction
> > > > > after the RTI already reacts to the popped mode1 register.
> > > > >
> > > > > But, as you said, the manual is silent about this. I think I also
> > > > > noticed different behaviour in the simulator as compared to the
target
> > > > > hardware in this issue.
> > > >
> > > > Another odd thing I noticed is that the effect of the register/DAG
> > > > primary/secondary select bits also in MODE1 seems to be different
than the
> > SIMD
> > > > bit. I haven't confirmed this for sure, but it sure looks like that
2nd
> > > > instruction after the RTI still uses the interrupt code's
register/DAG
> > select
> > > > setting rather than that of the interrupted code.
> > >
> > > I'm sure this isn't the case with the SHARC - don't know (but suspect
> > > the same) for the Hammerhead.
> >
> > When I have a chance I'd like to re-try this on both 21161 and 21065L
and see
> > what the behavior is.
>
> OK, I just tested this and have a definitive answer. The upshot is that
changes
> to the alternate register bits in MODE1 do not take place on the second
> instruction after RTI (DB), but changes to the SIMD bit does. This sounds
like
> an anomaly to me--either one or the other is wrong.
>
> Here is my test (in a mix of pseudo code and assembler):
>
> Test A: Main loop code is running with alternate registers selected
>
> Interrupt code:
> set r14 and r15 primary and alternate to known values
> select primary registers
> RTI(DB);
> dm(test1) = r14; // instruction 1
> dm(test2) = r15; // instruction 2
>
> Results: test1 and test2 both receive the values in primary registers.
This
> means that the change to MODE1 did NOT take effect until after instruction
2.
> Behavior was the same between 21065L and 21161.
>
>
>
> Test B: Main loop code is running with SIMD bit turned on
>
> Interrupt code:
> turn off SIMD mode
> set r14/s14 and r15/s15 primary and alternate to known values
> RTI(DB);
> dm(test1) = r14; // instruction 1
> dm(test2) = r15; // instruction 2
>
> Results: test1 receives the value in primary r14. Location test1+1 is not
> affected (no SIMD write). test2 receives the value in primary r15.
Location
> test2+1 receives the values in primary s15 (SIMD write occurred). This
means
> that the change to MODE1 took effect just before instruction 2. This was
on the
> 21161. I could not try Test B on the 21065L because it doesn't have SIMD
mode.
>
> Conclusion: the effect latency for MODE1 is not consistent among various
bits in
> the case of an automatic pop of STS in an RTI(DB) instruction. The SIMD
bit
> takes affect before the alternate register select bits.
>
>
>
>
>
Reply by Bernhard Holzmayer●May 26, 20042004-05-26
Jon Harris wrote:
> ...
> Conclusion: the effect latency for MODE1 is not consistent among
> various bits in
> the case of an automatic pop of STS in an RTI(DB) instruction.
> The SIMD bit takes affect before the alternate register select
> bits.
Thanks for this examination. If this is true (and I see no reason to
doubt it...), it will certainly be a great help to avoid conflicts.
Bernhard
Reply by Jon Harris●May 25, 20042004-05-25
"Jon Harris" <goldentully@hotmail.com> wrote in message
news:2hh6p7Fd0kbfU1@uni-berlin.de...
> Andor <an2or@mailcircuit.com> wrote in message
> news:ce45f9ed.0405242316.a96ccef@posting.google.com...
>
> I have code for both 21065L and 21161. The problem was originally noticed on
> the 21161 in conjunction with SIMD mode. I then went back to look at the
21065L
> code which is a bit different. The strange thing was that it looked like it
> should have had a similar problem with register and DAG select but didn't!
>
> > > > I would think
> > > > that the automatic pop of the status stack at the RTI has the same
> > > > latency as the "pop sts" instruction, or a direct write to the mode1
> > > > register, namely one instruction cycle.
> > > >
> > > > This would be consistent with you finding that the second instruction
> > > > after the RTI already reacts to the popped mode1 register.
> > > >
> > > > But, as you said, the manual is silent about this. I think I also
> > > > noticed different behaviour in the simulator as compared to the target
> > > > hardware in this issue.
> > >
> > > Another odd thing I noticed is that the effect of the register/DAG
> > > primary/secondary select bits also in MODE1 seems to be different than the
> SIMD
> > > bit. I haven't confirmed this for sure, but it sure looks like that 2nd
> > > instruction after the RTI still uses the interrupt code's register/DAG
> select
> > > setting rather than that of the interrupted code.
> >
> > I'm sure this isn't the case with the SHARC - don't know (but suspect
> > the same) for the Hammerhead.
>
> When I have a chance I'd like to re-try this on both 21161 and 21065L and see
> what the behavior is.
OK, I just tested this and have a definitive answer. The upshot is that changes
to the alternate register bits in MODE1 do not take place on the second
instruction after RTI (DB), but changes to the SIMD bit does. This sounds like
an anomaly to me--either one or the other is wrong.
Here is my test (in a mix of pseudo code and assembler):
Test A: Main loop code is running with alternate registers selected
Interrupt code:
set r14 and r15 primary and alternate to known values
select primary registers
RTI(DB);
dm(test1) = r14; // instruction 1
dm(test2) = r15; // instruction 2
Results: test1 and test2 both receive the values in primary registers. This
means that the change to MODE1 did NOT take effect until after instruction 2.
Behavior was the same between 21065L and 21161.
Test B: Main loop code is running with SIMD bit turned on
Interrupt code:
turn off SIMD mode
set r14/s14 and r15/s15 primary and alternate to known values
RTI(DB);
dm(test1) = r14; // instruction 1
dm(test2) = r15; // instruction 2
Results: test1 receives the value in primary r14. Location test1+1 is not
affected (no SIMD write). test2 receives the value in primary r15. Location
test2+1 receives the values in primary s15 (SIMD write occurred). This means
that the change to MODE1 took effect just before instruction 2. This was on the
21161. I could not try Test B on the 21065L because it doesn't have SIMD mode.
Conclusion: the effect latency for MODE1 is not consistent among various bits in
the case of an automatic pop of STS in an RTI(DB) instruction. The SIMD bit
takes affect before the alternate register select bits.
Reply by Jon Harris●May 25, 20042004-05-25
Andor <an2or@mailcircuit.com> wrote in message
news:ce45f9ed.0405242316.a96ccef@posting.google.com...
> Jon Harris wrote:
> > "Andor Bariska" <an2or@nospam.net> wrote in message
> ...
> > > Jon, are you sure the SHARC does not behave the same way?
> >
> > I'm confused about this. I'm only talking about the SHARC.
>
> Sorry. I thought you were differentiating between SHARC (2106x) family
> and Hammerhead (21161). It was my confusion.
I see. In my usage, SHARC refers to anything in the 21x6x family. It looks to
me that ADI really isn't using the Hammerhead name much anymore. It doesn't
seem to appear in 21161 documentation, and a web search at analog.com gets only
a few hits. I'm going to use part numbers for here on out to avoid ambiguity.
I have code for both 21065L and 21161. The problem was originally noticed on
the 21161 in conjunction with SIMD mode. I then went back to look at the 21065L
code which is a bit different. The strange thing was that it looked like it
should have had a similar problem with register and DAG select but didn't!
> > > I would think
> > > that the automatic pop of the status stack at the RTI has the same
> > > latency as the "pop sts" instruction, or a direct write to the mode1
> > > register, namely one instruction cycle.
> > >
> > > This would be consistent with you finding that the second instruction
> > > after the RTI already reacts to the popped mode1 register.
> > >
> > > But, as you said, the manual is silent about this. I think I also
> > > noticed different behaviour in the simulator as compared to the target
> > > hardware in this issue.
> >
> > Another odd thing I noticed is that the effect of the register/DAG
> > primary/secondary select bits also in MODE1 seems to be different than the
SIMD
> > bit. I haven't confirmed this for sure, but it sure looks like that 2nd
> > instruction after the RTI still uses the interrupt code's register/DAG
select
> > setting rather than that of the interrupted code.
>
> I'm sure this isn't the case with the SHARC - don't know (but suspect
> the same) for the Hammerhead.
When I have a chance I'd like to re-try this on both 21161 and 21065L and see
what the behavior is.
> > I guess the bottom line here is to use RTI(DB) with caution!
>
> Definitely. I once had a bug very similar to yours - popping the
> status stack in the second instruction after a RTI (DB) :-). The
> simple solution was to exchange last with second to last instruction
> in the interrupt routine.
Glad I'm not alone! The fact that we've both suffered from this indicates that
ADI should include some info on this in their documentation.
Reply by Andor●May 25, 20042004-05-25
Jon Harris wrote:
> "Andor Bariska" <an2or@nospam.net> wrote in message
...
> > Jon, are you sure the SHARC does not behave the same way?
>
> I'm confused about this. I'm only talking about the SHARC.
Sorry. I thought you were differentiating between SHARC (2106x) family
and Hammerhead (21161). It was my confusion.
> > I would think
> > that the automatic pop of the status stack at the RTI has the same
> > latency as the "pop sts" instruction, or a direct write to the mode1
> > register, namely one instruction cycle.
> >
> > This would be consistent with you finding that the second instruction
> > after the RTI already reacts to the popped mode1 register.
> >
> > But, as you said, the manual is silent about this. I think I also
> > noticed different behaviour in the simulator as compared to the target
> > hardware in this issue.
>
> Another odd thing I noticed is that the effect of the register/DAG
> primary/secondary select bits also in MODE1 seems to be different than the SIMD
> bit. I haven't confirmed this for sure, but it sure looks like that 2nd
> instruction after the RTI still uses the interrupt code's register/DAG select
> setting rather than that of the interrupted code.
I'm sure this isn't the case with the SHARC - don't know (but suspect
the same) for the Hammerhead.
>
> I guess the bottom line here is to use RTI(DB) with caution!
Definitely. I once had a bug very similar to yours - popping the
status stack in the second instruction after a RTI (DB) :-). The
simple solution was to exchange last with second to last instruction
in the interrupt routine.
Regards,
Andor
Reply by Bernhard Holzmayer●May 25, 20042004-05-25
Jon Harris wrote:
> ...
> I guess the bottom line here is to use RTI(DB) with caution!
So do I...
I was just tracing a bug around such a RTI(db) command, and I found
that it works fine if I code it as:
pop sts;
rti;
while it fails if I modify it to
rti(db)
pop sts;
nop;
I watched another related issue (which meanwhile made it into the
anomaly list):
the integrated status push of mode1 and astat fails under certain
circumstances. Eventually, an additional <push sts>-cmd (and the
corresponding pop sts at the return location) helped.
Newest versions of VisualDSP should handle this correctly.
Concerning your initial topic:
I checked the anomaly list, but didn't find a corresponding entry.
However, in the anomaly list for the 21160 (issue 16) reveals a
difference depending on how mode1 register is written.
In combination with the strange behaviour I watched, I guess that
there are risks around rti(db) in combination with the status stack
recovery.
While it's recommended to either place a nop after a pop sts or
avoid critical accesses immediately after, I assume that this is
necessary too, if you deal with the implicit pop sts which rti(db)
does, if recurring from distinct interrupts like IRQ0..2
Problems might increase, if you have nested interrupts enabled.
I'm wondering if it works correctly, if a higher priority interrupt
occurs during the rti(db) ...??
Bernhard