"Ian Buckner" <Ian_Buckner@agilent.com> wrote in message
news:1077269665.656938@cswreg.cos.agilent.com...
>
> >
> No url - that was a verbal quote from their apps engineer. He thought
> 3:1 was good, and expected that as the tools matured it might even
> improve a little :-|
> I asked the question because they were touting using HLL exclusively,
> and that was what the OP seemed to be considering. A more "normal"
> approach would be to use HLL for some parts and assembler for the
> intensive crunching.
>
> Regards
>     Ian
>

Thanks for your response.

We are considering exclusive C programming, at least until we receive an app
that requires assembly. I'll keep an eye and ear on the 3:1 ratio issue as
we ramp up and post our findings. The much faster speed of the Blackfin
should allow us to *ease* into assembly while we learn.

"kansas_ray" <kansas_ray@hotmail.com> wrote in message
news:m48Zb.1046$Fb7.483@newssvr22.news.prodigy.com...
>
> "Jon Harris" <goldentully@hotmail.com> wrote in message
> news:c12vaf$1dprhq$1@ID-210375.news.uni-berlin.de...
> > "kansas_ray" <kansas_ray@hotmail.com> wrote in message
> > news:IJ3Zb.981$vd6.496@newssvr22.news.prodigy.com...
> > >
> > > "Ian Buckner" <Ian_Buckner@agilent.com> wrote in message
> > > news:1077182391.61573@cswreg.cos.agilent.com...
> > > >
> > > > >
> > > > ADI say that the speed difference between assembler and a HLL
on
> > > > the Blackfin is around 3:1.
> > > >
> > > > Regards
> > > >     Ian
> > >
> > > Wow! I always expect some difference between assembly and a HLL
but 3:1
> is
> > > huge IMO. Any idea why?
> > >
> > > Regards,
> > > Ray
> >
> > An overall average number may not be all that useful.  There is
probably
> > quite a large amount of variability based on your particular HLL
code,
> your
> > skill in writing optimized assembler, etc..
> >
> >
>
> Something doesn't compute. A look at the libraries shows very
efficient C
> code. AD actually gives examples of "bad" C code vs good and you
would have
> to try pretty hard to be bad.
>
> Maybe Ian (or anyone) could post a URL to that quote of ADI's?
>
> Regards,
> Ray
>
>
No url - that was a verbal quote from their apps engineer. He thought
3:1 was good, and expected that as the tools matured it might even
improve a little :-|
I asked the question because they were touting using HLL exclusively,
and that was what the OP seemed to be considering. A more "normal"
approach would be to use HLL for some parts and assembler for the
intensive crunching.

Regards
    Ian

"kansas_ray" <kansas_ray@hotmail.com> wrote in
news:m48Zb.1046$Fb7.483@newssvr22.news.prodigy.com: 

> 
> "Jon Harris" <goldentully@hotmail.com> wrote in message
> news:c12vaf$1dprhq$1@ID-210375.news.uni-berlin.de...
>> "kansas_ray" <kansas_ray@hotmail.com> wrote in message
>> news:IJ3Zb.981$vd6.496@newssvr22.news.prodigy.com...
>> >
>> > "Ian Buckner" <Ian_Buckner@agilent.com> wrote in message
>> > news:1077182391.61573@cswreg.cos.agilent.com...
>> > >
>> > > >
>> > > ADI say that the speed difference between assembler and a HLL on
>> > > the Blackfin is around 3:1.
>> > >
>> > > Regards
>> > >     Ian
>> >
>> > Wow! I always expect some difference between assembly and a HLL but
>> > 3:1 
> is
>> > huge IMO. Any idea why?
>> >
>> > Regards,
>> > Ray
>>
>> An overall average number may not be all that useful.  There is
>> probably quite a large amount of variability based on your particular
>> HLL code, 
> your
>> skill in writing optimized assembler, etc..
>>
>>
> 
> Something doesn't compute. A look at the libraries shows very
> efficient C code. AD actually gives examples of "bad" C code vs good
> and you would have to try pretty hard to be bad.
> 
> Maybe Ian (or anyone) could post a URL to that quote of ADI's?
> 
> Regards,
> Ray
> 
> 
> 

I agree that 3x seems a little excessive. 

Most DSP programmers will use C for housekeeping functions where speed is 
not generally the issue. Using C just to avoid learning the assembly 
language is probably a bad idea.

I actually write all my DSP code in assembly. With the Sharc and 
Blackfin, C is certainly a reasonable option. I just find that DSPs have 
a rich enough assembly language that to some degree , its like trading 
one mid level language (the assembly) for another less efficient mid 
level language (C).

