Hi:

Even though I am able to do what I want with the existing 150MHz 
TMS320F2812 digital signal controller (DSC), I am always eager to have 
more speed, since applications that were otherwise inconceivable may 
become possible if more speed becomes available.

Is it likely that there will be further speed advances with this 
architecture?

Most microprocessors running at 100 MHz or greater speeds use cache. The 
C2000 doesn't, but rather has small segments of "SARAM" which can run at 
the full core speed.  The slower flash tops out at effectively about 90 
MIPS.

Even if the flash can't be made faster, wouldn't it be useful to have a 
faster core and faster SARAM able to keep up with the core, even if the 
flash remains at it's present speed limit?

For instance, would folks be interested in a 300MHz device with 16-32k 
of data+code space capable of running no wait states at a full 300MHz, 
where the larger 256-512k flash requires wait states making it only 
effectively 75-90MHz?

This would definitely expand the horizons for my applications, where a 
few interrupt service routines and computations have to be performed 
very fast, while a substantially larger blob of user interface code 
would be satisifed with a few 10s of MHz.

I'm also curious about the relative pros/cons of an architecture using 
cache that can achieve the higher speeds (like 300MHz) vs. a direct 
memory architecture like the C2000.  Would the introduction of 
non-deterministic behavior typical of cache architectures make cache 
undesirable for the types of applications C2000 is geared towards--real 
time SMPS and motor control?  Would that fact be a reason why TI might 
do exactly as I am picturing and advance the speed of the core and 
SARAMs even if the flash remains at its present speed?

Where do you see TI going next with C2000, and is it likely any other 
vendor will produce anything similar?

I took another wander around yesterday for similar DSCs with boatloads 
of peripherals such as the waveform generators, QEP interfaces, etc. 
that the C2000 has, which anything comparable seems to be found only on 
the Freescale DSCs.  But Freescale are 16 bit and very slow compared to 
C2000.  I also looked at Microchip's PIC32 and ST ARM/Cortex.  It seems 
like C2000 towers above anything else in the market, and this has 
remained so for several years.

The F2812 remains, after 4 years, one of the ultimate microcontrollers 
on steroids!

Your input is of interest.



-- 
Good day!

____________________________________
CRC
c...@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

Chris Carlen wrote:
> Hi:
> 
> Even though I am able to do what I want with the existing 150MHz 
> TMS320F2812 digital signal controller (DSC), I am always eager to have 
> more speed, since applications that were otherwise inconceivable may 
> become possible if more speed becomes available.
> 
> Is it likely that there will be further speed advances with this 
> architecture?
> 
> Most microprocessors running at 100 MHz or greater speeds use cache. The 
> C2000 doesn't, but rather has small segments of "SARAM" which can run at 
> the full core speed.  The slower flash tops out at effectively about 90 
> MIPS.
> 
> Even if the flash can't be made faster, wouldn't it be useful to have a 
> faster core and faster SARAM able to keep up with the core, even if the 
> flash remains at it's present speed limit?
> 
> For instance, would folks be interested in a 300MHz device with 16-32k 
> of data+code space capable of running no wait states at a full 300MHz, 
> where the larger 256-512k flash requires wait states making it only 
> effectively 75-90MHz?
> 
> This would definitely expand the horizons for my applications, where a 
> few interrupt service routines and computations have to be performed 
> very fast, while a substantially larger blob of user interface code 
> would be satisifed with a few 10s of MHz.
> 
> I'm also curious about the relative pros/cons of an architecture using 
> cache that can achieve the higher speeds (like 300MHz) vs. a direct 
> memory architecture like the C2000.  Would the introduction of 
> non-deterministic behavior typical of cache architectures make cache 
> undesirable for the types of applications C2000 is geared towards--real 
> time SMPS and motor control?  Would that fact be a reason why TI might 
> do exactly as I am picturing and advance the speed of the core and 
> SARAMs even if the flash remains at its present speed?
> 
> Where do you see TI going next with C2000, and is it likely any other 
> vendor will produce anything similar?
> 
> I took another wander around yesterday for similar DSCs with boatloads 
> of peripherals such as the waveform generators, QEP interfaces, etc. 
> that the C2000 has, which anything comparable seems to be found only on 
> the Freescale DSCs.  But Freescale are 16 bit and very slow compared to 
> C2000.  I also looked at Microchip's PIC32 and ST ARM/Cortex.  It seems 
> like C2000 towers above anything else in the market, and this has 
> remained so for several years.
> 
> The F2812 remains, after 4 years, one of the ultimate microcontrollers 
> on steroids!

