Suggation needed for 6713

Hello,
I am currently working on H.264 feature Integer DCT. I am modifying code and want to implement this feature on 6713. I want to know that weather it will be possible to do so?
Actually initially I was using setup for dm642 ccs. But since it is not available in my college I decided to go for 6713. I am new to this and want to know will it be possible. I just want to put integer dct implementation on 6713.
Any valuable suggation plz
Regards,
Nilesh Start a New Thread

Nilesh-

> I am currently working on H.264 feature Integer DCT. I am modifying code
> and want to implement this feature on 6713. I want to know that weather it
> will be possible to do so?
> Actually initially I was using setup for dm642 ccs. But since it is not
> available in my college I decided to go for 6713. I am new to this and want
> to know will it be possible. I just want to put integer dct implementation on 6713.
> Any valuable suggation plz

Suggest to look over recent C6x group discussion on subject "Using C6713 for image
processing". Here is the thread:

http://tech.groups.yahoo.com/group/c6x/message/8112

For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
algorithms it's going to a lot slower than DM642. You might try to locate a DSK
6416, which is low-cost and your Univ/college should have available.

-Jeff Start a New Thread

Hi...
There is no problem but we do not have dm642 available.
Can u please elaborate what did you mean to say by emulation on dsp matlab...
Regards,

Nilesh
tuo faith wrote:
Hi:

Can tell me what is your problem when you test H.264 on the DM642 chip? btw, you'd better to emulate it based on the dsp and matlab .

"H.264encoderondm642" wrote:
Hello,
I am currently working on H.264 feature Integer DCT. I am modifying code and want to implement this feature on 6713. I want to know that weather it will be possible to do so?
Actually initially I was using setup for dm642 ccs. But since it is not available in my college I decided to go for 6713. I am new to this and want to know will it be possible. I just want to put integer dct implementation on 6713.
Any valuable suggation plz
Regards,
Nilesh Start a New Thread

As I said last mail that we do not have 64xx series dsps available in our college I have no other option but to use 6713 dsp for implementing integer dct. Here I have some queries as below:

Now if I want real time implementation of H.264 decoder on TI with just integer dct on 6713 implemented, it means that I have to use file I\Os. Is this facility available on 6713? I want to write residual dct coeff. data in dsp memory and get its dct and again exchange idct o\p residual data with host pc through dsp memory, which will then continue with rest of decoding. Will this be a simple routine?

Can I use interrupts for this real time exchange of dct? Which will be better and less time to design.

What type of synchronization will I have to use between host and dsp? Assuming that I will use some flag in memory that will be polled by dsp and host to start processing dct coeff. And idct residuals respectively. That is this is a sequential process for each frame or macroblock even.

I initially do not mind how slow I have to keep my frame rate or processed by host pc I want to display decoded bitstream in original yuv format on my host while processing is being done, will this work? From my info there is no video port on 6713.

What kind of difference is between 6711 and 6713? Is they are compatible for code and h\w, memory mapping point of view?
Any other Concerns that i have to take care while implementing on 6713?
Thanx and Regards,
Nilesh
Jeff Brower wrote: Nilesh-

> Thanx for quick reply. In fact after reading all resopnses in lastr couple of days only i decided to ask query. Still
> i have some Q's in my mind. These are as below:
> 1. Is 64xx series latest as compared to 67xx?

Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in 2005. Currently TI's fastest available device
is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.

> 2. How much approx. cost of 6413 dsp board will? i don't know weather it is or not available in my college so
> i have to check that.

I think 6416 DSK is same cost as others, or close to it -- about USD 400.

> 3. For Integer DCT implementation fixed point is best processor to use i guess is that right? and i think 64xx
> seris is fixed point dsp series...?

Yes. 16x16 multipliers, 32-bit accumulators.

> 4. I agree that 67xx based implementaion will not be an efficient method. But will it worth some value at least
> entry level work exp. as i am doing my final year project and not a professional work , so if no 6416 is available i
> mean to say...

As I mentioned, for academic implementation one sub-block of H.264 algorithm, 6713 should be Ok assuming the main
point is to obtain DSP learning and experience. I would add that after graduation during your job search, it would
look better if you had done image processing work using 641x.

-Jeff

> Jeff Brower wrote: Nilesh-
>
>> I am currently working on H.264 feature Integer DCT. I am modifying code
>> and want to implement this feature on 6713. I want to know that weather it
>> will be possible to do so?
>> Actually initially I was using setup for dm642 ccs. But since it is not
>> available in my college I decided to go for 6713. I am new to this and want
>> to know will it be possible. I just want to put integer dct implementation on 6713.
>> Any valuable suggation plz
>
> Suggest to look over recent C6x group discussion on subject "Using C6713 for image
> processing". Here is the thread:
>
> http://tech.groups.yahoo.com/group/c6x/message/8112
>
> For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
> algorithms it's going to a lot slower than DM642. You might try to locate a DSK
> 6416, which is low-cost and your Univ/college should have available.
>
> -Jeff
> Start a New Thread

Hello Sir,
Your response is worth value for me! I am really thankful to you. I want to clear few of my doubts.

By JTAG u means to say emulator , right? If yes I have ext. emulator option on dsk 6713. And if emulator becomes unavailable then is there any other way to communicate with host? I mean usb or other.

In my case do I need to make 2 ccs projects? One for host and other for dsk. Or one program will suffice? Also what about memory mapping of project running on ccs should it be hypothetical then?

Can I use vc++ to communicate with dsk? And will it be easy as compared to ccs? I hope not. What is your say?

Thanking you ,
Nilesh

Jeff Brower wrote: Nilesh-

> As I said last mail that we do not have 64xx series dsp's available in our
> college I have no other option but to use 6713 dsp for implementing integer
> dct. Here I have some queries as below:
> Now if I want real time implementation of H.264 decoder on TI with just
> integer dct on 6713 implemented, it means that I have to use file I\O's.
> Is this facility available on 6713?

