Hi
Would you please answer my following question clearly?
Technical support @ ti.com said to me that data memory for C55x is limited to 64KW (like C54x)
but base on TI documents I think that C55x could support more than that by means of XARn. Does
using more than 64kw data memory incur any load or slow down on performance?
Could you send me a sample .cmd file for this purpose?
 Please reply it is very important for me because I want to select a c55x dsp for my project if
and only if it supports data memory more than 64KWs.
Regards
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

--- In c...@yahoogroups.com, ahmadagha23@... wrote:
>
> Hi
> Would you please answer my following question clearly?
> Technical support @ ti.com said to me that data memory for C55x is
limited to 64KW (like C54x) but base on TI documents I think that C55x
could support more than that by means of XARn. Does using more than
64kw data memory incur any load or slow down on performance?
> Could you send me a sample .cmd file for this purpose?
>  Please reply it is very important for me because I want to select a
c55x dsp for my project if and only if it supports data memory more
than 64KWs.
> Regards
>
The XAR in C55x is 16bits long.The C55x DSP can cross the page
boundary(64KW) only if you extend to 32bit before you access. 
For example, if the y is a pointer and you may need to access cross
page boundary, you can use following:

y=(uint16 *)((uint32)y+1);//uint16 *y;
The y will move to AC(32 bits) instead of XAR(16 bits).
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Ahmad-

> Would you please answer my following question clearly?
> Technical support @ ti.com said to me that data memory for C55x is limited
> to 64KW (like C54x) but base on TI documents I think that C55x could support
> more than that by means of XARn. Does using more than 64kw data memory incur
> any load or slow down on performance?
> Could you send me a sample .cmd file for this purpose?
>  Please reply it is very important for me because I want to select a c55x dsp
> for my project if and only if it supports data memory more than 64KWs.

First, regarding XARn:

  http://focus.ti.com/lit/ug/spru376a/spru376a.pdf

  http:/www.fulton.asu.edu/~karam/realdsp/Lectures/TIC55x_Addressing_Revised.ppt 

Note that XARn does not automatically increment if ARn wraps around 64k; your C55x
code has to handle that condition.

Second, for MELPe you don't need more than 64k x16 data memory, because the codebook
tables can be stored in program memory.  We went over this already.

-Jeff

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

On Thursday 05 June 2008, Jeff Brower wrote:
> > Would you please answer my following question clearly?
> > Technical support @ ti.com said to me that data memory for C55x is
> > limited to 64KW (like C54x) but base on TI documents I think that C55x
> > could support more than that by means of XARn. Does using more than 64kw
> > data memory incur any load or slow down on performance?
> > Could you send me a sample .cmd file for this purpose?
> >  Please reply it is very important for me because I want to select a c55x
> > dsp for my project if and only if it supports data memory more than
> > 64KWs.
>
> First, regarding XARn:
>
>   http://focus.ti.com/lit/ug/spru376a/spru376a.pdf
>
>  
> http:/www.fulton.asu.edu/~karam/realdsp/Lectures/TIC55x_Addressing_Revised.
>ppt
>
> Note that XARn does not automatically increment if ARn wraps around 64k;
> your C55x code has to handle that condition.

Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to have 
this page-boundary wrap-around bug in http://www.ti.com/litv/pdf/spru599d ?

Are such chips available "in the wild"?

The following pdf file mentions that OMAP1710 and OMAP2420 should have
revision 3.0 of C55x DSP:
http://www.ocpip.org/japanese/news/presentations/Japanese_JapanTI.pdf