C is also structually less than ideal for Harvard architectures. I'm not 
anti-C in general. Like everyone else, I write a little C for other 
things.


-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

"Jon Harris" <goldentully@hotmail.com> wrote in message
news:c12vaf$1dprhq$1@ID-210375.news.uni-berlin.de...
> "kansas_ray" <kansas_ray@hotmail.com> wrote in message
> news:IJ3Zb.981$vd6.496@newssvr22.news.prodigy.com...
> >
> > "Ian Buckner" <Ian_Buckner@agilent.com> wrote in message
> > news:1077182391.61573@cswreg.cos.agilent.com...
> > >
> > > >
> > > ADI say that the speed difference between assembler and a HLL on
> > > the Blackfin is around 3:1.
> > >
> > > Regards
> > >     Ian
> >
> > Wow! I always expect some difference between assembly and a HLL but 3:1
is
> > huge IMO. Any idea why?
> >
> > Regards,
> > Ray
>
> An overall average number may not be all that useful.  There is probably
> quite a large amount of variability based on your particular HLL code,
your
> skill in writing optimized assembler, etc..
>
>

Something doesn't compute. A look at the libraries shows very efficient C
code. AD actually gives examples of "bad" C code vs good and you would have
to try pretty hard to be bad.

Maybe Ian (or anyone) could post a URL to that quote of ADI's?

Regards,
Ray

"kansas_ray" <kansas_ray@hotmail.com> wrote in message
news:IJ3Zb.981$vd6.496@newssvr22.news.prodigy.com...
>
> "Ian Buckner" <Ian_Buckner@agilent.com> wrote in message
> news:1077182391.61573@cswreg.cos.agilent.com...
> >
> > >
> > ADI say that the speed difference between assembler and a HLL on
> > the Blackfin is around 3:1.
> >
> > Regards
> >     Ian
>
> Wow! I always expect some difference between assembly and a HLL but 3:1 is
> huge IMO. Any idea why?
>
> Regards,
> Ray

An overall average number may not be all that useful.  There is probably
quite a large amount of variability based on your particular HLL code, your
skill in writing optimized assembler, etc..

"Ian Buckner" <Ian_Buckner@agilent.com> wrote in message
news:1077182391.61573@cswreg.cos.agilent.com...
>
> >
> ADI say that the speed difference between assembler and a HLL on
> the Blackfin is around 3:1.
>
> Regards
>     Ian
>

Wow! I always expect some difference between assembly and a HHL but 3:1 is
huge IMO. Any idea why?

Regards,
Ray

"Jon Harris" <goldentully@hotmail.com> wrote in message
news:c10f9l$1cfo62$1@ID-210375.news.uni-berlin.de...
>snip<
> Also, keep in mind that in general the Blackfins run at a
significantly
> higher clock rate than the SHARCs.  If you don't need the 32-bit
precision
> or floating point of the SHARC, you end up paying the price both in
> increased cost and slower clock speed.  On the other hand, if you
have to do
> a lot of double-precision work with a 16-bit part, the 32-bit part
will
> almost assuredly end up being faster despite the slower clock rate.
>
>
A 32-bit multiply on the Blackfin reputedly takes 5 clocks.

Regards
    Ian

"kansas_ray" <kansas_ray@hotmail.com> wrote in message
news:%pLYb.743$g21.155@newssvr22.news.prodigy.com...
>
>snip<
> Thanks for your input. We did purchase the EZ-Kit for $99 and like
it. My
> software partner claims the assembly language of the Blackfin is
much more
> complicated than the 218X but with its superior speed, we may never
have to
> code that way again.
>
> Regards,
> Ray
>
>
ADI say that the speed difference between assembler and a HLL on
the Blackfin is around 3:1.

Regards
    Ian

"Al Clark" <dsp@danvillesignal.com> wrote in message
news:Xns94938572CDE34aclarkdanvillesignal@66.133.130.30...
> "kansas_ray" <kansas_ray@hotmail.com> wrote in
> news:2BLYb.745$kX.397@newssvr22.news.prodigy.com:
>
> >
> > Thanks, Al, for your insightful reply.
> >
> > The answer to all three questions is no, but the faster speed would
> > make life easier on some of our current projects and might be a
> > necessity in the near future. We have looked at the 219X and 2199X
> > (motor control variants) but the rep and disti both preach Blackfin.
>
> The 219x is really a next generation 218x. There is a serious DMA bug in
> the 0.x silicon. This was corrected in the 219x, but I don't think the
> 2199x has been fixed. We held up our dspstak 2191sx board for almost a
> year until we could use Rev 1.x silicon.
>
> ADI is certainly preaching Blackfin and it is going to completely replace
> the 218x and 219x. If you are clearly in the 16 bit precision space, then
> the Blackfin is probably the right choice.
>
> >
> > We have not even considered the Sharc. What are its claims to fame?
> > Isn't it in a different ballpark cost-wise? The variants of the
> > Blackfin and 218X that we've looked at or used are around $10 (qty 1).
>
> Low cost Sharcs are in the $20 - $30 dollar area in small quantities. The
> Blackfin is much cheaper.
>
> The advantages of the Sharc are precision and floating point capability.
> If you are building products in small quantities, then the chip price is
> probably not as important as development time. I think that you can learn
> the Sharc faster and that code is easier to write on the Sharc. This is
> particularly true if you have functions that are easier to write in
> floating point format (FFTs & RMS detectors are examples). IIR filters
> are also easier to implement due to the increased precision of the
> coefficients. BTW, the Sharc is also a 32 bit fixed point DSP as well, so
> you are not giving up any advantages to fixed point DSPs.

