Post Go back to editing

Compile numbers

Category: Software
Product Number: ADAU1467
Software Version: 4.7

I have a somewhat large program, and wanted to see if this complier message should cause any concern.  The program compiled without error, and most specs on RAM and INST RAM seem comfortably under limits. But I do see 128% listed under INST Cycles.  I am, however, running 4015 at 32 bit.  The program downloaded fine and appears functional.  Thanks!

Thread Notes

  • Hello ElsaDog,

    The compiler output shows you are exceeding the MIPS. If you want to examine the MIPS usage, you can use the framework called 'monitor overrun' which reads a register from DSP and tells you the used and available instructions per sample period. This framework does take some instructions to run but it's very helpful to know the MIPS usage, since it reads from the hardware register (program implemented in the DSP code), it's almost accurate.

    Below is link for the post, where Dave explains about it.

    ADAU 1452 Multirate instruction cycles and program overrun - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone

    Regards,

    Harish

  • Hello ElsaDog,

    As Harish noted, Read my old post which goes into a lot of details. 

    One of the things I did mention was what happens with this processor core when there are too many instructions?

    First let me explain what happens when there are extra cycles and the program is shorter. The program executes all the instructions then goes into hibernation waiting for the next Start Pulse. The Start Pulse is the sample rate clock. So when a new frame edge hits, the program counter is reset to instruction zero, then starts executing the instructions until it reaches the end and then hibernates. 

    Works great!

    Now, if there are more instructions then there are internal instruction clock cycles, then what happens is that you are executing instructions but you are not at the end of your program yet, the LRCLK sample rate clock edge hits! The instruction pointer is reset to zero and it starts executing from the start of the program. So the end of the program is never reached!! Since usually the end of the program is where you assign the sample to an output port, what happens is that some outputs have no signal. That is the best way to see it. It all depends on how the compiler compiled the program but usually it is an output that gets skipped. 

    So the program somewhat works. 

    By the way, for anyone reading this who uses an older Sigma200 or Sigma100 core, like the ADAU1701, those work differently!! What happens with those is that the new LRCLK edge is ignored!!! The program HAS to finish before the start pulse reset is active. So this means you run past the sample period then finish and wait for the new sample. Well, you end up skipping samples!!! You process every other sample!! That makes for some interesting audio artifacts and distortions. 

    Dave T