Did you look at the ADI BlackFin ? - or some of Infineon's
top-end parts ?

ADi did have FLASH DSC for a brief time, but I think they saw the
'flash-barrier' looming, and went instead to a fast ram based design
in their BlackFin series.(which I think now hits 400-600MHz)

Overall you are right, fast embedded controllers have rather stalled at 
the 'flash-barrier'. Above 100MHz is quite rare, and those that are
(like a couple of ARM9's) use slow flash, and a cache to do so.
(so you will hit the eratic cache issues)

Perhaps the future is Multi-core devices ?

Multiple uC is already quite common.

-jg

Chris Carlen wrote:

> Even though I am able to do what I want with the existing 150MHz 
> TMS320F2812 digital signal controller (DSC), I am always eager to have 
> more speed, since applications that were otherwise inconceivable may 
> become possible if more speed becomes available.

What kind of application do you need the high speed for?

> Is it likely that there will be further speed advances with this 
> architecture?

Unlikely.

> Most microprocessors running at 100 MHz or greater speeds use cache. The 
> C2000 doesn't, but rather has small segments of "SARAM" which can run at 
> the full core speed.  The slower flash tops out at effectively about 90 
> MIPS.

It is actually slower then that; 90 MIPS is the ideal case. The 
realistic figure would be 70...80 MIPS. However the critical code can be 
loaded in SARAM as you noted.

> Even if the flash can't be made faster, wouldn't it be useful to have a 
> faster core and faster SARAM able to keep up with the core, even if the 
> flash remains at it's present speed limit?

This is what L1 memory is for.

> For instance, would folks be interested in a 300MHz device with 16-32k 
> of data+code space capable of running no wait states at a full 300MHz, 
> where the larger 256-512k flash requires wait states making it only 
> effectively 75-90MHz?

This is BlackFin.

> This would definitely expand the horizons for my applications, where a 
> few interrupt service routines and computations have to be performed 
> very fast, while a substantially larger blob of user interface code 
> would be satisifed with a few 10s of MHz.


For the faster CPUs and DSPs, the limiting factor is the bus and the 
peripheral speed rather then the core speed.


> I'm also curious about the relative pros/cons of an architecture using 
> cache that can achieve the higher speeds (like 300MHz) vs. a direct 
> memory architecture like the C2000.  Would the introduction of 
> non-deterministic behavior typical of cache architectures make cache 
> undesirable for the types of applications C2000 is geared towards--real 
> time SMPS and motor control? 

It depends. The question is what speed and what latency do you really need.


> Would that fact be a reason why TI might 
> do exactly as I am picturing and advance the speed of the core and 
> SARAMs even if the flash remains at its present speed?
> 
> Where do you see TI going next with C2000, and is it likely any other 
> vendor will produce anything similar?

TI will probably come up with some sort of click and drag programming 
environment (like LabWiew) which will generate the code for 28xx. The 
floating point 28xx parts seem to be designed for that.

> 
> I took another wander around yesterday for similar DSCs with boatloads 
> of peripherals such as the waveform generators, QEP interfaces, etc. 
> that the C2000 has, which anything comparable seems to be found only on 
> the Freescale DSCs.  But Freescale are 16 bit and very slow compared to 
> C2000.  I also looked at Microchip's PIC32 and ST ARM/Cortex.  It seems 
> like C2000 towers above anything else in the market, and this has 
> remained so for several years.

TMS 28xx is not very fast, if compared to DSPIC or FreeScale 56xxx, or 
especially to BlackFin. It requires the dual power source with 
sequensing, it is power hungry, and it has only 3.3V I/O which is 
inconvenient for the control applications. The flash programming 
procedure is slow to ridicule. I have used 28xx in some projects, and I 
am not overly excited about it.

> The F2812 remains, after 4 years, one of the ultimate microcontrollers 
> on steroids!

Huh? Same sort of crap like all other MCUs. The most sensible vendor 
seems to be FreeScale, but they are crap, too :)

