PS:cores as in units the system can do computational operations on.

The 3 memory busses were the real strength of the DSP.
But 3 separate exclusive buses this does not match the AMIGA design.
And implementing today three buses makes nos sense at all.

Please understand that a DSP without its local buses is NOT better than a generic CPU.
 
A DSP makes only sense if you build the whole system design around it with several independent memory buses.

The same with the Falcon, it would have a been a lot sexy computer with a real 32bits memory bus (and a working Mint, monotasking in TOS was no way for me)

The Amiga is built around the concept of using specialized co-processors. If you want generic cores, get a multicore PC. Each core is a general purpose brute force monster. This is like the winmodem debate.

Moreover, if we want realistic audio positionning with HRTF or Ambisonic, or a feature such as wavetracing, it requires a dedicated co-processor, this is why sound cards by Aureal had a good DSP on board (Motorola 56362).

> If we want to make Natami a powerful system, we first have to overcome the most obvious lack of Amiga nowadays: Generic computing power.
I strongly disagree. It is true that the Amiga has a lack of CPU power, however, if we hardware accelerate everything, this lack of power, while still there, will no longer be an issue.

> Also DSP instruction encoding can be different to a CPU, i.e. general code density not so important.. VLIW making sense, etc..
This is another important point: VLIW.

Finally, there is the on-board SRAM which boosts the performance, moreover, if the SRAM is dual-ported, the DSP can do transfers between the external memory and the SRAM while at the same time working on said SRAM.

If developping a m56k compatible DSP is too much work (even though I find it useful to support programs using the Delfina m56002) here are two proposed other approaches.

First, there are DSPs available as VHDL code, it can be used as a starting point.

A second option would to use a downstripped N68k as a starting point. Take the 68k as starting point and do the following:
Remove most of the integer unit (keep only the address registers and the EA-unit)
Remove the FPU
Keep the SIMD unit
Add a dual-ported local SRAM
Make sure the processor only sees the SRAM as it's memory
Add a DMA unit to transfer data to and from the SRAM in parallel of the SIMD unit using the said SRAM.
Make sure said co-processor is used for audio only

This design would allow re-using the design of the 68k SIMD unit, while the first suggestion (use an existing DSP VHDL core) has the advantage of supporting VLIW. We seem to have a DSP calculation specialist on board (Denis Markovic), maybe we can have him determine which extra instructions are useful for sound processing.

So, again, there's no need to have a separate, and specialized DSP.

SIMD unit is quite general purpose to handle music tasks too, if need.

Audio processing should be done on a decicated unit to make sure it will never be stopped by another process taking over.

Moreover, if you are making a soundtrack for a movie, you will have to be able to decode the video in realtime with passable quality while playing back audio tracks mixed in realtime with added effects. If you miss a video frame, the world will not end, but if you miss a single audio sample the world will end: it will result in an audible glitch.

The DSPs on the M-audio and EMU soundcards are there for a good reason. Same thing for the DSP cards on a Pro Tools HD system.

For gaming audio, things like HRTF and wave cannot suffer the incertitudes associated with multitasking, otherwise there will be glitches in the audio, moreover, it will use 100% of the power of a dedicated unit (it requires a high enough processing power to justify a dedicated unit). The Aureal SQ3500 was a good example of this sort of good gaming audio, it provided hardware accelerated wavetracing and true HRTF.

Audio has always been the single weak point of the Amiga. Another thing to keep in mind: we cannot beat a modern computer and GPU for graphics. We can easly beat a modern computer system when it comes to sound. High audio capabilities do not need high clock speed and the total necessary processing power is much lower than for high-end graphics. We should pursue this objective.

As I said, if designing a m56k compatible DSP it too much work, we can take an existing VHDL DSP and integerate in the design (or make our simple 68k derived DSP).

I think that the same can be made with the SIMD coprocessor.

I was referring to the "Robin" processor, which will be 68K based plus SIMD unit added to delegate heavy calculations.

And it's a coprocessor into the Natami system, because the CPU is the N050/070.

