TMS320VC33 or another floating point DSP

"Randy Yates" <randy.yates@sonyericsson.com> wrote in message
news:xxpmzr0fg7o.fsf@usrts005.corpusers.net...
> "DigitalSignal" <digitalsignal999@yahoo.com> writes:
>
> > I have benchmarked the floating point software library for a fixed
> > point processor. The inefficiency ratio is about 50 to 100. In the
> > other words, you need 50 to 100 instruction cycles of a fixed point
> > processor to implement one floating point instruction. This should not
> > come as a surprise if you consider all the PUSH and POPs when a
> > subroutine is called.
> >
> > So for the people who frequently need floating point operations,
> > fixed-point processor is hardly the solution.
>
> Let's see - if I need 10,000 floating point operations per second,
> then, at a factor of 100:1, I need 1 MIPS - well within reach of any
> fixed-point DSP developed within the last 10 years.
>
> Your conclusion is a non-sequitor. The decision depends on the
> horsepower required.

Another way to say it which may be more to your liking is that the fixed point
DSP emulating a floating-point will need to run 50-100 times faster than a
similar floating point DSP.  This implies significantly higher cost, higher
power consumption, etc..  But like you pointed out, if you have a very small
horsepower need, software emulation may be just fine.  Personally, I've never
had the luxury of using a processor that is 50-100 times faster than it needs to
be in a work project!  :-)

As a side note, I'm guessing that the 50-100x performance hit is for using the
IEEE 754 32-bit floating-point format.  I would guess that if you rolled your
own floating point emulation where you didn't worry about the hidden bit of IEEE
or the various exceptions (NAN, Infinities, denormals), and only implemented the
minimum needed for your particular design, you could achieve somewhat better
results.  Something like block floating-point comes to mind.  Of course it would
take considerably more effort and be less re-usable.

Hi Jon,

Let me respond to your points below.

"Jon Harris" <jon_harrisTIGER@hotmail.com> writes:

> "Randy Yates" <randy.yates@sonyericsson.com> wrote in message
> news:xxpmzr0fg7o.fsf@usrts005.corpusers.net...
>> "DigitalSignal" <digitalsignal999@yahoo.com> writes:
>>
>> > I have benchmarked the floating point software library for a fixed
>> > point processor. The inefficiency ratio is about 50 to 100. In the
>> > other words, you need 50 to 100 instruction cycles of a fixed point
>> > processor to implement one floating point instruction. This should not
>> > come as a surprise if you consider all the PUSH and POPs when a
>> > subroutine is called.
>> >
>> > So for the people who frequently need floating point operations,
>> > fixed-point processor is hardly the solution.
>>
>> Let's see - if I need 10,000 floating point operations per second,
>> then, at a factor of 100:1, I need 1 MIPS - well within reach of any
>> fixed-point DSP developed within the last 10 years.
>>
>> Your conclusion is a non-sequitor. The decision depends on the
>> horsepower required.
>
> Another way to say it which may be more to your liking is that the fixed point
> DSP emulating a floating-point will need to run 50-100 times faster than a
> similar floating point DSP.  This implies significantly higher cost, 

The only way I see that this can be true is if the user's horsepower
requirement dictated a special high-speed version of the fixed-point
DSP, with a correspondingly high cost due to the reduced
yield. Otherwise I would think just the opposite is true - the
floating point part is going to be costlier due to the extra silicon
required to implement the floating point logic.

In fact, if the horsepower requirements were commensurate with a
moderately-priced fixed-point DSP, this would be a classic example of
trading off hardware for time of execution, similar to using
bit-serial logic in an FGPA or ASIC.

> power consumption, 

That depends on the ratio of mA/MIP to mA/MFLOP, I would guess. If the
ratio is less than 1:50 or so, it would be wash (or even an advantage)
power-wise. 

> etc..  But like you pointed out, if you have a very small
> horsepower need, software emulation may be just fine.  Personally, I've never
> had the luxury of using a processor that is 50-100 times faster than it needs to
> be in a work project!  :-)