Here is a bad thing about TMS28xx: not too long ago TI switched the 
silicon revision from "F" to "G". This introduced the incompatibility in 
the flash writing subroutines, and required the change of the software 
and the production procedures.


> Your input is of interest.

I don't understand your point.

Usually, the people are looking for a microcontroller which is suitable 
for the particular application. You seem to look for an application 
which is suitable for the microcontroller.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Jim Granville wrote:

> ADi did have FLASH DSC for a brief time, but I think they saw the
> 'flash-barrier' looming, and went instead to a fast ram based design
> in their BlackFin series.(which I think now hits 400-600MHz)

BlackFin core runs at 600MHz, however the peripheral clock speed is 
133MHz max. Hence all peripheral activities, interrupt latencies, bit 
banging and such are limited to that clock.


> Overall you are right, fast embedded controllers have rather stalled at 
> the 'flash-barrier'. Above 100MHz is quite rare, and those that are
> (like a couple of ARM9's) use slow flash, and a cache to do so.
> (so you will hit the eratic cache issues)
> 
> Perhaps the future is Multi-core devices ?

Perhaps there is no real demand for the faster speed?

> Multiple uC is already quite common.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Vladimir Vassilevsky wrote:
> 
> 
> Chris Carlen wrote:
> 
>> Even though I am able to do what I want with the existing 150MHz 
>> TMS320F2812 digital signal controller (DSC), I am always eager to have 
>> more speed, since applications that were otherwise inconceivable may 
>> become possible if more speed becomes available.
> 
> What kind of application do you need the high speed for?

At present I am generating 1us resolution arbitrary pulse sequences 
using compare matches.  There must be no jitter so HW compare match to 
generate the edges is essential.  I might need to make a waveform like:

START
delay 4us
high 15us
low 12us
high 30us
low 60us
high 10us
low 14us
...
STOP

Then on the next trigger the sequence might be totally different.  This 
is related to research in internal combustion engines.  These are fule 
injection pulses.  No this is not production research, but fundamental 
science.

>> Is it likely that there will be further speed advances with this 
>> architecture?
> 
> Unlikely.

Party pooper.

>> Most microprocessors running at 100 MHz or greater speeds use cache. 
>> The C2000 doesn't, but rather has small segments of "SARAM" which can 
>> run at the full core speed.  The slower flash tops out at effectively 
>> about 90 MIPS.
> 
> It is actually slower then that; 90 MIPS is the ideal case. The 
> realistic figure would be 70...80 MIPS. However the critical code can be 
> loaded in SARAM as you noted.

Yes, that is so.

>> Even if the flash can't be made faster, wouldn't it be useful to have 
>> a faster core and faster SARAM able to keep up with the core, even if 
>> the flash remains at it's present speed limit?
> 
> This is what L1 memory is for.
> 
>> For instance, would folks be interested in a 300MHz device with 16-32k 
>> of data+code space capable of running no wait states at a full 300MHz, 
>> where the larger 256-512k flash requires wait states making it only 
>> effectively 75-90MHz?
> 
> This is BlackFin.

I am aware of much faster devices.  What C2000 has is *peripherals*.  I 
can get things done with this chip that would take much longer with a 
more microprocessor-like device, which would force me to integrate logic 
in an FPGA to do the highly symbiotic hardware+software tasks.

>> This would definitely expand the horizons for my applications, where a 
>> few interrupt service routines and computations have to be performed 
>> very fast, while a substantially larger blob of user interface code 
>> would be satisifed with a few 10s of MHz.
> 
> 
> For the faster CPUs and DSPs, the limiting factor is the bus and the 
> peripheral speed rather then the core speed.

Not really.  If you need to get into an ISR, compute some setup 
parameters for some hardware, then get out fast enough for the hardware 
to do it's think, like generate another compare match, then having more 
CPU cycles per peripheral event is still an improvement.

>> Where do you see TI going next with C2000, and is it likely any other 
>> vendor will produce anything similar?
> 
> TI will probably come up with some sort of click and drag programming 
> environment (like LabWiew) which will generate the code for 28xx. The 
> floating point 28xx parts seem to be designed for that.

Well that's an interesting possibility.  Though there are already at 
least two products of this sort available already.

>> I took another wander around yesterday for similar DSCs with boatloads 
>> of peripherals such as the waveform generators, QEP interfaces, etc. 
>> that the C2000 has, which anything comparable seems to be found only 
>> on the Freescale DSCs.  But Freescale are 16 bit and very slow 
>> compared to C2000.  I also looked at Microchip's PIC32 and ST 
>> ARM/Cortex.  It seems like C2000 towers above anything else in the 
>> market, and this has remained so for several years.
> 
> TMS 28xx is not very fast, if compared to DSPIC or FreeScale 56xxx, or 
> especially to BlackFin. 

I don't see how you can consider it slow compared to 40MHz 16 bit.  It 
is way faster.  It may have more cycles to go through to get into an 
ISR, but it will get done with the ISR faster, so still will outperform 
something at 40MHz.

Blackfin is a totally different animal.  It's not a DSC.  It doesn't 
have 4 waveform generation timers, QEP inputs, etc.  It has lots of nice 
ways to get data in and out of the chip, but it is essentially a 
microprocessor.  It has less GPIO than F2812 without going to a 400ball 
BGA.  There are only 2 devices with LQFPs.

It requires the dual power source with
> sequensing, it is power hungry, and it has only 3.3V I/O which is 
> inconvenient for the control applications. The flash programming 
> procedure is slow to ridicule. I have used 28xx in some projects, and I 
> am not overly excited about it.

Yeah, it's not meant for cell phones and mp3 players.  I work in a lab. 
  I have to do many things, design electronics, fix lasers, align OPOs, 
and make lab instruments.

>> The F2812 remains, after 4 years, one of the ultimate microcontrollers 
>> on steroids!
> 
> Huh? Same sort of crap like all other MCUs. The most sensible vendor 
> seems to be FreeScale, but they are crap, too :)
> 
> Here is a bad thing about TMS28xx: not too long ago TI switched the 
> silicon revision from "F" to "G". This introduced the incompatibility in 
> the flash writing subroutines, and required the change of the software 
> and the production procedures.

