SC-570/571 Analog Devices DSPs

[jipihorn]

Hello everybody,

I've been searching for a long time some chips that can be used for computations with a TQFP (or similar package). It's very difficult to find any. The I/O pins number always follows the actual power of the chips, so any FPGA, DSP or similar stuff use big BGA package as soon as they begin to have some computational speed.

After trying to investigate the MAX10 FPGA (and giving up because of the impossibility to get actual and practical information about how to program them with a micro-controller), I discovered the ADPS-SC571 DSP chip. A TQFP double DSP+Arm core, perfect for what I want to do.
So I took hours to have an overall overview of this chip (without having worked with the analog devices tools and DSP series yet).
But, alas, similarly to the Altera MAX10 awful documentation, it's impossible to have a clear idea about this chip.
The documentation is totally mixed up with the SC-573 series (using BGA400 package). And you have the choose between empty (and useless) datasheets or several thousand pages of reference manuals to get overall information.
But, even with this, I couldn't figure out how this chip can be used :

This version does not have a external dynamic RAM pins (but seems to have an internal controller - it's drawn in the internal structure schematics in the reference hardware manual, but I'm pretty sure it's a copy/paste of the SC-573 document). I has only 1MB of RAM in addition to L1/L2 caches for DSPs and ARM cores. At the same time, there is a Linux plugin for this chip. I can understand that the Linux Image can be put in flash memory (up to 512 MB memory mapped SQI interface) but how this can be executed ? There is so few RAM that I can no see where the Linux Kernel can be loaded. I've asked at Analog Devices forum lots of questions but most of them are not answered clearly. In other words, how this chip can be used in practice with so few RAM and no external dynamic memory controller. They put very optional stuff on this package (parallel i/o for LCD displays, 21 pin Ethernet interface, 3 SQI ports using 11 pin each...), stuff that should have been discarded or simplified or shared in order to have a memory controller interface (even a simplified one, the BGA400 package has 49 pins dedicated to that).

Is there anybody here has already worked with this chip and can describe how this chip can be used in real life ?

Thanks in advance,

Jérôme.
(And I don't speak about the mail correspondence with ADI to get only the availability date of the SC571, it's beyond reality...)

[Kalvin]

What application you are looking at, what performance you are after and what other constraints you have other than low pincount?

[Rasz]

what computation exactly?
I got the feeling $10 RasPee zero is what you really want. Cheap >1GHz linux module with nice serial port to talk to your microcontroller.

[diyaudio]

The SC-570/571 documentation is still a incomplete state for good reason, its a massive leap with an arsenal of peripherals compared to its gen 4 family.

I would speak directly to ADI or Danville Signal on the subject.

 

[jipihorn]

Hello everybody.

It's funny to see this "universal" mechanism in forums where any questions, whatever precise or specific they are, leads to the inevitable answer "what are you planning to do ?"
In my case, it is not relevant regardless to the question itself, but anyway. To be short : signal processing with very strict timing constraints with I/O. So any ARM/Linux solution for this part is not usable. Linux/ARM combination  is totally useless because of it inability to have correct I/O timings, latency and jitter. So DSP or FPGA solution is  the alternative. in this case  a DSP with some light glue logic is a perfect solution. The central aspect here is the TQFP package, the key parameter that make the SC-571 a unique chip.
In the case of the SC571, the ARM core is only here for monitoring and external tasks with the huge advantage of memory sharing with DSP cores. In this context, having a Linux make things much more easier with all the high level stuff already available (IP stack...).

The last answer is pretty interesting, but I don't understand fully the sentence. It's not because of the author, it's because of my english level : "its a massive leap with an arsenal of peripherals compared to its gen 4 family". Does it means that the peripherals are much more advanced (I did't know the gen level of all these chips) and some more work is needed to provide tools for them ? This is strange, the SC-573 is being available since at least one year ! Nevertheless, I would be very, very grateful to have some insights about the SC-571 and some mysterious aspect of its architecture, especially how this chip can have an embedded Linux in its ARM core without RAM.

Many thanks in advance for any feedback form Analog !

Jerome.

[nctnico]

It's funny to see this "universal" mechanism in forums where any questions, whatever precise or specific they are, leads to the inevitable answer "what are you planning to do ?"
In my case, it is not relevant regardless to the question itself, but anyway. To be short : signal processing with very strict timing constraints with I/O. So any ARM/Linux solution for this part is not usable. Linux/ARM combination  is totally useless because of it inability to have correct I/O timings, latency and jitter.

Without specifying any numbers this is just a blanket statement. Ask yourself how a Linux system can playback video and audio. These are tasks which require accurate timing.

[Marco]

