New sub-$2.00 60MHz Piccolo C2000 Family from Texas Instruments

Bill Giovino wrote:
> "Ulf Samuelsson" wrote...
> :> The following statement may need a review:
> 
>>"The Piccolo is, of course, expected to be significantly faster than any
>>conventional microcontroller architecture when executing any sophisticated math code."
>>
>>The AVR32 with it's single cycle MAC is also "significantly faster than any
>>conventional microcontroller architecture"  on DSP algorithms.'
> 
> 
> While a microcontroller with a MAC (Multiply Accumulate Unite) is of course available,
> that core configuration is not what I would call a "conventional microcontroller".

  These days, "conventional microcontroller" means anything single chip, 
that can be _used_ as a "conventional microcontroller".
  So, forget legacy ideas about what should, or should not, be counted, 
and look instead at what the vendors are building, and how they might be 
used.
  AVR32 in the Single Chip Flash Models, certainly targets "conventional 
microcontroller" usage and customers.

-jg

On Sep 11, 9:24 am, "Alex T." <a-tessar...@ti.com> wrote:
> The CLA is actually fully programmble FPU. More details will be made
> available over time.
> 
> Initially we will support the CLA with TI supplied algorithms (kind of
> piece together software building blocks). Thats where the "hardcoded"
> terminology came in (maybe not be the most appropriate terminology). Then
> we will support full programmability with appropraite tools. Full
> programmability may come out in conjunction with the hardcoded blocks or
> soon thereafter, we are still working out details. 

If this is not ROM based, then I would saw "hardcoded' is certainly the 
wrong terminology.

<snip>

> The CLA itself is essentially a stripped down version of the FPU on our
> F2833x devices and made it work independently of the C28 CPU. It can
> directly access peripherals such as the ADC and PWM and respond to
> interrupts directly without CPU intervention. You could almost say that the
> Piccolo devices, with CLA, are dual core devices. 

Surely it would be smarter to tell users that ? (when the software has
caught up, of course ;) )

This sounds more like the TPU scheme of Freescale ?

Q: How much memory resource does the CLA have (Code/Data/Flash/RAM) ?

Q: What Debug access to the CLA and Memory, is available in silicon ?

Q: What is the "interrupt jitter" of the CLA operating some example tasks ?

It seems a novel approach, as usually FPU has the widest latency of any 
operation, and thus many apps move that outside the tightest interrupts.

Q: How many Phases of PWM can the CLA/Peripherals manage ?

In power designs, above a certain power level, you need to start 
paralleling Mosfets, and it can make much more sense from a ripple and 
emc viewpoint, to run a lot of phases.
That can slash the ripple currents - so a few cents more on the Silicon,
pays back big time in smaller, cheaper capacitors.


> The CLA in fact automatically shuts down when its task
> is complete. Basically, performance and power are interdependent.
> 
> We have applications where we do just that and even though the data sheet
> may specify a Max power number, it doesn't factor in the above. So
> comparing power between devices is complex. 

Then perhaps the industry needs a better benchmark ?
Something like a Joules/operation ?

-jg

>Is the JTAG support as completely messed and non-standard as
>the MSP320, or did you guys actually follow the IEEE standard
>this time around?

>s debugging info available for the C2000 so that open-source
>and third-party tools will work, or is it all top-secret with
>several sub-families only partially supported like the MSP430?

All of our C2000 devices use IEEE standard JTAG.

Development kits are available for third parties to develop applications.
We have a number of third parties that have and are developing tools for
these devices.

>Thanks for the intro.  So for the short term, it sounds like the CLA
>will be used a bit like the PSOC programmable analog is used, only the
>functions provided by TI are supported.  Are the supported CLA
>functions documented at this time?  I think that was the question that
>Boo was actually asking.
>
>It looks like these parts are still *very* preliminary.  Any idea when
>they will be shipping in volume?
>
>Rick

The Piccolo F2802x series of devices (without CLA) will be sampling by
Nov/Dec this year. The devices are in manufacturing and on their way.

The Piccolo F2803x series of devices (with CLA) will be sampling probably
around Mar/April next year. The design for the F2803x with CLA is actually
done, been debugged on FPGA as we speak. Adding the test infrastructure,
doing the layout and then silicon checkout is actually quite time consuming
(and the least fun).

