END OF LIVE of DSP567xx

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

END OF LIVE of DSP567xx

4,995 Views
Marcopolo
Contributor I

Hi,

 

I think Freescale want to stop the DSP567xx products, what do you think?

 

3 years old SymphonyStudio (use a 2007 Eclipse version)

No reference design available

No schematic available for the EVM module

Overpriced EVM carrier board + module

No dedicated forum, just Other MCU-CPU, I can't believe it!

Nothing in Google

 

We are evaluating the DSP56725 for a new project but it seems too dangerous

to start with this family of DSP.

 

Regards,

Marc

 

Tags (1)
0 Kudos
Reply
16 Replies

3,468 Views
clangen
Contributor I

Hi Marco,

 

regarding the EOL announcements for semiconductors you never know....

 

This is even true for analog components. The good news is that the DSP567xx are all in Freescale's longevity program. This claims that the 567xx were introduced in 2008 and will be shipped for then years from this date. Since that I expect them to be available until 2018 at least, see:

 

http://www.freescale.com/webapp/sps/site/overview.jsp?code=PRDCT_LONGEVITY_HM&fsrch=1&sr=1

 

I've heared rumors for obsolescense of the DSP56k successors for ten years now. Anyway this may happen to each other semiconductor. The good news is that the Onix design is validated and has paid off so it needs little effort for Freescale to continue this series. Anyway the design tools are old but mature (I even prefer Suite56 - using this I've learned ten years before).

 

The DSP56k applications have moved into a niche - but today this holds true for _all_ dedicated DSP architectures. Noone is going to design a new DSP architecture today anymore - the reason for this is that DSP architecture characteristics have been added to most RISC architectures so there seems to be a rigorous requirement for dedicated DSPs only at the low end battery driven equipment and the high power telecommunication infrastructure, sonar, RADAR and similar applications.

 

Both areas are not the field of appication for the DSP56k series that is dedicated to audio especially - in the consumer domain this is handled my ARM powered media processors now, the professional audio market is too small for a dedicated processor architecture.

 

Anyway I consider the 56k architecture besides ARM to be best suited to learn main characteristics of computer architectures - maybe this architecture will be teached at university even if it has been disapperaed from the market...

 

Best regards

 

Christian

 

 

0 Kudos
Reply

3,468 Views
Marcopolo
Contributor I

Thanks Christian and Nick for you viewpoint and information.

 

The fact the DSP567xx are all in Freescale's longevity program is a good news, yes but

I can't believe a 3 years old software like SymphonyStudio is bug free.

 

Many  users seem to use Suite 56, but for new users it is not really a user-friendly software.

 

Marc.

0 Kudos
Reply

3,468 Views
clangen
Contributor I

Hi Marc,

 

just some sidenotes (tend to be somewhat philosophical):

 

- It isn't possible to write bug free software in a not perfect world.

 

- I don't agree that a three years old software is more buggy than something that has been just released - but this is just an opinion experience taught me.

 

- Symphony Studio uses Eclipse CDT 3.1.1 (released in 2005 - even six years old now!). SInce this is just a framework (no IDE) to plug in propriate development tools like OpenOCD, ASM56300, SIM56300, G56C etc. everyone can feel free to build his own better Eclipse configuration. It would be a nice project to rebuild the tool chain using Eclipse Indigo CDT. The tools are all available for free.

 

- If you don't like to use open source tools you have the possibility to buy a tool chain by Tasking (compiler, assembler, debugger), see: http://tasking.com/products/dsp56xxx/ but don't even expect commercial to be bug free.

 

Christian

0 Kudos
Reply

3,468 Views
rocco
Senior Contributor II

Hi Marc, Nick and Christian,

 

We seem  to be the only DSP guys left here. These are my observations, which seems to agree with your own.

 

 

New designs avoid the DSP56 architecture because they cannot be made "C-efficient". How would you create a ring buffer with the AGU using C syntax? An ARM SOC with dedicated audio engines are much simpler and more cost-efficient to program. As Nick said, we are using the DSP56 because we already have highly optimized assembly code for it.

 