Yes, available via CCS + JTAG, independent of DSP type.

> I want to write residual dct coeff. data in dsp memory and get its dct and
> again exchange idct o\p residual data with host pc through dsp memory,
> which will then continue with rest of decoding. Will this be a simple
> routine?

The code for host file I/O is relatively simple but transfer rates are not fast.

> Can I use interrupts for this real time exchange of dct? Which will be
> better and less time to design.
>
> What type of synchronization will I have to use between host and dsp?
> Assuming that I will use some flag in memory that will be polled by dsp
> and host to start processing dct coeff. And idct residuals'
> respectively. That is this is a sequential process for each frame or
> macroblock even.

For questions about host data transfer using CCS + JTAG, you should first study TI
docs about "RTDX". You should not be setting up your own low-level interrupts and
semaphores. The exception would be if you are using HPI, which you won't be doing on
DSK 6713.

> I initially do not mind how slow I have to keep my frame rate or
> processed by host pc I want to display decoded bitstream in original yuv
> format on my host while processing is being done, will this work?

Should be possible, but image update rate will be slow.

> What kind of difference is between 6711 and 6713? Is they are compatible
> for code and h\w, memory mapping point of view?

For your application, main differences are speed (6713 is twice as fast) and amount
of onchip SRAM (6713 has 4x amount).

-Jeff

> Jeff Brower wrote: Nilesh-
>
> > Thanx for quick reply. In fact after reading all resopnses in lastr couple of days only i decided to ask query. Still
> > i have some Q's in my mind. These are as below:
> > 1. Is 64xx series latest as compared to 67xx?
>
> Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in 2005. Currently TI's fastest available device
> is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.
>
> > 2. How much approx. cost of 6413 dsp board will? i don't know weather it is or not available in my college so
> > i have to check that.
>
> I think 6416 DSK is same cost as others, or close to it -- about USD 400.
>
> > 3. For Integer DCT implementation fixed point is best processor to use i guess is that right? and i think 64xx
> > seris is fixed point dsp series...?
>
> Yes. 16x16 multipliers, 32-bit accumulators.
>
> > 4. I agree that 67xx based implementaion will not be an efficient method. But will it worth some value at least
> > entry level work exp. as i am doing my final year project and not a professional work , so if no 6416 is available i
> > mean to say...
>
> As I mentioned, for academic implementation one sub-block of H.264 algorithm, 6713 should be Ok assuming the main
> point is to obtain DSP learning and experience. I would add that after graduation during your job search, it would
> look better if you had done image processing work using 641x.
>
> -Jeff
>
> > Jeff Brower wrote: Nilesh-
> >
> >> I am currently working on H.264 feature Integer DCT. I am modifying code
> >> and want to implement this feature on 6713. I want to know that weather it
> >> will be possible to do so?
> >> Actually initially I was using setup for dm642 ccs. But since it is not
> >> available in my college I decided to go for 6713. I am new to this and want
> >> to know will it be possible. I just want to put integer dct implementation on 6713.
> >> Any valuable suggation plz
> >
> > Suggest to look over recent C6x group discussion on subject "Using C6713 for image
> > processing". Here is the thread:
> >
> > http://tech.groups.yahoo.com/group/c6x/message/8112
> >
> > For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
> > algorithms it's going to a lot slower than DM642. You might try to locate a DSK
> > 6416, which is low-cost and your Univ/college should have available.
> >
> > -Jeff Start a New Thread

Nilesh-

> As I said last mail that we do not have 64xx series dsp's available in our
> college I have no other option but to use 6713 dsp for implementing integer
> dct. Here I have some queries as below:
> Now if I want real time implementation of H.264 decoder on TI with just
> integer dct on 6713 implemented, it means that I have to use file I\O's.
> Is this facility available on 6713?

Yes, available via CCS + JTAG, independent of DSP type.

> I want to write residual dct coeff. data in dsp memory and get its dct and
> again exchange idct o\p residual data with host pc through dsp memory,
> which will then continue with rest of decoding. Will this be a simple
> routine?

The code for host file I/O is relatively simple but transfer rates are not fast.

> Can I use interrupts for this real time exchange of dct? Which will be
> better and less time to design.
>
> What type of synchronization will I have to use between host and dsp?
> Assuming that I will use some flag in memory that will be polled by dsp
> and host to start processing dct coeff. And idct residuals'
> respectively. That is this is a sequential process for each frame or
> macroblock even.

For questions about host data transfer using CCS + JTAG, you should first study TI
docs about "RTDX". You should not be setting up your own low-level interrupts and
semaphores. The exception would be if you are using HPI, which you won't be doing on
DSK 6713.

> I initially do not mind how slow I have to keep my frame rate or
> processed by host pc I want to display decoded bitstream in original yuv
> format on my host while processing is being done, will this work?

Should be possible, but image update rate will be slow.

> What kind of difference is between 6711 and 6713? Is they are compatible
> for code and h\w, memory mapping point of view?

For your application, main differences are speed (6713 is twice as fast) and amount
of onchip SRAM (6713 has 4x amount).

-Jeff

