XCore Exchange

Basically I am putting out an open call for suggestions for corrections and improvements to the batch of boards I am working on.

Essentially: where you foresee problems, egregious errors, things I overlooked etc.

I'm not too worried about the firmware aspect of the board, that's mostly written and well there is always ways to fix that! Mostly I'm looking for areas where I could have messed up: Trace widths, Introducing Noise, Potential for cross-talk, hardware level problems.

I just want to make sure this stage is done before I fret anymore about writing firmware for a board I don't have yet.

http://www.xcore.com/projects/mad-scien ... -interface Project Link.

Any chance of some PDFs?

Well I am not quite sure what you want pdfs of but here are a slew of them;

Schematics for boards and Datasheets for ADC and DAC and Clock.

I have a couple of comments...

schematics: have a look at XMOS' schematics and try to draw them in a simmiar way. don't cram the components together, and avoid diagonal wires. You already divided in functional blocks. Use the space. And don't use juntions to symbol a port. You have the ports there, connect the wires to them.

Board: Avoid unnecessarily thing traces.

L2: Unless you plan to send the boards to manufacture, you may be well served with two L1-TQFP 64 or 48 that can be easily soldered by hand. You are anyway not using all pins...

Are you planning SPDIF Ins and Outs ?

Have you considered using the CS2100 (with external reference)? We find the output jitter to be much smaller than the CS2300 (The CS2100 is what we now recommend)

ale500 wrote: Board: Avoid unnecessarily thing traces.

Explicate. Specifics are better.

ale500 wrote: L2: Unless you plan to send the boards to manufacture, you may be well served with two L1-TQFP 64 or 48 that can be easily soldered by hand. You are anyway not using all pins...

I would except i wasn't planning on doing any real hand soldering other than the jacks and ports.

I was instead and will Have a Solderpaste mask template cut and use a bed of sand in a Hotplate skillet to reflow the components actually. and while a bit risky -- meticulous placement of the L2 should have it right itself when the solder reflows.

ale500 wrote: Are you planning SPDIF Ins and Outs ?

No, never planned on this as a stereo system component.
I might perhaps draw up an XLR variant.

This was more working on DJ/Producer style of Audio Interface.

Ross wrote:Have you considered using the CS2100 (with external reference)? We find the output jitter to be much smaller than the CS2300 (The CS2100 is what we now recommend)

I had not, but I will now and will probably re-work as a revision.

** I have now started working on Ironing out putting that in, where Can I find the software control of the clock and such. In the USB 2.0 Multichannel SDK there was control for the 2300, is there equivalent for the 2100?

CivilDecline wrote:

Ross wrote:Have you considered using the CS2100 (with external reference)? We find the output jitter to be much smaller than the CS2300 (The CS2100 is what we now recommend)

I had not, but I will now and will probably re-work as a revision.

** I have now started working on Ironing out putting that in, where Can I find the software control of the clock and such. In the USB 2.0 Multichannel SDK there was control for the 2300, is there equivalent for the 2100?

The setup/control is exactly the same.

Edit: Just read your post re: S/PDIF input, if you have no digital streams to sync to I would advise using fixed local oscillators. We only use the clock multiplier so we can lock to an incoming digital stream (e.g. ADAT or S/PDIF). I would take a look at the clocking on the L1 board.

Ross wrote: The setup/control is exactly the same.

Awesome.

Ross wrote: Edit: Just read your post re: S/PDIF input, if you have no digital streams to sync to I would advise using fixed local oscillators. We only use the clock multiplier so we can lock to an incoming digital stream (e.g. ADAT or S/PDIF). I would take a look at the clocking on the L1 board.

its for changing bitrates between 44.1 and 48 families of sample rates
(i think unless your referencing something else)

CivilDecline wrote:

Ross wrote: The setup/control is exactly the same.

Awesome.

Ross wrote: Edit: Just read your post re: S/PDIF input, if you have no digital streams to sync to I would advise using fixed local oscillators. We only use the clock multiplier so we can lock to an incoming digital stream (e.g. ADAT or S/PDIF). I would take a look at the clocking on the L1 board.

its for changing bitrates between 44.1 and 48 families of sample rates
(i think unless your referencing something else)

Okay, you don't need a clock-multiplier to do that, just two different master clock sources (say two oscillators with a software controlled switch). We just use this multiplier when we want to lock to a external digital stream (the reference given to the clock multiplier from the XCore is derived from the stream).

You will get better performance, lower BOM and use less MIPS (since you wont have to generate this reference to the clock multiplier) if you use fixed master clocks (e.g. oscillators).

You could, of course, use an audio clock generator also to generate these fixed master clock frequencies.