The CLA functions are been worked on. We will be supporting the standard
trig type functions (div, sqrt, sin, cos, atan2,..) standard DSP type
functions (FIR, IIR,..) standard control functions (PID, PARK, IPARK, State
Estimator,...) and we will be porting our existing Motor Control library
and Digital Power library.

The CLA will also allow users to write their own functions. Below is a
simple example of coding the CLA in assembly:
       MMOV32   MR0,@m        ; MR0 = m  (load value from memory)
       MMOV32   MR1,@x        ; MR1 = x  (load value from memory)
       MMPYF32  MR1,MR1,MR0   ; MR1 = m*x, MR0 = b
       ||MMOV32 MR0,@b                   (load value from memory)
       MADDF32  MR1,MR1,MR0   ; MR1 = m*x + b
       MMOV32   @y,MR1        ;   y = m*x + b (store result to memory)

Cheers,
Alex T.

On Sep 11, 9:37=A0pm, "Alex T." <a-tessar...@ti.com> wrote:
> >Thanks for the intro. =A0So for the short term, it sounds like the CLA
> >will be used a bit like the PSOC programmable analog is used, only the
> >functions provided by TI are supported. =A0Are the supported CLA
> >functions documented at this time? =A0I think that was the question that
> >Boo was actually asking.
>
> >It looks like these parts are still *very* preliminary. =A0Any idea when
> >they will be shipping in volume?
>
> >Rick
>
> The Piccolo F2802x series of devices (without CLA) will be sampling by
> Nov/Dec this year. The devices are in manufacturing and on their way.
>
> The Piccolo F2803x series of devices (with CLA) will be sampling probably
> around Mar/April next year. The design for the F2803x with CLA is actuall=
y
> done, been debugged on FPGA as we speak. Adding the test infrastructure,
> doing the layout and then silicon checkout is actually quite time consumi=
ng
> (and the least fun).
>
> The CLA functions are been worked on. We will be supporting the standard
> trig type functions (div, sqrt, sin, cos, atan2,..) standard DSP type
> functions (FIR, IIR,..) standard control functions (PID, PARK, IPARK, Sta=
te
> Estimator,...) and we will be porting our existing Motor Control library
> and Digital Power library.
>
> The CLA will also allow users to write their own functions. Below is a
> simple example of coding the CLA in assembly:
> =A0 =A0 =A0 =A0MMOV32 =A0 MR0,@m =A0 =A0 =A0 =A0; MR0 =3D m =A0(load valu=
e from memory)
> =A0 =A0 =A0 =A0MMOV32 =A0 MR1,@x =A0 =A0 =A0 =A0; MR1 =3D x =A0(load valu=
e from memory)
> =A0 =A0 =A0 =A0MMPYF32 =A0MR1,MR1,MR0 =A0 ; MR1 =3D m*x, MR0 =3D b
> =A0 =A0 =A0 =A0||MMOV32 MR0,@b =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (load =
value from memory)
> =A0 =A0 =A0 =A0MADDF32 =A0MR1,MR1,MR0 =A0 ; MR1 =3D m*x + b
> =A0 =A0 =A0 =A0MMOV32 =A0 @y,MR1 =A0 =A0 =A0 =A0; =A0 y =3D m*x + b (stor=
e result to memory)
>
> Cheers,
> Alex T.

Thanks for the info.  To be honest, I would prefer to *not* have to
program a DSP like coprocessor in assembly (or at all if possible).
I'm not completely clear on how the CLA is to be used, but that's ok.
If it won't be in full production for eight months or so, I'll wait
before I spend a lot of time looking at it.  TI has burned me before
on new product introductions saying they were six months out for over
a year.

I understand that this part is oriented toward control functions, but
is there any plan to include a higher resolution ADC and DAC channels
perhaps?  I would like to have a single part to use for a variety of
apps rather than different specialized devices requiring many
different tools.  This part with 16 or 18 bit dual ADC and DACs would
have a much wider range of apps.

Rick

>This sounds more like the TPU scheme of Freescale ?
>
Kind of, the TPU is probably closer to the HET peripheral found in our
TI-ARM based devices. The CLA is closer to a normal CPU/FPU that is tightly
coupled to peripherals.

