ΣSigmaStudio Ask AI Русский Log in

Strange result from small addition to an existing project

SigmaDSP & SigmaStudio KJBob Oct 1, 2012 00:00 11 replies Original on forum ↗
Subscribe
KJBob Question
Oct 1, 2012 00:00

Hi,

My overall project has been though many revisions, growing to near the ADAU1701's capacity. After adding the two blocks circled below, instead of normal output the three used DACs all produce a shrill white noise.

The instruction count after the addition is 1008 (still OK). The added blocks are not in the audio path at all, instead they're intended to improve the performance of a tone decoder. Removing the offending blocks restored normal operation.

To troubleshoot I cut and pasted the tone decoder into several tiny projects with only a few other blocks, with inconsistent results. For example, the schematic below did not work (made the white noise) until I deleted the circled blocks (replacing them with a direct audio path). Compiling-downloading without these blocks stopped the white noise. Then I clicked the undo button a few times to restore these blocks, and compiled-downloaded again. Unlike just previously, this time the same schematic did not make the noise. The attenuator output is shown feeding a null T rather than the desired signal_add, as sometimes this change itself stopped the white noise (but not at first).

After installing the latest beta version of SigmaStudio, I rebuilt the small project with the tone decoder from scratch (not cutting and pasting from the full project this time). This version works. Somehow I remember running into the same white noise when adding stuff to my main project some months ago, when it was a lot smaller than it is now. I also worked around it then by redrawing the project without all the additions, deletions, and tests the original project file went through. Then I could continue on. I'd hate to have to redraw my entire project now, however, it would take a whole day. Anyone else had this problem? Is there an easier fix?

compiler

white_noise

a507cb6172de2914f33320f585feac96.jpg
a507cb6172de2914f33320f585feac96.jpg
a507cb6172de2914f33320f585feac96.jpg-450x312.jpg
a507cb6172de2914f33320f585feac96.jpg-450x312.jpg
b30d0c80fc14b9e0592f8dafa8cc1425.jpg
b30d0c80fc14b9e0592f8dafa8cc1425.jpg
b30d0c80fc14b9e0592f8dafa8cc1425.jpg-450x276.jpg
b30d0c80fc14b9e0592f8dafa8cc1425.jpg-450x276.jpg
ADIApproved Reply
Oct 2, 2012 00:00

Hi Bob,

There is a small piece of framework code in the ADAU1701 (in fact, in all SigmaDSPs) that runs at the start of each processing cycle. I wonder if this code is actually preventing the ADAU1701 from being able to execute all 1024 instructions within the span of a single frame.

By the way, since version 3.0 or so, the termination cell is not required for unused outputs. Removing the terminators will probably not buy you anything, but it will help to reduce screen clutter.

KJBob Reply
Oct 3, 2012 00:00

Hi Brett,

Thanks for your insight on high-MIPS projects. To be safe I'll try to stay at 1000 out of 1024 instructions, although a few more may still work.

Just in case a SigmaStudio programmer at ADI is sufficiently curious, I attached two small test projects. The second one (with the "5" in its name) was directly made from the first by deleting a few blocks, right away restoring by undo, then saving with the new name. The first one (named with the "4") produces white noise when loaded into a -1701MINZ, the other one doesn't. The two projects compile to similar but non-identical DSP code, confirmed by examining the export files. Though not a serious difficulty, understanding why this happens may prove helpful to their work in some way.

Bob

ADIApproved Reply
Oct 3, 2012 00:00

Thanks very much Bob. I realize that my first response might provide some anecdotal insight but not a real solution to the problem. I will look at the projects you attached and, with the help of a SigmaDSP programmer, try to figure out what exactly is the source of the problem.

KJBob Reply
Oct 8, 2012 00:00

Brett,

A quick update: I did redraw the whole thing which proved worthwhile anyway. It worked fine as expected. When I added the T junction, gain, and adder shown below left, it started hissing again. When instead adding only the parametric filter on the right, it was fine:

I'm not sure yet but the latter arrangement may do what's needed, so I'm back in business. So this may become moot except for curiosity as to why this happens. I'm very familiar with both curiosity and hissing (see my avatar).

Bob

d46993adf94ca1a18af5d7cd7a7a2463.jpg
d46993adf94ca1a18af5d7cd7a7a2463.jpg
d46993adf94ca1a18af5d7cd7a7a2463.jpg-550x167.jpg
d46993adf94ca1a18af5d7cd7a7a2463.jpg-550x167.jpg
ADIApproved Reply
Oct 8, 2012 00:00

Hi Bob,

I just thought of something you might be able to try in order to see if this is actually related to your signal flow or if it's somehow related to being close to the limit of available instructions in the DSP.

Would you be able to take the hissing version from your most recent post and delete some unrelated cells from that project (for example, if there are any processing blocks in a different audio signal chain)? If you could reduce the program instruction count significantly but the hiss remains, we can conclude that it's something in the arrangement of the cells that is causing the problem, rather than the fact that you're up next to the instruction count limit.

KJBob Reply
Oct 9, 2012 00:00

Hi Brett,

My difficulty does not seem to be related to project size. The project without the white noise has a few more instructions (999) than the one that hisses (996). Also, removing some 100 instructions didn't help. The bad one (above, left) was an attempt to introduce a simple pole-zero (or lag-lead) compensation to the loop. This I know how to figure but it caused the hissing problem. The other one that works substitutes a parametric filter set to slightly boost the response above the critical frequency. That one is beyond my ability to analyze -- instead I used the simulation stimulus/probe to obtain the desired gain and phase response. It's working well.

ADIApproved Reply
Oct 9, 2012 00:00

Bob, thanks for the detailed analysis. This puts me at a little more ease because at least it's not pointing to some kind of SigmaStudio-side compiler issue or a SigmaDSP-side "MIPS-over" condition that might be occurring. It's probably related to your PLL design (which, I have to admit, I don't really understand all that well!).

KJBob Reply
Oct 9, 2012 00:00

Brett,

Thanks for having a look at this one. It appears that the answer to mixing the first-order filter with the straight gain to produce lag-lead compensation is the punch line to, "Doctor, it hurts when I do that!"

KJBob Reply
Nov 11, 2012 00:00

Hi Brett,

I just discovered that substituting a homemade first-order filter for the stock one stops the white noise described above. In the image below, the left circuit I had originally used causes hissing in some cases, while the equivalent filter on the right does not.

Bob

c987447172d818e935479ac57177b18a.jpg
c987447172d818e935479ac57177b18a.jpg
c987447172d818e935479ac57177b18a.jpg-506x241.jpg
c987447172d818e935479ac57177b18a.jpg-506x241.jpg
ADIApproved Reply
Nov 12, 2012 00:00

Hi Bob,

Thanks for the debug work. Just to confirm, this is running on an ADAU1701, correct?

KJBob Reply
Nov 12, 2012 00:00

Hi Brett,

Yes, it's a ADAU1701. Where I work we like the -1701 for the same reason we like single-chip microcontrollers -- the high-speed digital stuff with its layout and EMI issues stays inside. That's why I'd like to see a Sigma DSP with both a high-end core and a 2-in, 4-out internal codec similar to that inside the -1701.

Bob