PlanetZ forums - scopeusers.com

On 2006-05-08 15:28, Shroomz wrote:
Developement time & cost is definately the issue/problem, but CW already have the SDK running on the 150 or 200mHz sharcs, no ??

Hmmm, I don't think so....

<font size=-1>[ This Message was edited by: Shroomz on 2006-08-24 06:34 ]</font>

On 2006-05-09 15:03, Shroomz wrote:
Can you explain that any further John?

Sorry, no...

<font size=-1>[ This Message was edited by: Shroomz on 2006-08-24 06:34 ]</font>

the SDK isn't running on Sharcs - it produces code for them (from an Intel CPU)

On 2006-05-10 14:25, astroman wrote:
the SDK isn't running on Sharcs - it produces code for them (from an Intel CPU)

Sorry, but SDK just loads it's modules on dsp exactly as Scope. It only has a different way to manage them and different functionalities. Or do I miss something?

No, Alfonso, you seem to be correct. From what I can tell, the SDK runs on an Intel, 'compiles' modules for the Sharc chips (takes the graphic routing information and all the properties of the modules and distill them into some format that can be executed on the sharc chips) and once they're compiled, load them onto the card's onboard memory (I would guess) where the Sharc chips can then 'get at them' to run them. In other words - the SDK is a program that runs on an Intel that creates programs for another processor (Sharc). It doesn't run on the Sharcs, the programs it creates DO.

I think Shroomz meant, or could more accurately have said, that CW is able to create programs for, and load programs into, the 150/200 mhz sharc hardware with some version of their SDK. It wouldn't be surprising if all they have to do to port the devices from the old system is to recompile them with their 150/200 compliant SDK.

On 2006-05-10 16:36, Liquid Len wrote:
...It wouldn't be surprising if all they have to do to port the devices from the old system is to recompile them with their 150/200 compliant SDK.

Ah, I wish it was only that easy!

LiquidLen already explained in detail how the developement process works and there's a ton of stuff on pages for those interested in details.

As quoted below the Sharc's binary code is upward compatible, but of course doesn't take advantage of the improved archticture the recent chips have.
Yet there is heavy(!) reworking needed in the 'embedding' control software (see below)

...Symbol name changes from the ADSP-2106x and ADSP-21161
processor programming models
These name changes can be managed through re-assembly using the
ADSP-21161 processor development tools to apply the ADSP-21161 processor
symbol definitions header file and linker description file. While
these changes have no direct impact on existing core applications, system
and I/O processor initialization code and control code do require
modifications.
Although the porting of source code written for the ADSP-2106x family
to ADSP-21161 processor has been simplified, code changes are required
to take full advantage of the new ADSP-21161 processor features. For
more information, see the ADSP-21160 SHARC DSP Instruction Set
Reference...

the full PDF is <a href=http://www.analog.com/UploadedFiles/Ass ... df>here</a>

about some optimizations from <a href=http://www.techonline.com/community/ed_ ... honline</a>

...The new DSP, the ADSP-21161N builds on the Hammerhead, or ADI 2116x, architecture. This microarchitecture extends the basic 48-bit instruction word, 32-bit data SHARC into SIMD operation. For Hammerhead, ADI designers doubled the number of computation units from one to two. Thus a SHARC instruction can be treated as a SIMD instruction and be executed simultaneously in the two computation units. This design tactic can double the peak execution rate for the SHARC and can be particularly effective in inner loops for code that is operating on multiple data sets.

For administrative and control code, it is unlikely that the SIMD extensions will make much of a difference. But, since DSPs spend much of their time in inner loop executions making MAC-based series, that won't matter.

Hammerhead is turning into a successful product. The 32-bit SIMD DSP is now in production and filling board sockets. Board vendors are happy with the DSP because it enables them to build on their existing SHARC expertise and code, while literally doubling performance for tuned inner loops....

cheers, Tom

<font size=-1>[ This Message was edited by: astroman on 2006-05-11 09:24 ]</font>

On 2006-05-10 22:42, johnbowen wrote:

On 2006-05-10 16:36, Liquid Len wrote:
...It wouldn't be surprising if all they have to do to port the devices from the old system is to recompile them with their 150/200 compliant SDK.

Ah, I wish it was only that easy!

Hehe. I guess that some things never change.

On 2006-05-11 06:15, Shroomz wrote:

On 2006-05-10 15:51, alfonso wrote:

On 2006-05-10 14:25, astroman wrote:
the SDK isn't running on Sharcs - it produces code for them (from an Intel CPU)