I guess I don't see it being such an unfathomable situation, thus the suggestion
seemed appropriate to me. 
-- 
%  Randy Yates                  % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC            %  you still wander the fields of your
%%% 919-577-9882                %  sorrow."
%%%% <yates@ieee.org>           % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr

Randy Yates wrote:
>Your conclusion is a non-sequitor. 

Did you mean non sequit*u*r?

--Bhooshan
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

"Randy Yates" <yates@ieee.org> wrote in message news:psvvdcex.fsf@ieee.org...
> Hi Jon,
>
> Let me respond to your points below.
>
> "Jon Harris" <jon_harrisTIGER@hotmail.com> writes:
>
> > "Randy Yates" <randy.yates@sonyericsson.com> wrote in message
> > news:xxpmzr0fg7o.fsf@usrts005.corpusers.net...
> >> "DigitalSignal" <digitalsignal999@yahoo.com> writes:
> >>
> >> > I have benchmarked the floating point software library for a fixed
> >> > point processor. The inefficiency ratio is about 50 to 100. In the
> >> > other words, you need 50 to 100 instruction cycles of a fixed point
> >> > processor to implement one floating point instruction. This should not
> >> > come as a surprise if you consider all the PUSH and POPs when a
> >> > subroutine is called.
> >> >
> >> > So for the people who frequently need floating point operations,
> >> > fixed-point processor is hardly the solution.
> >>
> >> Let's see - if I need 10,000 floating point operations per second,
> >> then, at a factor of 100:1, I need 1 MIPS - well within reach of any
> >> fixed-point DSP developed within the last 10 years.
> >>
> >> Your conclusion is a non-sequitor. The decision depends on the
> >> horsepower required.
> >
> > Another way to say it which may be more to your liking is that the fixed
point
> > DSP emulating a floating-point will need to run 50-100 times faster than a
> > similar floating point DSP.  This implies significantly higher cost,
>
> The only way I see that this can be true is if the user's horsepower
> requirement dictated a special high-speed version of the fixed-point
> DSP, with a correspondingly high cost due to the reduced
> yield.

With a 50-100x performance hit, unless the application was pretty light-weight
the scenario you describe seems pretty likely.  Worse yet would be if the
algorithm taxed today's higher-speed floating point DSPs, say a SHARC runing at
300 MHz.  The 15-30GHz fixed point processor to emulate that would be pretty
pricey (and power hungry)!  But assuming the processing requirement could be
satisifed by say 1 MFLOP, then a 50-100 MIP fixed point guy would be a fine
solution.  It  really depends on where the application sits relative to todays
technology "sweet spots".

> Otherwise I would think just the opposite is true - the
> floating point part is going to be costlier due to the extra silicon
> required to implement the floating point logic.
>
> In fact, if the horsepower requirements were commensurate with a
> moderately-priced fixed-point DSP, this would be a classic example of
> trading off hardware for time of execution, similar to using
> bit-serial logic in an FGPA or ASIC.
>
> > power consumption,
>
> That depends on the ratio of mA/MIP to mA/MFLOP, I would guess. If the
> ratio is less than 1:50 or so, it would be wash (or even an advantage)
> power-wise.

Do you think the power hit for floating point is really on the order of 50x
(assuming the same word-length)?

I think in an ideal world, if you could construct a floating-point DSP to exatly
do a particular floating-point job or construct a fixed-point DSP to do the same
job at 50-100 performance hit, the floating-point is going to win hands down in
both cost and power.  (I'm just guessing, but I would think it would take
somewhere around 2-5x the silicon to make a floating-point MAC vs. a
fixed-point.  Ray Andraka might know.)  But in practice, there just aren't a lot
of cheap, relatively slow floating-point DSPs out there, and you have a lot more
choices in the fixed point world.  So with real-world parts and light to
moderate processing requirements, the fixed point emulation might work out well.

