You can find the Cortex M4 instruction set documentation here. See post 365 in this thread for links to CMSIS DSP and rules of thumb for the number of bits needed in a filter implementation.

For audio DSP on the Cortex M4 I don't see any particular advantage to single precision floating point over 32 bit fixed point; SMLAL is a 64 bit accumulate while VFMA is a 32 bit accumulate. You might be able to save a few clocks with arm_biquad_cascade_df1_f32 compared to Q31 and maintain comparable precision at higher normalized frequencies. But it's probably not worth the additional scaling complexity and the CPU cycles for converting incoming samples to floating point and then back to fixed point for output.

Best way to be precise about CPU requirements versus accuracy is to set up your desired filter bank in F32 and Q31, look at the assembly the compiler generates, run some test vectors through both, and compare the output streams to reference output data calculated using F64 or something in the vicinity of Q63.

The seller has good English so if you have the requisite chat software installed, you can contact him.

Incidentally another snippet of gossip for ARM-philes : TI looks to be making a move away from ARM. For example the older M3 Stellaris parts have an EOL announcement and the newer parts with ARM on-board look to be just marketing ploys to sell TI's proprietary CPU. Expect the Stellaris M4 range never to be fully released, its been absolutely ages...

__________________"Having people devoted to attacking you – even in unfair, invalid or personal ways – is actually valuable for keeping one honest and self-reflective." - Glenn Greenwald

Incidentally another snippet of gossip for ARM-philes : TI looks to be making a move away from ARM. For example the older M3 Stellaris parts have an EOL announcement and the newer parts with ARM on-board look to be just marketing ploys to sell TI's proprietary CPU. Expect the Stellaris M4 range never to be fully released, its been absolutely ages...

Sorry for T.I. They missed the train. They may be cooked. I'm getting the same impression about Infineon XMC4500. China-based or Taiwan-based companies produce their own ARM-licenced chips nowadays. I'm afraid the whole USA silicon industry is due to collapse soon. We'll have the priviledge to watch this. Microsoft Windows 8 RT (for ARM) remaining an unfinished product, hesitating between tablet and desktop, the x86 era end got delayed by a few months. This helps hiding the fact that Intel is cooked. Even if Intel starts producing ARM-licenced chips for Apple, it is way too late and anyway volume will remain insignificant compared to worldwide figures. Now guess what will follow, after the USA silicon industry collapse?
There will be a new era opening with silicon chips embedding ROM describing their internal architecture using spice netlists and an XML description of their registers. Human will become less and less needed, for setting up and programming silicon devices. Complexity and versatility (reconfigurable silicon) will rise to a level, so high that it will come beyond human undertstanding. All what we are doing, at the moment, is prehistoric electronic engineering. This helps me swallow the pill of an imminent USA silicon industry collapse. Come back in 20 years. A child, of course assisted by design tools, will be able to design, assemble and program a computer equivalent to our best current desktops. A child will be able to design a cross-compiler enabling a Sinclair Spectrum Pacman source code, to run on it. A specialized 3D printer will enable such computer to replicate at a very low cost.
The fact that it took about 18 months for getting some kind of Cortex-M4 board executing IIRs (and I'm not even speaking about the fact that such board doesn't have audio ADCs and DACs), is an indication that electronics management, marketing, and engineering are outdated. Time has come for a radical new vertical integration. Only a few companies are on the right track. Those may survive.

I agree Steph - both TI and Intel are toast. The future belongs to the MediaTeks and Allwinners whose volumes are being ramped by sales of smartphones and tablets. TI's pulled out of where the real volumes are and Intel's only play-acting in mobile. The only question left in my mind is whether National (maybe in conjunction with BB) can be spun out once again before TI dies...

__________________"Having people devoted to attacking you – even in unfair, invalid or personal ways – is actually valuable for keeping one honest and self-reflective." - Glenn Greenwald

Sorry for T.I. They missed the train. They may be cooked. I'm getting the same impression about Infineon XMC4500.

You seems you are all going with some LPC4300 kits / builds. The Infineon XMC4500 Relax Lite kit (which also includes USB debugger) costs only 12.95 EUR on Mouser, but it seems quite a slow compared to LPC4330 (only 120 MHz system frequency). Might still be ok for couple of biquads though.

Btw. Is it possible to have an external clock (MCLK or oscillator) to be used to clock the SGIOP on the LPC parts? I would like to have as little jitter as possible and put oscillator on DAC board with the DAC itself running as slave.

XMC4500 seems to be support external clock. Strangely they call clock generation to baud rate generation in IIS context:

Quote:

Baud rate generation

Each USIC channel contains its own baud rate generator. The baud rate generation
can be based either on the internal module clock or on an external frequency input.
This structure allows data transfers with a frequency that can not be generated
internally, e.g. to synchronize several communication partners.

On XMC4500 there are three USIC's each containing two independent communications channels.

Depends on the biquad precision and the number of instructions required to drive the USICs, but 120MHz is probably enough for around 75 biquads for redbook, assuming a typical mix of 32 bit and 32x64 bit and that you're coding with the ARM CMSIS DSP library.

Quote:

Originally Posted by mhelin

Is it possible to have an external clock (MCLK or oscillator) to be used to clock the SGIOP on the LPC parts?

Yes, though I suppose an update to post 120 is in order. To summarize the LPC datasheet and manual, half of the SGPIO slices can be used as clocks for other slices. Additionally, there are two to four pins that can be used as inputs to the CGU (clock generation unit) and routed to the SGPIO peripheral. The number of pins depends on the package.

After studying the data sheet of XMC4500 better I realized that the external clock input is not for MCLK but for SCLK, or as they call it "shift clock" (=bit clock in I2S). If you divide the MCLK by 256/64 (MCLK/LRCLK ratio / frame length) =4 you get the proper frequency, but I'm not sure if XMC4500 can generate the LRCLK in slave mode. The data sheet is little bit void in some areas. The LPC4300 with SGIOP seems to be the M4F family best suited for 6 or more output channels.

Now has anyone designed his/her own boards yet? There were some posts regarding multiple multichannel DAC's that would be interchangeable. If this idea is still alive it would be nice if the pinout (and the physical connector, propably just a usual two-row 0.1" pin header with ground lines between the signal lines) for the multichannel DAC's would be published early. Regarding DAC's there is already one good quality multichannel DAC available from ASUS - ASUS Xonar H6 - it's meant for Xonar soundcard's surround channels but is quite good quality one (http://www.asus.com/Sound_Cards_and_...ters/Xonar_H6/). I have it's pinout somewhere, and if we sticked to that pinout then we don't need to build the DAC, only the processor board and power supplies + analog or digital input board (with or without SRC). H6 uses I2C (each of CODEC's has own address), and has one pin for mute relays. It's got also inputs for 3.3V, 5V and +/-12V (guess 12-18V is ok for the opamps) supplies.