Yeah,  probably crummy for production minded folks.

I work in a lab.  I chose the F2812 because the power/complexity ratio 
seemed better than anything else when it came out.  It still seems that 
way.  There are a few options for more MHz, but all are far more complex 
just to get the CPU working, with memory controllers, the need for 
external non-volatile, etc.

  >> Your input is of interest.
> 
> I don't understand your point.

I appreciate your response.

> Usually, the people are looking for a microcontroller which is suitable 
> for the particular application. You seem to look for an application 
> which is suitable for the microcontroller.

Yes, that is true.  I chose to experiment with the F2812 with no 
application, but simply had read about it in comparison to DSPics, ARMs, 
SHARCs, and the new Blackfin, and it seemed like a good step up from the 
AVRs that I was using for little things, yet easy enough to understand 
and get to do some intersting things without having to first understand 
a great deal of supporting infrastructure of setting up MMUs, OSes, 
etc., or having to build PWM generators and QEP decoders in an FPGA.


Good day!


_____________________
CC
c...@REMOVE-THIS.sbcglobal.net
SuSE 10.3 Linux 2.6.19

Jim Granville wrote:
> Chris Carlen wrote:
>> The F2812 remains, after 4 years, one of the ultimate microcontrollers 
>> on steroids!
> 
> Did you look at the ADI BlackFin ? - or some of Infineon's
> top-end parts ?

