SigmaDSP assembly code analysis

Started by BEBSynthesizers 8 years ago10 replieslatest reply 8 years ago1594 views

Hello all,

I have started to work on a crazy project: reversing the SigmaDSP assembly code. I really like these DSP, but I am really pissed off by the "SigmaStudio only" programming concept (plus the extremely bad support from AD, I have to say). Last version of SigmaStudio is seriously bugged, and the help file is completely obsolete.

The idea would be to have an assembler/linker at the end that could be used to replace SigmaStudio.

Is there anybody else on the forum who may have started this work too and would like to exchange information here about these DSP ?

[ - ]
Reply by drmikeApril 3, 2016

A long, long time ago my brother and I created a debugging tool for the SHARC processors which included an assembler.  If there is enough similarity I'll be happy to send you the assembler so you have something to start with.  

In a way it's pretty insane to do this much work.  But it can be a lot of fun and keep you off the streets for a long time.  I suspect you'll need quite a few beers along the way :-)

Dr. mike

[ - ]
Reply by BEBSynthesizersApril 3, 2016

Hi Dr Mike,

thank you for your proposal, but the SigmaDSP are completely different processors. They are fixed point (Q5.23), and they even differ from the 21XX.

And yes, it's aboslutely insane, but after just a few weeks, I have already been able to get impressive results just by optimizing the code compared to what SigmaStudio is generating (what AD calls "compiling", but it's absolutely not compiling at all, it's rather similar to linking pre-coded blocks and derive the RAM address they use)

[ - ]
Reply by arangurenjApril 3, 2016


Never done something like that, but... why would somebody need to do something like that? AFAIK, SigmaDSPs are supposed to be "packaged" DSPs which, in conjunction with SigmaStudio, allows to avoid the need for direct (ASM/C) programming of the DSP itself.

The only situation that I can imagine is if you are developing some advanced, non-existing (off the shelf in SigmaStudio) algorithm that you will later on integrate on SigmaStudio and / or sell in quantity.

If you insist in direct programming of the DSP, why not to move to something more open, such as SHARC/Blackfin, even ADSP-21xx?

[ - ]
Reply by BEBSynthesizersApril 3, 2016

There are multiple reasons :

- there is no SHARC with integrated ADC/DAC

- there is no SHARC in a similar price range

- ADSP-21XX are only 16 bits, while the Sigma are 28/56 bits (I am a long time programmer of the 21XX, and believe the difference with the SigmaDSP is simply terrific)

- most algorithms delivered within SigmaDSP are pretty bad or not optimized at all. All oscillators are non band-limited for example. Take also the sawtooth oscillator : you can not play with the phase for example, except by doing incredible processing by yourself, while a simple bitmask would do the job for a wrap-up. Other example : the AND/OR/XOR are not working on Q28.0 words (they only consider the values as 0 or not 0). I have hundreds of example like that

- when you look to the generated code, it's not optimized at all. The DSP loses a lot of processing power in reading/storing variables

- SigmaStudio itself is a pain, the help is a pain, it's not updated to include the last modules, and when you finally understand hwo to use them, you discover they are not what you need

AD is locking the ASM programming in order to protect their IP (and the IP from Dolby and other "partners"), but it hides the real processing power of these chips.

And yes, the situation is exactly the one you are describing : I need  algorithms for sound synthesis that do not exist at all in SigmaStudio. And switching to other DSPs would be a killer for my application (the price of the module would double, without including the fact that I would probably need to update my IDE from VisualDSP++ to the new one...)

[ - ]
Reply by CrandlesApril 3, 2016

I've actually done a bit of programming in assembly for the Sigma200 (only minor tweaks to update prexisting code though). I inherited a project where the people before me didn't like the prexisting code so they wrote their own modules. Have you tried creating your own custom "modules" to use in SigmaStudio? You might be able to hack-open some of their pre-existing libraries to figure out how to write your own. I remember the files I had to update were just .xml files containing assembly.

[ - ]
Reply by BEBSynthesizersApril 3, 2016

Hi Crandles,

what do you call the Sigma200? I only know the ADAU14XX and ADAU17XX or the AD19XXX series from AD, I don't think there are other models.

The method you describe is very interesting and differs from mine. Up to now, I have investigated the code generated by SigmaStudio, by adding one module at a time, checking the binary code generated and understanding what it does and then deduces the format of the binary instruction.

I took a look at SigmaStudio itself a long time ago to try to find how their DLL were working, but I remember I could not see the assembly generator. Maybe that could be a way to gain some time if you remember how you are/were doing that.

[ - ]
Reply by CrandlesApril 3, 2016

Sorry, I can't remember exactly what chip it was unfortuantely. I think it was either mid or low tier as there was also a Sigma300. It's been awhile but IIRC the instruction set format was pretty limited. I think every command was something like:

accum0 = coeff[0]*accum1 + coeff[4]*data

The commands were of that format even if you wanted to do something like to toggle a GPIO pin. My DSP programming of assembly is pretty limited so I'm not sure if that's a common practice or not...

Also, (this might not be useful at all) you couldn't have comments in-between the lines where you declared the coefficients...

I'm not entirely sure how they store the data in their library modules but if they're anything like the ones we wrote then they would be assembly themselves with some XML type tags indicating what to call the module in SigmaStudio as well as how many I/O ports to add.

Not sure if any of this is useful to you but good luck!

[ - ]
Reply by convolverApril 3, 2016


What AD DSP processor are you using?

I don't have any experience with these DSP chips.

However. I do have assembly language experience.

I worked on an assembly language project recently for

a pic micro-controller project. The deevice is from microchip.

If I had the specs to your chip and the assembly language instruction 

mnemonic guide.  I could help you out with your assembly language coding to replace the  software development that this package of yours can't do.

send me an email: mathcentia at gmail.

I will look into it and email back to you 5-6 hours after I get the package.

Geoff Ross

B. Eng

[ - ]
Reply by BEBSynthesizersApril 3, 2016

Hi Geoff,

the chips I am using are the SigmaDSP. The problem is not that I do not know how to program in assembly (I do that since a very long time on SHARC and 21XX)

The problem is that Analog Devices does not publish any programming detail about these DSP and force you to use their development tool called SigmaStudio (see my original post)

So simply said, there is no assembly language specification at all.

And that's precisely what I try to do...

[ - ]
Reply by convolverApril 3, 2016

Wish I could help you.

Its like a car without a hood.

This is the first time I heard about DSP chips without the assembly language instruction set specification.

But in this day and age I am not surprised.

People don't want to learn that way down at the machine level.

Also, companies don't want the little population of people that do understand low level machine architectures to view their hardware.

The problem is they design buggy high level cross-compilers.

Good luck!!