> Jeff Brower wrote: Nilesh-
>
> > Thanx for quick reply. In fact after reading all resopnses in lastr couple of days only i decided to ask query. Still
> > i have some Q's in my mind. These are as below:
> > 1. Is 64xx series latest as compared to 67xx?
>
> Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in 2005. Currently TI's fastest available device
> is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.
>
> > 2. How much approx. cost of 6413 dsp board will? i don't know weather it is or not available in my college so
> > i have to check that.
>
> I think 6416 DSK is same cost as others, or close to it -- about USD 400.
>
> > 3. For Integer DCT implementation fixed point is best processor to use i guess is that right? and i think 64xx
> > seris is fixed point dsp series...?
>
> Yes. 16x16 multipliers, 32-bit accumulators.
>
> > 4. I agree that 67xx based implementaion will not be an efficient method. But will it worth some value at least
> > entry level work exp. as i am doing my final year project and not a professional work , so if no 6416 is available i
> > mean to say...
>
> As I mentioned, for academic implementation one sub-block of H.264 algorithm, 6713 should be Ok assuming the main
> point is to obtain DSP learning and experience. I would add that after graduation during your job search, it would
> look better if you had done image processing work using 641x.
>
> -Jeff
>
> > Jeff Brower wrote: Nilesh-
> >
> >> I am currently working on H.264 feature Integer DCT. I am modifying code
> >> and want to implement this feature on 6713. I want to know that weather it
> >> will be possible to do so?
> >> Actually initially I was using setup for dm642 ccs. But since it is not
> >> available in my college I decided to go for 6713. I am new to this and want
> >> to know will it be possible. I just want to put integer dct implementation on 6713.
> >> Any valuable suggation plz
> >
> > Suggest to look over recent C6x group discussion on subject "Using C6713 for image
> > processing". Here is the thread:
> >
> > http://tech.groups.yahoo.com/group/c6x/message/8112
> >
> > For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
> > algorithms it's going to a lot slower than DM642. You might try to locate a DSK
> > 6416, which is low-cost and your Univ/college should have available.
> >
> > -Jeff Start a New Thread

Hello Sir,
## Do u means to say that I can use embedded JTAG emulator with just usb cable to pc and from CCS? What configuration setting I have to make for communication through this then?

## If I need to use one CCS project then :
My small portion of code i.e. integer dct is going to be on DSP 6713 so I need to download that part to 6713. So I was thinking to make 2 CCS project separately.
But if I can have this from one CCS project also possible then can u please explain me, how can I differentiate between part to be downloaded on target and remaining part that will be running on host through CCS. Do I need to have different sectional mapping to be used?

## Also I am getting following kind of errors while linking on CCS 6713:
[Linking...] "C:\CCStudio_v3.1\C6000\cgtools\bin\cl6x" -@"Debug.lkf"

undefined first referenced
symbol in file
--------- ----------------
_mref D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgY_ref D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgUV_tmp D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_P_interval D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_ftime D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_prevP_tr D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_p_trace D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgUV D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgY_tmp D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_tot_time D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_frame_no D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgY_pf D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_fb D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_alloca D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_p_ref D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgUV_prev D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_nal_startcode_follows D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_p_out D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_Bframe_ctr D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgY_prev D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_nextP_tr D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_mcef D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgUV_pf D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_errortext D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_refFrArr D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgUV_ref D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
_imgY D:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
>> error: symbol referencing errors - './Debug/TryDec.out' not built
>> Compilation failure
Build Complete,
2 Errors, 153 Warnings, 0 Remarks.
What can be reason? I have included .h file containing definition of global symbols as extern everywhere in .c file where errors are being reported.

Best Regards,
Nilesh

Jeff Brower wrote: Nilesh-

> By JTAG u means to say emulator , right? If yes I have ext. emulator option
> on dsk 6713. And if emulator becomes unavailable then is there any other way
> to communicate with host? I mean usb or other.

Yes I'm using term 'JTAG' interchangeably with emulator. But with DSK 6713, keep in
mind that you don't need a separate emulator unit (such as Spectrum Digital XDS510),
because CCS supports emulation over the USB port connection. This is a feature that
TI builds into CCS for DSK boards, but third-party boards typically don't have (which
is why most 3p boards require the external emulator to use CCS debug functions).

> In my case do I need to make 2 ccs projects? One for host and other for dsk.
> Or one program will suffice? Also what about memory mapping of project
> running on ccs should it be hypothetical then?

Just one CCS project. Your DSP code can perform host file I/O, but it's slow and you
have to be careful with it.

> Can I use vc++ to communicate with dsk? And will it be easy as compared to
> ccs? I hope not. What is your say?

