This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377D: DMIPS calculation

Part Number: TMS320F28377D

Hi,

I am interested to know the DMIPS of the microcontroller "TMS320F28377D"

  • Sharif,


    I'm looking into this to see if we have this number. 

    The Drystone benchmark measures performance of operations that are not very applicable to the types of applications the C2000 devices are typically in.  It may help to for us to understand what specific areas of performance you are concerned about.


    Regards

    Lori

  • I am evaluating about using TMS320F28377D Delfino series.

    I would like to understand the DMIPS of the TMS320F28377D to compute the throughput capability.

    I have requested the information from TI Live chat and Asian support, but not received the same however they informed that it can give 800 MIPS (which is already available on the net.)

    It would be really great if somebody performs Dhyrastone test on the C2000 based MCU. or somehow estimate it if that's not possible.

    If the DMIPS number is not available, I would like to understand if the MIPS count (800 MIPS mentioned in the website) can be considered with some factor (may be 0.5/0.75 etc) so as to represent the practical scenario.
  • Hi Sharif,

    We do not measure the performance of our C2000 MCUs by using Dhrystone benchmarks.  Dhrystone isn't a very helpful gauge for folks doing CPU architecture comparison, especially for computationally intensive real time control on an embedded MCU.  Some concerns are, for example, CPU architects and compilers can be (and have been) designed to score well on Dhrystone but perform poorly in real-life, real-time applications.  Dhrystone only measures a few basic operations.  It does not measure multiply accumulate, floating-point, SIMD or many other types of operations needed in mathematically-intensive algorithms many of which are supported by C compilers today.  

    Also, the benchmark has lost its credibility for modern CPU architectures as it does not have an official certification process. Frankly, if the world thought Dhrystone was still relevant it would have pushed for a certification process long ago.  Another pretty serious flaw is that the disclosure of the benchmarking environment is not required and sometimes when it is you will see special switches for the compiler that are only used during Dhrystone benchmarking and wouldn't otherwise be used in production development.  In short, it's just too out-of-date and too easy to manipulate to be valuable.

    If you look at the '377D and dual C28x and dual CLA cores (4 processing concurrently), each of these cores is capable of executing an instruction per cycle. Those instructions are C28x or CLA instructions which happen to be much more powerful for real time processing than what the Dhrystone benchmark creators in the 1980s could have anticipated at the time.  More importantly, the C2000 C28x and CLA are especially well-built for real time control of power electronics circuits.  The only relevant benchmarking in those cases is performance in the task of controlling power electronics.  If you are building an application like that, then some of our benchmark data is going to be very relevant for you.  For example, the '377 can complete a Park Transform in 19 cycles because of the new Trigonometry instructions added to the core.  This is leveraged in an optimized sensored FOC motor control algorithm that is capable of closing the current loop in 1.5 microseconds - and at high loop control bandwidth as well.  With a '377D you can control two of these fast current loops - on each core and have CPU bandwidth to spare.

    One more point: while flash cell read accesses are slower than RAM accesses, because of how a C2000 is designed, you will see access efficiency on fetches from flash that are very close to RAM access speeds.  This is because of the creative design of our interface wrapper.  As with any pipelined CPU, code discontinuities (branches/exceptions) are going to impact this performance.  So, make sure you understand your C28x native instructions/features, the code the compiler creates and where it locates the data being used if you want to get the most performance out of your system.

  • Hi Brian,

    Can you please tell me how the trigonometric calculations happen inside the TMU?

    I have gone through spruhs1a but it doesnot give any info.

    This is important for me.

    Thanks,
    Sharif.

  • Hello Sharif,

    This thread is closed. Please create a new thread. If there is pertinent information in this post, you can add a link to this post in your new thread.

    Edit:  Opening this thread again to keep information together.

    Best Regards,
    Adam Dunhoft

  • Hi Sharif,

    I don't believe that we share the logical design of the TMU.  Help me understand what your specifically interested in (more than what is in SPRUHS1A) and I'll see what we can share.

  • Brian Fortman said:

    Hi Sharif,

    I don't believe that we share the logical design of the TMU.  Help me understand what your specifically interested in (more than what is in SPRUHS1A) and I'll see what we can share.

    Basically I want to know its accuracy so that when a TMU result is magnified, The error expected is known.

  • Sharif Shaik said:

    Can you please tell me how the trigonometric calculations happen inside the TMU? ... This is important for me.

    TI will not provide such information just because yielding such performance means investing millions and billions of dollars in R&D. TI has many competitors in semiconductor market and these competitors also have R&D but yielding is not so significant compare to C2000 products. Believe or not, they would pay millions $$$ on such information, and not just because of an argument like "This is important for me." For example even multicore Intel Core I7 processor which costs more than 330$ per unit cannot get even close in trigonometric performance (per pipeline cycle).

    This is the reason of protecting R&D intellectual property information from public availability, especially when market competition is not ethical in real situations.

    Regards,

    Alexey

  • Did you not read the further conversation?
    I had asked for its accuracy and that's it. NOT the core implementation behind.
    If you donot have it, please do not to give irrelevant info.

    Thanks
  • Sharif Shaik said:
    Can you please tell me how the trigonometric calculations happen inside the TMU? ... This is important for me.

    Sharif Shaik said:
    I had asked for its accuracy and that's it. NOT the core implementation behind.


    So, you propose that first post wasn't yours? Fine.

    ... is not ethical in real situations.
  • The TMU 32-bit float sine/cosine precision is not less than 100 dB of dynamic range. This info is not for you, but for other readers.
  • The SNR ~ 100 dB, dynamic range ~ 109 dB.
  • Im checking with our design team if they have numbers on this. But a similar question had come up regarding the atan instruction and the response then was

    "It is difficult to define accuracy for floating-point numbers. The typical accuracy for TMU atan function is equivalent to ~ a 23-bit integer resolution. Since the atan covers 1/8th of a circle, you could say that over the range of a full circle (using atan2), you could say that the radian resolution would be equivalent to about 8 * 23 bits ~= 26 bits of angle accuracy. i.e. 360Deg/2^26 = 0.000,0054 degrees"

    For the sine, cosine i could compare the result, for an argument [-1,1], against MATLAB's double precision equivalent to within an error of 10^-7, which is roughly equivalent to 23 bits of accuracy if i were to represent the same number in fixed point (integer) format.
  • Thank you for feedback, Vishal. This should give ~140 dB of dynamic range (RMS). I will spend more time to get such results also.
  • New data: TDH ~128 dB (a little bit more than 21 bit).

  • Alexey Bagaev said:
          

    ...This info is not for you, but for other readers.

    Seriously? :-)
    Stop taking things to heart..