Floating Point DSP from Microchip (?)

Hi,

I would like to select a Floating Point DSP.  I was looking-up the 
Microchip website and I see things like:

   "Support for Floating Point" and
   "Floating Point Library"

I get a feeling as if they only have a software workaround and not a 
true Floating Point hardware implementation.  Somehow their wording 
about Floating Point DSPs does not sound like that of TI or ADI.

It is tough for me to make out because I am not used to selecting DSPs. 
  Your inputs in helping me make a clear choice are welcome.
(The simplest could be - "Yes, Microchip XYZ is a true hardware 
implemented Floating Point DSP.  I can vouch for it.".)

Thanks for your time.

Regards,
Anand

On Mon, 23 Apr 2012 15:12:20 +0530, "Anand P. Paralkar"
<anand.paralkar@gnospammale.com> wrote:

>Hi,
>
>I would like to select a Floating Point DSP.  I was looking-up the 
>Microchip website and I see things like:
>
>   "Support for Floating Point" and
>   "Floating Point Library"
>
>I get a feeling as if they only have a software workaround and not a 
>true Floating Point hardware implementation.  Somehow their wording 
>about Floating Point DSPs does not sound like that of TI or ADI.
>
>It is tough for me to make out because I am not used to selecting DSPs. 
>  Your inputs in helping me make a clear choice are welcome.
>(The simplest could be - "Yes, Microchip XYZ is a true hardware 
>implemented Floating Point DSP.  I can vouch for it.".)
>
>Thanks for your time.
>
>Regards,
>Anand

Hello Anand,
  I'll bet that you are correct, in that the Microchip 
microcontroller chips do not have high-speed 'hardware 
multiply' capability.

At: 

http://ww1.microchip.com/downloads/en/devicedoc/39962b.pdf 

their PIC24 microcontroller chip requires 81 clock 
cycles to perform one floating point multiply.

Good Luck,
[-Rick-]

"Anand P. Paralkar" <anand.paralkar@gnospammale.com> wrote in 
news:9vkmg7Fv6gU1@mid.individual.net:

> Hi,
> 
> I would like to select a Floating Point DSP.  I was looking-up the 
> Microchip website and I see things like:
> 
>    "Support for Floating Point" and
>    "Floating Point Library"
> 
> I get a feeling as if they only have a software workaround and not a 
> true Floating Point hardware implementation.  Somehow their wording 
> about Floating Point DSPs does not sound like that of TI or ADI.
> 
> It is tough for me to make out because I am not used to selecting DSPs. 
>   Your inputs in helping me make a clear choice are welcome.
> (The simplest could be - "Yes, Microchip XYZ is a true hardware 
> implemented Floating Point DSP.  I can vouch for it.".)
> 
> Thanks for your time.
> 
> Regards,
> Anand


As far as I know, Microchip does not have a floating point device. Generally 
speaking, floating point emulation is very inefficient with fixed point 
processors and more times than not, a bad idea if you care about performance.
It's usually better to use a fixed point version of the function or migrate 
to a device with native floating point support.    

OTOH, Devices that support floating point are usually very good fixed point 
processors as well. 

ADI and TI are the main floating point players. What are you trying to do? 

Al Clark
www.danvillesignal.com    

On 4/23/12 11:59 PM, Al Clark wrote:
>
>
> As far as I know, Microchip does not have a floating point device. Generally
> speaking, floating point emulation is very inefficient with fixed point
> processors and more times than not, a bad idea if you care about performance.
> It's usually better to use a fixed point version of the function or migrate
> to a device with native floating point support.
>
> OTOH, Devices that support floating point are usually very good fixed point
> processors as well.
>
> ADI and TI are the main floating point players. What are you trying to do?
>
> Al Clark
> www.danvillesignal.com

nice to see you around, Al.  it's been a few weeks or months.  you and 
Lori Ann okay?

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

Hope I do not end-up triggering a huge "Floating Point vs Fixed Point" 
debate here.  I am trying to implement a PID controller for valve control.

I read through a bit of the literature that is available on making a 
choice between Floating Point and Fixed Point.  For a newbie in signal 
processing like me, Floating Point seems to be the easiest and safest 
thing to use.  (Especially given the fact that it is going to be custom 
built and not destined for production en mass.)

Your comments regarding the choice of processor or any aspect about PID 
control for valve positioning are welcome.

Thanks,
Anand

On 24-04-2012 09:29, Al Clark wrote:
> "Anand P. Paralkar"<anand.paralkar@gnospammale.com>  wrote in
> news:9vkmg7Fv6gU1@mid.individual.net:
>
>
>
> As far as I know, Microchip does not have a floating point device. Generally
> speaking, floating point emulation is very inefficient with fixed point
> processors and more times than not, a bad idea if you care about performance.
> It's usually better to use a fixed point version of the function or migrate
> to a device with native floating point support.
>
> OTOH, Devices that support floating point are usually very good fixed point
> processors as well.
>
> ADI and TI are the main floating point players. What are you trying to do?
>
> Al Clark
> www.danvillesignal.com

On 4/24/12 12:59 AM, Anand P. Paralkar wrote:
>
> Hope I do not end-up triggering a huge "Floating Point vs Fixed Point"
> debate here. I am trying to implement a PID controller for valve control.
>
> I read through a bit of the literature that is available on making a
> choice between Floating Point and Fixed Point. For a newbie in signal
> processing like me, Floating Point seems to be the easiest and safest
> thing to use. (Especially given the fact that it is going to be custom
> built and not destined for production en mass.)
>

then per unit cost is not an issue.

> Your comments regarding the choice of processor or any aspect about PID
> control for valve positioning are welcome.

what's your sampling rate expected to be?  if the sampling rate is slow 
enough, you could do this with any chip, even those that don't know how 
to multiply (where you have a routine to do that).

also how is the valve physically controlled?  how is the position or 
state of the valve measured?  how will these values get in and out of 
the DSP (or CPU or MPU or whatever the chip is)?

FWIW, floating point looks ostensibly easier and safer, but it is not 
always and then when bad things happen, it can be harder to find and 
deal with using floating point.

case in point: denormalized numbers.

another case in point: a digital integrator used in a moving sum operation.

lastly, it's generally important to know your algorithm so well that you 
have an idea for how big numbers can get at any "node" in the alg.  once 
you know that, you're in just as good of a position to do this in fixed 
point as you are in floating point.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

Hope I do not end-up triggering a "Floating Point vs Fixed Point" debate 
here.  :) I am trying to implement a PID controller for valve control.

I read through a bit of the literature that is available on making a 
choice between Floating Point and Fixed Point.  For a newbie in signal 
processing like me, Floating Point seems to be the easiest and safest 
thing to use.  (Especially, given the fact that it is going to be a 
custom built product and not destined for production en mass.)

Your comments regarding the choice of processor or any aspect about PID 
control for valve positioning are welcome.

Thanks,
Anand

On 24-04-2012 09:29, Al Clark wrote:
> "Anand P. Paralkar"<anand.paralkar@gnospammale.com>  wrote in
> news:9vkmg7Fv6gU1@mid.individual.net:
>
>
>
> As far as I know, Microchip does not have a floating point device. Generally
> speaking, floating point emulation is very inefficient with fixed point
> processors and more times than not, a bad idea if you care about performance.
> It's usually better to use a fixed point version of the function or migrate
> to a device with native floating point support.
>
> OTOH, Devices that support floating point are usually very good fixed point
> processors as well.
>
> ADI and TI are the main floating point players. What are you trying to do?
>
> Al Clark
> www.danvillesignal.com

On 24-04-2012 11:00, robert bristow-johnson wrote:

> what's your sampling rate expected to be? if the sampling rate is slow
> enough, you could do this with any chip, even those that don't know how
> to multiply (where you have a routine to do that).

Don't know as yet.  Since this is not an application with a natural 
signal (audio/video and the like) as it's start point, I am having a 
tough time figuring this out.  I have an ominous feeling that it will be 
what it will be after I have finished implementing everything! :|

>
> also how is the valve physically controlled?

Using a pneumatic control block that takes a two bit digital input.

00 => chamber A to B (this results in valve open)
01 => chamber B to A (results in valve close)
10 => stop
11 => not allowed

this pneumatic control block will get a pwm input from the pid controller.

>how is the position or
> state of the valve measured?

Either a resistance (generated by a position indicating rheostat) 
converted to voltage or a current (4 - 20 ma) converted to voltage.

Even the set point will be indicated using a 4 - 20 mA signal.

how will these values get in and out of the
> DSP (or CPU or MPU or whatever the chip is)?

Using an ADC of a suitable resolution (basically whatever the DSP 
offers) and a suitable front-end.  I will probably use a low pass filter 
here.  I am yet to figure out what will be the cut-off frequency.

>
> FWIW, floating point looks ostensibly easier and safer, but it is not
> always and then when bad things happen, it can be harder to find and
> deal with using floating point.
>
> case in point: denormalized numbers.
>
> another case in point: a digital integrator used in a moving sum operation.
>
> lastly, it's generally important to know your algorithm so well that you
> have an idea for how big numbers can get at any "node" in the alg. once
> you know that, you're in just as good of a position to do this in fixed
> point as you are in floating point.
>

Agreed.  Except that, now I need an algorithm to know my algorithm! :)

On 24/04/2012 08:02, Anand P. Paralkar wrote:
> On 24-04-2012 11:00, robert bristow-johnson wrote:
>
>> what's your sampling rate expected to be? if the sampling rate is slow
>> enough, you could do this with any chip, even those that don't know how
>> to multiply (where you have a routine to do that).
>
> Don't know as yet. Since this is not an application with a natural
> signal (audio/video and the like) as it's start point, I am having a
> tough time figuring this out. I have an ominous feeling that it will be
> what it will be after I have finished implementing everything! :|
>
>>
>> also how is the valve physically controlled?
>
> Using a pneumatic control block that takes a two bit digital input.
>
> 00 => chamber A to B (this results in valve open)
> 01 => chamber B to A (results in valve close)
> 10 => stop
> 11 => not allowed
>
> this pneumatic control block will get a pwm input from the pid controller.
>
>> how is the position or
>> state of the valve measured?
>
> Either a resistance (generated by a position indicating rheostat)
> converted to voltage or a current (4 - 20 ma) converted to voltage.
>
> Even the set point will be indicated using a 4 - 20 mA signal.
>
> how will these values get in and out of the
>> DSP (or CPU or MPU or whatever the chip is)?
>
> Using an ADC of a suitable resolution (basically whatever the DSP
> offers) and a suitable front-end. I will probably use a low pass filter
> here. I am yet to figure out what will be the cut-off frequency.
>
>>
>> FWIW, floating point looks ostensibly easier and safer, but it is not
>> always and then when bad things happen, it can be harder to find and
>> deal with using floating point.
>>
>> case in point: denormalized numbers.
>>
>> another case in point: a digital integrator used in a moving sum
>> operation.
>>
>> lastly, it's generally important to know your algorithm so well that you
>> have an idea for how big numbers can get at any "node" in the alg. once
>> you know that, you're in just as good of a position to do this in fixed
>> point as you are in floating point.
>>
>
> Agreed. Except that, now I need an algorithm to know my algorithm! :)