signal processing with very strict timing constraints with I/O. So any ARM/Linux solution for this part is not usable. Linux/ARM combination  is totally useless because of it inability to have correct I/O timings, latency and jitter.

I'll keep this short, since you clearly don't want to talk about it, but for innocent bystanders I will point out that that is misinformation. Xenomai can do hard real time if you really need it, which support TI's AM33xx series which have 200 MHz coprocessors to handle cycle accurate arbitrary I/O. https://xenomai.org//embedded-hardware/ http://bela.io/

[jipihorn]

Why have I to justify myself about the numbers where these are not relevant for the question itself ? Have I to prove I'm smart enough to have done my homework and conclude that they are not suitable ? And for the video example, Linux does not do a lot, a dedicated hardware does. Linux is incapable to guarantee better than microsecond range in one I/O with multi GHz ARM A57 cores but magically can do picosecond timings in video ?
 
An sorry, Xenomai does not do what I call "accurate I/O" (nanosecond range jitter). I don't care about latency per se if it is guaranteed to be constant (a FIFO can manage this easily) which is far, far from the case. All publications and measurements converge to the same range of results.

In any case, it's irrelevant with the original question : how Analog Devices can run a linux in a SC-571 chip without memory controller.

Jerome.

[nctnico]

If you did your homework  then you'd know about ucLinux (which is far from ideal).
The thing is that if you explain more about what you actually want to achieve then you will get a ton of ideas and solutions you don't even know existed. Try it! It will make your life easier.

[Siwastaja]

Why have I to justify myself about the numbers where these are not relevant for the question itself ?

This is not some kind of freaking helpdesk where people get paid to answer your specific questions exactly, 100% relevantly, while keeping poker face with your broken attitude.

This is a discussion forum. You post something, we post something to cultivate the thought process.

It seems you need professional consultation help from someone who can give you specific and exact answers, while you pay them $250/hr.

You can get some quite solid feedback on public forums, but it requires the correct attitude. With yours, you have already pissed off about half of the potential commenters before they even started to reply.

It's unfortunate that the documentation of these complex chips often leave a lot to be desired. But that's the game, doing what you are doing just requires a lot of practical experience; experience on dealing with those chips and their style of documentation.

Thousands of pages of reference manual?

I always start a big project by reading most of the reference manual. Actually reading 1000 pages out of 3000 is typical. You do what you need to do, it takes a week or two. Then you read it again many many times while developing.

This is why I really think your project needs an experienced design engineer. For you to solve it, you'd need:

1) an attitude change, to allow learning process to start happening
2) a lot of time to do the learning.

After that, you'd be able to get better help, this forum included.

Now your "specific questions" that you want "exact answers" to, are actually far from exact and specific, you are just lying to yourself. What you really need is a wider consideration of your actual problem, i.e., the thing everyone here is trying to help you with. And an experienced designer.

I know that venting the frustration caused by dealing with poor documentation is necessary, but try to get past that point; at some point, you need to accept the reality and start getting some serious work done.

[Marco]

An sorry, Xenomai does not do what I call "accurate I/O" (nanosecond range jitter).

The PRUs on an AM33xx are much easier to guarantee bit-banged I/O timings for than a Sharc DSP core. A Sharc core is more modern and has a cache hierarchy to stuff things up, though bit banging on a Sharc core is a bit silly to begin with.

As for FIFO's, if you are using a build in peripheral (like say I2s, though you might have to make your own driver for it) it's simply going to be cycle accurate. Picosecond range jitter.

[Rasz]

Why have I to justify myself about the numbers where these are not relevant for the question itself ? Have I to prove I'm smart enough to have done my homework and conclude that they are not suitable ?

You already proved some things
-you want to program MAX10 flash with microcontrollers(?!?!), and somehow this disqualifies FPGAs completely
-you mention jitter and picoseconds/nanoseconds, like an audiophool

And for the video example, Linux does not do a lot, a dedicated hardware does. Linux is incapable to guarantee better than microsecond range in one I/O with multi GHz ARM A57 cores but magically can do picosecond timings in video ?

-you somehow have this idea of linux based systems bitbanging I/O???


DSP is DEAD. Its only holdouts are hard realtime with big performance requirements, basically SDRs in military/communications gear, and niche high end real time audio gear (effect rack mounted systems like antares, hundreds of channels audio consoles, etc), and of course the audiophool market. Those are Analog customers, and prices reflect that. Are you ready to drop $.5K for a dev kit, and couple grands more respectively for software and basic support contract? maybe even NDA for good measure. All that to get ~raspberrypi performance (couple of Gflops).

If you really think BGA is a show stopper, you have some revelations ahead to experience.

