Ahmad-
> Before responding to your questions I have a very important question: "technical
> support @ ti.com said to me that data memory for C55x is limited to 64KW (like
> C54x) but you said that it could support more than that.

TI tech support must be confused, or you must have confused them.  If that were true,
then what are the XARn registers for?  C55x is an improvement over C54x.
> does using more than 64kw data memory incurs any load or slow down on performance?

No.
> 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.

No.  I'm doing my best to give you some advice and answer many of your posts.  But
I'm not doing your project for you.
> We used c64x functional simulator version3.
>
> Yes we use the distributed fixed point version. Its memory usage is 148kw. Do you
> know where can I download a suitable version of melpe for DSP?

No.  Of course a DSP-based, real-time MELPe code distribution is not free.  You've
spent months on this project -- by now you fully realize it's not easy.  Who do you
think is going to give it to you for free?  After you've got it working (more
months), would you give your code away for free?

-Jeff

PS. Post to the group not to me.
> Jeff Brower <j...@signalogic.com> wrote:
>
>       Ahmad-
>
>      > I compute the execution cycles and MIPs for my algorithm on C64x
>      > simulator using its profiler. But as I saw the "total cycles" item
>      > was very more than "CPU execution cycles" item.
>      > My question is that the "total cycles" is important or
"execution
>      cycles"?
>      > Is the numbers of cycles is so big if we use C55x or it is because of
>      > C64x structure(its cash levels)?
>      > My algorithm is MELPe based and so it contains very big arrays and then
>
>      > the cash structure of C6x may slow down
>      > it???????is it true?
>
>      Additional non-CPU cycles are due to external memory access, I/O
>      (peripheral) access, DMA, etc.
>
>      Which 64x device are you simulating? A device such as 6415 has enough
>      onchip memory to hold all MELPe program and
>      codebook tables, so you would not need external memory (SDRAM).
>
>      Did you just load the MELPe distribution fixed-point C code? If so that's
>      intended for x86 and doesn't have efficient
>      organization and memory usage. What does the simulator show as your total
>      memory requirement?
>
>      -Jeff
>

Jeff--
Your post is the most helpful and restrained response I have seen on "whats
my code doing on your computer" type question.

--Bhooshan

On Fri, Jun 6, 2008 at 10:32 AM, Jeff Brower <j...@signalogic.com> wrote:

>   Ahmad-
> Before responding to your questions I have a very important question:
> "technical support @ ti.com said to me that data memory for C55x is
> limited to 64KW (like C54x) but you said that it could support more than
> that.
> TI tech support must be confused, or you must have confused them.  If that
> were true, then what are the XARn registers for?  C55x is an improvement
> over C54x.
> does using more than 64kw data memory incurs any load or slow down on
> performance?
> No.
> 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.
> No.  I'm doing my best to give you some advice and answer many of your
> posts.  But I'm not doing your project for you.
> We used c64x functional simulator version3.
>
> Yes we use the distributed fixed point version. Its memory usage is 148kw.
> Do you know where can I download a suitable version of melpe for DSP?
> No.  Of course a DSP-based, real-time MELPe code distribution is not free.
> You've spent months on this project -- by now you fully realize it's not
> easy.  Who do you think is going to give it to you for free?  After you've
> got it working (more months), would you give your code away for free?
>
> -Jeff
>
> PS. Post to the group not to me.
> *Jeff Brower <j...@signalogic.com>* wrote:
>
>  Ahmad-
>
> > I compute the execution cycles and MIPs for my algorithm on C64x
> > simulator using its profiler. But as I saw the "total cycles" item
> > was very more than "CPU execution cycles" item.
> > My question is that the "total cycles" is important or "execution
> cycles"?
> > Is the numbers of cycles is so big if we use C55x or it is because of
> > C64x structure(its cash levels)?
> > My algorithm is MELPe based and so it contains very big arrays and then
> > the cash structure of C6x may slow down
> > it???????is it true?
>
> Additional non-CPU cycles are due to external memory access, I/O
> (peripheral) access, DMA, etc.
>
> Which 64x device are you simulating? A device such as 6415 has enough
> onchip memory to hold all MELPe program and
> codebook tables, so you would not need external memory (SDRAM).
>
> Did you just load the MELPe distribution fixed-point C code? If so that's
> intended for x86 and doesn't have efficient
> organization and memory usage. What does the simulator show as your total
> memory requirement?
>
> -Jeff
>
>      
>

-- 
-----------------------------------------------------------
"I've missed more than 9000 shots in my career.
I've lost almost 300 games. 26 times I've been trusted to take the game
winning shot and missed.
I've failed over and over again in my life.
And that is why I succeed."
-- Michael Jordan
-----------------------------------------------------------
------------------------------------

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

A bit off topic:
Though I agree with Jeff in this specific thread, I'd like to see a
discussion about code sharing in the embedded community. I originally come
from a high level programming point of view (Java, C++, C) where open source
and code sharing is a bit more common.

I try to share my code, if there's something I've struggled with that might
help others, unless it of course interferes with my company's interests.
Code sharing pushes everyone forward, shortening our development time. Is
this something totally non-existant in the embedded community?

But again - this specific thread was not about getting a small example of
code to get going, but seemed to be a request for a more full project, which
is of course not the aim of code sharing.

-Sima
> No.  Of course a DSP-based, real-time MELPe code distribution is not free.
> You've spent months on this project -- by now you fully realize it's not
> easy.  Who do you think is going to give it to you for free?  After you've
> got it working (more months), would you give your code away for free?
>
> -Jeff
>

Sima-
> A bit off topic:
> Though I agree with Jeff in this specific thread, I'd like to see a discussion
> about code sharing in the embedded community. I originally come from a high level
> programming point of view (Java, C++, C) where open source and code sharing is a
> bit more common.
>
> I try to share my code, if there's something I've struggled with that might help
> others, unless it of course interferes with my company's interests. Code sharing
> pushes everyone forward, shortening our development time.

Agree.
> Is this something totally non-existant in the embedded community?

Open source is the way of the future, no question, regardless of level (OS,
application, embedded system, etc).  But I would add that embedded system developers
tend not to share, as their work often involves extensive hardware development in
order to make a functional product, and thus requires far greater investment in money
and engineering time.

But it's helpful to be nuanced when looking at this -- are they actually still
sharing?  A couple of good recent examples are Asterisk and GNU radio (software
defined radio).  Both of these are "getting done" on generic Linux machines, with
tremendous effort being put in by engineers, researchers, and developers across the
spectrum (companies, Univ programs, government and mil guys, etc).  The easiest way
to share on such complex projects is for everyone to use basic x86 servers and a few
popular distributions of Linux.  But at the same time embedded developers take this
code, customize when necessary, and migrate to a wide variety of "box" products
(note
there are crucial licensing issues in this process, to be discussed elsewhere).  At
the product level embedded developers are not likely to share, but those same guys
are sharing "one level up", i.e. in the Linux PC community.  This makes sense
because
it's in their best interest for the open source code base -- on which their products
depend -- to continue to advance.

In the GNU radio group, in particular, one sees a lot of work taking place to improve
latency and other aspects of real-time performance -- work that directly applies to
embedded systems.  No doubt those developers have their eye on actual products, but
they find it beneficial to share the basic development and "prototyping" with the
group.

-Jeff