Also, keep in mind that in general the Blackfins run at a significantly
higher clock rate than the SHARCs.  If you don't need the 32-bit precision
or floating point of the SHARC, you end up paying the price both in
increased cost and slower clock speed.  On the other hand, if you have to do
a lot of double-precision work with a 16-bit part, the 32-bit part will
almost assuredly end up being faster despite the slower clock rate.

"kansas_ray" <kansas_ray@hotmail.com> wrote in
news:2BLYb.745$kX.397@newssvr22.news.prodigy.com: 

> 
> "Al Clark" <dsp@danvillesignal.com> wrote in message
> news:Xns9492BBA356454aclarkdanvillesignal@66.133.130.30...
>>
>> Its really a bigger step than $4300. The Blackfin is a significant
>> departure from the 218x. This means that there is also learning time
>> to consider.
>>
>> I would start by analyzing what you are trying to accomplish in both
>> the short and the long run. What kind of applications are you trying
>> to solve?
>>
>> Here are some questions:
>>
>> 1. Do you need significantly more speed?
>> 2. Do you need less power consumption?
>> 3. Do you need greater precision?
>>
>> Certainly the Blackfin will replace the 218x and 219x for many 16 bit
>> embedded applications. We have a long history with 218x and 219x
>> DSPs, but most of our work is moving to the new ADSP-21262 Sharc. The
>> 32 bit precision and floating point features are generally more
>> significant to us than the features of the Blackfin. I think it is
>> easier to move from 218x to Sharc than 218x to Blackfin. We plan to
>> use the Blackfin primarily for applications where low power
>> consumption is very important. 
>>
>> The Blackfin is not going away and it will certainly replace the 218x
>> and 219x families. You can start using it now or in a year. If you
>> need an easier bridge to greater performance and time to market is a
>> factor, you might consider a ADSP-219x DSP. It is very easy to move a
>> 218x project to a 219x target, especially if you already are using
>> VDSP since you already have most of the tools and you know the
>> language. --
>> Al Clark
>> Danville Signal Processing, Inc.
> 
> Thanks, Al, for your insightful reply.
> 
> The answer to all three questions is no, but the faster speed would
> make life easier on some of our current projects and might be a
> necessity in the near future. We have looked at the 219X and 2199X
> (motor control variants) but the rep and disti both preach Blackfin.

The 219x is really a next generation 218x. There is a serious DMA bug in 
the 0.x silicon. This was corrected in the 219x, but I don't think the 
2199x has been fixed. We held up our dspstak 2191sx board for almost a 
year until we could use Rev 1.x silicon.

ADI is certainly preaching Blackfin and it is going to completely replace 
the 218x and 219x. If you are clearly in the 16 bit precision space, then 
the Blackfin is probably the right choice.

> 
> We have not even considered the Sharc. What are its claims to fame?
> Isn't it in a different ballpark cost-wise? The variants of the
> Blackfin and 218X that we've looked at or used are around $10 (qty 1).

Low cost Sharcs are in the $20 - $30 dollar area in small quantities. The 
Blackfin is much cheaper.

The advantages of the Sharc are precision and floating point capability. 
If you are building products in small quantities, then the chip price is 
probably not as important as development time. I think that you can learn 
the Sharc faster and that code is easier to write on the Sharc. This is 
particularly true if you have functions that are easier to write in 
floating point format (FFTs & RMS detectors are examples). IIR filters 
are also easier to implement due to the increased precision of the 
coefficients. BTW, the Sharc is also a 32 bit fixed point DSP as well, so 
you are not giving up any advantages to fixed point DSPs.

 
> I don't think there is a definitive right or wrong answer here. 

You're right. We currently support 218x, 219x, Sharc and will almost 
certainly be using Blackfin this year as well.


-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com