ADAU1701 Core Instruction Set

Hello leonxp,

Welcome aboard! SigmaDSP is different from microcontrollers and DSPs you may have used.

There's no assembler or C compiler, thus the instruction sets are (thankfully) not accessible to the

system designer. Instead these DSPs are fully programmable using the SigmaStudio Graphical

Development Tool, see:

http://www.analog.com/en/content/CU_over_SigmaStudio_graphical_dev_tool_overview/fca.html

The SigmaStudio IDE allows you to build your signal flow as a schematic diagram. Drag and

drop blocks and connect with wires. You have access to simple DSP functions like add and delay, to

build filters from scratch if you want to. Or use ready-made bi-quad and FIR filters, oscillators,

dynamic processors, etc. Available blocks depend on the target chip, the -1701 is fine but higher

performance SigmaDSPs can use a larger set of blocks. After drawing your schematic, SigmaStudio's

compiler converts it into instructions and parameters to load into the chip. Unlike instructions,

parameters can be manipulated by us; they are your filter coefficients and such.

The core handles 28 bit audio samples (56 in double-precision mode), but instructions are

coded in 40 bit (five byte) words. The ADAU1701 can hold about 1000 instructions, enough to handle

many audio functions in one system. For each of 48000 audio samples per second, the chip runs up to

1024 instructions, thus working at 49.2 million instructions per second (roughly 50 MIPS).

All instructions and data get stored in internal RAM, there's no external address and data

buses and you need not worry about how instructions are fetched. SigmaDSPs are volatile and need

some form of external nonvolatile memory to boot. Some models (including the -1701) can boot from a

small external E2Prom, others need a microcontroller whose program (among other tasks) loads the

SigmaDSP at power-up via a serial method such as I2C. Often programming that micro to boot the DSP

and then send new filter coefficients (when the end user adjusts a parametric EQ for example}, is

the most challenging part of designing with these DSPs -- especially for analog types like me, I

spend most of my C programming time chasing lost semicolons. SigmaStudio includes some tools to

help with microcontroller programming.

SigmaDSPs are optimized for stream-oriented audio post-processing with refreshingly simple

programming. They are limited in some capabilities, for example they are not well-suited for

frequency domain work such as the FFT. However, their utility keeps expanding with each new release

of SigmaStudio. Version 3.x is getting long in the tooth, I'm breathlessly waiting for ver. 4.0. If you need more power than SigmaDSP offers, you can always go swimming with the Sharcs (sorry).

Hope this introduction is helpful. To learn more -- Check the AD wiki:

http://wiki.analog.com/resources/tools-software/sigmastudio