>Q: How much memory resource does the CLA have (Code/Data/Flash/RAM) ?
>
Initial devices (F2803x) will have all RAM memory for CLA. 8Kbytes of RAM
for code and 4Kbytes of RAM for data. Future devices will have standard
functions in ROM. At boot time the main C28-CPU would copy the code from
its Flash to the code RAM of the CLA, configure the CLA and then let it
run.

>Q: What Debug access to the CLA and Memory, is available in silicon ?
>
The CLA has its own debug mechanism (run/halt/single step). Through the
debugger, the user can run the CLA, view memory and registers while the
C28-CPU is halted or running. Even while both the CLA and CPU is running,
you can view/modify memory while the system is running.

>Q: What is the "interrupt jitter" of the CLA operating some example tasks
?
>
I will use a PI control loop for an output power stage running at high
frequency. The interrupt jitter is zero. The CLA, ADC and PWM peripherals
are all synchronously clocked with the same clock (60MHz). The PWM triggers
the ADC conversion and when the ADC coversion finishes, the CLA is
triggered and the CLA then updates the PWM (duty and/or frequency and/or
phase). Some benchmark numbers we are getting are:

Sample To Output Delay   Effective Control Loop B/W   Number Of Phases
ADC->CLA(PI)->PWM
433nSec                         461KHz                       8

The number of phases is basically the number of PI control loops that can
be run at 461KHz max.

>It seems a novel approach, as usually FPU has the widest latency of any 
>operation, and thus many apps move that outside the tightest interrupts.
>
Agree FPUs tend to have higher latency. We designed the CLA to have single
cycle operation for MPY and ADD/SUB operations with the result available in
1 cycle (as compared to most FPUs where there is either a 2 or 3 cycle
latency for the result). MPY/ADD operations can also load/store in parallel
and we can also convert a 16/32 bit signed or unsigned integer value to a
float in a single cycle as we load. Basically we tried to match the latency
of a fixed-point machine so the FPU can operate inside the tightest
interrupts.

>Q: How many Phases of PWM can the CLA/Peripherals manage ?
>
As mentioned above, in theory the CLA running at 60MHz can do 8 phases
with 461Khz control loop). Add on top of that that the C28-CPU can also
operate in parallel and it can do about 5 phases at 60MHz, then in theory
there is enough horsepower to perform ~13 phases at 60MHz.

The first device will have 7 EPWM modules, each module can have
independent phase/duty/frequency control and modules can be synced up and
phased.  Five of these modules will have our High Resolution PWM
technnology with 150pSec resolution on both phase/duty and frequency.

So the peripheral will limit the number of phases to 7 (or 5 with High
Res). 

We do have devices currently available that support up to 16 phases in the
peripheral (F28044/45).

>In power designs, above a certain power level, you need to start 
>paralleling Mosfets, and it can make much more sense from a ripple and 
>emc viewpoint, to run a lot of phases.
>That can slash the ripple currents - so a few cents more on the Silicon,
>pays back big time in smaller, cheaper capacitors.
>
Agree. We actually have Digital Power development kits that support
multiple phases (up to 10) using existing devices. You can check them out
on the TI C2000 web site links.

>Then perhaps the industry needs a better benchmark ?
>Something like a Joules/operation ?
>
Agree, but unfortunately I don't think one benchmark could capture all of
the variety of applications. Probably need a suite of benchmarks each more
specific for given applications. Unfortunately for marketing and data sheet
documentation, they like to keep things simple :-)

Cheers,
Alex T.

>Thanks for the info.  To be honest, I would prefer to *not* have to
>program a DSP like coprocessor in assembly (or at all if possible).
>I'm not completely clear on how the CLA is to be used, but that's ok.
>If it won't be in full production for eight months or so, I'll wait
>before I spend a lot of time looking at it.  TI has burned me before
>on new product introductions saying they were six months out for over
>a year.
>
Programming in assembly is one option for the CLA. For some of the
applications we are taregting, where every cycle counts, it leaves little
option but program in assembly. Although we do support sharing C header
files in assembly code which makes it easier to build assembly code within
a main C application. The C28-CPU itself supports a C/C++ comipler and
users normally build their application in C/C++ and then for the CLA either
link in pre-packaged building blocks or write their own.

Other programming models will be supported but cannot give details now.

I can understand your issue with new product announcements. Although in
defence of our C2000 group, we have been fairly good at delivering on our
promisses. 