Sorry, but SDK just loads it's modules on dsp exactly as Scope. It only has a different way to manage them and different functionalities. Or do I miss something?

Alfonso, can you confirm or prove this? I believe you know what you're talking about, but just for anyone who doesn't, any chance you can prove this? Maybe with a small (tiny) screenshot from the SDK ?

cheers

CWA site SDK page, scroll down a little:
http://www.cwaudio.de/page.php?seite=sdk40pr&lang=en

<font size=-1>[ This Message was edited by: alfonso on 2006-05-11 17:18 ]</font>

<font size=-1>[ This Message was edited by: Shroomz on 2006-08-24 06:35 ]</font>

from the CWA link
...The SCOPE SDK is the only development environment for music applications running on DSP hardware with no latency, thus being suitable for live signal processing.

it's not the SDK running on DSP hardware with no latency, but the music applications
I'll buy you a CWA plugin of choice if you can proove LiquidLen or myself wrong

cheers, Tom

On 2006-05-11 17:46, astroman wrote:

from the CWA link
...The SCOPE SDK is the only development environment for music applications running on DSP hardware with no latency, thus being suitable for live signal processing.

it's not the SDK running on DSP hardware with no latency, but the music applications
I'll buy you a CWA plugin of choice if you can proove LiquidLen or myself wrong

cheers, Tom

I just think that there is no difference with Scope under this aspect. Every connection you make and any atom you load happen on sharcs.

No?....

No, there is a program that analyses your lists and graphics that define the device you're working on in SDK and this program 'compiles' (hence the name of such tools) the program instructions for the respective processor, a Sharc DSP in this case.
The program is entirely X86 CPU based - why else doesn't it run on Macs btw

The result(!) is loaded on the DSPs and in Scope SDK that's obviously done immediately, so for you it looks like you're programming the chips directly, but that isn't the case.

There's a tremendous amount of processing done before that final stage, and that processing is what makes the SDK outstanding.
I've dealt with at least a dozen different developement environments, also graphical ones, but none (except National Instrument's LabView*) comes even close to the degree of 'making a graphic into working code' like SDK does.

cheers, tom

* and on a 2nd thought I'm almost certain that the SDK core is either a derivative, or written by someone deeply involved in LabView's developement - or one of the best reverse engineered products ever


<font size=-1>[ This Message was edited by: astroman on 2006-05-11 18:47 ]</font>

I just think that there is no difference with Scope under this aspect. Every connection you make and any atom you load happen on sharcs.

No?....

Yes, exactly, Scope isn't running on the Sharcs either, it RUNS ON YOUR PC OR MAC. If SDK ran on your Pulsar card, how could you use it? The monitor isn't hooked up to the Pulsar card!

On 2006-05-11 18:44, Liquid Len wrote:

I just think that there is no difference with Scope under this aspect. Every connection you make and any atom you load happen on sharcs.

No?....

Yes, exactly, Scope isn't running on the Sharcs either, it RUNS ON YOUR PC OR MAC. If SDK ran on your Pulsar card, how could you use it? The monitor isn't hooked up to the Pulsar card!

Like in all comic masterpieces the source of the fun is when people use the same words ("runs") to mean different things and doesn't take immediate action to stop the misunderstanding...

I know well that Scope and SDK run both on OS's and perform some of their action thanks to the system in wich they are installed, but, with different functionalities and tools, they are basically the same thing.

If in Scope modular I connect a -64 bipolar constant to a ring modulator i get an inverter, I'm performing the same operation as I would in SDK with a bipolar value and a sync multiplier, just in a different frame, but there is no substantial difference in that action from the points of view of the system and of the dsp's.

<font size=-1>[ This Message was edited by: Shroomz on 2006-08-24 06:35 ]</font>

<font size=-1>[ This Message was edited by: Shroomz on 2006-08-24 06:36 ]</font>

On 2006-05-12 02:29, Shroomz wrote:
...Anyone want to prove that there's more code being executed in C or C++ when you run Scope or the sdk??

Alfonso clearly assumed that the SDK code runs on Sharcs, which isn't the case and it has been explained why.
Noone assumed that the Sharcs are unemployed - their specific model is just irrelevant for the developement process.

It's not(!) regarding the code generator (as part of the compiler) and (according to the AD note) the model is important regarding interfacing the host system.

Both these points are low level stuff that isn't even provided with the SDK (there is no Sharc assembler included) the system just chaines precompiled blocks (called atoms).

before you mess it up completely (see quote above), I'm off

cheers, tom