You can also search within the forum or ask more questions. Several expert AD application engineers (I'm not one of them) monitor the forum and will happily answer questions. They have helped me a lot.

Best regards,

Bob

Thanks for fielding this question, Bob!

Leonxp, if you have any additional questions, feel free to start a new question thread.

Bob thanks so much for your reply. I know that SigmaStudio provides me tools for program my DSP in a very easy way, but I'd need to know how, an action performed in the software, is translated in program line. I try to see the content of program lines downloaded to my DSP, or just decoding the instruction downloaded in the E2PROM when I use ADAU1701 in selfboot mode, but I can't figure out what those lines mean.

Composing a Schematic of just an input linked to output (connecting in a properly way DAC and ADC, based on Chip specification) and exporting System Files, I can read the 1024 instructions downloaded to the Chip (which are all exectuted every sample processed by the DSP) and I find out many sort of what I think should be Noperation (0x00 0x00 0x00 0x00 0x01) and 7 other lines I can't decode.

If there was a list of operations of the Chip instructions set I think I could easly understand what they mean. I'd need to know this to trying to improve RAM utilization when more complex programs are downloaded into the Chip.

I tried to seek for 50MIPS specifications, but what I found are 50Mips working at 32bit or 64bit per instructions (unuseful for me at the moment).

I hope someone who worked on the developing of the Chip ADAU1701 may teach me what are the instructions that Chip can perform (I'm talking about Machine Instructions or ALU Instructions like ADD, DIV, ...).

Thanks to all.

Regards.

Hi Leonxp,

The core instruction set of the SigmaDSP processor cores is not publicly available for several reasons. Here are a few examples:

One reason the instruction sets are not public is because of license agreements we have with our third-party algorithm providers (Dolby, BBE, Waves, etc.). For example, Dolby Pro Logic II is available as a licensed algorithm on SigmaDSP. If the instruction set of the core is known, then a user could read back the program RAM and reverse-engineer the Dolby algorithm, thus compromising the security of Dobly's code. For this reason, Analog Devices has agreed with Dolby and other algorithm providers to not make the instruction set available in order to their intellectual property.

Another reason that the the instruction set is not public is in order to respect and protect the IP of our customers, who often implement novel signal processing flows within SigmaStudio. Publicly releasing the core instruction set would compromise the integrity of our customer's signal processing, allowing their ideas to be reverse-engineered and duplicated by competitors, regardless of the DSP platform used in their systems. So, we keep the instruction set private in order to help protect against product cloning.

You are correct that the 0x00 0x00 0x00 0x00 0x01 instructions are NOPs. These are necessary in the ADAU1701 (but not in some other SigmaDSPs) because it always steps through every program instruction in RAM during each audio sample, with a hardware program counter reset occurring at the end of the frame. For this reason, it is necessary to write the full program RAM contents when you boot the ADAU1701. A good rule of thumb is that you should duplicate the exact register/RAM write sequence as SigmaStudio when booting your system.

The compiler assigns parameters and allots data memory when the project is compiled, so there should be no concern for memory optimization. This is handled in SigmaStudio automatically.

As Bob explained, the MIPS calculation is simply the number of instructions (1024) times the sample rate (typically 48 kHz), which results in 49.152 million instructions per second (MIPS). The instruction word length is 40 bits. The audio data word length is 28 bits, encoded in 5.23 fixed point format. The parameter word length is also 28 bits in 5.23 format.

Thanks BrettG!

Hi Leon:

I was wondering why is so important for you to know the SigmaDSP instruction set. I understand that you want to do some memory optimization but can you share a bit more of your application? Perhaps there are other ways to help you do what you are trying to do. If you prefer to send me a private message, please do so (this Forum supports sending private messages)

Regards

Miguel

This thread is quite old, but the question is quite recursive, so I think it's interesting to provide some details related to the original question.

1) How the program RAM istructions are fetched and executed?

The SigmaDSP (at least Sigma100 and Sigma200) are sometimes called "streaming DSP". They have a very specific instruction set without branches/sub routine/stack. Every time an interrupt is generated from ADC/DAC, the 1024 instructions (for ADAU1701) are executed, from address 0 to address 1023.

For each instruction, there is a condition code which says if the instruction shall be executed or ignored (replaced dynamically by a NOP)

In other terms, the SigmaDSP ignores some instructions depending on the condition associated to them rather than jumping over them (like a microcontroller would do). In all cases, whatever the test results, the program is 1024 instructions long between two interrupts.

If you look to the binary code generated by SigmaStudio, you will see that many instructions end with 0x01 (on rightmost side). The 0x01 means "always execute".Instruction 0x00000001 is "Unconditional NOP" for example (sounds weird, but that's how the SigmaDSP sees it)

Instructions ending with something else than 0x01 are condition related instructions. They are executed only if a given condition is met.

2) What's the instructions set of the core?

As explained by ADI, the instruction set is not public... which does not mean that you can't see it

Note however that the SigmaDSP instruction set is very different from what you may expect if you know microcontrollers or even SHARC DSP, since the instruction set does not have anything related to jumps/calls or stack related processing.

You don't even have "standard" accumulator load instruction.

The SigmaDSP are using MAC (Multiply and ACcumulate) almost everywhere (to give you an idea, to load an accumulator with a parameter, you have to code something which looks like accumulator=accumulator+parameter[x] * 1. There is nothing like accumulator=parameter[x]).

Consequently, writing a SigmaDSP program is far from being straightforward if you see it as a kind of microcontroller

Since SigmaDSP do not have any stack (and they have a very limited program size), they are almost impossible to program in C (or any high level language), and you can only use assembly language. And that's what SigmaStudio does too: it generates assembly source code from the graphical interface (each module in the toolbox generates a pre-programmed sequence of assembly instruction, SigmaStudio then calls an assembler to generate the binary code)

Technically, it's not complicated to write an assembler for the SigmaDSP once you know how instructions are organized. The main problem is mainly that you will need to write the whole program in assembly, without the help of SigmaStudio blocks.

3) I read, from datasheet, that the core should be a 50MIPS 28/56 bits and that a program RAM instruction has 40 bits. My question is what the hell does this mean? An istruction of 40 bit in a core that works at 28 or 56 bit, how is it possible?