But I'm observing this page wrap-around issue on Nokia 770 which uses
OMAP1710 :( Should this "no page-boundary wrap-around" mode be specifically
enabled in some way? Or is this pdf wrong?

-- 
Best regards,
Siarhei Siamashka

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Siarhei-

> On Thursday 05 June 2008, Jeff Brower wrote:
> > > Would you please answer my following question clearly?
> > > Technical support @ ti.com said to me that data memory for C55x is
> > > limited to 64KW (like C54x) but base on TI documents I think that C55x
> > > could support more than that by means of XARn. Does using more than 64kw
> > > data memory incur any load or slow down on performance?
> > > Could you send me a sample .cmd file for this purpose?
> > >  Please reply it is very important for me because I want to select a c55x
> > > dsp for my project if and only if it supports data memory more than
> > > 64KWs.
> >
> > First, regarding XARn:
> >
> >   http://focus.ti.com/lit/ug/spru376a/spru376a.pdf
> >
> >
> > http:/www.fulton.asu.edu/~karam/realdsp/Lectures/TIC55x_Addressing_Revised.
> >ppt
> >
> > Note that XARn does not automatically increment if ARn wraps around 64k;
> > your C55x code has to handle that condition.
> 
> Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to have
> this page-boundary wrap-around bug in http://www.ti.com/litv/pdf/spru599d ?
> 
> Are such chips available "in the wild"?
> 
> The following pdf file mentions that OMAP1710 and OMAP2420 should have
> revision 3.0 of C55x DSP:
> http://www.ocpip.org/japanese/news/presentations/Japanese_JapanTI.pdf
> 
> But I'm observing this page wrap-around issue on Nokia 770 which uses
> OMAP1710 :( Should this "no page-boundary wrap-around" mode be specifically
> enabled in some way? Or is this pdf wrong?

The PDF says "Also, in C55x CPU revision 3.0 onwards, the data addressing is linear,
so this wraparound on page boundary does not occur."  But I don't see how data
addressing can be "linear" without the XARn register automatically updating; i.e.
the
ARn register has to wrap back to zero and XARn has to increment.  My understanding is
that no C55x devices (2.x or 3.x) support this on automatic basis; user code has to
handle the page crossing condition.

Maybe a TI person on this group can clarify.

-Jeff

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Jeff;
Is it possible to set codebook in program memory and use it in C programming or it is only for
assembly?

Can I simply croos between pages?
Regards

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Siarhei--

> Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to have
> this page-boundary wrap-around bug in http://www.ti.com/litv/pdf/spru599d ?

First-up, TI doesnt consider this as a bug. They say rev2 had a known
limitation.
> Are such chips available "in the wild"?

Iam not very sure but newer C5510DSK that you find in sales channels uses Rev3.
> The following pdf file mentions that OMAP1710 and OMAP2420 should have
> revision 3.0 of C55x DSP:

I believe 1710 has Rev3 silicon. But TRM mentions 64ke restrictions.
Iam confused too.

> http://www.ocpip.org/japanese/news/presentations/Japanese_JapanTI.pdf
>
> But I'm observing this page wrap-around issue on Nokia 770 which uses
> OMAP1710 :( Should this "no page-boundary wrap-around" mode be specifically
> enabled in some way? Or is this pdf wrong?

See previous comment.

--Bhooshan

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Jeff--

> The PDF says "Also, in C55x CPU revision 3.0 onwards, the data addressing is
> linear,
> so this wraparound on page boundary does not occur." But I don't see how
> data
> addressing can be "linear" without the XARn register automatically updating;

Rev3 is flat memory and the DAGEN units have been expanded to a full
23 bit unit.

> i.e. the
> ARn register has to wrap back to zero and XARn has to increment. My
> understanding is
> that no C55x devices (2.x or 3.x) support this on automatic basis; user code
> has to
> handle the page crossing condition.

Iam doubtful on this. I think its handled auto from what I understand.

> Maybe a TI person on this group can clarify.
I hope so!
--Bhooshan

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

On Friday 06 June 2008, Bhooshan Iyer wrote:
> Siarhei--
>
> > Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to
> > have this page-boundary wrap-around bug in
> > http://www.ti.com/litv/pdf/spru599d ?
>
> First-up, TI doesnt consider this as a bug. They say rev2 had a known
> limitation.

That's just the other way to say it :) It might be not a silicon bug, but I
still consider it a design bug at least.

> > The following pdf file mentions that OMAP1710 and OMAP2420 should have
> > revision 3.0 of C55x DSP:
>
> I believe 1710 has Rev3 silicon. But TRM mentions 64ke restrictions.
> Iam confused too.

So might they be some custom chips which have all the bug fixes from Rev3, 
but page boundary wrap-around kept for some reasons (for example for better
compatibility with previous OMAP chips)?

Just because page boundary wrap-around looks like some special case of
circular buffer addressing, I had a hope that it might be configurable,
with "Rev2 compatibility mode" set as default.

I really would like to hear a comment from TI representative. I guess the
answer might be one of the following:
- OMAP1710 has page boundary wrap-around limitation and you can't do anything
about it  
- page boundary wrap-around can be disabled by setting some bit in some
status register
- no comments, that's a big secret :)

-- 
Best regards,
Siarhei Siamashka

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Hi,

C55x supports data memory more than 64kw, using XARn registers. But, this
64kw is DARAM(PAGE 0).
more than 64kw is SARAM. there is no difference between these two memories
when you profile your code on simulator. But, when you profile your code on
hardware, as SARAM is sequential access memory, instruction that is using
data in SARAM will take more number of cycles than data in DARAM.

Regards,
Chandrakala.

On Thu, Jun 5, 2008 at 11:43 AM, <a...@yahoo.com> wrote:

>   Hi
> Would you please answer my following question clearly?
> Technical support @ ti.com said to me that data memory for C55x is limited
> to 64KW (like C54x) but base on TI documents I think that C55x could support
> more than that by means of XARn. Does using more than 64kw data memory incur
> any load or slow down on performance?
> Could you send me a sample .cmd file for this purpose?
> Please reply it is very important for me because I want to select a c55x
> dsp for my project if and only if it supports data memory more than 64KWs.
> Regards
>
>  
>

Siarhei--
I have had it confirmed from TI that 1710 indeed has rev3 silicon and the
page pointer restriction issue doesnt apply anymore.

You said:

*"But I'm observing this page wrap-around issue on Nokia 770 which uses
OMAP1710 :( Should this "no page-boundary wrap-around" mode be specifically
enabled in some way? Or is this pdf wrong?"*

Whats the basis for this observation? If you can substantiate, I can go back
and check again with TI.

--Bhooshan

On Sat, Jun 7, 2008 at 1:49 PM, Siarhei Siamashka <
s...@gmail.com> wrote:

>   On Friday 06 June 2008, Bhooshan Iyer wrote:
> > Siarhei--
> >
> > > Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to
> > > have this page-boundary wrap-around bug in
> > > http://www.ti.com/litv/pdf/spru599d ?
> >
> > First-up, TI doesnt consider this as a bug. They say rev2 had a known
> > limitation.
>
> That's just the other way to say it :) It might be not a silicon bug, but I
> still consider it a design bug at least.
>
> > > The following pdf file mentions that OMAP1710 and OMAP2420 should have
> > > revision 3.0 of C55x DSP:
> >
> > I believe 1710 has Rev3 silicon. But TRM mentions 64ke restrictions.
> > Iam confused too.
>
> So might they be some custom chips which have all the bug fixes from Rev3,
> but page boundary wrap-around kept for some reasons (for example for better
> compatibility with previous OMAP chips)?
>
> Just because page boundary wrap-around looks like some special case of
> circular buffer addressing, I had a hope that it might be configurable,
> with "Rev2 compatibility mode" set as default.
>
> I really would like to hear a comment from TI representative. I guess the
> answer might be one of the following:
> - OMAP1710 has page boundary wrap-around limitation and you can't do
> anything
> about it
> - page boundary wrap-around can be disabled by setting some bit in some
> status register
> - no comments, that's a big secret :)
>
> --
> Best regards,
> Siarhei Siamashka
>  
>

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

All--

I have new info on the 55x rev3 silicon issue. Apparently there is
configurability by means of the reset vector to either use 23-Bit addressing
or 16-Bit addressing. This functionality is controlled by Bit 25 of the 55x
reset vector (the first 32 Bit word fetched by the C55 after Reset).If this
Bit is set to 0 then the 55x core in OMAP1710 will operate in 16-Bit mode,
when it is set to 1 then the C55x in OMAP1710 will operate in 23-Bit mode.
If set to 23bit, it invalidates the usage of the wrap around feature, else
the wrap around feature can/should be used.

--Bhooshan
On Tue, Jun 10, 2008 at 2:48 PM, Bhooshan Iyer <b...@gmail.com>
wrote:

> Siarhei--
> I have had it confirmed from TI that 1710 indeed has rev3 silicon and the
> page pointer restriction issue doesnt apply anymore.
>
> You said:
>
> *"But I'm observing this page wrap-around issue on Nokia 770 which uses
> OMAP1710 :( Should this "no page-boundary wrap-around" mode be specifically
> enabled in some way? Or is this pdf wrong?"*
>
> Whats the basis for this observation? If you can substantiate, I can go
> back and check again with TI.
>
> --Bhooshan
> On Sat, Jun 7, 2008 at 1:49 PM, Siarhei Siamashka <
> s...@gmail.com> wrote:
>
>>    On Friday 06 June 2008, Bhooshan Iyer wrote:
>> > Siarhei--
>> >
>> > > Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to
>> > > have this page-boundary wrap-around bug in
>> > > http://www.ti.com/litv/pdf/spru599d ?
>> >
>> > First-up, TI doesnt consider this as a bug. They say rev2 had a known
>> > limitation.
>>
>> That's just the other way to say it :) It might be not a silicon bug, but
>> I
>> still consider it a design bug at least.
>>
>> > > The following pdf file mentions that OMAP1710 and OMAP2420 should have
>> > > revision 3.0 of C55x DSP:
>> >
>> > I believe 1710 has Rev3 silicon. But TRM mentions 64ke restrictions.
>> > Iam confused too.
>>
>> So might they be some custom chips which have all the bug fixes from Rev3,
>>
>> but page boundary wrap-around kept for some reasons (for example for
>> better
>> compatibility with previous OMAP chips)?
>>
>> Just because page boundary wrap-around looks like some special case of
>> circular buffer addressing, I had a hope that it might be configurable,
>> with "Rev2 compatibility mode" set as default.
>>
>> I really would like to hear a comment from TI representative. I guess the
>> answer might be one of the following:
>> - OMAP1710 has page boundary wrap-around limitation and you can't do
>> anything
>> about it
>> - page boundary wrap-around can be disabled by setting some bit in some
>> status register
>> - no comments, that's a big secret :)
>>
>> --
>> Best regards,
>> Siarhei Siamashka

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

Bhooshan-

> I have new info on the 55x rev3 silicon issue. Apparently there is
> configurability by means of the reset vector to either use 23-Bit addressing
> or 16-Bit addressing. This functionality is controlled by Bit 25 of the 55x
> reset vector (the first 32 Bit word fetched by the C55 after Reset).If this
> Bit is set to 0 then the 55x core in OMAP1710 will operate in 16-Bit mode,
> when it is set to 1 then the C55x in OMAP1710 will operate in 23-Bit mode.
> If set to 23bit, it invalidates the usage of the wrap around feature, else
> the wrap around feature can/should be used.

Huh, never seen that one before.  Normally the first instruction will be an
unconditional branch; is that what TI is suggesting?  Or a NOP or something else?

Sounds like TI needed a way avoid changes to onchip (or offchip) I/O circuitry,
boot-loader etc, and limit the affect to the CPU core.

-Jeff

> On Tue, Jun 10, 2008 at 2:48 PM, Bhooshan Iyer <b...@gmail.com>
> wrote:
> 
> > Siarhei--
> > I have had it confirmed from TI that 1710 indeed has rev3 silicon and the
> > page pointer restriction issue doesnt apply anymore.
> >
> > You said:
> >
> > *"But I'm observing this page wrap-around issue on Nokia 770 which uses
> > OMAP1710 :( Should this "no page-boundary wrap-around" mode be
specifically
> > enabled in some way? Or is this pdf wrong?"*
> >
> > Whats the basis for this observation? If you can substantiate, I can go
> > back and check again with TI.
> >
> > --Bhooshan
> >
> >
> > On Sat, Jun 7, 2008 at 1:49 PM, Siarhei Siamashka <
> > s...@gmail.com> wrote:
> >
> >>    On Friday 06 June 2008, Bhooshan Iyer wrote:
> >> > Siarhei--
> >> >
> >> > > Hi, I wonder about C55x silicon revision 3.0 as it is mentioned not to
> >> > > have this page-boundary wrap-around bug in
> >> > > http://www.ti.com/litv/pdf/spru599d ?
> >> >
> >> > First-up, TI doesnt consider this as a bug. They say rev2 had a known
> >> > limitation.
> >>
> >> That's just the other way to say it :) It might be not a silicon bug, but
> >> I
> >> still consider it a design bug at least.
> >>
> >> > > The following pdf file mentions that OMAP1710 and OMAP2420 should have
> >> > > revision 3.0 of C55x DSP:
> >> >
> >> > I believe 1710 has Rev3 silicon. But TRM mentions 64ke restrictions.
> >> > Iam confused too.
> >>
> >> So might they be some custom chips which have all the bug fixes from Rev3,
> >>
> >> but page boundary wrap-around kept for some reasons (for example for
> >> better
> >> compatibility with previous OMAP chips)?
> >>
> >> Just because page boundary wrap-around looks like some special case of
> >> circular buffer addressing, I had a hope that it might be configurable,
> >> with "Rev2 compatibility mode" set as default.
> >>
> >> I really would like to hear a comment from TI representative. I guess the
> >> answer might be one of the following:
> >> - OMAP1710 has page boundary wrap-around limitation and you can't do
> >> anything
> >> about it
> >> - page boundary wrap-around can be disabled by setting some bit in some
> >> status register
> >> - no comments, that's a big secret :)
> >>
> >> --
> >> Best regards,
> >> Siarhei Siamashka
> >>
> >> ------------------------------------
> 
> OMAP35x EVM jump-starts low-power apps
> ------------------------------------
> The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start
building applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x
> 

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

On Monday 16 June 2008, Bhooshan Iyer wrote:
> I have new info on the 55x rev3 silicon issue. Apparently there is
> configurability by means of the reset vector to either use 23-Bit
> addressing or 16-Bit addressing. This functionality is controlled by Bit 25
> of the 55x reset vector (the first 32 Bit word fetched by the C55 after
> Reset).If this Bit is set to 0 then the 55x core in OMAP1710 will operate
> in 16-Bit mode, when it is set to 1 then the C55x in OMAP1710 will operate
> in 23-Bit mode. If set to 23bit, it invalidates the usage of the wrap
> around feature, else the wrap around feature can/should be used.

Thanks a lot. Just experimented with setting this bit in the reset vector and
it really works!

-- 
Best regards,
Siarhei Siamashka

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x