Price per mips may be favorable to the newer DSP56 chips, but development costs will overturn that advantage unless you are producing an awful lot of product.

 

Development tools are pretty pathetic, but we can seem to make them work. The newer chip features are not supported by the assembler, such as the shared memory in the 567xx family. Symphony-Studio was a disaster for us, so we are using Suite56, which means parallel-port-wigglers.

 

I have never bought an EVM or used a reference design, so I can't speak to those issues. We simply dig into the data books and roll our own hardware. I don't think the EVMs would help much in our application.

 

We are currently using the DSP56721, but I suspect that this will be our last product with the DSP56 family.

0 Kudos
Reply

3,468 Views
Marcopolo
Contributor I

 Hi,

 

A week ago, I tried to order samples.

It's funny, order total is $21.96 (10.00 +0.00 +0.00)  or  $11.96 (10.00 + 1.96)

 

I'm going to cancel my order because with your answers (thanks guys), I understood I can't use Freescale DSP56.

 

Marc.

 

 

Order's listing (total=$21.96)

 

Total Records:1 
 
 Order IDORDER AMOUNTORDER DATEStatus
 Ascending DescendingAscending DescendingAscending DescendingAscending Descending
1276512$ 21.9607-19-2011Pending
 
Total Records:1 

Order's detail (total=$11.96)

 

 
#ItemItem TypeOrder QtyShpd. QtyRetd. QtyStatusUnitPrice
($ US)
Discount Amount
($ US)
Item Total ($ US)Actual
Ship Date
 
Scheduled Ship Date
 
Software Download /
Entitlement Id
Track #
/Reference #
Service Request
1Ordered Part #  : DSPB56725AF
Part Description: DSP56724
Stocking Part #   : DSPB56725AF
Sample 

--

--

Pending 

--

--

--

------N/ACreate Service Request 
2Ordered Part #  : DSPB56721AF
Part Description: DSP56721
Stocking Part #   : DSPB56721AF
Sample 

--

--

Back-Ordered 

--

--

--

------N/ACreate Service Request 
Subtotal ($ US) :
Shipping Cost ($ US) :
Order Processing Charge ($ US) :
Sales Tax ($ US) :
VAT ($ US) :
0.00
0.00
10.00
0.00
1.96
 
Order Total (Amount to be paid) ($ US) :11.96 

Print invoice (total=$21.96)

 

#ItemItem TypeQtyUnit Price
($ US)
Discount Amount
($ US)
Item Sub Total
($ US)
1Ordered Part #  : DSPB56721AF
Part Description: DSP56721
Stocking Part #  : DSPB56721AF
Sample8$0.00$0.00$0.00
2Ordered Part #  : DSPB56725AF
Part Description: DSP56724
Stocking Part #  : DSPB56725AF
Sample8$0.00$0.00$0.00
Subtotal($ US)0.00
 Shipping & Order Processing Charge($ US)
10.00
Sales Tax($ US)0.00
VAT Tax (if applicable) ($ US)0.00
Order Total (Amount to be paid)($ US)21.96

0 Kudos
Reply

3,468 Views
clangen
Contributor I

Hi Marc,

 

interestingly enough that you like to cancel your order based on some opinions of guys like us. Personally I wouldn't do so but gather my own experiences.

 

I'm keen to know eventually what's the adequate alternative for the 5672x DSPs. Personally I'm interested in alrenatives as well but TMS320C6xx , SHARC and others are another league, Blackfin, TMS320C5x and other 16-bit architectures as well. The DSP56xxx has its own niche in between the remaining DSP architectures. I couldn't find something comparable until these days... There's only NXP's CoolFlux DSP that shows similar architecture, see: http://www.coolflux.com/nxp-coolflux-dsp . Unfortunately the core is licensable only, NXP is not offering a DSP chip themselves.

 

