Possible anomaly with 21161 SHARC

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

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

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

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.