I am interested in SHARC and Blackfin.  Well, actually I'm interested in 
everything!

> ADi did have FLASH DSC for a brief time, but I think they saw the
> 'flash-barrier' looming, and went instead to a fast ram based design
> in their BlackFin series.(which I think now hits 400-600MHz)
> 
> Overall you are right, fast embedded controllers have rather stalled at 
> the 'flash-barrier'. Above 100MHz is quite rare, and those that are
> (like a couple of ARM9's) use slow flash, and a cache to do so.
> (so you will hit the eratic cache issues)
> 
> Perhaps the future is Multi-core devices ?

Actually, I probably have more use for more peripherals than CPU speed, 
but a little more speed would be valuable.

I could almost make use of 2xF2812 just to have more PWMs for waveform 
generation in my present project.

Thanks for the input.

Good day!

-- 
_____________________
CC
c...@REMOVE-THIS.sbcglobal.net
SuSE 10.3 Linux 2.6.19

On Wed, 02 Jul 2008 18:40:55 -0700, CC
<c...@this-is-bogus.sbcglobal.net> wrote:

><snip>
>At present I am generating 1us resolution arbitrary pulse sequences 
>using compare matches.  There must be no jitter so HW compare match to 
>generate the edges is essential.

I just thought I'd mention the possibility of using a processor that
has a fixed (only one possibility) delay for timer interrupts relative
to the instruction cycle.  The ADSP-218x (and some earlier ones, can't
say about the Blackfin), if you set things up carefully, can be
entirely relied upon for fixed delay intervals.  Since all
instructions are one-cycle, it's very clean.

Just a thought,
Jon

CC wrote:

> At present I am generating 1us resolution arbitrary pulse sequences 
> using compare matches.  There must be no jitter so HW compare match to 
> generate the edges is essential.  I might need to make a waveform like:
> 
> START
> delay 4us
> high 15us
> low 12us
> high 30us
> low 60us
> high 10us
> low 14us
> ...
> STOP
> 
> Then on the next trigger the sequence might be totally different.  This 
> is related to research in internal combustion engines.  These are fule 
> injection pulses.  No this is not production research, but fundamental 
> science.

A good 'hard real time' example :)

Some uC have FIFO/DMA/queued peripherals, that might solve this.
Did you look at Freescale's TPU, for example ?
The xmega has some sort of DMA/IO handling, but it may not be up to
this level of task.

This is the sort of peripheral & time contraint, that lends itself
to a small FPGA / Large CPLD.

You would then choose a MCU, with a FIFO/DMA based SSC or SPI
(and those are relatively common), or map it as dualport Ram,
or even stream it out of a Quad Width SerialFLASH memory,
if you want if even more 'hard coded'

If you are doing research, a small companion FPGA board would
be obvious. That can also capture info, with very precise time
stamps as well.

We have done a numbers of designs, where programmable logic
'extended' the peripheral set of a uC. Makes the uC choice easier.

-jg

On Wed, 02 Jul 2008 18:40:55 -0700, CC
<c...@this-is-bogus.sbcglobal.net> wrote:

>
>At present I am generating 1us resolution arbitrary pulse sequences 
>using compare matches.  There must be no jitter so HW compare match to 
>generate the edges is essential.  I might need to make a waveform like:
>
>START
>delay 4us
>high 15us
>low 12us
>high 30us
>low 60us
>high 10us
>low 14us
>...
>STOP
>
>Then on the next trigger the sequence might be totally different.  This 
>is related to research in internal combustion engines.  These are fule 
>injection pulses.  No this is not production research, but fundamental 
>science.

How far in advance do you know the sequence ?

Would't it be simple to just use one shift register and preload the
pattern and clock it out at 1 MHz ? Some synchronous serial controller
(USRT)  might also do the trick, provided that you can run it in raw
mode without preamble, bit stuffing and CRC.