If Symphony Studio is the problem I could volunteer to repost my small tutorial again. Needless to say that most 'IDEs'  today are based on Eclipse (also TI's Code Composer is based on this). Once you've mastered the initial learning curve you will happily stay with Eclipse - I guess this is the industry standard today as well.

 

Today I noticed that Alteras Nios II is based on _exactly_ the same (mature) version 3.1.1 as Symphony Studio. So what?

 

Best regards

 

Christian

0 Kudos
Reply

3,468 Views
Nikko
Contributor III

A quick update on the topic of the end of life of 24-bit Motorola-Freescale DSP: all single core in the Symphony family are now 'Not recommended for new design'.

Well i can't help but feel a bit of sadness about that. I suppose AD with their ADAU wiped off the remaining of market share that Fresscale had maintained in the audio dsp business. I can't imagine now someone designing a new product based on dual cores without having prior experience with single cores.

 

 

0 Kudos
Reply

3,468 Views
clangen
Contributor I

Hi,

 

I don't think the EOL is a problem of pressure taken to Freescale by competitors. From the very beginning the DSP56k was heavily targeted to the audio market that doesn't exist the same way like in the 1980's/90's. Today even the most simple and cheap products have video and network capabilities as well. Car radios (that were one target market) don't exist any longer but are replaced my multi media dashboards. DVD players (another DSP56k target market) are dead since everything went into computers and movies are downloaded these days. Maybe the blue ray disk will never be sucessful as expected. One of the classic tasks for DSP is MPEG/Dolby etc. audio decoding that can be handled by any other MCU without woes.

 

The 'pure audio' niche is shrinking. Freescale now is migrating to the Kinetis (ARM Cortex-M3) and i.MX (ARM Cortex-A8/9) series now. Today's market demands can no longer be fulfilled by a pure DSP architecture - on the other hand standard MCU architecture designers have learned enough from this to adapt the main DSP characteristic (MAC, multiple access Harvard memory architecture with parallel data buses, peripherals accessable by fast interrupts, special address modifiers - the only characteristic I cannot see in standard MCUs is the special code execution control, say zero oeverhead looping), so there's no longer a need for pure DSP. Heavy number crunching can be handled by FPGAs if required at adequate cost. Maybe the only surviving pure DSP will be TI's TMS320C6xxx architecture as well as some DSP cores not available to the public (this is just an opinion).  

 

I can state this sadly as I'm one of the DSP56k guys having tons of assembly code at hand but the DSP56k is not the first computer architecture to pass away - I can remember many of them.

 

Now I'm installing a small museum in front of my office door at my university to make students remember the 'golden days' of DSP by exposing some artifacts of the past 25+ years I've collected. Maybe I continue teaching computer architecture courses using the DSP56k architecture (this gives a lot of fun anyway and is didactcally suitable) but I'm not even sure about this.

 

Christian

0 Kudos
Reply

3,468 Views
Nikko
Contributor III

Hi Christian,

 

You're absolutely right when you state that the audio dsp market has shrinked quite a lot, in particular since the introduction of the late ARM cores. Where I can not totally agree with you is when you state that competition in this segment is not relevant.

 

The point is that AD indeed released the ADAU. It's a 28-bit fix-point architecture with many ports for audio in and out (note that this is the major issue with ARM implementations: not enough audio peripherals for some applications). There are several versions, starting at 50 MMACS and going up to 172 MMACS - which is precisely the segment where the 24-bit freescale single-core dsps were sitting.

 

I don't think that AD would have introduced the Sigma DSP if there weren't a market. No one can afford the cost of developping a new family of ICs without a prior market study.

I actually know one product that uses this dsp, and know of an other one in development that's using it too. There's still space for DSP in embedded audio applications where ARMs are not suitable.

 

I gave myself DSP labs during 2 years at the uni. That was a long time ago, between 2002 and 2004. We were also using the dsp56k platform, with - believe it or not - DSP56002 evaluation boards. At some point we acquired DSP56311 evaluation boards - that was still before the advent of the Symphony family. These same boards are now obsolete.

 

Nowadays I wouldn't give student labs with the DSP24k. Even if the DSP principles and programming concepts remain the same, it's not doing a favor to students when you introduce them to an obsolete platform. The reason is these students, who undergo a DSP course, already know basics of programming and processor architecture and might have learnt that on a deprecated platform already (for example I programmed the 8-bit 8085 straight in HEX at uni before i started DSP) .

 

Also at a job interview nowadays it's far better to say that you have a bit of hands-on with the ARM rather than with the 56k. The interest engineering companies might have now in the 56k is about the same as the one banks have in Cobol: it's all about maintaining existing product.

 

I talk like that - but at the same time i'm expecting brand new boards with dual-cores Freescale chips... As far as i know there's no other chip capable of 24-bit 500 MMACS on a single dice for USD 6 each. But for how long?

0 Kudos
Reply

3,468 Views
emarx
Contributor I

Hmmm interesting to see this thread. I've been developing with DSP56k for about 15 years now. I've done everything from scratching audio (which requires fully variable sample rate conversion forwards and backwards), time stretching, IIRs, and FIRs. The DSP56k parts have always been amazing performers.

From what I see there aren't good alternatives for the DSP56k. Yes if you want to add tons of peripherals like USB, Wifi, touch displays, etc. there are lots of newer chips with better integration. But with integration things get complex, so these new parts seem to rely on massive buffering on peripherals. This means the devices get sluggish. I personally experimented with TI's TMS320C6748 for example. All I did was run an audio loop-through. It started giving out on me when I tried to lower the buffer to under 10msec. And that's just a very simple process. Now what happens when I try to add more complexity?

The Motorola DSP56k parts are the only ones I know of that literally allow you to program the device to work on a sample by sample basis for the audio. I work in the DJ Pro Audio market and know that there are DJs out there who can hear and feel msec latencies, and always go back to using vinyl on certain occasions specifically for this reason. Most of the more modern full featured equipment is made really cheaply in anticipation DJs will just throw it away in order to get the next thing with more features (and often even more latency and complexity).

Fortunately some of these parts are part of the Freescale longevity program. I sure hope this statement from Christian holds true: "The good news is that the Onix design is validated and has paid off so it needs little effort for Freescale to continue this series."

Please keep these parts going!

P.S. Christian, Nicholas what do you guys do?

0 Kudos
Reply

3,468 Views
clangen
Contributor I

Anyway my wishes that the ONIX core architecture will be available in future didn't fulfil. Maybe a future alternative to go will be ARM's Cortex-M7, but I'm not sure about this. If available I'll get my hands on this and see. Elliot, where are your current acivities in the DJ Pro Audio market? Maybe I can help.

0 Kudos
Reply

3,468 Views
emarx
Contributor I

Hello Christian,

Please feel free to write to me audioinn@audioinnovate.com. Would enjoy continuing this conversation with you

0 Kudos
Reply

3,468 Views
clangen
Contributor I

Dear Elliot,

it took me a while to look to this thread again because my activities has shifted away from DSP programming, especially for the DSP56k. Anyway it's a dead dog now so I moved my focus to other things. The lessons learned from this is never again focus my development activities to a dedicated platform again but to do developments on an more abstract level using high level language and model-driven software development. A consequence from this is that I discontinued a course in my university curriculum that had a tradition of 20+ years using the DSP56k architecture to discuss advanced computer architectures and how to optimize code (written in assembly language) for better efficiency.

The replacement course for this has another title as well, not "Microprocessors/DSP" but "Embedded Systems" now. I focus on the implementation of DSP algorithms in high level languages (C/C++) as well as I introduce Model-Driven software development using Matlab/Simulink and Embedded Coder as well as I give an introduction to Linux/Android as time allows me to do so. Besides this I also introduce VHDL programming using FPGA architectures that will be used for real time video processing and high-speed DSP.

I feel the times of dedicted DSP architectures are over. The drawback of current architectures is that they are becoming obsolete even faster than before, so a tradition of 15+ years cannot be built again anymore. We have to move to more abtsract design technologies to handle today's demands and, yes, we have to spend more money for development tools. For small companies it will become more harder to afford the tools as well as hardware design has been lifted to a more sophisticted level.

What I'm doing now? For my Embedded System's class I'm currently using LogicPD's OMAP-L138 eXperimenter board but this has become obsolete as well. I tried to order 15 units by Texas Instruments but after delivering 12 boards they had to give up because the LC display was discontinued by the supplier Hitachi.

In the class we are using Code Composer Studio 5 by Texas Instruments. The hurdles are differently to Symphony Studio but after some initial issues the students can handle this by far more easier since they can use the C programming language. I don't consider architectural details anymore since any knowledge about this will be useless since it will become obsolete to fast. I don't believe that the C6000 architecture has any future but it's great as a student's learning vehicle. If the time has come I just trash the hardware and move to other architectures since I don't stick to it.

For research activities we use any kind of hardware that is available to solve the problem. For a current research project we use TI's C2000 architecture because it's supported by Matlab's Embedded Coder, for another activity we work with Analog Devices' Blackfin because a client uses them. Recently I move my Embedded Systems' activities to Intel Atom based platforms since we can use off the shelf operating systems (Linux, Android and Windows) and run software developed on desktop computers.

There is a saying "don't put all your eggs into one basket" and this holds especially true for computers.

By the way if you like to get hands-on experience using the C6748 platform, buy this book and try the examples: http://www.amazon.com/Digital-Signal-Processing-Applications-OMAP/dp/047093686X/ref=sr_1_1?ie=UTF8&q...

You may do first tests using the C6748 LCDK TMS320C6748 DSP Development Kit (LCDK) - TMDXLCDK6748 - TI Tool Folder and Olimex TMS320XDS100 JTAG adapter TMS320-XDS100-V2 because the OMAP-L138 eXperimenter board used in Donald Reay's book is no longer available. Anyway all audio examples can run on this cheap combitation (under 300$) as well (TMDXLCDK6748 Texas Instruments | Mouser and TMS320-XDS100-V2 Olimex Ltd. | Mouser).

So just continue whith what you started already, the C6748. It's not as bad as your first trial. The advantage is that you can move your application to other platforms easily.

0 Kudos
Reply

3,468 Views
Nikko
Contributor III

Hi Christian,

 

Thanks for your post, I'm myself interested in the future of DSP.

 

I agree with you that a lot of applications now will not implement a dedicated DSP processor, because, as you say, mainstream processors tend to include some dsp capability.

 

However DSP processors manufacturers have reacted quite strongly to the new market trends by significantly cutting the MIPS cost. In 2005 for example, the most powerful DSP56k was the DSP56321 with 275 MIPS max, retailing over USD60. Nowadays the DSP567xx deliver 500 MIPS for USD6 or so, and competitors have similar offers.

 

The price cut on chips added to the relative simplicity of programming and implementing a dedicated DSP, makes me think that it's still a commercial viable solution for audio applications demanding lots of MIPS.

 

Regards,

 

Nick

0 Kudos
Reply

3,468 Views
Nikko
Contributor III

Hi Marc,

 

I've been hearing for years now on other forums such as DSPrelated that Freescale would give up their 24-bit DSP line.

 

You're right: the development environment is not great, but it's free.

 

The EVM for the DSP567xx is expensive, but you can evaluate the core architecture with the cheap Soundbite (single core DSP56371), and the schematics for that board are available.

 

The Freescale 24-bit DSP core is more than 20 years old. It's not anymore 'the king of audio DSPs' it used to be. Most of the guys sticking with it are doing so because they have a lot of assembly code available from past projects.

 

I wouldn't expect to see Freescale giving up for good their 24-bit DSP line any soon. But i wouldn't expect them neither to invest a lot of ressources in renewing the tools and docs...

 

What other DSP candidates have you considered so far?

 

Regards,

 

Nick

0 Kudos
Reply

3,468 Views
Marcopolo
Contributor I

Hi Nick,

 

Tanks for your answer.

 

I look at TI C6745 Fixed and floating-point DSP

(not the most used DSP from TI)

 

The TI  user's community is very active,  you can download free and up to date dev tools,

QFP case and cheap JTAG emulators are available.

 

Regards,

Marc.

0 Kudos
Reply