Ahmad-
> I asked the following questions through the email
because I did not receive their
> responds in www.dsprelated.com.
Who's asking? Ahmad? A. Salehi? Daryoosh? You guys probably got
answers, but
it's too confusing to go back and look since the person asking the
questions keeps
changing.
> 1- Are you sure that C6204 chip is going to be
obsolete. I asked from suport@ti and
> they say that the chip will be active?
I never said the C6204 would be obsolete. Hopefully you're not telling
people at TI
that I said the chip would be obsolete. TI very rarely actually discontinues
a
chip. I said it would be difficult to get your project done using C6204, since
there
would be very few sources of support. Active development is not occurring with
this
device. Go back and read my posts about this again.
> 2- Do you know why the MIPs for implementation of
MELPe encoder on C55x is nearly
> half of that in C6x? I perceive it from the information of "vocal" and
"adaptive
> digital" and "compandent" implementations.
My guess would be that more people have spent time to optimize C55x
implementations
of MELPe. Since MELPe is typically used in client-side or embedded system
applications, that often means requirements for low power consumption, small
form-factor, and low cost. These are requirements for which C55x may be more
suitable than C64x.
Suggest for your remaining questions that you post as separate threads, one for
file
I/O (c55x group), one for simulator CPU vs. execution cycles (c6x group).
-Jeff
> 3- I have written a C source code for C55x simulator
in which I have used the
> "fopen" function for reading the input samples from a file. But when my
program
> counter reaches to fopen execution the following error is displayed several
times
> and yhe program exits:
> Invalid CIO command (0).
>
> I deleted the "fopen" and "fprint" and other file related functions and use
a
> constant array as input data (instead of file context). Then I ran the
program
> again and the following error message happened during execution of my
program:
> Trouble running Target CPU: WARNING: PAGE BOUNDARY CROSSING DETECTED AT
PROGRAM
> COUNTER 0x12ee3
> the 0x12ee3 address is part of the _printfi(text) code.
> my .CMD and .map files are as follow:
> PAGE 0: /* ---- Unified Program/Data Address Space ---- */
> PMEM (RWIX) : origin = 0x000100, length = 0x01ff00 /* 128Kb page of RAM
*/
> PMEM2 (RWIX) : origin = 0x020100, length = 0x01ff00
> PMEM3 (RWIX) : origin = 0x040100, length = 0x01ff00
> PMEM4 (RWIX) : origin = 0x060100, length = 0x01ff00
> SECTIONS
> {
> .sysstack {} > PMEM2 PAGE 0
> .stack {} > PMEM2 PAGE 0
> .vectors: {} > PMEM PAGE 0
> .text: {} > PMEM PAGE 0
> .cinit: {} > PMEM4 PAGE 0
> .far: {} > PMEM PAGE 0
> .sysmem {} > PMEM PAGE 0
> .const: {} > PMEM PAGE 0
> .bss1: {} > PMEM PAGE 0
> .bss: {} > PMEM3 PAGE 0
> .cio: {} > PMEM PAGE 0
> .data: {} > PMEM PAGE 0
> }
>
> .MAP file:
> PAGE 0: PMEM 00000100 0001ff00 0001c24d RWIX
> PMEM2 00020100 0001ff00 000023e8 RWIX
> PMEM3 00040100 0001ff00 00013258 RWIX
> PMEM4 00060100 0001ff00 0000fefc RWIX
> output attributes/
> section page orgn(bytes) orgn(words) len(bytes) len(words) input
sections
> -------- ---- ----------- ----------- ---------- ----------
--------------
> .text 0 00000100 [ 00000080 ] 00013ca5 *
> .const 0 [ 00013da8 ] 00009ed4 * 00003134
> .bss 0 [ 00040100 ] 00020080 * 0000992c
> .cinit 0 [ 00060100 ] 00030080 * 00007f7e
> 4- 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)?
> Regards
> A.Salehi
