Performance and Flash Pipelining on TI 28F12 DSPs

We are developing an embedded controller based on a TI 28F12.
This new product consists of single board replacing an older system
containing 8 (different) boards, each one running code on an Intel
80196 16-bit microcontroller.

The software (painstakingly translated from '196 assembler into C &
C++) is typical microcontroller stuff, as opposed to DSP stuff (No FIR
filters, FFT's PID loops, no need for vector/MAC instructions, etc.)

In short, we are using the 2812 as a fast general purpose
microcontroller, with plenty of on-chip memory and peripherals.
The CPU was selected before I joined the project, based on the
assumption it will be fast enough to do the job of the 8-gang 80196s.

The question now is, how fast the CPU really is? We are about to start
writing some benchmarking code, but we do not have enough of the code
that will be running in the final application to get the full picture.

The software structure does not allow us to follow the classical
approach of running time critical loops from internal RAM instead of
Flash.
Due to the functions implemented and the fact that we are running the
equivalent of 4 different older products (the 8 controllers we are
replacing were not identical) there isn't a small well defined segment
of "critical code" we could move to RAM.

So, my question to the group: What kind of degradation from the
theoretical figure of 150 MIPS can we expect running code that does
not take advantage of the special DSP instructions and running only
from internal flash?

We will be accessing both onboard and outboard peripherals and need to
service several periodic interrupt sources, the fastest being 500 (1
source) and 125 (2 sources) microsecond rates.

Also, how big an impact has the "Flash Pipeling" ? Without it the
effective instruction execution rate is around 25Mhz, which puts us in
the same ballpark as the aggregated performance of the original
system, and probably will not meet our goals because the SW is now in
C instead of assembler, and some new functionality was added.

Does anybody have a reference point from a similar scenario?

Thanks,


Roberto Waltman

[ Please reply to the group, ]
[ return address is invalid. ]
.