Well that's a good question. For DSK 6711, TI offers a DLL that can be used to allow
Visual Studio C/C++ programs to communicate via the HPI. It works but has some
reliability issues. But for DSK 6713, the HPI is left unconnected, and all
communication goes through the USB + JTAG connection. EducationalDSP makes a small
daughtercard that you can add to the DSK 6713 and connect HPI to Visual Studio
programs (http://www.educationaldsp.com/stockproduct_dsk6xxxhpi.htm).

-Jeff

> Jeff Brower wrote: Nilesh-
>
> > As I said last mail that we do not have 64xx series dsp's available in our
> > college I have no other option but to use 6713 dsp for implementing integer
> > dct. Here I have some queries as below:
> >
> >
> > Now if I want real time implementation of H.264 decoder on TI with just
> > integer dct on 6713 implemented, it means that I have to use file I\O's.
> > Is this facility available on 6713?
>
> Yes, available via CCS + JTAG, independent of DSP type.
>
> > I want to write residual dct coeff. data in dsp memory and get its dct and
> > again exchange idct o\p residual data with host pc through dsp memory,
> > which will then continue with rest of decoding. Will this be a simple
> > routine?
>
> The code for host file I/O is relatively simple but transfer rates are not fast.
>
> > Can I use interrupts for this real time exchange of dct? Which will be
> > better and less time to design.
> >
> > What type of synchronization will I have to use between host and dsp?
> > Assuming that I will use some flag in memory that will be polled by dsp
> > and host to start processing dct coeff. And idct residuals'
> > respectively. That is this is a sequential process for each frame or
> > macroblock even.
>
> For questions about host data transfer using CCS + JTAG, you should first study TI
> docs about "RTDX". You should not be setting up your own low-level interrupts and
> semaphores. The exception would be if you are using HPI, which you won't be doing on
> DSK 6713.
>
> > I initially do not mind how slow I have to keep my frame rate or
> > processed by host pc I want to display decoded bitstream in original yuv
> > format on my host while processing is being done, will this work?
>
> Should be possible, but image update rate will be slow.
>
> > What kind of difference is between 6711 and 6713? Is they are compatible
> > for code and h\w, memory mapping point of view?
>
> For your application, main differences are speed (6713 is twice as fast) and amount
> of onchip SRAM (6713 has 4x amount).
>
> -Jeff
>
> > Jeff Brower wrote: Nilesh-
> >
> > > Thanx for quick reply. In fact after reading all resopnses in lastr couple of days only i decided to ask query. Still
> > > i have some Q's in my mind. These are as below:
> > > 1. Is 64xx series latest as compared to 67xx?
> >
> > Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in 2005. Currently TI's fastest available device
> > is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.
> >
> > > 2. How much approx. cost of 6413 dsp board will? i don't know weather it is or not available in my college so
> > > i have to check that.
> >
> > I think 6416 DSK is same cost as others, or close to it -- about USD 400.
> >
> > > 3. For Integer DCT implementation fixed point is best processor to use i guess is that right? and i think 64xx
> > > seris is fixed point dsp series...?
> >
> > Yes. 16x16 multipliers, 32-bit accumulators.
> >
> > > 4. I agree that 67xx based implementaion will not be an efficient method. But will it worth some value at least
> > > entry level work exp. as i am doing my final year project and not a professional work , so if no 6416 is available i
> > > mean to say...
> >
> > As I mentioned, for academic implementation one sub-block of H.264 algorithm, 6713 should be Ok assuming the main
> > point is to obtain DSP learning and experience. I would add that after graduation during your job search, it would
> > look better if you had done image processing work using 641x.
> >
> > -Jeff
> >
> > > Jeff Brower wrote: Nilesh-
> > >
> > >> I am currently working on H.264 feature Integer DCT. I am modifying code
> > >> and want to implement this feature on 6713. I want to know that weather it
> > >> will be possible to do so?
> > >> Actually initially I was using setup for dm642 ccs. But since it is not
> > >> available in my college I decided to go for 6713. I am new to this and want
> > >> to know will it be possible. I just want to put integer dct implementation on 6713.
> > >> Any valuable suggation plz
> > >
> > > Suggest to look over recent C6x group discussion on subject "Using C6713 for image
> > > processing". Here is the thread:
> > >
> > > http://tech.groups.yahoo.com/group/c6x/message/8112
> > >
> > > For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
> > > algorithms it's going to a lot slower than DM642. You might try to locate a DSK
> > > 6416, which is low-cost and your Univ/college should have available.
> > >
> > > -Jeff

---------------------------------
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. Start a New Thread

Nilesh-

> By JTAG u means to say emulator , right? If yes I have ext. emulator option
> on dsk 6713. And if emulator becomes unavailable then is there any other way
> to communicate with host? I mean usb or other.

Yes I'm using term 'JTAG' interchangeably with emulator. But with DSK 6713, keep in
mind that you don't need a separate emulator unit (such as Spectrum Digital XDS510),
because CCS supports emulation over the USB port connection. This is a feature that
TI builds into CCS for DSK boards, but third-party boards typically don't have (which
is why most 3p boards require the external emulator to use CCS debug functions).

> In my case do I need to make 2 ccs projects? One for host and other for dsk.
> Or one program will suffice? Also what about memory mapping of project
> running on ccs should it be hypothetical then?

Just one CCS project. Your DSP code can perform host file I/O, but it's slow and you
have to be careful with it.

> Can I use vc++ to communicate with dsk? And will it be easy as compared to
> ccs? I hope not. What is your say?