Simply because the memory width is not the same between PM (Program Memory) and DM (Data Memory)!

And SigmaDSP are not the only one like this. Take AVR microcontrollers : instructions are 16 bits wide (2 bytes), while data are 8 bits wide (1 byte)

Same thing for SigmaDSP : each data uses four bytes, while each instruction uses five bytes of memory

SHARC also use a similar approach : they are 32 bits DSP (data are four bytes), but each instruction is 48 bits wide (6 bytes)

Once again, it's because you see those DSP like "classical" processors, with a unified memory approach.

And a final word for mmmike :

Sorry to say that, but SigmaStudio is far, far from generating optimized code. There is simply no optimization performed by the tool (who generates concatenated sequence of code from related blocks, no more, no less).

And I do not even speak of functionalities which are almost impossible to code from SigmaStudio (try to program a PM oscillator, like the one you can find in "FM" music synthesizers - which is in fact Phase Modulation, not Frequency Modulation)

I have made some tests when I was designing the Horus DSP synthesizer module.Using assembly and manual optimization, I have been able to save 5 to 10% of program memory compared to what SigmaStudio does (plus being able to do things impossible to program from SigmaStudio)

Hi Ben:

Thank you for your deatailed post.

Some clarifications:

The Sigma200 core does have branches AND loops but you are correct that for the most part it functions sequencially.

The 40 bits is the opcode word length for the 144x however it varies depending on the size and memory of the SigmaDSP. Why is this such a concern to you, if I may ask?

The optimized code I refer to is per algorithm basis. I agree that once algorithms are instantiated, no further optimization is done post linking.

In any case the SigmaDSP is great for what it does and it's not great for what it doesn't. We accept it has limitations however I'm not sure if it was ever mentioned that it can produce the most beautiful and optimized code.

Can you explain your application?

Regards:

Miguel

PS. the Sigma300 (145x and 146x) have a completely different architecture closer to what you are expecting from a general purpose DSP (with interrupts, stack...) yet preserving the stream oriented architecture for latency critical application.

Hi Miguel,

since the original question was related specifically to ADAU1701 (which is a Sigma100), I concentrated mainly on it for the answer to Leon.

I don't understand your remark about "my concern about 40 bits opcode". I was just answering to the remark from Leon about the size difference between PM and DM, no more no less.

Now back to the main topic of your answer : as I explained, the way SigmaStudio works makes it unable to optimize anything. The problem is that there are a lot of load/store operations involved which could be avoided using direct assembly programming. Since the ADAU1701 memory is quite limited, the chip performance are a bit degraded compared to what can be done using pure assembly.

Beside this, I fully agree with you : the Sigma do very well what they are intended to do (signal processing). The optimized hardware is simply a killer, and the ADAU1701 running at 50MHz performs much better than a generic micro at the same frequency (including "ARM with DSP capabilities" ones)

Once again, the limitations I see do not come from the SigmaDSP itself, but from SigmaStudio. I am using the ADAU1701 as main processor in one of my products (just take a look here to see what it is : http://www.imodular-synth.com/) because it is perfectly adapted to this application in terms of peripherals. But algorithms used in music synthesis are quite hard (and sometimes simply impossible) to write using only SigmaStudio (and they require some assembly code tweaking)

Just to be clear : I *really* like the SigmaDSP, my idea was not to criticize them here. Just wanted to explain their "limitations" to Leon (and other visitors, since the question of assembly programming comes very often on forums related to the SigmaDSP)

Hi Ben:

I was only reading your answer when I read the 40 bits concern I didn't realized it wasn't yours. I really like your product. I wish you send samples .

On the optimization, we can certainly recommend 3rd parties to create libraries based on non-optimized SigmaStudio schematics if this helps.

Thanks for the positive words on the Sigma.

Miguel