DSP—Why So Hard?

1. DSP—Why So Hard? November 2010

2. Who ? • Peter.Eastty@Oxford-Digital.com • Design and sell processor cores and matching programming environments. • Program strange algorithms onto stranger processors with the strangest tools. • Customers • NDAs • Client lists. • You

3. Why ? • People expensive, Silicon cheap. • People slow, Silicon fast. • People slow, Computers fast. • Programmer efficiency is everything, it gets you time to market which gets you the market.

4. Why ? • Targets move, right up to the last minute. • Never, ever build a fixed function device. • Three stories. • Third party algorithms will have to be adopted whether public domain or highly secret.

5. What is an audio signal? • Known bandwidth • Known resolution • Known number of channels • So why don’t I enumerate them

6. Where ? • Large mixing consoles • Cell Phones • Hi Fi • TVs • iPod docs • PCs • etc.

7. What processing do we want to do to the audio? • Continuously varying value against time • Filtering • Polynomial • Non-linear • Decisions • DSP = Low Delay • Not block structured

8. What hardware resources are available? • Memory • Multipliers • Connections • Adders etc.

9. Data types for DSP • See RBJ on headroom and floating point • Want a fixed point data type. • Word length, 16 – 32 etc. have nothing to do with audio, setup the word-length to suit the audio not a computer.

10. Languages for DSP • C is not a DSP language, the data types are all wrong and it has no concept of time. • C++ could be a DSP language but it doesn’t want to be one, it too has no concept of time.

11. Languages for DSP • With modern hardware design and compiler technology there is never a need for assembler. NEVER EVER. • Of course if you’re tied to old hardware for legacy code reasons you still might have to hack in assembler.

12. Languages for DSP main (…) { ASM(…); ASM(…); ASM(…); } /* This is not C. */

13. Languages for DSP main (…) { Clear_Acc(); MAC(…); Store_Acc_to_Register(…); } /* This isn’t either. */

14. Languages for DSP main (…) { Multiply_by_Coefficient(); Biquad(…); Do_FFT(…); } /* Neither is this. */

15. Languages for DSP • Beware of ‘optional extensions’. • They can become mandatory. • There is still at least one University teaching DSP using FORTRAN and assembler … • ...sad to say they apologized about the FORTRAN.

16. Languages for DSP • I don’t know the perfect DSP language. • But any high level language is better than any machine specific language.

17. Multiple Memory Banks • If there are multiple memories then memory allocation is NOT the programmers job, the tool-chain should do this for you. • But it might be nice to be able to do some if you want to.

18. Multiply-Add • Source level individual operations (add, multiply etc.) should be independent, hardware instructions can combine multiple operations (like Multiply-Add). • Make sure the operations in a combined instruction are exactly the same as those in individual instructions.

19. Limiting • Whatever number system you use it will have a range, even floating point. • Limiting will be required after every operation that can exceed the range, multiply, add, subtract and absolute value. • This includes the multiply in a multiply-add. • -1 x -1 = -1 ????????

20. Pipelines • User should never have to think about pipelines. • Variable pipelines are wrong. • Pipeline is not a panacea for timing problems, it limits the processing in a loop. • Pushing code through a branch. • Using the pipe for parameter passing.

21. Pipelines • Definition of pipeline length, count between the instruction that generates an item and an instruction that may use it. • Short circuiting the pipe. Useful, but not very useful. • Can unwind the execution by having pipeline-length prime relative to instruction count, but this adds to delay, which in turn adds to storage requirement.

22. Branching • If you can find another way avoid branches. • If you have to have jumps and a pipeline keep it all away from the programmer. • If you do have jumps they’ll likely break the guaranteed timing.

23. Conditional Execution • Conditional execution doesn’t break pipeline etc. • But you’ll need as many condition code stores as you have pipeline length. • Timing is identical for conditional execution and multiplexer.

24. Multiplexer • y = (a < 0.0) ? b : c; • Timing is identical for conditional execution and multiplexer. • With multiplexer you can use any variable as a control so no condition code store is required. • y = (a <= 0.0) ? b : c;

25. ABS • For simple bends in an input/output relationship, Absolute Value plus some Addition and Subtraction is more economical than most other methods.

26. Truncation, Rounding, Dither and Noise Shaping • For every instruction that needs it … … and just for Output • Assume fixed point • Floating point is hard

27. Truncation, Rounding and Truncation Towards Zero!. • Truncation is easy but has DC offset • Truncation Towards Zero! • ½ LSB offset number systems • Rounding wins and is not much more complex.