With two shift registers, one could contain the high bits and the
other the low bits, making it easy to implement the start delay, when
neither is active.

The other alternative would be to use two  loadable synchronous down
counters, one to count the high period and one to count the low period
(and a third for the start delay) driven by a 1 MHz clock. Initially,
load two counters and when the first counter expires, enabling the
second counter and simultaneously generating  an interrupt, which then
reloads the first counter. 

The only requirement is that the interrupt latency is less than the
count time of the second counter so that it does not expire while the
first one is being reloaded. At the next half cycle, the roles are
interchanged.

Paul

"CC" <c...@this-is-bogus.sbcglobal.net> wrote in message
news:N4Wak.10936$c...@nlpi064.nbdc.sbc.com...
> Vladimir Vassilevsky wrote:
> >
> > Chris Carlen wrote:
> >
> >> Even though I am able to do what I want with the existing 150MHz
> >> TMS320F2812 digital signal controller (DSC), I am always eager to have
> >> more speed, since applications that were otherwise inconceivable may
> >> become possible if more speed becomes available.
> >
> > What kind of application do you need the high speed for?
>
> At present I am generating 1us resolution arbitrary pulse sequences
> using compare matches.  There must be no jitter so HW compare match to
> generate the edges is essential.  I might need to make a waveform like:
>
> START
> delay 4us
> high 15us
> low 12us
> high 30us
> low 60us
> high 10us
> low 14us
> ...
> STOP

This is the traditional application for the state machines implemented in
the hardware, such as PLD or FPGA. Some MCUs provide the programmable
sequencers for that (68HC16, for example). It can be also done with the use
of the DMA channels.


> >> For instance, would folks be interested in a 300MHz device with 16-32k
> >> of data+code space capable of running no wait states at a full 300MHz,
> >> where the larger 256-512k flash requires wait states making it only
> >> effectively 75-90MHz?
> >
> > This is BlackFin.
>
> I am aware of much faster devices.

With BlackFin, you can have a pure software solution with the interrupt
driven bit banging. The timing jutter could be less then 100ns, and the
generation of the pulses of the minimum length of 1us with the resolution of
~10ns is no problem.  The other option is DMAing directly to the port, with
no jitter at all.

>  What C2000 has is *peripherals*.

Yes, the timer event manager subsystem of TMS 28xx is impressive.

> > TMS 28xx is not very fast, if compared to DSPIC or FreeScale 56xxx, or
> > especially to BlackFin.
>
> I don't see how you can consider it slow compared to 40MHz 16 bit.  It
> is way faster.

Not quite so. TMS 28xx is not a DSP, it is MCU. It is quite inefficient on
the DSP operations like FIRs or IIRs.

> Blackfin is a totally different animal.  It's not a DSC.  It doesn't
> have 4 waveform generation timers, QEP inputs, etc.  It has lots of nice
> ways to get data in and out of the chip, but it is essentially a
> microprocessor.

BlackFin is fast MCU with good DSP capabilities.

>  It has less GPIO than F2812 without going to a 400ball
> BGA.  There are only 2 devices with LQFPs.

The 12mm BGA is nice small package. The only problem is the need for 4+
layer board. BlackFin in LQFP can be put on the two layer board.

> I work in a lab.  I chose the F2812 because the power/complexity ratio
> seemed better than anything else when it came out.

Good point about power/complexity ratio. I agree, F28xx is good by this
parameter.

> Yes, that is true.  I chose to experiment with the F2812 with no
> application, but simply had read about it in comparison to DSPics, ARMs,
> SHARCs, and the new Blackfin, and it seemed like a good step up from the
> AVRs that I was using for little things, yet easy enough to understand
> and get to do some intersting things without having to first understand
> a great deal of supporting infrastructure of setting up MMUs, OSes,
> etc., or having to build PWM generators and QEP decoders in an FPGA.

Why didn't you buy an arb generator or timer board from NI then? It could
save you a lot of effort.

VLV