If you are attempting proportional control with a pneumatic actuator in 
the loop then I wish luck - you are going to need it !
It is WAY too soon to be worrying about the processor.
First you need a model of your system, then you can attempt to model the 
control loop, then you will KNOW who much maths the processor needs to do.
I would start by building  a system model in SIMULINK (or MAPLE SIM) - 
if you don't have tools like that available you will need to do it some 
other way.
You will very likely find that you can't get the parameters you need for 
the model from the part manufacturers and you will need to measure them 
yourself.
Is this a commerical or a study project ?

Michael Kellett

"Anand P. Paralkar" <anand.paralkar@gnospammale.com> writes:
> [...]

Anand,

Have you considered the TI TMS320F2806x Piccolo series? They operate to
80 MHz and have a Control Law Accelerator - basically an integrated,
low-level coprocessor that can interface directory with the A/D for
low-latency processing and MIPS-intensive front-end processing such as
filtering and decimation.

They also have a floating point unit so you could use floating point at
least initially and then go to fixed-point later. 

Finally, there's also a VCU (Viterbi/Complex Unit) for accelerating
certain operations. 

Depending on the algorithm you could probably run this at a sample rate
as high as 1 MHz. (We are!)

--Randy

PS: I sound like a TI salesman/rep - I am not!


> On 24-04-2012 11:00, robert bristow-johnson wrote:
>
>> what's your sampling rate expected to be? if the sampling rate is slow
>> enough, you could do this with any chip, even those that don't know how
>> to multiply (where you have a routine to do that).
>
> Don't know as yet.  Since this is not an application with a natural
> signal (audio/video and the like) as it's start point, I am having a
> tough time figuring this out.  I have an ominous feeling that it will
> be what it will be after I have finished implementing everything! :|
>
>>
>> also how is the valve physically controlled?
>
> Using a pneumatic control block that takes a two bit digital input.
>
> 00 => chamber A to B (this results in valve open)
> 01 => chamber B to A (results in valve close)
> 10 => stop
> 11 => not allowed
>
> this pneumatic control block will get a pwm input from the pid controller.
>
>>how is the position or
>> state of the valve measured?
>
> Either a resistance (generated by a position indicating rheostat)
> converted to voltage or a current (4 - 20 ma) converted to voltage.
>
> Even the set point will be indicated using a 4 - 20 mA signal.
>
> how will these values get in and out of the
>> DSP (or CPU or MPU or whatever the chip is)?
>
> Using an ADC of a suitable resolution (basically whatever the DSP
> offers) and a suitable front-end.  I will probably use a low pass
> filter here.  I am yet to figure out what will be the cut-off
> frequency.
>
>>
>> FWIW, floating point looks ostensibly easier and safer, but it is not
>> always and then when bad things happen, it can be harder to find and
>> deal with using floating point.
>>
>> case in point: denormalized numbers.
>>
>> another case in point: a digital integrator used in a moving sum operation.
>>
>> lastly, it's generally important to know your algorithm so well that you
>> have an idea for how big numbers can get at any "node" in the alg. once
>> you know that, you're in just as good of a position to do this in fixed
>> point as you are in floating point.
>>
>
> Agreed.  Except that, now I need an algorithm to know my algorithm! :)

-- 
Randy Yates
DSP/Firmware Engineer
919-577-9882 (H)
919-720-2916 (C)