I agree with you. For professional audio software, dedicated processors are needed to ensure time-critical audio handling.
Even software on the most expensive audio workstations available today fail sometimes simply because they are multitasking the audio tasks with the system or other software.

The programmer could use one or more Natami 68k subcores entirely dedicated to processing audio if needed. For example, one subcore entirely dedicated to a software synthesizer. With the solution Claudio Wieland is proposing for the subcores, multitasking on an individual core is possible, but not required. So one or more 68k cores could become your 100% solid "DSP chip" :)

> So one or more 68k cores could become your 100% solid "DSP chip"
Only one powerful co-processor is needed for audio.

Using the 68k as a starting point may not necessarly be a bad approach, however, if using the 68k as a base for an audio co-processor, it should not be a vanilla 68k. It should include two sets of modifications:
1 Addition of on-board dual-ported SRAM
On-board SRAM would boost performance.
The core should only see its SRAM, not the distant ChipRAM
A DMA unit should be added to do transfers in parallel, between the SRAM and the NatAmi ChipRAM.
Without local RAM, the unit would have to work on the NatAmi ChipRAM which would be slow and for which the bus is shared with other components which means that there would be a bottleneck risk.
As others said in this forum topic, local SRAM is one of the things which give a DSP a higher performance than a generic processor for DSP tasks.

2 Remove everything unnecessary for an audio DSP
This includes things like, for example, 64 bit floating point instructions (32 bit is enough for audio).

Its a pity that instead discussing requirements and possible solutions some proposals seem to be based on misunderstandings of so called facts.
 
Without a clear understanding how the AMIGA works, how caches work, or knowledge of the instructions set of the 68K CPU - how can you make a good proposal?
 
 
 

Amiga Believer wrote:

The concept of subcores is not the best idea,

Well this is just your opinion.
Many will say that sub-cores are the most flexible and easy to program, and faster to develop than any other solution.

 
 
 

Amiga Believer wrote:

Moreover, an audio co-processor should be connected to ChipRAM while a "subcore" would likely be connected to FastRAM,

No one said that sub-cores are connected to the FastRam only.
There is no reason why a Sub-Core should not be able to work on Chipmem.
   
 
 

Amiga Believer wrote:

It should include two sets of modifications:     On-board SRAM would boost performance.

Data-Cache gives the same performance and is so much more flexible and easier to code for.
You need to explain us where the benefit of "plain" SRAM would be.
   
   
 

Amiga Believer wrote:

... A DMA unit should be added to do transfers in parallel,

 
Well from the system perspective the whole Subcore will work like a DMA unit.
Also an extra DMA unit inside a SubCore will have the same net-effect as parallel execution of outstanding loads. And adding outstanding loads to the 68K Cores was discussed long time ago already.
 
 
I assume that you want to solve problems with your ides.
But its not really clear to me which "problems" are really there.
I also get the impression that there are already solutions for some of those problems.
 

What I'm missing is a clear definition of what performance is catually needed to solve the AUDIO requirement.
 
What DSP model (which MHz) is in your opinion sufficient for this?
Was the DSP used in the Falcon sufficient?

How many MIPS of MFLOPS are needed for these algorithms?
Or if someone would use a dedicated 68030 Core for this.
What clockrate would the 68030 need to have for these routines?
 

Audio is a question of jitter, latency, and several other things.
I assume Claudio already looked into this, at least i hope he did.

How it has been explained to me the sub-cores are a sub-optimal solution for audio.
Then again it hasn't been explained that well nor have i seen the further idea's on them.

Dual ported SRAM is absolutely not a economical viable idea.
And Amiga Believer read the SIMD thread, the SIMD would have common components with the FPU so, you might want to re-think the striped down m68k.

What requirements do we really have:
- How much integer MIPS?
- How much MFLOPS?
- How much memory bandwidth?

We should also rethink if this is just a software requirement.
Maybe the real-time requirements could be meet with correct setting of Task-priority and or suing interrupts.
Before we talk about dedicated units we should validate whether the obviously simplest solution does work.