Re: performance of the MPC55XX compared to a TI67XX

Thanks to George and Julian,

We do not run with an OS, and are required to have three "dissimilar" 
dsps in our design.  Also we've been runing out of room with the TI 
chips since we like to run out of internal ram for most of our 
processing.  It seems to me that our real answer is to bring our good 
candidate DSPs in house and test them out hands on.

Thanks again for your input.

Todd

--- In [email protected], "Calvas, George \(G.\)" <GCALVAS@...> 
wrote:
>
> Below is some excellent advice and recommend it.  I have come to 
some of
> the same conclusions from the processor perspective, though there 
are
> other considerations when you add the system design aspects of your
> project.  Just one additional comment, understand your task rate
> scheduler requirements using that as your benchmark to assure your 
task
> executions will complete in time.  Also, you must take into account 
the
> budget, the bringing up (if you ever used them, you will 
understand!)
> and timing of learning and using new tools (os, compilers, 
debuggers,
> calibration, testing).  Processor subcore engines such as TPUs, when
> designed efficiently, are excellent I/O processors, especially for 
real
> time signal processing control.
>  
> 
> George Calvas 
> R&A PT Controls Engineer 
> CAE Tools & Methods Dept. 
> POEE Bldg.   MD76   Cube AY159 
> Phone#: 313 322.9040 
> 
>  
> 
> ________________________________
> 
> From: [email protected] [mailto:[email protected]] On 
Behalf
> Of Julian Requejo
> Sent: Wednesday, January 17, 2007 4:30 AM
> To: [email protected]
> Subject: Re: [MPC500] performance of the MPC55XX compared to a 
TI67XX
> 
> 
> 
> Dear Todd,
> 
> Your question is a quite different to answer.
> 
> > The topic of MHz vs MFLOPs vs MMACs and RISC vs CISC is confusing 
> > enough and I couldn't find anything specific to the subject on 
the 
> > freescale website.
> 
> Unfortunately this are important questions. As you might know, RISC
> processors execute quickly but "simple" instructions, while CISC
> processors execute more complex instructions but might take longer 
to do
> so. Caches play an important role in performance so this can't be
> ignored either. I think the TI family you mention is VLIW, which 
means
> that it's a pain (i.e. almost impossible) to program in assembly 
should
> you need to, but hopefully this is not an issue. TI measures this in
> MMACS, exactly for this reason: because for VLIW processors, they 
can
> "cheat" with the benchmarks more. In practice, you can't never fully
> utilize the whole pipeline of VLIW processors so that is purely
> theoretical. Floating point is another important (maybe deciding 
factor)
> to consider. Some CPUs support no floating point, others single 
point
> only (MPC5554), others double precission. If your applications 
requires
> double precission, I *highly* recommend you to choose a double prec!
> ission CPU, whatever you choose. For avionics and hard real-time
> applications I recommend you getting a CPU without cache or 
disabling it
> altogether since this could lead in unexpected run-time issues
> (unpredicable missed deadlines)
> 
> The reason why the MPC family is taylored torwards automotive is 
because
> of the TPU (this is something that allows you to control simple 
actions
> that require very precise timing, like engine in control and it is 
done
> with a subcore of the MPC), and lots of I/O.
> 
> TI family of DSP as taylored for digital signal processing 
applications.
> My rough advice is that if you are doing DSP apps and have 
experience
> with TI, then stick to TI. If you need more I/O, consider the MPC
> family.
> 
> So my advice is to first make a list of requirements
> - Math precision
> - Type of application
> - Operating system support
> - Budget (should you need new compilers, OS)
> 
> And then choose a processor family. Sorry if I didn't answer your
> question, but it is not an easy one. Benchmarking is a very fuzzy 
thing.
> You could buy cheap evaluation boards and if you are running rapid
> prototyping systems (i.e. Matlab embedded coder, dSpace TargetLink, 
etc)
> you test them with minimal effort). These tools usually offer run-
time
> analysis capabilities as well.
> 
> Reagards,
> -Julian
> 
> 
>  
> 
> 
> [Non-text portions of this message have been removed]
>