>I understand that this part is oriented toward control functions, but
>is there any plan to include a higher resolution ADC and DAC channels
>perhaps?  I would like to have a single part to use for a variety of
>apps rather than different specialized devices requiring many
>different tools.  This part with 16 or 18 bit dual ADC and DACs would
>have a much wider range of apps.
>
>Rick

Yes, we get that a lot. But at what cost? Integrating such technology is
being worked on, but you probably wouldn't get it at the price range of
Piccolo (at least in the near future).

On Sep 12, 12:03=A0am, "Alex T." <a-tessar...@ti.com> wrote:
>
> >I understand that this part is oriented toward control functions, but
> >is there any plan to include a higher resolution ADC and DAC channels
> >perhaps? =A0I would like to have a single part to use for a variety of
> >apps rather than different specialized devices requiring many
> >different tools. =A0This part with 16 or 18 bit dual ADC and DACs would
> >have a much wider range of apps.
>
> >Rick
>
> Yes, we get that a lot. But at what cost? Integrating such technology is
> being worked on, but you probably wouldn't get it at the price range of
> Piccolo (at least in the near future).

I get this response a lot when I ask about improvements to product
lines.  My question to *you* is "at what cost"?  I am not saying that
a 16 bit ADC/DAC is needed in the TMS320F28035/27.  But a different
member with that capability would allow a lot more applications to be
implemented with the same set of tools and without moving to a
different architecture.  Earlier in this thread these parts were being
promoted as being useful for a range of applications comparing it to a
"conventional microcontroller architecture".  If a variety of
peripherals are not provided within the family, then it is just
another motor control oriented DSP chip, no matter what you do within
the CPU.

I read that the sample rate of the 12 bit converter is pretty high.
Have any tests been done on oversampling to provide higher bit
resolutions?  That still doesn't provide DACs though.

Rick

>I get this response a lot when I ask about improvements to product
>lines.  My question to *you* is "at what cost"?  I am not saying that
>a 16 bit ADC/DAC is needed in the TMS320F28035/27.  But a different
>member with that capability would allow a lot more applications to be
>implemented with the same set of tools and without moving to a
>different architecture.  Earlier in this thread these parts were being
>promoted as being useful for a range of applications comparing it to a
>"conventional microcontroller architecture".  If a variety of
>peripherals are not provided within the family, then it is just
>another motor control oriented DSP chip, no matter what you do within
>the CPU.
>
We are working on it, and it would be another member of the C2000 family.

At what cost? its largely dependent on the target application and the
ADC/DAC specs required. There is such a wide variety of specs that its
almost impossible to build a "generic" device that caters for a wide
variety of applications. Just look at the wide variety of discrete ADC
devices available. So, I cannot answer that question. What you will
probably see in the future is devices with higher resolution ADC's but
targeting a specific range of applications.

>I read that the sample rate of the 12 bit converter is pretty high.
>Have any tests been done on oversampling to provide higher bit
>resolutions?  That still doesn't provide DACs though.
>
Yes, we have run oversampling tests on the 12-bit ADC and we have seen
about two bits of extra resolution. Beyond that the THD starts to limit
what we can achieve.

On the DAC side, not sure what applications you are thinking about, but
one area where we have a lot of interest is using the High Resolution PWM
to drive Audio speakers directly via D-Class amp. We have an evaluation
board available to demo this capability. So that is using High Res PWM to
replace what was done with a high resolution DAC in the past.

On Sep 11, 11:41=A0pm, "Alex T." <a-tessar...@ti.com> wrote:
> >This sounds more like the TPU scheme of Freescale ?
>
> Kind of, the TPU is probably closer to the HET peripheral found in our
> TI-ARM based devices. The CLA is closer to a normal CPU/FPU that is tight=
ly
> coupled to peripherals.
>
> >Q: How much memory resource does the CLA have (Code/Data/Flash/RAM) ?
>
> Initial devices (F2803x) will have all RAM memory for CLA. 8Kbytes of RAM
> for code and 4Kbytes of RAM for data. Future devices will have standard
> functions in ROM. At boot time the main C28-CPU would copy the code from
> its Flash to the code RAM of the CLA, configure the CLA and then let it
> run.

So the the CLA only has access to its RAM and not the CPU's RAM? And
the CLA RAM is basically dualported to the CPU?