> > etc..  But like you pointed out, if you have a very small
> > horsepower need, software emulation may be just fine.  Personally, I've
never
> > had the luxury of using a processor that is 50-100 times faster than it
needs to
> > be in a work project!  :-)
>
> I guess I don't see it being such an unfathomable situation, thus the
suggestion
> seemed appropriate to me.

In my experience, the cheapest processor that will do the job is designed in,
and if there is overhead, extra features are added to fill up overhead (and then
some)!  Having 2x the required processing power would be a luxury for me, so
50-100x would definitely be "unfathomable"!  But I'm sure others have had
significantly different experiences.  I suppose if you were using an
off-the-shelf platform rather than something custom-designed, you might be more
likely to have a large amount of overhead.

"bhooshaniyer" <bhooshaniyer@gmail.com> writes:

> Randy Yates wrote:
> >Your conclusion is a non-sequitor. 
> 
> Did you mean non sequit*u*r?

I believe my meaning was clear and the intent of your
post is to fault for a spelling error. 
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

"Jon Harris" <jon_harrisTIGER@hotmail.com> writes:
> [...]

Jon,

Stuff it, dude. The original poster stated:

  I'm looking for a "smaller" floating point DSP (do not need so much
  MIPS/MFLOPS). 

Thus my suggestion was reasonable.
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

Randy--

>> Did you mean non sequit*u*r?
>
>I believe my meaning was clear and the intent of your
>post is to fault for a spelling error. 

You apparently missed the humor(self-deprecating,actually...I get picked
on all the time for my bad spelling...that was a lame attempt at pointing
one out from my side...)in my post, so there is no point trying to telling
you that it was a failed attempt at humor.Never the less you must know that
I did not intend offence(why would you think otherwise? Because I argue at
times?) and I did believe your intent and argument was self evident.

--Bhooshan

		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

"Randy Yates" <randy.yates@sonyericsson.com> wrote in message
news:xxp7ji3fcz3.fsf@usrts005.corpusers.net...
> "Jon Harris" <jon_harrisTIGER@hotmail.com> writes:
> > [...]
>
> Jon,
>
> Stuff it, dude. The original poster stated:
>
>   I'm looking for a "smaller" floating point DSP (do not need so much
>   MIPS/MFLOPS).
>
> Thus my suggestion was reasonable.

I must admit, I never read the OP, but jumped in late.  The discussion seemed to
have turned to the general topic of fixed point emulation of floating point, so
that's where I was coming from.  But given the OP's requirements, your suggest
is reasonable.  Consider it "stuffed".  :-)

"bhooshaniyer" <bhooshaniyer@gmail.com> writes:

> Randy--
> 
> >> Did you mean non sequit*u*r?
> >
> >I believe my meaning was clear and the intent of your
> >post is to fault for a spelling error. 
> 
> You apparently missed the humor(self-deprecating,actually...I get picked
> on all the time for my bad spelling...that was a lame attempt at pointing
> one out from my side...)in my post, so there is no point trying to telling
> you that it was a failed attempt at humor.Never the less you must know that
> I did not intend offence(why would you think otherwise? Because I argue at
> times?) and I did believe your intent and argument was self evident.

Bhooshan, 

I haven't noticed anyone berating your spelling capabilities here so
your humorous innuendo was indeed lost on me. Compared to the pig-slop
that passes as English that we often get on this group, this seems
pretty minor.
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

Randy--

>Bhooshan, 
>
>I haven't noticed anyone berating your spelling capabilities here so

Well, it has happened few times,especially when I was in the middle
serious and passionate issues.I can understand if you havent noticed, but
some how I assumed you read almost all the threads here.Do not matter now
though.

>your humorous innuendo was indeed lost on me.

Yeah...That was the bigger tragedy.

>Compared to the pig-slop
>that passes as English that we often get on this group, this seems
>pretty minor.

It was pretty minor for sure.Especially since it was a french
expression(was it french), it was not even an english language spelling
mistake. 

Though am not familiar with the usage- "pig-slop", am assuming that you
are not very fond of the broken english variety...But you should cut some
holy slack for the non-native english speakers as well.

--Bhooshan
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com