How can I get the current DSP frequency of DM8168?

Hi Wang,

your quickest option is to run "cat /proc/cpuinfo". I get 986.31 BogoMIPS on my DM8168 rev E evaluation board.

Regards,

Ralph

Of course, "cat /proc/cpuinfo" deliveres only the ARM frequency. To get that for the DSP side I assume you will have to write a little test program for that to compare the clock rate with a real time clock.

Besides, the universal_copy was extremely slow for me when compiled with EZSDK 5.00.00.56, since I use the current EZSDK 5.01.01.88 (from here) it is somewhat faster. But I think it's speed does not too much depend on the DSP's frequency, the hardest bottleneck will be to get the data from and to RAM.

Regards,
Joern.

_Ralph_ said:

your quickest option is to run "cat /proc/cpuinfo". I get 986.31 BogoMIPS on my DM8168 rev E evaluation board.

Thank you Ralph, I also got 986.31 on rev C, but in the datasheet of DM8168, it says the ARM core is up to 1.2 GHz, and DSP is up to 1.0GHz,

is it mean we can change the frequency of ARM and DSP to make it faster? If so, how? 

Regards,

Wang

Thank you Joern.

Joern said:

To get that for the DSP side I assume you will have to write a little test program for that to compare the clock rate with a real time clock.

I am sorry, I'm not quite sure about this. Do you mean I have to write a clock program, and compare the clock rate with a real clock such as a stopwatch?

But how can I get DSP frequency by this?

Sorry I am a new guy in Davinci, and not quite familiar with DSP clock. I think I should follow the "Timing Services" Section in SYS/BIOS user's guide to write the DSP clock program, right? 

If there is a example about DSP clock, it will be greatly appreciated.

Joern said:

Besides, the universal_copy was extremely slow for me when compiled with EZSDK 5.00.00.56, since I use the current EZSDK 5.01.01.88 (from here) it is somewhat faster.

I just insert my algos into universal_copy example in EZSDK 5.00.00.56. I will try it in EZSDK 5.01.01.88. Thank you.

Joern said:

But I think it's speed does not too much depend on the DSP's frequency, the hardest bottleneck will be to get the data from and to RAM.

Yes, but my algos is a little big. I have tested it on DSP side under CCS, I calculate to speed using Run-->Clock tools in CCS. It really cost too many cycles.

So I think I should optimize my code and enhance the DSP working frequency.

Any advises will be greatly appreciated.

Regards,

Wang 

First I have to correct myself - to prevent that you will search for a non-existing version of EZSDK: when I wrote about EZSDK 5.01.01.88 it was a typo, of course I meant EZSDK 5.01.01.80 (from 01 June 2011).

song said:

So I think I should optimize my code and enhance the DSP working frequency.

Concerning optimization these documents might deliver some first impressions on how to do:

• TMS320C6000 Optimizing Compiler User's Guide
• Hand-Tuning Loops and Control Code on the TMS320C6000
• Advanced Linker Techniques for Convenient and Efficient Memory Usage

Additionally, to get some first ideas, maybe these slides are somewhat valuable, although concerning the older C64+:

• C64/C64+ Compiler Optimization Tricks

And last not least concerning your question:

song said:

I think I should follow the "Timing Services" Section in SYS/BIOS user's guide to write the DSP clock program, right? 

This document I didn't found until now, Thanks, I will work through this within the next time.

There are lots of TI documents being actually helpful, but unfortunately there is no complete and detailed overview. But if you've found one, and if it's relatively current, then always it's a good idea to follow the literature links there. Most documents are named like sprwx3e.pdf - the last letter before the extention .pdf is mostly a revision number. And TI has a mechanism which in much cases deliveres the most current version of those documents, for my virtual example sprwx3e.pdf that would be the URL "www.ti.com/lit/pdf/sprwx3" - this then deliveres maybe sprwx3e.pdf, maybe already sprwx3f.pdf or yet a newer one.. 

As you measure at DSP side and universal_codec was mentioned the RTSC framework obviousy is used, so you might start with Using xdc.runtime Timestamps, additionally this example deliveres some deeper insights.

In your case it should be enough to use the stuff around Timestamp_get64(), which gets (in my opinion) the DSP ticks from the TSCH:TSCL register - the timestamp_getFreq() for me seems not to deliver the actual frequency, but only the frequency assumed concerning the current settings. I measured by something like a real world stopwatch, comparing with a loop waiting for a huge amounts of TSCH:TSCL ticks, by help of some debug outputs... maybe someone has suggestions being more cleverly.

Best regards,
Joern.

Hi Joern,

    Thank you for your detailed explanation.

Joern said:

I think I should follow the "Timing Services" Section in SYS/BIOS user's guide to write the DSP clock program, right? 

This document I didn't found until now, Thanks, I will work through this within the next time.

[/quote]

  I am sorry about this, I mean spruex3i.pdf .

  I will try your method to measure my DSP frequency.

 Also, thanks for the slides about optimization, I will read those later.

 

Regards,

Wang

Is there anything in the Codec Engine to do this? There is "Engine_getCpuLoad" which allows you to get the DSP utilisation. Maybe there is a similar function that will let you see the DSP frequency?

Ralph

song said:

I think I should follow the "Timing Services" Section in SYS/BIOS user's guide to write the DSP clock program, right? 

This document I didn't found until now, Thanks, I will work through this within the next time.

[/quote]

  I am sorry about this, I mean spruex3i.pdf .

[/quote]

No. no - I am sorry for being unclear. Your link to spruex3 was perfect, I just only wanted to say thanks for that link, as it was you that I for the first time took notice of that document. :-)

Yes, I only found that from digging around the old DMAI decode application for the DM6467T. Maybe more digging would yield the CPU speed or some BogoMIPS-type measurement?

Ralph

Hi,

  I am sorry for the late reply.

Joern said:

  I am sorry about this, I mean spruex3i.pdf .

 My english is not so good, this is my fault, Joern.

 I will try to use the function to measure the load of CPU.

 May be it's hard to reconfig the frequency of DSP, right?

Thank you.

Regards,

wang