Sigma Running out of Steam?
I'm running an ADAU144x on the A/D development board with the usual USB interface. The development board includes a provision to force-clock one of the 1938 codec chips at 192kHz via SPI. The design has a Main board that contains seven Hierarchy boards, plus a couple of first-order filter modules and a Multiplexer module also on the main board for a test function. The entire circuit is set to operate at a 192kHz sampling rate, and all rate-sensitive modules have been checked to make sure that the rate has been propagated throughout the system. Everything looks right, and once I compile and view the output file I see that I'm using less than 50% of DSP resources.
One of my outputs off the main board is a 20kHz sinewave, generated directly with a Source/Oscillator/Sine Tone. The trouble is, the actual frequency coming out is one-fourth of that, or 5kHz. If I start removing Hierarchy boards one-by-one and recompiling, at some point the output frequency switches to one-half of what it should be, or 10kHz. If I remove even more Hierarchy boards, so that only a couple of the seven are left, the frequency pops up to 20kHz where it belongs. When 'removing' boards one-by-one, the wannabe 20kHz waveform undergoes a visible change when the circuit is recompiled. You can see on a scope that it's on the hairy edge of changing to the next higher fraction of 20kHz, exhibiting a 'hump' in the waveform that looks as if it wants join in and create a signal at 2X the current frequency. Sure enough, dump one more Hierarchy board and that's what it does: 5kHz becomes 10kHz, or 10kHz becomes 20kHz.
The high sampling rate is necessary because the design processes some signals up in the 60kHz range. But just for drill, I reset all the sampling rates to 48kHz. With all seven Hierarchy boards running, the 20kHz output is 10kHz. I need to remove only a few to get 20kHz out. It's almost as though (thinking now in hardware/analog terms) the clock is being loaded and needs some unity-gain buffers in there. Ideas, anyone?
I wonder if some of the cells in your hierarchy boards are using different sample rates. The simplest point to start debugging this issue is to confirm that all blocks are at the same rate. Please follow these steps:
1. Select the sample rate from the drop down menu.
2. Click the set system sample rate button.
Additionally, you can...
3. Right click the input cell, select set sample rate, and enter the sample rate manually in Hertz.
4. Click propagate sample rate.
If that doesn't fix the problem, let us know. Perhaps there is something else going on with the hierarchy boards.
electrojim wrote:
Everything looks right, and once I compile and view the output file I see that I'm using less than 50% of DSP resources.
The nominal sampling rate for a full program on the SigmaDSP is 48 kHz. If you're running at a 192 kHz sampling rate, which is 4x the nominal rate, then you'll have a maximum of 1/4 of the program resources available. For the ADAU144x, which has 3584 instructions available at 48 kHz, there will be a maximum of 896 instructions available when you run the core at a 192 kHz sampling rate. Make sure that you're executing less than this number of instructions; that may have something to do with the incorrect output from the tone generator.
Yes, these percentages are for a 48 kHz sampling rate. If you are using 192 kHz sampling rate, you cannot exceed 25% of the total available program memory.
Brett: Yes, I performed that exercise and checked everything; the sampling rate is propagated properly; 192kHz shows up everywhere.
Jerad: If what you say is true, then I must be running out of resources at 192kHz. Please check the attached snapshot, which shows the Output file after compiling (at 192kHz). According to what I gather from your explanation of resources, those percentage figures at the bottom reflect 48kHz operation, despite the fact that everything is set for 192kHz. In this case I definitely have more instructions than the chip can handle at this speed. Can you confirm?
Many thanks to you both.
Shouldn't the %'s scale with the sample rate? This sounds like it should be considered a bug in Sigma Studio.
MagicRuB wrote:
Shouldn't the %'s scale with the sample rate?
Since the sample rate used in the DSP core can be change dynamically (that is, simply by setting a register), the compiler actually has no idea of the sample rate currently being used. Therefore it always assumes that you are operating in normal-rate mode, as opposed to double-rate or quad-rate.
Giving the compiler the ability to check the sample rate register is feasible, but I could see that causing other problems. For example, if you compiled a project first in 48 kHz mode, then decided later on - after compilation - that you wanted to run the system at 192 kHz, all you would have to do it recalculate the filter parameters and change the setting of the sample rate register, without requiring a new compilation. In this case, since the compiler is not aware of the fact that you're changing the sample rate after the fact, it would not generate an error. This doesn't really solve the problem.
Perhaps a good solution would be to have the compiler output include three separate lines showing the percentage of MIPS used. One for Normal mode, one for Double mode, and one for Quad mode. The user would still be responsible for checking to make sure they are within the limits of allowable MIPS.
For example:
Instance Mips Inst Data Coeff Other
(max)
Beginning 16 16 0 1
SafeLoadCode 15 15 0 7
End 5 5 0 0
Input1 4 4 2 0
Subroutines called:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 40 40 2 8
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
(% - Normal Rate) 1% 1% 0% 0%
(% - Double Rate) 2% 1% 0% 0%
(% - Quad Rate) 4% 1% 0% 0%
Brett,
BrettG wrote:
Giving the compiler the ability to check the sample rate register is feasible, but I could see that causing other problems. For example, if you compiled a project first in 48 kHz mode, then decided later on - after compilation - that you wanted to run the system at 192 kHz, all you would have to do it recalculate the filter parameters and change the setting of the sample rate register, without requiring a new compilation.
I have to totally disagree. That's like saying after compiling a C/C++ (or whatever language) type project my compiler said I used, lets say, 100k of RAM. Then I modify the assembly executable/hex to change the array sizes and now my RAM requirements changed that I should somehow blame the compile that it didn't forecast that.
At compile time a compiler should tell you your resources with the current settings, whatever they may be. You don't even need to check the double/quad bit, just use whatever sample rate is on the main page. That is what the user thinks the sample rate is and what the system should be configured at anyway, right?
I understand that the DSP can change rates on the fly but I can't imagine that it's considered typical operation. Wouldn't this be considered a rare situation and in most cases the sample rate of the DSP never change? Isn't this what a SRC is for? I suppose you may have an argument for SigmaDSP's with no SRC but if they need variable sample rates then they should use a unit with a SRC, makes everything a million (yes, a million) times easier. Even so, if someone is tweaking on the SigmaDSP to the point they are using a dynamic sample rate and/or core clock then I imagine that this resource issue would cross their mind. Meanwhile, everyone else with static core clocks suffers with incorrect resource values in hopes you assume how it work. </rant>
Does this mean if I set SigmaStudio to 8 kHz sample rate I'm actually able to go up to 600% resources?
MagicRuB wrote:
I understand that the DSP can change rates on the fly but I can't imagine that it's considered typical operation. Wouldn't this be considered a rare situation and in most cases the sample rate of the DSP never change? Isn't this what a SRC is for?
In most cases, yes, the user will pick one sample rate for their system and everything will always run at that rate, with no changes during operation. However, in many portable systems the controller is always performing a balancing act of power vs. quality. In that kind of situation, the same signal flow can be used in several different operational modes but with different sample rates for each mode. For example, when a digital camera is playing back previously recorded audio, the sample rate is high - high quality and high power consumption - but when playing back a beep or GUI feedback sound, the same level of quality is not required, so the sample rate is set lower - leading to lower quality and lower power consumption. Between each of the modes, the core is halted, sample rate is changed, and new parameters are downloaded before playback begins. Typically, the project is compiled first and then filter coefficients for each mode are calculated separately. In every mode, the same program has to be executed, so the user must plan ahead to make the program fit the MIPS limitation in each desired sample rate.
MagicRuB wrote:
Does this mean if I set SigmaStudio to 8 kHz sample rate I'm actually able to go up to 600% resources?
The SigmaDSP's MIPS count in the compiler output represesnts the maximum number of instructions that can be processed by the core when running at a "standard" 44.1kHz or 48 kHz sample rate. Typically, the program RAM size will match this number, because having more RAM will add unnecessary production cost to the chip. Since the core rate is fixed, increasing the sample rate means that the number of instructions that can be processed will decrease proportionally. So, by doubling the sample rate, the instruction count is halved. In theory, decreasing the sample rate, all other things being equal, would allow you to process more instructions. However, since the program RAM size is fixed - and it usually matches the max MIPS count - decreasing the sample rate will not get you more instruction cycles, simply because there is nowhere to store them!
In earlier SigmaDSP generations, such as the AD1940, the sample rate bit actually controlled the program counter and told it to "jump-to-start" at a fixed instruction number. In the newer SigmaDSP generations, such as the ADAU144x, the "jump-to-start" is actually an instruction that is stored in RAM.
MagicRuB wrote:
At compile time a compiler should tell you your resources with the current settings, whatever they may be. You don't even need to check the double/quad bit, just use whatever sample rate is on the main page. That is what the user thinks the sample rate is and what the system should be configured at anyway, right?
In principle, this makes sense, but I have to run it by the software team. The problem is that SigmaStudio might be too flexible. The way SigmaStudio is currently set up, you can have multiple ICs in the project. Each IC can be running at a completely separate sample rate, which is why SigmaStudio treats each cell separately. For example, if I have two ICs in the project, one running at 48 kHz, and one running at 96 kHz, and add the exact same cells to each IC, the filter coefficients will still be calculated independently, which is desired. You can even hook up a single USBi to these multiple ICs and control them simultaneously in real-time, using the same SigmaStudio project, even though they are running at different rates.
The current scheme of selecting a "new item" sample rate and then adding cells for the desired IC allows you to maintain this independence. If there was an overall "project" sample rate, then this independence would be lost. So, in order to make your idea work we would have to put a setting on the hardware configuration page that allowed each IC's sample rate to be configured, and those settings would then propagate down to that IC's cells in the schematic, and of course the compiler would then be intelligent enough to know what sample rate each processor is using.
It's worth noting that the compiler would still have to check that DSP core rate bit. The reason is that the sample rate selected in the project only modifies the parameters that are calculated and stored in RAM. The DSP sample rate bit is really what controls the hardware, and in the end, it is the only thing that determines the actual sample rate of the system.
It sounds quite complicated and I'm not sure how much work it would entail. For now, the idea of including 3 lines in the compiler output (48 kHz MIPS %, 96 kHz MIPS %, 192 kHz MIPS %) might be a good first step in the right direction.
Brett,
It's worth noting that the compiler would still have to check that DSP core rate bit. The reason is that the sample rate selected in the project only modifies the parameters that are calculated and stored in RAM
If the project sample rate sets the DSP core rate bit then this whole thing could be avoided.
...you can have multiple ICs in the project. Each IC can be running at a completely separate sample rate, which is why SigmaStudio treats each cell separately...
Wouldn't multiple IC's dictate multiple resource charts? Just check the currently configured core bit rate and scale accordingly for each chart.
The whole beef I have about this is a "normal" user is given wrong information when the compiler has all the information needed to give correct results. Instead, an advanced multi-sample-rate user is catered to - yet that resource data us practically ignored! The baseline data doesn't even help because he/she should make an assumption that the compiler is telling me my resources for the currently compiled project, not what they will later change it to, and if I do change it then they would be smart enough to scale it themselves when they step up to 192k or whatnot. Catering to a potentially different sample rate is just plain silly.
Please log in to reply.