28. Dither • How do we make it? • Truly random, pseudo random, hash? • What colour do we want it to be? • What PDF do we want? • Make sure it’s un-correlated. • Want repeatability for test. • Problems with infinite gain components. • Rounding wins.

29. Noise shaping • What shape? • What order? • Want repeatability for test. • Problems with infinite gain components. • Rounding wins. • Make sure your instruction set can do dither and noise shaping.

30. Coefficient Interpolation • Coefficients as a sampled system • SRC called interpolation • HW or SW, 2-3 instructions to feed one. • Only in exceptional circumstances is it worth a hardware solution. • Linear is possible, first order filter is easy and works for many applications.

31. Coefficient Synchronization • Coefficient synchronisation. • Lots of people ignore it or treat it on a per use basis. • Can be done for linear or first order filters with ease. • This is really a synchronous sampling problem.

32. Coefficient Synchronization, Synchronization J i t t e r

33. Scaling, multiprocessors, synchronisation & segmentation • Not all solutions fit in a single processor. • Automatic segmentation of programs across multiple processors is possible. • But it is hard. • If the processors are not identical, and identically connected it’s very, very hard.

34. Scaling, multiprocessors, synchronisation & segmentation • If you have multiple processors and no branches then you can run them in lockstep, many examples. • For data transfer between processors simply send from one processor and receive by the other at the same time. • Disastrous for assembler, easy for compiler.

35. Scaling, multiprocessors, synchronisation & segmentation • How do you connect multiple processors, series or parallel? • If you chose either then you can’t do some algorithms. Use mesh or router instead. • Small routers are actually cheap and relatively easy to generate code for. • Multiple processors I/O, dedicated processor connections or is I/O a full member of the clan?

36. Constant folding and common code removal. • Easy in a compiler, often missed by an assembly language programmer. • Keep everything as source until the last possible moment. • That way common parts can be taken advantage of, constants, but more importantly data and instructions. • Leads to documentation of library functions requiring “at most X data memories and Y instructions”.

37. Libraries • Binary libraries don’t work well with pipelined processors, the cost of getting into or out of them is usually to great. • A binary library (like a dll) is NOT a secure method of distributing intellectual property. • Encrypted source going through a trusted tool-chain to generate encrypted binaries is the way to go.

38. Hardware with problems…. • Let’s just have one continuous data type (and maybe one integer type). • Different widths for different memories makes horrible problems. • Private instruction sets and ‘Useful’ instructions.

39. Hardware with problems…. • Do not chisel a digital analogue of an analogue circuit out of digits. • Sample rate to silicon clock ratio

40. Hardware with problems…. • Bi-quad coefficient ranges. • Feedback coefficients ranges need to be big enough. • Feed-forward coefficient ranges are not limited, they can get big. If there’s nowhere in your system to make gain, you’re in trouble.

41. Hardware with problems…. • The accumulator is dead. When hardware was expensive and DSP engineers were cheap it made sense to get performance this way, but that is no longer true. • Most of today’s algorithms aren’t sums of products anyway. • And it makes a high level description difficult.

42. Hardware with problems…. • Double precision is probably not the right thing for LF filters. • Choosing the right filter structure and adding a few bits is a financially better solution.

43. Hardware with problems…. • If you must have an accumulator make sure you can load and store it!

44. Hardware with problems…. • Shifting is required to get gain into the system. • There are few reasons for a shift of greater than 2^7 and very few for more than 2^15. • Shift after the multiplier, it’s the only place where there are the bits to shift. • Shift in the wrong place is common.

45. Hardware with problems…. • If a standard 5 coefficient bi-quad takes more than 5 instructions there’s something wrong. • A simple Z-1 delay, and cascades thereof should not consume instructions. • Simple rotating memory, and language support.

46. Hardware with problems…. • A pipeline needs to be started cleanly. • This is not always easy.

47. Debuggnig • Source level debugging is perfectly standard in almost every general purpose processor toolset, why is it missing from DSP toolsets?

48. Debuggnig • If you do add a debugger, remember that the objects you are processing are signals, thus they vary with time. • A numerical display of a signal is generally useless, like using a DVM to analyse audio, necessary but not sufficient. • Provide a scope and signal generator.

49. Debuggnig • Debugging Input or Output is a signal. • Easiest done by the instruction NOT the location.

50. How do we make DSP easier? • Get the algorithm away from the hardware • Use DSP that is compiler compatible