This isnt our first rodeo
https://www.eevblog.com/forum/microcontrollers/can-a-hobbyist-use-sharc-dsp's/
https://www.eevblog.com/forum/microcontrollers/anyone-work-with-sharc-processors/

Dont worry, you arent the first victim of DSP marketing :-). DSP was a requiremend 20 years ago, today its legacy niche.

[diyaudio]

The last answer is pretty interesting, but I don't understand fully the sentence. It's not because of the author, it's because of my english level : "its a massive leap with an arsenal of peripherals compared to its gen 4 family". Does it means that the peripherals are much more advanced (I did't know the gen level of all these chips) and some more work is needed to provide tools for them ? This is strange, the SC-573 is being available since at least one year ! Nevertheless, I would be very, very grateful to have some insights about the SC-571 and some mysterious aspect of its architecture, especially how this chip can have an embedded Linux in its ARM core without RAM.

Many thanks in advance for any feedback form Analog !

Jerome.

Ive actually been working on SHARC processors for about a year or so (when time permits), funny I started studying it as a result of my curiosity based on an Ebay purchase you can follow that project here.
https://www.eevblog.com/forum/microcontrollers/my-first-working-audio-dsp-prototype/msg798083/#msg798083

Now, about the SC-573 series, I have no idea why they been marketed as commercially ready silicon??? CLEARLY the documentation is really lacking context and poor compared compared to its predecessors like ADSP21489 which is a wayyyy better read (mind you its 5 years old) ..   with that said, why not use a 4th generation SHARC? they incredibly powerful and very capable processors. The latest SC processor documentation, software and SDK will take "a while" to mature.

By the way I own a ADZS-SC589-EZLITE and never actually used it as the support on the chip is poor at the moment, but things will get better I'm not sure how long its going to take.

look at this thing its a beast compared to the 4-TH generation SHARC!

[diyaudio]

Dont worry, you arent the first victim of DSP marketing :-). DSP was a requiremend 20 years ago, today its legacy niche.

Well, That's your personal opinion. 

[nctnico]

Dont worry, you arent the first victim of DSP marketing :-). DSP was a requiremend 20 years ago, today its legacy niche.

Well, That's your personal opinion. 

No. It is true. The amount of processing power in simple microcontrollers increased more than the amount of processing power needed for simple DSP tasks.

[rsjsouza]

Dont worry, you arent the first victim of DSP marketing :-). DSP was a requiremend 20 years ago, today its legacy niche.

Well, That's your personal opinion. 

No. It is true. The amount of processing power in simple microcontrollers increased more than the amount of processing power needed for simple DSP tasks.

I work with DSPs for almost 20 years. IME the applications for standalone DSPs is shrinking due to the power of general purpose microprocessors and its limited signal-processing abilities that cater to the simple applications such as digital filtering. However, the moment you need more serious processing such as deep filtering or FFTs, your simple ARM MAC instruction does not cut it.

[Rasz]

Dont worry, you arent the first victim of DSP marketing :-). DSP was a requiremend 20 years ago, today its legacy niche.

Well, That's your personal opinion. 

did you just Dude me?   

[diyaudio]

Dont worry, you arent the first victim of DSP marketing :-). DSP was a requiremend 20 years ago, today its legacy niche.

Well, That's your personal opinion. 

did you just Dude me?   

[Siwastaja]

What even is a DSP? 

It was simple 20 years back when people were either thinking in the x86 or 8-bit PIC terms.

DSP was easier to define by including MAC & SIMD instructions, DMA peripheral, etc.

Today all of what was so special two decades back is included in a $1 general purpose MCU which is not called "DSP" by anyone even though it could. So clearly, the DSP name isn't even very usable in marketing.

Products that carry "DSP" in their names do not necessarily offer so much difference. It seems, general purpose MCUs today are like "cheap DSPs" and "DSPs" are "DSPs on steroids", so I feel like the whole DSP term could be dropped. They are just CPUs after all, and their performance on signal filtering applications can be actually evaluated, instead of [ ] DSP  [ ] no DSP checkbox style classification. It was different when the "typical" DSP was maybe 10000x faster than a "typical" general purpose MCU in signal processing.

[Someone]

What even is a DSP? 

It was simple 20 years back when people were either thinking in the x86 or 8-bit PIC terms.

DSP was easier to define by including MAC & SIMD instructions, DMA peripheral, etc.

Today all of what was so special two decades back is included in a $1 general purpose MCU which is not called "DSP" by anyone even though it could. So clearly, the DSP name isn't even very usable in marketing.

DSPs are still distinct products with high throughput while low pipeline length cores, and multiple independent (often intelligent) parallel access memory interfaces. But their application space is being eroded on both ends, CPUs at the low end, and FPGAs at the high end (and power efficiency cases).