Well that's a good question. For DSK 6711, TI offers a DLL that can be used to allow
Visual Studio C/C++ programs to communicate via the HPI. It works but has some
reliability issues. But for DSK 6713, the HPI is left unconnected, and all
communication goes through the USB + JTAG connection. EducationalDSP makes a small
daughtercard that you can add to the DSK 6713 and connect HPI to Visual Studio
programs (http://www.educationaldsp.com/stockproduct_dsk6xxxhpi.htm).

-Jeff

> Jeff Brower wrote: Nilesh-
>
> > As I said last mail that we do not have 64xx series dsp's available in our
> > college I have no other option but to use 6713 dsp for implementing integer
> > dct. Here I have some queries as below:
> >
> >
> > Now if I want real time implementation of H.264 decoder on TI with just
> > integer dct on 6713 implemented, it means that I have to use file I\O's.
> > Is this facility available on 6713?
>
> Yes, available via CCS + JTAG, independent of DSP type.
>
> > I want to write residual dct coeff. data in dsp memory and get its dct and
> > again exchange idct o\p residual data with host pc through dsp memory,
> > which will then continue with rest of decoding. Will this be a simple
> > routine?
>
> The code for host file I/O is relatively simple but transfer rates are not fast.
>
> > Can I use interrupts for this real time exchange of dct? Which will be
> > better and less time to design.
> >
> > What type of synchronization will I have to use between host and dsp?
> > Assuming that I will use some flag in memory that will be polled by dsp
> > and host to start processing dct coeff. And idct residuals'
> > respectively. That is this is a sequential process for each frame or
> > macroblock even.
>
> For questions about host data transfer using CCS + JTAG, you should first study TI
> docs about "RTDX". You should not be setting up your own low-level interrupts and
> semaphores. The exception would be if you are using HPI, which you won't be doing on
> DSK 6713.
>
> > I initially do not mind how slow I have to keep my frame rate or
> > processed by host pc I want to display decoded bitstream in original yuv
> > format on my host while processing is being done, will this work?
>
> Should be possible, but image update rate will be slow.
>
> > What kind of difference is between 6711 and 6713? Is they are compatible
> > for code and h\w, memory mapping point of view?
>
> For your application, main differences are speed (6713 is twice as fast) and amount
> of onchip SRAM (6713 has 4x amount).
>
> -Jeff
>
> > Jeff Brower wrote: Nilesh-
> >
> > > Thanx for quick reply. In fact after reading all resopnses in lastr couple of days only i decided to ask query. Still
> > > i have some Q's in my mind. These are as below:
> > > 1. Is 64xx series latest as compared to 67xx?
> >
> > Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in 2005. Currently TI's fastest available device
> > is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.
> >
> > > 2. How much approx. cost of 6413 dsp board will? i don't know weather it is or not available in my college so
> > > i have to check that.
> >
> > I think 6416 DSK is same cost as others, or close to it -- about USD 400.
> >
> > > 3. For Integer DCT implementation fixed point is best processor to use i guess is that right? and i think 64xx
> > > seris is fixed point dsp series...?
> >
> > Yes. 16x16 multipliers, 32-bit accumulators.
> >
> > > 4. I agree that 67xx based implementaion will not be an efficient method. But will it worth some value at least
> > > entry level work exp. as i am doing my final year project and not a professional work , so if no 6416 is available i
> > > mean to say...
> >
> > As I mentioned, for academic implementation one sub-block of H.264 algorithm, 6713 should be Ok assuming the main
> > point is to obtain DSP learning and experience. I would add that after graduation during your job search, it would
> > look better if you had done image processing work using 641x.
> >
> > -Jeff
> >
> > > Jeff Brower wrote: Nilesh-
> > >
> > >> I am currently working on H.264 feature Integer DCT. I am modifying code
> > >> and want to implement this feature on 6713. I want to know that weather it
> > >> will be possible to do so?
> > >> Actually initially I was using setup for dm642 ccs. But since it is not
> > >> available in my college I decided to go for 6713. I am new to this and want
> > >> to know will it be possible. I just want to put integer dct implementation on 6713.
> > >> Any valuable suggation plz
> > >
> > > Suggest to look over recent C6x group discussion on subject "Using C6713 for image
> > > processing". Here is the thread:
> > >
> > > http://tech.groups.yahoo.com/group/c6x/message/8112
> > >
> > > For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
> > > algorithms it's going to a lot slower than DM642. You might try to locate a DSK
> > > 6416, which is low-cost and your Univ/college should have available.
> > >
> > > -Jeff Start a New Thread

Nilesh-

> ## Do u means to say that I can use embedded JTAG emulator
> with just usb cable to pc and from CCS?

Yes.

> What configuration setting I have to make for communication
> through this then?

The version of CCS that comes with DSK boards handles this automatically.

> ## If I need to use one CCS project then :
> My small portion of code i.e. integer dct is going to be on
> DSP 6713 so I need to download that part to 6713. So I was
> thinking to make 2 CCS project separately.
> But if I can have this from one CCS project also possible then
> can u please explain me, how can I differentiate between part
> to be downloaded on target and remaining part that will be
> running on host through CCS. Do I need to have different
> sectional mapping to be used?

I can understand why you would ask this, but you're thinking of the "tree" instead of
the "forest". Here are the main possibilities for host-side software:

-CCS only. Edit/compile/build/link code, debug functions,
waveform and data display functions, file I/O

-Simulink/MATLAB + CCS. Block diagrams with one or more
blocks that run on the DSP. Simulink uses CCS for DSP
code download and communication

-Visual Studio + HPI DLL. C/C++ code that talks to DSK
board (See previous post for notes)

Hopefully this explains why you don't need more than one CCS project. The main thing
you are missing is that CCS is both a GUI for code development (compile code) and
also contains debug, I/O, and other target (board) communication functions. I
suppose this is why TI calls it an IDE -- integrated development environment.

> ## Also I am getting following kind of errors while linking on CCS 6713:
> [Linking...] "C:\CCStudio_v3.1\C6000\cgtools\bin\cl6x" -@"Debug.lkf"

Linking errors are basic and you should be able to figure out on your own by studying
TI's example projects. As just a brief suggestion, I might guess that you don't have
b_frame listed in your .cmd (linker command) file.

-Jeff
>
> undefinedfirst referenced
> symbolin file
> -------------------------
> _mrefD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_refD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_tmpD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _P_intervalD:\a_nilesh\code comp sudio Projects\10 Jan
> deco\TryDec\Debug\b_frame.obj
> _ftimeD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _prevP_trD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _p_traceD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUVD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_tmpD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _tot_timeD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _frame_noD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_pfD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _fbD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _allocaD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _p_refD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_prevD:\a_nilesh\code comp sudio Projects\10 Jan
> deco\TryDec\Debug\b_frame.obj
> _nal_startcode_followsD:\a_nilesh\code comp sudio Projects\10 Jan
> deco\TryDec\Debug\b_frame.obj
> _p_outD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _Bframe_ctrD:\a_nilesh\code comp sudio Projects\10 Jan
> deco\TryDec\Debug\b_frame.obj
> _imgY_prevD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _nextP_trD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _mcefD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_pfD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _errortextD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _refFrArrD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_refD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgYD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> >>error: symbol referencing errors - './Debug/TryDec.out' not built
> >> Compilation failure
> Build Complete,
> 2 Errors, 153 Warnings, 0 Remarks.
> What can be reason? I have included .h file containing definition of global symbols
> as extern everywhere in .c file where errors are being reported.
>
> Best Regards,
> Nilesh
> Jeff Brower wrote:
>
> Nilesh-
>
> > By JTAG u means to say emulator , right? If yes I have ext. emulator
> option
> > on dsk 6713. And if emulator becomes unavailable then is there any
> other way
> > to communicate with host? I mean usb or other.
>
> Yes I'm using term 'JTAG' interchangeably with emulator. But with DSK
> 6713, keep in
> mind that you don't need a separate emulator unit (such as Spectrum
> Digital XDS510),
> because CCS supports emulation over the USB port connection. This is a
> feature that
> TI builds into CCS for DSK boards, but third-party boards typically don't
> have (which
> is why most 3p boards require the external emulator to use CCS debug
> functions).
>
> > In my case do I need to make 2 ccs projects? One for host and other for
> dsk.
> > Or one program will suffice? Also what about memory mapping of project
> > running on ccs should it be hypothetical then?
>
> Just one CCS project. Your DSP code can perform host file I/O, but it's
> slow and you
> have to be careful with it.
>
> > Can I use vc++ to communicate with dsk? And will it be easy as compared
> to
> > ccs? I hope not. What is your say?
>
> Well that's a good question. For DSK 6711, TI offers a DLL that can be
> used to allow
> Visual Studio C/C++ programs to communicate via the HPI. It works but has
> some
> reliability issues. But for DSK 6713, the HPI is left unconnected, and
> all
> communication goes through the USB + JTAG connection. EducationalDSP
> makes a small
> daughtercard that you can add to the DSK 6713 and connect HPI to Visual
> Studio
> programs (http://www.educationaldsp.com/stockproduct_dsk6xxxhpi.htm).
>
> -Jeff
>
> > Jeff Brower wrote: Nilesh-
> >
> > > As I said last mail that we do not have 64xx series dsp's available
> in our
> > > college I have no other option but to use 6713 dsp for implementing
> integer
> > > dct. Here I have some queries as below:
> > >
> > >
> > > Now if I want real time implementation of H.264 decoder on TI with
> just
> > > integer dct on 6713 implemented, it means that I have to use file
> I\O's.
> > > Is this facility available on 6713?
> >
> > Yes, available via CCS + JTAG, independent of DSP type.
> >
> > > I want to write residual dct coeff. data in dsp memory and get its
> dct and
> > > again exchange idct o\p residual data with host pc through dsp
> memory,
> > > which will then continue with rest of decoding. Will this be a simple
>
> > > routine?
> >
> > The code for host file I/O is relatively simple but transfer rates are
> not fast.
> >
> > > Can I use interrupts for this real time exchange of dct? Which will
> be
> > > better and less time to design.
> > >
> > > What type of synchronization will I have to use between host and dsp?
>
> > > Assuming that I will use some flag in memory that will be polled by
> dsp
> > > and host to start processing dct coeff. And idct residuals'
> > > respectively. That is this is a sequential process for each frame or
> > > macroblock even.
> >
> > For questions about host data transfer using CCS + JTAG, you should
> first study TI
> > docs about "RTDX". You should not be setting up your own low-level
> interrupts and
> > semaphores. The exception would be if you are using HPI, which you
> won't be doing on
> > DSK 6713.
> >
> > > I initially do not mind how slow I have to keep my frame rate or
> > > processed by host pc I want to display decoded bitstream in original
> yuv
> > > format on my host while processing is being done, will this work?
> >
> > Should be possible, but image update rate will be slow.
> >
> > > What kind of difference is between 6711 and 6713? Is they are
> compatible
> > > for code and h\w, memory mapping point of view?
> >
> > For your application, main differences are speed (6713 is twice as
> fast) and amount
> > of onchip SRAM (6713 has 4x amount).
> >
> > -Jeff
> >
> > > Jeff Brower wrote: Nilesh-
> > >
> > > > Thanx for quick reply. In fact after reading all resopnses in lastr
> couple of days only i decided to ask query. Still
> > > > i have some Q's in my mind. These are as below:
> > > > 1. Is 64xx series latest as compared to 67xx?
> > >
> > > Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in
> 2005. Currently TI's fastest available device
> > > is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.
> > >
> > > > 2. How much approx. cost of 6413 dsp board will? i don't know
> weather it is or not available in my college so
> > > > i have to check that.
> > >
> > > I think 6416 DSK is same cost as others, or close to it -- about USD
> 400.
> > >
> > > > 3. For Integer DCT implementation fixed point is best processor to
> use i guess is that right? and i think 64xx
> > > > seris is fixed point dsp series...?
> > >
> > > Yes. 16x16 multipliers, 32-bit accumulators.
> > >
> > > > 4. I agree that 67xx based implementaion will not be an efficient
> method. But will it worth some value at least
> > > > entry level work exp. as i am doing my final year project and not a
> professional work , so if no 6416 is available i
> > > > mean to say...
> > >
> > > As I mentioned, for academic implementation one sub-block of H.264
> algorithm, 6713 should be Ok assuming the main
> > > point is to obtain DSP learning and experience. I would add that
> after graduation during your job search, it would
> > > look better if you had done image processing work using 641x.
> > >
> > > -Jeff
> > >
> > > > Jeff Brower wrote: Nilesh-
> > > >
> > > >> I am currently working on H.264 feature Integer DCT. I am
> modifying code
> > > >> and want to implement this feature on 6713. I want to know that
> weather it
> > > >> will be possible to do so?
> > > >> Actually initially I was using setup for dm642 ccs. But since it
> is not
> > > >> available in my college I decided to go for 6713. I am new to this
> and want
> > > >> to know will it be possible. I just want to put integer dct
> implementation on 6713.
> > > >> Any valuable suggation plz
> > > >
> > > > Suggest to look over recent C6x group discussion on subject "Using
> C6713 for image
> > > > processing". Here is the thread:
> > > >
> > > > http://tech.groups.yahoo.com/group/c6x/message/8112
> > > >
> > > > For a specific sub-block of H.264, using 6713 might be Ok, but for
> fixed-point based
> > > > algorithms it's going to a lot slower than DM642. You might try to
> locate a DSK
> > > > 6416, which is low-cost and your Univ/college should have
> available.
> > > >
> > > > -Jeff
> Start a New Thread

Nilesh-

> I have tried all possible ways to tackle this undefined symbol problem. I have noticed few things that are strange
> for me. For e.g. my .bss section in mapping file have length of 0. This is for decoder code ==>

Somehow, you're making this way too hard. Linking is hardly the thing that should cause a many-day problem.

Who makes file "b_frame.c" -- you? Or you get this from a third-party?

-Jeff

> .bss 0 00000000 00000000 UNINITIALIZED
>
> while for my succesfull encoder it shows this as ==> .bss 0 00005da0 00000158 UNINITIALIZED
> 00005da0 00000158 b_frame.obj (.bss)
>
> Also similar to following Lines are there for each undefined symbol e.g.
>
> DW$60 .dwtag DW_TAG_variable, DW_AT_name("imgUV"), DW_AT_symbol_name("_imgUV")
> .dwattr DW$60, DW_AT_type(*DW$T$131)
> .dwattr DW$60, DW_AT_declaration(0x01)
> .dwattr DW$60, DW_AT_external(0x01)
> ****************************************************************
>
> .global _imgUV
> .bss _imgUV,4,4
> DW$42 .dwtag DW_TAG_variable, DW_AT_name("imgUV"), DW_AT_symbol_name("_imgUV")
> .dwattr DW$42, DW_AT_location[DW_OP_addr _imgUV]
> .dwattr DW$42, DW_AT_type(*DW$T$145)
> .dwattr DW$42, DW_AT_external(0x01)
> Now second code in mapping file has .global directive with it in comparison with first. And second is from mapping
> file of encoder which is working ok. While first code was from mapping file of decoder giving linking error. So
> though symbol is defined it is not globally defined. Which I think is definitely wrong.
>
> Also for your information I have som definition in my main file asbr /> > #define GLOBAL_VARS
> And global.h file that is included everywhere as br /> > #ifdef GLOBAL_VARS
> #define EXTERN_GLOBAL
> #else
> #define EXTERN_GLOBAL extern
> #endif
> And I have used symbol before all global variable in global.h file as XTERN_GLOBAL I tested all code on vc++ and it is working fine. But am not able to figure out why undefined symbol error is there.
> Also my .cmd file is OK as below=>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
>
> MEMORY
> {
> L2SRAM: origin = 0x00000000 length = 00008000h
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> CE1: origin = 0x90000000 length = 0x3FFFFFF
> CE2: origin = 0xA0000000 length = 0x3FFFFFF
> CE3: origin = 0xB0000000 length = 0x3FFFFFF
> }
>
> SECTIONS
> {
> /* .sysmem > CEO
> .stack > CEO*/
> .sysmem: {*(.sysmem) } > CEO | CE1 | CE2 | CE3
> .stack: {*(.stack) } > CEO | CE1 | CE2 | CE3
>
> .cinit > L2SRAM
> .bss: { /*b_frame.obj (.bss)*/
> *(.bss) } > L2SRAM
> .const > L2SRAM
> .cio > L2SRAM
> .switch > L2SRAM
> .data > L2SRAM
> .tables > L2SRAM
>
> .far > CE0
> .external > CE0
> .text > CE0
> }
>
> I need kindly your suggestions
> Regards,
> Nilesh
>
> Jeff Brower wrote:
> Nilesh- > ## Do u means to say that I can use embedded JTAG emulator
>> with just usb cable to pc and from CCS? Yes. > What configuration setting I have to make for communication
>> through this then? The version of CCS that comes with DSK boards handles this automatically. > ## If I need to
>> use one CCS project then :
>> My small portion of code i.e. integer dct is going to be on
>> DSP 6713 so I need to download that part to 6713. So I was
>> thinking to make 2 CCS project separately.
>> But if I can have this from one CCS project also possible then
>> can u please explain me, how can I differentiate between part
>> to be downloaded on target and remaining part that will be
>> running on host through CCS. Do I need to have different
>> sectional mapping to be used? I can understand why you would ask this, but you're thinking of the "tree" instead
>> of the "forest". Here are the main possibilities for host-side software: -CCS only. Edit/compile/build/link
>> code, debug functions,
> waveform and data display functions, file I/O -Simulink/MATLAB + CCS. Block diagrams with one or more
> blocks that run on the DSP. Simulink uses CCS for DSP
> code download and communication -Visual Studio + HPI DLL. C/C++ code that talks to DSK
> board (See previous post for notes) Hopefully this explains why you don't need more than one CCS project. The
> main thing you are missing is that CCS is both a GUI for code development (compile code) and also contains debug,
> I/O, and other target (board) communication functions. I suppose this is why TI calls it an IDE -- integrated
> development environment. > ## Also I am getting following kind of errors while linking on CCS 6713:
>> [Linking...] "C:\CCStudio_v3.1\C6000\cgtools\bin\cl6x" -@"Debug.lkf" Linking errors are basic and you should be
>> able to figure out on your own by studying TI's example projects. As just a brief suggestion, I might guess that
>> you don't have b_frame listed in your .cmd (linker command) file. -Jeff
>
> undefinedfirst referenced
> symbolin file
> -------------------------
> _mrefD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_refD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_tmpD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _P_intervalD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _ftimeD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _prevP_trD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _p_traceD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUVD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_tmpD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _tot_timeD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _frame_noD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_pfD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _fbD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _allocaD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _p_refD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_prevD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _nal_startcode_followsD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _p_outD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _Bframe_ctrD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgY_prevD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _nextP_trD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _mcefD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_pfD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _errortextD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _refFrArrD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgUV_refD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> _imgYD:\a_nilesh\code comp sudio Projects\10 Jan deco\TryDec\Debug\b_frame.obj
> >>error: symbol referencing errors - './Debug/TryDec.out' not built
> >> Compilation failure
> Build Complete,
> 2 Errors, 153 Warnings, 0 Remarks.
> What can be reason? I have included .h file containing definition of global symbols as extern everywhere in .c file
> where errors are being reported.
>
> Best Regards,
> Nilesh
> Jeff Brower wrote: Nilesh- > By JTAG u means to say emulator , right? If yes I have ext.
> emulator option
>> on dsk 6713. And if emulator becomes unavailable then is there any other way
>> to communicate with host? I mean usb or other. Yes I'm using term 'JTAG' interchangeably with emulator. But with
>> DSK 6713, keep in
> mind that you don't need a separate emulator unit (such as Spectrum Digital XDS510),
> because CCS supports emulation over the USB port connection. This is a feature that
> TI builds into CCS for DSK boards, but third-party boards typically don't have (which
> is why most 3p boards require the external emulator to use CCS debug functions). > In my case do I need to make 2
> ccs projects? One for host and other for dsk.
>> Or one program will suffice? Also what about memory mapping of project
>> running on ccs should it be hypothetical then? Just one CCS project. Your DSP code can perform host file I/O, but
>> it's slow and you
> have to be careful with it. > Can I use vc++ to communicate with dsk? And will it be easy as compared to
>> ccs? I hope not. What is your say? Well that's a good question. For DSK 6711, TI offers a DLL that can be used to
>> allow
> Visual Studio C/C++ programs to communicate via the HPI. It works but has some
> reliability issues. But for DSK 6713, the HPI is left unconnected, and all
> communication goes through the USB + JTAG connection. EducationalDSP makes a small
> daughtercard that you can add to the DSK 6713 and connect HPI to Visual Studio
> programs (http://www.educationaldsp.com/stockproduct_dsk6xxxhpi.htm). -Jeff > Jeff Brower wrote: Nilesh-
>>
>> > As I said last mail that we do not have 64xx series dsp's available in our
>> > college I have no other option but to use 6713 dsp for implementing integer
>> > dct. Here I have some queries as below:
>> >
>> >
>> > Now if I want real time implementation of H.264 decoder on TI with just
>> > integer dct on 6713 implemented, it means that I have to use file I\O's.
>> > Is this facility available on 6713?
>>
>> Yes, available via CCS + JTAG, independent of DSP type.
>>
>> > I want to write residual dct coeff. data in dsp memory and get its dct and
>> > again exchange idct o\p residual data with host pc through dsp memory,
>> > which will then continue with rest of decoding. Will this be a simple
>> > routine?
>>
>> The code for host file I/O is relatively simple but transfer rates are not fast.
>>
>> > Can I use interrupts for this real time exchange of dct? Which will be
>> > better and less time to design.
>> >
>> > What type of synchronization will I have to use between host and dsp?
>> > Assuming that I will use some flag in memory that will be polled by dsp
>> > and host to start processing dct coeff. And idct residuals'
>> > respectively. That is this is a sequential process for each frame or
>> > macroblock even.
>>
>> For questions about host data transfer using CCS + JTAG, you should first study TI
>> docs about "RTDX". You should not be setting up your own low-level interrupts and
>> semaphores. The exception would be if you are using HPI, which you won't be doing on
>> DSK 6713.
>>
>> > I initially do not mind how slow I have to keep my frame rate or
>> > processed by host pc I want to display decoded bitstream in original yuv
>> > format on my host while processing is being done, will this work?
>>
>> Should be possible, but image update rate will be slow.
>>
>> > What kind of difference is between 6711 and 6713? Is they are compatible
>> > for code and h\w, memory mapping point of view?
>>
>> For your application, main differences are speed (6713 is twice as fast) and amount
>> of onchip SRAM (6713 has 4x amount).
>>
>> -Jeff
>>
>> > Jeff Brower wrote: Nilesh-
>> >
>> > > Thanx for quick reply. In fact after reading all resopnses in lastr couple of days only i decided to ask query.
>> Still
>> > > i have some Q's in my mind. These are as below:
>> > > 1. Is 64xx series latest as compared to 67xx?
>> >
>> > Yes. 300 MHz 6713 came out about 2003. 1 GHz 6416T device came out in 2005. Currently TI's fastest available
>> device
>> > is 6455, also 1 GHz but with 2x speed 64x+ core, released in 2006.
>> >
>> > > 2. How much approx. cost of 6413 dsp board will? i don't know weather it is or not available in my college so
>> > > i have to check that.
>> >
>> > I think 6416 DSK is same cost as others, or close to it -- about USD 400.
>> >
>> > > 3. For Integer DCT implementation fixed point is best processor to use i guess is that right? and i think 64xx
>> > > seris is fixed point dsp series...?
>> >
>> > Yes. 16x16 multipliers, 32-bit accumulators.
>> >
>> > > 4. I agree that 67xx based implementaion will not be an efficient method. But will it worth some value at least
>> > > entry level work exp. as i am doing my final year project and not a professional work , so if no 6416 is
>> available i
>> > > mean to say...
>> >
>> > As I mentioned, for academic implementation one sub-block of H.264 algorithm, 6713 should be Ok assuming the main
>> > point is to obtain DSP learning and experience. I would add that after graduation during your job search, it would
>> > look better if you had done image processing work using 641x.
>> >
>> > -Jeff
>> >
>> > > Jeff Brower wrote: Nilesh-
>> > >
>> > >> I am currently working on H.264 feature Integer DCT. I am modifying code
>> > >> and want to implement this feature on 6713. I want to know that weather it
>> > >> will be possible to do so?
>> > >> Actually initially I was using setup for dm642 ccs. But since it is not
>> > >> available in my college I decided to go for 6713. I am new to this and want
>> > >> to know will it be possible. I just want to put integer dct implementation on 6713.
>> > >> Any valuable suggation plz
>> > >
>> > > Suggest to look over recent C6x group discussion on subject "Using C6713 for image
>> > > processing". Here is the thread:
>> > >
>> > > http://tech.groups.yahoo.com/group/c6x/message/8112
>> > >
>> > > For a specific sub-block of H.264, using 6713 might be Ok, but for fixed-point based
>> > > algorithms it's going to a lot slower than DM642. You might try to locate a DSK
>> > > 6416, which is low-cost and your Univ/college should have available.
>> > >
>> > > -Jeff Start a New Thread